Cardano’s development has been conceived as a journey involving five overlapping development themes, each of which is underpinned by a consensus protocol – Ouroboros. As Cardano evolves, the protocol must also change as fresh functionality and utility are brought onto the platform. Upgrades require gradual changes to the network protocol and in this article, we will explain how these protocol changes are implemented and what goes on behind the scenes to make this process smooth and straightforward.

Reducing complexity in protocol changes

In the crypto world, any fundamental change to the blockchain protocol is referred to as a hard fork. In most blockchains, a hard fork is a ‘traumatic’ event that causes a – hopefully short – break in block production. In contrast, Cardano handles hard forks automatically, without stopping block production. This gives a uniquely smooth upgrade process that allows new features to be introduced easily and evolve the platform’s capabilities.

Traditionally, when a hard fork event occurs, the current protocol stops operating. All block producers upgrade to a new version of the software that implements the new block production rules or other changes. Having done this, the chain history is erased and block production is restarted. This means that a hard-forked chain will be different from the previous version, which can raise concerns over the integrity of the blockchain, or even lead to splits in the chain.

With Cardano, we do things differently

The way that Cardano implements protocol changes is completely different from the way other blockchains handle hard forks. Our goal has always been to make these changes as seamless as possible. To enable a smooth transition, Cardano automatically preserves the history of previous blocks. This allows the protocol to be upgraded without radical interference to the chain. The previous state does not vanish. Rather, it is extended to include new capabilities. Instead of splitting into two different chains, Cardano combines the original blocks that comply with the current block production rules with new blocks that comply with the new block production rules.

We have christened the mechanism that does this the hard-fork combinator since it combines protocols without triggering interruptions or forcing a restart to Cardano. The Byron to Shelley transition used this technique for the first time. But the crucial point here is that Byron’s chain history did not disappear. Byron and Shelley chains appear ‘as one’, where the Shelley blocks extend the chain that was produced in the Byron era. Shifting from Byron’s Byzantine Fault Tolerance consensus protocol (OBFT) to Shelley’s Ouroboros Praos did not require block production to be stopped or all the nodes to update simultaneously. Instead, nodes could update independently.

As Cardano and Ouroboros evolve, the hard fork combinator approach ensures that Goguen, Basho, and Voltaire blocks will all be held in a single chain. Features will be added at each stage in successive hard forks. Some new features may not even need a hard fork (where the consensus protocol does not change).

The advent of token locking

Token locking is a feature in the next protocol update that we are now preparing to deploy on mainnet. Internally, we are calling this development stage Allegra (named after Lord Byron’s daughter). Alongside the integration of metadata on the network, this is the next significant upgrade for Goguen.

This represents a relatively small technical change to the consensus protocol, with a slight impact on the actual ledger. However, it is significant since it will prepare the platform for smart contracts and the creation of assets (in addition to ada) that run on Cardano. It also provides an important piece of Voltaire (governance) functionality, supporting a voting mechanism. Underlying this are system changes to ensure that we can continue to develop through future hard forks.

Token locking is a way of recording that a specific token is being used for some purpose. By token, we mean the items that are counted by the blockchain ledger. Until now, there has only been ada, but soon many other custom tokens will be able to use the Cardano platform. Locking, in this case, means ‘reserving’ a certain number of tokens for a specified period of time so they cannot be disposed of to gain a benefit (such as voting, or running a smart contract).

We can compare this with earning dividends from shares. A person who buys shares in a company might be rewarded with a dividend from the company’s profits. Let’s assume that this dividend is paid at the end of each calendar year and requires the shareholder to have held their shares for the entire year. If they were to sell some of their shares at the end of November, they would lose all the dividends for those shares for that year. They have entered a conditional contract with the share provider that gives them something of value (here, a dividend) in return for holding a specific token (here, a share) for a certain period (in this case, a full calendar year).

Enabling complex smart contracts

Token locking is essential to enable complex smart contracts, and to support certain conditions, for example, when making a purchase. Thus, when someone enters into a contractual agreement to sell a house, a promise is made by the vendor that this house won’t be sold to another person – only to the person who actually pays the money. So, the token can represent the house in this case, whereas the ‘promise’ will be the actual token locking. If the house is sold to a third party, the promise in the contract will have been broken and any penalties will be invoked. This precise functionality will become available to contract providers with the introduction of token locking, using ada coins as the tokens. The ada may still be delegated to a stake pool as usual.

