Crate secret_toolkit_utils

Source
Expand description

§Secret Contract Development Toolkit - Utility Tools

⚠️ This package is a sub-package of the secret-toolkit package. Please see its crate page for more context.

This package contains various uncategorized tools. It should be thought of as the shed in your backyard where you put the stuff that doesn’t belong elsewhere. There isn’t an overarching theme for the items in this package.

§Table of Contents

  1. Calls module
  2. Feature Toggle module

§Calls module

This module contains traits used to call another contract. Do not forget to add the use statement for the traits you want.

use secret_toolkit::utils::{InitCallback, HandleCallback};

Also, don’t forget to add the toolkit dependency to your Cargo.toml

§Instantiating another contract

If you want to instantiate another contract, you should first copy/paste the InitMsg of that contract. For example, if you wanted to create an instance of the counter contract at https://github.com/enigmampc/secret-template

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
pub struct CounterInitMsg {
    pub count: i32,
}

impl InitCallback for CounterInitMsg {
    const BLOCK_SIZE: usize = 256;
}

You would copy/paste its InitMsg, and rename it so that it does not conflict with the InitMsg you have defined for your own contract. Then you would implement the InitCallback trait as above, setting the BLOCK_SIZE constant to the size of the blocks you want your instantiation message padded to.

let counter_init_msg = CounterInitMsg {
     count: 100
};

let cosmos_msg = counter_init_msg.to_cosmos_msg(
    None,
    "new_contract_label".to_string(),
    123,
    "CODE_HASH_OF_CONTRACT_YOU_WANT_TO_INSTANTIATE".to_string(),
    None,
)?;

response = Ok(Response::new().add_message(cosmos_msg));

Next, in the init or handle function that will instantiate the other contract, you will create an instance of the CounterInitMsg, call its to_cosmos_msg, and place the resulting CosmosMsg in the messages Vec of the InitResponse or HandleResponse that your function is returning. In this example, we are pretending that the code id of the counter contract is 123. Also, in this example, you are not sending any SCRT with the InitMsg, but if you needed to send 1 SCRT, you would replace the None in the to_cosmos_msg call with Some(Uint128(1000000)). The amount sent is in uscrt. Any CosmosMsg placed in the messages Vec will be executed after your contract has finished its own processing.

§Calling a handle function of another contract

You should first copy/paste the specific HandleMsg(s) you want to call. For example, if you wanted to reset the counter you instantiated above

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
pub enum CounterHandleMsg {
    Reset { count: i32 },
}

impl HandleCallback for CounterHandleMsg {
    const BLOCK_SIZE: usize = 256;
}

You would copy/paste the Reset variant of its HandleMsg enum, and rename the enum so that it does not conflict with the HandleMsg enum you have defined for your own contract. Then you would implement the HandleCallback trait as above, setting the BLOCK_SIZE constant to the size of the blocks you want your Reset message padded to. If you need to call multiple different Handle messages, even if they are to different contracts, you can include all the Handle messages as variants in the same enum (you can not have two variants with the same name within the same enum, though).

let reset_msg = CounterHandleMsg::Reset {
    count: 200,
};

let cosmos_msg = reset_msg.to_cosmos_msg(
    "CODE_HASH_OF_CONTRACT_YOU_WANT_TO_EXECUTE".to_string(),
    "ADDRESS_OF_CONTRACT_YOU_ARE_CALLING".to_string(),
    None,
)?;

response = Ok(Response::new().add_message(cosmos_msg));

Next, in the init or handle function that will call the other contract, you will create an instance of the CounterHandleMsg::Reset variant, call its to_cosmos_msg, and place the resulting CosmosMsg in the messages Vec of the InitResponse or HandleResponse that your function is returning. In this example, you are not sending any SCRT with the Reset message, but if you needed to send 1 SCRT, you would replace the None in the to_cosmos_msg call with Some(Uint128(1000000)). The amount sent is in uscrt. Any CosmosMsg placed in the messages Vec will be executed after your contract has finished its own processing.

§Querying another contract

You should first copy/paste the specific QueryMsg(s) you want to call. For example, if you wanted to get the count of the counter you instantiated above

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
#[serde(rename_all = "snake_case")]
pub enum CounterQueryMsg {
    GetCount {},
}

impl Query for CounterQueryMsg {
    const BLOCK_SIZE: usize = 256;
}

