Blog > Authors > Olga Hryniuk

Mithril: a stronger and lighter blockchain for better efficiency

A new IOHK-developed protocol acts as a stake-based threshold signature scheme allowing for transparent, secure, and lightweight stake leveraging

29 October 2021 Olga Hryniuk 10 mins read

Mithril: a stronger and lighter blockchain for better efficiency

At the Cardano Summit 2021, IOHK researchers Pyrros Chaidos and Roman Oliynykov presented the design and goals of Mithril – new research and engineering effort carried out by IOHK. Mithril will provide a stake-based threshold signature scheme that can be implemented as the protocol to solve chain synchronization, state bootstrapping, and trust issues in blockchain applications.

Mithril is the name used for a fictional metal in Middle-Earth – a malleable material, very light in weight but strong as 'triple steel', which does not tarnish or dim. Thus, the name symbolizes strength in terms of security and a lightweight approach with regard to the developed protocol.

Leveraging stake for signature aggregation

Let’s start with some background information to understand Mithril's benefits for the development of blockchain solutions.

Cardano is a proof-of-stake blockchain, so the consensus algorithm randomly selects nodes to become block producers according to the stake they hold. For certain messages or actions, it is important that a particular number of stakeholders provide their cryptographic signatures. The consensus protocol determines how individual nodes assess the current state of the ledger system and has three main responsibilities:

  • perform a leader check and decide if a block should be produced
  • handle chain selection
  • verify produced blocks.

To achieve greater scalability in a blockchain setting, it is essential to address the complexity of critical operations that depend logarithmically on the number of participants. This means that the higher the number of participants (which are assumed to be numerous), the more complex it becomes to efficiently aggregate their signatures. In a base scenario, to presume a signature that talks for the majority of stakeholders, every stakeholder needs to sign the appropriate individual message. Although this is possible, it is inefficient in terms of scalability and speed.

Given the time it takes to validate a particular message, and the resource usage during chain synchronization, it is vital to provide a solution that makes multi-signature aggregation fast and efficient without compromising security features.

Mithril protocol design

Mithril is a protocol designed to:

  • leverage stake to obtain higher efficiency
  • ensure transparent setup while not requiring increased trust settings
  • leverage trade-offs between size and efficiency, which is guaranteed by the modular component design.

Mithril works in a public setting where signers don’t need to interact with other signers to produce a valid signature. The aggregator combines all the signatures into one, and this process is logarithmic with respect to the number of signatures, which results in a sublinear performance for Mithril aggregation. For example, when applied to full node clients like Daedalus, Mithril can boost full node data synchronization ensuring speed and decreasing resource consumption.

To represent a significant fraction of the total stake, Mithril uses the stake-based threshold setting. This behavior is different from the standard setting in which the given number of participants are required to validate a particular message. In the stake-based threshold setting, the protocol requires a fraction of the total stake to validate a given message to generate a correct signature.

Mithril also certifies consensus in a trustless setting. This means that it does not include any additional trust assumptions. It is possible to achieve consensus certification without including any additional assumptions, other than those already present in the proof of stake. For example, it can work within wallet-as-a-service, and the mobile client will use the certificate obtained from a Mithril node. With advanced security settings, such a procedure is potentially more efficient than SPO blockchain verification.

Finally, to ensure fast chain state bootstrapping, the signature scheme allows different stakeholders to validate only a given checkpoint of the chain. Stakeholders need not go through the whole transaction history of the given state – they simply need to go through the checkpoints to verify that the final stake is valid. This is beneficial for light client applications like light wallets that need to work fast without a full chain synchronization. Mithril signatures can be also useful for lightweight tally verification, or cryptocurrency governance decision making.

How it works

Mithril enables a multi-party signature by holding a number of individual lotteries (M) and considering a message to be valid if it has been signed by a number of different winners (K) over those lotteries. Each user, therefore, attempts to sign the message and then passes its signature through what is considered a lottery function. This function allows individual users to check if their signatures are eligible as lottery winners and output those without waiting. This is different from a standard setting, where slot leaders need to wait until their slot is active to participate. Once there are case signatures over different lotteries, they can be aggregated into a single Mithril signature.


The design of Mithril involves three phases:

Figure 1. Phases of Mithril operation

Parameter setup

To set up a Mithril protocol, users need to:

  • fix the group setting where the cryptography will take place
  • select the index range M, which is the number of elections they will be holding
  • set the quorum size K, which is the number of election winners that need to sign a signature for it to be accepted.

It is also important to provide a reference string for the proof system. This is possible in a transparent manner and does not require any high trust assumptions.


During this phase, users should update the state distribution. This lets every stakeholder know from what stake they are holding. Then, each stakeholder is responsible for registering their keys. This can happen either on or off the chain.

