How to use the Aomi Crypto Transactions agent skill

What does the aomi-transact skill make the agent do?

An agent skill is a set of instructions and files that an AI agent such as Claude Code loads when a task matches the skill's description. This one covers on-chain actions. You type a request like "swap 1 USDC for WETH on Uniswap V3", and the agent picks the protocol and contract, prepares the transaction or batch, simulates it on a forked copy of the chain, and returns a wallet request for you to sign.

The skill also covers read-only tasks: checking a price, reading balances, getting quotes or routes, and checking transaction status. The Aomi CLI is account-abstraction-first, so it signs through a zero-config Alchemy proxy by default and needs no provider credentials for that path. Each aomi command starts, runs and exits; there is no long-running process.

• Supported chains named in the source: Ethereum, Base, Arbitrum, Optimism, Polygon and Linea.
• Apps named in the source include Uniswap, Aave, Lido, Morpho, GMX, Hyperliquid and Polymarket.
• The wallet stays under your control (non-custodial), and the agent does not sign without your explicit instruction.

How do you install the aomi-transact skill?

Download the skill ZIP from this directory page and unzip it. For a personal install, place the unzipped skill folder in ~/.claude/skills/. For a single project, place it in that project's .claude/skills/ folder. In the Claude apps you can instead upload the ZIP under Settings → Capabilities → Skills.

The skill drives the Aomi CLI, which is published as the @aomi-labs/client npm package. You need Node.js and npm, and a recent enough release of @aomi-labs/client to include the flags the skill uses (the source sets a minimum version, and older releases lack the --aa, --aa-provider and --aa-mode options and the simulation gate). The source's install command is shown below. You can also run the client on demand with npx instead of installing it globally.

• Confirm Node.js and npm are installed before installing the CLI.
• Check the minimum version stated in the skill's Limitations section and install at least that release.
• The full skill bundle (references, templates and host metadata) lives in the upstream aomi-labs/skills repository. This page provides the canonical SKILL.md only, so clone the upstream if you need the extra files.

How do you trigger the skill with a natural request?

You do not need a special command. Describe what you want in plain English and the agent should load the skill when your request matches its scope. Good triggers include asking to chat with the Aomi agent from the terminal, checking balances or prices, building or simulating a batch of transactions, switching apps, models, chains or sessions, and signing EIP-712 typed data.

If you want to be explicit, name the protocol and the chain, and say whether you want the transaction sent to your own wallet. The agent will then pass the chain and your public address to the CLI.

• Read-only: "what is the price of ETH?"
• Single transaction: "Stake 0.01 ETH with Lido to get stETH"
• Batch: "swap 1 USDC for WETH on Uniswap V3, send to my wallet"
• Cross-chain: "Bridge 50 USDC from Ethereum to Base via CCTP. Recipient is my wallet."

What does a typical transaction flow look like?

For a single-transaction action such as a Lido stake, the agent runs a chat command with your public address and the chain ID, then lists the queued transactions. The source notes that a single stake needs no approval step, so there is one queued transaction. The agent should stop there, show you the details and wait for your instruction.

For a multi-step swap, the agent queues an approve transaction and a swap transaction (tx-1 and tx-2 in the source example). The simulator runs them in order on a forked chain, so the swap sees the approve's state changes. The source says simulation is mandatory for multi-step batches, and that you should not sign the second step on its own because it would revert.

• Replace 0xUserAddress with your own public address.
• Chain 1 is Ethereum mainnet in the source examples.
• The agent should summarise the tx ids, chain, value, recipient, purpose of the calldata and the simulation result before asking you to sign.
• Signing is a separate step that happens only after you name the exact tx ids.

What should you check before approving a signature?

Simulation is useful but does not prove that a live transaction will behave the same way. The source states that simulation cannot guarantee live execution, slippage, MEV protection or safe approvals. Before you sign, check the chain, token and contract addresses, the recipient, amounts, approval limits, fees, deadlines and the EIP-712 domain and message where relevant, including any account-delegation effects.

If a quote or calldata is rebuilt after you approve it, the earlier approval no longer applies and needs a fresh review. The source also says the agent blocks calldata whose recipient is not your own wallet; treat that block as a security feature and do not reword the prompt to get around it.

• Sign only transactions that the simulation shows as passed.
• Re-run aomi tx list if a deadline-bearing quote may have expired while you were reviewing.
• Do not paste real provider secrets into command arguments, because they end up in shell history. Use the protected credential mechanism of your installed version.

What do you need for production signing?

For everyday tests, the default proxy path may be enough on some chains. For production signing, the source recommends a reliable RPC URL that matches the chain, passed with --rpc-url. Public RPCs can return 429 (rate limited) or 401 (auth failure). The skill also needs network access to api.aomi.dev, because the CLI talks to that backend. Without it, only local read commands such as aomi tx list and aomi session log work.

On L2s such as Base, Arbitrum and Optimism, sponsorship through the zero-config proxy is not guaranteed. If your address holds no native gas on the destination chain, signing fails with an insufficient funds error. The source suggests funding the address with a small amount of native gas or configuring your own Alchemy or Pimlico provider with a sponsorship policy. Do not retry with --eoa, because that path also needs gas.

• Node.js and npm, plus @aomi-labs/client.
• Network access to api.aomi.dev.
• A wallet or EOA public address.
• A chain-matching RPC URL via --rpc-url for production signing.
• Native gas on the destination chain unless the sponsorship proxy covers it.
• Provider credentials (for example Alchemy or Pimlico, or app tokens for Binance, Polymarket or Dune) only for the apps that need them.

What safety features does the skill have, and what does it run?

The skill declares that it runs scripts and uses the network. Its key safety feature is a signing gate. The agent should not run aomi tx sign unless you give an explicit instruction naming a queued tx-N id that aomi tx list has shown. The skill is designed to stop and wait for that approval rather than trade automatically.

The skill never sets provider credentials on its own. Apps that need tokens must have them configured by you, either in your own shell or with aomi secret add. The source's risk rating for this skill is critical, which reflects that it can move real funds. Read the safety section of the SKILL.md before you use it with real money.

• Signing is gated behind an explicit request and a queued transaction.
• The skill is not an automated trading bot and is built to wait for your approval.
• Calldata that would send value or approvals to an address other than your own is blocked by the agent's guard.
• The source says the upstream security report and drain guard are not attested as a security guarantee by this catalog.

What tips help you get reliable results?

Start each new task with --new-session. The source warns that reusing a session mid-task can cause the agent to lose the quote it just gave you. Always list queued transactions before signing, and never assume that a chat reply means a transaction was queued. Simulate every multi-step batch first, and sign only batches that report as passed. Skip orphan transactions left over from earlier failed attempts.

• Use --new-session on the first command of a new task.
• Run aomi tx list before any signing step.
• Simulate multi-step batches with aomi tx simulate tx-1 tx-2 and any other ids in the batch.
• Sign only transactions from a batch that reports as passed.
• Use a dedicated RPC URL for production signing rather than a public endpoint.