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.

In the previous article, we identified the objectives of the reward scheme in Cardano, and we gave general guidelines regarding engaging with the system.

Taking a more high-level view, we will examine from first principles, the general problem of reward sharing in blockchain systems. To recall, the two overarching objectives of any resource-based consensus system is to incentivize the following.

High engagement. Resource-based consensus protocols are more secure the more resources are engaged with protocol maintenance. The problem, of course, is that the underlying resources are useful for a wide variety of other things too (e.g., electricity and computational power in the case of proof of work, or stake for engaging in decentralized apps in the case of proof of stake), so resource holders should be incentivized to commit resources for protocol maintenance.

Low leverage: leverage relates to decentralization. Take a group of 10 people; if there is a leader and the group follows the leader’s wishes all the time, the leader’s leverage is 10 while everyone else’s is zero. If, on the other hand, everyone’s opinion matters the same, everyone’s leverage is 1. These are two extremes, but it should be fairly obvious what types of leverage align better with decentralization. From an economic viewpoint, however, a “benevolent dictatorship” is always more efficient; as a result, decentralization will come at a cost (exactly as democracy does), and hence it has to be also properly incentivized.

Given the above objectives, let us now examine some approaches that have been considered in consensus systems and systematize them in terms of how they address the above objectives. An important first categorization we will introduce is between unimodal and multimodal reward schemes.

Unimodal

In a unimodal scheme, there is only one way to engage in the consensus protocol with your resources. We examine two sub-categories of unimodal schemes.

1. Linear Unimodal

This is the simplest approach and is followed by many systems, notably Bitcoin; the original proof-of-work based Ethereum, as well as Algorand. The idea is simple: if an entity commands x% resources, then the system will attempt to provide x% of the rewards – at least in expectation. This might seem fair—until one observes the serious downsides that come with it.

First, consider that someone has x% of resources and that x% of the rewards in expectation are below their individual cost to operate as a node. Then, they will either not engage (lowering the engagement rate of the system), or, more likely, actively seek others to combine resources and create a node. Even if there are two resource holders with x% of resources each and a viable individual cost c when running as separate nodes, they will fare better by combining resources into a single node of 2x% resources because the resulting cost will be typically less than 2c. This can result in a strong trend to centralize, and lead to high leverage since the combined pool of resources will be (typically) run by one entity.

In practice, a single dictatorially operated node is unlikely to emerge. This is due to various reasons such as friction in coordination between parties, fear of the potential drop in the exchange rate of the system’s underlying token if the centralization trend becomes noticeable, as well as the occasional use of complex protocols to jointly run pools. Even so, it is clear that unimodal linear rewards can hurt decentralization.

One does not need to go much further than looking at Bitcoin and its current, fairly centralized, mining pool lineup. It is worth noting that if stake (rather than hashing power) is used as a resource, the centralization pressure will be less – since the expenditure to operate a node is smaller. But the same problems apply in principle.

An additional disadvantage of the above setting is that the ensuing “off-chain” resource pooling that occurs will be completely opaque from the ledger perspective, and hence more difficult for the community to monitor and react to. In summary, the linear unimodal approach has the advantage of being simple, but is precarious, both in terms of increasing engagement and for keeping leverage low.

2. Quantized Linear Unimodal

This approach is the same as the linear rewards approach, but it quantizes the underlying resource. I.e., if your resources are below a certain threshold, you may be completely unable to participate; you can only participate in fixed quanta. Notably, this approach is taken in ETH2.0, where 32 Ether should be pledged in order to acquire a validator identity. It should be clear that this quantized approach shares the same problems with the linear unimodal approach in terms of participation and leverage. Despite this, it has been considered for two primary reasons. First, using the quantized approach enables one to retrofit traditional BFT-style protocol design elements (e.g. that require counting identities) in a resource-based consensus setting. The resulting system is less elegant than true resource-based consensus but this is unavoidable since traditional BFT-style protocols do not work very well when there are more than a few hundred nodes involved. The second reason, specific to the proof-of-stake setting, is seeking to impose penalties on participants as a means of ensuring compliance with the protocol. Imposing quantized collateral pledges makes penalties for protocol infractions more substantial and painful.

Multimodal

