luru20-cw-address-like

Crates.ioluru20-cw-address-like
lib.rsluru20-cw-address-like
version2.0.0
sourcesrc
created_at2024-04-02 07:43:05.410612
updated_at2024-04-02 07:43:05.410612
descriptionA trait that marks unchecked or checked CosmWasm address strings
homepagehttps://luru.money
repositoryhttps://github.com/luru-money/cw-plus-plus
max_upload_size
id1193291
size4,684
(luru-money)

documentation

README

Luru20 CW Address Like

This crate provides an trait AddressLike, which marks types that can be used as addresses in CosmWasm, namely String and cosmwasm_std::Addr.

Background

In CosmWasm, there are two types that are typically used to represent addresses:

  • String - Represents an unverified address, which are used in contract APIs, i.e. messages and query responses.
  • cosmwasm_std::Addr - Represents an verified address, used in contract internal logics.

When a contract receives an address (as a String) from a message, it must not simply assume it is valid. Instead, it should use the deps.api.addr_validate method to verify it, which returns an Addr. The contract can then use the Addr in its business logics or save it in storage.

Similarly, the contract should also converts Addrs back to Strings when returning them in query responses.

The problem

A problem arises when we want to define a struct or enum that is to be used in both the API and internal logics. For example, consider a contract that saves a "config" in its storage, which uses an Addr inside to represent the address of the contract's owner, while also providing a query method for the config, which uses a String.

In such cases, developers may either define two types, one for each case:

struct Config {
    pub owner: Addr,
}

struct ConfigResponse {
    pub owner: String,
}

This approach works, but is somewhat cumbersome, especially when the config contains more fields.

Another approach is to define a single type that contains a generic:

struct Config<T> {
    pub owner: T,
}

Then use Config<String> in the API and Config<Addr> in internal logics.

The main drawback of this approach is there's no restriction on what T can be. It is theoretically possible to plug any type in as T here, not limited to String and Addr.

How to use

In this crate we provide an AddressLike trait, which is defined simply as:

pub trait AddressLike {}

impl AddressLike for Addr {}
impl AddressLike for String {}

The developer can then define their type as:

struct Config<T: AddressLike> {
    pub owner: T,
}

This restricts that only String and Addr can be used as T.

License

Contents of this crate at or prior to version 2.0.0 are published under GNU Affero General Public License v3 or later; contents after the said version are published under Apache-2.0 license.

Commit count: 93

cargo fmt