Within the Voltaire mechanism – which will be first used with Project Catalyst Fund2 voting – those ada holders who wish to participate in the voting process will need to ‘lock’ some ada. This will represent their voting rights, according to the amount of ada that they lock. It will prove that individuals have a certain number of votes, and eliminate the possibility of any votes being counted more than once. An individual cannot allocate more votes than they hold, or vote on contradictory ideas, or duplicate the votes.

How is this implemented?

The introduction of token locking will happen behind the scenes. It will not affect the experience of ada holders because Daedalus and Yoroi wallets will automatically be updated without requiring any action from ada holders.

However, to implement the updated version of Ouroboros that will support token locking, all the nodes that run the network will have to ‘agree’ on it (that is, reach consensus). To achieve this, stake pool operators and exchanges that are running nodes will simply have to download the new version of the code and check its operation. IOHK’s development teams will support stake pool operators and monitor the network throughout this process to ensure that the transition goes smoothly.

Once token locking is running on the mainnet Cardano ledger, subsequent hard forks will introduce multi-asset and other smart contract capabilities. These will also be able to use token locking, opening up many new possibilities for Cardano users. In time, this will also lay the groundwork for creating non-fungible (unique) tokens on the Cardano blockchain.

IOHK’s innovative hard fork combinator has given Cardano a secure, smooth path to regular protocol updates – each bringing fresh value and utility to the network while minimizing disruption and risk. We’re in the final stages of quality testing and will start the testnet deployment process this month, with an expectation of moving to the mainnet around the middle of December. During 2021, there will be more upgrades using the combinator – multi-asset support is coming up – as the Cardano platform continues to fulfill its potential. Stay tuned for an exciting year.

Full decentralization lies at the heart of Cardano’s mission. While it is not the only goal that we're focused on, in many ways, it is a goal that will enable and accelerate almost every other. It is integral to where we want to go as a project.

It is also where the philosophical and technical grounding of the entire Cardano project meets its community, in very real and tangible ways. This is why we have done a lot of thinking on how to achieve decentralization effectively, safely, and with the health of the ecosystem front of mind.

Defining decentralization

Let’s start by explaining what we mean by decentralization. This is a word that is fraught with challenge, with several competing meanings prevalent in the blockchain community.

For us, decentralization is both a destination and a journey. Shelley represents the first steps toward a fully decentralized state; from the static, federated approach of Byron to a fully democratic environment where the community not only runs the network, but is empowered and encouraged to take decisions through an on-chain framework of governance and voting.

True decentralization lies at the confluence of three essential components, working together in unison.

• Networking - where geographically distributed agents are linked together to provide a secure and robust blockchain platform.
• Block production - where the work of building and maintaining the blockchain is distributed across the network to a collection of cooperating stake pools.
• Governance - where decisions about the blockchain protocol and the evolution of Cardano are taken collectively by the community of Cardano stakeholders.

Only when all these factors exist within a single environment can true decentralization be said to have been achieved successfully.

Key parameters that affect decentralization

Let's talk about d, maybe.

The d-parameter performs a pivotal role in controlling the decentralization of block production. Decentralization is a spectrum, of course, rather than an absolute. In simple terms, d controls ‘how’ decentralized the network is. For example, at one extreme, d=1 means that block production is fully centralized. In this state, IOG’s core nodes produce all the blocks. This was how Byron operated,

Conversely, once d=0, and decentralized governance is in place and on chain, ‘full’ decentralization will have been achieved. At this point, stake pool operators produce all the blocks (block production is 100% decentralized), the community makes all the decisions on future direction and development (governance is decentralized), and a healthy ecosystem of geographically distributed stake pools are connected into a coherent and effective network (the network is decentralized). We will have reached our decentralization goal.

The journey that d will take from 1 to 0 is a nuanced one that requires a careful balance between the action of the protocol and the reaction of the network and its community. Rather than declining instantly, d will go through a period of ‘constant decay’ where it is gradually decremented until it reaches 0. At this point Cardano will be fully decentralized. This gradual process will allow us to collect performance data and to monitor the state of the network as it progresses towards this all-important point. A parameter-driven approach will help provide the community with transparency and a level of predictability. Meanwhile, we’ll be monitoring the results carefully; there will always be socio-economic and market factors to consider once ‘in the wild’.

