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?
Email support@dnaprotocol.org.
Social network
@DnaOnChainGet in Touch
Send your enquiry directly by email.
Email DNA ProtocolOpens your email app. Review and send your message there.


