Skip to content

Nimiq staking mistakes we see as operators

Last updated Written by the ImpactZero validator team

In short

The common ones are avoidable: delegating to a validator that is registered but not elected, leaving stake undelegated and earning nothing, misreading the unstaking lock, and assuming rewards are fixed. Each costs time or rewards rather than principal. This guide explains how each happens and how to check for it.

How to read this page

None of the mistakes below lose principal. That is the first thing worth knowing, and it is a real property of the protocol rather than reassurance: Albatross punishes validators by burning rewards and by jailing them, not by taking delegated NIM. What these cost is time, rewards that were never earned, and occasionally access to your own funds for a while.

They also have something else in common. Every one of them leaves a signature you can go and look at, either in your own staker record or in the validator records the chain publishes. So each section below ends with the check rather than with advice.

Where this page quotes live data it is one reading, taken at block 61,538,832 on 14 September 2026, epoch 1345, from our own node.

1. Delegating to a validator that is registered but not elected

This is the big one, and it is the reason choosing a Nimiq validator spends longer on election than on fees. Three words get used as if they meant the same thing and they do not. Registered means a validator record exists on chain. Active means that record carries no inactivity flag, so it is eligible at the next election. Elected means the last election block actually handed it slots, so it is producing blocks in this epoch. Only the third one earns anything.

A validator can sit in the first two states for months. Delegating to it is not an error the chain will refuse, the transaction succeeds, your staker record looks perfectly healthy, and nothing arrives, because there is nothing to distribute at any fee.

The scale of it, from that reading. There were 52 validator records on chain. 13 carried an inactivity flag, leaving 39 that did not and were not retired, holding about 9.09 billion NIM between them. Slots are shared out 512 at a time in proportion to stake, so an average slot sits behind roughly 17.8 million NIM, and 9 of those 39 held less than one average slot's worth. Four of the 52 held nothing but the 100,000 NIM deposit and had no stakers at all.

The check. Open our validators page and read the Elected column before the fee column. The chip is drawn from two things: whether the address is in the chain's active set, and whether the official validators list has a reliability score for it. A blank reliability means no recent scored epoch selected that validator, which is the honest reading of "not elected". Then look at the size of the pool against that 17.8 million figure and decide whether a slot is likely.

An earlier reading the same day, quoted in choosing a Nimiq validator, found 40 records without a flag rather than 39. One record picked one up between the two reads. Neither page has a typo. That is the whole point of this section: a validator's state is a live value, not a property it owns.

2. Stake sitting in the contract with no validator behind it

A staker record has a delegation field, and it is allowed to be empty. Stake with nothing in that field is inside the staking contract, safe, under your key, and earning nothing at all. The developer documentation is blunt about it: if no validator is added, the staker is not delegating and is not eligible to receive rewards.

It is a rarer state than the first one, because most interfaces make you pick a validator on the way in. It shows up after a half finished change of validator, or when a transaction was built by hand.

The check. Read your own staker record. Ours, at the same block, looks like this, and the field to look at is the second one:

Field Value What it tells you
address NQ27 NCB1 3CYU 9P4L EM2V D7L2 28QE 36PA EXB1 Whose stake this is. Ours, in this example.
delegation NQ08 ACT8 T0FE PTG8 P5RL H2S3 QGXH V15R NVXY The validator behind it. Empty here would mean no rewards at all.
balance 341219403873 Luna, at 100,000 to one NIM, so 3,412,194.03873 NIM.
inactiveBalance 0 Nothing is cooling down.
inactiveFrom null No lock is running, because nothing was deactivated.
retiredBalance 0 Nothing is waiting to be withdrawn.

Two things are worth noticing about that record beyond the delegation. The balances are in luna, at 100,000 luna to one NIM, so a figure that looks alarming is usually a unit. And there is no rewards field anywhere in it, which is not an omission by our API. The protocol pays the batch reward to the validator's reward address and the split to stakers happens off chain, so the chain has nothing to report to you about earnings. Where the rewards come from covers that properly.

3. Believing a switch means unstaking first, or that it means no wait

Both halves of this get believed, and the truth is the awkward middle. It is worth getting right because the wrong version in either direction costs something.

You do not have to withdraw. Nimiq has a dedicated update staker transaction. Your NIM never leaves the staking contract, there is no retire, no remove stake, no new staker record, and no round trip through your own account. Anyone who tells you to unstake completely and start again is describing more work than the protocol asks for.

But you do have to wait. The developer documentation sets out the sequence in four steps: set the active stake to zero, wait for the inactive balance to be released, which is one epoch plus the blocks left in the current epoch, then update the validator address, then return the stake to active. The node software enforces exactly that. In update_staker, a staker that already has a delegation is rejected if its active balance is not zero, and rejected again if the inactive balance has not been released.