Finally, users need to distribute stake and compress their test keys, which is done using the Merkle tree. This function allows Mithril signatures to be verified against a single hash that represents that Merkle tree. So, the size of the state needed to verify a signature can be kept low.


While working with the chain, users can produce, aggregate, and verify Mithril signatures. Producing signatures involves users’ attempts to check if the signature they produced is actually a winner on one of the lotteries held in parallel. If true, the users will broadcast their signatures. If there are enough signatures supporting a particular message over different lotteries, they can be aggregated into a single Mithril signature. It can then be broadcast and verified by anyone using only the reference string for the proof system and the very short Merkle tree hash of stake distribution.

For example, a single user can create a signature with Mithril as follows:

Figure 2. Mithril signature creation

First, a user will check the amount of stake they hold and pass it through a score function to obtain their score threshold T. Then, they will attempt to produce a candidate signature S. For each index, they will evaluate whether the candidate's signature they produced paired with the message they have just signed. The index number of the lottery they're checking against should also produce a score value that is less than their threshold T. If that is true, then the candidate signature they produced has actually won the lottery on that particular index number. If not, they will make the next attempt.

After trying all possible indexes, users will potentially have one or more indexes for which their signature S is valid. For each of those indexes, they can output an individual signature consisting of their candidate signature, the index number for which it is valid, and the proof that verifies that their score is consistent with the registered stake.

Network architecture

Implementing Mithril on Cardano, we can represent the software interaction as follows:

Figure 3. Mithril network architecture

A high-level representation of software around a stake pool operator (SPO) includes its connection to the Cardano peer-to-peer (P2P) network, the Mithril node’s P2P network, and the Mithril client connected to the node run by an SPO.

The Mithril node at the SPO platform accesses its verified blockchain at the local storage and runs the protocol to produce Mithril certificates that are kept at the Mithril storage. Produced Mithril certificates can be verifiably synchronized across the whole network. Thus, the SPO can share both the full Cardano blockchain and the list of valid Mithril certificates for it. When the Mithril client connects to the network, it requests a list of Mithril certificates and asks only for the longest chain of the Cardano blockchain.

Several SPOs can also participate in such a setting. The Mithril client will then verify that certificates fully confirm the obtained Cardano blockchain. The whole procedure is lightweight and will not require the involvement of significant network storage or computational resources. Moreover, Cardano full node sync and fast sync with Mithril procedures are not mutually exclusive – they can be run in parallel. Mithril fast sync will be later confirmed by the full node sync.

Use cases

Let’s take a look at the use cases where Mithril applicability is highly beneficial.

Mithril boosts the efficiency of full node clients or applications such as Daedalus. It ensures fast and secure synchronization of the full node data, significantly improving time and required resources including computation, network exchange, and local storage while keeping high-level security guarantees.

Mithril is also applicable to light clients and mobile applications, ensuring a trustless approach. Another significant advantage is using Mithril signatures for running sidechains. The main blockchain can connect to different sidechains that can even have different consensus protocols. Mithril has benefits in lightweight blockchain state verification, and thus, certificates can validate the current state of the specific blockchain as well as the correctness of forward and backward transfers in a secure way.

Finally, stake-based voting applications and governance solutions can use Mithril regardless of the voting protocol’s complexity. Mithril signatures can be utilized for secure and lightweight tally verification. This is also useful in governance when stakeholders go through a decentralized decision-making process and provide the final result in an easy and verifiable way.


Several companies are already interested in Mithril implementation within their blockchain solutions. Galois, an advanced R&D firm focused on formal methods, cryptography, and hardware, will be implementing the first Mithril prototype based on the research done by IOHK. Galois will be implementing Mithril in the Rust programming language due to its fast prototyping features. They plan first to present smaller signatures with BulletProofs, then followed by production-ready implementations, and finally formal proofs of correctness.

Idyllic Vision is another company focused on building a self-sovereign identity protocol based on zero-knowledge proofs, a credential management system for organizations, and a mobile wallet for end users that supports interoperability between diverse society solutions. They are planning to implement the proof of concept of the Mithril node. In the following months, they will begin with creating a blueprint of solution architecture, defining a number of system components that should be developed and organically integrated into the existing infrastructure. This includes integration with the Mithril crypto library and the Cardano node, and a networking layer for communication between nodes. The result of this phase should be integrated into Cardano to enable fast bootstrapping of the node and support for extra functionality like lightweight clients as others.

To find out more, read the Mithril research paper and watch the Cardano Summit presentation.

Ouroboros Chronos provides the first high-resilience, cryptographic time source based on blockchain technology

Designed to provide more accurate global timekeeping, Chronos ensures increased security and network resilience to communication delays

27 October 2021 Olga Hryniuk 5 mins read

