A Nonce Is Not Replay Protection Until Someone Enforces It
A signed message can be copied and presented again. Its signature proves that specific bytes were signed; it does not, by itself, prove that the permission is still active or unused. Replay protection depends on the con
A signed message can be copied and presented again. Its signature proves that specific bytes were signed; it does not, by itself, prove that the permission is still active or unused.
Replay protection depends on the consumer checking the authorizationβs scope, time window, and use state.
Three values that are easy to confuse
-
Authorization nonce: part of a principal-signed permission. PriorSeal also carries a
maxUseslimit; the usual single-use setting is1. - EVM transaction nonce: part of a senderβs transaction sequence on a specific chain. It helps correlate an observed transaction, but it is not the authorizationβs use counter.
- External decision reference: a digest can bind an external decision to an authorization. That binding does not automatically make the external decision single-use across multiple authorizations.
These values may be linked in one evidence chain, but they make different claims.
A pending transaction has not consumed the authorization
In PriorSeal, an accepted authorization includes the canonical intent, principal, delegated executor, validity window, audience, policy hash, signature, and a single-use authorization nonce.
A pending correlated transaction remains a candidate. A confirmed or reverted transaction on the requested chain, from the delegated executor and with the authorized transaction nonce, consumes the authorizationβs single use. The observed action is correlated separately; a material mismatch is recorded as a mismatch rather than reopening the permission.
This distinction matters during retries. A timeout or pending observation is not proof that execution failed, and blindly submitting again can create a second transaction. Keep the authorization identity, transaction identity, and retry/recovery state separate.
Make consumption durable across workers
An in-memory βusedβ flag in one process cannot coordinate two workers. If a workflow needs atomic single-use enforcement across concurrent requests, its adapter needs shared durable state and a clear recovery path.
That rule applies to external decisions too. A PriorSeal authorization can be single-use while the external decision it references remains reusable. If the business rule says that decision itself may be consumed only once, enforce that with a durable atomic registry keyed to the decisionβs identity.
Expiry does not erase evidence
A signed time window limits when an authorization can be accepted or an execution can occur under the relevant policy. In PriorSeal, Intent.validUntil is evaluated against the containing blockβs execution timestamp.
That is separate from receipt retention. The receipt is immutable signed evidence and can remain verifiable after the intent window closes.
A short review checklist
- What exact intent, principal, executor, audience, and policy does the signature cover?
- Which authorization nonce and use limit does the consumer enforce?
- Is consumption coordinated atomically across workers?
- How are pending observations and lost responses recovered without an unsafe resubmission?
- Does an external decision have its own one-time-use rule, or is it only bound by reference?
A nonce is one input to replay protection. The guarantee comes from enforcing its scope and use state at the point where the authorization is accepted and consumed.
For implementation details, see the signed authorization design, the lifecycle and state model, and the SDK guide.
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.