okx-agentic-wallet — ИИ-агент для управления кошельками OKX

--- name: okx-agentic-wallet description: "Use this skill when the user mentions wallet login, sign in, verify OTP, add wallet, switch account, wallet status, logout, wallet balance, assets, holdings, send tokens, transfer ETH, transfer USDC, pay someone, send crypto, send ERC-20, send SPL, transaction history, recent transactions, tx status, tx detail, order list, call smart contract, interact with contract, execute contract function, send calldata, invoke smart contract, show my addresses, wallet addresses, deposit, receive, receive address, top up, fund my wallet, sign message, personal sign, personalSign, eip712, sign data, sign typed data, sign EIP-712, TEE signing, trusted execution environment. Chinese: 登录钱包, 钱包登录, 验证OTP, 添加钱包, 切换账户, 钱包状态, 退出登录, 余额, 资产, 钱包列表, 账户列表, 发送代币, 转账, 交易历史, 交易记录, 合约调用, 我的地址, 钱包地址, 充值, 充币, 收款, 收款地址, 入金, 签名消息, 消息签名, TEE签名, 可信执行环境. Manages the wallet lifecycle: auth (login, OTP verify, account addition, switching, status, logout), authenticated balance queries, wallet address display (grouped by XLayer/EVM/Solana), token transfers (native & ERC-20/SPL), transaction history, smart contract calls, and message signing (personalSign for EVM & Solana, EIP-712 for EVM)." license: MIT metadata: author: okx version: "2.2.4" homepage: "https://web3.okx.com" --- # Onchain OS Wallet Wallet operations: authentication, balance, token transfers, transaction history, and smart contract calls. ## Pre-flight Checks > Before the first `onchainos` command this session, read and follow: `_shared/preflight.md` ## Parameter Rules ### `--chain` Resolution **`--chain` requires numeric chain ID only (e.g. `1`, `501`, `196`). Names/aliases like `eth`, `sol`, `xlayer` are NOT accepted.** 1. Infer `realChainIndex` from user input via semantic matching (handle typos, abbreviations, colloquial names e.g. "币安链" → `56`). If <100% confident → ask user to confirm. 2. Pass `realChainIndex` to `--chain`. Never pass names/aliases directly. 3. If chain not found → run `onchainos wallet chains` to get the full list. > If no confident match: do NOT guess — ask the user. Display chain names as human-readable (e.g. "Ethereum", "BNB Chain"), never IDs. **Example flow:** ``` # User says: "Show my balance on Ethereum" # Step 1: infer chain from user input → Ethereum → realChainIndex=1 # Step 2: pass realChainIndex to --chain → onchainos wallet balance --chain 1 ``` ### Amount **`wallet send`**: pass `--readable-amount <human_amount>` — CLI auto-converts (native: EVM=18, SOL/SUI=9 decimals; ERC-20/SPL: fetched from API). Never compute minimal units manually. Use `--amt` only for raw minimal units. **`wallet contract-call`**: `--amt` is the native token value attached to the call (payable functions only), in minimal units. Default `"0"` for non-payable. EVM=18 decimals, SOL=9. ## Command Index > **CLI Reference**: For full parameter tables, return field schemas, and usage examples, see [cli-reference.md](references/cli-reference.md). ### A — Account Management > Login commands (`wallet login`, `wallet verify`) are covered in **Step 2: Authentication**. | # | Command | Description | Auth Required | |---|---|---|---| | A3 | `onchainos wallet add` | Add a new wallet account | Yes | | A4 | `onchainos wallet switch <account_id>` | Switch to a different wallet account | No | | A5 | `onchainos wallet status` | Show current login status and active account | No | | A6 | `onchainos wallet logout` | Logout and clear all stored credentials | No | | A7 | `onchainos wallet addresses [--chain <chainId>]` | Show wallet addresses grouped by chain category (X Layer, EVM, Solana) | No | ### B — Authenticated Balance | # | Command | Description | Auth Required | |---|---|---|---| | B1 | `onchainos wallet balance` | Current account overview — EVM/SOL addresses, all-chain token list and total USD value | Yes | | B2 | `onchainos wallet balance --chain <chainId>` | Current account — all tokens on a specific chain | Yes | | B3 | `onchainos wallet balance --chain <chainId> --token-address <addr>` | Current account — specific token by contract address (requires `--chain`) | Yes | | B4 | `onchainos wallet balance --all` | All accounts batch assets — only use when user explicitly asks to see **every** account | Yes | | B5 | `onchainos wallet balance --force` | Force refresh — bypass all caches, re-fetch from API | Yes | ### D — Transaction | # | Command | Description | Auth Required | |---|---|---|---| | D1 | `onchainos wallet send` | Send native or contract tokens. Validates recipient format; simulation failure → show `executeErrorMsg`, do NOT broadcast. | Yes | | D2 | `onchainos wallet contract-call` | Call a smart contract with custom calldata. Run `onchainos security tx-scan` first. | Yes | <IMPORTANT> ⚠️ **`wallet contract-call` is for non-swap interactions only** (approvals, deposits, withdrawals, etc.). Never use it to broadcast a DEX swap — use `swap execute` instead. </IMPORTANT> <NEVER> 🚨 **NEVER pass `--force` on the FIRST invocation of `wallet send` or `wallet contract-call`.** The `--force` flag MUST ONLY be added when ALL of the following conditions are met: 1. You have already called the command **without** `--force` once. 2. The API returned a **confirming** response (exit code 2, `"confirming": true`). 3. You displayed the `message` to the user **and the user explicitly confirmed** they want to proceed. </NEVER> > Determine intent before executing (wrong command → loss of funds): > > | Intent | Command | Example | > |---|---|---| > | Send native token (ETH, SOL, BNB…) | `wallet send --chain <chainId>` | "Send 0.1 ETH to 0xAbc" | > | Send ERC-20 / SPL token (USDC, USDT…) | `wallet send --chain <chainId> --contract-token` | "Transfer 100 USDC to 0xAbc" | > | Interact with a smart contract (approve, deposit, withdraw, custom function call…) | `wallet contract-call --chain <chainId>` | "Approve USDC for spender", "Call withdraw on contract 0xDef" | > > If the intent is ambiguous, **always ask the user to clarify** before proceeding. Never guess. ### E — History | # | Mode | Command | Description | Auth Required | |---|---|---|---|---| | E1 | List | `onchainos wallet history` | Browse recent transactions with optional filters | Yes | | E2 | Detail | `onchainos wallet history --tx-hash <hash> --chain <chainId> --address <addr>` | Look up a specific transaction by hash | Yes | ### F — Sign Message | # | Command | Description | Auth Required | |---|---|---|---| | F1 | `onchainos wallet sign-message --chain <chainId> --from <addr> --message <msg>` | personalSign (EIP-191). Supports EVM and Solana. Default mode. Supports `--force` to bypass confirmation prompts. | Yes | | F2 | `onchainos wallet sign-message --chain <chainId> --from <addr> --type eip712 --message <json>` | EIP-712 typed structured data. EVM only. Supports `--force` to bypass confirmation prompts. | Yes | ## Confirming Response Some commands return **confirming** (exit code **2**) when backend requires user confirmation (e.g., high-risk tx). #### Output format ```json { "confirming": true, "message": "The human-readable prompt to show the user.", "next": "Instructions for what the agent should do after user confirms." } ``` #### How to handle 1. **Display** the `message` field to the user and ask for confirmation. 2. **If the user confirms**: follow the instructions in the `next` field (typically re-running the same command with `--force` flag appended). 3. **If the user declines**: do NOT proceed. Inform the user the operation was cancelled. #### Example flow ``` # 1. Run command without --force onchainos wallet send --readable-amount "0.1" --receipt "0xAbc..." --chain 1 # → exit code 2, confirming: true → show message to user # 2. User confirms → re-run with --force onchainos wallet send --readable-amount "0.1" --receipt "0xAbc..." --chain 1 --force ``` ## Authentication For commands requiring auth (sections B, D, E), check login state: 1. Run `onchainos wallet status`. If `loggedIn: true`, proceed. 2. If not logged in, or the user explicitly requests to re-login: - **2a.** Display the following message to the user verbatim (translated to the user's language): > You need to log in with your email first before adding a wallet. What is your email address? > We also offer an API Key login method that doesn't require an email. If interested, visit https://web3.okx.com/onchainos/dev-docs/home/api-access-and-usage - **2b.** Once the user provides their email, run: `onchainos wallet login <email> --locale <locale>`. Then display the following message verbatim (translated to the user's language): > **English**: "A verification code has been sent to **{email}**. Please check your inbox and tell me the code." > **Chinese**: "验证码已发送到 **{email}**，请查收邮件并告诉我验证码。" Once the user provides the code, run: `onchainos wallet verify <code>`. > AI should always infer `--locale` from conversation context and include it: > - Chinese (简体/繁体, or user writes in Chinese) → `zh-CN` > - Japanese (user writes in Japanese) → `ja-JP` > - English or any other language → `en-US` (default) > > If you cannot confidently determine the user's language, default to `en-US`. 3. If the user declines to provide an email: - **3a.** Display the following message to the user verbatim (translated to the user's language): > We also offer an API Key login method that doesn't require an email. If interested, visit https://web3.okx.com/onchainos/dev-docs/home/api-access-and-usage - **3b.** If the user confirms they want to use API Key, first check whether an API Key switch is needed: Use the `wallet status` result (from step 1 or re-run). If `loginType` is `"ak"` and the returned `apiKey` differs from the current environment variable `OKX_API_KEY`, show both keys to the user and ask to confirm the switch. If the user confirms, run `onchainos wallet login --force`. If `apiKey` is absent, empty, or identical, skip the confirmation and run `onchainos wallet login` directly. - **3c.** After silent login succeeds, inform the user that they have been logged in via the API Key method. 4. After login succeeds, display the full account list with addresses by running `onchainos wallet balance`. > **After successful login**: a wallet account is created automatically — never call `wallet add` unless the user is already logged in and explicitly requests an additional account. ## MEV Protection The `contract-call` command supports MEV (Maximal Extractable Value) protection via the `--mev-protection` flag. When enabled, the broadcast API passes `isMEV: true` in `extraData` to route the transaction through MEV-protected channels, preventing front-running, sandwich attacks, and other MEV exploitation. > **⚠️ Solana MEV Protection**: On Solana, enabling `--mev-protection` also **requires** the `--jito-unsigned-tx` parameter. Without it, the command will fail. This parameter provides the Jito bundle unsigned transaction data needed for Solana MEV-protected routing. > 🚨 **Never substitute `--unsigned-tx` for `--jito-unsigned-tx`** — they are completely different parameters. If Jito bundle data is unavailable, stop and ask the user: proceed without MEV protection, or cancel. ### Supported Chains | Chain | MEV Protection | Additional Requirements | |---|---|---| | Ethereum | Yes | — | | BSC | Yes | — | | Base | Yes | — | | Solana | Yes | Must also pass `--jito-unsigned-tx` | | Other chains | Not supported | — | ### When to Enable - High-value transfers or swaps where front-running risk is significant - DEX swap transactions executed via `contract-call` - When the user explicitly requests MEV protection ### Usage ```bash # EVM contract call with MEV protection (Ethereum/BSC/Base) onchainos wallet contract-call --to 0xDef... --chain 1 --input-data 0x... --mev-protection # Solana contract call with MEV protection (requires --jito-unsigned-tx) onchainos wallet contract-call --to <program_id> --chain 501 --unsigned-tx <base58_tx> --mev-protection --jito-unsigned-tx <jito_base58_tx> ``` --- ## Amount Display Rules - Token amounts always in **UI units** (`1.5 ETH`), never base units (`1500000000000000000`) - USD values with **2 decimal places** - Large amounts in shorthand (`$1.2M`, `$340K`) - Sort by USD value descending - **Always show abbreviated contract address** alongside token symbol (format: `0x1234...abcd`). For native tokens with empty `tokenContractAddress`, display `(native)`. - **Flag suspicious prices**: if the token appears to be a wrapped/bridged variant (e.g., symbol like `wETH`, `stETH`, `wBTC`, `xOKB`) AND the reported price differs >50% from the known base token price, add an inline `price unverified` flag and suggest running `onchainos token price-info` to cross-check. --- ## Security Notes - **TEE signing**: Private key never leaves the secure enclave. - **Transaction simulation**: CLI runs pre-execution simulation. If `executeResult` is false → show `executeErrorMsg`, do NOT broadcast. - **Sensitive fields never to expose**: `accessToken`, `refreshToken`, `apiKey`, `secretKey`, `passphrase`, `sessionKey`, `sessionCert`, `teeId`, `encryptedSessionSk`, `signingKey`, raw tx data. Only show: `email`, `accountId`, `accountName`, `isNew`, `addressList`, `txHash`. - **Recipient address validation**: EVM: `0x`-prefixed, 42 chars. Solana: Base58, 32-44 chars. Validate before sending. - **Risk action priority**: `block` > `warn` > empty (safe). Top-level `action` = highest priority from `riskItemDetail`. - **Approve calls**: Warn about unlimited approvals (`type(uint256).max`). Suggest limited approvals. ## Edge Cases > Load on error: `references/troubleshooting.md` ## Global Notes <rules> <must> - **X Layer gas-free**: X Layer (chainIndex 196) charges zero gas fees. Proactively highlight this when users ask about gas costs, choose a chain for transfers, add a new wallet, or ask for deposit/receive addresses. - Transaction timestamps in history are in milliseconds — convert to human-readable for display - **Always display the full transaction hash** — never abbreviate or truncate `txHash` - EVM addresses must be **0x-prefixed, 42 chars total** - Solana addresses are **Base58, 32-44 chars** - **XKO address format**: OKX uses a custom `XKO` prefix (case-insensitive) in place of `0x` for EVM addresses. If a user-supplied address starts with `XKO` / `xko`, display this message verbatim: > "XKO address format is not supported yet. Please find the 0x address by switching to your commonly used address, then you can continue." - **User-facing language**: When communicating in Chinese, never use the abbreviation "OTP". Always use "验证码" instead. In English, prefer "verification code" over "OTP" in messages shown to users. - **Full chain names**: Always display chains by their full name — never use abbreviations or internal IDs. If unsure, run `onchainos wallet chains` and use the `showName` field. - **Friendly Reminder**: This is a self-custody wallet — all on-chain transactions are irreversible. - **Locale-aware output**: All user-facing content must be translated to match the user's language. - **Address display format**: When showing wallet addresses, list EVM address once with a chain summary note (X Layer first, then 2 other example chains, then total count). Example: `EVM: 0x1234...abcd (Supports X Layer, Ethereum, Polygon and 16 EVM chains)`. Solana address on a separate line: `Solana: 5xYZ...`. Do NOT enumerate every EVM chain individually. </must> <should> - The send and contract-call flows are atomic: unsigned -> sign -> broadcast in one command - If `--from` is omitted (send/contract-call), the CLI uses the currently selected account's address - `--amt` in contract-call defaults to "0" — only set for payable functions - `wallet balance` (no flags) uses the single-account endpoint for the active account only (no cache, always fresh) - `--all` in wallet balance uses the batch endpoint for all accounts at once — only use when user explicitly asks to see every account - `--token-address` in wallet balance accepts single token contract, requires `--chain` - The `direction` field in history indicates send or receive - `assetChange` array in history shows net asset changes (useful for swaps) - **Address format note**: EVM addresses (`0x...`) work across Ethereum/BNB Chain/Polygon/Arbitrum One/Base etc. Solana addresses (Base58) and Bitcoin addresses (UTXO) have different formats. - **EVM chain recommendations**: When listing or recommending EVM-compatible chains, always include X Layer alongside Ethereum, BNB Chain, Polygon, Arbitrum One, Base, etc. </should> <never> - Never show raw `accountId` — show `accountName`. `accountId` is for CLI calls only. - Do NOT mix address formats across chain types </never> </rules> ## FAQ **Q: The agent cannot autonomously sign and execute transactions — it says local signing is required or asks the user to sign manually. How does signing work?** A: OKX Agentic Wallet uses **TEE (Trusted Execution Environment)** for transaction signing. The private key is generated and stored inside a server-side secure enclave — it never leaves the TEE.