Ouroboros Chronos provides the first high-resilience, cryptographic time source based on blockchain technology

Global time synchronization across any distributed network is essential to ensure its resilience.

From ensuring up-to-date information between all participants, maintaining accurate transaction processing and block creation, time synchronization is especially important in terms of smart contract deployment.

In collaboration with scientists from the Universities of Edinburgh, Purdue, and Connecticut, Input Output found a way to globally synchronize clocks across a blockchain to provide a more secure and tamper-proof global time source. This includes synchronization of time from internet of things (IoT) devices, like measurement tools in supply chains, and general distributed systems, particularly where the disruption of a central clock represents a security risk. The research is realized by Ouroboros Chronos, the Greek word for time, which is the latest iteration of Ouroboros – the consensus algorithm that underpins the Cardano blockchain.

Time matters

Time is an indispensable concept within computer programs and applications. Without this concept, we would not be able to access any transport layer security (TLS) based websites, exchange data, or utilize various cryptographic algorithms.

Yet, time tracking is a difficult problem to solve. Accurate time synchronization presumes data transmission across the whole internet, and this, in turn, takes time too. It is also hard to predict how much time would be required for certain data transmission – the network state constantly changes and relies on such factors as congestion and the actual size of data among others. Thus, inconsistencies often occur and it is important to provide the tools and solutions for accurate timekeeping.

Real time

With common computers, we take timekeeping for granted. However, there is a rigorous mechanism that works behind the scenes. The Network Time Protocol (NTP), for instance, addresses the timekeeping issue using a hierarchy of servers distributed globally. This includes up to 15 Stratums the routing paths of which are developed to synchronize in the most optimized manner. This is also enabled by the construction of a Bellman-Ford shortest-path spanning tree that decreases both latency and transmission time inconsistencies.

The UK Government’s Satellite-derived time and position: Blackett review recently highlighted the need for more resilient timing data and the dangerous dependence of critical sectors from smart grids to autonomous vehicles on Global Navigation Satellite Systems (GNSS) that are vulnerable to jamming, cyber attacks, and space weather. Additionally, the world’s first National Timing Centre, led by the National Physical Laboratory, was recently created to investigate alternative and more resilient timing services for everything from telecommunications to smart transport. International metrology centers currently have to compare clocks operating at different frequencies and in multiple locations for accuracy.

Blockchain time synchronization

The concept of timekeeping is different for distributed ledger technology. Without an accurate and valid timestamp, the network cannot verify if the transaction that is being processed is valid and does not revert the previous one. There are different timestamping techniques used across a range of blockchain ledgers, however, they aren’t necessarily very accurate. For example, Bitcoin uses timestamps for consensus security reasons, but not primarily for timekeeping; and in Ethereum, on-chain timestamps are determined by miners whereas the consensus won’t technically block or verify those for validity.

Timekeeping is essential for smart contract execution as well. Inaccuracy poses a risk for decentralized finance (DeFi) smart contract attacks. Smart contract vulnerabilities aren’t always conditioned by poor code, time inconsistencies should be resolved to block any possible attacks within the ledger.

Ouroboros Chronos: designed to boost communication and timing resilience

The new research on Ouroboros Chronos enables blockchain technology to synchronize clocks more securely. Chronos is itself a cryptographically secure blockchain protocol that additionally provides an accurate source of time via a novel time synchronization mechanism, eliminating the vulnerabilities of externally hosted clocks. This also enables blockchain to accurately time-stamp transactions making the ledger more resistant to attacks that target time information.

The new protocol can dramatically boost the resilience of critical telecommunications, transport, trading systems, and infrastructures by synchronizing local time to a unified network clock that has no single point of failure.

Professor Aggelos Kiayias, director of the Blockchain Technology Laboratory at the University of Edinburgh and Chief Scientist at Input Output, who led the research, says:

The problem of synchronizing clocks without a central time-keeper is essential in creating a truly robust decentralized financial system. For the first time, we have developed a blockchain mechanism that enables a dynamically evolving group of parties to calibrate their local clocks so they are consistent – even if they come and go following arbitrary participation patterns. By creating a blockchain-based global clock, we have also paved the way to a more secure, tamper-resistant time source with many possible external applications.

By enabling accurate timing and thus full traceability of all transactions, the scientific breakthrough also marks a major step towards creating fully auditable and fraud-proof financial systems.

To find out more, see the published research here.

Thanks to Rachel Bruce, Jenny Corlett, Rod Alexander, and Christian Badertscher for their input and support in writing this post.

UTXO alliance: fostering innovation and collaboration across the blockchain space

We’re partnering with other UTXO-based blockchains to cultivate innovative solutions to advance interoperability, programmability, and scalability

