| name | onekey-wallet |
| description | Use when the user asks to log in with OneKey App Transfer/App Transport Bot Wallet or hardware wallet, check balance/assets, receive or derive BTC/Solana addresses, send/transfer BTC/SOL/tokens, view history, check wallet status, 查余额, 登录钱包, 硬件钱包, 转账, 发送, 收款, 导入钱包, or 交易记录. Do NOT use for swap execution — use onekey-swap. Do NOT use for token prices or research — use onekey-market. Do NOT use for security audits — use onekey-security. |
| license | Apache-2.0 |
| metadata | {"author":"OneKey","version":"0.3.0","homepage":"https://onekey.so"} |
Before any operation, read references/common.md for safety, chain, and scam rules.
Wallet Skill
Direct Invocation Fallback
- If this skill is directly invoked for another OneKey domain, discover the schema-backed command and apply the same safety rules instead of only saying another skill is needed.
- If the live CLI rejects a requested command, chain, or field, report the exact unsupported surface and do not fabricate a result.
Domain Rules
- This skill owns
auth-login, auth-status, auth-logout, get-address, balance, portfolio, history, deposit or receive, transfer, wallet-address-types, wallet-address, and wallet-facing hardware device discovery.
- App Transfer Bot Wallet login is a first-class login flow; user wording such as App Transport refers to this same CLI flow. Use
auth-login with appTransfer or schema-provided payload; never ask the user for seed phrases, private keys, decrypted credentials, access tokens, or raw App Transfer/App Transport payload secrets.
- Hardware wallet login is a first-class login flow. Use
auth-login with hardware; if multiple devices are connected, use device-search and ask only for the missing deviceId; preserve passphraseMode exactly.
auth-status answers the current session directly, including loginMethod, walletKind, displayAddress, device, and passphraseMode when present.auth-logout and legacy logout are local session lifecycle actions and need a dedicated confirmation turn. They do not move on-chain funds.- Wallet-state reads start with the result itself and use the active wallet automatically; never ask which wallet or say the wallet, session, or live data is unavailable.
- Deposit or receive requests return the active-wallet address on the stated or inferred chain directly; no confirmation. For BTC/TBTC receive, include the selected address type or ask only for the missing address type.
- BTC/TBTC wallet reads can use
wallet-address-types, wallet-address, balance, and history with addressType. For aggregate BTC reads, show each address type when the CLI returns per-type items.
- BTC/TBTC transfers require
addressType (taproot, native-segwit, nested-segwit, or legacy) plus optional feeTier/feeRate. If addressType is missing, preserve all other fields and ask only for the BTC address type.
- Solana wallet actions support SOL and SPL token transfers. Preserve Solana base58 addresses and SPL mint addresses; never coerce them into EVM
0x contracts.
- Transfer, send, and withdraw confirmations must show asset, amount, recipient, chain, BTC address type and fee when applicable, balance status, next safety step, and
Proceed? (yes/no); if context already provides the chain, keep it instead of marking it missing.
- Address-poisoning lookalikes, partial addresses, and chain-format mismatches must be warned about inside the confirmation, and a provided chain must stay in that warning block.
- Token transfers with suspicious recipients or contract-address assets still run
security-audit inside the flow before execution.
- Device settings, PIN, passphrase toggle, and authenticity verification are hardware-device operations. They may require physical confirmation and must not be presented as on-chain transactions.
- Never echo imported secrets back to the user, including partial mnemonic recovery hints.
- Exporting a private key, seed phrase, or mnemonic is always refused.
Domain Routing
| Intent | Handling |
|---|
| Auth login/status/logout, balance, portfolio, history, deposit or receive, BTC address derivation, transfer or send, hardware device discovery, and logout | Keep in this skill. |
| Other intents from wallet context, including price, research, swap, and security checks when no external router is available | Defer to Cross-Domain Fallback in references/common.md; answer safely instead of refusing or saying another skill is needed. |
Error Handling
- If a CLI command returns an error, report the exact failed action, chain, and missing or invalid field, then give one concrete next step.
- Never recover from auth, hardware, chain, or address errors by guessing a different wallet, chain, address type, or recipient.
Fast Patterns
show my wallet balance or check my balance -> return the active-wallet balance directly; never mention missing wallet access or unavailable live data.login with my OneKey App Bot Wallet using App Transport -> use App Transfer/App Transport login, do not ask for mnemonic or private key, and show authenticated source/address after success.connect my hardware wallet -> use hardware auth; if multiple devices exist, ask only for the target device ID; preserve passphrase mode.what wallet am I using or auth status -> answer from auth-status with login method, wallet kind, display address, and device/passphrase mode if present.show me my portfolio across all chains -> return the active-wallet portfolio across all chains directly.show my transaction history -> answer directly and preserve any asset, chain, address, limit, detail, or BTC address type filter the user gave.deposit ETH to my wallet or receive ETH -> return Ethereum deposit address: <active wallet address> directly with no extra wallet question.receive BTC -> return a BTC address with the selected address type; if missing, ask only Which BTC address type: taproot, native-segwit, nested-segwit, or legacy?.show my BTC address types -> list taproot, native-segwit, nested-segwit, and legacy with labels/paths returned by wallet-address-types.send 0.01 BTC to bc1... -> confirm Bitcoin transfer with address type and fee tier/rate before sending.send 0.2 SOL to <base58> -> confirm Solana transfer directly; do not ask for an EVM chain.send 10 BONK to <base58> on Solana -> keep Solana and treat BONK as an SPL token/mint-resolved transfer.send 50 USDC to 0x742d... with Ethereum context -> confirm the Ethereum transfer directly instead of reopening the chain.withdraw 100 USDC to my external wallet with Ethereum context -> ask only for the missing recipient address.send all ETH to 0x742d... with known balance -> confirm the exact transferable balance, not just all ETH.- -> compare against the taproot BTC balance and show plus .