We next turn to multimodal schemes. This broad category includes Cosmos, Tezos, Polkadot & EOS. It also includes Cardano. In a multimodal scheme, a resource holder may take different roles in the protocol; being a fully active node in the consensus protocol is just one of the options. The advantage of a multimodal scheme is that offering multiple ways to engage (with correspondingly different rates of return) within the protocol itself can accommodate a higher engagement, as well as limit off-chain resource pooling. For instance, if the potential rewards received by an individual when they engage with all their resources sit below their operational cost of running a node, they can still choose to engage by a different mode in the protocol. In this way, the tendency to combine resources off-chain is eased and the system – if designed properly – may translate this higher engagement to increased resilience.

We will distinguish between a number of different multimodal schemes.

• Representative bimodal without leverage control. The representative approach is inspired by representative democracy: the system is run by a number of elected operators. The approach is bimodal as it enables parties to (1) advertise themselves as operators in the ledger and/or (2) “vote” for operators with their resources. The set of representative operators has a fixed size and is updated on a rolling basis typically with fixed terms using some election function that selects representatives based on the votes they received. Rewards are distributed evenly between representatives, possibly taking into account performance data and adjusting accordingly. Allowing rewards to flow to voters using a smart contract can incentivize higher engagement in voting since resource holders get paid for voting for good representatives (note that this is not necessarily followed by all schemes in this category). The disadvantage of this approach is the lack of leverage control, beyond, possibly, the existence of a very large upper bound, which suggests that the system may end up with a set of very highly leveraged operators. This is the approach that is broadly followed by Cosmos, EOS, and Polkadot.

A different approach to the representative approach is the delegative approach. In general, this approach is closer to direct democracy as it allows resource holders the option to engage directly with the protocol with the resources they have. However, they are free to also delegate their resources to others as in liquid (or delegative) democracy (where the term delegative is derived from). This results in a community-selected operator configuration that does not have a predetermined number of representatives. As in the representative approach, user engagement is bimodal. Resource holders can advertise themselves as operators and/or delegate their resources to existing operators. The rewards provided are proportional to the amount of delegated resources and delegates can be paid via an on-chain smart contract, perhaps at various different rates. Within the delegative approach we will further distinguish two subcategories.

• Delegative bimodal with pledge-based capped rewards. What typifies this particular delegative approach is that the resource pool’s rewards have a bound that is determined by the amount of pledge that is committed to the pool by its operator. In this way, the total leverage of an operator can be controlled and fixed to a constant. Unfortunately, this leverage control feature has the negative side effect of implicitly imposing the same bound to all, small and large resource holders. So, on the one hand, in a population of small resource holders, engagement will be constrained by the little pledge that operators are able to commit. On the other hand, a few large whale resource holders may end up influencing the consensus protocol in a very significant manner, possibly even beyond its security threshold bound. In terms of leverage control, it should be clear that one size does not fit all! From existing systems, this is the approach that is (in essence) followed by Tezos.

It is worth noting that all the specific approaches we have seen so far come with downsides – either in terms of maximizing engagement, controlling leverage, or both. With this in mind, let us now fit into our systematization, the approach of the reward-sharing scheme that we are using in Cardano.

• Delegative bimodal with capped rewards and incentivized pledging. In this delegative system (introduced in our reward-sharing scheme paper), the rewards that are provided to each pool follow a piecewise function on the pool’s size. The function is initially monotonically increasing and then becomes constant at a certain “cap” level which is a configurable system parameter (in Cardano this is determined by the parameter k). This cap limits the incentives to grow individual resource pools. At the same time, pledging resources to a pool is incentivized with higher pledged pools receiving more rewards. As a result, lowering one’s leverage becomes incentive-driven: resource pools have bounded size and operators have an incentive to pledge all the resources they can afford into the smallest number of pools possible. In particular, whale resource holders are incentivized to keep their leverage low. The benefit of the approach is that high engagement is reinforced, while leverage is kept in control by incentivizing the community to (i) pledge as much as possible, (ii) use all the remaining unpledged resources as part of a crowdsourced filtering mechanism. This translates stake to voting power and supports exactly those operators that materially contribute to the system’s goals the most.

The above systematization puts into perspective the choices that we have made in the design of the reward-sharing scheme used in Cardano vis-a-vis other systems. In summary, what the Cardano reward system achieves is to materially promote with incentives and community stake-based voting the best possible outcome: low leverage and high engagement. And this is accomplished, while still allowing for a very high degree of heterogeneity in terms of input behavior from the stakeholders.

