Problem
A Core node can start the Random Sampling prover while it is admitted to the active sharding table. If staking changes later remove that identity from the sharding table, the already-running prover never reconciles eligibility and keeps ticking.
The contracts still fail closed, so this is not an authorization or fund-safety issue. It is avoidable operational waste: challenge gas estimation or proof submission is rejected, producing RPC traffic, CPU work, and repetitive warning logs every prover interval.
Why membership can change
StakingV10 removes an identity from the sharding table when stake falls below the minimum during redelegation or withdrawal. Admission is therefore not permanent for the lifetime of a daemon process.
Current lifecycle gap
- eligibility is considered only while binding the prover;
- after a successful bind, the retry timer is cleared;
- enabled handles are not rechecked;
- losing membership therefore does not stop or re-arm the prover.
An audit harness reproduced the state transition:
{"beforeEnabled":true,"membershipAfter":false,"afterEnabled":true}Desired behavior
- Reconcile Random Sampling eligibility at a low-frequency cadence or after an eligibility-shaped contract rejection.
- On authoritative non-membership, detach and stop the active handle, then wait for readmission.
- When membership returns, bind and start again without restarting the daemon.
- A transient identity/membership RPC error must preserve a healthy active handle rather than flapping it.
- Serialize reconciliation with shutdown so an in-flight lookup cannot resurrect a prover after
stop().
Acceptance tests
- admitted → removed stops the existing handle;
- removed → admitted starts a fresh handle;
- membership RPC failure while active does not stop the handle;
- concurrent shutdown cannot re-enable the prover.
Scope
Agent lifecycle only. No contract change is required.
Problem
A Core node can start the Random Sampling prover while it is admitted to the active sharding table. If staking changes later remove that identity from the sharding table, the already-running prover never reconciles eligibility and keeps ticking.
The contracts still fail closed, so this is not an authorization or fund-safety issue. It is avoidable operational waste: challenge gas estimation or proof submission is rejected, producing RPC traffic, CPU work, and repetitive warning logs every prover interval.
Why membership can change
StakingV10removes an identity from the sharding table when stake falls below the minimum during redelegation or withdrawal. Admission is therefore not permanent for the lifetime of a daemon process.Current lifecycle gap
An audit harness reproduced the state transition:
{"beforeEnabled":true,"membershipAfter":false,"afterEnabled":true}Desired behavior
stop().Acceptance tests
Scope
Agent lifecycle only. No contract change is required.