Overview

IOTA provides distributed ledger technology (DLT) for the Internet of Things (IoT) – a unique type of network used for connecting and exchanging value and data between humans and computers in our day-to-day lives. The network features a unique infrastructure architecture and an open-source product suite for governments, individuals, businesses, and institutions to use in Web3.

DLTs are the technology from which blockchains are created. The infrastructure allows users to view any changes and who made them, reduces the need to audit data, ensures the data is reliable, and only provides access to those who need it. IOTA, not to be perceived as a blockchain, is built using the Directed Acyclic Graph (DAG) technology, which does not follow a straight chain-like pattern similar to blockchains; DLTs maintain a ledger of token ownership across multiple nodes. IOTA’s DAG structure is called the Tangle. It allows for feeless transactions, making microtransactions between devices not only possible but practical​.

Source: Central Blockchain Council

IOTA does not use miners to validate transactions; instead nodes that issue a new transaction on the network must approve two previous transactions, allowing new transactions to be executed without paying network fees.

By design, IOTA offers solutions for establishing a secure and permissionless infrastructure that can drive a fee-less  economy; a next-generation data and value exchange network that is designed to be sustainable and run without the need for blocks or miners. This allows IOTA to overcome the cost and scalability limitations of blockchains.

IOTA is meant to bridge the gap between humans and machines and its infrastructure hosts a wide range of products across multiple verticals in different sectors, including mobile and automotive, supply chain logistics, smart energy, data marketplaces, finance and insurance, agriculture and healthcare. The protocol empowers individuals to control their private data, run tamper-proof programs, and engage in asset ownership and trading without intermediaries.

The Tangle

IOTA’s directed acyclic graph is labeled as the Tangle. The Tangle is a data structure replicated across a decentralized network of computers or nodes. It is a robust foundation for tracking token ownership and offers several unique features. At its core, the Tangle forms a directed acyclic graph (DAG) of blocks, creating a block-DAG architecture. In this structure, newer blocks are intricately attached to multiple older ones, resulting in a highly interconnected data structure.

One of the Tangle’s primary functions is to ensure the immutability of the data contained within it. The Tangle’s distributed nature creates a tamper-proof environment for data integrity. This means that once information is added to the Tangle, it is nearly impossible to change or manipulate, which increases the system’s integrity and transparency. Given that the Tangle is a replicated or distributed data structure, the nodes must agree and come to a consensus on its content.

Unlike blockchains, where only a single node can append a new block to the ledger at a time, the Tangle allows all participating nodes to write to the ledger in parallel. This is achieved through a DAG structure, which allows transactions to be processed simultaneously and independently of each other. Contrast this with traditional blockchains, which consist of a growing list of records called blocks linked together as a chain using cryptography. In standard blockchains, transactions can only become part of the ledger if they are included in a newly issued block, which is mined by a  miner one at a time. If all new transactions don’t fit into one block, some must be postponed to the following blocks. Additionally, block producers typically favor including transactions from users willing to pay higher fees. Accelerating block creation or increasing block sizes doesn’t solve the issues, as it is well known that this would compromise safety. In other words, to guarantee the security of the system, the throughput of the system must be artificially suppressed so that each block propagates fully before the next block is created.

On the other hand, IOTA’s Tangle offers a leaderless and probabilistic consensus protocol that enables parallel validation of transactions without requiring total ordering. It also eliminates the need for intermediary miners or validators in block creation, allowing all participating nodes to write to the ledger. This removes the need for additional mempools (short for memory pool; essentially a temporary storage area for unconfirmed transactions on a blockchain), and the Tangle itself is often seen as a distributed mempool. However, consensus on the state of the ledger is achieved through a committee-based selection process, which ensures low confirmation times.

The Tangle is the cornerstone of IOTA’s technology, providing numerous advantages that are essential for its target applications, especially for enabling the Internet of Things (IoT).

• Parallel Processing: the Tangle allows for parallel processing of transactions. As the number of transactions increases, the network becomes more efficient and faster, addressing the scalability issues that limit blockchain technologies​.
• Microtransactions: The Tangle’s architecture enables feeless transactions, which are vital for IoT applications where devices often need to perform numerous small transactions. This makes IOTA economically viable particularly for environments and ecosystems where the cost of transactions need to be minimal or nonexistent​.
• Distributed Consensus: Each transaction in the Tangle verifies two previous transactions, distributing the consensus mechanism across the entire network. This eliminates the need for miners and central authorities, leading to a more decentralized and democratic system.
• Low Energy Consumption: The Tangle’s design allows for transactions to be validated with minimal computational power, significantly reducing energy consumption compared to PoW (Proof of Work) blockchains. This is crucial for IoT devices, which need to operate efficiently with limited energy resources.
• Tamper-Proof Ledger: The Tangle provides a secure and immutable record of transactions, ensuring that data integrity is maintained. This is particularly important for applications requiring high levels of security and trust, such as supply chain management and smart cities​. The Tangle technology network is resistant to both quantum computing threats and 51% attacks (also known as double-spending attacks).

All things considered, a potential attempt to attack the network would require i) control over a majority of the network’s hash rate, ii) a complete view of the network to distribute the malicious hashing power effectively, and iii) collaboration with a substantial proportion of nodes to propagate the attack successfully.

IOTA Token – $IOTA

$IOTA is the native cryptocurrency of the IOTA network, designed to facilitate the transfer of value within the ecosystem. Since IOTA operates on a unique architecture called the Tangle, which allows for feeless transactions, this means that when a user transfers $IOTA tokens, the entire amount is transferred directly to the recipient without any deductions for transaction fees, making it especially suitable for microtransactions and use in IoT environments.

Transfer of Value:  $IOTA is primarily used for the transfer of value within the IOTA network. The tokens can be used to track and trace goods across supply chains.

Data Anchoring: $IOTA can be used to anchor data on the Tangle. Data transactions on IOTA’s DLT (the Tangle) require a deposit of $IOTA which will be returned when the data is declared obsolete and is no longer kept in the ledger state.

IOTA Identity: $IOTA is used in the management and verification of digital identity on the IOTA network. Through IOTA Identity, users can create and manage self-sovereign identities.

Tokenization of Assets: The Stardust upgrade allows $IOTA to be used in the creation and management of digital assets, including non-fungible tokens (NFTs).

Staking: $IOTA can be staked in various network activities, such as validating transactions or participating in governance decisions. Allowing token holders to influence the direction of the IOTA network and earn rewards for their participation.

Fixed Supply: The total supply of $IOTA is capped, preventing inflation. Unlike many other blockchain networks that continuously mint new tokens to reward validators, $IOTA’s fixed supply preserves the value of tokens over time.

Voting Power: Holding $IOTA tokens provides users with voting power, which is essential for participating in the network’s consensus mechanism and governance decisions.

Utility through Mana: The demand for IOTA tokens is driven by their ability to generate Mana, a resource that is crucial for accessing and utilizing the IOTA ledger. This utility ensures a sustainable demand for $IOTA tokens.

The Coordinator

The Coordinator, a specialized node within the IOTA network, plays a pivotal role in safeguarding and preserving the network’s integrity. In the early stages of the protocol, IOTA’s security model was founded on the assumption that legitimate transactions would vastly outnumber malicious ones. Initially, the network employed Proof of Work as its primary security mechanism. This meant that an attacker commanding the majority of the network’s hashing power could potentially manipulate consensus outcomes. Such an adversary could exploit this dominance to engage in double-spending or network fragmentation.

Given the absence of miners in its DLT, the Tangle, IOTA required supplementary security measures to protect itself against potential attacks and guarantee the accurate processing of transactions. The Coordinator was introduced to address these challenges by:

Ensuring Security: The primary purpose of the Coordinator was to secure the network during its early stages of development. It prevented double-spending and other types of attacks by confirming only valid transactions.

The Coordinator functions by issuing special transactions called milestones. A milestone is essentially a checkpoint that marks a set of transactions as confirmed. Only the transactions directly or indirectly referenced by these milestones are considered confirmed by the network.

IOTA’s Coordinator issuing milestones (in red); with each block referencing two preceding ones.

When a transaction is issued on the IOTA network, it must reference two previous transactions. Once these transactions are confirmed by a milestone, they are considered final and irreversible. The Coordinator was regarded an effective way to safeguard the system in the initial stages of the protocol by protecting the network from potential security threats, such as double-spending attacks

Even though this  mechanism does not give the IOTA Foundation the power to change history or imply that the Foundation can take users’ funds, it is worth highlighting the following:

• The Coordinator may allow the Foundation to choose which transactions receive priority.
• The Coordinator may allow the Foundation to freeze funds, by having milestones ignore transactions that spend them.
• The Coordinator could be a single point of attack and in a situation where the Coordinator stops working or is taken over, confirmations in the network would halt.
• The Coordinator was also a limiting factor for the scalability of the network.

Note that the Coordinator can confirm transactions but it can’t bypass consensus rules. Hence, creating, freezing, or stealing tokens is impossible for it. The Coordinator’s influence on the tangle is limited as the Tangle is continuously monitored by all other full nodes and it will be switched off with the IOTA 2.0 upgrade. This led to the development of Coordicide.

Project History

IOTA 1.0 (Legacy Version)

The IOTA Legacy version refers to the earlier stages of the IOTA network before the significant upgrades introduced with protocols like Chrysalis and Stardust. This version utilized a trinary-based data structure along with the Tangle.

Trinary-Based System

IOTA’s data structure in the legacy version was based on a trinary system, where trinary-based seeds, addresses, hashes etc only consist of characters in the latin alphabet and 9. E.g “9ABCDEFGHIJKLMNOPQRSTUVWXYZ”. This trinary system was fundamental to the IOTA network, influencing how seeds, addresses, and hashes were generated and managed. IOTA seed phrases were 81-characters long and they were crucial for generating private keys and addresses.

In the legacy version, IOTA offered three security levels (1, 2, and 3), corresponding to 81-trits, 162-trits, and 243-trits of security, respectively. Higher security levels required more rounds of hashing, providing stronger protection, especially recommended for exchanges and high-value transactions. A transaction in IOTA’s legacy version was encoded as 2673 trytes. Each transaction included essential components such as the transaction hash, the signature message fragment, the address, the value being transferred, and other metadata like timestamps, trunk and branch transactions, and the nonce.

Bundles

Transactions in the legacy version were grouped into bundles, which were atomic and had the UTXO (Unspent Transaction Output) Model. This meant that all transactions within a bundle had to be accepted together, or none would be accepted. A typical bundle in IOTA’s legacy version could include inputs, outputs, and remainders, ensuring that any unspent balance was returned to the sender.

IOTA 1.5 (Chrysalis Version)

Chrysalis refers to the first upgrade of the IOTA network, implemented in two distinct phases (Phase 1 in August 2020 and Phase 2 in April 2021), that aimed to significantly enhance the performance, security, and usability of the IOTA protocol. This upgrade was essential for transitioning the network from its experimental stage to a more mature and enterprise-ready version, setting the foundation for the eventual Coordicide (removal of the Coordinator) and full decentralization of the network.

Chrysalis Phase 1

• White-Flag Approach: In Chrysalis Phase 1, IOTA replaced its original heavy probabilistic consensus algorithm with the White-Flag approach. This new approach simplifies the confirmation process by ignoring conflicts rather than resolving them through complex calculations, which enhances the scalability and efficiency of the network.
• PoA – Coordinator: The network continued to rely on the Coordinator, a central node that secured the network during its early stages, operating under a Proof of Authority (PoA) consensus model.
• Legacy IOTA Mainnet: This phase was implemented on the legacy IOTA mainnet, marking the beginning of significant upgrades aimed at improving the network’s performance.

Impact:

• Improved Scalability and Efficiency: The White-Flag approach made IOTA more streamlined for transaction confirmations, reducing the computational burden on nodes and enabling the network to scale more effectively.
• Enhanced Network Security: By reducing the complexity of the consensus mechanism, the network became more secure against certain types of attacks.

Chrysalis Phase 2

• Binary Transition: One of the most significant changes in Phase 2 was the transition from a trinary (ternary) to a binary system for data representation. This alignment with conventional binary computing standards improved compatibility with existing hardware and software ecosystems.
• UTXO Model: IOTA moved from an account-based model to a UTXO (Unspent Transaction Output) model, similar to Bitcoin. This change provided greater transparency and traceability of individual transactions, enhancing security and enabling features like atomic swaps.
• EdDSA Implementation: The upgrade also replaced the Winternitz One-Time Signatures (WOTS) with EdDSA (Edwards-curve Digital Signature Algorithm), which offers more efficient and secure cryptographic operations.
• Dust Protection: To prevent the network from being spammed with tiny, insignificant transactions (often referred to as “dust”), Chrysalis Phase 2 introduced dust protection mechanisms. This feature ensured that nodes were not overwhelmed by maintaining an excessive number of small-value outputs.
• Overhaul of APIs: The upgrade included a complete overhaul of all APIs, making the network easier to interact with for developers and improving overall usability.

Impact:

• Increased Performance: The binary transition and UTXO model significantly improved the network’s performance, making it faster and more robust.
• Security Enhancements: The introduction of EdDSA and dust protection mechanisms greatly improved the security of the network, reducing the risk of attacks and ensuring that the ledger remained manageable.
• Developer-Friendly: The updated APIs and improved documentation made it easier for developers to build on IOTA, encouraging innovation and the development of new applications within the ecosystem.

Protocols and Core Technologies

Shimmer

Shimmer Network is the staging network of IOTA, used as a sort of testing ground for new ideas. With an identical DAG architecture, Shimmer Network is a feeless, parallelized DAG (Directed Acyclic Graph) ledger that was built to secure a network of customizable smart contract chains.

As a staging platform, Shimmer grants early access to cutting-edge developments that are battle-tested with real value at stake. Due to its nature, release candidates that withstand the test of time in the Shimmer Network are matured to the status of stable release and ported to the IOTA mainnet. In other words, Shimmer gives early access to new features before they are available on IOTA.

Shimmer Network is a feeless UTXO-based DAG ledger created to allow for scalable multi-chain networks to build and secure blockchains and application ecosystems that are interoperable and composable with each other.

Shimmer allows for unique tokenization features such as native NFT permissionless minting with zero fees. NFTs on Shimmer can also act as wallets, such that NFTs can also own other NFTs or assets. On a similar note, Shimmer also allows for use cases such as extending the ownership and control of Layer 1 assets to Layer 2 smart contract chains.

