AVIP · A2B Subprotocol

What It Is

A2B is AVIP's subprotocol for agent-to-business payment execution. It specifies how an AI agent can pay a Web2 merchant on behalf of a user or organization, with funds custodied by an on-chain smart contract and every step of the flow policy-checked against a signed Intent.

The counterparty in A2B is a traditional Web2 business — a merchant that has a public API or webhook but no DID, no on-chain identity, and no cryptographic signature. The protocol's job is to constrain the agent and the Platform so that the Web2 side cannot be trusted blindly, cannot walk away with user funds, and cannot leave the user without recourse.

A2B vs A2A. Where A2A choreographs a two-sided exchange between agents that both sign, A2B constructs a one-sided checklist where only the agent signs and the merchant's delivery is attested by Platform + witness data. See AVIP Overview for the side-by-side.

What It Provides

The Three-Act Flow

• Act 1 registers what the agent may do on-chain (order created, funds earmarked).
• Act 2 runs the actual work through a policy gate, producing one ActionTrace record per tool call.
• Act 3 collapses the trace into a Merkle root, anchors a CompletionProof, and releases funds contingent on the checklist being complete.

Each act produces on-chain evidence. If any act fails or times out, the funds path defaults to refund — the user never loses custody.

End-to-End Workflow

The three-act flow above is the high-level shape. The operational workflow below shows how the Action Gateway gates each tool call, how the contract checklist advances slot by slot, and where the deliver-or-refund branches sit:

Funds only move forward when both the off-chain Gateway and the on-chain contract agree; every other path — a denied call, a failed delivery, or a passed deadline — routes back to a retry or a contract-enforced refund.

Step 1: Intent & On-Chain Order Creation

An A2B Intent extends the generic AVIP Intent with fields specific to payment execution:

After signing, the Platform calls A2BOrderGateway.createOrder(intentHash, userAddr, maxAmount, deadline, data). This registers the order on-chain with status = CREATED. Any deviation from the signed Intent at any later step will be rejected by the Gateway or refused by the contract.

The on-chain order is the funds container. Nothing can move through the merchant without the contract's checklist advancing, and the contract advances only when the Gateway's policy and the contract's own invariants both agree.

Step 2: Policy-Gated Execution (Action Gateway)

All agent tool calls route through an Action Gateway — an off-chain policy engine bound to the signed Intent.

For each call, the Gateway verifies:

• The tool is in the Intent's allowedTools.
• The call's arguments are consistent with the Intent's scope and maxAmount.
• Required prerequisite tools have already succeeded (e.g., wallet.deposit before bitrefill.createInvoice).
• The deadline has not yet passed.
• For amounts above requiresConfirmAbove, a user-confirmation record exists.

The Gateway writes one ActionTrace record per call. Each record contains:

The records form a hash chain terminated by a Merkle root. Tampering with any record invalidates every subsequent hash and breaks the on-chain auditRoot.

Decisions are persisted even when the Gateway denies a call. Deny records are audit-critical — they show that the system refused an out-of-policy attempt rather than silently ignoring it.

Step 3: Contract Checklist & Settlement

The on-chain order walks through a fixed sequence of slots. Each slot corresponds to a state change that is only possible when the Gateway has approved a matching tool call.

Each transition is its own on-chain transaction against A2BOrderGateway. The contract refuses transitions that don't follow the checklist (e.g., trying to reach PAID before INVOICE_COMMITTED).

Funds never touch the merchant until the contract sees a committed invoice for a value ≤ deposit, and the payment transaction itself is constructed from the committed invoice's fields. This means the Platform, the agent, or the merchant cannot independently construct a different payment destination or amount.

Additional terminal states:

Step 4: Completion Proof & Sealed Delivery

When the merchant confirms delivery, two things happen in one step:

1. A CompletionProof is constructed and anchored. It contains:

   • intentHash — the signed Intent's hash
   • auditRoot — Merkle root of all ActionTrace records
   • deliveryHash — hash of the merchant-side delivery confirmation
   • verdict — DELIVERED / FAILED / EXPIRED
   • anchorTx — transaction where the proof was written to AnchorRegistry

2. The merchant's deliverable (e.g. gift card code) is sealed with envelope encryption:

   • A fresh symmetric key encrypts the deliverable
   • The symmetric key is encrypted to the user's long-term public key
   • The resulting redemption_ciphertext is stored; the plaintext is never stored
   • Only the user's secret key can open the envelope

The on-chain record contains only the ciphertext hash. The ciphertext itself lives off-chain (Platform DB, IPFS, or user device). This design keeps sensitive merchant deliverables private while still making the fact-of-delivery verifiable.

Timeout Self-Refund: expireOrder

If deadlineUnix passes while the order is still open, anyone can call A2BOrderGateway.expireOrder(intentHash). The contract:

• Verifies block.timestamp > deadline
• Transitions the order to EXPIRED
• Transfers the deposited USDC back to the user's smart account

Refund does not require the Platform, the agent, or the merchant. As long as one Ethereum-compatible node exists somewhere in the world, the user can recover their funds. This is what "runaway-resistant" means at the protocol level.

The same property applies to partial failures: if the agent funds a deposit and then disappears, the deadline acts as a safety valve.

On-Chain Data Per Transaction

A fully-executed A2B order produces multiple on-chain records:

A typical delivered order produces approximately six on-chain state transitions plus the CompletionProof anchor, on an EVM mainnet where A2B is deployed.

Enriched Data Under Every Anchor

Where each on-chain record stores only a 32-byte hash, the data behind that hash is published via ATEL's verification API:

• GET /verify/v1/tx/{txHash} — look up any anchored data by transaction hash
• GET /verify/v1/anchor?key={anchorKey} — look up by anchor key

The API recomputes the hash from the returned data and confirms whether it matches the on-chain anchor. This gives third parties a way to audit the full order end-to-end with nothing more than a transaction hash.

Zero-Trust Audit Commands

The SDK exposes three commands that replicate the audit logic locally:

atel bitrefill verify-intent <intentId>
# Verifies the Intent's Ed25519 signature and checks that the on-chain
# Order exists with matching intentHash, userAddr, maxAmount, deadline.

atel bitrefill audit <intentId>
# Fetches all ActionTrace records, recomputes the Merkle root locally,
# compares against the on-chain auditRoot.

atel bitrefill proof <intentId>
# Fetches the CompletionProof anchor transaction, decodes the JSON,
# compares against the Platform-side verdict.

All three are read-only against public endpoints and the blockchain. They intentionally require no Platform authentication — a user can run them with only their intent ID.

Relationship to A2A

A2B shares the same cryptographic substrate as A2A:

• Both use DID + Ed25519 signatures for agent identity.
• Both use the AnchorRegistry pattern for on-chain commitments.
• Both produce a CompletionProof structure that third parties can verify.
• Both support an expireOrder-style timeout as the universal escape hatch.

A2B diverges from A2A in:

Both subprotocols produce evidence that downstream consumers (compliance APIs, cross-platform audit pipelines, third-party verifiers) can treat uniformly.

For Integrators

• Want to integrate a new merchant into A2B? Start with A2B · Merchant Onboarding.
• Want to understand the on-chain contract in depth? See Pro File · Smart Contracts.
• Want to audit an existing transaction? See A2B · Zero-Trust Audit.