How much NIM do you need to run a Nimiq validator?

A deposit of 100,000 NIM, locked in the staking contract from the moment the validator is created until it is deleted. It is not a fee and it is not spent: the protocol returns it when you delete the validator, which takes a three step exit and up to about two days. It can shrink slightly, because fees from failed transactions are taken from it.

What hardware does a Nimiq validator need?

Nimiq publishes no hardware specification, and we are not going to invent one. What the documentation does say is that history sync mode uses far more disk and syncs very slowly, so a full node is the sensible mode. The requirement that actually matters is not a specification at all: the machine has to stay online, because time offline is what gets a validator deactivated.

Will my validator definitely produce blocks?

No. Election is re-decided at every epoch boundary and slots are shared out in proportion to stake, so a small validator is often not selected. On 14 September 2026 the 39 validator records carrying no inactivity flag held about 9.09 billion NIM between them, which puts an average slot behind roughly 17.8 million NIM. A 100,000 NIM deposit on its own is a small fraction of one slot.

What happens if my validator goes offline?

Missed block production burns the reward for that slot and suspends it briefly, which is minor and self correcting. Extended offline periods cause the validator to be deactivated, and a deactivated validator is not elected, so it earns nothing and neither do its stakers until it is reactivated. The node can be configured to send the reactivation transaction itself, which is what the separate fee key exists to pay for.

Can I lose the deposit?

Not by being offline. Albatross punishes with burned rewards and with jailing rather than by confiscating the deposit, and the documented exit returns the full 100,000 NIM. What you can lose is the ability to reach it: the private keys have no recovery path, and the documentation says so in as many words. Lose those and the deposit stays where it is.

What happens to my stakers if I shut the validator down?

They are protected by the protocol rather than by you. Delete only completes once all delegations have been withdrawn, and if stake is still there the chain leaves a tombstone record so those stakers can still get their NIM out afterwards. The cost lands on them as time rather than principal, which is the reason to give notice before winding one down.

Should I run a validator or just delegate?

Delegating is the right answer for most people and it costs nothing to say so. Running a validator makes sense if you want to operate infrastructure, if you have a reason for the node to exist beyond rewards, or if you can keep it online without it turning into an unpaid second job. If the only reason is earnings, delegating gets you exposure to the same reward pool with none of the uptime obligation.

How to run a Nimiq validator: requirements and a reality check

What it actually requires

The official documentation covers the commands well, so this page does not repeat them. It covers the part that comes after: what you are signing up for, and whether it is worth it. Start with the four things you cannot do without.

Requirement	Detail	The catch
100,000 NIM deposit	Locked in the staking contract from creation until deletion	Returned on exit, but unusable in the meantime and it takes days to get back
A node that stays online	`core-rs-albatross`, in a sync mode that is not history sync	Nimiq publishes no hardware specification. Uptime is the real requirement
Key material	A validator address key, a signing key, a voting key, a reward address	No recovery path. The documentation says so in an exclamation mark
Monitoring	Something that tells you the node stopped, before the chain does	Nobody supplies this. It is yours to build and yours to watch

The deposit

100,000 NIM, and it is a deposit rather than a fee. The protocol locks it for the life of the validator and returns it when the validator is deleted. It exists to make abandoning a validator expensive, which is the point of it, and it has one quiet erosion: fees from failed transactions come out of it, so a badly configured node can shave the deposit down over time.

Worth being clear about what the deposit is not. It is not stake in any competitive sense. A validator can only hold the deposit as its own stake; everything above that has to arrive as delegation from stakers, including from you if you want more behind it, which you send as an ordinary staker rather than as the operator.

The keys, and the sentence to reread

A Nimiq validator is not one key. There are four pieces and they have different jobs, which is a security design rather than bureaucracy:

The validator address key. A Schnorr key pair whose address is the validator's identity. It is the cold key, and because the address is derived from it the address cannot be changed later.
The signing key. A Schnorr key that signs micro blocks. It lives on the running node, so it is the warm one.
The voting key. A BLS key that votes on macro blocks and skip blocks. Also on the node, and the one that participates in consensus.
The reward address. Not a key you generate for this, just the address block rewards are paid to. Choose it deliberately, because everything the validator ever earns lands there.