Other features include a multi-chain and interoperable network where the release of an EVM chain will facilitate the growth of a developer community. This development will enable smart contract chains to have access to the state changes of all other anchored chains, which will offer a competitive advantage in terms of composability in smart contracts across completely different types of smart contract chains.

Shimmer’s permissionless, feeless and miner-less multi-asset ledger competes against other Layer 1 and Layer 2 blockchains by fostering an ecosystem with less constraints and faster speed at the infrastructure level.

• A parallel layer 1 DAG offers time-independent activity, which increases the speed and capacity as more Layer 2s are anchored to the base layer
• Feeless validations of transactions and smart contract state changes. This enables use cases such as running smart contracts on a L2 Smart Contract Chain while retaining the economic control and security of assets on the underlying UTXO ledger
• Bridgeless transfers of assets remove the need for using external bridges and allows for asset transfers with no fees.
• Any L2 asset can be wrapped as a L1 asset and then be feelessly transferred to an address on another L2 chain.
• More complex UTXO output types that allow for running custom logic and unique features such as unlock conditions, timelocks, atomic transactions

Unlock conditions

• Blocks (which stores some small data) specifies outputs (which specifies amount of tokens and their owner)
• Each output has a list of unlock conditions and owning one means it has an Address unlock condition that has your address listed, derived from your seed through a special mathematical function.
• This allows a variety of conditions such as timelocks and expiration times
• Expiration 
• When the expiration time is met, any tokens not consumed are automatically returned to you.
• Timelocks
• Allows you to set a time that prevents your tokens from being moved until it is over

The $SMR token acts as the feeless vessel for economic transactions between L2 chains while adding utility to the L1 chain (since it allows for bridging assets between L2s without paying transaction fees).

ShimmerEVM is the first public Smart Contract Chain that will bring additional utility to the IOTA ecosystem. This will be achieved by running a PoA (Proof of Authority) consensus that will be coupled with random transaction ordering at the protocol level to prevent MEV. Apart from being a fully EMV-compatible chain that will support Solidity smart contracts, it will also be interoperable with other EVM chains.

The feeless and parallelized DAG ledger that powers Shimmer Network was conceptualized to build a scalable and interoperable ecosystem of sovereign blockchains and decentralized applications.

The extended UTXO model of Shimmer enables more complex output types that lead to novel transaction features, atomic operations, and unique use cases. This is also enhanced by the immutable data of the network running on a fully refundable deposit model that facilitates feeless value transactions.

Shimmer Network is the infrastructure layer that will connect every ecosystem chain as an all-encompassing bridge where all transfers from one chain to another will not incur any gas costs while benefiting from the underlying security guarantees.

Multi-Asset Ledger Technology

Shimmer Network and IOTA are the infrastructure layer for the smart contract chains that operate on top of it. The multi-asset ledger technology enables conditional NFT transfers (NFTS can act as wallets), protection of node resources at the protocol level, load-balancing improvements in the network, and the removal of client-side trust assumptions. As the staging platform, all protocol upgrades will be performed on Shimmer first:

• The Chrysalis Upgrade (IOTA 1.5) delivered major improvements in performance, stability, reliability, and security.
• Stardust (the first Shimmer network upgrade) is the middle step between Chrysalis and Coordicide (IOTA 2.0). This upgrade is responsible for enabling smart contracts support on IOTA before the deployment of IOTA 2.0.

Multi-ledger technology improves horizontal scaling and allows for higher levels of throughput by allowing smart contracts to run on top of IOTA. The Stardust protocol will allow digital assets and data to be transferred between smart contract chains, and the IOTA Tangle will supply the trustless infrastructure for interoperability.

IOTA Smart Contracts work as a layer 2 extension of the IOTA Multi-Asset Ledger (Layer 1). The L1 ledger contains balances of the different kinds of assets (base tokens, native tokens, NFTs) that are locked in addresses. These assets can only be moved by unlocking the corresponding address with its private key.

The L1 Ledger is maintained by a series of Hornet nodes (a distributed implementation of IOTA’s multi-asset ledger), while the L2 state is maintained by a committee of Wasp nodes.

Each chain in IOTA Smart Contracts contains its own L2 ledger, which is independent of the L1 ledger. Smart contracts can exchange assets between themselves on the same chain, between different chains, and with addresses on the L1 ledger. The L2 ledger is, therefore, a collection of on-chain accounts to keep track of balance mappings where each account is controlled by a private key.

Currently, the Chrysalis ledger is optimized for payments.  After Stardust, Shimmer and IOTA will be well suited to be the base layer for other chains to operate on top of by allowing for:

• Parallel transaction processing, due the asynchronous nature of the IOTA Tangle and the UTXO Ledger Model.
• Feeless Inter-chain value transfers.
• Special application logic for trustless atomic operations by extending the current UTXO Model.
• Arbitrary data writes into the ledger state (which means that datasets are not pruned by mainnet nodes after some time).

The end goal is to build a modular and composable architecture that allows for use cases such as:

• Full EVM and WASM compatibility.
• Leverage existing tools and frameworks from other existing ecosystems.
• Build novel applications with no MEV (Miner/Maximal Extractable Value).
• Allow developers to tailor the chain infrastructure to the specific needs of their applications.
• Allow for scalability on top of a parallelized base layer.
• Full interoperability between chains deployed on the network.
• Feeless transactions.
• Enhance transaction logic through extended UTXOs.

On–Chain Digital Assets

Each native L1 account in the IOTA UTXO ledger is represented by an address controlled by a corresponding private/public key pair. The UTXO ledger keeps track of accounts as a collection of UTXOs belonging to each address.

Each IOTA Smart Contract L2 Chain has a L1 account called the chain account, which holds all the tokens entrusted to the chain in a single UTXO called the state output. The chain account is controlled by a chain address known as the chain ID, which is a special kind of L1 address that abstracts the controlling entity (the state of the controller address) from the identity of the chain (the controlling entity of the chain may change, while the chain ID stays the same).

Native and Custom Tokens

Native assets refer to L1 assets that can be created out of thin air as long as they fulfill the storage deposit. L2 assets, however, are created on L2s with smart contracts (similar to other blockchains).

Tokens are relevant for a variety of use cases, such as raising capital or decentralizing governance decisions. Since IOTA Smart Contracts (ISC) support the Ethereum Virtual Machine (EVM), they allow for the creation of ERC20 and ERC721 tokens on Layer 2s. Contrary to other networks, Shimmer and IOTA do not require the use of asset bridges in order to move tokens between different smart contract chains. This allows the ecosystem to avoid exposure to bridges, which are usually highly centralized and can be the cause of hacks (see Ronin Bridge Hack).

As an example, fungible tokens are implemented in Stardust using native tokens, which are minted using token foundries. The blockchain account in control of the foundry is referred to as the issuer.

• The issuer can melt tokens in their possession, reducing the total supply
• Token holders can burn tokens, which removes the tokens from the circulating supply, but has no effect in the total supply.

Transacting with native tokens is done via on-chain transfers that can be performed by both smart contract accounts and regular user addresses.

Furthermore, multiple output types are supported for transacting, and a transfer must always include the base currency of the network in order to  cover the network storage (due to IOTA’s storage deposit mechanism which allows for gasless transactions).

The initial version of Stardust supports Simple Token Schemes, which are used to define the supply control rules (what token issuers are allowed to do). A Simple Token Scheme determines the upper limit supply of tokens to guarantee that token issuers cannot inflate the supply beyond that limit.

Shimmer Token

$SMR is the native token of the Shimmer network and serves as its economic backbone. The total supply has been fully distributed to early adopters by staking MIOTA tokens for $SMR tokens. Similar to IOTA, $SMR tokens are used for transactions and have no inflation, meaning their supply is also fixed.

$SMR tokens were distributed to $IOTA holders who staked their $IOTA tokens during special staking periods on the IOTA network. The smallest unit of the $SMR token is called “glow,” with 1 $SMR equaling 1 million glow.

IOTA Smart Contract Protocol

For smart contracts to be able to run on the IOTA infrastructure, IOTA Smart Contract Chains need to satisfy the following requirements:

• Facilitate user interactions:
  • On-ledger requests (originate from the base protocol)
  • Off-ledger request (sent directly to the Layer 2 chain)
• Custom tokens for cross-chain transfers
• A place to store commitments of the Layer 2 chain.
  • Since every smart contract chain is responsible for producing state updates on a block by block basis (every block points to one state), it is necessary to record a cryptographic commitment on the L2 blockchains to trustlessly synchronize its state with the state if the underlying layer 1
• A ledger account with a permanent address that is controlled by a rotating committee to send/receive tokens.
  •  Since each smart contract chain is controlled by a validators set that comes together to produce a common threshold signature address, it is necessary to generate and keep track of unique addresses at the protocol level (since the validator set can change and a new address would be produced). This is achieved by:
    • Generating unique addresses deterministically.
    • Persisting the state and controlling keys across transactions.

 A ledger account is an address directly derived from a secret private key and that allows the owner to sign transactions and verify in the ledger whether the transaction signatures are valid or not.

IOTA Smart Contracts Protocol  (ISCP) is a framework that extends the base Layer 1 DLT and makes it possible to develop scalable and flexible smart contracts on the IOTA ecosystem. This framework allows anyone to spin up smart contract chains that will be anchored to the IOTA Tangle. It offers the following advantages:

• Scaling and fees are leveraged thanks to IOTA’s parallel execution.

• • • ISC allows many chains to be anchored to the IOTA Tangle and lets them execute transactions in parallel and communicate with each other. Because of this, ISC will benefit from higher throughput and lower fees than single-chain smart contract platforms.
    • Since ISC is a level 2 solution, only a committee of nodes needs to spend resources to execute the smart contracts of any given chain (while the rest of the IOTA network remains unaffected by the ISC traffic).

• Custom chains:

• • • Anyone can start a new chain and set its own rules. The chain owner has complete control over the gas fee policy
      • Set the gas price
      • Select which native token to charge
      • Choose what percentage of the fee goes to validators
    • It is also possible to deploy private chains with no public data besides the state hash that is anchored to the main IOTA Tangle.

• Flexibility:

• • ISC is agnostic about the virtual machine responsible for executing the smart contract code. Eventually, all kinds of virtual machines can be supported. For instance, ISC currently supports Rust/WASM – based smart contracts and Solidity/EVM-based smart contracts.

Wasp is the reference implementation of IOTA smart contracts. Multiple Wasp nodes are responsible for forming a committee that will be in charge of a given ISC chain. Whenever a Virtual Machine state change occurs, Wasp nodes must reach a consensus and anchor that state change to the IOTA Tangle in order to make that state immutable.

ISCP architecture enables IOTA Smart Contracts to work as Layer 2 extensions of the IOTA Multi-Asset Ledger (Layer 1, also called the UTXO ledger). In ISC, each L2 chain has its own state and smart contracts. As validator nodes execute the smart contracts, they tally the state changes triggered by these smart contracts and write them into the chain. Therefore, every time there is a state update, validators will collectively agree on the new states and commit to it by publishing the hash to the L1.

This modular architecture provides the advantage that each L2 can function as a sovereign chain while ISC allows for communication between all the L2 chains and with the L1.

Virtual Machines

Virtual Machines are the execution engines that run smart contracts, process inputs, execute the contract’s logic, and update the blockchain’s state. VMs ensure that the contracts operate securely and efficiently. The current release of IOTA Smart Contracts has support for EVM/Solidity smart contracts, as well as experimental WASM (Web Assembly) smart contracts, providing compatibility with existing smart contracts and tooling from other EVM based chains like Ethereum. This allows IOTA to offer the existing ecosystem around EVM/Solidity a familiar alternative.

Sandbox Interface

The Sandbox Interface in smart contracts is a security feature designed to restrict and control the way smart contracts interact with the outside world and the blockchain state.It ensures that smart contracts produce consistent and verifiable results every time they are executed. As an example,  assume a set of smart contracts that were allowed to access external data sources, like a weather forecast website. In that scenario, the outcome of its execution could vary depending on the current weather. This variability makes the contract non-deterministic, meaning that the result could differ with each execution, making it impossible to verify or reproduce. This is where the Sandbox Interface intervenes by restricting smart contracts from accessing external data directly. Instead, they rely on predefined, controlled inputs to ensure deterministic (consistent and reproducible) behavior.

Also, to prevent a single smart contract from interfering with the entire blockchain’s state, if a malicious contract could modify the entire state of the blockchain, it could cause significant harm. For instance, it could alter balances or corrupt data in other contracts. The Sandbox confines each smart contract to its own isolated state, allowing it only to modify a specific part of the blockchain state that it is permitted to interact with. Some key capabilities of the sandbox to ISC (IOTA Smart Contracts) include:

• State Management: Smart contracts can read and write to their own internal state, which is managed as key/value pairs.
• Access to Information: Contracts can access various pieces of information such as:
  • Contract ID: Unique identifier for the smart contract.
  • Request Details: Information about the current transaction or function call.
  • Balances: The amount of cryptocurrency or tokens owned by the contract.
  • Block Timestamp: The timestamp of the current block in the blockchain.
  • Cryptographic Tools: Functions for hashing, verifying signatures, etc.
  • Event Dispatch: Ability to emit events that other contracts or users can listen to.
  • Deterministic Entropy: Generates predictable “randomness” that remains consistent across contract executions, ensuring determinism.
  • Logging: For debugging during the development and testing phases.

• View Calls: These are read-only operations where the smart contract can access its state but cannot modify it. They are limited in scope and cannot issue new requests, emit events, or modify the blockchain state.
• Execution Calls: These allow the smart contract to perform write operations, such as modifying its state, emitting events, or interacting with other contracts.

Validators

Each chain is run by that chain’s validators committee. This committee is the owner of a key that is split between all of its validators. On its own, each of the key shares is useless, but the collective signature from all shares gives validators complete control over the chain.

The validators committee is responsible for executing the smart contracts in the chain:

1.  All validators execute the same code and reach a consensus on the state update.
2. Once the next state is computed and validated, the state will be committed to each validator’s database.
3. A new block containing the state changes will be added to the chain and the state hash will be saved to the Layer1 ledger.

Depending on the Governance model of any given chain, chain owners can rotate the committee of validators in order to add, remove, or replace individual validators.

• ISC does not define how to select validators to form a committee: it could be a decision made by the chain owner or it could be a public competition between candidates.
• ISC does not define how validator rewards are distributed.

The governance and management of validator nodes is done through the governance core contract.

State