You would copy/paste the GetCount variant of its QueryMsg enum, and rename the enum so that it does not conflict with the QueryMsg enum you have defined for your own contract. Then you would implement the Query trait as above, setting the BLOCK_SIZE constant to the size of the blocks you want your query message padded to. If you need to perform multiple different queries, even if they are to different contracts, you can include all the Query messages as variants in the same enum (you can not have two variants with the same name within the same enum, though).

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
pub struct CountResponse {
    pub count: i32,
}

Next, you will copy/paste the response of the query. If the other contract defines its response to the query with a struct, you are good to go.

If, however, the other contract returns an enum variant, one approach is to copy the fields of the variant and place them in a struct. Because an enum variant gets serialized with the name of the variant, you will then also want to create a wrapper struct whose only field has the name of the variant, and whose type is the struct you defined with the variant’s fields. For example, if you wanted to do a token_info query of the SNIP20 reference implementation, I would recommend using the SNIP20 toolkit function, but just for the sake of example, let’s say you forgot that toolkit existed.

#[derive(Serialize, Deserialize, JsonSchema, Debug)]
pub struct TokenInfo {
    pub name: String,
    pub symbol: String,
    pub decimals: u8,
    pub total_supply: Option<Uint128>,
}

#[derive(Serialize, Deserialize, JsonSchema, Debug)]
pub struct TokenInfoResponse {
    pub token_info: TokenInfo,
}

You would copy the QueryAnswer::TokenInfo enum variant and create a TokenInfo struct with those fields. You should make all those fields public if you need to access them. Then you would create the TokenInfoResponse wrapper struct, which has only one field whose name is the name of the QueryAnswer variant in snake case (token_info). As a reminder, you only need to do this to properly deserialize the response if it was defined as an enum in the other contract.

Now to perform the query

let get_count = CounterQueryMsg::GetCount {};
let count_response: StdResult<CountResponse> = get_count.query(
    deps.as_ref().querier,
    "CODE_HASH_OF_CONTRACT_YOU_WANT_TO_QUERY".to_string(),
    "ADDRESS_OF_CONTRACT_YOU_ARE_QUERYING".to_string(),
);

You create an instance of the CounterQueryMsg::GetCount variant, and call its query function, returning its value to a variable of the response type. If you were doing a token_info query, you would write let token_info_resp: TokenInfoResponse = .... You MUST use explicit type annotation here.

§Feature Toggle

This module implements feature toggles for your contract. The main motivation behind it is to enable pausing/unpausing certain operations rather than pausing/unpausing the contract entirely, while providing you with helper functions that will reduce your code to a minimum.

The feature toggles are designed to be flexible, so you can choose whether to put entire messages under a toggle or just certain code sections, etc.

§Initializing Features

Normally you’d want to initialize the features in the instantiate() function:

#[entry_point]
pub fn instantiate(
    deps: DepsMut,
    _env: Env,
    info: MessageInfo,
    msg: InstantiateMsg,
) -> StdResult<Response> {
    FeatureToggle::init_features(
        deps.storage,
        vec![
            FeatureStatus {
                feature: Features::Feature1,
                status: Default::default(),
            },
            FeatureStatus {
                feature: Features::Feature2,
                status: Default::default(),
            },
        ],
        vec![info.sender], // Can put more than one pauser
    )?;

    Ok(Response::new())
}

The feature field in FeatureStatus can be anything, as long as it’s implementing serde::Serialize. In this example it’s:

#[derive(Serialize)]
pub enum Features {
    Feature1,
    Feature2,
}

For the status field, you should use the built-in FeatureToggle::Status enum:

#[derive(Serialize, Debug, Deserialize, Clone, JsonSchema, PartialEq)]
pub enum Status {
    NotPaused,
    Paused,
}

The defult value of Status is Status::NotPaused.

§Put a toggle on a message

Putting a toggle on a message (or any code section of your choosing) is as easy as calling FeatureToggle::require_not_paused(). For example if we have a Redeem message in our contract, and we initialized the feature as Features::Redeem:

fn redeem(
    deps: DepsMut,
    env: Env,
    amount: Option<u128>,
) -> StdResult<Response> {
    FeatureToggle::require_not_paused(deps.as_ref().storage, vec![Features::Redeem])?;

    // Continue with function's operation
    Ok(Response::new())
}

If the status of the Features::Redeem feature is Paused, the contract will error out and stop operation.

§Pause/unpause a feature