There is a fifth, optional piece: a fee key on an ordinary account, whose only job is paying the fees on automatic reactivation transactions. It exists because a node that reactivates itself needs a way to pay for doing so without touching the keys that matter.

The documentation puts the important part bluntly: save the private keys securely, there is no way to recover them. That is not the usual boilerplate. There is no seed phrase flow, no support desk and no operator of last resort. Lose the validator address key and the deposit is still on the chain, visible, and permanently out of reach.

Registration is the easy part

In outline: generate the keys with the tools shipped alongside the node, configure the node with them, fund the validator address with at least the deposit, and send a create validator transaction. The node has to have established consensus and be up to date for that transaction to go out. Then you read the validator record back and confirm the public keys, the reward address, the staking balance and the state flags are what you meant.

That is an afternoon. Everything below is the rest of it.

Reality check one: election is a lottery you re-enter every epoch

This is the fact that decides whether any of the rest matters, and it is the one most guides leave until the end. Validators are only selected to produce blocks at the start of every epoch, at the election block, and the selection hands out 512 slots in proportion to stake, drawn against the chain's random seed. Being elected last epoch tells you nothing about this one.

Some arithmetic to size it, from one reading of our own node at block 61,538,832 on 14 September 2026:

52 validator records on chain.
13 of them carrying an inactivity flag, leaving 39 that carried none and were not retired.
Those 39 holding about 9.09 billion NIM between them, which puts an average slot behind roughly 17.8 million NIM.
9 of the 39 holding less than one average slot's worth.
4 records holding nothing but the 100,000 NIM deposit, with no stakers at all.
2,878 stakers delegating across the whole set.

Put the deposit against that average slot and you get the shape of the problem: 100,000 NIM is around 0.6% of one slot. A validator that has only its own deposit behind it is not unlucky when it is not elected. It is the expected outcome, and it will keep being the expected outcome until stakers delegate to it.

So the honest sequencing is the opposite of the intuitive one. Producing blocks does not attract delegation. Delegation is what makes producing blocks likely. How Albatross works covers the election mechanism itself, and our validators page shows who is currently on which side of it.

Reality check two: the cold start has no shortcut

A new validator is asking strangers to move money behind an operator with no history, and the tools the ecosystem uses to judge operators are built out of exactly the history it does not have.

The Validator Trust Score published with the official validators list is the clearest case. It is built from block production history, and its fields fill only once an epoch has ended and only if the validator was selected to produce a block. A brand new validator therefore shows blanks, and a blank score is a fair thing for a chooser to hesitate over even though it is not a fault. Choosing a Nimiq validator teaches readers to read that column, and it teaches them to read it on us too.

We are a live example rather than an observer here. Our own validator, ImpactZero, was registered on 11 September 2026 and held about 3.57 million NIM of total stake from 5 stakers at the reading above, most of it our own delegation. Its reliability and total score are empty. That is the cold start, in our own row, and why we run ImpactZero at 0% fee sets out the whole position with the live sources to check it against, including the ones that will contradict a paragraph like this one as soon as they move.

One more thing about state that is easy to miss until it happens to you. A validator record can change state without its operator sending anything: extended offline periods cause deactivation. Thirteen of the 52 records we read carried an inactivity flag, and there is no way to know from the outside which of those were the operator's decision.

Reality check three: the penalties are aimed at rewards, and at other people

Nimiq does not confiscate the deposit for bad behaviour. It burns rewards and it removes eligibility, which sounds gentler than slashing until you look at who pays.

A missed block. The reward for that slot is burned and the slot is suspended, and it can reactivate itself one block later. Minor and self correcting.
Extended time offline. The validator is deactivated. It is then not elected, so it produces nothing, and every staker behind it earns nothing for as long as that lasts.
Equivocation, for example signing two blocks at the same height. Immediate jailing for eight epochs, all rewards burned, and, the part that should concentrate the mind, your stakers cannot release their funds until the jail ends. A jailed validator also still has to vote, because the protocol needs its slots to reach the votes a macro block requires.