ISCP states refer to the snapshots of the smart contract’s data at any given point in time. These states determine the outcome of contract executions and must be maintained consistently across the network. The State Manager component of the ISCP ensures that these states are always up-to-date and retrievable for use by other components, such as the consensus and mempool.

Key Responsibilities of the State Manager:

• State Updates: The State Manager keeps the node’s state current by retrieving any missing data and ensuring it is consistently stored in the database (DB).
• Servicing Requests: It handles requests from other components of the ISCP, like the consensus engine and the mempool, ensuring that the required state is available for processing.
• State Commitment: It commits new states based on incoming blocks, ensuring that each state index nnn corresponds to the commitment of block index nnn on top of state index n−1n-1n−1.

State Transitions and Blocks

A state transition in ISCP occurs when a new block is committed. Each block represents the difference between two consecutive states. Therefore, to create a state index nnn, the system must obtain and commit block index nnn on top of state index n−1n-1n−1. The State Manager handles these transitions by:

• Block Retrieval: Blocks can be obtained directly from the node’s consensus or from neighboring nodes upon request.
• Block Storage: Retrieved blocks are stored in the State Manager’s cache for quick access and in the Write-Ahead Log (WAL) to ensure availability and persistence.

Snapshots

Snapshots are complete dumps of the state of the chain at a particular point in time. They are used primarily for:

• Node Synchronization: New nodes joining the network can quickly catch up with the current state by loading a snapshot instead of downloading all the individual blocks from the genesis block.
• Snapshot Format: Snapshots include key information like state index, state commitment (including trie root and block hash), and the actual bytes representing the block and trie of the state.

Snapshots are periodically created and stored locally or served over the network for new nodes to access. When a node starts, it can load the latest snapshot to initialize its state, significantly speeding up the synchronization process.

Block Retrieval and Commitment

When a request for a specific state is received, the State Manager follows a logical sequence to retrieve and commit the necessary blocks:

• Commitment Chain: The process begins with the most recent state in the database and works backwards, retrieving and committing the necessary blocks until the requested state is achieved.
• Failure Handling: If the required block is not found, the State Manager queries other nodes in the network. If the block is still unavailable, the node may panic, indicating that the request cannot be fulfilled due to missing historical data.

Block Cache and Write-Ahead Log (WAL)

• Block Cache: The in-memory storage for recently accessed blocks. This cache speeds up the process of state transitions by reducing the need to repeatedly fetch the same blocks from the network.
• WAL: The Write-Ahead Log is a file system-based storage that ensures blocks are not lost even if the node crashes before the state is committed to the database. WAL plays a crucial role in maintaining the integrity of the chain, especially during network disruptions or node failures.

Pruning

To manage the database size, old states are pruned regularly. Pruning involves deleting older states from the database while keeping a configurable number of recent states. This process ensures that the DB remains manageable in size while still retaining the necessary data for recent state transitions.

• Archive Nodes: Nodes that require all historical data can disable pruning, resulting in an archive node that retains all states ever obtained by the chain. However, this requires significant storage resources.

ISCP states allow for the correct execution and consistency of smart contracts on the Shimmer network. The State Manager’s role in maintaining these states ensures that:

• Smart Contracts Execute Correctly: By ensuring that the correct state is always available, the State Manager allows smart contracts to execute as intended.
• Network Security: Proper state management prevents inconsistencies and potential vulnerabilities that could arise from missing or incorrect state data.

Smart Contract Execution

Smart contracts lie dormant until someone/something instructs it to do something. Smart contract execution involves running the smart contract’s code on the virtual machine, triggered by user requests. These contracts have entry points, or functions, that either read (view entry points) or modify (full entry points) the blockchain’s state.

Smart contracts are invoked through requests that can be on-ledger (passing through the main ledger) or off-ledger (directly to validator nodes). The type of request determines how the contract is processed and whether gas fees are required for execution.

Accounts, Addresses and Fees

Similar to other Distributed Ledger Technologies (DLT), IOTA supports the trustees and atomic transfer of assets between addresses. Therefore, tokens owned by an address can be transferred to another address by providing a valid signature using the account’s private key. However, it is worth noting the following:

• In ISC, each chain has a L1 address (the chain ID) that enables it to control the L1 assets (base tokens, native tokens, and NFTs). The L2 ledger will act as the custodian of the L1 assets.
• The L2 Ledger is a collection of accounts that can be owned by different entities, each of which will be identified by a unique ID. In fact, the L2 ledger is a mapping of the unique ID to its corresponding balance of L2 assets.

We can classify IOTA accounts into 4 categories:

• L1 addresses (the agent ID of the L1 address) can be the owner of a L2 account, such that tokens in an address account can only be moved by requests that originate from a L1 address signature.

• Smart contract accounts can be the owner of a L2 account (each contract is uniquely identified in a chain by a name followed by the chain ID). These accounts allow for the trustless transfer of assets between smart contracts on the same or different chains. Note that tokens in a smart contract can only be moved by that smart contract.

• • The accounts contract is responsible for managing the L2 ledger and is able to:
    • View the current account balances
    • Deposit funds to the chain
    • Withdraw funds from the chian
    • Move funds from the common account to the chain’s owner account

• The Common Account is the L2 account controlled by the chain owner. This account is used to store funds collected from fees.

• Ethereum addresses refer to L2 accounts that are owned by an Ethereum address. Tokens in an Ethereum account can only be moved by sending an Ethereum transaction that is signed by the same address.

Allowance

An allowance is a feature within smart contracts that controls how much one address can spend on behalf of another address. Before a third party can withdraw tokens from your account, you must explicitly set an allowance for that third party’s address, specifying the maximum amount of tokens they are allowed to transfer. This mechanism is used in various dApps, where you might allow a smart contract to interact with your tokens to participate in staking, lending, or trading activities. The original token owner can adjust or revoke the allowance at any time, providing control over how your tokens are used by others.

Any funds sent to the chain are credited to the sender’s account. If you want a contract to use those funds, you must specify an Allowance in the request. Contracts can then claim any of the allowed funds using the sandbox TransferAllowedFunds function.

Access Nodes

Asides from the nodes of the chain’s committee, it is also possible to have some nodes act as access nodes to the chain. These nodes are not part of the committee of validators but will be connected to the IOTA L1 in order to receive updates from it. Every access node has the following properties:

• Holds a valid state chain on its database.
• Provides access to smart contracts for external callers who may want to query the state of the chain via view calls.
• The peers in the subnet (other access nodes) are connected to each other.
• Can query the state of the chain.
• Can send off-ledger requests directly to the node (instead of sending an on-ledger request as a L1 transaction).

Out of all access nodes in a ISC, some of them are the validator nodes that will participate in the validators committee.

IOTA Smart Contract Chains

IOTA smart contract chains have the following properties:

• Every chain has its own independent ledger.
• The ledger state of the chain users an account-based model (while the L1 uses an UTXO model).
• The chain’s state must be committed in the specific IOTA UTXO ledger account on L1.
• The chain is validated by its own set of validators, which will operate as the committee of validators.
• Each chain can host multiple smart contracts.
• Each smart contract can transact with other smart contracts on other IOTA smart contract chains in a trustless manner.

Consensus

Consensus is a required step for the validators committee to update the chain’s state. More than two third of validators have to agree to change the state in the same exact way. This prevents a single malicious node or a minority of nodes from executing invalid transactions.

Since Smart Contracts are deterministic, all honest nodes will return the same output for the same input values. Each validator has its own point of access to the Tangle and will receive transactions in a random order (due to a random delay caused by the propagation of transactions over the network).

The Consensus is achieved by individual nodes submitting a batch proposal. Each batch proposal contains a local timestamp and a list of unprocessed requests. The rest of the nodes will listen for those transactions and must agree on which batch proposals they want to work on. As long as more than two thirds of nodes are honest, they will manage to find an asynchronous common subset of the batch proposal. When that subset is found, the nodes will then have the same input and will return the same output.

After nodes agree on a common subset from their batch proposal, the raw list of batch proposals is turned into an actual batch where all requests are processed in the same order. Subsequently, the partial signatures of all nodes are combined into a full signature. This full signature is then fed to a pseudo-random function that will sort the smart contract requests (this protects ISC from MEV attacks).

Each of the ordered requests will then be executed by each node, independently producing the same new node. Every node will then craft a state anchor (a layer 1 transaction to prove the commitment to the new chain’s state). This state anchor is then signed by all nodes using their partial keys and exchanging the signatures. This way, every node obtains the same valid combined signature and the same valid state anchor transaction.

In summary, the state update of an ISC chain is the result of a leaderless and  asynchronous procedure where:

• Each validator node queries its own mempool and produces a batch proposal (batch of requests) with its own timestamp and signature by its own private key.
• Validator nodes run a distributed consensus algorithm to reach an agreement on the batch of requests based on batch proposals. This is done by the HoneyBadger Asynchronous Common Set (ACS).
• The output of the ACS is used to calculate the list of requests, which will be deterministically ordered and, therefore, cannot be modified by less than a quorum of validator nodes.
• Each node signs the transaction it calculated with its own private key share and aggregates the partial signatures received from its peers into a final threshold signature.
• All nodes post the final transaction to the L1 node.
• After the state anchor transaction is confirmed on the L1 ledger, it commits the updated state and the corresponding block to the database.

The Tangle Consensus Protocol

The Tangle consensus protocol is based on the premise that the validation of the ledger is done by the users of the ledger themselves, not by miners. Users add transactions to the ledger by validating two already attached transactions and then attaching their transactions into it. The equilibrium point in the consensus comes from the assumption that the optimal strategy for the (honest) user is to attach its transaction so that it maximizes its chances of being picked up by others (and that is only possible if you attach it to the valid ledger).

State Management and Anchoring

The Data State of the chain refers to a collection of key/value pairs that are stored in each node’s database, outside the UTXO ledger.

While smart contract requests are being executed, the virtual state is kept as an in-memory collection of key-value pairs that will be committed once they are stored in the node’s database.

The data state is represented as a state hash (usually a Merkle root), a timestamp, and a state index. Along with on-chain assets, the data state is stored in a single atomic unit on the L1 ledger, the state UTXO.

The concept of anchoring the state refers to placing the hash of the data state into the state UTXO and adding it to the L1 UTXO Ledger. The UTXO Ledger ensures that there is exactly one output for each chain on the ledger at any given time. This output is the state output or state anchor. This anchoring mechanism provides the following guarantees to IOTA Smart Contract chains:

• The state is immutable and tamper-proof
• There is a global consensus on the state of the chain

All updates to the data state occur through mutations of its key/value pairs (each mutation either sets a value for a key or deletes a key). A collection of mutations to the data state is a block. This state transition takes place as an atomic transaction in the layer1 that consumes the previous state UTXO and produces the next one.

On the L1 UTXO ledger, the state’s history is represented as a sequence of UTXOs, each of them holding the chain’s assets in a particular state and the anchoring hash of that state. Furthermore, due to practical reasons, not all transactions might be available at all time, since old transactions may be pruned in a snapshot process. Therefore, the only thing guaranteed is that the tip of the chain of UTXOs is always available (the latest data state hash).

IOTA SDK

The IOTA SDK is a toolset that provides developers with the means to interact with the IOTA and Shimmer networks. The SDK simplifies the process of creating, managing, and interacting with dApps on these networks, leveraging the unique features of the IOTA protocol.

Modules in the IOTA SDK

• Wallet Module:
  • High-Level Operations: The wallet module is designed for ease of use, providing high-level functions that make it simple to perform everyday operations, such as sending transactions and managing accounts. This module is stateful, meaning it maintains a persistent state, which is crucial for operations like tracking balances, managing addresses, and handling transaction histories.
  • Integration with Stronghold: For secure seed handling and storage, the wallet module can optionally integrate with IOTA Stronghold. Stronghold ensures that sensitive information like seeds and keys are securely stored and encrypted, preventing unauthorized access.
• Client Module:
  • Low-Level Flexibility: The client module offers more granular control over how developers interact with the IOTA network. It exposes low-level functions that are typically abstracted away in the wallet module. This module is ideal for developers who need to customize their interactions with the IOTA nodes, such as performing specific types of queries or managing more complex transaction workflows.
  • Increased Complexity: With greater flexibility comes increased complexity. Developers using the client module need to manage more details themselves, such as handling node connections, constructing transactions, and manually managing state.

Programming Language

• Rust: The core IOTA SDK is written in Rust, known for its safety and performance. Rust is particularly suited for developers looking to build high-performance, low-level applications.
• Bindings: To make the SDK accessible to a broader range of developers, bindings are provided for other popular languages:
  • Node.js (TypeScript/JavaScript): Ideal for web developers and those building full-stack applications that integrate with IOTA.
  • Python: Suitable for data scientists, researchers, and developers who prefer a more straightforward, scripting-oriented approach.
  • Wasm: Allows the SDK to be used in web environments, enabling browser-based applications to interact with the IOTA network directly.

Each binding is designed to adhere to the conventions and best practices of its respective language. For example, Python bindings avoid the Builder pattern commonly used in Rust, instead opting for named constructor arguments to align with Pythonic design principles.

Network Interaction

• REST API Communication: The SDK converts developer requests into REST API calls, which are then sent to an IOTA node. This node processes the requests and interacts with the wider IOTA network, whether on the mainnet or testnet.
• Testnet Usage: Developers are encouraged to start with the Public Testnet, which provides a safe environment for learning and experimenting without the risk of losing real funds. The testnet mirrors the mainnet’s functionality, allowing developers to fully understand the SDK’s capabilities in a risk-free environment.
• Test Tokens: Through the Public Testnet Faucet, developers can obtain test tokens to simulate real transactions and other operations without financial risk.

Secure Management with Stronghold

• Seed Management: Stronghold is a security framework developed by the IOTA Foundation that securely manages sensitive information like seeds and private keys. It encrypts this data at rest, ensuring that it cannot be extracted or compromised.
• Encrypted Snapshots: Stronghold uses encrypted snapshots to store sensitive data. These snapshots can be easily backed up and transferred between devices, with access controlled by a password. This ensures that your keys remain secure even if you need to move them to a new device.

Account and Address Management

• Multi-Account Model: The SDK supports the creation of multiple accounts from a single seed. Each account can generate multiple addresses, which are deterministically derived. This model is particularly useful for applications that need to manage multiple users or identities.
• Single Account Model: For simpler use cases, developers can opt to create a single account and manage multiple addresses within that account. This is often used by exchanges or services that need to manage many users but prefer a simpler architecture.