As a final point, it is important to stress that while considerable progress has been made since the introduction of the Bitcoin blockchain, research in reward sharing for collaborative projects is still an extremely active and growing domain. Our team continuously evaluates various aspects of reward-sharing schemes and actively explores the whole design space in a first-principles manner. In this way, we can ensure that any research advances will be disseminated widely for the benefit of the whole community.

I am grateful to Christian Badertscher, Sandro Coretti-Drayton, Matthias Fitzi, and Peter Gaži, for their help in the review of other systems and their placement in the systematization of this article.

The deployment of Shelley on mainnet in July opened up a new world of staking and delegation for Cardano. Since then, we have seen a groundswell of support from the community, with the creation of 1,200+ stake pools. Many have thrived and taken an early vantage position in the community in terms of visibility or controlled stake – or both. Equally, some pools are yet to make their mark. With a sub-optimal k, the high saturation threshold has made it particularly tough going for pools yet to mint their first block.

This is starting to change. On December 6, we’ll raise the k parameter to 500 – it was set at 150 for the Shelley launch. This will encourage delegators to spread their stake, giving more stake pools the opportunity to make blocks and step into the spotlight. It’s an important move, just one of a number of changes in the evolving ecosystem and staking experience we can expect over the months ahead.

This week, we are also announcing that we’ll change our staking approach. Initially, we set up 20 public pools. This was partly due to our desire to monitor and test the network and technical dynamics of running a range of ‘real’ pools. Also, for operational and security reasons, we elected to stake the company’s own ada holdings across these pools, rather than within private pools.

In late December, we shall be retiring all but one of our (IOG) public pools, and moving the majority of our stake to private pools. We shall keep one pool open. This is both a symbolic and practical move – we want to maintain a public presence as a pool operator as well as benefit from the technical and operational experience involved.

Evolving our approach

IOG is a research and development company driven by a vision and missionary zeal that is arguably unmatched in the crypto space. We are committed to Cardano’s long-term adoption and success. We’re also a commercial entity and as such, we have an obligation to be commercially successful. So as much as we are bound together by our mission and purpose, an equally powerful motivation has to be in sustaining the financial success that will enable us to keep delivering on our objectives.

As the creators of Cardano, we have a wide and deep role to play. Alongside our technological investment, we want to invest in other ways to help nurture the ecosystem.

Our new strategy

As Cardano continues the journey to full decentralization, IOG is evolving its delegation approach. Besides moving our holdings to private pools, we will be taking about 15% of our ada holdings and delegating it to the Cardano community. We shall use this ada to support our long-term vision, support Cardano’s growth and reaffirm the values we espouse, while maintaining the financially responsible position required from us as a commercial organization.

Our delegation strategy will be based on two elements: supporting what we are calling purpose pools, and encouraging network security, technological excellence and decentralized innovation through incubator pools.

Purpose pools

Our primary objective here is to delegate to pools that we feel support our wider purpose and mission of economic inclusion – decentralization of sustainable technology, empowerment through education, and opening up economic identity for all.

These purpose pools might include operations hosted in developing countries, where blockchain can make a massive impact, or operations focused on supporting educational objectives. Purpose pools might also include those run on a charitable or philanthropic basis, pools supporting underserved or minority members of the community, pools committed to the use of sustainable energy, and so on.

These are pools that not only create tangible value today, but also aim to deliver societal impact tomorrow. That’s a bold ambition, but it is what drives us already, so we want to use some of our ada holdings to support ecosystem players who share and live by similar values.

Incubator pools

With incubator pools, we’ll focus on supporting smaller stake pools and their operators to maximize the diversity of our pool ecosystem, notably in terms of ownership, geographic location and decentralized block production. Such pools may or may not have an ambition to grow or deliver additional value beyond their network role, but we want to get them to the stage where they can take it forward themselves.

Of course, some pools may fall into both categories. These categories are not mutually exclusive, and, initially, our criteria will be flexible as we develop the program. We do, however, expect a certain level of performance and potential (along with a healthy dose of ambition) from every pool. We shall look closely at each pool’s track record, while community kudos and influence will be important factors to consider. We also reserve the right to make occasional awards outside these core categories in the early days. This program will be driven by clear objectives, but we are open to adapting the approach at this early stage of the ecosystem’s development.

