A2B Profile — AVIP-A2B

A2B is a profile for the case where an AI agent pays a Web2 merchant on behalf of a user or organization. The counterparty has a public API or webhook but no DID, no on-chain identity, and no signature. The profile's job is to constrain the agent and the Platform so the untrusted Web2 side cannot take user funds and cannot leave the user without recourse.

For the conceptual overview, see Protocol · A2B Subprotocol. This page is the component-level profile.

Component Composition

The Three-Act Flow

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

Normative Requirements

• The Intent MUST whitelist tools via allowedTools; the Action Gateway MUST deny any call outside it.
• Funds MUST NOT reach the merchant until a committed invoice exists for an amount the deposit covers, and the payment MUST be constructed from the committed invoice's fields.
• The contract MUST refuse out-of-order slot transitions.
• After deadlineUnix, expireOrder MUST be callable by anyone and MUST refund userSA.
• Merchant deliverables MUST be sealed with envelope encryption; only the ciphertext hash is anchored on-chain.

Scenario Walkthrough

Setup. A user asks their agent to buy a 5 USDC gift card. The agent acts under its DID; the user's smart account userSA is the refund destination.

1. Declare. The agent signs an A2B Intent (category = gift_card, maxAmount = 5, deadlineUnix, allowedTools = [wallet.deposit, bitrefill.createInvoice, ...], userSA). After AVIP-INT-VER, the Platform calls A2BOrderGateway.createOrder(intentHash, ...). Status → CREATED.
2. Fund. userSA deposits USDC into the contract. Status → FUNDED.
3. Gate & commit. The agent calls tools; each routes through AVIP-EXE-GW, producing one ActionTrace record (allow / deny / pending_user_confirm). The merchant invoice is committed on-chain (commitInvoice). Status → INVOICE_COMMITTED.
4. Pay. The contract executes payment built from the committed invoice's fields; the audit root (Merkle root of all ActionTrace) is anchored. Status → PAID.
5. Deliver & seal. The merchant confirms delivery. A CompletionProof (intentHash, auditRoot, deliveryHash, verdict = DELIVERED) is anchored at keccak256("proof:a2b:" + intentHash). The gift-card code is sealed to the user's public key; only the ciphertext hash is stored on-chain. Status → DELIVERED.

Failure / timeout branch. If the merchant fails (FAILED) or the deadline passes (EXPIRED), AVIP-SET-EXP returns the deposit to userSA with no dependence on the Platform, agent, or merchant.

On-Chain Records

A delivered order produces roughly six on-chain transitions plus the CompletionProof anchor.

Zero-Trust Audit

All three audit commands are read-only against public endpoints and the chain, and require no Platform authentication (AVIP-AUD-VFY):

atel bitrefill verify-intent <intentId>   # signature + on-chain order match
atel bitrefill audit <intentId>           # recompute Merkle root vs on-chain auditRoot
atel bitrefill proof <intentId>           # decode CompletionProof vs Platform verdict

Divergence from A2A

Both profiles share the same identity, anchoring, proof structure, and timeout escape hatch — downstream consumers can treat their evidence uniformly.