Testnet

• Public Testnet Explorer: The IOTA SDK integrates with tools like the Shimmer Public Testnet Explorer that allow developers to explore the network, view transactions, and analyze data stored on the Tangle. This is useful for debugging, monitoring, and understanding how transactions propagate through the network.
• Test Tokens: Developers can obtain test tokens from the Shimmer Testnet Faucet, allowing them to experiment with transactions and other network features without risking real assets.

The IOTA SDK has several how-to guides that provide step-by-step instructions on various topics and functionalities. You can use these guides to understand and implement specific tasks or features within your application. The how-to guides offer clear and concise explanations, making integrating IOTA functionality into your projects easier.

IOTA Identity

IOTA Identity is a framework designed to implement decentralized identity (DID) standards, offering a DLT-agnostic approach with specific adaptations for the IOTA network. It enables the implementation of Self-Sovereign Identities (SSI) on the IOTA network. This framework is designed to comply with the World Wide Web Consortium (W3C) standards for Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs), ensuring interoperability and security across different systems and networks. It supports the creation and management of digital identities for people, organizations, devices, and objects, acting as a unified layer of trust. IOTA Identity leverages the unique features of the IOTA Tangle, such as feeless transactions and the UTXO model, to offer a scalable and efficient solution for digital identity management.

Decentralized Identity (DID) for Individuals

IOTA Identity allows individuals to maintain full control over their digital identities, enabling them to manage and share personal data selectively and securely. This system addresses issues related to data privacy, digital trust, and compliance with regulations like GDPR (General Data Protection Regulation). The framework allows users to create a singular digital profile, integrating all personal information, and decide how this data is shared and verified, enhancing privacy and security.

Identity for Organizations

Organizations can use IOTA Identity to comply with regulations such as GDPR in a cost-effective way. The framework shifts the responsibility of managing personally identifiable information (PII) from organizations to individuals, reducing the burden on companies to store and protect large amounts of sensitive data. It also enables organizations to issue verifiable credentials for KYC (Know Your Customer) and AML (Anti-Money Laundering) processes, streamlining customer onboarding and reducing fraud.

Identity for Things (IDoT):

IOTA Identity provides devices with unique digital identities, allowing them to prove their capabilities and authenticity. This capability is crucial for the “Economy of Things,” where devices autonomously transact and interact with each other. The framework supports the creation of Digital Twins, virtual representations of physical devices, which can interact securely with other entities in the network.

Decentralized Identifiers (DIDs)

DIDs are unique identifiers that are not tied to a centralized authority. They can represent any entity, such as a person, organization, or IoT device. DIDs are implemented according to the W3C’s DID specifications, ensuring global interoperability.

This DID is a text string containing the scheme, the DID method resolving to a VDR(Verifiable Data Registry); IOTA in our example below), and a unique string within that method.

A DID always includes a public and private key. While the public keys of a DID, which signs credentials are stored on the VDR (i.e. the IOTA DLT), the private key is stored in the holder’s wallet. With this combination, the holder – and only the holder – is able to cryptographically prove that they are the controller of the DID. The identifier is strongly tied to them.

Source: TangleLabs

The DID resolves to a DID Document, which contains public keys and other metadata necessary for identity verification and interaction. This document is stored on the IOTA ledger, ensuring it is publicly accessible and verifiable without relying on a centralized database.

DID Documents are digital files associated with a DID that include critical information such as public keys for verifying signatures, and service endpoints, which are URLs pointing to additional information or services related to the identity.

Verifiable Credentials (VCs)

VCs are digital statements that can be cryptographically verified. They function similarly to physical credentials, such as passports or driver’s licenses, but are more secure and flexible because they are digital and verifiable through cryptographic methods.

The entity that issues the credential is called the Issuer. The entity that receives and holds the credential (e.g., an individual who owns the passport) is called the Holder. The Verifier is an entity that verifies the credential (e.g., a border control agent checking the passport).

On IOTA, the issuance, management, and verification of VCs are conducted through DIDs. The credentials are stored off-chain, while the information necessary for verification, such as the public keys of issuers, is stored on the Tangle.

Verifiable Presentations

A verifiable presentation is the recommended data format for sharing one or more verifiable credentials. It is constructed and signed by a holder to prove control over their credentials and can be presented to a verifier for validation.

For instance, after an issuer creates and issues a verifiable credential to a holder, such as a university issuing a degree to a graduate, the holder stores it securely until asked to present it. A company could then request proof of that university degree: the holder can create a verifiable presentation containing their credential, already signed by their university, and present it to the company to validate. Note that verifiable presentations that contain personal data should, as with verifiable credentials, be transmitted and stored securely off-chain to satisfy data privacy regulations such as GDPR.

Replay Attacks

Replay attacks occur when a malicious actor reuses a previously valid verifiable presentation to impersonate the holder to a different verifier. Since the signature on the presentation remains valid until the verification method is rotated, the replayed presentation could be accepted as legitimate.

To prevent such attacks, verifiers should issue a unique challenge (a random and unpredictable string) for each verifiable presentation request. The holder must include this challenge in the signed presentation. The digital signature ensures that the challenge cannot be altered without invalidating the signature. Therefore, a verifiable presentation without the correct challenge should be considered invalid by the verifier. Holders can also specify that their presentation signatures expire after a short duration, although this should not be the sole security measure, as it might be ignored by some implementations.

Alias Outputs

These are specialized UTXOs used to store DID Documents on the IOTA ledger. Each Alias Output has an Alias ID, which becomes the basis for the DID. The Alias Output can also interact with other Layer 1 artifacts like NFTs and native assets, adding versatility to how identities are managed and utilized within the IOTA ecosystem. The state controller of an Alias Output can update the state metadata, while the governor can change controllers or even destroy the output. This dual-control mechanism enhances the security and flexibility of managing identities.

On IOTA, DID Documents are stored in Alias Outputs on the Tangle. This method ensures that the documents are securely stored in a decentralized manner, accessible by all network participants, and protected by the IOTA network’s security features. These methods within the DID Document contain public key information used to cryptographically prove ownership of the identity. This is crucial for ensuring that only the rightful owner can sign data associated with the DID.

Unlike many other DID frameworks, IOTA Identity does not impose transaction fees for creating or managing identities. Instead, it uses a redeemable deposit system, which makes it more predictable and accessible. Digital identities are always accessible across all nodes in the IOTA network, ensuring that they are available to holders, issuers, and verifiers at all times.

Also, the IOTA Identity framework incorporates multi-level control structures for managing access and updating identities, with mechanisms for key rotation and recovery. All updates are secured through the same protocols that govern the IOTA network, ensuring consistent and tamper-proof identity states.

Applications and Use Cases

• Personal Privacy and Data Management: IOTA Identity is particularly suited for scenarios where individuals need to manage their data autonomously, ensuring privacy while allowing them to participate fully in the digital economy.
• Regulatory Compliance for Organizations: Companies can use IOTA Identity to meet regulatory requirements, reduce the risk of data breaches, and streamline their customer management processes.
• Trust in IoT: By providing devices with secure and verifiable identities, IOTA Identity enables secure interactions within the IoT ecosystem, which is critical for applications like smart cities, industrial automation, and connected vehicles.

Wallets

Firefly

Firefly serves as the main gateway to the IOTA and Shimmer ecosystems, offering a secure and user-friendly interface for managing tokens..Wallets in Firefly are like a bank account and a personalized stock portfolio all in one. In that regard, wallets always belong to a specific profile of your Firefly application. You can view your wallet balance and transactions, send and receive funds instantly, measure your wallet and token value over time, and check your wallet activity by month.

• Built with Rust: Firefly is written in Rust, a programming language known for its strong emphasis on safety, performance, and low memory usage, which contributes to a secure and efficient application.
• Modular Design: The wallet’s design is modular, meaning different functionalities like seed storage, transaction handling, and cryptography are organized into separate modules. This modular approach simplifies the integration of new features and ensures that the wallet can adapt as the ecosystem grows.
• Stronghold Security: Sensitive operations, such as generating addresses and signing transactions, are conducted in isolated memory spaces using the IOTA Stronghold library. This approach minimizes the risk of unauthorized access to private keys or seeds.
• Crypto.rs Integration: Firefly incorporates the Crypto.rs library, which standardizes the cryptographic algorithms used across IOTA Foundation projects. This ensures that the cryptographic implementations are safe, easier to audit, and reliable.

Users migrating from the IOTA Legacy version  will need to use the IOTA Legacy Migration Tool to transfer their funds from the IOTA Legacy network to the IOTA Stardust network.

Bloom

Bloom is a desktop wallet with a focus on security developed by former members of the Firefly team. Bloom supports the IOTA and Shimmer networks, as well as ShimmerEVM in the same application. This means you can seamlessly transfer assets back and forth between Shimmer and ShimmerEVM without other tooling.

• Security: The Bloom wallet underwent a thorough security audit by Auditone, ensuring its reliability and safety.
• Streamlined Identity Verification: Bloom incorporates an identification solution that features a single, reusable KYC event to identify its users across multiple Web3 services, which was developed in collaboration with the IOTA Foundation, IDNow, walt.id and Spyce5.
• Interoperability: Bloom is compatible with Ledger Nano hardware wallets and also enables token, NFT, and data transfers between Layer 1 and Layer 2 chains without bridges, showcasing IOTA’s cross-chain architecture.
• Future Updates: Bloom aims to broaden its appeal even further by expanding its services to encompass Bitcoin, Ethereum, Polygon, and other important EVM L1s and L2s, alongside introducing features like social login for simple sign-up with Web2 OAuth credentials like Gmail or iCloud, cementing its position as a versatile wallet for the wider Web3 community.

The Bloom wallet is available on Mac, Windows, and Linux.

TanglePay

TanglePay is regarded as the first IOTA wallet mobile App. TanglePay is free, audited, secure and open-sourced. This IOTA wallet supports the new Chrysalis network and will be updated consistently to follow the roadmap of the IOTA Foundation.

IOTA Stronghold

IOTA Stronghold is an open-source software library developed by the IOTA Foundation to enhance the security and privacy of digital assets and secrets, such as cryptographic keys. Written in Rust, Stronghold is designed to provide a secure environment for handling sensitive data, ensuring that private keys and other critical information are never exposed to external processes.

IOTA Stronghold was initially developed to protect IOTA Seeds but has since expanded to secure any digital secret. It offers a secure, encrypted environment for storing and managing sensitive information, ensuring that secrets like private keys are never exposed or compromised. One of Stronghold’s key features is its “encrypted-by-nature” design. The records and their file backups are encrypted at all times, even when stored offline. This greatly reduces the risk of offline attacks where data might be accessed without proper authorization. Stronghold forms the security backbone of the IOTA Firefly wallet, ensuring that users’ private keys and sensitive data are securely managed. This integration demonstrates Stronghold’s role in safeguarding the IOTA ecosystem’s primary user interface for managing digital assets.

Stronghold Architecture

Stronghold uses a binary file called a “snapshot” to persist data. These snapshots are encrypted at rest and can be securely transported between different devices and operating systems. When decrypted, the snapshot functions as a vault in memory, where records can be accessed and used without ever being exposed in plaintext. The underlying architecture of Stronghold utilizes the Actor Model, where independent “actors” communicate through messages rather than direct function calls. This model enhances process isolation and security, enabling secure cryptographic operations across different devices.

Client Interface and API:

• Riker Actor Model: Stronghold’s client interface is built using the Riker actor model, allowing asynchronous operations without exposing the internal architecture to the consumer. This design ensures that the system remains modular, flexible, and easy to integrate with other software while maintaining robust security practices.
• Location API: Stronghold provides a Location API that allows users to manage and specify the storage of data within the vault. This API supports versioning and counter-based location management, offering a secure and structured approach to handling sensitive data.

Cryptographic Operations:

Stronghold supports a range of cryptographic operations, such as key generation, encryption, and digital signing, all performed within its secure environment. The library ensures that sensitive data, such as cryptographic keys, are never exposed, and only necessary outputs like signatures or public keys are returned to the user.

Hardening and Security Enhancements:

• Secure Computational Zone: Stronghold employs a secure computational zone that uses process sandboxing and syscall filtering to create a secure enclave for sensitive operations. This approach minimizes the attack surface by limiting the operations that can be performed within the secure zone, further protecting against potential exploits.
• Custom Memory Management: The system uses a custom memory allocator with guard pages, which restricts access to memory segments when they are not in use. This mitigates risks associated with memory-related attacks, such as buffer overflows.

Because of its composability, many exciting applications can be built using Stronghold — not just cryptocurrency wallets. Its low-level engine is use-case agnostic and flexible, the encryption algorithms can be swapped out at any time, composed in new ways, and extended with other parts of virtually any stack.

Here Alice’s wallet (left side) is protected by Stronghold which can be configured however she pleases to watch over the activity in her wallet and prevent dangerous events from taking place.

Alice securely shares her passport information with her travel agent, and because of the way that Strongholds sync with each other, when the travel agent no longer needs the passport data, she can remove his access to it.

Stardust

Stardust, introduced to the IOTA Mainnet in October 2023, is the current upgrade of the IOTA network, that aims to significantly enhance its utility, particularly in preparation for the Web3 era. Building on the foundation laid by the previous version, Chrysalis, Stardust introduces a wide array of new features and improvements that make IOTA more versatile, scalable, and capable of supporting smart contracts, custom tokens, and dApps. The Stardust upgrade transforms IOTA into a multi asset ledger that allows users to create, transfer, and tokenize native assets and NFTs without any fees. It also enables smart contract tokenization and anchoring of L2 chains on IOTA’s Tangle via the IOTA Chains Framework. This makes IOTA a trustless asset bridge between different L2 networks.

Prior to Stardust, only token balances were stored on the IOTA Ledger. However, Stardust expands the ledger’s functionality, necessitating increased data storage. To prevent uncontrollable ledger growth, Stardust implements a data cap for each transaction. This cap is flexible, scaling with the transaction’s token value. In essence, larger transactions can accommodate more data. This mechanism ensures fair distribution of ledger space while maintaining IOTA and Shimmer’s fee-less model. By tying data storage to token value, the maximum ledger size becomes intrinsically linked to the circulating token supply, preventing indefinite data accumulation. This concept is formalized as byte cost.