Read that list as an operator rather than as an investor and it says something specific: your mistakes are mostly paid for by other people. Running two instances of the same validator keys, which is the classic way to equivocate by accident, locks up other people's NIM for four days. That is the actual reason to be careful with the signing and voting keys, and it is a better reason than any of the ones about your own earnings.

The economics, without projections

We publish no reward rates anywhere on this site and we are not going to start on the page where the temptation is highest. What can be said honestly is the structure.

What comes in. Rewards are newly issued NIM plus transaction fees, paid every batch, proportional to total stake, and paid on chain to the validator's reward address. Not to stakers. Splitting it with them happens off chain, on a policy you set, publish and are trusted to honour. Where the rewards come from covers the mechanism.

What goes out. Deliberately qualitative, for the same reason our 0% page keeps it qualitative: a monthly figure would be the one number on the page nobody could check. The shape of it is a server that runs continuously, the attention of whoever keeps it running, the monitoring around it, and 100,000 NIM you cannot use for anything else in the meantime. It is steady rather than spiky, and none of it pauses while you are not elected.

What the two have to do with each other. Very little, and that is the point. The costs are certain and continuous; the income is contingent on being elected, which is contingent on delegation, which is contingent on trust you have not built yet. Any model of this that starts with a percentage is answering an easier question than the real one.

Getting back out

Worth reading before you start rather than after, because it is slower than people assume and it is a different sequence from the one a staker follows.

Deactivate. Takes effect at the next election block. The validator stays in the current epoch and cannot be elected in the next, and this opens a reporting window that runs to the end of the following epoch.
Retire. Only accepted once that window has closed, and it is irreversible. This is the point of no return.
Delete. Removes the validator and returns the 100,000 NIM deposit. Only after retirement, and only once the delegations are out. If stake is still delegated, the protocol leaves a tombstone record so those stakers can still withdraw.

End to end, the documentation says it may take up to about two days before the deposit is recovered, and the reason is the reporting window: the protocol is holding the collateral long enough for anyone to submit proof of misbehaviour.

One practical trap. If your node is configured to reactivate itself automatically, it will happily undo the first step of your exit. Turn automatic reactivation off before deactivating, and turn it off in the config file rather than only over RPC, because the RPC change does not survive a restart.

None of this resembles the staker path, which is deactivate, retire and withdraw with a lock measured in hours. Two of the three words are the same and none of the rules are. How to unstake NIM covers that side.

The part that is not technical

Everything above can be planned. These cannot, and they are what actually decides whether somebody is still running a validator a year later.

Keys you cannot lose and cannot recover. That is a filing problem more than a cryptography problem, and it lasts as long as the validator does. Where the backups live, who else can reach them if you cannot, and what happens to all of it if you stop caring about Nimiq in three years.
Somebody has to be awake. Not constantly, but reachable. A node that stops at the wrong hour is deactivated by the time anyone notices, and the cost of noticing late is borne by your stakers as well as by you.
A public promise you have to keep. The moment you publish a fee and a payout policy, people delegate on the strength of it, and the chain does not enforce a word of it. There is no fee field in a validator record. That is a reputational commitment, not a technical one, and it does not expire when you get bored.
Winding down is a thing you owe notice about. We have done it. Our first registration ran from July 2025 and was deactivated, retired and deleted in the August, and the sequence is on chain where anyone can read it. Doing it cleanly matters, because a staker who finds a deleted validator with no explanation attached has every reason to read the worst into it.

So should you run one?

A fair answer, from people with an obvious interest in the question.

Probably not, if the reason is rewards. Delegating puts you behind the same reward pool with none of the uptime obligation, none of the key management, and none of the responsibility for other people's lock ups. Our validators page compares every validator from live chain data and choosing a Nimiq validator is the method for reading it.

Possibly yes, if the node has a reason to exist beyond earning. Because you are building on Nimiq and want infrastructure you control, because you want a full node's view of the chain, or because you think the validator set should be less concentrated than it is and you are willing to be part of that. Those reasons survive a year of not being elected. A projection does not.

That is roughly our own answer, and we have written it out at length in why we run ImpactZero at 0% fee, including the parts that do not flatter us. The rest of the guides are 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.