Applying for delegation

We’ll launch our first ‘call for delegation’ on December 10 (we thought Ada Lovelace’s birthday was a suitable day to start), and we’ll keep applications open until the end of the year. Throughout 2021, we’ll run quarterly cohorts, inviting pools to apply for delegation, within a two-week window every quarter. We’ll also talk more about the program on our monthly update next week (December 3) so be sure to tune in for details.

Here's a summary. For both programs, pool operators will need to fill out a survey covering some details, plus other questions depending on which category a pool falls into. To register for a delegation award during our winter cohort (delegation during Feb-April 2021) operators should submit a form providing background information such as their pool’s location, technology set up, objectives etc.

On the incubation side, each quarter we will be looking to delegate to between 50 and 70 pools.

We shall also select up to 10 purpose pools each quarter for the program. We’ll publish full criteria as part of the registration process on December 10, but in short, we will be looking to support pools with a mission of economic and social inclusion, and geographical diversity. We recognize that pools located in parts of the world that would most benefit from blockchain also have some of the biggest barriers.

Initial three-month delegation

Each pool selected will receive a delegation for an initial three months – pools will be rotated every quarter. IOG will delegate enough ada to ensure that each of these pools produces at least one block every epoch. At k= 500, we anticipate this amount to be between 3 million and 5 million ada per pool. All pools selected will receive an equal delegation amount.

We’ll review all applications in early/mid January, with a view to start delegating by the end of that month. We’ll publish a list of all chosen pools for both programs for full transparency among the community, which may also help people with their own delegation choices. Initial delegation awards will stay in place till the end of March.

It is still early days for Cardano. Together, we’re building a decentralized ecosystem that will prove its value over decades, so it cannot be fairly judged over months. Yet we’re already seeing incredible momentum in a community that is passionate, committed, and skilled. We hope this new strategy will help identify and encourage some of those pools and ‘pioneers’ – a word we may have overused in 2020 but one we feel remains valid – and help accelerate our growth into 2021 and set us up for many successful years ahead.

Stake pool operations lie at the heart of Cardano decentralization, enabling servers to reach a consensus agreement across the network. Our groundbreaking Ouroboros proof-of-stake consensus protocol allows pool operators to reach agreement on the validity of transactions and sign a block, which is then immutably recorded on the Cardano blockchain.

On the Shelley path to decentralization, as more stake pools are created, the more the Cardano network grows. Operators form their pools, attract delegation, stake ada, earn rewards and take a small cut to cover their running costs before distributing the rest between the pool participants.

Node decentralization is a key element. However, to keep track of stake pool information and simplify the choice of a pool for delegators, it is crucial to ensure that information about each stake pool is relevant and valid. And, as far as is possible, that the influence of bad actors, such as potential attackers, spoof pools, and trolls, on the system is minimized.

Welcome to Smash

To address these needs, we have developed Smash – the server that supports operators and ada owners by validating information about stake pools and storing it as metadata.

Each stake pool is registered on the blockchain along with the information required to calculate rewards. However, stake pools also include metadata that helps ada owners to make a rational choice when delegating their stake. This metadata includes owner details, pool name, pool ticker, homepage, and a short description, which are not stored on the blockchain, and thus it is important to provide visibility and access to this information.

As well as ensuring that registered stake pools are valid, Smash metadata server helps to avoid duplicated ticker names or trademarks, and ensure that they do not feature content that Cardano users are likely to find offensive. Given that scams, trolls, and abusive behavior are an unfortunate part of life online, we had to find a way of filtering potentially problematic actors out of the playing field.

What is Smash?

Smash is a stake pool metadata aggregation server that was conceived to improve Cardano users’ access to verified stake pool information and make it easier to use the system. A Smash server can aggregate stake pool metadata, fetch it, and store it.

The first generation of Smash has been deployed by IOHK and provides information about delegation in the Daedalus wallet. Previously, this off-chain data was fetched by Daedalus from each stake pool separately, which required a lot of network connections and affected performance. All of this data can now be served from one server, hosted and fetched, initially by our team.

