[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GX2BHNNAS72P0B68S54HHD":3,"skill-same:01M6GX2BHNNAS72P0B68S54HHD":69},{"skillNo":4,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":15,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":23,"linkOnly":24,"markdownContent":25,"markdownBody":26,"frontMatter":27,"refName":28,"commitSha":29,"skillDirectory":30,"forksCount":31,"repositoryHtmlUrl":32,"repositoryHomepageUrl":6,"ownerHtmlUrl":33,"ownerBlogUrl":34,"ownerDescription":35,"updatedAt":36,"install":37,"resources":50},"01M6GX2BHNNAS72P0B68S54HHD","rustok-org-rustok-wallet-tui",null,"jiayaoqijia\u002Fcryptoskill","jiayaoqijia","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1453879?v=4","01M6GMYTX7Q7S504VC6E756ENR","YQ","01M6GMYV1QKJ1CC75MTTGT9PR0",81,"MIT","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fmcp-servers\u002Frustok-org-rustok-wallet-tui\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fmcp-servers\u002Frustok-org-rustok-wallet-tui\u002FSKILL.md",[],[19,20,21,22],"tui","Wallet","org","rustok org rustok wallet tui","2026-11-10 10:12:30",false,"---\nname: rustok-wallet-tui\ndescription: Self-custody Ethereum agent wallet. Installs from a verified release and runs entirely on your machine as a single container image (MCP over stdio); private keys never leave it. New connections are read-only. Read wallet context, balances and DeFi positions (Aave v3, ERC-4626); preview transactions. Sending funds on-chain is gated in a separate terminal console, never inside the agent chat: you approve each payment, or confirm autonomous mode once and the wallet sends on its own after that; message signing is refused outright, in every mode. You assume all risk for funds on the agent wallet — there are no hard-coded spending limits.\nversion: 0.12.0\nmetadata:\n  openclaw:\n    emoji: \"?\"\n    homepage: https:\u002F\u002Fgithub.com\u002Frustok-org\u002Fmcp\n---\n\n# rustok-wallet-tui\n\n> **License note:** this OpenClaw skill package (`skills\u002Frustok-wallet-tui\u002F`) is MIT-0\n> per ClawHub requirements. The Rustok wallet core itself is proprietary; only the\n> compiled binary image is distributed.\n\nYou are connected to a **self-custody** Ethereum agent wallet that runs entirely\non the user's machine as a single Docker image (`ghcr.io\u002Frustok-org\u002Frustok-wallet-tui`).\nThe container runs the wallet core + gateway and speaks MCP over **stdio**; the\nprivate keys live only in the user's local Docker volume and never leave it.\n\n> ⚠️ **Self-custody, real funds, your risk.** This wallet has **no hard-coded\n> spending limits or budgets** — the user consciously accepts that funds sent to\n> the agent wallet are at risk. txguard still flags risky transactions, but it\n> does not block them. All supported chains the user enables are live (incl.\n> Ethereum mainnet). New connections expose only read tools. If the user explicitly grants preview\u002Fexecute, always preview before executing and show the user the details.\n\n## What's protected — and what isn't (be honest with the user)\n\nThe wallet's guarantee is narrow and specific. State it plainly; do not oversell it.\n\nThe full list of boundaries — password delivery, updates, what we do not verify at\nall — lives in [docs\u002FCAVEATS.md](https:\u002F\u002Fgithub.com\u002Frustok-org\u002Fmcp\u002Fblob\u002Fmain\u002Fdocs\u002FCAVEATS.md).\n\n| | |\n|---|---|\n| **Protected** | Private keys stay in the user's **local Docker volume** and never leave the machine. **Sending funds on-chain** (`execute_transaction`) is gated in a **separate console window** (`rustok console`, opened by the user — see below): parked for the user's approval, with a PIN for high-risk items — unless the user has confirmed **autonomous mode** there, a confirmation only they can give, once per wallet. |\n| **Refused, not gated** | `sign_message` (EIP-191) is **refused outright** — in every mode, autonomous included. The console never sees a signature request, because signing does not happen at all: parking a signature for approval (`kind:sign`) is planned and not built. A tool that is listed and always refuses is neither a capability to rely on nor a hole to fear. Tell the user that rather than letting them plan around a signature. |\n| **Outside the model** | An agent with **shell \u002F `docker exec` access to the container** can read secrets and bypass client isolation. Direct message and typed-data signing are refused by the core in all wallet modes; a compromised host can still steal the private key. That is why the console is a **separate window, not an agent command**. Trusting your own agent is the user's call, the same as never pasting a seed phrase into an untrusted tool. |\n\n**Never claim** the agent (or a prompt-injected agent) \"cannot move funds.\" What is\ntrue: keys stay local, and supervised sends wait for approval in the console.\nOnce the user confirms autonomous mode, an execute grant can spend the full\nwallet balance without approval of each payment.\n\n### The mode switch, and why a send may still park\n\nThe user switches the wallet's mode **in the console**: press **`c`** on the\nDashboard, pick `read_only` \u002F `supervised` \u002F `autonomous`, enter the PIN. That\nis how autonomy is turned ON — and OFF: switching back to `supervised` parks\nevery future send again, and `read_only` refuses every write outright. The\nagent cannot flip that switch, and neither can an environment variable or a\nlaunch flag. Until a human has confirmed autonomy there, an autonomous-looking\nwallet **parks every send** exactly like a supervised one.\n\n**Turning autonomy on does not release what already waits.** A payment parked\nbefore the switch stays parked — it goes out when the user releases it in the\nconsole, or expires. Do not retry it: a retry adds a second parked copy that\nwill be paid separately if released, and switching the mode releases neither\nof them.\n\n**Your session reads the wallet's mode once, when it connects.** If the user\nswitches the mode mid-session, your tool list does not change until the next\nconnect — a tool you still see may now be refused by the core. The refusal is\nthe wallet enforcing the new mode; tell the user what it said, do not retry\naround it.\n\nConfirmation from a messenger does not exist yet — the console is the only\nplace the switch can be thrown.\n\n## What changed in 0.9.8\n\n- **`sign_message` is refused outright, and these texts finally say so.** Every\n  earlier release described it as an ungated hole you had to guard against. It is\n  not a hole and not a protection: signing is an unfinished capability, and\n  parking a signature for approval is planned and not built. Live acceptance of\n  0.9.7 asked the wallet and got a refusal; nine texts had said otherwise.\n\n## What changed in 0.9.7\n\n- **The wallet states what it does not promise.** A `## Legal` section below, and\n  a full [DISCLAIMER](https:\u002F\u002Fgithub.com\u002Frustok-org\u002Fmcp\u002Fblob\u002Fmain\u002FDISCLAIMER.md)\n  that names the limit of every safeguard — starting with the one easiest to read\n  as absolute: autonomous mode sends without asking once confirmed.\n\n## What changed in 0.9.5\n\n- **Gas limits now carry headroom.** A limit set to exactly the estimate turned\n  any drift between estimating and executing into a burnt fee — a contract call\n  could pay its gas and do nothing. Plain transfers were never affected.\n- **ERC-20 tokens are documented at last** (see below). The wallet has been able\n  to report registered tokens since 0.9.4, but nothing here said so, and an\n  unregistered token reads exactly like an absent one.\n- **`rustok connect --force` names what it is about to drop** instead of quietly\n  rebuilding the registration from the current shell.\n\n## Prerequisites\n\n- **Podman** (recommended) or **Docker**, curl, a SHA-256 tool and **trusted cosign 3+**. Install the verifier independently using a trusted system package channel; do not download and execute an unverified verifier in this bootstrap. See [Sigstore installation](https:\u002F\u002Fdocs.sigstore.dev\u002Fcosign\u002Fsystem_config\u002Finstallation\u002F).\n- An Ethereum RPC URL (public endpoints can be used for testing).\n\n## One-time onboarding (the user does this in their own terminal, once)\n\nUse the **published release SKILL.md** from the release\u002Flisting you trust. The repository file is a template: its bootstrap hash is deliberately unfilled and refuses to run. The generated [release SKILL.md](https:\u002F\u002Fgithub.com\u002Frustok-org\u002Fmcp\u002Freleases\u002Fdownload\u002Fwallet-tui-v0.12.0\u002FSKILL.md) binds the installer bytes before execution. A release bundle is also published as `wallet-skill.zip` with SKILL.md, claw.json, the exact installer, manifest and signature bundle.\n\n**1. Verify and install the command.** Blob verification uses the fixed release workflow\u002Ftag identity below, independently of downloaded certificate data. OCI verification inside the verified installer separately uses the image-publishing workflow on main. Missing\u002Fbroken\u002Fold verifier, bad signature or unavailable verification network refuses installation. Reading the installer costs about ~214 lines of POSIX sh.\n\n```sh\n(\n  set -eu\n  wallet_version=0.12.0\n  expected_installer_sha256='@INSTALLER_SHA256@'\n  # This hash is filled in the published release SKILL.md, not guessed locally.\n  printf '%s\\n' \"$expected_installer_sha256\" | grep -Eq '^[0-9a-f]{64}$' || {\n    echo 'Use the published release SKILL.md: this source template is not an installer.' >&2; exit 1;\n  }\n  cosign_version=$(cosign version 2>\u002Fdev\u002Fnull) || {\n    echo 'Install trusted cosign 3+ independently before continuing.' >&2; exit 1;\n  }\n  cosign_major=$(printf '%s\\n' \"$cosign_version\" | sed -n 's\u002F^GitVersion:[[:space:]]*v\\([0-9][0-9]*\\)\\..*\u002F\\1\u002Fp')\n  case \"$cosign_major\" in ''|*[!0-9]*) exit 1 ;; esac\n  [ \"$cosign_major\" -ge 3 ] || exit 1\n  stage_dir=$(mktemp -d)\n  trap 'rm -rf \"$stage_dir\"' EXIT\n  release_base=\"https:\u002F\u002Fgithub.com\u002Frustok-org\u002Fmcp\u002Freleases\u002Fdownload\u002Fwallet-tui-v$wallet_version\"\n  for asset in install.sh release.manifest release.manifest.sigstore.json; do\n    curl --proto '=https' --tlsv1.2 -fsSL \"$release_base\u002F$asset\" -o \"$stage_dir\u002F$asset\"\n  done\n  cosign verify-blob \"$stage_dir\u002Frelease.manifest\" \\\n    --bundle \"$stage_dir\u002Frelease.manifest.sigstore.json\" \\\n    --certificate-identity \"https:\u002F\u002Fgithub.com\u002Frustok-org\u002Fmcp\u002F.github\u002Fworkflows\u002Frelease-shelf.yml@refs\u002Ftags\u002Fwallet-tui-v$wallet_version\" \\\n    --certificate-oidc-issuer https:\u002F\u002Ftoken.actions.githubusercontent.com\n  if command -v sha256sum >\u002Fdev\u002Fnull 2>&1; then\n    actual_sha=$(sha256sum \"$stage_dir\u002Finstall.sh\" | cut -d' ' -f1)\n  elif command -v shasum >\u002Fdev\u002Fnull 2>&1; then\n    actual_sha=$(shasum -a 256 \"$stage_dir\u002Finstall.sh\" | cut -d' ' -f1)\n  elif command -v openssl >\u002Fdev\u002Fnull 2>&1; then\n    actual_sha=$(openssl dgst -sha256 \"$stage_dir\u002Finstall.sh\" | sed 's\u002F.*= \u002F\u002F')\n  else\n    echo 'A SHA-256 tool is required.' >&2; exit 1\n  fi\n  [ \"$actual_sha\" = \"$expected_installer_sha256\" ] || {\n    echo 'Installer checksum mismatch; refusing to execute it.' >&2; exit 1;\n  }\n  less \"$stage_dir\u002Finstall.sh\" # read the same verified file before executing it\n  sh \"$stage_dir\u002Finstall.sh\" --manifest \"$stage_dir\u002Frelease.manifest\" \\\n    --bundle \"$stage_dir\u002Frelease.manifest.sigstore.json\"\n)\n```\n\nThe installer never initializes a wallet, changes keys or registers an agent. It stores the signed release digest for all standard future launches; an image tag being repointed cannot change those selected bytes. It does not bootstrap cosign automatically.\n\n**2. Create the wallet** — the user chooses a 6-digit approval PIN; it prints the\n12-word phrase ONCE:\n\n```bash\nrustok init\n```\n\n**3. Register this wallet with the agent client (read-only by default):**\n\n```bash\nrustok connect claude\n```\n\nTo grant transactions, the user runs `rustok connect claude --force --capabilities read_wallet,preview_tx,execute_tx` in their own terminal and confirms the expansion. Capabilities only bound the client; wallet policy\u002FPIN remains a separate gate. Existing explicit subsets are preserved on reconnect\u002Fupdate; implicit or invalid old grants migrate to read-only. A read-only session cannot poll execution status. It must not interpret losing status access as a failed payment or replay an unknown outcome.\n\n`rustok init` asks the user to choose a **6-digit approval PIN** (typed twice) —\nthe one code they will ever enter: it unlocks the console session and confirms\npayments. The keyring password that encrypts the keystore is generated by `init`\nitself and kept in the engine's secret store; the user never sees or types it,\nand it never reaches shell history, `inspect` or any config file. `init` prints\nexactly one thing, once: the **12-word recovery phrase**.\n\nThe 12 words are the only backup — write them down offline; the wallet does not\nstore them. Recovery is `rustok restore` (or importing the words into any standard\nBIP-39 wallet — same address). A copy of the wallet volume by itself is **not** a\nbackup: the password that opens it lives outside the volume and is not something\nthe user knows. If the PIN is forgotten, `rustok set-pin` lets them choose a new\none — the old PIN is not needed. This changes the approval PIN, not keystore encryption. Restore from the same phrase recovers the same private key and does not revoke a leaked key.\n\n> **Rule of two windows:** never run `rustok init`, `rustok restore`,\n> `rustok set-pin` or the approval console through an agent shell\u002Fcommand — the\n> seed and PIN would leak into the agent's context. These belong only in the\n> user's own terminal (window 2). Do not ask the user for their PIN or their\n> phrase in this chat, ever.\n\n## Stopping and uninstalling\n\n`rustok stop` stops the selected wallet process. `read_only` refuses new writes;\nremoving a client registration removes its launch entry but does not stop live\nsessions. None of these actions deletes stored secrets or revokes the private\nkey. Before stopping for teardown, stop new requests,\nresolve pending approvals and wait for active execution outcomes as described\nunder maintenance below. Never automatically replay an unknown payment.\n\n**Before uninstalling, explain that stored keyring passwords are deleted. An\nencrypted volume alone is not a recoverable backup.** The user must confirm they\nhave their recovery phrase backed up offline before proceeding; never ask them\nto paste it into chat.\n\nThe user runs `rustok uninstall` in their own terminal. It deregisters supported\nclients, stops wallets and removes stored passwords\u002FRPC secrets, the installed\nshim\u002Frelease record and the installer PATH block. Encrypted key volumes remain.\nCheck reported warnings for registrations or other state that still need manual\nremoval; do not describe a partial teardown as complete.\n\nTo delete key volumes too, choose `rustok uninstall --purge-keys` **instead of**\nordinary uninstall. It requires the user's own terminal and the exact\n`delete my keys` confirmation before changes. Without the recovery phrase,\ndeleting those keys makes the funds unrecoverable. These are human maintenance\ncommands, not agent commands.\n\n## Where the balance you show comes from\n\nThe wallet reads chains through an RPC node. Since 0.11.0 it carries two public\nendpoints for each chain it shows (Ethereum, Base, Arbitrum by default), so a\nfresh install reports balances without the user configuring anything, and USDC\nappears beside the native coin without being registered.\n\n**Tell the user this when it matters, and never as a footnote to a payment:** any\nnode that reads a balance learns the address and the IP that asked — the\ncarried ones, one they name themselves, and their own provider's alike. They\nreplace the carried list with `RUSTOK_RPC_URLS_\u003Cchain>`; naming one replaces the\nlist rather than adding to it.\n\nOn Arbitrum two USDC rows are normal: the native token and the bridged one, which\nthe wallet labels `USDC.e`. On chain both call themselves `USDC` — only the\ncontract address separates them, which is why balance rows carry it. Never treat\nthem as one balance, and never sum them without saying you did.\n\n## How the agent runs the wallet\n\n`rustok connect claude|cursor|hermes|openclaw` generates the engine command using the saved immutable release digest, per-agent labels\u002Fvolume and one explicit capability grant. Do not build a second version-tag recipe. Each client owns its wallet by default; shared-volume concurrent writers are not verified as separate client principals. Config paths with spaces remain single arguments.\n\nInit uses `podman secret create` with the password on stdin, never in argv. The generated keyring password lives outside the encrypted volume, in a Podman secret or an owner-readable Docker fallback file. It is delivered through `RUSTOK_KEYRING_PASSWORD_FILE`; it is not collected by the agent, stored in agent config, printed or passed as a command-line password. These local file mounts unlock only the user's own wallet; they are not requests to read unrelated credentials. Host\u002Fshell compromise remains outside this protection. With Podman, RPC URLs configured through connect ride per-agent secrets; raw environment forwarding and the Docker fallback can expose configured RPC URLs in engine metadata. Keep keyed URLs out of agent chat.\n\nFor maintenance, `rustok update` verifies a signed release and preserves explicit subsets. Live sessions retain their old image\u002Fgrants until a human restart. Stop new requests in all sessions, resolve pending approvals and wait for active execution terminal outcomes before `rustok stop`. Previews, pending approvals and status outcomes do not survive restart. Unknown payment results require audit\u002Fhash\u002Fnetwork investigation; never replay automatically. No persistent execution ledger is promised.\n\n## Why Rustok exists\n\nRustok gives an AI agent a wallet of its own — self-custody, no middleman — so agents can begin\nto take part in the economy directly: weighing what's worth paying for, covering the compute,\ndata, and tools they rely on, and in time commissioning and paying the people who help them.\n\n## Tools\n\nThe stdio wallet image defaults to **read-only** tools. Preview and execution require an explicit human capability grant; initialize only narrows that ceiling.\nTo run a restricted agent, set `RUSTOK_MCP_CAPABILITIES` to a subset\n(`read_wallet` \u002F `preview_tx` \u002F `execute_tx`) — e.g. `read_wallet` for read-only.\nThe ceiling is enforced by the gateway, on the path every request takes: it\ncovers the MCP tools below **and** the HTTP routes behind them, so a session\ncannot reach past its capabilities by calling the gateway directly. In releases\nbefore 0.9.0 the ceiling was checked in the MCP layer only, which left every\nroute reachable beside it: the core refused signing for its own unrelated\nreasons, but a session narrowed away from `read_wallet` still read the wallet\naddress and every balance. A client may narrow its own session further in\n`initialize`, and can never widen it.\n\n| Tool | Capability | What it does |\n|------|-----------|--------------|\n| `get_wallet_context` | read_wallet | Active wallet address, the assets it holds (native coin + registered tokens), the assets it could not read, allowed chains |\n| `get_balances` | read_wallet | Balances of the active wallet — one row per asset, with `balance_formatted` to show and `token_address` to tell two same-named tokens apart — or the native balance of `{address, chain_id}` |\n| `get_positions` | read_wallet | DeFi positions — Aave v3 (collateral\u002Fdebt\u002Fhealth factor\u002FLTV) + ERC-4626 vaults; optional `{address}` |\n| `preview_transaction` | preview_tx | Preview any transaction `{to, value, chain_id, data?}` → decoded call (who\u002Fwhat is authorized), pre-sign simulation (revert check), gas, risk level |\n| `execute_transaction` | execute_tx | Submit a previewed transaction `{preview_id}` — parked for human approval on a supervised wallet, released by the core on one whose owner confirmed autonomous mode; a `pending` result carries `next_step` for the human |\n| `get_execution_status` | execute_tx | Poll a parked execution `{preview_id}` → `pending` \u002F `executed` (+`tx_hash`) \u002F `denied` \u002F `expired` \u002F `failed` (+`error_reason`), with the `not_after_unix` deadline. **`executed` means broadcast, not on-chain success** — see below |\n\n### ERC-20 balances use a configured registry\n\nThe wallet reports tokens in its configured registry and does not discover every\ntoken the address holds. On carried chains, the default registry includes USDC\n(and USDC.e on Arbitrum). An explicit `RUSTOK_TOKENS_\u003Cchain>` value **replaces**\nthat chain's carried registry rather than adding to it. To select a registry:\n\n```bash\n-e RUSTOK_TOKENS_1=\"USDC:0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48:6\"\n-e RUSTOK_TOKENS_8453=\"USDC:0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913:6\"\n```\n\n`SYMBOL:ADDRESS:DECIMALS`, comma-separated, one variable per chain, and the chain\nmust be listed in `RUSTOK_ALLOWED_CHAINS`. A malformed entry, a duplicate address\non one chain, or an unknown chain **fails startup** naming the chain — a\nhalf-loaded registry is worse than none. Symbol and decimals are taken from the\nuser, not read from the contract: get the decimals wrong and the wallet will show\na wrong amount confidently.\n\n**What this means for you, the agent:** before telling the user they hold none of\na token, say that it may simply not be registered. Reading an empty list as an\nempty wallet is the likeliest way to be wrong here — and it has already happened.\n\n## Behavioral guidelines\n\n1. **Always `preview_transaction` first** and show its decoded call + simulation (revert check) + risk level so the user gives informed approval.\n2. **The money path is preview → summary card → `execute_transaction` → core policy.**\n   In supervised mode, the transaction waits for human approval (`state: \"pending\"`)\n   in a separate terminal running `rustok console`. Once the user confirms\n   autonomous mode, execution can broadcast without approval of each payment;\n   an execute grant can spend the full wallet balance. Report the actual returned\n   state rather than promising that a send only waits. Never offer to run the\n   console yourself or ask the user to paste the approval PIN into chat.\n3. **`executed` means the transaction was broadcast, not that it succeeded.**\n   The wallet reports the hash the moment the network accepted the transaction\n   for inclusion; a transaction that reverts on-chain still costs its gas and\n   still reads as `executed` here. Verify the receipt independently before\n   telling the user their swap or approval went through — an explorer, or\n   `eth_getTransactionReceipt` where `status` must be `0x1`.\n4. **Poll `get_execution_status` reasonably**: when the user asks, or every ~15–30\n   seconds until the `not_after_unix` deadline (if it is `null` — only on request).\n   Stop on any terminal state: `executed`, `denied`, `expired`, `failed`. A\n   `denied` outcome is the human's answer — do not re-submit the same transaction;\n   a not-found error means the id is no longer retained — stop polling.\n5. **Surface what the preview decoded** (who\u002Fwhat is authorized, amount, revert check, estimated cost, risk level) before the user acts on it.\n6. **Use `get_wallet_context` first** so you don't hallucinate balances or chains.\n7. If a tool needs a capability the session lacks, it returns an authorization\n   error — explain that to the user rather than retrying.\n8. If the wallet is unreachable, tell the user the wallet container\u002Fonboarding may\n   not be set up (see onboarding above).\n\n## Legal\n\nProvided **as is**, without warranty of any kind, under the MIT-0 license.\n**What an agent does with this wallet is not an act of the authors:** the agent\ndriving it is third-party software whose output is unpredictable and may be\ninaccurate, incorrect, or undesirable, and evaluating each proposed transaction\nbefore approving it is the user's exclusive responsibility. Nothing this wallet\nor the agent driving it produces is investment, accounting, legal, or tax advice.\nSending funds is gated at the console **unless autonomous mode was confirmed**;\n**`sign_message` is refused outright** in every mode. The risk of loss is\nsubstantial and the user assumes all of it.\n\nFull terms, and every safeguard's limit named:\n\u003Chttps:\u002F\u002Fgithub.com\u002Frustok-org\u002Fmcp\u002Fblob\u002Fmain\u002FDISCLAIMER.md>\n","# rustok-wallet-tui\n\n> **License note:** this OpenClaw skill package (`skills\u002Frustok-wallet-tui\u002F`) is MIT-0\n> per ClawHub requirements. The Rustok wallet core itself is proprietary; only the\n> compiled binary image is distributed.\n\nYou are connected to a **self-custody** Ethereum agent wallet that runs entirely\non the user's machine as a single Docker image (`ghcr.io\u002Frustok-org\u002Frustok-wallet-tui`).\nThe container runs the wallet core + gateway and speaks MCP over **stdio**; the\nprivate keys live only in the user's local Docker volume and never leave it.\n\n> ⚠️ **Self-custody, real funds, your risk.** This wallet has **no hard-coded\n> spending limits or budgets** — the user consciously accepts that funds sent to\n> the agent wallet are at risk. txguard still flags risky transactions, but it\n> does not block them. All supported chains the user enables are live (incl.\n> Ethereum mainnet). New connections expose only read tools. If the user explicitly grants preview\u002Fexecute, always preview before executing and show the user the details.\n\n## What's protected — and what isn't (be honest with the user)\n\nThe wallet's guarantee is narrow and specific. State it plainly; do not oversell it.\n\nThe full list of boundaries — password delivery, updates, what we do not verify at\nall — lives in [docs\u002FCAVEATS.md](https:\u002F\u002Fgithub.com\u002Frustok-org\u002Fmcp\u002Fblob\u002Fmain\u002Fdocs\u002FCAVEATS.md).\n\n| | |\n|---|---|\n| **Protected** | Private keys stay in the user's **local Docker volume** and never leave the machine. **Sending funds on-chain** (`execute_transaction`) is gated in a **separate console window** (`rustok console`, opened by the user — see below): parked for the user's approval, with a PIN for high-risk items — unless the user has confirmed **autonomous mode** there, a confirmation only they can give, once per wallet. |\n| **Refused, not gated** | `sign_message` (EIP-191) is **refused outright** — in every mode, autonomous included. The console never sees a signature request, because signing does not happen at all: parking a signature for approval (`kind:sign`) is planned and not built. A tool that is listed and always refuses is neither a capability to rely on nor a hole to fear. Tell the user that rather than letting them plan around a signature. |\n| **Outside the model** | An agent with **shell \u002F `docker exec` access to the container** can read secrets and bypass client isolation. Direct message and typed-data signing are refused by the core in all wallet modes; a compromised host can still steal the private key. That is why the console is a **separate window, not an agent command**. Trusting your own agent is the user's call, the same as never pasting a seed phrase into an untrusted tool. |\n\n**Never claim** the agent (or a prompt-injected agent) \"cannot move funds.\" What is\ntrue: keys stay local, and supervised sends wait for approval in the console.\nOnce the user confirms autonomous mode, an execute grant can spend the full\nwallet balance without approval of each payment.\n\n### The mode switch, and why a send may still park\n\nThe user switches the wallet's mode **in the console**: press **`c`** on the\nDashboard, pick `read_only` \u002F `supervised` \u002F `autonomous`, enter the PIN. That\nis how autonomy is turned ON — and OFF: switching back to `supervised` parks\nevery future send again, and `read_only` refuses every write outright. The\nagent cannot flip that switch, and neither can an environment variable or a\nlaunch flag. Until a human has confirmed autonomy there, an autonomous-looking\nwallet **parks every send** exactly like a supervised one.\n\n**Turning autonomy on does not release what already waits.** A payment parked\nbefore the switch stays parked — it goes out when the user releases it in the\nconsole, or expires. Do not retry it: a retry adds a second parked copy that\nwill be paid separately if released, and switching the mode releases neither\nof them.\n\n**Your session reads the wallet's mode once, when it connects.** If the user\nswitches the mode mid-session, your tool list does not change until the next\nconnect — a tool you still see may now be refused by the core. The refusal is\nthe wallet enforcing the new mode; tell the user what it said, do not retry\naround it.\n\nConfirmation from a messenger does not exist yet — the console is the only\nplace the switch can be thrown.\n\n## What changed in 0.9.8\n\n- **`sign_message` is refused outright, and these texts finally say so.** Every\n  earlier release described it as an ungated hole you had to guard against. It is\n  not a hole and not a protection: signing is an unfinished capability, and\n  parking a signature for approval is planned and not built. Live acceptance of\n  0.9.7 asked the wallet and got a refusal; nine texts had said otherwise.\n\n## What changed in 0.9.7\n\n- **The wallet states what it does not promise.** A `## Legal` section below, and\n  a full [DISCLAIMER](https:\u002F\u002Fgithub.com\u002Frustok-org\u002Fmcp\u002Fblob\u002Fmain\u002FDISCLAIMER.md)\n  that names the limit of every safeguard — starting with the one easiest to read\n  as absolute: autonomous mode sends without asking once confirmed.\n\n## What changed in 0.9.5\n\n- **Gas limits now carry headroom.** A limit set to exactly the estimate turned\n  any drift between estimating and executing into a burnt fee — a contract call\n  could pay its gas and do nothing. Plain transfers were never affected.\n- **ERC-20 tokens are documented at last** (see below). The wallet has been able\n  to report registered tokens since 0.9.4, but nothing here said so, and an\n  unregistered token reads exactly like an absent one.\n- **`rustok connect --force` names what it is about to drop** instead of quietly\n  rebuilding the registration from the current shell.\n\n## Prerequisites\n\n- **Podman** (recommended) or **Docker**, curl, a SHA-256 tool and **trusted cosign 3+**. Install the verifier independently using a trusted system package channel; do not download and execute an unverified verifier in this bootstrap. See [Sigstore installation](https:\u002F\u002Fdocs.sigstore.dev\u002Fcosign\u002Fsystem_config\u002Finstallation\u002F).\n- An Ethereum RPC URL (public endpoints can be used for testing).\n\n## One-time onboarding (the user does this in their own terminal, once)\n\nUse the **published release SKILL.md** from the release\u002Flisting you trust. The repository file is a template: its bootstrap hash is deliberately unfilled and refuses to run. The generated [release SKILL.md](https:\u002F\u002Fgithub.com\u002Frustok-org\u002Fmcp\u002Freleases\u002Fdownload\u002Fwallet-tui-v0.12.0\u002FSKILL.md) binds the installer bytes before execution. A release bundle is also published as `wallet-skill.zip` with SKILL.md, claw.json, the exact installer, manifest and signature bundle.\n\n**1. Verify and install the command.** Blob verification uses the fixed release workflow\u002Ftag identity below, independently of downloaded certificate data. OCI verification inside the verified installer separately uses the image-publishing workflow on main. Missing\u002Fbroken\u002Fold verifier, bad signature or unavailable verification network refuses installation. Reading the installer costs about ~214 lines of POSIX sh.\n\n```sh\n(\n  set -eu\n  wallet_version=0.12.0\n  expected_installer_sha256='@INSTALLER_SHA256@'\n  # This hash is filled in the published release SKILL.md, not guessed locally.\n  printf '%s\\n' \"$expected_installer_sha256\" | grep -Eq '^[0-9a-f]{64}$' || {\n    echo 'Use the published release SKILL.md: this source template is not an installer.' >&2; exit 1;\n  }\n  cosign_version=$(cosign version 2>\u002Fdev\u002Fnull) || {\n    echo 'Install trusted cosign 3+ independently before continuing.' >&2; exit 1;\n  }\n  cosign_major=$(printf '%s\\n' \"$cosign_version\" | sed -n 's\u002F^GitVersion:[[:space:]]*v\\([0-9][0-9]*\\)\\..*\u002F\\1\u002Fp')\n  case \"$cosign_major\" in ''|*[!0-9]*) exit 1 ;; esac\n  [ \"$cosign_major\" -ge 3 ] || exit 1\n  stage_dir=$(mktemp -d)\n  trap 'rm -rf \"$stage_dir\"' EXIT\n  release_base=\"https:\u002F\u002Fgithub.com\u002Frustok-org\u002Fmcp\u002Freleases\u002Fdownload\u002Fwallet-tui-v$wallet_version\"\n  for asset in install.sh release.manifest release.manifest.sigstore.json; do\n    curl --proto '=https' --tlsv1.2 -fsSL \"$release_base\u002F$asset\" -o \"$stage_dir\u002F$asset\"\n  done\n  cosign verify-blob \"$stage_dir\u002Frelease.manifest\" \\\n    --bundle \"$stage_dir\u002Frelease.manifest.sigstore.json\" \\\n    --certificate-identity \"https:\u002F\u002Fgithub.com\u002Frustok-org\u002Fmcp\u002F.github\u002Fworkflows\u002Frelease-shelf.yml@refs\u002Ftags\u002Fwallet-tui-v$wallet_version\" \\\n    --certificate-oidc-issuer https:\u002F\u002Ftoken.actions.githubusercontent.com\n  if command -v sha256sum >\u002Fdev\u002Fnull 2>&1; then\n    actual_sha=$(sha256sum \"$stage_dir\u002Finstall.sh\" | cut -d' ' -f1)\n  elif command -v shasum >\u002Fdev\u002Fnull 2>&1; then\n    actual_sha=$(shasum -a 256 \"$stage_dir\u002Finstall.sh\" | cut -d' ' -f1)\n  elif command -v openssl >\u002Fdev\u002Fnull 2>&1; then\n    actual_sha=$(openssl dgst -sha256 \"$stage_dir\u002Finstall.sh\" | sed 's\u002F.*= \u002F\u002F')\n  else\n    echo 'A SHA-256 tool is required.' >&2; exit 1\n  fi\n  [ \"$actual_sha\" = \"$expected_installer_sha256\" ] || {\n    echo 'Installer checksum mismatch; refusing to execute it.' >&2; exit 1;\n  }\n  less \"$stage_dir\u002Finstall.sh\" # read the same verified file before executing it\n  sh \"$stage_dir\u002Finstall.sh\" --manifest \"$stage_dir\u002Frelease.manifest\" \\\n    --bundle \"$stage_dir\u002Frelease.manifest.sigstore.json\"\n)\n```\n\nThe installer never initializes a wallet, changes keys or registers an agent. It stores the signed release digest for all standard future launches; an image tag being repointed cannot change those selected bytes. It does not bootstrap cosign automatically.\n\n**2. Create the wallet** — the user chooses a 6-digit approval PIN; it prints the\n12-word phrase ONCE:\n\n```bash\nrustok init\n```\n\n**3. Register this wallet with the agent client (read-only by default):**\n\n```bash\nrustok connect claude\n```\n\nTo grant transactions, the user runs `rustok connect claude --force --capabilities read_wallet,preview_tx,execute_tx` in their own terminal and confirms the expansion. Capabilities only bound the client; wallet policy\u002FPIN remains a separate gate. Existing explicit subsets are preserved on reconnect\u002Fupdate; implicit or invalid old grants migrate to read-only. A read-only session cannot poll execution status. It must not interpret losing status access as a failed payment or replay an unknown outcome.\n\n`rustok init` asks the user to choose a **6-digit approval PIN** (typed twice) —\nthe one code they will ever enter: it unlocks the console session and confirms\npayments. The keyring password that encrypts the keystore is generated by `init`\nitself and kept in the engine's secret store; the user never sees or types it,\nand it never reaches shell history, `inspect` or any config file. `init` prints\nexactly one thing, once: the **12-word recovery phrase**.\n\nThe 12 words are the only backup — write them down offline; the wallet does not\nstore them. Recovery is `rustok restore` (or importing the words into any standard\nBIP-39 wallet — same address). A copy of the wallet volume by itself is **not** a\nbackup: the password that opens it lives outside the volume and is not something\nthe user knows. If the PIN is forgotten, `rustok set-pin` lets them choose a new\none — the old PIN is not needed. This changes the approval PIN, not keystore encryption. Restore from the same phrase recovers the same private key and does not revoke a leaked key.\n\n> **Rule of two windows:** never run `rustok init`, `rustok restore`,\n> `rustok set-pin` or the approval console through an agent shell\u002Fcommand — the\n> seed and PIN would leak into the agent's context. These belong only in the\n> user's own terminal (window 2). Do not ask the user for their PIN or their\n> phrase in this chat, ever.\n\n## Stopping and uninstalling\n\n`rustok stop` stops the selected wallet process. `read_only` refuses new writes;\nremoving a client registration removes its launch entry but does not stop live\nsessions. None of these actions deletes stored secrets or revokes the private\nkey. Before stopping for teardown, stop new requests,\nresolve pending approvals and wait for active execution outcomes as described\nunder maintenance below. Never automatically replay an unknown payment.\n\n**Before uninstalling, explain that stored keyring passwords are deleted. An\nencrypted volume alone is not a recoverable backup.** The user must confirm they\nhave their recovery phrase backed up offline before proceeding; never ask them\nto paste it into chat.\n\nThe user runs `rustok uninstall` in their own terminal. It deregisters supported\nclients, stops wallets and removes stored passwords\u002FRPC secrets, the installed\nshim\u002Frelease record and the installer PATH block. Encrypted key volumes remain.\nCheck reported warnings for registrations or other state that still need manual\nremoval; do not describe a partial teardown as complete.\n\nTo delete key volumes too, choose `rustok uninstall --purge-keys` **instead of**\nordinary uninstall. It requires the user's own terminal and the exact\n`delete my keys` confirmation before changes. Without the recovery phrase,\ndeleting those keys makes the funds unrecoverable. These are human maintenance\ncommands, not agent commands.\n\n## Where the balance you show comes from\n\nThe wallet reads chains through an RPC node. Since 0.11.0 it carries two public\nendpoints for each chain it shows (Ethereum, Base, Arbitrum by default), so a\nfresh install reports balances without the user configuring anything, and USDC\nappears beside the native coin without being registered.\n\n**Tell the user this when it matters, and never as a footnote to a payment:** any\nnode that reads a balance learns the address and the IP that asked — the\ncarried ones, one they name themselves, and their own provider's alike. They\nreplace the carried list with `RUSTOK_RPC_URLS_\u003Cchain>`; naming one replaces the\nlist rather than adding to it.\n\nOn Arbitrum two USDC rows are normal: the native token and the bridged one, which\nthe wallet labels `USDC.e`. On chain both call themselves `USDC` — only the\ncontract address separates them, which is why balance rows carry it. Never treat\nthem as one balance, and never sum them without saying you did.\n\n## How the agent runs the wallet\n\n`rustok connect claude|cursor|hermes|openclaw` generates the engine command using the saved immutable release digest, per-agent labels\u002Fvolume and one explicit capability grant. Do not build a second version-tag recipe. Each client owns its wallet by default; shared-volume concurrent writers are not verified as separate client principals. Config paths with spaces remain single arguments.\n\nInit uses `podman secret create` with the password on stdin, never in argv. The generated keyring password lives outside the encrypted volume, in a Podman secret or an owner-readable Docker fallback file. It is delivered through `RUSTOK_KEYRING_PASSWORD_FILE`; it is not collected by the agent, stored in agent config, printed or passed as a command-line password. These local file mounts unlock only the user's own wallet; they are not requests to read unrelated credentials. Host\u002Fshell compromise remains outside this protection. With Podman, RPC URLs configured through connect ride per-agent secrets; raw environment forwarding and the Docker fallback can expose configured RPC URLs in engine metadata. Keep keyed URLs out of agent chat.\n\nFor maintenance, `rustok update` verifies a signed release and preserves explicit subsets. Live sessions retain their old image\u002Fgrants until a human restart. Stop new requests in all sessions, resolve pending approvals and wait for active execution terminal outcomes before `rustok stop`. Previews, pending approvals and status outcomes do not survive restart. Unknown payment results require audit\u002Fhash\u002Fnetwork investigation; never replay automatically. No persistent execution ledger is promised.\n\n## Why Rustok exists\n\nRustok gives an AI agent a wallet of its own — self-custody, no middleman — so agents can begin\nto take part in the economy directly: weighing what's worth paying for, covering the compute,\ndata, and tools they rely on, and in time commissioning and paying the people who help them.\n\n## Tools\n\nThe stdio wallet image defaults to **read-only** tools. Preview and execution require an explicit human capability grant; initialize only narrows that ceiling.\nTo run a restricted agent, set `RUSTOK_MCP_CAPABILITIES` to a subset\n(`read_wallet` \u002F `preview_tx` \u002F `execute_tx`) — e.g. `read_wallet` for read-only.\nThe ceiling is enforced by the gateway, on the path every request takes: it\ncovers the MCP tools below **and** the HTTP routes behind them, so a session\ncannot reach past its capabilities by calling the gateway directly. In releases\nbefore 0.9.0 the ceiling was checked in the MCP layer only, which left every\nroute reachable beside it: the core refused signing for its own unrelated\nreasons, but a session narrowed away from `read_wallet` still read the wallet\naddress and every balance. A client may narrow its own session further in\n`initialize`, and can never widen it.\n\n| Tool | Capability | What it does |\n|------|-----------|--------------|\n| `get_wallet_context` | read_wallet | Active wallet address, the assets it holds (native coin + registered tokens), the assets it could not read, allowed chains |\n| `get_balances` | read_wallet | Balances of the active wallet — one row per asset, with `balance_formatted` to show and `token_address` to tell two same-named tokens apart — or the native balance of `{address, chain_id}` |\n| `get_positions` | read_wallet | DeFi positions — Aave v3 (collateral\u002Fdebt\u002Fhealth factor\u002FLTV) + ERC-4626 vaults; optional `{address}` |\n| `preview_transaction` | preview_tx | Preview any transaction `{to, value, chain_id, data?}` → decoded call (who\u002Fwhat is authorized), pre-sign simulation (revert check), gas, risk level |\n| `execute_transaction` | execute_tx | Submit a previewed transaction `{preview_id}` — parked for human approval on a supervised wallet, released by the core on one whose owner confirmed autonomous mode; a `pending` result carries `next_step` for the human |\n| `get_execution_status` | execute_tx | Poll a parked execution `{preview_id}` → `pending` \u002F `executed` (+`tx_hash`) \u002F `denied` \u002F `expired` \u002F `failed` (+`error_reason`), with the `not_after_unix` deadline. **`executed` means broadcast, not on-chain success** — see below |\n\n### ERC-20 balances use a configured registry\n\nThe wallet reports tokens in its configured registry and does not discover every\ntoken the address holds. On carried chains, the default registry includes USDC\n(and USDC.e on Arbitrum). An explicit `RUSTOK_TOKENS_\u003Cchain>` value **replaces**\nthat chain's carried registry rather than adding to it. To select a registry:\n\n```bash\n-e RUSTOK_TOKENS_1=\"USDC:0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48:6\"\n-e RUSTOK_TOKENS_8453=\"USDC:0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913:6\"\n```\n\n`SYMBOL:ADDRESS:DECIMALS`, comma-separated, one variable per chain, and the chain\nmust be listed in `RUSTOK_ALLOWED_CHAINS`. A malformed entry, a duplicate address\non one chain, or an unknown chain **fails startup** naming the chain — a\nhalf-loaded registry is worse than none. Symbol and decimals are taken from the\nuser, not read from the contract: get the decimals wrong and the wallet will show\na wrong amount confidently.\n\n**What this means for you, the agent:** before telling the user they hold none of\na token, say that it may simply not be registered. Reading an empty list as an\nempty wallet is the likeliest way to be wrong here — and it has already happened.\n\n## Behavioral guidelines\n\n1. **Always `preview_transaction` first** and show its decoded call + simulation (revert check) + risk level so the user gives informed approval.\n2. **The money path is preview → summary card → `execute_transaction` → core policy.**\n   In supervised mode, the transaction waits for human approval (`state: \"pending\"`)\n   in a separate terminal running `rustok console`. Once the user confirms\n   autonomous mode, execution can broadcast without approval of each payment;\n   an execute grant can spend the full wallet balance. Report the actual returned\n   state rather than promising that a send only waits. Never offer to run the\n   console yourself or ask the user to paste the approval PIN into chat.\n3. **`executed` means the transaction was broadcast, not that it succeeded.**\n   The wallet reports the hash the moment the network accepted the transaction\n   for inclusion; a transaction that reverts on-chain still costs its gas and\n   still reads as `executed` here. Verify the receipt independently before\n   telling the user their swap or approval went through — an explorer, or\n   `eth_getTransactionReceipt` where `status` must be `0x1`.\n4. **Poll `get_execution_status` reasonably**: when the user asks, or every ~15–30\n   seconds until the `not_after_unix` deadline (if it is `null` — only on request).\n   Stop on any terminal state: `executed`, `denied`, `expired`, `failed`. A\n   `denied` outcome is the human's answer — do not re-submit the same transaction;\n   a not-found error means the id is no longer retained — stop polling.\n5. **Surface what the preview decoded** (who\u002Fwhat is authorized, amount, revert check, estimated cost, risk level) before the user acts on it.\n6. **Use `get_wallet_context` first** so you don't hallucinate balances or chains.\n7. If a tool needs a capability the session lacks, it returns an authorization\n   error — explain that to the user rather than retrying.\n8. If the wallet is unreachable, tell the user the wallet container\u002Fonboarding may\n   not be set up (see onboarding above).\n\n## Legal\n\nProvided **as is**, without warranty of any kind, under the MIT-0 license.\n**What an agent does with this wallet is not an act of the authors:** the agent\ndriving it is third-party software whose output is unpredictable and may be\ninaccurate, incorrect, or undesirable, and evaluating each proposed transaction\nbefore approving it is the user's exclusive responsibility. Nothing this wallet\nor the agent driving it produces is investment, accounting, legal, or tax advice.\nSending funds is gated at the console **unless autonomous mode was confirmed**;\n**`sign_message` is refused outright** in every mode. The risk of loss is\nsubstantial and the user assumes all of it.\n\nFull terms, and every safeguard's limit named:\n\u003Chttps:\u002F\u002Fgithub.com\u002Frustok-org\u002Fmcp\u002Fblob\u002Fmain\u002FDISCLAIMER.md>\n",{},"main","3df1d0d67b30ff15236561f8c0f9f06d33f42dfd","skills\u002Fmcp-servers\u002Frustok-org-rustok-wallet-tui",17,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia","https:\u002F\u002Feth2030.com","Hardcore infra. Building @alt-research and applied cryptography.","2026-11-15 02:28:10",{"source":7,"skillName":5,"commands":38,"prompt":48,"zipAvailable":49},[39,42,45],{"tool":40,"command":41},"npx","npx skills add jiayaoqijia\u002Fcryptoskill --skill rustok-org-rustok-wallet-tui",{"tool":43,"command":44},"bunx","bunx skills add jiayaoqijia\u002Fcryptoskill --skill rustok-org-rustok-wallet-tui",{"tool":46,"command":47},"pnpm","pnpm dlx skills add jiayaoqijia\u002Fcryptoskill --skill rustok-org-rustok-wallet-tui","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fmcp-servers\u002Frustok-org-rustok-wallet-tui\u002FSKILL.md",true,[51,57,61,65],{"path":52,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":55,"sourceHtmlUrl":56},"claw.json","REFERENCE","参考文档",1039,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fmcp-servers\u002Frustok-org-rustok-wallet-tui\u002Fclaw.json",{"path":58,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":60,"sourceHtmlUrl":15},"LICENSE","许可证",913,{"path":62,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":63,"sourceHtmlUrl":64},"SOURCE.md",335,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fmcp-servers\u002Frustok-org-rustok-wallet-tui\u002FSOURCE.md",{"path":66,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":67,"sourceHtmlUrl":68},"TRUST.auto.yaml",2154,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fmcp-servers\u002Frustok-org-rustok-wallet-tui\u002FTRUST.auto.yaml",[70,98,121,138,151,161],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":74,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":23},"01M712C436EQYE43342Q4E7GG1","recipe-performance","Diagnose a specific MetaMask user flow's real-app performance and Sentry critical-user-flow telemetry with deterministic mm-harness recipes. Use for CUF boundaries, cold\u002Fwarm\u002Fbackground-resume behavior, latency regressions, lifecycle tags, duplicate or blocking network requests, long tasks, layout\u002Fpaint cost, screen redraws, React rerenders, or browser trace analysis where tests alone cannot prove the real app.","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-performance\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-performance\u002FSKILL.md",[],[78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97],"performance","recipe performance","recipe","mm","sentry","harness","app","deterministic","recipes","flow","cold","critical","analysis","tasks","react","browser","layout","screen","network","metamask",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":102,"licenseFileUrl":103,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":23},"01M70XT2F8A5CQZ81JBP98KSW3","mexc-spot-websocket","MEXC Spot WebSocket workflows for public streams, protobuf handling, depth maintenance, listen keys, and private streams without exposing API keys.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-websocket\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-websocket\u002FSKILL.md",[],[107,108,109,110,111,112,113,114,115,116,117,118,119,120],"mexc spot websocket","spot","websocket","api","workflows","public","listen","streams","depth","keys","for","api keys","maintenance","protobuf",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":102,"licenseFileUrl":125,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":23},"01M70XT0MBXN3WZY1BKN0CPNKR","mexc-spot-rest","MEXC Spot REST workflows for public data, signed account requests, orders, wallet\u002Fadmin actions, and secure signing without exposing API keys.","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-rest\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-rest\u002FSKILL.md",[],[129,108,130,131,132,20,133,118,117,116,134,135,136,112,137,111,110],"mexc spot rest","REST","admin","signing","requests","actions","secure","data","orders",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":102,"licenseFileUrl":142,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":23},"01M70XSYSVZ2N0N91XCAR2CAK0","mexc-futures-websocket","MEXC Futures WebSocket workflows for public streams, private account\u002Forder\u002Fposition streams, ping\u002Fpong, subscriptions, and depth maintenance.","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-futures-websocket\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-futures-websocket\u002FSKILL.md",[],[146,147,109,148,149,119,117,150,115,114,112,111],"mexc futures websocket","futures","position","ping","subscriptions",{"skillNo":152,"name":153,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":154,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":23},"01M6H0ZWHVE5W04WG2DKQE2SQC","0xklen-version-and-refresh-sanctions-lists","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-version-and-refresh-sanctions-lists\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-version-and-refresh-sanctions-lists\u002FSKILL.md",[],[158,159,160],"refresh","0xklen version and refresh sanctions lists","version",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":165,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":23},"01M6H0Z28Q3R8J0S799GJQWXM3","verify-tests-cover-changed-lines","Use when a PR adds code that the existing suite may not exercise. Measures patch coverage — the share of newly changed lines hit by tests — before approving.","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-verify-tests-cover-changed-lines\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-verify-tests-cover-changed-lines\u002FSKILL.md",[],[169,170,171,172,173,174,175,176,177,178,179],"tests","cover","verify tests cover changed lines","verify","coverage","pr","exercise","use","patch","code","share"]