TrustReceipt provides cryptographically verifiable, tamper-evident and exportable evidence for auditing agentic-commerce operations, designed to support eIDAS-aligned, ESIGN/UETA and UK retained trust services law flows.
A TrustReceipt is not a legal qualified signature by itself. It is structured evidence that a regulator, auditor or court can examine offline, paired with the legal framework that applies in your jurisdiction.
What is a TrustReceipt
Every time an AI agent reads catalog data, modifies a cart or completes a checkout in a Trusteed-connected store, the platform emits a detached JWS receipt signed by the merchant's Ed25519 key. The receipt records who did what, on which bucket (discovery, customer or checkout), against which input and output hashes, and at what time. It can be exported, re-verified offline, and produced as evidence years later.
Legal frameworks and current status
Trusteed maps every TrustReceipt to a `legal_posture` enum so consumers know exactly what legal weight to assign. AdES-candidate claims are only emitted when an RFC 3161 qualified timestamp is present.
Parameters we accept
Without a qualified TSP we emit `ades_candidate_timestamped` (with TSA) or `ades_candidate_no_tsa` (without). QTSP integration (InfoCert) deferred to spec 050.
Parameters we accept
EUDI dependency on Wallet Relying Party (WRP/RPRC) auto-registration is unproven cross-border. Pilot pending member-state rollout.
Parameters we accept
ESIGN §101(c) consumer-disclosure requirements implemented as signed evidence records. Counsel approval pending for production posture; current canary is observe-only.
Parameters we accept
Post-Brexit divergence tracked. UK Trust List integration ships behind feature flag pending ICO guidance on cross-border AI evidence.
Anatomy of a TrustReceipt
A TrustReceipt is a detached JWS (compact form) plus a small set of unsigned envelope fields. The signed payload is canonicalized with RFC 8785 before hashing. Raw input/output bodies never leave the merchant's encrypted vault.
{
"id": "trcpt_01HXY...",
"callId": "call_01HXY...",
"agentId": "agt_acme_browser",
"merchantId": "mch_paco_sandias",
"bucket": "checkout",
"tool": "complete_checkout",
"inputHash": "8f4a...c2",
"outputHash": "a1d9...77",
"signingKeyKid": "mch_paco_sandias-2026Q2",
"jws": "eyJhbGciOiJFZERTQSIsImtpZCI6...",
"jwksSnapshotUrl": "https://trusteed.xyz/.well-known/jwks/snapshot/2026-05.json",
"legal_posture": "ades_candidate_timestamped",
"createdAt": "2026-05-12T10:14:33Z"
}How verification works
Fetch the snapshot URL embedded in the receipt. The snapshot is itself signed and tied to a key history with validity windows.
Use the `kid` in the JWS header to pick the correct Ed25519 public key. Verify with any standards-compliant JOSE library — no Trusteed code required.
Reconstruct inputHash and outputHash from raw bodies (if disclosed). Compare against the signed values. Any mismatch = tampered.
If a TimeStampResp is attached, verify its full chain (TSA cert, OCSP/CRL, EKU, tolerance window). This anchors the receipt in real-world time.
AI agents reading or writing against a Trusteed-connected store can request and verify TrustReceipts as first-class evidence. This enables agent-to-agent auditing, multi-hop attribution chains, and dispute resolution without human escalation.
Minimum agent-side verification flow (Node.js, no Trusteed SDK required):
import { compactVerify, createLocalJWKSet } from "jose";
// 1. Get a receipt from the merchant API
const r = await fetch(`https://trusteed.xyz/api/v1/trust/receipts/by-order/${orderId}`)
.then((r) => r.json());
// 2. Resolve the JWKS snapshot referenced in the receipt
const jwks = await fetch(r.jwksSnapshotUrl).then((r) => r.json());
// 3. Verify the JWS signature (Ed25519, EdDSA)
const { payload, protectedHeader } = await compactVerify(
r.jws,
createLocalJWKSet(jwks),
);
// 4. Decide on legal posture before claiming AdES
if (r.legal_posture !== "ades_candidate_timestamped") {
console.warn("Receipt valid but no qualified timestamp present");
}Agent metadata
{
"documentType": "trust-receipt",
"signatureAlgorithm": "Ed25519",
"canonicalForm": "RFC 8785 JCS",
"timestampStandard": "RFC 3161",
"transportFormat": "compact JWS (RFC 7515)",
"verifierLibrary": "@trusteed/receipt-verifier",
"discovery": "https://trusteed.xyz/.well-known/mcp.json",
"policy": "https://trusteed.xyz/.well-known/agent-policy.json"
}Under ESIGN/UETA (US), UK ECA 2000, and eIDAS Art. 25 (EU), electronic evidence cannot be denied admissibility solely because it is electronic. A TrustReceipt provides the tamper-evidence and non-repudiation primitives a court typically asks for. Final admissibility always depends on the forum and the underlying transaction.
No. For Advanced Electronic Signature (AdES) posture, we use a standards-compliant RFC 3161 TSA. Qualified Electronic Signature (QES) requires a QTSP and is on the roadmap (spec 050).
Signed JWS are persisted in the merchant's audit log with a hash chain (RFC 8785). Raw input/output remain in an encrypted vault (AES-256-GCM). The JWKS history is published at a stable URL for offline verification.
Old receipts remain verifiable against the JWKS history snapshot referenced at issuance time. Revocation evidence is published as a signed JWS extension; verifiers MUST check it before claiming AdES posture.
Every agentic-commerce operation leaves a signed receipt. Start free or read the developer documentation.