Payment keys, stake keys, and why you have many addresses
A Cardano address usually contains two parts: a payment credential, which controls spending, and a staking credential, which controls delegation.
The consequence is that one wallet generates many payment addresses that all share a single stake key. Your funds are spread across them; your staking is unified. Look up one address and you see a fraction of your holdings, which is alarming if you do not know to expect it.
Cardanoscan handles this correctly: search a stake address and you get the aggregate position, the delegation and the full reward history. That is the view that corresponds to what a wallet shows you, and it is the one to use.
This also enables something genuinely useful — liquid staking without lock-up. Because delegation is controlled by a separate key from spending, your funds remain freely spendable while delegated. There is no unbonding period, unlike Polkadot's twenty-eight days or Ethereum's exit queue. It is one of Cardano's better design decisions and it falls directly out of the key separation.
Epochs, and why rewards arrive late
Cardano runs on five-day epochs, and staking rewards follow a schedule that surprises almost every new delegator: you delegate, and the first rewards appear roughly fifteen to twenty days later.
The reason is the snapshot mechanism. Your delegation is recorded in a snapshot at the end of one epoch, becomes active in the next, produces rewards in the one after, and is paid in the one after that. Nothing is wrong; the pipeline simply has depth.
Cardanoscan shows where you are in that cycle, which is the only way to distinguish "working normally" from "misconfigured". Given how many support questions this generates, it is a genuinely valuable thing for an explorer to surface.
One consequence worth knowing: because delegation is snapshotted, switching pools does not interrupt rewards. You keep earning from the old pool through the pipeline while the new delegation takes effect. There is no penalty and no gap.
Choosing a stake pool, factually
Cardanoscan's pool pages carry the data that actually determines returns, and it is worth knowing which fields matter.
Saturation is the important one. Above a protocol-defined threshold, a pool's rewards stop increasing with additional stake, so delegating to a saturated pool reduces everyone's return including yours. The mechanism exists to push stake towards decentralisation, and it works — but only if delegators look.
Fees come in two parts: a fixed minimum per epoch and a percentage margin. On a small pool the fixed fee is a larger proportion of a smaller reward pot, which matters more than the headline margin.
Blocks produced against blocks expected is the operational quality signal. A pool consistently producing fewer blocks than its stake implies has technical problems, and that translates directly into lower rewards.
We are describing how the mechanism works, not telling you where to delegate — that is a decision with financial consequences and it is yours.
| Field | Why it matters |
|---|---|
| Saturation | Past the threshold, extra stake earns nothing extra. The single most consequential field. |
| Fixed fee | Charged per epoch regardless of size. Proportionally heavier on small pools. |
| Margin | Percentage the operator takes after the fixed fee. |
| Pledge | Operator’s own stake. Skin in the game, and it affects reward calculation. |
| Blocks vs expected | Operational reliability. Persistent underperformance means technical problems. |
Extended UTXO and native assets
Cardano uses extended UTXO — like Bitcoin's model, but outputs can carry arbitrary data (a datum) and be guarded by scripts. It is a genuinely different computational model from Ethereum's accounts, with different properties: transaction outcomes are predictable before submission, and concurrency has to be designed for rather than assumed.
The most immediately visible consequence is native assets. Cardano tokens are not smart contracts. They are ledger-level objects, carried in outputs alongside ADA, transferred by the same machinery.
That removes a whole class of problem. There is no token contract that can be upgraded to block transfers, no approval mechanism to be exploited, no bespoke transfer logic to audit. The token approval risk that dominates EVM security advice simply does not exist here.
It also means an output carrying tokens must carry a minimum amount of ADA alongside them, which is why you cannot send tokens from an address holding no ADA. Cardanoscan shows the composition of each output, which is where that becomes visible.
What our reference tests showed
Our Cardano items were a simple ADA payment, a native asset transfer, a stake address with delegation history, a pool page, and an output carrying tokens with the minimum ADA attached.
Searching the payment address returned a partial picture, as the key model dictates. Searching the stake address returned the aggregate position and the full delegation and reward history, which is the view that matches what a wallet shows and the one we would tell anyone to use.
The reward history reconciled epoch by epoch, and the snapshot pipeline was visible in the data — the first reward appeared the number of epochs later that the mechanism predicts, rather than immediately.
The pool page showed saturation, pledge, fixed fee, margin and blocks produced against blocks expected. We deliberately looked at a saturated pool, and the figure was prominent enough that a delegator would notice it before committing, which is the whole point of surfacing it.
The token output test showed the ADA and the native asset as separate components of the same output, which is the only presentation that explains why a token transfer requires ADA to accompany it.