How will the d parameter change over time

The evolution from 1 to 0 is relatively simple:

When d=1, all blocks are produced by IOG core nodes, running in Ouroboros Byzantine Fault Tolerance (OBFT) mode. No blocks are produced by stake pool operators (running in Ouroboros Praos mode). All rewards go to treasury.

When d=0, the reverse becomes true: every block will be produced by stake pools (running in Praos mode), and none by the IOG core nodes. All rewards go to stake pools, once the fixed treasury rate is taken.

In between these extremes, a fraction of the blocks will be produced by the core nodes, and a fraction by the stake pools. The precise amounts are determined by d. So when d reaches 0.7, for example, 70% of the blocks will be produced by the core nodes and 30% will be produced by stake pools. When d subsequently reaches 0.2, 20% of the blocks will be produced by the core nodes, and 80% by the stake pools.

It is important to note that regardless of the percentage of blocks that are produced by the stake pools, however, once d < 1, all the rewards will go to stake pools in line with the stake that they hold (after the fixed treasury percentage is taken), and none to the core nodes. This means that IOG has absolutely no incentive to keep the d parameter high. In fact, when d reaches zero, IOG will be able to save the costs of running the core nodes, which are not insubstantial.

Like many other ada holders, IO Global is currently running a number of stake pools on the mainnet. As the creator of the Cardano platform, IO Global naturally has a significant stake in its success from fiscal, fiduciary, and security aspects, and this success will be built on a large number of effective and decentralized pools. As a commercial entity, IO needs to generate revenue from its stake, while recognizing the part it needs to play within an ecosystem of stake pools, helping to grow and maintain the health of the network as we move towards full decentralization. In the medium term, we will follow a private/public/community delegation approach, similar to that we adopted on the ITN, spreading our stake across both IOG and community pools. In the short term, however, we are running IOG pools on the mainnet, establishing a number of our own pools that can take some of the load from our core nodes. Using our stake and technical expertise to secure and stabilise the network is an important element at first, but one that will become less important as the d parameter decreases. The road to decentralization will offer many opportunities for pools of all sizes to establish themselves and thrive along the way.

The key milestones of the d journey

d<1.0 (Move away from centralization)

The first milestone happened on August 13 at the boundary of epoch 210 and 211 when the d parameter first dropped below 1.0. At this point, IOG's core nodes started to share the block production of blocks with community stake pools. This marks the beginning of the road to full decentralization.

d=0.8 (Stake pools produce 20% of blocks)

At 0.8, more pools (double the number compared to d=0.9) will get the opportunity to create blocks and establish themselves. At this level, pools won’t suffer in the rankings as long as they create one of the allocated blocks and get rewards. This way, we believe we can start growing the block-minting proportion of the network, at low network risk.

d<0.8 (Stake pool performance taken into account)

The next major milestone will happen when d drops below 0.8. Below that level, each pool's performance will be taken into account when determining the rewards that it receives. Above that level, however, the pool’s performance is ignored. The reason for this is to avoid unfairness to pools when they are only expected to produce a few blocks.

d<0.5 (Stake Pools Produce the Majority of Blocks)

When d drops below 0.5, stake pools will produce the majority of blocks. The network will have reached a tipping point, where decentralization is inevitable.

Before taking this dramatic step, we will ensure that two critical features are in place: peer-to-peer (P2P) pool discovery and protocol changes to enable community voting. These will enable us to make the final push to full and true decentralization The recently announced Project Catalyst program was the first step in this, concurrent journey to full on-chain governance.

d=0 (Achieve Full Decentralization)

As soon as the parameter reaches 0, the IOG core nodes will be permanently switched off.

IOG will continue to run its own stake pools that will produce blocks in line with the stake they attract, just like any other pools. But these will no longer have any special role in maintaining the Cardano network. It will also, of course, delegate a substantial amount of its stake to community pools. Simultaneously, the voting mechanism will be enabled, and it will no longer be possible to increase d and ‘re-centralize’ Cardano.

