Cardano Network Metrics Technical Glossary

Cardano extends Bitcoin's unspent-output accounting with three additions: an output can carry a datum, the transaction that spends it supplies a redeemer, and its value can hold native assets next to ada. A wallet or a node can therefore run a spending script against the exact state it will see on chain, so the fee and the execution budget of a transaction are known before it is submitted and there is no fee auction. What the model does not promise is that the script returns true: a transaction whose declared budget fits can still land and fail validation, which is what the collateral it names is set aside for.

Measured here: script execution telemetry · every transaction of a block as one box in the Block Pile

Ouroboros Praos elects the producer of every slot through a verifiable random function. Each pool holds a private VRF key and compares its output against a threshold derived from the pool's active stake share and the protocol's active slot coefficient, so a larger stake raises the chance of being elected without ever making it certain. The result stays private until the block is broadcast, which makes an attack planned against a known upcoming leader harder. The lottery is also why a small pool can mint more blocks than its stake share in a single epoch, and why those deviations average out over many epochs.

Both windows are measured on Cadence.

Block production is signed with a forward-secure key. Instead of staying the same for the life of a pool, the operational key evolves at an interval the ledger fixes, and the node discards the part of it that has expired. An attacker who copies a node's key today therefore cannot sign blocks for slots that have already passed. The trade-off is operational: the key has to be rotated on schedule, and a pool that misses a rotation stops minting until it catches up, which shows up on this site as missing blocks rather than as a failed transaction.

The number of independent entities that would have to act together to control more than half of the active stake, which in Ouroboros is the point at which they could reorganize the chain. The site counts it twice: the entity-level figure merges pools that share an operator, and the pool-level figure treats every registered pool on its own. Cross-chain comparison sites often publish a lower number for Cardano, because they measure the share that stalls a BFT chain instead of the majority a chain reorganization needs.

Counted live on Consensus.

One organization running several stake pools under separate registrations. Before the site counts anything, it groups pools that share a declared pool group, owner stake keys, or reward address. Without that step a single operator with many pools would look like many independent operators and inflate every decentralization count on the page. What the clustering cannot see is an operator who keeps every pool separate in all three of those fields.

Used by the entity-level count.

A concentration index between zero and one. Zero means every pool holds the same amount of active stake; values close to one mean a few pools hold almost all of it. On this site it is printed as an index and never as a percentage, because it measures the shape of the distribution rather than a threshold. It also says nothing about how many entities a majority would take, which is what the Nakamoto count answers, so the two belong next to each other.

Shown on Consensus.

Cardano divides time into one-second slots and groups a fixed number of them into an epoch. Almost everything settles on an epoch boundary: stake snapshots, reward distribution, pool parameters, and protocol parameter changes. That is why a delegation made today starts producing blocks two epochs later, and why the dashboard counts the epoch down instead of showing a percentage of the way through it. Blocks are produced only in the slots a pool wins, so an empty slot is the normal case rather than an error.

Blocks per hour against that rate: Cadence.

Liveness is the share of slots in a window that actually produced a block. Spacing is the time between one block and the next, which the protocol targets at a fifth of a minute; the 95th percentile of that spacing is what shows how far the slow tail stretches when a producer drops out or a block arrives late. Both are measured from block timestamps the site already stores, and both stay blank for hours the indexer never reported rather than being drawn as zero.

Measured on Cadence.

Active stake is the snapshot taken two epochs ago, and it is the figure that decides how many slots a pool wins now. Live stake is what delegators hold at this moment, including every delegation that arrived after that snapshot. A pool can therefore be producing blocks with much less stake than it appears to control, or much more. Whenever a number on this site uses one of the two, the label says which one.

Both columns on Consensus.

A pool registration carries a pledge, the amount of ada its operator binds to the pool. The ledger computes the pool's rewards with the lower of the declared pledge and the pledge actually present, so an operator who withdraws part of it earns as if the pool had pledged less, and that reduction applies to the delegators in the pool too. This site prints the declared pledge next to the live one so the gap is visible before it changes what anyone earns.

Live pledge tiles on the dashboard.

The ceiling on the stake that earns rewards in one pool, derived from the circulating supply and the protocol's target number of pools k, which governance sets (the live target). Stake delegated above the ceiling earns nothing extra, which pushes delegation toward smaller pools instead of letting one pool grow without limit. The ceiling moves whenever the supply or k moves, so the site reads it from the live parameters rather than quoting it.

