How to Build a Cardano Stake Pool

A Cardano stake pool maintains a full copy of the blockchain, participates in the peer-to-peer network and produces blocks when selected by the Ouroboros protocol. Delegators keep control of their ADA; they do not send funds to the pool operator. They delegate the staking power of their wallet to the pool, and the protocol uses the pool's active stake when assigning block opportunities.

The operator's job is to keep the pool ready. The node must be synchronized, the block producer must be able to sign blocks, the relays must communicate efficiently with the wider network, and the operational certificate must still be valid. You are also responsible for upgrades, monitoring, incident response, metadata, fee settings, pledge and communication with delegators.

What the pool does not do

• It does not take custody of a delegator's ADA.
• It does not choose when it will mint a block.
• It does not guarantee a fixed return.
• It cannot compensate for insufficient active stake by simply using a faster server.

What determines practical success

A minimal production design uses one block producer, at least two relays and a separate air-gapped machine. The relays speak to other Cardano nodes. The block producer speaks only to its own trusted relays. The offline machine stores and uses the most sensitive keys without ever joining a network.

Why at least two relays?

If one relay is offline during maintenance or an incident, the second relay can keep the producer connected. Hosting relays in different providers or regions reduces the chance that one network failure takes down the entire pool. A second relay also lets you perform rolling upgrades instead of disconnecting every path at once.

Optional nodes that become valuable later

A backup producer can shorten recovery time during a failure, but it must never forge simultaneously with the active producer using conflicting operational state. A dedicated monitoring node can collect metrics without adding work to the producer. Larger operations may also separate databases, tracing and public APIs from forging infrastructure.

The official Cardano operator handbook recommends production Linux servers, at least two CPU cores, substantial memory, fast storage and reliable broadband. The exact requirement depends on the database backend and node version, so the release documentation should always be checked before ordering hardware.

Choose storage carefully

Fast local NVMe storage is usually preferable to slow network-attached disks. The database performs many reads and writes, and the chain keeps growing. Do not provision a server with only a few gigabytes of free space after the initial synchronization. Monitoring should warn well before the disk becomes full.

Home server or cloud server?

A home server gives you physical control but depends on local power, internet stability, router configuration and physical security. A cloud server offers easier redundancy and public networking but introduces provider risk and monthly cost. Many operators use cloud relays and a separately hosted producer. The important point is to avoid putting every component in one failure domain.

Pool identity

Choose a clear pool name, a unique ticker, a domain you control and a public website. The current metadata format allows a ticker of 3 to 9 uppercase letters or numbers, a description of up to 255 characters and a homepage URL. Your metadata URL must be public, use HTTPS, stay within the registration limit and return the exact file without redirecting or changing its bytes.

DNS and relay names

Use names such as relay1.example.com and relay2.example.com instead of registering changing IP addresses whenever possible. DNS makes future migrations easier. Current cardano-node versions also support multi-host relay registration through DNS SRV records, but the simpler A/AAAA record model is easier for a first pool to understand and troubleshoot.

Pledge, fixed cost and margin

Pledge is ADA controlled by the owner and committed to the pool. It should remain delegated as declared. Fixed cost is deducted from epoch rewards before margin when the pool earns enough rewards; the current mainnet minimum is 170 ADA. Margin is the operator's percentage of the remaining rewards. A low fee can help marketing, but it must still support long-term infrastructure and maintenance.

The official handbook currently documents cardano-node 11.0.1, but the latest stable release can change. Check the official release page before installing and read the release notes for required libraries, database migrations and configuration changes.

Choose an installation method

• Official release binaries: fastest to install and suitable when you trust the release pipeline.
• Nix build: reproducible and recommended for operators who want to verify the build more closely.
• Source build with GHC and Cabal: flexible but more complex because the exact compiler and cryptographic-library versions must match the release.
• Container image: operationally convenient, but key mounts and container security require extra care.

A simple release-binary workflow looks like this. Replace the version after checking the current official release:

VERSION="11.0.1"
cardano-node --version
cardano-cli --version

# Use the official release artifact for your CPU architecture.
# Verify the source, checksum or signature before installing.

Create a dedicated service account

Run the node under a non-root Linux user with access only to its own configuration, database, socket and hot-key files. Use systemd to start it after reboot, restart it after a failure and capture logs. Do not run the producer from an interactive terminal as your normal production method.

Keep configuration separate from data

Use predictable directories for binaries, configuration, topology, database, sockets, logs and credentials. This makes upgrades and backups easier. The producer and relays can use similar software, but they should have different topology and credential settings.

Relay configuration

A relay listens on its Cardano port, connects to the wider network and accepts the producer as a trusted local peer. Its firewall should expose the Cardano port only as required, along with tightly controlled SSH access. It does not need the cold key, KES key, VRF signing key or operational certificate.