At this point in time, we will have irrevocably entered a fully decentralized Cardano network. Network + block production + on-chain governance = decentralization.

Rate of constant decay

The progressive decrement of d is known as constant decay. The gradual decrease will give us the chance to monitor the effects of each decrement on the network and to make adjustments where necessary. As the parameter decreases, more stake pools will also be able to make blocks, since the number of blocks that are made by the pools will increase, and less stake will then be required for each block that is made.

The key factors driving this decrease will be:

• The resilience and reliability of the network as a whole.
• The number of effective block-producing pools.
• The amount of the total stake that has been delegated.

Here’s our current thinking on what implementation might look like:

We will then likely pause before dropping the parameter below 0.5 to ensure that the two key conditions described above are met:

• The implementation of the new Peer-to-Peer pool discovery mechanism has been released and is successfully in use;
• We have successfully transitioned the first hard fork in the Shelley era, which will introduce the basis for community voting on protocol parameters, and other important protocol changes

We will resume the countdown to d=0 at a similar rate, pausing again if necessary before finally transitioning to d=0 in March 2021.

Other factors that affect decentralization: Saturation threshold

A second parameter – k – is used to drive growth in the number of pools by encouraging delegators to spread their stake. By setting a cap on the amount of stake that earns rewards (the saturation threshold), new delegators are directed towards pools that have less stake. In ideal conditions, the network will stabilise towards the specific number of pools that have been targeted. In practice, we saw from the ITN that many more pools than this number were supported by the setting that we chose.

The k parameter was set to 150 at the Shelley hard fork. This setting was chosen to balance the need to support a significant number of stake pools from the start of the Shelley era against the possibility that only a small number of effective pools would be set up by the community. In due course, it will be increased to reflect the substantial number of pools that have emerged in the Cardano ecosystem since the hard fork. This will spread stake, and so block production, among more pools. The overall goal in choosing the setting of the parameter will be to maximise the number of sustainable pools that the network can support, so creating a balanced ecosystem. In order to achieve this, a careful balance is required between opening up the opportunity to run a block-creating pool to as many pools as want to run the system, against the raw economics of running a pool (from bare metal servers, to cloud services, to people’s time), taking into account the rewards that can be earned from the actively delegated stake. Changing this parameter will therefore be done with a degree of caution and balance so that we ensure the long term success of a fully decentralized Cardano network. We’re now looking carefully at early pool data and doing some further modelling before making the next move.

d and pool rewards

Two questions remain: What is the effect of d on the rewards that a pool can earn, and can this parameter ever be increased?

Regarding rewards, as long as a pool produces at least one block, the value of the parameter has absolutely no effect on the rewards that a pool will earn – only on the number of blocks that are distributed to the pools. So if a pool has exactly 1% of the stake, it will earn precisely 1% of the total rewards, provided that it maintains its expected performance.

Finally, while d could in theory be increased, there would need to be a truly compelling reason to do so (a major protocol issue, or fundamental network security, for example.) We would never envision actually doing this in practice. Why? Simply because we want to smoothly and gradually reduce the parameter to 0 in order to achieve our objective of true decentralization. We’ll be making this journey carefully but with determination step by step. If each step is taken thoughtfully and with confidence, you should not need to retrace them? As d becomes 0, the centralized IO servers will be finally switched off, and Cardano will become a model of decentralized blockchain that others aspire to be.

Conclusion

The decline of centralized entities coincides with Cardano's rise towards full and true decentralization. In the near future, the Cardano blockchain will be solely supported and operated by a strong community of stake pools whose best interest is the health and further development of the network.

This journey, which began with Shelley and the implementation of the d parameter, will take Cardano through a path of evolutionary stages in which the network will become progressively more and more decentralized, as d decays. The journey will only end when the blockchain enters a state of irrevocable decentralization, a moment in time that will see networking, block production, and governance operating in harmony within a single environment.

Today, we’re kicking off the ‘Friends & Family’ testnet, which will allow us to establish a robust network to test and iterate, before we roll it out to the wider community. We’ve gathered a small number of around 20 ‘pioneers’ to help us with this important initial work. By the time you probably read this, they’ll be briefed and we’ll have things underway.