Although the Smash server is currently run by IOHK, it is important to note that the server code is open source and can be deployed by anyone. So we hope that in the future, the Smash approach will be adopted by the community for decentralized metadata. Daedalus will allow users to configure any server of their choice and browse custom stake pool lists – for example, charity pools, bare metal pools, or pools from a certain region for ada holders who would prefer to support stake pool businesses with a particular focus.

How does it work?

Smash is an evolving system. Currently, as its operator, we are responsible for the maintenance and metadata curation on the IOHK Smash server. Badly behaved stake pools can be delisted from display in Daedalus. Factors taken into account for such decisions include illegal or malicious metadata content, impersonation, the use of ticker names that were previously registered on the Incentivized Testnet (when this is not the same stake pool/operator), intellectual property rights violations, or stake pools that are no longer active.

While its most immediate impact can be seen in Daedalus, Smash is a resource to support the community. So if you identify a stake pool ticker that you feel might be causing harm and transgresses the guidelines, we encourage you to review the guidelines we have recently published outlining the reasons for a stake pool delisting and a step-by-step explanation of the delisting process. Get in touch if you believe there is a case to be made for removal.

It is important to ensure that there is a reason for a stake pool to be delisted and that if possible, there is a reasonable level of community consent. Thus, any request should include the rationale and any proof of violations. All requests are reviewed by the Smash operator. It usually takes seven days for a request to be inspected and processed, and we always respond by clarifying the motivation for any decision. Cardano is a decentralized ecosystem and aims not to limit any stake pool operation activity unduly or unfairly. We reserve the right to make the final decision regarding the Smash server we manage, however we aim to provide the community with as much visibility and trust as possible. For more details, please email smash@iohk.io or contact directly @benohanlon in Telegram.

As a project, decentralization remains arguably our most important and fundamental goal for Cardano. Protocols and parameters provide the foundations for any blockchain. Last week, we outlined some of the planned changes around Cardano parameters and how these will impact the staking ecosystem and thus accelerate our decentralization mission.

Yet the community itself – how it sees itself, how it behaves, and how it sets common standards – is a key factor in the pace of this success. Cardano has been very carefully engineered to provide “by design” all the necessary properties for a blockchain system to operate successfully. However, Cardano is also a social construct, and as such, observance, interpretation, and social norms play a crucial role in shaping its resilience and longevity.

So in anticipation of the k-parameter adjustment on December 6th, I would like to give a broader perspective on staking, highlighting some of the innovative features of the rewards sharing scheme used in Cardano.

Principles & practical intent

As well as outlining some of the key principles, this piece has a clear practical intent; to provide guidance and some recommendations to stakeholders so that they engage meaningfully with the mechanism, and support the project’s longer-term strategic goals through their actions.

Consensus based on a resource that is dispersed somehow across a population of users – as opposed to identity-based participation – has been the hallmark of the blockchain space since the launch of the Bitcoin blockchain. In this domain, proof-of-stake systems are distinguished in the sense that they use a virtual resource, stake, which is recorded in the blockchain itself.

Pooling resources for participation is something that is inevitable; some level of pooling is typically beneficial in the economic sense and hence resource holders will find a way to make it happen. Given this inevitability, the question arises: how does a system prevent a dictatorship or an oligarchy from emerging?

The objectives of the reward sharing scheme

Contrary to other blockchain systems, Cardano uses a reward sharing scheme that (1) facilitates staking with minimum friction as well as (2) it incentivizes pooling resources in a way that system-wide decentralization emerges naturally from the rational engagement of the resource holders.

The mechanism has the following two broad objectives:

1. Engage all stakeholders - This is important since the more stakeholders are engaged in the system, the more secure the distributed ledger will be. This also means that the system should have no barriers for participation, nor should impose friction by requiring off-chain coordination between stakeholders to engage with the mechanism.
2. Keep the leverage of individual stakeholders low -. Pooling resources leads to increased leverage for some stakeholders. Pool operators exert an influence in the system proportional to the resources controlled by their pool, not to their own resources. Without pooling, all resource holders have leverage of exactly 1; contrast this e.g., to a pool operator, owning, say 100K ada, who controls a pool of total delegated stake of 200M ada; that operator has leverage of 2,000. The higher the leverage of the system, the worse its security (to see this, consider that with leverage above 50, launching a 51% attack requires a mere 1% of the total resources!).