Block producer configuration

The producer should list only your own relays as local roots. Public roots and ledger peer discovery should be disabled for the producer. The producer's Cardano port should not be publicly reachable; allow connections only from your relay addresses. Once the pool is registered, the producer starts with the VRF signing key, KES signing key and operational certificate.

Synchronization

Start the relays first and let them synchronize. Then start the producer through those relays. A new node can obtain the database by normal chain synchronization or by using a trusted current snapshot mechanism such as Mithril, followed by normal verification and catch-up. Do not enable forging until the node is fully synchronized and the keys are ready.

# Typical checks after the service starts
cardano-cli query tip
systemctl status cardano-node
journalctl -u cardano-node --since "15 minutes ago"

# The reported sync progress should reach 100%,
# and the tip should continue advancing.

Test connectivity from both directions

Confirm that each relay sees the producer and that the producer sees every trusted relay. Confirm that public peers can reach each relay's registered port. Also verify DNS resolution, system time, firewall rules and whether the cloud provider has a second firewall layer outside the operating system.

Cold keys and hot keys are intentionally different

The VRF and KES signing keys have to exist on the producer because the node needs them while running. The cold key does not. It authorizes long-term pool control and should remain offline. KES limits the damage window of a compromised operational signing key because it expires and must be renewed.

The safest operational pattern is simple: build an unsigned transaction online, inspect and sign it offline, then submit the signed transaction online. Only public keys, addresses, protocol data and transaction files cross the boundary. Private keys remain on encrypted offline storage.

Use dedicated transfer media

Use a dedicated USB drive for transaction files and public data. Do not use that drive to store private keys. Keep the offline machine encrypted, physically secured and backed up. Disable or remove networking hardware when possible rather than relying only on a software setting.

Back up before you register

Create multiple encrypted offline backups of the cold key, cold counter, payment key, stake key and recovery information. Store copies in separate physical locations. Test that the backup can be read, but do not expose it to an internet-connected computer.

Generate the payment and stake key pairs on the air-gapped machine. Use their verification keys to create the payment and stake addresses for the correct network. Fund the payment address with enough ADA for the stake-address deposit, the 500 ADA pool-registration deposit, transaction fees and a safety margin.

Register the stake address first

The pool reward account and owner delegation use the stake credential. Before the pool can be registered, the stake address must be registered on-chain. The current stake-address deposit is 2 ADA and is returned when the stake credential is deregistered under the protocol rules.

Keep the owner wallet separate from daily server access

The producer does not need your payment or stake signing keys. It only needs the operational hot credentials. This separation prevents a server compromise from immediately becoming a wallet compromise.

The basic metadata file tells wallets and explorers the public name, description, ticker and homepage of the pool. It must be valid JSON, publicly available over HTTPS and unchanged after its hash is placed in the registration certificate.

{
  "name": "Your Pool Name",
  "description": "A clear description of the pool and its mission.",
  "ticker": "TICK",
  "homepage": "https://yourpool.example"
}

Hash before registration

Generate the metadata hash locally, upload the exact file and hash the downloaded public copy again. Both hashes must match. A line-ending change, invisible byte-order mark, automatic formatting plugin or redirect can cause a mismatch.

Keep the URL stable

Use a URL you control and expect to keep for the lifetime of the pool. If the URL or hash changes later, submit an updated registration certificate. Do not host critical metadata on a temporary file-sharing service.

Pool registration requires four main pieces: the hosted metadata, a pool registration certificate, an owner delegation certificate and a transaction that submits those certificates. The registration certificate identifies the cold verification key, VRF verification key, pledge, cost, margin, reward account, owner stake key, relay addresses and metadata hash.

Build the certificate offline

Fetch the current protocol parameters and public information from an online node, transfer those files to the air-gapped machine, and create the registration certificate where the cold signing key is stored. Do not copy the cold signing key onto the online node for convenience.

Create the owner delegation certificate

The owner stake credential should delegate to the new pool so the declared pledge can become part of the pool's active owner stake. If several owners are used, every owner stake key listed in the registration must be handled correctly.

Pay the registration deposit

The current pool deposit is 500 ADA. It is locked by the protocol and returned when the pool is properly retired. This is separate from pledge: pledge remains ADA in owner-controlled addresses rather than a protocol deposit.

Verify instead of assuming

After submission, query the pool ID and stake snapshot, and verify the transaction in more than one explorer. It can take an epoch boundary before every wallet and explorer displays the pool. A visible transaction alone does not prove that your producer is configured to forge.

Generate the VRF key, KES key and operational certificate using the official key-generation workflow. Place only the required hot files on the producer, restrict their ownership and permissions to the node service user, and reference them in the producer service.

Files the producer needs

• The VRF signing key.
• The current KES signing key.
• The current operational certificate.
• The node configuration, topology, database path and socket path.

