ATEL
A2B

How It Works

The user-visible flow of an A2B transaction, from signed intent to sealed delivery, with cryptographic audit at every step.

How It Works

This page walks through a complete A2B transaction from the user's perspective. For the protocol-level specification, see Protocol · A2B Subprotocol.

The Shape of a Transaction

An A2B order flows through three phases. Each phase produces on-chain evidence.

① Declarationsign Intent,create on-chain order② Executiongateway-gatedmerchant calls,audit trail③ Settlementfund release,delivery sealed,proof anchored

Your role is mostly at the edges — approving the original envelope and (optionally) reading the delivery. Everything in the middle is cryptographically enforced so you don't have to watch.

Phase 1 · You Declare What the Agent May Do

You (or the application you're using) create an Intent that says, in effect:

"I want my agent to spend up to X on this category of merchant by this deadline. If the amount exceeds Y, pause and ask me first."

Three fields matter most:

  • maxAmount — the ceiling. The agent cannot spend more than this under any circumstance.
  • deadlineUnix — a hard expiry. If the order hasn't completed by this time, the funds come back automatically.
  • requiresConfirmAbove — optional threshold. Amounts above this require you to confirm in-band before the payment goes through.

The Intent is signed with the agent's DID key, hashed, and written to the on-chain A2BOrderGateway contract. From this moment on, the contract and the Action Gateway both refuse anything outside this envelope.

Phase 2 · The Agent Executes, Gated by Policy

The agent now performs the actual work: searching the merchant's catalog, choosing an item, committing an invoice, paying the merchant. Every tool call the agent makes passes through an Action Gateway.

For each call, the Gateway:

  • Checks the tool is on the Intent's whitelist.
  • Checks arguments are within scope and budget.
  • Checks previous required tools have succeeded.
  • Checks the deadline hasn't passed.
  • If the amount crosses requiresConfirmAbove and you haven't approved, pauses and pings you.

Approved or denied, every decision is written as an ActionTrace record. These records hash-chain to form a tamper-evident audit trail. If anyone tries to edit what happened after the fact, the chain breaks and the audit root no longer matches what's on-chain.

Meanwhile on-chain, the order ratchets through a fixed checklist:

CREATEDFUNDEDINVOICE_COMMITTEDPAIDDELIVERED

Each transition is a separate transaction. The contract enforces the order — you cannot skip or reorder slots. This is what makes A2B runaway-resistant: funds cannot reach the merchant until a committed invoice exists for an amount the deposit covers, and the payment transaction is built from the committed invoice's fields, so no one can silently swap the destination.

Phase 3 · Settlement, Sealed Delivery, Anchored Proof

When the merchant confirms the delivery, three things happen:

  1. The audit root gets written on-chain. The Merkle root of every ActionTrace from Phase 2 is anchored as part of the confirmDelivery transaction. That root is now part of the permanent record.

  2. The deliverable gets sealed. If the merchant returned a gift card code, a receipt, a booking confirmation — anything sensitive — it is encrypted with envelope encryption to your public key. Only your secret key can open it. The encrypted blob lives off-chain; only its hash is anchored.

  3. A CompletionProof is anchored. This is a single on-chain record that ties the intent hash, the audit root, the delivery hash, and the verdict (DELIVERED / FAILED / EXPIRED) together. It is the master receipt a third party needs to reconstruct the entire transaction.

Your dashboard shows the delivery. Your audit badge turns green. The end.

What Happens When Things Go Wrong

A2B is designed so that every failure mode has a defined recovery path.

SituationWhat Happens
Agent goes silent after Phase 1Deadline passes → anyone calls expireOrder → USDC returns to your smart account
Merchant reports delivery failureOrder transitions to FAILED → funds refund path opens
Platform goes offline mid-transactionAs long as you have network access, expireOrder still works directly against the contract
You exceed requiresConfirmAbove by accidentGateway pauses, waits for your confirmation; if you don't confirm, order expires and refunds
Audit root doesn't match on-chain recordAudit badge turns amber; SDK audit command reports the mismatch
Delivery is late but eventually arrivesPost-payment tools are exempt from the deadline check — the merchant can still deliver after the gate closed

The "Only You Can Do This" Guarantee

One of A2B's core properties is that only two keys matter:

  • The agent's DID key signs the Intent. If it's compromised, only future orders are at risk — past orders stay locked by the signature already on-chain.
  • Your secret key opens the sealed delivery. Even ATEL cannot read your gift card code; even a compromised Platform cannot silently steal it.

The Platform, the Gateway, and the merchant each operate under the contract's constraints. Take any of them offline and the protocol still guarantees refund or delivery, not loss.

See Also

Edit on GitHub

Overview

A2B (Agent-to-Business) — let AI agents pay Web2 merchants on behalf of users and organizations, with on-chain custody and cryptographic audit.

Merchant Onboarding

What it takes for a Web2 merchant to plug into A2B — integration model, requirements, and what the merchant gets in return.

On this page

How It WorksThe Shape of a TransactionPhase 1 · You Declare What the Agent May DoPhase 2 · The Agent Executes, Gated by PolicyPhase 3 · Settlement, Sealed Delivery, Anchored ProofWhat Happens When Things Go WrongThe "Only You Can Do This" GuaranteeSee Also