Byte cost also creates yet another feature of the Stardust upgrade: it automatically prevents anyone from bloating the ledger by issuing spam transactions, all of which require space in the ledger. This feature is known as dust protection. The big advantage with Stardust is that all data secured through a byte cost deposit will become part of the ledger state. This means that, once propagated through the network, all nodes in the IOTA and Shimmer networks will save a copy of the data. The copy will be kept on all nodes and can be accessed from any node. It will not be automatically purged after a set length of time and therefore does not require a Chronicle permanode for a storage solution as in the current Chrysalis version of the IOTA network. The byte cost is an opportunity cost, locking in tokens for as long as a user wants to retain and persist data in the ledger. When the data is no longer needed, it can be removed and the deposited tokens freed up and refunded to the user. No tokens are consumed, paid, or destroyed to retain data over extended periods – they are only locked into transactions as a deposit to prevent uncontrolled ledger bloat.

In essence, storing data for eternity comes at the price of locking tokens as long as the data persists in the ledger. Spamming and bloating the ledger would only be possible if the attacker is willing to pay for it. The Stardust protocol is made up of key components as listed below:

Bridgeless Technology

Stardust implements the IOTA Tokenization Framework, which is designed to be a protocol add-in that enables trustless and atomic cross-chain asset transfers between IOTA Smart Contract chains. The IOTA Tangle, to which all chains are connected, is the bridge.

The IOTA Tokenization Framework makes it possible for anyone, including Smart Contract chains, to create supply-controlled custom tokens directly to the L1 Tangle. This will be the basis for wrapping the assets and creating L1 representations of them. Once this step is fulfilled, the assets can be sent between L2 chains in a seamless and gasless manner.

Multi-Asset Ledger

Through Stardust, IOTA redesigned and extended the Unspent Transaction Output (UTXO) model of the IOTA ledger to transform it into a fully-fledged Multi-Asset Ledger. Any account in the ledger is capable of holding and transferring native tokens that are minted into existence by Token Foundries. This upgrade extends IOTA beyond a simple cryptocurrency ledger into a comprehensive infrastructure capable of supporting a wide range of digital assets. It makes IOTA a well-suited foundation for distributed ledger technology (DLT) networks to operate on.

Native Tokens

These are user-defined fungible tokens minted in token foundries. These tokens are integrated directly into the IOTA ledger and can be transacted with just like IOTA tokens. A user does not need to convert base currency into native tokens. The creator of the user-defined token referred to as the issuer, is in control of the Token Foundry and regulates the minting or burning activity of tokens that belong to the foundry. Anyone can become an issuer and start minting their own tokens. Token foundries let issuers choose an appropriate supply control policy for their use cases. So, depending on the Token Scheme of the foundry, a native token in IOTA might have a dynamic, fixed, or capped total supply.

NFTs on the other hand, are different from native tokens because each token must be unique and must have some immutable data attached to them. Consequently, NFTs are supported on the base protocol level via NFT outputs. Minting an NFT doesn’t require expensive gas fees; all that needs to be in place is the right amount of storage deposit tokens that are 100% refunded after the NFT is destroyed. The issuer’s identity may also be immutably attached to the NFT next to arbitrary data, making it possible to detect counterfeits.

Custom Tokens

Projects can create their own tokens, which can be used for a variety of purposes, such as governance, access to services, or as part of decentralized applications (dApps). These tokens can be moved across different smart contract chains without the need for external bridges, thanks to the Tangle’s built-in interoperability​

Asset Wrapping

The multi-asset ledger allows for cross-chain asset transfers called Asset Wrapping between different smart contract chains connected to the IOTA Tangle.

IOTA Smart Contracts are a layer 2 extension to the base ledger (The Tangle) and are executed in smart contract chains run by layer 2 validators. Since smart contract chains can issue their own native assets that are traceable to a specific smart contract on a specific chain due to IOTA’s Tokenization Framework, a smart contract that handles tokens on the DLT’s second layer (Layer 2) can use the core contract to wrap its tokens into a native asset. It can also unwrap Native Assets (Layer 1) tokens into a Layer 2 representation of said token. This means you can send assets across both Layer 1 and Layer 2 chains. However, if you want to send Layer 2 you will first need to wrap assets to another chain as a native Layer 1 asset.

This mechanism is built into the protocol, eliminating the need for centralized bridges, which are often security risks​.

Output Unlock Condition

Output Unlock Conditions defines how and when an output (a result of a transaction based on its UTXO model) can be unlocked or spent. This adds a layer of programmable logic directly into the transaction layer, making the IOTA ledger more versatile.

Key Conditions:

• Address Unlock Condition: Here, outputs are locked under addresses that can be unlocked via a signature. This specifies that output can only be unlocked by the designated address, ensuring that only the intended recipient can spend the tokens or use the data associated with the output.
• Storage Deposit Return Condition: Due to the storage deposit rules, creating an output with less than the minimum required storage deposit funds is impossible. The new storage deposit return unlock condition allows to specify a return amount that has to be refunded to the sender’s account. Therefore, if one wants to send 1 token to someone but the minimum deposit is 10, they can send 11 tokens to the recipient and await 10 back. There is no cheating; the recipient has to send 10 tokens back if they wish to own that 1 token.
• Expiration Condition: Here a sender sets a deadline by which the output must be used. If the deadline passes without the output being consumed, it reverts to the sender or follows other specified rules, adding flexibility to transaction management​.
• Timelock Condition: Prevents an output from being spent until a specific time has passed. This can be used to delay transactions or synchronize actions across different parts of a dApp or smart contract​.

Output Features

Output Features are additional data elements that can be attached to transaction outputs. These features allow for more complex interactions and integrations with smart contracts and other dApps without affecting the actual unlocking of the output, facilitating a broader range of use cases directly within the IOTA protocol.

Key Features:

• Metadata Feature: Allows arbitrary data to be attached to an output. This is particularly important for smart contracts, as it can carry instructions or parameters needed for contract execution. Smart contract requests make use of it to encode the actual request call data that is only interpreted on L2.
• Sender Feature: The Stardust solution is the Sender Feature. Outputs can explicitly specify their senders, while a transaction validation logic ensures that the sender address is unlocked on the input side of the transaction. Therefore, the owner of the sender address must have agreed to carry out the on-ledger request under their name.
• The Issuer Feature: follows the same address verification logic as the Sender Feature, but it is only available for NFTs. Upon NFT minting, one might attach the issuer identity to the token if ownership of the issuer address is proved by unlocking it in the same transaction. Artists that disclose their issuer identities off-chain protect buyers and traders from fakes.
• Tag Feature: is a small piece of data intended to be used as an indexation tag for the output by custom applications built around the network. It enables outputs to be tagged with a small amount of data intended to be used as an index. It becomes possible to map data (Metadata Feature) stored in the ledger by a specific party (Sender Feature) for a specific purpose (Tag Feature).

Combining the Sender Feature with the Metadata Feature makes it possible to implement data oracles in the ledger with verified sources.

Storage Deposit System

As the ledger size grows, it can strain network resources. Designed to manage and regulate the amount of data stored on the IOTA ledger, the storage deposit system ensures that those who use the ledger’s storage space are also contributing to the network’s resource management. Nodes in any DLT network must have a copy of the most recent ledger to create or verify new transactions. The more user accounts there are, the more disk space is required on nodes to store the ledger state. Since transactions are feeless, a malicious user might bloat the ledger size by creating many accounts with just a tiny amount of funds (dust) on them.

The Chrysalis version already implemented a mechanism that prevents this attack, but not without caveats:

• it relies on the total ordering of transactions.
• it doesn’t consider that users can store arbitrary data in accounts too.

Stardust improves the previous solution and introduces the new storage deposit system. A user rents storage space in the ledger by holding the base currency of the protocol. Any ledger entry (a transaction output) must have a minimum amount of base currency tokens to cover the storage on nodes. The amount depends solely on the size of the ledger entry. The storage deposit is not a fee because it is fully refunded as soon as the ledger entry is cleaned up.

Tangle Improvement Proposal (TIP) Repository

The Tangle Improvement Proposal (TIP) Repository is a central hub for the community-driven process of enhancing the IOTA technology stack. TIPs are formal documents that suggest improvements, new features, or changes to the IOTA protocol. They play a crucial role in the collaborative development of the IOTA ecosystem, allowing community members, developers, and stakeholders to propose, discuss, and implement new ideas.

One of the significant milestones in the TIP repository is the Stardust upgrade. Stardust introduces tokenization and smart contract chain support, along with various other enhancements to the IOTA protocol. The TIP repository includes a dedicated list of TIPs associated with the Stardust upgrade, providing detailed information about the changes and improvements brought by this major update.

The TIP Process

• Proposing New Ideas:
  • Anyone with an idea for improving IOTA can propose it by starting a discussion on the designated TIP Github. This is the first step where the idea is shared with the community to gather feedback, refine the concept, and gauge interest.
• Submitting a Draft TIP:
  • After the initial discussion, if the idea gains traction, the proposer can submit a draft TIP. This draft should follow a specific template and be submitted as a pull request (PR) to the TIP repository.
  • The draft TIP is reviewed by TIP Editors and core developers, who provide feedback and suggestions for improvement. This ensures that the proposal is technically sound and aligns with the overall goals of the IOTA ecosystem.
• Draft to Proposed Status:
  • Once the draft TIP is refined and approved, it is merged into the repository as a “Draft TIP.”
  • The proposer is responsible for driving the implementation of the TIP, including developing a clear plan for how the new feature will be integrated into the IOTA network.
  • After the implementation is ready and has undergone satisfactory testing, the TIP is elevated to “Proposed” status. Proposed TIPs are typically demonstrated on the Shimmer network, which serves as IOTA’s staging network.
• Becoming an Active TIP:
  • A TIP reaches “Active” status when it gains majority support from the network and is fully integrated into the IOTA mainnet.
  • Active TIPs represent officially supported changes or features that have been successfully adopted by the IOTA network.
• Obsolete and Replaced TIPs:
  • Over time, some TIPs may become obsolete or be replaced by newer proposals. These TIPs are marked accordingly to indicate that they are no longer in use or have been superseded by more recent developments.

Detailed documentation and guidelines on the TIP process can be found in TIP-1, which outlines the procedures and standards for submitting and progressing TIPs.

IOTA 2.0

IOTA 2.0, often referred to as Coordicide, represents a significant evolution of the IOTA network, transitioning it from a semi-centralized system into a fully decentralized, scalable, and secure distributed ledger technology (DLT). IOTA 2.0 is built on five core principles designed to establish a decentralized digital infrastructure that supports autonomy and accessibility for users. These principles aim to ensure the security, scalability, and efficiency of the IOTA network.

Five Principles of IOTA 2.0

Accessibility

IOTA 2.0 introduces a model where users and block producers are merged into the same group, allowing all participants to create and add their own blocks to the ledger without paying fees to intermediaries. This concept, referred to as Accessible Writing, is facilitated by IOTA’s DAG architecture, which allows multiple blocks to be added concurrently. This approach enhances digital autonomy by enabling users to interact with the network independently, without relying on centralized service providers.

Parallelism

The IOTA network leverages its DAG-based architecture to enable Parallel Processing, allowing blocks to be created and processed simultaneously. Unlike traditional distributed ledger technologies (DLTs) that process transactions in sequential batches, IOTA processes transactions as they arrive, using a voting mechanism to resolve conflicts post-processing. This method reduces bottlenecks and enhances network performance, making IOTA suitable for high-volume, computationally intensive tasks.

Volume and Velocity

IOTA 2.0 is designed to handle a high volume of transactions quickly. The architecture allows for immediate execution of transactions, bypassing the delays associated with batch processing in traditional blockchains. This design ensures that low-value transactions are processed almost instantly, while larger transactions can be confirmed within seconds. The focus on high throughput is intended to accommodate a large number of users and maintain a rapid user experience.

Social Dynamics

IOTA 2.0 incorporates Social Dynamics by utilizing decentralized identities and accounts that reflect real-world interactions. Each user is provided with a decentralized digital identity in the form of an account interface. These accounts serve as static identifiers for managing interactions with the protocol, such as declaring states, staking, and issuing blocks. This system allows individuals, businesses, and machines to interact on the ledger, facilitating widespread adoption of the IOTA network.

Sustainable Tokenomics

The tokenomics of IOTA 2.0 emphasizes long-term commitment to the ecosystem. The supply of IOTA tokens is fixed, preventing inflation and minimizing fluctuations in token value. IOTA 2.0 introduces Mana, a non-transferable reputation system generated by holding IOTA tokens. Mana is used to access network resources, such as transferring funds or minting NFTs, and determines the user’s share of throughput access. This model incentivizes holding tokens over time, creating a circular economy that favors sustainable growth rather than short-term profit extraction.

Protocol Architecture

The IOTA 2.0 protocol is structured into three main layers:

1. Network Layer: This is the foundation of the IOTA network, where nodes exchange blocks and necessary data. Nodes only need to connect to a limited number of other nodes, forming a peer-to-peer network that enhances resilience and prevents simple attacks.
2. Communication Layer: This layer is responsible for managing how blocks connect to form the Tangle, the directed acyclic graph (DAG) that underpins IOTA. Key functions here include Rate Control and Congestion Control, which ensure that blocks are propagated efficiently and that the network remains functional even under high load.
3. (Decentralized) Application Layer: At the top of the protocol, this layer handles the contents and payloads of blocks. It manages the ledger state and ensures that consensus is reached regarding the inclusion of blocks in the Tangle.

Data Flow

When a block is created and enters the network, it undergoes a series of processes to ensure that it is valid, correctly integrated into the Tangle, and propagated throughout the network. This process is divided into several components:

Parser:

The Parser is the first component to handle an incoming block. It interprets the raw data (bytes) received and converts it into usable information. The Parser also filters out any redundant or invalid data, such as duplicate blocks or blocks with incorrect signatures. The Parser checks for the correctness of various block attributes, including the timestamp, Mana burn (a mechanism to regulate network usage), and the validity of cryptographic signatures.

Solidifier

The Solidifier ensures that each block is “solid,” in the sense that it is fully connected to previous blocks in the Tangle. If a block’s history is incomplete (e.g., missing previous blocks), the Solidifier requests the missing information from neighboring nodes. This is important for maintaining the integrity of the Tangle, ensuring that all blocks are part of a continuous, traceable history. New nodes joining the network use the Solidifier to establish a complete and accurate ledger history.

Booker:

The Booker is responsible for integrating the block into the Tangle and the ledger. It orders blocks and transactions, identifies any conflicts (such as double-spending attempts), and updates the ledger state accordingly. The Booker also interacts with the conflict DAG, where it maps out conflicts that need to be resolved by the consensus mechanism. It ensures that the ledger reflects the correct state after each block is processed.

