The problem Avtar.ai solves

Agent-to-agent API payments have no workable settlement layer at the volume agents actually operate at.

On-chain per call is too expensive. An agent buying weather data, a price feed, a translation is each call is worth fractions of a cent, but a Base transaction costs real gas regardless of what it's for. Settling every call on-chain means the fee dwarfs the price. Nobody does that.

Off-chain invoicing has no enforcement. The alternative is meter calls, bill monthly, trust the total — works between humans who have relationships and recourse. It doesn't work between autonomous agents transacting with counterparties they've never dealt with before and have no legal claim against. There's nothing stopping either side from disputing the number afterward, and no cheap way to prove who's right.

What exists in between (x402) only solves discovery and per-call authorization — a provider quotes a price, a consumer presents payment, the call proceeds. It doesn't solve the settlement problem: paying per call is exactly the on-chain-cost problem above, restated.

Avtar.ai closes that gap. The consumer locks escrow once. Calls are metered locally against it — no transaction, no signature, no gas per call. When the channel closes, one Groth16 proof establishes exactly what's owed, and one transaction pays the provider and refunds the rest. The proof is what replaces trust: the amount is provably correct without either party needing to believe the other's ledger, and without publishing the call count, the rate, or what the calls were for.

So the shape of the problem is: agents need to pay each other at machine speed and machine volume, with cryptographic settlement instead of either prohibitive gas costs or unenforceable trust

Disclosure

The settlement design which is meter off-chain, prove the total with Groth16, settle
once was first built and proven out on Stellar/Soroban before being adapted for Base. Everything in this repository is a from-scratch implementation for Base: new Solidity contracts, a new TypeScript SDK, a new Foundry test suite, and a rewritten circuit
address-binding scheme (BN254 hi/lo limbs in place of 32-byte Stellar
strkeys). No Soroban code, dependency, or artifact is present here.

Challenges we ran into

1.⁠ ⁠A stale proving key silently broke every settlement. The verifier is deployed immutably into the escrow's constructor, generated from a specific proving key. When the local key got regenerated, every proof came back a bare InvalidProof() — no clue why. We traced it to a bytecode diff between the committed verifier and what was actually deployed, then redeployed the full stack from the matching key.

2.⁠ ⁠Public RPC endpoints disagreed on account state mid-transaction. sepolia.base.org load-balances across nodes that don't agree on nonces, so opening a channel (three transactions in a row) would fail partway with nonce too low — a transient infra issue that read like a client bug. Fixed by switching to a steadier endpoint and adding a retry that reads the nonce the chain's own rejection names, instead of re-querying an inconsistent source.

3.⁠ ⁠Solidity and TypeScript had to encode addresses identically, with no automatic check that they did. BN254 field elements can't hold a full address, so each one is split into hi/lo limbs on both sides of the stack independently. A one-character drift between the two implementations would fail silently at settlement, not at compile time. Solved with a shared test vector that pins both implementations to the same expected output, so a mismatch fails in CI.

4.⁠ ⁠The escrow contract has no per-channel balance — only per-depositor. A dashboard trying to show "how much is locked for this channel" was actually reading the depositor's total pooled balance across every channel they'd ever opened, which looks right until two channels are open at once. Fixed by sourcing the per-channel figure from the agent's own session state, since the chain genuinely doesn't track it.