The ratio between the blocks a pool minted in an epoch and the number its active stake share predicts. Because the slot lottery is random, a pool with a small share can sit well above or below the expected count for several epochs in a row, and a single epoch of luck says almost nothing about how the pool is run. It becomes informative when it is read over many epochs, and it never says whether the blocks a pool produced were valid.

The fixed fee a pool deducts from an epoch's reward pot before it splits the rest with its delegators. It exists so that running a small pool can cover its own costs, and governance sets it as a protocol parameter (the value the ledger holds). Above it, each pool adds its own margin. The site prints the setting from the live parameters instead of a figure that a governance action can outdate, and names the two proposals that would lower it further rather than predicting which one passes.

Live on the dashboard.

Every epoch the ledger mints new ada from the reserves and adds that epoch's fees to the pot. Two protocol parameters decide how it is split: the reserve depletion rate (the live rate) determines how much of the reserves is minted this epoch, and the treasury cut (the live share) takes a share for the treasury before the rest is distributed to pools and their delegators by stake. Neither is a constant, so a governance action can change both, and the site reads them live.

The annualized return a delegator sees, computed as the rewards a pool distributed divided by the stake that earned them. It is not a protocol constant: a pool that mints more blocks than its stake share predicts, charges a lower fixed cost, or sets a lower margin returns more, and a pool that sits above its saturation limit dilutes the return it pays. The site prints it per pool over recent epochs, so a single lucky epoch does not read as a rate.

Pool rows on Consensus.

Refundable amounts the ledger holds while a credential is registered. Registering a stake key costs the live key deposit, registering a pool costs the live pool deposit, and governance adds its own two: one to register as a DRep and one to submit a governance action. All of them are protocol parameters that governance can change, and all of them are returned when the registration is deregistered, which is why the site prints what they are worth now instead of what they once were.

Live parameter list on the dashboard.

The queue a node keeps of transactions it has validated but not yet put into a block. Cardano's node orders that queue first in, first out: there is no fee auction, so a transaction cannot pay to overtake an earlier one, and paying more only changes what it costs rather than when it lands. The queue is local to each node and is not part of the ledger, which is why this site publishes no mempool size: nothing in the data it reads reports one, and a flat line would be a fabrication.

What the site measures instead: Block Space.

The share of a block's body limit that its transactions fill. The site groups sampled blocks into bands (under two percent, two to five, five to ten, and over ten percent of the limit) because the average alone hides the shape: a chain whose blocks average a few percent of the limit still has productive hours where one block is nearly full. The largest block in the sample is printed next to the band it falls into, and the limit itself comes from the live protocol parameters rather than from the markup.

Bands and limit: Block Space.

The indexer returns a sample of each block's transaction sizes rather than all of them, so the size mix on this site is measured from that sample and the page prints how many sizes it used. The sample is large enough to place a median and a 95th percentile, and small enough that a single very large transaction shows up as a tail rather than as a trend. Sizes are compared against the ledger's maximum transaction size (the live ceiling), because the two constrain each other: a larger ceiling means a larger tail is still a legal transaction.

Size mix: Block Space.

A transaction pays a fee built from two parts: a rate per byte of the serialized transaction (the live rate) and a fixed amount per transaction (the live amount). A wallet computes the sum itself before signing, so the cost of a transaction is known in advance and does not depend on how busy the chain is. The consequence worth knowing: fees scale with size, so a plain payment pays close to the fixed term while a script-heavy transaction pays mostly for its bytes.

Worked example from live values: Block Space.

ada is the currency of the Cardano ledger and a lovelace is its smallest unit: one ada is a million lovelace. The ledger counts in lovelace, so every amount in the protocol parameters (deposits, fees, the minimum pool cost) is a lovelace count and this site converts them for display. The wording follows the style guide the site writes by: ada in lowercase as a unit, ADA only as a ticker symbol.

Both units side by side: Block Space.

The generations of Cardano's smart contract engine. V1 arrived with Alonzo and runs the original validation functions; V2 arrived with Vasil and added the reference inputs, inline datums and reference scripts that the later eras build on; V3 arrived with Chang and Conway and adds bitwise primitives, BLS12-381 pairing operations for zero-knowledge proofs, and the governance voting contexts. Scripts of different eras can be spent in the same transaction. No indexer this deployment reads reports which era a script was compiled for, so the site does not split its figures by era and says so instead of guessing.

What is measured: Plutus.

