Coverage
AOMI FOR WALLETS
Give wallets protocol execution without replacing their agent or signer.
Whether a wallet team has already built its in-house agentic stack or is starting from scratch, Aomi can be the execution layer underneath—through a hosted integration or API access—returning simulated, policy-checked Actions to the signer it already runs.
The pitch
Stop rebuilding the transaction layer for every protocol.
The agent is your product surface and your differentiation. The protocol integrations, simulation infrastructure, guard policies, and receipt verification underneath it are not. Consume them as an API instead.
THE MENTAL MODEL
Access control model with full permission guardrails
One user can hold several logins, several wallets, and several chains at once. Transactions queue per public key, and every queue maps back to the one signer allowed to serve it. Your signer stays the authority in every path.
- signing authority — holds a key
- wallet · public key
- chain
- queued tx
- 01Logins
Alice signs in with Para and with Privy. Both resolve to one canonical user, so the account is the person, not the credential.
- 02Wallets and chains
Each login attaches wallets, and the thread context holds which wallet covers which chain. 0x123… covers Base and Arbitrum, 0x456… covers Base and Optimism, N2e3df… covers Solana.
- 03Queues
Transactions queue per public key rather than per user, so work on one wallet never blocks another.
- 04Resolution
Every queue maps to exactly one signer. The EVM wallets resolve to a human signature through Para or MetaMask. The Solana wallet resolves to a delegated key that signs without a prompt.
A transaction for Base is built for 0x456… and resolves to a Para signature, with the human in the loop.
A transaction for Solana is built for N2e3df… and is authorized through Privy to be signed by a delegated key that Aomi manages.
Rehearsal
Every action is simulated before signature.
The kernel builds exact calldata, runs the whole batch on a forked copy of the chain, then enforces slippage and policy guards. Failures surface at plan time, not inside your user's flow.Proof
A hash is not proof.
A watcher checks signer, chain, calldata, and ordering against the sealed Action before your product reports success. Receipts reconcile without your own indexing stack.One review surface
Component library that renders the action
Every Action carries a typed, kernel-sealed summary: title, ordered steps, cost, and warnings. Your existing review UI renders it directly, so what the user approves is exactly what the kernel verifies onchain.
Swap 0.5 ETH for ~1,240 USDC
The ownership boundary
Zero malformed encoding: the model handles parameters, not bytes.
On reads, the harness fetches, decodes, and formats before the model sees anything. On writes, the model emits high-level intent and the harness assembles every byte of the transaction — your signer stays the only write authority.
get_contract(addr, chain)
- DB cache hit → return
- miss → explorer fetch
- store back + proxy-resolve (EIP-1967)
get_account_info(addr, chain)
- → {balance, nonce} (gateway)
encode_and_call(sig, args, to)
eth_call(chain, to, calldata)(Anvil fork / gateway)format_token_units(raw, dec)format_wei_as_eth(wei)stage_tx { to, sig, args[] }
- args = base units (from model)
abi_encoder::execute_call
- parse_function_signature → selector = keccak256[:4]
- parse_param_value (str → DynSolValue)
- abi_encode_params → 32-byte words
AssembledEvmTx{ from*, chain*, to, value, data, label, kind }(*from / chain injected from wallet ctx)OWNERSHIP — why the model never sees a byte
Caches: contract ABI / source (SQLite / Postgres) · proxy-impl resolution
From AomiBench: benchmarking frontier models on onchain execution
Keep the wallet yours
Plug execution rails under your agent.
Bring your model's output. We will map it onto the Pipeline API, bind your signer stack once, and leave custody exactly where it is.
Map the integration