15 October 2021 Olga Hryniuk 9 mins read

UTXO alliance: fostering innovation and collaboration across the blockchain space

At the Cardano Summit, IOHK announced a collaboration with Ergo, Nervos, and Topl to create the UTXO alliance. Today, we’re delighted to welcome a new alliance partner – Komodo.

Komodo is an open-source technology provider that offers all-in-one blockchain solutions for developers and enterprises. Komodo works closely with organizations that want to launch branded decentralized exchanges, cross-protocol financial applications, and independent blockchains. Komodo's flagship end-user application AtomicDEX is a non-custodial multi-coin software wallet and atomic swap-powered decentralized exchange rolled into one app. AtomicDEX and its underlying technology – Komodo AtomicDEX API – is compatible with 99% of cryptocurrencies in existence and offers the widest cross-chain, cross-protocol trading support in the entire blockchain industry.

“UTXO blockchains lay the basis and undisputed foundations of today’s blockchain industry. UTXO technology reflects Satoshi Nakamoto’s core vision of ultimate (financial) liberty,” said Komodo business development leader, Kadan Stadelman. “On behalf of Komodo Platform and the AtomicDEX team, I am honored to join the UTXO alliance to uphold and advance this vision. I am certain that together with other alliance members, we will bring this technology to the next level. All for one and one for all.”

The UTXO alliance will facilitate cross-ecosystem initiatives to extend the capabilities of UTXO in terms of smart contract functionality. Teaming up with other blockchain industry projects, the shared objective is to foster and support further research, development, and education across the entire space.

The goal of the UTXO alliance is to drive continuous innovation of the UTXO model in terms of interoperability, scalability (sharding, state channels), and smart contract solutions. Enhancing these solutions and driving key initiatives to build bridges between blockchains powers fair and accessible global finance for everyone. This also establishes a collective effort to enforce the development and functionality of UTXO-based ledgers. Other projects using this model include NEO, Bitcoin, and its derivatives like Bitcoin Cash, Litecoin, and Zcash.

Why UTXO matters

The unspent transaction output (UTXO) accounting model guarantees security, data privacy, and scalability at the core of financial activities. UTXO models foster scalability, as multiple UTXOs can be handled simultaneously, and ensure enhanced security as the overall stake is not aggregated into a single account.

UTXO is a more secure alternative to account-based models (used by Ethereum, for example). Unlike UTXO-based ledgers, account-based blockchains track the overall balance, and the same address is used every time a transaction is made. This is vulnerable to hacks and hinders scalability, as transactions are processed sequentially, rather than in parallel.

Cardano’s extended UTXO (EUTXO) model, for example, supports multi-assets and smart contracts and enables arbitrary logic in the form of scripts. These scripts can be split across different branches enforcing more parallelism and higher scalability.

Alliance member Nervos is developing a permissionless, layer 1, open-source, proof-of-work blockchain protocol focused on creating the foundations for an interoperable universal public network.

“Implementing the ‘separation of duties’ principle, Bitcoin’s visionary UTXO model is naturally more scalable and prone to attacks than the account model,” said Ren Zhang, lead researcher at Nervos. “Many projects sharing this vision provide unique perspectives to extend UTXO’s possibilities. The UTXO alliance enables interoperability and coevolution of its members, providing the world a superset of our advantages.”

Manuel Chakravarty, Lambda scientist and Plutus architect at IOHK added:

The UTXO ledger model, battle-tested by Bitcoin, remains the gold standard for security and scalability. The UTXO alliance is an important step towards ensuring that it will be the gold standard for interoperability, too.

Focusing on interoperability, programmability, and scalability

Centralized finance has been the centerpiece for financial operations for decades. While such a system has served us well enough in general, it still suffers from a reliance on a central authority, exorbitant transaction fees, and unnecessary delays, complexity, and costs in making international payments because of regulatory restrictions. It’s time for change.


Blockchain technology addresses the challenges of centralization by enabling reliable peer-to-peer transactions based on cryptographic proof rather than relying on costly intermediaries. Many blockchain projects have emerged to provide a secure and decentralized environment for financial transactions. These projects vary in terms of consensus algorithms, accounting models, or smart contract applicability focusing on particular use cases (such as finance, data traceability, supply chain management, etc).

Growth is inevitable. However, the speed at which the blockchain landscape matures is challenged by siloed ecosystems and disparate governance rules, technology versions, or functionality support.

As Romain Pellerin, IOHK CTO, said at the Summit:

Mainstream blockchain adoption will pass only through the interconnection of networks, similar to how the Internet was built by the interconnection of intranets and extranets.