Files the producer must not have

• The cold signing key.
• The payment signing key.
• The stake signing key.
• Unencrypted backup archives containing any of those keys.

Restart the producer after adding the credentials and confirm through logs and node metrics that block forging is enabled. Check the KES period, operational-certificate counter and pool ID. Do this before the pool becomes active, not on the day you expect the first block.

At minimum, monitor synchronization, slot height, process liveness, peer connections, CPU, memory, disk space, KES expiry, block production, propagation time and unexpected errors. An operator should receive an alert before the database fills the disk, before KES expires and when a node stops advancing.

Useful monitoring layers

gLiveView is useful for a quick terminal view while connected through SSH. Prometheus, Grafana and Alertmanager provide historical metrics, dashboards and notifications. openBlockPerf adds an external view of network propagation. Many serious operators use more than one layer because each answers a different question.

Monitor the monitor

An alerting server on the same failed machine cannot notify you. Where possible, keep monitoring or at least external uptime checks outside the node's failure domain. Test alerts instead of assuming they work.

KES rotation creates a new KES key pair and a new operational certificate signed by the cold key. The process uses the current KES period and the latest cold counter. The new KES signing key and certificate are then installed on the producer.

A safe rotation sequence

1. Check the current KES period and the existing certificate expiry.
2. Back up and verify the latest cold counter.
3. Generate the new KES verification and signing keys.
4. Create the new operational certificate on the air-gapped machine.
5. Move only the new KES signing key and certificate to the producer.
6. Set restrictive ownership and permissions.
7. Reload or restart the node and verify forging status and expiry.
8. Keep the previous working files temporarily for controlled rollback, then retire them securely.

Server hardening

• Use SSH keys and disable password authentication after confirming key access.
• Restrict root login and use a named administrative account with sudo.
• Open only required ports; producer access should be limited to trusted relays and administration sources.
• Run the node as a dedicated unprivileged user.
• Keep the operating system patched and remove unused services.
• Use intrusion throttling or banning for repeated authentication failures.
• Synchronize time reliably and monitor NTP status.

What to back up

The irreplaceable items are the private keys, the current cold counter, wallet recovery material, metadata source, registration records and documented configuration. Node databases can be re-synchronized, but keys cannot be reconstructed unless you have a valid recovery method. Keep encrypted copies in separate physical locations.

Upgrade one path at a time

Read the node release notes before upgrading. Some versions add dependencies, change configuration or require ledger replay. Upgrade and validate one relay first, then the next relay, then the producer. Keep a rollback plan and enough disk space. Avoid performing a producer upgrade immediately before a likely leadership slot.

Document the recovery procedure

A backup that only one person remembers how to use is not a complete recovery plan. Record the service paths, DNS, firewall rules, providers, renewal dates, monitoring endpoints, KES procedure and emergency contacts without writing private keys into the document.

• Running everything on one public server: one outage or compromise affects every component.
• Keeping cold or wallet signing keys on the producer: a server breach can become total pool or fund loss.
• Using only one relay: maintenance disconnects the producer from the network.
• Opening the producer port to the internet: removes the protection the relay architecture is meant to provide.
• Ignoring free disk space: the node may stop when the database cannot write.
• Forgetting KES expiry: the producer remains online but cannot forge valid blocks.
• Restoring an old cold counter: can produce invalid or conflicting operational-certificate state.
• Registering an unreachable metadata URL: wallets and explorers may not display the pool correctly.
• Declaring pledge that is not maintained: can affect reward calculations and credibility.
• Expecting immediate blocks with very low stake: creates unrealistic business planning.
• Upgrading every node simultaneously: a bad release or configuration can take the entire pool offline.
• Testing backups only during an emergency: unreadable or outdated backups are discovered too late.

• The full registration workflow was completed successfully on a Cardano testnet.
• One producer and at least two relays are deployed in separate failure domains.
• The producer communicates only with trusted relays.
• Relay DNS and public Cardano ports resolve and respond correctly.
• All nodes use the intended stable cardano-node and cardano-cli versions.
• Every node is fully synchronized and system time is accurate.
• Cold, payment and stake signing keys exist only in the offline environment.
• Multiple encrypted offline backups and the latest cold counter are verified.
• Metadata is valid, publicly reachable and matches its registered hash.
• Pledge, fixed cost, margin, reward account, owners and relays were reviewed before signing.
• The pool registration and owner delegation appear correctly on-chain.
• VRF, KES and operational-certificate files are installed with restrictive permissions.
• Forging is enabled and the KES expiry date is recorded in monitoring.
• CPU, memory, disk, process, peers, sync, KES and block alerts are tested.
• A rolling upgrade procedure and rollback plan are documented.
• The public website and operator contact channels are ready for delegators.