Scheduler:

The Scheduler manages the rate at which blocks are processed and gossiped (shared) across the network. It queues blocks based on their issuer’s rate limit and selects blocks for further processing to ensure that the network remains fair and operational under load. The Scheduler is a key component of the network’s congestion control, preventing spam attacks by limiting the rate at which blocks from any single source can be processed.

Consensus:

The Consensus module works in parallel with the Scheduler to determine whether blocks are accepted and confirmed. It tracks approval and witness weights (indicators of network support for a block) and flags blocks as confirmed once they meet the necessary thresholds. This module ensures that consensus is reached in a decentralized manner, even as different nodes may initially have different views of the ledger state.

Tip Manager:

Tips refer to blocks that have not yet been referenced by subsequent blocks. The Tip Manager handles the selection of blocks (or tips) that will be added to the Tangle. It manages a pool of tips, removing old or confirmed blocks and adding new ones that have passed through the Scheduler. The Tip Manager is crucial for maintaining the Tangle’s growth and ensuring that new blocks are always referencing recent tips, keeping the network dynamic and up-to-date.

Block Factory

This component is responsible for creating new blocks. It gathers the necessary payloads, selects tips for approval, and assembles the block. The Block Factory also applies the Rate Setter, which regulates the creation of blocks to avoid network congestion. The Block Factory integrates slot commitments (used for determining the correct sequence of blocks) and timestamps, ensuring that each block is correctly formed before it enters the network.

Data Structures

Blocks

A block is a fundamental data structure that serves as a container for information. Each block contains various types of data, such as transactions or tagged data (payloads), and crucial metadata that supports the protocol’s operations.

• Protocol Version: Ensures that nodes apply the correct rules based on the protocol version used to create the block.
• Parents: A list of block IDs that a block references, including “strong” and “weak” approvals, or simply as “Shallow Like Parents” to adjust network consensus.
• Issuer ID: Identifies the node that created the block.
• Issuing Time (Timestamp): The exact time the block was issued, crucial for organizing blocks into specific time slots.
• Slot Commitment: A cryptographic summary that links the block to a specific slot, which is part of the timeline segmentation.
• Signature: A cryptographic signature from the issuer to ensure the block’s integrity and authenticity.
• Block ID: The block’s identity is created by hashing all the data it contains, which makes each block unique and verifiable.

Slots and Slot Commitments

Timelines in IOTA 2.0 are divided into segments called slots. Each slot has a fixed duration, and blocks are categorized into these slots based on their timestamps. This temporal categorization helps in organizing the data and reaching consensus among nodes.

A slot commitment is created by combining different pieces of information through hashing. These pieces of information are:

• Protocol Version denotes the protocol version, increased with each protocol upgrade.
• Slot Index indicates the index of a slot to which the commitment of slot content is committed. The slot with this index is considered committable by the block’s issuer.
• Previous Slot Commitment refers to the commitment of the slot with the preceding slot index.
• Commitment of Slot Content is the hash root of a Merkle tree that contains all commitment elements at the slot’s conclusion.
• Cumulative Weight represents the collective weight of validators referencing a particular past commitment, including the cumulative weight of the previous slot commitment.

Reference Mana Cost (RMC) is calculated from both the slot’s contents and the previous slot’s RMC.

These are cryptographic records of what is included in a slot. Each block includes a commitment to a past slot, allowing nodes to compare their views of the network and reach consensus. Slot commitments also include information about the previous slot’s commitment, forming a chain. In case of network forks, nodes use this chain to determine the correct sequence of slots based on voting power, ensuring that the network remains consistent.

Validation Blocks

Validation blocks are special blocks that determine the confirmation and finality of other blocks. They are exempt from standard congestion control mechanisms, ensuring that validation continues even during high network traffic. These blocks are minimalistic, containing only the essential data needed for validation and lacking the capacity to carry payloads like transactions. This design prevents misuse and ensures that the validation process is efficient and reliable.

Payloads

Payloads are the core data carried within blocks that aren’t validation blocks. These can be transactions, tagged data, or other types of information that need to be processed and stored on the Tangle.

Types

• Transactions: These are the most complex payloads, responsible for value transfer within the IOTA network. The IOTA 2.0 ledger state relies on the Unspent Transaction Output (UTXO) model. The UTXO model defines a ledger state where balances are not directly associated with addresses but with the outputs of transactions. In this model, transactions reference outputs of previous transactions as inputs, which are consumed (removed) to create new outputs. A transaction must consume all the funds of the referenced inputs.

Transactions include several components:

• Network ID: Identifies which network the transaction is intended for (e.g., mainnet, testnet).
• Creation Slot Index: Links the transaction to the slot it was created in.
• Input List and Output List: Define which UTXOs (Unspent Transaction Outputs) are consumed and created by the transaction, thereby updating the ledger state.
• Extra Payload: Optionally, a transaction can include additional data, such as tagged data, to enhance its functionality.

• Tagged Data: A simpler payload type used for storing arbitrary data on the Tangle. It includes:
  • Identifier: A header that identifies the payload type.
  • Tag: A customizable field that can be used to categorize or identify the data.
  • Data: The actual content being stored, which can be any information relevant to the application using the Tangle.

Mana

Mana is an incentive reward resource generated by holding $IOTA tokens. It is utilized for block issuance, access to network throughput, and protection against Sybil attacks. The amount of Mana accrued is proportional to the number of tokens held and the duration they are held.

When a user creates a block (i.e., processes a transaction or performs an action) on the IOTA network, Mana is consumed. The amount of Mana used depends on the network’s congestion levels, which means that in times of high demand, more Mana will be required to perform the same actions. The network’s throughput, or the rate at which transactions can be processed, is allocated based on the amount of Mana a user holds. This ensures that users who hold more Mana can process more transactions or data through the network. Mana is dynamically adjusted based on current network congestion, this ensures the network is not overloaded and that there is a fair distribution of processing power.

How to Obtain Mana

• Holding $IOTA Tokens: The primary method of acquiring Mana is by holding $IOTA tokens in your account. As long as tokens are held, they generate Mana over time, which accumulates in your account.
• Participating in Consensus: Validators who participate in the network’s consensus process by validating transactions also earn Mana as a reward. This incentivizes active participation in securing the network.
• Delegating Voting Power: Users who do not wish to validate transactions themselves can delegate their voting power to validators and receive a portion of the Mana rewards earned by those validators.
• Purchasing Mana: Users can also buy Mana from other holders on the network. This is particularly useful for users who need temporary higher throughput or for those who are unable to hold $IOTA tokens due to regulatory constraints.

Mana Decay

Mana decays over time if the associated $IOTA tokens are sold or transferred. This decay ensures that only active participants who continue to hold $IOTA tokens or actively contribute to the network maintain a high Mana balance. To maintain a high level of Mana, users must continue to hold $IOTA tokens. If tokens are sold or transferred, the Mana associated with them will gradually diminish, incentivizing long-term commitment to the network.

Mana Burn

When a user creates a block (or transaction), they must specify an amount of Mana that will be deducted from their balance. The required amount is determined by the block’s characteristics, such as its size, type, and the current network congestion. The amount of Mana to be burned is dynamically adjusted based on recent network activity. This ensures that the cost of issuing blocks increases during periods of high congestion, discouraging spam and preventing network overload. If a user’s Mana balance becomes negative due to excessive block creation or misbehavior, their account is locked, and their issuer deposit is frozen. This punitive measure ensures that all participants adhere to network rules and maintain fairness.

Mana Calculator

The Mana Calculator allows users to predict how much Mana they will earn based on their token holdings and participation in the network. Each validator and delegator will know how much Mana on average they can expect to receive, and unlike other blockchains where gas fees shoot up due to congestion on the network, users can identify the range of Mana that will be burned to process their transactions. This provides transparency and helps users plan their network activities.

Consensus Model

The IOTA 2.0 consensus model is a sophisticated evolution of the Nakamoto Consensus, originally popularized by Bitcoin, adapted to function on a Directed Acyclic Graph (DAG) structure rather than a traditional blockchain. This model allows every participant to agree on what is stored and valid in the ledger, ensuring consistent views among nodes.

In digital ledgers distributed across several nodes, a core challenge is ensuring all participants agree on the contents and validity of the ledger. IOTA addresses this by building on the Nakamoto Consensus, which traditionally resolves disagreements by favoring the longest or heaviest sub-chain. However, in IOTA 2.0, this concept is extended to a more complex structure— the Tangle, which is a DAG where blocks are interconnected rather than merely sequentially linked.

On-Tangle-Voting (OTV)

Each node contributes to the consensus process. When a new block is created, it references existing blocks in the Tangle, thereby encoding the node’s opinion on the validity of these blocks and the transactions they contain. This mechanism ensures that each block adds to the validity of the blocks it references, forming a cumulative consensus.

Validation blocks, issued by the validator committee, carry votes with weights determined by the selection process. The collective weight of these votes, known as Approval Weight, determines the inclusion of blocks and transactions in the consensus. This method of voting is crucial for maintaining the integrity and security of the network.

Processing Transactions and Conflict Resolution

IOTA 2.0 uses the UTXO model for managing transactions, where outputs are consumed and new ones are generated in corresponding value. This model simplifies tracking the history of funds, identifying conflicts (such as double-spending attempts), and allows parallel processing of independent outputs.

Tip Selection and Tangle Construction

Nodes in the IOTA 2.0 network select which blocks to reference using the Tip Selection Algorithm (TSA). The TSA selects references randomly from eligible blocks, balancing the need for rapid transaction confirmation with the network’s overall structure and efficiency. Tips are selected based on their eligibility, which is determined by their age, time constraints, and whether they belong to the correct slot commitment chain. This ensures that blocks are referenced in a timely and efficient manner.

The TSA dictates the “topology” or structure of the Tangle. The aim is for every node to select the minimum number of references necessary to create a diverse Tangle. This means avoiding any predetermined patterns dictating which blocks are referenced by specific nodes. The TSA is also designed to satisfy the principle that any block should be able to be quickly referenced by all tips; luckily, when nodes choose tips at random, referencing two blocks is sufficient (although the protocol allows for more references if the nodes prefer to do so: more references can enhance Tangle connectivity and confirmation speed).

Consensus Flags and Slot Commitment Chains

Consensus is achieved through consensus flags and slot commitment chains:

• Pre-Acceptance Flag: A block is given this flag when an online supermajority of the committee votes for it.
• Acceptance Flag: A block (or transaction) is given this flag when an online supermajority of the committee votes for it with Pre-Accepted validation blocks. This flag favors liveness and works adaptively fast under all network conditions.

• Pre-Confirmation Flag: A block is given this flag when a total supermajority of the committee votes for it. It signifies a higher level of approval compared to the pre-acceptance flag, but it is raised slowly under bad network conditions.
• Confirmation Flag: A block (or transaction) is given this flag when the total supermajority of the committee votes for it with Pre-Confirmed validation blocks. This flag favors safety and it can be slow under bad network conditions.
• Finalization Flag: A block (or transaction) is given this flag when its commitment is included in another block that gets confirmed.

These flags represent varying levels of confidence in a block’s validity, progressing from preliminary acceptance to final confirmation.

A supermajority, defined as a condition met by either over two-thirds of the online committee members (online supermajority) or over two-thirds of all committee members (total supermajority), plays a crucial role in these processes. This ensures that consensus can be maintained even under challenging network conditions, with online supermajority enabling continuous operation and total supermajority ensuring ultimate security.

Chain Switching Rule

In situations where network disruptions cause nodes to have differing views of the Tangle, the Chain Switching Rule, similar to Nakamoto’s principle in blockchain systems, favors the longest or heaviest sub-chain. Nodes continuously update their slot commitment chains, comparing them against others and switching to the majority chain when necessary. This ensures that, even in the face of network discrepancies, the IOTA 2.0 network can reach and maintain consensus.

Dynamic Allocation and the Scheduler

The scheduler in IOTA 2.0 uses a dynamic round-robin approach to allocate block processing power fairly among users. Each block issuer is assigned to a queue, and the scheduler processes blocks from these queues in turn, based on each issuer’s Mana. The throughput, or blockspace, is divided proportionally among users based on their Mana holdings. This means that users with more Mana have a greater ability to issue blocks, but the round-robin system ensures that all users get a fair share of network resources. Unlike Ethereum, where users must bid with fees to prioritize their transactions, IOTA 2.0’s scheduler eliminates the need for bidding, providing a more predictable and cost-effective environment for transaction processing.

Congestion Control

The mechanism ensures that network resources are distributed fairly among users based on their Mana holdings. This prevents any single user from monopolizing the network, ensuring equitable access for all participants. Users also know in advance how much Mana will be required to process their transactions, finally, IOTA 2.0 maintains a feeless transaction environment by allowing users to generate their own Mana and use it to issue blocks. This eliminates the need for traditional transaction fees and makes the network more accessible and cost-effective.

Why the Project was Created

IOTA was founded in October 2015 by David Sønstebø, Dominik Schiener, Sergey Ivancheglo, and Serguei Popov. Initial development was funded by an online public crowdsale, with the participants buying the IOTA value token with other digital currencies. In 2017, early IOTA token investors donated 5% of the total token supply to support ongoing development and establish the IOTA Foundation.

In 2018, the IOTA Foundation was officially chartered as a Stiftung (or foundation) in Berlin. Its primary mission is to facilitate the research, development, education, and standardization of IOTA technology. The IOTA Foundation is a board member of the International Association for Trusted Blockchain Applications (INATBA). Additionally, it’s a founding member of both the Trusted IoT Alliance and the Mobility Open Blockchain Initiative (MOBI). These associations aim to encourage the integration of blockchain and distributed ledger technologies in regulatory frameworks, the IoT ecosystem, and the mobility sector.

IOTA aims to revolutionize this landscape by offering a lightweight, fee-less, and scalable infrastructure technology. It introduces the Tangle, a novel data structure that diverges from the traditional blockchain model. This innovative approach is designed to facilitate seamless and secure microtransactions between IoT devices, underpinning a future where billions of connected devices can interact effortlessly.

The IOTA Foundation envisions a future built upon a public, openly accessible, and interoperable DLT network – a world that fosters true autonomy, transparency, and safety for all. Its vision seeks to empower individuals to shape their destinies while retaining control over their data and assets – an era of “Digital Autonomy for Everyone”.

