The lifecycle
1
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.
2
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.
3
Sign with your own wallet
Aomi stages a wallet request and your wallet signs the exact prepared
payload. Aomi never receives your private key. The backend decides whether
the prepared operation is an ordinary transaction, EIP-4337 owner
authorization, or another signature kind before it reaches the wallet.
4
Broadcast and confirm
The signed transaction is broadcast to the chain. Aomi reports the
transaction hash and waits for the confirmation.
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. Local state remembers the active Agent session and wallet configuration. Pending Actions remain durable in the backend Agent session and aomi tx list fetches their current state.
1
Chat your intent
Tell the Agent what you want. When the trade needs a signature, Aomi creates a pending Action for the active session.A chat reply does not always create an Action. The Agent may return a quote or route and ask whether to proceed. Stay in the same session and reply with a short confirmation, then inspect the Action list.
2
List the pending request
Confirm what is queued before you touch simulation or signing.A swap that needs approval can appear as one EVM execution Action containing ordered approval and swap transactions.
3
Simulate on a forked chain
Run the pending EVM execution Action on a fork before you sign. For a multi-step Action such as approve then swap, simulation preserves the prepared transaction order so the swap sees the approval state.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.
4
Sign the request you asked for
Execute only the pending Action the user reviewed. For an ordinary EVM or SVM execution Action, the CLI signs and submits with the configured local wallet. For a sign-only Action, it returns the exact signature to the backend.
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 execute the pending Action you asked for. The Agent uses the Action ID you named after
aomi tx listshows its current request and state. It does not sweep the queue. - Keep the signing RPC matched to the Action’s chain. The
--chainflag sets Agent context. The--rpc-urlflag sets where a local wallet submits an ordinary transaction. They are independent controls.
Execution assertions
The backend prepares the Action’s execution kind.aomi tx sign does not select an account-abstraction provider or rewrite an ordinary transaction into a smart-account operation.
--aa and --eoa are mutually exclusive assertions. --aa-provider and --aa-mode are rejected because provider, implementation, sponsorship, and broadcast policy belong to the backend-prepared operation. See Transactions and signing.
Why simulation comes first
Simulation exposes a bad transaction before broadcast, so you can stop before signing 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.
Skills and guards
See how protocol instructions and guards join this lifecycle.