So, today, it is important to ensure that the whole industry is driving towards interoperability. Users should be able to transact with each other without being limited to a certain ledger, smart contracts should be supported within different environments, and decentralized applications (DApps) should have cross-platform compatibility. Only such an approach will allow the blockchain industry to reach the full potential of its capabilities, driving further adoption.


The UTXO alliance is also focused on blockchain programmability for the creation of DApps and smart contracts. In fact, the design of new languages is required in order to adapt to the specific transaction and data storage management (Ergo’s and Cardano’s EUTXO, or Nervos’ cell model, for example) of the UTXO model. The founding members of the alliance have developed Antara, CKB-VM, ErgoScript, and Plutus as their smart contract languages. Alliance members are sharing knowledge and collaborating in the development of those technologies to rapidly scale the number of use cases that can be run on UTXO-based blockchains.

Also, those languages are built as domain-specific languages (DSLs) on top of common programming languages including Scala, Haskell, C, JavaScript, Go, Rust, etc. However, in certain cases, those common languages do not offer the security or ease of use that smart contract developers require.

To ensure enhanced security and code verifiability, IOHK has chosen Haskell as the programming language for Plutus smart contracts. It is the most widely used functional programming language for application development. Haskell is simple, secure, and formally verified. In terms of adoption, it is suitable for a wide range of financial use cases, while allowing to move funds rapidly, get the right results, and ensure scalability. This programming style fits well within the UTXO model with regard to state distribution and parallelization for enhanced scalability.

Nervos is also working on alternative provably secure programming options that use RISK-V compilers to support common programming languages with CKB-VM. Topl, on the other hand, has been working on a chain program engine proof of concept, which is basically an abstraction layer on top of the UTXO model that allows working with shared state execution environments. It uses a pointer registry and a series of UTXOs (represented as atomic data elements in ledger state -i.e., boxes-) to reconstruct an execution context for evaluating program method call transactions.

Taking into consideration different development efforts, the UTXO alliance will be exploring the best-case scenarios to create a unified smart contract ecosystem where a variety of programming languages can be compiled and used on different blockchain platforms. This will be instrumental in ensuring better interoperability between blockchains.


As a network grows, it is also important to take into account its scalability capability in terms of transaction processing and throughput. The UTXO model is different from the account-based one, as it functions based on the local state, and thus requires a different programming approach.

These two models have different properties and offer a different set of trade-offs, different pros and cons. The UTXO model ensures determinism, predictability and scalability by managing local states (the local portions of the overall graph of transactions) while the account model facilitates the development of use cases that rely on the global state (the whole graph of transactions needs to be processed before validation).

Hence, the UTXO model offers valuable properties of ensuring the execution of transactions and contracts prior to their submission on the chain with no surprises in terms of fees or validation. Also, the UTXO model can provide better scalability as it is simpler to shard a graph of transactions by definition by dividing into a set of sub-graphs.

It is also easier to detach a particular transaction or set of transactions (that transport data, scripts and assets) to continue activity off-chain before coming back with a result on-chain which ensures scalability by off-loading activities from the mainchain. IOHK, for example, has developed Hydra state channel solutions that increase the system throughput and allow running multiple operations in parallel without compromising scalability. You can find out more about scalability by reading about concurrency on Cardano and the Hydra approach.

Combining forces for the common goal

The UTXO alliance collaborates to advance the UTXO model while developing a universal UTXO standard. It aims to provide ada holders, cryptocurrency users, enterprises, and the developer community with a range of solutions that do not lock them into a single standard. For this, the alliance will be conducting academic research and releasing a number of papers that underpin secure and scalable smart contract development based on the UTXO model.

While interoperability is key, it is also crucial to provide blockchain solutions for increased funds security, scalability of transaction processing, and, of course, extended functionality granted by smart contracts.

Alliance member Topl has developed a blockchain built to be an impact monetization engine. James Aman, Topl founder and CTO said: “Extended UTXOs enable novel methods of computation in DLT systems that bridge the gap between hard-coded protocol behavior and smart contracts. EUTXOs enable users to engage in complex interactions while retaining full local verifiability even from light clients.”

To enable the possibility of utilizing various features in a blockchain-agnostic way, the alliance is committed to addressing such instrumental questions as:

  • how to seamlessly transfer data between different blockchain environments
  • what is the ideal size of data to be used in transactions
  • what should be the speed of data processing
  • the transaction cost, etc.

Thus, the alliance focuses on the mechanism that enables seamless and secure transactions between different blockchains to foster the greater adoption of blockchain technology. This will also drive the development of solid DApps and DeFi solutions.

Alex Chepurnoy, the co-founder of alliance member Ergo, added: “While it is well-known that UTXOs are better for blockchain scalability and simpler off-chain protocols, the extended UTXO model also allows for novel on-chain DeFi constructions with interesting properties.”