In essence, IOTA’s primary goal is to revolutionize the way we think about data and value exchange in the digital age, particularly in the context of the IoT, and to bring the benefits of decentralized technology to a broader range of applications, including those involving governments, institutions, and large enterprises enabling a world where devices can autonomously exchange value and data without intermediaries or significant costs.

Sector Outlook

With artificial intelligence (AI), machine learning, and billions of interconnected devices, collectively known as the Internet of Things (IoT) undergoing a revolutionary transformation in our world today, the hyper-connected future envisions a world where machines are not just passive tools but active economic agents, capable of exchanging data and value autonomously. This shift is paving the way for new economic models and creating unprecedented opportunities for businesses across various sectors.

The Rise of Intelligent, Autonomous Machines

In this emerging landscape, machines equipped with AI and machine learning algorithms are becoming smarter, more autonomous, and capable of making decisions in real-time. For instance, electric vehicles are no longer just modes of transport; they are energy assets that can store power and sell it back to the grid, using smart charging stations as intermediaries. This capability allows for dynamic energy management, contributing to a more sustainable and efficient energy grid.

Similarly, IoT devices are revolutionizing supply chains by enabling real-time tracking of goods from production to delivery. These devices can monitor conditions, optimize routes, and ensure that goods are handled correctly throughout the entire supply chain. This level of visibility and control not only improves efficiency but also reduces costs and enhances customer satisfaction.

Decentralized Ledger Technology and Cryptocurrencies

Parallel to these developments is the rise of decentralized ledger technology (DLT) and cryptocurrencies, which are creating new token economies. These economies are enabling innovative business models and fostering new communities that were previously unimaginable. For example, non-fungible tokens (NFTs) are unlocking new ways to monetize digital art, music, and other creative works, while decentralized autonomous organizations (DAOs) are enabling collective decision-making and governance in a transparent and trustless environment.

Moreover, the tokenization of assets—ranging from real estate to intellectual property—allows previously dormant or illiquid assets to be traded and utilized in new ways. Smart contracts, which are self-executing contracts with the terms of the agreement directly written into code, are further enhancing the automation and efficiency of transactions in these new economies.

Web3 and Decentralized Finance (DeFi)

The advent of Web3, often described as the decentralized internet, is another critical development. Web3 represents a shift away from the centralized platform economy dominated by tech giants toward a more decentralized ecosystem where users have greater control over their data and can directly participate in value creation. Decentralized finance (DeFi) is the first major application of Web3, offering financial services such as lending, borrowing, trading, and earning interest without the need for traditional financial intermediaries.

DeFi is democratizing access to financial services, allowing anyone with an internet connection to participate in the global economy. This has profound implications for financial inclusion, particularly in regions where access to banking services is limited.

The Tangle Versus Blockchains

The Tangle’s Directed Acyclic Graph (DAG) structure is akin to that of a web. Unlike blockchain’s single-file line of blocks, Tangle lets transactions branch out, intertwine, and run parallel. This non-linear architecture is where the Tangle excels. Simply put, the Tangle is built for scalability.  Blockchain’s linear structure on the other hand, while tried and true, still lacks some scalability demands.

Mining on blockchains can be very resource-heavy, slow, and you’re at the mercy of miners who can hike up fees whenever the network’s feeling congested. The Tangle cuts out the middlemen. No miners, no fees. Transactions get verified by the nodes themselves, making every transaction feeless and smooth. Due to that efficiency, when cost and speed are on the line, the Tangle excels. Blockchain’s Proof of Work /Proof of Stake consensus mechanisms and transparent ledger make it highly secure against tampering and fraud. While Tangle provides a higher level of transparency due to its interconnected nature, its security is still evolving. The choice between Tangle and blockchain depends on specific requirements. Tangle’s scalability and cost efficiency make it ideal for applications requiring high transaction throughput and minimal fees. Blockchain’s robust security and transparency make it suitable for use cases where trust and accountability are paramount. Both technologies continue to evolve, expanding their applications and shaping the future of DLTs.

Chains

IOTA EVM

The IOTA Ethereum Virtual Machine (EVM) is a Layer 2 solution running on top of the IOTA network, designed to bring Ethereum-compatible smart contracts to the IOTA ecosystem. This integration allows developers to deploy and interact with Ethereum-based decentralized applications (dApps) on IOTA, benefiting from the scalability, security, and feeless transactions of the IOTA Tangle.

Gas Fees and Block Time:

Similar to Ethereum, gas fees in IOTA EVM are dynamic and depend on current network usage. High-demand periods lead to higher gas prices. The chain owner in IOTA EVM has the authority to set minimum gas fees, providing more control over transaction costs. Unlike Ethereum, though, there is no guaranteed block time. A new EVM “block” will be created only when an ISC block is created, and ISC (IOTA Smart Contracts) does not enforce an average block time. This means that block times are variable; a new block will be created as soon as needed. Additionally,

IOTA EVM includes a special “Magic Contract,” which manages Layer 1 token transfers and ISC functionalities. This contract introduces specific commands, such as isc.send(…) enabling token transfers within the IOTA EVM environment.

Testnet

The IOTA EVM Testnet  is a test environment where developers can experiment with the IOTA EVM without risking real funds. The testnet mimics the mainnet’s functionality but is subject to occasional resets.

IOTA EVM Mainnet

The main operational network for deploying Ethereum-compatible dApps on IOTA. Its base token is $IOTA, a chain ID of 8822 and its transactions, blocks and and verified contracts can be seen on the IOTA EVM Explorer.

For Users

Developers

Web3 builders play a fundamental role in the evolution and expansion of the IOTA ecosystem, contributing to the creation of dApps protocols, and services that run on IOTA’s unique technology stack. As IOTA continues to dominate as a foundational layer for the Internet of Things (IoT) and Web3, the contributions of developers, entrepreneurs, institutions and innovators are more important than ever.

Builders are at the forefront of creating innovative dApps that utilize the feeless, scalable, and secure nature of the IOTA Tangle. These applications can range from DeFi platforms, NFT marketplaces, to IoT solutions, all contributing to the broadening of use cases for IOTA.

With the introduction of the IOTA Ethereum Virtual Machine (EVM), builders have the ability to deploy Ethereum-compatible smart contracts on IOTA, allowing them to port existing dApps or develop new ones that can operate in a fee-free environment while benefiting from IOTA’s unique features.

Enhancing the IOTA Infrastructure

• Building the Foundation: Web3 builders contribute directly to the development of the IOTA infrastructure, including node software, SDKs, and APIs. These contributions are vital for ensuring the network’s robustness, scalability, and ease of use.
• Open-Source Contributions: Many Web3 developers engage with the IOTA ecosystem through open-source projects, enhancing existing tools, creating new libraries, and improving the overall developer experience. These contributions are often recognized and supported by the IOTA Foundation through grants or collaborations.

Driving Decentralized Governance

• Community-Led Development: Builders in the IOTA ecosystem often participate in decentralized governance processes, such as proposing and voting on Tangle Improvement Proposals (TIPs). This collaborative approach ensures that the development of IOTA aligns with the needs and visions of its community.
• DAOs and Governance Models: As IOTA integrates more decentralized governance structures, Web3 builders are instrumental in designing and implementing decentralized autonomous organizations (DAOs) that manage various aspects of the IOTA network and its resources.

Enabling Web3 Integration

• Bridging TradFi and DeFi: Builders are key players in integrating traditional finance (TradFi) with decentralized finance (DeFi) on IOTA, particularly through the development of real-world asset (RWA) tokenization and liquidity solutions. These integrations bring new financial instruments into the Web3 space, broadening the appeal and usability of the IOTA network.
• Interoperability: Builders are also focusing on ensuring interoperability between IOTA and other blockchain ecosystems. By creating bridges and cross-chain solutions, they enable the seamless transfer of assets and data between IOTA and other networks, enhancing IOTA’s role in the broader Web3 ecosystem.

Community and Ecosystem Growth

• Mentorship and Education: Experienced Web3 builders often take on mentorship roles within the IOTA community, helping to onboard new developers and guiding them through the complexities of building on IOTA. Educational initiatives, such as workshops and hackathons, are frequently led by these builders, fostering a strong, knowledgeable community.
• Collaborative Innovation: The IOTA BuildSphere initiative and similar programs provide platforms for Web3 builders to collaborate, share resources, and co-create. These collaborative efforts lead to the rapid development of new projects and solutions, driving the ecosystem forward.

Hornet

Running a Node with HORNET

HORNET is a high-performance, easy-to-install node software written in Go, specifically designed for the IOTA and Shimmer networks. Running your own HORNET node offers several key benefits, including direct access to the network and contributing to its overall security and decentralization.

• Direct Network Access:
  • By running a HORNET node, you gain direct access to the IOTA or Shimmer network. This means you do not have to rely on or trust a third-party node for network interactions, providing greater control and security over your transactions and data.
• Enhancing Network Resilience:
  • Nodes are crucial for validating blocks and processing transactions within the Tangle. By running a node, you help to decentralize the network, making it more robust and resistant to attacks or failures.
• Efficient Use of IOTA or Shimmer:
  • Running your own node allows for more efficient use of IOTA or Shimmer. You have immediate access to the Tangle, which can improve transaction speed and reliability.

Requirements

To ensure your node can handle the demands of network operations, it should meet the following recommended specifications:

• CPU: 4 cores or 4 virtual CPUs (vCPUs).
• RAM: 8 GB.
• Storage: SSD storage for faster data processing and retrieval.
• Public IP Address: Essential for your node to communicate with the rest of the network.
• Ports:
  • 15600 TCP: Gossip protocol port.
  • 14626 UDP: Auto Peering port (optional).
  • 14265 TCP: REST HTTP API port (optional, for API access).

These ports can be configured and customized in the config.json file to suit your network setup.

HORNET is platform-independent and can be deployed on all major operating systems. However, the recommended setup is using Docker to run HORNET, along with INX extensions, secured behind a Traefik SSL reverse proxy. This setup ensures ease of management, security, and scalability.

Configuration Files

HORNET uses two main JSON configuration files:

• config.json: This file contains core configuration settings for your node, including network parameters, API configurations, and storage options.
• peering.json: This file manages the details of node neighbors (peers), which are critical for maintaining a well-connected and stable node in the network.

Before running a node, it’s essential to ensure that your device meets the minimum security requirements. This includes proper firewall settings, secure access configurations, and regular updates to the node software. It’s also crucial to run at least version v2.0.0+ of HORNET, which supports the Stardust upgrade and ensures compatibility with the latest network features.

Enterprises

IOTA offers unique advantages for businesses and enterprises, particularly in scenarios where trust, transparency, and efficiency are critical.

• Data Sharing and Integrity:
  • Secure Data Exchange: If your organization needs to share data with multiple parties while ensuring the integrity and origin of that data, IOTA provides a decentralized trust layer. This is especially useful when your organization collaborates with entities that don’t fully trust each other or when third-party governance and intermediaries introduce significant costs.
  • Audit Trail: IOTA’s ledger ensures that all data exchanges are securely recorded and verifiable, making it ideal for industries that require a transparent audit trail.
• Feeless Transactions and Micropayments:
  • Efficient Transactions: IOTA’s feeless cryptocurrency makes it perfect for business models where transaction speed and automation are crucial. For example, businesses that deal with micropayments or have high transaction volumes can significantly reduce costs associated with transaction fees.
  • Automation: With IOTA, organizations can automate payment processes, ensuring quick settlements and reducing the need for intermediaries.
• Global Data Infrastructure:
  • Open and Accessible: IOTA offers a globally available data infrastructure that businesses can connect to directly, facilitating seamless data and payment exchanges between partners worldwide.
  • Trust Between Unknown Parties: IOTA acts as a layer of trust in transactions involving unknown parties, making it suitable for global trade and supply chain operations.
• Supply Chain Transparency:
  • End-to-End Tracking: IOTA allows businesses to document every step in their supply chain in a non-manipulable way, enhancing trust in the products. This transparency can be crucial for industries like manufacturing, where tracking the origin and journey of materials or products is essential.
• New Business Opportunities:
  • Innovative Use Cases: IOTA’s architecture supports a variety of innovative use cases, including unique identification of people and machines, secure real-time transactions, and micropayments. These capabilities can open up new revenue streams and business models for enterprises.
  • Industry Applications: Businesses across various sectors, including IoT, Industry 4.0, smart cities, transportation, and healthcare, are already leveraging IOTA’s capabilities to innovate and streamline operations.

Institutional and Government Applications

IOTA is also tailored for institutional and government-related product development. The IOTA Foundation has built a reputation for working closely with large organizations and governments, introducing them to Distributed Ledger Technology (DLT) and helping integrate it into their operations. This makes IOTA an attractive platform for developers working on projects that require a blend of Web3 innovation and traditional organizational infrastructure.

Economics

Business Model

The IOTA Foundation is a non-profit organisation responsible for the research, development, and maintenance of IOTA. It doesn’t have a traditional business model like a company selling products or services. Instead, it operates an infrastructure where profitable business can rely and develop innovative projects on.

Operating Expenses

Operating expenses in the IOTA ecosystem cover a wide range of activities essential for maintaining and growing the network. These expenses typically include funding for development, infrastructure, community outreach, marketing, research, and partnerships. A significant portion of these expenses is supported through decentralized initiatives on the Tangle Treasury.

The Tangle Treasury acts as a community-managed fund, where members of the IOTA and Shimmer ecosystems can propose projects or initiatives that require funding. By submitting these proposals, community members can seek financial support for various activities, ranging from technical development to educational programs, all aimed at enhancing the overall ecosystem.

While the Treasury plays a crucial role in fostering development within the ecosystem, it is important to note that while the Tangle Treasury and the IOTA Foundation work closely together and support each other’s initiatives, they operate independently and the Tangle Treasury is not an official representation of IOTA.

Tokenomics

$IOTA is feeless,  a user will not have to pay any fees. So, if you send 10 $IOTA to another user, they get exactly 10 $IOTA, with no deductions.

There is a maximum of 4.6 billion IOTA tokens available. This is the total amount that can ever exist. These tokens are divided into even smaller units called “micros,” with 1 $IOTA being equal to 1,000,000 micros.

Supply and Changes with Stardust Upgrade

Originally, there were about 2.78 billion $IOTA tokens. However, with the Stardust upgrade on October 4, 2023, the total number of $IOTA tokens were increased to 4.6 billion. This upgrade was not just about increasing the supply but also about aligning IOTA with common standards used in other digital currencies.

