Protocol
Invalidation & revalidation
Cryptographic authentication is sticky. What can flip a pending transaction is a small, known set of state surfaces, fixed at admission, so a node can cheaply drop dead transactions and keep builders clear of wasted work.
Sticky vs hot
| Concept | Meaning |
|---|---|
| Sticky (crypto) | Canonical authenticators are stateless over the signature payload: authenticate(hash, data) does not flip because of unrelated chain state. |
| Hot (state) | The state surfaces below: payer/sender balance, protocol or 2D nonce slots, sender/payer actor_config, account-state/lock (config-change txs), and expiry. |
Classic AA re-simulates wallet code because validation lives in the account. Here, once admitted, the node should not rediscover dependencies; they were fixed at first sight.
Invalidation surfaces (known at admission)
- Payer balance: sponsored 8130 txs; sender balance for self-pay / 1559 / 7702.
- Nonce: protocol nonce or 2D channel slot; omitted for nonce-free (expiry instead).
- Sender actor_config: one slot.
- Payer actor_config: when sponsored.
- Config-change extras: account-state / lock slot + up to ~3 actor slots touched by the change.
- Expiry: transaction and/or actor key; always for nonce-free.
Three drop semantics
| Concept | Meaning |
|---|---|
| Exact-match | Nonce, actor-config, account-state/lock. Any write to the watched slot → drop; no need to re-check the old value. |
| Threshold (balance) | Balance moves often, so re-evaluate affordability against the sum of inflight reservations rather than dropping on every touch. Self-spend from a payer's own mined txs nets out. |
| Time (expiry) | Wall-clock: drop when the transaction or actor-key expiry passes, proactively about a block ahead. |
Invalidate ahead of the builder
Because every surface is known at admission, a node can watch the state it read and drop dead transactions before block building spends work on them, instead of discovering failures mid-pack. How a node feeds per-block state changes into that check, and the index that makes it cheap, are covered in Mempool design.
Blast radius & locks
The reason invalidation matters for admission is blast radius: without bounds, one actor_config write could invalidate every pending transaction that authenticated as that account, and one balance shock every transaction that account pays for. A node bounds each per account, and locking drives the signature blast to zero: a locked account's actor set is frozen, so config can no longer flip a validated transaction. That is exactly why a node can grant a locked account a higher rate.
The per-account counters and the balance-book accounting for locked, trusted payers live in Mempool design · account limits; why locks unlock higher throughput is in Authenticators & locks.
What builders still check
Once dead transactions are pruned, a selected tx should already be live. Cheap confirmations before / during inclusion remain:
- Nonce lane still free (or nonce-free still inside window).
- Payer still covers gas under current fees if needed.
- Expiry still valid.
- Optional: one actor_config SLOAD still matches admission.
- Lock still compatible with any account_changes.
Execution order after selection: Block building & execution.
Why canonical-only keeps this bounded
Non-canonical authenticators are not admitted on the 8130 path at all: only the canonical set can authenticate transactions for inclusion (they still run inside ordinary EVM execution). That restriction is what keeps the invalidation surface complete and enumerable, because canonical authenticators are stateless over the signature payload and carry no open-ended state dependencies. Extending the allowlist beyond the canonical set would reintroduce validation-scope tracing and defeat the bounded-invalidation model, so production deployments stay canonical-only.