Funding: getting money in, keeping gas flowing

Before the first run, two things: the owner had USDC to put into a budget, and someone covered gas so the agent never held the chain's native token. Value enters through two doors into an AI wallet, gasless stays gasless through paymaster policy, and earnings leave again. Everything runs on USDC, yet you never need USDC before you start: send what you have, from the chain you have it on, and it arrives as USDC.

Getting money into an AI wallet (on-ramp)

An owner needs (1) USDC in the AI wallet for budgets and (2) no gas at all on the paymaster path (EIP-3009/Permit2 deposits + sponsored UserOps), or a little native gas otherwise. Two doors bring in the USDC; the AI wallet is the same smart account either way, the one the wallet budget page deploys for your key and session keys draw from.

Door one: USDC on this network

Hold USDC on this network already? Send it straight to the AI wallet. The budget page does exactly that: connect, fund with USDC, approve the PaymentManager, authorize a session key. No fee on the way in. An exchange withdrawal to the AI wallet's address does the same and is pooled, the best privacy posture (privacy.md). Keep the owner wallet dedicated to agent budgets, not everything you own: it is what session keys draw from and what you revoke if anything goes wrong.

Door two: the deposit address, for everything else

Everything else goes through the wallet's deposit address: ETH on Ethereum, SOL, BTC, a stablecoin on Arbitrum, any major asset on any major chain. Ask for a quote from where you are to USDC here, send from your own wallet, and what arrives is credited as USDC minus the conversion fee. The fee is depositFeeBps in deployments.json (DEPOSIT_FEE_BPS at deploy, 1% by default) and goes to the treasury; the quote states it in basis points and USDC before you send, so the fee is always what the quote says. On the budget page it is the card "Fund your AI wallet from any chain"; from the command line, aioum deposit (the command-line track); from Claude, the aioum_deposit_* tools (the Claude track).

Pay by card

No crypto at all? Pay by card on the same card opens a licensed on-ramp partner's page: Coinbase Onramp, Transak, MoonPay or Stripe, whichever the network's operator holds keys for (a choice when more than one). You pay the partner by card; it delivers USDC on Base to your deposit address, and the sweep credits your AI wallet less the same fee. The ledger shows it as Card → USDC · Transak (or the partner you chose) from the moment the link is made: pending while you pay, arrived when the partner reports delivery, credited with the sweep transaction. The link is single-use and good for about five minutes. From the command line, aioum deposit card; from Claude, aioum_deposit_card.

The partners deliver to Base only, so the button works on a network that runs on Base and says so where it does not; on the local development network it reads "Card payments deliver to Base; on the local network this button is disabled".

What a partner charges is its own, shown on its page before you pay, and its documentation states what it shares with the integrator: Coinbase Onramp lists a 2.5% card fee (zero-fee USDC for eligible partners) and no partner share; Transak lets the operator add a partner fee of up to 5% in its dashboard, paid out monthly; MoonPay an affiliate fee of 0.5% to 1.25%, agreed with MoonPay; Stripe states none. Stripe delivers USDC on Base to customers in the United States only. The network's own fee is the same 1% on every deposit, taken by the sweep.

For the operator, each partner's keys are one line in .env (Keys to launch, "Deposits from any chain, and by card"). The deposit service mints or signs every link server-side as the partner requires (a Coinbase session token, a Transak widget session, a MoonPay signature, a Stripe onramp session), reads each partner's status API, and takes Transak's, MoonPay's and Stripe's webhooks at /card/webhook/<partner> with their signatures verified; GET /card/partners prints the webhook URLs to register. The network never holds fiat and never charges a card itself: taking the card payment and paying out USDC from a treasury is money transmission, which needs licensing, so that path is not built.

