# IOTA Documentation > IOTA is a next-generation smart contract platform with high throughput, low latency, and an asset-oriented programming model powered by Move This file contains all documentation content in a single document following the llmstxt.org standard. ## FAQs ## 1. How does the MoveVM improve security and developer experience? MoveVM offers: - **Resource-Oriented Programming:** Secure and flexible asset management. - **Strong Data Abstraction:** Simplifies resource management tasks. - **Static Verification:** Detects errors before code execution, enhancing security. - **Formal Verification Support:** Allows rigorous validation of smart contract logic. - **Improved Developer Experience:** Reduces bugs and vulnerabilities through strict typing. ## 2. How can I participate in the testnet and provide feedback? To participate: - **Join the Public Testnet:** Access the IOTA public testnet to explore new features. - **Provide Feedback:** Use dedicated channels on the [IOTA Builders Discord](https://discord.gg/iota-builders) server or [GitHub](https://github.com/iotaledger/iota) to report issues. ## 3. What are the hardware requirements for validators? [Validators](https://docs.iota.org/operator/validator-node/overview) are expected to have: - **RAM:** 128 GB - **CPU:** 24-core processor / 48 vCPUs - **Storage:** 4 TB NVMe SSD - **Network Uplink:** 1 Gbps - **Minimum Stake:** 2 million IOTAs (can be delegated to your validator by someone else) - **RAM:** 64 GB - **CPU:** 8-core processor / 16 vCPUs - **Storage:** 2 TB NVMe SSD - **Network Uplink:** 1 Gbps - **Minimum Stake:** 2 million IOTAs (can be delegated to your validator by someone else) ## 4. What happens to the existing IOTA EVM? The [IOTA EVM](https://wiki.iota.org/isc/introduction/) on Layer 2 will: - **Continue Operating:** It will eventually run alongside the new IOTA Layer 1. - **Integration Plans:** Future plans include integrating EVM capabilities directly into Layer 1. - **Temporary Pause During Upgrade:** The EVM chain will be paused and upgraded but will resume normal operations afterward. ## 5. What are the key features introduced with IOTA Rebased? Key features include: - **L1 Smart Contracts:** Smart contract capabilities directly on the Layer 1 network using MoveVM. - **[Delegated Proof of Stake (dPoS)](./tokenomics/proof-of-stake.mdx):** A fully decentralized network governed by validators and stakers. - **[Enhanced Tokenomics](./tokenomics/tokenomics.mdx):** Staking rewards, transaction fees with fee-burning, and storage deposits. - **[Improved Security and Performance](./iota-architecture/iota-security.mdx):** Resilient [consensus](./iota-architecture/consensus.mdx) mechanisms, fairer gas pricing, and dynamic validator selection. ## 6. Why is IOTA moving to the MoveVM and an object-based architecture? The shift to the MoveVM and an object-based architecture is designed to: - **Enhance Flexibility and Programmability:** Allow complex applications to be written via smart contracts directly on L1. - **Support Advanced Use Cases:** Enable sophisticated financial instruments, decentralized exchanges, and intricate supply chain systems. - **Improve Security:** Leverage MoveVM features like resource-oriented programming and static verification to enhance security. - **Simplify Development:** Provide strong data abstraction capabilities and support for formal verification, improving the developer experience. ## 7. How will the tokenomics change under the IOTA Rebased proposal? The new tokenomics model includes: - **[Staking Rewards](./tokenomics/validators-staking.mdx):** Validators and delegators receive newly minted IOTA tokens as rewards (approximately 767,000 IOTAs per epoch), resulting in an initial annual inflation rate of about 6%. - **[Transaction Fees](./tokenomics/gas-pricing.mdx):** Small fees are charged on transactions (around 0.005 IOTA for an average transaction) and are burned to create deflationary pressure. - **[Storage Deposits](./tokenomics/gas-pricing.mdx#storage-units):** A redeemable deposit is required for storage, similar to the storage deposit system used in IOTA Stardust. ## 8. How does staking work in the new tokenomics model? Staking involves: - **[Delegation to Validators](./tokenomics/validators-staking.mdx):** Token holders can delegate their tokens to validators to help secure the network. - **[Earning Rewards](./tokenomics/validators-staking.mdx#validator-pool-rewards):** Both validators and their delegators receive staking rewards from newly minted tokens. - **Proportional Distribution:** Rewards are distributed based on the amount of stake and validator commissions. ## 9. How will the new fee-burning mechanism work? The fee-burning mechanism: - **Burns Transaction Fees:** Collected fees are burned, reducing the overall token supply. - **Deflationary Effect:** Increased network usage leads to more fees burned, creating deflationary pressure. - **Supply Dynamics:** The mechanism balances inflation from staking rewards and deflation from fee burning. ## 10. How will the introduction of transaction fees affect users? Transaction fees are minimal and serve as a congestion control mechanism: - **Low Fees:** Approximately 0.005 IOTA per average transaction. - **Fee Burning:** Fees are burned to reduce the total supply, creating deflationary pressure. - **Staking Rewards Offset Fees:** Users can earn staking rewards that may exceed the cost of transaction fees. - **Sponsored Transactions:** Developers can cover transaction fees on behalf of users, allowing for feeless user experiences. ## 11. How will this affect current token holders? For current token holders: - **Balances Maintained:** All balances will be migrated to the new network without loss. - **Same Private Keys:** Users can access their tokens using their existing private keys in the new IOTA Wallet. - **[Staking Opportunities](./tokenomics/validators-staking.mdx):** Token holders can participate in staking or delegation to earn rewards. ## 12. Firefly Isn't Working **Firefly for IOTA is deprecated** and no longer supports the new IOTA Mainnet network. You should switch to the [new IOTA Wallet](https://chrome.google.com/webstore/detail/iota-wallet/lfhohhmmcplfddhojblhpbblpbcoecha). - You can import your **mnemonic** or connect your **Ledger device**. - If the in-app updater is broken (on Windows), [download the latest version manually from Firefly](https://firefly.iota.org/). ## 13. How to Migrate from Firefly/Bloom? Firefly IOTA is no longer compatible with the new IOTA Mainnet. Please migrate to the new [IOTA Wallet](https://chrome.google.com/webstore/detail/iota-wallet/lfhohhmmcplfddhojblhpbblpbcoecha). ### Using a Mnemonic: 1. Go to the new wallet. 2. Create a new profile by importing your mnemonic. 3. See: [Getting Started with the IOTA Wallet](../users/iota-wallet/getting-started.mdx) ### Using a Ledger Device: :::info Supported Ledger Devices | Device | Minimum IOTA App Version | Notes | |--------------------|--------------------------|-------| | Ledger Nano S | 0.9.2 | The app on the this device has to be [installed manually](../../users/iota-wallet/how-to/import/ledger.mdx?install-method=manual) because it is deprecated. | | Ledger Nano S Plus | 0.9.3 | | | Ledger Nano X | 0.9.3 | | | Ledger Flex | 1.0.0 | | | Ledger Stax | 1.0.0 | | ::: 1. Ensure your IOTA Ledger App is up to date 2. Install via Ledger Live. 3. See: [Use IOTA Wallet with a Ledger Device](../users/iota-wallet/how-to/import/ledger.mdx) If you're using a **Ledger Nano S**, follow this [specific guide](../users/iota-wallet/how-to/import/ledger.mdx). :::info After importing your mnemonic or connecting your Ledger, run the **Balance Finder**. This tool will help locate all your addresses. You may need to press "search" multiple times, especially if your funds are widely distributed. ::: :::tip Tip: It's easier to use the Balance Finder from the expanded wallet view. ::: ## 14. I Have Missing Balances. Where's My Money? 1. Ensure you're using the **correct mnemonic, seed, or Ledger**. 2. Use the **Balance Finder** to search for all your addresses: - [How to use Balance Finder](../users/iota-wallet/getting-started.mdx) 3. After finding your addresses, go to the [IOTA Wallet Dashboard](../users/iota-wallet-dashboard/getting-started.mdx) and check: - **Migration Tab**: For unmigrated Stardust balances [Migrate Stardust Assets](../users/iota-wallet-dashboard/how-to/migration.mdx) - **Vesting Tab**: For airdropped or locked funds from the October 2024 upgrade [Manage Vesting and Time-Locked Assets](../users/iota-wallet-dashboard/how-to/vesting.mdx) ## 15. I'm Sure My Funds Are in a Specific Address But They’re Not Showing 1. Connect that address to the [Wallet Dashboard](../users/iota-wallet-dashboard/getting-started.mdx). 2. Navigate to the **Migration** tab and copy your legacy address. 3. Paste it into the [Archived Explorer](https://archive.explorer.iota.org) to check past balances. If you don’t see your funds there, they are likely in a **different address**. Run the **Balance Finder** again. ## 16. I Can't Connect My New Accounts to the Wallet Dashboard This is a known issue. Please follow these steps: 1. Go to `IOTA Wallet > Apps Tabs > Active Connections > Wallet Dashboard`. 2. **Disconnect all** accounts. 3. Reconnect them again from the Wallet Dashboard. ## 17. I Lost My Mnemonic. Can I Still Migrate? Yes—if you still have your **Stronghold file** and its **password**, you can extract the seed: 1. Use **Firefly v2.1.0+** to extract the seed. - [Restore From Seed or Stronghold](../users/iota-wallet/how-to/import/seed.mdx) 2. Import the extracted mnemonic into the new wallet: - [Getting Started with the IOTA Wallet](../users/iota-wallet/getting-started.mdx) :::note Restoring from seed is not an industry standard and may only work with IOTA Foundation-supported wallets. Once restored, transfer your funds to a wallet with a **known mnemonic**. ::: ## 18. Importing a Stronghold Crashes Firefly If you still have a Firefly profile: - Follow this guide to export the seed: [Back up a Seed from a Firefly Profile](../users/iota-wallet/how-to/import/seed.mdx) If you **don’t** have the profile: 1. Download [Firefly Shimmer](https://firefly.iota.org/). 2. Create a Shimmer profile using your **mnemonic**. 3. Log out and export the seed: [Guide to Exporting Seed](../users/iota-wallet/how-to/import/seed.mdx) ## 19. What Does It Mean If My Account is Marked as "Legacy"? This means your addresses originate from the **"Chrysalis rotating address era"**. These addresses are considered outdated and may not be recognized by newer wallets. :::info **We recommend** moving your funds out of legacy addresses to ensure compatibility and accessibility. ::: ## 20. Will there be any migration steps for users? - **Seamless Transition:** The [migration process](../developer/stardust/stardust-migration.mdx) is designed to be automatic; However, more complex asset structures such as NFTs, Aliases or time-locked assets need to be migrated via the Start Migration button on the IOTA Wallet Dashboard. - **New Wallet Access:** Users will need to use the new [IOTA Wallet](../users/iota-wallet/getting-started.mdx) and can import their existing mnemonics or private keys. :::tip Migrate Stardust Assets Here is a step by step process on how to [Migrate Stardust Assets](../users/iota-wallet-dashboard/how-to/migration.mdx). ::: ## 21. Will transaction fees impact the feeless nature of IOTA? Yes, but: - **Minimal Impact:** Fees are very low and designed as a congestion control mechanism. - **Net Gain for Users:** Staking rewards can offset transaction fees, potentially resulting in more tokens than before. - **Sponsored Transactions:** Developers can sponsor fees, allowing users to transact without holding IOTA tokens. ## 22. How will the governance vote work? The governance vote allows IOTA token holders to decide on the proposed upgrade: - **Announcement Phase:** The proposal is announced, and the community is informed. - **Voting Open Phase (7 days):** Voters cast their ballots before counting begins. - **Counting Phase (7 days):** Votes accumulate over time; each IOTA token accumulates voting power at a rate of 0.01 votes per milestone. - **Quorum Requirement:** A minimum of 5% of the circulating supply must participate for the vote to be valid. - **Outcome Determination:** The option with the majority of votes prevails. ## 23. What happens if the proposal is accepted? If accepted: - **Mainnet Upgrade:** The IOTA network will transition to the new IOTA Rebased protocol after thorough testing and audits. - **Network Transition:** A final snapshot of the current network will migrate balances to the new network on a 1:1 basis. - **IOTA EVM Chain Upgrade:** The IOTA EVM Layer 2 chain will be temporarily paused and upgraded to integrate with the new ledger. - **Wallet Transition:** The IOTA Firefly wallet will be discontinued. Users can access their holdings with the new IOTA Wallet using the same private keys. - **Token Continuity:** No token migration is necessary; tokens will be available immediately after the launch. ## 24. What happens if the proposal is rejected? If rejected: - **Current Operations Continue:** The IOTA network will continue operating as it currently does. - **Future Decisions:** The IOTA Foundation will decide on future development paths and how to proceed with network improvements. ## 25. What is the IOTA Rebased proposal? The IOTA Rebased proposal is a significant upgrade to the IOTA protocol that aims to enhance the network's capabilities by: - **Transitioning to an Object-Based Architecture:** Moving away from the current UTXO model to an object-based ledger. - **Introducing the Move Virtual Machine (MoveVM):** Implementing MoveVM to enable Layer 1 (L1) smart contract capabilities. - **Establishing Full Decentralization:** Adopting a delegated proof-of-stake (dPoS) system with validators and stakers to secure the network. - **Updating Tokenomics:** Introducing staking rewards, transaction fees, and a fee-burning mechanism to create a dynamic supply. ## 26. What is the future roadmap for IOTA? The future roadmap includes: - **Protocol Refinements:** Enhancements like resilient consensus mechanisms and fairer gas pricing. - **Multi-VM Ledger:** Transitioning to support multiple virtual machines, including EVM, on Layer 1. - **Tooling and Products:** Developing new wallets, SDKs, CLI tools, and identity solutions. - **Mainnet Launch Timeline:** A potential launch in early 2025 after thorough testing and audits. ## 27. Why is IOTA making this change now? The change addresses: - **Market Demands:** There's a clear need for Layer 1 programmability and smart contracts to meet modern application requirements. - **Technological Evolution:** The new architecture allows for faster, more secure, and scalable solutions. - **Avoiding Delays:** Continuing with the current roadmap would require additional years of research and development with uncertain outcomes. ## 28. Where can I find more information and stay updated? Stay informed by: - **Visiting Official Resources:** Visit the official [IOTA Foundation Blog](https://blog.iota.org/) for regular updated. - **Joining Community Channels:** Engage with the IOTA community on the [IOTA Community Discord](https://discord.iota.org/), the [IOTA Builders Discord](https://discord.gg/iota-builders), [YouTube](https://www.youtube.com/c/iotafoundation), [X](https://www.twitter.com/iota/) and [GitHub](https://www.github.com/iotaledger/). - **Following Announcements:** Keep an eye on official blog posts and updates from the IOTA Foundation. --- ## About IOTA The IOTA ecosystem enables programmability in both [Layer 1](#layer-1) and [Layer 2](#layer-2) using [Move](#move) and [EVM/Solidity](#evm) smart contracts respectively. ## Layer 1 ### Move Move is a powerful, secure programming language designed specifically for digital asset management and smart contracts. Its unique features make it an ideal choice for developers working in the blockchain space. Here are the key features of Move: #### Object-Centric Design Move is fundamentally object-centric, allowing developers to intuitively model complex data structures and interactions. In Move, you can define objects representing assets, users, contracts, and more, facilitating a natural and straightforward way to manage state and behavior. #### Performance Move is based on the object model, not a shared global state. This allows transactions to be executed in parallel, which translates into a network with high throughput, less congestion, and therefore lower [gas](#gas-on-iota) fees. #### Security Move prioritizes safety and efficiency, with Rust’s ownership model inspiring Move’s approach to memory management and resource control. The compiler enforces strict rules to prevent common programming errors, ensuring that assets remain secure within user accounts and cannot be accessed without the correct keys. While the compiler catches many potential issues before deployment, developers should still be mindful of logical errors, arithmetic overflows, and other runtime concerns when implementing smart contracts. :::warning While the Move compiler catches many development mistakes, smart contracts can still have unintended edge cases and issues within their written logic. For this reason, it's still highly recommended to have smart contracts audited and double-checked, even when written in Move. ::: ### Networks #### IOTA Mainnet The [IOTA Mainnet](https://wiki.iota.org/build/networks-endpoints/#iota) is the L1 "production" network of IOTA. The IOTA Mainnet's tokens have a real-world value, so we recommend that you use the IOTA Testnet or Devnet to develop your application. #### IOTA Testnet The IOTA Testnet serves as a staging network and quality assurance. You can use this network to test your dApps and verify that planned changes do not adversely impact performance before deploying them to production. #### IOTA Devnet The IOTA Devnet is used to develop new features. You can use this network to code with the latest planned features of IOTA. ## Layer 2 ### EVM [EVM](https://ethereum.org/en/developers/docs/evm/) stands for "Ethereum Virtual Machine" and is currently the tried and tested virtual machine running most smart contract networks. [Solidity](https://soliditylang.org/) is the programming language of choice for the EVM. It was created for this specific purpose. The main benefit of using EVM/Solidity is its sheer amount of resources from years of development. The [IOTA Smart Contracts](https://wiki.iota.org/isc/introduction/) implementation is fully compatible with these resources, allowing you to leverage all existing EVM developer tools for developing on the IOTA EVM. Any contracts you've previously written can be deployed on IOTA Smart Contracts without modification. Keep in mind that while EVM has become a standard for smart contract execution on L2s, it is not inherently designed for the unique features and capabilities of L1s like Move smart contracts. Move, with its focus on asset safety, resource management, and formal verification, offers a fundamentally different approach at the L1 level. ### Networks #### IOTA EVM IOTA EVM is the distinct Layer 2 EVM running on top of the [IOTA Mainnet](./tokenomics/iota-token.mdx). #### IOTA EVM Testnet IOTA EVM Testnet is a distinct Layer 2 EVM on top of the IOTA testnet. :::info This network is subject to occasional resets (no data retention) which are usually announced with a one-week grace period. ::: ## IOTA Tokens The [IOTA token](./tokenomics/iota-token.mdx) is the main token in the IOTA ecosystem. One IOTA can be divided into smaller units called NANOs, with one IOTA being equivalent to one billion NANOs. ### Gas on IOTA Transactions on the IOTA network require [gas](./tokenomics/gas-pricing.mdx) fees, which are paid using IOTA or NANOs. ## Consensus on IOTA IOTA uses a [delegated proof-of-stake (DPoS)](./tokenomics/proof-of-stake.mdx) consensus mechanism to validate on-chain transaction blocks. [Validators](iota-architecture/validator-committee.mdx) must secure a certain amount of IOTA tokens to participate in the network, where they actively run the [Starfish](./iota-architecture/consensus.mdx) consensus protocol to finalize transactions. This approach incentivizes honest behavior, enhances security, and ensures an efficient and scalable blockchain while avoiding the high energy demands of Proof-of-Work (PoW) systems, which rely on computationally intensive mining. --- ## Consensus on IOTA import ThemedImage from '@theme/ThemedImage'; The primary goal of consensus in distributed systems is to establish a consistent order of transactions and ensure their availability. In IOTA, consensus is achieved through a combination of Delegated Proof-of-Stake (dPoS) and a Byzantine Fault Tolerant (BFT) protocol. All IOTA networks — Devnet, Testnet, and Mainnet — run the **Starfish** BFT consensus protocol. IOTA's consensus mechanism ensures: - **Low latency**: Transactions are confirmed quickly due to efficient leader election and consensus mechanisms. - **High throughput**: The protocol can process a large number of transactions per second, ensuring scalability. - **Fast finality**: Transactions reach finality in a short time, reducing the risk of rollbacks. - **Energy efficiency**: Unlike Proof-of-Work (PoW), a BFT consensus mechanism requires minimal computational resources. - **Security & decentralization**: The protocol resists common attacks by relying on an honest majority of validators while maintaining a decentralized structure. ## Delegated Proof-of-Stake (dPoS) in IOTA IOTA employs Delegated Proof-of-Stake (dPoS) as the overarching consensus mechanism. In this model: - Token holders delegate their voting power to validators. - Validators participate in block production and execute the Starfish protocol to finalize transactions. - Staking rewards serve as the main incentive for validators to behave honestly and secure the network. - This structure ensures security and decentralization while maintaining scalability. ## Consensus Committee Validators that participate in the consensus protocol collectively form the **Consensus Committee**. This committee is responsible for executing the consensus mechanism and finalizing transactions. ### Key Aspects of the Consensus Committee - **Validator Set**: The consensus committee consists of validators, which are selected based on delegated stake. - **Fixed Over an Epoch**: The validator set remains unchanged during an epoch to ensure stability. - **Roles of Validators**: - Accept transactions and execute the consensus protocol. - Maintain a consistently ordered ledger state. - Prevent double-spending and conflicts. For more details on validator staking, refer to the [Validators Staking](../tokenomics/validators-staking.mdx) page. To understand epoch transitions, see the [Epochs](./epochs.mdx) documentation. ## The Starfish Protocol **Starfish** is a _BFT_ consensus protocol optimized for **low latency** and **high throughput** using an uncertified _DAG_ structure. It is designed for robust operation under disrupted connections, uneven network latency, and adversarial validator behavior. ### Key Features of Starfish - **Parallel Block Proposals** Multiple validators can propose blocks simultaneously, maximizing network bandwidth and improving censorship resistance — a core advantage of DAG-based protocols. - **Three-Round Finality Rule** Blocks reach finality in only three rounds of communication, matching the efficiency of pBFT and achieving the theoretical minimum for BFT consensus. - **Optimized Voting** Validators vote and certify blocks in parallel rather than sequentially behind a single leader, significantly reducing median and tail latencies. - **Decoupled Block Headers and Transaction Payloads** Block header metadata is separated from transaction data, enabling efficient and flexible dissemination of headers. - **Cordial Dissemination of Block Headers** Even if multiple network routes are unavailable, a single functioning connection is sufficient to propagate block headers — without retries or request–response cycles. This ensures deterministic and predictable commit performance. - **Push-based Header Dissemination** Block headers are propagated between validators by push rather than on-demand pull. Validators at the edge of the network — with long round-trip times or a single reliable peer — achieve stable p95 commit latency, because no chain of request–response round-trips is needed to assemble a block's history. - **Linear Communication Cost for Transaction Data** Transactions are encoded into shards using Reed–Solomon erasure coding. Nodes can reconstruct missing data from partial shards, removing redundant broadcasts and enabling scalable throughput. - **Fault Tolerance** The protocol tolerates up to one-third of validators by stake being offline, crashed, or actively misbehaving, without substantially impacting commit latency. 🔗 **Reference:** [Starfish Paper](https://eprint.iacr.org/2025/567) --- ## Epochs and Reconfiguration ## Epoch In IOTA, an epoch is a fixed period (typically around 24 hours) during which the [validator set](./validator-committee.mdx) and their stakes remain constant. This stable period ensures that [transactions](../../developer/iota-101/transactions/transactions.mdx) are processed smoothly without unexpected validator changes. ## Epoch Numbering & Transaction Data Epochs are sequentially numbered, and each transaction on the IOTA network includes an epoch identifier. While regular users generally do not need to worry about epochs, they are relevant when dealing with expiring transactions, which must be completed before a specific epoch ends. ## Consensus & Checkpoints During each epoch, the Starfish consensus protocol operates to finalize transactions. Validators reach agreement by collecting transaction effect certificates, ensuring a consistent transaction order. A key part of this process is the checkpoint, which is a snapshot of finalized transactions at the end of an epoch. The checkpoint includes: - A set of finalized transactions - Validator agreement data - State updates required for the next epoch ## Reconfiguration At the end of each epoch, a reconfiguration process occurs to prepare the network for the next epoch. This involves the following. ### 1. Finalizing Transactions & Checkpoints - Validators finalize the order of transactions and generate a checkpoint, ensuring a synchronized network state. - This step guarantees that an honest majority of validators share the same transaction history, reinforcing consistency and security. ### 2. Distribution of Gas Rewards - Computation gas fees are distributed to the validator staking reward pool. - Stakers can withdraw their rewards after the epoch ends. Refer to the [Staking and Rewards](./staking-rewards.mdx) page for more details. ### 3. Validator Set Updates - Any pending staking and unstaking requests are processed. - The validator set is updated—new validators may be added, and inactive ones may be removed. - Since staking influences validator selection, it is only processed at epoch transitions. ### 4. Protocol Upgrades (Optional) :::info In Byzantine Fault Tolerant (BFT) `f` represents the number of faulty validators. `2f+1` represents the minimum number of validators needed to agree on a transaction to ensure integrity and finality, even if up to `f` validators are faulty. For example, if `f = 1`, this means 3 validators must confirm a transaction (a supermajority) to guarantee its integrity, ensuring that even if one validator is faulty, the correct decision still stands. ::: - If 2f+1 validators (a Byzantine Fault Tolerant supermajority) agree, the network may upgrade to a new protocol version. - These upgrades may include: - Security patches - New protocol features - Updates to the IOTA Move framework Refer to the [Protocol Upgrades](./protocol-upgrades.mdx) page for details. --- ## IOTA Architecture import ThemedImage from '@theme/ThemedImage'; IOTA shares some similarities with traditional blockchains but is unique in many ways. Use the topics in this section to understand the features that define the IOTA network. ## Understand IOTA Security Learn about the mechanisms available to secure on-chain assets, and the assurances IOTA provides regarding asset security. "Understand IOTA Security" explores the overall IOTA security architecture, to ensure the asset types you design leverage IOTA to provide a secure experience for asset holders. Go to [Understand IOTA Security](iota-security.mdx). ## Life of a Transaction "Life of a Transaction" details the transitions that all transactions on IOTA go through from creation to finality. This topic also explores some features of the blockchain (like epochs and checkpoints) that play a role in the life of a transaction. Go to [Life of a Transaction](transaction-lifecycle.mdx). ## Consensus Every transaction on IOTA that touches a shared object must go through a consensus process. This is to ensure that all nodes in the network agree on which transactions should be allowed to modify the ledger state. IOTA uses the [Starfish](https://eprint.iacr.org/2025/567) consensus algorithm, the successor of [Mysticeti](https://arxiv.org/pdf/2310.14821). Go to [Consensus](consensus.mdx). ## Sequencing Once consensus provides the set of transactions to be included in the ledger, they must be sequenced to determine their exact execution order. IOTA uses a unique sequencing algorithm aimed at maximizing throughput by leveraging concurrent processing capabilities. Go to [Sequencing](sequencing.mdx). ## Protocol Upgrades The IOTA protocol, framework, and execution engine are frequently extended to include new functionality and bug fixes. This functionality is added in the form of new code which is released to validator operators as part of our regular software releases. The IOTA protocol, however, requires a supermajority of validators to agree on those protocol upgrades. Go to [Protocol Upgrades](protocol-upgrades.mdx). ## IOTA Architecture Diagram The following diagram describes the architectural structure for IOTA's solution. The core components are: - [Execution Layer](../../developer/references/execution-architecture/execution-layer.mdx) - [IOTA Node](../../operator/full-node/overview.mdx) - [IOTA RPC](../../developer/references/iota-api.mdx) - [IOTA CLI](../../developer/references/cli.mdx) --- ## Security ## Access to Assets IOTA uses two key mechanisms to secure access to assets. First, the asset owner must cryptographically prove knowledge of their private key tied to their account address to use or transfer an asset. Thus, account keys must be securely stored and used. Second, access to assets, which are represented as Move objects in a smart contract, follows the object ownership model of the Move language. The Move VM enforces ownership rules and ensures that no bytecode execution can violate them. The only potential risks stem from logic errors within smart contracts. Once a transaction reaches consensus and is committed to the ledger, any modified or created assets are persistently updated and available for further use. :::tip Validator Selection The set of validators changes periodically and is [determined by the amount of locked and delegated IOTAs held](../tokenomics/validators-staking.mdx). ::: ### Delegated PoS Consensus Mechanism IOTA employs a delegated Proof-of-Stake (dPoS) mechanism to select validators (nodes that help secure and operate the network) for each epoch. Users can lock and delegate their IOTA tokens to validators, granting them voting power. Validators are chosen based on the number of delegated tokens, and any node with sufficient support can become a validator. ## Validators and Consensus Protocol The IOTA [consensus protocol](./consensus.mdx) is run by a set of independent [validators](../tokenomics/validators-staking.mdx). All validators follow the same protocol and participate in transaction validation, using their delegated voting power to reach consensus. The consensus protocol produces a consistently ordered stream of transactions, ensuring system reliability and security. It is designed to be Byzantine fault tolerant (BFT), meaning transactions will still be processed even if up to one-third of validators attempt to disrupt execution or violate protocol guarantees. Additionally, all transactions in IOTA are publicly available and auditable to verify that asset modifications are correctly executed. ### Rewards for Validators and Stakers Validators receive incentives through a fixed inflation of 767,000 IOTA tokens per epoch. These tokens are distributed to validators and their delegators based on specific rules, such as the validator's commission rate and total stake. Transaction fees are burned and do not contribute to validator rewards. Staked tokens remain secure and cannot be seized by validators or other participants. For more details, refer to the [staking and rewards](./staking-rewards.mdx) documentation. ## Addresses and Keys To access and manage assets on IOTA, users must hold the corresponding private key. This key must be kept secret, as even a majority of malicious validators cannot access assets without it. Each private key corresponds to a public address on the IOTA network. Users can generate multiple addresses, and sending an asset to an address automatically creates it. Since transactions are irreversible once they reach finality, users should always verify recipient addresses before sending assets. ## Asset Types and Logic The type and logic of any asset on the IOTA network are defined within smart contracts. While some core contracts are embedded in the protocol, most smart contracts are developed externally. IOTA smart contracts are immutable, allowing for third-party audits and preventing post-deployment modifications. The Move language enforces strong security guarantees by integrating asset security and smart contract verification at its core. Additionally, Move's capability objects provide a robust mechanism for defining access control and permissioned asset usage. ### Shared Assets Move allows for shared assets that, while publicly accessible, can have restricted usage enforced by the defining smart contract. Developers can specify which addresses have permission to interact with shared assets. ## Transaction Finality ### Certification and Finalization When a transaction is submitted in IOTA, validators must collectively agree on its validity. Once agreement is reached, they issue a cryptographic _certificate_ confirming its correctness. Even if some validators act maliciously, the transaction can still be finalized by a supermajority of honest validators. This ensures that transactions cannot be invalidated or blocked by a small group of malicious actors. ### Gas and Transaction Execution Every transaction incurs a gas fee for computational processing. A transaction either executes successfully or fails. Failures can result from smart contract errors or insufficient gas. If a transaction succeeds, its effects are permanently recorded on the IOTA network. If it fails, no changes occur, but some gas fees are still deducted to mitigate spam attacks. For more details, see the [gas and gas fees](../tokenomics/gas-pricing.mdx) documentation. ### Submitting Transactions Users can submit transactions directly or use third-party services. These services cannot generate transactions on behalf of users since they do not have access to private keys. However, they can confirm transaction finalization by collecting validator signatures. A transaction is considered final once it has accumulated sufficient validator signatures, ensuring its irreversibility. ## Auditing and Privacy ### Reading Assets and Transaction History IOTA full nodes provide access to asset balances and transaction histories. Validators generate cryptographic proofs verifying every transaction that contributed to an asset’s current state. Users can request and verify these proofs to ensure all transactions were correctly executed and consensus was followed. ### Public Auditability All transactions and assets on IOTA are publicly viewable, ensuring auditability. However, users can maintain pseudonymity by utilizing multiple addresses. Third-party custodial services can further enhance privacy by managing assets on behalf of users. Additionally, privacy-preserving smart contracts can be developed to add extra confidentiality layers. --- ## Protocol Upgrades The IOTA protocol, framework, and execution engine are frequently updated to introduce new features and bug fixes. These updates are released as part of regular software updates for validator operators. However, since all validators must agree on the results of each transaction execution, introducing changes to transaction execution presents a challenge. - How to ensure that all validators upgrade their software in a coordinated manner? - How to ensure that the transaction history remains consistent and replayable despite protocol changes? IOTA addresses these challenges through a structured **protocol upgrade** process. ## Protocol Upgrade Process ### Protocol Versioning Validators run the `iota-node` software, which supports multiple protocol versions, including future versions. The protocol version is determined by the `ProtocolConfig` struct. Validators that do not support the current protocol version cannot participate in consensus. The protocol version to be executed in the next epoch is recorded on-chain in a special end-of-epoch transaction. This ensures that all validators switch to the new protocol version at the same time. ### Upgrade Steps 1. **Implementation**: IOTA developers introduce a new protocol version by updating the `ProtocolConfig` struct with properties and values, which may include feature flags to control specific functionalities within the new version. 2. **Software Release**: A new `iota-node` binary is released, and validators update their software. After restarting, validators continue to run the previous protocol version until the upgrade is activated. 3. **Upgrade Signaling**: Upgraded validators signal their readiness to switch to the new protocol version. This is done through consensus among the validator committee. 4. **Consensus and Activation**: If enough validators agree to switch, the new protocol version is recorded on-chain at the end of the current epoch. The next epoch then executes using the upgraded protocol version. Full nodes follow a similar process but do not participate in voting. Instead, they synchronize with validators to ensure they execute transactions using the correct protocol version. ## IOTA Move Framework Upgrades The **IOTA Move Framework** is a collection of system smart contracts built into the validator binary. These contracts provide essential functionalities, such as native functions for smart contracts. The upgrade process for the IOTA Move Framework follows a similar structure to protocol upgrades: 1. **Framework Update in Software**: IOTA developers introduce changes to the IOTA Move Framework within the validator binary. 2. **Software Release and Validator Updates**: A new iota-node binary containing the updated framework is released. Validators update their software but continue using the existing framework until the upgrade is activated. 3. **Upgrade Signaling**: If a validator detects that its built-in framework differs from the framework stored on-chain (object 0x2), it signals its intent to upgrade. 4. **Consensus and Activation**: Once enough validators agree, the new framework version is written to object 0x2 at the end of the epoch. The next epoch then executes using the updated framework. --- ## Sequencing on IOTA # Sequencing Sequencing is the post-consensus phase in which transactions agreed upon by the IOTA [consensus protocol](./consensus.mdx) are processed and scheduled for execution. Due to the nature of [shared objects](../../developer/iota-101/objects/object-ownership/shared.mdx), conflicting transactions writing to the same shared objects must be executed sequentially. If not carefully managed, scheduling a large number of such conflicting transactions can lead to congestion during execution. The primary goal of sequencing is to schedule as many transactions as possible while avoiding an unmanageable load on the execution layer. The sequencing phase is responsible for two main tasks: - **Ordering**: Establishing the causal order of transactions committed by the IOTA [consensus protocol](./consensus.mdx). - **Congestion prevention**: Deferring the execution of transactions that could otherwise overwhelm the execution layer. The IOTA sequencing algorithm addresses both of these tasks simultaneously. ## Sequencing Algorithm In IOTA, transactions are initially ordered based on their gas prices. Each transaction is then evaluated individually using the placement algorithm described below to determine its position in the execution trace. During this evaluation, every transaction is subject to a binary decision: **Schedule** or **Defer**. - **Deferred** transactions are carried over to the transaction set of the next consensus commit. If a transaction is deferred a specific number of times (currently 10), is it eventually **cancelled**. - **Scheduled** transactions are forwarded to the execution phase in the order determined by the placement algorithm. :::info Best-effort sequencing In the IOTA sequencing algorithm, a transaction is deferred only if there is no way to schedule it without exceeding the load threshold on any individual execution worker. ::: ## Placement algorithm: Causal ordering of transactions The IOTA sequencing algorithm orders transactions with a strong emphasis on execution efficiency. When a transaction is evaluated, the algorithm searches for a suitable position in the execution trace where it can be placed without causing conflicts. This allows for parallel execution of transactions that operate on disjoint sets of shared objects. To achieve this, the algorithm maintains an allocation map that tracks access to shared objects. This ensures that no shared object is written to by more than one transaction at the same time, preserving execution safety. Once all transactions have been evaluated, the allocation map implicitly defines the causal ordering of the scheduled transactions. The sequencing algorithm guarantees that the longest sequential execution trace remains within a predefined load threshold. :::info Fairness in sequencing In IOTA, transactions included in the same consensus commit that write to an identical set of shared objects are guaranteed to be executed in descending order of their gas prices. ::: ### Example In the example below, we consider three transactions: - `Tx1` touches only object `a`, - `Tx3` touches only object `b`, - `Tx2` touches both objects `a` and `b`. `Tx1` is willing to pay the highest gas price, while `Tx3` offers the lowest. Additionally, `Tx2` is _estimated_ to have the longest execution time, while `Tx3` has the shortest. In the figure below, the length of the transactions depict their execution time. ![Sequencing example, final sequencing](/img/about-iota/iota-architecture/sequencing1.svg) A naive sequencing of these transactions based solely on gas price would result in a serial execution, since `Tx2` would have to wait for `Tx1` to complete (due to their shared access to object `a`), and `Tx3` would need to wait for `Tx2` (due to shared access to `b`). As a result, all transactions would be executed one after another. Instead, IOTA's sequencing algorithm carefully places `Tx3` before `Tx2` in the causal order. This enables simultaneous execution of `Tx1` and `Tx3` (which access disjoint objects), provided that there are sufficient parallel resources. The case is illustrated in the following image. ![Sequencing example, final sequencing](/img/about-iota/iota-architecture/sequencing2.svg) ## Gas Price Feedback for Cancelled Transactions When a transaction is cancelled due to shared object congestion, IOTA provides a **suggested gas price** in the execution status of that cancelled transaction. This suggested gas price informs the sender about the minimum gas price they should have paid for their transaction to have been successfully scheduled in the _same_ consensus commit. Other networks such as Sui only report which shared objects were congested, but not what gas price would have been enough for successful execution. Users on those networks have to rely on dry-run simulations to figure out a sufficient gas price. The IOTA protocol instead provides gas price feedback based on the actual scheduling decisions in the latest commits, which helps the sender estimate a sufficient gas price for a retry. ### How the suggested gas price is calculated - The gas price feedback algorithm simulates the allocation of the cancelled transaction at the latest possible execution start time within the commit's capacity, so that only the last scheduled transactions on each congested object overlap with it. - The clearing gas price for each object is the maximum gas price across those last scheduled transactions that overlap with the simulated allocation of the cancelled transaction. - The suggested gas price is then calculated as the maximum clearing gas price across all input objects of the cancelled transaction plus one, ensuring that it would outbid competing transactions and get scheduled. - The suggested gas price value is capped at the protocol's maximum gas price. ### Using the suggested gas price The sender can then retry the cancelled transaction with a gas price equal to or greater than the suggested value. :::note Suggested gas price is an estimate If the same congestion pattern repeats in a future commit, paying the suggested gas price guarantees scheduling. In practice, congestion changes between commits, so the suggested value should be considered as a good starting estimate but not as a hard guarantee to be scheduled. For better price estimate, please refer to [gas price prediction during dry run](../tokenomics/gas-pricing.mdx#gas-price-prediction). ::: --- ## Staking and Rewards IOTA uses a [Delegated Proof-of-Stake (DPoS)](../tokenomics/proof-of-stake.mdx) system, where [validators](../tokenomics/validators-staking.mdx) get their voting power from IOTA token holders who delegate their stakes to them. When rewards are distributed at the end of each [epoch](epochs.mdx), validators receive their [rewards](#rewards-distribution) based on their [performance](#performance) and [commission rate](#commission-rate). The rewards automatically increase as validators' staking pools receive new delegated stakes. ## Staking on IOTA vs. Other Blockchains The IOTA staking mechanism has some unique features compared to other blockchains. ### Self-custodial Staking Stakers keep their staked IOTA tokens in their own account. ### Auto-compounding Rewards Rewards automatically reinvest due to a liquidity-pool-inspired design. ### Staking Timing When a user stakes with a validator, their stake counts towards the validator's voting power starting from the next epoch. Similarly, when a user withdraws their stake, it stops counting from the next epoch. ## Validator Staking Pool Requirements There are minimum staking requirements a validator must satisfy to become active and to stay in the active validator set. More precisely: - A validator candidate must accrue at least 2M IOTA of stake before they can request to join the validator set. - If an active validator’s stake falls below 1.5M IOTA, the validator has seven epochs of grace period to gain back the stake before being removed from the validator set. - If an active validator’s stake falls below 1M IOTA, the validator is removed from the validator set at the end of the current epoch boundary. IOTA uses 24-hour epochs. ## Rewards Distribution At the end of each [epoch](epochs.mdx), newly minted IOTA tokens are distributed as rewards among validators and stakers. Within each [validator staking](../tokenomics/validators-staking.mdx) pool, stakers receive rewards proportionally through the appreciation of the pool's exchange rate. Validators also earn additional rewards, represented as StakedIOTA objects, which they receive at the end of each epoch in proportion to the commissions generated by their staking pool. Each epoch's rewards are funded by newly minted IOTA tokens, totaling 767k IOTA per epoch. This amount is distributed across staking pools based on their voting power and the specified tallying rule. The amount of rewards a validator gets depends on. :::tip Validator Selection Refer to the [Proof-of-Stake](../tokenomics/proof-of-stake.mdx) page to learn how validators are selected for transaction processing and the underlying economic model. ::: ### Performance If a validator underperforms, other validators can report them, causing the reported validator to lose all their rewards for that epoch. ### Commission Rate This is the percentage a validator takes from their stakers' rewards. For example, if a validator's commission rate is 10%, they take 10% of the rewards each epoch as new stake objects. ### Rewards Withdrawal Validators receive rewards as regular stake objects, so they withdraw their staking rewards the same way as stakers. Validators can call the [`0x3::iota_system::request_withdraw_stake`](https://github.com/iotaledger/iota/blob/develop/crates/iota-framework/packages/iota-system/sources/iota_system.move#L260) function to withdraw their stake and receive their rewards. --- ## Transaction Life Cycle import ThemedImage from '@theme/ThemedImage'; # Transaction Life Cycle ## High-level Overview ## Understanding the Transaction Lifecycle in IOTA The IOTA transaction lifecycle outlines the journey of a transaction from its creation by a user to its final settlement and recording on the ledger. This process involves client applications, full nodes, and validators, ensuring secure and consistent state transitions across the network. ### 1. Make Transaction A user or smart contract initiates a transaction through a wallet or application. This transaction can affect objects owned exclusively by the user (owned objects) or objects that multiple users can interact with ([shared objects](../../developer/iota-101/objects/object-ownership/shared.mdx)). The transaction typically includes: - Sender and recipient addresses - Value or assets to transfer - Timestamp and nonce - Digital signature (using the user's private key) The wallet application signs the transaction with the user's private key, ensuring its authenticity and integrity. ### 2. Process Transaction Once created and signed, the transaction is submitted to a full node. The full node performs an initial validation of the transaction structure and checks for sufficient account balance. It then distributes the transaction to validators in the network. Validators independently verify the transaction's validity. If deemed valid, they sign it and return the signed transaction to the full node. ### 3. Assemble Certificate After collecting signed responses from a supermajority of validators, the client assembles these responses into a transaction _certificate_. This step is crucial as it ensures that the transaction has been pre-approved by a sufficient number of validators before proceeding to consensus. Unlike traditional consensus-based blockchains, the client or gateway is responsible for propagating signatures and aggregating certificates, reducing the burden on validators. The client sends the assembled _certificate_ back to all validators. Upon receipt, validators verify the certificate's integrity and acknowledge its receipt. They then forward the _certificate_ to the IOTA DAG-based consensus protocol. If the transaction involves only owned objects, IOTA can process and execute it immediately without waiting for global consensus, leveraging **fast path consensus**. ### 4. Sequence All certificates, regardless of whether they involve **owned** or **shared objects**, are forwarded to the IOTA DAG-based consensus protocol. This protocol eventually produces a total order of certificates. Validators then verify and execute transactions that involve shared objects, ensuring deterministic and consistent state transitions across all nodes. ### 5. Process Certificate Certified transactions are then sent to validators for execution. Validators verify the certificate signatures to ensure the transaction is valid and not attempting to double-spend. Depending on whether the transaction uses shared input objects, the validators will either: - Execute it immediately if no shared objects are involved. - Submit it to IOTA's consensus layer to order the transaction with others if shared objects are involved, and then execute it. This ensures that transactions involving shared objects are consistently ordered across validators, preventing conflicts. ### 6. Assemble Effect Certificate After the transaction has been executed, clients can gather responses from a supermajority of validators again. These responses are then assembled into an effect _certificate_. This certificate serves as proof that the transaction has been fully executed, providing evidence of settlement finality and a guarantee that the transaction will be recorded in a checkpoint. ### 7. Checkpoint Certificate IOTA periodically creates checkpoints during consensus commits. These checkpoints record the finalized transaction state, providing a stable point of reference. They are also used to drive the validator reconfiguration protocol, supporting epoch transitions and validator set changes. ## Epoch Transitions and Their Impact The IOTA network undergoes [epoch](./epochs.mdx) transitions, which can affect how transactions are handled. Near epoch boundaries, transactions might occasionally need to be resubmitted. Generally, full nodes handle resubmission, though some client applications may automate this process. As a best practice, it's advisable to avoid submitting time-sensitive transactions immediately before epoch transitions. ## Verifying Finality If your wallet app crashes during a transaction, it stores the signed transaction locally. Upon restarting, it will verify if the transaction was finalized. If finalized, no further steps are required. If not, the app will need to resubmit the transaction. The wallet app can query the full node with the getTransactionBlock method to check if the transaction is finalized. If the response contains transaction details, it is finalized. If the response is None, the transaction may need to be resubmitted. This ensures that the coffee shop's full node will eventually recognize the transaction once it's included in a checkpoint and update the coffee shop's balance. --- ## Validator Committee A set of independent validators participate on the IOTA network, each running its own instance of the IOTA software on a dedicated machine or virtual server. Each validator handles read and write requests sent by clients, verifying transactions and updating on-chain information. To learn how to set up and run an IOTA validator node, including how staking and rewards work, see [IOTA Validator Node Configuration](../../operator/validator-node/configuration.mdx). IOTA uses Delegated Proof-of-Stake (DPoS) to determine which validators operate the network and their voting power. Validators are incentivized to participate in good faith via staking rewards, which are slashed in case of misbehavior. ## Epochs Operation of the IOTA network is temporally partitioned into non-overlapping, approximate fixed-duration (~24-hour) epochs. During a particular epoch, the set of validators participating in the network and their voting power is fixed. At an epoch boundary, reconfiguration might occur and can change the set of validators participating in the network and their voting power. Conceptually, reconfiguration starts a new instance of the IOTA protocol with the previous epoch's final state as [genesis](../../operator/common/genesis.mdx) and the new set of validators as the operators. Besides validator set changes, tokenomics operations such as staking/un-staking, and distribution of staking rewards are also processed at epoch boundaries. ## Quorums A quorum is a set of validators whose combined voting power is greater than two-thirds (>2/3) of the total during a particular epoch. For example, in an IOTA instance operated by four validators that all have the same voting power, any group containing three validators is a quorum. The quorum size of >2/3 ensures Byzantine fault tolerance (BFT). A validator commits a transaction (durably store the transaction and update its internal state with the effects of the transaction) only if it is accompanied by cryptographic signatures from a quorum. IOTA calls the combination of the transaction and the quorum signatures on its bytes a _certificate_. The policy of committing only _certificates_ ensures Byzantine fault tolerance: if >2/3 of the validators faithfully follow the protocol, they are guaranteed to eventually agree on both the set of committed _certificates_ and their effects. ## Write requests A validator can handle two types of write requests: transactions and _certificates_. At a high level, a client: - Communicates a transaction to a quorum of validators to collect the signatures required to form a _certificate_. - Submits a _certificate_ to a validator to commit state changes on that validator. ### Transactions When a validator receives a transaction from a client, it first performs transaction validity checks (validity of the sender's signature). If the checks pass, the validator locks all owned-objects and signs the transaction bytes, then returns the signature to the client. The client repeats this process with multiple validators until it has collected signatures on its transaction from a quorum, thereby forming a _certificate_. The process of collecting validator signatures on a transaction into a _certificate_ and the process of submitting _certificates_ can be performed in parallel. The client can simultaneously multicast transactions/_certificates_ to an arbitrary number of validators. Alternatively, a client can outsource either or both of these tasks to a third-party service provider. This provider must be trusted for liveness (it can refuse to form a _certificate_), but not for safety (it cannot change the effects of the transaction, and does not need the user's secret key). ### Certificates After the client forms a _certificate_, it submits it to the validators, which perform _certificate_ validity checks. These checks ensure the signers are validators in the current epoch, and the signatures are cryptographically valid. If the checks pass, the validators execute the transaction inside the _certificate_. Execution of a transaction either succeeds and commits all of its effects or aborts and has no effect other than debiting the transaction's gas input. Some reasons a transaction might abort include an explicit abort instruction, a runtime error such as division by zero, or exceeding the maximum gas budget. Whether it succeeds or aborts, the validator durably stores the _certificate_ indexed by the hash of its inner transaction. If a client collects a quorum of signatures on the effects of a transaction, the transaction is final. This means the effects will persist on the shared database and be permanently recorded in a checkpoint within a few seconds. The epoch boundary serves as an upper bound, but in practice, the effects certificate can be used immediately to prove finality, access results, and trigger new transactions. Clients may share the certificate directly with others or use a third-party service to help propagate it. --- ## IOTA Bounty Program The IOTA Bounty Program connects the community with funded tasks that help improve the IOTA products and ecosystem. [Terms & Conditions](/iota-bounty-program-terms-and-conditions) apply. ## Current Active Programs Help us test and improve the new IOTA SDK supporting Rust, Go, Kotlin and Python. All the rules and details on how to participate can be found on the project board by clicking on this card. This program starts on February 16th for selected community members and will be open for everyone on the 2nd of March. --- ## IOTA Bounty Program Terms & Conditions These Terms and Conditions (“Terms”) govern your participation in the IOTA Bounty Program (“Campaign”) operated by the IOTA Foundation (“we”, “us”, or “our”). By participating in the Campaign you confirm that you have read, understood, and agreed to these Terms. **The Campaign is provided "as is" without any warranties of any kind, express or implied. We make no guarantees regarding availability, security, continuity, or outcomes of the Campaign. We disclaim all liability for any losses, delays, errors, or issues arising from your participation, including the non-receipt of rewards or technical disruptions. To the fullest extent permitted by law, our total liability is limited to the actual IOTA rewards distributed to you, if any. Participation is at your own risk, and no specific outcome or reward is guaranteed.** ## 1. Purpose of the Campaign The IOTA Bounty Program offers participants the opportunity to improve the IOTA ecosystem and receive IOTA tokens as a reward for completing designated tasks. The program is managed and hosted on a dedicated GitHub Project board, which acts as the central hub for all available tasks. For details on currently active tasks, please consult the GitHub Project board. ## 2. Participation Participate in the Campaign by: 1. **Choosing a Task:** Browse the open issues on the GitHub Project board and find a task that aligns with your skillset. Once you have chosen a task, add a comment to it asking for it to be assigned to you. 2. **Contributing and Submitting:** Work on the selected task and submit your contribution via the linked repository. 3. **Raising a New Issue:** At times, we may also invite IOTA community members to create new issues and link them to the board for others to work on. ## 3. Eligibility All participants in the Campaign must: * Be at least 18 years old or the age of legal majority in your jurisdiction or have the consent of your legal guardian to participate; * Join the IOTA Builders Discord and have a valid GitHub account to submit content via the GitHub Project board; * Have a valid IOTA wallet address to receive token rewards; * Not be subject to any economic, trade, or financial sanctions. We reserve the right to screen wallet addresses through third-party compliance tools for anti-money laundering, sanctions, abuse, or fraud prevention purposes. Wallets flagged during compliance screening may be disqualified from reward distribution without prior notice. By participating in the Campaign, you confirm that you are not subject to any sanctions, including but not limited to sanctions imposed by the United Nations, the UK, the U.S., the EU, Switzerland or the UAE, and that there are no criminal or regulatory investigations, decisions or laws applicable to you that would prevent you from participating in the Campaign. ## 4. Selection and Rewards A designated Bounty Committee (“Committee”) will review and evaluate all submissions. Submissions are judged at the Committee’s sole discretion based on creativity, quality, relevance, and alignment with the task description. The Committee may choose to award full, partial, or no rewards. Rewards will be distributed in IOTA tokens. There is no guarantee of a reward, even if you make a submission. The reward will be distributed only after the submission has been deemed complete and satisfactory. The value of the reward may vary per bounty and is subject to change due to campaign parameters, technical issues, or budgetary constraints. The decisions of the Committee are final and cannot be appealed. ## 5. Content Moderation We reserve the right to moderate, hide, edit, or remove any content submitted in connection with the Campaign, at our sole discretion and without prior notice, especially if it violates these Terms, the bounty guidelines, or community standards. You agree to maintain an inclusive and welcoming environment and agree to abstain from submitting or otherwise distributing any content that could be construed as discriminatory, harassing, or unlawful. ## 6. Intellectual Property and Usage Rights By submitting content as part of the Campaign, you confirm that: * You are the original creator of the content and/or hold all necessary licenses and rights to submit the content; * The content does not infringe any third-party rights, such as trademarks, copyright or related rights and that the content does not violate any applicable laws. You grant us a worldwide, royalty-free, non-exclusive license to use, reproduce, modify, publish, and share your submission, including for promotional and community-building purposes, with credit where reasonably possible. ## 7. Disclaimer and Limitation of Liability Participation in the Campaign, including the use of any third-party platforms such as the GitHub Project platform, is undertaken entirely at your own risk. We provide no warranty regarding the availability, functionality, or continuity of the Campaign, its technical infrastructure, the GitHub Project platform, or the reward distribution process. Specifically, no warranties (express or implied) are made concerning: * Receipt or value of IOTA rewards; * Platform uptime, reliability, or error-free operation; * Freedom from bugs, exploits, or malicious activity. To the fullest extent permitted by law, we disclaim all liability for: * Loss or non-receipt of digital assets; * Submission errors, platform malfunctions, or technical failures; * Any incidental, indirect, special, or consequential damages arising from your participation in the Campaign. Our total liability, if any, is limited to the actual reward amount distributed to you (if any). You agree to waive any claims against us, including under contract, tort, or statutory provisions. ## 8. Data Collection and Privacy Participation in the Campaign requires the processing of certain personal data. By participating, you acknowledge that your data will be processed in accordance with the [Privacy Policy](https://www.iota.org/privacy-policy). ## 9. Governing Law and Jurisdiction These Terms shall be governed by and construed in accordance with the laws of Germany, without regard to conflict of law principles. Any disputes shall be subject to the exclusive jurisdiction of courts located in Berlin, Germany. ## 10. Final Provisions If any part of these Terms is held to be invalid or unenforceable, the remainder shall remain in full force and effect. These Terms constitute the entire agreement between you and us in relation to the Campaign. We reserve the right to modify, pause, or terminate the Campaign or any individual bounties at any time, and we reserve the right to amend these Terms at any time by publishing a new version of the Terms on the Campaign page. Continued participation after changes implies acceptance of the updated Terms. --- ## Gas Pricing and Transaction Fees The IOTA gas pricing mechanism determines how transaction fees are computed and plays a central role in ensuring efficient network operation. It serves two primary objectives: 1. Delivering **low, predictable transaction fees**. 2. Preventing **denial-of-service (DoS) attacks**. To achieve these goals, every IOTA transaction pays fees for **computation**, required to execute the transaction, and **storage**, required to persist data on-chain. Hence, transaction fees decompose into: `net gas fees = Computation fee + Storage fee − Storage rebate` where: - **Computation fee** = `computation_units * gas_price` - **Storage fee (deposit)** = `storage_units * storage_price` - **Storage rebate** is the amount refunded when previously stored data is deleted. Equivalently, the total gas fees are: `gas_fees = computation_units * gas_price + storage_units * storage_price - storage_rebate` This formulation separates the cost of execution from the cost of storage, while ensuring that users only pay for the net storage they consume over time. ## Computation Fees The computation fee captures the cost of executing a transaction: `computation_fee = computation_units * gas_price` ### Computation Units Different IOTA transactions require varying amounts of computational time for processing and execution. IOTA translates these varying operational loads into transaction fees by measuring each transaction in terms of _computation units_. In general, more complex transactions require more computation units. Importantly, though, the IOTA computation gas schedule is built with a _bucketing/step approach_. Two reasonably similar transactions translate into the exact same amount of computation units if they are in the same bucket, whereas two relatively different transactions translate into different amounts of computation units if they fall in separate buckets. The smallest bucket maps into 1,000 computation units, meaning that all transactions that fall into the smallest bucket cost 1,000 computation units. The step between buckets is 1,000 and the largest bucket maps into 5,000,000 computation units; if a transaction requires more computation units, it aborts. Using bucketing accomplishes two important goals: - Frees users from optimizing their smart contracts to deliver marginal gains in gas costs via "gas golfing" — instead, they can focus on step-function improvements in their products and services. - Gives users the freedom to adjust per-instruction gas costs and experiment with new gas metering schemes without creating significant development disruption. This can happen frequently, so it is important that they do not rely on per-instruction gas costs remaining stable over time. ### Gas Price The gas price is specified by the user and must be at least a protocol-defined baseline: `gas_price = reference_gas_price + tip` - The **reference gas price** is defined by the protocol (currently set to 1,000 NANOS) and acts as a baseline for transaction inclusion. All transactions must pay at least this amount, and fees up to this level are burned. - The **tip** is an optional additional fee paid by users to prioritize their transactions. Any amount above the reference gas price is transferred to validators as part of their rewards. During normal network conditions, most transactions use the reference gas price with no tip, ensuring predictable and stable fees. However, during periods of congestion, users can request an estimated minimum gas price for successful execution through a transaction dry run. This estimation is computed using a [predictive gas pricing algorithm](#gas-price-prediction), which helps users determine an appropriate tip. The algorithm leverages historical congestion data and dynamically adjusts weights for shared objects accessed by transactions using an online gradient descent method. ## Storage Fees The storage fee captures the cost of storing data on-chain: `storage_fee = storage_units * storage_price` ### Storage Units Similarly, IOTA transactions vary depending on the amount of new data written into on-chain storage. The variable storage units capture these differences by mapping the number of bytes held in storage into _storage units_. The current IOTA schedule is linear and maps each byte into 100 storage units. So, for example, a transaction that stores 25 bytes costs 2,500 storage units, while a transaction that stores 75 bytes costs 7,500 units. Importantly, in IOTA's storage model, users pay storage deposit fees for storing data in perpetuity but can also get a full rebate on previously stored data if that data is deleted. Hence, the amount of storage fees that users pay is 100% rebateable. This storage deposit mechanism incentivizes users to minimize the storage burden they place on all nodes by reducing their storage requirements and cleaning up unused objects. ### Storage Price - The **storage price** is fixed and shared across all transactions. It is set through governance proposals and updated infrequently. - Storage fees act as a **deposit**: users pay upfront for storing data, but receive a **100% rebate** when that data is deleted. The storage price is set exogenously with the goal of targeting the real-world cost of data storage. Over time, governance can adjust this value to reflect changes in hardware costs and the market value of the IOTA token. This design ensures that users internalize the long-term cost of storage while retaining strong incentives to minimize and clean up on-chain data. ## Gas Budgets Every transaction on IOTA must include a **gas budget**, which sets the maximum amount the user is willing to pay for computation and storage. The gas budget can be set between 1,000,000 NANOS (0.001 IOTA) and 50,000,000,000 NANOS (50 IOTA). This range protects the network against spam and denial-of-service attacks. Transactions are successfully executed if: `gas_budget >= max{computation_fees, net_gas_fees}` If the gas budget does not satisfy this condition, the transaction fails and a portion of the gas budget is charged. The charging rules are as follows: - If the **gas budget is insufficient to cover both computation fees and storage fees**, then the **entire gas budget** is charged. - If the **gas budget is sufficient for computation fees** but **not enough for net gas fees**, then a portion of the gas budget is charged corresponding to: - the computation fees, and - the fees associated with mutating the transaction's input objects. Ultimately, a successful transaction requires the end user to pay the transaction's **net gas fees**. However, since it is difficult to perfectly forecast computation time before the transaction is processed, the gas budget must also **cover at least the computation fees** in case the transaction aborts. Additionally, in some cases — especially when there are **high storage rebates** leading to **negative net storage fees** — the total gas fees the user pays (`net_gas_fees`) might be **lower than the computation fees**. As mentioned previously, the **storage rebate is 100%** of the originally paid storage fees. This mechanism ensures that users are reimbursed for previously stored data that is deleted, which encourages efficient use of on-chain storage. ### Examples The following table provides examples of gas accounting on the IOTA network. - In the first two and last two rows, computation units are the same because transactions fall within the same bucket. - The last two transactions are more complex than the first two, so they fall into a higher computation bucket. - In the last transaction, the storage rebate is large enough to fully offset the transaction gas fees, effectively giving the user a positive net balance. These examples highlight the importance of the gas budget: - The minimum gas budget is the smallest amount a transaction can specify to execute successfully. - When there is a storage rebate, the minimum gas budget is often larger than the net gas fees a user ultimately pays. - This is particularly evident in the last example, where the user receives a positive amount back after executing the transaction, because the minimum gas budget must still cover the computation fees. | | Reference Gas Price | Computation Units | Storage Price | Storage Units | Storage Rebate | Minimum Gas Budget | Net Gas Fees | | ------------------------------------------------------- | ----------------- | ---------------- | ------------- | ------------- | --------------- | ---------------- | --------------- | | Simple transaction storing 10 bytes | 1,000 NANOS | 1,000 | 75 NANOS | 1,000 | 0 NANOS | 1,075,000 NANOS | 1,075,000 NANOS | | Simple transaction storing 10 bytes and deleting data | 500 NANOS | 1,000 | 75 NANOS | 1,000 | 100,000 NANOS | 500,000 NANOS | 475,000 NANOS | | Complex transaction storing 120 bytes | 1,000 NANOS | 5,000 | 200 NANOS | 12,000 | 0 NANOS | 7,400,000 NANOS | 7,400,000 NANOS | | Complex transaction storing 120 bytes and deleting data | 500 NANOS | 5,000 | 200 NANOS | 12,000 | 5,000,000 NANOS | 2,500,000 NANOS | -100,000 NANOS | ## Gas Price Prediction During Dry Run {#gas-price-prediction} When you execute a **dry run** or **dev inspect** transaction, the IOTA network provides a `suggested_gas_price` in the response. This value helps users estimate an appropriate gas price for transactions that interact with shared objects, particularly during periods of network congestion. :::info When to Use It If your transaction touches popular shared objects (e.g., a DEX pool), the suggested gas price reflects the current level of congestion on those objects and helps reduce the probability that the transaction will be cancelled. For transactions that only use owned objects, no additional tip is required. ::: The network maintains a **congestion tracker** that monitors shared-object access patterns across checkpoints. For each mutable shared object, the tracker computes a _hotness_ value that reflects how congested that object is based on recent transaction history. This hotness value is updated using an online gradient-descent-based mechanism driven by checkpoint statistics (e.g., cancelled transactions, successfully scheduled transactions). During a dry run, the suggested gas price is calculated as: `suggested_gas_price = reference_gas_price + max_hotness` where `max_hotness` is the highest hotness value among all mutable shared objects accessed by the transaction. If the transaction does not access any tracked shared objects, the suggested gas price falls back to the current `reference_gas_price`. By using the `suggested_gas_price` from a dry-run response, users can adapt their gas price to current network conditions. This reduces the risk of underbidding during congestion while avoiding unnecessary overpayment during periods of low activity. --- ## IOTA Token The native asset on IOTA is called **IOTA**. At the launch of IOTA Rebased, **4,600,000,000** IOTA tokens were migrated from the previous network called _Stardust_. **767,000** new IOTA tokens are minted each epoch. As a result, IOTA has no fixed maximum supply — the total supply fluctuates over time based on the balance between token inflation and fee burning. :::info Decimals The number of decimals for the IOTA token has changed from **6** to **9** with this release: any balance from the Stardust network has been migrated and multiplied by 1,000 to accommodate. ::: The IOTA token serves four purposes on the IOTA network: - **Staking:** You can stake IOTA to participate in the delegated proof-of-stake mechanism. - **Transaction Fees:** IOTA is the asset denomination needed to pay the gas fees required to execute transactions and store created data on chain or process other operations on the IOTA network. - **Value transfers:** IOTA can be used as a versatile and liquid asset for various applications, including the standard features of money — a unit of account, a medium of exchange, or a store of value — and more complex functionality enabled by smart contracts, interoperability, and composability across the IOTA ecosystem. - **Governance:** IOTA tokens play an important role in governance by acting as a right to participate in on-chain voting on issues such as protocol upgrades. All original IOTA Tokens are represented as the `0x2::iota::IOTA` type of object on IOTA, accessible on the same (Hex format) addresses from the Stardust-based network. No manual migration is needed to access these tokens. --- ## Delegated Proof of Stake The IOTA platform relies on _delegated proof-of-stake_ (DPoS) to determine the set of validators that process transactions. ## IOTA Token Staking Within each epoch, all operations on the IOTA network processed by a fixed set of validators, each with a specific amount of stake from IOTA token holders. A validator's share of total stake is relevant in that it determines each validator's share of voting power for processing transactions. Staking IOTA implies that the staked IOTA tokens are locked for the entire epoch. IOTA token holders are free to withdraw their IOTA or to change their selected validator when the epoch changes. ## Economic Model This section covers how the different components of the IOTA economy interact with each other to introduce the IOTA DPoS system. For reference, see the Staking and Tokenomics diagram in the [IOTA Tokenomics](./tokenomics.mdx) overview. The IOTA economic model works as follows. At the beginning of each epoch, the delegated tokens for a given validator are added up, and a new [validator committee](../iota-architecture/validator-committee.mdx) is formed. Following this action, the protocol computes the total amount of stake as the sum of staked IOTA. During each epoch, users submit transactions to the IOTA platform and validators process them. For each transaction, users pay the associated computation fees, the storage deposit and, optionally, a tip for prioritization. In cases where users delete previous objects or data within objects, users obtain a rebate of their storage deposit. Validators observe the behavior of other validators and evaluate each other's performance. At the end of each epoch, the protocol distributes stake rewards to participants of the DPoS mechanism. This occurs through three main steps: - The total amount of stake rewards is calculated. The stake rewards are composed of a validator subsidy, which is currently set as 767,000 IOTA tokens per epoch, plus any tips from user transactions. - The total amount of stake rewards is distributed across various pools, proportionally to their stake and adjusted by validators' performance. - Each pool's amount of rewards is distributed between the validator and the other parties. Validators first keep a commission $$\delta_v$$ (maximum 20%) of the total pool rewards as a fee to cover their costs. The rest of the rewards (i.e., after discounting the validator's commission) is distributed among all users (including the validator) proportionally to their stake. To mitigate stake centralization, the protocol enforces a dynamic minimum commission based on each validator’s voting power (VP%). In particular, the effective commission applied during an epoch is set to the maximum between the validator’s chosen commission and its VP%. This prevents large validators from attracting disproportionate stake through very low fees, while preserving flexibility for smaller validators and maintaining a balanced, competitive staking ecosystem. Finally, let $$\beta_v$$ represent the share of stake managed by a validator $$v$$ that is owned by itself, while $$(1-\beta_v)$$ represents the share owned by third-party stakers. The rewards for users of validator's $$v$$ staking pool and for the validator $$v$$ itself equal: $$ UserStakeRewards_v \ = (1-\delta_v) \times (1-\beta_v) \times \mu_v \times \sigma_v \times TotalStakeRewards, $$ $$ ValidatorRewards_v \ = \ \Big(\beta_v + \delta_v \times (1-\beta_v)\Big) \times \mu_v \times \sigma_v \times TotalStakeRewards. $$ ### Tallying Rule The $$\mu_v$$ variable is used to incentivize validators to process transactions efficiently. Throughout each epoch, validators observe the behavior of other validators and evaluate their performance. This information is used in the _tallying rule_, whereby each validator assigns performance multipliers to others based on observed behavior. At the end of the epoch, these evaluations are aggregated into a global performance factor $$\mu_v$$ for each validator which directly affects each validator’s share of staking rewards: - Validators that operate efficiently at the reference gas price receive full rewards ($$\mu_v = 1$$). - Validators that deviate or perform poorly receive reduced rewards ($$\mu_v < 1$$). This variable ensures that validators have incurred monetary risk and therefore are incentivized to operate the IOTA network efficiently. The $$\sigma_v$$ parameter captures each pool's share of total stake. Consequently, validators with more stake earn more stake rewards and the joint $$\mu_v\sigma_v$$ term incentivizes validators to increase their share of the stake while also operating the network performantly. In the long-run, this incentive encourages users to shift the stake distribution towards the network's most efficient validators. --- ## Staking and Unstaking IOTA uses a Delegated-Proof-of-Stake (DPoS) system to secure and operate the network, meaning that the voting power of a validator in the network is determined by the amount of stake delegated to them by IOTA token holders. The more stake delegated to a validator, the more voting power they have. In exchange for processing transactions and performing consensus, validators earn rewards based on a given IOTA inflation rate. These rewards are then shared among stakers as staking rewards. ## Staking You stake your IOTA tokens by sending a transaction to the network that calls the staking function implemented as part of the system Move package. This transaction wraps the IOTA tokens in a self-custodial stake object. This stake object contains such information as the validator staking pool ID and the activation epoch of the stake. IOTA-compatible crypto wallets typically have functionality to initiate staking and unstaking from your IOTA address. See the respective documentation for these tools to begin staking your IOTA. ## Unstaking Similar to staking, a user withdraws their stake from a validator by sending a transaction that calls the unstaking function in the system Move package. This transaction unwraps the stake object, and sends both the principal and the accumulated rewards to the user as IOTA tokens. You accrue rewards only during epochs where the stake is active for the entire epoch. The rewards withdrawn from the validator's rewards pool are calculated based on the activation epoch and unstaking epoch of the stake. ## Choosing a validator for staking When you stake on IOTA, you have to choose a specific validator you would like to stake with. The choice of validator can potentially impact the amount of staking rewards you receive. The factors determining this amount include, but are not limited to: - _Validator commission rate_: a validator can set a non-zero commission rate specifying the percentage of staking rewards they are taking from the stakers. For example, if a validator has a commission rate of 10%, then 10% of every staker's staking rewards is given to the validator. Note that a validator can change its commission at a future moment in time without prior notice. - _Validator performance_: a validator with bad performance might be punished according to the [tallying rule](./proof-of-stake.mdx#tallying-rule). Punished validators receive only a fraction of staking rewards for the epoch during which they are punished, and you also will receive a fraction of that epoch's rewards when you withdraw your stake from that validator. IOTA-compatible crypto wallets and explorers typically provide validator information such as commission and APY. See the respective documentation for these tools for information on how to retrieve this data. --- ## IOTA Tokenomics import ThemedImage from '@theme/ThemedImage'; Tokenomics refers to the various concepts that shape the science and behavior of blockchain economies. In basic terms, **tokenomics** is the financial foundation of blockchains. Much the same way a building with a poor foundation is doomed to fail, a blockchain without a well-researched, extensively planned, and painstakingly implemented token economy eventually crumbles. IOTA tokenomics is based on sound financial concepts confirmed by extensive blockchain research. Designed for scale, the IOTA tokenomics structure is intended to support the financial needs of Web3 now and in the future. ## The Actors in the IOTA Economy Three main types of participants characterize the IOTA economy: - **Users** submit transactions to the IOTA platform to create, mutate, and transfer digital assets or interact with more sophisticated applications enabled by smart contracts, interoperability, and composability. - **Validators** manage transaction processing and execution on the IOTA platform. - **Delegators** are IOTA token holders who choose to delegate their tokens to validators to participate in the proof-of-stake mechanism. By holding IOTA tokens, they also gain the right to participate in the network’s governance. ## Tokenomics Overview The following flowchart provides a high-level overview of the monetary flow within the IOTA's tokenomics. At its core, the IOTA economy is driven by the [IOTA token](iota-token.mdx), the native asset of the IOTA ecosystem. When users submit transactions, they incur gas fees to pay for computation. A portion of this computation fee is burned to mitigate token inflation and users can include an optional tip to incentivize validators for faster processing during network congestion. In addition to the tips from users, staking rewards also include a validator subsidy. This subsidy of IOTA tokens is minted and distributed to well-behaving validators who contribute to the system's security. A portion of the overall staking rewards is allocated to delegators after deducting the validator's commission. Additionally, some tokens are locked as a storage deposit when creating objects and are redeemable upon object deletion. Referring back to this chart after the reader has learned the concepts in this section should provide additional clarity. --- ## Validators and Staking Pools Each IOTA validator maintains its own staking pool to track the amount of stake and to compound staking rewards. Validator pools operate together with a time series of exchange rates that are computed at each epoch boundary. These exchange rates determine the amount of IOTA tokens that each past IOTA staker can withdraw in the future. Importantly, the exchange rates increase as more rewards are deposited into a staking pool and the longer an amount of IOTA is deposited in a staking pool, the more rewards it will accrue. When IOTA is deposited to the staking pool in epoch `E`, those IOTA tokens are converted into staked tokens at the epoch `E` exchange rate. As the staking pool earns rewards, the exchange rate appreciates. At epoch `E'`, those staked tokens are worth more and translate into more IOTA. A global exchange rate table is used to track the accounting. Because all IOTA tokens in the staking pool are treated the same, regardless of whether they were originally deposited as new stake or as stake rewards, all IOTA tokens immediately count as stake and thus compound rewards immediately. The staking pool is implemented in a system-level smart contract ([staking_pool.move](https://github.com/iotaledger/iota/blob/develop/crates/iota-framework/packages/iota-system/sources/staking_pool.move)) and is part of the IOTA framework. ## Validator Pool Rewards At each epoch boundary, the system computes the staking rewards for each validator pool proportionally to the staked tokens in each pool. The staking rewards $$rewards(i, E)$$ for validator pool $$i$$ at epoch $$E$$ are computed as follows: $$ rewards(i, E) = \frac{ stakedTokens(i, E)}{\sum_i (stakedTokens(i, E)) }\times totalRewards(E). $$ $$rewards(i, E)$$ is then adjusted to consider potential slashed validators who have not met minimum quality requirements. Additionally, validators earn commissions on the staking pool's tokens. IOTA keeps track of the rewards accrued by both validators and delegators using a single global exchange rate table. ## Validator Staking Pool Requirements There are minimum staking requirements a validator must satisfy to become active and to stay in the active validator set. More precisely: - A validator candidate must accrue at least 2M IOTA of stake before they can request to join the validator set. - If an active validator’s stake falls below 1.5M IOTA, the validator has seven epochs of grace period to gain back the stake before being removed from the validator set. - If an active validator’s stake falls below 1M IOTA, the validator is removed from the validator set at the end of the current epoch boundary. IOTA uses 24-hour epochs. --- ## Why Move? While EVM/Solidity is the most famous smart contracts platform, it has some downsides that IOTA Move aims to address: - **Performance, scaling, and cost**: EVM builds on top of a global shared state, which is practical but doesn't scale well. This results in limitations in throughput, which is directly reflected in the fees you must pay to interact with these networks. The more congested the network, the more expensive it gets. Other blockchains try to mitigate this with additional extra execution layers (L2s on top of L1s) or rollup solutions, which also have downsides and limitations. - **Security:** As the first well-used smart contract language, Solidity did not have much to go by in terms of learnings around secure practices (there was no existing ecosystem yet), and it had to develop over the years with that legacy and backward compatibility in mind. Many of the issues from the past have been mitigated with workarounds. Still, given the nature of things, there are some limitations and annoyances we currently can't get around, like the security issues it has with both the code and infamous design patterns like the `approve()` method in the ERC standards. - **Tokens:** Assets like ERC20 tokens and ERC721/1155 NFTs are not part of the EVM and are purely standards for smart contracts deployed on an EVM chain interpreted as tokens by clients. While this works and allows much flexibility, it also has its downsides. Due to the nature of tokens being contracts and the state of your balance being stored within those contracts, it's not trivial to find all tokens in your account without knowing all token contract addresses and manually adding them, unlike the Ethereum balance itself, which is a different kind of token which can be found directly but works differently over an ERC20 token. This makes discovering your assets difficult and adds additional complexity to applications to close the gap between the native asset (ETH) and ERC20 tokens with workarounds like wrapped tokens, which is not ideal. - **Developer experience:** Solidity offers a wealth of developer tools and resources, including various libraries and frameworks to choose from, as well as extensive documentation and tutorials. The language, influenced by popular languages like C++ and JavaScript, is easy to learn and get started with. However, Solidity's lack of strictness allows for mistakes that the compiler may not catch, leading to bugs and security issues that are difficult to identify and resolve. Consequently, the developer experience suffers, and the language itself is not as safe to work with as it could be. IOTA Move is here to learn from these downsides and come up with a better alternative addressing these issues: * **Performance, scaling, and cost:** Given that IOTA Move is based on the object model (similar to UTXO's) and not a globally shared state, transactions can be executed in parallel, resulting in a much higher (potential) throughput over a traditional blockchain with shared state. This results in a lot less congestion and, thus, lower fees on an actively used network. * **Security:** Move was designed with security in mind. The language itself is based on Rust and is very strict regarding its typing system. The Move compiler is designed to catch many common programming errors, such as type mismatches, resource misuse, and violations of ownership or borrowing rules, before deployment. This helps ensure safety and correctness without relying solely on runtime checks. There's no such thing as re-entry, and given the object-based approach of Move, Assets residing in your account can't be touched at all by the smart contract itself without access to your account keys. * **Tokens:** In IOTA Move, there is no difference between the IOTA token (`Coin`) and a custom token (`Coin`), not in terms of use or implementation, except that the IOTA token can be used for gas payments. These objects reside in your own account and can thus easily be found without needing to know a Smart Contract address (this goes for any other type of owned object as well). There's no strange `approve()` functionality, and you keep control over your own owned assets. * **Developer Experience:** While Move is more challenging to get started with compared to Solidity due to its novelty and less mature developer tooling, the safety of the language and the ease of finding and resolving issues in your code make up for that. With Move, it's not so scary anymore to write complex logic from scratch, given most mistakes (apart from obvious implementation logic, doing things 'as intended') are caught directly by the compiler. This allows for more innovation, fewer value-destroying bugs, and a more excellent developer experience, fueling the next generation of smart contracts. To sum this up: IOTA offers both EVM and Move, so you can choose the best tool for the job. If you want to build something that needs to be secure, scalable, and cost-effective, IOTA Move is definitely the way to go. However, if you want a fast shortcut to get started with IOTA smart contracts, or you want to migrate an existing EVM project to IOTA, EVM/Solidity is a good choice. | EVM/Solidity | Move | | ------------------------------------------ | ------------------------------------------------------ | | State as part of contracts | State as objects | | Global shared state | Owned and Shared objects | | Transactions executed one by one | Parallel execution | | No enforced security for standards | Strict type system for standards, assurances | | Easy to get started with, hard to do right | Harder to get started with, but less room for mistakes | --- ## Account Abstraction :::info Account Abstraction RC Account Abstraction is currently a release candidate and, therefore, only available on Testnet and Devnet. If you test it out, please share your feedback with us in the [IOTA Builders Discord](https://builders-discord.iota.org/). ::: Account Abstraction (AA) in IOTA lets you replace fixed cryptographic signature verification with programmable Move logic, enabling flexible and extensible account authentication. This feature allows you to implement custom authentication logic, multi-signature schemes, time-locked accounts, and other advanced account management patterns. For a full conceptual introduction, see the [Account Abstraction explanation](./move/explanations/account-abstraction/introduction.mdx). ## Move How-Tos These guides show how to implement and manage abstract accounts in Move. Go to [How To](./move/how-tos/account-abstraction). --- ## Asset Tokenization Asset tokenization refers to the process of representing real-world assets, such as real estate, art, commodities, stocks, or other valuable assets, as digital tokens on the blockchain network. This involves converting the ownership or rights of an asset into digital tokens, which are then recorded and managed on the blockchain. ## High-level Overview The concept is to divide high-value assets into smaller, more affordable units, representing ownership or a fraction of the asset. This strategy enables wider participation from investors who might want to mitigate risk by investing in a portion of a digital asset rather than being the sole owner, thereby expanding accessibility to a broader range of investors. This pattern is similar to the [ERC1155](https://eips.ethereum.org/EIPS/eip-1155) multi-token standard with additional functionality. This makes it a suitable choice for Solidity based use cases that one might want to implement on IOTA. - **Asset creation** Each asset is fractionalized into a total supply, with each fraction represented as either a non-fungible token (NFT) or fungible token (FT) type collectible. This ensures that each individual fraction maintains a balance equal to or greater than one, and when combined, all fractions collectively reach the total supply of the asset. Besides the total supply, each asset is defined by various other fields such as name, description, and more. These fields collectively form the metadata for the asset, and they remain consistent across all fractions of the asset. - **NFTs vs FTs distinction** Each time a tokenized asset is minted, there's a possibility for it to be created with new metadata. If new metadata is incorporated, the tokenized asset is deemed unique, transforming it into an NFT. In this case, its balance is limited to one, signifying that only a single instance of this asset exists. If there's no additional metadata, the tokenized asset is categorized as an FT, allowing its balance to exceed one, enabling multiple identical instances of the asset to exist. FTs possess the capability to merge (join) among themselves or be split when the balance is greater than one. This functionality allows for the aggregation or division of units of the token, offering flexibility in handling varying quantities as needed. As previously mentioned, all the collectibles of tokenized assets, whether NFTs or FTs, when combined, can amount to the maximum total supply of the asset. - **Burnability** When you create the asset, you can define whether the fractions of the asset are eligible for removal or destruction from circulation. The process of removing or destroying assets is called burning. If a tokenized asset is burnable, then burning a fraction causes the circulating supply to decrease by the balance of the burnt item. The total supply, however, remains constant, allowing you to mint the burned fractions again if needed, thus maintaining the predetermined total supply of the asset. ## Move Packages As with all smart contracts on IOTA, Move provides the logic that powers asset tokenization. ### `asset_tokenization` Package :::info This reference implementation uses the [Kiosk standard](../standards/kiosk.mdx) to ensure that tokenized assets operate within their defined policy. Use the implementation as presented to have marketable tokenized assets that support rules like royalties, commissions, and so on. If using Kiosk is not a requirement, then you can exclude the unlock module and some of the proxy's methods related to transfer policies. ::: Select a module to view its details: The `tokenized_asset` module operates in a manner similar to the `coin` library. When it receives a new [one-time witness](../iota-101/move-overview/one-time-witness.mdx) type, it creates a unique representation of a fractional asset. This module employs similar implementations to some methods found in the `Coin` module. It encompasses functionalities pertinent to asset tokenization, including new asset creation, minting, splitting, joining, and burning. **Structs** - `AssetCap` Generate an `AssetCap` for each new asset represented as a fractional NFT. In most scenarios, you should create it as an owned object, which you can then transfer to the platform's administrator for access-restricted method invocation. ```rust struct AssetCap { id: UID, // the current supply in circulation supply: Supply, // the total max supply allowed to exist at any time total_supply: u64, // Determines if the asset can be burned or not burnable: bool } ``` - `AssetMetadata` The `AssetMetadata` struct defines the metadata representing the entire asset to fractionalize. This should be a shared object. ```rust struct AssetMetadata has key, store { id: UID, /// Name of the asset name: String, // the total max supply allowed to exist at any time total_supply: u64, /// Symbol for the asset symbol: ascii::String, /// Description of the asset description: String, /// URL for the asset logo icon_url: Option } ``` - `TokenizedAsset` The `TokenizedAsset` is minted with a specified balance that is less than or equal to the remaining supply. If the `VecMap` of an asset is populated with values, indicating multiple unique entries, it is considered an NFT. Conversely, if the `VecMap` of an asset is not populated, indicating an absence of individual entries, it is considered an FT. ```rust struct TokenizedAsset has key, store { id: UID, /// The balance of the tokenized asset balance: Balance, /// If the VecMap is populated, it is considered an NFT, else the asset is considered an FT. metadata: VecMap, /// URL for the asset image (optional) image_url: Option, } ``` - `PlatformCap` The `PlatformCap` refers to the capability issued to the individual who deploys the contract. This capability grants specific permissions or authority related to the platform's functionalities, allowing the deployer certain controlled actions or access rights within the deployed contract. ```rust /// Capability that is issued to the one deploying the contract struct PlatformCap has key, store { id: UID } ``` **Functions** - `init` This function creates a `PlatformCap` and sends it to the sender. ```rust fun init(ctx: &mut TxContext) {} ``` - `new_asset` This function holds the responsibility of creating a fresh representation of an asset, defining its crucial attributes. Upon execution, it returns two distinct objects: the `AssetCap` and `AssetMetadata`. These objects encapsulate the necessary information and characteristics defining the asset within the system. ```rust public fun new_asset( witness: T, total_supply: u64, symbol: ascii::String, name: String, description: String, icon_url: Option, burnable: bool, ctx: &mut TxContext ): (AssetCap, AssetMetadata) {} ``` - `mint` The function performs the minting of a tokenized asset. If new metadata is introduced during this process, the resulting tokenized asset is considered unique, resulting in the creation of an NFT with a balance set to 1. Alternatively, if no new metadata is added, the tokenized asset is classified as an FT, permitting its balance to surpass 1, as specified by a provided argument. Upon execution, the function returns the tokenized asset object. ```rust public fun mint( cap: &mut AssetCap, keys: vector, values: vector, value: u64, ctx: &mut TxContext ): TokenizedAsset {} ``` - `split` This function is provided with a tokenized asset of the FT type and a balance greater than 1, along with a value less than the object's balance, and performs a split operation on the tokenized asset. The operation divides the existing tokenized asset into two separate tokenized assets. The newly created tokenized asset has a balance equal to the given value, while the balance of the provided object is reduced by the specified value. Upon completion, the function returns the newly created tokenized asset. This function does not accept or operate on tokenized assets of the NFT type. ```rust public fun split( self: &mut TokenizedAsset, split_amount: u64, ctx: &mut TxContext ): TokenizedAsset {} ``` - `join` This function is given two tokenized assets of the FT type and executes a merge operation on the tokenized assets. The operation involves increasing the balance of the first tokenized asset by the balance of the second one. Subsequently, the second tokenized asset is burned or removed from circulation. After the process concludes, the function returns the ID of the burned tokenized asset. This function does not accept or operate on tokenized assets of the NFT type. ```rust public fun join( self: &mut TokenizedAsset, other: TokenizedAsset ): ID {} ``` - `burn` This function requires the `assetCap` as a parameter, thereby restricting its invocation solely to the platform admin. Additionally, it accepts a tokenized asset that is burned as part of its operation. Upon burning the provided tokenized asset, the circulating supply decreases by the balance of the burnt item. It necessitates a tokenized asset that is burnable. ```rust public fun burn( cap: &mut AssetCap, tokenized_asset: TokenizedAsset ) ``` - `total_supply` This function retrieves and returns the value representing the total supply of the asset. ```rust public fun total_supply(cap: &AssetCap): u64 {} ``` - `supply` This function retrieves and returns the value representing the current circulating supply of the asset. ```rust public fun supply(cap: &AssetCap): u64 {} ``` - `value` This function takes a tokenized asset as input and retrieves its associated balance value. ```rust public fun value(tokenized_asset: &TokenizedAsset): u64 {} ``` - `create_vec_map_from_arrays` This internal helper function populates a `VecMap`. It assists in the process of filling or setting key-value pairs within the `VecMap` data structure. ```rust fun create_vec_map_from_arrays( keys: vector, values: vector ): VecMap {} ``` - `tokenized_asset` full example ```move file=/examples/move/asset_tokenization/asset_tokenization/sources/tokenized_asset.move ``` The `proxy` module comprises methods that the type owner utilizes to execute publisher-related operations. **Structs** - `Proxy` The `PROXY` struct represents the one-time witness (OTW) to claim the publisher. ```rust struct PROXY has drop {} ``` - `Registry` This shared object serves as a repository for the `Publisher` object, specifically intended to control and restrict access to the creation and management of transfer policies for tokenized assets. Mutable access to this object is exclusively granted to the actual publisher. ```rust struct Registry has key { id: UID, publisher: Publisher } ``` - `ProtectedTP` This is a shared object that stores an empty transfer policy. It is required to create one per type `` generated by a user. Its involvement is apparent in the unlock module. ```rust struct ProtectedTP has key, store { id: UID, policy_cap: TransferPolicyCap, transfer_policy: TransferPolicy } ``` **Functions** - `init` This function is responsible for creating the `Publisher` object, encapsulating it within the registry, and subsequently sharing the `Registry` object. ```rust fun init(otw: PROXY, ctx: &mut TxContext) {} ``` - `setup_tp` This function leverages the publisher nested within the registry and the sender's publisher. It generates and returns a transfer policy and the associated transfer policy cap specific to the `TokenizedAsset`. This type 'T' is derived from the `Publisher` object. It also generates an empty transfer policy wrapped in a `ProtectedTP` object, which is shared. You can use this functionality under specific conditions to override the kiosk lock rule. ```rust public fun setup_tp( registry: &Registry, publisher: &Publisher, ctx: &mut TxContext ): (TransferPolicy>, TransferPolicyCap>) {} ``` - `new_display` This function utilizes the publisher nested within the registry and the sender's publisher to generate and return an empty `Display` for the type `TokenizedAsset`, where `T` is encapsulated within the `Publisher` object. ```rust public fun new_display( registry: &Registry, publisher: &Publisher, ctx: &mut TxContext ): Display> {} ``` - `transfer_policy` This function, provided with the `protectedTP`, returns the transfer policy specifically designed for the type `TokenizedAsset` ```rust public(friend) fun transfer_policy( protected_tp: &ProtectedTP ): &TransferPolicy {} ``` - `publisher_mut` This function can only be accessed by the owner of the platform cap. It requires the registry as an argument to obtain a mutable reference to the publisher. ```rust public fun publisher_mut( _: &PlatformCap, registry: &mut Registry ): &mut Publisher {} ``` - `proxy` full example ```move file=/examples/move/asset_tokenization/asset_tokenization/sources/proxy.move ``` The `unlock` module facilitates the unlocking of a tokenized asset specifically for authorized burning and joining. It allows tokenized asset type creators to enable these operations for kiosk assets without necessitating adherence to the default set of requirements, such as rules or policies. **Structs** - `JoinPromise` A promise object is established to prevent attempts of permanently unlocking an object beyond the intended scope of joining. ```rust struct JoinPromise { /// the item where the balance of the burnt tokenized asset will be added. item: ID, /// burned is the id of the tokenized asset that will be burned burned: ID, /// the expected final balance of the item after merging expected_balance: u64 } ``` - `BurnPromise` A promise object created to ensure the permanent burning of a specified object. ```rust struct BurnPromise { expected_supply: u64 } ``` **Functions** - `asset_from_kiosk_to_join` This helper function is intended to facilitate the joining of tokenized assets locked in kiosk. It aids in unlocking the tokenized asset that is set for burning and ensures that another tokenized asset of the same type will eventually contain its balance by returning a `JoinPromise.` ```rust public fun asset_from_kiosk_to_join( self: &TokenizedAsset, // A to_burn: &TokenizedAsset, // B protected_tp: &ProtectedTP>, // unlocker transfer_request: TransferRequest> // transfer request for b ): JoinPromise {} ``` - `prove_join` A function utilized to demonstrate that the unlocked tokenized asset is successfully burned and its balance is incorporated into an existing tokenized asset. ```rust public fun prove_join( self: &TokenizedAsset, promise: JoinPromise, proof: ID) { } ``` - `asset_from_kiosk_to_burn` Helper function that facilitates the burning of tokenized assets locked in a kiosk. It assists in their unlocking while ensuring a promise that the circulating supply will be reduced, achieved by returning a `BurnPromise`. ```rust public fun asset_from_kiosk_to_burn( to_burn: &TokenizedAsset, asset_cap: &AssetCap, protected_tp: &ProtectedTP>, transfer_request: TransferRequest>, ): BurnPromise { } ``` - `prove_burn` Ensures that the circulating supply of the asset cap is reduced by the balance of the burned tokenized asset. ```rust public fun prove_burn( asset_cap: &AssetCap, promise: BurnPromise) { } ``` - `unlock` full example ```move file=/examples/move/asset_tokenization/asset_tokenization/sources/unlock.move ``` ### `template` Package An example use case package that enables utilization of Rust WASM functionality to support seamless asset creation on the browser. This is similar to the launchpad approach and serves as the template package whenever a new asset requires representation as a tokenized asset. Effectively allowing users to edit fields of this template contract on the fly and publish it with the edits included. This package implements two essential modules, each catering to distinct functionalities required for asset tokenization. More details regarding how Rust WASM was implemented can be found in the [Web Assembly](#webassembly-wasm-and-template-package) section. - **Modules** - `template` This is the module that supports defining a new asset. When you need to represent a new asset as a fractional asset, modify this module to `