Close

Fresh Requests and Replay Protection

Cases
10. 10

Fresh Requests and Replay Protection

Technical guide · Updated 17 September 2026 · Digital identity on XRPL.

A valid proof can be stale

Mathematical validity alone does not make an old presentation appropriate for a new request. The verifier must also check the audience, challenge, expiry and any replay state required by its acceptance policy.

Challenge-bound presentations

In the test circuit, a nullifier is derived from the holder secret, nonce and audience. The application uses its request and replay checks alongside cryptographic verification. A nullifier is not a universal identifier or an independent guarantee of anonymity.

Keep state and time explicit

A request can expire while a browser is generating a proof. A service restart, missing record or unavailable status check must not silently become an acceptance. Re-evaluate the request rather than assuming a previously displayed success still applies.

Useful negative tests

  • Present a proof for a different audience
  • Retry an already-consumed request
  • Complete a request after its expiry
  • Check behaviour when the required registry or replay state is unavailable

Ledger history is not replay protection

A historical anchor may remain inspectable long after a request expires. That record does not make a new presentation acceptable. The current application checks and ledger evidence remain separate.

Read the complete reference architecture · XRPL network reference

get in touchQuestions about identity, proofs or ledger evidence?

Social network

@DnaOnChain

Get in Touch

Send your enquiry directly by email.

support@dnaprotocol.org

Email DNA Protocol

Opens your email app. Review and send your message there.