A2B FAQ

Direct answers to the concerns we hear most often. Each answer points to the part of the protocol or product that backs it up.

"If my agent can just call the merchant's API directly, why do I need A2B?"

Because "directly" means trusting the agent vendor with your money before any delivery exists. If the agent is compromised, mis-configured, or simply disappears, your prepaid funds go with it.

A2B puts the funds in a smart contract that only releases when a committed invoice exists for an amount the deposit covers, and every checklist slot has advanced in order. The agent's ability to "spend your money" is bounded by what the contract will accept — not by what the agent feels like doing.

→ See How It Works · Phase 2.

"Can't I just trust the agent vendor?"

Trusting a vendor means trusting they won't be hacked, won't go insolvent, won't be blocked by a regulator, won't silently change their pricing or logic. Each of those is a real operational risk that has materialized somewhere in the industry in the last five years.

A2B replaces "trust the vendor" with "trust the contract and the chain." The contract's source code is public; the chain's behavior is auditable by anyone. The vendor's role is reduced to coordinator — they can fail or disappear without trapping your funds.

"Isn't the smart contract just another middleman?"

A middleman is an entity that can withhold, redirect, or take a cut of the transaction. The A2B contract can do none of those things — its behavior is determined by published source code that anyone can read. It has no keys that can move funds outside the checklist it enforces. It is not "an intermediary that can act"; it is "a rule that executes itself."

"Do I have to sign a transaction every time an agent buys something?"

No. The typical flow has you sign twice across the life of an order: once to authorize spending up to maxAmount (the Intent), and optionally once more to confirm an amount that crosses your requiresConfirmAbove threshold. Everything else — the on-chain transitions, the merchant calls, the settlement — happens without you in the loop.

Gas fees are paid by the Platform operator. You do not need to hold the chain's native token.

"What if the merchant never delivers?"

Two paths:

• The merchant confirms FAILED. The contract transitions to FAILED; the refund path opens.
• The merchant goes silent. After the deadlineUnix, anyone can call A2BOrderGateway.expireOrder(intentHash). The contract refunds the deposit to your smart account. You can do this yourself with cast send — no Platform, no agent, no merchant required.

→ See How It Works · What Happens When Things Go Wrong.

"Won't my gift card code leak if it's on the blockchain?"

The code is never on the blockchain in plaintext. Merchant deliverables are wrapped in envelope encryption: a fresh symmetric key encrypts the deliverable, and that symmetric key is itself encrypted to your public key. Only your secret key can open the envelope.

The on-chain anchor contains only the hash of the ciphertext — enough to prove "this ciphertext was delivered at this time" without revealing its contents.

→ See Protocol · A2B · Step 4.

"What stops my agent from blowing the whole budget on something I didn't want?"

Three independent gates:

1. The signed Intent has a hard maxAmount. The contract will reject transitions that try to exceed it.
2. The Intent has a scope list restricting which categories / merchants the agent may touch.
3. An requiresConfirmAbove threshold can force the agent to pause and ask you before crossing a cost level you picked.

All three are enforced in real time by the Action Gateway and the contract. You do not have to watch the agent.

"The Action Gateway and the smart contract sound redundant. Why both?"

They police different things:

• The smart contract enforces the fund flow: checklist order, amount consistency, deadline-based refund. It cares about "can money move?"
• The Action Gateway enforces the policy: tool whitelist, argument scope, sequencing, user confirmation. It cares about "should this call happen?"

Either one alone is insufficient. The contract without the Gateway would release funds for any invoice that fits the budget, regardless of whether the agent's underlying tool call was within policy. The Gateway without the contract would be a centralized gatekeeper that could itself be bypassed by anyone talking to the merchant directly. Together, they constrain the agent from both the custody side and the policy side.

"Why anchor the CompletionProof on-chain? Isn't it enough to have it in the Platform DB?"

Because a database can be edited after the fact by whoever runs it. An on-chain anchor cannot be edited, and the hash chain binds the anchored data to its exact content at the time it was anchored.

The result: any third party with only an intentId can fetch the CompletionProof, recompute its hash, and confirm it matches the on-chain value — without trusting the Platform. That's the point of "zero-trust audit."

→ See A2B · Zero-Trust Audit.

"Does the merchant have to do anything crypto-specific to integrate?"

No. The merchant exposes a public API (catalog, invoice, delivery signal) in whatever shape is natural for them. The Platform handles all on-chain plumbing. The merchant sees a standard payment flow with a webhook-style delivery confirmation.

→ See Merchant Onboarding.

"Which merchants does A2B support today?"

A2B is production-verified on mainnet with live merchants. Specific integrations and representative transactions are listed in Resources · Changelog with block-explorer-verifiable transaction hashes.

The protocol does not limit categories. Any Web2 merchant with a public API can plug in; the list of live integrations grows as business-side integrations complete.

"Which blockchains does A2B run on?"

A2B is deployed on multiple EVM-compatible mainnets. Specific addresses and block-explorer verification links are in Resources · Changelog. The protocol is chain-neutral — additional EVM mainnets can be added without changes to the protocol itself.

"If ATEL Platform goes offline, will my funds be stuck?"

No. Funds live in the A2BOrderGateway contract, not in a Platform-controlled account. As long as at least one Ethereum-compatible node anywhere in the world will accept a transaction, you (or anyone else) can call expireOrder directly against the contract after the deadline, and the contract refunds the deposit to your smart account.

The Platform's role is coordination — useful for a smooth user experience but not necessary for fund recovery.

"How do I see that all of this is actually working — not just described in docs?"

Three SDK commands let anyone verify any completed order end-to-end:

atel bitrefill verify-intent <intentId>
atel bitrefill audit <intentId>
atel bitrefill proof <intentId>

All three are read-only, require no authentication, and recompute cryptographic invariants locally against public data. Running them on any completed order answers the question "did this really happen the way the system claims?" with a yes/no from the chain itself.

→ See A2B · Zero-Trust Audit.