## **INTRODUCTION**

Welcome to the central hub for Cardano documentation. Here, you'll find content that describes and supports the features on both the Cardano mainnet and testnet environments.

This includes basic explainers for newcomers to Cardano, explanations of the core features, details about Cardano's design and evolution, insights into how the Cardano network operates, and platform architecture. You can also access developer resources that explain the core concepts and provide links to developer documentation for more technical tutorials.

If you are interested in building tools on Cardano, integrating with Cardano, and connecting with the wider developer community, please visit the **[Cardano Developer Portal](https://developers.cardano.org/home/)**.

INTRODUCTION

## **CARDANO EXPLAINED**

Cardano is a decentralized third-generation proof-of-stake blockchain platform and home to the ada cryptocurrency. It is the first blockchain platform to evolve out of a scientific philosophy and a research-first driven approach.

The Cardano platform has been designed from the ground up and verified by an industry-leading combination of top engineers and academic experts in the fields of blockchain and cryptography. It has a strong focus on sustainability, scalability, and transparency. It is a fully open source project that aims to deliver an inclusive, fair, and resilient infrastructure for financial and social applications on a global scale. One of its primary goals is to bring reliable, secure financial services to those people who do not currently have access.

Cardano has been designed with security as one of its founding principles. It is written in Haskell, a functional programming language. In a functional language like Haskell, building your system using pure functions is encouraged, which leads to a design where components are conveniently testable in isolation. Furthermore, advanced features of Haskell enable employing a whole range of powerful methods for ensuring the correctness of the code, such as basing the implementation on formal and executable specifications, extensive property-based testing, and running tests in simulation.

Cardano's smart contract platform seeks to deliver more advanced features than any protocol previously developed and will serve as a stable and secure platform for the development of enterprise-level DApps. Cardano's democratic governance system, being implemented based on **[CIP-1694](https://cips.cardano.org/cip/CIP-1694)** on-chain governance mechanisms, will enable the project to evolve over time and sustainably fund itself through a visionary treasury system.

You can read more about Cardano on the **[official Cardano website](https://cardano.org/)** and watch a summary of Cardano's mission in this **[explainer video](https://www.youtube.com/watch?v=l_Nv0-PVrnM/)**.

CARDANO EXPLAINED

## **NEW TO CARDANO**

The understanding of basic concepts plays an integral role in getting acquainted with blockchain and Cardano in particular. In this section, we start our journey with basic concepts such as the notion of blockchain, understanding proof of stake, and what is a cryptocurrency. You will also find out about various types of wallets and tracking tools, and learn about the delegation options.

NEW TO CARDANO

## **WHAT IS BLOCKCHAIN**

A blockchain is a type of database or ledger that is duplicated and distributed to all participants within the blockchain network. It is made up of a set of interconnected nodes that store data or items of value in blocks. These blocks are validated, cryptograhpically secured, and linked to each other in chronological order in a chain. The information stored in the validated blocks of the blockchain cannot be altered later on. It is permanently inscribed in the distributed ledger.

Blockchain technology, otherwise known as distributed ledger technology (DLT), provides a decentralized and accessible data structure for various records. Such records might include financial payment and transaction details, as well as other types of information – from commerce to internet of things (IoT) records.

As a blockchain stores data in a decentralized manner, it is independent of centralized, controlling entities, or middlemen. This provides enhanced transparency of data storage and its management. An important feature of blockchain is that it stores records immutably, which means that they cannot be changed, forged, or deleted, as this will break the chain of records.

Blockchain can be compared to a book of permanent records, where every page acts as an information holder:

![](https://docs.cardano.org/assets/images/chain-of-blocks-cc81268ae211fa0d21acffddaec12bba.png)


Let’s take a closer look at existing data storage solutions to understand the difference between these systems:


![](https://ucarecdn.com/af01444d-6881-4aab-a0a9-ec2ff6a0ea40/)


- **Centralized systems** — all data entries and activities are usually managed using one central server. This increases the risk of a single point of failure, and also means that the controlling entity (such as banks or government institutions, for example) act as decision-makers.
- **Distributed systems** — generally rely on multiple server nodes, each of which serves a subset of the total end clients.
- **Decentralized systems** — all data and records of transactions are stored not in one server, but in a system of interconnected, independent nodes and terminals. This ensures independence from centralized entities, transparency, and security.

Finally, blockchains not only provide an immutable and secure database but also act as a functional environment to transact funds, create digital currencies, and process complex deals using digital agreements [(smart contracts)](https://docs.cardano.org/about-cardano/new-to-cardano/what-is-a-smart-contract).

WHAT IS BLOCKCHAIN

## **WHAT IS CRYPTOCURRENCY**

A cryptocurrency is a digital asset, which is stored on the ledger and is designed to serve as a medium of exchange for goods or services. It is otherwise called crypto.

Blockchain ledgers serve as the underlying technology for cryptocurrency creation in a decentralized environment. Blockchain protocols use rigorous cryptography techniques to enable the minting (creation) of cryptocurrency and to secure and verify crypto ownership and fund movement records. The price of cryptocurrency is not controlled by a government or centralized financial institution. It is defined by its value, correlation to real-world figures, and is driven by market supply and demand.

Addresses are used when sending cryptocurrency payments. They are unique identifiers and are represented by a string of numbers and letters that are obtained from the user's public keys.

**Ada is the native currency of Cardano**

Each blockchain ledger has its underlying cryptocurrency or native currency. Ada is the native, or principal currency on [Cardano](https://cardano.org/). This means that ada is the main payment unit on Cardano; it is accepted as fee-payment, to make deposits, and is also the only currency in which rewards are distributed.

Lovelace is the smallest denomination of ada. One ada = 1,000,000 lovelaces. Ada has six decimal places, which makes it easily divisible into smaller fractions.

**Native tokens**

Cardano also supports the creation of native tokens ‒ digital assets that are created for specific purposes. This means that users, developers, and businesses can use the Cardano blockchain to create tokens that represent a footprint of value (whether defined by the community, market state, or self-governed entity). A token can be fungible (interchangeable) or non-fungible (unique), and act as a payment unit, reward, trading asset, or information holder.


## **info**
**Related topics:**

- **[Cardano monetary policy](https://docs.cardano.org/about-cardano/explore-more/monetary-policy)**
- **[Learn about native tokens](https://docs.cardano.org/developer-resources/native-tokens)**.

WHAT IS CRYPTOCURRENCY

## **PROOF STAKE**

Proof of stake (PoS) is a type of [consensus mechanism](https://docs.cardano.org/about-cardano/learn/consensus-explained) or protocol that uses the amount of stake (or value) held in the system to determine consensus. In essence, a consensus protocol is what controls the laws and parameters governing the behavior of blockchains. Think of consensus as a ruleset that each network participant adheres to. As blockchains are not controlled by any single, central authority, a consensus protocol is used instead to allow distributed network participants to agree on the history of the network captured on the blockchain – to reach consensus on what has happened, and continue from a single source of truth.

Cardano is built on the ground-breaking PoS consensus protocol [Ouroboros](https://iohk.io/en/blog/posts/2022/06/03/from-classic-to-chronos-the-implementations-of-ouroboros-explained/), and the first blockchain consensus protocol to be developed through peer-reviewed research. At the heart of the protocol are [stake pools](https://docs.cardano.org/about-cardano/learn/stake-pools), reliable server nodes run by a stake pool operator to which ada holders can delegate their stake. Stake pools are used to ensure that everyone can participate in the protocol, regardless of technical experience or availability to keep a node running. These stake pools focus on maintenance and hold the combined stake of various stakeholders in a single entity.

**How does proof of stake compare to proof of work protocols?**

In contrast, proof of work (PoW) is a synchronous protocol that encourages miners to compete to be the first who can solve any problems within the block. A rewards system is used to incentivize this problem-solving. However, this approach comes at a cost, with increased electricity usage and longer time spans to solve problems within the chain. These factors can slow the network down significantly and means it is costly to maintain.

**Features of proof of stake**

One of the key features of PoS is that as a user's value increases, the opportunity to maintain the ledger also increases. This means a higher chance to produce new blocks that can be added to the blockchain and timestamped accordingly. The creator of a new block is chosen based on a combination of random selection and a determination of their stake, or wealth. A type of leader election occurs within the chain. It is worth remembering that within a proof of stake protocol, participants accumulate the transaction fees thereby adding to their wealth as they go. This approach encourages steady and stable growth of the blockchain and reduces the instances of stalled transactions that can prevent chain growth.

**Primary advantages of proof of stake**

Some of the primary advantages of PoS over PoW include:

- rigorous security protocols are incorporated into a PoS protocol
- reduced centralization - the risk of centralization is reduced by issuing penalties for selfish practices within the network
- energy efficiency - energy consumption is extremely efficient as a smaller amount of electricity, as well as hardware resources, are needed to produce and run the blockchain
- cost efficiencies - PoS currencies are far more cost-effective than those operating on PoW protocols.

PROOF STAKE

## **CARDANO TRACKING TOOLS**

Since Cardano is a public blockchain ledger, it is possible to easily track all recent transactions, block details, and epoch data using different tools.


**Exploring transactions and blocks**

**Cardano explorers**

There is a list of available [Cardano explorers](https://explorer.cardano.org/). These explorers provide user-oriented tools that fetch data from the main database and reflect it in a straightforward and convenient web interface.

Explorers usually show [epoch](https://www.essentialcardano.io/glossary/epoch-1e938a90) details, which include:

- a number of blocks produced during this epoch
- time the epoch started
- time of last produced block
- number of processed transactions
- total output in ada.

By choosing a specific block, you can explore it in more detail to see its ID, size, epoch and block details, number of included transactions, and confirmations.

You can also search for specific epochs, transactions, or blocks by pasting their IDs in the search field.

**Exploring assets**

Cardano supports multi-asset creation and management. To see a list of created assets and tokens, you can use these tools:

- [AdaStat (tokens)](https://adastat.net/tokens)
- [Cardano Assets](https://cardanoassets.com/)
- [Cardanoscan (tokens)](https://cardanoscan.io/tokens)
- [Pool.pm (tokens)](https://pool.pm/tokens)
- [Cexplorer (tokens)](https://cexplorer.io/token)
 
**Exploring stake pools**

To find a list of all registered stake pools, their tickers, pool names, and IDs, you can use these tools:

- [Cardano PoolTool](https://pooltool.io/)
- [Cardanoscan (pools)](https://cardanoscan.io/pools)
- [Pool.pm (pools)](https://pool.pm/search)


![](https://i.imgur.com/uj5kKUC.png)

CARDANO TRACKING TOOLS

## **TYPE OF WALLETS**

A blockchain wallet is a safe and secure place where users can keep their digital assets.

![](https://i.imgur.com/llzdxTp.png)

Blockchain wallets come in different forms, from desktop and mobile applications to hardware (USB-like) devices and paper wallets. All wallets are designed to enable the storage of digital assets and to allow the sending and receiving of those. Technically, assets are not stored in the wallet ‒ their records live on the blockchain and can be accessed using unique private keys, which grant the right to make transactions. Losing your private keys means losing access to your digital assets. That is why it is crucial to keep your keys safe and offline.

The difference between the wallet types lies in their security and supported functionality. Paper wallets are the most secure, for example, but not as convenient in use; some wallets support a limited number of assets, some lack certain features (like delegation, for instance).

Let's take a closer look at the pros and cons of different wallet types:

- **Paper wallets** — these are paper documents that contain public and private key details. Such documents can be stored in a safe place and are highly secure as they can’t be compromised via online attacks. Paper wallets are best to use for long-term savings. On the other hand, the assets linked to paper wallets are not possible to operate online, as they will have to be moved to other wallets first.
- **Hardware wallets** — these are devices that store digital assets offline and can be connected to a computer to access them. Hardware wallets are secure and their benefit lies in the balance of offline security and convenience as they can be carried around and used when needed. The disadvantage of the hardware wallet is the risk of device loss or damage.
- **Online wallets** — these wallets can be commonly set up using a browser. They work through the internet and store assets in a certain application or software. This is convenient as users can send, receive, and use their digital assets as in any other bank account or payment system. However, online wallets are more open to security issues and can be compromised or attacked. Search online for the most secure and suitable wallet; always keep your keys offline and use 2FA verification where possible (giving preference to security keys over SMS verification).
- **Desktop wallets** — these wallets can be downloaded on a personal computer. They are secure and convenient in use. Before choosing the best-matching solution, it is important to ensure that your computer meets software requirements and that the wallet supports the asset you would like to work with. Desktop wallets are easy to use, but are not as flexible or portable.
- **Mobile wallets** — these are wallet applications that can be installed directly on a smartphone. Such wallets are simple to install and use and are a good additional option for digital asset storage.

**Where to store ada?**

Different wallets support ada. Take a look at some possible options below to choose the one that matches your needs best.

**Daedalus**

Daedalus is a full node, desktop wallet. Daedalus downloads a full copy of the Cardano blockchain and independently validates every transaction in its history. This provides maximum security and completely trustless operation, without centrally-hosted third-party servers. It supports all major desktop operating systems and provides the following features:

- easy installation with one-click setup of bundled Cardano node
- locally stored wallets and encrypted private keys, not shared with third-party servers
- trustless operation with a locally running full Cardano node which independently validates full transaction history of the blockchain
- supports Cardano network by participating in the Ouroboros protocol
- wallet backup and restoration using mnemonics
- support for staking and delegation
- support for voting
- complete autonomy without reliance on third-party servers and services
- paper wallet generator for offline storage of funds

To install Daedalus, follow these steps:

1. First, read [system requirements](https://iohk.zendesk.com/hc/en-us/articles/360010496553). Please note that Daedalus is a resource-intensive application. If you want to manage ada quickly and easily you can try Lace, Nami, Yoroi, or other wallets.
2. Visit the official [Daedalus website](https://daedaluswallet.io/).
3. Follow [these installation instructions](https://iohk.zendesk.com/hc/en-us/articles/360011602173-Quick-start-guide#:~:text=Go%20to%20https%3A%2F%2Fdaedaluswallet,Daedalus%20wallet%20on%20your%20Machine.).

**Hardware wallets**

Here is a list of hardware wallets to consider for storing and transacting with ada:

1. Trezor Model T
2. [Ledger Nano S Plus](https://shop.ledger.com/pages/ledger-nano-s-plus)
3. [Ledger Nano X](https://shop.ledger.com/pages/ledger-nano-x)

See [how to use hardware wallets with Daedalus](https://iohk.zendesk.com/hc/en-us/articles/900004722083-How-to-use-Ledger-and-Trezor-HW-with-Daedalus).

**Other options**

- [Lace](https://www.lace.io/)
- [Nami](https://namiwallet.io/)
- [Eternl](https://eternl.io/app/mainnet/welcome)
- [GeroWallet](https://gerowallet.io/)
- [Typhon](https://typhonwallet.io/#/)
- [Ellipal](https://www.ellipal.com/)
- [AdaLite](https://adalite.io/)
- [Infinito Wallet](https://www.infinitowallet.io/)
- [Atomic Wallet](https://atomicwallet.io/)
- [Guarda](https://guarda.com/)
- [Tangem](https://tangem.com/)
- [SimpleHold Wallet](https://simplehold.io/)
- [Coin Wallet](https://coin.space/)
- [NuFi](https://nu.fi/)
- [NOW Wallet](https://walletnow.app/)


TYPE OF WALLETS

## **HOW TO DELEGATE**

Ada that is held on Cardano represents its holder’s stake in the protocol. The size of the stake is proportional to the amount of ada held. Users who hold a stake in Cardano can get passive rewards for validating blocks.

Since not everyone has the time, knowledge, or resources to run a stake pool, ada holders can delegate their stake to a preferred pool and let an operator maintain their stake on their behalf. This allows everyone to participate in the consensus and get rewards without having to continuously run the node online. The higher the stake in a pool, the more rewards will be assigned to its owners.

![](https://i.imgur.com/Paq8klb.png)

Ada holders can delegate their stake using different ecosystem wallets that support this functionality. Here are some useful articles to review:

- [How to stake your ada](https://www.essentialcardano.io/infographic/how-to-stake-your-ada)
- [How to choose a stake pool](https://iohk.zendesk.com/hc/en-us/articles/900002174303-How-to-choose-a-stake-pool)
- [How safe is it to delegate to a stake pool?](https://iohk.zendesk.com/hc/en-us/articles/900002046123-How-safe-is-it-to-delegate-to-a-stake-pool-)
- [How to delegate to a stake pool using](https://iohk.zendesk.com/hc/en-us/articles/900005718683-How-to-Delegate-to-a-stake-pool) Daedalus
- [Staking and delegating for beginners](https://forum.cardano.org/t/staking-and-delegating-for-beginners-a-step-by-step-guide/36681) (Daedalus)
- [How to delegate from the Yoroi wallet](https://forum.cardano.org/t/cardano-shelley-how-to-delegate-from-the-yoroi-wallet/38230)



![](https://i.imgur.com/RwS708B.png)

HOW TO DELEGATE

## **STAKING CALCULATOR**

Staking calculator is a tool used to predict approximate rewards a user may receive by delegating ada to a stake pool. Note that the rewards predicted by this calculator are only an **estimate**.

The actual amount of ada received in rewards may vary, and will depend on a number of factors, including actual stake pool performance, which is the number of blocks a stake pool is observed to produce in a given epoch versus the number it was expected to produce. Changes to network parameters may also affect rewards.

The annualized equivalent returns given by this calculator assume that stake is delegated to the same stake pool for a 365-day period, and that stake pool performance and other settings are consistent over that timeframe. IOG accepts no responsibility for any discrepancy between estimated and actual rewards, **this calculator is provided for guidance only**.

![](https://i.imgur.com/DIcah0s.png)

![](https://i.imgur.com/bULzKTT.png)

![](https://i.imgur.com/ItrI8ex.png)

![](https://i.imgur.com/bnYqy8A.png)

![](https://i.imgur.com/pBQXDvR.png)

![](https://i.imgur.com/7un0JCk.png)

STAKING CALCULATOR

## **WHAT IS SMART CONTRACT**

Smart contracts on Cardano are simple programs often referred to as validator scripts in which users define custom logic. They are automatically executed by each Cardano node validating the transaction when the transaction attempts to move funds from the script's address. The address of each script is derived from the hash-sum of the compiled script.

Once deployed, smart contracts become immutable, which means they cannot be changed. They are distributable and tamper-proof, fast, and cost-effective, as there is no intermediary, which saves both money and time.

**Tooling and languages**

Cardano introduced smart contract support in 2021. As a multi-functional environment, Cardano now supports the development and deployment of smart contracts using different programming languages. Here are some examples:

- [Plutus](https://plutus.readthedocs.io/en/latest/) — a purpose-built smart contract development and execution platform. Plutus contracts consist of parts that run on the blockchain (on-chain code) and parts that run on a user’s machine (off-chain or client code). Plutus draws from modern language research to provide a safe, full-stack programming environment based on Haskell, the leading functional programming language.
- [Marlowe](https://docs.marlowe.iohk.io/docs/introduction) — a domain-specific language (DSL) for writing and executing financial contracts that allows building contracts visually as well as in more traditional code. Financial institutions can use it to develop and deploy custom instruments for their customers and clients, for example. The Marlowe language itself is now embedded in JavaScript, TypeScript, and Haskell offering a choice of editors depending on developers’ preferences and skills.
- [Aiken](https://aiken-lang.org/) - a language and toolchain favoring developer experience. Aiken is used for on-chain validator scripts only.
- [OpShin](https://github.com/OpShin) - a programming language based on Python for generic smart contracts for Cardano.
- [plu-ts](https://github.com/HarmonicLabs/plu-ts) - TypeScript-embedded smart contract programming language and a transaction creation library.


## **info**
Discover more ecosystem [builder tools here](https://developers.cardano.org/tools).

Further reading and related topics:

- [Developer Portal - smart contracts overview](https://developers.cardano.org/docs/smart-contracts/)
- [A list of community-built developer tools on Cardano](https://www.essentialcardano.io/article/a-list-of-community-built-developer-tools-on-cardano) 

WHAT IS SMART CONTRACT

## **CARDANO NODES**

The [Cardano node](https://github.com/input-output-hk/cardano-node#overview-of-the-cardano-node-repository) is the top-level component within the network. Network nodes connect to each other within the networking layer, which is the driving force for delivering information exchange requirements. This includes new block diffusion and transaction information for establishing a better data flow. Cardano nodes maintain connections with peers that have been chosen via a custom peer-selection process. By running a Cardano node, you are participating in and contributing to the network.

**How does it work?**

[Stake pools](https://docs.cardano.org/about-cardano/learn/stake-pools) use the Cardano node to validate how the pool interacts with the network and are responsible for transaction processing and block production. They act as reliable server nodes that hold and maintain the combined stake of various stakeholders in a single entity.

**Producing a block**

The goal of blockchain technology is the production of an independently-verifiable and cryptographically-linked chain of records (blocks). A network of block producers works to collectively advance the blockchain. A [consensus](https://docs.cardano.org/about-cardano/learn/consensus-explained) protocol provides transparency and decides which candidate blocks should be used to extend the chain.

Submitted valid transactions might be included in any new block. A block is cryptographically signed by its producer and linked to the previous block in the chain. This makes it impossible to delete transactions from a block, alter the order of the blocks, remove a block from the chain (if it already has a number of other blocks following it), or insert a new block into the chain without alerting all the network participants. This ensures the integrity and transparency of the blockchain expansion.

**Slots and epochs**

The Cardano blockchain uses the [Ouroboros Praos](https://eprint.iacr.org/2017/573.pdf) protocol to facilitate consensus on the chain. Ouroboros Praos divides time into epochs. Each Cardano epoch consists of a number of slots, where each slot lasts for one second. A Cardano epoch currently includes 432,000 slots (5 days). In any slot, zero or more block-producing nodes might be nominated to be the slot leader. On average, one node is expected to be nominated every 20 seconds, for a total of 21,600 nominations per epoch. If randomly elected slot leaders produce blocks, one of them will be added to the chain. Other candidate blocks will be discarded.

**Slot leader election**

The Cardano network consists of a number of stake pools that control the aggregated stake of their owners and other stakeholders, also known as delegators. Slot leaders are randomly elected from among the stake pools. The more stake a pool controls, the greater the chance it has of being elected as a slot leader to produce a new block that is accepted into the blockchain. This is the basic concept of [proof of stake (PoS)](https://docs.cardano.org/about-cardano/new-to-cardano/proof-of-stake). To maintain a level playing field, and prevent a situation where a small number of very large pools control the majority of stake, Cardano has an incentive system that discourages delegation to pools that already control a large portion of the total stake.

**Transaction validation**

When validating a transaction, a slot leader needs to ensure that the sender has included enough funds to pay for that transaction and must also ensure that the transaction’s parameters are met. Assuming that the transaction meets all these requirements, the slot leader will record it as a part of a new block, which will then be connected to other blocks in the chain.


## **info**
Related topics:

- [About the Cardano network](https://docs.cardano.org/about-cardano/explore-more/cardano-network)

CARDANO NODES

## **STAKE POOLS**

A stake pool is a reliable server node that focuses on ledger maintenance and holds the combined resources - the 'stake' - of various stakeholders in a single entity. Stake pools are responsible for processing transactions that will be placed in the ledger, as well as producing new blocks. Stake pools are at the core of [Ouroboros](https://iohk.io/en/blog/posts/2022/06/03/from-classic-to-chronos-the-implementations-of-ouroboros-explained/), Cardano's proof-of-stake protocol.

To be secure, Ouroboros requires a good number of stakeholders to be online and maintain sufficiently good network connectivity at any given time. This is why Ouroboros relies on stake pools, entities that are committed to running the protocol 24/7, on behalf of the contributing stakeholders that hold ada. The idea is that these resource holders can bring their resources (their stake) together and form a pool, where typically one holder is the operator of the pool and the rest are delegators. Typically, the stake pool operator (SPO) installs and runs software compatible with the platform (the server node), while delegators take a more passive role. They delegate their stake to the pool.

While Ouroboros is cheaper to run than a proof-of-work protocol, running Ouroboros still incurs some costs. Therefore, SPOs are rewarded for running the protocol in the form of incentives that come from the transaction fees and inflation of the circulating ada supply.


## **info**
Further reading:

- [About stake pools, operators, and owners](https://docs.cardano.org/stake-pool-operators/about-stake-pools)

STAKE POOLS

## **DELEGATION**

As Cardano is a proof of stake (PoS) system, owning ada not only allows you to buy goods or services, but also confers upon you the right and obligation to participate in the protocol and create blocks. Stake delegation is a mechanism inherent in the [Ouroboros protocol](https://eprint.iacr.org/2016/889.pdf) that allows the protocol to scale even in a setting where the set of stakeholders might be highly fragmented.

Anyone who owns ada can participate in stake delegation while retaining their spending power. Note that you can spend your ada normally at any time, regardless of how you delegated it. This mechanism will enable stakeholders to participate in the slot leader election process in each epoch.

Stake delegation gives rise to stake pools that act similarly to mining pools in the Bitcoin protocol. Stake pool operators (SPOs) must be online to generate blocks if they are selected as slot leaders.

There are three options ada holders can consider for delegating their stake:

1. Run their own stake pool
2. Agree with a third party to run a private stake pool for them
3. Delegate to other stake pools.

**note**

If you are not familiar with Cardano CLI or stake pool operations, [see delegation tips here](https://docs.cardano.org/about-cardano/new-to-cardano/how-to-delegate).

**Stake delegation requirements**

Delegating stake requires posting two certificates to the chain: a staking address registration, and a delegation certificate. Posting certificates requires funds, so a user setting up their first wallet will need a bootstrapping mechanism. This mechanism relies on the possibility of base addresses using a [staking key](https://github.com/input-output-hk/cardano-rosetta/tree/master/examples#staking-key-registration-and-delegation) before posting the registration certificate for that key. Note that the stake address can be based either on a single key or on a script such as [multi-sig](https://github.com/input-output-hk/cardano-node-wiki/blob/main/docs/reference/simple-scripts.md#multi-signature-scripts).

**Delegation scheme**

With the concept of delegation, any stakeholder can allow a stake pool to generate blocks for the Cardano network. Then the protocol will distribute the rewards to all participants, including the fees for the SPO. A stakeholder delegates to a particular pool ID, which is the hash of the operator's [verification key](https://docs.cardano.org/about-cardano/learn/cardano-keys#vrf-keys).

To limit the delegate’s block generation power to a certain range of epochs and slots, the stakeholder can limit the proxy signing key’s valid message space to strings ending with a slot number in a specific range of values. This simple scheme is secure due to the verifiability and prevention of misuse properties of proxy signature schemes. This ensures that any stakeholder can verify that a proxy signing key was actually issued by a specific stakeholder to a specific delegate, and that the delegate can only use these keys to sign messages inside the key’s valid message space, respectively.

The funds belonging to one staking key of a user’s wallet require posting a single transaction, containing a delegation certificate. This will only incur the usual transaction fees. In particular, a stakeholder needs to pay a deposit for registering a stake address and not for the stake delegation itself. Once a stake address is registered, the stakeholder will only pay fees to set the delegation choice.

Note that the stakeholder's stake will count for the pool's stake during the reward calculation.

**Stake delegation scenario**

Imagine a user who is about to receive their first ada, through redemption, from a trade on an exchange, or some other source. They will set up a new wallet, and create an address to receive those funds. This address will be a base address, using a staking key that is generated by the wallet, but not yet registered on the chain.

After receiving the initial funds, the user can then participate in staking, by posting a staking key registration certificate, and a delegation certificate for their staking key. Once the key is registered, newly created addresses can be pointer addresses to the staking key registration certificate.

## **info**
Related topics:

- Operating a stake pool
- [Advice for stakeholders - delegators and stake pool operators](https://iohk.io/en/blog/posts/2020/11/13/the-general-perspective-on-staking-in-cardano/)

DELEGATION

## **PLEDGING AND REWARD**

Pledging is an important mechanism that encourages the growth of a healthy ecosystem within the Cardano blockchain. When you register a stake pool you can choose to pledge some, or all, of your ada to the pool, to make it more attractive to people who want to delegate. Although pledging is not required when setting up a stake pool, it can make the pool more attractive to delegators, as the higher the amount of ada that is pledged, the higher the rewards that will be paid out. The a0 protocol parameter defines the influence of the pledge on the pool reward.

**Distributing rewards**

During each epoch, rewards are distributed amongst all stakeholders who have delegated to a stake pool, either to their own stake pool, or another pool. These rewards are auto-generated by the protocol and are not managed by the stake pool operators (SPOs). Rewards come from two sources:

- All transaction fees: collated from the set of transactions included in a block that was minted during that epoch.
- Monetary expansion: involves distinguishing between the total supply of ada and the maximal supply of ada. The total supply consists of all ada currently in circulation, plus the ada in the treasury. The maximal supply is the maximal amount of ada that can ever exist. The difference between these two figures is called the reserve. During each epoch, a fixed but parameterizable percentage of the remaining reserve is taken from the reserve and used for epoch rewards and treasury, where the amount being sent to the treasury is a fixed percentage of the amount taken from the reserve.


Learn more about rewards sharing in the [rewards sharing and pledge on Cardano video](https://www.youtube.com/watch?v=EAzyN3H8MOA&t=7s).


The following formula outlines how the reward mechanism works. The available rewards amount, transaction fees, plus monetary expansion, are denoted by R. First, the share of all available rewards that a specific pool can receive is determined, as follows:

![](https://docs.cardano.org/assets/images/pledge_formula-6f0c9a8bbfad3923058b99148f970609.png)


These elements are defined as follows:

- R - total available rewards for this epoch
- a0 - pledge influence factor (can be between 0 and infinity)
- z0 - relative pool saturation size, i.e. 0.5% based on a number of desired pools (k=200)
- σ - stake delegated to the pool (including stake pledged by the owners and stake delegated by others)
- σ’ = min(σ, z0) - as σ, but capped at z0
- s - stake pledged by the owners
- s’ = min(s, z0) - as s, but capped at z0

Note that z0, σ and s are all relative, so they are fractions of the total supply, as they all lie between zero and one.

Two important considerations are:

1. Rewards increase with σ, but stop increasing once σ reaches z0, that is once the pool becomes saturated.
2. If a0 (the pledge influence) is zero, this formula simply becomes R·σ’, so it is proportional to the pool's stake, up to the point of saturation. For larger values of a0, the pledge s becomes more important.

Remember that the pledge is declared during pool registration (alongside the cost and margin values), and has to be honored by the pool owners who are delegating to the pool. If they collectively delegate less than the declared pledge, pool rewards for that epoch will be zero. Note that the pool will be public if its operator margin is set to less than 100%.

The rewards that are produced by this formula are now adjusted by pool's performance: we multiply by β/σa, where β is the fraction of all blocks produced by the pool during the epoch and σa is the stake delegated to the pool relative to the active stake (ie, total stake that is correctly delegated to a non-retired pool).

For an optimally performing pool (a pool producing all the blocks that it can produce), this factor will be 1, on average. The actual value will fluctuate due to the stochastic nature, or random process of the [Ouroboros Praos](https://eprint.iacr.org/2017/573.pdf) consensus algorithm.

After pool rewards have been calculated and adjusted for pool performance, they are distributed amongst the pool operator and the pool members, or people who delegated part, or all of their stake, to the pool. This happens in several steps:

- First, the declared costs are subtracted and given to the pool operator
- Next, the declared margin is subtracted and given to the pool operator
- Finally, the remainder is split fairly (proportional to delegated stake), amongst all stakeholders who delegated to the pool, including the pool owners.

The actual amount of ada received in rewards may vary, and will depend on a number of factors including; the actual stake pool performance, that is, the number of blocks a stake pool is observed to produce in a given epoch versus the number it was expected to produce. Changes to network parameters may also affect rewards.

PLEDGING AND REWARD

## **CONSENSUS EXPLAINED**

Consensus is the process of reaching a majority opinion by everyone involved in running the blockchain. An agreement must be made on which blocks to produce, which chain to adopt and to determine the single state of the network. The consensus protocol determines how individual nodes assess the current state of the ledger system and reach a consensus.

Blockchains create consensus by allowing participants to bundle transactions that others have submitted to the system in blocks, and add them to their chain (sequence of blocks). Determining who is allowed to produce a block when, and what to do in case of conflicts, (such as two participants adding different blocks at the same point of the chain), is the purpose of the different consensus protocols.

The protocol has three main responsibilities:

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

**About Ouroboros**

Cardano runs on the Ouroboros consensus protocol, which was delivered with several peer-reviewed papers presented at top-tier conferences and publications in the area of cybersecurity and cryptography. Rather than relying on 'miners' (as in proof-of-work protocols) to solve computationally complex equations to create new blocks – and rewarding the first to do so – proof of stake selects [stake pools to create new blocks](https://docs.cardano.org/about-cardano/learn/cardano-node#how-does-it-work) based on the stake they control in the network.

**How Ouroboros works**

Ouroboros divides time on Cardano into epochs where each epoch is divided into slots. A slot is a short period of time in which a block can be created. Grouping slots into epochs is central to adjusting the leader election process to the dynamically changing stake distribution.

Central to Ouroboros’ design is that it must retain its security in the presence of attacks. As such, the protocol has built-in tolerance to prevent attackers from propagating alternative versions of the blockchain and assumes that an adversary may send arbitrary messages to any participant at any time. The protocol is guaranteed to be secure in the so-called synchronous setting (that is, with strong guarantees on message delivery times) so long as more than 51% of the stake is controlled by honest participants (ie, those following the protocol).

A slot leader is elected for each slot, who is responsible for adding a block to the chain and passing it to the next slot leader. To protect against adversarial attempts to subvert the protocol, each new slot leader is required to consider the last few blocks of the received chain as transient: only the chain that precedes the prespecified number of transient blocks is considered settled. This is also referred to as the settlement delay. Among other things, this means that a stakeholder can go offline and still be synced to the blockchain, so long as it’s not for more than the settlement delay.

Within the Ouroboros protocol, each network node stores a copy of the transaction mempool – where transactions are added if they are consistent with existing transactions – and the blockchain. The locally stored blockchain is replaced when the node becomes aware of an alternative, longer valid chain.

Read the following section to learn more about the different types of Ouroboros.

CONSENSUS EXPLAINED

## **OUROBOROS OVERVIEW**

In mythology, [Ouroboros (also, uroboros)](https://en.wikipedia.org/wiki/Ouroboros) is usually depicted as a snake (or sometimes a dragon) eating its own tail in a closed circle. The word Ouroboros itself derives from Ancient Greek, its literal meaning being 'tail eating' or 'tail devourer.'

As a symbol, Ouroboros represents the infinity of time flowing back unto itself, in a never-ending cycle, as if caught in an eternal loop. Ouroboros first appeared in Egypt, in the 13th century BC. Later, alchemists adopted Ouroboros into their mystical symbolism.

Throughout the ages, Ouroboros has been interpreted and used in a variety of ways by a plethora of cultures. One of the most common interpretations is that the symbol represents the interconnectedness and infinity of the universe.

In 2017, [Charles Hoskinson](https://en.wikipedia.org/wiki/Charles_Hoskinson) adopted Ouroboros to name the proof-of-stake consensus protocol underlying Cardano. In this context, Ouroboros represents the possibility of infinite and ethical growth and scalability of the blockchain. Ouroboros' central message is the delivery of greater opportunities for the world, and its preservation through [much-reduced energy consumption](https://iohk.io/en/blog/posts/2021/08/17/why-they-re-calling-cardano-the-green-blockchain/).

**What is Ouroboros**

[Ouroboros](https://eprint.iacr.org/2016/889.pdf) is the consensus protocol for Cardano, the first provably secure proof-of-stake protocol, and the first blockchain protocol based on peer-reviewed research.

Combining unique technology and mathematically verified mechanisms (including behavioral psychology and economic philosophy principles), Ouroboros guarantees and supports the security and sustainability of any blockchain implementing it. The result is a protocol with proven security guarantees, able to facilitate the propagation of global, permissionless networks with minimal energy requirements. Cardano is the first such network.

Ouroboros selects participants - stake pools, in this case - to create new blocks based on the stake they control in the network, and facilitates the creation of distributed, permissionless networks capable of sustainably supporting new markets.

**Ouroboros implementations**

Ouroboros comes in different versions:

- [Ouroboros Classic](https://iohk.io/en/research/library/papers/ouroborosa-provably-secure-proof-of-stake-blockchain-protocol/)
- [Ouroboros BFT](https://iohk.io/en/research/library/papers/ouroboros-bfta-simple-byzantine-fault-tolerant-consensus-protocol/)
- [Ouroboros Praos](https://iohk.io/en/research/library/papers/ouroboros-praosan-adaptively-securesemi-synchronous-proof-of-stake-protocol/)
- [Ouroboros Genesis](https://iohk.io/en/research/library/papers/ouroboros-genesiscomposable-proof-of-stake-blockchains-with-dynamic-availability/)
- [Ouroboros Crypsinous](https://iohk.io/en/research/library/papers/ouroboros-crypsinousprivacy-preserving-proof-of-stake/)
- [Ouroboros Chronos.](https://iohk.io/en/research/library/papers/ouroboros-chronospermissionless-clock-synchronization-via-proof-of-stake/)


** Ouroboros Classic**

The first implementation of [Ouroboros](https://iohk.io/en/research/library/papers/ouroborosa-provably-secure-proof-of-stake-blockchain-protocol/) achieved three major milestones:

- the foundation for an energy-efficient protocol to rival proof of work
- the introduction of the mathematical framework to analyze proof of stake
- the implementation of a novel incentive mechanism to reward participants in a proof-of-stake setting.

But what really set Ouroboros apart from other blockchain protocols (specifically, proof-of-stake protocols), was its ability to generate unbiased randomness in the protocol’s leader selection algorithm, and the subsequent security assurances that provided. Randomness prevents the formation of patterns, which is critical for maintaining the protocol’s security. Ouroboros was the first blockchain protocol developed with this type of rigorous security analysis.

**Ouroboros BFT**

[Ouroboros Byzantine Fault Tolerance (BFT)](https://iohk.io/en/research/library/papers/ouroboros-bfta-simple-byzantine-fault-tolerant-consensus-protocol/) was the protocol's second implementation, used during the Byron update (transition from the old Cardano codebase to the new). The second instance of the protocol prepared Cardano for the decentralization that came with the Shelley release.

Ouroboros BFT enabled synchronous communication between a network of federated servers – the blockchain – providing ledger consensus in a simpler and more deterministic manner.

**Ouroboros Praos**

[Ouroboros Praos](https://iohk.io/en/research/library/papers/ouroboros-praosan-adaptively-securesemi-synchronous-proof-of-stake-protocol/) introduced substantial security and scalability improvements to the Ouroboros Classic implementation. Praos processes transaction blocks by dividing chains into slots, which are aggregated into epochs. But unlike Ouroboros Classic, Praos is analyzed in a semi-synchronous setting and is secure against adaptive attackers, using private-leader selection and forward-secure, key-evolving signatures to ensure that a strong adversary cannot predict the next slot leader and launch a focused attack (such as a DDoS attack).

**Ouroboros Genesis**

The fourth iteration of Ouroboros - [Genesis](https://iohk.io/en/research/library/papers/ouroboros-genesiscomposable-proof-of-stake-blockchains-with-dynamic-availability/) - further improves upon Ouroboros Praos by adding a novel chain selection rule that enables parties to bootstrap from a genesis block without the need for trusted checkpoints or assumptions about past availability. The Genesis paper also provides proof of the protocol’s Universal Composability, which demonstrates that the protocol can be composed with other protocols in arbitrary configurations in a real-world setting, without losing its security properties.

**Ouroboros Crypsinous**

[Ouroboros Crypsinous](https://iohk.io/en/research/library/papers/ouroboros-crypsinousprivacy-preserving-proof-of-stake/) equips Genesis with privacy-preserving properties. It is the first formally analyzed privacy-preserving proof-of-stake blockchain protocol, which achieves security against adaptive attacks while maintaining strong privacy guarantees by introducing a new coin evolution technique relying on Snarks and key-private forward-secure encryption. Crypsinous isn’t currently planned to be implemented on Cardano, but it can be used by other chains for increased privacy-preserving settings.

**Ouroboros Chronos**

[Chronos](https://iohk.io/en/research/library/papers/ouroboros-chronospermissionless-clock-synchronization-via-proof-of-stake/) achieves two goals: first, it shows how blockchain protocols can synchronize clocks securely via a novel time synchronization mechanism and thereby become independent of external time services. Second, it provides a cryptographically secure source of time to other protocols. In short, Chronos makes the ledger more resistant to attacks that target time information.

From an application point of view, Chronos can dramatically boost the resilience of critical telecommunications, transport, and other IT infrastructures that require the synchronization of local time to a unified network clock that has no single point of failure.

OUROBOROS OVERVIEW

## **CARDANO KEYS**

Cardano keys are asymmetric cryptography key pairs used for:

- signing and validating payments and staking certificates
- identifying and defining addresses on the Cardano blockchain.

This schematic illustrates the relationship between keys, addresses, and certificates:

![](https://docs.cardano.org/assets/images/keys-certificates-f296896ae053d833b064b28cb89ed509.png)

**Types of keys**

In Cardano, there are two main key types:

- node keys
- address keys.

**Node keys**

Node keys represent the security of the blockchain and consist of the following keys:

- operator/operational key
- key evolving signature (KES) key pair
- verifiable random function (VRF) keys.

**Operator/operational key**

These are operators’ offline key pairs that include a certificate counter for new certificates.

It is the responsibility of the operator to manage both the hot (online), and cold (offline) keys for the pool. Cold keys must be secure and should not reside on a device with internet connectivity. It is recommended to keep multiple backups of cold keys.

**KES key pair**

To create an operational certificate for a block-producing node, you need a KES key pair, which authenticates who you are.

A KES key can only evolve for a certain number of periods and becomes useless afterwards. This is useful, because even if an attacker compromises the key and gets access to the signing key, he can only use that to sign blocks from now on, but not blocks dating from earlier periods, making it impossible for the attacker to rewrite history.

After the set number of periods has passed, the node operator must generate a new KES key pair, issue a new operational node certificate with that new key pair, and restart the node with the new certificate.

**VRF keys**

Ouroboros Praos adds an extra layer of security to block production via VRF keys.

In other proof-of-stake blockchain protocols (Ouroboros Classic or BFT, for instance), we know who has the right to make the block in each slot, because the slot leader schedule is public. In this case, you only have to prove that you are who you say you are, and everyone can check the public slot leader schedule to verify it.

However, Ouroboros Praos's slot leader schedule is kept private, which means that nobody knows in advance who is going to be the slot leader, but once someone is, they can prove to everyone else that they are using the VRF key.

The VRF key is a signing verification key stored within the operational certificate. It proves that a node has the right to create a block in a given slot.

**Address keys**

Address keys represent the functions of the addresses derived from the keys for identifying funds on the blockchain that consist of the following keys:

- Payment key: single address key pair usually used for generating UTXO addresses
- Staking key: stake/reward address key pair usually used for generating account/reward addresses.


## **info**
Developer resources:

- [Creating keys and addresses](https://github.com/input-output-hk/cardano-node-wiki/wiki/3_keys_and_addresses)
- [Creating KES key pair](https://github.com/input-output-hk/cardano-node-wiki/wiki/7_KES_period)
- [Generating stake pool keys](https://iohk.zendesk.com/hc/en-us/articles/900001331786-Generate-stake-pool-keys)
- [Generating payment/staking keys and address](https://iohk.zendesk.com/hc/en-us/articles/900001219883-Generating-payment-staking-keys-and-address)

CARDANO KEYS

## **CARDANO ADDRESSES**

The addresses are a blake2b-256 hash of the relevant verifying/public keys concatenated with some metadata that can be stored on the [Cardano blockchain](https://cardano.org/).

Shelley introduced four different types of addresses:

- base addresses
- pointer addresses
- enterprise addresses
- reward account addresses.

Besides those new addresses, Shelley continued to support Byron-era bootstrap addresses and script addresses, but only the new base and pointer addresses carried stake rights. Therefore, addresses consist of some serialized data specified in the ledger specification stored in the blockchain’s blocks, eg, an Unspent Transaction Output (UTXO) address.

The serialized data (address) contains two parts:

- metadata: used for interpreting
- payload: the raw or encoded data.

**Base addresses**

A base address directly specifies the staking key that should control the stake for that address. The staking rights associated with funds held in this address may be exercised by the owner of the staking key. Base addresses can be used in transactions without registering the staking key in advance.

The stake rights can only be exercised by registering the stake key and delegating to a stake pool. Once the stake key is registered, the stake rights can be exercised for base addresses used in transactions before or after the key registration.

**Pointer addresses**

A pointer address indirectly specifies the staking key that should control the stake for the address. It references a stake key by a stake key pointer, which is a location on the blockchain of the stake key registration certificate for that key. Pointer addresses can be used in transactions, even if their target is not an active stake key registration. This covers the scenario where the key was unregistered after (or indeed, before) the transaction, and also covers pointers to targets that are plainly invalid. The reason for allowing such invalid targets is so that nodes only need to track the currently active stake keys.

The pointer can be considerably shorter than the hash used in base addresses.

There is a subtlety with pointer addresses. It might happen that a stake key registration certificate referenced by a pointer address might be lost due to a rollback. To prevent loss of funds in this scenario, the system considers pointer addresses with an invalid pointer to be valid for the purpose of using funds stored therein as inputs for transactions (but ignores them for the purpose of proof of stake participation). Optionally, a wallet might refuse to create transactions to pointer addresses before the referenced certificate has become immutable, to prevent funds from being excluded from the proof of stake, in the case of rollbacks.

**Enterprise addresses**

Enterprise addresses carry no stake rights, so using these addresses means that you are opting out of participation in the proof-of-stake protocol.

Exchanges or other organizations that control large amounts of ada – but hold it on behalf of other users – may wish to follow a policy of not exercising stake rights. By using enterprise addresses, exchanges can demonstrate that they follow this policy. Since enterprise addresses are not associated with any staking key, they are automatically excluded from the mechanisms that influence the slot leadership schedule. Note that using addresses with no stake rights effectively decreases the total amount of stake, which plays into the hands of a potential adversary.

Also note that enterprise addresses may still be used to receive, hold, and send
tokens with a policyID (non-ada assets).

**Reward account addresses**

A reward address is a cryptographic hash of the public staking key of the address. Reward account addresses are used to distribute rewards for participating in the proof-of-stake protocol (either directly or via delegation).

They have the following properties:

- account-style accounting is used, not UTXO-style
- funds cannot be received via transactions; instead, their balance is only increased when rewards are distributed
- a one-to-one correspondence exists between registered staking keys and reward account addresses.

This key is used whenever funds are withdrawn from the address. Furthermore, stake associated with funds in the address contributes to the stake of this key. Just as in the case of enterprise addresses, the staking object for a reward address does not need to contain information.

CARDANO ADDRESSES

## **CHAIN CONFIRMATION VERSUS TRANSACTION CONFIRMATION**

When discussing [Cardano](https://cardano.org/), often-repeated questions are what is Cardano’s transaction time?, and how many network confirmations does Cardano require before a transaction goes through? The answers to these questions require a deeper look at the concepts of chain confirmation and transaction confirmation, and how these relate to the Ouroboros protocol.

**Chain confirmation**

This is the point beyond which the chain is guaranteed by the protocol not to alter any further because of randomness, or random events.

Chain confirmation occurs at some point in the future, after a certain amount of future k blocks have been minted. The time between now and the point when chain confirmation for a particular transaction occurs is called the stability window (that is, the number of slots required for a block to become stable, where stable is defined as a block that cannot be rolled back). The formula to calculate this window is 3k/f (where k is the security parameter in genesis, and f is the active slot co-efficient parameter in genesis that determines the probability for amount of blocks created in an epoch.)

**Transaction confirmation**

This is the point in time when a transaction is accepted into the chain and becomes immutable. The concepts of block depth and settlement window come into play here.

A transaction can be considered confirmed if the block that contains it is deep enough in the chain. Deep enough is a relative concept: the depth of a block indicates how many more blocks have been added to the chain since that particular block was appended to it. And because blocks have depth, so do the transactions contained in them.

If the depth of a particular block is greater than a pre-defined threshold, the transaction is considered to be confirmed, and the assets in that transaction can be used 'safely' (ie, the protocol guarantees that the transaction has become immutable, so the assets can be traded, exchanged, etc.)

The time period that elapses between the point when a transaction is confirmed, and when the transaction's assets can be used to exchange with other assets is called the settlement window.

**Likelihood of immutability**

Another way of determining whether or not a transaction is confirmed is by considering the transaction's likelihood of immutability. The probability of a transaction being immutable depends on how many blocks have been added to the chain since that transaction was accepted into the chain. The more blocks added, the higher the probability that the transaction will become immutable.

A transaction becomes immutable as soon as its depth is greater than 3k/f slots. This is guaranteed by the [Ouroboros Praos protocol](https://eprint.iacr.org/2017/573.pdf). However, 3k/f slots normally exceed the requirements in most situations, so a more practical approach is to consider the probability for a transaction to become immutable. In this case, we consider that a transaction is confirmed if the probability for it to become immutable is high enough.

CHAIN CONFIRMATION VERSUS TRANSACTION CONFIRMATION

## **EXTENDED UTXO MODEL**

**info**

The EUTXO handbook is now out! Deep dive into [Cardano's EUTXO accounting model here](https://ucarecdn.com/3da33f2f-73ac-4c9b-844b-f215dcce0628/EUTXOhandbook_for_EC.pdf).

Cardano (like Bitcoin) is an Unspent Transaction Output (UTXO)-based blockchain, which utilizes a different accounting model for its ledger from other account-based blockchains like Ethereum. Cardano implements an innovative [Extended Unspent Transaction](https://iohk.io/en/blog/posts/2021/03/11/cardanos-extended-utxo-accounting-model/) Output (EUTXO) model, which was introduced by the Alonzo upgrade to support multi-assets and smart contracts.

**Overview of the UTXO model**

In the UTXO model, a transaction has inputs and outputs, where the inputs are unspent outputs from previous transactions. Assets are stored on the ledger in unspent outputs, rather than in accounts. In abstract terms, think of a transaction as the action that unlocks previous outputs, and creates new ones.

**Transaction output**

A transaction output includes an address (that you can think of as a lock) and a value. In keeping with this analogy, the signature that belongs to the address is the key to unlock the output. Once unlocked, an output can be used as input. New transactions spend outputs of previous transactions, and produce new outputs that can be consumed by future transactions. Each UTXO can only be consumed once, and as a whole. Each output can be spent by exactly one input, and one input only.

**Transaction input**

A transaction input is the output of a previous transaction. Transaction inputs include a pointer and a cryptographic signature that acts as the unlocking key. The pointer points back to a previous transaction output, and the key unlocks this output. When an output is unlocked by an input, the blockchain marks the unlocked output as 'spent'. New outputs created by a given transaction can then be pointed to by new inputs, and so the chain continues. These new outputs (which have not yet been unlocked, ie, spent) are the UTXOs. Unspent outputs are simply that, outputs that have not yet been spent.

In summary, transactions consume unspent outputs from previous transactions, and produce new outputs that can be used as inputs for future transactions.

![](https://ucarecdn.com/2a252deb-412f-4019-ae1e-e6dba7dea50b/)

The users' wallets manage these UTXOs and initiate transactions involving the UTXOs owned by the user. Every blockchain node maintains a record of the subset of all UTXOs at all times. This is called the UTXO set. In technical terms, this is the chainstate, which is stored in the data directory of every node. When a new block is added to the chain, the chainstate is updated accordingly. This new block contains the list of latest transactions (including, of course, a record of spent UTXOs, and new ones created since the chainstate was last updated). Every node maintains an exact copy of the chainstate.

**Cardano’s extended UTXO model**

The EUTXO model extends the UTXO model in two ways:

1. It generalizes the concept of ‘address’ by using the lock-and-key analogy. Instead of restricting locks to public keys and keys to signatures, addresses in the EUTXO model can contain arbitrary logic in the form of scripts. For example, when a node validates a transaction, the node determines whether or not the transaction is allowed to use a certain output as an input. The transaction will look up the script provided by the output's address and will execute the script if the transaction can use the output as an input.
2. The second difference between UTXO and EUTXO is that outputs can carry (almost) arbitrary data in addition to an address and value. This makes scripts much more powerful by allowing them to carry state information.

Furthermore, EUTXO extends the UTXO model by allowing output addresses to contain complex logic to decide which transactions can unlock them, and by adding custom data to all outputs. When validating an address, the script will access the data being carried by the output, the transaction being validated, and some additional pieces of data called redeemers, which the transaction provides for every input. By looking up all this information, the script has enough context to give a ‘yes’ or ‘no’ answer in what can be highly complex situations and use cases.

EUTXO enables arbitrary logic in the form of scripts. This arbitrary logic inspects the transaction and the data to decide whether the transaction is allowed to use an input or not.

The UTXO model with its graph structure is fundamentally different from the account-based model used by some existing smart-contract enabled blockchains. As a result, the design patterns that work for DApps on account-based blockchains do not translate directly to Cardano. New design patterns are needed because the underlying representation of the data is different.

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

**Advantages of EUTXO**

Cardano’s EUTXO model provides a secure and versatile environment to process multiple operations without system failures. This model offers better scalability and privacy, as well as more simplified transaction logic, as each UTXO can only be consumed once and as a whole, which makes transaction verification much simpler.

The EUTXO model offers unique advantages over other accounting models. The success or failure of transaction validation depends only on the transaction itself and its inputs, and not on anything else on the blockchain. As a consequence, the validity of a transaction can be checked off-chain, before the transaction is sent to the blockchain. A transaction can still fail if some other transaction concurrently consumes an input that the transaction is expecting, but if all inputs are still present, the transaction is guaranteed to succeed.

This contrasts with an account-based model (as used by Ethereum), where a transaction can fail in mid-script execution. This can never happen in EUTXO.

Due to the ‘local’ nature of transaction validation, a high degree of parallelism is possible. A node could, in principle, validate transactions in parallel, if those transactions do not try to consume the same input. This is great both for efficiency and for reasoning, simplifying the analysis of possible outcomes, and proving that ‘nothing bad’ can happen. You can dive deeper into the EUTXO model blog post.

A powerful feature of the EUTXO model is that the fees required for a valid transaction can be predicted precisely prior to posting it. This is a unique feature not found in account-based models. Account-based blockchains, like Ethereum, are indeterministic, which means that they cannot guarantee the transaction’s effect on-chain. This uncertainty presents risks of monetary loss, unexpectedly high fees, and additional opportunities for adversarial behavior.

To summarize, EUTXO offers greater security, smart contract execution cost predictability (without unpleasant surprises) and more powerful parallelization.

EXTENDED UTXO MODEL

## **TRANSACTION COSTS AND DETERMINISM**

Cardano’s approach to price setting mainly relies on market demand over actual supply. On Cardano, more than one type of demand competes for the common supply. Thus, it is crucial to consider both relative and absolute pricing. One way to do this is to inspect the effects of smart contract pricing, non-fungible token (NFT) operations, and so on, with respect to some common value – in our case, the consumption of Cardano’s processing power.

The Cardano ledger's design is focused on high assurance, security, and proven formal verification. In alignment with this strategy, it is also important to ensure that transaction processing is deterministic, meaning that a user can predict the impact and outcome of a transaction before its actual execution.

The ability to guarantee the cost of transaction execution and how the transaction behaves on the ledger before it is submitted became even more prominent with the introduction of smart contract support in 2021. This feature is different from other blockchains, including Ethereum, where other network activity can influence the gas cost. This ability is also guaranteed by the deterministic nature of Cardano and Plutus scripts.

**Determinism**

Determinism, in the context of transaction and script processing, is a synonym for predictability. This means that a user can predict locally (off-chain) how their transaction will impact the on-chain state of the ledger, without encountering the following:

- unexpected script validation outcomes or failures
- unexpected fees
- unexpected ledger or script state updates.

**Validation**

An important aspect of processing a transaction is validating the actions it is taking. A transaction is taking an action when it contains data in the specific field to that action. For example, a transaction is spending UTXO U when it contains a reference to U in its input field, and it is minting a token X when its mint field contains X.

Cardano uses scripts to validate actions. These scripts, which are pieces of code, implement pure functions with True or False outputs. Script validation is the process of invoking the script interpreter to run a given script on appropriate arguments.

Script validation can be performed for the following actions:

- Spending a UTXO locked by a script address: the script that is run is the one whose hash forms the address.
- Minting a token: the script that is run is the one whose hash forms the policy ID of the token being minted.
- Reward withdrawal: the script that is run is the one whose hash forms the staking address.
- Applying a certificate: the script that is run is the one whose hash forms the certificate author’s credential.

Besides letting the node know which script to run, all transaction actions indicate how to assemble arguments passed to that script. Alonzo introduced a new approach to transaction validation on Cardano due to the implementation of Plutus scripts.

**Ledger features**

The Alonzo upgrade changed the data on the ledger as follows:

1. Plutus scripts can lock UTXOs.
2. A component, added to the contents of the output parts of UTXOs, enables script state-like functionality. In addition to assets and an address, a UTXO locked by Plutus scripts also contains a datum. A datum is a piece of data that can be thought of as an interpretation of the script state.
3. There are a number of protocol parameters used to impose additional validation requirements on transactions. These include upper limits on computational resources that scripts can consume.

To support Plutus scripts, transactions have the following features:

1. For each of its actions, the transaction carries a user-specified argument, called a redeemer. Depending on the script, a redeemer can serve a different purpose. For example, it can act as the bid the user places in an auction, or the user’s guess in a guessing game, among many other functions.
2. The transaction specifies computational execution budgets for each script.
3. To ensure that a transaction can pay its execution fee, Alonzo introduced collateral.
4. Transactions contain an integrity hash, needed to ensure that it has not been compromised, outdated, etc.

With the Vasil upgrade, Plutus scripts were upgraded to V2 functionality with an improved cost model and new built-ins. The use of reference inputs, inline datums, and reference scripts allowed for efficient throughput and significantly increased performance. [See the complete Vasil feature overview here](https://docs.cardano.org/about-cardano/evolution/upgrades/vasil).

The node performs the checks that ensure the transaction is constructed correctly. For example, it must not exceed the maximum execution resource budget. It also invokes the Plutus script interpreter to run the scripts.

The non-deterministic gas model can charge users unpredictably large fees. In Cardano scripts, this source of indeterminism is addressed by requiring that the resource budget itself, as well as the fee required to cover this budget, are included in the transaction. Script execution necessarily returns either True or False, and will not loop indefinitely. The reason for this is that every operation a script performs takes a non-zero amount of resources, which are tracked by the interpreter. If the budget specified by the transaction is exceeded, script execution terminates and returns False.

The following key points make the outcomes of script and transaction validation **predictable**:

- the script interpreter will always terminate and return the same validation result when applied to the same arguments
- a transaction necessarily fixes all arguments that will be passed to the script interpreter during validation
- a transaction specifies all the actions it is taking that require script validation
- compulsory signatures on a transaction ensure that it cannot be altered by an adversary in a way that causes scripts to fail
- applying a transaction in the EUTXO ledger model is deterministic.

Script validation failure or success does affect how a transaction is processed. However, the True or False outcome, as well as ledger changes associated with either outcome, are predictable for a given transaction.

## **info**
Further reading:

- [Cost model parameters for Plutus scripts](https://plutus-apps.readthedocs.io/en/latest/reference/cost-model-parameters.html)
- [No surprises transaction validation on Cardano: Part 1](https://iohk.io/en/blog/posts/2021/09/06/no-surprises-transaction-validation-on-cardano/)
- [No surprises transaction validation: Part 2 (about two phases of validation and collateral](https://iohk.io/en/blog/posts/2021/09/06/no-surprises-transaction-validation-on-cardano/)

TRANSACTION COSTS AND DETERMINISM

## **ABOUT COLLATERAL MECHANISM**

The collateral mechanism is an important feature that has been designed to ensure successful smart contract execution.

Relying on the guarantees provided by the deterministic design of the ledger, Cardano implements a two-phase validation scheme. The main reason for two-phase validation is to limit the amount of uncompensated validation work by nodes. Each phase serves a purpose in achieving this goal:

- The first phase checks whether the transaction is constructed correctly and can pay its processing fee
- The second phase runs the scripts included in the transaction.

If the transaction is phase-1 valid, phase-2 scripts run. If phase-1 fails, no scripts run, and the transaction is immediately discarded.

Collateral is used to guarantee that nodes are compensated for their work in case phase-2 validation fails. Thus, collateral is the monetary guarantee a user gives to assure that the contract has been carefully designed and thoroughly tested. The collateral amount is specified at the time of constructing the transaction. Not directly, but by adding collateral inputs to the transaction. The total balance in the UTXOs corresponding to these specially marked inputs is the transaction’s collateral amount. If the user fulfills the conditions of the guarantee, and a contract gets executed, the collateral is safe.

**The scenario**

Without collateral, the user is not charged if a smart contract fails. However, by the time the transaction fails, the network has already incurred some costs to initiate and validate the transaction. This means that a malicious actor could flood the network with invalid transactions, denying service to other users at little cost.

**The solution**

When a user initiates a transaction, they commit enough ada to cover its execution cost. On Cardano, transactions that call and use non-native smart contracts (known as phase-2 contracts) also need enough collateral to cover costs related to potential transaction failures. This amount can be small, but it is sufficient to make a denial of service (DOS) attack prohibitively expensive.

Collateral fees are collected only if a transaction fails validation. If the contract passes validation, the transaction fees are collected, but the collateral is not.

**The reasoning**

An honest user is never at risk of losing their collateral.

The [Cardano](https://cardano.org/) blockchain is deterministic with respect to transaction costs because these costs depend only on local values and local state. That means a user can calculate the execution cost (in ada) of a transaction before submitting it. This feature is different from other blockchains, including Ethereum, where other network activity can influence the gas cost. The required amount of collateral depends only on the execution cost.

The Cardano testnet provides a safe environment with free test ada, so decentralized application (DApp) developers can thoroughly test their smart contracts before deploying them to mainnet. If transactions succeed on testnet, the developer can be perfectly sure that all the scripts will indeed succeed.

If the on-chain conditions have changed since the transaction was constructed, that transaction will be rejected entirely, and no fees will be charged. If a signature is missing, for example, no collateral would be charged.

**Technical details**

The term collateral refers to the total ada contained in the UTXOs referenced by collateral inputs. A transaction uses collateral inputs to cover its fees if a phase-2 script fails.

The Shelley formal specification introduced the concept of 'multi-signature' scripts. Phase-1 scripts, such as these, are captured entirely by the ledger rules. Execution costs can therefore be easily assessed before they are processed by the implementation, and any fees can be calculated directly within the ledger rule implementation, based on the size of the transaction that includes the script, for example.

In contrast, phase-2 scripts can perform arbitrary (and, in principle, Turing-complete) computations. Cardano requires transactions that use phase-2 scripts to have a budget in terms of a number of abstract ExUnits. This budget gives a quantitative bound on resource usage in terms of a number of specific metrics, including memory usage or abstract execution steps. The budget is then used as part of the transaction fee calculation.

After the Vasil upgrade, DApp developers can also specify a change address for the script collateral. This means that in case the script fails phase-2 validation, only the right amount will be taken, and the remaining funds will be sent to the provided change address. The [how to use collateral outputs](https://github.com/perturbing/vasil-tests/blob/main/collateral-output-cip-40.md) tutorial provides more details.

ABOUT COLLATERAL MECHANISM

LEARN

## **CARDANO ARCHITECTURE**

This section describes the high-level architecture of Cardano, providing details on the core components and their interactions.

The following diagram outlines the interaction between the system components of Cardano:

![](https://ucarecdn.com/3756645a-a4a2-4d2f-846a-e454bf7cba60/)

**System components**

The current implementation of Cardano is highly modular. It includes the following components (different deployment use cases will use different combinations of components):

- [Node](https://github.com/input-output-hk/cardano-node)
- [Command line interface (CLI)](https://github.com/IntersectMBO/cardano-cli)
- [Cardano wallet](https://github.com/input-output-hk/cardano-wallet)
- [Cardano db-sync](https://github.com/input-output-hk/cardano-db-sync)
- [GraphQL API](https://github.com/input-output-hk/cardano-graphql) server (Apollo)
- [SMASH server](https://github.com/IntersectMBO/cardano-db-sync/tree/master/cardano-smash-server).

**Nodes and remote nodes**

A blockchain system consists of a set of nodes distributed across a network that communicate with each other to achieve [consensus](https://docs.cardano.org/about-cardano/learn/consensus-explained) about the system’s state.

Nodes are responsible for:

- Executing the [Ouroboros](https://github.com/IntersectMBO/ouroboros-network?tab=readme-ov-file#ouroboros-network) protocol
- Validating and relaying blocks
- Producing blocks (some nodes)
- Providing information about the state of the blockchain to other local clients.

**Node process**

The `cardano-node` is the top level Cardano component that consists of the other subsystems, of which the most significant are [consensus](https://github.com/IntersectMBO/ouroboros-consensus?tab=readme-ov-file#ouroboros-consensus), [ledger](https://github.com/IntersectMBO/cardano-ledger?tab=readme-ov-file#cardano-ledger), and [networking](https://github.com/IntersectMBO/ouroboros-network?tab=readme-ov-file#ouroboros-network) with ancillary configuration, CLI, logging, and monitoring.

**Node-to-node IPC protocol**

The purpose of the node-to-node Inter-Process Communication (IPC) protocol is to allow for the exchange of blocks and transactions between nodes as part of the Ouroboros consensus algorithm.

The node-to-node protocol is a composite protocol, consisting of three mini-protocols:

- **chain-sync**: used for following the chain and getting block headers
- **block-fetch**: used for getting block bodies
- **tx-submission**: used for forwarding transactions.

These mini-protocols are multiplexed on a single long-running Transmission Control Protocol (TCP) connection between nodes. They can be run in both directions on the same TCP connection to allow for peer-to-peer (P2P) settings.

The overall protocol – and each mini-protocol – is designed for a trustless setting where both sides need to guard against Denial-of-Service (DoS) attacks. For example, each mini-protocol uses consumer-driven control flow, so a node only requests more work when it is ready, rather than having work pushed upon it.

The protocol design is modular and evolvable: version negotiation is used to agree on the set of mini-protocols to use, which allows additional or updated mini-protocols to be added over time without causing compatibility issues.

**Node-to-client IPC**

The purpose of the node-to-client IPC protocol is to allow local applications to interact with the blockchain via the node. This includes applications such as wallet backends or blockchain explorers. The node-to-client protocol enables these applications to access the raw chain data and to query the current ledger state. It also provides the ability to submit new transactions to the system.

The node-to-client protocol uses the same design as the node-to-node protocol, but with a different set of mini-protocols, and local pipes rather than TCP connections. As such, it is a relatively low-level narrow interface that exposes only what the node can provide natively. For example, the node provides access to all the raw chain data but does not provide a way to query data on the chain. The job of providing data services and more convenient higher level APIs is delegated to dedicated clients, such as cardano-db-sync and the wallet backend.

The node-to-client protocol consists of three mini-protocols:

- **chain-sync**: used for following the chain and getting blocks
- **local-tx-submission**: used for submitting transactions
- **local-state-query**: used for querying the ledger state.

The node-to-client version of chain sync uses full blocks, rather than just block headers. This is why no separate block-fetch protocol is needed. The local-tx-submission protocol is like the node-to-node tx-submission protocol but simpler, and it returns the details of transaction validation failures. The local state query protocol provides query access to the current ledger state, which contains a lot of interesting data that is not directly reflected on the chain itself.

**info**

Read more about the [networking protocol design here](https://docs.cardano.org/about-cardano/explore-more/cardano-network/networking-protocol).



**Command line interface (CLI)**

The node’s CLI tool is the 'swiss army knife' of the system. It can do almost everything, but it is quite low level and not very convenient because it’s text-based and lacks a graphical user interface (GUI).

The CLI tool can:

- query the node for information
- submit transactions
- build and sign transactions
- manage cryptographic keys.

**Daedalus wallet**

Daedalus is a full node wallet that helps users to manage their ada, and can send and receive payments on the Cardano blockchain. Daedalus consists of a wallet frontend and a backend. The frontend is the graphical application that users see and interact with. The backend is a service process that monitors the state of the user’s wallet and does all the 'heavy lifting', such as coin selection, transaction construction, and submission. The backend interacts with a local node via the node-to-client IPC protocol, and interacts with the frontend via a HTTP API. The backend also provides a CLI that enables interaction with the wallet. The wallet backend can also be used on its own – without Daedalus – via its API. This is a convenient way for software developers to integrate Cardano with other applications and systems.

**Cardano DB Sync**

The Cardano node stores only the blockchain itself and the associated information needed to validate the blockchain. This design principle is about minimizing code complexity (and reducing computational cost and resource use) to keep the node's local interfaces as minimal as possible and to use external clients to provide a variety of convenient interfaces and extra functionality. In particular, the node does not provide a convenient query interface for historical information on the blockchain. This data service is provided by a separate component using a Structured Query Language (SQL) database.

Learn more about [Cardano DB Sync here](https://github.com/IntersectMBO/cardano-db-sync?tab=readme-ov-file#cardano-db-sync).

CARDANO ARCHITECTURE

## **CARDANO NETWORK**

The Cardano network is a technical infrastructure combining Cardano nodes and their interactions in one unified system. It consists of a collection of nodes that communicate with each other to maintain the distributed ledger. These nodes are the actors on Cardano that validate blocks, add blocks to the chain, and distribute transactions.

The networking layer is the driving force for delivering information exchange requirements, which includes new blocks diffusion and transaction information for establishing a better data flow. Cardano nodes maintain connections with peers that have been chosen via a custom peer selection process.

**info**

Read the following specifications for more details:

- [The Shelley networking protocol](https://ouroboros-network.cardano.intersectmbo.org/pdfs/network-spec/network-spec.pdf)
- [An introduction to the design of data diffusion and networking for Cardano Shelley](https://ouroboros-network.cardano.intersectmbo.org/pdfs/network-design/network-design.pdf).


**Data flow between and within nodes**

To understand how nodes communicate with each other, let’s suppose that node A is connected to node B. Then, the Ouroboros protocol schedules a node N to generate a new block in a given time slot. Depending on the location of nodes A, B, and N in the network topology, and whether a new block arrives first at A or B, node A can be either upstream or downstream of node B.

A set of mini-protocols is used to enable communication between different nodes. Each mini-protocol implements a basic information exchange requirement, such as informing peers of the latest block, sharing blocks as needed, or sharing new transactions around the Cardano network. For connection purposes, mini-protocols are determined by the version of the network protocol. For example, there are two protocol suites: node-to-node and node-to-client. The node-to-client protocol suite is used by wallets and chain consumers. Protocol suites use different sets of mini-protocols and the version is negotiated when a new connection is established using a specific protocol (protocols are described in the following sections).

Clients can also choose which node-to-client mini-protocols to use, but it is important to note that the node needs to be able to reply to all of them to support different use cases. For example, to communicate, node A runs its client-side instance of the chain-sync mini-protocol that talks with a server instance of the chain-sync mini-protocol at node B. Such a situation is similar to the functionality of other mini-protocols.

The scheme below illustrates how data flows within a node. Circles represent protocol threads and internal threads that are responsible for running the client and server processes within the respective mini-protocols.

![](https://docs.cardano.org/assets/images/node_data_flow-8161728b90a9190d24db7d0036f1db6e.jpg)


Two types of data flow exist:

1. Mini-protocols communicate with mini-protocols of other nodes by sending and receiving messages across a public network (internet); this flow is not covered within the scheme above.
2. Within a node, mini-protocols communicate with each other by reading from, and writing to, a shared mutable variable, which is represented by boxes in the scheme. Arrows indicate whether a thread has read or write access to the shared state.

**Addressing network complexities and constraints**

To design an efficient and robust networking architecture, a number of potential issues regarding complexity and constraints have been evaluated.

**Congestion control** is one such feature and is used to deal with system overload. Congestion control is vital to ensure that the system is robust enough while operating high workloads. Within the networking design, it is common that the number of transactions that occur can be higher than the number that can be actually processed for inclusion in the blockchain. Therefore, it is important to ensure that the increasing rate of transaction submission into a block does not decrease the performance of blockchain.

The actual node has a limit to the amount of data it can process. In particular, a node might have to share its processing power with other processes that run on the same machine or operating system instance. This means that a node can slow down and result in the system not being able to process all the available data from the network.

To address these issues, the congestion control feature has been designed to operate appropriately in such a situation and recover from transient conditions. In any case, a node must not exceed its memory limits so there must be defined memory limits, breaches of which are treated as protocol violations. These factors mean that the system will be able to meet performance goals.

**Real-time constraints and coordinated universal time** are other aspects that have been considered while designing the networking architecture. In Cardano, Ouroboros consensus protocols model the passage of physical time as an infinite sequence of time slots, assigning slot leaders to create a new block in those time slots. Choosing a slot time, however, might cause certain complexities in terms of the slot length, as it should be long enough for a new block to have a good chance to reach the next slot leader in time. Therefore, a chosen value for the slot length was initially set to 20 seconds in the Byron era. With [Ouroboros Praos](https://eprint.iacr.org/2017/573.pdf) implemented in the Shelley era, a slot length of 1 second is chosen but, on average, only 0.05 of slots will produce a block (and thus on average, there will be 20-second intervals between blocks). It is assumed that the clock skews between the local clocks of the nodes are small with respect to the slot length. Possible clock inaccuracies should still be taken into consideration, especially when dealing with time-stamped incoming blocks. It is important to differentiate whether there is a time difference or whether the node considers an adversarial behavior of another node.

**Utilizing mini-protocols**

Mini-protocols are used to communicate between multiple nodes while implementing information exchange requirements. A mini-protocol is a defined modular building block of the network protocol. Structuring the network protocol around mini-protocols helps to manage the overall complexity of the design while ensuring useful flexibility.

Mini-protocols describe both the initiator and the responder within the communication stream. The initiator is the dual element of the responder and vice versa. A node typically runs many instances of mini-protocols, which includes many instances of the same mini-protocol. Each mini-protocol instance of the node then communicates with the dual instance of the exact peer. All mini-protocols that communicate with the same peer share a single communication channel (pipe or socket). A multiplexer or de-multiplexer is used to multiplex respective protocols over that channel.

The set of mini-protocols that is used for connection between two participants of the system depends on the role of these participants, for instance, whether the node acts as a full node or a blockchain consumer (for example, a wallet).

It is also worth noting that the implementation of mini-protocols uses a generic framework for **state machines**. This framework uses correct-by-construction techniques to guarantee the implementation of several properties of the protocol. In particular, this technique assures that no deadlocks occur and communication is canceled in the following scenarios:

- when one side is expected to transmit the next message, and the other side is awaiting the message, and both sides agree that the protocol has been terminated
- when either side receives a message that is not expected according to the protocol.

All mini-protocols based on this framework include the following information in their description:

- an informal description of the protocol
- state machine states
- exchanged messages
- a transition graph of the state machine global view
- the client’s implementation of the protocol
- the server implementation of the protocol.

**Example mini-protocols**

This section outlines some examples of mini-protocols.

**Ping pong protocol**

This is a simple protocol for testing that a client can use to check that the server is responsive. The ping pong protocol is very simple because the messages do not carry any data and the ping pong client, as well as the ping pong server, do not access the internal state of the node.

**Request response protocol**

The request response protocol is polymorphic in the request and response data that is being transmitted. This means that there are different possible applications of this protocol and the application of the protocol determines the types of requests sent and responses received.

**Chain synchronization protocol**

The chain synchronization protocol is used by a blockchain consumer to replicate the producer’s blockchain locally. A node communicates with several upstream and downstream nodes and runs an independent client instance and an independent server instance for each node with which it communicates.

The chain synchronization protocol is polymorphic. The node-to-client protocol uses an instance of the chain synchronization protocol that transfers full blocks, while the node-to-node instance only transfers block headers. In the node-to-node scenario, the block fetch protocol is used to transfer full blocks.

**Block fetch protocol**

The block-fetching protocol enables a node to download a range of blocks.

**Local transaction submission mini-protocol**

The local transaction submission mini-protocol is used by local clients, for example, wallets or CLI tools, to submit transactions to a local node. The protocol is not used to forward transactions from one core node to another. The protocol follows a simple request-response pattern:

1. the client sends a request with a single transaction
2. the server either accepts the transaction (returning a confirmation), or rejects it (returning the reason).

**Node-to-node transaction submission protocol**

The node-to-node transaction submission protocol is used to transfer transactions between full nodes. The protocol follows a pull-based strategy where the initiator asks for new transactions and the responder replies with transactions. It is suitable for a trustless setting where both sides need to guard against resource consumption attacks from the other side. The implementation of the node-to-node transaction mini-protocol is based on a generic mini-protocol framework (the same as for all other mini-protocols). For technical reasons, the roles of the initiator and the responder are reversed in this case compared to the way other mini-protocols are implemented in the framework. In other words, the server is the initiator who requests new transactions, and the client is the responder who replies with transactions.

**Handshake mini-protocol**

The handshake mini-protocol is used to negotiate the protocol version and the protocol parameters that are used by the client and the server. It is used first when a new connection is initialized and consists of a single request from the client and a single reply from the server. The handshake mini-protocol is a generic protocol that can negotiate any kind of protocol parameters. It assumes that protocol parameters can be encoded to, and decoded from Concise Binary Object Representation (CBOR) terms. A node that runs the handshake protocol must instantiate it with the set of supported protocol versions and callback functions for handling the protocol parameters. These callback functions are specific to the supported protocol versions.

CARDANO NETWORK

## **NETWORKING PROTOCOL DESIGN OVERVIEW**

Transmission Control Protocols (TCP) and Internet Protocols (IP) form a protocol suite universally deployed on the network. TCP/IP enables a reliable bidirectional communication channel between systems on the internet.

The ordered delivery of Cardano node communication protocols is guaranteed by the TCP/IP protocol.

Operating systems limit the number of concurrent connections. By default, Linux, for example, can open 1,024 connections per process, whereas macOS limits this number to 256. To avoid excessive use of resources and enable reliable means for connection establishment, Cardano uses a multiplexer.

**Connection management**

The network layer handles a range of specific tasks besides the exchange of block and transaction information required by the Ouroboros protocol.

Generally, connection management implementation includes the performance of the following tasks:

- opening a socket and/or acquiring resources from the OS
- negotiating the protocol version with the handshake mini-protocol
- spawning the thread that runs the multiplexer (which can be instructed to start/stop various mini-protocols)
- discovering and classifying exceptions thrown by mini-protocols or the multiplexer itself
- shutting down the connection in case of an error
- handling a shutdown request from the peer
- shutting down the threads that run mini-protocols
- closing a socket.

**Multiplexing**

The multiplexing layer acts as a central crossing between [mini-protocols](https://docs.cardano.org/about-cardano/explore-more/cardano-network#utilizing-mini-protocols) and the network channel. It runs several mini-protocols in parallel in a single channel ‒ TCP connection, for example.

Figure 1 reflects how data flows between two nodes, each running three mini-protocols using a multiplexer (MUX) and a de-multiplexer (DEMUX).

![](https://docs.cardano.org/assets/images/connection-manager-db2bcf7812f11900477fdfc232d278cb.png)

Figure 1. Data flow between the nodes through multiplexing

Data transmitted between nodes passes through the MUX/DEMUX of the nodes. There is a fixed pairing of mini-protocol instances, which means that each instance only communicates with its dual instance (an initiator and a responder side).

The implementation of the mini-protocol also handles serialization and de-serialization of its messages. Mini-protocols write chunks of bytes to the MUX and read chunks of bytes from the DEMUX. The MUX reads the data from mini-protocols, splits it into segments, adds a segment header, and transmits the segments to the DEMUX of its peer. The DEMUX uses the segment’s headers to reassemble byte streams for the mini-protocols on its side. The multiplexing protocol (see the note below) itself is completely agnostic to the structure of the multiplexed data.

![](https://i.imgur.com/ldE27MT.png)

**Data segments of the multiplexing protocol**

Multiplexing data segments include the following details:

- **Transmission time** ‒ a timestamp based on the lower 32 bits of the sender’s monotonic clock with a resolution of one microsecond
- **Mini-protocol ID** ‒ the unique ID of the mini-protocol
- **Payload length** ‒ the size of the segment payload in bytes; the maximum payload length supported by the multiplexing wire format is 216 − 1. Note that an instance of the protocol can choose a smaller limit for the size of segments it transmits
- **Mode** ‒ the single bit M (the mode) is used to distinguish the dual instances of a mini-protocol. The mode is set to 0 in segments from the initiator (the side that initially has agency), and it is set to 1 in segments from the responder.

**Cardano node communication protocols**

Cardano uses inter-process communication (IPC) protocols to allow for the exchange of blocks and transactions between nodes, and to allow local applications to interact with the blockchain via the node.

**Node-to-node IPC overview**

The Node-to-node (NtN) protocol transfers transactions between full nodes. NtN includes three mini-protocols (chain-sync, block-fetch, and tx-submission), which are multiplexed over a single TCP channel using a network-mux package.

The following diagram represents the NtN operational flow:

![](https://docs.cardano.org/assets/images/node-to-node-ipc-b07831e63f18e78ab58919dd6bf90bfb.png)


NtN follows a pull-based strategy, where the initiator node queries for new transactions and the responder node replies with the transactions if any exist. This protocol perfectly suits a trustless setting where both sides need to be protected against resource consumption attacks from the other side.

**NtN mini-protocols explained**

A brief explanation of the NtN mini-protocols:

- **chain-sync**: a protocol that allows a node to reconstruct a chain of an upstream node
- **block-fetch**: a protocol that allows a node to download block bodies from various peers
- **tx-submission**: a protocol that allows submission of transactions. The implementation of this protocol is based on a generic mini protocol framework, with one peculiarity: the roles of the initiator and the responder are reversed. The Server is the initiator that asks for new transactions, and the Client is the responder that replies with the transactions. This role reversal was designed thus for technical reasons.

To ensure optimal networking service, the team has also implemented an additional protocol:

- **keep-alive**: a protocol that ensures continuous connection between nodes and minimizes performance faults.

**Node-to-client IPC overview**

Node-to-client (NtC) is a connection between a full node and a client that consumes data but does not take part in the Ouroboros protocol (a wallet, for example.)

The purpose of the NtC IPC protocol is to allow local applications to interact with the blockchain via the node. This includes applications such as wallet backends or blockchain explorers. The NtC protocol enables these applications to access the raw chain data and to query the current ledger state, and it also provides the ability to submit new transactions to the system.

The NtC protocol uses the same design as the node-to-node (NtN) protocol, but with a different set of mini-protocols, and using local pipes rather than TCP connections. As such, it is a relatively low-level and narrow interface that exposes only what the node can provide natively. For example, the node provides access to all the raw chain data but does not provide a way to query data on the chain. The job of providing data services and more convenient higher-level APIs is delegated to dedicated clients, such as cardano-db-sync and the wallet backend.

**NtC mini-protocols**

The NtC protocol consists of three mini-protocols:

- **chain-sync** - used for following the chain and getting blocks
- **local-tx-submission** - used for submitting transactions
- **local-state-query** - used for querying the ledger state.

The NtC version of chain-sync uses full blocks, rather than just block headers. This is why no separate block-fetch protocol is needed. The local-tx-submission protocol is like the NtN tx-submission protocol but simpler, and it returns the details of transaction validation failures. The local-state-query protocol provides query access to the current ledger state, which contains a lot of interesting data that is not directly reflected on the chain itself.

**How NtC works**

In NtC, the node runs the producer side of the chain-sync protocol only, and the client runs the consumer side only.

This table shows which mini-protocols are enabled for NtC communication:

![](data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAX4AAACWCAIAAABW2HTwAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAA+6SURBVHhe7Z1NesM2r4W7w+znDr+Jl5KlZCldRi9AgviRIDm0IcuOzjtoIBIESAI6SZs+zj//AQDAy4H0AABOANIDADgBSA8A4AQgPQCAE4D0AABOANIDADgBSA8A4AQgPQCAE9iTnn8AAKAC0RTHHekR64WckhSAFHRjCZAeAOZAN5YA6QFgDnRjCZAeAOZAN5YA6QFgDnRjCZAeAOZAN5YA6QFgDnRjCZAeAOZAN5YA6QFgDnRjCUXS83P755/bz7ACX9//NpdnoDBiOf79/lqF72N9K2zvJbc9vxn3Ng7OZbsbY9WowTbKKG3auGyl6exiOZ6VHvdCJxV5gDRpe0MJF3yU9AzpqQt3b+PgXDa7cXSeYNITeoMf4tM1i51eY6H0EOuRadKkXOzbLXxnoVQ88my6hyg4pgDpeW82u5G+D/oeoI5YS8+6uHWN81m8QHoK3qRt6fmx+rbcbaBvQPM243YbP+OO3a13SvRF3zTFjMgtFWvaWMEDne5izxJx6dDhlB1LvPbkEb8KvBdUKrEcvWg/XEzXYFzG0BuorUIXIpajVnryd3yKNClXkcJKgQmy+nPPplXute87aHY302113x7QfJtlHWMrN8KlDmxKDDMzT+cI3pDNbuSiueJRbc2SKvsuuTjpNX6U9HD4Fp2+cqU1mzZBeJVtM+m22NdGh0uIEBfqgxtNHWIM4fee4G3YlR5nUT2ljFbmUPBr8wLpKXiTdqVHvo5C6wY0b9jAaqf8pcM+cbM+hY5GF41ngXMHmzdyzzgK3g1qFbEcvmhcSLLpi4xY7VFbJb3GUunhy169c5NsFrvFbYb+92bdgFY5lHtnp0zc7XAJEeJCfXCjqUOMIfzeE7wNd6VHSmm/AnFlXhf3quU+Wnr4Xp+/2H3p6UlWZdaShtpu7rTTQ7mwMVTHVppLCJc6+CDqkHkusoE3Y7MbfdG4sOueHA/25BrkYqTX+Kz0BCqulcKI5eCiSXBfd92KDoauiDtdba756m/DxqoQgeGB6DJOLs+Zg78cG117rrKBt4JKJZYjb5ExEnrD1zz2x6Wgs4vlmJeeg3ldUrz24B6nvAJ/D0hPBNID7gHpKQHSE4H0gHtAekqA9AAwB7qxBEgPAHOgG0uA9AAwB7qxBEgPAHOgG0uA9AAwB7qxBEgPAHOgG0t4RHoAAOB5RFMcd6RHrBdySlIAUtCNJUB6AJgD3VgCpAeAOdCNJUB6AJgD3VgCpAeAOdCNJUB6AJgD3VgCpAeAOdCNJUB6AJgD3VgCpAeAOdCNJRRLz49+CH8pO0nzj7md+cSv9DOad/AZpxb+jlM+rKw06SMXukw+G+OVUNnFUtpnLy/2y2MvL+QHkVzjw9LT7v+Q295KGivuan2Y9DTdMe+ptb/jERV4bBsu052kc3ua3Y1Ft5UHXGwZaTcur+idD/AepNf4gPTwTfc/5fD7Fv09edL1C6H1nntXJlh2FCc6v8Me6/PfX9LcdT7+1tnKx2Mcz84rMC7pnbf/LpRJzw9f9FFvfJp0L1mf+6YGaFgX8MRARrVNmnEba/LQbX3SVLTWFujDZkSe6Kxi6bGaoX+XRx3dCfqQDfRni60Zs1Dqxk6aNMRfBhSPfPM62g7sZ9pc2IqzyVGGLDGNcbTb9xgZC94D2pBYC9qm6eD+jPl12dh7He2V0OHFcjwgPZ1453WkSUehM3ob99lmmylLbKsap/WDbJ/t/CQ9dMM70ILxaGYe0VJ7c6BDPdHiDGy4E4jJsc0cAW00DdWs5T5c0Gx6y9zIpeiuaJYZdvOzOBaFrRGc7ZHnHaCdibWibfXLrsXfUTjmcHDm1Uiv8W9Ij24kdWxNMhqhT3u/+ydhj4YsodUab6xMI94JnfuNSC3rarXPozTXPpqG8qPBQWC/1TRblolc+nDYQLIbXfZz+/r++f5iW8csuq30MWz+PUi7UeC9us3qGRvjuvhwbviipNf4GdKzlyzMuTZuRW/Y9yaddn4WwK3IcrGfLCJPdqGRLHOMOAYT1E8Nxi1qKTtjOp3lE8poHsqNmsmzHffdO5secKgQvz3JbhQZo+WLf8qcRe9jZi2jnw8dWqwEv/Gt64oT5n0t6OhiOT5DepJsOhKmtBv8qNk67btmHbtBLotRt6hN0rd080gjboQe5H4+0oDHuoPNej+z81BudJjeMZnu1nIfhE8bHwa0UH/eIY/2H+LEyaLbSh/DbeQt2H0F4uE3rstgh32PP8snS0+vsxXOlTFsRLvBObSVi373XbN1kpjRRyTapJ/OI/rY3qOjs2ELw28Zsds2ypZlGaNpKD86zLbIIi2no+mSLU2J4aFh+jmq+1AQYvhYSF5q2dfz7wEdT6wEv3Eiu65wHr6WNzrbC0mv8WOkh+CUA0u9rO7oBjYbtx8dXRvEzkl8xoVPC+8abzNic2yskqjfxhl8ek3V47G3TrefMSTAfih6MAfdmbsh7+lddJqxxPyrNDcxaMtk3IUOu+uh6cE7uPm3gHYoVkI4WaOfqaETbuydTvZS6OxiOR6WnqM4JekD8EsS+w78PT6lG98cSE8hUJ5LAOkpAdJTRP/3DQjPBYD0lADpAWAOdGMJkB4A5kA3lvDB0rP+XQKTj+4xvwJcGkhPCZAeSA+YA9JTAqQH0gPmgPSU8OnSo5+rMMTDC0n/rRPj/78t9uh0P1vR/MP/3MZc9v/5AjnUE2KBJ0iv8XOkx8tHlwgTkoWkmClaMkzxczNt7bCdCQBxyivw90iv8XOkR0VBhUMFRw1mPAR9EVoc/xkrBI/ZagAckJ4SPlx6TB3oKUhPFJkxGtd0eMx/woTQhjvLFeDSUEeIBZ4gvcYPlJ4nf+rhubDA4CXZOLgqkJ4SPlx6ho6w3U0TELOcenjtEYdkRVAoGl2qFbgykJ4SPlx6nvsN11KsvEaZF4QHBKglxAJPkF7jZ0gPAKeAbiwB0gPAHOjGEiA9AMyBbiwB0gPAHOjGEiA9AMyBbiwB0gPAHOjGEiA9AMyBbiwB0gPAHOjGEiA9AMyBbizhEekBAIDnEU1x3JEesV7IKUkBSEE3lgDpAWAOdGMJkB4A5kA3lgDpAWAOdGMJkB4A5kA3lgDpAWAOdGMJkB4A5kA3lgDpAWAOdGMJVdJz7OeJUlSxHOEDlKtYB7VPWfXsJQ4rxoe1buE/0HWC2WWHXNZFoaqKpbT2X9SDx3Dl2yTXOC89vq/be/fAu7RLustD3qadoL/Ltzj/XYmA9Hwcv+rGB+t6IUqkJ3BEk3+Q9CxbjlfttSBa9OPYeAW4kqM/UNX7/EXp4YmOn+Zu6FhP2Nhw3dn9cqqlGQPtgQOrsSQst9ZsVv53Nfyo7lQ8LEBL2BmrzTvsL+w1zPbp222MayCQQBck1oJRlFBqVwy71nWBrgcdXizHM9LDl1p+nWnSWGBl1F9eMTPF10zyHOt10UZQJpkaQ2GKHwTvHnxsk2x5u7u00W72cJkDj/FsnzOT5kYiNS37WCmRnbkeBhl0U2KtaAXyf0Tb7j2WYDg482qk1/iw9LSuPeAq06Suqg57s9xD7mq0fbdVO57pVFtJJGvGlHuj1ct2yZYOq48/hbMthj/ZMjnP6WohjWwPG5sDGXS7Yq1Z1IMf7SrpYrUGuOH0Gh+TnuwtKCJNGl6XQRwcL1H+MrUNN+wvrqdBOxtTHHvn1C0Jhw7LbUNxa/TUfPyosy3GYlAI8YXuNVaGXViUjc2BDLpUsRLi5bk6CDK3KtD1oKOL5XhAelr/H3aJadL4Fg1C6cdD6uo91c6DNjaD+J+w6Xnhk+7BcptFqI8fdbbFCMsEHlsk5wXNL41sDxubAxkbr0AnXh7f6+5VaoGuR430JE1fyoT0uNq7snrf4WCbbo7dcyMok0yNUG6KhyQp00L3R8vnnZrphrvJ1gjibMszBr0jz5Id9knzzV6vDHtbrtGYYE3ajYPF5fmL5Sm20wJdj/QaZ6WH7zRS3LkUUSxHe3MCktUmfFFtk2NU/b6+f0Y3hLaILKdawHHQFmuVn3ArbLz98qp7c5T9vxzvbNuCDfpsfokg+W2lX6Gb89MhOVhDFydWwvryXDF0Yl2g60FnF8sxKz2Hc0pSAFLQjSVAegCYA91YAqQHgDnQjSVAegCYA91YAqQHgDnQjSVAegCYA91YAqQHgDnQjSVAegCYA91YAqQHgDnQjSU8Ij0AAPA8oimOO9Ij1gs5JSkAKejGEiA9AMyBbiwB0gPAHOjGEiA9AMyBbiwB0gPAHOjGEiA9AMyBbiwB0gPAHOjGEiA9AMyBbiwB0gPAHOjGEqqkx31C8AEf60tRxXKEzxOuIgR1hzriWD78ZT+h9wOhcomltM9aXnQIj6Gs2yTX+ID0uM/CPuTC06QHS08TBusmd8S7iX+zs9isLVn5YcAh/KobXb+AlBrp8Rxx52dIz/IcPNOf7ya+vzMOvvBAr34KG6+ArymKeZ9y6Tnk0uekhyc6fpo31rHt2dhwtaAtSnISXSMrVjGWDsl22GUVWgfDwYKr5fJDX7cbZ/j63//ZsjauD6ASumuxFoxahQJmRXNj1y0SHV4sx4PSI/d5wGWmSWOBlVH/IB7O10zyHOt1kQ/a1ndCHu+TxVg6jJYz0w0ausovz6M6k+ddApdWQ4Ba6MLFWsHV8H+MNi8a6sSk1/ig9HTa7RffZpo0vKEKp9e3ejzkrgbP91WZZ5tlJG4ezWJ4h9BaPN48wiYHuirEV1dd3NC4IZQftbSglrQbBa6Su/q8aFyzdf2vRnqNT0lPfHNqSJOmeeLgeC/H10hrkwZ/o+oO25tv3iufLIZzsOlBG0/3o4M+vo2yEdFhC0VPvJIiaABQDV29WAmreiyQOTdh3teCji6W4znpiZdfQpo0vKFKyD4eUlfvqbZ60shixdpnI8bCYZWYYN8xTt68LF3uhnl0pHLYskbL9wPlOZLdVyDWY6NoBjvse/xZaqTH3fchdzkhPW4vbivedzjw1z7WHLunOfK0O0geLI3hHdx2fIgYvtmmRS6qd1tG7TZbIyYjsfwQqIWuV6yERT2yovkxHlT7WqTXOC09481rHHCTFFUsh0spSMltwm9F3klijKpf+zmhD4e2CBlcLBnndFmM4BCiuBhECN+J64nbN5naynYGHVu0uviEEVAL3a9YCat6ZEXzY7EnLgSdXSzHA9JzLKckPYF/f36e7kOWLSjPkVylGw8G0vPHgPIcDrqxBEjPH6L/exqE52DQjSVAegCYA91YAqQHgDnQjSVAegCYA91YAqQHgDnQjSVAegCYA91YAqQHgDnQjSU8Ij0AAPA8oikOiDoA4AQgPQCAE4D0AABOANIDADgBSA8A4AQgPQCAE4D0AABOANIDADgBSA8A4AQgPQCAl/Pff/8PCdfbJhYimKAAAAAASUVORK5CYII=)

NETWORKING PROTOCOL DESIGN OVERVIEW

## **PEER-TO-PEER (P2P) NETWORKING**

Cardano nodes and the interactions between them are combined together within a networking layer, which distributes information about transactions and block creation among all active nodes. In this way, the system validates and adds blocks to the chain and also verifies transactions. A distributed network of nodes must keep communication delays to a minimum, and be resilient enough to cope with failures or capacity constraints.

In the Byron federated system, nodes were connected by a static configuration that was defined in a topology file. Since the introduction of Shelley, the system has been functioning in a hybrid mode. Moving from the federated state of network connectivity to the hybrid one, the teams delivered a manually constructed P2P network of SPO relay nodes. This means that SPO block-producing nodes can connect to both trusted relay nodes and other SPO-run relay nodes. Hybrid connectivity is not automated, however, it enables the exchange of block and transaction information without relying on trusted relays only.

A trusted relay is the one that the SPO, wallet, or exchange accessing the network ‘trusts’. Though this role has mostly been performed by IOG, other entities, such as the Cardano Foundation, a wallet, or exchanges can also run trusted relays. Block-producing nodes can connect to any relays they deem trustable.

1 . Federated: introduced in the Byron development phase in 2017, trusted core and relay nodes maintained the network and connected users, wallets, and exchanges.

![](https://ucarecdn.com/dcd6bf70-5c73-4fbc-8683-1f199e8f554b/) 

2 . Hybrid: since the Shelley development phase in 2020, block-producing nodes send and receive communications through trusted relays and/or a manual community-developed and managed tool called the topology updater.

![](https://ucarecdn.com/3e7d4b86-040c-416a-9eda-076e8ffe41c9/)

3 . Dynamic P2P: provides automation and resilience to optimize network performance. SPO relays can automatically connect to each other through self-discovery and optimization.

![](https://ucarecdn.com/48167b72-9192-42e0-a367-5f3e40612388/)

To ensure efficient communication between nodes, it is desirable to enable automated connections of SPO relays to each other, so that less static configuration is needed. Dynamic P2P has been gradually enabled since the node [v.1.35.6](https://github.com/input-output-hk/cardano-node/releases/tag/1.35.6) release. For more details, see [this blog post](https://iohk.io/en/blog/posts/2023/03/16/dynamic-p2p-is-coming-to-cardano/).

With the deployment of Dynamic P2P, networking keeps evolving with additions such as Ouroboros Genesis and peer sharing:

4 . Ouroboros Genesis: in development. Anyone running their own node or Daedalus wallet will connect to a fully decentralized and self-organized network. Genesis enables secure node bootstrapping and the removal of trusted relays. Read this blog post to learn more about the [transition to Genesis](https://iohk.io/en/blog/posts/2024/03/14/approaching-full-p2p-node-operations/).

![](https://ucarecdn.com/9ce084f4-28d6-4557-919e-d60a18ded168/)

5 . Peer sharing: in development. Peer sharing will facilitate the discovery of potential peers that are not registered on the chain within the overall Cardano node network. This phase will also allow anyone to contribute to running the network, rather than just using resources from SPOs.

![](https://ucarecdn.com/9359a2da-a6ed-4edd-89b4-508ae96145e7/)

**Dynamic P2P capabilities**

The network stack undergoes a number of improvements to achieve the desired network resilience. These improvements do not require a protocol change, but rather enable automated peer selection and communication between peers and nodes.

The P2P networking is enabled due to the use of the following components:

- **Outbound governor** (formerly known as P2P governor) ‒ manages the automatic initiation of outbound connections between peers and classifies them as cold, warm, or hot (known, ready, or in use). The governor establishes a connectivity map of the local network. One part of the governor is the churn governor, which optimizes the network graph by dropping the 20% lowest performing peers.
- **Server** ‒ accepts connections. There is a soft and a hard limit on the number of connections that influence the speed of connection acceptance.
- **Inbound protocol governor** ‒ runs and governs inbound network ‘mini-protocols’ on an accepted connection.
- **Connection manager** ‒ tracks the state of each network connection: each one might be used as a warm or hot outbound connection or used by the inbound side. Warm connections only keep connectivity while hot ones take an active part in the consensus protocol.

Next, we take a closer look at how the outbound governor works to ensure automated connectivity between peer nodes on the network.

**Outbound governor functionality**

The Cardano network consists of multiple peer nodes. Some peer nodes are more active than others, some have established connections, and some should be promoted to ensure the best system performance. Each block-producing node maintains a set of peers mapped into three categories:

- cold peers ‒ existing peers without an established network connection
- warm peers ‒ peers with an established bearer connection, which is only used for network measurements without implementing any of the node-to-node mini-protocols
- hot peers ‒ peers that have a connection, which is being used by all three node-to-node mini-protocols.

Newly discovered peers are initially added to the cold peer set. The outbound governor is then responsible for peer connection management: it defines which peers are beneficial for connection purposes, and which should be promoted or demoted between cold, warm, or hot sets.

The primary goal of the outbound governor is to maintain the target number of cold, warm, and hot peers. This builds and maintains a connectivity map of the local part of the network, and simplifies the process of connection definitions by handling them automatically.

To establish connectivity between nodes, the outbound governor engages in the following activities:

- promotion of cold peers to warm peers
- demotion of warm peers to cold peers
- promotion of warm peers to hot peers
- demotion of hot peers to warm peers.

The outbound governor needs to establish and maintain:

- a target number of cold peers (for example, 100)
- a target number of hot peers (for example, between 2–20)
- a target number of warm peers (for example, between 10–50)
- a set of warm peers that are sufficiently diverse in terms of hop distance and geographic locations
- a target churn frequency for hot or warm changes
- a target churn frequency for warm or cold changes
- a target churn frequency for cold or unknown changes.

![](https://ucarecdn.com/b6bae79e-5960-4d4e-9f6c-993a100b01c3/)

Using 2–20 hot peers is cost-efficient, as peers exchange only their block headers. The block body, in turn, is typically requested only once, and it tends to follow the shortest path through the connectivity graph.

The purpose of warm peers is to provide access to those peers that can be quickly promoted to hot ones (in case any of the hot peers fail), and also provide candidates for the churn of hot peers.

The policy for selecting which warm peers to promote to hot relies on the upstream measurements. The purpose of a degree of churn between cold and warm peers is, in part, to discover the network distance between more peers and to allow potentially better warm peers to take over from existing hot peers. This enables further optimization and adjustments. Maintaining diversity in hop distances contributes to better block distribution times across the globally distributed network.

Overall, this approach follows a common pattern for probabilistic search or optimization that uses a balance of local optimization with some elements of higher-order disruption to avoid becoming trapped in a poor local optimum.

Peers maintain a limited set of information, which is based on their previous direct interactions. Cold peers, for instance, may not maintain any data, as they have not established interactions yet. Such data can be compared to a ‘reputation’ property, however, these details are purely local and are not shared among other nodes. Local peer reputation information is also updated when peer connections fail. The network does not maintain negative peer information for extended periods of time: to bound resources and because of the simplicity of [Sybil attacks](https://iohk.io/en/blog/posts/2018/10/29/preventing-sybil-attacks/).

The implementation classifies exceptions that cause connection failures into three classes:

- internal node exceptions (for example, local disk corruption)
- network failures (for example, dropped TCP connections)
- adversarial behavior (for example, a protocol violation detected by the typed-protocols layer or by the consensus layer).

In the case of adversarial behavior, the peer can be immediately demoted from the hot, warm, or cold sets.

PEER-TO-PEER (P2P) NETWORKING

## **CARDANO FEE STRUCTURE**

[Cardano](https://cardano.org/) uses a transaction fee system that covers the processing and long-term storage cost of transactions.

The Cardano environment is unique in the way it handles fees, as fees do not go directly to the block producer. Instead, they are pooled and then distributed to all pools that created blocks during an epoch.

Currently, there are no fees for the memory cost of tracking the accumulated chain state, in particular, UTXO.

**Preventing economic attacks**

The Shelley hard fork event meant that the Cardano blockchain moved from federated to a fully decentralized environment, which might increase the incentive for malicious actors to perpetrate economic attacks.

An economic attack might occur where the costs incurred by the operators of a system are not covered by fees on the users of a given system. These situations allow users to impose costs on operators without paying the full cost themselves, which could potentially lead to a severe drop in operator participation, and might ultimately lead to the collapse of the system itself.

To prevent this situation from arising, it is crucially important to address both the existing unaccounted operator costs and the new costs.

Cardano's fee structure is quite simple.

Fees are constructed around two constants (a and b). The formula for calculating minimal fees for a transaction (tx) is a * size(tx) + b, where:

- a/b are protocol parameters
- size(tx) is the transaction size in bytes.

**Protocol parameters (a and b)**

Protocol parameters are values that can be altered by Cardano's update system to react and adapt to changes in transaction volume, hardware prices, and ada valuation. Changing these parameters constitutes a hard fork, since it influences which transactions are accepted by the system.

**Protocol parameter a**

Parameter a reflects the dependence of the transaction cost on the size of the transaction. The larger the transaction, the more resources are needed to store and process it.

**Protocol parameter b**

The value of b is a payable fee, regardless of the size of the transaction. This parameter was primarily introduced to prevent Distributed-Denial-of-Service (DDoS) attacks. b makes such attacks prohibitively expensive, and eliminates the possibility of an attacker generating millions of small transactions to flood and crash the system.

**Protocol parameter x**

x represents the size of the transaction in bytes.

CARDANO FEE STRUCTURE

## **CARDANO MONETARY POLICY**

Cardano achieves true decentralization with the Voltaire development phase, which includes decentralized voting and treasury systems to empower the community to influence Cardano's evolution, and provide a funding mechanism to transform Cardano into a self-funded, self-sustainable environment.

Decentralization does come with its own set of challenges, as factors such as security, performance, stability, sustainability, fairness, and crucially, economic viability come into play.

Maintaining, developing, and improving a blockchain project requires ongoing monetary support. With Voltaire, the treasury performs this function, and funding for new features, improvements, etc. is allocated through a decentralized voting system.

**Stake pools**

The principles of decentralization and fairness drive Cardano's development. Cardano offers equal opportunities to anyone who wishes to become part of the network by running a stake pool. But the very freedom to participate opens up the possibility of unfair advantage posed by larger stake pool operators. This presents the challenge of maintaining the integrity of the chain while incentivizing people to create pools and support the chain.

**Incentives mechanism**

Cardano's monetary expansion relies on a long-term commitment by stake pool operators to provide ongoing support for the chain. This commitment requires a solid and stable incentivization mechanism for the operators, so this mechanism must ensure that the incentive system does not significantly change in time in a way that might adversely affect the operators’ income.

Cardano's incentive system for stake pool operators is designed to balance k fully saturated pools (where k is the number of desired pools), so this equilibrium means that rewards will be optimal for everybody when all stake is delegated uniformly to the k most attractive pools.

**Monetary policy**

Cardano's monetary policy addresses two issues:

- the necessity to offer rewards for people who participate in the network
- funding the treasury.

**Rewards**

The expansion and future improvement of the Cardano blockchain will be greatly influenced by its community, who need to be incentivized through rewards to participate in Cardano’s development.

Staking rewards for delegators and stake pool operators come from two sources:

- Transaction fees - fees from every transaction from all blocks produced during every epoch go into a virtual 'pot'. A fixed percentage (ρ) of the remaining ada reserves is added to that pot.
- Monetary expansion - a certain percentage (τ) of the pot is sent to the treasury, and the rest is used as epoch rewards.

This system is designed to ensure that the portion of rewards taken from the reserves is high at the beginning when transaction numbers are still relatively low. This incentivizes early adopters to move quickly to benefit from high initial rewards. Over time, and as the number of transactions increases, additional fees will compensate for smaller reserves.

This mechanism also ensures that available rewards are predictable and do not vary dramatically. Instead, rewards change gradually. The fixed percentage taken from remaining reserves every epoch guarantees a smooth exponential decline.

**Funding the treasury**

The treasury's goal is the provision of funds to develop Cardano activities through a voting process. This necessitates a process whereby funds are regularly sent to the treasury to ensure that funds are always available.

**Policy rationale for the ρ and τ values**

A lot of thought was put into determining what the values for ρ (fixed percentage) and τ (funds going into the treasury) should be.

**Calculating ρ**

While searching for the right ρ value, the team faced a quandary: A higher value would mean higher rewards for everybody initially, and the treasury would fill faster. But higher values of ρ would also mean that the reserves would deplete faster. Paying high rewards and incentivizing early adopters is a crucial consideration, but so is to offer a long-term perspective for all stakeholders. Therefore, the solution to this quandary requires a tradeoff between these two issues.

Adopting an exponential decay approach to prevent Cardano’s reserve from running out makes sense in this situation.

Calculating the 'reserve half life' (that is, the time that it takes for half of the reserve to be used up) visualizes the impact of choosing a specific value of ρ over another. This was the subject of much discussion, and eventually, the value assigned was 0.3%. The reason why is that mathematical projections showed that a ρ (the fixed percentage of ada going into the virtual pot every epoch) value of 0.3% would mean a reserve half-life of four to five years. In simple terms, just half of the remaining reserve would be used every four to five years.

**Choosing τ**

Determining the right value for τ (the percentage of unclaimed rewards automatically going to the reserves every epoch) was equally challenging. Following discussions, deliberations, and projections, the τ value was set at a fixed rate of 20%.

This rate applies to both the per-epoch monetary expansion and the fees that the blockchain charges for each transaction. The treasury amount is deducted before any other rewards are allocated. The remaining per-epoch monetary expansion and fees may be allocated to stake pools based on the provided formula.

It is important to note that the rewards given to stake pools may be reduced under certain conditions, such as when pools are not saturated, not fully pledged, or fail to produce their allocated blocks. Any unclaimed rewards remain in the reserves for future allocation. This explains the slightly varying difference in the percentage of treasury allocations.

CARDANO MONETARY POLICY

## **TIME HANDLING ON CARDANO**

Time is necessarily relative to every participant in the blockchain system and is critically important to support and maintain the safety properties of the Ouroboros consensus protocol. Minted blocks are expected to be propagated to all nodes in the system in a timely manner, so time requires the construction of a globally acceptable representation for consensus to be reached.

**Time-handling with Ouroboros**

Locally, a node computes the passing of time using a 'wall-clock' system. The code for this clock is complicated because the slot length can vary at a hard fork boundary, so the time must be computed carefully taking this into account.

The code performs four steps to get the currentSlot:

1. Waits for some delay corresponding to either the time left till the next slot, or an arbitrary 60s delay if the current slot is unknown, which happens when syncing
2. Gets current system time and translates it to a slot number according to slot length for the current era
3. If the new slot is greater than the previous one, it 'ticks' a new current slot
4. If the above is not true, it either waits a bit longer or reports an error if current time jumped too far back.

The local currentSlot is compared to the slot reported by the tip of the node's ledger. If the latter is older, it is ignored because this means that the node is synchronizing its state with the chain.

Since the slot length can change at a hard fork, consensus can only convert slots to time up to a fixed point in the future – the 'stability window' – in which no hard forks can happen. In practice, the stability window is essential as it provides a measure of time needed to guarantee transaction finality and chain state immutability. During the stability window, the network must produce at least k blocks, where k is the number of blocks after which the chain becomes immutable. The stability window can take up to 3k/f, which is 36 hours with current parameters, or roughly a day.

**Current challenges**

There is a fundamental physical limitation to the speed at which information can travel: the speed of light. This implies that synchronizing time over a network of nodes takes time.

Network Time Protocol ([NTP](https://www.newyorker.com/tech/annals-of-technology/the-thorny-problem-of-keeping-the-internets-time)) exists to provide a synchronization mechanism, which addresses time limitations and measurement differences. On the other hand, NTP does not guarantee a monotonic increase: time can sometimes jump back and forth a few seconds or even hours. Existing systems providing accurate, precise, and reliable clocks at a global scale are centralized, like the global clock provided by [Spanner](https://research.google/pubs/pub39966/), for example.

Currently, on Cardano:

1. Network parameters are set in such a way that the granularity of observable time intervals (eg, block time) on the chain is 20s, which is equal to the slot length (1s) divided by the block coefficient f (the expected block frequency, 0.05). These parameters are unlikely to change in the short-term future.
2. These 20 seconds have been determined as the optimum budget to guarantee the protocol's safety, given the constraints to replicate new transactions and blocks across the network (300ms TCP delay across the globe, with thousands of nodes). While block throughput might be increased in the future, it's unlikely that it will reduce the granularity of observable on-chain time.
3. Transaction finality can be achieved in approximately one day, and cannot happen in less than a day, according to Ouroboros consensus design. Note that although a high level of confidence is already reached in a matter of minutes or hours, the probability of a block being ultimately discarded decreases exponentially with its depth and the number of nodes that have to adopt this block.

Finally, in the longer term, the current Ouroboros protocol is planned to be replaced with [Ouroboros Chronos](https://iohk.io/en/blog/posts/2021/10/27/ouroboros-chronos-provides-the-first-high-resilience-cryptographic-time-source-based-on-blockchain/). Ouroboros Chronos addresses the timekeeping challenges by providing the first high-resilience cryptographic time source based on blockchain technology.

**The importance of determinism in a blockchain environment**

In the current context, determinism means that a given transaction has a 'fixed effect' on the ledger state. But it is important to distinguish between the concepts of historical and prospective determinism.

Blockchains are based on the principle of replicating a fixed sequence of transactions (grouped in blocks) to reach a consensus about the state of the world. All blockchains have historical determinism, meaning that transactions in the chain have a fixed effect, else the results of validating the chain would be non-deterministic, which would break consensus.

But few blockchains have prospective determinism, meaning that a transaction that has not yet been added to the chain does have a fixed effect (or won't apply). Cardano does feature prospective determinism.

On blockchains that do not have prospective determinism users cannot know how much gas fees they need to pay for transactions which then results in such users overpaying for transactions. The lack of prospective determinism is also why a risk exists that a transaction on such blockchains can fail while also consuming lots of gas.

**The power of prospective determinism**

Prospective determinism is a very powerful feature of Cardano, for multiple reasons:

- Users know, ahead of time, what a transaction will do, so there are no surprises. This is particularly relevant for scripts because users know exactly:
- how the scripts will behave, and
- how much execution budget is needed.
- Proposed transactions can safely be processed in parallel. This parallelism is one of the reasons for Hydra's speed.
- Because users know in advance whether a transaction will fail or not, script failures can be punished harshly (because they will never happen to non-malicious users).
- Broadly, it makes interacting with, and evolving the blockchain easier and more predictable.

Prospective determinism of transactions requires that every part of transaction validation, including script execution, is completely deterministic. This is ultimately why Cardano cannot have non-deterministic operations in scripts.

One of the ways to get prospective determinism is by having the effect of a transaction be entirely determined by the transaction itself and the outputs it references. In the context of Cardano, this is called locality. Locality is also of great benefit for users since it means that anyone can know what a transaction does just by looking at the transaction.

**How do Plutus scripts handle time?**

Plutus scripts get access to the transaction validity range, defined by its creator. When defining the validity range, a creator can decide that a transaction is valid from slot X to slot Y, or leave one or both of the bounds undefined. This imposes constraints into which slot a transaction can be included, which is very useful on-chain to define various 'contracts'.

The script can assume that the actual time of validation is in this range. Otherwise, the transaction will fail in [phase 1](https://iohk.io/en/blog/posts/2021/09/07/no-surprises-transaction-validation-part-2/) before script execution. This ensures determinism since the script will always see the same piece of information (the validity range) regardless of when the script is validated, so the behavior will be the same.

The limits of the validity interval are expressed in real time (POSIXTime), rather than slots, and the conversion from slots to real time is done by consensus. Using real time rather than slots is important because slot lengths can change at a hard fork, so assumptions based on counting slots are generally unreliable. The fact that scripts see the validity range allows the scripts to make assertions like 'the current time is before/after some given time', but it does not enable a script to make any other kind of assertion ('the second in which this transaction is validated is even', for example.)

In Alonzo's original design, the validity range covered all known uses of time, while also fitting neatly with the existing time-to-live (TTL) field. In theory, it is possible to apply the same principles to other kinds of assertions, for example – let the script rely on assertions checked in phase 1. However, this would not be easy as it implies deep structural changes to various parts of the Cardano network. And because phase 1 checks need to be valid for every node across the network, this precludes any kind of assertion that depends on some local condition, like 'Current Time'.

**Use cases for time**

Time has different applications in the Cardano ecosystem.

**Hydra**

The Hydra protocol is dependent on time to compute and enforce the contestation deadline, which is a critical part of the protocol's safety mechanism. The Hydra Head state machine tracks the passage of time using UTCTime but the tick comes from the chain, based on the slot number observed from blocks produced by the chain. The reason for using UTCTime addresses the limitations inherent in the slot-to-time conversion the validity window imposes. One cannot convert a slot too far in the future, which means that it is simpler to use UTCTime off-chain and only do conversions when submitting/receiving transactions to or from the chain.

This implies that the tick's granularity is roughly 20s, as this is the expected frequency at which blocks are produced. Using this measure of time, Hydra is available to react to the protocol-relevant crossing of the contestation deadline.

What's important is that local time in the Hydra Head (and nodes) is tied to the on-chain time handled by Ouroboros. As Hydra is an isomorphic protocol, it is desirable to process 'timed transactions' also on layer 2 ([see issue #196](https://github.com/input-output-hk/hydra-poc/issues/196)). However, Hydra does not produce blocks, so the consensus itself does not need a notion of time (yet).

This requires an understanding of the precision and process of discretizing time on a layer 2 ledger. Although the complexities of handling time on-chain also apply to layer 2, layer 2 can provide better solutions since such networks are much smaller, have a shorter lifespan, and do not need to scale globally.

If you're interested in getting involved in discussions and sharing the types of applications you have and the resolution time they'd require, join this [Hydra Discord channel](https://discord.com/channels/826816523368005654/890903732462710836/890951034099335178).

**Marlowe**

Marlowe is a domain-specific language (DSL) for writing financial and transactional contracts, nearly all of which involve time. A wide variety of standard financial contracts have been written in Marlowe, including most of the [ACTUS](https://www.actusfrf.org/) standard contracts (eg, loans, swaps, options, and derivatives). Furthermore, Marlowe supports a variety of non-financial contract types such as auctions, token swaps, and even games. Cardano's existing mechanisms for working with time dovetail nicely with Marlowe's semantics and provide Marlowe transactions with locality and determinism inherited from Plutus.

In Marlowe, contract's time typically appears in the deadlines and timeouts that constrain how the execution of the contract evolves, and this works perfectly with Cardano's validity intervals. The timeout logic is needed in a loan contract, for example, to handle the situation where a loan payment is missed: then different logic needs to be executed in order to impose a penalty, adjust the schedule of future payments, etc. Contracts may also directly use the time endpoints of the validity interval in numerical computations, perhaps to adjust future payment amounts based on when an early payment was received. The fact that time appears as an interval has little practical impact on Marlowe because the interval can be as short as the time taken from submitting a transaction to its appearing in a block on the Cardano network – just a few minutes.

**Solutions**

Cardano could potentially provide more accurate time-related data during transaction validation, such as the timestamp from the block producer at which the block was minted, converted from its slot, or even the actual timestamp in UTC with milliseconds precision. However, this would break prospective determinism as it does on protocols which do not include this feature: a user could no longer tell if a transaction can definitely apply to the ledger or not, because that would depend on the exact timestamp that the block producer used when creating the block.

Another option is adding various assertion kinds to transaction bodies beyond the validity interval. This is possible, but difficult as already outlined before, hence there needs to be a use case for these assertion kinds to be useful.

Finally, layer 2 networks such as Hydra, can provide increased accuracy through shorter 'slot length' and shorter validity range, alongside decreased latency in transactions finality. Note that the current Hydra Head implementation does not yet provide that level of flexibility.

**Conclusion**

Time is a complex topic, especially in a decentralized blockchain setting. There is a clear notion of on-chain time on Cardano with specific constraints and available improvement options in the longer term.

On-chain time behaves in a somewhat different way from the time in traditional software. This divergence is defined in a consistent way to address system constraints while ensuring security and usability for end-users and stake pool operators. Moreover, Cardano's measure of time appears to be good enough to cover multiple use cases, even when compared to traditional finance uses.

TIME HANDLING ON CARDANO

Concurrency refers to the ability of different actors to perform work simultaneously without interfering with each other. In Cardano's Extended Unspent Transaction Output (EUTXO) model, transactions can be processed in parallel, enabling multiple operations without causing system failures. This approach enhances system throughput while maintaining the performance of individual operations.

The EUTXO model, employed by Cardano, allows for secure and predictable execution of smart contracts. By splitting logic across different branches and utilizing multiple UTXOs, Cardano achieves greater parallelism, leading to improved scalability.

The level of concurrency sets the limit for simultaneous operations. Developers should adopt strategies to minimize contention and translate concurrency into parallelism, which may involve a learning curve but yields significant benefits.

**info**

Learn more:

- [Concurrency: Cardano smart contracts and the EUTXO model](https://www.essentialcardano.io/article/concurrency-and-all-that-cardano-smart-contracts-and-the-eutxo-model)
- [How to design a scalable Plutus application](https://plutus-apps.readthedocs.io/en/stable/plutus/howtos/writing-a-scalable-app.html)
- [About the order book pattern.](https://plutus-apps.readthedocs.io/en/stable/plutus/explanations/order-book-pattern.html)

UNDERSTANDING CONCURRENCY

## **CARDANO PROTOCOL PARAMETERS REFERENCE GUIDE**


Protocol parameters on Cardano are the various settings that define the blockchain's behavior. Some protocol parameters are stable and non-updatable while others can be adjusted to adapt to changing conditions over time.

Examples of important Cardano protocol parameters include the maximum block size, the transaction fee structure, the block production schedule, and the minimum ada balance required for staking (read more in the following sections). Parameter choices can have a significant impact on the network's performance, security, and usability, and their alteration must be carefully considered.

The Voltaire governance system for Cardano aims to provide a flexible and adaptable framework that can evolve over time. This includes monitoring and changing the various protocol parameters. The collaboration of founding entities (Input Output Global, the Cardano Foundation, and EMURGO) with the community allows for a decentralized approach to governance and decision making. Cardano can then respond to changing conditions and optimize its performance and functionality to meet the needs of its users.

Additionally, the use of protocol parameters allows for agility and innovation within the network, as new ideas and proposals can be tested and implemented without requiring a hard fork or other disruptive changes to the network's architecture. This enables Cardano to remain at the forefront of blockchain technology and provide a robust and sustainable infrastructure for decentralized applications (DApps) and services.

**Types of protocol parameters on Cardano**

Cardano protocol parameters are classified as follows:

- **Network parameters** – affect Cardano’s connectivity properties and performance. Examples include the maximum number of connections allowed per node, peer discovery algorithm, the network propagation speed, block body and header size, transaction size, etc.
- **Economic parameters** – affect the economic aspects of blockchain operations. Examples include parameters such as the transaction fee structure, the minimum ada balance required for staking or transacting, stake pool fees, treasury settings, etc.
- **Technical parameters** – affect technical protocol properties like the consensus algorithm or cost models, for example. These include the stake pool pledge influence, a target number of stake pools, collateral percentage, and others.
- **Governance parameters** – as Voltaire is rolled out, a new class of parameters will be introduced to define the governance process.

Protocol parameters are either updatable or non-updatable:

- **Updatable** parameters can be adjusted through governance processes. These parameters can be used to change the operation of the block-producing protocol, vary transaction fees, define the influence of pledge, etc.
- **Non-updatable** parameters affect the fundamentals of the Cardano protocol and are stable, which means that they cannot be changed except via a hard fork. Non-updatable parameters include those defining the genesis block or basic security properties, for example. Some non-updatable parameters may be embedded in the source code or implemented as software. Each major protocol version defines its own set of updatable and non-updatable parameters.

Updatable parameters are designed to be flexible and adaptable, allowing the network to evolve over time in response to changing conditions and community needs. Non-updatable parameters, on the other hand, are typically set at the launch of the network or when introducing major changes to the protocol and are intended to provide a stable and secure foundation for the network's operations.

**A list of updatable protocol parameters**

![](https://i.imgur.com/JQnEahb.png)

![](https://i.imgur.com/o7zoucX.png)

![](https://i.imgur.com/9wA0zAD.png)

![](https://i.imgur.com/QnBVg2n.png)

You can find a [list of non-updatable protocol parameters here](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0009/README.md#non-updatable-parameters).

[CIP-09](https://cips.cardano.org/cip/CIP-0009), [CIP-28](https://cips.cardano.org/cip/CIP-0028), and [CIP-55](https://cips.cardano.org/cip/CIP-0055) provide an overview of protocol parameters in the Shelley, Alonzo, and Babbage eras.

CARDANO PROTOCOL PARAMETERS REFERENCE GUIDE

## **RELEVANT RESEARCH PAPERS AND SPECIFICATIONS**

Cardano is a third-generation blockchain platform that aims to provide the community with more advanced features than any protocol yet developed. As a proof-of-stake blockchain, it is built with the rigor of high-assurance formal development methods and aims to achieve the scalability, interoperability, and sustainability needed for real-world applications. Cardano is the first platform to evolve out of scientific philosophy based on discovery, peer review, and cryptographic research.

Building a strong foundation in the blockchain industry, Cardano has an ethos of openness and transparency. All the [research and technical specifications](https://iohk.io/en/research/library/) that underpin Cardano are publicly published and available to the community.

Cardano’s development roadmap is divided into 5 eras that focus on the foundation, decentralization, smart-contract and multi-asset ledger deployment, scalability, and governance of a pioneering blockchain environment. Relevant research papers and specifications according to the Cardano development roadmap are outlined below.

**Byron**

A period dedicated to building a foundational federated network that enabled the purchase and sale of ada. The network ran the proof-of-stake Ouroboros consensus protocol.

**Relevant research papers**:

[Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol](https://eprint.iacr.org/2016/889.pdf)

[Ouroboros-BFT: A Simple Byzantine Fault Tolerant Consensus Protocol](https://eprint.iacr.org/2018/1049.pdf)

**Relevant specifications**:

[A Formal Specification of the Cardano Ledger](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/byron-ledger.pdf)

[Specification of the Blockchain Layer](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/byron-blockchain.pdf)

[Formal Specification for a Cardano Wallet](https://iohk.io/en/research/library/papers/formal-specification-for-a-cardano-wallet/)

[Small Step Semantics for Cardano](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/small-step-semantics.pdf)

**Shelley**

A period of growth and development for the network focused on ensuring greater decentralization, which will lead to enhanced security and a more robust environment once the majority of nodes are run by network participants.

**Relevant research paper**s:

[Ouroboros Praos: An adaptively-secure, semi-synchronous proof-of-stake blockchain](https://eprint.iacr.org/2017/573.pdf)

[Ouroboros Genesis: Composable Proof-of-Stake Blockchains with Dynamic Availability](https://eprint.iacr.org/2018/378.pdf)

[Stake-Bleeding Attacks on Proof-of-Stake Blockchains](https://eprint.iacr.org/2018/248.pdf)

[Reward Sharing Schemes for Stake Pools](https://arxiv.org/ftp/arxiv/papers/1807/1807.11218.pdf)

[Account Management in Proof of Stake Ledgers](https://eprint.iacr.org/2020/525.pdf)

[Flexible Formality: Practical Experience with Agile Formal Methods](https://iohk.io/en/research/library/papers/flexible-formalitypractical-experience-with-agile-formal-methods/)

[Coalition-Safe Equilibria with Virtual Payoffs](https://arxiv.org/pdf/2001.00047.pdf)

[Efficient Random Beacons with Adaptive Security for Ungrindable Blockchains](https://iohk.io/en/research/library/papers/efficient-random-beacons-with-adaptive-security-for-ungrindable-blockchains/)

[SecureCyclon: Dependable Peer Sampling](https://iohk.io/en/research/library/papers/securecyclon-dependable-peer-sampling/)

[Practical Settlement Bounds for Longest-Chain Consensus](https://iohk.io/en/research/library/papers/practical-settlement-bounds-for-longest-chain-consensus/)

[Blockchain Participation Games](https://iohk.io/en/research/library/papers/blockchain-participation-games/)

[Consensus Redux: Distributed Ledgers in the Face of Adversarial Supremacy](https://iohk.io/en/research/library/papers/consensus-redux-distributed-ledgers-in-the-face-of-adversarial-supremacy/)

**Relevant specifications**:

[Engineering Design Specification for Delegation and Incentives in Cardano–Shelley](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/shelley-delegation.pdf)

[A Specification of the Non-Integral Calculations in the Shelley Ledger](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/non-integer-calculations.pdf)

**Goguen**

The Goguen era will introduce smart-contract functionality to build decentralized applications while supporting multi-functional assets, fungible, and non-fungible token standards.

**Relevant research papers**:

[The Extended UTXO Model](https://iohk.io/en/research/library/papers/the-extended-utxo-model/)

[UTXOma: UTXO with Multi-Asset Support](https://iohk.io/en/research/library/papers/utxoma-utxo-with-multi-asset-support/)

[Native Custom Tokens in the Extended UTXO Model](https://iohk.io/en/research/library/papers/native-custom-tokens-in-the-extended-utxo-model/)

[Functional Blockchain Contracts](https://iohk.io/en/research/library/papers/functional-blockchain-contracts/)

[Scripting Smart Contracts for Distributed Ledger Technology](https://eprint.iacr.org/2016/1156.pdf)

[Marlowe: financial contracts on blockchain](https://iohk.io/en/research/library/papers/marlowefinancial-contracts-on-blockchain/)

[Marlowe: implementing and analysing financial contracts on blockchain](https://iohk.io/en/research/library/papers/marloweimplementing-and-analysing-financial-contracts-on-blockchain/)

[Unraveling recursion: compiling an IR with recursion to System F](https://iohk.io/en/research/library/papers/unraveling-recursioncompiling-an-ir-with-recursion-to-system-f/)

[System F in Agda, for fun and profit](https://iohk.io/en/research/library/papers/system-f-in-agdafor-fun-and-profit/)

[Translation Certification for Smart Contracts](https://iohk.io/en/research/library/papers/translation-certification-for-smart-contracts/)

[Message-passing in the Extended UTxO Ledger Model](https://iohk.io/en/research/library/papers/message-passing-in-the-extended-utxo-ledger-model/)

[Structured Contracts in the EUTxO Ledger Model](https://iohk.io/en/research/library/papers/structured-contracts-in-the-eutxo-ledger-model/)

**Relevant specifications:**

[A Formal Specification of the Cardano Ledger with a Native Multi-Asset Implementation](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/mary-ledger.pdf)

[A Formal Specification of the Cardano Ledger integrating Plutus Core](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/alonzo-ledger.pdf)

**Basho**

An era of optimization, improving the scalability and interoperability of the network. Enhancing the network performance, Basho will introduce sidechains, new blockchains, interoperable with the main Cardano chain, with immense potential to extend the network’s capabilities.

**Relevant research papers:**

[Proof-of-Stake Sidechains](https://eprint.iacr.org/2018/1239.pdf)

[Hydra: Fast Isomorphic State Channels](https://eprint.iacr.org/2020/299.pdf)

[Interhead Hydra: Two Heads are Better than One](https://iohk.io/en/research/library/papers/interhead-hydratwo-heads-are-better-than-one/)

[Mithril: Stake-based Threshold Multisignatures](https://iohk.io/en/research/library/papers/mithrilstake-based-threshold-multisignatures/)

[Babel Fees via Limited Liabilities](https://iohk.io/en/research/library/papers/babel-fees-via-limited-liabilities/)

[Djed: A Formally Verified Crypto-Backed Pegged Algorithmic Stablecoin](https://iohk.io/en/research/library/papers/djeda-formally-verified-crypto-backed-pegged-algorithmic-stablecoin/)

[State Machines across Isomorphic Layer 2 Ledgers](https://iohk.io/en/research/library/papers/state-machines-across-isomorphic-layer-2-ledgers/)

[Tiered Mechanisms for Blockchain Transaction Fees](https://iohk.io/en/research/library/papers/tiered-mechanisms-for-blockchain-transaction-fees/)

[Approximate Lower Bound Arguments](https://iohk.io/en/research/library/papers/approximate-lower-bound-arguments/)

**Relevant specifications:**

[Formal Specification of the Cardano Ledger for the Babbage era](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/babbage-ledger.pdf)

**Voltaire**

A development era enabling the Cardano network to become a self-sustaining system. Voltaire will introduce a voting and treasury system that will enable network participants to use their stake and voting rights to influence the future development of the blockchain.

**Relevant research papers:**

[A Treasury System for Cryptocurrencies: Enabling Better Collaborative Intelligence](https://eprint.iacr.org/2018/435.pdf)

[Updatable Blockchains](https://eprint.iacr.org/2020/887.pdf)

[SoK: Blockchain Governance](https://iohk.io/en/research/library/papers/fait-accompli-committee-selection-improving-the-size-security-tradeoff-of-stake-based-committees/)

[Fait Accompli Committee Selection: Improving the Size-Security Tradeoff of Stake-Based Committees](https://iohk.io/en/research/library/papers/fait-accompli-committee-selection-improving-the-size-security-tradeoff-of-stake-based-committees/)

**Relevant specifications:**

[CIP-1694: An On-Chain Decentralized Governance Mechanism for Voltaire](https://github.com/JaredCorduan/CIPs/blob/voltaire-v1/CIP-1694/README.md)

Formal specification is a work in progress

[Formal specification of the Cardano blockchain ledger, mechanized in Agda](https://iohk.io/en/research/library/papers/formal-specification-of-the-cardano-blockchain-ledger-mechanized-in-agda/)

RELEVANT RESEARCH PAPERS AND SPECIFICATIONS

## **DESIGN RATIONALE**

[Cardano](https://cardano.org/) is an open source [proof-of-stake](https://docs.cardano.org/about-cardano/new-to-cardano/proof-of-stake) blockchain project that began in 2015 to address existing blockchain challenges in the design and development of cryptocurrencies. It aims to provide a more balanced and sustainable ecosystem that better accounts for the needs of its users as well as other systems seeking integration.

The first generation of blockchains (like Bitcoin) offered decentralized ledgers for secure cryptocurrency transfer. However, such blockchains did not provide a functional environment for complex deal settlement and decentralized application (DApp) development. As blockchain technology matured, the second generation (like Ethereum) provided more enhanced solutions for writing and executing smart contracts, application development, and the creation of different token types. On the other hand, the second generation of blockchains often faces issues in terms of scalability.

Cardano is conceived as the third-generation blockchain as it combines the properties of the prior generations and evolves to meet all the arising needs of users. When comparing blockchain properties, many aspects should be considered. Thus, the best solution must ensure the highest security, scalability (transaction throughput, data scale, network bandwidth), and functionality (besides transaction processing, the blockchain should provide all means for business deal settlement). Moreover, it is important to ensure that blockchain technology is constantly developing in terms of sustainability and is interoperable with other blockchains and financial institutions.

To address these needs, Cardano has been built focusing on such core concepts as:

- **Scalability** – ensures that the Cardano network is capable of processing an increasing number of transactions as user demand grows. Scalability also provides higher bandwidth capabilities to allow transactions to carry a significant amount of supportive data that can be easily managed within the network. For these needs, Cardano is implementing various techniques (like data compression for instance), and introduces such scaling solutions as [Hydra](https://hydra.family/head-protocol/) and [Mithril](https://mithril.network/doc/), for example. Read more about the [research underpinning Cardano's scalability here](https://www.essentialcardano.io/article/an-analysis-of-the-research-underpinning-cardanos-scalability).
- **Interoperability** – ensures the most multi-functional environment for financial, business, or commercial operations by enabling users to interact with different blockchain systems. Cardano aims to support cross-chain transfers, multiple token types, and commonly used smart contract languages. Read more about the concept of [partner chains](https://iohk.io/en/blog/posts/2023/11/03/partner-chains-are-coming-to-cardano/).
- **Sustainability** – designing a proof-of-stake blockchain means it is vital to ensure that the system is self-sustainable. To drive growth and maturity in a truly decentralized manner, Cardano is built to allow the community to maintain its continuous development by participating, proposing, and implementing system improvements. This is now being implemented through [CIP-1694](https://cips.cardano.org/cip/CIP-1694) on-chain governance mechanisms.

**Cardano advantages**

- **Academic research** – formal methods, such as mathematical specifications, property-based tests, and proofs, are the best way to deliver high assurance software systems and give confidence to users for the management of digital funds. Cardano has been built using formal methods to achieve strong guarantees on the functional correctness of core components of the system. All of the research and technical specifications that underpin Cardano are publicly available, and all Cardano development activity is published online.
- **System design** – Cardano is written in Haskell, a secure functional programming language that encourages building a system using pure functions, which leads to a design where components are conveniently testable in isolation. Advanced features of Haskell enable employing a whole range of powerful methods for ensuring code correctness, such as basing the implementation on formal and executable specifications, extensive property-based testing, and running tests in simulation.
- **Security** – [Ouroboros](https://iohk.io/en/blog/posts/2020/06/23/the-ouroboros-path-to-decentralization/) (the Cardano proof-of-stake protocol) establishes rigorous security guarantees; it was delivered with several peer-reviewed papers presented in top-tier conferences and publications in the area of cybersecurity and cryptography.
- **Energy efficiency** – Cardano is a proof-of-stake blockchain. In contrast to proof-of-work blockchains, [Cardano requires much less energy](https://iohk.io/en/blog/posts/2021/08/17/why-they-re-calling-cardano-the-green-blockchain/) and computational power. The Bitcoin network is secured through computers doing ever-more-energy-intensive computations – proof of work – which is unsustainable in the long term. Cambridge University has an online tool that shows the [computers powering Bitcoin](https://cbeci.org/) already consume more electricity than some countries, like [Switzerland](https://www.bfe.admin.ch/bfe/en/home/supply/statistics-and-geodata/energy-statistics/overall-energy-statistics.html) for example.
- **Seamless upgrades** – traditionally, blockchains upgrade using hard forks. When conducting a hard fork, the current protocol would stop operating, new rules and changes would be implemented, and the chain would restart – with its previous history being erased. Cardano handles hard forks differently. Instead of implementing radical changes, the Cardano [hard fork combinator technology](https://iohk.io/en/blog/posts/2020/05/07/combinator-makes-easy-work-of-shelley-hard-fork/) ensures a smooth transition to a new protocol while saving the history of the previous blocks and not causing any disruptions for end users.
- **Decentralization** – Cardano is maintained by over 3,000 distributed stake pools that are operated by the community. All blocks and transactions are validated by network participants without any reliance on a centralized authority.
- **Functional environment for business use cases** – Cardano is establishing a foundation for global, decentralized finance to develop a range of DApps that can run using functional and domain-specific smart contracts, providing multi-asset tokens for any needs.

DESIGN RATIONALE

## **DEVELOPMRNT PHASES AND ERA**

**info**
This overview is based on [CIP-59](https://cips.cardano.org/cip/CIP-0059).

Cardano’s development follows a well-defined and clearly communicated [roadmap](https://roadmap.cardano.org/en/). Firmly based on academic research and rigorous testing, this process has resulted in a chain with zero outages.

Cardano has gone through multiple development phases and eras enabled by hard fork combinator events. The following concepts are explained below:

- **Development phase** – a high-level collection of features described on the [Cardano roadmap](https://roadmap.cardano.org/en/).
- Ledger era – a collection of ledger features introduced with a hard fork. Starting with Alonzo, eras are planned to be named after mathematicians and computer scientists in a, b,c order.
- **Intra-era hard fork** – a small and focused semantic change to the ledger requiring a hard fork.
- **Consensus mechanism** – a collection of consensus features introduced with a hard fork. Historically, these have featured the name ‘Ouroboros’.
- **Ledger protocol** – a collection of ledger features between the consensus layer and the ledger layer, roughly characterized by block header validation.

**Development phases**

Cardano’s development phases include Byron, Shelley, Goguen, Basho, and Voltaire – all named after poets except for Goguen, a computer scientist.

- **Byron**. Byron set the foundation for Cardano development allowing users to buy and sell ada on a proof-of-stake blockchain network. Initially, the Cardano ledger was established as a federated network, where block production and transaction validation were maintained by [the founding entities](https://www.essentialcardano.io/article/founding-and-iog-organization). Byron saw the delivery of [Daedalus](https://daedaluswallet.io/) and Yoroi wallets, and also provided users with a Block Explorer ‒ a tool specifically designed for browsing the blockchain.
- **Shelley**. The Shelley development theme introduced a decentralized ledger creating a completely new economic system, which drives the network’s growth and gradual optimization. Shelley evolved from Byron’s federated network maintenance, with more and more blocks being produced by the distributed stake pool operator community. This theme focused on many critical steps that ensure enhanced user experience in terms of stake pool operation, delegation preferences, and incentives.
- **Goguen**. Goguen development focused on the establishment of a global, financial, and multi-functional system for decentralized application (DApp) building, smart contract support, and custom token issuance. Goguen is a key building block to establish a versatile platform to build solutions around such application domains as supply chain, track and trace, finance, medical records, identity voting, property registration, P2P payments, and many others.
- **Basho**. Basho focuses on Cardano’s optimization in terms of improving the scalability and interoperability of the network. Whereas other development stages focus on decentralization and new functionality, Basho is about improving the underlying performance of the Cardano network to better support growth and adoption for applications with high transaction volume.
- **Voltaire**. Decentralized governance and decision making lie at the heart of Voltaire granting the Cardano community the ability to vote on network development updates, technical improvements, and project funding. For the Cardano network to become more decentralized, it requires not only the distributed infrastructure introduced during Shelley but also the capacity to be maintained and improved over time in a decentralized way.

**Ledger eras**

There are several eras within the evolution of Cardano. Each era refers to the rules of the ledger. For example, what transaction types and what data is stored in the ledger, or the validity and meaning of the transactions.

**Byron and Shelley eras**

The evolution of the Cardano mainnet began with the Byron ledger rules. The mainnet underwent a hard fork in late July 2020 to switch from the Byron rules to the Shelley ledger rules. It was a full reimplementation of Cardano, which enabled two fundamental changes: the support for multiple sets of ledger rules, and the management of the hard fork process of switching from one set of rules to the next. In other words, the new implementation could support both the Byron rules and the Shelley rules, which meant that, when deployed to the mainnet in early 2020, the implementation was fully compatible with the Byron rules. This allowed for a smooth transition from the old to the new implementation. Once all Cardano users had upgraded their nodes to the new implementation, it became possible to invoke the hard fork combinator event and switch to the Shelley rules.

**Allegra, Mary, and Alonzo eras**

Allegra, Mary, and Alonzo eras are all part of the Goguen development phase.

Starting with Goguen, the ledger team introduced the notion of era into the ledger code. Shelley ledger rules then became ‘the Shelley era’.

Because Goguen features were implemented in steps, each set of functionality was introduced with a different hard fork, hence there were several ledger eras:

- Allegra: introduced token locking support
- Mary: brought native tokens and multi-asset functionality to Cardano
- Alonzo: introduced smart contract support.

The names Allegra and Mary were chosen for their connection to the poet Percy Shelley and were only intended to be used as [variable names](https://github.com/input-output-hk/cardano-ledger/blob/1cbf1fc2bb005a8206e5b5a7cdf44d35baaca455/eras/shelley-ma/impl/src/Cardano/Ledger/Allegra.hs#L40) for a very specific abstraction used in the ledger code.

Goguen, the smart contract development phase, was the only phase named not after a poet. So the name of the ledger era that introduced smart contracts was named after Alonzo Church – the person who invented the lambda calculus (Plutus Core uses a variant of [system F](https://en.wikipedia.org/wiki/System_F)).

Going forward, the teams decided to use names in a,b,c order, after individuals who contributed to mathematics and computer science. One lack of consistency to notice is that eras can use both first and last names. This is driven by conciseness.

**Babbage era**

The Babbage ledger era introduced such features as inline datums, reference scripts, and reference inputs. However, the release is also known as Vasil, named to honor the late Bulgarian mathematician and Cardano ambassador Vasil Dabov.

**Intra-era hard forks**

A new era must be introduced with a hard fork, but the ledger can also change semantics during a controlled hard fork with another mechanism – an intra-era hard fork. This is an implementation detail that involves bumping the major protocol version but not creating a new ledger era. The Alonzo era, for example, experienced an intra-era hard fork when going from major protocol version 5 to 6.

You can see a table with Cardano’s phases, eras, and intra-era hard forks visualized below:

![](https://ucarecdn.com/17dfdeb2-0f39-4b21-989d-18c64d5494ee/)

Image source: CIP-59 Cardano features annex

**Conclusion**

It is important to understand that not all of the semantic changes to the Cardano network involve the ledger. Changes to the consensus protocol or the networking layer may also require a hard fork. There is also an abstraction between the consensus and ledger layers, named the protocol. The distinction between the ledger protocols and the ledger eras corresponds roughly to how block headers are validated (protocol) versus how block bodies are validated (era). The Shelley era used the ‘transitional Praos’ protocol (TPraos), which consisted of Praos combined with a transition system to move away from Ouroboros BFT. The Babbage era replaced TPraos with Praos.

Note that the protocol version is unrelated to the node-to-node and node-to-client protocol versions. The consensus layer maintains a versioning scheme for the node queries that does not necessarily align with the protocol version described in this overview.

The protocol version is also included in each block header indicating the maximum protocol version that the block producer is capable of supporting.

DEVELOPMRNT PHASES AND ERA

## **ABOUT HARD FORKS**

The term hard fork describes a radical change in the blockchain: a change from one protocol to another, for example. In most blockchains, a hard fork indicates block changes or a change to their interpretation.

Traditionally, when conducting a hard fork, the current protocol would stop operating, new rules and changes would be implemented, and the chain would restart. It is important to note that a hard-forked chain will be different from the previous version and that the history of the pre-forked blockchain will no longer be available.

The Cardano blockchain hard forked from a Byron federated model to a Shelley decentralized one in 2020. However, this hard fork was unique. Instead of implementing radical changes, Cardano ensured a smooth transition to a new protocol while saving the history of the previous blocks. This means that the chain did not change radically, instead, it contained Byron blocks, and after a transition period, added Shelley blocks. There was no fundamental restart point that erased the history of previous activities.

**What is a hard fork combinator?**

A combinator is a technical term used to indicate the combination of certain processes or things. In the case of Cardano, a hard fork combinator combines protocols, thereby enabling the [era-to-era transition](https://iohk.io/en/blog/posts/2020/04/29/from-byron-to-shelley-part-one-the-testnets/) without system interruption or restart. It ensured that Byron and Shelley ledgers appeared as one ledger. Shifting from [Ouroboros BFT](https://eprint.iacr.org/2018/1049.pdf) to [Ouroboros Praos](https://iohk.io/en/research/library/papers/ouroboros-praosan-adaptively-securesemi-synchronous-proof-of-stake-protocol/) did not require all nodes to update simultaneously. Instead, nodes could update gradually, in fact, some could run Byron blocks, while others could run Shelley blocks.

The hard fork combinator is designed to enable the combination of several protocols, without having to make significant adjustments.

Read more about Cardano's upgrades in the following section.

ABOUT HARD FORKS

CARDANO EVOLUTION

## **BYRON TO SHELLY**

Cardano's Byron mainnet ran on the [Ouroboros Classic](https://iohk.io/en/research/library/papers/ouroboros-a-provably-secure-proof-of-stake-blockchain-protocol/) consensus protocol. Cardano's Shelley mainnet transitioned to a decentralized network running on the [Ouroboros Praos](https://iohk.io/en/research/library/papers/ouroboros-praos-an-adaptively-secure-semi-synchronous-proof-of-stake-protocol/) consensus protocol, which enabled more extended capabilities while also supporting the staking process with monetary rewards for ada holders and stake pool operators.

To enable orderly transitions in Cardano without any diversions in the system, it was necessary to update the code to support the new protocol’s conditions. Doing so in a single update might have caused a range of complexities, so Cardano decided to take a two-stage approach, using the Ouroboros Byzantine Fault Tolerance (BFT) protocol as an intermediary.

The shift from Ouroboros Classic to BFT (which happened on February 20, 2020) is the only traditional hard fork within the Cardano blockchain. This forking event restarted the Byron mainnet to run the BFT protocol and enable a smoother transition to Ouroboros Praos without any further chain interruptions. The BFT protocol was carefully designed so that blockchain history would remain unchanged, and the blockchain would appear as a single entity.

BYRON TO SHELLY

## *ALLEGRA**

Allegra was the Shelley protocol upgrade that introduced token locking support to enable various kinds of smart contract use cases.

Allegra represented a relatively small technical change to the consensus protocol, with a slight impact on the actual ledger. However, it was significant since it prepared the platform for smart contracts and the creation of assets (in addition to ada) that run on Cardano. It also provided an important piece of Voltaire (governance) functionality, supporting a voting mechanism.

Token locking is a way of recording that a specific token is being used for some purpose. 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).

**info**

Read more about token locking [in this blog post](https://iohk.io/en/blog/posts/2020/12/02/goguen-brings-token-locking-to-cardano/).

**Token locking use cases**

Support for token locking is crucial to enable complex deal settlement and funds accounting.

It can be used in the following scenarios:

- **Contractual agreement** – when someone enters into a contractual agreement, to sell a property, for instance, it is important to promise that this property will not be sold to anyone else – only to the person who actually pays the money. In this case, the token can represent the property and the ‘promise’ – the actual token locking. If the property is sold to a different third party, then the contract becomes void.
- **Vote registry** – within the Voltaire voting mechanism, token locking will enable users to lock a certain amount of their tokens to represent their voting rights. Ada holders who participate in the voting process will be required to ‘lock’ their tokens. This will represent their voting rights, according to the stake that they hold, and eliminate the risks associated with scenarios such as double-counting votes, allocating more votes than possible, contradictory votes, or vote duplication.
- **Multi-asset tokens** – Cardano provides support for multi-asset tokens, where the ledger supports the creation and use of multiple custom token types, besides ada. Token locking allows ada tokens to be ‘locked’, for example, to create another custom asset of equivalent value.

ALLEGRA

## **MARY**

Mary is the Shelley protocol upgrade implemented in March 2021. It introduced native token and multi-asset support on Cardano. Mary allowed users to create uniquely defined (custom) tokens and carry out transactions with them directly on the Cardano blockchain.

With the Mary upgrade, the ledger’s accounting infrastructure processes not only ada transactions but also transactions that simultaneously carry several asset types. Native support grants distinct advantages for developers as there is no need to create smart contracts to handle custom token creation or transactions. Instead, the accounting ledger tracks the ownership and transfer of assets, removing extra complexity and potential for manual errors, while ensuring significant cost efficiency.

Developers, businesses, and applications can create general purpose (fungible) or specialized (non-fungible) tokens to achieve commercial or business objectives. These might include the creation of custom payment tokens or rewards for decentralized applications; stablecoins pegged to other currencies; or unique assets that represent intellectual property. All these assets can then be traded, exchanged, or used as payment for products or services.

**info**

Further reading:

- [Learn about native tokens](https://docs.cardano.org/developer-resources/native-tokens)

MARY

## **ALONZO**

Alonzo is the protocol upgrade implemented in September 2021, as part of the Goguen development phase. It built on top of transaction metadata, token locking, and native asset functionality to enable smart contract development.

This upgrade introduced a versatile platform opening up opportunities for businesses and developers, by allowing the creation of smart contracts and decentralized applications (DApps) for decentralized finance (DeFi).

Such capability was enabled by adding the necessary tools and the infrastructure using the Plutus platform. Applying a rigorous approach based on formal methods and verification, Alonzo extended the basic multi-signature scripting language (multisig) used in Cardano Shelley. Multisig was upgraded to the Plutus Core language for more powerful and secure scripting options. For this, Alonzo implemented the [extended unspent transaction output (EUTXO) accounting model](https://iohk.io/en/blog/posts/2021/03/12/cardanos-extended-utxo-accounting-model-part-2/).

**info**

Further reading:

- [Smart contracts - here we come](https://iohk.io/en/blog/posts/2021/04/08/smart-contracts-%E2%80%93-here-we-come/)
- [Plutus: what you need to know](https://iohk.io/en/blog/posts/2021/04/13/plutus-what-you-need-to-know/)

ALONZO

## **VASIL**

Vasil is the protocol upgrade implemented in June 2022. Named after the late Bulgarian mathematician and prominent Cardano community member Vasil Dabov, the Vasil upgrade introduced five key mechanisms to improve the blockchain's performance: [CIP-31](https://cips.cardano.org/cip/CIP-0031) (reference inputs), [CIP-32](https://cips.cardano.org/cip/CIP-0032) (inline datums), [CIP-33](https://cips.cardano.org/cip/CIP-0033) (reference scripts), [CIP-40](https://cips.cardano.org/cip/CIP-0040) (collateral outputs), and diffusion pipelining.

Here's a more detailed feature overview.

**Diffusion pipelining**

Diffusion pipelining is a feature that improves block propagation times and further leads to higher throughput. In essence, it streamlines the process of sharing information about newly created blocks among network participants. The goal is to ensure that blocks can be shared (propagated) in the network within five seconds after their creation. For this, diffusion pipelining propagates blocks before their full validation thus overlapping the time spent on diffusion with the time needed on validation.

Pipelining also ensures that the block header referencing the hash of a previous block is propagated correctly. The body of the block is retained within the metadata included in the next block, which is essential for DDoS attack resistance even without full block confirmation.

Diffusion pipelining provides more space for block size increase and Plutus script improvements, leading to a more scalable setting overall.

**Plutus Core changes**

Plutus Core is a scripting language used in the Cardano ledger. It consists of basic core language constructs and also includes built-in types (integers, strings, etc) and built-in functions (integer addition, etc) that provide functionality that would be difficult or expensive to implement in the Plutus Core code. Built-in functions mostly operate on built-in types. Built-in types come with a size metric that is used by costing functions. For example, the size metric for integers returns the bit-size of the integer.

The performance of Plutus Core scripts relates to how expensive it is to run a script in the ledger. The cost model describes CPU and memory fees for each language primitive and can be used off-chain to predict fees for running such scripts.

Model performance is calculated by `costing _evaluation_` in abstract resource units (exunits) of CPU and memory. Individual steps of evaluation are costed, and built-in functions must also come with a `_costing function_` that provides costing information for them. The costing function for a built-in function is a mathematical function that takes the sizes of the arguments (as computed by their size metrics) and returns an estimate of the budget that will be used to perform that function.

For example, the costing function for addition says that the CPU and memory costs are both proportional to the maximum of the sizes of the input integers (with some appropriate constants). Determining costing functions is done empirically by running the function in question against a large number of inputs and choosing a costing function that fits the data well.

**Scripts in the Cardano ledger**

The Cardano ledger recognizes various types of scripts that are identified by ‘language’ version. This language tag allows the ledger to distinguish between different script types. When a new behavior or functionality is introduced, so is a new language. Each new version of Plutus will be its own language, and all Plutus Core language versions are supported forever in the ledger. This provides the ability to validate the history of the chain indefinitely.

Part of the specification of a language in the ledger explains how language scripts run, what arguments they are given, and how those arguments are structured. Languages also have an associated subset of Cardano protocol parameters that control some aspects of the script evaluation. For Plutus, this is the cost model that is associated with each new language version.

**Plutus evaluator speed improvements**

Due to performance improvements in the Plutus evaluator, both Plutus V1 and Plutus V2 scripts have lower cost model parameters than before, resulting in 20-30% improvements in script resource usage.

**Updated cost model parameters**

The updated cost model parameters include the following changes:

1 . Extend the set of built-in functions by adding the new built-in “serialiseData.”

2 . The built-in function “verifySignature” was renamed “verifyEd25519Signature” to make it more clear what its function is.

3 . Recalibrate the cost model for the version of the evaluator in the node to align with the CPU parameters changes.

**New Plutus Core built-in**

The built-in types and type operators remain unchanged from the Alonzo upgrade. All the new built-in functions are backward compatible. Adding them does not break any older script validators. The Vasil release continues to support the Alonzo built-in functions and adds the following new function:

**serialiseData**

A new Plutus built-in is added for serializing `BuiltinData` to `BuiltinByteString`. The serialiseData function takes a data object and converts it into a [CBOR](https://cbor.io/) object.

Plutus already provides a built-in for hashing data structure, for example, `sha2_256 :: BuiltinByteString -> BuiltinByteString`, it does not provide generic ways of serializing some data types to `BuiltinByteString`.

The overall memory and CPU costs are reduced by having a new built-in to serialize any Plutus ‘BuiltinData’ to ‘BuiltinByteString’ such that validators can leverage more optimized implementations and bytestring builders via built-ins than what is available on-chain.

For more explanations, how-to guides, and tutorials, see [Plutus Docs](https://plutus.readthedocs.io/en/latest/index.html).

**Plutus script addresses**

*A Plutus V2 script does not have the same hash value as a Plutus V1 script.*

Since scripts must match their on-chain hashes exactly, it is important that the scripts that an application uses do not accidentally change. For example, changing the source code or updating dependencies or tooling may lead to small changes in the script. As a result, the hash will change. In cases where the hashes must match exactly, even changes which do not alter the functionality of the script can be problematic.

In light of this consideration, some DApp developers might expect that when doing a migration from Plutus V1 scripts to Plutus V2 scripts, the same source code, when recompiled, will generate the same hash value of that script address. However, it is impossible for a compiled V2 script to have the same script hash and address as a compiled V1 script.

Using the exact same script with different language versions will result in different hashes. The exact same script (as in UPLC.Program) can be used as a Plutus V1 script or a Plutus V2 script, and since the language version is part of the hash, the two hashes will be different.

**A Plutus V1 script will not necessarily have the same hash value when recompiled with a later version of the Plutus compiler**

Suppose you write your Haskell source code (Plutus Tx), compile it into Plutus Core code (PLC), generate its hash value, then use it in a transaction. If you don’t save your compiled code, and then decide to use the same script in the future, you would have to recompile it. This could result in a different hash value of the script address even without upgrading from Plutus V1 to Plutus V2 scripts. This is because the hash is computed based on the output of the compiled code.

Given Plutus compiler version changes, changes in the dependencies, and multiple other improvements, it is expected that the hash value of the script address will change after the source code is recompiled.

**When to export and save the output of a compiled script**

Once you expect that you will not modify the on-chain part of your application and you don’t want the hash value of your script address to change, the best way to keep it the same is to save the output of your final compiled Plutus Core code (PLC) to a file.

For details on how to export scripts, please see: [How to export scripts, datums, and redeemers](https://plutus.readthedocs.io/en/latest/howtos/exporting-a-script.html) in the Plutus Core user documentation.

**Reference inputs (CIP-31)**

Transaction outputs carry datums, which enable access to information on the blockchain. However, these datums are constrained in a number of ways. For example, to access information in the datum, you’d have to spend the output that the datum is attached to. This requires the re-creation of a spent output. Any user who wishes to look at the data cannot spend the old output (which is gone), but must spend the new output (which they will not know about until the next block). In practice, this limits some applications to one ‘operation’ per block, thus decreasing the desired performance.

CIP-31 introduces a new mechanism for accessing information in datums – a reference input. Reference inputs allow looking at an output without spending it. This will facilitate access to information stored on the blockchain without the need for spending and re-creating unspent transaction outputs (UTXOs).

The key use case of CIP-31 is to support reference scripts (CIP-33). Other use cases include:

1 . Inspecting the state (datum, or locked value) of an on-chain application without having to consume the output. For example, checking the current state of a stablecoin state machine.
2 . The ability to reference on-chain data providers that store data in outputs by other scripts.

See the [how to use reference inputs](https://github.com/perturbing/vasil-tests/blob/main/reference-inputs-cip-31.md) tutorial for more details.

**Inline datums (CIP-32)**

Datums carrying transaction information are commonly implemented by attaching hashes of datums to outputs. This is quite inconvenient for users. Datums tend to represent the result of computation done by the party who creates the output, and as such, there is almost no chance that the spending party will know the datum without communicating with the creating party. This means that either the datum must be communicated between parties off-chain, or on-chain by including it in the witness map of the transaction that creates the output (‘extra datums’). Such a case requires the spending party to watch the whole chain to find the datum, which is also inconvenient.

CIP-32 suggests a solution that allows datums themselves to be attached to outputs instead of datum hashes. This will allow much simpler communication of datum values between users.

**Use cases** include:

- Creating a single UTXO with data to be used in multiple subsequent transactions, but only paying the cost for submitting it once.
- Storing little information on-chain. For example, Oracles can benefit from this by simply adding some off-chain data to the main chain.

See the how to [use inline datums](https://github.com/perturbing/vasil-tests/blob/main/inline-datums-cip-32.md) tutorial for more details.

**Reference scripts (CIP-33)**

When you spend an output locked with a Plutus script, you must include the script in the spending transaction. Hence, the size of the scripts contributes to transaction size, which directly influences Cardano’s throughput.

Large script sizes pose problems for users because:

1. Larger transactions result in higher fees.
2. Transactions have size limits. Large scripts can hit the limits. Even if one script fits, multiple scripts in one transaction might not fit. This makes it difficult to execute complex transactions that rely on several scripts.

CIP-33 introduces the ability to reference a script without including it in each transaction. This hugely reduces the contribution of scripts to the transaction size.

See the [how to reference scripts](https://github.com/perturbing/vasil-tests/blob/main/referencing-scripts-cip-33.md) tutorial for more details.

**Transaction redeemers**

Two important elements in Plutus are datums and redeemers. The datum is a piece of information that can be associated with a UTXO and is used to carry script state information. It is frequently used in combination with a redeemer, which is like an instruction or command to the contract.

With the Vasil hard fork, developers can see redeemers for all inputs rather than just the one being passed to the currently executing script.

**Collateral change address**

Script collateral is the monetary guarantee a user gives to assure that the transaction that uses a contract has been carefully constructed and thoroughly tested before submission to the validators. It is used to guarantee that nodes are compensated for their work in case phase-2 validation fails. The collateral amount is specified at the time of constructing the transaction and is reserved to allow for the on-chain script execution.

With the Vasil hard fork, DApp developers can specify a change address for the script collateral. This means that in case the script fails phase-2 validation, only the right amount will be taken, and the remaining funds will be sent to the provided change address.

See the [how to use collateral outputs](https://github.com/perturbing/vasil-tests/blob/main/collateral-output-cip-40.md) tutorial for more details.

**Single VRF implementation**

On Cardano, the Verifiable Random Function (VRF) determines which SPO creates the next block. Before Vasil, there were two VFR functions executed on every network hop to validate a block. With the Vasil hard fork, one of these functions is dropped, resulting in faster block validation and overall network syncing times.

VASIL

## **VALENTINE (SECP)**

The Valentine (or SECP) upgrade is Cardano’s intra-era hard fork that followed the Vasil upgrade. Valentine was a small and focused semantic change to the ledger, which brought new built-in functions to Plutus to support SECP elliptic curves (ECDSA and Schnorr). Although an intra-era hard fork requires a hard fork combinator event, it does not change the ledger era, which means that this was an upgrade to the Babbage ledger era.

**About ECC**

ECC is a popular primitive for developing cryptographic protocols and secure applications using custom encryption and decryption algorithms validated by digital signatures. ECC provides the same level of security as other mechanisms while using shorter keys and signatures.

There are different elliptic curves one can use, with secp256k1 as one of the options. Each of these curves differs in its parameters. The secp256k1 curve provides two common signature schemes – ECDSA and Schnorr.

Cardano uses the Edwards-curve Digital Signature Algorithm (EdDSA) with elliptic curve Curve25519 as its base curve (Ed25519). Ed25519 is designed to be resistant to certain types of cryptographic attacks, making it a secure choice.

Ed25519 is part of the family of [safeCurves](https://safecurves.cr.yp.to/), which secp256k1 is not part of. The variance in algorithms means that Plutus DApp developers who want to work with other blockchains and need to validate ECDSA and Schnorr signatures would have to spend time, effort, and funds to implement such algorithms over the Standards for Efficient Cryptography (SECP) elliptic curves in Plutus. This extra implementation considerably increases potential security risks.

Since only Cardano’s primary signature algorithm Ed25519 was provided as a Plutus built-in function, ECDSA and Schnorr operations would be more expensive and time-consuming unless also provided as built-in functions.

**What did the SECP upgrade bring?**

Cardano’s Valentine upgrade added new built-in functions to Plutus to support ECDSA and Schnorr signatures along with Cardano’s native signature.

These built-in functions are now native to Cardano, and since they are implemented and audited by experts, they provide the highest level of security. This standardization allows any Plutus DApp developer to widen the choice of multi-signature or threshold signature design to use.

[CIP-49](https://github.com/mlabs-haskell/CIPs/blob/c5bdd66fe49c19c341499f86cebaa2eef9e90b74/CIP-0049/README.md) provides a more in-depth oversight of the motivation and specification for the new implementation of built-in functions.

After the new cryptographic primitives implementation, Plutus can easily verify transactions from other blockchains using ECDSA and Schnorr standards. For example, Plutus can natively verify signatures generated in EVM sidechains, which improves the developer experience in terms of process simplicity, cost, and advanced security.

![](https://ucarecdn.com/7c41014d-2a03-493e-83f1-054c6e3ac78f/)

**Example scripts**

Below is a link to examples of scripts and script data files containing the inputs for working with SECP256k1 elliptic curves.

The use of these scripts is similar to a [token minting process](https://github.com/input-output-hk/cardano-node-wiki/blob/main/docs/reference/plutus/plutus-minting-script-example.md), where you build a transaction to mint a token using `--mint-script-file` with a provided Plutus script and `--mint-redeemer-file` for provided input script data.

See the tutorial on [how to use SECP256K1 primitives](https://github.com/input-output-hk/Vasil-testnet/blob/main/secp-primitives-cip.md).

VALENTINE (SECP)

## **CHANG**

The Chang upgrade ushered in the Conway ledger era, a deeply transformative advancement for Cardano's governance, where any ada holder can submit or participate in the voting process for governance actions. The upgrade is happening in two stages, Chang #1 and Chang #2, now known as the Plomin hard fork.

Conway, named after the eminent mathematician [John Horton Conway](https://en.wikipedia.org/wiki/John_Horton_Conway), builds upon previous phases, emphasizing decentralized decision-making and enhanced smart contract functionalities.

In November 2024, following the sudden passing of Matthew Plomin, the hard fork working group recommended to rename the second upgrade after him. As a founding partner of the USDM Stablecoin, Matt was instrumental in the construction and regulatory compliance of groundbreaking financial technologies. The renaming has been widely affirmed by the community in a following governance info action.

**What does Chang enable?**

**info**

Learn more about Cardano governance and related terminology in [CIP-1694](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1694) and [this glossary](https://docs.intersectmbo.org/cardano-governance/key-terms/general-glossary).

Chang enables on-chain participatory governance through the implementation of mechanisms outlined in CIP-1694. This upgrade ensures transparency, inclusivity, and resilience of governance within the Cardano ecosystem. The Conway era is based on liquid democracy, which enables individual empowerment through democratic consent by leveraging a voting process with the option of direct and representative voting. Ada holders can vote individually on every governance matter, or delegate their voting power to [delegate representatives (DReps)](https://iohk.io/en/blog/posts/2022/04/11/introducing-the-concept-of-delegate-representatives-dreps/) they trust in decision making. DReps consolidate the voting influence of numerous ada holders, ensuring that each participant can contribute to the future of Cardano’s development.

With the introduction of [PlutusV3](https://iohk.io/en/blog/posts/2024/02/12/unlocking-more-opportunities-with-plutus-v3/), Plutus scripts are available for use as part of the governance system, enabling sophisticated voting possibilities like supporting DAOs, for example. Chang also brings advanced Plutus cryptographic primitives, other new primitives, and performance enhancements to the platform. These additions provide developers with a richer smart contract creation toolkit, enhancing both developer and user experiences, and unlocking new possibilities for decentralized applications (DApps) on Cardano.

**Chang’s key features**

**Decentralized governance mechanisms**: through Chang, Cardano institutes on-chain decentralized governance mechanisms including a constitutional committee (CC), DReps, and a new governance role for stake pool operators (SPOs), fostering community-driven decision-making processes.

**On-chain voting**: Chang facilitates on-chain voting for governance actions, allowing stakeholders to propose and vote on protocol changes and other governance-related matters.

**PlutusV3 ledger language**: [PlutusV3](https://iohk.io/en/blog/posts/2024/02/12/unlocking-more-opportunities-with-plutus-v3/) introduces advanced Plutus primitives and cryptographic capabilities, enhancing the platform's smart contract functionalities. Cryptographic primitives are central to every blockchain, including hash functions, digital signatures, and zero-knowledge proof (ZKP) systems. These elements are designed for computational efficiency, ensuring robust security for their applications. PlutusV3 enhancements include:

- **BLS12-381 primitives**. This collection of new built-in functions is fundamental for cryptographic operations that allow for efficient verification of zero-knowledge proofs.
- **New hash primitives**. Blake2b-224 and Keccak-256 are new cryptographic hash functions used for validating transaction signatures (improving compatibility with Ethereum), and secure data verification respectively.
- **Sums of products (SOPs)**. PlutusV3 introduces SOPs, a new approach to encoding data types in Plutus Core. This method improves script efficiency and code generation for Plutus Core compilers, leading to faster program execution and streamlined smart contract development.
- **Bitwise primitives**. The Chang upgrade brings two new bitwise primitives – `integerToByteString` and `byteStringToInteger`. Additional primitives will be added to Plutus V1, V2, and V3 with future upgrades. These primitives offer robust capabilities for low-level bit manipulations. This enhances performance optimization, cryptographic support, integer-string conversions, and efficient algorithms and data structures within smart contracts.

**Additional functionalities you can expect**

Conway also introduces several new functionalities:

- Reference scripts are enabled for Plutus V1 scripts. This enables legacy scripts to take advantage of reference scripts, reducing DApp costs and increasing on-chain capacity.
- The `minFeeRefScriptsCoinsPerByte` protocol parameter refines the Plutus cost model and improves fee calculations by allowing separate tuning of the costs for reference scripts.
- Adjustments to SPO deposits: SPO deposits are tracked individually, distinguishing between stake address registration deposits and stake pool registration deposits. This distinction has been retroactively applied all the way back to Shelley, facilitated by the static nature of deposits since their introduction.
- General ledger rules improvements.

**The Chang upgrade in stages**

Chang is gradually implemented in two stages. The first stage established foundational governance features, and the second will emphasize community-driven decision-making and governance.

First stage/bootstrapping

The first stage was completed in August, 2024. Its purpose is to enable initial governance features and lay the groundwork for Conway-era functionality. During this time, DReps can register, and ada holders can delegate their voting power. PlutusV3 was introduced, which included new governance features.

An [interim constitution](https://docs.intersectmbo.org/cardano/cardano-governance/cardano-constitution/interim-cardano-constitution) was established with safeguards supported by a technical guardrails script. An interim constitutional committee oversees the constitutionality of governance actions during the interim period, prior to ratification of a full constitution. The bootstrap period is used to form the group of DReps. Limited governance actions are supported, including parameter changes, hard forks, and 'Info' actions.

During the interim period, only SPOs and the interim constitutional committee can vote on governance actions, including possible protocol parameter changes. As an exception, DReps can participate in 'Info' actions at this stage.

The goal of the first stage is to ensure security and continuity during the governance bootstrapping phase, allowing DReps to register and campaign for delegation, while developing and ratifying a final constitution.

**The second stage/on-chain decision making**

The second stage, which emphasizes decentralized governance, will be initiated by the community after the bootstrap period is complete. The governance action to approve this Plomin hard fork was submitted on chain at the end of epoch 529, December 20, 2025 at 21:44 UTC. [Intersect](https://www.intersectmbo.org/) will oversee, establish, and help facilitate the community in self-government initiatives for the Cardano ecosystem. All governance entities, including DReps, SPOs, and the interim constitutional committee, can vote on governance actions during this stage. The conclusion of this stage will allow for treasury withdrawals.

**The Cardano constitution**

The Cardano Constitutional Convention was held simultaneously in Buenos Aires - Argentina, and Nairobi - Kenya from December 4 to 6, 2024. After 63 workshops across 51 countries, participants came together to refine and strengthen the constitution. The draft constitution was agreed to by 95% of elected delegates.

The delegate-approved Cardano constitution is the foundational document that translates the community’s values and decisions into a clear set of principles, rules, and responsibilities. It defines the governance framework for the Cardano ecosystem, outlining stakeholders' roles and obligations, including DReps, SPOs, and others. This constitution guides Cardano toward becoming a sustainable platform for Web3 products and services.

**Start testing on SanchoNet**

Developers and enthusiasts eager to explore the new features introduced by the Chang upgrade can [begin testing on SanchoNet](https://sancho.network/get-started/).

SanchoNet is the testnet for rolling out governance features for the Cardano blockchain, aligning with the comprehensive CIP-1694 specifications. SanchoNet stands apart from other testnets; it's a vibrant, inclusive, and community-driven platform. Every community member is invited to join SanchoNet and actively contribute to shaping Cardano's governance future.

As SanchoNet advances in its journey of implementation and feature rollout, the community is encouraged to embrace specific roles crucial for testing and refining the governance mechanisms:

- Testnet ada holders: as a testnet ada holder, your role is paramount. You can engage in crafting and submitting governance actions, and your insights will be invaluable to ensure that the governance system upholds the highest standards of security and efficiency.
- SPOs: SPOs are the backbone of any blockchain network, and on SanchoNet, it's no different. As an SPO, you can take charge and run the testnet network with diligence and integrity and by voting on relevant actions. Your feedback will be invaluable.
- DReps: DReps are the voice of the broader community. As a representative, your role involves participating in voting on governance actions. You can consider the collective interests of the community as you engage in these important decisions.
- SanchoNet is more than just a testnet, it is a playground of opportunities. Within this space, the community can collaboratively create a governance system that is robust, decentralized, and truly community-driven. Your involvement, dedication, and passion will be the driving force behind SanchoNet's success.

**Chang readiness**

You can check [engineering and ecosystem readiness for the Plomin upgrade here](https://cardanoupgrades.docs.intersectmbo.org/plomin-upgrade/chang-upgrade-2-readiness).

CHANG

UPGRADE EXPLAINED

## **CONTRIBUTION GUILDLINES**

The Cardano Docs site follows the principles of open-source collaboration, inclusiveness, and community-driven success. Contributing to Cardano Docs helps create a rich, accurate, and up-to-date resource for the entire Cardano community. By sharing your knowledge and expertise, you ensure the documentation remains a valuable and reliable source of information for all.

Note that Cardano Docs focuses on providing information about Cardano's functionalities and features, while the [Developer Portal](https://developers.cardano.org/) offers developer-related tutorials and guides. These two resources exist in tandem, ensuring a seamless user experience for both general users and developers.

By using this website and contributing to Cardano Docs, you agree to be bound by and comply with the CC BY 4.0 license.

**What to contribute?**

You can contribute in several ways, including:

- **Edits**: spot typos or inaccuracies? Fix them!
- **Feature overviews**: suggest additional overviews or functionality explainers relevant to Cardano
- **References**: add more references to community-driven projects or resources
- **Graphics**: contribute with graphics, infographics, etc. Please refer to the [Cardano branding assets](https://cardano.org/brand-assets/) for this.

**How to contribute?**

**Creating a pull request**

1 . **Find the page**: navigate to the page you want to edit
2 . **Edit the page**: click the ‘Edit this page’ button
3 . **Make changes**: make changes using [Markdown (MD) formatting](https://docusaurus.io/docs/next/markdown-features) and adhere to the style guidelines (please see below)
4 . **Create a pull request**: submit your changes through a pull request.

 <iframe width="1280" height="720" src="https://docs.cardano.org/pull-request-render.mp4" title="How to contribute?
" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe> 

If you prefer working with GitHub locally, follow these steps:

1 . **Fork the repository**: go to the [Cardano Docs GitHub repository](https://github.com/input-output-hk/cardano-documentation) and fork it to your account
2 . **Clone the repository**: clone the forked repository to your local machine
3 . **Create a new branch**: create a new branch for your changes
4 . **Make your edits**: edit the documentation files using MD formatting
5 . **Commit your changes**: commit your changes with a clear and descriptive message
6 . **Push to GitHub**: push your changes to your forked repository
7 . **Submit a pull request**: open a pull request from your new branch to the main repository.

See more about [Docusaurus set up here](https://github.com/input-output-hk/cardano-documentation?tab=readme-ov-file#website).

**Raising an issue**

By raising an issue, you can identify areas for improvement, report problems, or suggest new content.

To create an issue:

1 . Go to the GitHub repository: navigate to the Cardano Docs [GitHub repository](https://github.com/input-output-hk/cardano-documentation)
2 . Create a new issue: click ‘Issues’ and then ‘New issue’
3 . Describe the issue: provide a clear and detailed description of the issue or suggestion
4 . Submit the issue: click ‘Submit new issue.’

Your contributions are vital to maintaining the quality and integrity of Cardano Docs. Whether you’re correcting a typo, adding new content, or suggesting improvements, every contribution helps. Thank you for being an active Cardano community member and helping make Cardano Docs an invaluable resource for everyone.

**Style guide**

**General notes**

Ensure simplicity, accuracy, and accessibility. Aim for a broad understanding, even for select audiences. Be concise – avoid unnecessary words.

**Style principles**

**Language**

- Use American English: -ize rather than -ise endings, ‘color’ instead of ‘colour’
- Avoid slang words
- Use gender-inclusive pronouns – they/their/them
- Active voice, avoid passive.

**Abbreviations and acronyms**

- No full stops in abbreviations: eg, ie, PhD, etc, v (note, not vs), plc, Inc
- Write acronyms as said (eg, radar, laser, captcha), use initial caps for entities, avoid capitalization
- Minimize the use of acronyms and initialisms. Spell out on first use, eg peer-to-peer (P2P)
- Refer to the [Cambridge dictionary](https://dictionary.cambridge.org/).

**Legal and investment**

- Avoid investment or legal advice.

**Punctuation**

- Use the Oxford/serial comma
- Use single quote marks: ‘cascading disruption’
- Use en dash – (option-hyphen on a Mac keyboard; Alt-hyphen on PC)
- Use a full stop at the end of the last bullet point.

**Capitalization**

- Lowercase for job titles, degree names, and university departments
- Use lowercase after a colon, eg ‘Feature: this feature is about…’
- Book, film, and game titles should be in italics, and academic papers should be in ‘single quotes’ – avoid subtitles.

**Numbers and time**

- Spell out one to nine: one, two, three, four, five, once I caught a fish alive, except for percentages: 1%, 2%, 3%
- Use numerals for anything higher: 10, 11, 12, 13, 14, 15
- Spell out million, billion when in prose: there are nine million bicycles in Beijing
- Use abbreviations for money: £5m, $10bn, 12tn yen
- When talking generally, use MMMM DD, YYYY format, eg February 1, 2018
- For technical purposes, use ISO 8601 standard for dates and time: YYYY-MM-DD eg 2018-02-01.

**Bullet lists**

- Start with a capital letter and use full stops in complete sentences. You can format the bullet ‘title’ in bold if there is one:
- Feature name 1. This full sentence describes the feature in more detail.
- Feature name 2. This full sentence describes the second feature in more detail.
- Omit full stops in short itemized lists; use it after the last bullet point. For example, the discussed feature includes such items as:

- Item 1
- Item 2
- Item 3.

- In shorter statements, full stops can also be omitted. For example:
- Maintain uniformity across all documentation
- Encourage user interaction with clear instructions
- Incorporate visuals judiciously to enhance understanding.

**Links**

- Write clear and meaningful links; don’t use ‘here’ as a link. Always embed links; don’t just paste one as is.

**Headlines and titles**

- Headlines are ‘Sentence case only’. The limited use of capitals is a way of avoiding confusion for proper names. Use initial caps for navigation section names and topic headings.
- No full stops at the end of headlines, pull quotes, captions, and other display matter, or when referencing figures: just ‘See Figure 1 for details…’.

**Markdown features**

Cardano Docs uses Markdown for formatting. Below are the main Markdown features:

![](https://i.imgur.com/7FwHWee.png)

![](https://i.imgur.com/rcGZdvN.png)

For more details, see [MD features here](https://docusaurus.io/docs/next/markdown-features).

CONTRIBUTION GUILDLINES

Welcome to the central hub for Cardano documentation. Here, you'll find content that describes and supports the features on both the Cardano mainnet and testnet environments.

This includes basic explainers for newcomers to Cardano, explanations of the core features, details about Cardano's design and evolution, insights into how the Cardano network operates, and platform architecture.

Introduction to Cardano

Course Details

Level

Ratings

Modules

Lessons

Holder $WORK Price

Contact Us

Documentation

Navigation