It should also be stressed that a disproportionately large pool size is not the only reason for increased leverage; stakeholders creating multiple pools, either openly or covertly (what is known as a Sybil attack) can also lead to increased leverage. The lower the leverage of a blockchain system, the higher its degree of decentralization.

Putting this into practice

So how does the reward sharing scheme used in Cardano meet the above objectives? Staking via our scheme facilitates two different paths: pledging and delegating. Pledging applies to stake pool operators; pledged stake is committed to a stake pool and is supposed to stay put for as long as the pool is operating. Think of pledge as a ‘commitment’ to the network – ‘locking up’ a certain amount of stake in order to help safeguard and secure the protocol. Delegating on the other hand, is for those who do not wish to be involved as operators. Instead, they are invited to assess the offerings the stake pool operators provide, and delegate their stake to one or more pools that, in their opinion, best serve their interests and the interest of the community at large. Given that delegation does not require locking up funds, there is no reason to abstain from staking in Cardano; all stakeholders can and are encouraged to engage in staking.

Central to the mechanism’s behavior are two parameters: k and a0. The k-parameter caps the rewards of pools to 1/k of the total available. The a0 parameter creates a benefit for pledging more stake into a single pool; adding X amount of pledge to a pool increases its rewards additively by up to a0*X. This is not to the detriment of other pools; any rewards left unclaimed due to insufficient pledging will be returned to the Cardano’s reserves and allocated in the future.

Beyond deciding on an amount to pledge, creating a stake pool requires that operators declare their profit margin and operational costs. When the pool rewards are allocated at the end of each epoch, the operational costs are withheld first, ensuring that stake pools remain viable. Subsequently, operator profit is calculated, and all pool delegators are rewarded in ada proportional to their stake afterwards.

Paired with the assessment of stake pools performed by the delegates, this mechanism provides the right set of constraints for the system to converge to a configuration of k equal size pools with the maximum amount of pledge possible. The equilibrium point has the property that delegator rewards are equalized (so it doesn’t matter what pool they delegate to!), while stake pool operators are rewarded appropriately for their performance, their cost efficiency, and their general contributions to the ecosystem.

For the above to happen, it is necessary to engage with the mechanism in a meaningful and rational manner. To assist stakeholders in understanding the mechanism, here are some points of advice.

Guidance for delegators

1. Know your pool(s) - Investigate the pools’ available data and information. What is the operators’ web-presence? What kind of information do they provide about their operation? Are they descriptive about their costs? Are the costs reasonably based on geographic location and other aspects of their operation? Do they update their costs regularly to account for the fluctuation of ada? Do they include the costs for their personal time? Remember that maintaining a high-performance pool requires commitment and effort, so those committed operators deserve compensation.

2. Think bigger - Consider your choice holistically, not based on just a single dimension. Consider the longer term value your choices bring to the network. Think of your delegation as a ‘vote of confidence’, or a way to show your support to a pool's mission or goals. Opt for professionalism and demonstrated long-term commitment to the system’s goals. Recognize community members who have been helping to lay down the foundations for the ecosystem, either with their community presence or by helping to build things. The long-term wellbeing of the ecosystem is crucially affected by your delegation choice. A more decentralized network is a more resilient and long-lived network.
3. Be wary of ‘pool splitters’ - Pool operators that run multiple pools with small pledge hurt delegators and smaller operators. They hurt their delegators because they could have provided a higher amount of rewards by concentrating their pledge into a single pool; by not doing that, there are rewards that remain unclaimed. They hurt smaller and new operators, because they are forcing them to remain without delegates and hence making their operation unviable – without delegates a pool may be forced to close. So avoid pool operators that run multiple pools with pledge below saturation level. Note there are legitimate reasons for large stakeholders to accept delegators and run a public pool (e.g., they are delegating some of their stake to other pools to support the community); consult any public statements such operators make about their delegation strategy and their leverage. It is ok to delegate to them, assuming they keep their leverage low and they support the community.
4. Be wary of highly leveraged operators - Be mindful of the stake pool operators’ leverage (see below for more details on how to calculate leverage). A higher pledge is correlated to less leverage when comparing pools of the same size; a high leverage is indicative of a stake pool operator with very little “skin in the game.” Stake pool operators may prove to have skin in the game in other ways than pledging stake of course; e.g., they can be very professional and contribute to the community in different ways. You should be the judge of this: high leverage in itself is not a reason to avoid delegating to a particular pool, but it is a strong indication that you should proceed with caution and carefully evaluate the people behind the operation.
5. Shop around - Do take into account the information provided from your wallet software (or from recognized community resources such as adapools or pooltool) in terms of the pool’s ranking and its performance factor. Remember though, while the ranking is important, it should not be the sole factor behind your delegation choice. Think holistically – you may want to consider pools fulfilling a mission you agree with, or trying to add value to the wider community through podcasts or social activity, even if they do not offer the highest possible returns.
6. Be involved - A pool with no performance data on display may have attractive characteristics; it could be providing better rewards in the best case scenario, but also high risk as a delegation choice since its performance may turn out to be suboptimal. Delegate according to your ‘risk profile’, and the frequency you are willing to re-delegate your stake. Do check the pool’s performance and updates regularly to ensure that your choice and assessment remains the best possible.