The reactivate flag some interfaces set is worth understanding rather than trusting. It does one thing: it moves the released balance straight back to active behind the new validator in the same transaction, so you do not have to send a fourth. It does not shorten the wait, and it cannot, because the transaction carrying it is only valid after the wait is over.

The check. Before you plan a switch, look at inactiveFrom in your own staker record. It is null while everything is active, and once you deactivate it holds the height the clock started from. The update becomes valid one epoch after the election block that follows it, which normally lands between about 12 and 24 hours from when you sent the deactivation. The same arithmetic as unstaking, because it is the same lock.

4. Treating an exchange earn product as Nimiq staking

Search for how to stake NIM and a wall of posts will point you at exchange earn products and at DeFi platforms, some of them published under handles that look official. Nimiq's own staking FAQ states that exchanges supporting NIM do not offer direct staking.

Those products are not fake, they are simply a different thing wearing the same word. The distinction that matters is not about yield, it is about who is holding the coins while it happens, and the test takes one second:

  • Nimiq staking asks you to sign. The delegation ends up on the public ledger against your own address, and only your address can undo it.
  • A custodial product asks you to send. The coins go to an address that is not yours, and a company's database, not the chain, is what says you own anything.

The check. After you stake, put your address into our block explorer. A real delegation is a transaction to the staking contract naming a validator. If the only thing you can find is a transfer out to somebody else's address, you did the other thing. How to stake NIM walks the self custodial route end to end.

5. The 100 NIM floor, and the other number

Two minimums circulate and both are real, which is exactly why people trip over them. The protocol floor for creating a staker is 100 NIM, in the developer documentation. The official staking page said as little as 1000 NIM when we read it on 14 September 2026. An interface is free to ask for more than consensus does, and one of them has.

The floor also behaves in a way people do not expect once a stake exists. It applies to your non retired balance as a whole rather than to each transaction, so topping up an existing stake does not have to clear it again. Going the other way it bites: you cannot retire so much that the balance left behind sits under the minimum without being zero. Retiring all of it is always allowed; retiring almost all of it may not be.

The check. If a stake transaction is refused and the amount looks fine, compare it against the interface's own stated minimum first, and against 100 NIM second. The two answers are usually different and the interface's is the one you are actually facing.

6. Sending the retire before the lock has passed

Unstaking is three transactions and the middle one has a clock on it. Deactivate whenever you like. Retire only once the inactive balance has been released, which for a staker whose validator is not jailed is one epoch of reporting window counted from the next election block.

Send it early and the chain refuses it. Not delays it, refuses it. In the node software, retire_stake checks whether the inactive stake has been released and returns an error if it has not, so the transaction is invalid rather than pending. It never mines, your staker record does not change, and nothing is at risk. The most common version of this mistake is the second half of it: sending it again, five more times, in the belief that something is stuck. Nothing is stuck. The only thing that changes the answer is the chain head reaching the release height.

The check. Look for the transaction in the block explorer. If a retire was refused there is nothing to find, because a rejected transaction leaves no trace at all. An absence is the confirmation. Interfaces that show a countdown, including the one on this site, keep the button disabled until the height is reached for exactly this reason.

7. Expecting rewards before the first elected epoch

Two clocks run behind every new stake, and impatience usually comes from watching only one of them.

The protocol clock. Stake changes are reflected at the next election block, not the moment the transaction mines. An epoch is 43,200 blocks, roughly 12 hours, so a fresh delegation starts counting somewhere in the next half day. How Albatross works has the full structure.

The validator's clock. Even after your stake counts, the validator has to be elected in an epoch, produce blocks in it, and then distribute. Distribution is off chain and on whatever schedule the operator publishes. A brand new validator has the worst version of this problem: its trust score fields stay empty until it has been selected and an epoch has ended, so there is a stretch where the honest answer to "how is it doing" is that nobody knows yet.

Nothing on this site quotes a reward rate, and this is one of the reasons. Rates move with everything staked across the network, every validator's payout policy differs, and a number printed here today would be quietly wrong within weeks.

The check. Note the epoch number when you stake, then look again after the next election block. If your delegated balance is counted and the validator still has no slots, the problem is section 1 rather than patience.

8. Expecting one address to back two validators

A staker record holds one delegation field. Not a list, not a weighting, one field. So an address backs one validator at a time, and spreading a stake across two of them means two addresses, each with its own staker record.

That is a genuine option and one worth considering, since concentration is the one cost a staker imposes on everybody else rather than only on themselves. It is just not a setting inside a single stake, and it carries the ordinary overhead of a second address: another balance to watch, and the same backup discipline covering both.

The check. Look at the delegation field on each address separately. There is no combined view in the protocol, because there is no combined thing.

