DX402 / Durable evidence

Keep a private copy of your API response.

Save an encrypted copy of the API response you paid for. Retrieve it later and verify that it matches what was delivered.

Get started API reference

Start with your role

I bought an API response

Use a seller that supports DX402. Keep the payment ID and the buyer key used for that purchase. Retrieve the evidence record, download the encrypted copy, then decrypt and verify it locally.

Open the integration guide

I sell access to an API

Add the durable-evidence hook to your seller integration. Once the payment succeeds, encrypt the delivered response, upload it to the configured storage, and anchor the evidence.

Open the integration guide

How it works

The seller saves an encrypted copy of the response and records its location and content hash. The buyer can retrieve that copy later and check that its decrypted content matches the recorded hash.

Access uses the buyer’s encryption key material. Key recovery depends on the network, wallet, and integration; supported flows can recover it from the payment or use an explicitly declared buyer key.

API reference

GET /dx402/evidence/{paymentId}

route	what it does
`POST /dx402/anchor`	record a pointer and sign its receipt
`GET /dx402/evidence/{paymentId}`	what is anchored for that payment
`GET /dx402/receipt/{paymentId}`	the signed EIP-712 attestation
`GET /dx402/blob/{paymentId}`	the sealed bytes. The store is private: a pointer resolves through here, never through a public bucket, and it addresses the payment rather than a storage key so old pointers survive a re-layout
`GET /dx402/stats`	storage configuration and evidence counters
`POST /dx402/recover`	not implemented in v0.1 — answers 501 rather than pretending

Architecture and responsibilities

The seller handles the response, the facilitator records the evidence, and the buyer decrypts it. In direct mode, the facilitator holds neither the plaintext nor the buyer’s private key.

piece	runs	holds
`x402-axum` the seller hook	in the seller, at the one point where the delivered body and the settlement identity both exist	the plaintext. It encrypts and uploads.
`src/dx402/` this facilitator	notary and index: signs EIP-712 receipts, records pointers	in `direct` mode, neither plaintext nor key material
`x402-reqwest` the buyer	fetches, decrypts and checks `contentHash`	the private key, which never leaves that side

Encryption and verification

Evidence storage is independent of payment success. If saving evidence fails, the payment result is preserved and the integration reports why evidence was skipped. Buyers should check that evidence was actually created before relying on later recovery.

contentHash is over the PLAINTEXT. Over the ciphertext it would only prove the blob was not corrupted. Over the plaintext it proves the anchor decrypts to what was actually delivered — which is the entire claim.
paymentId is the AEAD associated data, and it is keccak256(caip2Network || txHash). Derive it differently on either side and decryption fails with nothing to point at.
Anchoring is publishing. Retention defaults to 90 days on purpose. A permanent, irrevocable anchor is a decision the buyer has to make, not a default someone inherits.
Key validation. Small-order ed25519 keys are rejected to protect the encryption process.
Signature metadata. EVM key recovery uses the facilitator’s EIP-712 metadata lookup.

Storage and retention

Storage availability and retention depend on the configured backend. The table below reports the current service configuration.

backend	retention	revocable	public	enabled
loading…

Live service details

—

responses anchored

GET /dx402/stats

—

default retention

GET /dx402/stats

—

active backend

GET /dx402/stats

—

receipt signer

signs attestations only — no funds, no gas

Project status and specification

DX402 is the durable-evidence extension implemented by Ultravioleta DAO. Read the specification and integration details. It is not part of the core x402 standard.