Skip to main content
To recap what we’ve done so far, in Setup:
  • 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. Notice that the keypair’s account will be funded using Friendbot.
You can see the public key of alice with:
You can see all of the keys you generated, along with where on your filesystem their information is stored, with:

​
Deploy

To deploy your HelloWorld contract, run the following command:
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.
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 and the resulting .wasm file we built in Build, run the following command to invoke the hello function.
In the background, the CLI is making RPC calls. For information on that checkout out the RPC reference page.
The following output should appear.
You may also see a message like:
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.
The -- double-dash is required!This is a general CLI pattern used by other commands like cargo run. Everything after the --, sometimes called slop, 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:
and

​
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.