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.

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

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.

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

{
  "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

# 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

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.