{"id":"0d6b40ff-a61a-4f8f-ae44-9c68f7dde796","entityType":"agent","slug":"clawhub-ceciliaz030-aomi-transact","name":"Transact","canonicalUrl":"https://www.xpersona.co/agent/clawhub-ceciliaz030-aomi-transact","canonicalPath":"/agent/clawhub-ceciliaz030-aomi-transact","generatedAt":"2026-10-11T11:25:49.847Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T08:54:24.103Z","emptyReason":null},"description":"Build natural-language crypto agents, web3 assistants, and trading bots that read and write EVM chain state. Aomi turns prompts (\"swap 1 ETH for USDC\", \"open...","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s174406t7fv0e6ry94swqb3jc186877h:aomi-transact","sourceUrl":"https://clawhub.ai/ceciliaz030/aomi-transact","homepage":"https://clawhub.ai/ceciliaz030/skills/aomi-transact","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/ceciliaz030/aomi-transact","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/ceciliaz030/skills/aomi-transact","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":61,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Transact technical dossier on Xpersona with agent coverage, OPENCLEW support, and live trust metadata."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T08:54:24.103Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T08:54:24.103Z","emptyReason":null},"stars":null,"forks":null,"downloads":1107,"packageName":null,"latestVersion":"0.10.1","tractionLabel":"1.1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T08:54:24.088Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T08:54:24.103Z","lastCrawledAt":"2026-10-11T08:54:24.088Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T08:54:24.088Z","lastVerifiedAt":null,"highlights":[{"version":"0.10.1","createdAt":"2026-07-10T19:31:03.396Z","changelog":"aomi-transact v0.10.1 - Updated compatibility for @aomi-labs/client v0.1.42 and new CLI versions. - Major docs, workflow, and naming update: sessions renamed to threads; session.md replaced with thread.md. - Expanded EVM and Solana support instructions; clarified account-abstraction, signing, and CLI authentication flows. - Improved troubleshooting and error handling documentation, including new backend-dependent states. - Cleaned file structure, removing session.md and skill-card.md, and adding comprehensive thread.md reference.","fileCount":15,"zipByteSize":51193},{"version":"0.10.0","createdAt":"2026-05-16T11:00:41.498Z","changelog":"**Major update: Strongly expanded documentation, enhanced references, new permissions and safety controls, and multi-app support.** - Added extensive internal documentation: new reference files for commands, workflows, apps, examples, account abstraction, troubleshooting, session handling, and security. - Updated and condensed skill overview to clarify usage for building crypto/Web3 agents, DeFi bots, and on-chain assistants across major EVM chains and 40+ protocols. - Permissions manifest introduced: restricts shell/network tools, file system access, and outbound connections for improved security (risk tier L2). - Output and error handling sections improved for clarity; troubleshooting guidance now referenced directly. - Expanded \"When to Use\" and command surface descriptions, including new AA/session controls and integration notes for plugin environments. - Skill metadata updated: tags, compatible-with, author, homepage, and explicit version incremented to 0.10.0.","fileCount":15,"zipByteSize":49079},{"version":"0.5.0","createdAt":"2026-04-20T10:38:26.822Z","changelog":"Execute EVM transactions through conversational AI via aomi CLI","fileCount":2,"zipByteSize":11293}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s174406t7fv0e6ry94swqb3jc186877h:aomi-transact","setupComplexity":"low","setupSteps":["Install using `clawhub skill install s174406t7fv0e6ry94swqb3jc186877h:aomi-transact` in an isolated environment before connecting it to live workloads.","No published capability contract is available yet, so validate auth and request/response behavior manually.","Review the upstream CLAWHUB listing at https://clawhub.ai/ceciliaz030/aomi-transact before using production credentials."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ceciliaz030-aomi-transact/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ceciliaz030-aomi-transact/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ceciliaz030-aomi-transact/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-ceciliaz030-aomi-transact/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-ceciliaz030-aomi-transact/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-ceciliaz030-aomi-transact/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T11:25:49.844Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ceciliaz030-aomi-transact/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ceciliaz030-aomi-transact/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ceciliaz030-aomi-transact/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ceciliaz030-aomi-transact/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T08:54:24.103Z","emptyReason":null},"readme":"Skill: Transact\n\nOwner: ceciliaz030\n\nSummary: Build natural-language crypto agents, web3 assistants, and trading bots that read and write EVM chain state. Aomi turns prompts (\"swap 1 ETH for USDC\", \"open...\n\nTags: ai-agents:0.5.0, blockchain:0.5.0, evm:0.5.0, latest:0.10.1, transactions:0.5.0\n\nVersion history:\n\nv0.10.1 | 2026-07-10T19:31:03.396Z | auto\n\naomi-transact v0.10.1\n\n- Updated compatibility for @aomi-labs/client v0.1.42 and new CLI versions.\n- Major docs, workflow, and naming update: sessions renamed to threads; session.md replaced with thread.md.\n- Expanded EVM and Solana support instructions; clarified account-abstraction, signing, and CLI authentication flows.\n- Improved troubleshooting and error handling documentation, including new backend-dependent states.\n- Cleaned file structure, removing session.md and skill-card.md, and adding comprehensive thread.md reference.\n\nv0.10.0 | 2026-05-16T11:00:41.498Z | auto\n\n**Major update: Strongly expanded documentation, enhanced references, new permissions and safety controls, and multi-app support.**\n\n- Added extensive internal documentation: new reference files for commands, workflows, apps, examples, account abstraction, troubleshooting, session handling, and security.\n- Updated and condensed skill overview to clarify usage for building crypto/Web3 agents, DeFi bots, and on-chain assistants across major EVM chains and 40+ protocols.\n- Permissions manifest introduced: restricts shell/network tools, file system access, and outbound connections for improved security (risk tier L2).\n- Output and error handling sections improved for clarity; troubleshooting guidance now referenced directly.\n- Expanded \"When to Use\" and command surface descriptions, including new AA/session controls and integration notes for plugin environments.\n- Skill metadata updated: tags, compatible-with, author, homepage, and explicit version incremented to 0.10.0.\n\nv0.5.0 | 2026-04-20T10:38:26.822Z | user\n\nExecute EVM transactions through conversational AI via aomi CLI\n\nArchive index:\n\nArchive v0.10.1: 15 files, 51193 bytes\n\nFiles: agents/openai.yaml (371b), references/account-abstraction.md (7698b), references/apps.md (16361b), references/commands.md (8609b), references/drain-vectors.md (4853b), references/examples.md (26196b), references/gotchas.md (6529b), references/thread.md (6073b), references/troubleshooting.md (5386b), references/workflows.md (6689b), SECURITY.md (14720b), skill-card.md (2764b), SKILL.md (9276b), templates/aomi-workflow.sh (8166b), _meta.json (133b)\n\nFile v0.10.1:SKILL.md\n\n---\nname: aomi-transact\ndescription: >\n Build natural-language crypto agents, web3 assistants, and trading bots that read\n and write EVM chain state. Aomi turns prompts (\"swap 1 ETH for USDC\", \"open a 3x\n GMX long\", \"bet $100 on Polymarket\") into wallet-signed transactions on Ethereum,\n Base, Arbitrum, Optimism, Polygon, Linea — non-custodial, fork-simulated. Use when\n the user wants a crypto/DeFi agent, AI trading/wallet assistant, or on-chain\n execution against Uniswap, Aave, Lido, GMX, Hyperliquid, Polymarket, Binance, OKX,\n or 40+ other protocols. Trigger with prompts about swaps, lending, bridging,\n staking, perps, prediction markets, or any DeFi/CEX action needing a wallet\n signature. Account-abstraction first with EIP-7702/4337 and EOA fallback. MUST NOT fabricate\n or echo credentials; values reach the CLI only when the user explicitly supplied them.\ncompatibility: 'Verified against @aomi-labs/client v0.1.42 and the current aomi-widget/packages/client TypeScript CLI. Install globally via npm install -g @aomi-labs/client@latest, or run on demand via npx @aomi-labs/client@latest. The CLI defaults to https://api.aomi.dev; pass --backend-url https://api-staging.aomi.dev when explicitly targeting staging. viem and Solana signing dependencies are bundled by the package. Designed for claude-code; also works with Cursor, Codex CLI, Gemini, and any agent runtime that supports the Anthropic skill spec.'\nlicense: MIT\nversion: \"0.10.1\"\nauthor: 'aomi-labs '\ntags: [crypto, defi, web3, evm, ethereum, wallet, account-abstraction, trading, mcp, agent]\nallowed-tools: 'Bash(aomi:*), Bash(npx:*)'\nmetadata:\n author: 'aomi-labs '\n version: \"0.10.1\"\n repository: aomi-labs/skills\n homepage: https://github.com/aomi-labs/skills/tree/main/aomi-transact\npermissions:\n files:\n read: [~/.aomi/]\n write: [~/.aomi/]\n deny_write: [SOUL.md, MEMORY.md, AGENTS.md]\n network:\n allow: [api.aomi.dev]\n deny: \"*\"\n shell:\n - aomi\n - npx @aomi-labs/client@latest\n tools: []\nrisk_tier: L2\nrequires:\n binaries: [aomi, npx]\n---\n\n# Aomi Transact\n\n## Overview\n\nAomi Transact drives the `aomi` TypeScript CLI to build natural-language crypto agents and web3 assistants. It composes calldata, fork-simulates transactions as a batch, and stages wallet requests for explicit user signing — non-custodial throughout. Current chain metadata includes Ethereum, Polygon, Arbitrum, Base, Optimism, Sepolia, Linea, Monad, Monad Testnet, and local Anvil. The npm CLI is the production/end-user surface; the Rust `aomi-cli` in `product-mono` is an in-process dev/test CLI with different signing gates. For deep references, see [commands.md](references/commands.md), [workflows.md](references/workflows.md), [gotchas.md](references/gotchas.md), [account-abstraction.md](references/account-abstraction.md), [apps.md](references/apps.md), [examples.md](references/examples.md), [thread.md](references/thread.md), [drain-vectors.md](references/drain-vectors.md), [troubleshooting.md](references/troubleshooting.md).\n\n## Prerequisites\n\n- Node.js 18+ with npm or npx\n- `@aomi-labs/client` v0.1.42 or newer: `npm install -g @aomi-labs/client@latest`\n- For EVM signing: a 0x-prefixed private key via `aomi wallet dev-key`, `--private-key`, or `PRIVATE_KEY`\n- For Solana sign-only flows: a base58 or JSON keypair via `aomi wallet dev-key --solana`, `--solana-private-key`, or `SOLANA_PRIVATE_KEY`\n- Optional: `AOMI_ACCOUNT_BEARER` / `--account-bearer` for authenticated account-bound requests\n- Optional: Alchemy or Pimlico credentials for direct account-abstraction providers; otherwise the CLI tries the backend Alchemy proxy path\n\n## Instructions\n\n1. Detect or install the CLI: `aomi --version 2>/dev/null || npx @aomi-labs/client@latest --version`\n2. Start a new thread: `aomi chat \"\" --new-session`\n3. Inspect queue: `aomi tx list`\n4. For multi-step flows, simulate first: `aomi tx simulate tx-1 tx-2`\n5. Sign: `aomi tx sign tx-1`\n6. Verify: `aomi thread status` or `aomi thread log`\n\nFor the full procedure (read-only requests, building wallet requests, signing policy, batch simulation, secret ingestion), see [workflows.md](references/workflows.md).\n\n## Examples\n\n```bash\naomi chat \"what is the price of ETH?\" --new-session\naomi chat \"swap 1 ETH for USDC\" --new-session --public-key 0xYourAddress --chain 1\naomi tx list && aomi tx simulate tx-1 tx-2 && aomi tx sign tx-1 tx-2\naomi chat \"stake 0.5 ETH on Lido\" --app lido --chain 1 --new-session\n```\n\nFour end-to-end walkthroughs (approve+swap, lending, bridging, staking) in [examples.md](references/examples.md). Per-app first-turn examples (Khalani, 0x, Polymarket, Binance, Neynar) in [apps.md](references/apps.md#usage-examples).\n\n## Output\n\n- `aomi chat`: agent response or `⚡ Wallet request queued: tx-N`\n- `aomi tx list`: table of pending/signed tx ids with `batch_status`\n- `aomi tx simulate`: per-step success/failure, revert reason, gas usage\n- `aomi tx sign`: transaction hash and on-chain confirmation\n\n## Error Handling\n\n| Error | Cause | Solution |\n|-------|-------|----------|\n| `insufficient funds for transfer` | EOA has no native gas | Fund EOA or configure AA sponsorship |\n| `AA execution failed with all modes` | AA path failed after mode fallback | Read the per-mode errors; use `--eoa` only if the user accepts EOA gas/payment semantics |\n| `stateful: false` in simulation | Wrong batch order | Reorder tx ids to match execution dependency |\n| `RPC 401`/`429` | Rate-limited or missing key | Set `--rpc-url` to authenticated endpoint |\n| No tx queued after chat | Agent returned quote first | Run `aomi tx list`; send a confirmation reply |\n| Orphaned `tx-N` in list | Previous simulation failed | Only sign txs with `batch_status: passed` |\n| `Failed to get apps/models: HTTP 404` | Public backend does not expose that introspection route | Treat `app list`/`model list` as backend-dependent; do not block chat/sign flows on it |\n\nFull troubleshooting in [troubleshooting.md](references/troubleshooting.md).\n\n## Safety Justification\n\nThis skill is `risk_tier: L2` because it can sign and broadcast on-chain transactions. The permissions manifest enforces least privilege:\n\n- **Shell allowlist** scopes execution to `aomi` and `npx @aomi-labs/client@latest` only — no arbitrary subprocesses.\n- **Network allowlist** restricts outbound traffic to `api.aomi.dev`. User-supplied `--rpc-url` endpoints are resolved by the CLI itself; operators must review them before allowing signing.\n- **File scope** is read+write to `~/.aomi/` only; identity files (`SOUL.md`, `MEMORY.md`, `AGENTS.md`) are deny-listed against writes per OWASP AST03 mitigation #3.\n- **No blind signing.** Multi-step flows go through `aomi tx simulate` on a forked chain before `aomi tx sign`. Drain-vector calldata fields (`recipient`, `onBehalfOf`, `mintRecipient`, `_to`) are blocked at simulation time when they do not equal `msg.sender` — see [drain-vectors.md](references/drain-vectors.md).\n- **Opaque credentials.** The skill never fabricates, derives, or echoes credential values; setup commands run only when the user explicitly asks and supplies the value in this turn. Full rules in [gotchas.md → Hard Rules](references/gotchas.md#hard-rules).\n\n## When to Use\n\n- The user wants to chat with the Aomi agent from the terminal.\n- The user wants balances, prices, routes, quotes, or transaction status.\n- The user wants to build, simulate, confirm, sign, or broadcast wallet requests.\n- The user wants to inspect or switch apps, models, chains, or threads.\n- The user wants to inspect or change Account Abstraction settings.\n- The user wants to authenticate a CLI account with `aomi login`, inspect it with `aomi account`, or inspect linked wallets with `aomi wallet ls`.\n- The user wants to build a new app from an API spec or SDK — use the companion skill **aomi-build**.\n\n## Command Surface\n\n```\naomi --prompt \"\" Send one prompt and exit\naomi chat Send a message\naomi tx list|simulate|sign\naomi thread list|new|resume|delete|status|log|events|close\naomi model list|current|set\naomi app list|current\naomi chain list|current|set\naomi wallet ls|dev-key|set-mode\naomi login|logout\naomi account\naomi cron ls|show|cancel\naomi config current|set-backend\naomi secret list|clear|add\naomi deploy\n```\n\nFull command reference, flags, and env vars in [commands.md](references/commands.md).\n\n## Resources\n\n- Source repository: https://github.com/aomi-labs/skills/tree/main/aomi-transact\n- npm package: https://www.npmjs.com/package/@aomi-labs/client\n- Companion skill for adding new protocol integrations: [aomi-build](https://github.com/aomi-labs/skills/tree/main/aomi-build)\n- Account abstraction deep-dive: [references/account-abstraction.md](references/account-abstraction.md)\n- Drain-vector catalog (security): [references/drain-vectors.md](references/drain-vectors.md)\n- End-to-end transaction examples: [references/examples.md](references/examples.md)\n- Troubleshooting playbook: [references/troubleshooting.md](references/troubleshooting.md)\n- OWASP AST03 (Over-Privileged Skills) spec: https://owasp.org/www-project-agentic-skills-top-10/ast03\n- Anthropic skill spec: https://docs.claude.com/en/docs/claude-code/skills\n\nFile v0.10.1:_meta.json\n\n{\n \"ownerId\": \"kn7axfgphsdj10cpkqw6n840nh86837c\",\n \"slug\": \"aomi-transact\",\n \"version\": \"0.10.1\",\n \"publishedAt\": 1783711863396\n}\n\nFile v0.10.1:references/account-abstraction.md\n\n# Account Abstraction Reference\n\nRead this when:\n\n- The user asks about AA modes, sponsorship, or chain defaults.\n- `aomi tx sign` returns an AA error and you need to pick a flag.\n- The user explicitly requests `4337` or `7702`.\n\n## Execution Model\n\nThe CLI uses **auto-detect** by default for EVM transactions. It tries account abstraction first, then falls back according to the requested mode:\n\n| User-side provider configured? | Flag | Result |\n|---|---|---|\n| Pimlico configured | `--aa-provider pimlico` | Pimlico BYOK (user-side credential) |\n| Alchemy configured | (none) | Alchemy BYOK (user-side credential) |\n| Nothing configured | (none) | Backend Alchemy proxy if available, otherwise EOA fallback after AA attempts |\n| Any | `--aa` / `--aa-provider` / `--aa-mode` | AA with explicit settings; no EOA fallback when `--aa` is set |\n| Any | `--eoa` | Direct EOA, skip AA |\n\nWith no explicit `--aa`, the current TypeScript CLI signs in this order: preferred AA mode, alternative AA mode, then EOA. With `--aa`, it tries AA modes only and returns a hard error if both fail. The zero-config proxy path is useful, but it is not a guarantee of sponsorship or availability.\n\n## Mode Fallback\n\nWhen using AA, the CLI tries modes in order:\n\n1. Try preferred mode (current configured default: 7702 on Ethereum, Polygon, Arbitrum, Base, and Optimism).\n2. If preferred mode fails, try the alternative mode (7702 ↔ 4337).\n3. If both modes fail and `--aa` was not set, try EOA.\n4. If `--aa` was set, return an AA-only error with the per-mode failures.\n\n## AA Configuration\n\nAA is configured per-invocation via flags or by credentials the user has configured on their side. There is no persistent AA config file on the skill's side.\n\nPriority chain for AA resolution: **flag > user-side credential > backend proxy/default > EOA fallback when allowed**.\n\n## AA Providers\n\n| Provider | Flag | Notes |\n| -------- | ----------------------- | -------------------------------- |\n| Alchemy | `--aa-provider alchemy` | 4337 (sponsored via gas policy), 7702 (EOA pays gas) |\n| Pimlico | `--aa-provider pimlico` | 4337 (sponsored via dashboard policy) |\n\nProvider selection rules:\n\n- If the user explicitly selects a provider via flag, use it.\n- In auto-detect mode, the CLI prefers explicit/user-side provider credentials, then the backend Alchemy proxy path.\n- Pimlico is used only when explicitly requested or configured; Alchemy can be direct BYOK or backend-proxied depending on available credentials.\n\nThe skill never configures provider credentials itself. If `aomi tx sign` reports missing provider credentials, stop and ask the user to configure them before re-running.\n\n## AA Modes\n\n| Mode | Flag | Meaning | Gas |\n| ------ | ---------------- | -------------------------------- | --- |\n| `4337` | `--aa-mode 4337` | Bundler + paymaster UserOperation via smart account. Gas sponsored by paymaster. | Paymaster pays |\n| `7702` | `--aa-mode 7702` | Native EIP-7702 type-4 transaction with delegation. EOA signs authorization + sends tx to self. | EOA pays |\n\n**7702 requires the signing EOA to have native gas tokens** (ETH, MATIC, etc.). There is no paymaster/sponsorship for 7702. Use 4337 for gasless execution.\n\n## Default Chain Modes\n\n| Chain | ID | Default AA Mode | Supported AA Modes |\n| -------- | ----- | --------------- | ------------------ |\n| Ethereum | 1 | 7702 | 4337, 7702 |\n| Polygon | 137 | 7702 | 7702, 4337 |\n| Arbitrum | 42161 | 7702 | 7702, 4337 |\n| Base | 8453 | 7702 | 7702, 4337 |\n| Optimism | 10 | 7702 | 7702, 4337 |\n\nThese match the live `aomi chain list` output in CLI v0.1.42 for the chains with displayed AA metadata.\n\n## Sponsorship\n\nSponsorship is available for **4337 mode only**. 7702 does not support sponsorship. Sponsorship policy is configured on the provider's side — the user's provider account decides whether a given UserOperation is sponsored. Once the user has configured their provider, `aomi tx sign` (with the appropriate AA flags if the user wants an explicit provider) will pick up the active policy automatically.\n\n### Sponsorship in practice (verified against v0.1.42 source behavior)\n\nThe \"zero-config Alchemy proxy\" path is not a guarantee of free gas. Empirically:\n\n- **7702 default on the configured EVM chains**: gas is paid by the EOA. A zero native-gas wallet cannot rely on 7702.\n- **4337 sponsorship**: depends on the provider/paymaster policy. The backend proxy path may exist, but the skill must not promise gasless execution without evidence from the user's configured provider.\n- **Auto mode**: when AA fails and `--aa` was not set, the CLI can try EOA. This means an apparent AA failure may still require native gas because the final submission path is EOA.\n\n**Practical rule the skill must follow**: before signing on an L2, confirm the EOA has a small amount of native gas on the destination chain (~0.0005 ETH equivalent is enough). If the user is sending USDC-only to an L2 with no native gas, warn them that signing on that L2 will fail unless they:\n\n1. fund the EOA with a tiny amount of native gas on that chain, **or**\n2. configure a real BYOK AA provider on their side (Alchemy with a Gas Manager policy attached, or Pimlico with a sponsorship policy on the dashboard — the user sets the credential in their own environment) and pass `--aa --aa-provider alchemy|pimlico --aa-mode 4337` on `aomi tx sign`.\n\nDo not promise the user \"AA will pay for gas on L2s\" without verifying the user's setup. The default proxy path may silently fall through.\n\nWhen the CLI emits a viem `insufficient funds for transfer` error, do not re-run with `--eoa` blindly — `--eoa` will also fail if the EOA has 0 gas. Stop and tell the user to fund the destination chain or configure a sponsoring BYOK provider.\n\n## Supported Chains\n\n| Chain | ID | AA available? |\n| ------------- | -------- | ------------- |\n| Ethereum | 1 | Yes (4337, 7702; default 7702) |\n| Polygon | 137 | Yes (7702, 4337; default 7702) |\n| Arbitrum One | 42161 | Yes (7702, 4337; default 7702) |\n| Base | 8453 | Yes (7702, 4337; default 7702) |\n| Optimism | 10 | Yes (7702, 4337; default 7702) |\n| Sepolia | 11155111 | Chain supported; AA metadata not displayed by `chain list` |\n| Linea Mainnet | 59144 | Chain supported; verify provider support before AA |\n| Linea Sepolia | 59141 | Chain supported; verify provider support before AA |\n| Monad | 143 | Chain supported; verify provider support before AA |\n| Monad Testnet | 10143 | Chain supported; verify provider support before AA |\n| Anvil (local) | 31337 | Local chain; prefer `--eoa` unless testing AA explicitly |\n\nFor chains without displayed AA metadata, expect provider support to vary. Pass `--eoa` when the user wants a plain EOA signature, or pass explicit AA flags only after confirming the provider supports that chain.\n\n## RPC Guidance By Chain\n\nUse an RPC that matches the pending transaction's chain:\n\n- Ethereum txs → Ethereum RPC\n- Polygon txs → Polygon RPC\n- Arbitrum txs → Arbitrum RPC\n- Base txs → Base RPC\n- Optimism txs → Optimism RPC\n- Sepolia txs → Sepolia RPC\n- Linea txs → Linea RPC\n- Monad txs → Monad RPC\n\nPractical rule:\n\n- `--chain` affects the wallet/thread context for chat and request building.\n- `--rpc-url` affects where `aomi tx sign` estimates and submits the transaction.\n- Treat them as separate controls and keep them aligned with the transaction you are signing.\n\nFile v0.10.1:references/apps.md\n\n# Apps Reference\n\nRead this when:\n\n- The user asks \"what apps are available?\" or names a category (CEX, lending, perps, prediction, social).\n- You need to pick `--app` for a request and want to see the catalog.\n- You need a usage example for a specific app.\n\n## Discovering Apps\n\nThe set of installed apps is dynamic — the catalog below is a snapshot. Always confirm against the live CLI:\n\n```bash\naomi app list # enumerate apps exposed by the backend\naomi app current # show the currently active app\n```\n\nSelect an app for a chat turn with `--app ` or set `AOMI_APP=` for a multi-command shell. When an app needs provider credentials, the aomi CLI reports at runtime what is missing. The user configures those credentials themselves; the skill does not perform that setup unless the user explicitly asks (see SKILL.md \"Secret Ingestion\").\n\n## App Catalog\n\nAll apps share a common base toolset (`send_transaction_to_wallet`, `encode_and_simulate`, `get_account_info`, `get_contract_abi`, etc.). The tools listed below are the app-specific additions. The \"Credentials\" column indicates whether an app needs user-configured credentials at all; the CLI reports the specific names at runtime when something is missing.\n\n| App | Description | App-Specific Tools | Credentials |\n|-----|-------------|-------------------|-------------|\n| `default` | General-purpose on-chain agent with web search | `brave_search` | None |\n| `binance` | Binance CEX — prices, order book, klines | `binance_get_price`, `binance_get_depth`, `binance_get_klines` | Exchange credentials |\n| `bybit` | Bybit CEX — orders, positions, leverage | `brave_search` (no Bybit-specific tools yet) | Exchange credentials |\n| `cow` | CoW Protocol — MEV-protected swaps via batch auctions | `get_cow_swap_quote`, `place_cow_order`, `get_cow_order`, `get_cow_order_status`, `get_cow_user_orders` | None |\n| `defillama` | DefiLlama — TVL, yields, volumes, stablecoins | `get_token_price`, `get_yield_opportunities`, `get_defi_protocols`, `get_chain_tvl`, `get_protocol_detail`, `get_dex_volumes`, `get_fees_overview`, `get_protocol_fees`, `get_stablecoins`, `get_stablecoin_chains`, `get_historical_token_price`, `get_token_price_change`, `get_historical_chain_tvl`, `get_dex_protocol_volume`, `get_stablecoin_history`, `get_yield_pool_history` | None |\n| `dune` | Dune Analytics — execute and fetch SQL queries | `execute_query`, `get_execution_status`, `get_execution_results`, `get_query_results` | Provider token |\n| `dydx` | dYdX perpetuals — markets, orderbook, candles, trades | `dydx_get_markets`, `dydx_get_orderbook`, `dydx_get_candles`, `dydx_get_trades`, `dydx_get_account` | None |\n| `gmx` | GMX perpetuals — markets, positions, orders, prices | `get_gmx_prices`, `get_gmx_signed_prices`, `get_gmx_markets`, `get_gmx_positions`, `get_gmx_orders` | None |\n| `hyperliquid` | Hyperliquid perps — mid prices, orderbook | `get_meta`, `get_all_mids` | None |\n| `kaito` | Kaito — crypto social search, trending, mindshare | `kaito_search`, `kaito_get_trending`, `kaito_get_mindshare` | Provider token |\n| `kalshi` | Kalshi prediction markets via Simmer SDK | `simmer_register`, `simmer_status`, `simmer_briefing` | SDK token |\n| `khalani` | Khalani cross-chain intents — quote, build, submit | `get_khalani_quote`, `build_khalani_order`, `submit_khalani_order`, `get_khalani_order_status`, `get_khalani_orders_by_address` | None |\n| `lifi` | LI.FI aggregator — cross-chain swaps & bridges | `get_lifi_swap_quote`, `place_lifi_order`, `get_lifi_bridge_quote`, `get_lifi_transfer_status`, `get_lifi_chains` | Optional provider token |\n| `manifold` | Manifold prediction markets — search, bet, create | `list_markets`, `get_market`, `get_market_positions`, `search_markets`, `place_bet`, `create_market` | Provider token |\n| `molinar` | Molinar on-chain world — move, explore, chat | `molinar_get_state`, `molinar_look`, `molinar_move`, `molinar_jump`, `molinar_chat`, `molinar_get_chat`, `molinar_get_new_messages`, `molinar_get_players`, `molinar_collect_coins`, `molinar_explore`, `molinar_create_object`, `molinar_customize`, `molinar_ping` | None |\n| `morpho` | Morpho lending — markets, vaults, positions | `get_markets`, `get_vaults`, `get_user_positions` | None |\n| `neynar` | Farcaster social — users, search | `get_user_by_username`, `search_users` | Provider token |\n| `okx` | OKX CEX — tickers, order book, candles | `okx_get_tickers`, `okx_get_order_book`, `okx_get_candles` | Exchange credentials |\n| `oneinch` | 1inch DEX aggregator — quotes, swaps, allowances | `get_oneinch_quote`, `get_oneinch_swap`, `get_oneinch_approve_transaction`, `get_oneinch_allowance`, `get_oneinch_liquidity_sources` | Provider token |\n| `para` | Para — MPC wallet management across EVM, Solana, Cosmos (threshold signing) | (Para wallet tools — confirm with `aomi app current` after selecting) | Provider token |\n| `para-consumer` | Para Consumer — consumer-wallet helper: prices, yield, swap quotes, bridge routes | (Consumer-facing read tools — confirm via runtime) | Provider token |\n| `polymarket` | Polymarket prediction markets — search, trade, CLOB | `search_polymarket`, `get_polymarket_details`, `get_polymarket_trades`, `resolve_polymarket_trade_intent`, `build_polymarket_order_preview` | None |\n| `polymarket-rewards` | Polymarket LP — liquidity provisioning into reward-enrolled markets, ranked by reward APY | (LP scoring + position tools — confirm via runtime) | Provider token |\n| `x` | X/Twitter — users, posts, search, trends | `get_x_user`, `get_x_user_posts`, `search_x`, `get_x_trends`, `get_x_post` | Provider token |\n| `yearn` | Yearn Finance — vault discovery, details | `get_all_vaults`, `get_vault_detail`, `get_blacklisted_vaults` | None |\n| `zerox` | 0x DEX aggregator — swaps, quotes, liquidity | `get_zerox_swap_quote`, `place_zerox_order`, `get_zerox_swap_chains`, `get_zerox_allowance_holder_price`, `get_zerox_liquidity_sources` | Provider token |\n\nWhen a \"Credentials\" entry says *Exchange credentials*, *Provider token*, or *SDK token*, ask the user to configure that app's credentials in their own terminal (or — only if they explicitly ask — run `aomi secret add` with the value they supply).\n\nTo build a new app from an API spec or SDK, use the companion skill **aomi-build**.\n\n## Usage Examples\n\nEach example shows the canonical first chat turn for that category. Follow the standard workflow afterwards: `aomi tx list` → (`aomi tx simulate` for multi-step) → `aomi tx sign`.\n\n### Solver Networks — `khalani`\n\nCross-chain intents executed by a solver network. Khalani returns multiple solver routes per quote; prefer the one that offers a `TRANSFER` deposit method when present.\n\n**Get a quote (read).** Requires `--public-key` even for read-only quotes — without it the agent refuses with \"I need a connected wallet to fetch a Khalani quote.\"\n\n```bash\naomi chat \"quote bridging 50 USDC from Polygon to Base via Khalani. Prefer a TRANSFER deposit method if available.\" \\\n --app khalani --public-key 0xUserAddress --chain 137 --new-session\n```\n\nVerified response shape (historical real-backend capture; re-check against the current backend before treating exact app output as stable):\n\n```\nRoute Options:\n 1. Hyperstream (Native Filler) ⭐ supports TRANSFER\n Deposit Methods: CONTRACT_CALL, TRANSFER\n Amount Out: 49.950049 USDC\n Duration: ~10s\n Fee: ~0.05 USDC (~0.1%)\n 2. Across\n Deposit Methods: CONTRACT_CALL only\n Amount Out: 49.984261 USDC\n Duration: ~2s\n Gas: 0.032 POL (~$0.02)\n 3. DeBridge\n Deposit Methods: CONTRACT_CALL only\n Amount Out: 49.681958 USDC\n Duration: ~2 min\n Gas: 0.108 POL (~$0.08)\n```\n\n**Build and submit the order (write).** After the user picks a route, confirm in the same thread:\n\n```bash\naomi chat \"proceed with Hyperstream using the TRANSFER method\"\naomi tx list # confirm the wallet request was queued\naomi tx sign tx-1 --rpc-url # source-chain RPC must match\n```\n\nNotes:\n\n- Khalani internally exposes Across, DeBridge, and other solvers as routes. If the standalone `across` app is unavailable on the active backend, go through Khalani and pick the Across route at quote time.\n- Single-chain intents work too: `--app khalani --chain 1` for an Ethereum-only request.\n- Inspect open orders: `aomi chat \"list my open Khalani orders\" --app khalani --public-key 0xUserAddress` (read-only, but still wallet-aware).\n- If the agent returns a quote without queueing a wallet request, that's expected — you have to explicitly say \"proceed\".\n\n### Cross-Chain — `zerox`\n\n0x aggregator for swaps and cross-chain liquidity. Good for \"best-price\" single-chain swaps and for swaps spanning chains where 0x has coverage.\n\n```bash\n# Best-price swap on Base\naomi chat \"best price to swap 1 ETH for USDC on Base via 0x\" \\\n --app zerox --chain 8453 --new-session\n\n# Cross-chain swap — let the aggregator pick the route\naomi chat \"swap 100 USDC on Arbitrum for ETH on Optimism via 0x\" \\\n --app zerox\n\n# List supported chains\naomi chat \"which chains does 0x support today?\" --app zerox\n```\n\nNotes:\n\n- `zerox` requires a provider token. If `aomi tx sign` fails because credentials are missing, ask the user to configure their 0x credentials (do not invent or paste them on the user's behalf).\n- For approve-and-swap on a single chain, simulate the batch with `aomi tx simulate tx-1 tx-2` before signing.\n\n### Prediction Markets — `polymarket`\n\nSearch markets, inspect details, build trade previews on Polymarket's CLOB. Polymarket lives on Polygon — pass `--chain 137`.\n\n**Find markets (read).** No wallet required for search:\n\n```bash\naomi chat \"find 3 active Polymarket markets about US politics in 2026; list them with id and current YES price\" \\\n --app polymarket --new-session\n```\n\nVerified response shape (historical real-backend capture; re-check against the current backend before treating exact app output as stable):\n\n```\n1. Trump out as President before GTA VI?\n Market ID: 540820 YES: 0.52 Liquidity: $19,447 Volume: $622,047\n2. Xi Jinping out before 2027?\n Market ID: 559651 YES: 0.0775 Liquidity: $108,298 Volume: $8,416,434\n3. Will Gavin Newsom win the 2028 Democratic presidential nomination?\n Market ID: 559652 YES: 0.2705 Liquidity: $678,162 Volume: $24,719,477\n```\n\n**Build a buy preview (write-leaning).** Requires `--public-key` and `--chain 137`. Returns an unsigned preview the user must explicitly confirm before any tx is queued:\n\n```bash\naomi chat \"build a YES buy preview for \\$5 on Polymarket market 559651. Just build the preview, do not place it.\" \\\n --app polymarket --public-key 0xUserAddress --chain 137 --new-session\n```\n\nVerified preview shape:\n\n```\nPolymarket Order Preview\n Market: Xi Jinping out before 2027?\n Market ID: 559651\n Side: BUY YES\n Order Type: Market Order (Fill-or-Kill)\n Amount: $5.00 USDC\n Current YES: 0.0775 (~7.75%)\n Estimated Shares: ~64.52\n Wallet: 0xUserAddress\n Network: Polygon (137)\n Status: Preview only — no order placed\n```\n\n**Place the order (write).** Once the user confirms:\n\n```bash\naomi chat \"place the order\"\naomi tx list # confirm a wallet request was queued\naomi tx sign tx-1 # AA-first signing on Polygon (default 4337)\n```\n\nNotes:\n\n- `build_polymarket_order_preview` returns an unsigned order for review. `aomi tx list` shows nothing until the user confirms with \"place the order\" or similar.\n- `resolve_polymarket_trade_intent` maps natural-language trades (\"buy YES on Xi for $5\") to a concrete market+side+size before the preview step. Useful when the user describes a trade casually.\n- `polymarket-rewards` is a separate app (LP-side, not trader-side) — see catalog above.\n\n### CEX — `binance`\n\nRead-only market data from Binance. No on-chain signing involved.\n\n```bash\n# Spot price snapshot\naomi chat \"what is BTCUSDT trading at on Binance?\" \\\n --app binance --new-session\n\n# Top-of-book depth\naomi chat \"show me top 5 levels of the ETHUSDT order book on Binance\" \\\n --app binance\n\n# Recent klines\naomi chat \"1h klines for SOLUSDT for the last 24 hours from Binance\" \\\n --app binance\n```\n\nNotes:\n\n- `binance` needs Exchange credentials. The skill never invents these. If `aomi chat` fails because credentials are missing, ask the user to configure them on their side.\n- This is a data app — no `tx-N` will be queued from these commands. `aomi tx list` is not part of this flow.\n\n### Social — `neynar`\n\nFarcaster user lookup and search via Neynar.\n\n```bash\n# Look up a user\naomi chat \"look up the Farcaster user 'dwr.eth' via Neynar\" \\\n --app neynar --new-session\n\n# Search by handle\naomi chat \"search Farcaster for users matching 'aomi'\" --app neynar\n```\n\nNotes:\n\n- `neynar` requires a provider token. Same rule as the other token-gated apps: ask the user to configure it.\n- Like `binance`, this is a read-only data app — no wallet requests are queued.\n\n### Social — `x`\n\nX/Twitter user lookup, post fetching, and search.\n\n```bash\n# Look up a user\naomi chat \"look up the X user @AnthropicAI - return handle, follower count, and bio\" \\\n --app x --new-session\n\n# Search posts\naomi chat \"search X for posts mentioning 'claude code' from the last week, top 3 with handle and text\" \\\n --app x\n\n# Trending topics\naomi chat \"what's trending on X right now?\" --app x\n```\n\nRead-only data app — no wallet requests are queued. The X app needs a provider token configured on the backend.\n\n> **TODO — not verified end-to-end.** On the live backend at the time of capture, both lookup and search returned \"I don't have access to the X API at the moment due to authentication issues\" — the X provider token was not configured for the test account. The shape of the call is correct; the backend response when the token *is* configured has not been captured here. When you have a working setup, replace this note with the real response shape (handle, follower_count, bio for `get_x_user`; array of posts for `search_x`).\n\n### Bridging — Across (no standalone app)\n\nIf the user-facing `across` app is unavailable on the active backend, Across is still commonly reachable two ways:\n\n1. **As a route inside Khalani.** Khalani's solver network lists Across alongside Hyperstream and DeBridge in its quote response — pick the Across route at quote time.\n2. **As a tool the agent picks itself.** Asking any wallet-aware app for a bridge may produce an Across-routed wallet request even without `--app khalani`. Re-check the generated SpokePool address against the active chain before signing.\n\n```bash\n# Option 1 — via Khalani (lets Khalani's solver pick Across)\naomi chat \"quote bridging 50 USDC from Polygon to Base via Khalani\" \\\n --app khalani --public-key 0xUserAddress --chain 137 --new-session\n# Then: aomi chat \"proceed with the Across route\"\n\n# Option 2 — direct (let the agent pick Across as the tool)\naomi chat \"Bridge 1 USDC from Ethereum mainnet to Base via Across. Include approve as a separate tx so we can simulate the batch.\" \\\n --public-key 0xUserAddress --chain 1 --new-session\naomi tx list\naomi tx sign tx-1 tx-2\n```\n\nObserved behavior in earlier CLI/backend captures:\n\n- Across requests carry an expiring `fillDeadline`. If the agent's first build expires by the time simulation runs, the agent automatically rebuilds with a fresh deadline and the new tx-N will pass. **Old failed attempts remain visible in `aomi tx list`** with `batch_status: \"Batch [N,M] failed at step 2: 0x...\"` — sign only the txs whose status reads `Batch [...] passed`.\n- The mainnet→L2 leg uses AA 7702 (default for chain 1) and signs cleanly with the EOA's small ETH stash paying.\n- The L2→mainnet leg requires the EOA to have native gas on the L2 unless a real 4337 sponsor path is configured — see [account-abstraction.md → Sponsorship in practice](account-abstraction.md#sponsorship-in-practice-verified-against-v0142-source-behavior).\n\n> **TODO — direct integration.** If a standalone `across` app gets added later, replace this stub with read + write examples in the same shape as the other entries.\n\nFile v0.10.1:references/commands.md\n\n# Command Reference\n\nFull command surface for the TypeScript `aomi` CLI (or `npx @aomi-labs/client@latest` equivalent), verified against `@aomi-labs/client` v0.1.42. The skill invokes read forms freely; `set`/mutating forms only when the user explicitly asks.\n\n## Chat\n\n```bash\naomi chat \"\" # one-shot send and exit\naomi --prompt \"\" # root-level compatibility form\naomi chat \"\" --new-session\naomi chat \"\" --verbose # stream tool calls and agent output\naomi chat \"\" --model \naomi chat \"\" --public-key 0xUserAddress --chain 1\naomi chat \"\" --app khalani --chain 137\naomi chat \"\" --account-bearer \"$AOMI_ACCOUNT_BEARER\"\n```\n\n- Quote the message.\n- On the first command in a new assistant thread, prefer `--new-session`.\n- Pass `--public-key` on the first wallet-aware message.\n- Use `--app`, `--model`, `--chain` to change the active context for the next request.\n\n## Transactions\n\n```bash\naomi tx list # pending/signed requests\naomi tx simulate [ ...] [--cluster devnet] # dry-run a batch on a fork / cluster\naomi tx sign [ ...] [--cluster devnet] # sign and submit\n```\n\n## Threads\n\n```bash\naomi thread list # local threads with topic + pending count\naomi thread new\naomi thread resume # set active pointer\naomi thread delete # remove (check no pending txs first)\naomi thread status # current thread summary\naomi thread log # replay conversation + tool output\naomi thread events # raw backend system events\naomi thread close # clear active pointer; next chat starts fresh\n```\n\nSelectors accept the backend thread id, `thread-N`, or `N`.\n\n## Secrets\n\n```bash\naomi secret list # handle names only, no values\naomi secret clear # drop all configured secrets\naomi secret add NAME= [NAME=...] # user-directed only (see workflows.md)\n```\n\n## Apps and Models\n\n```bash\naomi app list\naomi app current\naomi model list\naomi model current\naomi model set # persist model for current thread\n```\n\n`aomi chat --model \"\"` applies a model for one turn without persisting it. Pick an app per turn with `--app ` or `AOMI_APP=`. The installed set is dynamic — confirm with `aomi app list`. Full catalog and per-app credential requirements in [apps.md](apps.md).\n\n## Chain\n\n```bash\naomi chain list\naomi chain current\naomi chain set # only when user asked to change default\n```\n\n## Wallet and Config\n\n```bash\naomi wallet ls # linked wallets, providers, signing policy, grants\naomi wallet ls --provider privy # filter linked wallets by provider\naomi wallet dev-key # user-directed EVM 0x key\naomi wallet dev-key --solana # user-directed Solana keypair\naomi wallet set-mode
\naomi login # browser auth URL, mint account bearer\naomi login --provider privy --evm # request an EVM provider wallet\naomi login --provider privy --solana # request a Solana provider wallet\naomi logout\naomi account # inspect authenticated account and linked methods\naomi config current # backend URL\naomi config set-backend # repoint CLI at a different backend\n```\n\n`aomi wallet dev-key` persists local signing material under `AOMI_STATE_DIR`. After running, confirm with the derived address or Solana public key — never repeat the key value back. Every linked wallet has a signing policy: `autonomous`, `human_sync`, or `denied`. `aomi wallet set-mode` changes a policy via signed EIP-712 challenge and commit; grants toward `autonomous` must be signed by that wallet's own key.\n\n## Cron\n\n```bash\naomi cron ls # scheduled thread jobs\naomi cron show # inspect one scheduled thread\naomi cron cancel # cancel one scheduled thread\n```\n\n## Deploy\n\n```bash\naomi deploy --activation-token \"$AOMI_DEPLOY_TOKEN\" --app-source-id \n```\n\nThe TypeScript deploy command is a portal/app-source deployment surface and uses `AOMI_DEPLOY_TOKEN`. Do not confuse it with the Rust `aomi-build deploy` flow, which uses `AOMI_APP_ACTIVATION_TOKEN`.\n\n## Flags and Env Vars\n\nFlags override environment variables.\n\n| Flag | Default | Purpose |\n| --------------- | ---------------------- | --------------------------------------------------------- |\n| `--backend-url` | `https://api.aomi.dev` | Backend URL |\n| `--api-key` | none | API key for non-default apps (user-supplied) |\n| `--account-bearer` | `AOMI_ACCOUNT_BEARER` | Account-bound auth bearer |\n| `--account-provider` | deprecated | Legacy provider exchange; prefer `--account-bearer` |\n| `--account-provider-token` | deprecated | Legacy provider token; prefer `--account-bearer` |\n| `--app` | `default` | Backend app |\n| `--model` | backend default | Thread model |\n| `--new-session` | off | Create a fresh active thread for this command |\n| `--public-key` | none | Wallet address for chat/thread context |\n| `--private-key` | `PRIVATE_KEY` | EVM signing key for this invocation |\n| `--solana-private-key` | `SOLANA_PRIVATE_KEY` | Solana signing key for this invocation |\n| `--rpc-url` | chain RPC default | RPC override for signing |\n| `--chain` | none | Active wallet chain (inherits thread chain if unset) |\n| `--cluster` | `AOMI_SOLANA_CLUSTER` | Solana cluster (`mainnet-beta`, `devnet`, `testnet`, or CAIP-2) |\n| `--eoa` | off | Force plain EOA, skip AA (sign-only) |\n| `--aa` | off | Force AA, error if provider not configured (sign-only) |\n| `--aa-provider` | auto-detect | `alchemy` \\| `pimlico` (sign-only) |\n| `--aa-mode` | chain default | `4337` \\| `7702` (sign-only) |\n\n| Env Var | Default | Purpose |\n| ----------------- | --------- | -------------------------------------- |\n| `AOMI_STATE_DIR` | `~/.aomi` | Root directory for local thread state |\n| `AOMI_CONFIG_DIR` | `~/.aomi` | Root directory for persistent config |\n| `AOMI_ACCOUNT_BEARER` | none | Account auth bearer minted by login or supplied by user |\n| `AOMI_CHAIN_ID` | none | Default active chain |\n| `CHAIN_RPC_URL` | none | Signing RPC override |\n| `PRIVATE_KEY` | none | EVM signing key |\n| `SOLANA_PRIVATE_KEY` | none | Solana signing key |\n| `AOMI_SOLANA_CLUSTER` | none | Default Solana cluster |\n\n## Config Rules\n\n- EVM signing keys must be 0x-prefixed hex. Solana signing keys are base58 or JSON keypairs. Configuring either is a user action, not a skill action.\n- `--aa-provider` and `--aa-mode` cannot be used with `--eoa`.\n- The default signing RPC is one URL. For chain switching, pass `--rpc-url` on `aomi tx sign` with a chain-matching public RPC.\n- In auto-detect mode, the CLI tries AA first for EVM transactions and can fall back to EOA when AA fails unless `--aa` was explicitly requested.\n- Solana signing currently materializes legacy pending `solana_sign` requests with unsigned transactions; canonical instruction-only `svm_ixs` requests may not appear as CLI-signable pending txs yet.\n\nFor account-abstraction details (modes, providers, sponsorship, chain defaults), see [account-abstraction.md](account-abstraction.md).\n\nFile v0.10.1:references/drain-vectors.md\n\n# Drain Vectors\n\nRead this when:\n\n- A simulation fails with an annotation like `recipient != msg.sender` or similar, and you need to know whether that's a guard-block or a real bug.\n- You're constructing a new flow and need to know which calldata field the agent treats as the \"drain\" for a given protocol.\n- The user types a prompt with a non-self recipient (*\"swap and send to 0xFriend\"*) and you need to predict whether the agent will let it through.\n\n## What this is\n\nA **drain vector** is the calldata field where a malicious prompt could redirect funds away from the user — `recipient` in Uniswap, `onBehalfOf` in Aave, `mintRecipient` in CCTP, `_to` in OP-stack bridges. The agent blocks these at simulation time when they don't equal `msg.sender`.\n\nWhen you see a `Batch success: false` with a drain-vector annotation, it is **not** a transaction-construction bug. It is the agent's guard rejecting calldata that would route the user's funds to a non-self address. The skill's job is to surface the block to the user — not to reformulate the prompt to bypass it.\n\nFor example flows that hit these guards (Uniswap recipient, Aave onBehalfOf, CCTP mintRecipient, OP-stack `_to`), see the relevant section in [examples.md](examples.md).\n\n## Reference table\n\n| Protocol | Drain Vector | Notes |\n|----------|--------------|-------|\n| Uniswap V3 `exactInputSingle` / `exactOutputSingle` | `recipient` (word3) | Block at simulation if != msg.sender |\n| Uniswap V2 `swapExactTokensForTokens` | `to` parameter | Same |\n| 1inch v6 `swap` | `dstReceiver` inside `SwapDescription` tuple | Same |\n| Sushi V2 `swapExactTokensForTokens` | `to` (recipient) | Same |\n| Curve `exchange` | n/a — refunds msg.sender directly | No drain vector by design |\n| Aave V3 `supply` | `onBehalfOf` | Same |\n| Aave V3 `borrow` / `withdraw` | `to` | Same |\n| Aave V3 `repay` | `onBehalfOf` | Same |\n| Compound V3 `supplyTo` | `dst` | Same |\n| Morpho `supply` | `onBehalfOf` (inside MarketParams call) | Same |\n| CCTP `depositForBurn` | `mintRecipient` (bytes32, left-padded) | Same |\n| Across `depositV3` | `recipient` (word1) | Same |\n| Stargate `send` | `recipient` inside `SendParam` AND separate `refundAddress` | **Both** are drain vectors |\n| Arbitrum native bridge `outboundTransferCustomRefund` | `_to` AND `_refundTo` | Both |\n| OP-stack `bridgeETHTo` / `depositETHTo` (Base/Optimism) | `_to` | Plus `_to == address(0)` is a hard block (not just a warning) — bridging to zero permanently locks funds on L2 |\n| zkSync Mailbox `requestL2Transaction` | `_contractL2` AND `_refundRecipient` | Both |\n| LST tokens (stETH, wstETH, rETH, eETH, etc.) `transfer` / `transferFrom` | `_to` | Special-case block on the issued token, not on the staking call. The agent guards against attacker prompts like *\"transfer my stETH to 0xdEaD\"* even though stETH itself is a known Lido contract |\n\n## How the guard fires\n\nThe agent runs `simulate_batch` against a forked chain before staging calldata to the wallet. When a drain vector is detected, the simulation result includes an annotation like:\n\n```\nBatch [1] failed: drain-vector at recipient != msg.sender\n step 1: exactInputSingle((USDC, WETH, 500, 0xdEaD..., 1_000_000, 0, 0))\n user: 0xUserAddress\n field: recipient (word3)\n```\n\nThe wallet never sees this calldata — it's rejected at the simulation gate. The skill should **surface the block** to the user. Two scenarios:\n\n1. **The user typo'd or forgot their own address** → confirm with them (\"did you mean to send to your own wallet?\") and re-prompt with the corrected recipient.\n2. **The user actually wanted to send to a different address** (a friend, a multisig, a contract) → the agent's default policy is conservative; the user can override only by re-prompting with explicit acknowledgment, and the skill should surface that the calldata is intentionally non-self before signing.\n\nDo **not** attempt to bypass the guard by reformulating the prompt without the user's explicit redirect. Do not paste the exact same intent through a different app to evade the check.\n\n## Hard blocks vs. soft warnings\n\nMost drain-vector annotations are **soft warnings** — they fail simulation and ask for explicit confirmation. A few are **hard blocks** that cannot be acknowledged through:\n\n- **`_to == address(0)`** on OP-stack bridges. Bridging to zero permanently locks funds on L2 with no recovery path. The agent fails simulation with a clear \"L2 funds will be permanently unrecoverable\" message. If the user typo'd, do **not** retry — surface the block and re-prompt for the correct address.\n- **Token-level `transfer` to a known sink address** (`0x0`, `0xdEaD`, etc.) on a freshly issued LST. Special-case to prevent the staking-then-transfer attacker chain.\n\nFor the full per-protocol example flows that hit these guards, see [examples.md](examples.md).\n\nFile v0.10.1:references/examples.md\n\n# Flow Examples\n\nRead this when:\n\n- The user asks for a concrete end-to-end example of a DeFi operation.\n- You're constructing a new flow and want a template to pattern-match against.\n- You're a new tool-using model and need to know what shape `aomi chat` will return for a given user intent.\n\nEach example is anchored to a **real backend-side capture** from a mainnet anvil fork. Prompts, gas figures, addresses, and the `Internal trace` blocks come directly from those captures. The \"What the user sees in the terminal\" blocks are **reformatted** from the same backend events into the CLI's pretty-printed style — the data is real, the exact text formatting may drift slightly across CLI versions. See [Verification provenance](#verification-provenance) at the end of this doc for source logs and capture dates.\n\nThe CLI lifecycle is consistent across every example:\n\n> **chat** (natural-language intent) → **list** (verify what was queued) → **simulate** (catch reverts before signing) → **sign** (wallet pop) → **verify** (chain-state confirmation)\n\nIf you only remember one thing: **the user gives intent in plain English; aomi composes calldata; simulate is the gate; the wallet only sees what passed simulation.**\n\nA term you'll see throughout: a **drain vector** is the calldata field where a malicious prompt could redirect funds to a wrong recipient — `recipient` in Uniswap, `onBehalfOf` in Aave, `mintRecipient` in CCTP, `_to` in OP-stack bridges. The agent blocks these at simulation time when they don't equal the user's own address. The skill's job is to surface the block, not bypass it. Full per-protocol table in [drain-vectors.md](drain-vectors.md).\n\nTwo notes on what you'll see in the terminal:\n\n- The `Internal trace` blocks below show what the agent does silently between chat and the queued-tx output. Users only see this with `--verbose` or by replaying via `aomi thread log`. Without `--verbose`, the user sees just the assistant prose followed by `⚡ Wallet request queued: tx-N`.\n- The shortest one-shot form is `aomi --prompt \"\"`. The examples below use `aomi chat \"\"` for readability — both behave the same.\n\n---\n\n## 1. Swap — Uniswap V3 exactInputSingle\n\n**Anchored to** `redteam-uniswap-happy-1.log` — USDC→WETH on mainnet, fee tier 500 (0.05%), captured shape.\n\n### What the user types\n\n```bash\naomi chat \"swap 1 USDC for WETH on Uniswap V3, send to my wallet\" \\\n --public-key 0xUserAddress --chain 1 --new-session\n```\n\nThat's enough. The agent picks `SwapRouter02 0x68b3465833fb72A70ecDF485E0e4C7bD8665Fc45`, fee tier 500, recipient = your wallet, and queues the approve in the same batch.\n\n### What the user sees in the terminal\n\n```\nI've staged your USDC → WETH swap on Uniswap V3 (0.05% fee tier).\n\nTransaction Batch:\n 1. Approve Uniswap Router to spend USDC\n 2. Swap 1 USDC → WETH on V3 0.05% pool, recipient = your wallet\n\nRun `aomi tx simulate tx-1 tx-2` to dry-run, then `aomi tx sign tx-1 tx-2` to send.\n\n⚡ Wallet request queued: tx-1\n to: 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48\n value: 0\n chain: 1\n⚡ Wallet request queued: tx-2\n to: 0x68b3465833fb72A70ecDF485E0e4C7bD8665Fc45\n value: 0\n chain: 1\n```\n\n### Internal trace (visible with `--verbose` or `aomi thread log`)\n\nThe agent activates the skill, reads balance/allowance, then stages two txs and simulates:\n\n```\nactivate_skills → uniswap\nread USDC.balanceOf / USDC.allowance to SwapRouter02\nstage \"Approve Uniswap Router to spend USDC\"\n approve(0x68b3...Fc45, MAX) on USDC\nstage \"USDC to WETH swap\"\n exactInputSingle((USDC, WETH, 500, , 1_000_000, 0, 0))\nsimulate_batch → Batch success: true\n (no drain-vector annotations)\n```\n\n### Lifecycle\n\n```bash\naomi tx list\n# pending:\n# tx-1 to 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 (USDC)\n# label: Approve Uniswap Router to spend USDC\n# tx-2 to 0x68b3465833fb72A70ecDF485E0e4C7bD8665Fc45 (Uniswap SwapRouter02)\n# label: Swap 1 USDC for WETH on Uniswap V3 (0.05% pool)\n\naomi tx simulate tx-1 tx-2\n# Simulation result:\n# Batch success: true\n# Stateful: true\n# Total gas: 197194\n#\n# Step 1 — Approve Uniswap Router to spend USDC\n# success: true\n# gas_used: 55798\n#\n# Step 2 — Swap 1 USDC for WETH on Uniswap V3\n# success: true\n# gas_used: 141396\n\naomi tx sign tx-1 tx-2\n# Exec: aa (alchemy, 7702)\n# ✅ Sent! Hash: 0x... (single hash for the atomic batch)\n```\n\n### What to expect / pattern notes\n\n- **One hash for the 7702 atomic batch** — both `tx-1` and `tx-2` show the same hash in `aomi tx list` after signing. Not a bug.\n- **Recipient is the drain vector** — exactInputSingle word3. The agent blocks `recipient != msg.sender` at simulation time. If the user types *\"swap and send the WETH to 0xdEaD\"*, the batch will fail simulation with a drain-vector annotation. Don't try to bypass — surface the block.\n- **Other DEX apps with the same shape**: `sushiswap` (V2 `swapExactTokensForTokens`, recipient at word3), `oneinch` (v6 `swap` with `dstReceiver` inside a tuple), `curve` (`exchange` — no recipient param, refunds msg.sender directly).\n- **If the user names a path** (USDC→DAI→WETH), the agent picks `swapExactTokensForTokens` on the V2 router or routes via 1inch — let it choose unless overridden with `--app uniswap`.\n- **1inch fallback pattern.** Captured in `~/.aomi/sessions/messages-cli-*.json`: when a user asks for `oneinch` `unoswap` directly, the agent stages approve + swap, simulates, and the swap step reverts because `unoswap` requires a `dex` parameter encoded by the 1inch off-chain API (pool address + protocol flags) that the agent can't construct on its own. The agent's response is **not silent retry** — it explains the gap and offers a fallback:\n > *\"`unoswap` requires a specifically encoded `dex` parameter that includes the pool address and swap protocol flags (e.g., Uniswap V3), which cannot be manually constructed reliably without the 1inch API. Since I do not have a 1inch API tool to generate valid calldata, I cannot complete this swap through the 1inch Aggregator. **Would you like me to try this swap using a direct DEX instead?** I can use the Uniswap or Sushiswap skills to perform the USDC to WETH trade directly.\"*\n\n When you see this, agree to the fallback (*\"yes, use Uniswap\"*) and the agent will rebuild the batch against `SwapRouter02` as in the example above. Don't insist on 1inch unless the user has a separate API key configured to provide the dex param.\n\n---\n\n## 2. Lending — Aave Supply (with retry-as-batch pattern)\n\n**Anchored to** `redteam-aave-happy.log` — supply 1 USDC to Aave V3 on mainnet. This example documents the **first-attempt-fails, retry-with-approve** pattern that's the most common multi-step shape in lending.\n\n### What the user types\n\n```bash\naomi chat \"supply 1 USDC on Aave\" \\\n --public-key 0xUserAddress --chain 1 --new-session\n```\n\n### What the user sees in the terminal\n\nIf the agent first tries a single-tx supply, simulation rejects it:\n\n```\nI tried to supply 1 USDC to Aave V3 directly, but simulation failed:\n Batch [1] failed: ERC20: transfer amount exceeds allowance\n\nRebuilding as a 2-tx batch — approve first, then supply.\n\nTransaction Batch:\n 1. Approve Aave V3 Pool to spend 1 USDC\n 2. Supply 1 USDC to Aave V3 (recipient = your wallet)\n\nBoth pass simulation. Run `aomi tx simulate tx-2 tx-3` to verify, then sign.\n\n⚡ Wallet request queued: tx-2\n to: 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48\n value: 0\n chain: 1\n⚡ Wallet request queued: tx-3\n to: 0x87870Bca3F3fD6335C3F4ce8392D69350B4fA4E2\n value: 0\n chain: 1\n```\n\n`tx-1` is the stale orphan from the first attempt — sign only `tx-2 tx-3`.\n\n### Internal trace (visible with `--verbose`)\n\n```\nactivate_skills → aave\nstage \"supply USDC for user\"\n supply(USDC, 1_000_000, , 0) on Aave V3 Pool 0x87870Bca...\nsimulate_batch → Batch [1] failed: ERC20: transfer amount exceeds allowance\n (no drain-vector annotations — calldata itself is benign)\n\n# Agent rebuilds:\nstage \"Approve Aave Pool to spend USDC\"\n approve(0x87870Bca..., 1_000_000) on USDC\nstage \"supply USDC for user\" (re-staged)\nsimulate_batch → Batch [2,3] passed\n total gas 258_121 (approve 55_558 + supply 202_563)\n```\n\n### Lifecycle\n\n```bash\naomi tx list\n# pending after retry:\n# tx-1 (stale — failed sim, ignore)\n# tx-2 to 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 (USDC)\n# label: Approve Aave Pool to spend USDC\n# tx-3 to 0x87870Bca3F3fD6335C3F4ce8392D69350B4fA4E2 (Aave V3 Pool)\n# label: supply USDC for user\n\naomi tx simulate tx-2 tx-3\n# Simulation result:\n# Batch success: true\n# Stateful: true\n# Total gas: 258121\n#\n# Step 1 — Approve Aave Pool to spend USDC\n# success: true\n# gas_used: 55558\n#\n# Step 2 — supply USDC for user\n# success: true\n# gas_used: 202563\n\naomi tx sign tx-2 tx-3\n\naomi chat \"show my Aave positions\"\n```\n\n### What to expect / pattern notes\n\n- **The first stage_tx may fail simulation, that's normal.** When the agent gets `ERC20: transfer amount exceeds allowance`, it stages a fresh approve and re-batches. `aomi tx list` will show 3 entries: an orphan tx-1 from the first attempt and the working tx-2/tx-3 pair. **Sign the pair, not the orphan.**\n- **`onBehalfOf` is the drain vector.** If the user types *\"supply for 0xFriend\"*, the agent blocks `onBehalfOf != msg.sender` at simulation time. Same pattern for borrow / withdraw `to` / repay `onBehalfOf`.\n- **Compound v3 differs**: it uses `supplyTo(dst, asset, amount)` on the Comet target (e.g. cUSDCv3 `0xc3d688B6...`); `dst != msg.sender` is the drain. Same retry shape.\n- **Morpho uses a tuple-encoded `MarketParams` struct** — the agent constructs raw calldata for `supply((loanToken, collateralToken, oracle, irm, lltv), assets, shares, onBehalfOf, data)`. The user just says *\"supply 100 USDC to the wstETH/USDC Morpho market\"* — picking the market is the agent's job.\n\n---\n\n## 3. Staking — Lido Submit (LST, no approve)\n\n**Anchored to** a real CLI session captured in `~/.aomi/sessions/current.json` — stake 0.01 ETH, mint stETH. The simplest shape in this doc: single tx, no approve, native ETH as the asset, and the agent surfaces the expected share output before the user signs.\n\n### What the user types\n\n```bash\naomi chat \"Stake 0.01 ETH with Lido to get stETH. Build the transaction.\" \\\n --public-key 0xUserAddress --chain 1 --new-session\n```\n\n### What the user sees in the terminal\n\nThe agent's first response (after silent context/simulation/balance checks):\n\n```\nThe simulation for staking 0.01 ETH to receive stETH was successful. You have a\nsufficient balance of ~0.0148 ETH to cover both the stake and gas.\n\nSimulation Details:\n Contract: 0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84 (Lido: stETH)\n Function: submit(address(0))\n Value: 0.01 ETH\n Estimated stETH Output: 0.008121... (Shares)\n\nI've prepared the transaction for your approval:\n```\n\nThen the queued-tx block, followed by the agent's confirmation message:\n\n```\n⚡ Wallet request queued: tx-1\n to: 0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84\n value: 10000000000000000\n chain: 1\n\nI've prepared the transaction to stake 0.01 ETH on Lido for stETH. The simulation\nwas successful, indicating you will receive approximately 0.00812 stETH (based\non current protocol shares). I've also verified your balance (0.0148 ETH) is\nsufficient to cover the stake and gas.\n\nTransaction Details:\n Action: submit(0x000...000)\n Contract: 0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84 (Lido: stETH)\n Value: 0.01 ETH\n\nPlease approve the request in your wallet to broadcast the transaction.\n```\n\nThe two assistant messages around the queued-tx event is real CLI behavior — the agent narrates before staging and confirms after. Don't treat the second message as a duplicate.\n\n### Internal trace (visible with `--verbose` or `aomi thread log`)\n\nThe actual silent tool sequence captured from `current.json`:\n\n```\nread Get network context for Lido staking (block 24828069, gas 1.25 gwei)\nactivate_skills → lido\nread Simulate Lido staking (submit 0.01 ETH) → returns shares: 8121458494637141 wei\nread Check ETH balance for staking → 0.014857 ETH available\nstage Lido Staking\n submit(address(0)) on Lido stETH 0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84\n value = 0.01 ETH, gas = 150_000\n status = pending_approval\n```\n\nNote: Lido is a single-tx flow, so the agent runs a one-off `simulate` read **before** staging — that's what produces the *\"Estimated stETH Output: 0.008121...\"* line in the user-facing response. The `simulate_batch` step you see in multi-step examples isn't here; the user calls `aomi tx simulate tx-1` separately if they want to dry-run again before signing.\n\n### Lifecycle\n\n```bash\naomi tx list\n# pending:\n# tx-1 to 0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84 (Lido: stETH)\n# label: Stake 0.01 ETH in Lido for stETH\n# value: 0.01 ETH\n\naomi tx simulate tx-1\n# Simulation result:\n# Batch success: true\n# Stateful: true\n# Total gas: ~150000\n#\n# Step 1 — Stake 0.01 ETH in Lido for stETH\n# success: true\n\naomi tx sign tx-1\n\naomi chat \"show my stETH balance\"\n```\n\n### What to expect / pattern notes\n\n- **No approve.** ETH is the asset (passed via `msg.value`); single-tx flow. Same shape applies to `rocket_pool` (`deposit()` → rETH), `etherfi` (`deposit()` → eETH), `kelp` (`depositETH()` → rsETH), `renzo` (`depositETH()` → ezETH), `mantle_staked_eth` (`stake()` → mETH).\n- **Rebasing vs non-rebasing.** stETH rebases (your balance grows over time without any tx); wstETH is the wrapped non-rebasing version. The agent's prose surfaces this distinction unprompted — preserve it in your own summaries, don't strip it. EtherFi follows the same split (eETH rebases, weETH is wrapped); Rocket Pool's rETH is non-rebasing by design.\n- **The pre-stage share estimate** (*\"Estimated stETH Output: 0.008121...\"*) is a Lido-specific Eth-to-shares conversion at the current ratio. If the user asks *\"how much stETH will I get?\"* before staking, the agent has already computed this — surface it instead of re-asking.\n- **The drain vector for LSTs is on the issued token, not on `submit()`.** Once the user holds stETH, an attacker prompt like *\"transfer my stETH to 0xdEaD\"* would normally pass any \"is this a known Lido contract?\" check (stETH IS a known Lido contract). The agent adds a special-case `transfer` / `transferFrom` block on stETH itself. Same for the other LST tokens listed above.\n- **Withdrawals are time-delayed.** `requestWithdraw` queues a claim, the user comes back later for `claimWithdraw`. Don't simulate them as part of the same batch — surface the delay.\n\n---\n\n## 4. Bridge with attestation — CCTP (Ethereum → Base)\n\n**Anchored to** `redteam-cctp-happy3.log` — bridge 50 USDC, captured shape including the bot's protocol-specific UX hint about Circle attestation timing.\n\n### What the user types\n\n```bash\naomi chat \"Bridge 50 USDC from Ethereum mainnet to Base via CCTP. Recipient is my own wallet. Approve first.\" \\\n --public-key 0xUserAddress --chain 1 --new-session\n```\n\nThis is the **gold-standard prompt shape** for any bridge: amount + asset + chains + protocol + recipient + multi-step hint. The agent does the rest.\n\n### What the user sees in the terminal\n\n```\nI've staged and simulated the bridge for 50 USDC from Ethereum to Base via CCTP.\nThe simulation was successful.\n\nNote on Settlement: Once you sign and broadcast these transactions, the USDC will\nbe burned on Ethereum. You will need to wait approximately 13–19 minutes for\nCircle's attestation before the funds are minted to your wallet on Base.\n\nTransaction Batch:\n 1. Approve USDC — allow the CCTP Messenger (0x28b5...cf5d) to spend 50 USDC.\n 2. Bridge to Base — call depositForBurn to send the funds to Base (Domain ID: 6).\n\nPlease sign tx-1 and tx-2 in your wallet to proceed.\n\n⚡ Wallet request queued: tx-1\n to: 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48\n value: 0\n chain: 1\n⚡ Wallet request queued: tx-2\n to: 0x28b5a0e9c621a5badaa536219b3a228c8168cf5d\n value: 0\n chain: 1\n```\n\n### Internal trace (visible with `--verbose`)\n\nCCTP shows the most paranoid pre-stage verification — balance, allowance, ABI, proxy unwrap, selector check — before staging anything:\n\n```\nactivate_skills → cctp\nread chain context / current_time\nread USDC.balanceOf → 1_000 USDC available\nread USDC.allowance(, TokenMessenger) → 0\nread USDC ABI + EIP-1967 implementation unwrap\nread TokenMessenger ABI + implementation unwrap\nverify depositForBurn selector present on impl\n\nstage \"Approve USDC for CCTP Messenger (50 USDC)\"\n approve(0x28b5...cf5d, 50_000_000) on USDC\nstage \"Bridge 50 USDC from Ethereum to Base using CCTP\"\n depositForBurn(50_000_000, 6, , USDC, ...)\n on TokenMessenger 0x28b5a0e9c621a5badaa536219b3a228c8168cf5d\n\nsimulate_batch → Batch [1,2] passed\n total gas 164_891 (approve 55_570 + depositForBurn 109_321)\n (no drain-vector annotations)\n```\n\n### Lifecycle\n\n```bash\naomi tx list\n# pending:\n# tx-1 to 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 (USDC)\n# label: Approve USDC for CCTP Messenger (50 USDC)\n# tx-2 to 0x28b5a0e9c621a5badaa536219b3a228c8168cf5d (CCTP TokenMessenger)\n# label: Bridge 50 USDC from Ethereum to Base using CCTP\n\naomi tx simulate tx-1 tx-2\n# Simulation result:\n# Batch success: true\n# Stateful: true\n# Total gas: 164891\n#\n# Step 1 — Approve USDC for CCTP Messenger (50 USDC)\n# success: true\n# gas_used: 55570\n#\n# Step 2 — Bridge 50 USDC from Ethereum to Base using CCTP\n# success: true\n# gas_used: 109321\n\naomi tx sign tx-1 tx-2\n\n# After signing, the source-chain burn confirms in 1-2 blocks, but the destination\n# mint requires ~13-19 min for Circle's off-chain attestation. Track via:\naomi chat \"track my CCTP bridge — has Circle attested yet?\"\n```\n\n### What to expect / pattern notes\n\n- **`mintRecipient` is the L2 owner, encoded as `bytes32`.** A natural-language *\"send to my wallet\"* gets correctly converted to `0x000000...<20-byte-address>` left-padded. If the user types a different address, the agent blocks `mintRecipient != msg.sender` at simulation time.\n- **Domain IDs are CCTP-specific, not chain IDs.** Base = 6, Arbitrum = 3, Optimism = 2, Avalanche = 1, Solana = 5. The agent translates *\"to Base\"* → `destinationDomain = 6`. Don't pass chain IDs here.\n- **Settlement is off-chain.** After `aomi tx sign` the source-chain burn confirms in 1-2 blocks, but the destination mint requires Circle's attestation (13-19 minutes). This is **not** a `tx-N` in `aomi tx list` — track it with a follow-up chat.\n- **Other bridge shapes** with the same overall flow but different settlement model:\n - **Across** (`depositV3` to SpokePool, ~30s settlement, recipient at word1) — fast but variable relayer fee. Bot will fetch a quote first.\n - **Stargate** (`send(SendParam, fee, refundAddress)`, recipient inside SendParam tuple, separate refundAddress, LayerZero settlement) — **both** recipient AND refundAddress are drain vectors; the agent blocks either if it differs from `msg.sender`.\n - **Arbitrum native** (`outboundTransferCustomRefund`, `_to` and `_refundTo` both drain vectors, ~10 min L1→L2).\n - **OP-stack native** (Base/Optimism `bridgeETHTo` or `depositETHTo` — see example 5).\n\n---\n\n## 5. Native L2 bridge — Base depositETHTo (single tx, no approve)\n\n**Anchored to** `redteam-base_native-happy.log` — deposit 0.01 ETH to L2. The simplest bridge shape: ETH is the asset, no approve, no off-chain attestation, ~1-3 minute L1→L2 inclusion.\n\n### What the user types\n\n```bash\naomi chat \"bridge 0.01 ETH from Ethereum to Base, recipient is my wallet\" \\\n --public-key 0xUserAddress --chain 1 --new-session\n```\n\n### What the user sees in the terminal\n\n```\nI've staged your bridge of 0.01 ETH from Ethereum to Base via the native L1StandardBridge.\n\nTransaction:\n depositETHTo(your wallet, gasLimit=200_000) value = 0.01 ETH\n on L1StandardBridge (0x3154...2c35)\n\nSettlement is automatic: ETH appears on Base in roughly 1-3 minutes. No destination-chain\nstep on your end. Note the gas estimate is unusually high (~620k) because the call\nincludes creating the L2 deposit ticket — that's expected, not a bug.\n\nRun `aomi tx sign tx-1` to broadcast.\n\n⚡ Wallet request queued: tx-1\n to: 0x3154cf16ccdb4c6d922629664174b904d80f2c35\n value: 10000000000000000\n chain: 1\n```\n\n### Internal trace (visible with `--verbose`)\n\n```\nactivate_skills → base_native\nstage \"bridge 0.01 ETH to Base via depositETHTo\"\n depositETHTo(, 200_000, 0x) on L1StandardBridge 0x3154cf16ccdb4c6d922629664174b904d80f2c35\n value = 0.01 ETH\nsimulate_batch → Batch [1] passed\n total gas 620_845 (includes L2 deposit ticket creation)\n (no drain-vector annotations)\n```\n\n### Lifecycle\n\n```bash\naomi tx list\n# pending:\n# tx-1 to 0x3154cf16ccdb4c6d922629664174b904d80f2c35 (Base L1StandardBridge)\n# label: bridge 0.01 ETH to Base via depositETHTo\n# value: 0.01 ETH\n\naomi tx simulate tx-1\n# Simulation result:\n# Batch success: true\n# Stateful: true\n# Total gas: 620845\n#\n# Step 1 — bridge 0.01 ETH to Base via depositETHTo\n# success: true\n# gas_used: 620845\n\naomi tx sign tx-1\n```\n\n### What to expect / pattern notes\n\n- **No approve.** ETH is the asset (passed via `msg.value`); only one tx.\n- **Gas is unusually high (~600k+).** The L1 portion is cheap, but the OP-stack `depositETHTo` includes creating the L2 deposit ticket — the gas estimate accounts for that. Don't be alarmed.\n- **`_to = address(0)` is a hard block, not just a warning.** OP-stack bridges to `0x0` permanently lock funds (no recovery on L2). The agent fails simulation with the message *\"Bridge recipient is address(0). L2 funds will be permanently unrecoverable.\"* If the user typo'd a zero address, do **not** retry — surface the block.\n- **Optimism is identical** with target `0x99c9fc46f92e8a1c0dec1b1747d010903e884be1` (OP L1StandardBridge). zkSync uses `requestL2Transaction` on the Mailbox `0x32400084c286cf3e17e7b677ea9583e60a000324` with both `_contractL2` (L2 target) and `_refundRecipient` (L2 gas refund) as drain vectors.\n- **Returning from Base/OP back to mainnet requires native gas unless sponsorship is actually configured** — if the EOA has 0 ETH on the L2, auto mode may still fail with `insufficient funds for transfer` after AA attempts. See [account-abstraction.md → Sponsorship in practice](account-abstraction.md#sponsorship-in-practice-verified-against-v0142-source-behavior).\n\n---\n\n## What All Five Flows Have in Common\n\n- **Always start a wallet-aware thread** with `--public-key 0xUserAddress` and the right `--chain`.\n- **Always read `aomi tx list`** between chat and signing — never guess what's queued.\n- **Always simulate multi-step batches** before signing. Single-tx flows are simulation-optional but never wrong to simulate.\n- **Always confirm** with the user before `aomi tx sign` for any flow that moves funds.\n- **The natural-language prompt shape** that consistently works:\n > * [] [] []*\n >\n > Examples:\n > - *\"swap 100 USDC for WETH on Uniswap\"* (verb amount asset protocol)\n > - *\"supply 1000 USDC on Aave\"* (verb amount asset protocol)\n > - *\"stake 1 ETH on Rocket Pool\"* (verb amount asset protocol)\n > - *\"bridge 50 USDC from Ethereum to Base via CCTP, recipient my wallet, approve first\"* (full template)\n- **Things the agent does silently before staging** — balance check, allowance check, ABI verification (proxy unwrap if applicable), selector verification. Visible to the user only with `--verbose` or via `aomi thread log`. Don't bypass these by feeding raw calldata unless you're red-team testing the guard.\n- **The simulator is the gate, not the wallet.** If simulation reports `Batch success: false` (or you see a guard-block annotation in `aomi thread events`), **do not** attempt `aomi tx sign` — surface the failure to the user and either rebuild (allowance retry pattern) or stop.\n- **Multi-tx batches return one hash on 7702 (AA), two hashes on EOA-batched.** Both `tx-1` and `tx-2` share the same `txHash` in `aomi tx list` after signing under the AA 7702 atomic-batch path — that's expected. On the EOA path with `batched: true` (e.g. when AA falls through or the user passes `--eoa`), each `tx-N` carries a **`txHashes: [hash1, hash2]`** array — the operation produces two on-chain transactions, with the second being the canonical one shown as `txHash`. Reference: real captures in `~/.aomi/sessions/session-*.json` show `executionKind: \"eoa\"`, `batched: true`, and the dual-hash array. If you see two hashes, that's not a duplicate-broadcast bug — that's the EOA-batched signing pattern.\n\n## Verification provenance\n\n| Example | Source capture | Date |\n|---|---|---|\n| 1. Uniswap V3 swap | `redteam-uniswap-happy-1.log` | 2026-04-29 |\n| 2. Aave supply | `redteam-aave-happy.log` | 2026-04-28 |\n| 3. Lido stake | `~/.aomi/sessions/current.json` (real CLI capture, not redteam) | 2026-04-07 |\n| 4. CCTP bridge | `redteam-cctp-happy3.log` | 2026-04-25 |\n| 5. Base native bridge | `redteam-base_native-happy.log` | 2026-04-28 |\n\nThe example-3 source row is the only one taken from a live CLI session rather than a backend redteam log — useful as a sanity check that the CLI rendering documented in the \"What the user sees\" blocks matches what real users observe. If you see a divergence between this doc and current bot behavior, the capture date tells you how recent the source is — re-run a happy-path test on the affected protocol before assuming this doc is wrong.\n\nFile v0.10.1:references/gotchas.md\n\n# Gotchas, Hard Rules, and Security Model\n\n## What You Probably Got Wrong\n\nLLM training data on aomi is stale. These are the most common mistakes the skill is shaped to prevent. Each correction is anchored to current `@aomi-labs/client` v0.1.42 behavior and local TypeScript source.\n\n- **\"Aomi is a wallet\"** → Aomi is an agent + CLI. It composes calldata and queues a wallet request; the user signs. The CLI does not custody funds, never signs without an explicit `aomi tx sign`, and never broadcasts on its own initiative.\n\n- **\"`aomi chat` always queues a transaction\"** → Often the first response is a quote, route, or clarifying question. The agent only stages calldata when it has enough context. Always run `aomi tx list` after chat to see what is actually pending — never assume.\n\n- **\"Approval and swap are one transaction\"** → Most DeFi flows are two-step: `approve` then `supply`/`swap`/`deposit`. Aomi stages them as a batch and `aomi tx simulate tx-1 tx-2` runs them sequentially on a fork so the second step sees the first's state changes. Sign them as a batch, not individually.\n\n- **\"Use `--rpc-url` to switch chains\"** → `--chain` controls the wallet/thread context (which chain the agent thinks you are on); `--rpc-url` controls where `aomi tx sign` estimates and submits. They are independent. For a cross-chain flow, the queued tx has its own `chain` field — pass `--rpc-url` matching *that* chain when signing.\n\n- **\"AA always sponsors gas on L2s\"** → The currently displayed AA defaults are 7702 on Ethereum, Polygon, Arbitrum, Base, and Optimism. 7702 spends native gas from the EOA. 4337 can be sponsored only when the selected provider/paymaster policy supports it. If the EOA has 0 native gas on the destination chain, auto mode may still fail after AA attempts because the fallback path is EOA. See [account-abstraction.md → Sponsorship in practice](account-abstraction.md#sponsorship-in-practice-verified-against-v0142-source-behavior).\n\n- **\"`--new-session` should always be passed\"** → Pass it on the *first* command of a new task. Reusing it mid-task starts a fresh conversation and the agent loses context (e.g. the quote it just gave you). For follow-up confirmations like *\"yes, proceed\"*, omit `--new-session`.\n\n- **\"Failed simulation txs disappear\"** → They do not. `aomi tx list` can show older `tx-N` entries from earlier failed attempts alongside the current passing batch. Check the `batch_status` line and only sign txs marked as passing.\n\n- **\"7702 and 4337 are interchangeable\"** → They are not. 7702 is a native EIP-7702 type-4 transaction with EOA delegation; the EOA pays gas. 4337 is a bundler+paymaster UserOperation; the paymaster can sponsor. Current displayed defaults: 7702 on Ethereum, Polygon, Arbitrum, Base, and Optimism. Use 4337 only when a supported paymaster path is actually configured.\n\n- **\"`aomi wallet set` is still the key command\"** → The current surface uses `aomi wallet dev-key` for local test keys and `aomi wallet ls` for linked wallet/account policy inspection. Solana local keys use `aomi wallet dev-key --solana ` or `--solana-private-key` / `SOLANA_PRIVATE_KEY` for one invocation.\n\n- **\"`aomi app list` and `aomi model list` are required preflights\"** → These introspection routes are backend-dependent and may return 404 on the public backend. Do not block chat, tx list, simulation, or signing flows just because app/model listing is unavailable.\n\n- **\"Drain vectors are aomi-specific\"** → They are protocol-specific calldata fields where a malicious prompt could redirect funds (`recipient` in Uniswap, `onBehalfOf` in Aave, `mintRecipient` in CCTP, `_to` in OP-stack bridges). The agent blocks these at simulation time when they do not equal `msg.sender`. The skill's job is to surface the block, not bypass it. Full table in [drain-vectors.md](drain-vectors.md).\n\n## Hard Rules\n\n- Never invent, guess, or derive a credential value. The skill only ever passes through a value the user has explicitly given for a specific action in this turn.\n- Never echo a credential value back after it has been used. Confirm the action (\"dev key set\", \"secret `` added\") without restating the value.\n- Setup commands that take a credential (`aomi wallet dev-key `, `aomi secret add NAME=`, flags like `--private-key`) are only run when the user has explicitly asked for that specific setup in this turn and has supplied the value themselves. Do not run them on the skill's own initiative to \"prepare\" or \"fix\" something.\n- Before running a credential-setup command the user asked for, briefly confirm what will be persisted and where (local CLI state vs. the aomi backend — see [workflows.md → Secret Ingestion](workflows.md#secret-ingestion) for the transmission note), so the user can abort.\n- Only call `aomi tx sign` after `aomi tx list` shows a pending `tx-N` the user asked for.\n- When starting a new assistant thread, default the first aomi command to `--new-session` unless the user wants to continue an existing thread.\n- The signing RPC must match the pending transaction's chain. `--chain` (thread context) and `--rpc-url` (signing transport) are independent — keep them aligned.\n- `--aa-provider` and `--aa-mode` are AA-only controls and cannot be used with `--eoa`.\n\n## Security Model\n\nThis skill is scoped to the `aomi` CLI. It does not install software, read files outside the aomi state directory, or execute code it generates.\n\n- **Credentials are opaque pass-through.** The skill never fabricates, guesses, or derives a credential value. Values only reach the CLI when the user has handed them over for a specific command in this turn, and they are not echoed or retained.\n- **No unsolicited setup.** The skill does not run credential-persisting setup (`aomi wallet dev-key`, `aomi secret add NAME=`) to \"prepare\" for a task. It runs those commands only when the user explicitly asked, with the value the user supplied.\n- **No blind signing.** Multi-step flows (approve → swap, approve → deposit) go through `aomi tx simulate` on a forked chain before `aomi tx sign`. Single-step read operations do not require simulation.\n- **User-directed batches only.** `aomi tx sign` can take multiple ids; that is for batches the user has reviewed, not for sweeping a queue.\n- **Read-only by default.** Chat, simulation, thread inspection, and app/model/chain introspection do not move funds. Signing is a separate, explicit step the user must ask for.\n\nFile v0.10.1:references/thread.md\n\n# Thread Reference\n\nRead this when:\n\n- You need to know **where** conversation history, pending txs, or signed receipts live.\n- `aomi tx list` returns `No active thread` and you need to recover the right thread.\n- The user asks \"what's in `~/.aomi/`?\" or wants to clean up old threads.\n- You're picking between `--new-session`, `aomi thread resume `, and just letting the active thread continue.\n\n## Two-tier storage model\n\nA \"thread\" is split across two stores. Knowing what lives where prevents wrong-place lookups.\n\n**Backend (the aomi server)** holds the durable record:\n\n- The full conversation transcript (user prompts + assistant prose).\n- All tool calls + tool outputs the agent made silently.\n- System events (BYOK key changes, sponsorship decisions, etc.).\n- Indexed by a `sessionId` UUID.\n\n`aomi thread log`, `aomi thread events`, and the message replay in `aomi thread status` all hit the backend with the local `sessionId`. If the backend is unreachable or the sessionId is wrong, these will silently return empty or fail.\n\n**Local on disk** (`$AOMI_STATE_DIR` if set, else `~/.aomi/`) holds the lookup keys and the parts the wallet flow needs:\n\n- `sessionId` and `clientId` (UUIDs the backend uses to find the rest).\n- `publicKey`, `chainId`, `baseUrl` (current wallet/chain/backend context).\n- `pendingTxs[]` and `signedTxs[]` (full calldata, gas estimates, hashes — same data the backend has, mirrored locally so `aomi tx list` works without a network round-trip).\n- `secretHandles{}` (handle names only — values are never stored locally).\n\nThe local state is what `aomi tx list`, `aomi tx sign`, and `aomi config current` read from. None of these touch the backend. (`aomi wallet ls` is the separate linked-wallets view: one table with address, chain, provider, signing mode, grant expiry, autonomous_ok, and primary.)\n\n## File layout\n\n```\n~/.aomi/\n├── active-session.txt # one line, the local thread id (e.g. \"43\")\n├── aa.json # AA config cache; usually \"{}\"\n└── sessions/\n ├── session-1.json\n ├── session-2.json\n ├── ...\n ├── session-.json # one file per local thread\n ├── current.json # rolling pointer/cache used by the REPL\n └── messages-cli-.json # per-call message buffers (REPL streaming)\n```\n\nEach `session-.json` is the local source of truth for that thread. Inspecting it is safe — it does not contain credential values, only handle names. Useful when debugging:\n\n```bash\ncat ~/.aomi/sessions/session-43.json | jq '{sessionId, chainId, publicKey, pending: (.pendingTxs|length), signed: (.signedTxs|length)}'\n```\n\n## The `active-session.txt` mechanic\n\n`aomi tx list`, `aomi tx sign`, and `aomi tx simulate` all need an **active** thread. The active thread is just the local id stored in `~/.aomi/active-session.txt`. Set automatically by:\n\n- `aomi --prompt \"...\"` (creates or reuses one)\n- `aomi chat \"...\"` (same)\n- `aomi --new-session ...` (creates a new one)\n- `aomi thread new` (creates a new one, no chat)\n- `aomi thread resume ` (sets active to an existing thread)\n\nCleared by `aomi thread close` and sometimes by errors mid-flight.\n\n**The \"No active thread\" recovery pattern**: if `aomi tx list` reports no active thread, run `aomi thread list` to find the right thread by topic or pending count, then `aomi thread resume > /dev/null && aomi tx list` in the same shell call (the active-thread pointer can be lost between subprocess invocations).\n\n## Lifecycle: `--new-session` vs `resume` vs neither\n\nThree rules, in order:\n\n1. **Starting fresh work in a new assistant thread or terminal**: pass `--new-session` on the first chat command. Old thread context (pending txs from previous tasks, accumulated message tokens) won't bleed in.\n2. **Continuing a task you started earlier (same thread)**: don't pass `--new-session`. The active thread persists across `aomi` invocations; the next `aomi chat \"proceed\"` lands in the same conversation.\n3. **Picking up a previous thread by id**: `aomi thread resume ` first, then issue commands. Useful when `aomi tx list` shows pending txs you need to sign from a thread that was closed earlier (e.g. thread-43 in our run had pending Across txs after the shell rotated).\n\nAccount login is no longer nested under `wallet` or `account`: use `aomi login` for the browser/device flow, `aomi account` to inspect the active account, and `aomi wallet ls` to inspect linked wallets and signing policy.\n\n## Cleanup hygiene\n\nThreads accumulate. After a few weeks of use, `~/.aomi/sessions/` can hold 50–100+ files. Cleanup is safe:\n\n```bash\naomi thread list # see what's there, with topics + pending counts\naomi thread delete # delete one — safe if no pending txs\naomi thread close # clear active pointer; next chat starts fresh\n```\n\n**Before deleting a thread, check it has no pending wallet requests** (`aomi tx list` after `aomi thread resume `). Deleting a thread with pending txs orphans them — the backend may still know about them, but the local CLI loses the calldata and ids needed to sign.\n\n`messages-cli-*.json` buffer files in `sessions/` are safe to remove manually — they're per-invocation REPL caches, not thread state.\n\nThe `secretHandles{}` block in a thread JSON is safe to read and inspect. The values they reference are stored on the backend, scoped to that thread's `clientId`. `aomi secret clear` removes them from the backend; deleting the thread locally does not.\n\n## When to override the state dir\n\n`AOMI_STATE_DIR` lets the user point the CLI at a non-default state root. Common reasons:\n\n- Test setups: `AOMI_STATE_DIR=$(mktemp -d) aomi --prompt \"...\"` — clean slate per run, no contamination of the user's main `~/.aomi/`.\n- Multiple identities: separate dirs for separate wallets / backends, switched via shell function or `direnv`.\n\nThe skill itself does not set this variable. If the user wants isolation, they configure it in their own shell.\n\nFile v0.10.1:references/troubleshooting.md\n\n# Troubleshooting\n\nRead this when a command fails unexpectedly or behaves differently than the workflow predicts.\n\n## Chat / Thread\n\n- If `aomi chat` returns `(no response)`, wait briefly and run `aomi thread status`.\n- If `aomi thread status` shows the thread is gone, the local pointer may be stale — retry with `--new-session`.\n\n## Signing\n\n- If AA signing fails, the CLI tries the alternative AA mode automatically. If both modes fail and `--aa` was not set, it can try EOA. Read the console output before retrying manually.\n- If AA fails with a credential error, stop and ask the user to check their provider configuration on their side. Do not try to configure it from the skill.\n- If a transaction fails on-chain, check the RPC URL, balance, and chain.\n- If the signer address differs from the stored thread public key, the CLI updates the thread to the signer address and continues — this is expected, not an error.\n\n## RPC\n\n- `401`, `429`, and generic parameter errors during `aomi tx sign` are usually RPC problems, not transaction-construction problems. Pass a reliable chain-matching public RPC via `--rpc-url`.\n- If one or two public RPCs fail for the same chain, stop rotating through random endpoints and ask the user to supply a proper RPC URL for that chain themselves. Do not paste provider-keyed URLs into chat.\n- The pending transaction already contains its target chain. If the default RPC is wrong, override with `--rpc-url` for the matching chain.\n\n## Simulation\n\n- If `aomi tx simulate` fails with a revert, read the revert reason. Common causes: expired quote or timestamp (re-chat to get a fresh quote), insufficient token balance, missing prior approval. Do not sign transactions that failed simulation without understanding why.\n- If `aomi tx simulate` returns `stateful: false`, the backend could not fork the chain — simulation ran each tx independently via `eth_call`, so state-dependent flows (approve → swap) may show false negatives. Retry, or check that the backend's Anvil instance is running before signing.\n\n## Cross-chain\n\n- When the chat/thread chain (`--chain`) differs from the chain the agent eventually queues a tx for, that's normal — the user may have asked for a cross-chain operation. Sign with `--rpc-url` matching the *queued tx*'s chain, not the thread chain.\n\n## Invocation\n\n- If `aomi: command not found`, the user does not have the global install. Substitute `npx @aomi-labs/client@latest` for `aomi` in every command and retry.\n- If `aomi --version` reports a version older than `0.1.42`, advise `npm install -g @aomi-labs/client@latest` (or use `npx @aomi-labs/client@latest …` for one-shot calls) before continuing — older versions may lack flags or Solana/account-auth behavior this skill assumes.\n\n## Quirks observed in current CLI/source\n\nThese are not bugs the skill should try to fix — they are CLI behaviors to recognize and route around.\n\n- **`[session] Backend user_state mismatch (non-fatal)` log spam** appears between the prompt and the agent response. These lines are large JSON dumps that look alarming. Ignore them — they are not errors. Look past them for the actual agent response and the `⚡ Wallet request queued: tx-N` line.\n- **The active thread pointer can disappear between shell invocations.** If `aomi tx list` returns `No active thread` after a successful chat, run `aomi thread list` to find the thread id (look for `topic` matching what you just asked the agent), then `aomi thread resume > /dev/null && aomi tx list` in the **same** shell call.\n- **Stale failed-simulation txs accumulate.** When the agent retries (e.g. Across with expired deadlines), the failed prior attempts stay visible in `aomi tx list`. Match against the `batch_status` metadata: only sign txs whose status reads `Batch [...] passed`. Skip ones tagged `failed at step N: 0x...`.\n- **Agent self-heals expired deadlines.** For deadline-bearing routes (Across, Khalani fillers), if simulation reports an expiry, the agent will rebuild the request automatically with fresh deadlines. Do not re-prompt — just check `aomi tx list` for the latest passing batch.\n- **`BYOK key set for anthropic: sk-ant-...` echoes the first ~7 characters of the provider key.** This is by design (provider identification, not authentication). Do not try to scrub it from output — it is not a credential leak.\n- **Public backend app/model introspection can return 404.** Treat `aomi app list` and `aomi model list` as convenience commands. A 404 there does not prove chat, tx, simulation, or signing is broken.\n- **Solana instruction-only pending requests are not fully CLI-signable yet.** The current TypeScript signer reconstructs pending Solana signables when the backend/local pending record includes `unsigned_tx` / `unsignedTx`. Canonical `svm_ixs` without an unsigned tx may be filtered out.\n\n## AA and native gas\n\nIf `aomi tx sign` returns `insufficient funds for transfer` from viem, the active path needs native gas from the EOA. See `references/account-abstraction.md#sponsorship-in-practice-verified-against-v0142-source-behavior` for the expected behavior and recovery options. Short version: the EOA needs a small amount of native gas on the destination chain, or the user needs to configure a real BYOK 4337 provider with a sponsorship policy. Do not retry with `--eoa` blindly — that path also requires gas.\n\nFile v0.10.1:references/workflows.md\n\n# Workflows\n\nEnd-to-end operational procedures. Use the CLI as one-shot commands — each `aomi` call starts, runs, and exits. Conversation history lives on the backend; local thread data lives under `AOMI_STATE_DIR` or `~/.aomi`.\n\n## Quick Start\n\nRun once at the start of a thread:\n\n```bash\naomi --version 2>/dev/null || npx @aomi-labs/client@latest --version\naomi chat \"hello\" --new-session\naomi thread status 2>/dev/null || echo \"no thread\"\n```\n\nExpected: `aomi --version` prints `0.1.42` or newer. If older, run `npm install -g @aomi-labs/client@latest` or use `npx @aomi-labs/client@latest`.\n\n## Default Workflow\n\n1. Chat with the agent.\n2. If the agent asks whether to proceed, reply with a short confirmation in the same thread.\n3. Review pending requests with `aomi tx list`.\n4. For multi-step batches, run `aomi tx simulate tx-1 tx-2 …` before signing.\n5. Sign with `aomi tx sign `.\n6. Verify with `aomi tx list`, `aomi thread log`, or `aomi thread status`.\n\nThe CLI output is the source of truth. If you do not see `Wallet request queued: tx-N`, there is nothing to sign yet. For a scriptable wrapper, see [../templates/aomi-workflow.sh](../templates/aomi-workflow.sh).\n\n## Read-Only Requests\n\nUse when the user does not need signing:\n\n```bash\naomi chat \"\" --new-session\naomi chat \"\" --verbose\naomi tx list\naomi thread log\naomi thread status\naomi --version\naomi app list\naomi app current\naomi chain list\naomi thread list\naomi thread resume \n```\n\nFor chain-specific requests, prefer `--chain ` on the command itself. Use `AOMI_CHAIN_ID=` only when multiple consecutive commands should stay on the same chain.\n\n## Building Wallet Requests\n\nGive the agent the task plus wallet address and chain on the first turn:\n\n```bash\naomi chat \"swap 1 ETH for USDC\" --new-session --public-key 0xUserAddress --chain 1\naomi chat \"swap 1 POL for USDC on Polygon\" --app khalani --chain 137\n```\n\nA chat response does not always queue a transaction immediately — the agent may return a quote or route first and ask whether to proceed. Keep the same thread and reply with a short confirmation message. Only move to `aomi tx sign` after a wallet request is queued. Confirm with `aomi tx list`.\n\nQueued request:\n\n```\n⚡ Wallet request queued: tx-1\n to: 0x...\n value: 1000000000000000000\n chain: 1\nRun `aomi tx list` to see pending transactions, `aomi tx sign ` to sign.\n```\n\nFor per-app first-turn examples (Khalani, 0x, Polymarket, Binance, Neynar), see [apps.md](apps.md#usage-examples).\n\n## Batch Simulation\n\nUse `aomi tx simulate` to dry-run pending transactions before signing. Simulation runs each tx sequentially on a forked chain so state-dependent flows (approve → swap) are validated as a batch.\n\n```bash\naomi tx simulate tx-1\naomi tx simulate tx-1 tx-2\n```\n\nResponse:\n\n```\nSimulation result:\n Batch success: true\n Stateful: true\n Total gas: 147821\n\n Step 1 — approve USDC\n success: true\n gas_used: 46000\n Step 2 — swap on Uniswap\n success: true\n gas_used: 101821\n```\n\n**Always simulate multi-step flows** before signing. **Optional** for single independent txs (simple ETH transfer, standalone swap with no prior approval). **Skip** for read-only operations or when `aomi tx list` shows nothing. If simulation fails at step N, read the revert reason before retrying — do not blindly re-sign.\n\nFull simulation-and-signing walkthrough on a multi-step batch in [examples.md](examples.md#1-approve--swap).\n\n## Signing Policy\n\n- Default: `aomi tx sign [ ...]` — AA-first; uses configured BYOK provider or backend proxy where available, then can fall back to EOA unless `--aa` is explicit.\n- `--eoa` skips AA entirely.\n- `--aa`, `--aa-provider`, or `--aa-mode` force AA mode; incompatible with `--eoa`.\n- **Mode fallback**: when AA is used, the CLI tries the preferred mode (current default 7702 on displayed AA chains). If it fails, tries the alternative. If both fail and `--aa` was not set, it can try EOA; with `--aa`, it returns an AA-only error.\n\n```bash\naomi tx sign tx-1 # default: zero-config AA\naomi tx sign tx-1 --eoa # force EOA\naomi tx sign tx-1 --aa --aa-provider pimlico --aa-mode 4337\naomi tx sign tx-1 --cluster devnet # Solana cluster override\n```\n\nSigning rules that always apply:\n\n- `aomi tx sign` handles both transaction requests and EIP-712 typed-data signatures. Batch signing is supported for transactions only, not EIP-712.\n- Solana sign-only requests are supported when the pending request includes an unsigned transaction payload; instruction-only `svm_ixs` requests may not be CLI-signable yet.\n- A single `--rpc-url` override cannot be used for a mixed-chain multi-sign request.\n- The pending transaction already contains its target chain — pass `--rpc-url` matching that chain if the default RPC is wrong.\n\nIf signing fails because credentials are missing, stop and ask the user to configure them — do not try to set them from the skill.\n\n## Secret Ingestion\n\nTwo paths, depending on who is driving.\n\n**Inspect** (skill-driven, always safe):\n\n```bash\naomi secret list # handle names only, never raw values\naomi secret clear # drop all configured secrets\n```\n\n**Add** (user-driven): when the user explicitly asks to configure a credential and supplies the value in this turn:\n\n```bash\naomi secret add NAME= [NAME= ...]\n```\n\nBefore doing so, warn about the trust boundary (below) so the user can abort. Do not initiate ingestion. Do not paraphrase the user's request into a new credential. Do not repeat the value back — confirm with the handle name only.\n\n**Trust boundary.** `aomi secret add` transmits each credential value to the aomi backend and stores a handle locally. The backend — not just the user's machine — becomes a trust boundary. If the user prefers the value to stay entirely local, advise them to export it in their shell environment and let the CLI read it from there.\n\n## Thread And Storage\n\nA thread is split across two stores: the **backend** holds the conversation transcript and tool calls; the **local disk** (`$AOMI_STATE_DIR` or `~/.aomi/`) holds lookup keys, pending/signed tx state, and secret handle names. `aomi tx list` reads local; `aomi thread log` reads backend.\n\n```bash\naomi thread list\naomi thread resume \naomi thread delete \naomi thread close\n```\n\nFull layout (`~/.aomi/sessions/session-N.json`, `active-session.txt`), the local-vs-backend split, lifecycle rules for `--new-session` vs `resume`, and cleanup hygiene in [thread.md](thread.md).\n\nFile v0.10.1:SECURITY.md\n\n# aomi-transact Security Posture\n\nThis document maps the `aomi-transact` skill against [OWASP Agentic Skills Top 10 (v1.0, March 2026)](https://owasp.org/www-project-agentic-skills-top-10/) and records the controls in place for each risk. Reviewers can audit the per-control claims against the live SKILL.md frontmatter, the references, and the captured scanner reports under [`.scanner-reports/`](../.scanner-reports/).\n\n**Last reviewed:** 2026-07-05 against `@aomi-labs/client` v0.1.42 and local TypeScript CLI source.\n\n## Threat model\n\n`aomi-transact` is a procedure for an AI agent to drive the [`@aomi-labs/client`](https://www.npmjs.com/package/@aomi-labs/client) CLI — composing natural-language intents into queued wallet requests, simulating them on a forked chain, and signing them via account-abstraction-first execution. The skill itself does not custody funds, sign without explicit user request, or write outside `~/.aomi/`. The CLI it drives, however, **does** execute on-chain transactions, so the skill is correctly classified as **risk_tier: L2** (elevated) under the OWASP universal manifest schema.\n\n## Controls by AST risk\n\n### AST01 — Malicious Skills\n\n**Risk**: A skill is published that hides an exfiltration / drain payload behind benign-looking documentation.\n\n**Controls in place:**\n\n- The skill is published from [`aomi-labs/skills`](https://github.com/aomi-labs/skills) under MIT license; provenance is verifiable via `git log` and the GitHub repo signing keys.\n- The skill body (`SKILL.md` plus `references/`, `templates/`, `agents/`) contains no executable code beyond the `templates/aomi-workflow.sh` shell wrapper and shell snippets in documentation. The wrapper is human-auditable (~263 lines, no minification, no eval/exec, no curl-pipe-bash).\n- All shell snippets in `references/*.md` are documentation, not executed by the skill itself. The skill's actual operational scope is constrained to `aomi ` and `npx @aomi-labs/client@latest ` per the `permissions.shell` declaration.\n- No network calls outside the declared `permissions.network.allow` list.\n- **Open**: signed releases (sigstore / `gh attestation`) are not yet wired up. Tracked separately.\n\n### AST02 — Skill Injection / Tampering\n\n**Risk**: A modified skill is loaded from an untrusted source; tampering goes undetected.\n\n**Controls in place:**\n\n- Canonical source is the `aomi-labs/skills` GitHub repo. Tags are not yet signed; users who care about integrity should pin to a commit SHA and verify against the upstream repo.\n- The `permissions.files.deny_write` list (`SOUL.md`, `MEMORY.md`, `AGENTS.md`) blocks the skill from rewriting agent identity files, which is the canonical injection target.\n- **Open**: `gh skill` repo / ref / tree-SHA frontmatter pre-population is on the release checklist (see `docs/todo` item #8) but not yet landed.\n\n### AST03 — Over-Privileged Skills\n\n**Risk**: A skill declares broad permissions (`shell: true`, `network: true`) it doesn't actually need; an injection prompt later abuses the privilege.\n\n**Controls in place:**\n\n- A complete OWASP-format `permissions:` manifest is declared in `SKILL.md` frontmatter:\n - `files.read`: `~/.aomi/` only.\n - `files.write`: `~/.aomi/` only. The skill never writes files directly; the underlying CLI manages its own state dir.\n - `files.deny_write`: identity files (`SOUL.md`, `MEMORY.md`, `AGENTS.md`).\n - `network.allow`: `api.aomi.dev` only. `network.deny: \"*\"`.\n - `shell`: array form, two argv prefixes (`aomi`, `npx @aomi-labs/client@latest`). Spec example uses boolean; the array form is a least-privilege extension consistent with AST03 intent.\n - `tools: []` — no MCP / external tool surface.\n- Claude Code's `allowed-tools` field is set to `Bash, Grep` (broad) so the skill can render diagnostic snippets in documentation; the OWASP manifest provides the actual operational lockdown as defense-in-depth.\n\n**Verification**:\n\n- [`Cisco AI Defense skill-scanner`](https://github.com/cisco-ai-defense/skill-scanner) v0.x — **0 findings**, `Status: SAFE`. Report: `.scanner-reports/cisco-ai-defense.md`.\n\n### AST04 — Skill Confused Deputy\n\n**Risk**: A skill's identity is reused for a privileged action the user didn't authorize.\n\n**Controls in place:**\n\n- The skill is **read-only by default**. Chat, simulation, thread inspection, and app/model/chain introspection do not move funds. Signing is a separate, explicit step the user must request (see the \"Hard Rules\" section in `SKILL.md`).\n- `aomi tx sign` is only invoked after `aomi tx list` shows a pending `tx-N` the user asked for.\n- Drain-vector annotations on simulation (recipient ≠ msg.sender, etc.) cannot be bypassed by reformulating the prompt — the skill explicitly forbids this in the security section. See [`references/drain-vectors.md`](references/drain-vectors.md) for the full table.\n\n### AST05 — Skill Side-Effects / Hidden Actions\n\n**Risk**: A skill performs persistent state changes that survive the session without the user's knowledge.\n\n**Controls in place:**\n\n- Side-effect-producing commands (`aomi wallet dev-key `, `aomi wallet set-mode
`, `aomi secret add NAME=value`, `aomi config set-backend`) are **only** run when the user explicitly asks for that specific setup in the current turn and supplies the value themselves. The skill never runs them on its own initiative.\n- Before running a credential-setup command the user asked for, the skill confirms what will be persisted and where (local CLI state vs. the aomi backend) so the user can abort.\n- Read-side variants (`aomi wallet ls`, `aomi account`, `aomi config current`, `aomi secret list`) are skill-driven and safe — they expose handle names only, never raw values.\n\n### AST06 — Insecure Skill Communication\n\n**Risk**: A skill exfiltrates data through a side channel (logging, telemetry, off-domain HTTP).\n\n**Controls in place:**\n\n- The skill makes no direct network calls. The CLI it drives talks to `api.aomi.dev` (the declared backend) and to user-supplied RPC endpoints passed through `--rpc-url` at sign time.\n- The skill **never echoes a credential value back to the user** after a setup command completes. Confirmation is by handle name or derived address only (see \"Hard Rules\" #2 in `SKILL.md`).\n- `aomi secret add` transmits the credential value to the aomi backend; the skill surfaces this trust-boundary explicitly to the user before running the command (see `references/thread.md` and the SKILL.md \"Secret Ingestion\" subsection).\n\n### AST07 — Inadequate Logging / Auditability\n\n**Risk**: A skill takes actions that cannot be reconstructed after the fact.\n\n**Controls in place:**\n\n- The CLI maintains a thread log per thread (`aomi thread log`, `aomi thread events`) that replays the full conversation, all tool calls, and all system events from the backend.\n- Local thread JSON files (`~/.aomi/sessions/session-N.json`) mirror pending and signed transaction state with full calldata, gas estimates, and hashes — inspectable via `cat` + `jq` without a network round-trip.\n- The skill's own actions are limited to invoking `aomi `; every invocation is observable in the user's shell history.\n\n### AST08 — Skill Supply-Chain Attacks\n\n**Risk**: A dependency the skill relies on is compromised; the skill picks up the compromise transitively.\n\n**Controls in place:**\n\n- The skill itself has **no runtime dependencies** beyond the `aomi` / `npx` binaries and an outbound HTTP path to `api.aomi.dev`.\n- The CLI (`@aomi-labs/client`) is published to npm by `aomi-labs`. The skill currently tracks the latest package and warns if the detected version is older than v0.1.42 because the command surface is still moving.\n- The companion `templates/aomi-workflow.sh` shell wrapper depends only on POSIX shell + `jq`, both checked at startup.\n- **Open**: npm package signing / sigstore attestation is not yet wired up.\n\n### AST09 — Insufficient User Consent\n\n**Risk**: A skill performs actions the user has not explicitly authorized.\n\n**Controls in place:**\n\n- Every state-changing CLI invocation requires explicit user consent in the same turn:\n - `aomi tx sign` — only after `aomi tx list` shows a pending `tx-N` the user requested.\n - `aomi wallet dev-key` / `aomi wallet set-mode` / `aomi secret add` / `aomi config set-backend` — only when the user has explicitly asked for that setup and supplied the value.\n - Multi-step batches (`approve` + `swap`) are reviewed by the user via `aomi tx simulate` before signing.\n- Drain-vector annotations cannot be bypassed; the skill surfaces blocks rather than reformulating prompts.\n\n### AST10 — Cross-Platform Reuse\n\n**Risk**: A skill that's safe on one host (e.g. Claude Code) becomes unsafe when loaded on a different host (Codex, Cursor, OpenClaw) due to differing tool-permission semantics.\n\n**Controls in place:**\n\n- The OWASP `permissions:` manifest is declarative metadata that all OWASP-aware scanners and registries can read regardless of host. The Claude Code-specific `allowed-tools` field coexists as a sibling.\n- An `agents/openai.yaml` is provided for Codex/OpenAI-host metadata (display name, default prompt, invocation policy).\n- **Open**: end-to-end install verification across Claude Code + Codex + at least one community installer is on the release checklist (#9, #20). The skill is shaped for cross-platform reuse but has not yet been load-tested on every host.\n\n## Captured scanner reports\n\nAll reports under [`.scanner-reports/`](../.scanner-reports/). Re-run any scanner with the local commands documented in [`docs/todo`](../docs/todo).\n\n| Scanner | Status | Findings | Report |\n|---------|--------|----------|--------|\n| Cisco AI Defense skill-scanner | **PASS** | 0 critical / 0 high / 0 medium / 0 low | [`cisco-ai-defense.md`](../.scanner-reports/cisco-ai-defense.md) |\n| pors/skill-audit | **PASS** | 0 errors / 4 warns (documentation regex matches) | [`pors-skill-audit.txt`](../.scanner-reports/pors-skill-audit.txt) |\n| NMitchem/SkillScan | **PASS** | Risk 2.0/10 (threshold 6.0), 1 HIGH = upstream regex bug | [`skillscan.txt`](../.scanner-reports/skillscan.txt) |\n| Snyk agent-scan | **PASS (advisory)** | 4 HIGH characterizations of risk class — see analysis below | [`snyk-agent-scan.txt`](../.scanner-reports/snyk-agent-scan.txt), [`snyk-agent-scan.json`](../.scanner-reports/snyk-agent-scan.json) |\n\n**Notes on findings**:\n\n- The 4 pors WARN findings match documentation patterns (`access sensitive data`, `delete...` operations) that appear in `references/thread.md` because the docs explain those CLI commands. They are documentation regex matches, not actual destructive code paths.\n- The SkillScan HIGH finding (`MCP_001: MCP server launched via npx without version pinning`) is acknowledged. This skill intentionally uses `npx @aomi-labs/client@latest` so agent guidance tracks the current CLI contract; for locked-down environments, install `@aomi-labs/client` globally from a pinned version or npm lockfile and use the `aomi` binary path instead.\n- The 4 Snyk HIGH findings (W007, W009, W011, W012) are taxonomic characterizations of the skill's intentional risk surface, not bugs. Each is acknowledged below with the in-place mitigation. Snyk's own exit code is 0 (advisory output), and the skill's `risk_tier: L2` declaration in the OWASP manifest already states this risk class up front.\n\n### Snyk Agent Scan (W-codes) — finding-by-finding analysis\n\nThe Snyk Agent Scan rule pack characterizes a skill's risk surface, not just bugs. For a transaction-signing AI skill that uses third-party data sources to compose calldata, the following findings are **structural** — they describe what the skill does on purpose, with mitigations in place. Reviewers should evaluate them against the OWASP AST controls in this document.\n\n| Code | Title | Status | Mitigation in place |\n|------|-------|--------|---------------------|\n| **W007** | Insecure credential handling | Acknowledged — by design | Skill frontmatter description explicitly forbids the LLM from fabricating, guessing, echoing, or logging credential values. `aomi secret add NAME=` and `aomi wallet dev-key ` use placeholder syntax in all docs; the user supplies the real value. The \"Hard Rules\" and \"Security Model\" sections of SKILL.md, plus AST05 (Side-Effects) and AST06 (Insecure Communication) above, codify the no-unsolicited-setup posture. |\n| **W009** | Direct money access | Acknowledged — by design | The skill is explicitly classified `risk_tier: L2` in the OWASP manifest because it signs and broadcasts on-chain transactions. AST04 (Confused Deputy) and AST09 (Insufficient User Consent) above codify the \"read-only by default, signing requires explicit user request\" posture. `aomi tx sign` is only invoked after `aomi tx list` shows a pending `tx-N` the user asked for, and multi-step batches go through `aomi tx simulate` on a forked chain first. |\n| **W011** | Third-party content exposure | Acknowledged — by design | The agent uses 25+ apps (DefiLlama, 1inch, Khalani, Brave Search, X, Neynar, etc.) to fetch quotes, routes, and read-only data — that is the skill's purpose. Fund-moving calldata that the third-party content influences is gated by `aomi tx simulate` (drain-vector annotations block `recipient != msg.sender`) and an explicit user `aomi tx sign` step. AST04 above and [`references/drain-vectors.md`](references/drain-vectors.md) document the per-protocol guard rules. |\n| **W012** | Potentially malicious external URL (npx) | Acknowledged — documented | `npx @aomi-labs/client@latest` is the on-demand fallback used to follow the live CLI. Users are explicitly directed to install globally with `npm install -g @aomi-labs/client@latest` for repeated use, or pin a version in their own environment. The OWASP `permissions.shell` array constrains the skill's actual operational scope to `aomi` and `npx @aomi-labs/client@latest` only. AST08 (Supply-Chain Attacks) above acknowledges that npm package signing / sigstore attestation is open. |\n\nThese four findings are inherent to **any** AI agent skill that signs on-chain transactions and reads third-party data. They cannot be eliminated without removing the skill's core capability. The combined posture — explicit risk_tier, OWASP permission manifest, drain-vector guards, simulate-before-sign, no-unsolicited-credential-setup — is what makes the skill safe to use despite these characterizations.\n\n## Reporting issues\n\nSecurity issues should be reported privately. See the top-level [`SECURITY.md`](../SECURITY.md) in `aomi-labs/skills` for the disclosure process, or open a private security advisory on the GitHub repo.\n\nArchive v0.10.0: 15 files, 49079 bytes\n\nFiles: agents/openai.yaml (371b), references/account-abstraction.md (7077b), references/apps.md (16488b), references/commands.md (5644b), references/drain-vectors.md (4853b), references/examples.md (26186b), references/gotchas.md (5932b), references/session.md (6062b), references/troubleshooting.md (5323b), references/workflows.md (6330b), SECURITY.md (14831b), skill-card.md (3258b), SKILL.md (7161b), templates/aomi-workflow.sh (8164b), _meta.json (133b)\n\nFile v0.10.0:SKILL.md\n\n---\nname: aomi-transact\ndescription: >\n Build natural-language crypto agents, web3 assistants, trading bots, blockchain MCPs,\n or Claude Code / Cursor / Codex / Gemini plugins that read and write EVM chain state.\n Aomi turns prompts (\"swap 1 ETH for USDC\", \"open a 3x GMX long\", \"bet $100 on\n Polymarket\") into wallet-signed transactions on Ethereum, Base, Arbitrum, Optimism,\n Polygon, Linea — non-custodial, fork-simulated. Trigger when the user wants a\n crypto/DeFi agent, AI trading/wallet assistant, EVM protocol wrapped as MCP tools, or\n on-chain execution against Uniswap / Aave / Lido / Morpho / Across / 1inch / GMX /\n Hyperliquid / Polymarket / Binance / OKX. Low-level primitives encode_and_call,\n simulate_batch, stage_tx, commit_tx, commit_eip712 plus multi-step\n swap-approve-execute routing. 40+ tuned protocol apps. MUST NOT fabricate or echo\n credentials; values reach the CLI only when the user explicitly supplied them.\ncompatibility: \"Requires @aomi-labs/client v0.1.30 or newer. Install globally (`npm install -g @aomi-labs/client`) or run on demand (`npx @aomi-labs/client@0.1.30 `).\"\nlicense: MIT\nversion: \"0.10\"\nauthor: aomi-labs\ncompatible-with: claude-code\ntags: [crypto, defi, web3, evm, ethereum, wallet, account-abstraction, trading, mcp, agent]\nallowed-tools: Bash, Grep\nmetadata:\n author: aomi-labs\n version: \"0.10\"\n repository: aomi-labs/skills\n homepage: https://github.com/aomi-labs/skills/tree/main/aomi-transact\npermissions:\n files:\n read: [~/.aomi/]\n write: [~/.aomi/]\n deny_write: [SOUL.md, MEMORY.md, AGENTS.md]\n network:\n allow: [api.aomi.dev]\n deny: \"*\"\n shell:\n - aomi\n - npx @aomi-labs/client@0.1.30\n tools: []\nrisk_tier: L2\nrequires:\n binaries: [aomi, npx]\n---\n\n# Aomi Transact\n\n## Overview\n\nAomi Transact drives the `aomi` CLI to build natural-language crypto agents and web3 assistants on EVM blockchains. It composes calldata, fork-simulates transactions as a batch, and stages wallet requests for explicit user signing — non-custodial throughout. Supported networks: Ethereum, Base, Arbitrum, Optimism, Polygon, Linea. 40+ integrated protocol apps (Uniswap, Aave, Lido, GMX, Polymarket, and more). For deep references, see [commands.md](references/commands.md), [workflows.md](references/workflows.md), [gotchas.md](references/gotchas.md), [account-abstraction.md](references/account-abstraction.md), [apps.md](references/apps.md), [examples.md](references/examples.md), [session.md](references/session.md), [drain-vectors.md](references/drain-vectors.md), [troubleshooting.md](references/troubleshooting.md).\n\n## Prerequisites\n\n- Node.js 18+ with npm or npx\n- `@aomi-labs/client` v0.1.30 or newer: `npm install -g @aomi-labs/client`\n- An EVM-compatible wallet with a signing key (EOA or AA-capable)\n- Optional: Alchemy or Pimlico API key for account-abstraction gas sponsorship\n\n## Instructions\n\n1. Detect or install the CLI: `aomi --version 2>/dev/null || npx @aomi-labs/client@0.1.30 --version`\n2. Start a new session: `aomi --prompt \"\" --new-session`\n3. Inspect queue: `aomi tx list`\n4. For multi-step flows, simulate first: `aomi tx simulate tx-1 tx-2`\n5. Sign: `aomi tx sign tx-1`\n6. Verify: `aomi session status`\n\nFor the full procedure (read-only requests, building wallet requests, signing policy, batch simulation, secret ingestion), see [workflows.md](references/workflows.md).\n\n## Examples\n\n```bash\naomi --prompt \"what is the price of ETH?\" --new-session\naomi chat \"swap 1 ETH for USDC\" --new-session --public-key 0xYourAddress --chain 1\naomi tx list && aomi tx simulate tx-1 tx-2 && aomi tx sign tx-1 tx-2\naomi chat \"stake 0.5 ETH on Lido\" --app lido --chain 1 --new-session\n```\n\nFour end-to-end walkthroughs (approve+swap, lending, bridging, staking) in [examples.md](references/examples.md). Per-app first-turn examples (Khalani, 0x, Polymarket, Binance, Neynar) in [apps.md](references/apps.md#usage-examples).\n\n## Output\n\n- `aomi chat`: agent response or `⚡ Wallet request queued: tx-N`\n- `aomi tx list`: table of pending/signed tx ids with `batch_status`\n- `aomi tx simulate`: per-step success/failure, revert reason, gas usage\n- `aomi tx sign`: transaction hash and on-chain confirmation\n\n## Error Handling\n\n| Error | Cause | Solution |\n|-------|-------|----------|\n| `insufficient funds for transfer` | EOA has no native gas | Fund EOA or configure AA sponsorship |\n| `AA provider not configured` | No Alchemy/Pimlico key | Use `--eoa` or `aomi secret add ALCHEMY_KEY=` |\n| `stateful: false` in simulation | Wrong batch order | Reorder tx ids to match execution dependency |\n| `RPC 401`/`429` | Rate-limited or missing key | Set `--rpc-url` to authenticated endpoint |\n| No tx queued after chat | Agent returned quote first | Run `aomi tx list`; send a confirmation reply |\n| Orphaned `tx-N` in list | Previous simulation failed | Only sign txs with `batch_status: passed` |\n\nFull troubleshooting in [troubleshooting.md](references/troubleshooting.md).\n\n## Safety Justification\n\nThis skill is `risk_tier: L2` because it can sign and broadcast on-chain transactions. The permissions manifest enforces least privilege:\n\n- **Shell allowlist** scopes execution to `aomi` and `npx @aomi-labs/client@0.1.30` only — no arbitrary subprocesses.\n- **Network allowlist** restricts outbound traffic to `api.aomi.dev`. User-supplied `--rpc-url` endpoints are resolved by the CLI itself; operators must review them before allowing signing.\n- **File scope** is read+write to `~/.aomi/` only; identity files (`SOUL.md`, `MEMORY.md`, `AGENTS.md`) are deny-listed against writes per OWASP AST03 mitigation #3.\n- **No blind signing.** Multi-step flows go through `aomi tx simulate` on a forked chain before `aomi tx sign`. Drain-vector calldata fields (`recipient`, `onBehalfOf`, `mintRecipient`, `_to`) are blocked at simulation time when they do not equal `msg.sender` — see [drain-vectors.md](references/drain-vectors.md).\n- **Opaque credentials.** The skill never fabricates, derives, or echoes credential values; setup commands run only when the user explicitly asks and supplies the value in this turn. Full rules in [gotchas.md → Hard Rules](references/gotchas.md#hard-rules).\n\n## When to Use\n\n- The user wants to chat with the Aomi agent from the terminal.\n- The user wants balances, prices, routes, quotes, or transaction status.\n- The user wants to build, simulate, confirm, sign, or broadcast wallet requests.\n- The user wants to inspect or switch apps, models, chains, or sessions.\n- The user wants to inspect or change Account Abstraction settings.\n- The user wants to build a new app from an API spec or SDK — use the companion skill **aomi-build**.\n\n## Command Surface\n\n```\naomi --prompt \"\" Send one prompt and exit\naomi chat Send a message\naomi tx list|simulate|sign\naomi session list|new|resume|delete|status|log|events|close\naomi model list|current|set\naomi app list|current\naomi chain list|current|set\naomi wallet current|set\naomi config current|set-backend\naomi secret list|clear|add\n```\n\nFull command reference, flags, and env vars in [commands.md](references/commands.md).\n\nFile v0.10.0:_meta.json\n\n{\n \"ownerId\": \"kn7axfgphsdj10cpkqw6n840nh86837c\",\n \"slug\": \"aomi-transact\",\n \"version\": \"0.10.0\",\n \"publishedAt\": 1778929241498\n}\n\nFile v0.10.0:references/account-abstraction.md\n\n# Account Abstraction Reference\n\nRead this when:\n\n- The user asks about AA modes, sponsorship, or chain defaults.\n- `aomi tx sign` returns an AA error and you need to pick a flag.\n- The user explicitly requests `4337` or `7702`.\n\n## Execution Model\n\nThe CLI uses **auto-detect** by default and always signs via AA unless `--eoa` is passed:\n\n| User-side provider configured? | Flag | Result |\n|---|---|---|\n| Pimlico configured | `--aa-provider pimlico` | Pimlico BYOK (user-side credential) |\n| Alchemy configured | (none) | Alchemy BYOK (user-side credential) |\n| Nothing configured | (none) | **Alchemy proxy via the aomi backend — zero-config AA** |\n| Any | `--aa-provider`/`--aa-mode` | AA with explicit settings |\n| Any | `--eoa` | Direct EOA, skip AA |\n\nThere is **no silent EOA fallback**. If AA is selected and both AA modes fail, the CLI returns a hard error suggesting `--eoa`. The zero-config proxy path means the user does not need any provider credential of their own for AA to work.\n\n## Mode Fallback\n\nWhen using AA, the CLI tries modes in order:\n\n1. Try preferred mode (default: 7702 for Ethereum, 4337 for L2s).\n2. If preferred mode fails, try the alternative mode (7702 ↔ 4337).\n3. If both modes fail, return error with suggestion: use `--eoa` to sign without AA.\n\n## AA Configuration\n\nAA is configured per-invocation via flags or by credentials the user has configured on their side. There is no persistent AA config file on the skill's side.\n\nPriority chain for AA resolution: **flag > user-side credential > backend zero-config default**.\n\n## AA Providers\n\n| Provider | Flag | Notes |\n| -------- | ----------------------- | -------------------------------- |\n| Alchemy | `--aa-provider alchemy` | 4337 (sponsored via gas policy), 7702 (EOA pays gas) |\n| Pimlico | `--aa-provider pimlico` | 4337 (sponsored via dashboard policy) |\n\nProvider selection rules:\n\n- If the user explicitly selects a provider via flag, use it.\n- In auto-detect mode, the CLI picks whichever provider the user has configured on their side — the skill treats that choice as opaque.\n- If no AA provider is configured, auto-detect uses the zero-config path provided by the aomi backend.\n\nThe skill never configures provider credentials itself. If `aomi tx sign` reports missing provider credentials, stop and ask the user to configure them before re-running.\n\n## AA Modes\n\n| Mode | Flag | Meaning | Gas |\n| ------ | ---------------- | -------------------------------- | --- |\n| `4337` | `--aa-mode 4337` | Bundler + paymaster UserOperation via smart account. Gas sponsored by paymaster. | Paymaster pays |\n| `7702` | `--aa-mode 7702` | Native EIP-7702 type-4 transaction with delegation. EOA signs authorization + sends tx to self. | EOA pays |\n\n**7702 requires the signing EOA to have native gas tokens** (ETH, MATIC, etc.). There is no paymaster/sponsorship for 7702. Use 4337 for gasless execution.\n\n## Default Chain Modes\n\n| Chain | ID | Default AA Mode | Supported AA Modes |\n| -------- | ----- | --------------- | ------------------ |\n| Ethereum | 1 | 7702 | 4337, 7702 |\n| Polygon | 137 | 4337 | 4337, 7702 |\n| Arbitrum | 42161 | 4337 | 4337, 7702 |\n| Base | 8453 | 4337 | 4337, 7702 |\n| Optimism | 10 | 4337 | 4337, 7702 |\n\nThese match the live `aomi chain list` output in CLI v0.1.30.\n\n## Sponsorship\n\nSponsorship is available for **4337 mode only**. 7702 does not support sponsorship. Sponsorship policy is configured on the provider's side — the user's provider account decides whether a given UserOperation is sponsored. Once the user has configured their provider, `aomi tx sign` (with the appropriate AA flags if the user wants an explicit provider) will pick up the active policy automatically.\n\n### Sponsorship in practice (verified against v0.1.30)\n\nThe \"zero-config Alchemy proxy\" path is not a guarantee of free gas. Empirically:\n\n- **Ethereum mainnet, default 7702**: works cleanly. Gas is paid out of the EOA's small ETH stash via the 7702 delegation contract (`0x6900...E139`). Verified across approve+swap, swap-back, and approve+bridge batches.\n- **Base, default 4337 with the zero-config proxy**: observed to **not** sponsor in CLI v0.1.30. Even with `--aa --aa-mode 4337` explicit, `aomi tx sign` returned `insufficient funds for transfer` from viem when the EOA had 0 native gas on Base. The call appeared to fall through to a direct EOA `eth_sendTransaction` rather than a sponsored UserOperation.\n\n**Practical rule the skill must follow**: before signing on an L2, confirm the EOA has a small amount of native gas on the destination chain (~0.0005 ETH equivalent is enough). If the user is sending USDC-only to an L2 with no native gas, warn them that signing on that L2 will fail unless they:\n\n1. fund the EOA with a tiny amount of native gas on that chain, **or**\n2. configure a real BYOK AA provider on their side (Alchemy with a Gas Manager policy attached, or Pimlico with a sponsorship policy on the dashboard — the user sets the credential in their own environment) and pass `--aa-provider alchemy|pimlico --aa-mode 4337` on `aomi tx sign`. The exact credential variable names are documented by `aomi --help`; the skill does not hard-code them.\n\nDo not promise the user \"AA will pay for gas on L2s\" without verifying the user's setup. The default proxy path may silently fall through.\n\nWhen the CLI emits a viem `insufficient funds for transfer` error followed by `Use --eoa to sign without account abstraction`, that is the failure signature. Do not re-run with `--eoa` blindly — `--eoa` will also fail if the EOA has 0 gas. Stop and tell the user to fund the destination chain or configure a sponsoring BYOK provider.\n\n## Supported Chains\n\n| Chain | ID | AA available? |\n| ------------- | -------- | ------------- |\n| Ethereum | 1 | Yes (4337, 7702; default 7702) |\n| Polygon | 137 | Yes (4337, 7702; default 4337) |\n| Arbitrum One | 42161 | Yes (4337, 7702; default 4337) |\n| Base | 8453 | Yes (4337, 7702; default 4337) |\n| Optimism | 10 | Yes (4337, 7702; default 4337) |\n| Sepolia | 11155111 | No AA defaults — use `--eoa` |\n| Anvil (local) | 31337 | No AA defaults — local fork; use `--eoa` |\n\nFor Sepolia and Anvil, `aomi tx sign` without `--eoa` may fail. Pass `--eoa` explicitly when signing on these chains.\n\n## RPC Guidance By Chain\n\nUse an RPC that matches the pending transaction's chain:\n\n- Ethereum txs → Ethereum RPC\n- Polygon txs → Polygon RPC\n- Arbitrum txs → Arbitrum RPC\n- Base txs → Base RPC\n- Optimism txs → Optimism RPC\n- Sepolia txs → Sepolia RPC\n\nPractical rule:\n\n- `--chain` affects the wallet/session context for chat and request building.\n- `--rpc-url` affects where `aomi tx sign` estimates and submits the transaction.\n- Treat them as separate controls and keep them aligned with the transaction you are signing.\n\nFile v0.10.0:references/apps.md\n\n# Apps Reference\n\nRead this when:\n\n- The user asks \"what apps are available?\" or names a category (CEX, lending, perps, prediction, social).\n- You need to pick `--app` for a request and want to see the catalog.\n- You need a usage example for a specific app.\n\n## Discovering Apps\n\nThe set of installed apps is dynamic — the catalog below is a snapshot. Always confirm against the live CLI:\n\n```bash\naomi app list # enumerate apps exposed by the backend\naomi app current # show the currently active app\n```\n\nSelect an app for a chat turn with `--app ` or set `AOMI_APP=` for a multi-command shell. When an app needs provider credentials, the aomi CLI reports at runtime what is missing. The user configures those credentials themselves; the skill does not perform that setup unless the user explicitly asks (see SKILL.md \"Secret Ingestion\").\n\n## App Catalog\n\nAll apps share a common base toolset (`send_transaction_to_wallet`, `encode_and_simulate`, `get_account_info`, `get_contract_abi`, etc.). The tools listed below are the app-specific additions. The \"Credentials\" column indicates whether an app needs user-configured credentials at all; the CLI reports the specific names at runtime when something is missing.\n\n| App | Description | App-Specific Tools | Credentials |\n|-----|-------------|-------------------|-------------|\n| `default` | General-purpose on-chain agent with web search | `brave_search` | None |\n| `binance` | Binance CEX — prices, order book, klines | `binance_get_price`, `binance_get_depth`, `binance_get_klines` | Exchange credentials |\n| `bybit` | Bybit CEX — orders, positions, leverage | `brave_search` (no Bybit-specific tools yet) | Exchange credentials |\n| `cow` | CoW Protocol — MEV-protected swaps via batch auctions | `get_cow_swap_quote`, `place_cow_order`, `get_cow_order`, `get_cow_order_status`, `get_cow_user_orders` | None |\n| `defillama` | DefiLlama — TVL, yields, volumes, stablecoins | `get_token_price`, `get_yield_opportunities`, `get_defi_protocols`, `get_chain_tvl`, `get_protocol_detail`, `get_dex_volumes`, `get_fees_overview`, `get_protocol_fees`, `get_stablecoins`, `get_stablecoin_chains`, `get_historical_token_price`, `get_token_price_change`, `get_historical_chain_tvl`, `get_dex_protocol_volume`, `get_stablecoin_history`, `get_yield_pool_history` | None |\n| `dune` | Dune Analytics — execute and fetch SQL queries | `execute_query`, `get_execution_status`, `get_execution_results`, `get_query_results` | Provider token |\n| `dydx` | dYdX perpetuals — markets, orderbook, candles, trades | `dydx_get_markets`, `dydx_get_orderbook`, `dydx_get_candles`, `dydx_get_trades`, `dydx_get_account` | None |\n| `gmx` | GMX perpetuals — markets, positions, orders, prices | `get_gmx_prices`, `get_gmx_signed_prices`, `get_gmx_markets`, `get_gmx_positions`, `get_gmx_orders` | None |\n| `hyperliquid` | Hyperliquid perps — mid prices, orderbook | `get_meta`, `get_all_mids` | None |\n| `kaito` | Kaito — crypto social search, trending, mindshare | `kaito_search`, `kaito_get_trending`, `kaito_get_mindshare` | Provider token |\n| `kalshi` | Kalshi prediction markets via Simmer SDK | `simmer_register`, `simmer_status`, `simmer_briefing` | SDK token |\n| `khalani` | Khalani cross-chain intents — quote, build, submit | `get_khalani_quote`, `build_khalani_order`, `submit_khalani_order`, `get_khalani_order_status`, `get_khalani_orders_by_address` | None |\n| `lifi` | LI.FI aggregator — cross-chain swaps & bridges | `get_lifi_swap_quote`, `place_lifi_order`, `get_lifi_bridge_quote`, `get_lifi_transfer_status`, `get_lifi_chains` | Optional provider token |\n| `manifold` | Manifold prediction markets — search, bet, create | `list_markets`, `get_market`, `get_market_positions`, `search_markets`, `place_bet`, `create_market` | Provider token |\n| `molinar` | Molinar on-chain world — move, explore, chat | `molinar_get_state`, `molinar_look`, `molinar_move`, `molinar_jump`, `molinar_chat`, `molinar_get_chat`, `molinar_get_new_messages`, `molinar_get_players`, `molinar_collect_coins`, `molinar_explore`, `molinar_create_object`, `molinar_customize`, `molinar_ping` | None |\n| `morpho` | Morpho lending — markets, vaults, positions | `get_markets`, `get_vaults`, `get_user_positions` | None |\n| `neynar` | Farcaster social — users, search | `get_user_by_username`, `search_users` | Provider token |\n| `okx` | OKX CEX — tickers, order book, candles | `okx_get_tickers`, `okx_get_order_book`, `okx_get_candles` | Exchange credentials |\n| `oneinch` | 1inch DEX aggregator — quotes, swaps, allowances | `get_oneinch_quote`, `get_oneinch_swap`, `get_oneinch_approve_transaction`, `get_oneinch_allowance`, `get_oneinch_liquidity_sources` | Provider token |\n| `para` | Para — MPC wallet management across EVM, Solana, Cosmos (threshold signing) | (Para wallet tools — confirm with `aomi app current` after selecting) | Provider token |\n| `para-consumer` | Para Consumer — consumer-wallet helper: prices, yield, swap quotes, bridge routes | (Consumer-facing read tools — confirm via runtime) | Provider token |\n| `polymarket` | Polymarket prediction markets — search, trade, CLOB | `search_polymarket`, `get_polymarket_details`, `get_polymarket_trades`, `resolve_polymarket_trade_intent`, `build_polymarket_order_preview` | None |\n| `polymarket-rewards` | Polymarket LP — liquidity provisioning into reward-enrolled markets, ranked by reward APY | (LP scoring + position tools — confirm via runtime) | Provider token |\n| `x` | X/Twitter — users, posts, search, trends | `get_x_user`, `get_x_user_posts`, `search_x`, `get_x_trends`, `get_x_post` | Provider token |\n| `yearn` | Yearn Finance — vault discovery, details | `get_all_vaults`, `get_vault_detail`, `get_blacklisted_vaults` | None |\n| `zerox` | 0x DEX aggregator — swaps, quotes, liquidity | `get_zerox_swap_quote`, `place_zerox_order`, `get_zerox_swap_chains`, `get_zerox_allowance_holder_price`, `get_zerox_liquidity_sources` | Provider token |\n\nWhen a \"Credentials\" entry says *Exchange credentials*, *Provider token*, or *SDK token*, ask the user to configure that app's credentials in their own terminal (or — only if they explicitly ask — run `aomi secret add` with the value they supply).\n\nTo build a new app from an API spec or SDK, use the companion skill **aomi-build**.\n\n## Usage Examples\n\nEach example shows the canonical first chat turn for that category. Follow the standard workflow afterwards: `aomi tx list` → (`aomi tx simulate` for multi-step) → `aomi tx sign`.\n\n### Solver Networks — `khalani`\n\nCross-chain intents executed by a solver network. Khalani returns multiple solver routes per quote; prefer the one that offers a `TRANSFER` deposit method when present.\n\n**Get a quote (read).** Requires `--public-key` even for read-only quotes — without it the agent refuses with \"I need a connected wallet to fetch a Khalani quote.\"\n\n```bash\naomi chat \"quote bridging 50 USDC from Polygon to Base via Khalani. Prefer a TRANSFER deposit method if available.\" \\\n --app khalani --public-key 0xUserAddress --chain 137 --new-session\n```\n\nVerified response shape (CLI v0.1.30, real backend):\n\n```\nRoute Options:\n 1. Hyperstream (Native Filler) ⭐ supports TRANSFER\n Deposit Methods: CONTRACT_CALL, TRANSFER\n Amount Out: 49.950049 USDC\n Duration: ~10s\n Fee: ~0.05 USDC (~0.1%)\n 2. Across\n Deposit Methods: CONTRACT_CALL only\n Amount Out: 49.984261 USDC\n Duration: ~2s\n Gas: 0.032 POL (~$0.02)\n 3. DeBridge\n Deposit Methods: CONTRACT_CALL only\n Amount Out: 49.681958 USDC\n Duration: ~2 min\n Gas: 0.108 POL (~$0.08)\n```\n\n**Build and submit the order (write).** After the user picks a route, confirm in the same session:\n\n```bash\naomi chat \"proceed with Hyperstream using the TRANSFER method\"\naomi tx list # confirm the wallet request was queued\naomi tx sign tx-1 --rpc-url # source-chain RPC must match\n```\n\nNotes:\n\n- Khalani internally exposes Across, DeBridge, and other solvers as routes. There is **no standalone `across` app** in v0.1.30 — to use Across, go through Khalani and pick the Across route at quote time.\n- Single-chain intents work too: `--app khalani --chain 1` for an Ethereum-only request.\n- Inspect open orders: `aomi chat \"list my open Khalani orders\" --app khalani --public-key 0xUserAddress` (read-only, but still wallet-aware).\n- If the agent returns a quote without queueing a wallet request, that's expected — you have to explicitly say \"proceed\".\n\n### Cross-Chain — `zerox`\n\n0x aggregator for swaps and cross-chain liquidity. Good for \"best-price\" single-chain swaps and for swaps spanning chains where 0x has coverage.\n\n```bash\n# Best-price swap on Base\naomi chat \"best price to swap 1 ETH for USDC on Base via 0x\" \\\n --app zerox --chain 8453 --new-session\n\n# Cross-chain swap — let the aggregator pick the route\naomi chat \"swap 100 USDC on Arbitrum for ETH on Optimism via 0x\" \\\n --app zerox\n\n# List supported chains\naomi chat \"which chains does 0x support today?\" --app zerox\n```\n\nNotes:\n\n- `zerox` requires a provider token. If `aomi tx sign` fails because credentials are missing, ask the user to configure their 0x credentials (do not invent or paste them on the user's behalf).\n- For approve-and-swap on a single chain, simulate the batch with `aomi tx simulate tx-1 tx-2` before signing.\n\n### Prediction Markets — `polymarket`\n\nSearch markets, inspect details, build trade previews on Polymarket's CLOB. Polymarket lives on Polygon — pass `--chain 137`.\n\n**Find markets (read).** No wallet required for search:\n\n```bash\naomi chat \"find 3 active Polymarket markets about US politics in 2026; list them with id and current YES price\" \\\n --app polymarket --new-session\n```\n\nVerified response shape (CLI v0.1.30, real backend):\n\n```\n1. Trump out as President before GTA VI?\n Market ID: 540820 YES: 0.52 Liquidity: $19,447 Volume: $622,047\n2. Xi Jinping out before 2027?\n Market ID: 559651 YES: 0.0775 Liquidity: $108,298 Volume: $8,416,434\n3. Will Gavin Newsom win the 2028 Democratic presidential nomination?\n Market ID: 559652 YES: 0.2705 Liquidity: $678,162 Volume: $24,719,477\n```\n\n**Build a buy preview (write-leaning).** Requires `--public-key` and `--chain 137`. Returns an unsigned preview the user must explicitly confirm before any tx is queued:\n\n```bash\naomi chat \"build a YES buy preview for \\$5 on Polymarket market 559651. Just build the preview, do not place it.\" \\\n --app polymarket --public-key 0xUserAddress --chain 137 --new-session\n```\n\nVerified preview shape:\n\n```\nPolymarket Order Preview\n Market: Xi Jinping out before 2027?\n Market ID: 559651\n Side: BUY YES\n Order Type: Market Order (Fill-or-Kill)\n Amount: $5.00 USDC\n Current YES: 0.0775 (~7.75%)\n Estimated Shares: ~64.52\n Wallet: 0xUserAddress\n Network: Polygon (137)\n Status: Preview only — no order placed\n```\n\n**Place the order (write).** Once the user confirms:\n\n```bash\naomi chat \"place the order\"\naomi tx list # confirm a wallet request was queued\naomi tx sign tx-1 # AA-first signing on Polygon (default 4337)\n```\n\nNotes:\n\n- `build_polymarket_order_preview` returns an unsigned order for review. `aomi tx list` shows nothing until the user confirms with \"place the order\" or similar.\n- `resolve_polymarket_trade_intent` maps natural-language trades (\"buy YES on Xi for $5\") to a concrete market+side+size before the preview step. Useful when the user describes a trade casually.\n- `polymarket-rewards` is a separate app (LP-side, not trader-side) — see catalog above.\n\n### CEX — `binance`\n\nRead-only market data from Binance. No on-chain signing involved.\n\n```bash\n# Spot price snapshot\naomi chat \"what is BTCUSDT trading at on Binance?\" \\\n --app binance --new-session\n\n# Top-of-book depth\naomi chat \"show me top 5 levels of the ETHUSDT order book on Binance\" \\\n --app binance\n\n# Recent klines\naomi chat \"1h klines for SOLUSDT for the last 24 hours from Binance\" \\\n --app binance\n```\n\nNotes:\n\n- `binance` needs Exchange credentials. The skill never invents these. If `aomi chat` fails because credentials are missing, ask the user to configure them on their side.\n- This is a data app — no `tx-N` will be queued from these commands. `aomi tx list` is not part of this flow.\n\n### Social — `neynar`\n\nFarcaster user lookup and search via Neynar.\n\n```bash\n# Look up a user\naomi chat \"look up the Farcaster user 'dwr.eth' via Neynar\" \\\n --app neynar --new-session\n\n# Search by handle\naomi chat \"search Farcaster for users matching 'aomi'\" --app neynar\n```\n\nNotes:\n\n- `neynar` requires a provider token. Same rule as the other token-gated apps: ask the user to configure it.\n- Like `binance`, this is a read-only data app — no wallet requests are queued.\n\n### Social — `x`\n\nX/Twitter user lookup, post fetching, and search.\n\n```bash\n# Look up a user\naomi chat \"look up the X user @AnthropicAI - return handle, follower count, and bio\" \\\n --app x --new-session\n\n# Search posts\naomi chat \"search X for posts mentioning 'claude code' from the last week, top 3 with handle and text\" \\\n --app x\n\n# Trending topics\naomi chat \"what's trending on X right now?\" --app x\n```\n\nRead-only data app — no wallet requests are queued. The X app needs a provider token configured on the backend.\n\n> **TODO — not verified end-to-end.** On the live backend at the time of capture, both lookup and search returned \"I don't have access to the X API at the moment due to authentication issues\" — the X provider token was not configured for the test account. The shape of the call is correct; the backend res\n\nArchive v0.5.0: 2 files, 11293 bytes\n\nFiles: SKILL.md (33722b), _meta.json (132b)","readmeExcerpt":"Skill: Transact Owner: ceciliaz030 Summary: Build natural-language crypto agents, web3 assistants, and trading bots that read and write EVM chain state. Aomi turns prompts (\"swap 1 ETH for USDC\", \"open... Tags: ai-agents:0.5.0, blockchain:0.5.0, evm:0.5.0, latest:0.10.1, transactions:0.5.0 Version history: v0.10.1 | 2026-07-10T19:31:03.396Z | auto aomi-transact v0.10.1 - Updated compatibility for @aomi-labs/client v0","codeSnippets":[],"executableExamples":[{"language":"bash","snippet":"aomi chat \"what is the price of ETH?\" --new-session\naomi chat \"swap 1 ETH for USDC\" --new-session --public-key 0xYourAddress --chain 1\naomi tx list && aomi tx simulate tx-1 tx-2 && aomi tx sign tx-1 tx-2\naomi chat \"stake 0.5 ETH on Lido\" --app lido --chain 1 --new-session"},{"language":"text","snippet":"aomi --prompt \"\" Send one prompt and exit\naomi chat Send a message\naomi tx list|simulate|sign\naomi thread list|new|resume|delete|status|log|events|close\naomi model list|current|set\naomi app list|current\naomi chain list|current|set\naomi wallet ls|dev-key|set-mode\naomi login|logout\naomi account\naomi cron ls|show|cancel\naomi config current|set-backend\naomi secret list|clear|add\naomi deploy"},{"language":"bash","snippet":"aomi app list # enumerate apps exposed by the backend\naomi app current # show the currently active app"},{"language":"bash","snippet":"aomi chat \"quote bridging 50 USDC from Polygon to Base via Khalani. Prefer a TRANSFER deposit method if available.\" \\\n --app khalani --public-key 0xUserAddress --chain 137 --new-session"},{"language":"text","snippet":"Route Options:\n 1. Hyperstream (Native Filler) ⭐ supports TRANSFER\n Deposit Methods: CONTRACT_CALL, TRANSFER\n Amount Out: 49.950049 USDC\n Duration: ~10s\n Fee: ~0.05 USDC (~0.1%)\n 2. Across\n Deposit Methods: CONTRACT_CALL only\n Amount Out: 49.984261 USDC\n Duration: ~2s\n Gas: 0.032 POL (~$0.02)\n 3. DeBridge\n Deposit Methods: CONTRACT_CALL only\n Amount Out: 49.681958 USDC\n Duration: ~2 min\n Gas: 0.108 POL (~$0.08)"},{"language":"bash","snippet":"aomi chat \"proceed with Hyperstream using the TRANSFER method\"\naomi tx list # confirm the wallet request was queued\naomi tx sign tx-1 --rpc-url # source-chain RPC must match"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: aomi-transact\ndescription: >\n Build natural-language crypto agents, web3 assistants, and trading bots that read\n and write EVM chain state. Aomi turns prompts (\"swap 1 ETH for USDC\", \"open a 3x\n GMX long\", \"bet $100 on Polymarket\") into wallet-signed transactions on Ethereum,\n Base, Arbitrum, Optimism, Polygon, Linea — non-custodial, fork-simulated. Use when\n the user wants a crypto/DeFi agent, AI trading/wallet assistant, or on-chain\n execution against Uniswap, Aave, Lido, GMX, Hyperliquid, Polymarket, Binance, OKX,\n or 40+ other protocols. Trigger with prompts about swaps, lending, bridging,\n staking, perps, prediction markets, or any DeFi/CEX action needing a wallet\n signature. Account-abstraction first with EIP-7702/4337 and EOA fallback. MUST NOT fabricate\n or echo credentials; values reach the CLI only when the user explicitly supplied them.\ncompatibility: 'Verified against @aomi-labs/client v0.1.42 and the current aomi-widget/packages/client TypeScript CLI. Install globally via npm install -g @aomi-labs/client@latest, or run on demand via npx @aomi-labs/client@latest. The CLI defaults to https://api.aomi.dev; pass --backend-url https://api-staging.aomi.dev when explicitly targeting staging. viem and Solana signing dependencies are bundled by the package. Designed for claude-code; also works with Cursor, Codex CLI, Gemini, and any agent runtime that supports the Anthropic skill spec.'\nlicense: MIT\nversion: \"0.10.1\"\nauthor: 'aomi-labs '\ntags: [crypto, defi, web3, evm, ethereum, wallet, account-abstraction, trading, mcp, agent]\nallowed-tools: 'Bash(aomi:*), Bash(npx:*)'\nmetadata:\n author: 'aomi-labs '\n version: \"0.10.1\"\n repository: aomi-labs/skills\n homepage: https://github.com/aomi-labs/skills/tree/main/aomi-transact\npermissions:\n files:\n read: [~/.aomi/]\n write: [~/.aomi/]\n deny_write: [SOUL.md, MEMORY.md, AGENTS.md]\n network:\n allow: [api.aomi.dev]\n deny: \"*\"\n shell:\n - aomi\n - npx @aomi-labs/client@latest\n tools: []\nrisk_tier: L2\nrequires:\n binaries: [aomi, npx]\n---\n\n# Aomi Transact\n\n## Overview\n\nAomi Transact drives the `aomi` TypeScript CLI to build natural-language crypto agents and web3 assistants. It composes calldata, fork-simulates transactions as a batch, and stages wallet requests for explicit user signing — non-custodial throughout. Current chain metadata includes Ethereum, Polygon, Arbitrum, Base, Optimism, Sepolia, Linea, Monad, Monad Testnet, and local Anvil. The npm CLI is the production/end-user surface; the Rust `aomi-cli` in `product-mono` is an in-process dev/test CLI with different signing gates. For deep references, see [commands.md](references/commands.md), [workflows.md](references/workflows.md), [gotchas.md](references/gotchas.md), [account-abstraction.md](references/account-abstraction.md), [apps.md](references/apps.md), [examples.md](references/examples.md), [thread.md](references/thread.md), [drain-vectors.md](references/drain-vect"},{"path":"_meta.json","content":"{\n \"ownerId\": \"kn7axfgphsdj10cpkqw6n840nh86837c\",\n \"slug\": \"aomi-transact\",\n \"version\": \"0.10.1\",\n \"publishedAt\": 1783711863396\n}"},{"path":"references/account-abstraction.md","content":"# Account Abstraction Reference\n\nRead this when:\n\n- The user asks about AA modes, sponsorship, or chain defaults.\n- `aomi tx sign` returns an AA error and you need to pick a flag.\n- The user explicitly requests `4337` or `7702`.\n\n## Execution Model\n\nThe CLI uses **auto-detect** by default for EVM transactions. It tries account abstraction first, then falls back according to the requested mode:\n\n| User-side provider configured? | Flag | Result |\n|---|---|---|\n| Pimlico configured | `--aa-provider pimlico` | Pimlico BYOK (user-side credential) |\n| Alchemy configured | (none) | Alchemy BYOK (user-side credential) |\n| Nothing configured | (none) | Backend Alchemy proxy if available, otherwise EOA fallback after AA attempts |\n| Any | `--aa` / `--aa-provider` / `--aa-mode` | AA with explicit settings; no EOA fallback when `--aa` is set |\n| Any | `--eoa` | Direct EOA, skip AA |\n\nWith no explicit `--aa`, the current TypeScript CLI signs in this order: preferred AA mode, alternative AA mode, then EOA. With `--aa`, it tries AA modes only and returns a hard error if both fail. The zero-config proxy path is useful, but it is not a guarantee of sponsorship or availability.\n\n## Mode Fallback\n\nWhen using AA, the CLI tries modes in order:\n\n1. Try preferred mode (current configured default: 7702 on Ethereum, Polygon, Arbitrum, Base, and Optimism).\n2. If preferred mode fails, try the alternative mode (7702 ↔ 4337).\n3. If both modes fail and `--aa` was not set, try EOA.\n4. If `--aa` was set, return an AA-only error with the per-mode failures.\n\n## AA Configuration\n\nAA is configured per-invocation via flags or by credentials the user has configured on their side. There is no persistent AA config file on the skill's side.\n\nPriority chain for AA resolution: **flag > user-side credential > backend proxy/default > EOA fallback when allowed**.\n\n## AA Providers\n\n| Provider | Flag | Notes |\n| -------- | ----------------------- | -------------------------------- |\n| Alchemy | `--aa-provider alchemy` | 4337 (sponsored via gas policy), 7702 (EOA pays gas) |\n| Pimlico | `--aa-provider pimlico` | 4337 (sponsored via dashboard policy) |\n\nProvider selection rules:\n\n- If the user explicitly selects a provider via flag, use it.\n- In auto-detect mode, the CLI prefers explicit/user-side provider credentials, then the backend Alchemy proxy path.\n- Pimlico is used only when explicitly requested or configured; Alchemy can be direct BYOK or backend-proxied depending on available credentials.\n\nThe skill never configures provider credentials itself. If `aomi tx sign` reports missing provider credentials, stop and ask the user to configure them before re-running.\n\n## AA Modes\n\n| Mode | Flag | Meaning | Gas |\n| ------ | ---------------- | -------------------------------- | --- |\n| `4337` | `--aa-mode 4337` | Bundler + paymaster UserOperation via smart account. Gas sponsored by paymaster. | Paymaster pays |\n"},{"path":"references/apps.md","content":"# Apps Reference\n\nRead this when:\n\n- The user asks \"what apps are available?\" or names a category (CEX, lending, perps, prediction, social).\n- You need to pick `--app` for a request and want to see the catalog.\n- You need a usage example for a specific app.\n\n## Discovering Apps\n\nThe set of installed apps is dynamic — the catalog below is a snapshot. Always confirm against the live CLI:\n\n```bash\naomi app list # enumerate apps exposed by the backend\naomi app current # show the currently active app\n```\n\nSelect an app for a chat turn with `--app ` or set `AOMI_APP=` for a multi-command shell. When an app needs provider credentials, the aomi CLI reports at runtime what is missing. The user configures those credentials themselves; the skill does not perform that setup unless the user explicitly asks (see SKILL.md \"Secret Ingestion\").\n\n## App Catalog\n\nAll apps share a common base toolset (`send_transaction_to_wallet`, `encode_and_simulate`, `get_account_info`, `get_contract_abi`, etc.). The tools listed below are the app-specific additions. The \"Credentials\" column indicates whether an app needs user-configured credentials at all; the CLI reports the specific names at runtime when something is missing.\n\n| App | Description | App-Specific Tools | Credentials |\n|-----|-------------|-------------------|-------------|\n| `default` | General-purpose on-chain agent with web search | `brave_search` | None |\n| `binance` | Binance CEX — prices, order book, klines | `binance_get_price`, `binance_get_depth`, `binance_get_klines` | Exchange credentials |\n| `bybit` | Bybit CEX — orders, positions, leverage | `brave_search` (no Bybit-specific tools yet) | Exchange credentials |\n| `cow` | CoW Protocol — MEV-protected swaps via batch auctions | `get_cow_swap_quote`, `place_cow_order`, `get_cow_order`, `get_cow_order_status`, `get_cow_user_orders` | None |\n| `defillama` | DefiLlama — TVL, yields, volumes, stablecoins | `get_token_price`, `get_yield_opportunities`, `get_defi_protocols`, `get_chain_tvl`, `get_protocol_detail`, `get_dex_volumes`, `get_fees_overview`, `get_protocol_fees`, `get_stablecoins`, `get_stablecoin_chains`, `get_historical_token_price`, `get_token_price_change`, `get_historical_chain_tvl`, `get_dex_protocol_volume`, `get_stablecoin_history`, `get_yield_pool_history` | None |\n| `dune` | Dune Analytics — execute and fetch SQL queries | `execute_query`, `get_execution_status`, `get_execution_results`, `get_query_results` | Provider token |\n| `dydx` | dYdX perpetuals — markets, orderbook, candles, trades | `dydx_get_markets`, `dydx_get_orderbook`, `dydx_get_candles`, `dydx_get_trades`, `dydx_get_account` | None |\n| `gmx` | GMX perpetuals — markets, positions, orders, prices | `get_gmx_prices`, `get_gmx_signed_prices`, `get_gmx_markets`, `get_gmx_positions`, `get_gmx_orders` | None |\n| `hyperliquid` | Hyperliquid perps — mid prices, orderbook | `get_meta`, `get_all_mids` | None |\n| `kaito` | Kaito — crypto social search, trending, min"},{"path":"references/commands.md","content":"# Command Reference\n\nFull command surface for the TypeScript `aomi` CLI (or `npx @aomi-labs/client@latest` equivalent), verified against `@aomi-labs/client` v0.1.42. The skill invokes read forms freely; `set`/mutating forms only when the user explicitly asks.\n\n## Chat\n\n```bash\naomi chat \"\" # one-shot send and exit\naomi --prompt \"\" # root-level compatibility form\naomi chat \"\" --new-session\naomi chat \"\" --verbose # stream tool calls and agent output\naomi chat \"\" --model \naomi chat \"\" --public-key 0xUserAddress --chain 1\naomi chat \"\" --app khalani --chain 137\naomi chat \"\" --account-bearer \"$AOMI_ACCOUNT_BEARER\"\n```\n\n- Quote the message.\n- On the first command in a new assistant thread, prefer `--new-session`.\n- Pass `--public-key` on the first wallet-aware message.\n- Use `--app`, `--model`, `--chain` to change the active context for the next request.\n\n## Transactions\n\n```bash\naomi tx list # pending/signed requests\naomi tx simulate [ ...] [--cluster devnet] # dry-run a batch on a fork / cluster\naomi tx sign [ ...] [--cluster devnet] # sign and submit\n```\n\n## Threads\n\n```bash\naomi thread list # local threads with topic + pending count\naomi thread new\naomi thread resume # set active pointer\naomi thread delete # remove (check no pending txs first)\naomi thread status # current thread summary\naomi thread log # replay conversation + tool output\naomi thread events # raw backend system events\naomi thread close # clear active pointer; next chat starts fresh\n```\n\nSelectors accept the backend thread id, `thread-N`, or `N`.\n\n## Secrets\n\n```bash\naomi secret list # handle names only, no values\naomi secret clear # drop all configured secrets\naomi secret add NAME= [NAME=...] # user-directed only (see workflows.md)\n```\n\n## Apps and Models\n\n```bash\naomi app list\naomi app current\naomi model list\naomi model current\naomi model set # persist model for current thread\n```\n\n`aomi chat --model \"\"` applies a model for one turn without persisting it. Pick an app per turn with `--app ` or `AOMI_APP=`. The installed set is dynamic — confirm with `aomi app list`. Full catalog and per-app credential requirements in [apps.md](apps.md).\n\n## Chain\n\n```bash\naomi chain list\naomi chain current\naomi chain set # only when user asked to change default\n```\n\n## Wallet and Config\n\n```bash\naomi wallet ls "}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":null,"editorialQuality":{"score":100,"threshold":65,"status":"thin","wordCount":1860,"uniquenessScore":42,"reasons":["uniqueness-below-45"]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T08:54:24.103Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T08:54:24.103Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T11:25:49.847Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}