Module deregister 

decdn node deregister — leave the active set (ADR 003 § Node Registry).

The reverse of decdn node register, and the first leg of a full bond exit. deregisterNode() clears declaredMbps, which is what releases the bondRequired(declaredMbps) floor requestUnbond enforces (#1351); the complete sequence is

decdn node deregister  ->  decdn node unbond --all  ->  [window]  ->  decdn node unbond

Two things about that sequence drive this command’s shape, and both are disclosed rather than left to be discovered:

• The bond does not move here. deregisterNode touches the registration and the tier, nothing else: the deposit stays put and stays fully slashable. An operator who reads “deregister” as “exit and refund” has done only the first of three steps. This is the likeliest misconception, so the summary says so on every run.
• Re-entry is not free. The call bumps registrationNonce[nodeId], which invalidates any registration signature already signed against the old nonce, and clears the tier — so coming back costs a fresh declareMbps + registerNode (the bond itself is retained, so no new funds are needed; ADR 003 § Node Registry).

Unlike unbond there is no phase to select from chain state — this is one transaction that either applies or reverts. There is still a pre-flight read, of registry state (getNodeByAddress + ejected, NOT the composite isActive — see build_plan), so the two states the operator can be in are named up front instead of surfacing as a bare NodeNotActive revert: already deregistered, or ejected.

Both exit the same way — decdn node unbond --all, which releases the tier via declareMbps(0) for any inactive operator (#1361) — but they need different advice about RE-ENTRY, which is why the states are distinguished: a blacklist-ejected operator’s registerNode reverts until governance calls unEjectNode, so pointing them at decdn node register would be wrong.

Functions

run

Entry point for decdn node deregister.