The IOTA Ecosystem DLT Foundation is based in the Abu Dhabi Global Market (ADGM) in the United Arab Emirates. Its purpose is to support and promote the IOTA and Shimmer ecosystem and the adoption of IOTA and Shimmer in the Middle East, Africa, and Asia, by providing funding and support to projects, driving utility to our base layer through RWA tokenization. As such, it will support local growth and regional activities by growing awareness around DLT, IOTA, and our ecosystem; onboarding, supporting, and funding builders and developers; supporting integrations, partnerships, and ecosystem adoption; and introducing DLT public infrastructure.
While the IOTA Foundation is primarily focused on developing the core IOTA protocol, other entities help support the ecosystem around IOTA and Shimmer technology. In June 2022, the Tangle Ecosystem Association was founded in Switzerland to support ecosystems in Europe and America.
Now, as announced at the end of November, the IOTA Ecosystem DLT Foundation has been founded in Abu Dhabi, United Arab Emirates (UAE). This strategic move signals a decisive push to foster and bolster the IOTA ecosystem across the Middle East, Africa, and Asia.
The recent approval of the IOTA Ecosystem DLT Foundation as the first regulated Distributed Ledger Technology (DLT) foundation under the Abu Dhabi Global Market (ADGM) Authority makes it the first fully regulated crypto foundation in the UAE. This endorsement underscores the IOTA Foundation’s commitment to regulatory compliance, with an audit of its tokenomics conducted by Zokyo, a leading cybersecurity company specializing in digital assets, and its dedicated division, Zokyo Econ Lab. Notably, Zokyo is the first auditor to set up an auditing framework based on the standards set by ADGM.
Why the UAE? Global expansion and collaboration
Expanding our footprint into new regions is key to IOTA’s growth. While crypto is a global and remote-first industry, it’s important to collaborate with regulators and have a presence on the ground. This is not only to secure a sound legal footing but also because IOTA’s targeted use cases, spanning global trade and supply chains, the circular economy and sustainability, public goods and infrastructure, tokenization of real-world assets (RWA), and more, are directly related to real-world applications. The IOTA Ecosystem DLT Foundation can supercharge our efforts to empower new businesses and use cases in the UAE, the Middle East, and around the globe.
The UAE is a rapidly growing market focused on innovation and technology. One of the largest Web3 hubs in the world and the ideal gateway to the Middle East and South East Asia, it has close trade relationships across the Middle East and North Africa (MENA), India, China, and beyond. The UAE has recently made visionary investments in blockchain, smart cities, and the Internet of Things (IoT) and is positioning itself as a leader in sustainable development, crypto, and Web3. According to Fortune, “Abu Dhabi and Asia show crypto is charging ahead”.
At the same time, the UAE is laying the foundation to become a pre-eminent force in the global crypto economy through regulation and legislation. The challenges stemming from regulatory uncertainty are frequently cited by projects in our ecosystem and beyond as the number one roadblock that hinders development. ADGM’s Distributed Ledger Technology Foundations Regulations 2023 is the most advanced and flexible regulation in the crypto space so far and we’re happy that it has received significant input from the global DLT industry. The introduction of token holder governance in a solid legal framework that establishes a legal entity for DLT projects is a milestone for the global regulation and acceptance of DLT.
The work being done in the UAE to remove regulatory bottlenecks is key to ensuring continuous progress of our emerging ecosystem and a major opportunity to speed up the adoption and growth of IOTA and its ecosystem applications.
Other ecosystems have had to set up their companies under opaque conditions and in subpar jurisdictions and are now faced with the consequences of this. Being part of the ADGM crypto ecosystem from the start, and enabling ecosystem projects to set up local operations, will enable us and our partners to get the setup phase right.
Foundation goals: long-term value growth and ecosystem development
The IOTA Ecosystem DLT Foundation will be seeded with 552,000,000 $IOTAs (equivalent to over 200 million US dollars), constituting 12% of the total supply that will be released over four years.
Embracing an ecosystem-of-ecosystems approach, the IOTA Ecosystem DLT Foundation’s core mission is not to directly build products and applications but to create an environment conducive for others to do so, offering support along the way.
The IOTA Ecosystem DLT Foundation will mainly focus on the following areas:
Education and events: Content, workshops, and collaboration with universities and researchers will raise awareness of DLT and the IOTA technology stack and use cases. The focus will first be on the underlying technology and frameworks, helping developers expand their skills, before shifting to use cases built on top of IOTA to inspire budding entrepreneurs and enterprises. The end goal is to grow the number of pilot projects, proofs-of-concept, and business incubated on top of the IOTA network.
Business development and partnerships: The aim is to connect existing ecosystem teams and builders in the UAE while fostering new relationships with start-ups, enterprises, universities, and government agencies. These relationships will feed back into efforts to connect existing ecosystem projects with local and regional players, strengthening the ecosystem and facilitating the growth of startups and projects building on top of the technology stack. The regulatory framework provided by ADGM means the UAE is the ideal sandbox environment for realizing pilots and rolling them out in real industry contexts.
Builder support and funding: These will incubate and grow new projects leveraging IOTA. Activities will primarily focus on helping individual developers, entrepreneurs, and young startups grow, and supporting them from the ideation stage to being sustainable, standalone businesses. This will be done through grants or direct investment support into these projects.
Regulatory advice and support: Over the past years, we’ve worked with governments and regulators globally, inputting on proposed legislation and regulation and developing pilot projects that showcase the potential of DLT-based applications spanning government services, identity, and other areas. The IOTA Ecosystem DLT Foundation will become a trusted advisor to regulators, shaping regulatory frameworks to maximize adoption and impact, and bridging relationships between UAE and EU institutions to develop an operable global regulatory framework for the DLT space.
Public DLT infrastructure: IOTA provides public goods and infrastructure to governments and businesses around the world that can be used to create secure, transparent, and efficient systems for a variety of applications. These include a) Supply chain infrastructure like TLIP (Trade Logistics & Information Pipeline), for which a neutral governing body in the UAE will be set up; b) Digital identity platforms like IOTA Identity 1.0 that manage complex certification systems and give digital autonomy and borderless ID to people, entities, and things, which will be rolled out with businesses and governments in the UAE; and c) Government infrastructure for enhancing inter- and cross-border services, similar to the European Blockchain Services Infrastructure (EBSI), of whose pre-procurement phase IOTA is among the three finalists.
Real-world asset tokenization:The IOTA Ecosystem DLT Foundation will help incorporate real-world asset (RWA) tokenization in the UAE with IOTA, unlocking new opportunities, bridging TradFi with DeFi, and bringing new assets into the IOTA network. IOTA’s commitment to RWA tokenization as a means of allowing widespread participation in emerging digital economies stands to gain significantly from the regulatory backing and transparency provided by ADGM. IOTA already occupies a distinctive position to realize these opportunities at scale, forging collaborations and partnerships at governmental and regulatory levels, as in the examples listed above.
Outlook for IOTA in the UAE
The IOTA Ecosystem DLT Foundation will be key to IOTA’s next phase of growth. Through collaboration with local government, regulators, and industry partners, the Foundation will advocate for and support sustainable, positive-sum DLT projects and applications.
Beyond the technical sphere, the Foundation commits to embodying a force for good in the UAE and the broader crypto space. Rooted in the fundamentally collaborative nature of crypto, the Foundation’s success hinges on building relationships with the right partners on the ground to amplify IOTA’s reach and capabilities.
On top of this, IOTA will build its presence in the UAE, hiring and training local talent, and becoming a funnel for talent from around the world to enter the UAE and set up operations at ADGM.
For more about the IOTA Ecosystem DLT Foundation, email contact@iotadlt.foundation, or – as always – you can drop your questions in our Discord.
IOTA 2.0 emphasizes accessibility in Distributed Ledger Technology (DLT), enabling users to interact with the ledger without barriers. It achieves this by empowering every token holder to issue blocks independently, eliminating token fees, ensuring fair network use, and maximizing network capacity through efficient design. This approach ensures digital autonomy, enabling users to manage assets freely and contribute to network decisions.
In the final installment of our introductory series on IOTA 2.0, we delve into one of its key principles: Accessibility. In the context of Distributed Ledger Technology (DLT), accessibility means enabling every user to interact with the DLT by writing in the ledger without barriers. This process, integral to the functioning of any DLT, involves creating and propagating blocks, validating information, and ensuring confirmation. Accessible Writing is the smoothest possible implementation of this process, central to the widespread adoption of the protocol and the realization of digital autonomy.
In essence, IOTA 2.0’s vision of digital autonomy hinges on accessibility. Users must be able to easily access the ledger to exercise control over their assets, avoid unnecessary costs, and contribute to network decisions. Achieving truly accessible writing involves enabling users to include information in the ledger without dependencies on others. IOTA 2.0 addresses this by eliminating the necessity of payment for issuing blocks and ensuring the network’s ability to handle a large volume of blocks per second, thus paving the way for true accessibility in writing on the ledger.
The IOTA 2.0 protocol incorporates components to meet these requirements, which we’ll explore further in this blog post.
Component 1: Every IOTA Token Holder is a Block Issuer
From its inception, the IOTA protocol has striven to make the best possible use of its DAG architecture (you can read more about this in Part 10 of this series, An Obvious Choice: Why DAGs Over Blockchains?). The DAG allows blocks to be included in the network at any point in time and decouples the consensus from block issuance. These features are crucial because they enable a straightforward, efficient solution: empowering users to create their own blocks.
Standard blockchains can’t provide this capability due to their reliance on a single, heaviest chain, necessitating the determination of the next block issuer or a decision on which block among many to include. This creates a dependency between users who just want to include information in the block (i.e. interact with the ledger) and the issuer. In contrast, IOTA’s DAG architecture allows every user the freedom to issue their blocks. This empowerment means users can independently manage their assets by buying, selling, or transferring them at any moment.
Component 2: IOTA is Feeless for Token Holders
Every DLT must handle congestion to process incoming blocks effectively and reach consensus on the ledger state. Traditional blockchains let validators decide which information makes it into the ledger through the issuance of blocks. This setup encourages competition among users for the validator’s services and transaction fees extracted from the base token. As a result, value is extracted from users and given to a narrow class of validators. It also exposes users to a larger degree to issues like Maximal Extractable Value (MEV) and censorship, where validators have excessive control over ledger content due to their dual roles in ledger access and consensus.
In IOTA 2.0, as detailed in our blog posts on tokenomics and congestion control, a robust system is built to manage congestion without token fees. This system revolves around Mana, generated by holding tokens, decaying over time, and consumed when issuing blocks. The scheduler allocates throughput based on Mana holdings. This innovative approach eliminates traditional fees, replacing them with a model where ledger access is central, contributing to the long-term value of the network. This self-sustaining system, combined with users’ ability to issue their own blocks, ensures fair network usage proportional to users’ tokens (and thus its commitment to the network), granting full control over their assets.
Component 3: Network Capacity and Efficiency
The last two components talk about autonomy, the ability the protocol gives the user to control all their assets. Now we deal with the undeniable fact that BPS (blocks per second) matters! Autonomy can only be exercised if the network has enough capacity to process transactions. If demand exceeds the network’s capacity, exceeding transactions won’t make it through. In such a scenario, users’ allowed throughput may become too low, delaying their ability to issue blocks and undermining the autonomy and control over assets that IOTA aims to provide. This situation might force users to buy access from others, contradicting the feeless nature of the system. Buying Mana is an option for those who momentarily require more transactions per second, and not a requirement to use the network. It’s crucial to maintain high network capacity to avoid these issues, as discussed in Part 2 of our blog series, emphasizing the fundamental principles every DLT needs.
IOTA 2.0 addresses this challenge by maximizing efficiency and boosting network capacity, with its modules designed to achieve this goal:
The choice of a Directed Acyclic Graph (DAG) network structure enables Parallel Execution and Stream Processing, optimizing hardware and bandwidth usage (see An Obvious Choice: Why DAGs Over Blockchains?).
These three design components ensure IOTA 2.0 achieves maximum capacity while maintaining rapid confirmations, preserving the core principles of autonomy and feeless usage.
A map of IOTA 2.0
This concludes our series of blog posts that introduce the forthcoming IOTA 2.0 protocol. The series began by describing our vision of digital autonomy for everyone before explaining how IOTA 2.0 will overcome blockchain challenges to achieve that vision. This blog post concludes the introduction by showing how the key point of accessibility is achieved, and how components we’ve encountered throughout the previous blog posts contribute to it.
This may be the last blog post of this series, but there’s more to come in the future. As we always strive to build something even greater, we look forward to building a DLT that can make our community proud and go further than what has been achieved before. Together, with you all, going beyond IOTA 2.0.
In traditional blockchains, the mempool acts as a waiting area for unconfirmed transactions, allowing miners to prioritize transactions based on fees. However, this opens the door to MEV, where miners manipulate transaction order for personal gain. In IOTA 2.0, the mempool is merged with the Tangle – transactions aren’t waiting to be included in blocks but are already included in single transaction blocks by users. So there is no mempool in the sense of a waiting area. The DAG-based structure, leaderless consensus, and simplified transaction life cycle in IOTA 2.0 minimize MEV by removing intermediaries and preventing manipulation.
This blog post discusses the concept of the mempool and Maximal Extractable Value (MEV) in blockchains, and how IOTA 2.0 tackles these concepts to protect its users against harmful value extraction.
A blockchain is a permanent record of linked transactions that can’t be changed. In most blockchains, before your transaction is included in a block and added to the blockchain, it goes through a memory pool (or “mempool” for short), which is like a waiting area for transactions. The mempool stores unconfirmed transactions until they can be verified and included in a block. Once it’s in the block, your transaction can’t be tampered with.
Understanding mempools
In traditional blockchains, there isn’t one universal mempool for all nodes. Different nodes may have different mempools because of network issues or different configurations. Individual nodes may also have different rules for accepting transactions based on factors like gas price and mempool size.
Nodes receive transactions in their mempools and verify them to ensure they’re valid. They do so by verifying correct signature schemes, that the sum of output values doesn’t exceed the sum of input values, and that funds haven’t been double spent. They then send the transactions to other nodes (this process is called “gossiping”) until a leader (for example, a miner) eventually takes transactions from the mempool and adds them to a block. Once a transaction is added to a block, it is removed from the mempool.
Miners are motivated by profits, so they usually prioritize transactions carrying higher fees from the mempool. This allows transactions with higher fees to replace transactions with lower fees and, in effect, a bidding war can ensue with the highest bidders “winning” by getting included in the next block. If you’re not willing to pay more, you could get “priced out” multiple times while your transaction sits unconfirmed in the mempool.
In summary, the mempool in traditional blockchains is a waiting area for transactions before they are added to the blockchain. It helps determine the order of transactions and prioritize transactions based on fees.
Another drawback to a mempool is how it enables MEV.
What is MEV?
Maximal Extractable Value (MEV), also known as Miner Extractable Value, refers to the potential profit that miners or validators can extract from information they glean from your transaction while it waits in the mempool.
In Proof-of-Work consensus systems, each miner has the power to choose the transactions they include in a block, usually favoring those that benefit them the most. This creates a strong temptation for miners to manipulate block content, re-order transactions, or carefully place their own transactions for their own advantage.
The rearranging and selecting of transactions isn’t exclusive to miners but also applies to validators in Proof-of-Stake blockchains. Many blockchains use gas prices to determine the order of transactions: The higher the gas price a user pays, the faster their transaction gets included in a block. By observing the gas cost of transactions in the mempool, one can easily influence the order by placing another transaction before or after them.
MEV has drawn criticism as a form of market manipulation that increases transaction costs, causes chain instability, and negatively impacts retail traders. Some argue that MEV incentivizes miners to validate the network, but the general sentiment is that preventing MEV is beneficial for the future of DeFi.
IOTA 2.0 has no mempool like in traditional blockchains. Here’s why:
Our users are also our validators: DLTs generally have two competing groups of actors: users who want cheap throughput and low node requirements and miners and validators who want to maximize the value of blockchain through MEV, block rewards, and fees. The motivation and incentives of these groups are at odds, with miners and validators effectively extracting value from users. In IOTA 2.0, service providers are eliminated and these two groups become one: This means users can directly write transactions into the data structure without any intermediaries. This resolves conflicts of interest and allows users to maintain their digital autonomy, as there isn’t a separate group of block creators to charge fees or extract value from the network.
Leaderless consensus: The leaderless nature of the IOTA 2.0 protocol enables parallel stream processing: Its DAG-based structure allows for the rapid creation of small blocks without the need for a mempool. All transactions can be processed as they arrive, without waiting, and blocks can be processed in any order (check out Parallel Stream Processing in this blog post for more information). The leaderless consensus also eliminates the need for shared mempools for pending transactions and the special roles of miners or validators.
Simplified transaction life-cycle:In traditional blockchains, the transaction lifecycle involves several steps: creation and broadcast, waiting in the mempool, ordering into a block, issuing the block to the network, validation, execution, and receiving approvers. In IOTA 2.0, the transaction lifecycle is simplified: the transaction is packaged into a block and broadcasted to the network nodes, where it is executed upon arrival, and the block receives approvers. This more efficient process also eliminates the need for a mempool, allowing for faster execution and confirmation.
How leaderless IOTA 2.0 minimizes MEV
Because there is no mempool in IOTA 2.0, your transaction is directly packaged into a single transaction block and added to the ledger without waiting. This prevents bots from being able to scan your transactions and reorder them before being included in the next block. As an effect, value extraction through MEV becomes essentially impossible.
Finally, removing intermediaries like miners or validators altogether also helps to address the MEV problem. In traditional leader-based protocols, the transaction order is decided by a leader, meaning they have control over the ledger state. In contrast, IOTA 2.0 is a leaderless protocol, where many validators independently propose blocks. Leaderless sequencing of blocks prevents manipulation of transaction order, eliminating MEV.
In our next and final blog post in this introduction to IOTA 2.0, we show how we achieve accessible writing and why it matters. Look out for it to appear on December 4th!
The new IOTA Ecosystem DLT Foundation is the first DLT foundation registered with the Abu Dhabi Global Market in the United Arab Emirates. The IOTA Ecosystem DLT Foundation will be seeded with over $100 million in IOTA tokens for nurturing the IOTA ecosystem and accelerating the growth of the IOTA protocol in the region, fostering community-driven initiatives and regulatory synergy.
In September this year, we shared our plans for a new Foundation in Abu Dhabi, United Arab Emirates, to grow our global expansion.
Today, we’re excited to announce that the IOTA Ecosystem DLT Foundation has been registered as the first foundation under the DLT Foundations Regulations of Abu Dhabi Global Market (ADGM). This landmark achievement positions IOTA at the forefront of digital and real-world convergence in the financial sector in the MENA (Middle East and North Africa) region and globally.
We look forward to working with ADGM’s authorities to drive forward the regulatory landscape and bridge the gap between the real world and the digital one. ADGM has one of the most progressive and responsive regulatory frameworks, making our collaboration a major step toward bringing institutional investors and assets into the digital ecosystem.
The IOTA Ecosystem DLT Foundation will be seeded with over $100 million in IOTA tokens, to be vested over the next four years. This funding is earmarked for nurturing the IOTA ecosystem and accelerating the growth of the IOTA protocol. In line with its community-driven ethos, the IOTA Ecosystem DLT Foundation will foster valuable partnerships in the region to advance the adoption of IOTA and its staging network, Shimmer, across various sectors. This includes collaboration with institutional investors, governments, and academic institutions for the tokenization of real-world assets and bringing them on-chain, thus bringing billions of dollars into the UAE’s virtual assets space.
Our inroad into the UAE aims to cultivate a flourishing crypto community within ADGM’s ecosystem. In the future, regularly held events will encourage a common vision for a decentralized future and drive Abu Dhabi’s crypto hub forward through its legal framework.
Hamad Sayah Al Mazrouei, CEO of the Registration Authority (RA) of ADGM said, “Welcoming IOTA, one of the most established and well-respected blockchain protocols into ADGM’s DLT regime exemplifies our ambition to position Abu Dhabi’s stature as a prime location and ADGM as the leading jurisdiction for the blockchain industry. It is a strong validation of ADGM’s progress with its new and revolutionary DLT Foundations Framework. Working with companies like IOTA, ADGM aims to move towards a future characterized by setting global benchmarks in the ever-evolving blockchain and Web3 landscape”.
“The IOTA Foundation’s support from ADGM and our partnership with UAE authorities is about more than global expansion. It’s about ushering in a new era of regulatory synergy in the crypto markets,” said Dominik Schiener, Co-Founder and Chairman of the IOTA Foundation. “We want to ensure that we take the right steps toward digital autonomy for everyone, and that means making sure a diversity of communities take an active role in shaping the Foundation’s technology and governance.”
About the ADGM
Abu Dhabi Global Market (ADGM) is the international financial center (IFC) of the capital city of the United Arab Emirates, which opened for business on 21st October 2015. ADGM augments Abu Dhabi’s position as a leading financial center and a business hub serving as a strategic link between the growing economies of the Middle East, Africa, South Asia, and the rest of the world.
Operating within an international regulatory framework based on direct application of English Common Law, ADGM governs the entire Al Maryah Island and Al Reem Island, which is designated as the financial free zone of Abu Dhabi.
ADGM is ranked as one of the most preferred top IFCs in the Middle East and Africa region and named MENA’s largest fintech hub. Its progressive and inclusive business ecosystem gravitates toward global financial and non-financial institutions while leveraging synergies between ADGM and multiple jurisdictions positioned as one of the world’s most advanced, diverse, and progressively governed financial hubs.
As we embark on this exciting journey with ADGM, our goal is to empower a diverse range of communities to actively participate in shaping the future of IOTA and DLT/blockchain. We’re especially looking forward to contributing to a new era in regulatory collaboration within crypto markets.
In a future blog post, we’ll be explaining more about the strategy behind the IOTA Ecosystem DLT Foundation; in the meantime, if you have any questions about the IOTA Ecosystem DLT Foundation, email contact@iotadlt.foundation, or – as always – you can drop your questions in our Discord.
IOTA 2.0 combines the best of the UTXO and Account models for digital asset ownership, especially tokens. The UTXO model simplifies conflict resolution, enables parallel transactions, and enhances privacy (and in IOTA 2.0 is enhanced by Account Outputs for extra flexibility). Meanwhile, the Account model enables dynamic asset management and more complex transactions. It seamlessly handles resources like Mana, making it a versatile and high-performance platform for digital asset control.
In distributed ledgers, there are two primary models for tracking the ownership of digital assets like tokens or NFTs: the Unspent Transaction Output (UTXO) model and the Account model. IOTA 2.0 combines the strengths of both to create a versatile ecosystem for managing digital assets efficiently. Let’s explore each model and how IOTA 2.0 uses them!
The UTXO model
In the UTXO model, transactions generate outputs, which are registers of the digital assets that were received through the transaction. The same transaction also consumes outputs generated by past transactions. This cycle of generating and consuming outputs enables the easy validation of transactions by identifying conflicts in consumed outputs.
In general, each output is accessible only with the owner’s private key. When issuing a transaction consuming outputs, the owner uses the private key to prove their ownership of the digital assets like tokens, thereby validating the transaction. Consumed outputs are replaced by new ones: the recipient’s output holds the transaction’s value, and any leftover value forms another new output.
According to this model, nodes maintain a shared list of all unspent outputs. Whenever a new transaction is included in the ledger, it consumes some outputs and generates new ones.
There are many key advantages to using the UTXO model:
Parallelism for Transactions: Transactions move funds owned by a single user, so transactions issued by different users consume completely different outputs. Such transactions can be processed in parallel, enabling faster and more efficient transaction validation.
Simplified Conflict Identification: In the UTXO model, conflicts are easy to classify and identify: If two transactions attempt to consume the same output, it’s immediately recognized as a conflict.
Despite these advantages, the UTXO model faces challenges when registering spendable resources such as states that change dynamically (such as exchanging two distinct currencies) or Mana (see our blog post on congestion control). Resources like gas or Mana are necessary to run DeFi applications and smart contracts, but implementing them with a UTXO-based system can be difficult since an asset that represents such a resource could not be spent simultaneously by more than one transaction. The Account model offers a solution to these challenges.
The Account model maintains a list of balances, updating it with each validated transaction or protocol-triggered event, like block rewards. Although it sounds much simpler than using the UTXO model, just keeping balances can lead to complications. For example, conflicts aren’t so simple to identify. Imagine a user with a balance of two tokens attempting to send three transactions of one token each. One of these transactions will be deemed invalid, but which one? By enabling transactions with a more complex logic, the ordering between these transactions starts to matter, and reaching consensus on transaction ordering is an extremely difficult task. So the cost of using the Account model is a more complex consensus module.
In this model, the list of balances is maintained as a global ledger state that is changed by each validated transaction. Even the slightest change in any account, no matter how simple, necessitates an update to the global ledger state, which, as mentioned above, is no easy task. This complexity poses challenges for applications that rely on frequent, dynamic value changes. However, this feature, which enables the modification of an account by issuing a transaction without knowing the current value of the account, can also open up many advantages. For example, one can issue multiple transactions without waiting for one of them to be settled. Such flexibility would be possible in the UTXO model only if the assets of the owner are already separated into different outputs.
Despite the good points of the Account model, we acknowledge the advantages of each model. So building IOTA 2.0 is not simply about choosing one of them, but how to use each to our advantage.
The IOTA 2.0 Model
The IOTA 2.0 protocol extends the UTXO model to enable the flexibility of the Account model. This approach builds on a model introduced in IOTA 1.5, Alias Outputs, and extends it into what we call Account Outputs.
Put simply, Account Outputs are outputs that carry a state within themselves. Instead of a single owner, the output now has two controlling parties: a “state controller” capable of changing the contained state and a “governor” who determines the owner (but can’t change the output’s state). This feature enhances the flexibility of the UTXO model and further enriches the asset management capabilities of IOTA 2.0.
Once conflicts have been efficiently resolved on the DAG and the resulting state has been committed, the state of the Account Output and properties associated with it can be stored as an account state. This account state conforms to the Account model in the sense that its values can be updated independently of any specific output, opening up a wider range of applications possible with a purely UTXO-based system.
IOTA 2.0 enables its users to benefit from the strengths of Account-based models while providing a UTXO-based ledger that enables secure asset management, parallel transactions, and easy conflict identification. Uniting the best of both worlds to achieve true versatility and performance, all to empower our users and achieve digital autonomy!
Stay tuned for the next blog post in this series on November 30th, which looks at the concept of mempools and how IOTA 2.0’s unique approach limits MEV to protect users against value extraction.
IOTA Identity 1.0 provides a stable SSI implementation for Stardust-enabled networks. allowing easy integration for existing and new apps that want to maximize digital autonomy and privacy for users.
Last September, when the Stardust protocol upgrade and its tokenization framework were introduced to our staging network, Shimmer, we leveraged these advancements to enhance IOTA Identity – our decentralized identity tool. Following its launch on Shimmer, the next iteration of IOTA Identity underwent thorough testing and refinement. Now, with the successful integration of the Stardust upgrade on IOTA, we’re excited to introduce IOTA Identity 1.0 with its enhanced capabilities to the broader IOTA network.
First introduced in 2018, IOTA Identity is a decentralized identity (DID) method, identified as did:iota, along with an associated library. These components leverage the unique attributes of the IOTA ledger, facilitating the seamless integration of digital identities into both new and existing applications. While this post provides a summary of information released alongside the debut of IOTA Identity 1.0 on Shimmer (see the blog post here), it also highlights the latest enhancements based on our insights into Identity since September of last year.
The technical revamp
To align IOTA Identity with the Stardust version of the protocol, we have completely rethought how identities should be created, updated, and resolved. Leveraging the Stardust ledger’s capabilities, we’ve adapted Alias Outputs to represent identities, enabling interactions with other Layer 1 entities such as fungible and non-fungible tokens (NFTs).
On a technical level, DID documents are now stored in the state metadata field of Alias Outputs, making them accessible for resolution across all nodes. This approach utilizes Layer 1 access control mechanisms for ownership and permissions management.
Alias Outputs provide four capabilities for hosting identities:
Globally Unique Identifier: Alias IDs can’t be changed after creation, aligning perfectly with the immutable nature of DID identifiers. The DID contains the Alias ID, allowing seamless conversion between the two. A simple example: The last part of the DID (the method-specific identifier) corresponds to the ID of the Alias Output (did:iota:0x0a6cf67b1faff3c4c9097ce91d84b1df490917b39a64a5b6ef30476ce4c528d3).
Data Storage: Outputs can store arbitrary data, such as DID documents, in their state metadata.
Controller Management: Only the state controller can modify the Alias Output, effectively becoming the DID controller, and aligning with DID terminology.
Extended Capabilities: A DID within an Alias Output inherits all the capabilities of that output, including token transactions and native asset minting. We explore these use cases in more detail below.
We’ve also implemented an on-chain revocation mechanism that can be embedded in the issuing party’s identity. This guarantees high availability during credential verification and simplifies processes by re-using the same access control mechanisms issuers use to update their identities.
Unlocking new possibilities
Representing identities via Alias Outputs on Layer 1 opens up exciting interactions with other Layer 1 entities, leading to innovative use cases. For each interaction, we’ve provided examples in the library, available here:
Alias Outputs can control other Alias Outputs, enabling one identity to govern another. This enables us to create hierarchies of identities and model situations like company subsidiaries or human custodians. In this context, control is divided between two parties: the governor and the state controller. The governor decides who can make updates to an identity by assigning a state controller, while the state controller determines how the identity is represented by making changes to the DID document.
For example, imagine a smartphone manufacturer called Phonemkr and its subsidiaries: Phoneshop, where people can buy phones, and Phoneshippr, which ships the phones. Phoneshop manages the identity of Phoneshippr, but the manufacturer (Phonemkr) wants ultimate control over both.
This is achieved by setting the address of an identity’s Alias Output as the state controller or governor unlock condition of another identity. Today, the Alias Output can only have a single state controller, but we intend to allow multiple controllers with future protocol updates. So in our example, multiple controllers would allow both Phonemkr and Phoneshop to make updates to the identity, providing more flexibility.
Authenticating transactions
Identities can receive, hold, and send tokens. This enables the sender and receiver of funds to be identified, providing stronger assurances to everyone involved.
Because an Alias Output can hold tokens, any DID can be converted into an address. For instance, if Alice exchanges DIDs with Bob and wants to send him funds, Bob authenticates his DID to Alice. When Alice sends funds to Bob’s Alias Output address, she can be confident that whoever controls Bob’s identity – typically Bob himself – will access the funds.
Conversely, if someone receives funds from an Alias Output containing a DID, they can authenticate the origin of the funds, potentially supporting anti-money laundering efforts. Observers can track fund movements, making it advisable to use different identities for various use cases instead of a single identity for all interactions.
An Alias Output’s address can serve as the Unlock Condition of any output, allowing the Alias Output to control the Basic Output and its funds. Funds are transferred by creating a Basic Output controlled by the receiver’s Alias Output. This setup provides a permanent identifier to receive funds while adhering to security best practices like key rotation, enabling the transfer of funds to DIDs on Layer 1.
DIDs issuing NFTs
With the Stardust protocol upgrade, NFTs can now be minted and transferred on Layer 1 through dedicated NFT Outputs, and DIDs can help prove the identity of the NFT’s issuer.
For example, Phonemkr wants to issue digital product passports in the form of NFTs for each phone it sells. Phonemkr creates its identity in an Alias Output and provably links its DID to its website, phonemkr.com. If Phonemkr issues NFTs with its identity as the issuer, it proves that phonemkr.com issued those NFTs.
Similar to fund transfers, NFTs can be owned by and transferred to DIDs, since the Unlock Condition of an NFT Output can be an Alias Output representing a DID, providing assurances about whom you receive NFTs from or send NFTs to.
Furthermore, NFTs can unlock (read “own”) identities. This could greatly benefit entities or organizations represented and traded through NFTs (though isn’t generally recommended for humans). This allows the transfer of ownership of an entity or organization and its corresponding identity in a single atomic interaction.
DIDs issuing native tokens
When a DID serves as the minter of native tokens, it provides greater assurances and trust to token holders. With this information, token holders can verify the origin of native tokens and validate claims made by the asset issuer.
This is made possible because native tokens are created through a Foundry Output controlled by a single Alias Output. Embedding an Identity into this Alias Output enables the identity of the minter to be resolved.
Authenticating smart contracts chains
The Stardust protocol upgrade will enable the state of IOTA Smart Contract (ISC) chains to be anchored into Alias Outputs in the ledger. With IOTA Identity, smart contract chains can be provably linked to identities.
As mentioned earlier, identities can be organized hierarchically, enabling a single identity to create and control multiple Alias Outputs. This means an identity within an Alias Output can govern the Alias Output of an ISC chain. This lets users identify the governor of a chain and helps them decide whether they want to trust and interact with the chain. It also lets external observers verify and prove who has ultimate control of the chain.
JSON Web Token
As the SSI ecosystem converges on common standards and formats, we strive to choose the most capable and interoperable technologies. Following that reasoning, we’ve transitioned to the JSON Web Token (JWT) encoding for credentials and presentations. This aligns with the latest proposals and recommendations from regulatory projects in the EU. Credentials and presentations are now embedded in JWTs (a widely used format for exchanging attributes and permissions) and need to be stored and transmitted in this format.
We’ve built the library in such a way that alternative credentials formats, like the very promising Data Integrity Draft, can be implemented alongside the current format moving forward.
Key Storage Enhancements
We reworked the storage interface to enable implementers to develop their own solutions for storing sensitive key material. For advanced requirements, the new interface should make it significantly easier to adapt the library to existing key management solutions that offer the highest level of security and durability. To achieve the necessary flexibility, we’ve divided the interface into two parts: one handles key storage and operations, while the other handles library-specific state.
As before, we ship a default implementation of the interface using Stronghold for Rust, allowing implementers to work quickly and securely. The default implementation allows implementers to manage keys, used for access to the ledger, and identities to be stored (and backed up) in the same Stronghold snapshot file, improving the ergonomics of key management.
Domain Verification
A significant new feature in 1.0 is Domain Name Verification, a process that verifiably links a domain to an identity. The link can be discovered either by starting from the domain or the identity.
An example of starting from the identity is verifying the minter of an NFT. By inspecting an IOTA Layer 1 NFT, you can discover which Alias Output minted it. In turn, the Alias Output can contain an identity that can be linked to a domain. By resolving the domain, a verifier can confirm the cryptographic link and have confidence that the entity that controls the domain also issued the NFT, thereby confirming the authenticity of the NFT.
Conversely, an example starting from the domain is when you discover identities linked to a homepage and establish a Web3 connection to an endpoint referenced in the linked identity. Through this link, you can start from a trusted homepage and discover linked corporate identities for future on- and off-chain interactions.
It’s important to note that information published on-chain must be carefully evaluated to fulfill individual needs for anonymity and compliance with data privacy laws. While corporations may choose to link their homepage to their digital identity, individuals may prefer not to create such links to their personal homepage.
To maximize interoperability, our implementation follows a proposal developed by the Decentralized Identity Foundation (DIF). The proposal makes the link from an identity to a homepage optional, allowing identities to decide how discoverable they want the linkage to be. To establish a link, the domain owner needs to upload a credential signed by the linked identity to their domain. Both the domain and the identity can contain multiple links, creating a web of trusted relationships between multiple domains (e.g. membership in professional and non-profit organizations, hobbies, fan clubs, etc.) and identities.
In conclusion: the future of digital ID
IOTA Identity 1.0 lays the foundation for ambitious identity solutions for individuals, organizations, and objects. Leveraging the scalability of the IOTA Tangle and the versatility of the Stardust ledger, we’ve created a unique ecosystem for both on- and off-chain interactions between cryptographic and self-sovereign identity elements.
Join us in this exciting journey as we continue to shape the future of digital identities on the IOTA Tangle. Follow us on Twitter at @iota , join the ID channel on Discord, or contact us at identity@iota.org. Together, we’re redefining the possibilities of identity verification and trust in the digital realm.
IOTA 2.0’s sustainable Mana-based tokenomics will establish a circular, replenishable economy. Instead of wealth flowing in one direction from the system’s users to its maintainers, all IOTA token holders receive Mana with which they can access the network. Validators and delegators are incentivized with additional Mana that can be used or sold, while everyone has the same opportunities to participate in the network.
Having introduced the key elements of IOTA 2.0’s tokenomics earlier in this series of blog posts, this article describes how IOTA’s tokenomics supports our vision of Digital Autonomy for Everyone and generates value for users. We begin by looking at the immediate benefits for users who want to stake their tokens in order to either validate or delegate. We then look at Mana, the token-generated asset that is also given as a reward for validating and delegating, and how it can be estimated in advance. Then we look at the larger role Mana plays in making IOTA 2.0’s tokenomics a fair system for every participant.
As we saw in Accounts, Tokens, Mana, and Staking, it’s easy to either stake your IOTA tokens and help validate the network or delegate them to a validator. But why would you want to do that – what benefits would it bring to you?
Becoming a validator or delegator on the IOTA network offers a wide range of benefits, from earning Mana to enhancing security and being at the forefront of innovative technology.
Receive extra Mana: Validating or delegating gives you the opportunity to receive extra Mana on top of the Mana that you accrue just by holding IOTA tokens. This additional stream of Mana can be used to gain more throughput or sold as you choose. (The development of any Mana market will be the work of the community, and will not be controlled by the IOTA Foundation. Early Mana markets may be community-developed platforms selling Mana for fiat or IOTA tokens, while DEX-based Mana marketplaces could emerge post-L1 smart contract implementation.) To give you a preview of how much Mana you can expect to receive, we’ve built the IOTA 2.0 Mana calculator, which we’ll introduce in the next section of this blog post.
Enhance security, trust, and reliability: Validators help verify and confirm transactions, enhancing the trustworthiness and reliability of the network. By actively participating in consensus, you help prevent malicious activities such as double-spending and other attacks, ensuring a strong and dependable ecosystem that attracts more users and businesses to the platform and gives you certainty that everything is in order for your own on-chain activity.
Support decentralization, diversity, and security: By validating, you play a vital role in ensuring the decentralization and security of the IOTA network. And even if you don’t want or don’t have the ability to run your own validator node, you can still make your voice heard by delegating. A diverse set of validators and delegators ensures that no single entity or group dominates the consensus process, promoting a more resilient, inclusive, and democratic ecosystem.
Embrace flexibility, reliability, and low barriers to entry: If you can’t spare the time or effort in setting up and maintaining a validator node but still want to receive extra Mana, contribute to consensus, and benefit from the network’s growth, delegation offers the chance to do so. Delegating also helps you adapt to evolving network conditions: you can switch your delegation to different validators based on their performance or changing requirements, ensuring your voting power remains efficient. And when you delegate to a validator with a track record of reliability and trustworthiness, you align yourself with their expertise and reputation in the network.
Calculating Mana
In IOTA 2..0, 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, you’ll know the range of Mana that will be burned to process your transactions. (to learn more about Mana, and how it accrues and decays over time, please refer to our Wiki).
The Mana Calculator is designed to provide reassurance, predictability, and a clear understanding of your potential Mana rewards based on whether you validate or delegate your IOTA tokens.
By selecting the task that aligns with your preference, you can simulate the amount of Mana generated under three different network congestion levels: “low congestion,” “stable price,” and “extreme congestion.” For example:
Delegating: By inputting the amount of IOTA tokens you intend to delegate to a validator, the calculator will show you the Mana you can receive while supporting the network’s decentralization.
Validating: If you’re ready to actively participate in securing the network as a validator, input your staked IOTA tokens, and the calculator will estimate the Mana rewards you can expect to receive based on your contributions to validating transactions.
(Disclaimer: The Mana Calculator is intended for informational purposes only and provides estimates. The actual amount of Mana received may vary due to network dynamics. Always exercise due diligence and make informed decisions when engaging in any DLT-related activities.)
Fair tokenomics: Mana as the basis for access
Incentives are essential for any DLT tokenomics, covering necessary costs and ensuring fairness among diverse actors. But, too many crypto projects are over-dependent on offering generous fee rewards to attract participants, which leads to greed that obscures the original vision of the network, and to users feeling exploited and excluded. The inflation that derives from using the underlying token as a reward for participation exacerbates wealth imbalance, consolidating power and wealth in the hands of a few. Not only does this fly in the face of the core ideology of any cryptocurrency but it also leaves the system open to corruption and tampering.
IOTA 2.0’s tokenomics aims to overcome this negative spiral by decoupling the token from its incentives system and rewarding contributions to the system with more access to the system. This access attracts players who want to utilize the IOTA network to its full potential, rather than those who only seek to extract profit.
The IOTA network’s access-based incentives model combined with its unique DAG-based consensus enables a set of properties that drive IOTA’s long-term vision of digital autonomy for everyone. It empowers participants to actively engage with the protocol, forging a mutually beneficial relationship between users and IOTA technology.
IOTA tokenomics is fair because it addresses significant barriers to adoption;
No fees for token holders and no inflation: IOTA’s access-based incentive scheme means that no fees are required for token holders and removes the need for IOTA token inflation to support incentives. Instead, the IOTA token supply remains fixed, preventing the dilution of token holders’ funds due to inflationary rewards.
Fairer wealth redistribution: By decoupling rewards from the base token, we prevent the imbalance of power found in systems with token fees and inflation, where wealth flows from end-users to validators, making the rich richer and the poor poorer.
Long-term commitment from adopters: Because rewards aren’t simply tokens that can be cashed out to make an immediate profit, but are tied directly to the utility of the system, access becomes more valuable as the technology and ecosystem mature, increasing utility and demand for the use of the system.
Access to all: IOTA 2.0 consensus is leaderless, meaning that access to write to the ledger is never controlled by a single entity. Instead of relying on centralized entities or validators, IOTA allows all token-holders to issue their own blocks and play an active role in consensus. And by rewarding active participation with access, IOTA 2.0 accommodates users who are restricted from receiving cryptocurrency rewards for legal or regulatory reasons.
Mana: building a circular path to a thriving ecosystem
As one of the five principles of IOTA 2.0, our sustainable Mana-based tokenomics establish a circular, replenishable economy. The flow chart below illustrates the key drivers of our tokenomics that, by reinforcing each other, will propel IOTA’s growth.
As more entities recognize its potential and begin to integrate IOTA into their operations, the popularity of IOTA increases. As the digital asset becomes more attractive, the incentive to protect and secure the network grows stronger, and the cost of an attack rises alongside the token’s increasing intrinsic value. Increased security motivates more participants to actively engage in the network, which in turn enhances the overall performance and reliability of the protocol as well as encourages even more users to join the ecosystem. As network activity rises, the demand for efficiency and scalability through more Layer 1 blockspace and interoperability between Layer 2 networks increases, making Mana more sought after.
Welcome to a world where innovation meets fairness, where all participants are incentivized with the same opportunities, and where the power of IOTA 2.0’s tokenomics drives us toward a decentralized future.
In the next article, published on November 28th, we look at how IOTA 2.0 adopts the best aspects of the UTXO and Accounts model to represent digital asset management.
Most distributed ledgers can be either safe but slow or fast but vulnerable. IOTA 2.0 is a dynamically available protocol, allowing you to find your own balance between caution and optimism according to your expectations of the ledger. Curious about why this adaptiveness is a precious feature of a distributed ledger? Read on to find out why a hybrid approach makes ensuring finality and availability at the same time possible.
When you interact with a distributed ledger, you’re likely to have two fundamental expectations. You want assurance that your submitted data will eventually find a place on the ledger, and that, once included, the fate of your data will be definitively determined. While this two-fold expectation might seem obvious in the context of distributed ledgers, the reality is that many blockchains are only capable of fulfilling one aspect of this promise (as discussed in this paper from the 2021 IEEE Symposium on Security and Privacy).
One of the standout features of IOTA 2.0 is its ability to ensure dynamic availability. This enables you to have your transactions seamlessly processed despite any transient faults that may arise in the consensus protocol, while at the same time ensuring that your transactions will be finalized definitively by the consensus protocol.
In this blog post, we’ll explore dynamic availability and uncover the reasons why achieving both dynamic availability and definite finality simultaneously can be challenging – but it’s a challenge that IOTA 2.0 addresses effectively.
Unreliability of networks
To understand why achieving dynamic availability and definite finality simultaneously is difficult, it’s important to recall an often-overlooked reality of today’s computer networks: their inherent unreliability. Computer networks comprise layered structures where each layer is susceptible to numerous kinds of failures, ranging from hardware faults in network devices to anomalies in the physical medium or unforeseen misbehavior in communication algorithms.
Implications of network unreliability, combined with the likelihood of intentional adversarial behavior by peers in the network, give rise to some important communication challenges. For example, let’s consider a scenario where you establish a direct wired connection with someone in a peer-to-peer communication setup. After forming the connection, you send a message to your peer, asking “Are you there?” to which you receive no response. Given the unreliable nature of the communication medium, it becomes impossible to distinguish between two potential situations:
Your peer is an honest participant and sent a YES answer, but you didn’t receive the message due to network faults or insufficient waiting time. (Note: In theory, waiting time is never truly long enough to guarantee receipt.)
Your peer is an adversarial participant and chose not to send you a response even though the connection functions flawlessly.
This example highlights the core challenge posed by network unreliability: it becomes impossible to ascertain the honesty of participants within the network. This means that in any peer-to-peer network, it isn’t possible to ascertain either the existence or the number of adversarial nodes. Moreover, if any adversarial node exists, it can provide its peer with conflicting answers, hindering any collaboration between nodes. This is the reality of how the Internet operates, and distributed ledgers that are built on the Internet are no exception to these challenges.
Collaboration between distributed nodes is a challenging task. Several approaches to this problem have been studied for the past 50 years. Let’s delve into these approaches, analyzing them in two categories: ensuring finality and ensuring availability
The first category of solutions relies on the supermajority of a predetermined set of nodes in the network, known as voting-based consensus protocols. These protocols rely on two key assumptions:
Each node participating in the consensus protocol has knowledge of the total number of nodes in the protocol.
There is an upper bound on the number of adversarial nodes, which is known to all participants. (Note: It has been theoretically proven that consensus is not achievable when more than one-third of the nodes are adversarial .)
In distributed ledgers that rely on the assumptions above, consensus between nodes on which data should be added to the ledger is achieved by seeking approval from a supermajority (in other words, more than two-thirds) of the peers. This requirement ensures that honest nodes will never have conflicting views of the ledger. Consequently, the approved data can be written to the ledger irreversibly, meaning that the transaction (or any other considered data) is finalized.
To grasp the behavior of voting-based consensus protocols under dynamic participation, let’s consider the following scenario. Imagine a distributed ledger maintained by a network of 10 peers. These peers decide on the inclusion of transactions in the ledger using the aforementioned procedure: a set of transactions is written to the distributed ledger if it receives confirmation from seven peers.
Now, envision a situation where four of the peers lose connectivity with the remaining six due to a network issue. Fortunately, all six remaining peers continue to benevolently run the consensus protocol. However, since the disconnected nodes cannot determine whether the problem lies in the network connectivity or if the candidate transaction set lacks sufficient confirmations, no transaction set can be written to the ledger until the connection problem is resolved. In other words, the ledger suffers a loss of availability.
To summarize, voting-based consensus protocols used in blockchain solutions such as Algorand, Tendermint, Avalanche, and SUI ensure that whatever is written on the ledger is definitely finalized, while the consensus protocol may halt the processing of transactions in case of a lack of sufficient numbers of pre-determined participants.
Before introducing the second set of consensus solutions, it’s worth mentioning that consensus among untrusted peers with dynamic participation was once widely believed to be impossible, as this 2010 paper on multiparty computation makes clear. This notion held fast until a groundbreaking idea emerged, bringing together a combination of established techniques such as proof of work, hash chains, and Merkle Trees. This solution, known as the Nakamoto Consensus, marked the inception of the blockchain revolution with the introduction of the Bitcoin blockchain.
The Nakamoto Consensus algorithm relies on a simple principle. Participants of the consensus, called miners, compete with each other to solve a cryptographic puzzle (i.e., proving their computational resources), without needing to know how many miners exist in the network. The puzzle-solving procedure is similar to a lottery in which the probability of winning for a node is proportional to the computing power of the node. The solver of the puzzle is given the right to determine the set of transactions to be written to the next block of the ledger.
The distinctive feature of proof-based consensus protocols is the fact that the protocol continues to function even when there is only one miner. Therefore miner nodes are free to leave and re-enter the competition at any time. Thus, the protocol maintains availability even under undesirable network conditions.
To deal with cases where there are multiple leaders (concurrent solvers of the puzzle), honest nodes follow a simple rule: select the ledger with the highest number of blocks (i.e., the longest chain). In cases where chains have equal lengths, pick the one that you witnessed the earliest.
Note that, in the given scenario, there is no way to determine whether there is a set of adversaries that are processing a parallel ledger without informing the rest of the network until their ledger becomes longer than the chain of the benevolent node. When they have a longer chain, they reveal their chain, waiting for the rest of the network to adapt to it, thus effectively ignoring all transactions that were in the neglected blocks. Due to this, one can never be sure whether a transaction is irreversible.
Bitcoin and proof-based consensus protocols rely on probabilistic finality: In the absence of malicious nodes, the probability of a transaction in a block being revoked reduces exponentially with the number of succeeding blocks. A recent analysis shows that a transaction contained in a Bitcoin block that is six rounds older than the newest block may be successfully reverted with a probability between 0.11% and 0.16% by an adversary controlling 10% of the mining power. Cardano and Proof-of-Work-based Ethereum are other examples of blockchains with probabilistic guarantees of finality.
Picking the best of both worlds: Flexible consensus
As we’ve seen, the two categories of consensus have their strengths and weaknesses. While voting-based consensus protocols prioritize consistency over availability, Nakamoto-like proof-based consensus models ensure dynamic participation at the cost of definite finality.
In distributed systems, it is well-known that achieving both dynamic participation and guaranteeing safety under network partitions is impossible, as this paper from 2002 argues.
However, it is possible to design a consensus protocol in which two types of consensus models coexist and to let you the user determine the level of safety on the spectrum between definite finality and dynamic availability.
This is the approach taken by IOTA 2.0.
IOTA 2.0: definite finality and dynamic availability
As we explored in Part 6 of this series of blog posts, IOTA 2.0 takes a layered approach to consensus. Blocks that are issued by users and submitted to the network are guaranteed to be included in the Tangle and receive a quicker acceptance flag, while an ongoing consensus mechanism eventually decides on their irreversibility. This approach is akin to having a finality gadget running alongside a dynamically available block creation procedure, as implemented in Ethererum (Proof of Stake) and Polkadot blockchains.
Thus, in IOTA 2.0, it is up to you the user to determine the level of safety. Upon revealing their transactions to the network and receiving a quick acceptance, you can start to optimistically build on top of accepted transactions before the consensus protocol takes the final decision on your transaction. Conversely, a more conservative user can opt to wait for their transactions to receive the finalized flag before taking any action dependent on the accepted transaction. Needless to say, you can dynamically adjust your level of caution when using IOTA 2.0: continue building on top of your low-risk transactions as soon as they are accepted, and wait for your high-risk transactions to be finalized before proceeding.
The next blog post, Fair Tokenomics for all Token Holders (published on November 16th) will present the sustainable tokenomics of IOTA 2.0.
On Monday, November 6th, we held a Discord AMA on the recent series of videos, blog posts, and wiki pages that introduce the upcoming IOTA 2.0 protocol update. Community members asked several questions to Andrew Cullen, Andrea Villa, Billy Sanders, Darcy Camargo, Nikita Polianskii, and Piotr Macek from our team of researchers and engineers; they also added their own insights.
We’ve reproduced the questions and answers (lightly edited for clarity) here for those of you who missed it. For those of you who prefer to watch rather than read, we’ve also shared some of the best questions with long-time community member Linus Naumann in the video below.
Thirty questions about IOTA 2.0
1) What’s your expectation of how the Mana market will develop? How much monetary value compared to what you stake are you expected to receive in return for staking (APY)? 1-5%?
Andrew: Firstly, the Mana market isn’t something the IOTA Foundation intends to invest resources into developing, but is something that we intend to leave to the community. We have put a lot of thought into how we’ve implemented Mana itself, to ensure that it is flexible enough to be used in lots of different ways, from its primary use for block issuance to Layer 1 and Layer 2 smart contracts, to a measure of reputation, to buying and selling on a “Mana market”. I could foresee the earliest embodiments of Mana markets taking the form of third-party providers developed by the community that sell Mana for fiat currency or IOTA tokens. This version of a Mana market would exist alongside block issuance service providers that simply issue blocks on users’ behalf and don’t even require Mana from the user. Offering block issuance as a service is a form of Mana market as well because you’re paying for a service that requires Mana. More sophisticated DEX-based Mana marketplaces would evolve after the arrival of L1 smart contracts.
Unfortunately, I can’t speculate about the expected APY for staking but I can tell you that there is a simple 1:2:3 rule for delegation/staking to calculate how much additional Mana you can earn for delegation or staking over simply holding tokens. Holding Y tokens earns you X Mana, delegating those tokens earns you at least 2X Mana, and staking those tokens earns you at least 3X Mana (provided you do your job correctly as a validator).
2) What are the hardware requirements to run a node as a validator?
Piotr: Running a validator node will not require much more resources than running a regular node. The only difference is that a validator will need to run an inx-validator INX extension, which doesn’t use a lot of resources. We’ve just implemented the validator plugin, so we don’t yet know the exact requirements, but the plugin basically constructs and issues a block in certain intervals, which doesn’t consume a lot of resources.
3) Is the monetary value of Mana taken into account for the development parameters; e.g. artificially reducing capacity to increase the value of Mana?
Andrew: The supply and demand for Mana are certainly taken into account in choosing the parameters of the network. One way this is taken into account is that in the early stages of the network, the decay of Mana will be very slow, which allows participants to hoard Mana because the Mana will be of low value at this stage. However, when the network is more mature and Mana becomes more valuable, the decay rate will increase so that Mana can no longer be hoarded. So we will not artificially limit supply just to make it valuable, it’s sort of the opposite actually. Mana will become valuable when the network is useful, but there won’t be any tricks to make it valuable before that.
4) How does IOTA 2.0 address the scalability challenges that the previous version faced, and what innovative features have been implemented to ensure faster and more efficient transactions?
Andrea: The IOTA 2.0 protocol has been redesigned from the ground up to have a leaderless and parallel voting mechanism. All validators, regardless of the mechanism involved in selecting them, can simultaneously vote on blocks and transactions appearing on the Tangle. This is opposed to the current milestone approach where a section of the Tangle can only be evaluated at the time of receiving a milestone. In fact, in IOTA 2.0, nodes keep a live tracking of the weight of any object until reaching the acceptance threshold.
5) Can you provide insights into the security enhancements of IOTA 2.0, particularly in relation to preventing potential attacks and securing the network for long-term viability?
Andrea: Unlike the linear confirmation process in the previous version, IOTA 2.0 allows multiple parts of the Tangle to be validated concurrently, significantly increasing transaction throughput. The same is also true for its validation and voting process: it is parallel and decentralized, as there is no single Coordinator to rely upon. In IOTA 2.0, a set of validators is selected following the outcome of a committee selection process, backed by delegated Proof of Stake. A committee of validators is selected on every epoch: a multiple of slots roughly a day in length. In this scheme, a candidate validator can become an actual validator by providing enough stake, receiving stake delegations by users in the network, and proving its ability to follow the protocol before the selection process of the following epoch. This way, the network is not only secured by enough stake, but it is also resilient against validators becoming malicious or going offline.
6) What strategies has IOTA 2.0 adopted to reduce its carbon footprint and contribute to more environmentally friendly blockchain technology?
Piotr: Compared to the previous version, the improvement is that we don’t rely on Proof of Work for congestion control, which reduces the amount of computation. Here is a detailed analysis that was performed on the GoShimmer prototype some time ago. The energy usage and the overall approach didn’t change, so it’s still roughly up-to-date: https://blog.iota.org/energy-consumption-of-iota-2-0/.
7) How does IOTA 2.0 address the potential threat of adversarial validators attempting to manipulate the confirmation process in the Tangle, and could you provide more details on the preventive measures that have been implemented to safeguard the network?
Nikita: The protocol itself serves as our safeguard, enabling us to tolerate up to a third of adversarial validators in the committee. This protocol can be segmented into various components, including the congestion control mechanism, the approval weight module, the tip selection algorithm, the chain switching rule, etc.
Each of these components contributes to providing protection in distinct ways. Our tip selection algorithm enables the selection of all blocks issued by honest nodes, ensuring that no honest block can be censored or disregarded by adversarial validators. Otherwise, any adversarial blocks will eventually be ignored by honest nodes. Our tip selection also allows consistent generation of slot commitments by all honest nodes. A block issued X seconds ago is expected to receive an approval weight of value F(X) from the committee, preventing blocks with an old timestamp from infiltrating the Tangle.
The congestion control mechanism is designed to prevent spamming by adversarial validators and nodes. Using the approval weight module, each node logically interprets the local DAG, Tangle, and arrives at the same conclusions concerning the confirmation and finalization of blocks and transactions.
8) Regarding the alignment of goals and incentives between users and validators in IOTA 2.0, can you elaborate on the specific mechanisms that enable users to produce their own blocks and how this eliminates the extraction of value from users through inflation, ultimately benefiting the entire network?
Andrew: The “specific mechanisms” in question pretty much span the entire protocol so it isn’t easy to point you towards one protocol feature that enables this. First of all, it’s the Mana-based congestion control that enables users to create their own accounts and issue and pay for their own blocks. They also generate their own Mana by simply holding tokens (we consider holding tokens to be valuable to the protocol as it makes the tokens scarce and the network more secure), and they can increase their generation rate by delegating (considered a more valuable use of tokens and so earns more rewards). Validators are user accounts that have locked up their tokens, and they issue validator blocks periodically to essentially vote for the parts of the Tangle they see as correct, which is an extra valuable service and earns even more Mana. These different classes of users earning different amounts of Mana have a similar implication to inflation because Mana (access to issue blocks) is distributed from those who contribute least to the protocol to those who contribute most to the protocol. However, this phenomenon occurs in Mana only, and not in the base token. Also, users never pay a validator to approve their transactions as can be seen in many protocols with fees for prioritization, and this eliminates other forms of value extraction as well as inflationary ones.
9) Could you explain the role of Mana burn in preventing spam and regulating the number of blocks users can issue within a specific time interval, and how this mechanism differs from other similar approaches, such as Ethereum’s EIP-1559?
Andrew: Our Mana burn mechanism has some similarities with EIP-1559. Our idea for this Mana burn mechanism came from our earlier adaptive PoW proposal rather than being inspired by EIP-1559. We define a reference Mana cost (RMC) as equivalent to the base fee in EIP-1559, but the main difference with our approach is that it doesn’t include an additional tip for prioritization. The RMC adapts slowly to increasing demand for access, it can increase each 10 second-slot to increase the cost of a transaction in response to persistent increases in demand. However, in spikes of congestion, this mechanism is of little help, and this is where the tip comes in for EIP-1559, to prioritize traffic during these spikes. In our case, this prioritization is instead done without a Deficit Round-Robin (DRR) scheduler, which allows transactions through for each account holder at a rate proportional to their Mana holdings. They can’t pay for priority, because this leads to unpredictable fees and delays that we see in other networks. Instead, users take what they can get based on their Mana holdings during these peaks, and the payoff is predictable delays and fees based entirely on the protocol-defined RMC. Check out the Wiki article on congestion control for a detailed explanation if you haven’t already.
10) How does IOTA 2.0’s congestion control mechanism, which allocates throughput based on users’ Mana holdings, ensure consistent and predictable fees while preventing unpredictable delays in transaction processing, as typically seen in congested blockchain networks?
Andrew: Firstly, our congestion control doesn’t use a priority queue. Priority queues are the primary cause of unpredictable fees and delays in most blockchain networks, i.e. validators choose the highest-value transactions to include. In IOTA 2.0, we set the fee at the protocol level using a mechanism very similar to Ethereum’s base fee (EIP-1559), but we don’t allow any additional priority tip on top of that fee. In times of high congestion, transactions are prioritized based on the total Mana holdings using a DRR scheduler. The DRR scheduler offers far more consistent and predictable delays than a priority queue in times of high congestion but comes with the trade-off that you can’t “buy priority” in times of high congestion, you have to work with the rate you have available based on your total Mana holdings.
11) The section about the scheduler mentions that it iterates through block issuers based on their deficit, which is proportional to their Mana. How does this approach eliminate the need for users to bid for transaction priority, ensuring efficient block processing without excessive fees or delays?
Andrew: There is simply no way to increase the priority in the scheduler for your transaction in times of high congestion. The DRR scheduler works like a bucket with holes in it for each account holder, and the size of the hole is proportional to your Mana holdings, so your transactions get through at a rate proportional to Mana holdings. There is no way around this by paying extra, it’s baked into the protocol. We have done lots of research on scheduling policies and this one provides by far the best consistency, fairness, and security properties so that user experience won’t suffer as it does in other projects with unpredictable priority fees in times of congestion.
12) Is there a cap on the number of positions for IOTA 2.0 node validators, and what is the maximum number of positions in the validator committee？
Andrew: Anyone can register as a validator, and there is no limit on the number of registered validators. However, there is a cap on the size of the validator committee (the active validators) in any epoch (which is roughly one day), and that is a protocol parameter. We have a parameters taskforce currently determining the optimal combination of parameters like these for launch, but there will probably be around 50 validators per epoch in the committee. Selection of the validators for the committee will initially be based entirely on the staked tokens, i.e., only the top stakers for the epoch will be included in the committee each epoch.
13) What level of MPS/TPS was achieved during internal stress tests and what level would you expect for the testnet? Are there any (hard/soft) caps in place? Could you please provide an overview of the expected finality times? Are they fixed or might they evolve over time (if dependent on parameters)?
Piotr: We haven’t performed any actual stress testing yet, as the software hasn’t yet reached a state to test those kinds of things. Internally on our local machines, we’ve been running up to 500 BPS; however, this number doesn’t say much on its own because those were simple data blocks that didn’t execute the VM and didn’t mutate the ledger. We have yet to design a proper stress test, taking into account different block and transaction types, and hardware on which we’re going to run those tests. The only cap is the scheduler rate, which has not yet been chosen. Finality (meaning that something will never, under any circumstances be reversed) will be in a matter of minutes, as this happens on the commitment level, and generating a commitment is delayed by a minute. We will, however, have a confirmation flag on the block level as well, which will also mean that a supermajority of validators have seen the block, and under normal conditions that’s going to be as good as final. However, we don’t call this finality, because there are some edge conditions under which such blocks could, in theory, be reversed. This is extremely unlikely though. This paper analyzes the confirmation time. It doesn’t use the latest version of the acceptance gadget, but the dependencies still hold.
Community Member: Adding on to this, the hardware plays a big factor in the throughput a node will reach. When we spam-tested Chrysalis, smaller servers could sustain a constant 1200, and bigger servers had no problem going way over 3000. Pure MPS numbers don’t mean anything. It will be a tester effort to find out what bottlenecks the RC will have and how to mitigate them. Back then, starting at between three and four vCPUs, disk would be the limiting factor.
Piotr: Right now we hope the IO won’t be a major problem as we operate mostly in memory, but we will have to find out anyway what the actual bottleneck is.
14) After the launch of IOTA 2.0, what advantages will we have compared with other cryptocurrencies (e.g. ADA, SOL)? What are the disadvantages? In the meantime, after the launch of IOTA 2.0, what is our roadmap for the next steps? What directions need to be taken after IOTA 2.0 to strengthen it?
Andrea: IOTA 2.0 stands out in the DLT landscape primarily because of its unique data structure where the Mempool is inherently integrated into the data structure itself, unlike traditional blockchains. This integration facilitates continuous and parallel voting on transactions throughout the network, which enables a more dynamic and fluid consensus mechanism compared to the block-by-block approach of conventional blockchains.
The seamless inclusion of the Mempool within the Tangle also means that conflict resolution becomes a more streamlined process. There is no waiting for the next block to address conflicts; they are resolved in real time as they arise, allowing for a system that is more responsive and agile.
Looking towards the future with the advent of extended Layer 1 programmability, IOTA 2.0 is poised to mitigate critical issues such as Miner Extractable Value (MEV). Traditional blockchains are susceptible to MEV because miners can manipulate transaction order within a block to their advantage, potentially destabilizing the network and introducing unfairness. IOTA’s architecture naturally avoids such pitfalls as it doesn’t rely on block or miner-based transaction ordering, which could lead to a more stable and equitable network environment. In a nutshell: block proposer and builder separation arises from the data structure itself instead of being an addendum on top of an existing mechanism.
15) How decentralized will the validator committee really be if the committee consists of for example 10 of the richest wallets or if all people delegate to a few validators? What I was hoping to see with IOTA 2.0, is a system where, in theory, multiple small validators can outvote the largest validator. For example, 1000 nodes with 100,000 IOTA each have the same voting weight as one node with 100,000,000 IOTA. The more validators, the more secure the network is. I was hoping to run my own IOTA node and to help secure the network. But if I’m not one of the top IOTA holders or a famous community member who gets a lot of delegations, my node will never be included in the validator committee, and therefore my node doesn’t raise the strength and security of the whole network. Is this correct?
Nikita: That is a good question as it is about true decentralization. In the current version of the protocol, the committee will be formed by taking active validators with the most stake. The size will probably be around 32 validators. So, if you don’t have enough delegation plus your own staking, then you might not be included in the committee. We reduce the power of the richest validators by capping the voting weight of each committee member. In general, to improve decentralization, we expect to have a fair randomized lottery in the committee selection process in a future upgrade. Then the chance of all stakeholders to sit in the committee will be fair and proportional to the amount of their stake.
Community Member: Doesn’t anything but one token = one vote (e.g. linear relation between tokens and voting power) open you up to Sybil attacks? Since one user with 100 IOTA can easily make 100 accounts with one IOTA. Reducing the power of the richest validators only works if they are honest (and in that case, who cares?). If they aren’t honest, they can easily work around that.
Nikita: There are two properties that we are talking about here. The first property is to have a committee selection procedure that is robust to splitting and merging staked tokens, i.e. it gives a fair opportunity for everyone to participate in the committee. The second property is for smaller users with smaller stakes (100 users with 10 staked IOTAs) to be able to outbid the influence of the wealthiest stakeholder (one user with 1000 staked IOTAs). Satisfying the first property negates the second property because the richest user as the richest user could create 100 entities with 10 staked IOTAs and control them all. But we can achieve certain tradeoffs between both properties, e.g. we can make an expected voting weight of a user fair (proportional to the staked tokens) and cap the power of every single user in the committee.
16) On a similar note, it seems like network bandwidth is a limiting factor for every DLT if it is truly distributed on a global scale. Decreasing the messaging overhead, allowing asynchronous transactions and parallel transactions, optimizing node software to multithread, and keeping compute requirements low are ways to increase network throughput. Yet, in any DLT, a supermajority of the network still needs to see a transaction before it is confirmed, This makes network latency a big factor for confirmation and finalization. Currently, slot commitments in IOTA 2.0 occur at 10-second intervals and this provides finality. Before this 10-second interval is a ‘confirmation’ probabilistic, and after a slot commitment is it deterministic? The deCOO is running at roughly two-second intervals on Shimmer. This provides a ‘clock’ similar in some ways to the slots on IOTA 2.0. Could the slot commitments run at intervals of less than two seconds, or does it need to be longer to allow for heterogeneous networking conditions or other factors? Could there be cases where confirmed but not finalized transactions would be ‘good enough?’
Nikita: In the current protocol version, the confirmation process is deterministic, assuming the network remains synchronous for a minute or so and experiences no unexpected congestion. This assumption is generally reasonable in most use cases; for instance, it is totally fine to rely on confirmation or even acceptance when the transaction’s value is relatively small.
Issues may arise when the network becomes asynchronous. Specifically, the only scenario where a confirmed transaction might not transition to a finalized state is if, immediately after confirmation, the network becomes fully partitioned, resulting in various commitments made by validators. In cases involving slow or adversarial validators, it’s possible that a commitment might lack the confirmed transaction, despite the supermajority of the network acknowledging its confirmation. If a network disruption occurs, there is potential for the network to adopt the commitment chain of these slow or adversarial validators, excluding the confirmed transaction. While we haven’t observed such cases in our test scenarios, it’s theoretically possible to design artificial examples where this issue could occur.
We can make slot duration as small as possible, but this will not completely solve the “slow finalization” problem since nodes don’t produce and reveal slot commitments immediately after the slot ends but after specifically designed periods. These delays are important for consistency because they ensure that all honest nodes produce the same commitments for slots under synchronous settings. You can read more details about the consensus flags in our Wiki article on consensus.
17) What were the main barriers that caused so much delay in IOTA 2.0? What’s your least favorite part of IOTA 2.0 that you think needs to be optimized?
Andrea: The properties that arise from our data structure are awesome: common and causal Mempool is directly part of our data structure. But our data structure is very hard to get right! The DAG arising from the blocks in the Tangle needs to logically co-exist with a nested and orthogonal DAG living within it: the UTXO DAG. This represents the causality of the spends involved in the transactions observed on the Tangle. While these processes are, to some extent, orthogonal to each other, they must also be coordinated for convergence to arise across the network. The interplay between this interaction and the tip selection mechanism required us to reconsider very fundamental concepts: time perception, tip selection, etc.
The current IOTA 2.0 protocol is a result of a long series of failed ideas and refinements of successful ideas. I believe that the way we internally model conflict preference across conflict sets could be simplified by the introduction of new handy primitives we introduced in other sections of the code. In addition, the “explicit voting” via specialized reference types that every block carries came into existence because of the need to identify portions of the Tangle to be orphaned; unless this need proves itself useful again in the future I believe that a simplified and “implicit” voting mechanism is possible: reducing complexity in the tip selection and booking components.
18) How is the strategy of holding and selling Mana in IOTA different from the conventional approach of selling block reward tokens immediately? Given that block producers in traditional blockchains like Ethereum can (1) use ETH rewards as a proxy for network throughput by bidding up GAS prices and (2) delay selling their rewards in anticipation of higher demand and prices, is there an aspect of Mana’s design that inherently differs or offers advantages in this regard?
Andrew: There are two ways that our approach is fundamentally different. The first is that the rewards in question are not the base token, and the second is that there is no straightforward option for “bidding up” the price of access. The only way you can increase the price of issuance single-handedly is by congesting the network, which is tremendously expensive and completely unfeasible. Delaying selling rewards in anticipation of higher demand is something that would be no different from other cryptos.
Billy: Also, our system encourages users to hold Mana rather than dump it: Mana is not worth anything until there is use of the ledger. When there is use, there is adoption, and the system can sustain the value extraction. In most DPoS systems, people buy coins, earn some rewards, and then cash out. So the systems are constantly bleeding value.
Community Member: This however does raise the question if users want to run a validator since it is essentially gambling for higher prices, as the rewards won’t be enough to pay for node operation. Also, there might be competition with other income methods like yield farming.
Billy: There are certainly some tradeoffs. But this is a tradeoff for people who want to be early adopters. The first Bitcoin miners had no guarantee they weren’t wasting their time. But in the end, we want to encourage people to be validators who want to use the system and want to stick around rather than people who want to make a quick buck.
19) You are introducing a new asset, “Mana”. Now ledger, clients, and the end-user should have to take care of tracking more complicated stuff to be able to use the protocol. Do you think this can be hidden from the end user?
Piotr: It can be hidden in part so that the regular end-user doesn’t need to see how much Mana they need to issue a block and what are the generation and decay factors and all the other complex stuff – so a wallet could only show something like “you need to wait five minutes to generate Mana to issue another block” or something like that. Of course, that will depend on the wallet implementation but we will strive to make it as seamless as possible.
20) Could other crypto projects (even blockchains) use the IOTA 2.0 consensus mechanism?
Nikita: Yes, other projects could potentially use ideas from our consensus protocol (e.g. our confirmation rule requires only three network trips to achieve confirmation, which is the bare minimum). One important design choice of our consensus protocol is dynamic availability, i.e. even under serious network disruptions and many validators being offline, the network constantly updates an available ledger. To the best of our knowledge, this feature is currently not present in other DAG-based protocols (except PoW-based Kaspa, which does not have absolute finality).
21) Is the work of the research team finished or are you working on something else? Are you planning to change the protocol again after IOTA 2.0?
Billy: The research work for IOTA 2.0 is done, but the protocol will most definitely change. For instance, we’re already planning to implement cryptographic sortitioning in the committee selection mechanism. There were several ideas that we wanted to include in IOTA 2.0, but we had to draw a line in the sand so we could deliver. In the future, we want to get into the pace of smaller protocol updates and continual maintenance, rather than massive projects like Coordicide.
Piotr: As you can see on the project board for ‘iota-core’, there are a lot of nice-to-have issues. However, these changes won’t come as a big release that turns the protocol on its head, but rather in smaller releases. One such update will be changing the committee rotation algorithm to something more robust than taking the top stakers.
Community Member: Now that IOTA 2.0 is decentralized, how are you going to push future changes to the protocol? Are you going to create forks, use the discussions of the tips, etc.? You need to get acceptance of those changes from the community using the protocol.
Billy: We have an on-chain protocol update mechanism, like other chains. For this initial version of the protocol, we went with a super simple mechanism: after a new protocol version is proposed, validators can signal their support. If enough validators indicate enough support for enough time, then everyone switches to the new version.
22) With all the changes made to IOTA 2.0, how much have we deviated (if at all) from the original machine-to-machine economy vision and being the security layer for large-scale Internet of Things? Doesn’t the prerequisite of needing Mana pose some adoption hurdles to ensure sensors and small devices get adequate throughput during periods of congestion?
Billy: We have expanded on this vision. The M2M economy is not here yet, so it makes sense to focus on some things in between. Also, a chain that can be an M2M economy chain is capable of so much more. In the Wiki, we outline our vision of Digital Autonomy for Everyone, a much broader concept that will not only enable the M2M economy but also capture more use cases.
Community Member: Understandable, the M2M vision is a longer-term play, and a network capable of doing that could also be so much more. My question was more to understand if some of the constraints for small footprint and light devices in the M2M/IoT scenario would be easy to handle with the new Mana system to guarantee throughput. Setting up tons of devices and preloading them with an amount of IOTA to generate Mana to guarantee throughput seems a bit of a stretch to me and I’m sure there are better ways of doing that. I was wondering if you or anyone at the IOTA Foundation see that as an adoption issue going forward and if there exists a simpler solution to do it? In other words, what would Mana or throughput management for small edge devices look like?
Billy: Mana is great for IoT devices since all they need is a wallet. Also, using our account system, you can have a central controller that holds the Mana and just lists the PKs that can spend it. So it is actually a very flexible system.
23) How partition tolerant will IOTA 2.0 be in a scenario where parts of the network continue to function offline or on an intranet and then attempt to rejoin the main Tangle later?
Billy: A situation like this can happen, and there are different scenarios:
Nonvalidator nodes are cut off from the main part of the network. In this case, the nodes will stop accepting stuff and thus not issue and commit anything. After they’re re-connected, they receive all the blocks and commitments they’ve missed and continue normally.
A minority of the committee is disconnected. In this case, a commitment fork takes place and acceptance continues in both parts, but finality can only continue on one or none of the forks, never two. In this situation, the minority partition will have to switch their chains, discard all the blocks and commitments that were issued when the partition was taking place, and accept the majority partition’s version of the Tangle and the commitment chain.
Community Member: So would it be accurate to say that IOTA 2.0 is not really partition tolerant as originally envisioned? On a simpler note, would it be right to say, as per the CAP theorem, partition tolerance has now been given less priority over consistency and availability of data? This would also mean that “offline” or “isolated” sub-Tangles that orphan from the main DAG cannot function in a silo without reconnecting, correct?
Billy: No, IOTA 2.0 is definitely partition tolerant. We used some ideas that are common in the ecosystem to deal with the CAP theorem, such as explained in this blog post.
24) Will Mana have any role to play in an account’s (non-consensus) governance voting power?
Billy: This isn’t completely decided at this point – there are some problems with using it like that. Mana as a non-soul-bound resource has the same drawbacks as using a base token (IOTA, SMR) as voting power, because it can be bought and transferred, so it doesn’t reflect the reputation of an account well. Having a soul-bound resource could allow us to use it as a reputation score, which then could be used as a voting power because it cannot be bought or transferred.
25) How often is Mana decay and generation applied? Because if the decay exceeds the generation, a user using a hardware wallet (which creates a potentially significant delay between the network state on which the wallet generates the payload and the time the signed payload gets issued by an issuer) might face issues if they want to take their Mana with them.
Piotr: Mana is generated every slot, but it’s decayed every epoch – in the implementation, it doesn’t mean that we iterate through all the accounts and outputs and update them as that would be costly. Instead, whenever we need to read the Mana value of an account/output, we dynamically calculate the decay and generation. I’m not sure if I understand the other part of the question correctly, but it’s completely OK to create a transaction and issue it some minutes or hours later (with some exceptions where the transaction requires some context). The transaction contains a slot index in which it was created, and that value is used to calculate the generation and decay of Mana, so if you issue that transaction the next day, the potential Mana is generated only up to the slot index that is contained in the transaction.
Darcy: As a complementary comment: Mana is generated linearly (to time and tokens) and decays proportional to the Mana held (at a global fixed rate). This means that a user’s total Mana is always increasing unless they move funds (that will not generate Mana for them anymore) or burn Mana to issue blocks.
Community Member: That was exactly the case I thought of when writing this question. I assumed a whale doing a large Mana sell to an account with very low token holdings. In this case, the decay would be higher than the minimal amount and the user wouldn’t be able to send a transaction constructed in a past epoch, assuming it instantly applies. Backdating would essentially give a way to undo Mana burn (since the generation would be re-applied). This might also allow you to game the system in some ways.
Piotr: Not necessarily. our Mana would decay less but also generate less. And the next transaction that you don’t backdate will decay all the Mana that you skipped previously, so the decay will always get you.
26) How can Mana be converted into Block Issuance Credits (BIC)? Is there a different answer to the above question if Mana is stored in BIC form instead of on a UTXO?
Piotr:It can be converted into a transaction. If you spend an output that has some stored and/or potential Mana, you can allot it to an account within a transaction which turns it into BIC. Regarding the second question: No, all Mana is decayed at the same rate.
27) Why would I stake/delegate with one of the smaller validators? Doesn’t our staking model encourage us to delegate to the 50 biggest stakers? How do you encourage creating new smaller validators?
Andrew: Although our initial implementation of committee selection will be based on top stakers only, we plan to implement randomized committee selection in a future update. With randomized committee selection, all validators, no matter how small, will stand a chance to be selected. For the sake of simplicity at launch, we will begin with only top stakers though.
So as you have said, it would be advisable for delegators to distribute their funds across the top 50 stakers in this initial setup.
28) Do I as a delegator have any risks in getting my tokens locked if the validator misbehaves?
Andrea: No you don’t. Delegator funds are also not locked: they are simply used as part of the validator selection process, as they are counted as part of the stake function for the candidate to be selected. However, if you decide to undelegate your funds before the epoch’s end you will not be eligible for rewards for that epoch. As you can see, you have an incentive to delegate to a validator that is doing its job, because if that validator does not you will not reap any rewards!
Community Member: So if I delegate, do I automatically stake? Could you briefly explain the difference between staking and delegating?
Andrea: No, delegation is a very separate process from staking. A staker locks its funds and has to perform validation duties if selected as part of an epoch’s committee.
On the other hand, a delegator can only delegate tokens to a staker and has no specific duty. The only role of the delegator and its funds is to incentivize the validator’s duties: the more delegations a validator can attract the bigger the rewards they and their delegators can obtain.
29) Which feature still needs to be implemented for IOTA 2.0? How is testing going? Is there still a lot to do on that side?
Piotr: As you can see on the project board on GitHub, all the features for the first release were recently implemented and we’re just refactoring and testing code here and there. We don’t plan to implement any new features before releasing the testnet.
As for the testing, some Nil Pointer exceptions and memory leaks have already come up, but that was to be expected. We currently don’t see any roadblocks or big problems.
Community Member: What percentage of Code coverage do you target? And how much is already done?
Piotr: It’s not the test coverage that we aim for, because a big part of the code is already covered with tests. The hardest problems arise when the node is running and suddenly some things align in a certain way and it crashes. It’s mostly these kinds of problems that we want to focus on, as those are close to impossible to find with basic unit tests.
Community Member: In that case what is concretely missing for you to run the public testnet? By letting the community participate, you could find such edge cases faster because more people are using and testing the network.
Piotr: Because it’s additional overhead for us. Currently, we want to fix problems that we find ourselves so that you don’t experience them in the testnet. Some of those bugs could crash the whole network, so as you remember from the previous devnet that we had last year, after every bugfix we had to do a release with a fresh snapshot, etc. Which I’m sure was also annoying for you.
Community Member: And what are the biggest hurdles currently?
Piotr: We have found some bugs that are hard to reproduce and debug. Some of them might be caused by the chain manager, so we hope that the reactive chain manager will solve some of those, as this has fixed some hard-to-catch bugs in other places (we had a problem with marking blocks as solid, which happened once in a couple of weeks of testing; using the reactive approach fixed that).
30) Andrew mentioned in a subthread that the epoch length will be roughly one day. What is the reason for this time to be rather lengthy compared to other blockchains? Long epoch times make it easier to target a validator, either via network attacks or socially, for example by bribing them. Would this also give a corrupt committee (even when the malicious actors do not have 33% of the tokens, they might have luck in a future random selection) more time to deal damage?
Billy: Currently, we are not robust against malicious committees. The reason why is that (1) we currently take the top 32 stakers, and (2) we structured the incentives so that the stake will be evenly balanced amongst these validators. As such, we will have all the stake securing every committee, and so a malicious committee means that one-third of the stake is malicious!
We plan to implement a more sophisticated committee selection mechanism via cryptographic sortitioning. The reason this is not in the current version is that we didn’t want more delays caused by mucking about with cryptography
Community Member: Would shortening the epoch time to e.g. one hour cause issues with the current system? Too much overhead?
Billy: Yes, there is a lot of precomputation at epoch boundaries, namely computing the rewards distribution. This makes it easier to do this less frequently. We could maybe do it once an hour, but we didn’t see a reason to change it. Also, it’s nice for the epoch to be a power of two slots. We chose (2^13) 10s since it is close to a day and thus somewhat intuitive.
Consensus and access are key aspects of DLT security and protection against malicious nodes. IOTA 2.0 will employ committee-based consensus, where committee selection hinges on staked value to deter attackers. State reversion is guarded via conflicting opinion chains and supermajority consensus. For access security, the protocol introduces token-generated Mana and the Scheduler, thwarting spam by requiring tokens for block issuance, but without introducing fees. A decay factor ensures equitable Mana distribution, while the Scheduler ensures fair block allocation.
Security has been the major point of concern in DLT since its conception. In centralized monetary systems, fees are paid so banks and governments are responsible for keeping our money safe. This consumes the user’s funds and limits their control over their assets. This goes against IOTA 2.0’s vision of Digital Autonomy for Everyone.
To build the future of the Web3 economy and give users autonomy over their assets, the Tangle (the underlying data structure of the IOTA DLT) needs to be secure against all sorts of attacks and exploitations, and this blog post shows how we will achieve this with IOTA 2.0.
What does it mean for a DLT to be secure? It means that someone who wants to harm or exploit the network will not be able to do so by any means using the network.
Among the many targets of an attack on a DLT are consensus and access. Let’s check what kind of worries exist in these two components.
Consensus security: Preventing manipulation
Consensus is the basis of DLT security. Making sure nodes reach the same state of the ledger is equivalent to preventing value from being improperly generated or extracted from the network. Achieving a common state is just part of the objective, as making sure that this common state can’t be reverted is of equal importance.
If a malicious node can decide what is included in the consensus, it could censor nodes at will, indefinitely delay the consensus mechanism, and freeze network operations. Additionally, the risk of double-spending emerges if consensus is susceptible to reverting. To counteract these threats, the following questions arise:
How does the protocol prevent malicious nodes from deciding which transactions to accept?
How does the protocol stop malicious nodes from preventing other nodes from achieving consensus?
The IOTA 2.0 protocol addresses these concerns through its committee-based consensus. By basing committee membership on staked value, attackers will need to invest a very large amount of money in the network (hence reducing the motivation to harm it) or will have negligible chances to be on the committee. Even in the improbable scenario that a malicious validator becomes a committee member, the weighted voting system means that their voting impact will be so low that they can’t decide on the ledger state nor delay voting by other nodes! Furthermore, the rotation of the committee also means that this malicious node can’t impact the network in the long term.
If, on the other hand, a malicious node carries a very high stake in order to manipulate the consensus, the effects of any manipulation would end up harming its own stake as the network loses value with any successful attack. In other words, no one can manipulate the ledger without losing value themselves.
The protocol also introduces a mechanism for reverting states in case of erroneous decisions taken due to communication problems. Changing the ledger state is difficult: By monitoring slot commitment chains and the voting weight of each possible chain, nodes switch opinions when a conflicting chain’s weight massively overtakes the current chain. For a standard node, this means that its current state disagrees with an overwhelming majority of the committee members (two-thirds of the committee’s voting weight, or what we call a supermajority). If a malicious node can’t impact a single consensus outcome, it definitely can’t impact the state reversion process.
Access security: Ensuring fairness for all users
Access is the other important factor in DLT security. Here, “access” refers to the right and ability of a node to use the network, generally by issuing new blocks with data that aims to modify the ledger state. One of the main concerns of any user is that they will be able to use the network in a way that is fair (“fair” in this context means that users receive their share proportionally to their contributions to the network).
Thus, the protocol has to ensure that a malicious node can’t issue an unfair share of blocks (and thus prevent other nodes from being able to issue their fair share of blocks) nor congest the network in order to halt its operation.
So when talking about access, the two main questions are:
How does the protocol prevent malicious nodes from issuing an unfair share of blocks?
How does the protocol prevent malicious nodes from spamming and congesting the network?
The IOTA 2.0 protocol addresses these points using two primary tools of congestion control: Mana and the Scheduler.
As described in Understanding Congestion Control: Regulating Access in a Permissionless System, users burn their Mana in order to issue blocks. A block that is received by a node but hasn’t burned the required Mana will not be processed. This means that a spammer must hold a substantial amount of Mana to issue a large quantity of blocks. However, Mana’s decay factor curtails long-term accumulation, impeding the accumulation of excessive Mana for malicious purposes while the Mana Burn system adapts the amount to be burned over time, further limiting the potential for attacks from malicious nodes. This ensures that only legitimate users contribute to network activity.
The Scheduler complements this process by ensuring fair block allocation. It matches block issuance with the proportionate stored Mana, thus curbing the potential for malevolent users to exploit the system.
For more on IOTA 2.0’s congestion control, visit our wiki.
IOTA 2.0: Enhancing DLT Security for Web3 Autonomy
In conclusion, the IOTA 2.0 protocol will tackle DLT security concerns in two key aspects: consensus and access security.
Consensus security helps prevent manipulation and maintain the integrity of the ledger. IOTA 2.0 implements a committee-based consensus system, where committee membership is based on staked value. This makes it economically unfeasible for attackers to manipulate the consensus, and even in rare cases where a malicious node becomes part of the committee, their influence is minimal, ensuring the network’s integrity and stability.
Access security ensures fairness for all users in terms of their ability to use the network. The IOTA 2.0 protocol leverages Mana and the Scheduler to regulate access and prevent malicious nodes from issuing an unfair share of blocks or congesting the network. Mana’s decay factor and the adaptive Mana Burn system limit the potential for malicious accumulation, while the Scheduler allocates blocks fairly based on stored Mana, ensuring that legitimate users can contribute to network activity seamlessly.
In essence, attackers cannot spam, indefinitely congest the traffic or issue more blocks than they deserve. IOTA 2.0 promotes a fair and robust allocation where invested users can use the network feelesly, and all in a secure environment!
Published on November 13th, the next article in this series of blog posts will look at Dynamic Availability (the system’s ability to continue to accept or confirm transactions despite any number of validators crashing) and describe how IOTA 2.0. enables you to find your own balance between caution and optimism according to your needs.
TL;DR: The article discusses blockchain technology limitations and how Directed Acyclic Graph helps IOTA 2.0 overcome these challenges. While blockchain’s Proof of Work mechanism has flaws like high fees and slow processing, DAG benefits enable parallel and stream processing, the elimination of middlemen, and the involvement of all users in consensus. DAGs’ collaborative approach aligns with IOTA’s vision of building the foundation for the future digital economy, empowering users, while achieving higher efficiency.
IOTA will always be one of the first associations that comes to mind when anyone thinks about Directed Acyclic Graphs (DAG). But the early adoption of the DAG data structure isn’t an arbitrary choice, nor the result of an urge to just have something different. DAG was and still is the only choice for IOTA to achieve its objective of Digital Autonomy for Everyone. This blog post explains why this is true; but first, for some context, let’s explain the fundamental problems that have plagued blockchain since its inception!
DLTs, blockchains, and the beginning of everything
At the beginning of the Distributed Ledger Technology (DLT) adventure, the Bitcoin solution to updating the ledger was simple but effective. In a competitive race against time, a hard-to-solve cryptographic puzzle would decide who had the right to write the next block in the ledger and validate the ledger’s history, with the puzzle-solver earning rewards and fees.
This Proof of Work (PoW) design combines the consensus mechanism (which decides which information enters the shared ledger) and the access module (which decides who has the right to publish on the network) into a single element: the mining of new blocks.
Despite having the advantage of simplicity, PoW has its share of flaws. It incentivizes competition between users to have their transactions included in the ledger, which creates fees that exponentially increase with network demand. The work of unsuccessful miners is wasted and the “longest chain wins” approach leaves miners uncertain over whether or not their transactions will eventually be included in the accepted longest chain.
This leads to protocols requiring a long streak of blocks mined sequentially in a chain to guarantee acceptance for a block, which dramatically slows down the inclusion of information in the ledger.
From Proof of Work to Proof of Stake
These blockchain technology limitations inspired a quest to bypass the problems and scale blockchains to broader proportions. The most relevant innovation so far has been the development of Proof of Stake (PoS) blockchains, which avoid expensive computational work. In PoS systems, users only need to lock their tokens as collateral (in other words, they stake their tokens) to join a lottery to mine the next block.
While this approach improves energy consumption it does not improve the central problems of blockchain:
Blocks need to be processed in sequence, so the validation process is concentrated in batches inside blocks, which creates wasteful idle periods for validators not making use of their hardware;
Users are dependent on validators to publish their transactions in the network, which creates fee and value extraction problems.
Clearly, a change was required to align DLTs with the requirements of future protocols, and, while building on existing blockchain designs was always a possibility, the walls and bottlenecks that could be found would have been too detrimental to what the IOTA Foundation aims to achieve.
We want to build the base of the Web 3.0 economy, to empower digital autonomy and adopt a self-sustainable ecosystem. This means that adopting blockchain, with its obvious and fatal flaws, was never considered for the IOTA network. Instead, we built the Tangle, a different data architecture based on a DAG structure, which enables more creative solutions and higher efficiency in helping us achieve our vision.
The benefits of DAG
The Tangle enables a network design where new blocks can approve multiple older blocks without having to form a singular chain. Instead of just having a singular chain of blocks at predefined intervals, blocks can be attached at any point in a graph of interconnected blocks, pointing in one direction, thereby creating a Directed Acyclic Graph, or DAG. “Acyclic” in this context means that it can not reference itself and form a circle. So instead of a single fishing line into which knots are made at predefined intervals, the IOTA Tangle can be seen as a fishing net in which knots can be made at any location, with the net becoming dynamically wider or narrower, based on demand.
The Tangle removes many bottlenecks that hinder blockchains from being used on a meaningful scale. IOTA makes full use of the DAG benefits to avoid these bottlenecks:
Parallel Processing: In DAG-based networks, blocks don’t need to be processed in order. This enables parallel processing, which means that the processing and validation of new transactions are evenly spread over time, reducing idle time for nodes. Furthermore, the lack of sequential dependence enables many transactions to be processed at the same time, which greatly increases the network’s ability to handle heavy computations and congestion.
Stream Processing: The validation process is always working, making better use of the validator’s hardware and allowing confirmations to be achieved much quicker than otherwise. The lack of idle time optimizes the use of network resources, achieving the best performance for any invested hardware.
No middlemen: IOTA users can issue their own blocks with their own transactions without the need for mining or relying on value-extracting middlemen. The lack of extra actions in the issuance process makes every application much more efficient and faster, prevents censorship, and preserves the value of assets.
All users contribute to consensus: Last but not least, IOTA’s use of a DAG enables more distributed validation systems, where all users can contribute to the consensus, whether by issuing blocks that create the approvals used to propagate opinions, by delegating their voting power to validators, or by issuing validation blocks that determine the final version of the ledger. Everyone plays a role and is rewarded for it.
The DAG-based design, therefore, follows a collaborative approach that makes the most of individual contributions, instead of a competitive approach requiring everyone to expend power but reward only a single actor.
Building on a DAG isn’t an arbitrary choice: it allows us to build our vision, empower the community, offer our users autonomy, and have the capacity and performance to be the basis of the future digital economy.
Up next in Part 11 of this series of blog posts, published November 10th, we look at what makes IOTA 2.0 secure.
TL;DR: The IOTA and Shimmer communities have voted to accept the governance proposals [IGP – 0001] and [SGP – 0006]. The communities have agreed to support the Shimmer Community Treasury Grant Committee’s proposal to optimize the specification that defines their way of operating and to receive a budget of IOTA tokens to operate an IOTA Community Grant Program. This blog post presents the final verified result of this vote.
From October 12th to 27th, the IOTA and Shimmer communities voted on the governance proposals [IGP – 0001] and [SGP – 0006] (read the announcement here). These proposals were submitted by members of the Tangle Community Treasury DAO as a result of their learnings in operating the Shimmer Community Grant program since its inception in April this year.
We’re pleased to share the final results of these votes in which both communities have given the green light to the proposals.
Proposal [IGP – 0001]: Tangle Community Treasury Grant Committee Revision
The proposal suggested:
Giving 10 million IOTA tokens from the IOTA Community Treasury (54.8 million IOTA tokens as decided in the 2022 Build/Burn vote) to the Tangle DAO Grant Committee so they can launch an IOTA Grant Program. The IOTA tokens shall be given to the Committee once an IOTA EVM Chain makes the IOTA Community Treasury available.
Answer 1: Yes, approve the proposed framework revisions
Votes received: 17,930,983,583,402,792 (96.14%)
Answer 2: No, I don’t want to implement the proposed changes
Votes received: 582,511,637,632,794 (3.15%)
Answer 3: Abstain
Votes received: 138,168,183,315,125 (0.74%)
Participation in this vote: 5.21% of the maximum achievable votes.
Proposal [SGP – 0006]: Tangle Community Treasury Grant Committee Framework Revision
The proposal suggested revising the specification and include changes to:
Enable the Tangle Treasury DAO to use unused assets to benefit the Shimmer and/or IOTA ecosystem and community.
Give the Tangle Treasury DAO the right to create and sign contracts with grant receivers.
Update the specifications to make it easier for community and committee members to understand.
Change wording, edit grammar, and include mentions of the IOTA Community Treasury in the specification.
Answer 1: Yes, approve the proposed framework revisions
Votes received: 15,451,760,086,140,298 (99.56%)
Answer 2: No, I don’t want to implement the proposed changes
Votes received: 21,600,109,924,392 (0.14%)
Answer 3: Abstain
Votes received: 47,084,504,636,160 (0.30%)
Participation in this vote: 7.07% of the maximum achievable votes.
Our Community Node operators have verified both proposal counts and approved the correctness of the ballots.
What’s on the horizon?
The Tangle Community Treasury DAO is now set to operate under the revised specification.
A budget of 10 million IOTA tokens from the IOTA Community Treasury will be allocated to kickstart an IOTA Community Grant program once these tokens become available.
We extend our gratitude to participants and voters in both communities. Your active involvement in the governance process is invaluable. Together, we’re shaping the future of the IOTA and Shimmer ecosystems.
TL;DR: IOTA 2.0 uses slot commitment chains to achieve consensus and synchronization of its distributed ledger. Each block contains a cryptographic commitment to a specific past time interval called a “slot”. These slot commitments form a chain that ensures nodes agree on accepted data, aid in dynamic availability and fork resolution, and drive finalization for added security. Overall, slot commitment chains play a crucial role in creating a reliable, decentralized, and scalable network for IOTA 2.0.
In any distributed ledger, regular checkpoints are crucial for achieving consensus on an accepted and finalized state – in other words, checkpoints help sync the different records of a ledger among its nodes. Checkpoints also enable data to be compressed into a local snapshot and any unnecessary information to be pruned. IOTA’s solution to create such checkpoints is slot commitment chains.
This advanced blog post dives into the technical nitty-gritty of slot commitment chains and how they help achieve finality by syncing the ledger.
Introduction to slot commitment chains
Every block issued by a node includes a reference to a slot commitment, which is a cryptographic commitment to a specific time interval in the past known as a “slot”. These slots are precisely defined 10-second intervals that do not overlap with one another. The slot commitment encapsulates all the crucial information about that slot, including accepted blocks and transactions. It also commits to the preceding slot’s commitment, effectively forming a linked sequence known as a “slot commitment chain”.
When nodes agree on a slot commitment, they essentially concur on the data accepted by the network until the end of that particular slot. In this way, slot commitments function as checkpoints that nodes can use to synchronize their ledger. Slot commitments and the slot commitment chain allow nodes to synchronize their local versions of the ledger by comparing them with each other. If they are identical, nodes know they have the same information. This blog post explores additional functionalities based on slot commitments.
Structure of slot commitments
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.
A slot commitment uniquely identifies a committed slot and its contents. Analogous to a block header in a blockchain, each slot commitment references the commitment of the previous slot, creating a slot commitment chain that extends back to the Genesis commitment.
Block header
As shown in the figure below, the slot commitment is contained in the block’s header. This design makes it easier to create an attestation of a slot commitment – a cryptographically verifiable list of nodes that agree on the history of the Tangle up to the respective slot.
Commitment of slot content
An important ingredient of a slot commitment, the Commitment of Slot Content is a hash value calculated as the Merkle Root of the binary tree with the following leaves:
Tangle Root: The hash root of a sparse Merkle tree that contains all accepted blocks issued within the slot. This serves as a statement of accepted blocks in the Tangle. It is used to prove the inclusion or absence of accepted blocks.
State Root: The hash root of a sparse Merkle tree containing all Unspent Transaction Outputs (UTXOs) at the slot’s conclusion. It is used to prove the existence or absence of UTXOs.
State Mutation Root: The hash root of a sparse Merkle tree containing accepted transactions in the current slot and serving as proof of state mutation from the prior slot to the current one. It helps to prove the inclusion or absence of accepted transactions.
Accounts Root: The hash root of a sparse Merkle tree containing Block Issuer (Block Issuance Credits, Issuer Public Keys, Expiry Slot) and staking data (Fixed Cost, Stake End Epoch, Staking Amounts) for accounts that are staking or are block issuers. It is used to prove the issuance of blocks for a given account ID.
Committee Root: The hash root of a sparse Merkle tree containing account IDs representing current or upcoming committee members. It is updated only when the committee is successfully rotated. It is used to prove the inclusion or absence of a specific account to the committee.
Rewards Root: The hash root of a sparse Merkle tree that contains data related to rewards (e.g., pool stake, pool reward, fixed cost) for committee members at the previous epoch’s conclusion. It helps to prove the existence or absence of rewards for a given Staker or Delegator.
Attestation Root: The hash root of a sparse Merkle tree that contains data related to the attestation of all account IDs at the end of the slot. It is used to prove the attestation of previous commitments by a given account ID.
How are slot commitments generated?
Nodes maintain their own slot commitment chain based on their understanding of the Tangle, which includes accepted blocks and transactions. Each node tracks the online validator committee, which consists of validator committee members who have issued at least one block with recent timestamps and aligned their slot commitment chains with one another. When the online validator committee reaches consensus on accepting all the blocks and transactions within a slot, or when a maximum timeout is reached, the nodes generate the commitment for that slot.
Under normal network conditions, all nodes should observe the same blocks, resulting in the acceptance of the same blocks and transactions. Consequently, this leads to the generation of identical slot commitments by all nodes.
Why are slot commitment chains necessary?
In IOTA 2.0, slot commitment chains are used to create a reliable history of consensus decisions made by the validator committee. These chains serve three main purposes:
1. Synchronization: Slot commitment chains provide a reliable means for network participants to synchronize the content of the Tangle up to the latest committed slot. This feature is particularly useful when initializing a new node, rejoining the network after inactivity, or switching a slot commitment chain.
For example, when initializing a new node, the genesis block of the Tangle serves as the ultimate truth. The node connects with neighboring nodes in the network, either manually or through autopeering, and begins receiving the latest blocks via gossiping.
However, the challenge lies in determining which blocks have been accepted and whether the node’s peers share the same ledger state. The solution is to use the slot commitments included in the received blocks.
As the new node starts receiving blocks through the gossip protocol, it can trace the chain of slot commitments, with each new slot commitment referring to the previous one, creating a chain that extends back to the Genesis block. While the node processes the received blocks, it verifies the commitments for all slots, monitors the evolution of the validator committee through epochs, and identifies the latest finalized slot. This process ensures that the node is synchronized with the network and maintains the ledger state corresponding to the slot commitment.
2. Dynamic Availability and Fork Resolution: The design of the IOTA 2.0 protocol allows nodes to progress the Tangle and the ledger, thereby preserving the network’s functionality and integrity even under challenging conditions such as network partitions or offline validators. Indeed, the acceptance of blocks, transactions, and the subsequent creation of slot commitments rely on the online validator committee’s active participation in the consensus.
However, in challenging network conditions as described above, nodes may not see the same blocks at the same time. This divergence could result in different blocks being accepted, leading to forks or different commitments for the same slots. Forks, in turn, can lead to varying interpretations of the ledger state among nodes, making it challenging to determine which version of the ledger is correct.
One of the significant advantages of using slot commitments is that nodes can quickly identify if some blocks contain slot commitments different from their own. Slot commitment chains make it easier to identify the point in the Tangle where nodes initially disagreed. Nodes can immediately check which chain is heavier and start following the heaviest chain of blocks, i.e., the chain with the majority of consensus. Without slot commitments, it would be difficult to determine the point at which nodes started seeing different blocks and how they need to switch to the correct state. For more about dynamic availability, check out the upcoming Part 12 in this series of blog posts, Dynamic Availability: Protocol-Based Assurances.
3. Finalization: In IOTA 2.0, finalization occurs on the slot commitment level. The committee finalizes slot commitments, along with all the transactions and blocks associated with those commitments.
To finalize a slot commitment, a supermajority (holding more than two-thirds of the voting power) of the committee must reference this commitment in their validation blocks. In addition, all these validation blocks must be issued within the same slot and be confirmed.
Finalization flags are computed by each node based on their locally maintained copy of the Tangle. However, a node’s perception of finalization is represented in the block header, i.e. when issuing a new block, the node includes both a slot commitment of the latest committable slot and the Slot Index of the latest finalized slot commitment in the respected chain. For more on consensus, check out the Wiki article on our consensus model.
How does it work?
To better understand the mechanics of slot commitment chains in IOTA 2.0, let’s delve into the two critical components: the Chain Switching Rule, which addresses the resolution of forked slot commitment chains, and the Heaviest Chain Selection, which explains how nodes determine the heaviest and reliable chain.
Chain Switching Rule
In challenging network conditions, nodes may perceive different blocks being accepted, thus creating different slot commitment chains. Nodes may not even be aware that this is happening until the problem disappears (e.g. the network is merged again) and all nodes in the network see the same blocks. In the following visualization of the Tangle, the forked slot commitment chains resemble forks in a blockchain.
To resolve this, each node tracks and updates its own slot commitment chain and checks the slot commitments contained in blocks received from other nodes. Forks in slot commitment chains can’t be merged as these could lead to inconsistencies and double spending in the set of accepted transactions. Instead, each node selects which slot commitment chain is heaviest. Nodes in the minority partitions switch to the majority chain after their current slot ends, abandoning blocks from the minority chains. The abandoned blocks need to be re-issued by their issuers after they switched the chain.
The Chain Switching Rule enables liveness for the finalization flag in the IOTA 2.0 consensus. Once the network recovers from its divided state and validators are back online, nodes successfully switch to the heaviest chain and the validator committee continues to finalize slot commitments.
Heaviest chain selection
Because each block is signed by its issuer, nodes can create for each slot commitment attestation (commitment-issuer) lists with committed validation blocks that reference a past slot commitment. Attestation lists allow a node to determine the cumulative weight of a slot commitment chain. Specifically, the weight of a slot commitment is computed as the voting weight of validators in the respected attestation list. The cumulative weight of a slot commitment chain is then determined as the sum of the weights of all slot commitments in that chain.
The first step to selecting the heaviest chain is for a node to request the cumulative weight of the received commitment of the fork from its peers. Since the cumulative weight is a part of the tree data structure used to obtain the slot commitment, the required data to be sent is rather small. If the cumulative weight of the fork is lower than or equal to the weight of the main chain, the node discards the fork. In addition, if the last finalized slot for the node happened after the fork started, the fork is discarded.
The first step is done naively without requesting all attestations. To check the correctness of the cumulative weight, the node must request attestation lists for the slot commitment chain after the forking point. If the cumulative weight was computed incorrectly, then the fork is discarded and the neighbor dropped. Otherwise, the node creates a candidate engine for the fork.
If the candidate engine learns that the cumulative weight of the fork is correct, then the node needs to switch engines. It discards the minority chain along with all the blocks and transactions issued after the forking point and puts the heavier one in the place of the main chain.
Our proposed Chain Switching Rule is a distinctive approach compared to fork choice rules in other consensus protocols. For instance, Ethereum’s LMD-GHOST algorithm prioritizes the fork with the heaviest subtree, considering only the latest vote per validator. In contrast, our solution counts validator votes with multiplicity, per chain rather than per tree. Meanwhile, Cardano’s densest chain rule favors the chain with more blocks in a bounded segment following the forking point. In comparison, when selecting between two chains, our Chain Switching Rule gives precedence to the chain with the latest finalized slot commitment. If the two chains are equal, it gives preference to the chain with the highest cumulative weight (without restricting to a segment).
Conclusion
Slot commitment chains are pivotal in achieving consensus, maintaining ledger synchronization, resolving forks, and driving finalization. By enabling nodes to create a reliable and consistent ledger state, slot commitment chains ensure the integrity and trustworthiness of the network, even under challenging conditions.
The next blog post in this series, published on November 8th, looks at the benefits of IOTA’s underlying Directed Acyclic Graph architecture.
TL;DR: To manage congestion and ensure fairness, the IOTA 2.0 protocol will use a dynamic approach based on users’ Mana holdings. Our Congestion Control Mechanism includes a scheduler, Mana burn, and tip selection, all working together to provide consistent, fair, and secure network throughput with predictable fees.
As a directed acyclic graph (DAG), the Tangle enables blocks to be created in parallel, unlike the sequential order in blockchains. This requires a decentralized mechanism to impose some kind of order on how and when blocks are processed. In a DLT system, congestion control mechanisms manage network congestion: however, when a surge in transaction activity causes congestion in a traditional blockchain network, there can be unpredictable delays in transaction processing and exponentially increasing fees.
Conversely, in IOTA 2.0, we’ve designed a congestion control mechanism where throughput is dynamically allocated among users based on the Mana they hold (remember that Mana is the reward resource automatically generated by holding IOTA tokens). As depicted in the figure below, nodes add any valid block received by neighboring nodes (given that they include the necessary Mana to burn) to their local version of the Tangle before appending them to their scheduling buffer.
This blog post describes how congestion control will work in IOTA 2.0 by outlining its main components: the scheduler, Mana burn, and the tip selection. For a more detailed description, we recommend the Wiki version of this article, to be published on October 25th.
Traffic-aware anti-spam mechanism: Mana burn
When creating a block, the issuer must specify an amount in Mana that will be deducted from their Mana balance. This amount depends on block characteristics (e.g., signature, payload type) and Reference Mana Cost, which is objectively calculated for every slot commitment based on the recent traffic activity, namely on the number of blocks included in the previous slot commitment. This value will be known in advance by the user – you don’t have to make a bet or guess.
This mechanism acts as an anti-spam where the number of blocks each user can issue in a certain time interval is bounded as Mana accrual is capped too. However, while this “Mana burn” is registered by nodes as soon as the block is received, the Mana balances are updated only upon commitment. For this reason, the protocol punishes any misbehavior leading to a negative Mana balance by locking the account and its issuer deposit.
Some readers may have already noticed similarities with other protocols, say Ethereum’s EIP-1559, where the base fee adapts over time based on block size. But the situation changes when the traffic load increases… as we’ll see next!
Dynamic allocation and scheduler’s role
Other projects commonly rely on “priority fees” to choose which transactions will be part of the next block. However, when the available throughput (or “blockspace” in blockchain terminology) is not sufficient to contain all new transactions, it becomes impossible to predict or bound the cost of fees to be paid. In IOTA we take a different approach, sharing the blockspace proportionally to the issuer’s Mana.
A dynamic approach is key. It’s like sharing a pizza with four friends. Normally, you’d divide it into four equal pieces. But what if Joe wants more than his one slice while Mary would like a bit less? To make everyone happy, you’d divide the pizza into many small slices and then take a dynamic approach: in turn, you let each friend take a slice – first Joe, then Mary, John, and Lisa, then again Joe, Mary, etc. – until they’ve satisfied their hunger, eating as much or as little as they want.
Our scheduler, which decides which block should be processed next, works in a similar way: each block issuer (friend) is linked to a queue over which the scheduler iterates in a round-robin fashion (in turn, one at a time). The protocol schedules blocks from issuers depending on their deficit (hunger), a quantity proportional to the issuer’s Mana (see deficit round-robin algorithm).
In blockchains like Ethereum, you must add a fee to your transaction to increase its chances of getting processed and validated, leading to excessive prices under congestion due to unpredictable auctions where the highest bidder receives priority. In contrast, our scheduler makes bidding unnecessary and keeps any delay between the creation and dissemination of blocks to a minimum.
Tip selection
In IOTA 2.0, blocks that haven’t yet been referenced by later blocks are called “tips”. Each node keeps a pool of local tips, and when a new block is created, the node chooses between two and eight eligible tips at random from its pool. To be eligible, a block has to belong to the same slot commitment chain chosen by the node and satisfy certain time constraints: after all, we don’t want to reference blocks that are too old or that are likely to be pruned.
Blocks selected by the scheduler are then forwarded to neighboring nodes and added to the local tip pools. In a DLT, the act of blocks referencing other blocks is important because it links block creation to consensus: the more a block is referenced by other blocks, the more “weight” it gains, increasing the probability of being approved and the speed of being confirmed.
Conclusion: A unique approach
The IOTA 2.0 Congestion Control Mechanism satisfies several important requirements.
It is fundamental for consistencyas it works as a pre-consensus guaranteeing that blocks issued by honest users are received by all honest users within a specific timeframe with high probability.
It provides fairnessby granting block issuers access to a portion of the network’s available throughput proportional to the amount of Mana they hold in their account.
It guarantees security in the sense that malicious actors won’t be able to affect the consistency and fairness of the system.
Going beyond that, our congestion control mechanism offers more benefits:
Predictability: Unlike traditional mechanisms that experience escalating fees during congestion, IOTA 2.0 sets clear and capped Mana requirements. As a block producer, you’ll know exactly how much Mana is needed to execute your transaction, ensuring transparency and predictability.
Feeless: IOTA 2.0 users can generate their own Mana to issue blocks and are not required to pay fees as in auction-like systems. No more worrying about exorbitant prices!
Efficiency: The blockspace is fully utilized thanks to the dynamic approach: If one doesn’t want a slice of pizza, another friend can eat it. In other words, everyone can access the network during low-congestion periods.
In conclusion, the IOTA 2.0 Congestion Control Mechanism is a unique approach to facilitating a fair sharing of network resources, ensuring efficient block delivery, and providing predictable assurances for block issuers. By leveraging Mana and implementing a scheduling buffer, IOTA 2.0 will pave the way for our future secure and scalable decentralized network.
The next blog post in this series looks at how nodes sync the ledger to achieve finality – look out for it on October 27th.
TL;DR: Validators are crucial for IOTA’s consensus mechanism and are rewarded with Mana for their contribution to the security of the ledger. The consensus mechanism selects a committee of validators for each epoch, but anyone who registers to validate is considered a validator regardless of whether they are selected.
As essential nodes in the network, validators uphold the integrity and security of the DLT system by validating transactions and maintaining consensus. But who are they, what exactly do they do, and how do they benefit IOTA 2.0?
This blog post provides an overview of the subject: For a more detailed description, we recommend the Wiki article on this subject, to be published on October 19th.
What are validators and validator committees?
Validators are a vital part of the IOTA 2.0 protocol that upholds the integrity and security of the DLT system by validating transactions and maintaining consensus. Anyone can become a validator.
To do this, they participate in committees formed for a specific period known as an “epoch”. Committee members issue special validation blocks, resolve double spends, determine block inclusion, finalize slot commitments, and are rewarded for their work with Mana at the end of the epoch. The size of the committee is limited to avoid slowing down confirmation time.
How do validators and validator committees benefit IOTA 2.0?
Validators and their committees bring important properties to IOTA 2.0.
They ensure security by preventing double spending and manipulation of the consensus. All nodes accept blocks and transactions approved by the committee members and follow the slot commitment chain adopted by a majority of the committee.
They help the ledger progress efficiently by promptly approving blocks (any validator in the committee that deviates from this expected behavior will get fewer rewards, if any). The bounded size of a committee reduces computational costs and confirmation time, making consensus efficient.
Also, they promote decentralized democracy by not requiring a minimum stake to become a validator, allowing for easy participation by many nodes. In addition, users can also participate implicitly by delegating their stake to a trusted validator, increasing their chance of being elected to the committee. This promotes a more democratic and inclusive validation process.
How do I become a validator?
Anyone who runs a node can become a validator through a one-time registration process. Once the registration is successful, the node has a chance of being selected to become a validator node.
Delegation is also an option for token holders who don’t want to or can’t be validators themselves yet still want to contribute to the security of the network. They assign their voting power to a validator node maintained by someone they trust and get rewarded with Mana. Token holders can change their chosen validator at any time.
How are validator committees formed?
To join a committee, you must first register as a validator before the start of the epoch and be active during a specific period. (By “being active”, we mean that one of your blocks must be accepted; in other words, at least 67% of the online validator’s committee have referenced it). During this period, a limited number of active stakeholders with the largest measured stake (that’s both locked and delegated stake) will be included in the committee.
Once an epoch ends, its committee of validators automatically disbands.
The committee selection process is planned to be temporary until we have installed random selection, thus further improving the decentralization of the network.
What do validators do in IOTA 2.0?
Validators’ primary responsibilities include:
Regular block issuance: Validators should issue blocks within a specific time frame to maintain consensus. Their rewards depend on the number of accepted blocks and the expected number of validation blocks per slot.
Proper referencing: Validators in the committee must reference the latest validation blocks in the slot commitment chain and randomly select valid blocks from their tip pool.
Correct voting: The opinion expressed by a validation block should be aligned with the preferred reality of the block issuer. For example, validation blocks should not represent a vote for two transactions that conflict with each other.
Regular commitment to slots: Committee members must commit to a slot once it becomes committable. This ensures that the slot commitment chain is consistently updated and finalization of transactions functions properly.
How are validators rewarded?
Validators are rewarded for their work with Mana. The size of the reward depends on the size of the validator’s stake, the rate at which they issued validation blocks, and how much voting power was delegated to them by third parties.
If the user has delegated voting power to a node, they also earn Mana rewards whenever their chosen validator gets selected for the committee and performs their duties. The percentage of rewards shared by validators with delegators is defined by the validators.
To promote fairness, quality, and decentralization, we’ve designed the IOTA 2.0 reward system around the following properties.
Fairness and quality: Rewards are predetermined, and consider both voting power and the quality of service provided by validators. Validators failing to meet requirements won’t receive rewards for that epoch. To promote healthy competition, rewards are distributed among pools of participants based on various factors, not solely proportional to their voting power. Also, to attract delegators and maintain fairness, validators are encouraged to set their fixed costs at reasonable levels. If a validator’s fixed cost exceeds their share of rewards, they won’t receive any rewards, potentially leading to a lack of delegators. Validators retrieve their rewards through a regular transaction with a special Reward Input (more details here). Rewards are kept waiting to be claimed for roughly a year before expiring. No reward is given if tokens are no longer locked at the time of claiming, so one can choose to claim rewards when unlocking the staked funds or forfeiting them.
Avoiding fund centralization: Our reward system is designed to avoid incentivizing the centralization of validator funds. Combining stakes from different validators does not lead to increased rewards, so there is no need to set a cap on validator rewards. Similarly, the reward formula discourages the concentration of delegator funds. If a large amount of stake is delegated to a single validator, the rewards for individual delegators become smaller. This encourages delegators to re-delegate to validators with less stake delegated to them. To avoid hoarding, the network has a “Mana Decay” mechanism that gradually reduces the amount of accumulated Mana.
Promoting early contributions to network security: The reward function has two phases: a phase with high but decaying Mana rewards followed by a phase with a constant level of Mana rewards. The decaying phase is particularly relevant in the network’s early stages when participation needs a boost: In this phase, the total rewards paid out will be higher than in the more constant phase but will decrease over time, so validators and delegators that wish to save their rewards to be used or sold later (since in this early stage Mana will probably not have a high demand) are not excessively punished by the Mana decay. The later constant phase of the reward function comes into play when the network matures and reaches a stable state of high utility. At this point, the reward function remains constant, promoting a steady and fair distribution of rewards among participants.
Possible problems associated with validators
Validators may attempt to manipulate the confirmation process in the Tangle, but IOTA 2.0 has preventive measures (for more information, see the previous blog post in this series, A New Consensus Model: Nakamoto Consensus on a DAG).
Censorship attempts: Adversarial validators may try to censor valid blocks by not referencing them. However, honest validators will still reference valid blocks, so to succeed in censorship, adversarial validators must avoid all blocks built on the censored one, leading to isolation and orphaning of their own blocks.
Block issuance halt: Adversarial validators could stop issuing blocks, temporarily pausing confirmation and finalization. Yet, the Tangle and ledger continue growing as approval from the “online” committee is sufficient for block and transaction acceptance. The process resumes with the next committee.
Manipulating slot commitments: Adversarial validators may create competing slot commitment chains or produce a slot commitment prematurely. However, honest nodes prioritize the heaviest chain and ignore unfamiliar commitments or commitments lacking sufficient support.
Aligning goals and incentives of network participants
DLTs generally have two conflicting groups: users who want cheap throughput and low node requirements and miners/validators who want to maximize value through block rewards and fees. The motivation and incentives of these two groups are typically at odds, with miners/validators effectively extracting value from the users.
However, in IOTA 2.0, these groups are merged into one, eliminating the need for separate service providers. Users can produce their own blocks and validator incentives don’t directly extract value from other users through inflation.
By aligning the incentives of all participants, users and validators no longer clash but instead advance their shared interests within the network.
As always, you can take a deeper dive into this subject in tomorrow’s Wiki version of this article. In the next blog post in this series, published on October 23rd, we’ll explore how congestion control happens on the communication layer of the IOTA 2.0 protocol.
TL;DR: This article delves into the IOTA 2.0 consensus mechanism, an evolution of the Nakamoto consensus. It focuses on vote propagation and validation blocks in the Tangle. It explores how nodes vote on a single view of the ledger state through a committee of selected validators. The weight of votes ensures security against malicious actions, while the uniform random tip selection algorithm dictates the structure of the Tangle. The article also covers consensus flags, slot commitment chains, conflicts, and the chain-switching rule.
In digital ledgers shared across several nodes, a fundamental challenge arises: How can everyone agree on what’s stored and valid in the ledger? This agreement ensures consistent views among nodes, and this is where a consensus mechanism comes into play.
The new IOTA 2.0 consensus protocol represents the next evolutionary step of the Nakamoto Consensus, initially popularized by Bitcoin. This blog post describes IOTA’s consensus mechanism: For a more detailed view, consult the Wiki version of this article, to be published on October 17th.
Adapting the Nakamoto Consensus
In Bitcoin, blocks are linked together in a sequential chain. This is the backbone of the Nakamoto consensus, which resolves disagreement among forking blockchains by favoring the longest or heaviest sub-chain.
Now envision a scenario where agreements aren’t limited to a chain of blocks but expand into a dynamic web of interconnected blocks — a Directed Acyclic Graph (DAG). As we’ve seen in Data Structures Explained: The Parts that Make the Tangle, the IOTA network’s underlying data structure, known as the Tangle, is a DAG where each block is linked to multiple preceding blocks.
Network disruptions and malicious participants can lead each node to have a distinct view of the Tangle, potentially resulting in disparate ledger versions. The IOTA 2.0 consensus protocol applies a robust and efficient method for nodes to collectively vote and agree on a single view of what is valid in the Tangle. This builds upon Nakamoto’s concept, integrating it with the idea of the heaviest subDAG, creating a more adaptable consensus model.
How do nodes vote on the Tangle?
In IOTA 2.0, each node plays a role in consensus. When creating a new block, the issuer attaches it to existing blocks so that the new block encodes the node’s opinion about valid blocks and transactions in the Tangle. Essentially, a block votes on the validity of the blocks it is attached to and adds to the validity of the preceding blocks.
For secure and efficient voting, the IOTA network relies on votes written in validation blocks. As explained in the next blog post,Confirming Blocks: How Validators Operate, these blocks are issued by the validator committee, which is chosen via the staking mechanism. Each committee member can issue validation blocks at regular intervals. This property, coupled with the limited committee size, facilitates swift and efficient decision-making.
A validation block’s vote carries the weight of the respective validator, which is determined through the committee selection procedure. Adding up the weight of blocks that validate a specific block or transaction yields the Approval Weight. This weight determines the inclusion of consensus flags for blocks and transactions (more about flags later).
Conflicts and the ledger DAG
IOTA 2.0 employs the Unspent Transaction Output (UTXO) model for processing and registering transactions. Transactions consume outputs and generate new ones corresponding to the transferred and remaining value.
This has two advantages. First, it is easy to map the history of funds by associating the blocks with the transactions that generated and consumed a UTXO. These associations between blocks allow us to create the Ledger DAG, as it represents all the changes in the ledger made by blocks.
The second advantage of the UTXO system is that it allows us to easily identify conflicts, as they can be simply defined as different transactions that consume the same UTXO! The UTXO protocol prevents many complex double-spend scenarios that account-based ledgers face, such as when four transactions consume funds that are enough for only two of them, creating many different scenarios for resolution.
The third advantage of the UTXO model is that different outputs are independent of one another, so they can be spent in parallel.
We’ll see more details about the potential of the UTXO protocol in UTXO vs. Accounts – Merging the Best of Both Worlds, Part 14 of this blog post series, to be published on November 15th.
Tip selection
Now that we’ve seen how conflicting transactions are defined and nodes’ votes are propagated, how do nodes construct the Tangle and decide which conflicting transactions should be added to the ledger?
Recall that each block represents the issuer’s opinion, propagating along the block’s past in the Tangle. Ideally, a node would reference every other block in the past that it considers to be “eligible” (i.e. successfully processed and “gossiped”, or shared). However, because the amount of references necessary for every eligible block is unfeasible, the Tip Selection Algorithm (TSA) chooses a few references at random.
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).
Once tips are chosen, nodes can attribute different reference types to various tips. This allows nodes to cast their votes on conflicting transactions: transactions with the largest Approval Weight receive support. For more details, check out our Consensus whitepaper.
In summary, IOTA 2.0 uses a uniform random selection of references restricted to eligible blocks because it is simple, lightweight, and fulfills the requirements for opinion propagation in the Tangle.
Consensus flags and slot commitment chains
So now we know how blocks are chosen to be processed by the consensus mechanism. But how is consensus itself actually achieved?
The consensus mechanism is all about reaching an agreement on the status of blocks and the transactions they contain. Consensus is facilitated by the use of consensus flags and slot commitment chains. Before we talk about them, let’s briefly talk about supermajority.
A supermajority is used to define good proportions of the committee for the flags and is separated into two types: online supermajority means that the voting weight of over two-thirds of the online committee members satisfies a given condition, while total supermajority means that the voting weight of over two-thirds of all committee members satisfies a given condition.
This separation between online supermajority and total supermajority enables a continuous operation of the Tangle. The online committee enables a preliminary consensus to be reached and commitments to be generated. However, if the consensus is based on a total supermajority, it can be halted if a significant portion of the committee goes offline. For more details on this, look out for our blog post on Dynamic Availability, to be published on November 2nd.
But what are consensus flags? Consensus flags represent confidence levels about whether a block is successfully gossiped and included in the Tangle by the network, striking a balance between safety and liveness for effective network management. “Acceptance” is live and used to determine which blocks will be included in slot commitments, while “Confirmation” and “Finalization” are related to the safety of the network, and are the ones that users will rely on.
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.
We learned about commitment and slots in Data Structures Explained: The Parts that Make the Tangle. Here we expanded on these concepts, as now we know that accepted blocks and transactions are included in the slot commitments of new blocks.
The purpose of commitments is to simply enable nodes to compare their views of what is valid. Different visions of what should be considered valid (and thus confirmed and finalized) can be represented by the nodes in a tree, from where we can extract chains that represent a possible opinion of the nodes. These are the slot commitment chains, which you can learn more about in “Finality: How Nodes Sync the Ledger”, published on October 25th.
Chain Switching Rule
How does consensus work in challenging circumstances like network disruptions?
Network delays could cause nodes to perceive different blocks as accepted, leading to forking slot commitment chains, which are similar to forks in traditional blockchains. To handle these divergences, IOTA 2.0 uses a strategy similar to the Nakamoto Consensus, where the longest or heaviest sub-chain is favored.
More specifically, each node tracks and updates its own slot commitment chain while checking slot commitments in blocks from other nodes. The consensus protocol embraces a simple yet effective strategy: nodes assess the cumulative weight of their slot commitment chains and privilege the chain with the latest finalized slot commitment and the heaviest weight. When nodes on the minority chain recognize the majority chain, they switch to the majority chain after their current slot concludes.
The cumulative weight of a slot commitment chain is determined by adding the weights of all slot commitments within that chain. A slot commitment’s weight is calculated based on the voting weight of validators who agreed on it during a short period.
Once the network is healed, the Chain Switching Rule navigates all nodes to the heaviest slot commitment chain, enabling the continued process of confirmation and finalization. This mechanism allows IOTA 2.0 to uphold consensus even when facing dynamic challenges caused by network discrepancies.
Tip of the iceberg
And so we conclude our journey through the consensus mechanism of IOTA 2.0. But beware: this is just the tip of the iceberg. To learn all the technical aspects of how the consensus mechanism works, watch out for the Wiki version of this article tomorrow.
The next blog post in this introduction to IOTA 2.0, published on October 18th, takes a closer look at confirmation and the role of validators and validator committees.
We are thrilled to announce that the IOTA Foundation has been chosen as a key participant in the UAE’s official startup delegation at the upcoming CEATEC conference, scheduled from October 17th to 20th and held at the Makuhari Messe in Chiba, Japan. This recognition is an immense honor and a testament to IOTA’s pivotal role in pioneering Web3 and Web2 innovations.
CEATEC, a premier global event for cutting-edge technology, this year focuses on transformative technologies that aim “towards society 5.0”. Our presence at the conference’s UAE booth is a great opportunity to spotlight IOTA’s potential for the Japanese and global markets.
IOTA has earned its reputation as a leading network for both Web3 and Web2 innovations. With its innovative Tangle technology, IOTA is spearheading the next generation of open, fair, highly efficient, and decentralized networks based on a Directed Acyclic Graph. This revolutionary approach not only enhances security and scalability but also opens doors to a myriad of new use cases across various industries.
We look forward to meeting industry leaders, entrepreneurs, and innovators at CEATEC. Our team is ready to provide insights, demos, and discussions on how IOTA can be a game-changer for the Japanese and global market. This is a significant moment in our journey, and we’re excited to share the possibilities that IOTA offers in shaping the future of technology.
Stay tuned for updates, and make sure to visit the UAE booth at CEATEC to explore the limitless potential of IOTA in driving the digital transformation of our world. See you at CEATEC!
TL;DR: IOTA 2.0’s tokenomics revolves around two assets, IOTA tokens and Mana, accessible through decentralized accounts. IOTA tokens provide voting power and are fixed in supply to prevent inflation. Token holders can stake to validate the network or delegate to other users. Mana is generated by holding IOTA tokens and enables various network activities without intermediaries. IOTA’s validators and delegators are rewarded with Mana, not fees, promoting fairness and decentralization.
Tokenomics are the economic principles and incentives that govern a cryptocurrency or digital token.
The IOTA 2.0 tokenomics model revolves around IOTA tokens and Mana. Both of these assets will be accessible through your account, from where you’ll be able to either stake your IOTA tokens and help validate the network or delegate them to a validator.
This blog post provides an overview of accounts, tokens, Mana, and staking. For a more detailed description, we recommend the Wiki version of this article, to be published on October 14th. For an overview of how IOTA 2.0’s tokenomics benefits everyone equally, check out Fair Tokenomics for all Token Holders, scheduled for November 8th.
Accounts
If you want to participate in the IOTA economy, your first step will be to create an account, which you’ll be able to use for any economic activity in the protocol. Accounts are decentralized, so they have no association with the IOTA Foundation or any other party.
Your account is a component on the ledger from which you can stake tokens as a validator, delegate tokens to other validators, claim Mana, and hold credits to issue blocks.
But accounts offer even more advantages. Thanks to IOTA Decentralized Identifiers, accounts can serve as a digital identity that is accessible, transparent, persistent, self-controlled, portable, and interoperable, thereby ensuring digital autonomy.
Let’s look at the two assets held by an account: IOTA tokens and Mana.
IOTA tokens
Unlike traditional blockchain systems that continuously mint new tokens to reward their validators, the total amount of IOTA 2.0 tokens remains fixed, preventing inflation and preserving the value of your tokens.
Holding IOTA tokens also grants voting power in the consensus mechanism and for governance decisions.
However, the real driver behind IOTA tokenomics is the sustainable demand for IOTA tokens created by the utility of Mana, the essential resource for accessing and utilizing the IOTA ledger.
Mana
IOTA tokens generate Mana over time. Mana is a resource that allows you to perform certain actions on the IOTA 2.0 network – think of it like a loyalty score that unlocks features. Unlike most blockchain systems where block creation is reserved for a select group of validators, any IOTA account holder can use their Mana to create transactions and access features like transferring funds, minting an NFT, or engaging with smart contracts, all without having to pay intermediaries.
Each time you create a block on the IOTA network, it will consume Mana, meaning it is subtracted from the Mana balance in your account. The amount of Mana to be consumed depends on the network’s congestion levels; nodes dynamically regulate this amount as transactions are processed.
IOTA 2.0’s congestion control distributes throughput (the rate or capacity at which transactions or data can be processed or transmitted) among the network’s users based on the amount of Mana they hold. So, holding IOTA tokens entitles the holder to a share of the network’s throughput capacity through their mana generation. In other words, investing in IOTA tokens ensures that the user will have a guaranteed minimum average throughput for as long as they desire.
How do I get Mana?
You can obtain Mana in different ways. While the primary way is by holding IOTA tokens, Mana can also be earned as a reward for participating in consensus by validating transactions. If you can’t spare the time or the effort to validate, you can also earn Mana by delegating your voting power to a validator and claiming a mutually agreed part of their reward – keep reading for more on this.
You can also purchase Mana directly from other holders on the network if, say, you lack IOTA tokens, temporarily require higher throughput, or cannot hold crypto tokens due to regulatory issues in your jurisdiction. This means that, even if you don’t hold IOTA tokens, you can still participate in the network by purchasing Mana.
Staking and delegating
As mentioned above, Mana is given to anyone who helps validate the IOTA 2.0 network. But how do you validate?
There are actually two methods of validation: 1) validating blocks by locking up your funds (in other words, staking) or 2) delegating your voting power.
Validation through staking is when you stake your IOTA tokens to potentially be selected to validate transactions on the network. In return, you’ll be rewarded with Mana.
To become validators, users must run a node, lock up IOTA tokens, and register on the ledger as validators by adding a stake feature to their accounts. They are then selected periodically to form a validator committee. This committee regularly issues “validation blocks” that approve transactions.
The amount of Mana given as a reward for validation depends on how well the validators perform their duties, including issuing the expected rate of confirmed validation blocks, helping to confirm other blocks, the size of the stake, and how much voting power was delegated to them.
If you aren’t willing or able to lock up your tokens to perform the computational job of a validator, you will still be able to delegate the voting power of your tokens to a validator. This is done simply by specifying the validator’s account ID during a token transfer. This process is called liquid delegation because it doesn’t lock up your tokens and you’re still rewarded with a share of the Mana reward earned by the validator you delegated to.
Rewarding validators and delegators with Mana
In other blockchain systems, validators are rewarded for their work with the base token and fees, gradually accumulating more wealth. There’s nothing wrong with this in principle: Validators perform a valuable job and should be rewarded! However, it diminishes the amount of other users’ tokens due to the transaction fees they pay the validators. This can also make certain use cases extremely expensive (or even unsustainable) in the long run.
However, in IOTA 2.0, validators are rewarded without detracting base tokens from other users.
In IOTA 2.0, access will be paid with replenishable Mana, ensuring no one has to spend their IOTA tokens on fees.
But how will validators profit if they aren’t rewarded with fees or IOTA token inflation?
They profit in two ways. Firstly, their Mana rewards gain them additional throughput (and without paying fees). Secondly, validators can profit from selling their spare Mana to users who either lack IOTA tokens or occasionally require higher throughput. This creates a natural Mana market driven by network demand.
At the early stages of the network, the network’s demand may not support a highly profitable Mana market. Therefore, validators and delegators receive proportionally more Mana during these early years, incentivizing early network security.
Mana is a critical component of the IOTA economy. By being granted to all participating users proportionally to their token holdings, whether they hold IOTA tokens or stake them and participate in consensus as delegators or validators, it ensures that the network remains open to all and access is distributed fairly without generating base token inflation. And, to prevent a monopoly over the supply of Mana in the system, the Mana you hold gradually decays over time: holding IOTA tokens guarantees the generation of new Mana while selling or disposing of your tokens means that your Mana will decay without any generation. So users will continuously contribute to the system to secure their Mana.
Benefits of the IOTA 2.0 incentivization model
Our incentivization model will create a community of validators and token holders, all rewarded according to their contributions to securing the network and processing transactions efficiently.
The IOTA incentivization model will promote three key benefits:
It’s permissionless, so anyone can participate in the consensus. All actors are rewarded fairly according to their stake and participation.
It’s committed to the security of the network, with staked tokens locked up to stabilize voting power distribution and protect the protocol against exploits. It encourages staked tokens to be locked up by offering increased rewards compared to delegating tokens. This makes the protocol less susceptible to exploits since it tends to stabilize the distribution of voting power and encourages ‘good’ behavior by validators, who will have tokens invested in the network while performing validation duties.
It features liquid delegation, which allows token holders to delegate their voting power without locking up their tokens, and thus commit to network functionality and security even if they aren’t willing or able to perform the computational job of a validator.
It disincentivizes the concentration of delegated stake on a single validator by reducing rewards for delegators in such cases. This encourages delegators to choose validators with less delegated stake, leading to a stable ratio of delegated and validator stake in the system.
Together, these benefits will create a community of validators and token holders, all being rewarded proportionally for their contributions to securing the network and processing transactions efficiently.
Instead of wealth flowing in one direction from the system’s users to its maintainers, all IOTA token holders will be rewarded with Mana that they can utilize to access the network. Read more about this in Fair Tokenomics for all Token Holders, part 13 of this blog post series, to be published on November 8th.
For a more in-depth introduction to these topics, check out the related Wiki version of this article, to be published on October 14th. In our next blog post, published on October 16th, we’ll look deeper into consensus, committees, approval weight, and the finality gadget.
Following on from our recent launch of ShimmerEVM, we are thrilled to announce the upcoming release of Bloom, an innovative new wallet developed by the former Firefly team.
Bloom is a beautifully-designed, user-centric desktop wallet with first-class security. Bloom will be implementing a variety of new features including full EVM support, and later dApp connections with WalletConnect.
This upcoming wallet represents a big step forward for IOTA ecosystem users, launching with both Shimmer and ShimmerEVM in the same application. Importantly, users will be able to seamlessly transfer assets back and forth between Shimmer and Shimmer EVM without any outside third-party tooling. Over time, Bloom will support the entirety of the IOTA ecosystem, integrating both Shimmer and IOTA networks in a single app experience.
Building on a Solid Foundation
Bloom wallet continues the team’s ethos of simplifying the core Web3 wallet experience. Building on top of Firefly’s solid foundation, Bloom aims to create the most intuitive, secure and enjoyable wallet on the market.
Their expertise was instrumental in Firefly’s success, and they will no doubt bring their unique talents to spearheading wallet innovation with Bloom.
Enabling Growth Through Open Source
In the true spirit of open source software development, this innovative fork exemplifies the power of open source collaboration. Firefly is built under an Apache 2.0 licence, enabling the Bloom team to freely access and build upon the codebase.
The open-source ethos will continue, with Bloom planning to release additional contributions under a different license. We look forward to seeing what the community creates alongside Firefly and Bloom.
Building toward IOTA 2.0 and Shimmer EVM
We view this as an incredibly positive development for IOTA Foundation, the Bloom team, and the broader crypto community in the pursuit of IOTA 2.0. Bloom will stimulate collaboration, healthy competition and growth across the entire ecosystem.
In the meantime, development will continue on Firefly alongside Bloom. Firefly’s focus shifts to supporting the core protocol only, providing a testing ground for new protocol upgrades, including IOTA 2.0. Whereas Bloom presents an opportunity to pursue user-facing features and cutting-edge advancements that benefit the entire Web3 ecosystem.
We wish the Bloom team great success and will be cheering them on as they blossom as an independent entity.
You can follow Bloom’s progress on X (Twitter) and join the Bloom community on Discord. They will be releasing more information over the coming days. Stay tuned.
Please be aware that the Firefly X (Twitter) account has been taken over by the Bloom wallet team and rebranded to Bloom Wallet.
TL;DR: A new governance proposal is becoming available for voters in the IOTA and Shimmer networks. This proposal asks to modify the existing operating framework for the Shimmer Community Grant committee (SGP – 0006 for a vote by Shimmer Token Holders) while also integrating the IOTA Community Treasury Tokens into this Grant system with an initial Budget of 10 million IOTA Tokens (IGP – 0001 for a vote by IOTA Token Holders). The pre-vote period starts on Thursday at 3 pm CET, and the counting period begins seven days later.
After several weeks of preparation by the IOTA & Shimmer Community Governance Group and successfully passing the first two initial governance phases in our Governance Forum, a governance proposal is being presented to both IOTA and Shimmer voters.
Starting on Thursday, 12 October, at 3 pm CET, voters can vote on these matters in both networks via your IOTA and Shimmer Firefly Wallets with their token holdings. Please be aware that the proposal only passes if the votes in both networks result in the acceptance of the proposal by a simple majority of voters, passing a quorum of 5% of the circulating Token supply.
We kindly ask all token holders to participate in this vote in both networks.
Shimmer Community Treasury Grant Committee Revision
The Proposal SGP – 0006 / IGP – 0001 was crafted by the members of the Shimmer Community Treasury Committee. It suggests improvements in processes governing how they operate the grant system based on their experience over the last few months.
Please refer to a more detailed description of changes to the current processes suggested in the Revisions section of the Proposal. The changes have been thoroughly discussed within the weekly meetings of the community governance group, and a joint proposal based on the work of this group has been developed.
To vote on this proposal with your Shimmer holdings, please open your Firefly Shimmer Wallet starting Thursday, 12 October, at 3 pm CET, and follow the steps described in the Governance Guide for Firefly.
The Proposal SGP-0006/IGP-0001 also seeks the approval of the IOTA community to recognize the existing Shimmer Community Treasury Grant committee, which has been elected by the community and operates under the legal entity Tangle DAO LLC in the Marshall Islands, as its representative responsible for managing an IOTA Community Grant Program.
Additionally, the proposal calls for allocating an initial budget of 10 million IOTA tokens from its total Treasury holdings of 54.896.344 million IOTA tokens to this Committee. The budget shall supply an IOTA Community Grant program until March 2025. This allocation will empower the Community Grant Committee to support IOTA-related projects. Find all details in Revision 22 of the Governance proposal.
IOTA Tokens holders are asked to accept this proposal via a vote with their IOTA Holdings in their Firefly Wallet. To vote with your IOTA holdings, please open your Firefly Wallet starting Thursday, 12 October, at 3 pm CET, and follow the steps described in the Governance Guide for Firefly.
Node operators – your help is needed in counting the votes!
Every Hornet node in the Shimmer and IOTA network with an enabled participation plugin (enabled by default on all nodes that have been set up using the recommended setup process) will be able to participate in the decentralized counting and validation of the votes. To do this, please add the events (as JSON or raw links) that are to be counted in your Hornet node dashboard. Find the new participation event links and a tutorial on adding them using your nodes dashboard here.
We want to encourage every IOTA and Shimmer Token holder to participate in these important governance votes and contribute to the project in this way. Every vote counts, so choose wisely!
TL;DR: Blocks and payloads are two of the most important data structures in IOTA. Blocks serve as containers for data in the network and contain various information, including protocol versions, parent block IDs, and issuer ID. Blocks are categorized according to time slots, and slot commitments ensure agreement among nodes. Validation blocks help determine block confirmation and finality. Blocks carry payloads, including transactions and tagged data, allowing for simple-to-implement and expandable applications.
The IOTA protocol is composed of several structures, which we can think of as simple, solid, indivisible structures, just like an atom. In this blog post, we’ll break down the IOTA atoms to see what they look like inside and how they help IOTA operate!
In our previous blog post, Data Flow: How Nodes Process Blocks, we saw how nodes work at processing blocks; now we want to see how the other structures of IOTA 2.0, namely blocks, slot commitments, and payloads, are made and why they’re so relevant! As always, for a more detailed look, we refer you to our Wiki article on Data Structures, to be published tomorrow, October 11th.
The anatomy of a block
The most prominent unit of information in the IOTA 2.0 protocol, the block is a container for a collection of data to be stored in the network. To spread this data among all network participants, blocks are gossiped by nodes, making this data eventually available to every node on the Network Layer.
Aside from the data it contains (which we call “payload”) a block also contains important information that helps keep the protocol functioning. Let’s take a look at the main pieces of information inside a block:
Protocol Version: This allows nodes to apply the correct protocol rules to the blocks, especially after a protocol update is introduced.
Parents: A list of past blocks that are strongly or weakly approved or are directly referenced to adjust opinions (these are called “Shallow Like Parents”).
Issuer ID: The ID of the node that created the block.
Issuing Time: The time the block is issued, commonly referred to as the Timestamp.
Slot Commitment: A slot commitment is a cryptographic summary of a slot (more on slot commitments below).
Signature: The signature of the issuer.
The block ID is then generated by a hashing process involving the data contained in the block.
Slots and slot commitments
Slots divide the timeline into segments that categorize blocks. Each slot is uniquely indexed, and since each slot’s duration is fixed, it is straightforward to determine which slot a block belongs to based on its timestamp.
Because of filters within the Parser (explained in detail in the previous blog post in this series, Data Flow Explained: How Nodes Process Blocks), blocks can only be added to slots within a specific timeframe. It’s important to note that a block’s timestamp reflects when it was issued, so even if it arrives later, it can still be added to a slot as long as it’s not too delayed. This process ensures that, over time, nodes that receive identical information will share the same understanding of which blocks have been accepted for a particular slot. Reaching a consensus on this list of blocks through comparison is a vital aspect of the consensus process. To facilitate this, nodes create what we refer to as “slot commitments”.
Slot commitments act as cryptographic records of slot contents. Each block includes a commitment to a past slot, so that it is always possible to check which blocks a certain node has knowledge of.
Moreover, each slot commitment carries information about the commitment of the preceding slot, forming a tree of commitments. In cases where commitment chains diverge due to a fork, nodes will follow the chain generated by nodes with the largest voting power. More insight into tracking slot commitment chains and selecting the heaviest one is available in “A New Consensus Model”, published on October 16th.
Validation blocks
Validation blocks determine the confirmation and finality status of other blocks. Because of their importance, they are exempt from the standard congestion control mechanism (you can see more on this in “Understanding Congestion Control”, to be published on October 23rd). As a result, any level of congestion will never bring the validation process to a halt.
In terms of structure, validation blocks mirror regular blocks but with a key distinction: they can only contain a minimal amount of data. This ensures they can’t accommodate transactions or other payloads. This limitation also ensures that no committee member can exploit the validation block to gain free throughput. Identifying these blocks is straightforward, as the validator’s committee information is publicly available (you’ll be able to refer to “A New Consensus Model”, Part 6 of this series of blog posts, for additional insights).
Payloads: Transactions and Tagged Data
Payloads are data packages contained in all IOTA blocks that aren’t validation blocks. They are used to execute transactions and run applications on the Tangle. IOTA’s simple payload model is designed to be easy for developers to use and adaptable to new technologies.Each payload includes a header specifying its payload type, enabling easy identification through processing. At launch, IOTA 2.0 will support two major kinds of payloads: Transactions and Tagged Data.
Tagged Data is a generic data payload with a customizable tag field that can be used as an identifier for applications or any other use that the issuer requires. Essentially, the tagged data payload is composed of three fields: identifier (header), tag, and data.
Transactions, on the other hand, are payloads used for value transfer, which is the most used and supported application among users. A transaction contains the transaction identifier (header) and the Transaction Essence, which is the main data field for transactions and contains all necessary information for secure writing to the ledger. This information includes:
Network ID: Identifies if the transaction should be used on the mainnet, testnet, Shimmer, or a private network.
Creation Slot Index: The index of the slot at which the transaction is included.
Input List: List of all UTXOs to be consumed by the transaction.
Output List: List of all UTXOs to be generated by the transaction.
Extra Payload: Possibly a tagged data payload that is included in the transaction.
Largely due to its ability to consume and create UTXOs and consequently modify the IOTA Ledger, transactions are the most complex type of payload.
This completes our journey inside the structure of the main elements of the IOTA 2.0 protocol. With this in mind, we can better understand the functionality of other modules of the protocol and grasp why the Tangle is the ideal platform for the future of DLT applications!
Again, a more detailed look at data structures in IOTA 2.0 can be found in the Wiki tomorrow. Coming up in Part 5 of this blog post series (published on October 13th), we’ll explain accounts, tokens, Mana, and staking.
The previous quarter saw major developments at the IOTA Foundation, with the launch of ShimmerEVM at the end of September drawing on the Shimmer, Firefly Wallet, and Developer Experience and teams. Another milestone: the introduction to IOTA 2.0, our upcoming protocol update, and the culmination of years of work. But apart from these two mega-projects, plenty of new ground was broken across other disciplines, from Research to Regulatory Affairs, Engineering, and Developer Experience.
Shimmer Updates
Shimmer EVM Launch
The main focus in the last quarter has been on getting IOTA Smart Contracts (ISC)/ShimmerEVM ready for public use on the Shimmer network. After the re-launch of the public testnet, multiple extensive testing sessions took place and we worked together with the various stakeholders to address all major wishes and concerns before the chain was launched for deployment on September 28th. After a short bootstrapping phase, ShimmerEVM is now available to use for everyone. In the next quarter, our focus will be on improving user experience and working towards improved multi-chain support in a future version.
Shimmer Governance and Vote
In the last quarter, the IOTA and Shimmer Community Governance teams enhanced their governance processes. Notably, they introduced an updated specification for the Shimmer Community Treasury Committee, presented as a new governance proposal. This proposal incorporated insights from the initial months of operating the Shimmer Community Grant Committee and is currently undergoing a community vote. Another achievement was the establishment of the Marshall Island DAO LLC entity for the Tangle Treasury DAO. This entity is now fully registered and has consequently transitioned out of its initial setup within the Tangle Ecosystem Association.
Assembly Updates
As announced on September 15th, the Assembly project and token will be discontinued in favor of IOTA Chains and L1 smart contracts.
While technically feasible, Assembly’s envisioned architecture would introduce too much delay in our technical roadmap while introducing an inferior solution compared to recent advancements. Among these are zkRollups, which inherit the security of the L1 through cryptographic proofs, thus no longer requiring complex mechanisms to guarantee economic security through a native token.
Instead of further developing and releasing the Assembly project and token, we will therefore focus our efforts on IOTA Chains, our generalized smart contract framework for anchoring Layer 2 (L2) blockchains on IOTA, and developing L1 smart contracts. IOTA holders that staked for Assembly tokens will get an IOTA token airdrop. You can read more about the decision to stop the development of Assembly in this blog post.
IOTA Updates
Most notably, the IOTA Foundation recently advanced to a state of confidence about all aspects of the IOTA 2.0 protocol, culminating the efforts of the past years to upgrade to a fully decentralized, parallelized, open, and fair protocol. Three academic papers, describing the core architecture of IOTA 2.0, outlining the Ledger, Networking, and Congestion Control Algorithm have been published and peer-reviewed (read more on it in our recent blog post).
Meanwhile, public information and documentation on all aspects of the IOTA 2.0 protocol have been prepared for public scrutiny. We recently started publishing a series of articles and videos that will last for about six to eight weeks due to the sheer amount of information. Once all aspects are published, all details of how the IOTA 2.0 protocol works will be publicly available and properly documented.
Alongside the public introduction of the IOTA 2.0 protocol, the IOTA Core development, representing the future IOTA 2.0 node software, is progressing very well, as can be witnessed on its public Kanban board.
Research
Responsible for advancing the IOTA protocol, the Core Node Research team Andrea VillaJonas Theis has discussed and settled questions about the dynamic liveness threshold, validators issuing on multiple chains (the nothing-at-stake problem) to maximize the likelihood of receiving rewards, and implications of the maximum committable age for slot commitments and acceptance. Some user interactions around transaction building and mana allocation are being discussed to minimize user friction around these hard-to-grasp concepts.
Responsible for the design of the fundamental modules in IOTA 2.0, the Protocol Research team has mostly worked on documentation and on supporting the implementation of the IOTA 2.0 software through the definition of a parameter dependency graph, improved user experience, more secure consensus, and penalties for malicious behavior, among others. We present more about this below.
Additionally, the team held “Beyond the Chain: First Workshop on DAG-based Distributed Ledgers” this July. The workshop received good attendance and interest and talks from various European Universities (UZH, Imperial, Aalborg University, Porto University, Salamanca University, and more), and the team is already planning the next event.
The Smart Contract Research Team has been focusing on how to make the best use of Move’s object model on top of the IOTA 2.0 protocol. Specifically, the team has been working on designing models for ownership and access control of objects. Additionally, it has analyzed approaches to determinism in smart contract execution.
Ledger Research
Continuing to focus on our data and application layers, Ledger Research has seen several developments in various components of the IOTA ledger, including:
The Finalization Research Working Group, responsible for developing the IOTA 2.0 protocol’s consensus mechanism, has focused on improving the consistency in block acceptance, including, and most importantly, the dynamic liveness threshold guiding the tip selection algorithm.
The Group’s paper Reality-based UTXO Ledger was accepted in the Association for Computing Machinery’s (ACM) peer-reviewed journal Distributed Ledger Technologies: Research and Practice (DLT). It describes the theoretical foundations of the ledger model in IOTA 2.0, i.e. how transactions optimistically update the ledger and how one can keep track of the dependencies of the possible conflicts. The Group’s paper Fairness Notions in DAG-based DLTs was accepted by the 5th Conference on Blockchain Research & Applications for Innovative Networks and Services (BRAINS 2023): It discusses different dimensions of fairness and conducts a comparative analysis to examine how they relate to different components of DAG-based DLTs.
The Congestion Control Working Group, responsible for designing the access scheme for the protocol, has focused on facilitating user experience with the newly created Usability Task Force (see below). Additionally, the group has designed and implemented dedicated validation block throughput (to solve the problem described here). Finally, the team was honored that their paper Managing Write Access Without Token Fees in Leaderless DAG-Based Ledgers was awarded the Best Paper Award at the 6th International Congress on Blockchain and Applications (BLOCKCHAIN Congress 2023) at the University of Salamanca (Spain).
The Incentives Working Group, responsible for developing the new incentives mechanism and research subjects related to game theory and tokenomics, supported the implementation of the incentives mechanism in the IOTA core node. Additionally, an interactive Mana Calculator is being developed so users can simulate different scenarios of Mana generation, as well as delegation and staking rewards. The Mana calculator will be published during the IOTA 2.0 protocol introduction series, which we just started.
In the last quarter, the IOTA Smart Contract (ISC) Consensus Working Group, responsible for formally describing and refining the ISC consensus and related algorithms, redesigned the recovery algorithm, while also implementing and deploying it to the Shimmer Testnet. Currently, the Group is working on the documentation of the involved algorithms.
The Zero-Knowledge (ZK) Working Group, which is responsible for investigating ZK techniques and solutions for scalability and privacy-related use cases, has been studying existing ZK proof generation platforms for a possible ZK integration with our L1 smart contract platform. The team focused on answering the question: what makes a smart contract platform zk-friendly? For this purpose, some open-source ZK solutions such as RiscZero and zkSync have been analyzed. The team also initiated a PoC on ZK integration with the standard Move virtual machine.
The Applied Cryptography Working Group, which oversees the implementation and utilization of cryptographic algorithms, played an active role in the release of an enhanced Stronghold version 2.0. Additionally, the Group bolstered the security of associated projects like iota-sdk and the Firefly wallet. Furthermore, the group has commenced the planning of a quantum-readiness roadmap, aligning with the recommendations set forth by CISA, NSA, and NIST.
IOTA Task Forces
IOTA’s various task forces have also made significant improvements during the recent quarter, specifically:
The Accounts Taskforce, responsible for designing the mechanisms of Mana and staking for IOTA 2.0 continued to iron out the details of the Tangle Improvement Proposals (TIPs) for the IOTA 2.0 ledger that specify the workings of Mana, staking, and delegation as well as their interplay with accounts. The taskforce’s attention has shifted from specifying to implementing the TIPs and some members of the Accounts Taskforce became part of the newly established Usability Taskforce.
The Usability Taskforce, responsible for ensuring a high-quality user experience and usability of the IOTA 2.0 protocol as well as the Firefly wallet, was launched. Based on user stories, the task force made decisions about which usability aspects to focus on first. As users need accounts to issue blocks in IOTA 2.0, simplifying account creation is one of the highest priorities. The task force decided on an implicit account creation mechanism that allows users to create an account when they are onboarded into a network and this mechanism is currently being specified and implemented. The task force continues to discuss other aspects of usability, such as account creation for users with existing funds, among other items.
The newly-created Parameter Task Force is responsible for translating mathematical model parameters to high-level (TangleSim) parameters and refines them for both high and low-level (iota-core) models. They analyze proposal performance, security, and robustness based on TangleSim parameters. After iota-core is online, they will continue to optimize parameters for better protocol performance while maintaining security.
The EBSI Taskforce, responsible for assisting the IOTA Foundation’s participation in the EU Blockchain Pre-Commercial Procurement in research-related matters, is still progressing with its work on Phase 2B as outlined in the tender.
IOTA Engineering
IOTA Core Team: The node software implementing all the critical aspects of IOTA 2.0 with its initial PoA has been completed (except for the implicit account creation mechanism for making Accounts the first-class citizen in our new protocol going forward). Developed features include potential mana calculation and decay, block scheduler around Reference Mana Cost (RMC), validators’ performance tracking and reward calculations, UTXO and Account ledger storage pruning, adaptive RMC, validators’ tip selection, INX plugins, and more. The team will soon split into hardening the PoA feature set and implementing the dPoS committee selection, rewards tracking, and rotation.
Tooling: The takeover of the Firefly codebase and release processes together with the migration of the wallet to iota-sdk is complete. The preparation of Firefly for the Stardust upgrade was successfully concluded on October 4th. The Explorer migration to iota-sdk is still in progress but close to the finish line. There has also been good progress for a Tangle Visualizer 2.0, with the layout and mechanisms laid down and the current focus on developing an external tool that will be used to “record” the Tangle stream data in order to be able to feed pre-recorded data to the Visualizer, thus enabling it to replay specific scenarios visually.
Identity: The team aligned the JWT implementation with established standards for encoding Credentials and Presentations, culminating in the release of the 1.0 Release Candidate (on Rust and JavaScript). Furthermore, it founded the Identity Working Group, comprised of prominent community contributors and aimed at decentralizing the library’s maintenance and development efforts.
Firefly Wallet
Both Firefly IOTA and Firefly Shimmer have received updates, including several bug fixes and a security enhancement through a Stronghold upgrade.
In Firefly IOTA, work is underway to ensure compatibility with the upcoming Stardust upgrade of the IOTA network and the IOTA airdrop to reward stakers who participated in the Assembly staking events. In Firefly Shimmer, preparations have been made for the ShimmerEVM launch, enabling Layer 1 to Layer 2 transactions.
Additionally, it’s important to note that the mobile version of Firefly has been deprecated. This decision was made to focus on maintaining wallet libraries for external entities and a desktop wallet implementation that guarantees access to all core functionality developed by the IOTA Foundation.
Developer Experience
The Developer Experience team lent its support to the release of the IOTA SDK by reorganizing the examples within the repository and incorporating the most pertinent code snippets from these examples into the how-to guide on the Wiki. This enhancement facilitates a quicker onboarding process for developers looking to begin their journey with IOTA and Shimmer using the IOTA SDK.
In preparation for the ShimmerEVM Mainnet launch, the team overhauled the documentation, categorizing it into separate sections for EVM and Wasm, thereby improving its accessibility. Moreover, the team followed the Diataxis framework to ensure a more systematic organization and edited the content to make it more easily understandable.
For the impending IOTA 2.0 release, the Developer Experience team has focused on enhancing and refining the communication materials, with additional input from the Research Team, significantly contributing to the development of the Wiki. You can see the changes here.
Community and Ecosystem
IOTA Governance: Preparations are underway so that the IOTA Community Treasury Tokens will become available to the IOTA Community once the IOTA EVM chain goes live. A governance system will be built to provide the needed technical solutions. Additionally, we are preparing the process of collaboratively designing the framework for the new IOTA Ecosystem Fund with input from the IOTA Community and Ecosystem. If you want to participate in this process, please join our Governance meeting every Thursday at 4 p.m. CET on the IOTA Discord platform.
Touchpoint: In the lead-up to the ShimmerEVM Mainnet launch, Touchpoint has positioned itself as a pillar of the ecosystem, expanding to over 50 teams and 100 builders. Achievements include: uniting core community members into task-focused groups and addressing challenges from ecosystem marketing to community initiatives like bug bounty programs. Teams have had the opportunity to sharpen their pitch skills through community feedback sessions, preparing them for investor interactions. This quarter, the scope of Touchpoint events was broadened, hosting a range of activities from project demos to service providers introducing their verticals to the community. Lastly, from Oracles to Bridges and Exchanges, the team has focused on partnering with the top teams in crypto, ensuring our ecosystem has a robust infrastructure and foundation.
If your project is interested in joining the Touchpoint program, you can apply here.
Regulatory Affairs
In Q3 2023, the IOTA Foundation’s Regulatory Affairs team closely monitored global regulatory developments. Notably, the U.S. Securities and Exchange Commission (SEC) and the Commodity Futures Trading Commission (CFTC) continued their enforcement actions against crypto companies. Meanwhile, Europe’s Markets in Crypto-Assets regulation (MiCA) brought much-needed clarity to EU-based crypto companies regarding licensing, investor protection, and market transparency rules.
During this period, the Regulatory Affairs team continued to work closely with regulators to promote appropriate, new regulatory frameworks for the crypto-asset industry and to align regulatory approaches across jurisdictions. For example, the team participated in the consultation by the International Organization of Securities Commissions (IOSCO) on Policy Recommendations for Crypto and Digital Asset Markets and prepared a response to the AMF Discussion Paper on Decentralised Finance published by the French financial market regulator Autorité des Marchés Financiers (AMF). The responses are expected to be published later this year.
Additionally, a significant part of the team’s efforts in Q3 was dedicated to establishing stronger connections in the Middle East and preparing for the registration of a new Distributed Ledger Technology (DLT) Foundation in the United Arab Emirates (UAE). The team collaborated closely with local authorities to become one of the pioneering DLT foundations in the market.
Social Impact and Sustainability
The BC100+ initiative reached many milestones in the third quarter of 2023. Following its manifesto launch in June at bc100plus.org, the website now showcases its signatory members and is a repository for all related reports. Applications to BC100+ have continued to be reviewed, with 18 signatory members added. Notable additions approved by the Steering Committee, led by the IOTA Foundation’s Mariana de la Roche, include the Ethereum Climate Platform. Finally, a report summarizing BC100+’s activities from March to August 2023 can be found here.
The IOTA Foundation has continued its leadership role in the INATBA Social Impact and Sustainability Working Group. The most recent success of the Group involved the monthly Podcast for Social Impact and Financial Inclusion. Work continues on a Latin American report exploring the remarkable endeavors shaping the landscape of sustainability, conservation, and social impact in the region.
Notable publications from the team in Q3 include papers on the Impact of Distributed Ledger Technology on Supply Chain Sustainability and a Definition of DeFi paper. Furthermore, as education is a key objective of Social Impact, the team is working on three additional papers. In collaboration with the INATBA Education Working Group, EUBOF, and Blockchain Bundesverband, Mariana de la Roche, and Åsa Dahlborn published a paper to clarify blockchain misconceptions, which will also be included in a guide for newcomers to blockchain. This is essential for global adoption, informed decision-making, and building trust among users, businesses, and policymakers. Also in collaboration with INATBA, this time the Privacy Working Group, a paper on Smart Contract Definitions is in the works. Finally, a paper on Staking as a Service has been published in collaboration with the EBA.
As stated earlier in this post, the core components of the IOTA 2.0 protocol have been detailed in three academic papers and successfully peer-reviewed. Alongside it, the full documentation of the IOTA 2.0 protocol has been prepared and is currently being released to the public. Meanwhile, the IOTA Core development is progressing without any noteworthy delays. Following the implementation of the core protocol in the IOTA Core node software, a private test network will be set up, followed by a public test network, which will introduce the fully decentralized IOTA 2.0 protocol to the public for the first time.
Coming Up
As noted above, the introductory campaign to the upcoming IOTA 2.0 has already begun, with a series of blog posts, Wiki articles, and videos that explore the protocol in depth: this will continue to be a major – but far from only – focus in Q4. But you don’t have to wait for the next quarterly update to see what we’re working on: join our community on Discord or follow us on X/Twitter for the latest news and discussions.
TL;DR: This blog post delves into the functionality of IOTA 2.0 through its Data Flow, the process by which data is used to construct the network and generate further data for propagation. The IOTA protocol comprises three layers: Network, Communication, and Application. Nodes in the Network Layer exchange data necessary for operations, while the Communication Layer manages block connections in the Tangle using Rate Control and Congestion Control. The Application Layer handles block contents and payloads, thereby maintaining the ledger state and enabling consensus. The Data Flow breaks down block processing into components like Parser, Storage, Solidifier, Booker, Scheduler, and Tip Manager. This intricate system ensures the efficient and robust functioning of IOTA 2.0, even under high congestion.
How does IOTA work? There’s no one-line answer to this question, as IOTA is the result of years of researching and iterating solutions until arriving at something that has extraordinary performance while still aligned with our vision. (If you want to read more about our vision, head back to Digital Autonomy for Everyone: The Future of IOTA).
The lack of a one-line answer doesn’t mean there is no answer! One way to understand IOTA 2.0 is from the perspective of its Data Flow. Data Flow is what we call the process of how the data you share with the ledger is used to build the network, and how the network generates further data to be propagated. Understanding Data Flow means understanding how each module of the protocol interacts with the data you share with it.
Here’s the simplest answer to the question “How does IOTA work?” As always, for a more technical answer, read the Wiki version of this article, to be published on October 10th.
The IOTA 2.0 protocol structure
The IOTA 2.0 protocol is structured into three distinct layers, each serving a specific purpose in managing nodes, blocks, and payloads.
At the bottom of the pyramid is the Network Layer, which is a network of nodes that exchange the data necessary for everything to function: i.e. blocks and packets of information used by the protocol. To optimize their hardware resources, nodes only need to maintain a connection with a limited number of other nodes. The peer-to-peer network of these nodes is the Network Layer. The Peer Discovery and Neighbor Selection modules randomly select neighboring nodes, bolstering network resilience by preventing simple attacks.
Blocks that arrive via the network layer must connect with other blocks by establishing references to them. These connections form the Directed Acyclic Graph (DAG) as we know it – in other words, the Tangle! The Communication Layer regulates the blocks that build the Tangle and is handled by the modules that control the flow of information: Rate Control and Congestion Control.
The contents of blocks and their payloads are handled by the Application Layer. Payloads contain the data that will be used by applications, including crucial components like Consensus and Notarization. These elements enable consensus between nodes regarding block inclusion in the Tangle and validation of transactions (you can read more about our consensus in “A New Consensus Model”, Part 6 of our blog post series, published on October 16th). Because achieving agreement on data is the most important problem for DLTs, the Application Layer is responsible for maintaining the ledger state.
Breaking down the data flow
When you create a block on IOTA 2.0, it first enters the Network Layer, where a careful process unfolds before the node can process all your block’s information and make any necessary changes required by this new information.
The Data Flow separates this procedure into six distinct components, ensuring that the data is properly handled. These components are the Parser, Solidifier, Booker, Scheduler, and Tip Manager. Let’s take a look at each of these components to understand how they shape our protocol!
Parser: As the first step for blocks arriving at a node, the Parser interprets the received bytes and turns them into usable information for the other components of the process. The parser filters out redundant or invalid information (for example, when multiple copies of a block are received from neighbors, if a mistake was made in the hashing process, or if information was lost due to a communication error). The Parser checks the correctness of the translated information, such as the block’s timestamp, Mana burn, slot commitment age, and signature (Don’t worry if any of these topics are unfamiliar to you: stay tuned for upcoming blog posts in this series!).
Solidifier: Solid blocks maintain consistent connections to past blocks, preventing information gaps when retracing previous block history. The Solidifier ensures that the data it processes is solid (or, if not, that it doesn’t proceed any further in the Data Flow). If any blocks are missing, it requests the information from neighboring nodes. New nodes joining the network can also use the solidifier to establish a history of the ledger and bootstrap an otherwise empty database!
Booker: Responsible for keeping order in the Tangle and the ledger, the booker arranges received blocks and transactions, identifies conflicts, and establishes possible conflicts in the conflict DAG (more on this in Part 6, A New Consensus Model), which results in differences that need to be resolved by the consensus module. It adds blocks to the Tangle and applies the changes in the corresponding ledger reality.
Scheduler: Serving as the gatekeeper of the Gossip protocol (which relays information to neighboring nodes), the Scheduler queues blocks based on their issuer and selects blocks for further gossiping and/or inclusion in tip pools according to the issuer’s rate. It protects against spam, maintains order during congestion, and ensures that access to the Tangle remains functional and fair!
Consensus: In parallel to the Scheduler, the booked blocks go to the Consensus module. This is where the Approval and Witness Weights are propagated and tracked, and where the blocks and transactions are flagged as accepted and confirmed when these weights pass a certain threshold. This module is the one that keeps the confirmation moving forward!
Tip Manager: The tip manager adds blocks selected by the scheduler into the tip pool. It also keeps the local tip pool of a node in order by removing newly approved or very old blocks.
There’s also a supplementary component that is used when the node itself is creating the block:
Block Factory: As the name suggests, this is where new blocks are formed! Based on information provided by the user, a payload is generated and fed to the factory where the block is created by selecting tips to be approved using the Tip Selection Algorithm (find out more about tip selection in “Understanding Congestion Control”, Part 8 of this blog post series, published on October 23rd). Then, the slot commitment is fetched (slot commitments are described in Part 6), the timestamp is registered and, finally, all information is signed. This adheres to the creation rate set by the Rate Setter, which is an element of our congestion control mechanism.
The data flow is the first step to understanding the IOTA 2.0 protocol, from the point of view of the block as it traverses nodes and metamorphoses into fresh Tangle data and ledger content. This process is the result of a deeply iterated and deliberated system that is not only robust but extremely efficient, even during high congestion.
Forthcoming blog posts will explore these aspects in greater depth, beginning with “Data Structures Explained – The Parts that Make the Tangle”, published on October 11th.
TL;DR: The five core principles of IOTA 2.0 aim to lay the foundation for a democratic and autonomous digital future. The principles are Accessibility, Parallelism, Volume and Velocity, Social Dynamics, and Sustainable Tokenomics. We delve into the details of each principle, explaining how they work and how they contribute to the overall goal of creating a world-spanning infrastructure that offers security and economic opportunities to everyone.
IOTA’s five core principles lay the foundation for a truly democratic and autonomous digital future.
This blog post gives you an overview of the principles:For a more detailed description, don’t miss the introductory Wiki article to be published on October 5th.
Each principle is designed to ensure that you as a user have complete control over your digital assets and transactions. (For more on our vision of Digital Autonomy for Everyone, read the first part of this introductory series to IOTA 2.0).
Accessibility: With Accessible Writing,you can create and add your own blocks to the ledger, without having to pay someone else.
Parallelism: Say goodbye to computational bottlenecks with Parallel and Stream Processing, which ensures that multiple blocks can be processed at once on arrival.
Volume and Velocity: High volume and velocity transactions ensure everyone enjoys a rapid user experience: You can execute many transactions in just a few seconds.
Social Dynamics: The protocol will replicate real-world social dynamics through the use of account-based digital identities, giving you easy management of your assets and digital identity.
Sustainable Tokenomics: IOTA is designed to prevent value extraction by encouraging long-term commitment to the ecosystem. Owning IOTA tokens over time guarantees feeless access to the network.
These principles underpin an open and permissionless system that enables a truly world-spanning infrastructure offering security and economic opportunities to everyone. Let’s look at each principle in more depth.
Principle 1. Accessibility: Most DLTs rely on block producers to create blocks, thereby adding and confirming information on the network (which we call “writing”). They are the gatekeepers of the network, and other users – who fundamentally want cheap throughput – usually have to pay them a fee to include their information in blocks. This creates a conflict of interest between users and block producers. To resolve this conflict, IOTA merges users and block producers into the same group, so you – like everyone else – can mint your own blocks, without having to pay someone else.
We call this process Accessible Writing, and it’s made possible thanks to the high block creation rate achieved through our Directed Acyclic Graph (DAG) architecture. In a DAG, multiple blocks can be added at the same time (see Principle 2), increasing the overall block creation rate and allowing additional actors to participate in the network.
Accessible Writing increases everyone’s digital autonomy by ensuring each user can interact with the network without going through a service provider.
Principle 2. Parallelism: Our DAG-based architecture enables blocks to be created not only at the same time but also in parallel. In addition, the protocol can be divided into many smaller blocks that can be constantly processed, rather than in big batches. Typically, most DLTs first order all transactions to resolve conflicts before processing them in big batches, which creates delays. Instead, IOTA processes first and then uses voting to sort out any discrepancies caused by conflicts.
Thus transactions can be processed in parallel and on arrival, which increases performance and reduces bottlenecks at times of peak congestion. IOTA’s parallel processing also makes it ideal for heavy computations, making it a scalable settlement layer for side chains and bridges. It also enables us to utilize the maximum computational power of every node in the network.
Principle 3. Volume and Velocity: For a distributed ledger to be successful, it needs to be able to handle a lot of transactions quickly. While traditional blockchains batch transactions into sequential blocks slowly and periodically, IOTA 2.0’s architecture allows your transactions to be executed as soon as they arrive, without having to wait to get clumped together and be processed in batches. This means that your low-value transactions can be completed almost instantly, and, if you want more security for a larger transaction, you just have to wait a few seconds for it to be confirmed. Moreover, it’s important to have as much throughput as possible for the system so it can service as many people as possible.
Principle 4. Social Dynamics: IOTA 2.0 uses decentralized identities and accounts to reflect the dynamics of the real world on the ledger, thereby enabling widespread adoption. For example, as a user of IOTA 2.0, you’ll have your own decentralized digital identity in the form of an account interface, where all your interactions with the protocol will occur. Accounts provide static identifiers for you to declare states, lock funds, stake, and issue blocks, and your control over your account represents your digital autonomy. Also, institutions, businesses, and machines can be identifiable on the ledger and can interact with IOTA users and their digital identities.
5. Sustainable Tokenomics: IOTA 2.0 encourages long-term investment in the ecosystem with tokenomics that revolves around two key resources: IOTA tokens and Mana. A fixed supply of IOTA tokens means no inflation and prevents additional fluctuations in token value while holding IOTA tokens generates Mana, a resource that unlocks the ability to perform various actions such as transferring funds, minting NFTs, and engaging with smart contracts. Also, the amount of Mana determines the average share of throughput access. Alternatively, users can stake tokens as validators or delegate tokens to validators in order to claim extra Mana. So instead of rewarding users by diluting the IOTA token, we incentivize them with Mana, which gains utility as the network matures, creating a circular, replenishable economy that favors long-term investment over short-term profit extraction.
A solid foundation
Together, these principles create an open and permissionless system that offers security and economic opportunities to everyone. By using IOTA, users become part of a network that prioritizes their needs and autonomy, empowering them to have control over their digital lives.
In our next blog post, we’ll dive into data flow and how all the components fit together.
TL;DR: The Stardust protocol upgrade on the IOTA network is happening today, introducing the tokenization framework and with it the ability to anchor L2 smart contract chains to it. In addition, the former IOTA network will be forked, resulting in the IOTA network based on the Stardust protocol version with an increased supply; and IOTA Classic, which will also be based on the IOTA Stardust protocol but keep the old supply.
The Stardust protocol upgrade and fork of the IOTA network will commence Wednesday, 04 October 2023, at around 8 a.m. CEST. This follows our initial announcement on 15 September 2023.
Due to the fork, you can expect a downtime of up to 4 hours. We’ll announce the beginning and finalization of the procedure through our official IOTA X account (formerly “Twitter”).
The Stardust protocol version was first introduced on the Shimmer network on 28 September 2022 and has been trialed since without any issues or incidents.
A snapshot of the ledger will be generated, which will be made available on GitHub under this addressafter the fork commences. The snapshot will be verifiable by using https://github.com/iotaledger/snapshot-tool-new-supply, also after the fork commences. Information about the snapshot will be made available in this GitHub repository.
If you maintain a node on the IOTA network, following the Stardust upgrade, you should upgrade your software to the latest Hornet release, which will be available soon with the version number 2.0.0. You can download the new Firefly IOTA version 2.0.0 here after the network is operational.
Please note that we will not provide any tooling or software for the IOTA Stardust Classic network. An endpoint for IOTA Classic will be available at https://api.iota-classic.iotaledger.net after the fork commences. To the best of our knowledge, no one has yet attempted to garner community support to take over the maintenance of the IOTA Classic network. We welcome any moves to do so: if you are interested, get in touch via Discord.
Users who previously staked for assembly tokens will be allocated an airdrop, displayed in this tab in the Firefly wallet.
The new Firefly wallet version contains a tab displaying the airdrop sent to users who previously staked for Assembly tokens. After the Stardust upgrade is complete, ~10% of the airdrop will be immediately available to users, with the remaining ~90% vesting every two weeks over a period of 24 months. No user action is required to migrate tokens to the IOTA Stardust network and no action is required to access the airdropped IOTA tokens.
For any questions on Stardust, get in touch with us through Discord.
TL;DR: This blog post is the first in a series that explains the IOTA 2.0 protocol update before it is introduced as a network. Join us as we forge a future where digital autonomy is not just an ideal, but a tangible reality. To achieve this reality, we need an infrastructure that enables it: That is what we are building with IOTA 2.0. With our research concluded and implementation well underway, the time has come to explain IOTA 2.0 in detail. Future blog posts, videos, and wiki articles will delve into the core principles and other aspects of IOTA 2.0, explaining its architecture and advantages.
In the realm of technical innovation, patience is a virtue.
After an extensive period of research and prototyping, the IOTA Foundation proudly presents IOTA 2.0, a protocol that encapsulates our vision of Digital Autonomy For Everyone.
The entire architecture of IOTA has been meticulously rebuilt from scratch, emerging as a resolute and robust system. This blog post is the first in a series of upcoming blog posts, wiki articles, and videos that will share with you the details of IOTA 2.0 in its entirety. Together they are blueprints for a future where everyone can enjoy digital autonomy.
For a more detailed take on this article, we recommend the Wiki version of this article, to be published on October 5th.
Web2 and its discontents
The internet has turned the world digital, overcoming physical barriers and borders and effectively turning the world into a global village. There’s no doubt that almost all aspects of our lives will eventually be digitized, one way or another, and that we’ll need to safely navigate the digital world in order to interact with anyone else.
But among the convenience of Web2 (the current version of the internet), something vital remains missing – trust, autonomy, and true equality. Web2 falls short of providing us with the freedom we yearn for. It fails to guarantee that anyone is who they say they are, and its centralized nature allows business and political powers to decide who can access and participate, leaving us vulnerable to manipulation, exclusion, and predatory value extraction. We can’t even interact with each other without going through siloed applications run by centralized service providers that extract as much profit – which is usually your data – as possible.
For these reasons and more, it is impossible for any profit-driven entity or state actor inclined to act in the best interest of their shareholders or citizens to establish a world-spanning network that is accepted, trusted, and used by everyone.
Such a system can only be established by someone or something free from profit-driven motives. The most likely candidate is a distributed ledger technology (DLT). As long as they adhere to the core idea of what a DLT is supposed to be, DLTs are impartial, incorruptible, and unstoppable.
Digital autonomy for everyone
There have been incredible improvements in DLT since the early days of Bitcoin. Most notably, the initial notion of transacting monetary value peer-to-peer has advanced to transacting any form of data, making use of the same immutability and security guaranteed by DLT. In turn, anchoring data on a DLT has enabled smart contracts, which are securely and transparently stored and predictably executed on a DLT.
These two factors – immutability and smart contracts – are at the core of Web3. By using Web3, you can base actions and execute logic on immutable and therefore trustworthy information, creating a new form of interaction where you are in full control without having to rely on middlemen service providers. You can replace your siloed Web2 applications with interoperable decentralized applications. Additionally, you can exchange value using the same medium as the exchange of data, allowing for a powerful combination for the first time in the history of digitization.
In this new era, Web3 becomes a formidable challenger to the dominant extractive model of Web2. The centralized service providers, who once held sway over our data and resources, will find their grip loosened as we embrace a more equitable and interoperable system.
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. Our vision seeks to empower individuals to shape their destinies while retaining control over their data and assets – a vision we call “Digital Autonomy for Everyone.”
With the IOTA 2.0 protocol leading the way, the path towards this future begins to unfold. The long-awaited removal of the Coordinator heralds the dawn of true decentralization, paving the way for carefully balanced incentives and a level playing field for all participants.
Our unique value propositions
IOTA 2.0 is an update of our innovative distributed ledger technology. At its heart remains the Tangle, our Directed Acyclic Graph (DAG) architecture where blocks are interconnected in a non-linear manner and confirm each other, unlike conventional blockchains that rely on miners and transaction fees. By combining unique value propositions (see below), IOTA 2.0 will be a decentralized, egalitarian, and sustainable DLT.
The most immediate way IOTA 2.0 will help deliver digital autonomy for everyone is through its innovative accounts system. Your account holds your IOTA tokens and generates Mana, a resource that grants system access. You can use your account to stake, delegate, claim rewards, and issue blocks. It’s a digital home to store assets, host digital identities, and build applications or smart contracts. The account is a decentralized part of the ledger and not registered with the IOTA Foundation or any other party. And thanks to the IOTA Decentralized Identifiers, accounts serve as a digital identity that is accessible, transparent, persistent, self-controlled, portable, and interoperable.
IOTA 2.0 also presents a unique set of value propositions that sets it apart from other DLTs and will empower you to live, work, and transact independently in the digital future:
Feelessness for token holders: All users generate Mana by owning tokens. This is what ensures a share of the network’s capacity, not paying fees out of the IOTA token. Also, issuing blocks doesn’t incur a fee that diminishes token share; therefore, IOTA 2.0 prioritizes network utility and preserves the value of the IOTA token, rather than allowing third-party validators to extract value through fees without intending to use the network themselves.
Sustainable utility-based tokenomics and incentives: IOTA 2.0’s tokenomics is a fair system that treats all participants equally, without differentiation between users and block producers. There is a fixed amount of IOTA tokens and by holding IOTA tokens you generate the Mana utility resource. Unlike other DLTs, IOTA 2.0 avoids dilution and inflation, preventing the compounding effect that enriches the already wealthy.
Collaborative, asynchronous Nakamoto-based consensus: In IOTA 2.0, nodes can add blocks they learn about from their local copy of the Tangle, allowing real-time consensus to emerge without relying on periodic blocks as in traditional blockchains. This decentralized consensus process prevents anyone from having excessive control and censoring or manipulating information. Decisions made locally are relayed to all other nodes until all nodes in the network eventually know all changes made to the ledger.
Reality-based conflict resolution: When using IOTA 2.0, you can enjoy continuous block processing, even during conflicts like attempted double-spends. When a conflict is detected, a node creates a local copy and tracks both potential versions of the truth. Transactions unrelated to the conflict are unaffected by the multiple realities created and the “useless” copy is dismissed once the truth is determined. This keeps ledger integrity intact throughout conflicts, allowing uninterrupted operations for all undisputed transactions.
Coming up
After years of testing and iterative development, our updated, completely decentralized IOTA 2.0 network will be the very best implementation of a feeless distributed ledger based on a DAG.
The next blog post in this series, published on October 3rd, outlines the five core principles underpinning the IOTA 2.0 distributed ledger. Once we’ve explained to you why we have built IOTA 2.0 and its purpose, we’ll dissect the architecture of the protocol, explaining how it works: from the underlying DAG structure to the node networking layer, the Tangle 2.0’s consensus mechanism, tokenomics, and incentives – always with you, the user, in mind and explaining what sets us apart from other DLTs.
And don’t forget to look out for the Wiki version of this article, published October 5th, for a more in-depth look at this topic.
TL;DR: New peer-reviewed papers on our approach to the ledger, networking, and consensus form the theoretical backbone of IOTA 2.0, our forthcoming protocol upgrade. The Ledger Paper introduces a reality-based approach to transactions, the Networking Paper offers a ‘pre-consensus’ through the IOTA Congestion Control Algorithm (ICCA) for efficient throughput and congestion management, and the Consensus Paper ensures informed decision-making using the ‘heaviest DAG’ approach. Combined, they provide a system that enables efficient conflict resolution, and a fair and dynamic environment for the future of DLT.
The primary focus of the IOTA Foundation’s research department is to design the future of the protocol, develop cutting-edge technology, and fulfill the IOTA vision. Therefore, the development of IOTA 2.0, our forthcoming protocol update, is tightly linked with our research progress.
Our researchers and developers have meticulously rebuilt the entire architecture of IOTA from scratch, emerging as a resolute and robust IOTA 2.0. One way of assessing the quality of this work is by evaluating the quality of our academic output, which in turn serves as a validation of the protocol. Specifically, IOTA 2.0 stands on the shoulders of three scientific papers:
The Networking Paper, “Access Control for Distributed Ledgers in the Internet of Things: A Networking Approach”, published in IEEE Internet of Things Journal (also available on arXiv).
The Ledger Paper, “Reality-Based UTXO Ledger”, published in ACM Distributed Ledger Technologies: Research and Practice (also available on arXiv).
The Consensus Paper, “A Leaderless Nakamoto Consensus on IOTA 2.0″, published in IEEE Access (also available on arXiv).
With the recent acceptance of the Ledger paper in the journal ACM Distributed Ledger Technologies, all three papers have undergone stringent peer review, ensuring that the proposed solutions are robust and scientifically sound, affirming the quality and innovation behind IOTA’s new design.
In this blog post, we unpack “The Trilogy”, summarising the academic pillars on top of which IOTA 2.0 is built. But first, let’s comment on the interplay of these three papers.
The big picture
IOTA’s architecture is a testament to the synergy achieved when multiple research components come together. The Networking Paper’s pre-consensus mechanism lays the groundwork, ensuring efficient throughput, and is the foundation for the Consensus Paper. The Consensus Paper is also built on the principles and strategies of a reality-based ledger introduced in the Ledger Paper. Together, these research pieces form a comprehensive framework, demonstrating the advanced capabilities and vision of IOTA 2.0.
Bridging the Networking and Consensus papers
The Networking Paper explains the IOTA Congestion Control Algorithm (ICCA), which acts as a pre-consensus checkpoint. This ensures that, before transactions progress to the consensus stage, they’re first vetted for authenticity, weeding out potential malicious inputs. This preliminary evaluation is vital for maintaining the integrity of a decentralized system like IOTA 2.0, ensuring a clean slate of transactions for the subsequent phase.
Once vetted by the ICCA, these transactions are directed towards the main consensus process, as elaborated in the Consensus Paper. Given that these transactions are pre-filtered, the consensus stage can now focus on validation and verification without being bogged down by questionable inputs.
Together, these two papers illustrate IOTA’s layered approach: first filtering for integrity with the Networking Paper, then validating with the Consensus Paper, ensuring a seamless, efficient, and secure transaction process.
Bridging the Ledger and Consensus papers
The Ledger and Consensus papers serve as pivotal components within IOTA 2.0’s framework.
The Ledger Paper’s introduction of multiple realities forms the foundation for the ‘heaviest DAG’ approach in the Consensus Paper. This integration ensures the consensus mechanism operates with a comprehensive snapshot, making decisions with a holistic view of all possible ledger states or realities.
Leveraging the ‘heaviest DAG’ principle, conflicts among the realities set by the Ledger Paper can be resolved efficiently, eliminating the need for abrupt or complete system halts.
Unpacking The Trilogy
1. The Networking Paper: “Access Control for Distributed Ledgers in the Internet of Things: A Networking Approach”
Diving deep into the infrastructure of IOTA, the Networking Paper presents a framework for how IOTA maintains its decentralized ethos while managing challenges tied to its open-access model. Let’s go through its core facets:
Efficient Congestion Control: IOTA 2.0, through the IOTA Congestion Control Algorithm (ICCA), champions high efficiency in regulating throughput. The mechanism serves as a ‘pre-consensus’, enabling nodes to sieve blocks from malicious users. With ICCA, there’s an assurance of fairness in both throughput (aligned with the user’s Mana) and latency.
Resource-Aware Mechanism: Recognizing that resources, whether bandwidth or node capabilities, are finite, each block is given a ‘work score’. This score captures the amount of resources required from nodes to process that block and is affected by block size and signature, among other factors.
Decentralization at its Peak: The system adopts a deterministic scheduling process, computed in work score per second. This ensures that nodes meeting the minimum hardware criteria can effectively manage and process all visible blocks without being swamped by high-speed devices.
Lightweight Scheduler Protecting the P2P Network: We adopt an efficient scheduling algorithm based on Deficit Round Robin (DRR) to deal with high Mana variance and bursty traffic and to protect the node’s neighbors from spam attacks. The node’s inbox is logically split into several queues, each one corresponding to a different user. The scheduler iterates all queues in sequence and increments a counter (deficit) according to a value proportional to the user’s Mana: if the deficit is greater than the work score of the block at the head of the queue, this block will be scheduled and the value of the counter is decremented by the block’s work score.
Local Traffic as a Mirror of Global Congestion: In distributed ledgers all traffic traverses through every node. Hence, local congestion at a node indicates congestion elsewhere in the network. This observation is crucial, as it presents an opportunity for an access control algorithm based entirely on local traffic and without the need for additional, potentially corruptible, messages between nodes.
Permissionless Access: In IOTA 2.0, each user can produce blocks and add them to the ledger without the need for intermediaries. Hence, to regulate the block generation per user in a decentralized manner, the Networking Paper suggests using a rate setter based on the AIMD algorithm, adapting the issue rate depending on local information, that is the issuer queue length. However, since this approach is more suitable for a high-congestion network, we propose a deficit-based rate setter for the launch of IOTA 2.0, which adapts the rate based on the accumulated deficit.
Built-in Resistance to Spam: In the event of congestion, either due to spamming or high traffic, IOTA’s protocol is designed to selectively drop blocks. When the inbox buffer becomes full, the protocol drops a block from the queue with the greatest work divided by the user’s Mana. The paper demonstrates that these blocks, especially those created by malicious users, are dropped without hampering the throughput of genuine users.
Note: The final version of our congestion control also requires issuers to burn a certain amount of Mana to issue blocks. In this way, users will be required to use the valuable blockspace with caution.
2. The Ledger Paper: “Reality-Based UTXO Ledger”
The Ledger Paper, a cornerstone of IOTA 2.0’s foundation, introduces a significant departure from traditional blockchain architecture: an optimistic treatment of incoming transactions before an eventual consensus is achieved. Here’s what this means, broken down:
Reality-Based Ledger: At the heart of this paper is the introduction of a ‘reality-based’ ledger. In simple terms, this ledger doesn’t just record a single version of events (or ‘reality’). Instead, it allows for multiple, conflicting versions of events to coexist temporarily until a consensus is achieved. This is a radical idea, as it moves away from the classic ‘one chain of blocks’ model that most are familiar with.
Fast and Parallelizable Ledger Progression: In conventional blockchains, transactions are grouped into blocks that are added sequentially to the chain. IOTA 2.0’s approach allows transactions to be processed in parallel. This means the system can handle multiple transactions at the same time, significantly speeding up the overall throughput and responsiveness of the network.
Optimistic Execution of Transactions: Traditionally, a blockchain must resolve conflicts (two transactions trying to spend the same funds, for example) before adding transactions to the chain. IOTA’s reality-based ledger takes a more optimistic approach: it allows transactions – whether they are independent, concurrent, or even conflicting – to be executed and charted. The network later resolves conflicts and reaches consensus, ensuring that the ‘real’ version of events is agreed upon. This means that IOTA can keep operating smoothly and quickly, even if not all users are in agreement about what has happened.
Optimistic Processing as a Mitigation Strategy: By optimistically processing transactions – meaning the system proceeds with transactions even when there is contention over an output – the network can continue to function smoothly while conflicts are resolved. We see this as a viable strategy to mitigate the contention problem inherent in the UTXO model. In the ‘unpacking’ of the Consensus paper below, we’ll see that this feature develops its full strength in combination with our Conflict resolution mechanism.
This approach represents a substantial leap in the quest for a more scalable, efficient, and robust distributed ledger technology. It’s one of the standout features that sets IOTA 2.0 apart from the pack.
3. The Consensus Paper: “A Leaderless Nakamoto Consensus on IOTA 2.0”
Traditional blockchains have a simple rule for resolving conflicts: the longest chain wins. This is a straightforward way to ensure that all participants in a network agree on the history of transactions. However, IOTA’s unique architecture requires a more sophisticated approach. This is where the concept of the ‘heaviest Directed Acyclic Graph (DAG)’ comes into play, in which the Tangle itself is used for conflict resolution. Let’s break this down into the main points:
Heaviest DAG: Instead of simply following the longest chain of blocks, IOTA nodes look at a more complex structure: a DAG, known as the Tangle. In this system, the ‘heaviest’ DAG (meaning the one with the largest number of non-conflicting transactions) is deemed the authoritative version of the transaction history.
Leaderless Consensus Mechanism: Traditional blockchains often rely on some form of leadership: a miner who finds a new block, or a group of validators who agree on the next block. IOTA’s consensus is leaderless, meaning that no single participant has authority over the others. This approach is more democratic and reduces the risk of centralization, enhancing the network’s security and resilience.
Streamlining Conflict Resolution in IOTA: In most blockchain systems, each block is a collection of several transactions bundled together. IOTA takes a radically different approach: each block contains just a single transaction. This seemingly simple change has profound implications for how the network operates and resolves conflicts. With each block containing only one transaction, conflicts can be identified and addressed at a granular level.
No Need for Total Ordering: Traditional blockchains must establish a total order of transactions, which means every node in the network has to agree on the exact sequence of all transactions. IOTA’s approach bypasses this need. With single-transaction blocks, the network can resolve conflicts independently and in parallel, without having to agree on the order of unrelated transactions.
Enhanced Network Responsiveness: This structure allows IOTA to operate with a high degree of responsiveness. Because the network is resolving conflicts continuously and independently, transactions can be confirmed more swiftly, allowing the ledger to progress without unnecessary delays.
In conclusion, the Ledger, Networking, and Consensus papers serve as the three cornerstones of IOTA 2.0. Together, they form a comprehensive framework, designed to address the challenges and capitalize on the opportunities of a decentralized future.
Anyone following our progress closely is likely aware that we’re currently implementing the above-mentioned principles and methods. Coming up next is a full introduction to the IOTA 2.0 protocol, going into the deepest levels of all its aspects, including full documentation. In the meantime, if you have questions or suggestions, feel free to get in touch on our Discord.
TL;DR: The IOTA Foundation, projects in its ecosystem, and BC100+ recently showcased blockchain applications for sustainability at a workshop hosted by the Global Business Blockchain Council and European Partners for the Environment in New York City. The event emphasized DLT’s role in fostering sustainability and IOTA’s collaborations with projects like Demia (IOTA spin-off), KUPKrush, and Zentrix.io to promote environmental goals. The IOTA Foundation is committed to a positive social impact and encourages Web3 builders engaged in similar projects to join their efforts.
Since its inception, IOTA has been architected from the ground up to be energy-efficient and sustainable. We have also focused on fostering real-world impact and enabling purpose-bound assets, as well as encouraging collaboration between projects, dAPPs, and communities around issues of green tech and sustainability goals.
On September 13th, 2023, IOTA Foundation’s Mariana de la Roche took part in a think tank workshop organized by the Global Business Blockchain Council and European Partners for the Environment and hosted by Microsoft in New York City. The event was an opportunity to illustrate how IOTA is being leveraged to create blockchain applications for sustainability.
In her presentation, Mariana discussed BC100+, where she is a member of the steering committee and which includes the IOTA Foundation as a founding member. BC100+ connects the blockchain ecosystem to the broader efforts of UN agencies and global initiatives in support of the UN Charter values and the SDGs.
IOTA tech creating sustainability
Also presenting at the workshop were three IOTA community projects:
Demia (formerly known as DigitalMRV) is a spin-off from the IOTA Foundation and ClimateCHECK that over the last five years has worked with organizations like UNFCCC, Gold Standard, and Dell Technologies. It’s a carbon market orchestration platform that enables projects to be audited and certified efficiently, increasing the value of their carbon credits. According to Mathew Yarger, CEO and Founder: “In our pursuit of a global data commons for emissions data at Demia, collaboration is not just an option; it’s our compass. By working within a thriving ecosystem like IOTA’s and participating in collaborative events like the BC100+ initiative, we’re able to accelerate joint progress, harmonizing our efforts to build a more transparent, secure, and sustainable future”
KUPKrush aims to harness IOTA to change the economics of recycling by embedding environmental, recycling, and disposal costs for products in their original selling price, instead of letting those costs fall on communities and future generations. KUPKrush uses IOTA tech to reward each verified action that moves an item closer to being recycled with a small sum that is paid instantly without the energy waste and transaction fees associated with most blockchains. According toTerry Shane, KUPKrush CEO, and Founder, “IOTA was chosen because the network provides an immutable, self-auditing record of the lifetime history of each product to eliminate the potential for “greenwashing”. We envision a world in which all recycling history information, down to the individual item level, is freely available to all cities and their citizens as part of a transparent, open data-commons”.
Zentrix is a Web3 development and consultancy one-stop-shop with hands-on experience in the industrial application of blockchain technology, MVPs, and prototype development. Its CEO, Nenad Gilgoric, represented the DIG_it consortium at the workshop. Dig_IT is an EU-funded Research and Innovation consortium to digitize the mine supply chain and create a more sustainable mining industry. According to Nenad: “Using blockchain for monitoring processes and performance in mining can promote responsible production and consumption by tracking the source of minerals and ensuring that they are extracted and processed in an environmentally and socially responsible manner. This can help reduce the negative environmental and social impacts associated with mining by imposing traceability and enabling regulative compliance against the first of the five-step framework of the EU conflict minerals regulation (2021). Being a part of BC100+ gives our project voice and exposure, enabling us to share the knowledge, resources, and best practices we developed for the sustainable mining industry.”
If you are a Web3 builder engaged in a project or dApp that harnesses distributed ledger technology such as IOTA for a more environmentally sustainable future, our Touchpoint Open Builders Program wants to hear from you, either through the Touchpoint application form or in our IOTA Discord server. You can also read more about the IOTA Foundation’s commitment to positive social impact here.
To discover more about the work of the BC100+ in building a more sustainable and inclusive world through blockchain, visit https://bc100plus.org.
TL;DR: IOTA is undergoing a major upgrade with Stardust, aiming to enhance its tokenomics and capabilities. After the launch of IOTA 2.0, we will introduce programmable smart contracts on Layer 1. The Assembly project and token will be discontinued in favor of IOTA Chains, a generalized smart contract framework. A new Ecosystem Fund will be created to decentralize governance and support ecosystem growth. A temporary token inflation over four years will support this fund. We also discuss token distribution changes and governance.
Over the past decade, the crypto market has evolved from what was initially a small community of idealists and dreamers experimenting with novel concepts on Bitcointalk Forum, into a global industry with billions in yearly investments and tens of thousands of people working full-time to progress the adoption of distributed ledgers and cryptocurrencies.
When IOTA was started in 2015, the team and our community were driven by a vision to create a better, sustainable, and more equitable future for everyone. Our primary goal was to create an impact in the real world, showcasing the potential of IOTA across all industries together with large enterprise companies and governments. Guided by a scientific approach, we introduced the first DAG-based DLT architecture, and over the years have developed it further into a reliable, global network infrastructure.
With our forthcoming IOTA 2.0 protocol upgrade, we will take the next big step to introduce a unique and highly competitive protocol architecture that is fully permissionless, leaderless, and decentralized. This has the potential to position IOTA as one of the leading technologies for traditional industries and for new Web3 ecosystems to build, grow, and scale on IOTA.
To make this future a reality, we feel that now the time has come to make bold decisions, double down on IOTA, and maximize the utility and economic activity of the $IOTA token. To do so we had to make some key decisions.
The four key decisions we want to share today are:
We will focus on maximizing the utility, scalability, and economic activity of the IOTA network and the $IOTA token, with Shimmer positioned as a complementary staging network to validate and expedite the technical roadmap of IOTA.
After the launch of IOTA 2.0, we will introduce programmability on the IOTA Layer 1 (L1) by integrating general-purpose smart contracts. This will help to maximize the utility of the $IOTA token by increasing the demand for Mana and it will align L2 networks with the IOTA L1 through shared security.
We will not further develop and release the Assembly project and the Assembly token. Instead, we will focus our efforts on IOTA Chains, our generalized smart contract framework for anchoring Layer 2 (L2) blockchains on IOTA, and developing L1 smart contracts. IOTA holders that staked for Assembly tokens will get an IOTA token airdrop.
We will introduce a new Ecosystem Fund that will help further decentralize the governance of IOTA and support ecosystem growth. Several community governance vehicles, committees, and entities will be set up to empower the community to help manage the ecosystem fund. This Ecosystem Fund will be funded through a temporary token inflation that will last for four years, increasing the total supply to 4.6 billion IOTA tokens.
Future-proofing IOTA
IOTA 2.0 will be a consensus and settlement layer capable of securing and tokenizing assets, to enable seamless and frictionless transfers and to connect and create new digital ecosystems for Web3, enterprises, and governments. Our leaderless consensus is one of the best alternatives to the existing validator/miner-based networks by maximizing decentralization and permissionless participation for everyone.
Our generalized smart contract framework (IOTA Smart Contract Chains) will allow anyone to deploy and anchor WASM or EVM-based L2 networks into the IOTA L1. The upcoming launch of the ShimmerEVM on the Shimmer network – the staging network of IOTA – will mark the launch of the first smart contract chain in the IOTA ecosystem. We will continue investing in IOTA Chains to increase customizability, decentralization, tooling, features, interoperability, and broader support with existing solutions. This includes supporting zkRollups and other zk-based technologies in the future.
Just some examples of L2 networks that are currently being developed within our ecosystem are:
ShimmerEVM, the first EVM-compatible smart contract chain to launch on Shimmer. This will be the basis for an entire DeFi ecosystem to be created.
GovChains, which we have developed through EBSI (European Blockchain Services Infrastructure), are an example of government-operated L2 networks to be built on IOTA to enable new digital services for governments and citizens (e.g. digital identities, digital product passports, registries, etc.)
TLIP is a network for trade and logistics, currently already running in a large-scale pilot in Kenya and being expanded across Africa and other countries.
Demia is an L2 network for tracking, securing, and making decisions based on verifiable climate data.
These L2 networks will finally introduce programmability and dApps to the IOTA ecosystem. However, unless they are unified and share security with the L1, they will inevitably take activity and liquidity away from it, thereby decreasing its security and growth.
To further expand the possibilities of IOTA and enable shared security and liquidity, we will introduce programmability through general-purpose smart contracts on the IOTA L1.
The full picture:
With IOTA 2.0, we will have a highly competitive consensus and settlement protocol to establish IOTA’s unique ledger architecture as a foundational trust layer;
With IOTA Chains, we have a framework for building and launching general-purpose and application-specific L2 smart contract networks on IOTA, including EVM and WASM-based networks;
With the introduction of L1 programmability, we will have a framework to open up the IOTA base layer to new possibilities for builders to create applications and utility on a single, highly scalable, and composable network and to secure and connect L2 networks built on IOTA.
Smart contracts on IOTA L1
Through a multi-year development effort, L1 smart contracts on IOTA will be introduced through a general-purpose VM (Virtual Machine). This solution will run on the unique DAG of IOTA 2.0 without limiting the overall scalability and throughput of the network.
Applications built on IOTA through L1 smart contracts will generate significantly more demand for Mana, which in turn will increase the demand for $IOTA tokens. This self-sustaining economic system is key to increasing the security of the IOTA network and in turn, generating more demand for applications and L2 networks to build on IOTA.
More progress updates and details on the solution will be shared in the coming months. The work on the solution has already started some months ago, with a new team focused on L1 smart contracts. The development of L1 smart contracts is a multi-year effort and we only intend to launch a public testnet of this sometime after the launch of IOTA 2.0.
$IOTA Tokenomics: One token to create a thriving ecosystem
With IOTA 2.0 and the introduction of Mana, the tokenomics of IOTA will receive a major overhaul. The upcoming demand for blockspace through L1 smart contracts, asset tokenization, and IOTA Chains anchoring activity will create more demand for IOTA tokens, thereby underpinning them with intrinsic value and utility. An increase in the value of the IOTA token also directly increases the security of the entire network, which in turn creates more demand for blockspace.
Demand for blockspace is the main driver for the value appreciation of IOTA. The more demand we have for blockspace, the more demand there is for Mana and thus, the IOTA token. With the introduction of L1 smart contracts, we expect to see the demand for Mana increase significantly. This will be a virtuous cycle where more adoption will lead to more demand for IOTA tokens to be staked to secure the network and to gain access to the network. Together with our ecosystem, we want to focus on maximizing the utility and economic activity of the IOTA L1 and the $IOTA token.
A deeper dive into the Tokenomics of IOTA 2.0 and the involvement of Mana will be published in the forthcoming IOTA Tokenomics Whitepaper.
We will not release Assembly and the Assembly token in favor of IOTA
We had initially intended to introduce Assembly because, at the time of the announcement, we did not have a feasible solution to establish programmability through general-purpose smart contracts directly on the IOTA L1. UTXO-based smart contracts were a very limited concept, not capable of delivering the kind of flexibility we envisioned. Over the past year, the DLT space, as well as our research teams, have made great progress in that direction. We have shown that we can indeed achieve programmability by directly embedding smart contracts on our L1 ledger without limiting the overall network’s performance.
This development, in combination with the advancement of zkRollups (which inherit the security of the L1 through cryptographic proofs, thus they no longer require complex mechanisms to guarantee economic security through a native token), proved to us that Assembly’s envisioned technical architecture, while technically feasible, would introduce too much of a delay on our technical roadmap and it would introduce a solution that we deem inferior to our new approach with L1 smart contracts.
With the planned introduction of smart contracts on L1 and the further development of the IOTA Chains framework for AppChains and zkRollups, the role of Assembly within the IOTA ecosystem would be obsolete. While we could continue to invest resources into it, launching a technologically inferior solution and yet another token would further fragment the ecosystem.
Instead of creating further complexity in our protocol, creating a potentially competing solution that takes away value from IOTA and the $IOTA token and diluting our focus, we have made the decision to officially stop Assembly and the Assembly token before its launch.
The ideas, concepts, and the intended value creation of Assembly will instead flow into IOTA. Instead of having competing tokens across the layers, we will embed the $IOTA token within all core functions of our network. The combination of a highly scalable, decentralized, and secure settlement layer with IOTA 2.0, the IOTA Chains framework for AppChains and zkRollups on L2, and the introduction of smart contracts on L1 will position IOTA as one of the leading Web3 ecosystems.
While this was a difficult decision to make, we are confident that this is the best path forward for IOTA and the future we want to create. IOTA stakers that have received Assembly tokens will be eligible for an IOTA token airdrop. Further details are provided below.
Ecosystem Fund to support IOTA’s growth and adoption
Since the start of IOTA in 2015, we have always done things differently than others. We did not raise a large funding round with our initial token sale (only $500k was raised), 100% of the token supply was issued to the community and we did not reserve any tokens for the founders, team, or the foundation. All development was funded by donations from the community.
As the industry evolved over the years and new token projects started to progressively reserve more of their issued token supplies to spend on marketing activities and adoption, it became increasingly more difficult for IOTA to compete with our limited ability to invest in the ecosystem’s growth and adoption.
The upcoming release of IOTA 2.0 and the launch of smart contracts on IOTA will mark a turning point. Together with our ecosystem we can finally take matters into our own hands and forge our own success. However, technology alone will not help IOTA succeed. Only by combining technology with the ability to invest in growth and adoption will we be able to position IOTA as a leading ecosystem again. Instead of battling for survival, we need to battle for adoption.
Before the launch of IOTA 2.0, we now have an opportunity to change IOTA’s tokenomics from 2015 by making an adjustment to the token distribution for the first and final time. Through a temporary token inflation that will last four years, we are introducing a new dedicated Ecosystem Fund to support the growth and further development of IOTA and realize its vision of the future.
IOTA token distribution with Stardust fork
The new IOTA ecosystem fund will be funded through the vested release of new IOTA tokens created as part of the upcoming IOTA Stardust hard fork (more details below). Following the hard fork, there will be a temporary bi-weekly token release that will last for four years, after which the total supply has been reached. This token release over four years will equate to an average temporary 12% inflation per year. After these four years, the circulating token supply of IOTA will be equal to its new fixed total supply of 4,600,000,000 IOTA. (Note that we are using a new IOTA token denomination: for more details, see the end of this article).
With the new token distribution, existing holders will retain more than 60% of the total supply, while the new IOTA ecosystem funds, contributors, and the IOTA token airdrop to those who staked for Assembly will together be less than 40%.
The following visuals break down the token distribution and release schedule, with the entities that will receive IOTA tokens through this release schedule:
0:00
/
IOTA Holders: Existing IOTA holders own a total of 2,529,939,788 IOTA tokens.
Unclaimed Tokens: The 176,304,541 unclaimed IOTA tokens from the Chrysalis network upgrade will be removed from the circulating supply and only released once valid claims are processed. After the end of the two-year claim period, the community can decide whether these tokens should be burned to reduce the total token supply or assigned to the IOTA Treasury DAO. More information is below.
Treasury DAO: The Treasury DAO will receive 54,896,344 IOTA tokens, as was officially decided in a governance vote in 2022. As part of the unclaimed tokens of the previous migration period, a final valid manual claim of 7,664,631 will be processed.
Ecosystem Fund: In total, the ecosystem fund will equal 1,820,469,717 IOTA tokens, which will be gradually released over four years. This ecosystem fund will be used for R&D (IOTA Foundation) and for Ecosystem Funding (TEA and IOTA DLT Foundation), as well as contributors and an IOTA airdrop.
Tangle Ecosystem Association (based in Zug, Switzerland): Responsible for ecosystem funding and support, with a key focus on Europe and the US. TEA receives 12% of the total supply, or 552,000,000 IOTA tokens. 10% of those tokens will initially be unlocked, with the remainder unlocked through bi-weekly releases over four years.
IOTA Foundation (based in Berlin, Germany):The main entity responsible for the R&D and government affairs work of IOTA. Receives 7.075% of all tokens, or 325,469,717 IOTA Tokens. An initial unlock of 10% of the locked IOTA tokens, with the remainder unlocked through bi-weekly releases over four years
IOTA DLT Foundation (based in Abu Dhabi, UAE): Responsible for ecosystem funding and support, with a key focus on the MENA, Africa, and Asia regions. Receives 12% of the total supply, or 552,000,000 IOTA tokens. An initial unlock of 10% of those tokens with the remainder unlocked through bi-weekly releases over four years.
Contributors: Contributors are key partners and dedicated members who are helping IOTA and the ecosystem. They will receive a total of 5% of the total supply, or 230,000,000 IOTA tokens. An initial unlock of 10% of IOTA tokens, with the rest vesting over 24 months.
IOTA Airdrop: Airdrop for IOTA stakers that staked for Assembly tokens. A total of 3.5% of all tokens, or 161,000,000 IOTA Tokens, are distributed to IOTA stakers. An initial unlock of 10% of the IOTA Tokens, with the remainder unlocked through bi-weekly releases over 24 months. This airdrop will be directly visible within the wallet of each eligible user.
With the removal of the unclaimed tokens from the circulating supply, at the time of the network upgrade, the circulating supply of IOTA will be 2,785,272,714 IOTA tokens which is slightly more than today’s token supply of 2,779,530,283 MIOTA. Over four years, through a release of tokens every two weeks, the circulating supply will gradually increase. After four years, the total supply of 4,600,000,000 has been reached. It is important to mention that the community can vote in the future to further reduce the total circulating supply by burning the unclaimed tokens (more information below).
Governance of the ecosystem funds
In our efforts to further decentralize the ecosystem, two new entities have been established to further streamline and accelerate the growth and support of IOTA and its ecosystem. Separately to the IOTA Foundation, which is primarily focused on the R&D and regulatory affairs efforts, the Tangle Ecosystem Association based in Zug, Switzerland, and the IOTA DLT Foundation based out of Abu Dhabi, UAE, have been set up to support the IOTA ecosystem.
Under the legal umbrella of the Tangle Ecosystem Association and the IOTA DLT Foundation, our community will be empowered to initiate, set up, and run purpose-bound committees that will work collaboratively to improve IOTA and the overall ecosystem. These committees will be able to receive and steward budgets from the newly created ecosystem fund in a transparent manner.
The purpose of these committees, as indicated by their charter, is to support the growth of IOTA and its ecosystem by responsibly managing the new ecosystem token treasury. The governance structure for the Tangle Ecosystem Association and IOTA DLT Foundation have been uniquely designed to empower the IOTA community with special privileges. These privileges are:
Governance over token treasury: Through a formal governance process, the IOTA community can propose and vote to establish special committees that will manage part of the token treasury for specific purposes (e.g. establish IOTA gaming ecosystem, IOTA marketing initiatives, Asia adoption, etc.).
Oversight and transparency: The community will have oversight over how budgets of token-voted committees are allocated. Updates on the overall spending of the ecosystem funds will be shared every quarter, with a detailed yearly transparency report published at the end of the year.
Through a formal governance process, the community can establish specific committees. Community members will be voted into these committees through a token voting process, and the committees will be hosted under the legal umbrella of the entities. These committees are then directly responsible for allocating a predefined budget and can do so with autonomy.
The tasks of these committees can cover a wide range of important ecosystem responsibilities such as community building, marketing initiatives, public goods funding, pushing adoption in certain markets and industries, infrastructure integrations, organizing hackathons and events, and many others. The community will be empowered to propose these committees for specific tasks and nominate the members for these committees. If such proposals find enough support in the community and align with general guidelines and principles, the proposed committee will be established and will receive a budget from the newly created Ecosystem Fund.
We believe that this is an important step to further decentralize IOTA and to ensure its growth. We look forward to working together with our community to realize the vision of IOTA and allocate the new Ecosystem Fund in the best interest of IOTA.
After the Stardust upgrade, we will invite our community and ecosystem partners to work with us on a detailed process that defines the scope and governance of these committees and the respective allocated assets from the ecosystem fund for this endeavor. Exact details will then be discussed and voted on by the community
IOTA Community Treasury DAO
Once smart contracts are deployed on the IOTA mainnet, we will finally be able to officially establish the IOTA Community Treasury DAO. This DAO will receive 54,896,344 million IOTA tokens, as decided by a community-wide governance vote in 2022. The IOTA Community Treasury funds will be fully available after the IOTA smart contract chain has launched and the necessary governance smart contracts for this DAO have been deployed.
We recommend that the Tangle Treasury (recently established under the legal entity Tangle DAO LLC incorporated in the Marshall Islands) should receive a first budget from the IOTA Community Tokens to begin the operation of an IOTA Community Grant program along with its already successfully running Shimmer Grant Program. This initial budget allocation will make it possible for the IOTA Community Grant program to immediately become operational and start supporting the ecosystem.
After the IOTA Stardust upgrade, a governance vote amongst IOTA token holders will be held to officially enable the IOTA Community Grant Program under the Tangle DAO LLC. The IOTA Community Governance group has already created a governance proposal to facilitate these implementations.
IOTA token airdrop
Part of the total supply of the Assembly token had been distributed to IOTA stakers. To date, this amounts to 12,380,515,719.163956 ASMB tokens or around 12% of the total Assembly supply.
Because the development of the Assembly network has been stopped, stakers will not receive Assembly tokens. IOTA holders who have staked for Assembly tokens will be eligible for an airdrop of IOTA tokens. Following the IOTA Stardust network fork, roughly 161,000,000 IOTA, or 3.5% of the total supply, will be airdropped to IOTA stakers.
Any staker can look up the amount of IOTA tokens that will be airdropped to them by searching for their addresses in the token distribution for IOTA Stardust.
A new version of Firefly that displays the amount of IOTA tokens that will be airdropped to any staker will be released after the IOTA ledger has been upgraded to the IOTA Stardust protocol version. Likewise, the IOTA explorer will display future token unlocks for all addresses.
Apart from an immediate unlock of 10% of the allocated tokens per address, airdrops of IOTA tokens will be happening pro rata, over 24 months through bi-weekly automated unlocks.
Unclaimed tokens
After the IOTA network’s upgrade to the Chrysalis protocol version in February 2021, users were required to migrate their tokens to a new EdDSA-based ledger layout. From this migration period, 176,304,674 tokens still have not been migrated by their owners. The current ability to auto-migrate tokens from the pre-Chrysalis IOTA network via the Firefly wallet will end with the IOTA Stardust upgrade. Once IOTA smart contracts are available on the IOTA network, this feature will be restored and migrations can be processed automatically again.
The Coordinator for the current IOTA legacy mainnet will be deactivated synchronously with the upgrade of the IOTA network from Chrysalis to Stardust. We thank the engaged group of community members who have still been operating nodes in the legacy network since the Chrysalis upgrade in 2021 for their service to the community.
Until the new migration solution of the Stardust ledger is implemented, there will be a period in which no further claims can be processed. Therefore, we recommend that anyone who has been waiting for the migration of their tokens from the legacy network to migrate their tokens now to the Chrysalis network with the Firefly wallet’s automated migration functionality before this feature is temporarily deactivated with the Stardust protocol upgrade.
Once the smart contracts-based migration solution is established, the network will continue to service migrations for another two years before the ability to migrate tokens from the legacy network will end. After that time, the community will vote on whether any unclaimed tokens should be burned (thereby reducing the total token supply) or whether they should be contributed to the Community Treasury DAO.
Next Step: IOTA fork with Stardust upgrade
On September 29th, 2022 the Native Tokenization Framework (referred to internally as “Stardust”) was released on Shimmer. Since then, it has been battle-tested for release on the IOTA network. Two weeks from today, IOTA will be upgraded to the Stardust protocol.
With the Stardust upgrade, IOTA will receive exciting new features that will greatly increase its utility, including:
Transforming IOTA into a multi-asset ledger through the ability to feelessly mint, tokenize, and transfer native assets
The ability to feelessly mint and transfer NFTs on the IOTA L1
Smart contract tokenization, which enables the anchoring of L2 Smart Contract Chains on IOTA’s Tangle via the IOTA Chains Framework and enables IOTA to act as a trustless asset bridge between L2 Chains.
Asset wrapping, which enables assets from L2 chains to be wrapped and unwrapped into L1 native assets.
The IOTA L1 will become a messaging layer for smart contract requests between L2 networks.
Once the IOTA network has been upgraded to Stardust, the IOTA and Shimmer networks will have feature parity until the Shimmer network advances further to accommodate IOTA 2.0. L2 smart contract chain will be launched on the IOTA network after they have been sufficiently tested and trialed on the ShimmerEVM.
With the Stardust upgrade, the IOTA network will fork. One network will have the tokenomics adjusted to allow for the creation of a new ecosystem fund, while the other network fork will keep the same token supply as today. Technically, two networks will be spawned from the current Chrysalis IOTA network:
IOTA Stardust: A network upgraded from the current Chrysalis protocol version to the Stardust version, with a total supply of 4,600,000,000 IOTA and a circulating supply of 2,785,272,581. Over four years, tokens will be unlocked through a temporary token release matching roughly 12% of new tokens per year.
IOTA Stardust Classic: A network upgraded from the current Chrysalis protocol version to the Stardust version, with a total supply of 2,779,530,283 IOTA (under the old denomination).
Tokens in both networks will be accessible by their respective owners using their private keys as used in the current Chrysalis protocol version of the IOTA network. There is no user action required to migrate tokens to either of the upcoming Stardust networks. A simple wallet upgrade is sufficient. Tokens held on exchanges are unaffected by this upgrade.
Node operators need to make a decision on which network they support. Instructions will be provided at the time of the upgrade.
Please note that moving forward, the IOTA Foundation will only support the IOTA Stardust network. Any entity or group eager to take over the operations of the IOTA Stardust Classic network needs to garner sufficient support from the community so the IOTA Foundation can hand over the keys of the distributed validators to them.
The IOTA Foundation will maintain the IOTA Stardust Classic network for four weeks, starting with its launch, but not provide any technical or user support for it, including node software and wallet software, exchange integrations, as well as any adaptations of libraries.
The current Chrysalis DevNet will be deactivated three months after the upgrade of the IOTA network to the Stardust protocol version, to enable large entities and corporations to migrate their applications.
Validator Committee on IOTA Mainnet
Together with the Stardust network upgrade and the new token distribution of IOTA Stardust, the Coordinator node previously operated by the IOTA Foundation, will be replaced by a permissioned validator committee, operated by multiple entities, as introduced this week.
While this new committee setup is only an intermediary step until IOTA 2.0 is introduced on the IOTA network (which will implement fully permissionless and decentralized Delegated Proof of Stake-based validation of the network), it meanwhile offers a higher grade of decentralization, censorship-resistance, and resilience.
We believe this to be a simple but useful intermediary step to further decentralize the network until its next major upgrade to IOTA 2.0 occurs.
The IOTA Stardust Classic network will also receive a validator committee. If an entity or a group gathers sufficient support from token holders to take over the validator committee, that group can take over the nodes in the validator committee and determine who should maintain them.
New IOTA token denomination: moving away from metric unit prefixes
At the inception of IOTA, we intended to adhere to standards by using metric system prefixes. However, indicating a multiple or submultiple of the unit has been proven impractical to deal with daily, especially since, at most, one of those units is used (MIOTA). With the Stardust upgrade, we will therefore change the units of measurement.
Instead of kilo (KIOTA), mega (MIOTA), giga (GIOTA), tera (TIOTA), peta (PIOTA), the new smallest unit in IOTA is called “micro”, or “micros” for multiple units. What was previously 1 MIOTA will now simply be one IOTA. 1,000,000 micros equal 1 IOTA.
These units of accounts are already in place with Shimmer today, where glow is the smallest unit.
Finally, the following timeline outlines the main ETAs detailed in this blog post:
We understand that this is a lot of information to take in. These strategic choices have been made to position IOTA as a prominent protocol for both conventional industries and emerging Web3 ecosystems to establish, flourish, and expand using IOTA. Don’t hesitate to inquire about any uncertainties you may have, either by participating in Dominik’s upcoming online AMA today, Friday 15 September, at 18:00 CEST or by getting in touch with us through Discord.
TL;DR: IOTA plans to establish a regulated foundation in Abu Dhabi, UAE, to expand its global presence and decentralize governance. The new entity aims to foster IOTA’s growth and support the crypto community. It aligns with the UAE’s vision for technology innovation, positioning IOTA as a DLT leader in the region and beyond.
IOTA is thrilled to announce a significant milestone in our journey towards establishing IOTA as a global, digital infrastructure and innovation ecosystem. We are proud to reveal our plans to establish a new independent, regulated foundation to be headquartered in Abu Dhabi in the United Arab Emirates (UAE). This move underlines our commitment to the UAE and our ambitions to grow IOTA’s reach and importance around the globe. Over the coming weeks, we will share specific details about the entity, its structure, and governance with the community.
The purpose of this entity is to become one of the primary organizations to foster the growth, adoption, and global expansion of IOTA. As we open up a new chapter with IOTA, we need to match technology with the right support to establish IOTA as a global ecosystem. We can only do this by operating out of the right environment. We are convinced that the UAE will offer IOTA the best environment to realize its global ambitions.
Establishing an additional headquarters for IOTA is a step to further decentralize the governance of IOTA. IOTA will only succeed if it is a globally distributed, open, permissionless, and impartial digital infrastructure. We want IOTA to be a public goods infrastructure that will power our digital society and economy. With the new foundation in Abu Dhabi, we are confident that we will achieve this vision of the future.
Pioneering a new era
As we embark on this exciting endeavor, we are proud to declare that we are poised to become one of the leading DLT entities to operate in the UAE. Being established under the new regulatory framework, we intend to work closely with regulators, business leaders, and government entities to further advance the UAE’s global role as a leader in technology and business. This distinction highlights our dedication to embracing robust oversight and well-defined procedures to support and enhance the crypto community within the UAE and worldwide.
According to Dominik Schiener, Chairman of the IOTA Foundation: ”From the very beginning, we have experienced a very warm welcome and unwavering support from leaders, regulators, and businesses in Abu Dhabi. I am simply amazed at how the country operates and how it is being led by visionary and open-minded leaders. This “can-do” mentality is the perfect environment for us to take IOTA to the next level. We are excited to play a role in helping to establish the UAE as a hub for technology innovations.”
Establishing the new entity’s headquarters in Abu Dhabi gives the IOTA Foundation a central hub for overseeing the growth and expansion of IOTA on a global scale. Abu Dhabi’s strategic location and progressive regulatory environment make it an ideal base for our operations, especially across the Gulf Cooperation Council countries and in Africa and Asia.
Empowering the ecosystem
The newly established foundation will operate under the guidance of a dedicated board of directors. One of its primary objectives will be to provide essential funding and support to the rapidly growing IOTA ecosystem. This commitment aligns with our mission to foster innovation and development within the broader DLT space.
Building on our ethos of community-driven progress, the new foundation will enable our vibrant community to actively participate in the creation of committees. This inclusive approach ensures that the collective wisdom and diverse talents in the IOTA community will continue to shape our technology and the governance of the project itself.
Our venture into the UAE marks a significant chapter in IOTA’s journey. We are excited to be at the forefront of regulatory innovation, tokenization of real-world assets, and new Web3 applications by working closely with leading institutions out of the UAE, and building a thriving DLT ecosystem in the UAE and beyond. With an additional headquarters in Abu Dhabi, we are ready to embrace the opportunities and challenges that lie ahead as we continue to lead the way in DLT technology.
Stay tuned for more updates as we embark on this exciting adventure together.
