## **OPERATING A STAKE POOL**

Welcome to the stake pool operations section!

Here, you will find explanations about stake pools, operators, and owners, along with core concepts such as node connectivity, keys, operational certificates, metadata management, performance, and ranking.

**info**

To get started with stake pool operations, refer to:

- [Developer portal SPO tutorials](https://developers.cardano.org/docs/operate-a-stake-pool/)
- [Cardano course SPO tutorials](https://cardano-course.gitbook.io/cardano-course/handbook/create-a-stake-pool)
- [The Guild Operators' tutorials.](https://cardano-community.github.io/guild-operators/)



<table><thead><tr><th></th><th></th></tr></thead><tbody><tr><td>Node details</td><td><a href="/developer-resources/release-notes/release-notes">Release notes</a>, <a href="/developer-resources/release-notes/comp-matrix">compatibility matrix</a>, <a href="https://github.com/input-output-hk/cardano-node#overview-of-the-cardano-node-repository" target="_blank" rel="noopener noreferrer">Cardano node repository</a>, <a href="/developer-resources/cardano-node-course">Cardano node video course (includes SPO explainers).</a></td></tr><tr><td>Testnets</td><td><a href="/cardano-testnets/environments">Cardano testnet environments</a>, <a href="/cardano-testnets/tools/faucet">testnets faucet</a>.</td></tr><tr><td>Tools</td><td><a href="https://developers.cardano.org/tools/" target="_blank" rel="noopener noreferrer">Cardano ecosystem tools</a>, <a href="https://www.essentialcardano.io/article/a-list-of-community-built-developer-tools-on-cardano" target="_blank" rel="noopener noreferrer">community-built developer tools</a>.</td></tr><tr><td>Explorers</td><td><a href="https://adastat.net/transactions" target="_blank" rel="noopener noreferrer">AdaStat</a>, <a href="https://adatools.io/" target="_blank" rel="noopener noreferrer">Adatools</a>, <a href="https://cardanoscan.io/transactions" target="_blank" rel="noopener noreferrer">Cardanoscan</a>, <a href="https://cexplorer.io/" target="_blank" rel="noopener noreferrer">Cexplorer</a>, <a href="https://cardanoassets.com/" target="_blank" rel="noopener noreferrer">Cardano Assets</a>, <a href="https://pool.pm/tokens" target="_blank" rel="noopener noreferrer">Pool.pm</a>, <a href="https://www.adatainment.com/index.php?page=home&amp;lang=en" target="_blank" rel="noopener noreferrer">ADAtainment</a>, <a href="https://pooltool.io/" target="_blank" rel="noopener noreferrer">Cardano PoolTool</a>.</td></tr><tr><td>SPO alliances</td><td><a href="https://cardano-community.github.io/guild-operators/" target="_blank" rel="noopener noreferrer">Guild Operators</a>: a group of well-known and experienced community members that provides information about guild tools that simplify various stake operations, <a href="https://singlepoolalliance.net/" target="_blank" rel="noopener noreferrer">Cardano Single Pool Alliance (SPA)</a>: a group of separate SPOs who have vowed to run a single stake pool for the sole purpose of providing the Cardano ecosystem with true decentralization, <a href="https://www.xspo-alliance.org/" target="_blank" rel="noopener noreferrer">xSPO Alliance</a>: a group of small SPOs that joined with a total live stake of less than one million ada each.</td></tr><tr><td>Communication channels</td><td><a href="https://t.me/SPOannouncements" target="_blank" rel="noopener noreferrer">SPO Telegram announcements channel</a>, <a href="https://discord.com/invite/5kaErDKDRq" target="_blank" rel="noopener noreferrer">IOG Technical Community Discord</a>, <a href="https://iohk.zendesk.com/hc/en-us" target="_blank" rel="noopener noreferrer">support</a>.</td></tr></tbody></table></div></article><nav class="pagination-nav docusaurus-mt-lg" aria-label="Docs pages"><a class="pagination-nav__link pagination-nav__link--next" href="/stake-pool-operators/about-stake-pools"><div class="pagination-labels-wrapper"><div class="pagination-nav__sublabel">

OPERATING A STAKE POOL

## **ABOUT STAKE POOLS, OPERATORS, AND OWNERS**

A [stake pool](https://docs.cardano.org/about-cardano/learn/stake-pools) is a reliable server node that represents the combined stake of various stakeholders in a single entity. Stake pools use the [Cardano node](https://docs.cardano.org/learn/cardano-node/) to form the backbone of the Cardano network by processing transactions and validating and producing blocks.

Stake pool roles include a stake pool operator and one or more stake pool owner(s). It is important to note the conceptual differences between the two:

- A stake pool operator is the owner of the cold and VRF signing keys used to create the stake pool. The operator configures and maintains stake pool infrastructure and is responsible for monitoring it. The operator can register, re-register, or retire a stake pool, update certificates, and ensure that the block-producing node can sign and validate blocks and process transactions.
- A stake pool owner is determined by the stake signing keys used in stake pool creation. The owner's pledge stake is intended to provide protection against Sybil attacks.

Usually, the stake pool operator and the owner are the same person. However, a stake pool can have multiple owners that choose to combine their pledge. It should be noted that the stake pool's declared pledge must be met by the combined stake in the owner's wallets and failure to do so will result in the pool being unable to produce blocks.

All operator and owner rewards are paid out into a single rewards account associated with the reward address of the pool. If a stake pool has multiple owners, it is up to the owner of the rewards account to distribute rewards to the operator and other owners.

An agreement is likely needed to define when and how the accumulated rewards in a shared account should be split. For example, they can agree to have the operator control the shared account, or they can choose to use a multisig account.

To run a pool effectively, a bi-directional relationship and trust are crucial. If this trust is broken, other parties can lose in regards to accumulated or potential rewards, or reputation for the operator.


**info**

Developer resources:

- [Stake pool operations overview](https://developers.cardano.org/docs/operate-a-stake-pool/)
- [Cardano course: creating a stake pool](https://cardano-course.gitbook.io/cardano-course/handbook/create-a-stake-pool)

ABOUT STAKE POOLS, OPERATORS, AND OWNERS

## **ESTABLISHING CONNECTIVITY BETWEEN THE NODES**

Nodes connect to each other within the Cardano networking layer, and this connection is essential for information exchange about transactions and new block creation.

**Cardano networking**

Cardano's networking evolved from its initial federated structure to hybrid and the Dynamic peer-to-peer (P2P) model. Networking will keep evolving with future additions such as Ouroboros Genesis and peer-sharing. See [this explainer](https://docs.cardano.org/about-cardano/explore-more/cardano-network/p2p-networking) for more details about network evolution and P2P.

In a previous hybrid setup, SPOs could configure a node to connect to, for example, 50 other SPO nodes. This is a pretty large number, since many nodes can be offline, change their addresses, etc. While 20 connections are enough for efficient communication, SPOs had to over-provision because of the static configuration.

In a Dynamic P2P setup, SPOs can target to configure 20 connections, which can be picked from thousands of SPO relays, not just 50. And if any are offline, or go offline, the setup will automatically pick new ones, to meet the set target. This means that the configuration is no longer limited to a static pool of 50 peers.

**Connecting core and relay nodes**

As a stake pool operator, you will have two types of nodes: core nodes and relay nodes. Each core node must be accompanied by one or more relay nodes.

The difference between the two types is that core nodes are responsible for producing blocks, while relays are responsible for communicating with other relays in the network and broadcasting blocks. This difference determines how they are configured and how they are connected to the network.

A core node is configured with various key pairs and an operational certificate required for block generation. It only connects to its relay nodes.

**info**

Developer resources:

- [Stake pool networking](https://developers.cardano.org/docs/operate-a-stake-pool/stake-pool-networking)
- [Cardano relay configuration](https://developers.cardano.org/docs/operate-a-stake-pool/cardano-relay-configuration)
- [Configurations and setup](https://cardano-course.gitbook.io/cardano-course/handbook/create-a-stake-pool/the-setup)

ESTABLISHING CONNECTIVITY BETWEEN THE NODES

## **LOGGING AND MONITORING**

Regular monitoring of active nodes is crucial to determine if the node is running optimally, if the system is performant, or if fine-tuning is required.

**info**

Developer resources:

- [Cardano course: monitoring the nodes](https://cardano-course.gitbook.io/cardano-course/handbook/monitoring-our-nodes)
- [Monitoring with gLiveView](https://developers.cardano.org/docs/operate-a-stake-pool/monitoring-gLiveView)
- [Grafana dashboard tutorial](https://developers.cardano.org/docs/operate-a-stake-pool/grafana-dashboard-tutorial)

LOGGING AND MONITORING

## **CREATING KEYS AND OPERATIONAL CERTIFICATES**

**About the stake pool operator keys**

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 that has internet connectivity. It is recommended that you have multiple backups of your cold keys.

The keys that you need as a stake pool operator are:

- stake pool cold key
- stake pool hot key (KES key)
- stake pool VRF key.

The KES key, or hot key as mentioned above, is a node operational key that authenticates who you are. You specify the validity of the KES key using the start time and key period parameters and this KES key needs to be updated every 90 days. The VRF key is a signing verification key and is stored within the operational certificate.

**info**

Developer resources:

- [Generating wallet keys](https://developers.cardano.org/docs/operate-a-stake-pool/generating-wallet-keys)
- [Generating block-producing keys](https://developers.cardano.org/docs/operate-a-stake-pool/block-producer-keys)
- [Cardano course: generating keys.](https://cardano-course.gitbook.io/cardano-course/handbook/create-a-stake-pool/generate-keys)

**Creating an operational certificate and registering a stake pool**

Stake pool operators must provide an operational certificate to verify that the pool has the authority to run. The certificate includes the operator’s signature and important information about the pool (addresses, keys, etc.)

Operational certificates represent the link between the operator’s offline key and their operational key. A certificate’s job is to check whether or not an operational key is valid, to prevent malicious interference. The certificate identifies the current operational key, and is signed by the offline key.

Certificates are generated with an issue counter number and included in the header of each block the node generates.

Certificates include a kes-period (start date), which indicates the period within which the certificate is valid before you need to create another one.

Certificates are generated on the offline machine using the offline/cold keys, before being copied over to the node to validate the KES keys used to sign the blocks.

**info**

Developer resources:

- [Registering a stake address](https://developers.cardano.org/docs/operate-a-stake-pool/register-stake-address)
- [Registering a pool](https://developers.cardano.org/docs/operate-a-stake-pool/register-stake-pool)
- [Cardano course: registering a stake pool.](https://cardano-course.gitbook.io/cardano-course/handbook/create-a-stake-pool/register-stake-pool)


CREATING KEYS AND OPERATIONAL CERTIFICATES

## **STAKE POOL OPERATIONS AND MAINTENANCE**

After a successful stake pool registration and its further operation, SPOs might be interested in obtaining certain information about their pools’ activity. Information about those pools that are operating on mainnet can be fetched using different explorer tools. See [introduction](https://docs.cardano.org/stake-pool-operators/operating-a-stake-pool) for useful resources.

In certain cases, exchanges and stake pool operators, in particular, are looking for in-depth information about their mainnet and testnet pools. To access data that is stored on the Cardano blockchain, it is recommended to use [cardano-node](https://github.com/input-output-hk/cardano-node), [cardano-db-sync](https://github.com/input-output-hk/cardano-db-sync), or [cardano-graphql](https://github.com/input-output-hk/cardano-graphql).

Each of the above integration components can be installed and easily deployed using Docker.

**info**

Developer resources:

- [Cardano course: operations and maintenance](https://cardano-course.gitbook.io/cardano-course/handbook/create-a-stake-pool/pool-maintainance)
- [Developer portal: operator tools](https://developers.cardano.org/docs/operate-a-stake-pool/guild-ops-suite)

STAKE POOL OPERATIONS AND MAINTENANCE

## **POOL METADATA MANAGEMENT**

Stake pools are registered on-chain, and their on-chain data (such as information required to calculate rewards) is critical to the operation of the ledger. Stake pools also possess metadata that helps users make a rational choice of a stake pool to delegate to. This metadata is stored off-chain as it might reflect sensitive content, and such an approach allows for a degree of decentralized censorship.

On the other hand, off-chain metadata storage prerequisites a challenge of open access by different users. On-chain stake pool registrations contain a URL pointer to the off-chain metadata and a content hash that can be fetched from a specific stake pool. This might cause both performance and privacy issues. Another crucial aspect to address is the stake pool’s 'ticker' name, which is the short name a stake pool is recognized by. Ticker names might reflect prominent brands or trademarks which should not be duplicated as this leads to confusion. Stake pool operators (SPOs) running multiple pools might want to use the same metadata for all their pools and then, this might also lead to these pools appearing with the same ticker name.

**Use cases**

A stake pool metadata aggregation server (SMASH) is introduced to address metadata performance and privacy issues. Delegators, SPOs, exchanges, or wallets can deploy and use SMASH to ensure a higher level of metadata accountability and maintenance. SMASH aggregates metadata from existing stake pools and provides an efficient way to fetch it and store it in a semi-centralized environment. SMASH operators (exchanges, wallets, SPOs) are then enabled to validate and manage this metadata curating it for censorship via the delisting feature.

**Run your own**

The first generation of the SMASH server has been deployed by Input Output Global (IOG). It aggregated stake pool metadata and offered a list of valid stake pools with reviewed content and ticker names. Nowadays, various solutions exist to synchronize data from the chain and a SMASH server is provided out-of-the-box as part of the cardano-db-sync project.

For running your own, see [these Cardano DB Sync instructions](https://github.com/IntersectMBO/cardano-db-sync/blob/master/doc/smash.md#smash-characteristics).

POOL METADATA MANAGEMENT

## **STAKE POOL PERFORMANCE**

A stake pool elected as a slot leader is responsible for producing new blocks for the Cardano network. If the stake pool does not produce a block, the slot will remain empty and the blockchain will not be extended. The Cardano blockchain can tolerate a number of missing blocks, but the majority of blocks expected to be produced (at least 50% + 1) must be generated during an epoch.

Although occasionally missed blocks don’t affect the extension of the blockchain as a whole, an unresponsive elected stake pool decreases the overall performance of the network, which is undesirable.

Stake pool performance is calculated according to its expected activity as the ratio of a number of blocks a stake pool produces in a given epoch versus the number it was capable to produce. For instance, if the stake pool could produce 100 blocks (based on its stake and the chance to be elected) in an epoch, but it actually produced just 50 blocks, its performance would be 50%.

Poor stake pool performance decreases the number of rewards that a pool and its members receive, thereby decreasing its attractiveness to delegators. To improve its performance, a stake pool should have good network connectivity, be run on a reliable system, and actively participate in block production and verification.

The higher the pool’s performance, the more attractive it will be to delegators since it will offer higher rewards and incentives.

STAKE POOL PERFORMANCE

## **STAKE POOL RANKING**

In the Daedalus wallet and Cardano Explorer, stake pools are ranked based on the amount of rewards that users will receive if they choose to delegate to those pools. Ranking shows pool saturation level, simplifying the pool choice. From a delegator's perspective, once a pool reaches a certain saturation point, it will no longer be beneficial to delegate to it. The most attractive stake pools are displayed first and ordered from the top down.

The ranking system is designed to provide users with the ability to choose the most suitable stake pool for a higher return on investment (ROI), so reliable stake pool operators can maintain and support the system and maximize decentralization.

**Ranking parameters**

A pool's ranking is based on several parameters: cost and margin, the pool's performance, and the amount of stake that the pool has already accumulated. These factors promote reliable stake pools that are not yet saturated and provide low cost and margin.

STAKE POOL RANKING

## **GUIDELINES FOR OPERATING LARGE STAKE POOLS**

This section provides guidelines for operators of large stake pools, specifically how to manage the risks and complexity of maintaining significant stake or multiple pools. Operators of smaller stake pools may also find much of this advice useful to them.

**Main recommendations**

1 . **Consider reliability and robustness**. Stake pools require high-reliability servers with:

- Resilient compute capability.
- Robust networking capability.

2 . **Consider networking requirements carefully**:

- High bandwidth connections are essential to run a relay node (e.g., 5 Mbit/s + 0.1 Mbit/s per downstream peer as a capacity planning number).

3 . **Operate sufficient relay nodes** as well as stake pools:

- Relay nodes are necessary for the maintenance of the network.
- Provision two relay nodes for each active stake pool.

4 . **Be aware of system and network performance**, especially if using virtualized or shared servers:

- Each stake pool may need its own dedicated hardware resources (compute, memory, and network).
- It is recommended to use different servers for stake pools and relay nodes.
- Virtualization may complicate the process of determining whether stake pools have adequate resources.

5 . **Do not replicate stake pools** on the network:

- Stake pool replication is adversarial behavior, which may lead to blocks being rejected.
- Use high-reliability techniques to switch between duplicate or back-up servers without exposing both simultaneously to the network.

6 . **Stake pools should have limited network connections**:

- This reduces stake pool exposure to denial-of-service (DOS) attacks and improves performance.
- Relay nodes should handle the larger portion of network traffic.
- Stake pools should only be connected to trusted nodes (relay and/or stake generating).
- Stake pools and relay nodes should restrict the services that are exposed (e.g., using a firewall).

7 . **Security is paramount**:

- Use airgapping when signing transactions – do not store cold keys on an online server (including the one that is running a stake pool or a relay node).
- Use hardware wallets for high-value private keys, where possible.
- Where private keys cannot be stored in hardware wallets (e.g., cold keys), store them offline.
- Be aware of and plan for enforced key rotations using the key evolving signature (KES) scheme.

**Managing risks and complexity**

Operating stake pools effectively is crucial to ensure the long-term health and liveliness of decentralization on Cardano. When a stake pool operator (SPO) operates multiple stake pools (or has a single pool that directly controls a significant percentage of the total staked ada), they may have a significant effect on the overall system throughput as a consequence of the “proof-of-stake” principle.

The Cardano design and security analysis assume that each stake pool operates in a broadly independent and mutually supportive (non-adversarial) manner. This means that large SPOs have a particular responsibility to ensure that their operation supports the needs of the network as a whole. For this, it is essential to evaluate and address common risks that may be experienced in stake pool operations.

**Virtualization and containerization risks**

Because stake pools and relay nodes have specific real-time requirements, it is generally not recommended to run Cardano nodes on virtualized resources without undertaking careful performance, reliability, and security analyses. The mapping of Cardano nodes to the underlying physical infrastructure must consider timing issues for block production and propagation.

**Security and common-mode failures**

The risks of operating a stake pool using container-based virtualization include increased chances of common-mode system failures, resource contention, and increased exposure to security risks (including DOS attacks and loss of private keys). The use of containerized environments, where relay nodes share the same physical infrastructure as stake pool nodes, may impact real-time requirements on block production and networking infrastructure, thus reducing stake pool income. Moreover, concentrating network connections (as may happen with virtualized or containerized services) increases the chances of a DOS attack, as well as reduces network redundancy in non-obvious ways. In a virtualized or shared environment, a single NIC/cable failure or DOS attack, for instance, might then affect multiple stake pools or relay nodes, including those that might be run by different SPOs.

**Shared resources**

The diffusion of a newly minted block causes a “pulse” of activity to occur. Stake pools and relay nodes that share physical computing resources will be forced to compete for shared CPU, memory, storage, networking, and other resources. The demand for these resources is not smooth, it is correlated by the block diffusion. This can negatively affect block production or result in blockchain synchronization failures. Under some conditions, performance can degrade in a non-linear way (e.g., adding a second node may reduce performance by more than 50%). To eliminate such risks, it is important to analyze performance requirements not only for the typical load but also for limit cases.

**Maintenance and upgrade**

System maintenance and upgrades should be always taken into consideration. Although migration of a virtualized instance to new hardware, or duplication of a running instance might seem easy, this commonly results in some timing disruption. This is more significant in a real-time setting (such as Cardano) than for typical data processing applications, which often have high levels of replication and redundancy. System upgrades may also have unexpected effects on the virtualized system’s performance, or occasionally, functionality. SPOs, therefore, need to be aware of underlying system maintenance and take appropriate action to avoid losing blocks (and income).

**Geographical and physical concentration**

Virtualized systems are often concentrated into a few large data centers. This creates potential points of common network failures, including reliance on specific portions of national infrastructures (internet backbones, power grids, etc). Large SPOs should aim to disperse their operations across multiple regions, and very large operators should aim for a global presence.

**Provisioning**

To ensure overall network resilience and robustness, SPOs that operate large stake pools must take special care of:

**Stake pool configuration**

1 . Network configurations should ensure sufficient connectivity to other stake pools (including those that are run by other operators).

2 . The effects of virtualization should be considered carefully: given the pulsed-nature of block diffusion, it is easy to overload physical compute, memory, and networking resources. Unlike a typical database or web service operation, Cardano stake pools have real-time compute and networking requirements. Failure to observe these requirements may have an impact on stake pool returns. It is generally not recommended to share server resources between multiple stake pools or relay nodes.

3 . Stake pools should always be supported by sufficient relay nodes (two or more). This reduces the risk of a single relay node failure, which can potentially isolate a block-producing node. Failure of a block-producing node should only affect block production for that single stake pool. It is particularly important that large SPOs take on this responsibility since they are receiving a higher proportion of the operating rewards for the network.

4 . To support the relay capacity scaling, it is desirable to use DNS names that map to multiple IP addresses and/or use multiple on-chain DnsName entries. Ideally, these entries should be supported over disjointed network infrastructure (e.g., different ISPs or physical paths).

**Security preferences**

1 . Cold keys should never be stored on active servers (especially cloud servers).

2 . Payment keys should be kept separate from block signing keys. Airgaps should be maintained between stake pools and systems used for transaction signing.

3 . Hardware wallets or other secure means should be used to protect cold keys. One hardware wallet may be needed per set of keys (e.g., per stake pool), and these may need to be physically secured.

4 . Back-up keys should be also securely maintained for each stake pool.

**General advice:**

1 . Consider hardware performance, including memory, storage, and networking capabilities.

2 . Perform failure-mode-effects analysis to ensure that single failures of a delivery component are suitably constrained.

3 . Carefully consider containerization and virtualization performance to eliminate excessive contention for common resources (e.g., CPU cores).

4 . Submit stake pool certificates that include both the IP address and DNS names.

5 . Ensure that suitable monitoring is in place:

- Receiving the vast majority of (>90%) blocks within 4,000ms of their associated slot time.
- Track block production times to ensure that allocated resources remain sufficient (this will increase as transaction rates and block sizes increase).

6 . Plan the expansion of relay nodes (potentially at a different location) that are associated with your stake registration (DDoS mitigation / rapid increases in load due to increase of delegation to SPO’s stake pools, etc.).

7 . Plan for regular maintenance events (to minimize stake pool downtime and/or to perform maintenance when the leadership schedule indicates a good interval).

8 . Plan and exercise disaster recovery every 3 to 6 months.

9 . When operating multiple stake pools, spread out your block producer nodes across multiple continents to limit block production disruption and eliminate large-scale network outages.

**Example system and relay topology configurations**

There is no standard system configuration as every stake pool has different operational requirements and preferences. It is the choice of an SPO on how to configure the topology.

However, taking into account the earlier advice, it is recommended that an SPO maintains at least two and an additional relay node(s) per a stake pool. In the case of running multiple stake pools, it is best that SPOs use geographically diverse peers, spread relay nodes across the world, and reach out to other SPOs (particularly other large ones) making agreements to add each other's relay nodes. The more SPOs they have peer-sharing agreements with, the more likely their blocks will propagate and get included in the chain.

Monitoring is important for all SPOs, and it is essentially a responsibility of an operator to ensure the quality of their pools’ functionality. As an example of a monitoring process that reflects Prometheus rules alerting on thresholds, one can take a look at the [cardano-ops repository here](https://github.com/input-output-hk/cardano-ops/blob/master/modules/monitoring-cardano.nix#L13).

**Example relay topology**

Please note that IOHK relay nodes are outlined as examples.

```
{
  "Producers": [
	{
  	"addr": "north-america.relays-new.cardano-mainnet.iohk.io",
  	"port": 3001,
  	"valency": 4
	},
	{
  	"addr": "asia-pacific.relays-new.cardano-mainnet.iohk.io",
  	"port": 3001,
  	"valency": 4
	},
	{
  	"addr": "europe.relays-new.cardano-mainnet.iohk.io",
  	"port": 3001,
  	"valency": 4
	}
  ]
}
```

**Node configuration options**

The `MaxConcurrencyDeadline` configuration option controls how many attempts the node will run in parallel to fetch the same block. Considering that getting the same block as soon as possible is important for both relay nodes and block producer nodes, we recommend setting the MaxConcurrencyDeadline value to 4.

**Delegation and pledging advice**

**Delegation**

Stake delegation is the process of allocating individual stakeholders’ funds to collective stake pools. Delegation is performed for block production purposes to ensure that the block creation complies with the proof-of-stake consensus. By delegating, stakeholders do not transfer stake ownership, voting or other rights.

Large SPOs will generally control a significant amount of third-party stake to maintain trust in the blockchain, thus being responsible for:

- producing blocks
- processing transactions
- maintaining the Cardano network
- ensuring that the owner pledge is made
- securing the pool (e.g., protecting its private keys)
- providing public communications about the pool, including retirement announcements, changes in pricing or other pool parameters.

Large operators are not responsible for distributing block production rewards to delegators as this is handled automatically by the blockchain. SPOs are also not responsible for securing delegator keys or taking delegation, voting, or other actions on behalf of stakeholders. Individual stakeholders must take personal responsibility for their own security and must make their own decisions in terms of delegation, voting, etc.

**Pledging**

Pledging is an important mechanism for producing Cardano’s healthy ecosystem. SPOs may opt to pledge some, or all, of their ada to the pool in order to make it more attractive to other delegators, and thus to grow the size of the pool as a whole. Pledged ada may be supplied either by an SPO or by other owners.

**Pledging rewards**

Pledge influences the rewards that a stake pool can earn, and thus the rewards that delegators can obtain from the pool. The pledging amount may be specified, if desired, during the pool registration, and can then be changed on an epoch-by-epoch basis. No minimum pledge is required, however, there is also no maximum pledge.

Given two equivalent stake pools, the one with the greater pledge will earn more rewards, and therefore be more attractive to other delegators. However, the SPO or other pool owners should collectively meet the pledge by delegating. It is also important to ensure that there are enough funds in addresses that use the pool owner's address(es) as stake reference. **Failure to meet the pledge** will mean that no rewards can be earned for the pool by any owner or delegator. This will generally result in loss of delegation and perhaps pool collapse.

Unlike delegation, the SPO is responsible for distributing all pledging rewards. This may be done in any agreed manner and is not enforced by the blockchain.

Collective stake pool operation (maintained by an operator and a group of owners, pledging their stake) requires mutual trust and is a good way to build a larger pool while sharing the risks and rewards.

**Defense against Sybil attacks**

The pledging mechanism is designed to mitigate against Sybil attacks, which could theoretically allow a proof-of-stake network to be taken over without supplying a significant personal stake. By making pools with higher pledges more attractive, such attacks are prevented. The pledge formula is designed so that a pool with a higher pledge will produce higher rewards and thus become more attractive. To conduct a [Sybil attack](https://iohk.io/en/blog/posts/2018/10/29/preventing-sybil-attacks/), an adversary must divide their pledge amongst a large number of pools. Since this will dilute each pool pledge, delegators will be motivated by the rewards mechanism to re-delegate to non-adversarial pools.

GUIDELINES FOR OPERATING LARGE STAKE POOLS

Here, you will find explanations about stake pools, operators, and owners, along with core concepts such as node connectivity, keys, operational certificates, metadata management, performance, and ranking.

Welcome to the stake pool operations section!

Operating a Cardano Stake Pool

Course Details

Level

Ratings

Modules

Lessons

Holder $WORK Price

Contact Us

Documentation

Navigation