The lifecycle
Simulate on a forked chain
Before anything touches the real chain, Aomi forks the current chain state and runs your transaction on the fork. Multistep flows, like an approve and then a swap, are simulated together as one batch. If the transaction would revert, you find out here, with no gas spent.
Review the real outcome
The simulation returns the actual result: the tokens you would receive, the balances that would change, and any revert reason. You read the real outcome, not an estimate.
Sign with your own wallet
Aomi stages a wallet request and your wallet signs it. Aomi never holds your keys and never signs on your behalf. Signing is account abstraction first, with an EIP-7702 or EIP-4337 fallback.
Driving a trade from the CLI
Theaomi-transact skill runs this lifecycle for you, but every step maps to a real command. When you want to see the moves, or run them by hand, here is the flow.
The CLI is one shot per command. Each aomi command starts, runs, and exits. It is not a long running process. Your session state persists between runs on local disk, so the next command continues the same conversation, holds the same pending transactions, and remembers your wallet.
Chat your intent
Tell the agent what you want. When the trade needs a signature, the agent stages a wallet request and the CLI queues it locally as A chat reply does not always queue a transaction. The agent may return a quote or a route and ask whether to proceed. Stay in the same session and reply with a short confirmation. Nothing is staged until you see
tx-1, printing the destination, value, and chain.Wallet request queued: tx-N.List the pending request
Confirm what is queued before you touch simulation or signing.A swap that needs an approval first shows up as two pending transactions, the approve and the swap.
Simulate on a forked chain
Run the pending transactions on a fork before you sign. For a multi step batch like approve then swap, simulate both together so the swap sees the state the approve creates.The result reports per step success, any revert reason, and gas used. If a step reverts, read the reason and fix the intent. Do not sign past a failed simulation.
Safety rules the agent follows
These rules keep a trade safe whether the skill drives the CLI or you do.- Never invent or guess credentials. The agent passes through only a value you gave it for a specific action. It does not fabricate, derive, or echo a key back to you.
- Always simulate a multi step batch before signing. An approve then swap, or an approve then deposit, is state dependent. Simulate the batch together with
aomi tx simulatefirst. The second step reverts if you submit it alone. - Only sign the pending transaction you asked for. The agent signs the queued
tx-Nyou named afteraomi tx listshows it. It does not sweep the queue. - Keep the signing RPC matched to the pending transaction chain. The
--chainflag sets your session context. The--rpc-urlflag sets where the signed transaction is submitted. They are independent controls, so keep the signing RPC aligned with the chain of the transaction you are signing.
Signing modes
By defaultaomi tx sign is account abstraction first. It tries account abstraction, then falls back to direct EOA signing if account abstraction is unavailable or fails. You can force a mode when you need one.
| Flag | Behavior |
|---|---|
| (default) | Account abstraction first, automatic EOA fallback |
--aa | Require account abstraction. Error if no provider is configured |
--eoa | Force direct EOA execution, skip account abstraction |
--aa-provider takes alchemy or pimlico. --aa-mode takes 4337 or 7702.
--aa and --eoa are mutually exclusive. You cannot combine --aa-provider or --aa-mode with --eoa. See the aomi CLI reference for the full signing surface.
Why simulation comes first
Most agents build calldata, sign it, and hope. Aomi catches a bad transaction at simulation time, before broadcast, so your agent never burns gas on a malformed call. Simulation also guards against drain vectors. When a recipient field in the calldata, such asrecipient, onBehalfOf, mintRecipient, or _to, does not match the signer, the transaction is blocked at simulation time instead of being signed.
Non-custodial by design
At no point does Aomi take custody. It reads chain state, builds the transaction, and simulates it. Your wallet is the only thing that can sign. This holds across every supported chain.Next
Overview
What trading on Aomi is and which chains it covers.
The aomi-transact skill
Run this lifecycle by chat from your AI assistant.