菜单
Use when performing private or anonymous ETH transfers on Taiko. Covers deposit creation, target address funding, ZK proof generation, and on-chain claiming via REST API or CLI.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Set up, run, and manage Taiko nodes on Hoodi testnet or mainnet using Docker or from source. Use when "run node", "node operator", "simple-taiko-node", "taiko-geth", "taiko-client", or "sync" is mentioned.
Deploy, test, and interact with smart contracts on Taiko networks (Type-1 ZK-EVM rollup on Ethereum). Use when "Taiko", "Hoodi", "L2 deployment", "bridge", "forge", or "Taikoscan" is mentioned. For x402 payment APIs use the taiko-x402 skill instead.
Build and integrate x402 HTTP payment flows on Taiko using Taiko-operated facilitators. Use when adding per-request USDC payment gating to APIs deployed on Taiko (seller), building AI agents or clients that autonomously pay for x402 services (buyer), or configuring Taiko facilitators. Triggers: "x402", "HTTP payment", "pay per request", "monetize API", "USDC payment", "402 Payment Required", "facilitator.taiko.xyz", "paid API", "AI agent payments", "payment middleware".
| name | taiko-shadow |
| description | Use when performing private or anonymous ETH transfers on Taiko. Covers deposit creation, target address funding, ZK proof generation, and on-chain claiming via REST API or CLI. |
Shadow is a privacy-preserving ETH claim system on Taiko L2. An agent deposits ETH to a deterministically-derived "target address" on L1 Ethereum, then claims on Taiko L2 using a ZK proof — without linking depositor and recipient.
Network Selection: If the user has not specified "hoodi" or "mainnet", always ask which network to use before proceeding.
No pool required. Unlike mixers, Shadow uses ZK proofs per deposit — a single user can privately transfer ETH without waiting for others to participate.
Create deposit → Fund target address (L1) → Generate ZK proof → Claim on L2
Constraints: 1–5 notes per deposit, total ≤ 8 ETH, 0.1% protocol fee per claim.
| Situation | Use |
|---|---|
| Default / automated pipeline | Server (REST API) |
| No Docker server available | CLI (shadowcli.mjs) |
| Scripted proving only | start.sh --prove FILE (see server reference) |
| Error | Fix |
|---|---|
insufficient balance: X < Y | Fund target on L1, wait for checkpoint, retry |
nullifier already consumed | Note already claimed — skip, check others |
Please install docker first | Start Docker daemon |
RPC chainId mismatch | Use L1 RPC matching deposit's chainId |
DEPOSIT schema validation failed | See deposit schema |
| Server not responding | Re-run start.sh |
| Step | Tool | Purpose |
|---|---|---|
| Before deposit | get_balance | Verify source address has enough ETH on L1 |
| After funding | get_transaction_info | Confirm L1 funding tx is confirmed |
| During prove | get_bridge_message_status | Track cross-chain relay status |
| Before new deposit | get_pending_messages | Check for stuck prior deposits |
| Before claim | get_gas_price | Estimate L2 claim tx cost |
taiko bridge status <TX_HASH> --json # check bridge relay for L1 funding tx
taiko bridge history <ADDRESS> --json # list all bridge deposits for an address
Use TaskCreate / TaskUpdate to persist deposit_id across session interruptions:
deposit_id and targetAddress in descriptionTaskList → find in_progress shadow deposits → extract deposit_id