How Nimiq Albatross proof-of-stake works: validators, epochs, finality

The numbers, and where each one comes from

Albatross is Nimiq's proof of stake consensus protocol. It is built out of a small set of fixed constants, and almost everything else follows from them. Every figure in this table is a named constant in the node software's mainnet policy, read at release tag v2.1.0 on 14 September 2026, rather than a number copied from a description of the protocol.

Micro blocks: one producer, one second

The ordinary unit of the chain is the micro block. It carries user transactions, and it is produced and signed by a single validator, the one that owns the current slot. There is no race and no competition to produce it: the protocol has already decided whose turn it is, and that validator simply publishes.

Whose turn it is comes from a verifiable random function. The slot owner list is reshuffled using the entropy of the previous block's random seed, and it is reshuffled for every single micro block. Nobody can predict who produces next, and nobody can steer it, because the seed is derived from a proof that anyone can verify but nobody can choose the output of.

One second is a target rather than a floor. The constant is literally commented in the source as "the optimal time in milliseconds between blocks", and producers publish when they are ready. Over the whole life of the proof of stake chain the observed average is a shade under the target, which we work out precisely further down.

When a producer misses its turn

Validators go offline, and the chain cannot wait for them. If the expected micro block does not arrive in time, the remaining validators agree a skip block in its place. A skip block is canonical, meaning the protocol determines exactly what it must look like: no transactions, an empty body, no new randomness (it inherits the previous seed), and a timestamp fixed at four seconds after the previous block. It needs a supermajority of signatures, aggregated into a single proof, and then the chain moves on.

There is no cap on how many skip blocks can occur in a row, so a run of absent validators slows the chain but does not stop it.

The macro block: where finality actually happens

Every sixtieth block is not a micro block. It is a macro block, and it is a different kind of object produced in a different way.

• It carries no user transactions. Its body holds reward transactions, which distribute the batch's block rewards and fees, and nothing else.
• It is voted, not produced. A leader proposes it and the validator set runs Tendermint over the proposal: propose, then pre-vote, then pre-commit. Each phase needs the agreement of more than two thirds of the 512 slots, and the votes are aggregated into one BLS signature.
• It is what makes a transaction final. Once the macro block closing a batch is confirmed, every transaction in that batch is settled. Not probably settled, not settled pending some number of confirmations. The vote is the settlement, and the protocol has no mechanism to undo it.

So the honest answer to "how long until my Nimiq payment is irreversible" is: until the end of the current batch, which is at most about a minute and on average about thirty seconds. That is a substantially different promise from the one a proof of work chain makes, and the comparison with Bitcoin and Ethereum puts it side by side.

Macro blocks come in two flavours. Most of them are checkpoint blocks: they close a batch, finalise its transactions, and keep the same validator set. The last macro block of an epoch is an election block, which does all of that and also chooses who validates next. In each epoch there are 719 checkpoints and one election.

The epoch and the election: 512 slots, shared by stake

An epoch is 720 batches, so 43,200 blocks, so about 12 hours. Its defining property is that the validator set does not change inside it. Whoever was elected at the start validates until the end, and no mid epoch replacement exists even for a validator that goes offline or gets jailed.

At the epoch boundary the election macro block hands out 512 slots. Slots are allocated in proportion to total stake, which means a validator's own deposit plus everything delegated to it, using the randomness from the election block's seed. Each validator receives a continuous range of slot numbers whose size reflects its stake.

Two consequences are worth stating plainly, because both surprise people.

• A staker never holds a slot. Your delegation adds to the weight that earns your validator its slots. It does not give you one. That is the root of why rewards reach you through the validator rather than from the protocol directly.
• Election is re-run from scratch every 12 hours. Being elected in one epoch guarantees nothing about the next. For a small validator, and ours is one, that means election is an ongoing outcome rather than a status you attain.

Because 512 slots are shared in proportion to stake, a validator holding a small fraction of total stake may well receive no slots at all in a given epoch. That is not a fault condition. It is the design, and it is the single most important thing to understand before choosing a validator.

Registered, active, elected: three different things

These three words get used interchangeably in most writing about Nimiq, and they mean genuinely different things. Almost every "why is my stake not earning" question resolves to a confusion between them.

The important asymmetry: registered, inactive, jailed and retired are flags stored in the validator record, so you can read them straight off the chain. Elected is not a flag at all. It is a property of the current epoch, derived from the slot allocation in the last election block, and it evaporates and is recomputed twice a day.

That is also why validator counts differ between sources without any of them lying. Our is Nimiq still active page counts all four denominators separately for exactly this reason.

Punishments: burned rewards and jail, but not your principal

Albatross has two levels of punishment, and the gap between them is large.

Minor: a block production delay

