mvx_sc_best_practices_skill

Overview

This skill provides expert guidelines for developing, auditing, and optimizing MultiversX smart contracts written with the multiversx-sc framework. It focuses on storage and gas efficiency, security patterns, testing, and production-ready organization to build safer, cheaper, and more maintainable contracts. The guidance is practical and targeted at Rust-based MultiversX contract teams and auditors.

How this skill works

The guidance inspects common contract design choices and recommends storage mappers and idiomatic patterns to minimize writes and gas. It outlines security practices (arithmetic, reentrancy, access control), testing workflows (Mandos and unit tests), and production patterns like caching, error constants, and modular views. Recommendations include concrete code patterns for caching, storage access, events, and cross-contract read shortcuts.

When to use it

• When designing new MultiversX smart contracts to minimize gas and storage cost.
• While auditing contracts to find DoS vectors, reentrancy risks, and inefficient storage usage.
• Before deploying to production to add tests, validations, and access controls.
• When optimizing deployed contracts for gas by refactoring storage mappers and batching writes.
• When writing integration tests or Mandos scenarios to verify happy and error paths.

Best practices

• Prefer SingleValueMapper for individual values and avoid MapMapper unless iteration is required.
• Use BigUint for all token and financial math; reserve u64/u32 for counters or small IDs.
• Follow Checks-Effects-Interactions and validate state in callbacks for async calls.
• Never iterate potentially unbounded VecMapper on-chain; treat loops as gas risks.
• Use Managed types (ManagedVec, ManagedBuffer, ManagedAddress) to reduce serialization overhead.
• Centralize require! checks in a validation module and keep views in a dedicated views.rs for clarity.

Example use cases

• Implementing a token sale contract that minimizes storage writes and validates token identifiers.
• Auditing an existing contract to replace MapMapper usage and remove on-chain loops that can gas-exhaust the block.
• Building a staking contract using BigUint for rewards, access control modules for admins, and Mandos for scenario tests.
• Refactoring a contract to use a Drop-based storage cache to batch reads/writes and cut gas costs.
• Reading another same-shard contract’s reserve value via storage_mapper_from_address for a cheaper cross-contract read.