Context
Stake-bound account removal can delete the account context for a queued top-up without deleting the queued deposit, letting that stale top-up bind to a later replacement account for the same node pubkey.
Claim
Stake-bound account removal can delete the account context for a queued top-up without deleting the queued deposit, letting that stale top-up bind to a later replacement account for the same node pubkey.
Flow
The path requires a top-up to stay in deposit_queue long enough for a min/max stake change, stake-bound removal, withdrawal completion, and account deletion, likely through deposit backlog or a low/zero deposit-processing cap. The replacement deposit must arrive after the old full-withdrawal block removes the account; if it arrives before deletion, the existing account's has_pending_withdrawal flag causes deposit rejection/refund instead of replacement account creation.
Impact
The old top-up can be interpreted under the wrong account lifecycle. It can be popped against a replacement account with different withdrawal credentials and consensus key, enter refund/removal handling using replacement metadata, or be skipped if processed after deletion but before replacement.
Root Cause
The implementation misses the invariant check or state update described in the claim, allowing the accepted state to be consumed later as if it were valid.
Code
Related Issues/PRs
The following existing items touch the same trust boundary, adjacent root cause, or likely remediation stack.
Note that #339 is stale queued top-up rebinding after account deletion/replacement.
Fix
Add the missing validation or state update at the affected boundary, reject or repair inconsistent state before it is consumed, and add a regression test that exercises the trigger and asserts the bad state cannot reach the impacted path.
Context
Stake-bound account removal can delete the account context for a queued top-up without deleting the queued deposit, letting that stale top-up bind to a later replacement account for the same node pubkey.
Claim
Stake-bound account removal can delete the account context for a queued top-up without deleting the queued deposit, letting that stale top-up bind to a later replacement account for the same node pubkey.
Flow
The path requires a top-up to stay in
deposit_queuelong enough for a min/max stake change, stake-bound removal, withdrawal completion, and account deletion, likely through deposit backlog or a low/zero deposit-processing cap. The replacement deposit must arrive after the old full-withdrawal block removes the account; if it arrives before deletion, the existing account'shas_pending_withdrawalflag causes deposit rejection/refund instead of replacement account creation.Impact
The old top-up can be interpreted under the wrong account lifecycle. It can be popped against a replacement account with different withdrawal credentials and consensus key, enter refund/removal handling using replacement metadata, or be skipped if processed after deletion but before replacement.
Root Cause
The implementation misses the invariant check or state update described in the claim, allowing the accepted state to be consumed later as if it were valid.
Code
remove_accountremoves the account but does not purge same-pubkey queued deposits: https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/consensus_state.rs#L430-L444.Related Issues/PRs
The following existing items touch the same trust boundary, adjacent root cause, or likely remediation stack.
Note that #339 is stale queued top-up rebinding after account deletion/replacement.
Fix
Add the missing validation or state update at the affected boundary, reject or repair inconsistent state before it is consumed, and add a regression test that exercises the trigger and asserts the bad state cannot reach the impacted path.