Firstly, we will need to add Pause and Unpause messages in our HandleMsg enum. We can simply use FeatureToggle::FeatureToggleHandleMsg - it’s an enum that contains default messages that FeatureToggle also has default implementation for:

pub enum ExecuteMsg {
    // Contract messages
    Redeem {
        amount: Option<Uint128>,
    },
    Etc {}, //..

    // Feature toggle
    Features(FeatureToggleHandleMsg::<Features>),
}

The FeatureToggle struct contains a default implementation for triggering (pausing/unpausing) a feature, so you can just call it from your execute() function:

#[entry_point]
pub fn execute(
    deps: DepsMut,
    env: Env,
    info: MessageInfo,
    msg: ExecuteMsg,
) -> StdResult<Response> {
    match msg {
        ExecuteMsg::Redeem { amount } => redeem(deps, env, amount),
        ExecuteMsg::Etc {} => etc(deps, env),
        ExecuteMsg::Features(m) => match m {
            FeatureToggleHandleMsg::Pause { features } => FeatureToggle::handle_pause(deps, &info, features),
            FeatureToggleHandleMsg::Unpause { features } => FeatureToggle::handle_unpause(deps, &info, features),
            // `SetPauser` and `RemovePauser` go here too
        },
    }
}

Note: FeatureToggle::pause() and FeatureToggle::unpause() requires info.sender to be a pauser!

§Adding/removing pausers

Similarly to the section above, add FeatureToggleHandleMsg to your HandleMsg.

Note: you should only add Features(FeatureToggleHandleMsg) to the HandleMsg enum once, and it’ll add all the supported messages.

FeatureToggle provides with default implementation for these too, but you can wrap it with your own logic like requiring the caller to be admin, etc.:

#[entry_point]
pub fn execute(
    deps: DepsMut,
    env: Env,
    info: MessageInfo,
    msg: ExecuteMsg,
) -> StdResult<Response> {
    // This is the same `match` clause from the section above
    match msg {
        ExecuteMsg::Redeem { amount } => redeem(deps, env, amount),
        ExecuteMsg::Features(m) => match m {
            FeatureToggleHandleMsg::SetPauser { address } => set_pauser(deps, info, address),
            FeatureToggleHandleMsg::RemovePauser { address } => remove_pauser(deps, info, address),
            // `Pause` and `Unpause` go here too
        },
    }
}

fn set_pauser(
    deps: DepsMut,
    info: MessageInfo,
    address: String,
) -> StdResult<Response> {
    let admin = get_admin()?;
    if admin != info.sender {
        return Err(StdError::generic_err("Unauthorized"));
    }

    let address = deps.api.addr_validate(&address)?;
    FeatureToggle::handle_set_pauser(deps, address)
}

fn remove_pauser(
    deps: DepsMut,
    info: MessageInfo,
    address: String,
) -> StdResult<Response> {
    let admin = get_admin()?;
    if admin != info.sender {
        return Err(StdError::generic_err("Unauthorized"));
    }

    let address = deps.api.addr_validate(&address)?;
    FeatureToggle::handle_remove_pauser(deps, address)
}

Note: set_pauser and remove_pauser are permissionless by default.

§Overriding the default implementation

If you don’t like the default implementation or want to override it for any other reason (for example, using a different storage namespace), you can do that by defining your own struct and implement FeatureToggleTrait for it:

struct TrollFeatureToggle {}

impl FeatureToggleTrait for TrollFeatureToggle {
    // This is mandatory
    const STORAGE_KEY: &'static [u8] = b"custom_and_super_cool_key";

    // This is optional
    fn pause<T: Serialize>(storage: &mut dyn Storage, features: Vec<T>) -> StdResult<()> {
        for f in features {
            Self::set_feature_status(storage, &f, Status::NotPaused)?;
        }

        Ok(())
    }

    // This is optional
    fn unpause<T: Serialize>(storage: &mut dyn Storage, features: Vec<T>) -> StdResult<()> {
        for f in features {
            Self::set_feature_status(storage, &f, Status::Paused)?;
        }

        Ok(())
    }
}

§Queries

Similarly to FeatureToggleHandleMsg, query messages (and default implementations) are also provided:

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
#[serde(rename_all = "snake_case")]
pub enum FeatureToggleQueryMsg<T: Serialize + DeserializeOwned> {
    Status {
        features: Vec<T>,
    },
    IsPauser {
        address: String,
    },
}

You can use them in your query() the same way you used FeatureToggleHandleMsg.

Re-exports§

Modules§