Token Distribution

With the IOTA Foundation: 7.075%, Tangle Ecosystem Association: 12%, UAE Entity: 12%, Contributors: 5% and an IOTA Airdrop: 3.5%

Before the supply increase, all $IOTA tokens were already out there in circulation, with no new tokens being created. Even with the recent increase, IOTA still doesn’t have ongoing inflation like some other cryptocurrencies, where new tokens are continuously created. The current increase will result in about 12-13% inflation over the next four years, but this is a one-time adjustment.

Governance

The governance system in IOTA, supported by the IOTA Foundation, is implemented across both the IOTA and Shimmer networks to act on community-driven decisions.

IOTA and Shimmer

Community-Driven Discussions and Proposals:

• Open Discussions: Governance in IOTA begins with open discussions fostered by the community, particularly within the IOTA and Shimmer Discord channels. Community members are encouraged to participate in these discussions, which occur regularly and are essential for brainstorming and developing governance systems and tools. Weekly meetings are held every Thursday at 4 pm CET, where any community member can join to contribute to these important discussions.
• IOTA/Shimmer Governance Forum: This forum is the central hub for discussing specific proposals. It serves as the first stage in reaching community consensus through soft consensus polling. Discussions here are crucial as they shape the proposals that may eventually be voted on by the entire community.

Structured Governance Process

The governance process in IOTA and Shimmer is structured into three distinct phases, each critical in ensuring that proposals are thoroughly vetted and agreed upon by the community before implementation.

• Phase 1: Open Discussion:
  • In this phase, any community member can submit a proposal to the Governance Forum. The proposal is then discussed openly, allowing for feedback, suggestions, and revisions. Proposals that garner sufficient support, indicated by likes or votes, move to the next phase.
• Phase 2: Temperature Check:
  • During this phase, the proposal is refined into its final form. It includes a detailed explanation of the proposed changes, their reasoning, and implementation specifics. A one-week poll in the forum allows active members to decide whether the proposal should proceed to the final voting stage.
• Phase 3: On-Chain Voting:
  • The proposal is uploaded to nodes within the IOTA or Shimmer network and displayed in the Firefly Wallet. Token holders can then cast their votes, deciding whether to accept or reject the proposal. The voting process is decentralized and secure, leveraging IOTA’s protocol features to ensure transparency and integrity.

On-Chain Voting Mechanism

The on-chain voting mechanism is a cornerstone of IOTA’s governance system, ensuring that all token holders can participate in decision-making. This process is facilitated by two main components:

• Hornet-INX Participation Plugin: This plugin is activated in Hornet nodes and enables node operators to participate in the decentralized counting and verification of votes. The voting process is time-based, meaning that the longer tokens are committed to a vote, the more weight that vote carries.
• Firefly Governance Functionality: The Firefly Wallet includes a comprehensive governance dashboard that manages all voting activities. Users can allocate their tokens as voting power and participate in ongoing votes. The governance dashboard also displays the different phases of a proposal, from its announcement to the final vote tally.

Governance Framework

The governance processes in IOTA and Shimmer are outlined in the Shimmer Governance Framework, which has been developed through extensive community discussions. This framework defines:

• Stakeholders and Roles: It identifies who the stakeholders are in the governance process and what roles they play. This ensures that every participant understands their responsibilities and the scope of their influence.
• Proposal Structure and Rules: The framework specifies how proposals should be structured, the rules for submitting and discussing them, and how they progress through the governance phases.
• Scope of Governance: It outlines what aspects of the IOTA and Shimmer networks are subject to governance and how decisions in these areas are made.
• Polling and Voting Rules: It sets the rules for when and how polls and votes occur, ensuring that the process is fair and transparent.

On-chain governance allows decentralized networks like IOTA to evolve and adapt based on the collective will of their participants. By enabling token holders to vote on key issues directly on the Tangle, IOTA ensures that decisions are made in a transparent and democratic manner. This approach removes central points of control and aligns the network’s evolution with the interests of its community.

Governance Voting Process in IOTA

The governance voting process in IOTA is divided into several distinct phases, each designed to ensure that votes are cast, counted, and verified securely and transparently.

Proposal Announcement:

• Governance proposals are first announced and published on a public platform such as GitHub. These proposals detail the specifics of the issue being voted on.
• Node operators running Hornet nodes with the Participation Plugin can activate these voting ballots, enabling the network to recognize and count votes related to the proposal.

Voting Open:

• The voting period opens once a predefined milestone on the Tangle is reached, marking the start of the voting phase.
• During this seven-day period, token holders can cast, change, revoke, or redo their votes using the Firefly Wallet. Votes are associated with the number of IOTA or Shimmer tokens the voter allocates for the governance decision.
• It’s essential for voters to cast their votes early in this phase to maximize the impact of their voting power, as changes in opinion after the counting phase begins will not retroactively alter the vote count.

Counting Start:

• After the voting period closes, the network begins counting votes. Each vote gains weight based on the time the associated tokens have been held at the designated address. The longer the tokens remain at the address during the counting period, the more weight the vote accumulates.
• This mechanism ensures that votes cast by long-term token holders carry more influence, discouraging short-term speculation or manipulation of the voting process.

Counting Stops and Results:

• Once the counting phase ends, the network stops accumulating votes. Nodes then produce and verify the final results, which are made publicly available through the network’s API.
• The decentralized nature of this process ensures that no single entity controls the outcome, and all participants can independently verify the results.

Voting Mechanism

The voting mechanism utilizes the protocol’s ability to issue value transactions with attached metadata. To participate in voting, the user must define the amount of $SMR that should be used for governance votes, which represents their voting power, for each wallet associated with their Firefly profile. The tokens that represent the voting power will be sent to a new output (UTXO) at the same address (i.e., the users send the tokens to themselves) using the Manage Voting Power function in the Governance section of Firefly.

This Governance Output to which the tokens are allocated will now be used for all governance votes of this wallet. The voter can decide to vote on all kinds of governance questions with the allocated voting weight. Whenever a vote is cast, it uses the tokens stored in the Governance Output for a transaction. To reiterate, the user sends the tokens to themselves, to the same output, using the same address.

During this transaction, metadata that includes the ballot event ID, question ID, and answer will be attached to the UTXO where the tokens reside. This immutably writes the metadata onto the UTXOs of this address in the Tangle. So, after the voting transaction is complete, the tokens will still reside at the same address as before, but now they will have attached metadata representing the voter’s opinion for the referendum.

The result will be produced and verified decentralized through every node participating in the counting. Each node can make the current and final result of its counting publicly available through an API endpoint. After the Counting Start phase begins (the milestone in the Tangle that has been designated as the starting point), the number of votes will be tallied for every milestone where tokens are recognized on a UTXO with the attached voting metadata. The community has determined that 1000 Glow (0.001 $SMR) represents one vote per milestone in Shimmer and 1000 Micros (0.001 $IOTA) represents one vote per milestone in IOTA.

Examples for Shimmer is also very similar to IOTA:

A vote using an amount of 1 $SMR for an option will be counted as follows:

• Since 1000 Glow represents one vote, a vote with one million Glow (equal to 1 $SMR) will result in 1000 votes per milestone.
• The counting occurs at every milestone of the “counting period, meaning that:
• 1000 votes are counted at the first milestone.
• 1000 votes are counted at the second milestone.
• 1000 votes are counted at the third milestone, and so on.

Let’s assume that the counting period lasts for 1,500 milestones: The method described above updates the nodes’ voting database every time a new milestone is reached. For instance, if a voter uses 1 $SMR token in a vote, after 10 milestones, they would have gained 10,000 votes. After 100 milestones, the accumulated votes would be 100,000; after 1,500 milestones, the total counted votes would reach 1.5 million.

This counting mechanism also means that the token’s Vote vote-holding time greatly influences the result. Votes gain “weight” based on the time they are kept on an address during the counting phase.

This is a crucial security feature of the voting mechanism that rewards long-term token holders and punishes voting speculators or attempts to buy votes. This is achieved by requiring voters to lock their capital over a longer period and making any attempt to buy votes a speculative risk due to the potential volatility of the Token price during the seven-day counting phase.

Weighting Votes

The mechanism inherently rewards long-term token holders who maintain their vote throughout the counting phase. This discourages speculative behavior, such as trying to influence votes by buying tokens temporarily. Since the votes accumulate over time, those who commit their tokens for the entire period have more influence.

A user can start voting at any time, stop, or even switch your vote to another option during the counting phase. However, doing so impacts the total number of votes attributed to each option, as votes are only accumulated while tokens are held in the vote. Users retain full control over their tokens during the voting process, allowing them to change their voting preferences without losing access to their tokens. This design promotes security and flexibility, ensuring that token holders can respond to changes in the voting process without losing their voting power.

Tangle Treasury

Tangle Treasury is a community-driven initiative designed to support the IOTA and Shimmer ecosystems through funding and governance. It operates as a decentralized autonomous organization (DAO), allowing community members to propose, discuss, and vote on various projects and initiatives that aim to enhance the IOTA ecosystem. However, it is important to note that the Tangle Treasury does not officially represent the IOTA Foundation.

Key Components of Tangle Treasury:

• Treasury Committee:
  • The Treasury Committee plays a crucial role in overseeing the grant allocation process. This committee is responsible for reviewing proposals, ensuring they align with the broader goals of the IOTA and Shimmer ecosystems, and managing the distribution of funds. The committee members are chosen by the community, ensuring transparency and community representation in decision-making.
• Proposal Submission and Voting:
  • Community members can submit proposals to the Tangle Treasury. These proposals can range from technical developments, community projects, to educational initiatives. Once a proposal is submitted, it goes through a review process by the Treasury Committee before being put to a community vote. The voting process is designed to be inclusive, with decisions made based on the collective input of the IOTA community.
• Request for Proposals (RFP):
  • The Tangle Treasury also issues Requests for Proposals (RFPs) for specific projects or areas of development that the community has identified as high priority. These RFPs invite experts and developers to submit proposals that address these specific needs. The RFP process helps direct funds towards critical areas that require immediate attention or innovation.
• Governance and Transparency:
  • The governance of the Tangle Treasury is managed through a combination of community participation and structured oversight by the Treasury Committee. This ensures that all decisions are made transparently and with broad community support. The Treasury also regularly updates the community on its activities and decisions, maintaining a high level of transparency.

Team

The IOTA Foundation is led by Dominik Schiener (Chairman of the Board of Directors & Co-Founder)  and features a diverse team of experienced professionals and advisory members with backgrounds in computer science, cryptography, software development, and business operations. It is a German-based non-profit organization with over 130+ team members distributed across 25+ countries globally.

Some of the team members include:

The Board

Dominik Schiener, Chairman & Co-Founder:

• Dominik Schiener is an Italian entrepreneur, co-founder, and chairman of the IOTA Foundation. He oversees partnerships and the overall realization of the project’s vision. Dominik is a seasoned blockchain expert who has been actively involved in the space since 2013, with a notable career spanning multiple startups, including Fileyy, Bithaus GmbH, and Finhaus Ltd., before co-founding the IOTA Foundation, where he currently serves as chairman, and has also won awards and invested in innovative projects like CargoChain and CredX.

Serguei Popov, Supervisory Board Member:

• In 1994, he received his Diploma from Moscow State University for the Department of Mathematics and Mechanics. He graduated from and attained his Ph.D. in the Department of Mathematics and Mechanics at the Moscow State University under the supervision of Professor Mikhail Menshikov, in 1997.
• Serguei authored the initial whitepaper on the IOTA’s Tangle, which laid the foundation for the IOTA vision. He was also a driving force behind the IOTA Foundation’s research department.

Dr. Navin Ramachandran, Supervisory Board Member:

• Co-founder of OpenCancer and PEACH. Medical doctor, educationalist and information researcher.
• serves as a Member of the Board of Directors at the IOTA Foundation, where he brings his expertise in business, technology, and innovation to help shape the organization’s strategy and direction.

Luca Moser, Board Member:

• Luca Moser has been involved with IOTA since its early days and has played a crucial role in shaping the project’s direction and strategy.
• Luca Moser is a strong advocate for decentralized technologies and has spoken at various conferences and events, sharing his insights on the potential of IOTA and distributed ledger technology to transform industries and society.

Jan Misselwitz, Board Member:

• 10+ years of international experience in tech startups and commodities trading
• Proven track record of driving growth, performance, and profit
• Expertise in operations management, business strategy, budgeting, and financial management

Below is an inexhaustive list of more team members:

• Alexander Sporn – Head of Engineering.
• Jens Lund-Nielsen – Head of Global Trade & Supply Chain.
• Lucas Tórtora – Head of Developer Experience.
• Tom Jansson – Head of Legal & Regulatory Affairs.
• Carola Dierkes – Head of People & Culture.
• Levente Pap – Engineering Team Lead
• Dr. Bing-Yang Lin – Senior Applied Research Engineer.
• Daria Dziubałtowska – Applied Research Engineer.
• Dave de Fijter – Director of Engineering – Smart Contracts.
• José Manuel Cantera Fonseca – Technical Analyst & Project Lead

Project Investors

Initial Coin Offering (ICO)

IOTA conducted an online public crowdsale as an ICO in December 2015, raising approximately $500,000. The ICO price was set at $0.00059 per $IOTA. During this ICO, all the tokens were sold without any lock-up period, and it played a crucial role in initially funding the IOTA project.

Bosch

In December 2017, Robert Bosch Venture Capital GmbH (RBVC), the corporate venture capital company of the Bosch Group, made a significant investment in IOTA by acquiring IOTA tokens. However, the specific amount Bosch invested in IOTA was not publicly disclosed.The collaboration was aimed at elevating the technology’s adoption and pushing the IOTA ecosystem forward.

Funding Round

In Q4 2021, IOTA raised an $100 million through a funding round. This round included several notable investors, such as HTX Ventures (formerly Huobi Ventures) and Signum Capital and other Asian based venture capital firms and hedge funds like LD Capital, HYperchain Capital and Du Capital participated in the investment. This funding was aimed at further development and scaling of the IOTA ecosystem.

Community Links

• Website: IOTA Website
• Wallets:  Firefly  | Bloom | TanglePay
• IOTA Mainnet Explorer
• Docs: IOTA Wiki
• Whitepaper: The Coordicide
• Papers: IOTA For Business
• Research: IOTA Research
• IOTA Governance Forum
• X: IOTA
• Discord: IOTA Discord
• Youtube: IOTA Youtube
• GitHub: IOTA GitHub