Skip to main content

Featured

From Monad 101 Session 1 to Web3 MVP: Building with AI Prompts Hey folks! As a full-stack blockchain dev hustling through hackathons in Hyderabad, I just wrapped Session 1 of  Monad 101 Speedrun HYD Edition  (Jan 2026). It was a game-changer—focusing on Web3 basics, Monad's parallel EVM, and  AI-powered workflows  to ship dApps fast. No fluff, just prompts that spit out deployable code. Here's how I built a basic "Counter" Web3 app in under an hour using simple AI instructions. What I Learned in Session 1 Session 1 dove into Monad testnet setup, wallet integration (MetaMask vibes), and leveraging tools like Cursor IDE or local Ollama models for 10x faster prototyping. The mantra?  Prompt > Code > Deploy . Perfect for my late-night hackathon sprints where time = prizes. Key gems: Monad's 10k TPS EVM means no gas wars—ideal for gaming dApps like my Solana battle arenas. AI handles 80% boilerplate; I tweak for security/tokenomics. Step-by-Step: AI → Working d...

Deep Dive into CosmWasm Contract Standards: CW20, CW721, CW4, and CW3

Deep Dive into CosmWasm Contract Standards: CW20, CW721, CW4, and CW3

CosmWasm provides several smart contract standards for different use cases in the Cosmos ecosystem. In this guide, we will explore four key standards: CW20, CW721, CW4, and CW3. These standards enable developers to create and manage fungible tokens, non-fungible tokens (NFTs), group memberships, and multisig wallets, respectively.



CW20: Fungible Token Standard

The CW20 standard is the equivalent of ERC20 in the Ethereum ecosystem. It defines a standard interface for fungible tokens in the Cosmos ecosystem. This standard allows for the creation, transfer, and management of fungible tokens within a CosmWasm-based blockchain.

Structure

Key Components:

Messages (Msg): Define the actions that can be performed, such as minting, transferring, and burning tokens.

State: Defines the data structures for storing token balances, allowances, and metadata.

Query: Provides functions to query token information like balance, total supply, and allowances.

Example:

pub struct InstantiateMsg {
    pub name: String,
    pub symbol: String,
    pub decimals: u8,
    pub initial_balances: Vec<Cw20Coin>,
}

pub struct ExecuteMsg {
    Transfer { recipient: String, amount: Uint128 },
    Burn { amount: Uint128 },
    Mint { recipient: String, amount: Uint128 },
}

pub struct QueryMsg {
    Balance { address: String },
    TokenInfo {},
}

pub struct TokenInfoResponse {
    pub name: String,
    pub symbol: String,
    pub decimals: u8,
    pub total_supply: Uint128,
}

CW20_ICS20: IBC Enabled CW20

The cw20_ics20 contract extends the CW20 standard to support Inter-Blockchain Communication (IBC). This allows CW20 tokens to be sent across different chains using the ICS20 protocol. The main functionality of this contract includes:

Sending Tokens: 

Allows CW20 tokens to be sent from one chain to another.

Redeeming Tokens: Allows previously sent tokens to be redeemed on the destination chain.

Key Features:

IBC Integration: Uses the ICS20 protocol to enable cross-chain token transfers.

Error Handling: Implements error messages for handling issues with the Go ibctransfer module.

For more details, you can refer to the cw20_ics20 README.

Structure:

Key Components:

IBC Messages: Define actions for sending and receiving tokens across chains.

Error Handling: Implements error handling for cross-chain transactions.

State: Manages token transfers and redemptions.

CW721: Non-Fungible Token (NFT) Standard

The CW721 standard is the equivalent of ERC721 in the Ethereum ecosystem. It defines a standard interface for non-fungible tokens, which are unique and indivisible. CW721 allows for the creation, transfer, and management of NFTs within a CosmWasm-based blockchain.


Key Features:

Unique Assets: Each token has a unique identifier.

Metadata: Supports additional metadata for each token, such as name, description, and image.

Ownership: Allows for transferring ownership of tokens.

The CW721 standard provides a flexible and efficient way to handle NFTs in the Cosmos ecosystem, ensuring interoperability and ease of use for developers and users.

Structure:

Key Components:

Messages (Msg): Define actions for minting, transferring, and burning NFTs.

State: Defines data structures for storing NFT ownership and metadata.

Query: Provides functions to query NFT details like owner, token metadata, and total supply.

Example:

pub struct InstantiateMsg {

    pub name: String,