A validator that does not produce its block on time loses the reward for that slot, which is burned rather than redistributed. The slot joins the punished set for the current batch and the next, so the reward distribution can cross check it, and the slot is deactivated but may reactivate itself one block later. A validator holding 15 slots that delays one block collects 14 slot rewards out of 15. It is a small, self correcting penalty for a small, common failure.

Severe: equivocation and jail

Equivocation means saying two contradictory things at once: two blocks at the same height, two Tendermint proposals for the same round, or two votes in the same round and step. Any honest validator that witnesses it can submit a proof, and the moment that proof is on chain the offender is jailed for 8 epochs, which is about four days. All of its slots are punished, all of its rewards are burned for the duration, and it cannot be re-elected while jailed. It must nonetheless keep voting until the current epoch ends, because there is no mid epoch mechanism to replace its slots.

What is not punished

This is the part that differs from what people expect if they have come from another proof of stake chain, and it is worth being exact about.

Nimiq does not slash principal. Neither the validator's 100,000 NIM deposit nor any NIM delegated to it is confiscated for either offence. The penalties are burned rewards and lost time. Stakers are not untouched, because a staker's lock up period aligns with the validator's, so a jailed validator means your stake is locked for longer than you planned. But what you lose is rewards and liquidity, not the stake itself.

That does not make validator choice unimportant. It shifts what is at risk: not your NIM disappearing, but your NIM sitting idle behind an operator that is offline, unelected or jailed, earning nothing while it waits.

The arithmetic, checked against a live reading

All of the above is only as good as the constants it rests on, and those constants are checkable. We run a validator node on Nimiq mainnet, so here is a reading taken from it on 14 September 2026 at 00:01 UTC:

The proof of stake chain began at block 3,456,000. If a batch really is 60 blocks, then 968,013 batches have closed and the chain is 35 blocks into the next one:

3,456,000 + (968,013 x 60) + 35 = 61,536,815

Which is the height the node reported, exactly. Now the epoch. If an epoch really is 720 batches, then 1,344 epochs have closed and the chain is 334 batches into epoch 1,345:

(1,344 x 720) + 334 = 968,014

Which is the batch the node reported, exactly, and the 334 matches the batch-within-epoch figure the endpoint returns independently. Both equations close on the nose, which means the constants are right and no interval is missing anywhere between the migration and now.

How fast is the chain really running?

One more thing falls out of the same reading. The migration block carries the timestamp 1732034720000, which is 19 November 2024 at 16:45:20 UTC. Between then and the reading above, 57,309,366 seconds elapsed and 58,080,815 blocks were produced. Divide one by the other and the average gap between blocks is about 0.987 seconds, roughly 1.3% quicker than the one second target.

That is the expected behaviour rather than a discrepancy: one second is the optimal spacing, not an enforced minimum, so producers that are ready early publish early. Cumulatively it puts the chain around nine days ahead of where a strict one second metronome would have it, which is the sort of detail worth knowing if you are ever tempted to convert a block height into a date by multiplying.

Where the documentation contradicts itself

If you have read the official protocol pages you may have seen different numbers from ours, so here is the discrepancy, named and resolved rather than quietly papered over.

The block format page states 1440 batches per epoch and, in the same sentence, that an epoch takes about 12 hours. Both cannot be true. At roughly one batch per minute, 1440 batches is 24 hours, not 12. The document contradicts itself internally.

Three independent things say 720:

• The node software. MAINNET_POLICY declares batches_per_epoch: 720. This is the code the network actually runs.
• The chain's own numbers. The equation above closes with 720 and fails badly with 1440. At 1440 batches per epoch, batch 968,014 would sit in epoch 673. Our node says 1,345.
• The endpoint's own accounting. It reported batch 334 of the epoch with 386 remaining. Those sum to 720.

So an epoch is 720 batches and 12 hours, and the 12 hour half of the documentation's sentence was the correct half. We do not publish the 1440 figure anywhere on this site.

The other apparent conflict is friendlier: the docs say a batch is 59 micro blocks while the code says blocks_per_batch: 60. Both are right and they are describing the same thing. A batch is 60 blocks, of which the first 59 are micro blocks and the last is the macro block that closes it. The docs are counting the micro blocks; the code is counting all the blocks.

Check it yourself

Everything above is verifiable in a couple of minutes and none of it requires trusting us. Open the block explorer and watch blocks arrive about a second apart, then watch the height reach the end of a batch and see the macro block that closes it. The validators page shows the real set with each one's stake, and NimMap draws the delegation graph that stake proportional slot allocation operates on.

For context around this page: what Nimiq is for the chain in general, the comparison with Bitcoin and Ethereum for how this consensus differs from theirs, and NIM tokenomics for the issuance that those batch rewards are paid out of. The rest is in the Learn hub.

We publish no price figures anywhere on this site and nothing on this page is financial advice.