In my last blog, I outlined how the Shelley experience will roll out within clearly defined phases. These first three phases will involve exploring and testing the new Shelley capabilities via a series of testnets. I thought it might be useful to offer a glimpse ahead to provide some additional context.

The rollout of the testnets will happen very much in parallel with our continued progress towards mainnet. So alongside the work on the Haskell Shelley testnet, the mainnet will be systematically upgraded to support the Shelley era protocol, that will enable staking, delegation and metadata.

Similarly, IOHK’s block-producing and public-facing relay nodes on the mainnet will be upgraded so that they are ready for Shelley, and the Blockchain Explorer, Daedalus Wallet, Wallet CLI and other user-facing software will be polished so that it can be used for mainnet.

Users will soon be able to go to the official Cardano websites or other providers such as Yoroi, to download a new wallet – currently in development – that will work with both Byron and Shelley era blocks. The Shelley-era Daedalus wallet will contain all the logic for staking and delegation that has been tested on the Incentivized Testnet, plus new features that are specific to the full Shelley protocol. Stakepool operators, exchanges and others will also be able to download Shelley-compatible nodes and to adapt their own software to support the new Shelley client API. However, during this period, the mainnet will still be running in Byron reboot mode with federated consensus governed by the OBFT (Ouroboros Byzantine Fault Tolerance) algorithm. Think of it as a time when forward compatibility is being integrated but not yet ‘switched on’.

The move to Shelley will be accomplished using the new hard fork combinator that has been developed by IOHK.The hard fork combinator allows a node to transition from one blockchain protocol to another. The Cardano node software that is running on the mainnet will gradually evolve so that it is able to deal with both Byron era and Shelley era blocks, and will be modified to include the hard fork combinator. When the time comes to move the mainnet from the Byron era to the Shelley era, IOHK will trigger a hard fork.

‘Switching on’ Shelley

This will activate the hard fork combinator within the nodes, and the nodes will then change from only producing Byron era blocks to only producing Shelley era blocks. After the hard fork, no new Byron era blocks will be recorded on the blockchain, and the nodes will be able to support distributed block production, staking and delegation. They will have seamlessly switched from the OBFT to the Ouroboros Praos consensus mechanism. We will have entered the Shelley era on the mainnet.

Distributed stake pools and Decentralization of Block Production

Central to Shelley is the idea of decentralization. IOHK believes that companies, systems, and platforms run by a single individual or central authority are more vulnerable and less fair. This is why it is crucial that we move block production to our supporters rather than keeping the power contained within our organizations.

The Cardano blockchain currently operates on a federated basis. Effectively, nodes ‘controlled’ by IOHK and EMURGO are responsible for block production, while Daedalus wallet users act as the nodes of the network. Shelley will mark the ‘beginning of the end’ of that era, as we move from Byron’s static federated system to an active, decentralized system.

At the moment, core nodes and relays are owned and operated by IOHK. The network propagates through relays into each individual wallet. Once the system decentralizes, nodes will be run by stake pool operators and networked with individual wallets. Once control of the system is transferred over, the community will be fully running the Cardano ecosystem.

Federated Block Production (Byron)

Following the hard fork, IOHK’s existing core nodes will initially produce all of the Shelley blocks, as in the Byron era. However, this will change over time, under the control of the built-in d (decentralization) parameter. This parameter can be considered as a control valve that allows increasing amounts of decentralization.

In the decentralization phase, the federated system will still produce a (steadily decreasing) portion of the blocks. As this happens, stake pools will begin registering, operating, and producing blocks and will start to earn rewards in proportion to the stake that is delegated to them. As time passes, more blocks will be made by stake pools and fewer will be made by the core consensus nodes. The balance between the two will be controlled by the d parameter.

Distributed Block Production (Shelley and Beyond)

We will use metrics like the amount of ada that has been staked to determine how quickly to change the d parameter and so to decentralize the network. Once the network has fully decentralized, the stake pools will completely take over block production. At that point, we will then be able to shut down the core consensus nodes and disable the d parameter. This is the first step towards the full decentralization of Cardano. We will return to that in future blog posts, when we discuss some of the exciting developments that the Shelley mainnet will enable.

