Payment keys, stake keys, and why you have many addresses
A Cardano address usually contains two parts: a payment credential controlling spending, and a staking credential controlling 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 — the view that corresponds to what your wallet shows you, and the one to use.
This design also enables something genuinely useful: liquid staking with no 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, which means there is no reason to hesitate over moving away from a saturated or underperforming pool.
Reading a stake pool page
Cardanoscan's pool pages carry the data that 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 rather than telling you where to delegate. That is a decision with financial consequences and it is yours.
Extended UTXO and native assets
Cardano uses extended UTXO — like Bitcoin's model, but outputs can carry arbitrary data 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 — and where an apparently inexplicable failed transaction usually has its explanation.
Governance, and what an explorer can show you about it
Cardano moved into its Voltaire phase with on-chain governance: delegated representatives, a constitutional committee, and votes recorded on the ledger rather than announced elsewhere.
The property that matters for a reader is the same one that makes Polkadot governance interesting. Because governance actions are on-chain, you can read what a proposal would actually do rather than relying on its description. A proposal titled one thing and encoding another is detectable, and the explorer is where you would detect it.
Cardanoscan surfaces this data alongside the staking information. For most people it will never be relevant. For anyone who holds ADA and wants to understand what is being decided with it, it is the difference between participating and being told about it afterwards.
It also changes what delegation means. A stake key can delegate to a pool for block production and separately to a representative for governance, which are different decisions with different consequences. Explorers that treat delegation as a single field get this wrong, and it is worth checking that the tool you are using distinguishes them.
The broader point, which applies well beyond Cardano: the value of putting a process on chain is not that it is decentralised in some abstract sense. It is that the process becomes checkable by anyone with a browser. That is a genuinely different accountability property from a published announcement, and very few chains have it.