DEV Community

imokokok
imokokok

Posted on

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 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 maxUses limit; the usual single-use setting is 1.
  • 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

  1. What exact intent, principal, executor, audience, and policy does the signature cover?
  2. Which authorization nonce and use limit does the consumer enforce?
  3. Is consumption coordinated atomically across workers?
  4. How are pending observations and lost responses recovered without an unsafe resubmission?
  5. 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.

Top comments (0)