The road towards Shelley has been long but creating a global financial and social operating system takes time, scientific rigor, and the support of an informed, passionate community. As always, we thank you for your support and encourage you to follow our official channels closely as the Haskell Shelley testnet and subsequent phases roll out.

Following the successful Byron reboot of Cardano, we are beginning our phased transition to the Shelley mainnet. This means moving from a static, federated system to a dynamic, decentralized Cardano blockchain.

The process begins with a series of Haskell Shelley testnets, culminating in the Shelley upgrade hybrid phase.

The Haskell Shelley testnets will be a different experience from the previous Incentivized Testnet (ITN) for both stake pool operators and general users/ada holders. This is because the ITN and the Haskell testnets have been created with different goals in mind.

The ITN was designed to give stake pool operators experience in building their critical infrastructure, while allowing IOHK’s engineers to test the new incentive mechanisms with real ada, delegated by actual ada holders. The Haskell Shelley testnet is about ensuring that the Shelley mainnet is calibrated to be a best-in-class experience from day one. Unlike the ITN, the Haskell Shelley testnet will not involve ‘regular’ ada holders: the testnet will not be incentivized. Each phase is intended to run for a much shorter period – weeks rather than months. We will, of course, be testing out the operation of the wallet, explorer, and so on, but using a faucet distributing test ada that doesn’t offer rewards. Ada holders will be able to try Daedalus and the explorer on the public testnet and provide feedback, but without using real ada.

The Shelley experience will roll out within clearly defined phases. The first three phases will involve exploring and testing the new Shelley capabilities and moving to a situation where we are ready for full Shelley mainnet deployment.

Phase 1: Pioneers and the ‘Friends & Family’ phase

The rollout will begin with an invitation-only ‘friends and family’ testnet. During this phase, IOHK will first spin up and run a Shelley-only test network internally. We will then invite about 20 trusted stake pool operators – we’re calling them ‘pioneers’ – to join this (initially closed) network. These operators will comprise a small group who have demonstrated a high level of technical skill and community contribution during the ITN.

These pioneers will blaze the trail for others to follow as we head to full Shelley deployment on the Cardano mainnet. In this important first phase, we’ll be asking them to perform specific functionality tests to capture their valuable feedback while exploring the capabilities of the Haskell Shelley platform. We expect to invite more pioneers to join us – a few at a time – as we add features and prove the reliability of the testnet.

In this ‘closed alpha’ testing phase, IOHK will focus on tuning system parameters such as the saturation threshold, network resilience, and decentralization. Furthermore, IOHK’s engineers will see the Ouroboros Praos consensus mechanism working outside of simulation. The pioneer phase will give IOHK’s engineers the opportunity to address any issues in a controlled environment, with feedback and support from stake pool operators, before moving to the next phase. The findings will be communicated to the Cardano community and opportunities will be taken to learn about and improve the Shelley system.

This phase will also be all about producing high-quality technical documentation and support. The pioneers (supported by the community as a whole) will help us produce documentation that will make it easy to set up and run stakepools, and give our technical support team an understanding of the issues that our users will face.

Phase 2: Opening up the testnet – the public phase

The community response to the ITN was incredible, and we are blessed with having a wealth of skilled stake pool operators in the community. We’ll keep everyone informed through every step of the process and – as ever – our repos will be fully open. But for purely practical reasons, we’ll be working 1-2-1 with just a small group of around 20 operators at first. But our goal is to open things up as soon as we can, with full public access in the next phase.

This will allow all the stake pool operators who participated in the ITN to redeploy their previously constructed infrastructure, and to tune their stake pool to the new Haskell settings. This testnet will run as closely as possible to mainnet conditions, including mixing Byron and Shelley era blocks.

During each evolution in the transition to Shelley, IOHK is placing an emphasis on community training and collaboration. Decentralization of knowledge is just as important as decentralization of the platform. Pioneer participants in the alpha testnet will provide crucial support in advising the remaining stake pool operators on configuration and use of the Shelley system. And as operators acclimatize, we’ll also be asking them to support and bring new operators on board.

Phase 3: The balance check

