> ## Documentation Index
> Fetch the complete documentation index at: https://developers.stellar.org/llms.txt
> Use this file to discover all available pages before exploring further.

# 2. Deploy to Testnet

> Deploy Stellar smart contracts to Testnet using the CLI, interact with other contracts, test functionality, debug issues, and prepare for Mainnet deployment.

To recap what we've done so far, in [Setup](https://developers.stellar.org/docs/build/smart-contracts/getting-started/setup.md):

* we set up our local environment to write Rust smart contracts
* installed the stellar-cli
* created a `hello-world` project, then tested and built the `HelloWorld` contract

In this guide, we’ll generate a Testnet-funded identity, deploy the contract to Testnet, and interact with it using the Stellar CLI.

## Configure a Source Account

When you deploy a smart contract to a network, you need to specify a source account's keypair that will be used to sign the transactions.

Let's generate a keypair called `alice`. You can use any name you want, but it might be nice to have some named keys that you can use for testing, such as [`alice`, `bob`, and `carol`](https://en.wikipedia.org/wiki/Alice_and_Bob). Notice that the keypair's account will be funded using [Friendbot](https://developers.stellar.org/docs/networks.md#friendbot).

```sh theme={"theme":{"light":"github-light","dark":"github-dark"}}
stellar keys generate alice --network testnet --fund
```

You can see the public key of `alice` with:

```sh theme={"theme":{"light":"github-light","dark":"github-dark"}}
stellar keys address alice
```

You can see all of the keys you generated, along with where on your filesystem their information is stored, with:

```sh theme={"theme":{"light":"github-light","dark":"github-dark"}}
stellar keys ls -l
```

## Deploy

To deploy your HelloWorld contract, run the following command:

> [tab] macOS/Linux
>
> ```sh theme={"theme":{"light":"github-light","dark":"github-dark"}}
> stellar contract deploy \
>   --wasm target/wasm32v1-none/release/hello_world.wasm \
>   --source-account alice \
>   --network testnet \
>   --alias hello_world
> ```

> [tab] Windows (PowerShell)
>
> ```powershell theme={"theme":{"light":"github-light","dark":"github-dark"}}
> stellar contract deploy `
>   --wasm target/wasm32v1-none/release/hello_world.wasm `
>   --source-account alice `
>   --network testnet `
>   --alias hello_world
> ```

This returns the contract's id, starting with a `C`. In this example, we're going to use `CACDYF3CYMJEJTIVFESQYZTN67GO2R5D5IUABTCUG3HXQSRXCSOROBAN`, so replace it with your actual contract id.

> [!TIP]
>
> We used the `--alias` flag in this deploy command which will create a `~/.config/stellar/contract-ids/hello_world.json` file that maps the alias `hello_world` to the contract id and network. This allows us to refer to this contract as its alias instead the contract id.

## Interact

Using the code we wrote in [Write a Contract](https://developers.stellar.org/docs/build/smart-contracts/getting-started/hello-world.md#contract-source-code) and the resulting `.wasm` file we built in [Build](https://developers.stellar.org/docs/build/smart-contracts/getting-started/hello-world.md#build-the-contract), run the following command to invoke the `hello` function.

> [!NOTE]
>
> In the background, the CLI is making RPC calls. For information on that checkout out the [RPC](https://developers.stellar.org/docs/data/apis/rpc/admin-guide) reference page.

> [tab] macOS/Linux
>
> ```sh theme={"theme":{"light":"github-light","dark":"github-dark"}}
> stellar contract invoke \
>   --id CACDYF3CYMJEJTIVFESQYZTN67GO2R5D5IUABTCUG3HXQSRXCSOROBAN \
>   --source-account alice \
>   --network testnet \
>   -- \
>   hello \
>   --to RPC
> ```

> [tab] Windows (PowerShell)
>
> ```powershell theme={"theme":{"light":"github-light","dark":"github-dark"}}
> stellar contract invoke `
>   --id CACDYF3CYMJEJTIVFESQYZTN67GO2R5D5IUABTCUG3HXQSRXCSOROBAN `
>   --source-account alice `
>   --network testnet `
>   -- `
>   hello `
>   --to RPC
> ```

The following output should appear.

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
["Hello", "RPC"]
```

> [!NOTE]
>
> You may also see a message like:
>
> ```
> ℹ️  Simulation identified as read-only. Send by rerunning with `--send=yes`.
> ```
>
> This is expected! The `hello` function is **read-only**—it doesn't modify any on-chain state. When the CLI detects a read-only function, it automatically runs it as a **local simulation** instead of submitting a transaction to the network. This means:
>
> * **No fees**: The simulation is free—no transaction is submitted to the ledger.
> * **Instant result**: The output you see (`["Hello", "RPC"]`) is already the correct result.
> * **Ignore `--send=yes`**: For read-only functions, the simulation already gave you what you need.
>
> The `--send=yes` flag is only needed for **state-changing functions**—those that write to contract storage. For those, the CLI first simulates the transaction (to estimate fees and check for errors), then you use `--send=yes` to actually submit and persist changes on-chain.

> [!NOTE]
>
> The `--` double-dash is required!
>
> This is a general [CLI pattern](https://unix.stackexchange.com/questions/11376/what-does-double-dash-mean) used by other commands like [cargo run](https://doc.rust-lang.org/cargo/commands/cargo-run.html). Everything after the `--`, sometimes called [slop](https://github.com/clap-rs/clap/issues/971), is passed to a child process. In this case, `stellar contract invoke` builds an *implicit CLI* on-the-fly for the `hello` method in your contract. It can do this because Soroban SDK embeds your contract's schema / interface types right in the `.wasm` file that gets deployed on-chain. You can also try:
>
> ```sh theme={"theme":{"light":"github-light","dark":"github-dark"}}
> stellar contract invoke ... -- --help
> ```
>
> and
>
> ```sh theme={"theme":{"light":"github-light","dark":"github-dark"}}
> stellar contract invoke ... -- hello --help
> ```

## Summary

In this lesson, we learned how to:

* deploy a contract to Testnet
* interact with a deployed contract

Next we'll add a new contract to this project, and see how our workspace can accommodate a multi-contract project. The new contract will show off a little bit of Soroban's storage capabilities.