IOTA Developer Cheat Sheet

Quick reference on best practices for IOTA Network developers.

Dev Sheet

Commands	Description
which iota	to check if iota is already installed or not.
iota client	to connect to IOTA network
iota client envs	to check environments
iota client new-env --alias <ALIAS> --rpc <RPC>	to create new environment.
iota client switch --env <EnvAlias>	to switch another environment.
RUST_LOG="off,iota_node=info" cargo run --bin iota start --force-regenesis --with-faucet	to start local network.
iota keytool list	to list all the address.
iota move new first_package	to create new move package.
pnpm create @iota/dapp --template react-client-dapp	to setup React app with dApp kit
cargo install --locked --git https://github.com/iotaledger/iota.git --branch <BRANCH-NAME> --features gas-profiler iota	To get the latest version of CLI
iota client active-address	to get the current address.
iota client -–help	to list out all commands of iota client.
iota client new-address <Scheme> Scheme	to generate address , Scheme - (ed25519,secp256k1,secp256r1)

Move

Topic	Description
General	Upgrading a package (P to P') doesn't auto-update dependencies; update dependent packages and clients explicitly. Public function signatures can't be deleted/changed; use public(package) or private visibility unless exposing permanent library functions. It is not possible to delete struct types, add new fields (though you can add dynamic fields), or add new abilities via an upgrade. Introduce new types carefully—they will live forever! Use vector-backed collections (vector, VecSet, VecMap, PriorityQueue) with a known maximum size of ≤ 1000 items. Use dynamic field-backed collections (Table, Bag, ObjectBag, ObjectTable, LinkedTable) for any collection that allows third-party addition, larger collections, and collections of unknown size. Move objects have a maximum size of 250KB—any attempt to create a larger object leads to an aborted transaction. Ensure that your objects do not have an ever-growing vector-backed collection. If your function f needs a payment in (e.g.) IOTA from the caller, use fun f(payment: Coin<IOTA>) not fun f(payment: &mut Coin<IOTA>, amount: u64). This is safer for callers—they know exactly how much they are paying, and do not need to trust f to extract the right amount. Don't micro-optimize gas usage. IOTA computation costs are rounded up to the closest bucket, so only very drastic changes will make a difference. In particular, if your transaction is already in the lowest cost bucket, it can't get any cheaper. Follow the Move coding conventions for consistent style.
Composability	Use the display standard to customize how your objects show up in wallets, apps, and explorers Avoid "self-transfers"—whenever possible, instead of writing transfer::transfer(obj, tx_context::sender(ctx)), return obj from the current function. This allows a caller or programmable transaction block to use obj.
Testing	Use iota::test_scenario to mimic multi-transaction, multi-sender test scenarios. Use the iota::test_utils module for better test error messages via assert_eq, debug printing via print, and test-only destruction via destroy. Use iota move test --coverage to compute code coverage information for your tests, and iota move coverage source --module <name> to see uncovered lines highlighted in red. Push coverage all the way to 100% if feasible.

Apps

Topic	Description
Optimal performance	For optimal performance and data consistency, apps should use the wallet's signTransactionBlock API to sign transactions and then submit them via execute_transactionBlock on the app's full node. This ensures immediate read-after-write consistency, as the app's full node reflects writes instantly, avoiding delays from checkpointing.
Lower latency	For lower latency, use executeTransactionBlock with "showEffects": false and "showEvents": false if your app only needs confirmation of a transaction without immediate access to its effects or events.
Local cache	Apps should implement a local cache for frequently read data rather than over-fetching from the full node.
Transaction cache	Whenever possible,use programmable transaction blocks to compose on-chain functionality instead of deploying new contracts, enabling batching and lowering gas fees.
Wallet dependency	Apps should leave gas budget, gas price, and coin selection to the wallet. This gives wallets more flexibility, and it's the wallet's responsibility to dry run a transaction to ensure it doesn't fail.

Signing

Topic	Description
Concurrent Transactions	Avoid signing concurrent transactions involving the same owned object. Use independent objects or wait for one transaction to finish to prevent client equivocation, which can lock the objects until the epoch ends.
CLI transaction	Use the --serialize-output flag with any iota client command (e.g., publish, call) to generate a base64 transaction for signing.
Transaction Signing	IOTA supports several signature schemes for transaction signing, including native multisig.

Feedback Form

Title *

Describe your feedback here