How the deposit address works. Every AI wallet has one, computed in advance (DepositForwarderFactory.addressOf(wallet), CREATE2), so any route, bridge or exchange can deliver USDC to it before the contract behind it exists. That contract, a DepositForwarder, only forwards: sweep() sends feeBps of the arrived USDC to the treasury and the rest to the AI wallet. Funds sent before deployment are safe; the first sweep (sweepFor(wallet)) deploys and forwards in one transaction. Sweeping is permissionless: nothing to steal, only to forward. Any other token that lands there was not converted, so sweepToken forwards it in full; there is no receive, so native coin reverts instead of getting stuck.

The service behind the door. The deposit service (npm run deposits, port 8551; offchain/src/deposits/server.ts) takes the source chains and assets, 72 chains including Solana and Bitcoin, from the route provider, LI.FI, and asks it for a route to USDC here, delivered to the deposit address. A quote shows what you send, what arrives as USDC (and the least that can), the fee, the credit, the route and how long it takes, timed from the quote itself. A ledger records every deposit: source route for a quoted one, card for a partner's card payment, direct for USDC that reached the address any other way. A record moves pending → arrived → credited, or to failed with the route's reason; it refreshes against the provider each time you read it, and a background loop refreshes pending deposits and sweeps every known deposit address holding USDC, so a plain transfer or exchange withdrawal is credited within a minute with no quote at all. The AI wallet's USDC balance is the credit; aioum wallet shows it.

The service runs in one of two modes. route where the provider delivers to this chain. direct on every other chain, the local development network among them, where it serves only the path that is real everywhere: the deposit address, and the sweep of USDC sent straight to it; /chains, /tokens and /quote answer 501 with one sentence, "Routes from other chains deliver to Base; on this network send USDC to your deposit address and it is swept to your AI wallet", and the app card, the CLI and Claude say the same. Nothing is simulated. scripts/devstack.sh review starts it. On Base Sepolia, the dollar is the network's own zUSD (0x84e2…6e77), not Circle's testnet USDC: the network's faucet gives 50 zUSD with 1,500 ZAI once per wallet, claimed by your node, and test ETH comes from a public gas faucet.

Paymaster policy (who pays for "gasless")

Whichever door the money came in through, the agent never holds the chain's gas token. Gasless means someone prepaid gas into the EntryPoint, and the policy says who and on what terms.

On the AIOUM network a signature-gated (verifying) paymaster (AIOUMVerifyingPaymaster) sponsors only UserOps the sponsorship service signed for, such as session-key setups and openSessionFor calls within quota; without a valid sponsorship signature an op fails validation and cannot touch the deposit. It deploys unfunded with SPONSOR_SIGNER_ADDRESS as signer, and the treasury funds it deliberately: sponsorship is an onboarding budget line, not an open tap.

On your local development network the deploy script deploys and funds (2 ETH) the accept-everything AIOUMPaymaster, so every op is sponsored without a signature. It belongs only on a private chain, because anyone can drain it, which is why verify-deploy fails closed if it finds one funded on a public chain. To rehearse the network's policy locally, USE_VERIFYING_PAYMASTER=1 npm run deploy runs the verifying paymaster instead, with npm run billing issuing the sponsorships.

Whichever paymaster is live needs monitoring and refill. npm run paymaster prints the EntryPoint deposit and a runway estimate; AIOUM_PAYMASTER_MIN_ETH=0.5 npm run paymaster exits nonzero below the threshold, for cron or alerting; npm run paymaster -- refill 1.5 tops the deposit up. The treasury cadence: refill to N days of runway on alert, and review the sponsorship budget in governance alongside the fee parameters, since both are lines in the same ledger.

Getting earnings out (operator off-ramp)

Operators earn USDC/ETH on-chain: settlements land in the operator wallet, no custodial balance to withdraw. From there it goes wherever the operator wants: exchange deposit, Circle redemption, spending on-chain. Every settlement is an on-chain receipt with exact amounts and timestamps, exportable via the subgraph/indexer, so tax and accounting auditability comes with the rails.

With funding in place the loop is closed: money comes in from wherever it was and lands in an AI wallet as USDC, a session key turns it into per-call payments, a node collects them, and an operator takes them out.

Next: SDK and HTTP API — the exact functions and endpoints behind everything the builder pages described.