Agentic Consent Receipt + Replay Verifier
Proof-based consent verification with cryptographic signatures, anti-replay protection, and offline verification for autonomous agents.
Generate Demo Receipt
Create a signed consent receipt with custom parameters. The demo uses HMAC-SHA256 for browser compatibility; production uses Ed25519.
Generated Receipt
This receipt is signed with the demo key pair and can be verified below.
Verify Receipt
Test the receipt above against different transaction contexts. Use the toggle to switch between online and offline verification modes.
Verification Checks
| Check | Result |
|---|---|
| Signature Valid | — |
| Not Expired | — |
| Scope Valid | — |
| Constraints Valid | — |
| Replay Detected | — |
| Offline Status | — |
What is ACRRV?
ACRRV (Agentic Consent Receipt + Replay Verifier) is a proof-based consent verification system for AI agents and autonomous transactions. It gives merchants, issuers, and platforms a way to verify that an agent was explicitly authorised to perform an action—with cryptographic signatures, scope limits, and anti-replay protection.
Consent receipts are machine-verifiable evidence of user consent: who delegated, which agent, what scope (e.g. pay, book, cancel), and what constraints (amount, merchant, time window). The replay verifier ensures each receipt can only be used once, preventing double-spend and fraud. This demo shows how receipt generation and verification work in the browser; production deployments use Ed25519 signing and optional backend nonce ledgers.
ACRRV fits into agentic proof and agentic payments infrastructure: it is the consent layer that lets businesses trust agent-driven transactions with verifiable evidence instead of assumptions.
Why Consent Receipts for AI Agents?
When AI agents act on behalf of users—making payments, booking travel, or renewing subscriptions—merchants and issuers need more than a UI claim that the user clicked “allow.” They need verifiable proof of consent: what was authorised, by whom, when, and within what limits.
Proof of consent, not just capture
Consent capture (the moment the user agrees) is different from consent proof (the evidence that can be checked at transaction time). ACRRV produces signed receipts that any verifier can validate: signature, expiry, scope, and constraints. That supports dispute resolution, issuer authorisation checks, and merchant acceptance policies.
Anti-replay and double-spend prevention
Each receipt includes a unique nonce. Once the nonce is used (or recorded in a ledger), the same receipt cannot be reused. That prevents replay attacks and double-spending when agents operate at scale or in offline-capable flows.
Offline and edge verification
Signed receipts can be verified locally when the device or agent is offline. Freshness windows and optional reconnect sync keep verification sound without requiring a live round-trip for every transaction. That matters for field devices, transport, and intermittent connectivity. See resilient offline verification for more context.
How It Works
ACRRV lets agents prove they have explicit consent before taking action. Each receipt is cryptographically signed and protected against replay attacks. Below are four typical roles in an agentic consent flow: the user delegating to a shopping or travel agent, the merchant verifying the receipt before accepting payment, and the issuer maintaining an audit trail.
Shopping Agent
The user gives the agent a signed receipt granting permission to pay up to a set amount (e.g. $500) on specific categories such as travel bookings only. Before each transaction, the agent (or wallet) presents the receipt; the verifier checks signature, scope, and constraints. The receipt is verified before the payment is accepted.
Travel Agent
The agent books flights and hotels with explicit consent that can be limited to specific merchants or categories. Receipt constraints define which merchants are allowed, maximum amounts, and currency. The travel platform or issuer can verify the receipt before confirming the booking.
Merchant Verification
The merchant checks receipt validity before accepting an agent-driven transaction. Signature, expiry, scope, and constraints (amount, merchant ID, currency) are verified. Anti-replay protection ensures the same receipt cannot be used twice, preventing double-spending and fraud.
Issuer Audit Trail
The issuer (or platform) inspects the nonce ledger to detect unauthorized transaction attempts and prevent fraud. Each used nonce is recorded; replay attempts are rejected. The audit trail supports compliance and dispute resolution without storing full receipt payloads.
Technical Architecture
ACRRV is built with production-grade cryptography and a modular design so it can be integrated into agentic payments, merchant verification, and issuer authorisation flows. The receipt format is canonical JSON; signing uses Ed25519 in production (this demo uses HMAC-SHA256 in the browser for compatibility). Anti-replay is handled by nonce tracking with pluggable backends; offline verification is supported via signed payloads and optional reconnect sync.
Below are the main technical components: receipt structure, signing and verification, replay protection, and offline behaviour.
Receipt Format
Canonical JSON structure with all required claims so that signing and verification are deterministic:
- Receipt ID (UUID v4)
- Agent & Delegator IDs
- Consent Scope (array of allowed actions)
- Constraints (amount, merchant, time window)
- Nonce (replay protection)
- Offline Policy (optional)
Ed25519 Signing
Asymmetric signatures (Ed25519 in production) ensure:
- Authenticity (issuer verified)
- Integrity (payload unchanged)
- Non-repudiation (issuer cannot deny having signed)
- No key material in flight
Anti-Replay
Nonce tracking prevents receipt reuse (replay attacks):
- In-memory store (fast)
- File-based persistence
- Adapter interface (Redis, Postgres)
- Automatic expiry cleanup
Offline Verification
Agents can verify when offline:
- Signature valid offline
- Constraints checked locally
- Freshness window limits drift
- Sync on reconnect when connection is restored
API Endpoints
The ACRRV backend exposes REST endpoints for generating signed consent receipts, verifying them against a transaction context, and inspecting claims without verifying the signature. Public keys are served by key ID for signature verification. Full API documentation and examples are in the README.
Use the demo above to generate and verify receipts in the browser; for production integration, use the endpoints below or the TypeScript library.
POST /api/receipts/generate
Create and sign a consent receipt
POST /api/receipts/verify
Verify receipt against transaction context
POST /api/receipts/inspect
Decode receipt claims (no signature check)
GET /api/health
Health check and timestamp
GET /api/public-keys/:keyId
Retrieve public key for signature verification
Frequently Asked Questions
What is ACRRV?
ACRRV stands for Agentic Consent Receipt + Replay Verifier. It is a system that produces cryptographically signed consent receipts for AI agents. Each receipt proves that a user (delegator) authorised an agent to perform certain actions within defined scope and constraints. The replay verifier ensures each receipt can only be used once, preventing double-spend and replay attacks.
Why do AI agents need consent receipts?
When an AI agent makes a payment or booking on behalf of a user, merchants and issuers need verifiable evidence that the user consented. A UI that says “user agreed” is not enough for dispute resolution or compliance. Consent receipts provide machine-verifiable proof: who delegated, which agent, what actions, and what limits (amount, merchant, time).
How does anti-replay work?
Each receipt contains a unique nonce. When the receipt is used (e.g. for a payment), the nonce is recorded in a ledger or store. If the same receipt is presented again, the verifier detects that the nonce was already used and rejects it. That prevents the same consent from being reused for multiple transactions (double-spending) or replayed by an attacker.
Can consent receipts be verified offline?
Yes. The receipt payload is signed; the signature can be verified locally without a network call. Constraints (amount, merchant, expiry) can also be checked offline. Replay detection may be deferred until reconnect, or handled with a freshness window. That makes ACRRV suitable for edge devices and intermittent connectivity. See resilient offline verification for more.
How does this relate to AffixIO agentic payments?
ACRRV is a lab prototype that demonstrates the consent-receipt and replay-verification layer. AffixIO Agentic Payments and Agentic Proof describe the broader verification and trust infrastructure for agent-driven transactions. Consent receipts are one component of that: they prove user consent; AffixIO can also verify agent identity, policy, and eligibility.
Want to build with ACRRV?
Full source code, TypeScript library, CLI, and deployment guides. Integrate consent receipts and replay verification into your agentic payments or merchant flows.
Get API Access