    pub symbol: String,

}

pub struct ExecuteMsg {

    Mint { token_id: String, owner: String, metadata: Option<String> },

    Transfer { recipient: String, token_id: String },

    Burn { token_id: String },

}

pub struct QueryMsg {

    Owner { token_id: String },

    NftInfo { token_id: String },

    AllNftInfo { token_id: String },

}

pub struct NftInfoResponse {

    pub owner: String,

    pub metadata: Option<String>,

}

CW4: Group Membership Standard

CW4 is a specification for managing group memberships. It is often used in conjunction with CW3 multisig contracts. The purpose of CW4 is to store a set of members or voters that can be accessed to determine permissions in other contracts.


Key Components:

Membership Storage: Stores information about group members, including their weights (voting power).

Membership Queries: Provides functionalities to query membership details and total weight.

Membership Updates: Allows for adding, updating, or removing members.

Structs:

Cw4Contract: A wrapper around addresses providing helpers for CW4 contracts.

Member: Represents a group member with an associated weight.

MemberDiff: Shows the old and new states for a given member.

Enums:

Cw4ExecuteMsg: Execution messages for CW4 contracts.

Cw4QueryMsg: Query messages for CW4 contracts.

For more details, refer to the cw4 README.

Structure:

Key Components:

Messages (Msg): Define actions for adding, updating, and removing members.

State: Stores membership information and weights.

Query: Provides functions to query member details and total weights.

Example:

pub struct InstantiateMsg {

    pub admin: Option<String>,

    pub members: Vec<Member>,

}

pub struct ExecuteMsg {

    AddMember { member: Member },

    RemoveMember { address: String },

    UpdateMember { member: Member },

}

pub struct QueryMsg {

    Member { address: String },

    TotalWeight {},

}


pub struct Member {

    pub address: String,

    pub weight: u64,

}

pub struct MemberResponse {

    pub weight: u64,

}

pub struct TotalWeightResponse {

    pub weight: u64,

}

CW3: Multisig Wallet Standard

CW3 is a specification for multisig wallets. Multisig wallets require multiple approvals (signatures) to execute transactions, providing an extra layer of security. The CW3 standard allows for the creation and management of multisig wallets within the Cosmos ecosystem.


Key Features:

Multisig Management: Allows for the creation of multisig wallets with customizable approval requirements.

Transaction Proposals: Users can create proposals that require multiple signatures to be executed.

Membership Integration: Can be combined with CW4 to manage the set of signers dynamically.

Components:

Threshold: Defines the number of signatures required to approve a transaction.

Proposals: Mechanism to create, approve, and execute transaction proposals.

CW3 contracts provide robust functionalities for managing secure multisig wallets, making them ideal for managing community funds, DAOs, and other collaborative projects.

Structure: 

Key Components:

Messages (Msg): Define actions for creating proposals, voting, and executing transactions.

State: Stores proposals, votes, and multisig configuration.

Query: Provides functions to query proposal details, vote status, and wallet configuration.

Example:

pub struct InstantiateMsg {

    pub voters: Vec<Voter>,

    pub threshold: u64,

}

pub struct ExecuteMsg {

    SubmitProposal { proposal: Proposal },

    Vote { proposal_id: u64, vote: VoteOption },

    ExecuteProposal { proposal_id: u64 },

}

pub struct QueryMsg {

    Proposal { proposal_id: u64 },

    Vote { proposal_id: u64, voter: String },

    Threshold {},

}

pub struct Proposal {

    pub title: String,

    pub description: String,

    pub actions: Vec<Action>,

}

pub struct Voter {

    pub address: String,

    pub weight: u64,

}

pub struct ProposalResponse {

    pub proposal: Proposal,

    pub status: ProposalStatus,

    pub votes: Vec<VoteResponse>,

}

pub struct VoteResponse {

    pub voter: String,

    pub vote: VoteOption,

}

pub struct ThresholdResponse {

    pub threshold: u64,

}

Conclusion

This guide provides an overview of the structures and key components of CosmWasm's contract standards CW20, CW721, CW4, and CW3 offer powerful tools for developers in the Cosmos ecosystem. They provide standardized interfaces and functionalities for managing fungible tokens, non-fungible tokens, group memberships, and multisig wallets. By leveraging these standards, developers can build interoperable and secure blockchain applications with ease.



For further details and implementation examples, please refer to the respective GitHub repositories in the CosmWasm cw-plus project.

Comments

Popular Posts