This is only the beginning, and we are currently looking into collaborations with more ecosystems to pioneer improvements of the UTXO model, investigate how the common knowledge and technology stack can improve scalability properties, and contribute to open-source research. We’ll keep you posted as the alliance grows.

Visit the UTXO alliance website to find out more, join the alliance or contribute to the research.

Concurrency and all that: Cardano smart contracts and the eUTXO model

Cardano’s eUTXO model provides a secure and versatile environment to process multiple operations without system failures

10 September 2021 Olga Hryniuk 7 mins read

Concurrency and all that: Cardano smart contracts and the eUTXO model

Cardano is a UTXO-based blockchain, which utilizes a different programming paradigm for decentralized applications (DApps) from other account-based blockchains like Ethereum. The specific flavor Cardano uses is the Extended Unspent Transaction Output (eUTXO) model introduced by the Alonzo upgrade. eUTXO offers greater security allowing for smart contract execution cost predictability (without unpleasant surprises) and, as a result, offers a different approach to parallelization.

eUTXO inherits the per-branches design of the UTXO (Bitcoin) model, where one branch is by definition a sequence of transactions that requires a sequence of validations. To split the logic across different branches and enforce more parallelism, it is essential to build DApps and other solutions using multiple UTXOs. This provides benefits in terms of scaling, just like developing Bitcoin services prerequisites splitting one wallet into sub wallets.

DApps built on Cardano are not limited to one transaction per block. In fact, the block budget (that is the maximum number of transactions it can hold) allows the execution of hundreds of simple transactions and several complex scripts. However, the eUTXO model allows spending a transaction output only once. Given that users can face contention issues trying to access the same UTXO, it is important to use many different UTXOs. Note that this is important unless such a design would benefit from a strict ordering of clients. Sets of UTXOs can be used to implement design patterns that include semaphores. In addition, different users can interact with one smart contract without any concurrency failure. That is because a smart contract can handle a number of different UTXOs that make up its current state and off-chain metadata that allows interpreting those UTXOs.

Doing things in parallel

Blockchains achieve immutability and transparency of transaction processing differently. Any blockchain system should have a set of properties to meet the ever-growing need for secure yet swift operation processing, namely:

  • Throughput – the number of operations a system can perform within a certain time period. This relates, for example, to the number of transactions or smart contracts processed in one second.
  • Performance – how fast the system works. Performance measures the time of transaction or smart contract execution.
  • Scalability – the ability of the system to perform multiple operations without overloading the network or influencing performance properties.

By increasing parallelism, we can ultimately improve the throughput of the system while keeping the performance of individual operations the same, but this sort of scalability will always be limited by the degree of contention.

When it comes to scalability, we also distinguish such system properties as concurrency, parallelism, and contention. Concurrency is essential to allow multiple actors to progress on a certain task without interfering with each other. Parallelism allows such progress at the same time without any interference. Contention occurs when those multiple actors interfere with each other while working either concurrently or in parallel.

Understanding concurrency

Concurrency may or may not improve a system’s performance, throughput, or responsiveness. The amount of concurrency limits the maximum number of simultaneous operations that can be performed.

To obtain actual performance improvements in a UTXO-based blockchain, processors or other actors should be able to perform multiple actions simultaneously. The higher the level of concurrency, the higher the maximum possible parallelism. Such an approach then translates to performance improvements and throughput. It also provides significant advantages over account-based systems (like Ethereum).

Deploying DApps on UTXO ledgers is different

Cardano’s approach to DApp deployment is different and thus it requires a learning curve and a different approach. This is like working with different programming languages: there is one goal – to deploy a solution, but so many programming languages to use for this purpose.

Maximizing concurrency is a skill that needs to be learned: developers need to write code in a way that severely restricts the opportunities for contention (e.g., by avoiding shared states and accidental dependencies). The system must then translate this concurrency into parallelism. A number of developers have already identified ways to approach this, while others are still developing solutions. Simply transplanting lessons learned on one blockchain will not work; while the learning curve is a little steeper, the results make this worthwhile.

Either way, it is important to understand that to deploy a scalable DApp on Cardano, a developer can’t just use an adapted Ethereum contract. Cardano is based on the UTXO model; it is not account-based. And this means that a single on-chain state will not meet the concurrency property on Cardano. Instead, DApps should split up their on-chain state across many UTXOs. This will increase the concurrency in their application, thereby allowing higher throughput.

Our education team has previously shared a simple AMM-style DEX implementation in the Plutus Pioneer course. While this is useful for teaching purposes, this architecture would not directly support a commercial DEX where an order book approach and additional concurrency are required. A developer looking to deploy on the Cardano mainnet would need to improve the scalability of the architecture accordingly.