The work a script may consume, counted in two meters: CPU steps and memory units. The ledger bounds it twice. A per-transaction cap limits what one transaction may declare (the live step cap and the live memory cap), and a per-block budget limits what all script work in one block may use together (the live step budget and the live memory budget). Both are protocol parameters that governance can raise, and a transaction is rejected before inclusion if its declared budget exceeds the per-transaction cap. The work itself is priced too, at a rate per CPU step (the live step price) and per memory unit (the live memory price), which is how the execution fee of a transaction is built on top of its size-based fee.

Live ceilings and usage: Plutus.

How much of a block's execution budget its scripts actually used, as a share of the limit in force. It answers a different question from the fee table: not what a transaction costs, but how close the network is to the ceiling it can carry. A chain whose contracts use a few percent of the budget has room for more script work per block; one that approaches the limit would start leaving transactions out. The site draws both meters on one axis, so the busier of the two is the one that reads.

Timeline and distribution: Plutus.

Two ways to reach data without moving it. A reference input lets a script read a UTxO without spending it, so several transactions can read the same state inside one block instead of queuing behind each other. A reference script stores a script on chain once, and later transactions point at it by hash instead of carrying its bytes, which shrinks what they have to pay for. The second one has a price attached: carrying a script costs extra bytes, and the ledger charges for them per byte.

How often the chain uses them: Plutus.

Carrying script bytes in a transaction costs more than carrying ordinary data: the ledger charges a per-byte rate for reference script bytes on top of the normal fee (the live rate). That is the trade the on-chain pattern is built on: store a large script once, then let every later transaction point at it, and the saving grows with the number of calls. It is also why the largest contract size is printed next to the ledger's maximum transaction size, since the two constrain each other.

Prices and measurement: Plutus.

The input a transaction sets aside for the case where its scripts run and return false. The ledger takes a share of the fee as collateral (the live share) from that input instead of the fee alone, so a failing script costs the submitter more than a successful one. Since CIP-40 the transaction also names an output that receives whatever the collateral input held beyond that share, which is what stops a large collateral input from being consumed whole. On a transaction that validates, nothing is taken.

Collateral measured per transaction: Plutus.

The governance system the Conway era introduced. Three bodies vote on governance actions: DReps, whose voting power is the stake delegated to them, stake pool operators, and a constitutional committee that checks an action against the constitution. Participating costs a deposit: registering as a DRep costs the live DRep deposit and submitting an action costs the live action deposit, both refundable when the credential or the action ends. A DRep that stops voting for the live activity window loses the voting power delegated to it.

Protocol settings: the parameter list.

Three separate efforts that are easy to confuse. Hydra builds isomorphic state channels, where a group settles transactions off chain at low latency and posts the result to the main chain. Mithril produces stake-based threshold signatures that let a client verify a snapshot of the chain without replaying it, which is what makes fast syncing and light clients possible. Leios is the consensus-side proposal that separates transaction endorsement from block ranking to raise throughput. None of the three changes what this site measures today about the main chain, so none of them appears as a series here.

How the site combines blocks into a multi-day window. Averaging per-block shares equally would give a block with one transaction the same weight as a block with a thousand, so each block's figure is weighted by its transaction count instead: the sum of the values times their counts, divided by the sum of the counts. Every share on a window longer than the live hour uses this method, and the hourly rollups the long charts read are built from the same rule, which is why a quiet hour cannot drag a five-day figure down.

Applied on Block Space and Plutus.

Block rows are kept for two days. Above that the site stores one row per hour: block count, transaction count and the aggregates the long charts need, written only for the hours the indexer actually reported. An hour without a row is drawn as a gap rather than as a zero, so an empty stretch in a five-day chart is a gap in the data and not a quiet chain. Rows past the retention window are deleted by the sync, which is why the far end of a long range thins out.

Visible in Blocks per Hour.

Blocks, transactions and protocol parameters come from the indexers this deployment reads, and the hourly rollups and window aggregates are computed here and stored in the site's own database. Two consequences a reader should keep in mind: a figure that needs a measurement no indexer publishes is absent rather than estimated, and every metric panel names the file and the function that derives it, so the provenance can be checked rather than trusted.

The same point in the FAQ.

Most figures here describe a window rather than the chain as a whole: the live hour, the last day, the last five days. A number belongs to the blocks the indexer returned for that window, which is the same set of blocks the charts draw, and the sample size and the window are printed next to it. Reading it the other way round is the usual mistake: an hour says what that hour looked like, not what the network always does.

Every tile names its window on Plutus.