- Home
- Skills
- Multiversx
- Mx Ai Skills
- Multiversx Smart Contracts
multiversx-smart-contracts_skill
10
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill multiversx/mx-ai-skills --skill multiversx-smart-contracts- SKILL.md29.7 KB
Overview
This skill helps you build, test, and deploy MultiversX smart contracts using Rust, the sc-meta scaffolding tool, and mxpy. It provides concrete patterns for contract structure, storage mappers, payment handling, events, and safe cross-contract calls. Use it to implement tokens, NFTs, staking, crowdfunding, and any on-chain business logic.
How this skill works
It inspects common contract patterns and recommends Rust SDK primitives including annotations, storage mappers, and payment APIs. It guides use of sc-meta for scaffolding, Cargo configuration for compilation to WASM, and mxpy for deployment. It emphasizes type-safe payments (Payment + NonZeroBigUint), the Tx builder for transfers, and correct mapper choices for gas and iteration needs.
When to use it
- Building new on-chain logic or custom token standards (ESDT, NFT, META-ESDT).
- Implementing payable endpoints, staking, minting, or crowdfunding mechanics.
- Scaffolding a contract quickly with sc-meta templates and deploying with mxpy.
- Refactoring legacy payment code to the unified TokenId/Payment API.
Best practices
- Prefer Payment<TokenId> and NonZeroBigUint to prevent zero-value transfers.
- Use the Tx builder API for all transfers and cross-contract calls instead of legacy send APIs.
- Choose storage mappers based on access patterns: SetMapper for iterable uniqueness, UnorderedSetMapper for cheaper non-ordered sets, MapMapper only when key iteration is required.
- Annotate methods properly: #[init] for constructors, #[endpoint] for mutable calls, #[view] for read-only access.
- Favor TokenId (EGLD represented as EGLD-000000) over legacy identifiers for uniform token handling.
Example use cases
- Create a fungible token contract that issues, mints, and tracks balances with FungibleTokenMapper.
- Build an NFT minting contract using NonFungibleTokenMapper and UniqueIdMapper for token IDs.
- Implement a staking contract with TimelockMapper to schedule admin changes and QueueMapper for reward distribution.
- Develop a crowdfunding contract that accepts multiple payments and tracks backers with MapStorageMapper or SetMapper.
- Write upgrade-safe contracts with #[upgrade] handlers and storage mapper patterns for migrations.
FAQ
Use AddressToIdMapper to assign compact numeric IDs and save gas when tracking many users; it provides O(1) membership and address lookup by ID.
How do I accept both EGLD and ESDT payments safely?
Mark the endpoint #[payable] and use self.call_value().single() or .all() to obtain Payment values where token_identifier is TokenId and amount is NonZeroBigUint, ensuring non-zero transfers and unified handling.