We proposed a solution within our recent Djed stablecoin paper. For the Djed implementation on Cardano, an order book modeling pattern is favored whereby an order maker is responsible for forwarding any minting or burning order to the stablecoin smart contract, with an additional incentive fee imposed on each would-be buyer or seller of stablecoins and reserve coins. Several security mechanisms – via the extensive use of non-fungible tokens (NFTs) – are also used to guarantee the uniqueness of transactions, the correctness of each submitted order, and to prevent front-running attacks. NFT tokens are also used to report successful or failed minting and burning orders. We’ll publish a fuller article on this shortly.

To learn more about scalability, you can read how to design a scalable Plutus application and find out how to organize DApps on Cardano using order book patterns. Developers have also presented concurrent and deterministic approaches to the eUTXO smart contract architecture that might be regarded as a generalization of the parallel state machine steps introduced in the Hydra paper to realize multi-step state machines. A number of other developers and community members have also published papers, videos, articles, and useful threads on Twitter outlining their approaches. It’s a brilliant lesson in how the community will continue to develop its own innovative solutions, as approaches become more standardized with platform maturity.

Moving forward

The Alonzo hard fork event will introduce the core building blocks of Plutus 1.0. This is the beginning of ecosystem growth. Although it is still early, the Alonzo testnet allows our developers to assess system properties and build scalable DApps in advance – preparing for their mainnet launch. Dozens of projects have already been working with local instances of Plutus environments. With the main public testnet soon supporting smart contracts, we expect a significant ramping up of activity over the next few weeks and in the months ahead. Later this month, the Cardano summit (25-26 September) will showcase many of these projects, plus provide important updates on the smart contracts roadmap and the ongoing evolution of the technology stack. Developer events, hackathons, and, of course, the results of Project Catalyst will continue to bring new tools and abstractions to this fast-growing developer ecosystem.

If you are a developer, make sure to join our Discord community and get involved with Project Catalyst if you are looking to fund your project.

I'd like to acknowledge Lars Brünjes, Jann Müller, and Manuel Chakravarty for their technical input and support during the blog post preparation.

Djed: implementing algorithmic stablecoins for proven price stability

Djed is the first coin to use formal verification to eliminate price volatility

18 August 2021 Olga Hryniuk 7 mins read

Djed: implementing algorithmic stablecoins for proven price stability

Cryptocurrency volatility is one of the obstacles to its wider adoption. Blockchain technologies provide benefits such as transparency, data immutability, and proven security of financial operations. Yet, it is harder than fiat currencies to predict how the market will behave, or forecast the value of a digital currency. This hinders using cryptocurrencies as accounting and exchange units in daily operations.

A stablecoin is a cryptocurrency pegged to a basket of fiat currencies or a single currency (eg, USD or EUR); commodities like gold or silver; stocks; or other cryptocurrencies. Stablecoins include mechanisms that maintain a low price deviation from their target price and so are useful to store or exchange value, as their built-in mechanisms remove the volatility.

Some stablecoins lack transparency and liquidity of their reserves, which compromises their price stability. To address these challenges, IOG has teamed up with Emurgo, another of the three founding partners of Cardano, and the Ergo blockchain, which uses UTXO-based accounting like Cardano, to work on a stablecoin contract called Djed. Djed is based on algorithmic design. This means it uses smart contracts to ensure price stabilization, and that the coin will be useful for decentralized finance (DeFi) operations.

How stablecoins work

Different mechanisms contribute to the stability of the coin’s value and help eliminate price variations. These mechanisms are underpinned by the economic principles of supply and demand.

A common mechanism is backing the stablecoin by a reserve of the currency used as the peg. If demand is higher than the supply of sell or buy orders, this supply should be increased to avoid fluctuations in the price. Typically, stablecoin reserves are not stored in cash. Instead, they are kept in interest-bearing financial instruments such as bonds. The returns on these provide revenue for the operator.

As long as the stablecoin is fully backed by reserves in the currency to which it is pegged – and the operator can react quickly to variations in demand – price stability is maintained.

Common risks

Stablecoin reserves are commonly associated with investments. The lack of liquidity of these investments may prevent the operator from reacting quickly to demand. This compromises stability in the short term.

A drawback of fiat-backed stablecoins is that they require trust in the entities keeping the reserves. Lack of the reserves’ transparency or of the ‘full-backing’ claim, combined with inefficient stabilization measures, have already caused Tether stablecoin (USDT) to fall below $0.96, as shown in Figure 1.

Figure 1. Price of the Tether stablecoin (USDT) in the past three years

Issues of transparency do not arise when the backing asset is a cryptocurrency on a public blockchain. Furthermore, the use of smart contracts ensures efficient and reliable execution of stabilization measures due to its automated and secure mechanisms.

