10 releases (4 breaking)

0.5.0 Jan 9, 2024
0.4.2 Nov 29, 2023
0.3.2 Nov 4, 2023
0.3.0 Oct 30, 2023
0.1.0 Sep 3, 2023

#1575 in Magic Beans

Download history 8/week @ 2024-01-05 1/week @ 2024-02-16 5/week @ 2024-02-23 2/week @ 2024-03-01 41/week @ 2024-03-08 173/week @ 2024-03-15 5/week @ 2024-03-29

219 downloads per month


615 lines


A framework for publishing, developing, deploying, and upgrading Soroban smart contracts.

You can think of it as a package manager for Smart Contracts.

Consider the following contract:

use soroban_sdk::{self, contract, contractimpl};

pub struct ContractA;

impl ContractA {
    pub fn add(x: u32, y: u32) -> u32 {
        x.checked_add(y).expect("no overflow")


The last line smartdeploy_sdk::core_riff ensures that the contract is redeployable.

After building you can publish the contract:

smartdeploy call smartdeploy --fee 10000 -- \
                                publish \
                                --contract-name contract-a \
                                --wasm-file-path .../contract_a.wasm \
                                --author default

This invokes the smartdeploy contract directly and calling the method publish. It also uses --wasm-file-path read in the bytes of the file as the arg.

To deploy you can use the deploy subcommand which, as we'll see later, creates a CLI interface for calling a custom init function of the contract in the same transaction as the deploy.

smartdeploy deploy --published-name contract_a \
                   --deployed-name contract_a \
                   --source default

Now let's say that we have a second contract b

use soroban_sdk::{self, contract, contractimpl, Address, Env};


pub struct ContractB;

impl ContractB {
    /// Add two numbers using the `add` method of ContractA.
    pub fn add_with(env: Env, contract_id: Address, x: u32, y: u32) -> u32 {
        contract_a::Client::new(&env, &contract_id).add(&x, &y)


We can "install" contract_a and then reference it to create a client:

smartdeploy install contract_a

Now the import_contract macro let's you import the contract the same way you would depend on a normal rust depenedency.

contract_a::Client::new(&env, &contract_id).add(&x, &y)

Now build the contract since contract_a was added to target/smartdeploy/contract_a/index.wasm

soroban contract build --package contract-b

Next after publishing and deploying contract_b, let's take this a step further and create a third contract.

use soroban_sdk::{self, contract, contractimpl, symbol_short, Env, Symbol};


pub struct ContractC;

const KEY: &Symbol = &symbol_short!("KEY");

fn default_value(env: &Env) -> u32 {

impl ContractC {
    /// Initialize the contract with a number to be used as the default value.
    pub fn init(env: Env, num: u32) {
        if !env.storage().instance().has(KEY) {
            env.storage().instance().set(KEY, &num);
    /// Add two numbers using the `add` method of ContractA.
    pub fn add_with(env: Env, x: u32, y: Option<u32>) -> u32 {
            &y.unwrap_or_else(|| default_value(&env)),


We'll need to install contract_b as well

smartdeploy install contract_b

This also adds a target/smartdeploy/contract_b/contract_id.txt file with the contract id of the contract. With the contract's id we can create client directly without the need to track down the contract id


And we can access the address directly


This is super handy for oracle contracts or any contract that you want developers to call in their contracts.

You'll also notice that this contract has an init method. Currently with the soroban CLI you cannot deploy and invoke a contract in one step. You can with smartdeploy!

Just like the awesome feature of the soroban CLI, smartdeploy generates a CLI for the contract that is to be deployed. You can access the possible methods with --help

smartdeploy deploy --published-name contract_c \
                   deployed-name c3pO \
                   --source default \ 
                   -- \
smartdeploy deploy --published-name contract_c --deployed-name c3pO -- --help
Usage: c3pO [COMMAND]

  owner_get  Returns the owner of the contract
  owner_set  Sets the owner of the contract. If one already set it transfers it to the new owner, if signed by owner.
  redeploy   Redeploy the contract to a wasm hash
  help       Print this message or the help of the given subcommand(s)

  -h, --help  Print help
smartdeploy deploy --published-name contract_c \
                   deployed-name c3pO \
                   --source default \ 
                   -- \
                   init --num 41

Now we can call the contract with smartdeploy call and leave off the --y argument, which should then default to 41.

smartdeploy call c3pO -- add_with --x 1

This calls creates a cross contract call to contract_b and then it calls contract_a. All without having to manually reference any contract ids!

Smartdeploy is also a Dapp!

Check it out here: launch.smartdeploy.dev.

It current lets you see all published contracts:


Deploy them:


And see all deployed contracts


Coming soon:

  • Autogenerated init method input forms for when deploying like you can with the CLI.
  • Autogenerated forms for any deployed contract's methods (not just deployed smartdeploy)!
  • Indexing will let dapp let you quickly search about contracts like crates.io.

Getting started

The key idea behind smartdeploy is that contract should be redeployable and maintainable. To solve this smartdeploy allows for publishing contract binaries and set of primitives to ensure that contracts can be redeployed.


First you need to add smartdeploy-sdk to your contract's Cargo.toml

cargo add smartdeploy-sdk


Currently smartdeploy relies on yet unstable version of the CLI

cargo install soroban-cli --version 20.0.0-rc4

Next you need to add the following line to your contract:


This adds three methods to your contract: owner_set, owner_get, and redeploy. After deploying your contract you must call owner_set, with your account so that you can call redploy, providing the hash of an installed contract (see next section for more info).

However, while you are developing this can be tedious so there is also dev_deploy.


This adds the method dev_deploy to your contract. This let's you redeploy your contract with just a wasm binary. However, it is not meant to be used on a public network as anyone can call it.

So assuming you choose the later option, after initially deploying your contract, you'll get a contract id, e.g.CA5YTYGCKWYJW7P3JNSMVKV2HRN4TOFMZ2VW4AQ5WQS4P3BGHNOU3PPX.

Then after making changes to your contract you can redeploy with the following:

                        --network <standalone/futurenet> \
                        --fee 1000000 \
                        --source <address or name of identity> \ 
                        -- \ 
                        dev_deploy --wasm-file-path <path/to/contarct.wasm>

This makes use of the new --<arg>-file-path argument that is added to the contract's generated CLI, allowing you to pass a file as the input to the contract's method. --fee is also used because the default is 100, which is probably not enough for the cost of including the bytes of your contract.

The other core idea behind smartdeploy is that contract can be published so that anyone can deploy an instance of it. This means that this fee is only paid by the contract publisher.

Note you can also use a .env file in the same directory where you call invoke to set CLI arguments. For example,


Uses Loam-SDK

Smartdeploy CLI


cargo install smartdeploy-cli

Currently the smartdeploy CLI has a install and call subcommand which lets you use a deployed contract's name when invoking it.

cargo run -- call smartdeploy -- --help

Can list out deployed_contracts

cargo run -- call smartdeploy -- list_deployed_contracts


~1.5M SLoC