Aomi Transact

Use the TypeScript aomi CLI to prepare, review and execute user-authorized transactions. The Rust aomi-cli in product-mono has a different interface.

Procedure

1. Establish capabilities. Read commands.md

first. Check package availability and installed help; a source test or SDK migration message does not prove a working published CLI. Stop a missing capability branch with its release requirement; keep a working older binary.

1. Resolve funding. Identify the requested recipient, amount, destination

chain ID and token contract. Read the user's wallet catalog for operational addresses and known funded chains. Check live token and native gas balances across those positions before preparing a payment. A zero Ethereum USDC balance is not a wallet-wide shortfall. Use tx preflight when available; follow funding checks otherwise. Keep a treasury/Safe refill as a separately authorized source choice.

1. Bind the intent. Show the selected sender, source asset/chain, destination

asset/chain, amount, recipient, estimated fees and shortfall. For conversion or bridging, obtain a fresh quote with minimum destination output, gas on each leg and route fees. USDC and USDG are different contracts/assets. Finish this step with unambiguous, funded terms before building a payment.

1. Prepare once. On a new task use `aomi chat "<exact intent>" --new-session

--public-key <sender> --chain <chain-id>. Continue its original session on follow-ups. Read aomi tx list --json, retain the full Commit ID and export that exact Commit with aomi tx export <commit-id> --format commit`.

1. Review. Match the durable review to the approved intent, including sender,

chain, token, amount, recipient, calldata, fees and simulation. Check all legs and approval limits. Simulation for a Commit lives in its review; tx simulate is a separate legacy Action tool. Require passed simulation for execution.

1. Execute the reviewed Commit. Use aomi tx sign <commit-id> only within

the user's authorization and an available designated signer. For an external signer, preserve the exact export and report the signed payloads or prepared broadcast hash through tx submit; see workflows.md. Inspect prepared AA payloads before choosing the signing path; see account-abstraction.md.

1. Reconcile the same payment. Retain original session, full Commit ID,

approved intent and transaction hash together. Refresh that Commit with aomi tx list --json before retrying; the backend observes the receipt and moves it to confirmed. A known hash or outstanding wallet attempt calls for reconciliation, not a new signing attempt. Report preparation, simulation, signature, submission and confirmation separately. Bridge completion also needs the destination receipt and spendable output token.

Credentials and state

Use the existing authorized signer without exposing key material. Credential setup is a separate user-directed operation; values stay opaque and out of chat, logs, fixtures and exported payment records. ~/.aomi may contain signing keys, bearers and secret handles. Its permission manifest expresses intended scope; actual enforcement depends on the host. For credential handling, local state and recovery, read gotchas.md and session.md.

Branch references

• 404, missing package, timeout or retry: troubleshooting.md.
• Commands, installation and flags: commands.md.
• Funding, execution and secret ingestion: workflows.md.
• Direct payment or bridge walkthrough: examples.md.
• Protocol field/recipient warnings: drain-vectors.md.
• App discovery and prompt examples: apps.md; runtime

capabilities and this procedure take precedence over historical app examples.

Source: https://github.com/aomi-labs/skills/tree/main/aomi-transact