Enhanced stabilization mechanisms of Djed algorithmic stablecoin

Djed is a crypto-backed algorithmic stablecoin contract that acts as an autonomous bank. It operates by keeping a reserve of base coins, and minting and burning stablecoins and reserve coins. The contract maintains the peg of stablecoins to a target price by buying and selling stablecoins, using the reserve, and charging fees, which accumulate in the reserve, as shown in Figure 2. The ultimate beneficiaries of this revenue stream are holders of reserve coins, who boost the reserve with funds while assuming the risk of price fluctuation.

Figure 2. How Djed works

The Djed stablecoin is designed as an asset pegged to a fiat currency (USD), along with a governing algorithm. This approach provides a stable means of exchange. But Djed is not limited to being pegged to the dollar. It can work with other currencies, as long as there are oracles providing the contract with the corresponding pricing index.

The first formally verified stablecoin protocol

Djed is the first formally verified stablecoin protocol. The use of formal methods in the programming process has greatly contributed to the design and stability properties of Djed. Using formal techniques, the properties are proven by mathematical theorems:

  • Peg upper and lower bound maintenance: the price will not go above or beyond the set price. In the normal reserve ratio range, purchases and sales are not restricted, and users have no incentive to trade stablecoins outside the peg range in a secondary market.
  • Peg robustness during market crashes: up to a set limit that depends on the reserve ratio, the peg is maintained even when the price of the base coin falls sharply.
  • No insolvency: no bank is involved, so there is no bank contract to go bankrupt.
  • No bank runs: all users are treated fairly and paid accordingly, so there is provably no incentive for users to race to redeem their stablecoins.
  • Monotonically increasing equity per reserve coin: under some conditions, the reserve surplus per reserve coin is guaranteed to increase as users interact with the contract. Under these conditions, reserve coin holders are guaranteed to profit.
  • No reserve draining: under some conditions, it is impossible for a malicious user to execute a sequence of actions that would steal reserves from the bank.
  • Bounded dilution: there is a limit to how many reserve coin holders and their profit can be diluted due to the issuance of more reserve coins.

Djed versions

There are two versions of Djed:

  • Minimal Djed: this version is designed to be as simple, intuitive, and straightforward as possible, without compromising stability.
  • Extended Djed: this more complex version provides some additional stability benefits. The main differences are the use of a continuous pricing model and dynamic fees to further incentivize the maintenance of the reserve ratio at an optimal level.


IOG, Ergo, and Emurgo teams have been working on the implementation of the Djed algorithmic stablecoin contract earlier in 2021 to test different models.

The first implementation of a Djed stablecoin contract was SigmaUSD on Ergo. This was the first algorithmic stablecoin deployed on a UTXO-based ledger in Q1 2021. It had a fee of 1% for buying or selling operations, and an oracle that updated the exchange rate every hour. This initial version was subject to a reserve draining attack by an anonymous user who owned a large number of ERGs (Ergo’s native coin). The attack was ultimately unsuccessful, and it is estimated that the attacker lost $100,000.

To further discourage such attacks, this initial deployment of Minimal Djed was replaced by a version where the fee was set to 2%, the oracle updated every 12 minutes, and every oracle update was allowed to change the price by at most 0.49%, unless the price difference was greater than 50%. This provided stronger resilience against reserve draining attacks.

Djed has also been implemented by the IOG team in Solidity. One version uses the native currency of the Ethereum blockchain as a base coin, and another uses any ERC20-compliant token as a base coin. So far, these implementations have been deployed to testnets for Binance Smart Chain’s testnet, Avalanche’s Fuji, Polygon’s Mumbai, Ethereum’s Kovan, Ethereum’s Rinkeby, and RSK’s testnet.

Djed: Cardano implementation

The Alonzo update to Cardano will enable smart contracts using Plutus. Plutus is powered by Haskell, which guarantees a safe, full-stack programming environment.

Draft implementation of an earlier version of Minimal Djed is available in the Plutus language. In this implementation, stablecoins and reserve coins are native assets uniquely identified by the hash of the monetary policy that controls their minting and burning according to the Djed protocol. This implementation also assumes that oracle data such as the exchange rate is provided as signed data directly to the transactions, instead of being posted on-chain.

There is also an ongoing OpenStar implementation. OpenStar is a framework for private permissioned blockchains developed in Scala. The implementation of Djed using OpenStar follows the idea of off-chain smart contract execution to have a stablecoin on Cardano that does not depend on smart contracts executed on-chain.

To find out more about Djed stablecoin, see the recently published research paper or check out the presentation by Bruno Woltzenlogel Paleo, IOG technical director, at Ergo summit 2021.

We’d like to thank and acknowledge Bruno Woltzenlogel Paleo for his input to this article and support throughout the process of its creation.