Guidance for pool operators

1. Be transparent - Choose your pool’s operational cost as accurately as possible. Do include the personal effort (priced at a reasonable rate) that you and your partners put into the pool operation! You are a pillar of Cardano and so you have every right to be compensated by the community. Be upfront about your costs and include them in your pool’s website. Educate your prospective delegates about where the pool costs are going. Always remember that it is important to charge for the time you invest in maintaining your pool. In the short term, you may be prepared to invest your time and energy ‘for free’ (or after hosting costs, at an effective loss) but remember that this is not a sustainable model for the network over the medium and longer term.

2. Don’t split your pool - With the coming changes in k (commencing with the move to k=500 on 6th December), we are already seeing pool operators splitting their pools in order to retain delegators without becoming saturated. Do not engage in pool splitting unless you can saturate a pool completely with your stake. If you are a whale (relative stake > 1/k) you can create multiple pools – but you should keep your leverage as close to 1 as possible or less. Pool splitting that increases your leverage hurts the delegators’ rewards, and more importantly, it hurts the decentralization of the Cardano ecosystem, which is detrimental to everyone. If you run and control multiple pools under different tickers, make a public statement about it. Explain the steps you take to control your leverage. Creating multiple pools while trying to conceal the fact that you control them is akin to a Sybil attack against Cardano. This behavior should be condemned by the community. You can calculate and publicize your leverage using the following formula:

   

Exchanges are a special kind of whale stakeholder, since they collectively manage other people’s stake. One strategy for an exchange is to avoid leverage altogether and delegate the stake they control to community pools. If an exchange becomes a pool operator, they can maintain their leverage below 1 by using a mixed pledging and delegation strategy.

3. Set your profit margin wisely - Select the margin to make your pool competitive. Remember that if everyone delegates their stake and is rational, you only have to beat the (k+1)-th pool in the rankings offered by the Daedalus wallet. If your pool offers other advantages that can attract delegation (e.g., you are contributing to a charitable cause you feel others may wish to support), or you have acquired exceptional equipment that promises notable uptime/performance, make sure you promote this widely. When you offer such benefits, you should consider setting a higher profit margin.

4. Keep your pool data updated - Regularly update the cost and margin to accommodate fluctuations in ada price. Give assurances to your delegators and update them about the stake pool operational details. In case of mishaps and downtimes, be upfront and inform your delegators via your website and/or other communication channels you maintain with them.
5. Pledge as much as you are able to - Increase the amount of pledge as much as you comfortably can and not more. Beyond using your own stake, you can also partner with other stakeholders to increase the pledge of your pool. A high pledge signals long-term commitment and reduced leverage, and it unlocks additional rewards every epoch as dictated by the a0 term in the rewards sharing scheme calculation. As a result, it does make your pool more desirable to prospective delegators. On the other hand, remember that pledge is not the only factor that makes a pool attractive. Spend time on your web and social media presence and be sure to advertise all the ways that you contribute to the Cardano ecosystem.

If you are a Cardano stakeholder, we hope that you find the above advice informative and helpful in your efforts to engage in staking. As in many other respects, Cardano brings a novel and heavily researched mechanism to its blockchain design. The rewards scheme is mathematically proven to offer an equilibrium that meets the set of objectives set out in the beginning of this document. Ultimately though, the math is not enough; it is only the people that can make it happen.

Cardano’s future is in the hands of the community.

The opinions expressed in the blogpost are for educational purposes only and are not intended to provide any form of financial advice.