The third and final phase prior to mainnet deployment is the balance check. This will bring together the Byron and ITN transaction histories, and prepare the mainnet for the Shelley era. At this point, the ITN rewards and mainnet balances will be consolidated. After this point, it will no longer be possible to earn rewards on the ITN. However, users will be able to check their rewards and confirm them in mainnet wallets. We’ll share full details of what ada holders need to do to reclaim their ITN rewards a little nearer the time. The balance check phase will last for only a couple of weeks before we start moving towards decentralized stake pools and the Shelley era.

How we will select the pioneers

We are selecting the pioneer group based on a number of criteria, devised in collaboration with the team at the Cardano Foundation. Pool operators must have a deep knowledge of running stake pools on the ITN, as well as competency working with Linux, and come from a range of backgrounds and geographical locations. Some will be working with cloud solutions providers to run their pool, others with their own hardware – we’ll have a mix. By selecting pioneers from different geographical regions, we will be able to ensure a global reach, and test out our new network implementation.

Pioneers will be expected to commit a set number of hours per week to supporting the rollout program, give direct feedback and provide advice to the community and mentor others at subsequent phases. Bringing others on board and supporting them along the way will be a crucial part of the role. To be clear, as ever, all our repos will be open so we encourage everyone to get involved. As always, IOHK’s developers value input from every member of the Cardano community. Anyone who wishes to is encouraged to spin up their own nodes. If they are skilled developers they can also recommend enhancements to the Shelley Haskell code base because all the information will be published through GitHub.

We’ll be looking to expand the network rapidly with more pools as soon as this earliest testing phase delivers the results we want.

Ensuring an easier start for everyone

The Haskell Shelley code base has been developed with formal methods and the high assurance Haskell programming language. So while we anticipate that some minor elements will need addressing, we believe that the initial experience should be free of any major issues. This is the approach that we have used for the Byron reboot, with great success, and we will be building on the code base that we have developed there. The approach will deliver even greater benefits for Shelley and beyond, by allowing us to deploy software much more quickly than in the past, with new features subject to rigorous and careful checks even before coding has been completed.

Our goal is to provide a plug-and-play solution to get stake pool operators up and running. This means they should be able to pick up a pre-prepared docker image or AWS instance, for example, and their stake pool will be launched. We will, of course, also provide standalone binaries and source code for those with more experience, or who have specific configuration requirements.

We’re now in the final stages of preparation and things are heating up (you may have recently seen a tweet that the new node has produced its first block). With that successful first step completed, we’ll be sharing dates and more details very soon. We’ll also be publishing further blogs outlining the other key steps and milestones in the process. Keep an eye out for those and meanwhile stay tuned to IOHK’s social channels. We’ll be sure to let you know as we start rolling things out.

We’ve talked a lot about incentives lately. That’s because right now we’re running the Incentivized Testnet: a Shelley testnet that provides an opportunity for stakeholders to delegate their stake or operate a stake pool to earn real ada rewards. Later this month, anybody that had ada in either a Daedalus or Yoroi mainnet wallet during the balance snapshot (taken on November 29) will be able to participate in the Incentivized Testnet, as either a delegator or stake pool operator, or both.

One of our key goals for the Incentivized Testnet is to test – in a real-world setting – the assumptions made in the Ouroboros incentives whitepaper, which uses game theory to calculate the incentives required to ensure consistent, active, and strong participation within a blockchain network.

The foundation of Cardano is mathematics; its central pillar, however, is a philosophy aimed at creating a fairer, more transparent, and more equitable system, decentralized and globally distributed.

Why incentives matter

Successful systems depend upon the adequate supply of incentives. Think of a company. A company must sufficiently incentivize its employees to work. This doesn’t just mean turning up to work – existing within the system – but performing a specific function to the desired standard. The same is true (and, arguably, is more crucial) for decentralized systems. Cardano is a decentralized network of global participants, each of whom must be adequately incentivized to take part and perform their roles, with the understanding that the network’s interests align with their own.

A brief overview of the incentives mechanism

Cardano’s incentives model begins with an assumption of rationality: that each player will act to maximize their own returns. These returns are the system’s incentives, and can take the form of tangible rewards – such as money – or intangible rewards, such as esteem, reputation, status, identity, or fulfilment.

