Four checks, no invitation list
LiveADR 0003: the node status is Active, its stake is at or above min_stake, its heartbeat is inside the configured window, and its VRF key was registered at a slot earlier than the request. fulfill then writes the node, stake and heartbeat it accepted onto the request.
- Node 01heartbeat in windowFulfilled
- Node 02heartbeat in windowEligible
- Node 03heartbeat in windowEligible
- Node 04heartbeat staleIneligible
A heartbeat inside the window
LiveA node heartbeats with its own authority. The window is a registry field between 1 and 150,000 slots, a safety bound rather than a chosen duration. Outside it, the node is ineligible until it heartbeats again.
Stake locked before fulfilment
LiveA deposit that reaches min_stake makes a node Active. Unstaking locks the whole stake until cooldown_end_slot and rejects heartbeat and fulfil meanwhile. The slash authority can still take lamports during that cooldown.
Run a nodeMinimum stake
configured
Heartbeat window
configured
Registered before request
required
Slash
available
Protocol README
Known limitation
“An operator who funds several keys can still choose among those outputs. The cost of each extra key is the configured minimum stake. A minimum of zero does not resist that.”
Many keys, one operator
There is no on-chain list of nodes, so a program cannot draw a winner from every registered key. An operator who registered several keys before a request can submit whichever of those outputs they prefer.
The cost of an identity
Each extra key has to lock at least min_stake, a number the registry authority sets. Zero is allowed, and zero does not resist Sybil.
What would close it
PlannedA stake-weighted draw needs an on-chain node index the programs do not have, and a weight would be an economic policy. ADR 0003 leaves it open. Reputation stays a counter, never a weight.