Two smaller ones worth naming

  • Stopping after the deactivation. Deactivating is not withdrawing. A balance left inactive earns nothing and will sit there indefinitely until someone sends the other two transactions. The three steps are walked in how to unstake NIM.
  • Reading the deactivation amount backwards. The set active stake transaction does not take the amount you want to unstake. It takes the balance to leave active. Pass the amount somebody typed and you unstake everything except it. Every interface worth using converts that for you, and anyone building the transaction by hand should assume they have it the wrong way round until they have tested it.

Running all of these checks at once

They collapse into four things you can read in about a minute, and none of them require trusting us:

  1. Your staker record. Is delegation set, is inactiveFrom what you expect, and are the balances where you think they are.
  2. Your validator's row. Elected or not, on the validators page, before anything about fees.
  3. The epoch. Has an election block passed since your last stake change.
  4. The transaction itself. In the block explorer, or drawn as edges around your address in NimMap.

If a stake still looks wrong after those four, it is worth writing to us, because it is probably something we have not documented yet. Everything else we have written is on the Learn hub.

All live figures on this page are a single reading taken at block 61,538,832 on 14 September 2026 and will have moved since. Nothing here is financial advice, we publish no price figures anywhere on this site, and nothing on this page promises a reward.

Questions people ask

I staked NIM and I am not earning anything. What is wrong?
Check three things in order. Is your stake delegated to a validator at all, because undelegated stake is not eligible for rewards. Is that validator being elected, because a registered validator that is not elected produces no blocks and has nothing to distribute. And has an election block passed since you staked, because stake changes only count from the next one. None of the three is a fault in your wallet.
Do I have to unstake before I can switch to another validator?
No, and yes to half of it. Your NIM never has to leave the staking contract, so there is no retire, no withdrawal and no new staker record. But the protocol will only accept an update staker transaction once your active balance is zero and the inactive balance has been released, which is the same lock as unstaking. So you skip the withdrawal, not the wait.
Can I stake NIM on an exchange earn product instead?
You can use such a product, but it is not Nimiq staking. Nimiq's own staking FAQ states that exchanges supporting NIM do not offer direct staking. If you deposit NIM somewhere so that it can earn on your behalf, a company holds your coins and its records say what you own. Nimiq staking is a transaction signed by your account, and the delegation is on the public ledger against your own address.
Is the minimum 100 NIM or 1000 NIM?
Both figures are real and they answer different questions. 100 NIM is the protocol floor for creating a staker, per the developer documentation. The official staking page said as little as 1000 NIM when we read it on 14 September 2026, which is an interface asking for more than consensus does. Treat 100 NIM as the floor the chain enforces and whatever your wallet shows as the floor you actually face.
I sent a retire transaction too early and it never appeared. Did I lose anything?
No. The staking contract rejects a retire while the inactive balance is still locked, so the transaction is invalid rather than merely unlucky. It does not mine, your staker record is untouched and no NIM moves. Sending it again immediately does not help, because the only thing that changes the answer is the chain head reaching the release height.
Can I split my stake between two validators?
Not from one address. A staker record holds exactly one delegation field, so an address backs one validator at a time. Splitting means using two addresses and creating a staker on each, which also means two backups to keep straight and two records to watch. It is a real option, just not a setting.
Which of these mistakes can actually lose my NIM?
None of them, and that is worth saying plainly. Albatross punishes validators by burning rewards and by jailing them, not by confiscating delegated principal. What these mistakes cost is time, rewards you did not earn, and in the jailed case access to your own funds until the jail ends. The one thing that does lose NIM outright is losing your backup, which is a wallet problem rather than a staking one.

Sources

  • Nimiq Developer Center, Stakers, the staker state machine, the four steps an update staker involves, the 100 NIM minimum, no partial removal of retired stake, and the rule that a staker with no validator is not eligible for rewards
  • Nimiq Developer Center, Validators, the on chain validator record and its fields, deactivation taking effect at the next election block, and extended offline periods causing deactivation
  • Nimiq Developer Center, Staking FAQ, official FAQ: exchanges supporting NIM do not offer direct staking, funds available 12 hours to 4 days depending on validator status, payout periodicity is validator policy
  • Nimiq, Staking, official staking page, "as little as 1000 NIM" and the Nimiq Wallet named as the place to do it, read 14 September 2026
  • core-rs-albatross, staker.rs, the node software itself: update_staker fails if the active balance is not zero or the inactive balance is not released, retire_stake fails on an unreleased balance, and reactivate_all_stake only moves released funds back to active. Read 14 September 2026
  • Validator records, live from our own node, the 52 records, their inactivity flags, balances and staker counts, read at block 61,538,832 on 14 September 2026
  • A staker record, live from our own node, our own delegation, used on this page as the worked example of what a staker record does and does not contain