Selfless acts are rare. As individuals, we pursue strategies that reward us, directly or indirectly. A network of participants each acting out of self-interest, however, can lead to chaos. That’s why successful systems codify – in protocols, rules, or laws – when and how much each participant will be rewarded. One of the core principles of game theory is that an ideal system is one where a selfish participant, acting in their own best interests, is also, by design, acting in the best interests of the system.

This is the function of Ouroboros’ incentives mechanism: a set of instructions that specify how and when rewards are paid out, and in what proportions to reward different levels of stake contribution. It allows a distributed network of participants to coordinate and collaborate in a decentralized system and receive rewards in accordance with their self-interest, while still contributing to the long-term health of the network.

Aims of Cardano’s incentive model

Equality and fairness are key to the sustainability of any future system, but can only be assured by the system itself, independent of individual goals or self-interest. Individuals must be free to exercise their ingenuity and maximize their outcomes, as long as doing so does not impede the operation of the network or restrict the possibilities of another (for example, by gaining a disproportionate amount of control). If one participant is the winner every time, other participants are disincentivized and, eventually, disenfranchised. The final implementation of Cardano’s incentives mechanism, as outlined in the incentives whitepaper, incorporates these factors, ensuring that that the biggest doesn’t always win, and that not only the richest get richer.

This is one of the aims of the game theory underpinning the incentives model – to test the thresholds and parameters for exploitation and the alignment of individual and collective interest – and is similarly one of the aims of the Incentivized Testnet. Over time, we will introduce new factors to the rewards calculation and monitor the impact on participant behavior.

Testing the incentive model

The incentives model we’re introducing to the Incentivized Testnet is not the final model. We plan to use this phase to test the incentives model incrementally, verifying our assumptions and exploring whether the network and participants respond in the way we anticipate.

We will not only be testing our game theory, however. We’ll also be testing the technology, ensuring that additional factors for reward calculations are only included once a baseline model is proven to be secure and stable.

In the beginning, various factors will not be included in the rewards calculation. These include factors to increase the number of stake pools and to better rank stake pools according to their desirability. Other factors will be included but in a limited capacity, and their function and calculation will evolve over time. This includes stake pool ranking. At first, the ranking will be based on a stake pool’s performance but, as we progress through the Incentivized Testnet, will transition to be based on desirability (a combination of cost, margin, pledged stake, and performance).

We’ll then gradually introduce additional factors into the rewards calculation, beginning with factors to encourage growth in the number of stake pools and to ensure the system promotes the most desirable stake pools. Each of these is important, and introducing them in a staged approach will allow us to ensure they function as intended and that each has the intended effect on the network.

Incentivized Testnet rewards

The rewards for delegating stake or operating a stake pool on the Incentivized Testnet depend upon the percentage of network participation. An approximate 3.8 million ada will be awarded per epoch. If 50 percent of the network participates, then we estimate the annual return for delegation will be approximately 7 to 8 percent but could, if network participation is lower, be as high as 13-15 percent. These figures are subject to treasury taxes and stake pool fees. A rewards calculator is now available on the Incentivized Testnet website which, in addition to other variables, allows you to calculate approximate rewards relative to different levels of network participation. Here’s a sneak peek:

Approximate delegation rewards calculation at 30% participation

Approximate delegation rewards calculation at 50% participation

Meanwhile, for stake pool operators, the rewards for stake pool operation, assuming a pledged amount of 10,000,000 ada, a 10 dollar daily stake pool operating fee, 50 percent network participation in the Incentivized Testnet, and the operator margin set to 10 percent, the total return rate for stake pool delegation will be approximately 12 to 13 percent. We will be updating the calculator over time to include more sophisticated rewards calculation modelling.

Approximate stake pool operation rewards calculation at 50% participation

More coming soon

This is a testnet, and as such involves an iterative process to reach our desired end: a complete and fully functioning incentives mechanism – as described in the Ouroboros whitepaper – that rewards network participants accurately and fairly in proportion to their contribution, while preventing any single actor from gaining a disproportionate amount of control over the network. We’ll be actively monitoring participant behavior throughout the testnet, to determine when and what additional factors may be included in the rewards calculation.

To learn more about the Incentivized Testnet, visit our website. If you’re interested in running a stake pool, register your interest and explore our testnet website for step-by-step instructions. And, as always, follow us on Twitter or sign up to our email list for the latest progress updates.