{"id":"916fafaf-8274-464c-bf67-41f1f0812f17","entityType":"agent","slug":"clawhub-casualsecurityinc-nano","name":"Nano (XNO)","canonicalUrl":"https://www.xpersona.co/agent/clawhub-casualsecurityinc-nano","canonicalPath":"/agent/clawhub-casualsecurityinc-nano","generatedAt":"2026-10-10T03:35:20.538Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-09T08:00:54.251Z","emptyReason":null},"description":"Nano (XNO) cryptocurrency wallet operations, transaction analysis, and explorer lookups. Use for send/receive, balances, pending funds, address validation, unit conversion, tx/hash/account lookup, explorer links, and Nano block-lattice questions. Prefer xno-mcp first; use xno-skills CLI as fallback. Configured OWS wallets ARE the assistant's own wallets — never claim you cannot receive or hold Nano. Skill: Nano (XNO) Owner: casualsecurityinc Summary: Nano (XNO) cryptocurrency wallet operations, transaction analysis, and explorer lookups. Use for send/receive, balances, pending funds, address validation, unit conversion, tx/hash/account lookup, explorer links, and Nano block-lattice questions. Prefer xno-mcp first; use xno-skills CLI as fallback. Configured OWS wallets ARE the assistant's own wallets — never clai","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 3.5K downloads reported by the source. Last updated 10/9/2026.","installCommand":"clawhub skill install s173axkamqya99dpj4a8n2ttyh8610x4:nano","sourceUrl":"https://clawhub.ai/casualsecurityinc/nano","homepage":"https://clawhub.ai/casualsecurityinc/skills/nano","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/casualsecurityinc/nano","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/casualsecurityinc/skills/nano","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":71,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Nano (XNO) cryptocurrency wallet operations, transaction analysis, and explorer lookups. Use for send/receive, balances, pending funds, address validation, unit"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-09T08:00:54.251Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T08:00:54.251Z","emptyReason":null},"stars":null,"forks":null,"downloads":3458,"packageName":null,"latestVersion":"5.0.0","tractionLabel":"3.5K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T08:00:54.250Z","emptyReason":null},"lastUpdatedAt":"2026-10-09T08:00:54.251Z","lastCrawledAt":"2026-10-09T08:00:54.250Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-10T08:00:54.250Z","lastVerifiedAt":null,"highlights":[{"version":"5.0.0","createdAt":"2026-10-08T12:29:25.129Z","changelog":"Automated publish from d8f8e529b131ec60bac74d817c39ecbd7d4bd084","fileCount":31,"zipByteSize":24337},{"version":"4.7.5","createdAt":"2026-08-31T15:46:30.002Z","changelog":"Automated publish from 70ccb75a35430047c7ed3a6bb692e127e79c135b","fileCount":31,"zipByteSize":24412},{"version":"4.7.4","createdAt":"2026-08-24T09:22:45.913Z","changelog":"Automated publish from 19f56d6320f159c84bfcecb79433d0c0a714de32","fileCount":31,"zipByteSize":24261},{"version":"4.7.3","createdAt":"2026-08-23T17:43:31.066Z","changelog":"Automated publish from 96d113d2d85eb1d0378a95e21f84d2751833f63d","fileCount":25,"zipByteSize":20179},{"version":"4.7.2","createdAt":"2026-08-23T17:41:00.747Z","changelog":"Automated publish from 861bbf8b8222d21915d4503ce6222f1b68b65d9f","fileCount":25,"zipByteSize":20312},{"version":"4.7.1","createdAt":"2026-08-20T07:02:56.062Z","changelog":"Automated publish from 64ac7b14815c86cc68d4fe7a7b267e76caac9abb","fileCount":25,"zipByteSize":20259},{"version":"4.7.0","createdAt":"2026-08-20T06:03:32.243Z","changelog":"Automated publish from 6b1e84f18b350c89836c96770dc21f06a7b8e066","fileCount":25,"zipByteSize":19980},{"version":"4.6.1","createdAt":"2026-08-20T05:44:01.231Z","changelog":"Automated publish from 966289ea45114ab747e78f1797aa8398e4ff8906","fileCount":25,"zipByteSize":20314}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s173axkamqya99dpj4a8n2ttyh8610x4:nano","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-casualsecurityinc-nano/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-casualsecurityinc-nano/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-casualsecurityinc-nano/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-casualsecurityinc-nano/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-casualsecurityinc-nano/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-casualsecurityinc-nano/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T03:35:20.535Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-casualsecurityinc-nano/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-casualsecurityinc-nano/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-casualsecurityinc-nano/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-casualsecurityinc-nano/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-09T08:00:54.251Z","emptyReason":null},"readme":"Skill: Nano (XNO)\n\nOwner: casualsecurityinc\n\nSummary: Nano (XNO) cryptocurrency wallet operations, transaction analysis, and explorer lookups. Use for send/receive, balances, pending funds, address validation, unit conversion, tx/hash/account lookup, explorer links, and Nano block-lattice questions. Prefer xno-mcp first; use xno-skills CLI as fallback. Configured OWS wallets ARE the assistant's own wallets — never claim you cannot receive or hold Nano.\n\nTags: latest:5.0.0\n\nVersion history:\n\nv5.0.0 | 2026-10-08T12:29:25.129Z | user\n\nAutomated publish from d8f8e529b131ec60bac74d817c39ecbd7d4bd084\n\nv4.7.5 | 2026-08-31T15:46:30.002Z | user\n\nAutomated publish from 70ccb75a35430047c7ed3a6bb692e127e79c135b\n\nv4.7.4 | 2026-08-24T09:22:45.913Z | user\n\nAutomated publish from 19f56d6320f159c84bfcecb79433d0c0a714de32\n\nv4.7.3 | 2026-08-23T17:43:31.066Z | user\n\nAutomated publish from 96d113d2d85eb1d0378a95e21f84d2751833f63d\n\nv4.7.2 | 2026-08-23T17:41:00.747Z | user\n\nAutomated publish from 861bbf8b8222d21915d4503ce6222f1b68b65d9f\n\nv4.7.1 | 2026-08-20T07:02:56.062Z | user\n\nAutomated publish from 64ac7b14815c86cc68d4fe7a7b267e76caac9abb\n\nv4.7.0 | 2026-08-20T06:03:32.243Z | user\n\nAutomated publish from 6b1e84f18b350c89836c96770dc21f06a7b8e066\n\nv4.6.1 | 2026-08-20T05:44:01.231Z | user\n\nAutomated publish from 966289ea45114ab747e78f1797aa8398e4ff8906\n\nv4.6.0 | 2026-08-06T09:15:00.547Z | user\n\nAutomated publish from 86f5730dbe1d82e3e6bfd4fc084c258125608bb4\n\nv4.5.2 | 2026-07-20T07:52:07.603Z | user\n\nAutomated publish from 2fa46b8c1419b2c0dd6fb42faf5159a52676d695\n\nv4.5.1 | 2026-07-20T03:14:43.582Z | user\n\nSwitch to publish under the correct organization now that ClawHub merged its PR 2102:\n\n`openclaw/clawhub#2102 (https://github.com/openclaw/clawhub/pull/2102) — \"fix(skills): allow publishing a new version under a different owner (personal→org migration)\"`\n\nv4.5.0 | 2026-07-15T05:39:33.134Z | user\n\nAutomated publish from c47d5e656a59f82fbe30598d37eee59e3f02e727\n\nv4.4.0 | 2026-06-29T13:55:12.937Z | user\n\nAutomated publish from 782cda565eb7c548ecd828355add76835e8925b0\n\nv4.3.0 | 2026-06-02T14:25:34.127Z | user\n\nAutomated publish from 5d6e1573cece4291676d9a4d8407e01d07ada5fd\n\nv4.2.3 | 2026-05-28T08:54:32.676Z | user\n\nAutomated publish from 28754628158933e3e8cde7a78cd11fc7d520063c\n\nv4.2.2 | 2026-05-25T17:40:14.100Z | user\n\nAutomated publish from 3705daff7afa1b61875c91de474a248bf77df225\n\nv4.2.0 | 2026-05-25T11:47:53.505Z | user\n\nAutomated publish from 3a11f7b34d3a5d8c19277bbe7fb9c4ae1221ec7a\n\nv4.1.0 | 2026-05-25T09:34:47.498Z | user\n\nAutomated publish from e2416ab08bb5b289354b64a92559d6afb707052a\n\nv4.0.1 | 2026-05-25T09:13:55.225Z | user\n\nAutomated publish from 4bfb595cb3ed354839bf5014b6d68804b3ae966c\n\nv4.0.0 | 2026-05-25T08:16:02.508Z | user\n\nAutomated publish from c8754477ec94e6c5b9d57bc2fef8b3343a165138\n\nv3.4.0-2-gc785241 | 2026-05-24T12:51:24.216Z | user\n\nAutomated publish from c785241e25b16c060ab4a16734634d8ee154069d (v3.4.0-2-gc785241)\n\nv3.4.0 | 2026-05-24T06:43:12.586Z | user\n\nAutomated publish from 5a495528ee5f72276a9a7046f4e82e49c8c3a8ec (v3.4.0)\n\nv3.3.3-2-gff64e12 | 2026-05-24T03:58:19.763Z | user\n\nAutomated publish from ff64e12f0b95e45b0934114c032497c8f1585b74 (v3.3.3-2-gff64e12)\n\nv3.3.3-1-ga47a260 | 2026-05-23T16:18:18.863Z | user\n\nAutomated publish from a47a260726ee97c422c272d743b8ccbc0d629f19 (v3.3.3-1-ga47a260)\n\nv3.3.3 | 2026-05-23T16:05:57.866Z | user\n\nAutomated publish from 093877c9646cd43684915ed238194780a8aef406 (v3.3.3)\n\nv3.3.2 | 2026-05-23T14:49:13.427Z | user\n\nAutomated publish from 653bea5ce50c0f37f8854f05b6231c619fb97e5f (v3.3.2)\n\nv3.3.1 | 2026-05-23T14:28:53.243Z | user\n\nAutomated publish from dada3d47fabb46dc7c4f863f23805cbca8633714 (v3.3.1)\n\nv3.3.0-2-g847a78c | 2026-05-23T14:05:45.146Z | user\n\nAutomated publish from 847a78cee27ff62b5922c650a56e9344f2f143b9 (v3.3.0-2-g847a78c)\n\nv3.3.0 | 2026-05-23T10:35:20.896Z | user\n\nAutomated publish from a7404cfa6a958c2353fb67e80cd3008d9a38a51c (v3.3.0)\n\nv3.2.6-1-g3441c05 | 2026-05-23T06:49:29.896Z | user\n\nAutomated publish from 3441c05696b60afa9f75409186095f3d5a55ef38 (v3.2.6-1-g3441c05)\n\nv3.2.6 | 2026-05-23T06:38:52.871Z | user\n\nAutomated publish from a1c7295d8494342d6ef53db0901b433f9c795d65 (v3.2.6)\n\nv3.2.5-5-g422fd99 | 2026-05-23T06:36:33.452Z | user\n\nAutomated publish from 422fd99761e34ecaf690292aa0610f92cff1b72c (v3.2.5-5-g422fd99)\n\nv3.2.2 | 2026-05-20T18:20:05.982Z | user\n\nAutomated publish from a8c37b7eac059b412648df868666e25af9394b50 (v3.2.2)\n\nv3.2.0-1-g435a686 | 2026-05-20T16:43:44.619Z | user\n\nAutomated publish from 435a68621903ec9833526e904a4fd1b0157e1cbe (v3.2.0-1-g435a686)\n\nv3.2.0-1-g27502d3 | 2026-05-20T16:38:58.766Z | user\n\nAutomated publish from 27502d3c0ce93333f3682e7a2ad58dffb3c69126 (v3.2.0-1-g27502d3)\n\nv3.2.0 | 2026-05-12T09:32:50.892Z | user\n\nAutomated publish from 70e14ff188ad9427ec26cc31d5fab226fe0f6595 (v3.2.0)\n\nv3.1.4-2-gf4bd3ab | 2026-05-11T05:29:47.809Z | user\n\nAutomated publish from f4bd3abd3c6c911aafb789e2b330139a322b6e7d (v3.1.4-2-gf4bd3ab)\n\nv3.1.4 | 2026-05-11T04:37:01.839Z | user\n\nAutomated publish from c0c44582ba0e82d2383c48e7206a110e116aeaae (v3.1.4)\n\nv3.1.3-2-g71eb464 | 2026-05-10T16:33:33.001Z | user\n\nAutomated publish from 71eb4640880a84218de47f9d86b613e9ceb02fd0 (v3.1.3-2-g71eb464)\n\nv3.1.3 | 2026-05-10T16:16:11.025Z | user\n\nAutomated publish from 7bdf6c85a45a7e39234cfc66ac7cdf3933b75fa9 (v3.1.3)\n\nv3.1.2-3-gcf73a5f-dirty | 2026-05-10T09:00:01.856Z | user\n\nAutomated publish from cf73a5ff718cb8572e739213abedc4b1a7dc4fde (v3.1.2-3-gcf73a5f-dirty)\n\nv3.1.2-1-gd1e1089-dirty | 2026-05-10T08:38:36.459Z | user\n\nAutomated publish from d1e10895a0a63b1039f97c9dba97f2d7365e6f2d (v3.1.2-1-gd1e1089-dirty)\n\nv3.1.2-dirty | 2026-05-10T08:02:57.888Z | user\n\nAutomated publish from 1a4fd227c2f96dae0d8af3c6d6b0bf31504758ff (v3.1.2-dirty)\n\nv2.8.5 | 2026-05-05T06:28:28.625Z | user\n\nAutomated publish from de1f26ed43d7a8bcbb74fe1366d531e0701ce13e (v2.8.5)\n\nv2.8.4 | 2026-05-05T06:01:39.615Z | user\n\nAutomated publish from f15488906ab6bb26e07ddac37fa13493b87a6cb1 (v2.8.4)\n\nv2.8.3 | 2026-05-05T05:52:48.699Z | user\n\nAutomated publish from e7b9ef846c95863644217e00459a71370a98b7c1 (v2.8.3)\n\nv2.8.2 | 2026-05-05T04:17:51.777Z | user\n\nAutomated publish from 9f33bd92045b8aed1f95a9742f4bd356db6d4a7f (v2.8.2)\n\nv2.8.1-2-g48a7715 | 2026-05-05T04:08:32.777Z | user\n\nAutomated publish from 48a7715c1ce28897ac739bea2e402eac3d175c0e (v2.8.1-2-g48a7715)\n\nv2.8.1-1-g493310b | 2026-05-05T04:07:02.814Z | user\n\nAutomated publish from 493310b57fdf2b4d18864fbe6aeb8f4c136945ad (v2.8.1-1-g493310b)\n\nv2.8.1 | 2026-05-05T04:06:36.886Z | user\n\nAutomated publish from e6c45ba9fe5046389b27fd9eb46c79347e7ec4ba (v2.8.1)\n\nArchive index:\n\nArchive v5.0.0: 31 files, 24337 bytes\n\nFiles: references/balance.md (309b), references/block_change.md (401b), references/block_receive.md (472b), references/block_send.md (419b), references/blocklattice.md (3148b), references/change-rep.md (335b), references/config.md (1513b), references/convert.md (275b), references/diag.md (248b), references/history.md (275b), references/info.md (316b), references/mcp.md (1066b), references/payment.create.md (825b), references/payment.receive.md (803b), references/payment.refund.md (988b), references/qr.md (383b), references/receive.md (340b), references/rpc_account-balance.md (442b), references/rpc_account-info.md (354b), references/rpc_probe-caps.md (470b), references/rpc_receivable.md (338b), references/send.md (301b), references/sign.md (299b), references/submit-block.md (366b), references/troubleshooting.md (3463b), references/validate.md (237b), references/verify.md (347b), references/wallets.md (189b), skill-card.md (2232b), SKILL.md (25106b), _meta.json (123b)\n\nFile v5.0.0:SKILL.md\n\n---\nname: nano\ndescription: \"Nano (XNO) cryptocurrency wallet operations, transaction analysis, and explorer lookups. Use for send/receive, balances, pending funds, address validation, unit conversion, tx/hash/account lookup, explorer links, and Nano block-lattice questions. Prefer xno-mcp first; use xno-skills CLI as fallback. Configured OWS wallets ARE the assistant's own wallets — never claim you cannot receive or hold Nano.\"\ntriggers:\n - nano\n - xno\n - nano transaction\n - xno transaction\n - transaction analysis\n - largest transaction\n - nanocurrency\n - nano_\n - xrb_\n - block lattice\n - block explorer\n - explorer link\n - transaction link\n - tx link\n - tx hash\n - block hash\n - xno-skills\n - xno-mcp\n - wallet\n - wallets\n - send nano\n - receive nano\n - send xno\n - receive xno\n - balance\n - check balance\n - pending\n - qr code\n - payment qr\n - nano qr\n - xno qr\n - request payment\n - invoice\n - refund\n - return funds\n - send back\n - convert units\n - raw to xno\n - xno to raw\n - validate address\n - nano address\n - sign message\n - verify message\n - representative\n - pow\n - proof of work\n - open account\n - frontier\n - top up\n - fund wallet\n - how much xno\n - how much nano\ncomplements:\n - ows # Open Wallet Standard — wallet lifecycle (create, import, rename, delete)\nrequires_network: true\n---\n\n# Nano (XNO)\n\n## Scope & Disambiguation\n\nThis skill applies **exclusively to the Nano cryptocurrency protocol** (ticker: XNO, block-lattice ledger, [Nano.org](https://nano.org)).\n\n**Activate for**: nanocurrency, XNO, `nano_` addresses, block-lattice, ORV, xno-skills, xno-mcp.\n\n**Do NOT activate for**: Ledger Nano (hardware wallet), GNU nano (text editor), Nanopay, or any other product that uses the word \"nano\" unrelated to XNO. If ambiguous, ask for clarification.\n\n**Legacy terminology**: \"Rai\", \"RaiBlocks\", `xrb_` addresses — historical only (pre-2018). Always normalize to Nano / `nano_`.\n\n---\n\n## Wallet Ownership & Agent Authority\n\nWallets returned by `wallet_list` are wallets configured for this assistant environment. Treat them as **assistant-controlled wallets** for Nano operations.\n\n**The assistant may**:\n\n- list wallets;\n- inspect balances, pending funds, history, and representatives;\n- receive funds into an assistant-controlled wallet;\n- provide an assistant-controlled receiving address;\n- send funds when the user explicitly requests it.\n\n> **Never say** \"I don't have a wallet\", \"I can't receive funds\", or \"the skill only operates wallets you control\" when `wallet_list` exposes configured wallets.\n\n**Disambiguation**: \"Send me Nano\" means send to an **assistant-controlled wallet**, unless the user names another recipient. Do not reinterpret it as a request to send to a hypothetical personal wallet, and do not refuse on that basis.\n\nBefore any wallet operation, call `wallet_list`. If the user says they want to send Nano to the assistant, list the wallets, identify a suitable receiving wallet/address, and present the full address (never abbreviated). Do not initiate a receive until the user asks to claim funds or a payment workflow requires it.\n\n---\n\n## Global Execution Policy\n\n**This policy applies to every Nano task in this skill, without exception.**\n\n### 1. Prefer MCP tools first\n\nWhen the environment provides `xno-mcp` tools (`wallet_list`, `wallet_send`, `wallet_receive`, `wallet_balance`, `util_convert`, `util_qr`, `util_validate`, `rpc_account_balance`, `payment_create`, etc.) — **always use them first**. They handle signing, PoW, and broadcast automatically via OWS.\n\nIf the client supports MCP, set it up as a \"stdio\" type MCP server.\n\n**Preferred — global install** (avoids `npx` concurrency issues that cause handshake failures):\n\n npm install -g xno-skills@5.0.0\n xno-skills mcp\n\n**Fallback** (only if global install is not possible):\n\n npx -y xno-skills@5.0.0 mcp\n\n> **Why not `npx` by default?** When multiple agent sessions start concurrently, `npx` can fail during package resolution — the second process exits before the MCP handshake completes. A global install eliminates this race.\n\nMCP is the primary execution path because tools, schemas, and results are structured for the client. Use the included CLI script (`xno-skills`) only as a fallback when MCP is unavailable or the client cannot attach MCP servers. MCP and the CLI target EXACTLY the same underlying code paths — two access paths, not two different products.\n\n### 2. Fall back to CLI only when MCP is unavailable\n\nIf `xno-mcp` tools are not available, or the user explicitly asks for CLI usage, use the `xno-skills` CLI in this priority order:\n\n```\n1. xno-skills (global install — preferred)\n2. bunx -y xno-skills@5.0.0 \n3. pnpm dlx xno-skills@5.0.0 \n4. npx -y xno-skills@5.0.0 \n```\n\nIf the global `xno-skills` binary is not available, fall through to the next option. Always pin the version (`@4.5.2`) with `bunx`/`pnpm dlx`/`npx` to prevent interactive prompts from freezing.\n\nBefore guessing a subcommand, run `--help`:\n\n```bash\nxno-skills --help # or: bunx -y xno-skills@5.0.0 --help\n```\n\n### 3. Wallet lifecycle → `ows` skill only\n\nFor wallet **create, import, rename, or delete**: delegate to the `ows` skill. Do not invoke `ows` CLI commands directly from this skill.\n\n### 4. Never do any of the following\n\n- Write custom Node.js/TypeScript scripts to interact with the Nano protocol.\n- Use `curl` for RPC calls.\n- Attempt to manually compute or supply Proof of Work. PoW is automatic.\n- Use `npx` to fetch random or third-party npm packages as workarounds.\n- Export mnemonics or seeds (`ows wallet export`). OWS keeps secrets encrypted. The entire point of OWS is that the agent never sees the private key.\n- Change `maxSendXno` unless the human/operator explicitly asks to change the spending limit. A blocked send or refund is not permission to raise the limit automatically.\n\n### 5. Prefer `blocklattice.io` for explorer links\n\nWhen the user asks for an account, block, transaction, or explorer link, always prefer `blocklattice.io` unless they explicitly request another explorer.\n\n---\n\n## Safety Rules\n\n- **State verification**: Always fetch balance and frontier via RPC before manually building a block. Never hallucinate previous hashes.\n- **PoW is automatic**: MCP tools and the CLI both handle PoW internally. Never attempt to supply or generate PoW manually.\n- **Pre-send state**: Before `wallet_send`, inspect the source wallet's confirmed balance and total receivable amount with `wallet_balance`. If confirmed funds cannot cover the requested send and receivables are needed, call `wallet_receive`, then recheck. Do not submit receive blocks merely because unrelated funds are pending.\n- **Persistence on \"Account not found\"**: This is normal for a brand-new, unopened account. Continue — `wallet_receive` will automatically build an open block (sets `previous` to zeros), sign it via OWS, generate PoW, and broadcast. Never conclude you are unauthorized or that OWS cannot sign Nano blocks.\n- **No mnemonic exports**: Never call `ows wallet export` or suggest exporting to a third-party wallet unless the user explicitly commands it.\n- **Supply chain**: Only use `xno-skills@5.0.0` and `@open-wallet-standard/core`. No other npm packages.\n- **Stop-loss**: If you have made 5 tool calls without completing the operation, stop and report what you tried, what failed, and ask for guidance. Hard limits: max 3 retries of the same failing tool; max 2 `config_set` RPC endpoint switches.\n\n---\n\n## Wallet Discovery\n\n> **CRITICAL: Always call `wallet_list` first.** Before any wallet operation, identify which OWS wallets exist. Never assume a wallet name.\n\n```json\n{ \"name\": \"wallet_list\", \"arguments\": {} }\n```\n\nTo **create** a new wallet, delegate to the `ows` skill. Then return here for all Nano operations.\n\n**MCP Resources** (passive reads, no tool call needed):\n\n- `wallet://{name}` — wallet summary and primary account state\n- `wallet://{name}/account/{index}` — pending blocks and details for a specific account index\n\n---\n\n## Reading Balances\n\n**Via MCP tools:**\n\n```json\n{ \"name\": \"wallet_balance\", \"arguments\": { \"wallet\": \"my-wallet\" } }\n{ \"name\": \"rpc_account_balance\", \"arguments\": { \"address\": \"nano_...\" } }\n```\n\n**Via CLI (required flags only):**\n\n```bash\nbunx -y xno-skills@5.0.0 balance --wallet \"my-wallet\"\nbunx -y xno-skills@5.0.0 rpc account-balance
\n```\n\nFull options: [balance](references/balance.md), [rpc_account-balance](references/rpc_account-balance.md)\n\n**Public zero-config RPC nodes** (used automatically by xno-skills defaults):\n\n- `https://rainstorm.city/api` (primary)\n- `https://nanoslo.0x.no/proxy` (secondary)\n- `https://rpc.nano.to` (tertiary)\n\nPending funds are not spendable. Receive them only when the user asks to claim them or they are needed for the requested operation (see Receiving Funds section).\n\n---\n\n## Receiving Funds (Including Unopened Accounts)\n\nA Nano transfer shows as **pending** until the recipient publishes a receive block. Funds are not spendable until received.\n\n**A new / \"unopened\" account chain is normal.** It returns `\"Account not found\"` from RPC. This is not an error — `wallet_receive` will automatically build an open block (sets `previous` to zeros), sign it via OWS, generate PoW, and broadcast.\n\n> **OWS DOES support Nano block signing.** Never assume otherwise.\n\nWhen receipt is requested or needed to fund a send, call `wallet_receive`. Do not treat an unopened account as a blocker: `wallet_receive` handles the open block.\n\n**Via MCP:**\n\n```json\n{ \"name\": \"wallet_receive\", \"arguments\": { \"wallet\": \"my-wallet\" } }\n```\n\n**Via CLI (required flags only):**\n\n```bash\nbunx -y xno-skills@5.0.0 receive --wallet \"my-wallet\"\n```\n\nFull options: [receive](references/receive.md)\n\n**Unopened account — explicit representative:**\nIf no `defaultRepresentative` is configured via `config_set`, pass `representative` explicitly on the first receive.\n\n### ⚠️ CLI `block` commands are NOT senders\n\n`xno-skills block receive` / `block send` output **unsigned hex only** — no PoW, no signing, no broadcast. A block without PoW is always rejected. **Never fall back to these when `wallet_receive` or `wallet_send` fails.**\n\n| | MCP `wallet_receive`/`wallet_send` | CLI `block receive`/`block send` |\n| ------------- | ---------------------------------- | -------------------------------- |\n| Builds block | ✅ | ✅ |\n| Signs via OWS | ✅ | ❌ |\n| Generates PoW | ✅ | ❌ |\n| Broadcasts | ✅ | ❌ |\n\n---\n\n## Sending Funds\n\nThe account must be opened (have a receive block) and have sufficient balance.\n\n**Preflight**: Call `wallet_balance` for the source wallet before each send. If its confirmed balance is insufficient but its receivable amount can cover the requested send, call `wallet_receive` and recheck before sending. Do not receive unrelated pending funds solely because they exist.\n\n**Via MCP:**\n\n```json\n{ \"name\": \"wallet_send\", \"arguments\": { \"wallet\": \"my-wallet\", \"destination\": \"nano_...\", \"amountXno\": \"0.01\" } }\n```\n\n**Via CLI (required flags only):**\n\n```bash\nbunx -y xno-skills@5.0.0 send --wallet \"my-wallet\" --to \"nano_...\" --amount-xno 0.01\n```\n\nFull options: [send](references/send.md)\n\n**Validate the destination address first** (see Address Validation section).\n\n**Spending limits**: Every `wallet_send` and `payment_refund` is gated by `maxSendXno` (default: 1.0 XNO).\n\nIf a send is blocked by this limit, report the current limit and ask the human/operator whether they want to change it. Never call `config_set` to raise `maxSendXno` unless they explicitly asked to modify the spending limit.\n\nOnly when the human/operator explicitly asks to change the spending limit:\n\n```json\n{ \"name\": \"config_set\", \"arguments\": { \"maxSendXno\": \"5.0\" } }\n```\n\n---\n\n## Payment Requests\n\nFor tracked inbound funding workflows:\n\n### Step 1 — Check existing wallets and balance first\n\nIf sufficient funds already exist, skip creating a request.\n\n### Step 2 — Create request\n\n```json\n{\n \"name\": \"payment_create\",\n \"arguments\": { \"walletName\": \"my-wallet\", \"amountXno\": \"0.1\", \"reason\": \"testing payment flow\" }\n}\n```\n\nReturns: `nano:` URI, target address, and request ID.\n\n### Step 3 — Present to operator\n\nTell the user the amount, reason, and address. Offer a QR code (see QR Generation section).\n\n### Step 4 — Wait and receive\n\nAfter the user says funds are sent:\n\n```json\n{ \"name\": \"payment_receive\", \"arguments\": { \"id\": \"\" } }\n```\n\nReturns status: `pending`, `partial`, `funded`, or `received`. If `partial`, tell the user how much more is needed. If multiple Nano sends are pending on the wallet address, inspect `rpc_receivable` and retry `payment_receive` with the intended `sendHash`; never guess which tracked request owns a pending send.\n\n### Step 5 — Confirm\n\nReport the received amount, updated balance, and that funds are ready.\n\n**Rules:**\n\n- Always check existing wallets first; don't create unnecessary wallets.\n- Never claim receipt without calling `payment_receive` — pending is not received in Nano.\n- If the operator asks \"did you get it?\", always re-check.\n\n**History:**\n\n```json\n{ \"name\": \"wallet_history\", \"arguments\": { \"wallet\": \"my-wallet\", \"limit\": 20 } }\n```\n\nFull options: [payment_create](references/payment.create.md), [payment_receive](references/payment.receive.md), [wallet_history](references/history.md)\n\n---\n\n## Returning Funds\n\n**Core safety rule: never guess the refund destination.** Always confirm with the operator.\n\n### Step 1 — Identify what to return\n\nIf linked to a payment request:\n\n```json\n{ \"name\": \"payment_refund\", \"arguments\": { \"id\": \"\", \"execute\": false } }\n```\n\nOtherwise, check history:\n\n```json\n{ \"name\": \"wallet_history\", \"arguments\": { \"wallet\": \"my-wallet\", \"limit\": 20 } }\n```\n\n### Step 2 — Evaluate and confirm\n\n- **Single source**: Present the address and amount. Ask: \"I received X XNO from `nano_...`. Shall I return it?\"\n- **Multiple sources**: List all candidates with amounts, ask which to refund.\n- **No sources**: Report \"No incoming transactions found to refund.\"\n\nAlways show the **full address** — never abbreviate.\n\n### Step 3 — Execute\n\n```json\n{\n \"name\": \"payment_refund\",\n \"arguments\": { \"id\": \"\", \"execute\": true, \"confirmAddress\": \"nano_...\" }\n}\n```\n\nOr use `wallet_send` directly if not linked to a payment request.\n\n**Edge cases:**\n\n- \"Return everything\": list all accounts with balances, confirm before draining.\n- \"Return to [specific address]\": validate the address first, then confirm amount.\n- Spending limit blocks refund: report the current limit and ask whether the human/operator wants to change it. Never raise `maxSendXno` unless they explicitly request that configuration change.\n\nFull options: [payment_refund](references/payment.refund.md)\n\n---\n\n## QR Generation\n\nGenerates a terminal-friendly ASCII QR code for a Nano address, optionally with an amount.\n\n**Via MCP:**\n\n```json\n{ \"name\": \"util_qr\", \"arguments\": { \"address\": \"nano_...\", \"amountXno\": \"1.5\" } }\n```\n\n**Via CLI (required args only):**\n\n```bash\nbunx -y xno-skills@5.0.0 qr nano_1abc...\n```\n\nFull options: [qr](references/qr.md)\n\n> **CRITICAL — stdout truncation**: Agents often have stdout truncated (e.g. ``). To display a full QR code:\n>\n> 1. Use `--json` and parse the `\"qr\"` field, or\n> 2. Redirect to a temp file (`> /tmp/qr.txt`) and read it with a file-reading tool.\n\n---\n\n## Address Validation\n\nAll validation is **offline** — no network required.\n\n**Valid address format:**\n\n- Prefix: `nano_` (65 chars total) or `xrb_` (64 chars, legacy — still valid)\n- Alphabet: `13456789abcdefghijkmnopqrstuwxyz` (no `0`, `l`, `v`, or `i`)\n- Last 8 chars: Blake2b-40 checksum of the public key\n\n**Via MCP:**\n\n```json\n{ \"name\": \"util_validate\", \"arguments\": { \"address\": \"nano_...\" } }\n```\n\n**Via CLI:**\n\n```bash\nbunx -y xno-skills@5.0.0 validate nano_1abc...\n```\n\nFull options: [validate](references/validate.md)\n\n**Always validate before sending XNO to an untrusted address.**\n\n---\n\n## Unit Conversion\n\nXNO uses **30 decimal places**. Floating-point arithmetic is unsafe. Always use this tool.\n\n| Unit | Raw value | Relation |\n| ----- | --------- | ------------ |\n| raw | 1 | base unit |\n| mnano | 10²⁴ | 0.000001 XNO |\n| knano | 10²⁷ | 0.001 XNO |\n| XNO | 10³⁰ | 1 XNO |\n\n**Via MCP:**\n\n```json\n{ \"name\": \"util_convert\", \"arguments\": { \"amount\": \"1.5\", \"from\": \"xno\", \"to\": \"raw\" } }\n```\n\n**Via CLI:**\n\n```bash\nbunx -y xno-skills@5.0.0 convert 1 xno # all units\nbunx -y xno-skills@5.0.0 convert 1 knano\nbunx -y xno-skills@5.0.0 convert 1000000000000000000000000000000 raw\nbunx -y xno-skills@5.0.0 convert 1 xno --json\n```\n\nFull options: [convert](references/convert.md)\n\n---\n\n## Message Signing & Verification (NOMS / ORIS-001)\n\n### OWS-backed signing via MCP — Not yet available\n\nThe `sign_message` and `verify_message` MCP tools require OWS upstream support that has not yet merged. If the user asks you to sign or verify a message using their wallet:\n\n> Sorry, OWS-backed NOMS message signing is not available yet in `xno-mcp`. It depends on an upstream pull request. If you'd like this feature, please add a 👍 at:\n> **https://github.com/open-wallet-standard/core/pull/217**\n\n### Low-level CLI signing (raw private key)\n\nSigning with a raw hex private key works via CLI today, but **the agent must never handle the key value**. A raw private key passed through an LLM context is exposed to logs, memory, and any downstream system — treat it like a password.\n\n**Agent's role**: construct the command with a placeholder and ask the user to run it themselves in their own terminal.\n\nPresent the user with this command to run locally:\n\n```bash\n# Sign — run this yourself, replacing the placeholder with your actual key\nbunx -y xno-skills@5.0.0 sign \"\" --key YOUR_PRIVATE_KEY_HEX\n\n# Sign with JSON output\nbunx -y xno-skills@5.0.0 sign \"\" --key YOUR_PRIVATE_KEY_HEX --json\n```\n\nFor verify, the agent _can_ run this directly (no secret material involved):\n\n```bash\n# Verify\nbunx -y xno-skills@5.0.0 verify \"\" \n\n# Verify with JSON output\nbunx -y xno-skills@5.0.0 verify \"\" --json\n```\n\n**NOMS standard (ORIS-001)**: Signatures are computed over a binary payload with a magic header, ensuring a valid signature cannot be misinterpreted as a Nano transaction block.\n\n**Note**: `verify` accepts both `nano_`/`xrb_` addresses and raw 32-byte hex public keys.\n\n> Do not prompt the user to export their mnemonic to get a private key. Never accept, repeat, or emit a private key value — only use the placeholder pattern above.\n\nFull options: [sign](references/sign.md), [verify](references/verify.md)\n\n---\n\n## Nano Protocol Reference\n\nThe ledger is a block lattice of independent account-chains. Every block is a Universal State Block carrying full account state (balance, representative, previous hash). A send is final immediately; funds become spendable only when the recipient publishes a receive/open block. Pending funds sit unclaimed forever until received.\n\nDeep protocol details — state-block anatomy, open/send/receive/change semantics, PoW thresholds, key/address derivations, representatives & ORV: [blocklattice](references/blocklattice.md)\n\n### Changing Representative\n\n```json\n{ \"name\": \"wallet_change_rep\", \"arguments\": { \"wallet\": \"my-wallet\", \"representative\": \"nano_...\" } }\n```\n\n```bash\nbunx -y xno-skills@5.0.0 change-rep --wallet \"my-wallet\" --representative \"nano_...\"\n```\n\nFull options: [change-rep](references/change-rep.md)\n\n### Explorer Links\n\n- Account: `https://blocklattice.io/account/`\n- Block: `https://blocklattice.io/block/`\n\n---\n\n## Configuration & Defaults\n\nNo configuration required: public RPC nodes, local-first WASM/GPU PoW with remote fallback, default representative, max send `1.0 XNO`. Config lives in a JSON file that reloads before every operation — overrides via `config_set` or `NANO_RPC_URL` / `NANO_WORK_URL` env vars take effect immediately, no restart.\n\nDefaults, override precedence, set/reset semantics: [config](references/config.md)\n\n---\n\n## CLI Reference\n\nAll subcommands support `--json` for machine-readable output and `--help` for full options.\n\n| Subcommand | Description | Reference |\n| --------------------- | ----------------------------------------- | -------------------------------------------------------- |\n| `wallets` | List wallets with Nano accounts | [wallets](references/wallets.md) |\n| `balance` | Show balance and pending amount | [balance](references/balance.md) |\n| `receive` | Receive pending blocks | [receive](references/receive.md) |\n| `send` | Send Nano | [send](references/send.md) |\n| `change-rep` | Change representative | [change-rep](references/change-rep.md) |\n| `submit-block` | Sign and submit prepared block hex | [submit-block](references/submit-block.md) |\n| `history` | Show transaction history | [history](references/history.md) |\n| `info` | Discover account state and representative | [info](references/info.md) |\n| `convert` | Convert between XNO units | [convert](references/convert.md) |\n| `qr` | Generate QR code for address | [qr](references/qr.md) |\n| `validate` | Validate address or block hash | [validate](references/validate.md) |\n| `sign` | Sign NOMS message with private key | [sign](references/sign.md) |\n| `verify` | Verify NOMS message signature | [verify](references/verify.md) |\n| `rpc account-balance` | Fetch account balance via RPC | [rpc_account-balance](references/rpc_account-balance.md) |\n| `rpc receivable` | List receivable blocks via RPC | [rpc_receivable](references/rpc_receivable.md) |\n| `rpc account-info` | Fetch account info via RPC | [rpc_account-info](references/rpc_account-info.md) |\n| `rpc probe-caps` | Probe RPC node capabilities | [rpc_probe-caps](references/rpc_probe-caps.md) |\n| `block send` | Build unsigned send block hex | [block_send](references/block_send.md) |\n| `block receive` | Build unsigned receive block hex | [block_receive](references/block_receive.md) |\n| `block change` | Build unsigned change block hex | [block_change](references/block_change.md) |\n| `mcp` | Start MCP server or view config | [mcp](references/mcp.md) |\n\n---\n\n## Troubleshooting\n\nIf tools are behaving unexpectedly, call `system_diag` first to verify versions and environment:\n\n```json\n{ \"name\": \"system_diag\", \"arguments\": {} }\n```\n\nReturns:\n\n- `xnoSkills.version` — xno-skills version\n- `xnoSkills.path` — resolved executable path\n- `xnoSkills.invocation` — how it was launched (npm-global, npx, bunx, source, etc.)\n- `ows.version` — `@open-wallet-standard/core` version\n- `ows.path` — OWS package location\n- `environment.mockOws` — whether mock mode is active\n- `environment.nanoRpcUrl` — override RPC URL if set\n\n**CLI equivalent:**\n\n```bash\nxno-skills diag\nxno-skills diag --json\n```\n\n`diag` does not make network calls. If `Local PoW Recommended` is `false` or PoW timing looks surprising, run `xno-skills rpc probe-caps ` to verify remote `work_generate` support.\n\nRecovery procedures — **\"RPC request failed: All endpoints exhausted\"**, **MCP crashes / \"Not connected\" errors**, **PoW failures (`POW_FAILED` / timeout)**: [troubleshooting](references/troubleshooting.md)\n\n---\n\n## Quick-Start Example\n\n```\n1. wallet_list: {} → discover \"my-wallet\" exists\n2. wallet_balance: { wallet: \"my-wallet\" } → check balance / pending\n3. wallet_receive: { wallet: \"my-wallet\" } → only if receipt was requested or pending funds are needed\n4. wallet_send: { wallet: \"my-wallet\", destination: \"nano_...\", amountXno: \"0.01\" }\n```\n\nFile v5.0.0:_meta.json\n\n{\n \"ownerId\": \"kn7dfxwgbd2zfpzbcba5n1sj89835ct5\",\n \"slug\": \"nano\",\n \"version\": \"5.0.0\",\n \"publishedAt\": 1791462565129\n}\n\nFile v5.0.0:references/balance.md\n\n# xno-skills balance\n\n```\nUsage: xno-skills balance [options]\n\nShow balance and pending amount\n\nOptions:\n --wallet OWS wallet name\n --count Max receivable blocks to return if pending > 0 (default: 10)\n -j, --json Output in JSON format\n -h, --help display help for command\n```\n\nFile v5.0.0:references/block_change.md\n\n# xno-skills block change\n\n```\nUsage: xno-skills block change [options]\n\nBuild an unsigned change block\n\nOptions:\n -a, --account
Nano account address\n --representative
New Nano representative address\n --url RPC URL override\n -j, --json Output JSON with block hex + metadata\n -h, --help display help for command\n```\n\nFile v5.0.0:references/block_receive.md\n\n# xno-skills block receive\n\n```\nUsage: xno-skills block receive [options]\n\nBuild an unsigned receive block\n\nOptions:\n -a, --account
Recipient Nano address\n --hash Hash of the pending send block\n --amount-raw Amount in raw\n --amount-xno Amount in XNO\n --url RPC URL override\n -j, --json Output JSON with block hex + metadata\n -h, --help display help for command\n```\n\nFile v5.0.0:references/block_send.md\n\n# xno-skills block send\n\n```\nUsage: xno-skills block send [options]\n\nBuild an unsigned send block\n\nOptions:\n -a, --account
Sender Nano address\n -t, --to
Recipient Nano address\n --amount-xno Amount to send in XNO\n --url RPC URL override\n -j, --json Output JSON with block hex + metadata\n -h, --help display help for command\n```\n\nFile v5.0.0:references/blocklattice.md\n\n# Block-Lattice Protocol Reference\n\nOn-demand protocol reference for the Nano skill. Load this when you need block anatomy, PoW thresholds, key derivations, or consensus details — not during routine wallet operations.\n\n## Block-Lattice Mental Model\n\n**The ledger is a block lattice** — a set of completely independent account-chains.\n\n- Every account maintains its own linear chain of state blocks.\n- Only the account owner (private-key holder) can append to their chain.\n- No global mempool, no miners, no gas fees, no block producers.\n- Each block records the **full current state** of its account (balance, representative, previous hash).\n- Total supply is fixed at genesis.\n\n### Universal State Blocks\n\n**All blocks today are Universal State Blocks** (`type: \"state\"`):\n\n```json\n{\n \"type\": \"state\",\n \"account\": \"nano_...\",\n \"previous\": \"64-hex...\", // frontier hash, or \"0\" for open block\n \"representative\": \"nano_...\",\n \"balance\": \"decimal-string\", // new balance in raw (1 XNO = 10^30 raw)\n \"link\": \"...\", // send: destination address; receive: send block hash; change: \"0\"\n \"signature\": \"128-hex...\",\n \"work\": \"16-hex...\"\n}\n```\n\n### The Account-Chain Dance\n\n**Alice sends to Bob**:\n\n1. Alice builds a Send block: `previous` = her frontier, `balance` = old − amount, `link` = Bob's address.\n2. Alice signs + PoW + broadcasts. Funds are **irrevocably deducted** from Alice and become **pending** on Bob's chain.\n\n**Bob must claim**:\n\n1. Bob builds a Receive block: `previous` = his frontier (zeros for open), `balance` = old + amount, `link` = Alice's send block hash.\n2. Bob signs + PoW + broadcasts. Only then are funds spendable.\n\n**Critical**: The send is final for Alice. Funds are not spendable by Bob until his receive block is confirmed. There is no automatic receive. Pending funds sit forever until claimed.\n\n### PoW Thresholds (Epoch v2, 2026)\n\n- Send / Change: `fffffff800000000`\n- Receive / Open / Epoch: `fffffe0000000000`\n\nEpoch blocks use the receive/open threshold above. The historical epoch-1\nthreshold `ffffffc000000000` is legacy-only and must not be selected for\ncurrent mainnet blocks.\n\nPoW input:\n\n- Open block (height 1): `blake2b(nonce || public_key)`\n- All other blocks: `blake2b(nonce || previous_frontier_hash)`\n\n### Representatives & ORV\n\n- Voting weight = balance delegated to a representative.\n- Quorum = >67% of online weight → confirmed → cemented (deterministic finality, typically <1s).\n- Choose representatives with high uptime, low voting weight concentration, and trustworthy operators.\n- Lists: [blocklattice.io/representatives](https://blocklattice.io/representatives), [nanoticker.org](https://nanoticker.org/representatives)\n\n### Data Representations\n\n- **Seed**: 32 bytes (64 hex, uppercase)\n- **Private key**: `blake2b(32, seed || index)`, index as 4-byte big-endian uint\n- **Address**: `nano_` + 52-base32(public key) + 8-base32(Blake2b-40 checksum). Total 65 chars.\n- **Block hash / frontier**: 32 bytes (64 hex)\n- **Signature**: 64 bytes (128 hex), Ed25519 + Blake2b\n- **Work**: 8 bytes (16 hex)\n- **Balance**: always raw units as decimal string in JSON. Never floating-point.\n\nFile v5.0.0:references/change-rep.md\n\n# xno-skills change-rep\n\n```\nUsage: xno-skills change-rep [options]\n\nSubmit a change representative block\n\nOptions:\n --wallet OWS wallet name\n --representative
New Nano representative address\n -j, --json Output in JSON format\n -h, --help display help for command\n```\n\nFile v5.0.0:references/config.md\n\n# Configuration Reference\n\nOn-demand configuration reference for `xno-mcp` / xno-skills. Load this when you need override precedence, env vars, or set/reset semantics.\n\n## Defaults (zero-config)\n\n- Public RPC nodes (`rainstorm.city`, `nanoslo.0x.no/proxy`, `rpc.nano.to`)\n- PoW: local WASM/GPU by default; falls back to remote via the first RPC node when local is not performant\n- Representative: `nano_3arg3asgtigae3xckabaaewkx3bzsh7nwz7jkmjos79ihyaxwphhm6qgjps4`\n- Max per send: `1.0 XNO`\n\n## Config file behavior\n\n`xno-mcp` reads configuration from a JSON file on disk. It reloads the file before every operation, so manual edits take effect immediately. No restart required.\n\n### Override precedence\n\n**Remote PoW URL** (resolved in order):\n\n1. `NANO_WORK_URL` env var\n2. saved config `workUrl`\n3. `NANO_RPC_URL` env var\n4. saved config `rpcUrl`\n5. default primary RPC node\n\n**RPC endpoint list** (normal traffic):\n\n1. explicit tool argument `rpcUrl`\n2. saved config `rpcUrl`\n3. `NANO_RPC_URL` env var\n4. default RPC node list\n\n### Setting values\n\n```json\n{ \"name\": \"config_set\", \"arguments\": { \"workUrl\": \"https://my-node.example/api\" } }\n```\n\n### Resetting values\n\nSetting a string field to `\"\"` or `null` clears the saved override (falls back to defaults):\n\n```json\n{ \"name\": \"config_set\", \"arguments\": { \"workUrl\": \"\" } }\n```\n\nSetting a number field to `null` clears the saved override:\n\n```json\n{ \"name\": \"config_set\", \"arguments\": { \"powTimeoutMs\": null } }\n```\n\nOmitted fields are preserved unchanged.\n\nFile v5.0.0:references/convert.md\n\n# xno-skills convert\n\n```\nUsage: xno-skills convert [options] \n\nConvert between XNO units\n\nArguments:\n amount Value to convert\n from Source unit: xno or raw\n\nOptions:\n -j, --json Output in JSON format\n -h, --help display help for command\n```\n\nFile v5.0.0:references/diag.md\n\n# xno-skills diag\n\n```\nUsage: xno-skills diag [options]\n\nShow diagnostics and system information\n\nOptions:\n -j, --json Output in JSON format\n --retune Rerun PoW profiling and overwrite cached tuning\n -h, --help display help for command\n```\n\nFile v5.0.0:references/history.md\n\n# xno-skills history\n\n```\nUsage: xno-skills history [options]\n\nShow transaction history\n\nOptions:\n --wallet OWS wallet name\n --limit Max entries to show (default: 20)\n -j, --json Output in JSON format\n -h, --help display help for command\n```\n\nArchive v4.7.5: 31 files, 24412 bytes\n\nFiles: references/balance.md (309b), references/block_change.md (401b), references/block_receive.md (472b), references/block_send.md (419b), references/blocklattice.md (3169b), references/change-rep.md (335b), references/config.md (1509b), references/convert.md (275b), references/diag.md (248b), references/history.md (275b), references/info.md (316b), references/mcp.md (1066b), references/payment.create.md (653b), references/payment.receive.md (618b), references/payment.refund.md (987b), references/qr.md (383b), references/receive.md (340b), references/rpc_account-balance.md (442b), references/rpc_account-info.md (354b), references/rpc_probe-caps.md (470b), references/rpc_receivable.md (338b), references/send.md (301b), references/sign.md (299b), references/submit-block.md (366b), references/troubleshooting.md (2560b), references/validate.md (260b), references/verify.md (347b), references/wallets.md (189b), skill-card.md (3503b), SKILL.md (23357b), _meta.json (123b)\n\nFile v4.7.5:SKILL.md\n\n---\nname: nano\ndescription: \"Nano (XNO) cryptocurrency wallet operations, transaction analysis, and explorer lookups. Use for send/receive, balances, pending funds, address validation, unit conversion, tx/hash/account lookup, explorer links, and Nano block-lattice questions. Prefer xno-mcp first; use xno-skills CLI as fallback. Configured OWS wallets ARE the assistant's own wallets — never claim you cannot receive or hold Nano.\"\ntriggers:\n - nano\n - xno\n - nano transaction\n - xno transaction\n - transaction analysis\n - largest transaction\n - nanocurrency\n - nano_\n - xrb_\n - block lattice\n - block explorer\n - explorer link\n - transaction link\n - tx link\n - tx hash\n - block hash\n - xno-skills\n - xno-mcp\n - wallet\n - wallets\n - send nano\n - receive nano\n - send xno\n - receive xno\n - balance\n - check balance\n - pending\n - qr code\n - payment qr\n - nano qr\n - xno qr\n - request payment\n - invoice\n - refund\n - return funds\n - send back\n - convert units\n - raw to xno\n - xno to raw\n - validate address\n - nano address\n - sign message\n - verify message\n - representative\n - pow\n - proof of work\n - open account\n - frontier\n - top up\n - fund wallet\n - how much xno\n - how much nano\ncomplements:\n - ows # Open Wallet Standard — wallet lifecycle (create, import, rename, delete)\nrequires_network: true\n---\n\n# Nano (XNO)\n\n## Scope & Disambiguation\n\nThis skill applies **exclusively to the Nano cryptocurrency protocol** (ticker: XNO, block-lattice ledger, [Nano.org](https://nano.org)).\n\n**Activate for**: nanocurrency, XNO, `nano_` addresses, block-lattice, ORV, xno-skills, xno-mcp.\n\n**Do NOT activate for**: Ledger Nano (hardware wallet), GNU nano (text editor), Nanopay, or any other product that uses the word \"nano\" unrelated to XNO. If ambiguous, ask for clarification.\n\n**Legacy terminology**: \"Rai\", \"RaiBlocks\", `xrb_` addresses — historical only (pre-2018). Always normalize to Nano / `nano_`.\n\n---\n\n## Wallet Ownership & Agent Authority\n\nWallets returned by `wallet_list` are wallets configured for this assistant environment. Treat them as **assistant-controlled wallets** for Nano operations.\n\n**The assistant may**:\n\n- list wallets;\n- inspect balances, pending funds, history, and representatives;\n- receive funds into an assistant-controlled wallet;\n- provide an assistant-controlled receiving address;\n- send funds when the user explicitly requests it.\n\n> **Never say** \"I don't have a wallet\", \"I can't receive funds\", or \"the skill only operates wallets you control\" when `wallet_list` exposes configured wallets.\n\n**Disambiguation**: \"Send me Nano\" means send to an **assistant-controlled wallet**, unless the user names another recipient. Do not reinterpret it as a request to send to a hypothetical personal wallet, and do not refuse on that basis.\n\nBefore any wallet operation, call `wallet_list`. If the user says they want to send Nano to the assistant, list the wallets, identify a suitable receiving wallet/address, and present the full address (never abbreviated). Do not initiate a receive until the user asks to claim funds or a payment workflow requires it.\n\n---\n\n## Global Execution Policy\n\n**This policy applies to every Nano task in this skill, without exception.**\n\n### 1. Prefer MCP tools first\n\nWhen the environment provides `xno-mcp` tools (`wallet_list`, `wallet_send`, `wallet_receive`, `wallet_balance`, `util_convert`, `util_qr`, `util_validate`, `rpc_account_balance`, `payment_create`, etc.) — **always use them first**. They handle signing, PoW, and broadcast automatically via OWS.\n\nIf the client supports MCP, set it up as a \"stdio\" type MCP server.\n\n**Preferred — global install** (avoids `npx` concurrency issues that cause handshake failures):\n\n npm install -g xno-skills@4.7.5\n xno-skills mcp\n\n**Fallback** (only if global install is not possible):\n\n npx -y xno-skills@4.7.5 mcp\n\n> **Why not `npx` by default?** When multiple agent sessions start concurrently, `npx` can fail during package resolution — the second process exits before the MCP handshake completes. A global install eliminates this race.\n\nMCP is the primary execution path because tools, schemas, and results are structured for the client. Use the included CLI script (`xno-skills`) only as a fallback when MCP is unavailable or the client cannot attach MCP servers. MCP and the CLI target EXACTLY the same underlying code paths — two access paths, not two different products.\n\n### 2. Fall back to CLI only when MCP is unavailable\n\nIf `xno-mcp` tools are not available, or the user explicitly asks for CLI usage, use the `xno-skills` CLI in this priority order:\n\n```\n1. xno-skills (global install — preferred)\n2. bunx -y xno-skills@4.7.5 \n3. pnpm dlx xno-skills@4.7.5 \n4. npx -y xno-skills@4.7.5 \n```\n\nIf the global `xno-skills` binary is not available, fall through to the next option. Always pin the version (`@4.5.2`) with `bunx`/`pnpm dlx`/`npx` to prevent interactive prompts from freezing.\n\nBefore guessing a subcommand, run `--help`:\n```bash\nxno-skills --help # or: bunx -y xno-skills@4.7.5 --help\n```\n\n### 3. Wallet lifecycle → `ows` skill only\n\nFor wallet **create, import, rename, or delete**: delegate to the `ows` skill. Do not invoke `ows` CLI commands directly from this skill.\n\n### 4. Never do any of the following\n\n- Write custom Node.js/TypeScript scripts to interact with the Nano protocol.\n- Use `curl` for RPC calls.\n- Attempt to manually compute or supply Proof of Work. PoW is automatic.\n- Use `npx` to fetch random or third-party npm packages as workarounds.\n- Export mnemonics or seeds (`ows wallet export`). OWS keeps secrets encrypted. The entire point of OWS is that the agent never sees the private key.\n- Change `maxSendXno` unless the human/operator explicitly asks to change the spending limit. A blocked send or refund is not permission to raise the limit automatically.\n\n### 5. Prefer `blocklattice.io` for explorer links\n\nWhen the user asks for an account, block, transaction, or explorer link, always prefer `blocklattice.io` unless they explicitly request another explorer.\n\n---\n\n## Safety Rules\n\n- **State verification**: Always fetch balance and frontier via RPC before manually building a block. Never hallucinate previous hashes.\n- **PoW is automatic**: MCP tools and the CLI both handle PoW internally. Never attempt to supply or generate PoW manually.\n- **Pre-send state**: Before `wallet_send`, inspect the source wallet's confirmed balance and total receivable amount with `wallet_balance`. If confirmed funds cannot cover the requested send and receivables are needed, call `wallet_receive`, then recheck. Do not submit receive blocks merely because unrelated funds are pending.\n- **Persistence on \"Account not found\"**: This is normal for a brand-new, unopened account. Continue — `wallet_receive` will automatically build an open block (sets `previous` to zeros), sign it via OWS, generate PoW, and broadcast. Never conclude you are unauthorized or that OWS cannot sign Nano blocks.\n- **No mnemonic exports**: Never call `ows wallet export` or suggest exporting to a third-party wallet unless the user explicitly commands it.\n- **Supply chain**: Only use `xno-skills@4.7.5` and `@open-wallet-standard/core`. No other npm packages.\n- **Stop-loss**: If you have made 5 tool calls without completing the operation, stop and report what you tried, what failed, and ask for guidance. Hard limits: max 3 retries of the same failing tool; max 2 `config_set` RPC endpoint switches.\n\n---\n\n## Wallet Discovery\n\n> **CRITICAL: Always call `wallet_list` first.** Before any wallet operation, identify which OWS wallets exist. Never assume a wallet name.\n\n```json\n{ \"name\": \"wallet_list\", \"arguments\": {} }\n```\n\nTo **create** a new wallet, delegate to the `ows` skill. Then return here for all Nano operations.\n\n**MCP Resources** (passive reads, no tool call needed):\n- `wallet://{name}` — wallet summary and primary account state\n- `wallet://{name}/account/{index}` — pending blocks and details for a specific account index\n\n---\n\n## Reading Balances\n\n**Via MCP tools:**\n```json\n{ \"name\": \"wallet_balance\", \"arguments\": { \"wallet\": \"my-wallet\" } }\n{ \"name\": \"rpc_account_balance\", \"arguments\": { \"address\": \"nano_...\" } }\n```\n\n**Via CLI (required flags only):**\n```bash\nbunx -y xno-skills@4.7.5 balance --wallet \"my-wallet\"\nbunx -y xno-skills@4.7.5 rpc account-balance
\n```\n\nFull options: [balance](references/balance.md), [rpc_account-balance](references/rpc_account-balance.md)\n\n**Public zero-config RPC nodes** (used automatically by xno-skills defaults):\n- `https://rainstorm.city/api` (primary)\n- `https://nanoslo.0x.no/proxy` (secondary)\n- `https://rpc.nano.to` (tertiary)\n\nPending funds are not spendable. Receive them only when the user asks to claim them or they are needed for the requested operation (see Receiving Funds section).\n\n---\n\n## Receiving Funds (Including Unopened Accounts)\n\nA Nano transfer shows as **pending** until the recipient publishes a receive block. Funds are not spendable until received.\n\n**A new / \"unopened\" account chain is normal.** It returns `\"Account not found\"` from RPC. This is not an error — `wallet_receive` will automatically build an open block (sets `previous` to zeros), sign it via OWS, generate PoW, and broadcast.\n\n> **OWS DOES support Nano block signing.** Never assume otherwise.\n\nWhen receipt is requested or needed to fund a send, call `wallet_receive`. Do not treat an unopened account as a blocker: `wallet_receive` handles the open block.\n\n**Via MCP:**\n```json\n{ \"name\": \"wallet_receive\", \"arguments\": { \"wallet\": \"my-wallet\" } }\n```\n\n**Via CLI (required flags only):**\n```bash\nbunx -y xno-skills@4.7.5 receive --wallet \"my-wallet\"\n```\n\nFull options: [receive](references/receive.md)\n\n**Unopened account — explicit representative:**\nIf no `defaultRepresentative` is configured via `config_set`, pass `representative` explicitly on the first receive.\n\n### ⚠️ CLI `block` commands are NOT senders\n\n`xno-skills block receive` / `block send` output **unsigned hex only** — no PoW, no signing, no broadcast. A block without PoW is always rejected. **Never fall back to these when `wallet_receive` or `wallet_send` fails.**\n\n| | MCP `wallet_receive`/`wallet_send` | CLI `block receive`/`block send` |\n|---|---|---|\n| Builds block | ✅ | ✅ |\n| Signs via OWS | ✅ | ❌ |\n| Generates PoW | ✅ | ❌ |\n| Broadcasts | ✅ | ❌ |\n\n---\n\n## Sending Funds\n\nThe account must be opened (have a receive block) and have sufficient balance.\n\n**Preflight**: Call `wallet_balance` for the source wallet before each send. If its confirmed balance is insufficient but its receivable amount can cover the requested send, call `wallet_receive` and recheck before sending. Do not receive unrelated pending funds solely because they exist.\n\n**Via MCP:**\n```json\n{ \"name\": \"wallet_send\", \"arguments\": { \"wallet\": \"my-wallet\", \"destination\": \"nano_...\", \"amountXno\": \"0.01\" } }\n```\n\n**Via CLI (required flags only):**\n```bash\nbunx -y xno-skills@4.7.5 send --wallet \"my-wallet\" --to \"nano_...\" --amount-xno 0.01\n```\n\nFull options: [send](references/send.md)\n\n**Validate the destination address first** (see Address Validation section).\n\n**Spending limits**: Every `wallet_send` and `payment_refund` is gated by `maxSendXno` (default: 1.0 XNO).\n\nIf a send is blocked by this limit, report the current limit and ask the human/operator whether they want to change it. Never call `config_set` to raise `maxSendXno` unless they explicitly asked to modify the spending limit.\n\nOnly when the human/operator explicitly asks to change the spending limit:\n```json\n{ \"name\": \"config_set\", \"arguments\": { \"maxSendXno\": \"5.0\" } }\n```\n\n---\n\n## Payment Requests\n\nFor tracked inbound funding workflows:\n\n### Step 1 — Check existing wallets and balance first\nIf sufficient funds already exist, skip creating a request.\n\n### Step 2 — Create request\n```json\n{\n \"name\": \"payment_create\",\n \"arguments\": { \"walletName\": \"my-wallet\", \"amountXno\": \"0.1\", \"reason\": \"testing payment flow\" }\n}\n```\nReturns: `nano:` URI, target address, and request ID.\n\n### Step 3 — Present to operator\nTell the user the amount, reason, and address. Offer a QR code (see QR Generation section).\n\n### Step 4 — Wait and receive\nAfter the user says funds are sent:\n```json\n{ \"name\": \"payment_receive\", \"arguments\": { \"id\": \"\" } }\n```\nReturns status: `pending`, `partial`, `funded`, or `received`. If `partial`, tell the user how much more is needed.\n\n### Step 5 — Confirm\nReport the received amount, updated balance, and that funds are ready.\n\n**Rules:**\n- Always check existing wallets first; don't create unnecessary wallets.\n- Never claim receipt without calling `payment_receive` — pending is not received in Nano.\n- If the operator asks \"did you get it?\", always re-check.\n\n**History:**\n```json\n{ \"name\": \"wallet_history\", \"arguments\": { \"wallet\": \"my-wallet\", \"limit\": 20 } }\n```\n\nFull options: [payment_create](references/payment.create.md), [payment_receive](references/payment.receive.md), [wallet_history](references/history.md)\n\n---\n\n## Returning Funds\n\n**Core safety rule: never guess the refund destination.** Always confirm with the operator.\n\n### Step 1 — Identify what to return\n\nIf linked to a payment request:\n```json\n{ \"name\": \"payment_refund\", \"arguments\": { \"id\": \"\", \"execute\": false } }\n```\n\nOtherwise, check history:\n```json\n{ \"name\": \"wallet_history\", \"arguments\": { \"wallet\": \"my-wallet\", \"limit\": 20 } }\n```\n\n### Step 2 — Evaluate and confirm\n\n- **Single source**: Present the address and amount. Ask: \"I received X XNO from `nano_...`. Shall I return it?\"\n- **Multiple sources**: List all candidates with amounts, ask which to refund.\n- **No sources**: Report \"No incoming transactions found to refund.\"\n\nAlways show the **full address** — never abbreviate.\n\n### Step 3 — Execute\n\n```json\n{\n \"name\": \"payment_refund\",\n \"arguments\": { \"id\": \"\", \"execute\": true, \"confirmAddress\": \"nano_...\" }\n}\n```\n\nOr use `wallet_send` directly if not linked to a payment request.\n\n**Edge cases:**\n- \"Return everything\": list all accounts with balances, confirm before draining.\n- \"Return to [specific address]\": validate the address first, then confirm amount.\n- Spending limit blocks refund: report the current limit and ask whether the human/operator wants to change it. Never raise `maxSendXno` unless they explicitly request that configuration change.\n\nFull options: [payment_refund](references/payment.refund.md)\n\n---\n\n## QR Generation\n\nGenerates a terminal-friendly ASCII QR code for a Nano address, optionally with an amount.\n\n**Via MCP:**\n```json\n{ \"name\": \"util_qr\", \"arguments\": { \"address\": \"nano_...\", \"amountXno\": \"1.5\" } }\n```\n\n**Via CLI (required args only):**\n```bash\nbunx -y xno-skills@4.7.5 qr nano_1abc...\n```\n\nFull options: [qr](references/qr.md)\n\n> **CRITICAL — stdout truncation**: Agents often have stdout truncated (e.g. ``). To display a full QR code:\n> 1. Use `--json` and parse the `\"qr\"` field, or\n> 2. Redirect to a temp file (`> /tmp/qr.txt`) and read it with a file-reading tool.\n\n---\n\n## Address Validation\n\nAll validation is **offline** — no network required.\n\n**Valid address format:**\n- Prefix: `nano_` (65 chars total) or `xrb_` (64 chars, legacy — still valid)\n- Alphabet: `13456789abcdefghijkmnopqrstuwxyz` (no `0`, `l`, `v`, or `i`)\n- Last 8 chars: Blake2b-40 checksum of the public key\n\n**Via MCP:**\n```json\n{ \"name\": \"util_validate\", \"arguments\": { \"address\": \"nano_...\" } }\n```\n\n**Via CLI:**\n```bash\nbunx -y xno-skills@4.7.5 validate nano_1abc...\n```\n\nFull options: [validate](references/validate.md)\n\n**Always validate before sending XNO to an untrusted address.**\n\n---\n\n## Unit Conversion\n\nXNO uses **30 decimal places**. Floating-point arithmetic is unsafe. Always use this tool.\n\n| Unit | Raw value | Relation |\n|---|---|---|\n| raw | 1 | base unit |\n| mnano | 10²⁴ | 0.000001 XNO |\n| knano | 10²⁷ | 0.001 XNO |\n| XNO | 10³⁰ | 1 XNO |\n\n**Via MCP:**\n```json\n{ \"name\": \"util_convert\", \"arguments\": { \"amount\": \"1.5\", \"from\": \"xno\", \"to\": \"raw\" } }\n```\n\n**Via CLI:**\n```bash\nbunx -y xno-skills@4.7.5 convert 1 xno # all units\nbunx -y xno-skills@4.7.5 convert 1 knano\nbunx -y xno-skills@4.7.5 convert 1000000000000000000000000000000 raw\nbunx -y xno-skills@4.7.5 convert 1 xno --json\n```\n\nFull options: [convert](references/convert.md)\n\n---\n\n## Message Signing & Verification (NOMS / ORIS-001)\n\n### OWS-backed signing via MCP — Not yet available\n\nThe `sign_message` and `verify_message` MCP tools require OWS upstream support that has not yet merged. If the user asks you to sign or verify a message using their wallet:\n\n> Sorry, OWS-backed NOMS message signing is not available yet in `xno-mcp`. It depends on an upstream pull request. If you'd like this feature, please add a 👍 at:\n> **https://github.com/open-wallet-standard/core/pull/217**\n\n### Low-level CLI signing (raw private key)\n\nSigning with a raw hex private key works via CLI today, but **the agent must never handle the key value**. A raw private key passed through an LLM context is exposed to logs, memory, and any downstream system — treat it like a password.\n\n**Agent's role**: construct the command with a placeholder and ask the user to run it themselves in their own terminal.\n\nPresent the user with this command to run locally:\n\n```bash\n# Sign — run this yourself, replacing the placeholder with your actual key\nbunx -y xno-skills@4.7.5 sign \"\" --key YOUR_PRIVATE_KEY_HEX\n\n# Sign with JSON output\nbunx -y xno-skills@4.7.5 sign \"\" --key YOUR_PRIVATE_KEY_HEX --json\n```\n\nFor verify, the agent *can* run this directly (no secret material involved):\n\n```bash\n# Verify\nbunx -y xno-skills@4.7.5 verify \"\" \n\n# Verify with JSON output\nbunx -y xno-skills@4.7.5 verify \"\" --json\n```\n\n**NOMS standard (ORIS-001)**: Signatures are computed over a binary payload with a magic header, ensuring a valid signature cannot be misinterpreted as a Nano transaction block.\n\n**Note**: `verify` accepts both `nano_`/`xrb_` addresses and raw 32-byte hex public keys.\n\n> Do not prompt the user to export their mnemonic to get a private key. Never accept, repeat, or emit a private key value — only use the placeholder pattern above.\n\nFull options: [sign](references/sign.md), [verify](references/verify.md)\n\n---\n\n## Nano Protocol Reference\n\nThe ledger is a block lattice of independent account-chains. Every block is a Universal State Block carrying full account state (balance, representative, previous hash). A send is final immediately; funds become spendable only when the recipient publishes a receive/open block. Pending funds sit unclaimed forever until received.\n\nDeep protocol details — state-block anatomy, open/send/receive/change semantics, PoW thresholds, key/address derivations, representatives & ORV: [blocklattice](references/blocklattice.md)\n\n### Changing Representative\n\n```json\n{ \"name\": \"wallet_change_rep\", \"arguments\": { \"wallet\": \"my-wallet\", \"representative\": \"nano_...\" } }\n```\n```bash\nbunx -y xno-skills@4.7.5 change-rep --wallet \"my-wallet\" --representative \"nano_...\"\n```\n\nFull options: [change-rep](references/change-rep.md)\n\n### Explorer Links\n\n- Account: `https://blocklattice.io/account/`\n- Block: `https://blocklattice.io/block/`\n\n---\n\n## Configuration & Defaults\n\nNo configuration required: public RPC nodes, local-first WASM/GPU PoW with remote fallback, default representative, max send `1.0 XNO`. Config lives in a JSON file that reloads before every operation — overrides via `config_set` or `NANO_RPC_URL` / `NANO_WORK_URL` env vars take effect immediately, no restart.\n\nDefaults, override precedence, set/reset semantics: [config](references/config.md)\n\n---\n\n## CLI Reference\n\nAll subcommands support `--json` for machine-readable output and `--help` for full options.\n\n| Subcommand | Description | Reference |\n|---|---|---|\n| `wallets` | List wallets with Nano accounts | [wallets](references/wallets.md) |\n| `balance` | Show balance and pending amount | [balance](references/balance.md) |\n| `receive` | Receive pending blocks | [receive](references/receive.md) |\n| `send` | Send Nano | [send](references/send.md) |\n| `change-rep` | Change representative | [change-rep](references/change-rep.md) |\n| `submit-block` | Sign and submit prepared block hex | [submit-block](references/submit-block.md) |\n| `history` | Show transaction history | [history](references/history.md) |\n| `info` | Discover account state and representative | [info](references/info.md) |\n| `convert` | Convert between XNO units | [convert](references/convert.md) |\n| `qr` | Generate QR code for address | [qr](references/qr.md) |\n| `validate` | Validate address or block hash | [validate](references/validate.md) |\n| `sign` | Sign NOMS message with private key | [sign](references/sign.md) |\n| `verify` | Verify NOMS message signature | [verify](references/verify.md) |\n| `rpc account-balance` | Fetch account balance via RPC | [rpc_account-balance](references/rpc_account-balance.md) |\n| `rpc receivable` | List receivable blocks via RPC | [rpc_receivable](references/rpc_receivable.md) |\n| `rpc account-info` | Fetch account info via RPC | [rpc_account-info](references/rpc_account-info.md) |\n| `rpc probe-caps` | Probe RPC node capabilities | [rpc_probe-caps](references/rpc_probe-caps.md) |\n| `block send` | Build unsigned send block hex | [block_send](references/block_send.md) |\n| `block receive` | Build unsigned receive block hex | [block_receive](references/block_receive.md) |\n| `block change` | Build unsigned change block hex | [block_change](references/block_change.md) |\n| `mcp` | Start MCP server or view config | [mcp](references/mcp.md) |\n\n---\n\n## Troubleshooting\n\nIf tools are behaving unexpectedly, call `system_diag` first to verify versions and environment:\n\n```json\n{ \"name\": \"system_diag\", \"arguments\": {} }\n```\n\nReturns:\n- `xnoSkills.version` — xno-skills version\n- `xnoSkills.path` — resolved executable path\n- `xnoSkills.invocation` — how it was launched (npm-global, npx, bunx, source, etc.)\n- `ows.version` — `@open-wallet-standard/core` version\n- `ows.path` — OWS package location\n- `environment.mockOws` — whether mock mode is active\n- `environment.nanoRpcUrl` — override RPC URL if set\n\n**CLI equivalent:**\n```bash\nxno-skills diag\nxno-skills diag --json\n```\n\n`diag` does not make network calls. If `Local PoW Recommended` is `false` or PoW timing looks surprising, run `xno-skills rpc probe-caps ` to verify remote `work_generate` support.\n\nRecovery procedures — **\"RPC request failed: All endpoints exhausted\"**, **MCP crashes / \"Not connected\" errors**, **PoW failures (`POW_FAILED` / timeout)**: [troubleshooting](references/troubleshooting.md)\n\n---\n\n## Quick-Start Example\n\n```\n1. wallet_list: {} → discover \"my-wallet\" exists\n2. wallet_balance: { wallet: \"my-wallet\" } → check balance / pending\n3. wallet_receive: { wallet: \"my-wallet\" } → only if receipt was requested or pending funds are needed\n4. wallet_send: { wallet: \"my-wallet\", destination: \"nano_...\", amountXno: \"0.01\" }\n```\n\nFile v4.7.5:_meta.json\n\n{\n \"ownerId\": \"kn7dfxwgbd2zfpzbcba5n1sj89835ct5\",\n \"slug\": \"nano\",\n \"version\": \"4.7.5\",\n \"publishedAt\": 1788191190002\n}\n\nFile v4.7.5:references/balance.md\n\n# xno-skills balance\n\n```\nUsage: xno-skills balance [options]\n\nShow balance and pending amount\n\nOptions:\n --wallet OWS wallet name\n --count Max receivable blocks to return if pending > 0 (default: 10)\n -j, --json Output in JSON format\n -h, --help display help for command\n```\n\nFile v4.7.5:references/block_change.md\n\n# xno-skills block change\n\n```\nUsage: xno-skills block change [options]\n\nBuild an unsigned change block\n\nOptions:\n -a, --account
Nano account address\n --representative
New Nano representative address\n --url RPC URL override\n -j, --json Output JSON with block hex + metadata\n -h, --help display help for command\n```\n\nFile v4.7.5:references/block_receive.md\n\n# xno-skills block receive\n\n```\nUsage: xno-skills block receive [options]\n\nBuild an unsigned receive block\n\nOptions:\n -a, --account
Recipient Nano address\n --hash Hash of the pending send block\n --amount-raw Amount in raw\n --amount-xno Amount in XNO\n --url RPC URL override\n -j, --json Output JSON with block hex + metadata\n -h, --help display help for command\n```\n\nFile v4.7.5:references/block_send.md\n\n# xno-skills block send\n\n```\nUsage: xno-skills block send [options]\n\nBuild an unsigned send block\n\nOptions:\n -a, --account
Sender Nano address\n -t, --to
Recipient Nano address\n --amount-xno Amount to send in XNO\n --url RPC URL override\n -j, --json Output JSON with block hex + metadata\n -h, --help display help for command\n```\n\nFile v4.7.5:references/blocklattice.md\n\n# Block-Lattice Protocol Reference\n\nOn-demand protocol reference for the Nano skill. Load this when you need block anatomy, PoW thresholds, key derivations, or consensus details — not during routine wallet operations.\n\n## Block-Lattice Mental Model\n\n**The ledger is a block lattice** — a set of completely independent account-chains.\n\n- Every account maintains its own linear chain of state blocks.\n- Only the account owner (private-key holder) can append to their chain.\n- No global mempool, no miners, no gas fees, no block producers.\n- Each block records the **full current state** of its account (balance, representative, previous hash).\n- Total supply is fixed at genesis.\n\n### Universal State Blocks\n\n**All blocks today are Universal State Blocks** (`type: \"state\"`):\n\n```json\n{\n \"type\": \"state\",\n \"account\": \"nano_...\",\n \"previous\": \"64-hex...\", // frontier hash, or \"0\" for open block\n \"representative\": \"nano_...\",\n \"balance\": \"decimal-string\", // new balance in raw (1 XNO = 10^30 raw)\n \"link\": \"...\", // send: destination address; receive: send block hash; change: \"0\"\n \"signature\": \"128-hex...\",\n \"work\": \"16-hex...\"\n}\n```\n\n### The Account-Chain Dance\n\n**Alice sends to Bob**:\n1. Alice builds a Send block: `previous` = her frontier, `balance` = old − amount, `link` = Bob's address.\n2. Alice signs + PoW + broadcasts. Funds are **irrevocably deducted** from Alice and become **pending** on Bob's chain.\n\n**Bob must claim**:\n1. Bob builds a Receive block: `previous` = his frontier (zeros for open), `balance` = old + amount, `link` = Alice's send block hash.\n2. Bob signs + PoW + broadcasts. Only then are funds spendable.\n\n**Critical**: The send is final for Alice. Funds are not spendable by Bob until his receive block is confirmed. There is no automatic receive. Pending funds sit forever until claimed.\n\n### PoW Thresholds (Epoch v2, 2026)\n\n- Send / Change: `fffffff800000000`\n- Receive / Open / Epoch: `fffffe0000000000`\n\nEpoch blocks use the receive/open threshold above. The historical epoch-1\nthreshold `ffffffc000000000` is legacy-only and must not be selected for\ncurrent mainnet blocks.\n\nPoW input:\n- Open block (height 1): `blake2b(nonce || public_key)`\n- All other blocks: `blake2b(nonce || previous_frontier_hash)`\n\n### Representatives & ORV\n\n- Voting weight = balance delegated to a representative.\n- Quorum = >67% of online weight → confirmed → cemented (deterministic finality, typically <1s).\n- Choose representatives with high uptime, low voting weight concentration, and trustworthy operators.\n- Lists: [blocklattice.io/representatives](https://blocklattice.io/representatives), [nanoticker.org](https://nanoticker.org/representatives)\n\n### Data Representations\n\n- **Seed**: 32 bytes (64 hex, uppercase)\n- **Private key**: `blake2b(32, seed || index)`, index as 4-byte big-endian uint\n- **Address**: `nano_` + 52-base32(public key) + 8-base32(Blake2b-40 checksum). Total 65 chars.\n- **Block hash / frontier**: 32 bytes (64 hex)\n- **Signature**: 64 bytes (128 hex), Ed25519 + Blake2b\n- **Work**: 8 bytes (16 hex)\n- **Balance**: always raw units as decimal string in JSON. Never floating-point.\n\nFile v4.7.5:references/change-rep.md\n\n# xno-skills change-rep\n\n```\nUsage: xno-skills change-rep [options]\n\nSubmit a change representative block\n\nOptions:\n --wallet OWS wallet name\n --representative
New Nano representative address\n -j, --json Output in JSON format\n -h, --help display help for command\n```\n\nFile v4.7.5:references/config.md\n\n# Configuration Reference\n\nOn-demand configuration reference for `xno-mcp` / xno-skills. Load this when you need override precedence, env vars, or set/reset semantics.\n\n## Defaults (zero-config)\n\n- Public RPC nodes (`rainstorm.city`, `nanoslo.0x.no/proxy`, `rpc.nano.to`)\n- PoW: local WASM/GPU by default; falls back to remote via the first RPC node when local is not performant\n- Representative: `nano_3arg3asgtigae3xckabaaewkx3bzsh7nwz7jkmjos79ihyaxwphhm6qgjps4`\n- Max per send: `1.0 XNO`\n\n## Config file behavior\n\n`xno-mcp` reads configuration from a JSON file on disk. It reloads the file before every operation, so manual edits take effect immediately. No restart required.\n\n### Override precedence\n\n**Remote PoW URL** (resolved in order):\n1. `NANO_WORK_URL` env var\n2. saved config `workUrl`\n3. `NANO_RPC_URL` env var\n4. saved config `rpcUrl`\n5. default primary RPC node\n\n**RPC endpoint list** (normal traffic):\n1. explicit tool argument `rpcUrl`\n2. saved config `rpcUrl`\n3. `NANO_RPC_URL` env var\n4. default RPC node list\n\n### Setting values\n\n```json\n{ \"name\": \"config_set\", \"arguments\": { \"workUrl\": \"https://my-node.example/api\" } }\n```\n\n### Resetting values\n\nSetting a string field to `\"\"` or `null` clears the saved override (falls back to defaults):\n```json\n{ \"name\": \"config_set\", \"arguments\": { \"workUrl\": \"\" } }\n```\n\nSetting a number field to `null` clears the saved override:\n```json\n{ \"name\": \"config_set\", \"arguments\": { \"powTimeoutMs\": null } }\n```\n\nOmitted fields are preserved unchanged.\n\nFile v4.7.5:references/convert.md\n\n# xno-skills convert\n\n```\nUsage: xno-skills convert [options] \n\nConvert between XNO units\n\nArguments:\n amount Value to convert\n from Source unit: xno or raw\n\nOptions:\n -j, --json Output in JSON format\n -h, --help display help for command\n```\n\nFile v4.7.5:references/diag.md\n\n# xno-skills diag\n\n```\nUsage: xno-skills diag [options]\n\nShow diagnostics and system information\n\nOptions:\n -j, --json Output in JSON format\n --retune Rerun PoW profiling and overwrite cached tuning\n -h, --help display help for command\n```\n\nFile v4.7.5:references/history.md\n\n# xno-skills history\n\n```\nUsage: xno-skills history [options]\n\nShow transaction history\n\nOptions:\n --wallet OWS wallet name\n --limit Max entries to show (default: 20)\n -j, --json Output in JSON format\n -h, --help display help for command\n```\n\nArchive v4.7.4: 31 files, 24261 bytes\n\nFiles: references/balance.md (309b), references/block_change.md (401b), references/block_receive.md (472b), references/block_send.md (419b), references/blocklattice.md (3169b), references/change-rep.md (335b), references/config.md (1509b), references/convert.md (275b), references/diag.md (248b), references/history.md (275b), references/info.md (316b), references/mcp.md (1066b), references/payment.create.md (653b), references/payment.receive.md (618b), references/payment.refund.md (987b), references/qr.md (383b), references/receive.md (340b), references/rpc_account-balance.md (442b), references/rpc_account-info.md (354b), references/rpc_probe-caps.md (470b), references/rpc_receivable.md (338b), references/send.md (301b), references/sign.md (299b), references/submit-block.md (366b), references/troubleshooting.md (2560b), references/validate.md (260b), references/verify.md (347b), references/wallets.md (189b), skill-card.md (3175b), SKILL.md (23357b), _meta.json (123b)\n\nFile v4.7.4:SKILL.md\n\n---\nname: nano\ndescription: \"Nano (XNO) cryptocurrency wallet operations, transaction analysis, and explorer lookups. Use for send/receive, balances, pending funds, address validation, unit conversion, tx/hash/account lookup, explorer links, and Nano block-lattice questions. Prefer xno-mcp first; use xno-skills CLI as fallback. Configured OWS wallets ARE the assistant's own wallets — never claim you cannot receive or hold Nano.\"\ntriggers:\n - nano\n - xno\n - nano transaction\n - xno transaction\n - transaction analysis\n - largest transaction\n - nanocurrency\n - nano_\n - xrb_\n - block lattice\n - block explorer\n - explorer link\n - transaction link\n - tx link\n - tx hash\n - block hash\n - xno-skills\n - xno-mcp\n - wallet\n - wallets\n - send nano\n - receive nano\n - send xno\n - receive xno\n - balance\n - check balance\n - pending\n - qr code\n - payment qr\n - nano qr\n - xno qr\n - request payment\n - invoice\n - refund\n - return funds\n - send back\n - convert units\n - raw to xno\n - xno to raw\n - validate address\n - nano address\n - sign message\n - verify message\n - representative\n - pow\n - proof of work\n - open account\n - frontier\n - top up\n - fund wallet\n - how much xno\n - how much nano\ncomplements:\n - ows # Open Wallet Standard — wallet lifecycle (create, import, rename, delete)\nrequires_network: true\n---\n\n# Nano (XNO)\n\n## Scope & Disambiguation\n\nThis skill applies **exclusively to the Nano cryptocurrency protocol** (ticker: XNO, block-lattice ledger, [Nano.org](https://nano.org)).\n\n**Activate for**: nanocurrency, XNO, `nano_` addresses, block-lattice, ORV, xno-skills, xno-mcp.\n\n**Do NOT activate for**: Ledger Nano (hardware wallet), GNU nano (text editor), Nanopay, or any other product that uses the word \"nano\" unrelated to XNO. If ambiguous, ask for clarification.\n\n**Legacy terminology**: \"Rai\", \"RaiBlocks\", `xrb_` addresses — historical only (pre-2018). Always normalize to Nano / `nano_`.\n\n---\n\n## Wallet Ownership & Agent Authority\n\nWallets returned by `wallet_list` are wallets configured for this assistant environment. Treat them as **assistant-controlled wallets** for Nano operations.\n\n**The assistant may**:\n\n- list wallets;\n- inspect balances, pending funds, history, and representatives;\n- receive funds into an assistant-controlled wallet;\n- provide an assistant-controlled receiving address;\n- send funds when the user explicitly requests it.\n\n> **Never say** \"I don't have a wallet\", \"I can't receive funds\", or \"the skill only operates wallets you control\" when `wallet_list` exposes configured wallets.\n\n**Disambiguation**: \"Send me Nano\" means send to an **assistant-controlled wallet**, unless the user names another recipient. Do not reinterpret it as a request to send to a hypothetical personal wallet, and do not refuse on that basis.\n\nBefore any wallet operation, call `wallet_list`. If the user says they want to send Nano to the assistant, list the wallets, identify a suitable receiving wallet/address, and present the full address (never abbreviated). Do not initiate a receive until the user asks to claim funds or a payment workflow requires it.\n\n---\n\n## Global Execution Policy\n\n**This policy applies to every Nano task in this skill, without exception.**\n\n### 1. Prefer MCP tools first\n\nWhen the environment provides `xno-mcp` tools (`wallet_list`, `wallet_send`, `wallet_receive`, `wallet_balance`, `util_convert`, `util_qr`, `util_validate`, `rpc_account_balance`, `payment_create`, etc.) — **always use them first**. They handle signing, PoW, and broadcast automatically via OWS.\n\nIf the client supports MCP, set it up as a \"stdio\" type MCP server.\n\n**Preferred — global install** (avoids `npx` concurrency issues that cause handshake failures):\n\n npm install -g xno-skills@4.7.4\n xno-skills mcp\n\n**Fallback** (only if global install is not possible):\n\n npx -y xno-skills@4.7.4 mcp\n\n> **Why not `npx` by default?** When multiple agent sessions start concurrently, `npx` can fail during package resolution — the second process exits before the MCP handshake completes. A global install eliminates this race.\n\nMCP is the primary execution path because tools, schemas, and results are structured for the client. Use the included CLI script (`xno-skills`) only as a fallback when MCP is unavailable or the client cannot attach MCP servers. MCP and the CLI target EXACTLY the same underlying code paths — two access paths, not two different products.\n\n### 2. Fall back to CLI only when MCP is unavailable\n\nIf `xno-mcp` tools are not available, or the user explicitly asks for CLI usage, use the `xno-skills` CLI in this priority order:\n\n```\n1. xno-skills (global install — preferred)\n2. bunx -y xno-skills@4.7.4 \n3. pnpm dlx xno-skills@4.7.4 \n4. npx -y xno-skills@4.7.4 \n```\n\nIf the global `xno-skills` binary is not available, fall through to the next option. Always pin the version (`@4.5.2`) with `bunx`/`pnpm dlx`/`npx` to prevent interactive prompts from freezing.\n\nBefore guessing a subcommand, run `--help`:\n```bash\nxno-skills --help # or: bunx -y xno-skills@4.7.4 --help\n```\n\n### 3. Wallet lifecycle → `ows` skill only\n\nFor wallet **create, import, rename, or delete**: delegate to the `ows` skill. Do not invoke `ows` CLI commands directly from this skill.\n\n### 4. Never do any of the following\n\n- Write custom Node.js/TypeScript scripts to interact with the Nano protocol.\n- Use `curl` for RPC calls.\n- Attempt to manually compute or supply Proof of Work. PoW is automatic.\n- Use `npx` to fetch random or third-party npm packages as workarounds.\n- Export mnemonics or seeds (`ows wallet export`). OWS keeps secrets encrypted. The entire point of OWS is that the agent never sees the private key.\n- Change `maxSendXno` unless the human/operator explicitly asks to change the spending limit. A blocked send or refund is not permission to raise the limit automatically.\n\n### 5. Prefer `blocklattice.io` for explorer links\n\nWhen the user asks for an account, block, transaction, or explorer link, always prefer `blocklattice.io` unless they explicitly request another explorer.\n\n---\n\n## Safety Rules\n\n- **State verification**: Always fetch balance and frontier via RPC before manually building a block. Never hallucinate previous hashes.\n- **PoW is automatic**: MCP tools and the CLI both handle PoW internally. Never attempt to supply or generate PoW manually.\n- **Pre-send state**: Before `wallet_send`, inspect the source wallet's confirmed balance and total receivable amount with `wallet_balance`. If confirmed funds cannot cover the requested send and receivables are needed, call `wallet_receive`, then recheck. Do not submit receive blocks merely because unrelated funds are pending.\n- **Persistence on \"Account not found\"**: This is normal for a brand-new, unopened account. Continue — `wallet_receive` will automatically build an open block (sets `previous` to zeros), sign it via OWS, generate PoW, and broadcast. Never conclude you are unauthorized or that OWS cannot sign Nano blocks.\n- **No mnemonic exports**: Never call `ows wallet export` or suggest exporting to a third-party wallet unless the user explicitly commands it.\n- **Supply chain**: Only use `xno-skills@4.7.4` and `@open-wallet-standard/core`. No other npm packages.\n- **Stop-loss**: If you have made 5 tool calls without completing the operation, stop and report what you tried, what failed, and ask for guidance. Hard limits: max 3 retries of the same failing tool; max 2 `config_set` RPC endpoint switches.\n\n---\n\n## Wallet Discovery\n\n> **CRITICAL: Always call `wallet_list` first.** Before any wallet operation, identify which OWS wallets exist. Never assume a wallet name.\n\n```json\n{ \"name\": \"wallet_list\", \"arguments\": {} }\n```\n\nTo **create** a new wallet, delegate to the `ows` skill. Then return here for all Nano operations.\n\n**MCP Resources** (passive reads, no tool call needed):\n- `wallet://{name}` — wallet summary and primary account state\n- `wallet://{name}/account/{index}` — pending blocks and details for a specific account index\n\n---\n\n## Reading Balances\n\n**Via MCP tools:**\n```json\n{ \"name\": \"wallet_balance\", \"arguments\": { \"wallet\": \"my-wallet\" } }\n{ \"name\": \"rpc_account_balance\", \"arguments\": { \"address\": \"nano_...\" } }\n```\n\n**Via CLI (required flags only):**\n```bash\nbunx -y xno-skills@4.7.4 balance --wallet \"my-wallet\"\nbunx -y xno-skills@4.7.4 rpc account-balance
\n```\n\nFull options: [balance](references/balance.md), [rpc_account-balance](references/rpc_account-balance.md)\n\n**Public zero-config RPC nodes** (used automatically by xno-skills defaults):\n- `https://rainstorm.city/api` (primary)\n- `https://nanoslo.0x.no/proxy` (secondary)\n- `https://rpc.nano.to` (tertiary)\n\nPending funds are not spendable. Receive them only when the user asks to claim them or they are needed for the requested operation (see Receiving Funds section).\n\n---\n\n## Receiving Funds (Including Unopened Accounts)\n\nA Nano transfer shows as **pending** until the recipient publishes a receive block. Funds are not spendable until received.\n\n**A new / \"unopened\" account chain is normal.** It returns `\"Account not found\"` from RPC. This is not an error — `wallet_receive` will automatically build an open block (sets `previous` to zeros), sign it via OWS, generate PoW, and broadcast.\n\n> **OWS DOES support Nano block signing.** Never assume otherwise.\n\nWhen receipt is requested or needed to fund a send, call `wallet_receive`. Do not treat an unopened account as a blocker: `wallet_receive` handles the open block.\n\n**Via MCP:**\n```json\n{ \"name\": \"wallet_receive\", \"arguments\": { \"wallet\": \"my-wallet\" } }\n```\n\n**Via CLI (required flags only):**\n```bash\nbunx -y xno-skills@4.7.4 receive --wallet \"my-wallet\"\n```\n\nFull options: [receive](references/receive.md)\n\n**Unopened account — explicit representative:**\nIf no `defaultRepresentative` is configured via `config_set`, pass `representative` explicitly on the first receive.\n\n### ⚠️ CLI `block` commands are NOT senders\n\n`xno-skills block receive` / `block send` output **unsigned hex only** — no PoW, no signing, no broadcast. A block without PoW is always rejected. **Never fall back to these when `wallet_receive` or `wallet_send` fails.**\n\n| | MCP `wallet_receive`/`wallet_send` | CLI `block receive`/`block send` |\n|---|---|---|\n| Builds block | ✅ | ✅ |\n| Signs via OWS | ✅ | ❌ |\n| Generates PoW | ✅ | ❌ |\n| Broadcasts | ✅ | ❌ |\n\n---\n\n## Sending Funds\n\nThe account must be opened (have a receive block) and have sufficient balance.\n\n**Preflight**: Call `wallet_balance` for the source wallet before each send. If its confirmed balance is insufficient but its receivable amount can cover the requested send, call `wallet_receive` and recheck before sending. Do not receive unrelated pending funds solely because they exist.\n\n**Via MCP:**\n```json\n{ \"name\": \"wallet_send\", \"arguments\": { \"wallet\": \"my-wallet\", \"destination\": \"nano_...\", \"amountXno\": \"0.01\" } }\n```\n\n**Via CLI (required flags only):**\n```bash\nbunx -y xno-skills@4.7.4 send --wallet \"my-wallet\" --to \"nano_...\" --amount-xno 0.01\n```\n\nFull options: [send](references/send.md)\n\n**Validate the destination address first** (see Address Validation section).\n\n**Spending limits**: Every `wallet_send` and `payment_refund` is gated by `maxSendXno` (default: 1.0 XNO).\n\nIf a send is blocked by this limit, report the current limit and ask the human/operator whether they want to change it. Never call `config_set` to raise `maxSendXno` unless they explicitly asked to modify the spending limit.\n\nOnly when the human/operator explicitly asks to change the spending limit:\n```json\n{ \"name\": \"config_set\", \"arguments\": { \"maxSendXno\": \"5.0\" } }\n```\n\n---\n\n## Payment Requests\n\nFor tracked inbound funding workflows:\n\n### Step 1 — Check existing wallets and balance first\nIf sufficient funds already exist, skip creating a request.\n\n### Step 2 — Create request\n```json\n{\n \"name\": \"payment_create\",\n \"arguments\": { \"walletName\": \"my-wallet\", \"amountXno\": \"0.1\", \"reason\": \"testing payment flow\" }\n}\n```\nReturns: `nano:` URI, target address, and request ID.\n\n### Step 3 — Present to operator\nTell the user the amount, reason, and address. Offer a QR code (see QR Generation section).\n\n### Step 4 — Wait and receive\nAfter the user says funds are sent:\n```json\n{ \"name\": \"payment_receive\", \"arguments\": { \"id\": \"\" } }\n```\nReturns status: `pending`, `partial`, `funded`, or `received`. If `partial`, tell the user how much more is needed.\n\n### Step 5 — Confirm\nReport the received amount, updated balance, and that funds are ready.\n\n**Rules:**\n- Always check existing wallets first; don't create unnecessary wallets.\n- Never claim receipt without calling `payment_receive` — pending is not received in Nano.\n- If the operator asks \"did you get it?\", always re-check.\n\n**History:**\n```json\n{ \"name\": \"wallet_history\", \"arguments\": { \"wallet\": \"my-wallet\", \"limit\": 20 } }\n```\n\nFull options: [payment_create](references/payment.create.md), [payment_receive](references/payment.receive.md), [wallet_history](references/history.md)\n\n---\n\n## Returning Funds\n\n**Core safety rule: never guess the refund destination.** Always confirm with the operator.\n\n### Step 1 — Identify what to return\n\nIf linked to a payment request:\n```json\n{ \"name\": \"payment_refund\", \"arguments\": { \"id\": \"\", \"execute\": false } }\n```\n\nOtherwise, check history:\n```json\n{ \"name\": \"wallet_history\", \"arguments\": { \"wallet\": \"my-wallet\", \"limit\": 20 } }\n```\n\n### Step 2 — Evaluate and confirm\n\n- **Single source**: Present the address and amount. Ask: \"I received X XNO from `nano_...`. Shall I return it?\"\n- **Multiple sources**: List all candidates with amounts, ask which to refund.\n- **No sources**: Report \"No incoming transactions found to refund.\"\n\nAlways show the **full address** — never abbreviate.\n\n### Step 3 — Execute\n\n```json\n{\n \"name\": \"payment_refund\",\n \"arguments\": { \"id\": \"\", \"execute\": true, \"confirmAddress\": \"nano_...\" }\n}\n```\n\nOr use `wallet_send` directly if not linked to a payment request.\n\n**Edge cases:**\n- \"Return everything\": list all accounts with balances, confirm before draining.\n- \"Return to [specific address]\": validate the address first, then confirm amount.\n- Spending limit blocks refund: report the current limit and ask whether the human/operator wants to change it. Never raise `maxSendXno` unless they explicitly request that configuration change.\n\nFull options: [payment_refund](references/payment.refund.md)\n\n---\n\n## QR Generation\n\nGenerates a terminal-friendly ASCII QR code for a Nano address, optionally with an amount.\n\n**Via MCP:**\n```json\n{ \"name\": \"util_qr\", \"arguments\": { \"address\": \"nano_...\", \"amountXno\": \"1.5\" } }\n```\n\n**Via CLI (required args only):**\n```bash\nbunx -y xno-skills@4.7.4 qr nano_1abc...\n```\n\nFull options: [qr](references/qr.md)\n\n> **CRITICAL — stdout truncation**: Agents often have stdout truncated (e.g. ``). To display a full QR code:\n> 1. Use `--json` and parse the `\"qr\"` field, or\n> 2. Redirect to a temp file (`> /tmp/qr.txt`) and read it with a file-reading tool.\n\n---\n\n## Address Validation\n\nAll validation is **offline** — no network required.\n\n**Valid address format:**\n- Prefix: `nano_` (65 chars total) or `xrb_` (64 chars, legacy — still valid)\n- Alphabet: `13456789abcdefghijkmnopqrstuwxyz` (no `0`, `l`, `v`, or `i`)\n- Last 8 chars: Blake2b-40 checksum of the public key\n\n**Via MCP:**\n```json\n{ \"name\": \"util_validate\", \"arguments\": { \"address\": \"nano_...\" } }\n```\n\n**Via CLI:**\n```bash\nbunx -y xno-skills@4.7.4 validate nano_1abc...\n```\n\nFull options: [validate](references/validate.md)\n\n**Always validate before sending XNO to an untrusted address.**\n\n---\n\n## Unit Conversion\n\nXNO uses **30 decimal places**. Floating-point arithmetic is unsafe. Always use this tool.\n\n| Unit | Raw value | Relation |\n|---|---|---|\n| raw | 1 | base unit |\n| mnano | 10²⁴ | 0.000001 XNO |\n| knano | 10²⁷ | 0.001 XNO |\n| XNO | 10³⁰ | 1 XNO |\n\n**Via MCP:**\n```json\n{ \"name\": \"util_convert\", \"arguments\": { \"amount\": \"1.5\", \"from\": \"xno\", \"to\": \"raw\" } }\n```\n\n**Via CLI:**\n```bash\nbunx -y xno-skills@4.7.4 convert 1 xno # all units\nbunx -y xno-skills@4.7.4 convert 1 knano\nbunx -y xno-skills@4.7.4 convert 1000000000000000000000000000000 raw\nbunx -y xno-skills@4.7.4 convert 1 xno --json\n```\n\nFull options: [convert](references/convert.md)\n\n---\n\n## Message Signing & Verification (NOMS / ORIS-001)\n\n### OWS-backed signing via MCP — Not yet available\n\nThe `sign_message` and `verify_message` MCP tools require OWS upstream support that has not yet merged. If the user asks you to sign or verify a message using their wallet:\n\n> Sorry, OWS-backed NOMS message signing is not available yet in `xno-mcp`. It depends on an upstream pull request. If you'd like this feature, please add a 👍 at:\n> **https://github.com/open-wallet-standard/core/pull/217**\n\n### Low-level CLI signing (raw private key)\n\nSigning with a raw hex private key works via CLI today, but **the agent must never handle the key value**. A raw private key passed through an LLM context is exposed to logs, memory, and any downstream system — treat it like a password.\n\n**Agent's role**: construct the command with a placeholder and ask the user to run it themselves in their own terminal.\n\nPresent the user with this command to run locally:\n\n```bash\n# Sign — run this yourself, replacing the placeholder with your actual key\nbunx -y xno-skills@4.7.4 sign \"\" --key YOUR_PRIVATE_KEY_HEX\n\n# Sign with JSON output\nbunx -y xno-skills@4.7.4 sign \"\" --key YOUR_PRIVATE_KEY_HEX --json\n```\n\nFor verify, the agent *can* run this directly (no secret material involved):\n\n```bash\n# Verify\nbunx -y xno-skills@4.7.4 verify \"\" \n\n# Verify with JSON output\nbunx -y xno-skills@4.7.4 verify \"\" --json\n```\n\n**NOMS standard (ORIS-001)**: Signatures are computed over a binary payload with a magic header, ensuring a valid signature cannot be misinterpreted as a Nano transaction block.\n\n**Note**: `verify` accepts both `nano_`/`xrb_` addresses and raw 32-byte hex public keys.\n\n> Do not prompt the user to export their mnemonic to get a private key. Never accept, repeat, or emit a private key value — only use the placeholder pattern above.\n\nFull options: [sign](references/sign.md), [verify](references/verify.md)\n\n---\n\n## Nano Protocol Reference\n\nThe ledger is a block lattice of independent account-chains. Every block is a Universal State Block carrying full account state (balance, representative, previous hash). A send is final immediately; funds become spendable only when the recipient publishes a receive/open block. Pending funds sit unclaimed forever until received.\n\nDeep protocol details — state-block anatomy, open/send/receive/change semantics, PoW thresholds, key/address derivations, representatives & ORV: [blocklattice](references/blocklattice.md)\n\n### Changing Representative\n\n```json\n{ \"name\": \"wallet_change_rep\", \"arguments\": { \"wallet\": \"my-wallet\", \"representative\": \"nano_...\" } }\n```\n```bash\nbunx -y xno-skills@4.7.4 change-rep --wallet \"my-wallet\" --representative \"nano_...\"\n```\n\nFull options: [change-rep](references/change-rep.md)\n\n### Explorer Links\n\n- Account: `https://blocklattice.io/account/`\n- Block: `https://blocklattice.io/block/`\n\n---\n\n## Configuration & Defaults\n\nNo configuration required: public RPC nodes, local-first WASM/GPU PoW with remote fallback, default representative, max send `1.0 XNO`. Config lives in a JSON file that reloads before every operation — overrides via `config_set` or `NANO_RPC_URL` / `NANO_WORK_URL` env vars take effect immediately, no restart.\n\nDefaults, override precedence, set/reset semantics: [config](references/config.md)\n\n---\n\n## CLI Reference\n\nAll subcommands support `--json` for machine-readable output and `--help` for full options.\n\n| Subcommand | Description | Reference |\n|---|---|---|\n| `wallets` | List wallets with Nano accounts | [wallets](references/wallets.md) |\n| `balance` | Show balance and pending amount | [balance](references/balance.md) |\n| `receive` | Receive pending blocks | [receive](references/receive.md) |\n| `send` | Send Nano | [send](references/send.md) |\n| `change-rep` | Change representative | [change-rep](references/change-rep.md) |\n| `submit-block` | Sign and submit prepared block hex | [submit-block](references/submit-block.md) |\n| `history` | Show transaction history | [history](references/history.md) |\n| `info` | Discover account state and representative | [info](references/info.md) |\n| `convert` | Convert between XNO units | [convert](references/convert.md) |\n| `qr` | Generate QR code for address | [qr](references/qr.md) |\n| `validate` | Validate address or block hash | [validate](references/validate.md) |\n| `sign` | Sign NOMS message with private key | [sign](references/sign.md) |\n| `verify` | Verify NOMS message signature | [verify](references/verify.md) |\n| `rpc account-balance` | Fetch account balance via RPC | [rpc_account-balance](references/rpc_account-balance.md) |\n| `rpc receivable` | List receivable blocks via RPC | [rpc_receivable](references/rpc_receivable.md) |\n| `rpc account-info` | Fetch account info via RPC | [rpc_account-info](references/rpc_account-info.md) |\n| `rpc probe-caps` | Probe RPC node capabilities | [rpc_probe-caps](references/rpc_probe-caps.md) |\n| `block send` | Build unsigned send block hex | [block_send](references/block_send.md) |\n| `block receive` | Build unsigned receive block hex | [block_receive](references/block_receive.md) |\n| `block change` | Build unsigned change block hex | [block_change](references/block_change.md) |\n| `mcp` | Start MCP server or view config | [mcp](references/mcp.md) |\n\n---\n\n## Troubleshooting\n\nIf tools are behaving unexpectedly, call `system_diag` first to verify versions and environment:\n\n```json\n{ \"name\": \"system_diag\", \"arguments\": {} }\n```\n\nReturns:\n- `xnoSkills.version` — xno-skills version\n- `xnoSkills.path` — resolved executable path\n- `xnoSkills.invocation` — how it was launched (npm-global, npx, bunx, source, etc.)\n- `ows.version` — `@open-wallet-standard/core` version\n- `ows.path` — OWS package location\n- `environment.mockOws` — whether mock mode is active\n- `environment.nanoRpcUrl` — override RPC URL if set\n\n**CLI equivalent:**\n```bash\nxno-skills diag\nxno-skills diag --json\n```\n\n`diag` does not make network calls. If `Local PoW Recommended` is `false` or PoW timing looks surprising, run `xno-skills rpc probe-caps ` to verify remote `work_generate` support.\n\nRecovery procedures — **\"RPC request failed: All endpoints exhausted\"**, **MCP crashes / \"Not connected\" errors**, **PoW failures (`POW_FAILED` / timeout)**: [troubleshooting](references/troubleshooting.md)\n\n---\n\n## Quick-Start Example\n\n```\n1. wallet_list: {} → discover \"my-wallet\" exists\n2. wallet_balance: { wallet: \"my-wallet\" } → check balance / pending\n3. wallet_receive: { wallet: \"my-wallet\" } → only if receipt was requested or pending funds are needed\n4. wallet_send: { wallet: \"my-wallet\", destination: \"nano_...\", amountXno: \"0.01\" }\n```\n\nFile v4.7.4:_meta.json\n\n{\n \"ownerId\": \"kn7dfxwgbd2zfpzbcba5n1sj89835ct5\",\n \"slug\": \"nano\",\n \"version\": \"4.7.4\",\n \"publishedAt\": 1787563365913\n}\n\nFile v4.7.4:references/balance.md\n\n# xno-skills balance\n\n```\nUsage: xno-skills balance [options]\n\nShow balance and pending amount\n\nOptions:\n --wallet OWS wallet name\n --count Max receivable blocks to return if pending > 0 (default: 10)\n -j, --json Output in JSON format\n -h, --help display help for command\n```\n\nFile v4.7.4:references/block_change.md\n\n# xno-skills block change\n\n```\nUsage: xno-skills block change [options]\n\nBuild an unsigned change block\n\nOptions:\n -a, --account
Nano account address\n --representative
New Nano representative address\n --url RPC URL override\n -j, --json Output JSON with block hex + metadata\n -h, --help display help for command\n```\n\nFile v4.7.4:references/block_receive.md\n\n# xno-skills block receive\n\n```\nUsage: xno-skills block receive [options]\n\nBuild an unsigned receive block\n\nOptions:\n -a, --account
Recipient Nano address\n --hash Hash of the pending send block\n --amount-raw Amount in raw\n --amount-xno Amount in XNO\n --url RPC URL override\n -j, --json Output JSON with block hex + metadata\n -h, --help display help for command\n```\n\nFile v4.7.4:references/block_send.md\n\n# xno-skills block send\n\n```\nUsage: xno-skills block send [options]\n\nBuild an unsigned send block\n\nOptions:\n -a, --account
Sender Nano address\n -t, --to
Recipient Nano address\n --amount-xno Amount to send in XNO\n --url RPC URL override\n -j, --json Output JSON with block hex + metadata\n -h, --help display help for command\n```\n\nFile v4.7.4:references/blocklattice.md\n\n# Block-Lattice Protocol Reference\n\nOn-demand protocol reference for the Nano skill. Load this when you need block anatomy, PoW thresholds, key derivations, or consensus details — not during routine wallet operations.\n\n## Block-Lattice Mental Model\n\n**The ledger is a block lattice** — a set of completely independent account-chains.\n\n- Every account maintains its own linear chain of state blocks.\n- Only the account owner (private-key holder) can append to their chain.\n- No global mempool, no miners, no gas fees, no block producers.\n- Each block records the **full current state** of its account (balance, representative, previous hash).\n- Total supply is fixed at genesis.\n\n### Universal State Blocks\n\n**All blocks today are Universal State Blocks** (`type: \"state\"`):\n\n```json\n{\n \"type\": \"state\",\n \"account\": \"nano_...\",\n \"previous\": \"64-hex...\", // frontier hash, or \"0\" for open block\n \"representative\": \"nano_...\",\n \"balance\": \"decimal-string\", // new balance in raw (1 XNO = 10^30 raw)\n \"link\": \"...\", // send: destination address; receive: send block hash; change: \"0\"\n \"signature\": \"128-hex...\",\n \"work\": \"16-hex...\"\n}\n```\n\n### The Account-Chain Dance\n\n**Alice sends to Bob**:\n1. Alice builds a Send block: `previous` = her frontier, `balance` = old − amount, `link` = Bob's address.\n2. Alice signs + PoW + broadcasts. Funds are **irrevocably deducted** from Alice and become **pending** on Bob's chain.\n\n**Bob must claim**:\n1. Bob builds a Receive block: `previous` = his frontier (zeros for open), `balance` = old + amount, `link` = Alice's send block hash.\n2. Bob signs + PoW + broadcasts. Only then are funds spendable.\n\n**Critical**: The send is final for Alice. Funds are not spendable by Bob until his receive block is confirmed. There is no automatic receive. Pending funds sit forever until claimed.\n\n### PoW Thresholds (Epoch v2, 2026)\n\n- Send / Change: `fffffff800000000`\n- Receive / Open / Epoch: `fffffe0000000000`\n\nEpoch blocks use the receive/open threshold above. The historical epoch-1\nthreshold `ffffffc000000000` is legacy-only and must not be selected for\ncurrent mainnet blocks.\n\nPoW input:\n- Open block (height 1): `blake2b(nonce || public_key)`\n- All other blocks: `blake2b(nonce || previous_frontier_hash)`\n\n### Representatives & ORV\n\n- Voting weight = balance delegated to a representative.\n- Quorum = >67% of online weight → confirmed → cemented (deterministic finality, typically <1s).\n- Choose representatives with high uptime, low voting weight concentration, and trustworthy operators.\n- Lists: [blocklattice.io/representatives](https://blocklattice.io/representatives), [nanoticker.org](https://nanoticker.org/representatives)\n\n### Data Representations\n\n- **Seed**: 32 bytes (64 hex, uppercase)\n- **Private key**: `blake2b(32, seed || index)`, index as 4-byte big-endian uint\n- **Address**: `nano_` + 52-base32(public key) + 8-base32(Blake2b-40 checksum). Total 65 chars.\n- **Block hash / frontier**: 32 bytes (64 hex)\n- **Signature**: 64 bytes (128 hex), Ed25519 + Blake2b\n- **Work**: 8 bytes (16 hex)\n- **Balance**: always raw units as decimal string in JSON. Never floating-point.\n\nFile v4.7.4:references/change-rep.md\n\n# xno-skills change-rep\n\n```\nUsage: xno-skills change-rep [options]\n\nSubmit a change representative block\n\nOptions:\n --wallet OWS wallet name\n --representative
New Nano representative address\n -j, --json Output in JSON format\n -h, --help display help for command\n```\n\nFile v4.7.4:references/config.md\n\n# Configuration Reference\n\nOn-demand configuration reference for `xno-mcp` / xno-skills. Load this when you need override precedence, env vars, or set/reset semantics.\n\n## Defaults (zero-config)\n\n- Public RPC nodes (`rainstorm.city`, `nanoslo.0x.no/proxy`, `rpc.nano.to`)\n- PoW: local WASM/GPU by default; falls back to remote via the first RPC node when local is not performant\n- Representative: `nano_3arg3asgtigae3xckabaaewkx3bzsh7nwz7jkmjos79ihyaxwphhm6qgjps4`\n- Max per send: `1.0 XNO`\n\n## Config file behavior\n\n`xno-mcp` reads configuration from a JSON file on disk. It reloads the file before every operation, so manual edits take effect immediately. No restart required.\n\n### Override precedence\n\n**Remote PoW URL** (resolved in order):\n1. `NANO_WORK_URL` env var\n2. saved config `workUrl`\n3. `NANO_RPC_URL` env var\n4. saved config `rpcUrl`\n5. default primary RPC node\n\n**RPC endpoint list** (normal traffic):\n1. explicit tool argument `rpcUrl`\n2. saved config `rpcUrl`\n3. `NANO_RPC_URL` env var\n4. default RPC node list\n\n### Setting values\n\n```json\n{ \"name\": \"config_set\", \"arguments\": { \"workUrl\": \"https://my-node.example/api\" } }\n```\n\n### Resetting values\n\nSetting a string field to `\"\"` or `null` clears the saved override (falls back to defaults):\n```json\n{ \"name\": \"config_set\", \"arguments\": { \"workUrl\": \"\" } }\n```\n\nSetting a number field to `null` clears the saved override:\n```json\n{ \"name\": \"config_set\", \"arguments\": { \"powTimeoutMs\": null } }\n```\n\nOmitted fields are preserved unchanged.\n\nFile v4.7.4:references/convert.md\n\n# xno-skills convert\n\n```\nUsage: xno-skills convert [options] \n\nConvert between XNO units\n\nArguments:\n amount Value to convert\n from Source unit: xno or raw\n\nOptions:\n -j, --json Output in JSON format\n -h, --help display help for command\n```\n\nFile v4.7.4:references/diag.md\n\n# xno-skills diag\n\n```\nUsage: xno-skills diag [options]\n\nShow diagnostics and system information\n\nOptions:\n -j, --json Output in JSON format\n --retune Rerun PoW profiling and overwrite cached tuning\n -h, --help display help for command\n```\n\nFile v4.7.4:references/history.md\n\n# xno-skills history\n\n```\nUsage: xno-skills history [options]\n\nShow transaction history\n\nOptions:\n --wallet OWS wallet name\n --limit Max entries to show (default: 20)\n -j, --json Output in JSON format\n -h, --help display help for command\n```\n\nArchive v4.7.3: 25 files, 20179 bytes\n\nFiles: references/balance.md (309b), references/block_change.md (401b), references/block_receive.md (472b), references/block_send.md (419b), references/change-rep.md (335b), references/convert.md (275b), references/diag.md (248b), references/history.md (275b), references/info.md (316b), references/mcp.md (1066b), references/qr.md (383b), references/receive.md (340b), references/rpc_account-balance.md (442b), references/rpc_account-info.md (354b), references/rpc_probe-caps.md (470b), references/rpc_receivable.md (338b), references/send.md (301b), references/sign.md (299b), references/submit-block.md (366b), references/validate.md (260b), references/verify.md (347b), references/wallets.md (189b), skill-card.md (2946b), SKILL.md (27763b), _meta.json (123b)\n\nFile v4.7.3:SKILL.md\n\n---\nname: nano\ndescription: \"Nano (XNO) cryptocurrency wallet operations, transaction analysis, and explorer lookups. Use for send/receive, balances, pending funds, address validation, unit conversion, tx/hash/account lookup, explorer links, and Nano block-lattice questions. Prefer xno-mcp first; use xno-skills CLI as fallback.\"\ntriggers:\n - nano\n - xno\n - nano transaction\n - xno transaction\n - transaction analysis\n - largest transaction\n - nanocurrency\n - nano_\n - xrb_\n - block lattice\n - block explorer\n - explorer link\n - transaction link\n - tx link\n - tx hash\n - block hash\n - xno-skills\n - xno-mcp\n - wallet\n - wallets\n - send nano\n - receive nano\n - send xno\n - receive xno\n - balance\n - check balance\n - pending\n - qr code\n - payment qr\n - nano qr\n - xno qr\n - request payment\n - invoice\n - refund\n - return funds\n - send back\n - convert units\n - raw to xno\n - xno to raw\n - validate address\n - nano address\n - sign message\n - verify message\n - representative\n - pow\n - proof of work\n - open account\n - frontier\n - top up\n - fund wallet\n - how much xno\n - how much nano\ncomplements:\n - ows # Open Wallet Standard — wallet lifecycle (create, import, rename, delete)\nrequires_network: true\n---\n\n# Nano (XNO)\n\n## Scope & Disambiguation\n\nThis skill applies **exclusively to the Nano cryptocurrency protocol** (ticker: XNO, block-lattice ledger, [Nano.org](https://nano.org)).\n\n**Activate for**: nanocurrency, XNO, `nano_` addresses, block-lattice, ORV, xno-skills, xno-mcp.\n\n**Do NOT activate for**: Ledger Nano (hardware wallet), GNU nano (text editor), Nanopay, or any other product that uses the word \"nano\" unrelated to XNO. If ambiguous, ask for clarification.\n\n**Legacy terminology**: \"Rai\", \"RaiBlocks\", `xrb_` addresses — historical only (pre-2018). Always normalize to Nano / `nano_`.\n\n---\n\n## Global Execution Policy\n\n**This policy applies to every Nano task in this skill, without exception.**\n\n### 1. Prefer MCP tools first\n\nWhen the environment provides `xno-mcp` tools (`wallet_list`, `wallet_send`, `wallet_receive`, `wallet_balance`, `util_convert`, `util_qr`, `util_validate`, `rpc_account_balance`, `payment_create`, etc.) — **always use them first**. They handle signing, PoW, and broadcast automatically via OWS.\n\nIf the client supports MCP, set it up as a \"stdio\" type MCP server.\n\n**Preferred — global install** (avoids `npx` concurrency issues that cause handshake failures):\n\n npm install -g xno-skills@4.7.3\n xno-skills mcp\n\n**Fallback** (only if global install is not possible):\n\n npx -y xno-skills@4.7.3 mcp\n\n> **Why not `npx` by default?** When multiple agent sessions start concurrently, `npx` can fail during package resolution — the second process exits before the MCP handshake completes. A global install eliminates this race.\n\nMCP is the primary execution path because tools, schemas, and results are structured for the client. Use the included CLI script (`xno-skills`) only as a fallback when MCP is unavailable or the client cannot attach MCP servers. MCP and the CLI target EXACTLY the same underlying code paths — two access paths, not two different products.\n\n### 2. Fall back to CLI only when MCP is unavailable\n\nIf `xno-mcp` tools are not available, or the user explicitly asks for CLI usage, use the `xno-skills` CLI in this priority order:\n\n```\n1. xno-skills (global install — preferred)\n2. bunx -y xno-skills@4.7.3 \n3. pnpm dlx xno-skills@4.7.3 \n4. npx -y xno-skills@4.7.3 \n```\n\nIf the global `xno-skills` binary is not available, fall through to the next option. Always pin the version (`@4.5.2`) with `bunx`/`pnpm dlx`/`npx` to prevent interactive prompts from freezing.\n\nBefore guessing a subcommand, run `--help`:\n```bash\nxno-skills --help # or: bunx -y xno-skills@4.7.3 --help\n```\n\n### 3. Wallet lifecycle → `ows` skill only\n\nFor wallet **create, import, rename, or delete**: delegate to the `ows` skill. Do not invoke `ows` CLI commands directly from this skill.\n\n### 4. Never do any of the following\n\n- Write custom Node.js/TypeScript scripts to interact with the Nano protocol.\n- Use `curl` for RPC calls.\n- Attempt to manually compute or supply Proof of Work. PoW is automatic.\n- Use `npx` to fetch random or third-party npm packages as workarounds.\n- Export mnemonics or seeds (`ows wallet export`). OWS keeps secrets encrypted. The entire point of OWS is that the agent never sees the private key.\n- Change `maxSendXno` unless the human/operator explicitly asks to change the spending limit. A blocked send or refund is not permission to raise the limit automatically.\n\n### 5. Prefer `blocklattice.io` for explorer links\n\nWhen the user asks for an account, block, transaction, or explorer link, always prefer `blocklattice.io` unless they explicitly request another explorer.\n\n---\n\n## Safety Rules\n\n- **State verification**: Always fetch balance and frontier via RPC before manually building a block. Never hallucinate previous hashes.\n- **PoW is automatic**: MCP tools and the CLI both handle PoW internally. Never attempt to supply or generate PoW manually.\n- **Pre-send state**: Before `wallet_send`, inspect the source wallet's confirmed balance and total receivable amount with `wallet_balance`. If confirmed funds cannot cover the requested send and receivables are needed, call `wallet_receive`, then recheck. Do not submit receive blocks merely because unrelated funds are pending.\n- **Persistence on \"Account not found\"**: This is normal for a brand-new, unopened account. Continue — `wallet_receive` will automatically build an open block (sets `previous` to zeros), sign it via OWS, generate PoW, and broadcast. Never conclude you are unauthorized or that OWS cannot sign Nano blocks.\n- **No mnemonic exports**: Never call `ows wallet export` or suggest exporting to a third-party wallet unless the user explicitly commands it.\n- **Supply chain**: Only use `xno-skills@4.7.3` and `@open-wallet-standard/core`. No other npm packages.\n- **Stop-loss**: If you have made 5 tool calls without completing the operation, stop and report what you tried, what failed, and ask for guidance. Hard limits: max 3 retries of the same failing tool; max 2 `config_set` RPC endpoint switches.\n\n---\n\n## Wallet Discovery\n\n> **CRITICAL: Always call `wallet_list` first.** Before any wallet operation, identify which OWS wallets exist. Never assume a wallet name.\n\n```json\n{ \"name\": \"wallet_list\", \"arguments\": {} }\n```\n\nTo **create** a new wallet, delegate to the `ows` skill. Then return here for all Nano operations.\n\n**MCP Resources** (passive reads, no tool call needed):\n- `wallet://{name}` — wallet summary and primary account state\n- `wallet://{name}/account/{index}` — pending blocks and details for a specific account index\n\n---\n\n## Reading Balances\n\n**Via MCP tools:**\n```json\n{ \"name\": \"wallet_balance\", \"arguments\": { \"wallet\": \"my-wallet\" } }\n{ \"name\": \"rpc_account_balance\", \"arguments\": { \"address\": \"nano_...\" } }\n```\n\n**Via CLI (required flags only):**\n```bash\nbunx -y xno-skills@4.7.3 balance --wallet \"my-wallet\"\nbunx -y xno-skills@4.7.3 rpc account-balance
\n```\n\nFull options: [balance](references/balance.md), [rpc_account-balance](references/rpc_account-balance.md)\n\n**Public zero-config RPC nodes** (used automatically by xno-skills defaults):\n- `https://rainstorm.city/api` (primary)\n- `https://nanoslo.0x.no/proxy` (secondary)\n- `https://rpc.nano.to` (tertiary)\n\nPending funds are not spendable. Receive them only when the user asks to claim them or they are needed for the requested operation (see Receiving Funds section).\n\n---\n\n## Receiving Funds (Including Unopened Accounts)\n\nA Nano transfer shows as **pending** until the recipient publishes a receive block. Funds are not spendable until received.\n\n**A new / \"unopened\" account chain is normal.** It returns `\"Account not found\"` from RPC. This is not an error — `wallet_receive` will automatically build an open block (sets `previous` to zeros), sign it via OWS, generate PoW, and broadcast.\n\n> **OWS DOES support Nano block signing.** Never assume otherwise.\n\nWhen receipt is requested or needed to fund a send, call `wallet_receive`. Do not treat an unopened account as a blocker: `wallet_receive` handles the open block.\n\n**Via MCP:**\n```json\n{ \"name\": \"wallet_receive\", \"arguments\": { \"wallet\": \"my-wallet\" } }\n```\n\n**Via CLI (required flags only):**\n```bash\nbunx -y xno-skills@4.7.3 receive --wallet \"my-wallet\"\n```\n\nFull options: [receive](references/receive.md)\n\n**Unopened account — explicit representative:**\nIf no `defaultRepresentative` is configured via `config_set`, pass `representative` explicitly on the first receive.\n\n### ⚠️ CLI `block` commands are NOT senders\n\n`xno-skills block receive` / `block send` output **unsigned hex only** — no PoW, no signing, no broadcast. A block without PoW is always rejected. **Never fall back to these when `wallet_receive` or `wallet_send` fails.**\n\n| | MCP `wallet_receive`/`wallet_send` | CLI `block receive`/`block send` |\n|---|---|---|\n| Builds block | ✅ | ✅ |\n| Signs via OWS | ✅ | ❌ |\n| Generates PoW | ✅ | ❌ |\n| Broadcasts | ✅ | ❌ |\n\n---\n\n## Sending Funds\n\nThe account must be opened (have a receive block) and have sufficient balance.\n\n**Preflight**: Call `wallet_balance` for the source wallet before each send. If its confirmed balance is insufficient but its receivable amount can cover the requested send, call `wallet_receive` and recheck before sending. Do not receive unrelated pending funds solely because they exist.\n\n**Via MCP:**\n```json\n{ \"name\": \"wallet_send\", \"arguments\": { \"wallet\": \"my-wallet\", \"destination\": \"nano_...\", \"amountXno\": \"0.01\" } }\n```\n\n**Via CLI (required flags only):**\n```bash\nbunx -y xno-skills@4.7.3 send --wallet \"my-wallet\" --to \"nano_...\" --amount-xno 0.01\n```\n\nFull options: [send](references/send.md)\n\n**Validate the destination address first** (see Address Validation section).\n\n**Spending limits**: Every `wallet_send` and `payment_refund` is gated by `maxSendXno` (default: 1.0 XNO).\n\nIf a send is blocked by this limit, report the current limit and ask the human/operator whether they want to change it. Never call `config_set` to raise `maxSendXno` unless they explicitly asked to modify the spending limit.\n\nOnly when the human/operator explicitly asks to change the spending limit:\n```json\n{ \"name\": \"config_set\", \"arguments\": { \"maxSendXno\": \"5.0\" } }\n```\n\n---\n\n## Payment Requests\n\nFor tracked inbound funding workflows:\n\n### Step 1 — Check existing wallets and balance first\nIf sufficient funds already exist, skip creating a request.\n\n### Step 2 — Create request\n```json\n{\n \"name\": \"payment_create\",\n \"arguments\": { \"walletName\": \"my-wallet\", \"amountXno\": \"0.1\", \"reason\": \"testing payment flow\" }\n}\n```\nReturns: `nano:` URI, target address, and request ID.\n\n### Step 3 — Present to operator\nTell the user the amount, reason, and address. Offer a QR code (see QR Generation section).\n\n### Step 4 — Wait and receive\nAfter the user says funds are sent:\n```json\n{ \"name\": \"payment_receive\", \"arguments\": { \"id\": \"\" } }\n```\nReturns status: `pending`, `partial`, `funded`, or `received`. If `partial`, tell the user how much more is needed.\n\n### Step 5 — Confirm\nReport the received amount, updated balance, and that funds are ready.\n\n**Rules:**\n- Always check existing wallets first; don't create unnecessary wallets.\n- Never claim receipt without calling `payment_receive` — pending is not received in Nano.\n- If the operator asks \"did you get it?\", always re-check.\n\n**History:**\n```json\n{ \"name\": \"wallet_history\", \"arguments\": { \"wallet\": \"my-wallet\", \"limit\": 20 } }\n```\n\nFull options: [payment_create](references/payment.create.md), [payment_receive](references/payment.receive.md), [wallet_history](references/history.md)\n\n---\n\n## Returning Funds\n\n**Core safety rule: never guess the refund destination.** Always confirm with the operator.\n\n### Step 1 — Identify what to return\n\nIf linked to a payment request:\n```json\n{ \"name\": \"payment_refund\", \"arguments\": { \"id\": \"\", \"execute\": false } }\n```\n\nOtherwise, check history:\n```json\n{ \"name\": \"wallet_history\", \"arguments\": { \"wallet\": \"my-wallet\", \"limit\": 20 } }\n```\n\n### Step 2 — Evaluate and confirm\n\n- **Single source**: Present the address and amount. Ask: \"I received X XNO from `nano_...`. Shall I return it?\"\n- **Multiple sources**: List all candidates with amounts, ask which to refund.\n- **No sources**: Report \"No incoming transactions found to refund.\"\n\nAlways show the **full address** — never abbreviate.\n\n### Step 3 — Execute\n\n```json\n{\n \"name\": \"payment_refund\",\n \"arguments\": { \"id\": \"\", \"execute\": true, \"confirmAddress\": \"nano_...\" }\n}\n```\n\nOr use `wallet_send` directly if not linked to a payment request.\n\n**Edge cases:**\n- \"Return everything\": list all accounts with balances, confirm before draining.\n- \"Return to [specific address]\": validate the address first, then confirm amount.\n- Spending limit blocks refund: report the current limit and ask whether the human/operator wants to change it. Never raise `maxSendXno` unless they explicitly request that configuration change.\n\nFull options: [payment_refund](references/payment.refund.md)\n\n---\n\n## QR Generation\n\nGenerates a terminal-friendly ASCII QR code for a Nano address, optionally with an amount.\n\n**Via MCP:**\n```json\n{ \"name\": \"util_qr\", \"arguments\": { \"address\": \"nano_...\", \"amountXno\": \"1.5\" } }\n```\n\n**Via CLI (required args only):**\n```bash\nbunx -y xno-skills@4.7.3 qr nano_1abc...\n```\n\nFull options: [qr](references/qr.md)\n\n> **CRITICAL — stdout truncation**: Agents often have stdout truncated (e.g. ``). To display a full QR code:\n> 1. Use `--json` and parse the `\"qr\"` field, or\n> 2. Redirect to a temp file (`> /tmp/qr.txt`) and read it with a file-reading tool.\n\n---\n\n## Address Validation\n\nAll validation is **offline** — no network required.\n\n**Valid address format:**\n- Prefix: `nano_` (65 chars total) or `xrb_` (64 chars, legacy — still valid)\n- Alphabet: `13456789abcdefghijkmnopqrstuwxyz` (no `0`, `l`, `v`, or `i`)\n- Last 8 chars: Blake2b-40 checksum of the public key\n\n**Via MCP:**\n```json\n{ \"name\": \"util_validate\", \"arguments\": { \"address\": \"nano_...\" } }\n```\n\n**Via CLI:**\n```bash\nbunx -y xno-skills@4.7.3 validate nano_1abc...\n```\n\nFull options: [validate](references/validate.md)\n\n**Always validate before sending XNO to an untrusted address.**\n\n---\n\n## Unit Conversion\n\nXNO uses **30 decimal places**. Floating-point arithmetic is unsafe. Always use this tool.\n\n| Unit | Raw value | Relation |\n|---|---|---|\n| raw | 1 | base unit |\n| mnano | 10²⁴ | 0.000001 XNO |\n| knano | 10²⁷ | 0.001 XNO |\n| XNO | 10³⁰ | 1 XNO |\n\n**Via MCP:**\n```json\n{ \"name\": \"util_convert\", \"arguments\": { \"amount\": \"1.5\", \"from\": \"xno\", \"to\": \"raw\" } }\n```\n\n**Via CLI:**\n```bash\nbunx -y xno-skills@4.7.3 convert 1 xno # all units\nbunx -y xno-skills@4.7.3 convert 1 knano\nbunx -y xno-skills@4.7.3 convert 1000000000000000000000000000000 raw\nbunx -y xno-skills@4.7.3 convert 1 xno --json\n```\n\nFull options: [convert](references/convert.md)\n\n---\n\n## Message Signing & Verification (NOMS / ORIS-001)\n\n### OWS-backed signing via MCP — Not yet available\n\nThe `sign_message` and `verify_message` MCP tools require OWS upstream support that has not yet merged. If the user asks you to sign or verify a message using their wallet:\n\n> Sorry, OWS-backed NOMS message signing is not available yet in `xno-mcp`. It depends on an upstream pull request. If you'd like this feature, please add a 👍 at:\n> **https://github.com/open-wallet-standard/core/pull/217**\n\n### Low-level CLI signing (raw private key)\n\nSigning with a raw hex private key works via CLI today, but **the agent must never handle the key value**. A raw private key passed through an LLM context is exposed to logs, memory, and any downstream system — treat it like a password.\n\n**Agent's role**: construct the command with a placeholder and ask the user to run it themselves in their own terminal.\n\nPresent the user with this command to run locally:\n\n```bash\n# Sign — run this yourself, replacing the placeholder with your actual key\nbunx -y xno-skills@4.7.3 sign \"\" --key YOUR_PRIVATE_KEY_HEX\n\n# Sign with JSON output\nbunx -y xno-skills@4.7.3 sign \"\" --key YOUR_PRIVATE_KEY_HEX --json\n```\n\nFor verify, the agent *can* run this directly (no secret material involved):\n\n```bash\n# Verify\nbunx -y xno-skills@4.7.3 verify \"\" \n\n# Verify with JSON output\nbunx -y xno-skills@4.7.3 verify \"\" --json\n```\n\n**NOMS standard (ORIS-001)**: Signatures are computed over a binary payload with a magic header, ensuring a valid signature cannot be misinterpreted as a Nano transaction block.\n\n**Note**: `verify` accepts both `nano_`/`xrb_` addresses and raw 32-byte hex public keys.\n\n> Do not prompt the user to export their mnemonic to get a private key. Never accept, repeat, or emit a private key value — only use the placeholder pattern above.\n\nFull options: [sign](references/sign.md), [verify](references/verify.md)\n\n---\n\n## Block-Lattice Mental Model\n\n**The ledger is a block lattice** — a set of completely independent account-chains.\n\n- Every account maintains its own linear chain of state blocks.\n- Only the account owner (private-key holder) can append to their chain.\n- No global mempool, no miners, no gas fees, no block producers.\n- Each block records the **full current state** of its account (balance, representative, previous hash).\n- Total supply is fixed at genesis.\n\n### Universal State Blocks\n\n**All blocks today are Universal State Blocks** (`type: \"state\"`):\n\n```json\n{\n \"type\": \"state\",\n \"account\": \"nano_...\",\n \"previous\": \"64-hex...\", // frontier hash, or \"0\" for open block\n \"representative\": \"nano_...\",\n \"balance\": \"decimal-string\", // new balance in raw (1 XNO = 10^30 raw)\n \"link\": \"...\", // send: destination address; receive: send block hash; change: \"0\"\n \"signature\": \"128-hex...\",\n \"work\": \"16-hex...\"\n}\n```\n\n### The Account-Chain Dance\n\n**Alice sends to Bob**:\n1. Alice builds a Send block: `previous` = her frontier, `balance` = old − amount, `link` = Bob's address.\n2. Alice signs + PoW + broadcasts. Funds are **irrevocably deducted** from Alice and become **pending** on Bob's chain.\n\n**Bob must claim**:\n1. Bob builds a Receive block: `previous` = his frontier (zeros for open), `balance` = old + amount, `link` = Alice's send block hash.\n2. Bob signs + PoW + broadcasts. Only then are funds spendable.\n\n**Critical**: The send is final for Alice. Funds are not spendable by Bob until his receive block is confirmed. There is no automatic receive. Pending funds sit forever until claimed.\n\n### PoW Thresholds (Epoch v2, 2026)\n\n- Send / Change: `fffffff800000000`\n- Receive / Open / Epoch: `fffffe0000000000`\n\nEpoch blocks use the receive/open threshold above. The historical epoch-1\nthreshold `ffffffc000000000` is legacy-only and must not be selected for\ncurrent mainnet blocks.\n\nPoW input:\n- Open block (height 1): `blake2b(nonce || public_key)`\n- All other blocks: `blake2b(nonce || previous_frontier_hash)`\n\n\n\n### Representatives & ORV\n\n- Voting weight = balance delegated to a representative.\n- Quorum = >67% of online weight → confirmed → cemented (deterministic finality, typically <1s).\n- Choose representatives with high uptime, low voting weight concentration, and trustworthy operators.\n- Lists: [blocklattice.io/representatives](https://blocklattice.io/representatives), [nanoticker.org](https://nanoticker.org/representatives)\n\n**Change representative:**\n```json\n{ \"name\": \"wallet_change_rep\", \"arguments\": { \"wallet\": \"my-wallet\", \"representative\": \"nano_...\" } }\n```\n```bash\nbunx -y xno-skills@4.7.3 change-rep --wallet \"my-wallet\" --representative \"nano_...\"\n```\n\nFull options: [change-rep](references/change-rep.md)\n\n### Data Representations\n\n- **Seed**: 32 bytes (64 hex, uppercase)\n- **Private key**: `blake2b(32, seed || index)`, index as 4-byte big-endian uint\n- **Address**: `nano_` + 52-base32(public key) + 8-base32(Blake2b-40 checksum). Total 65 chars.\n- **Block hash / frontier**: 32 bytes (64 hex)\n- **Signature**: 64 bytes (128 hex), Ed25519 + Blake2b\n- **Work**: 8 bytes (16 hex)\n- **Balance**: always raw units as decimal string in JSON. Never floating-point.\n\n### Blockchain Explorer\n\n- Always prefer `blocklattice.io` unless the user explicitly requests another explorer.\n- Account: `https://blocklattice.io/account/`\n- Block: `https://blocklattice.io/block/`\n\n---\n\n## Configuration & Defaults\n\n`xno-mcp` reads configuration from a JSON file on disk. It reloads the file before every operation, so manual edits take effect immediately. No restart required.\n\n**No configuration is required to get started.** Defaults work out of the box:\n\n- Public RPC nodes (`rainstorm.city`, `nanoslo.0x.no/proxy`, `rpc.nano.to`)\n- PoW: local WASM/GPU by default; falls back to remote via the first RPC node when local is not performant\n- Representative: `nano_3arg3asgtigae3xckabaaewkx3bzsh7nwz7jkmjos79ihyaxwphhm6qgjps4`\n- Max per send: `1.0 XNO`\n\n### Override precedence\n\n**Remote PoW URL** (resolved in order):\n1. `NANO_WORK_URL` env var\n2. saved config `workUrl`\n3. `NANO_RPC_URL` env var\n4. saved config `rpcUrl`\n5. default primary RPC node\n\n**RPC endpoint list** (normal traffic):\n1. explicit tool argument `rpcUrl`\n2. saved config `rpcUrl`\n3. `NANO_RPC_URL` env var\n4. default RPC node list\n\n### Setting values\n\n```json\n{ \"name\": \"config_set\", \"arguments\": { \"workUrl\": \"https://my-node.example/api\" } }\n```\n\n### Resetting values\n\nSetting a string field to `\"\"` or `null` clears the saved override (falls back to defaults):\n```json\n{ \"name\": \"config_set\", \"arguments\": { \"workUrl\": \"\" } }\n```\n\nSetting a number field to `null` clears the saved override:\n```json\n{ \"name\": \"config_set\", \"arguments\": { \"powTimeoutMs\": null } }\n```\n\nOmitted fields are preserved unchanged.\n\n---\n\n## RPC Error Recovery\n\n**\"RPC request failed: All endpoints exhausted\"** is almost always transient (rate limiting, brief node restart). Follow in order, stopping as soon as one works:\n\n| Step | Action |\n|---|---|\n| 1 | Wait 5 s. Retry with identical arguments. |\n| 2 | `config_set({ rpcUrl: \"https://rainstorm.city/api\" })`, retry. |\n| 3 | `config_set({ rpcUrl: \"https://nanoslo.0x.no/proxy\" })`, retry. |\n| 4 | `config_set({ rpcUrl: \"https://rpc.nano.to\" })`, retry. |\n| 5 | Try any other public node, retry. |\n| 6 | `config_set({ rpcUrl: \"\" })` to reset. **Stop — report to user.** |\n\nCalling `config_set` with a new `rpcUrl` creates a fresh `NanoClient`, bypassing the exponential backoff cooldown on default endpoints.\n\n**Prohibited at every step**: custom scripts, curl, CLI `block` commands, manual PoW.\n\n---\n\n## CLI Reference\n\nAll subcommands support `--json` for machine-readable output and `--help` for full options.\n\n| Subcommand | Description | Reference |\n|---|---|---|\n| `wallets` | List wallets with Nano accounts | [wallets](references/wallets.md) |\n| `balance` | Show balance and pending amount | [balance](references/balance.md) |\n| `receive` | Receive pending blocks | [receive](references/receive.md) |\n| `send` | Send Nano | [send](references/send.md) |\n| `change-rep` | Change representative | [change-rep](references/change-rep.md) |\n| `submit-block` | Sign and submit prepared block hex | [submit-block](references/submit-block.md) |\n| `history` | Show transaction history | [history](references/history.md) |\n| `info` | Discover account state and representative | [info](references/info.md) |\n| `convert` | Convert between XNO units | [convert](references/convert.md) |\n| `qr` | Generate QR code for address | [qr](references/qr.md) |\n| `validate` | Validate address or block hash | [validate](references/validate.md) |\n| `sign` | Sign NOMS message with private key | [sign](references/sign.md) |\n| `verify` | Verify NOMS message signature | [verify](references/verify.md) |\n| `rpc account-balance` | Fetch account balance via RPC | [rpc_account-balance](references/rpc_account-balance.md) |\n| `rpc receivable` | List receivable blocks via RPC | [rpc_receivable](references/rpc_receivable.md) |\n| `rpc account-info` | Fetch account info via RPC | [rpc_account-info](references/rpc_account-info.md) |\n| `rpc probe-caps` | Probe RPC node capabilities | [rpc_probe-caps](references/rpc_probe-caps.md) |\n| `block send` | Build unsigned send block hex | [block_send](references/block_send.md) |\n| `block receive` | Build unsigned receive block hex | [block_receive](references/block_receive.md) |\n| `block change` | Build unsigned change block hex | [block_change](references/block_change.md) |\n| `mcp` | Start MCP server or view config | [mcp](references/mcp.md) |\n\n---\n\n## Troubleshooting\n\nIf tools are behaving unexpectedly, call `system_diag` first to verify versions and environment:\n\n```json\n{ \"name\": \"system_diag\", \"arguments\": {} }\n```\n\nReturns:\n- `xnoSkills.version` — xno-skills version\n- `xnoSkills.path` — resolved executable path\n- `xnoSkills.invocation` — how it was launched (npm-global, npx, bunx, source, etc.)\n- `ows.version` — `@open-wallet-standard/core` version\n- `ows.path` — OWS package location\n- `environment.mockOws` — whether mock mode is active\n- `environment.nanoRpcUrl` — override RPC URL if set\n\n**CLI equivalent:**\n```bash\nxno-skills diag\nxno-skills diag --json\n```\n\n`diag` does not make network calls. If `Local PoW Recommended` is `false` or PoW timing looks surprising, run `xno-skills rpc probe-caps ` to verify remote `work_generate` support.\n\n### MCP Server Crashes & \"Not connected\" Errors\n\n- **OWS is an in-process library, NOT a daemon**: There is no background \"OWS daemon\" or wallet service running. `@open-wallet-standard/core` is a library loaded entirely in-process by the MCP server and CLI.\n- **\"Not connected\" from MCP client**: If an MCP client/agent receives a \"Not connected\" error on `wallet_balance` or any other tool, it typically means the underlying `xno-mcp` server process has crashed (usually due to a Rust native addon panic during PoW or backend initialization) or was terminated. It does **not** mean a background daemon is down.\n\n### PoW failures (`POW_FAILED` / timeout)\n\n**PoW is done locally by default.** xno-skills uses WASM-based Proof of Work that runs in-process — no external work peer is required.\n\nOn first use, the system probes local backends to build a local-first execution plan. This probe itself runs real PoW and may take 5–15 seconds — this is normal and happens on the first PoW operation in a process.\n\n**Diagnose in order, stopping at the first resolution:**\n\n| Step | Check | Action |\n|---|---|---|\n| 1 | Was this the very first `send`/`receive` on a fresh MCP or CLI process? | Allow for first-use warmup. Retry the operation once. |\n| 2 | Did the error say \"Timed out after 10000ms\"? | That is the local WASM per-backend timeout. It means WASM itself failed or is unavailable. Check Node.js version (`node --version`) — WASM PoW requires Node 16+. |\n| 3 | Is the system under heavy CPU load? | WASM PoW is CPU-bound. A send block requires ~8× more work than receive. Wait for load to drop, then retry. |\n\n---\n\n## Quick-Start Example\n\n```\n1. wallet_list: {} → discover \"my-wallet\" exists\n2. wallet_balance: { wallet: \"my-wallet\" } → check balance / pending\n3. wallet_receive: { wallet: \"my-wallet\" } → only if receipt was requested or pending funds are needed\n4. wallet_send: { wallet: \"my-wallet\", destination: \"nano_...\", amountXno: \"0.01\" }\n```\n\nFile v4.7.3:_meta.json\n\n{\n \"ownerId\": \"kn7dfxwgbd2zfpzbcba5n1sj89835ct5\",\n \"slug\": \"nano\",\n \"version\": \"4.7.3\",\n \"publishedAt\": 1787507011066\n}\n\nFile v4.7.3:references/balance.md\n\n# xno-skills balance\n\n```\nUsage: xno-skills balance [options]\n\nShow balance and pending amount\n\nOptions:\n --wallet OWS wallet name\n --count Max receivable blocks to return if pending > 0 (default: 10)\n -j, --json Output in JSON format\n -h, --help display help for command\n```\n\nFile v4.7.3:references/block_change.md\n\n# xno-skills block change\n\n```\nUsage: xno-skills block change [options]\n\nBuild an unsigned change block\n\nOptions:\n -a, --account
Nano account address\n --representative
New Nano representative address\n --url RPC URL override\n -j, --json Output JSON with block hex + metadata\n -h, --help display help for command\n```\n\nFile v4.7.3:references/block_receive.md\n\n# xno-skills block receive\n\n```\nUsage: xno-skills block receive [options]\n\nBuild an unsigned receive block\n\nOptions:\n -a, --account
Recipient Nano address\n --hash Hash of the pending send block\n --amount-raw Amount in raw\n --amount-xno Amount in XNO\n --url RPC URL override\n -j, --json Output JSON with block hex + metadata\n -h, --help display help for command\n```\n\nFile v4.7.3:references/block_send.md\n\n# xno-skills block send\n\n```\nUsage: xno-skills block send [options]\n\nBuild an unsigned send block\n\nOptions:\n -a, --account
Sender Nano address\n -t, --to
Recipient Nano address\n --amount-xno Amount to send in XNO\n --url RPC URL override\n -j, --json Output JSON with block hex + metadata\n -h, --help display help for command\n```\n\nFile v4.7.3:references/change-rep.md\n\n# xno-skills change-rep\n\n```\nUsage: xno-skills change-rep [options]\n\nSubmit a change representative block\n\nOptions:\n --wallet OWS wallet name\n --representative
New Nano representative address\n -j, --json Output in JSON format\n -h, --help display help for command\n```\n\nFile v4.7.3:references/convert.md\n\n# xno-skills convert\n\n```\nUsage: xno-skills convert [options] \n\nConvert between XNO units\n\nArguments:\n amount Value to convert\n from Source unit: xno or raw\n\nOptions:\n -j, --json Output in JSON format\n -h, --help display help for command\n```\n\nFile v4.7.3:references/diag.md\n\n# xno-skills diag\n\n```\nUsage: xno-skills diag [options]\n\nShow diagnostics and system information\n\nOptions:\n -j, --json Output in JSON format\n --retune Rerun PoW profiling and overwrite cached tuning\n -h, --help display help for command\n```\n\nFile v4.7.3:references/history.md\n\n# xno-skills history\n\n```\nUsage: xno-skills history [options]\n\nShow transaction history\n\nOptions:\n --wallet OWS wallet name\n --limit Max entries to show (default: 20)\n -j, --json Output in JSON format\n -h, --help display help for command\n```\n\nFile v4.7.3:references/info.md\n\n# xno-skills info\n\n```\nUsage: xno-skills info [options]\n\nDiscover the current state and representative of any Nano account\n\nOptions:\n --wallet OWS wallet name\n --address
Nano address to inspect\n -j, --json Output in JSON format\n -h, --help display help for command\n```\n\nFile v4.7.3:references/mcp.md\n\n# xno-skills mcp\n\n```\nUsage: xno-skills mcp [options]\n\nStart the MCP server or view configuration instructions\n\nOptions:\n -h, --help display help for command\n\nConfiguration for popular AI agent harnesses:\n\nPreferred (global install — avoids npx concurrency handshake failures):\n\n npm install -g xno-skills@4.7.3\n\n1. Claude Desktop / Cursor / Roo Code (in config.json):\n{\n \"mcpServers\": {\n \"xno\": {\n \"command\": \"xno-skills\",\n \"args\": [\"mcp\"]\n }\n }\n}\n\n2. Gemini CLI:\n gemini mcp add xno xno-skills mcp\n\n3. Claude Code:\n claude mcp add xno xno-skills mcp\n\nFallback (if global install is not possible):\n\n1. Claude Desktop / Cursor / Roo Code (in config.json):\n{\n \"mcpServers\": {\n \"xno\": {\n \"command\": \"npx\",\n \"args\": [\"-y\", \"xno-skills@4.7.3\", \"mcp\"]\n }\n }\n}\n\n2. Gemini CLI:\n gemini mcp add xno npx -y xno-skills@4.7.3 mcp\n\n3. Claude Code:\n claude mcp add xno npx -y xno-skills@4.7.3 mcp\n\nTo run the MCP server directly in this terminal:\n xno-skills mcp (if globally installed)\n npx -y xno-skills mcp (fallback)\n```\n\nArchive v4.7.2: 25 files, 20312 bytes\n\nFiles: references/balance.md (309b), references/block_change.md (401b), references/block_receive.md (472b), references/block_send.md (419b), references/change-rep.md (335b), references/convert.md (275b), references/diag.md (248b), references/history.md (275b), references/info.md (316b), references/mcp.md (1066b), references/qr.md (383b), references/receive.md (340b), references/rpc_account-balance.md (442b), references/rpc_account-info.md (354b), references/rpc_probe-caps.md (470b), references/rpc_receivable.md (338b), references/send.md (301b), references/sign.md (299b), references/submit-block.md (366b), references/validate.md (260b), references/verify.md (347b), references/wallets.md (189b), skill-card.md (3468b), SKILL.md (27763b), _meta.json (123b)\n\nFile v4.7.2:SKILL.md\n\n---\nname: nano\ndescription: \"Nano (XNO) cryptocurrency wallet operations, transaction analysis, and explorer lookups. Use for send/receive, balances, pending funds, address validation, unit conversion, tx/hash/account lookup, explorer links, and Nano block-lattice questions. Prefer xno-mcp first; use xno-skills CLI as fallback.\"\ntriggers:\n - nano\n - xno\n - nano transaction\n - xno transaction\n - transaction analysis\n - largest transaction\n - nanocurrency\n - nano_\n - xrb_\n - block lattice\n - block explorer\n - explorer link\n - transaction link\n - tx link\n - tx hash\n - block hash\n - xno-skills\n - xno-mcp\n - wallet\n - wallets\n - send nano\n - receive nano\n - send xno\n - receive xno\n - balance\n - check balance\n - pending\n - qr code\n - payment qr\n - nano qr\n - xno qr\n - request payment\n - invoice\n - refund\n - return funds\n - send back\n - convert units\n - raw to xno\n - xno to raw\n - validate address\n - nano address\n - sign message\n - verify message\n - representative\n - pow\n - proof of work\n - open account\n - frontier\n - top up\n - fund wallet\n - how much xno\n - how much nano\ncomplements:\n - ows # Open Wallet Standard — wallet lifecycle (create, import, rename, delete)\nrequires_network: true\n---\n\n# Nano (XNO)\n\n## Scope & Disambiguation\n\nThis skill applies **exclusively to the Nano cryptocurrency protocol** (ticker: XNO, block-lattice ledger, [Nano.org](https://nano.org)).\n\n**Activate for**: nanocurrency, XNO, `nano_` addresses, block-lattice, ORV, xno-skills, xno-mcp.\n\n**Do NOT activate for**: Ledger Nano (hardware wallet), GNU nano (text editor), Nanopay, or any other product that uses the word \"nano\" unrelated to XNO. If ambiguous, ask for clarification.\n\n**Legacy terminology**: \"Rai\", \"RaiBlocks\", `xrb_` addresses — historical only (pre-2018). Always normalize to Nano / `nano_`.\n\n---\n\n## Global Execution Policy\n\n**This policy applies to every Nano task in this skill, without exception.**\n\n### 1. Prefer MCP tools first\n\nWhen the environment provides `xno-mcp` tools (`wallet_list`, `wallet_send`, `wallet_receive`, `wallet_balance`, `util_convert`, `util_qr`, `util_validate`, `rpc_account_balance`, `payment_create`, etc.) — **always use them first**. They handle signing, PoW, and broadcast automatically via OWS.\n\nIf the client supports MCP, set it up as a \"stdio\" type MCP server.\n\n**Preferred — global install** (avoids `npx` concurrency issues that cause handshake failures):\n\n npm install -g xno-skills@4.7.2\n xno-skills mcp\n\n**Fallback** (only if global install is not possible):\n\n npx -y xno-skills@4.7.2 mcp\n\n> **Why not `npx` by default?** When multiple agent sessions start concurrently, `npx` can fail during package resolution — the second process exits before the MCP handshake completes. A global install eliminates this race.\n\nMCP is the primary execution path because tools, schemas, and results are structured for the client. Use the included CLI script (`xno-skills`) only as a fallback when MCP is unavailable or the client cannot attach MCP servers. MCP and the CLI target EXACTLY the same underlying code paths — two access paths, not two different products.\n\n### 2. Fall back to CLI only when MCP is unavailable\n\nIf `xno-mcp` tools are not available, or the user explicitly asks for CLI usage, use the `xno-skills` CLI in this priority order:\n\n```\n1. xno-skills (global install — preferred)\n2. bunx -y xno-skills@4.7.2 \n3. pnpm dlx xno-skills@4.7.2 \n4. npx -y xno-skills@4.7.2 \n```\n\nIf the global `xno-skills` binary is not available, fall through to the next option. Always pin the version (`@4.5.2`) with `bunx`/`pnpm dlx`/`npx` to prevent interactive prompts from freezing.\n\nBefore guessing a subcommand, run `--help`:\n```bash\nxno-skills --help # or: bunx -y xno-skills@4.7.2 --help\n```\n\n### 3. Wallet lifecycle → `ows` skill only\n\nFor wallet **create, import, rename, or delete**: delegate to the `ows` skill. Do not invoke `ows` CLI commands directly from this skill.\n\n### 4. Never do any of the following\n\n- Write custom Node.js/TypeScript scripts to interact with the Nano protocol.\n- Use `curl` for RPC calls.\n- Attempt to manually compute or supply Proof of Work. PoW is automatic.\n- Use `npx` to fetch random or third-party npm packages as workarounds.\n- Export mnemonics or seeds (`ows wallet export`). OWS keeps secrets encrypted. The entire point of OWS is that the agent never sees the private key.\n- Change `maxSendXno` unless the human/operator explicitly asks to change the spending limit. A blocked send or refund is not permission to raise the limit automatically.\n\n### 5. Prefer `blocklattice.io` for explorer links\n\nWhen the user asks for an account, block, transaction, or explorer link, always prefer `blocklattice.io` unless they explicitly request another explorer.\n\n---\n\n## Safety Rules\n\n- **State verification**: Always fetch balance and frontier via RPC before manually building a block. Never hallucinate previous hashes.\n- **PoW is automatic**: MCP tools and the CLI both handle PoW internally. Never attempt to supply or generate PoW manually.\n- **Pre-send state**: Before `wallet_send`, inspect the source wallet's confirmed balance and total receivable amount with `wallet_balance`. If confirmed funds cannot cover the requested send and receivables are needed, call `wallet_receive`, then recheck. Do not submit receive blocks merely because unrelated funds are pending.\n- **Persistence on \"Account not found\"**: This is normal for a brand-new, unopened account. Continue — `wallet_receive` will automatically build an open block (sets `previous` to zeros), sign it via OWS, generate PoW, and broadcast. Never conclude you are unauthorized or that OWS cannot sign Nano blocks.\n- **No mnemonic exports**: Never call `ows wallet export` or suggest exporting to a third-party wallet unless the user explicitly commands it.\n- **Supply chain**: Only use `xno-skills@4.7.2` and `@open-wallet-standard/core`. No other npm packages.\n- **Stop-loss**: If you have made 5 tool calls without completing the operation, stop and report what you tried, what failed, and ask for guidance. Hard limits: max 3 retries of the same failing tool; max 2 `config_set` RPC endpoint switches.\n\n---\n\n## Wallet Discovery\n\n> **CRITICAL: Always call `wallet_list` first.** Before any wallet operation, identify which OWS wallets exist. Never assume a wallet name.\n\n```json\n{ \"name\": \"wallet_list\", \"arguments\": {} }\n```\n\nTo **create** a new wallet, delegate to the `ows` skill. Then return here for all Nano operations.\n\n**MCP Resources** (passive reads, no tool call needed):\n- `wallet://{name}` — wallet summary and primary account state\n- `wallet://{name}/account/{index}` — pending blocks and details for a specific account index\n\n---\n\n## Reading Balances\n\n**Via MCP tools:**\n```json\n{ \"name\": \"wallet_balance\", \"arguments\": { \"wallet\": \"my-wallet\" } }\n{ \"name\": \"rpc_account_balance\", \"arguments\": { \"address\": \"nano_...\" } }\n```\n\n**Via CLI (required flags only):**\n```bash\nbunx -y xno-skills@4.7.2 balance --wallet \"my-wallet\"\nbunx -y xno-skills@4.7.2 rpc account-balance
\n```\n\nFull options: [balance](references/balance.md), [rpc_account-balance](references/rpc_account-balance.md)\n\n**Public zero-config RPC nodes** (used automatically by xno-skills defaults):\n- `https://rainstorm.city/api` (primary)\n- `https://nanoslo.0x.no/proxy` (secondary)\n- `https://rpc.nano.to` (tertiary)\n\nPending funds are not spendable. Receive them only when the user asks to claim them or they are needed for the requested operation (see Receiving Funds section).\n\n---\n\n## Receiving Funds (Including Unopened Accounts)\n\nA Nano transfer shows as **pending** until the recipient publishes a receive block. Funds are not spendable until received.\n\n**A new / \"unopened\" account chain is normal.** It returns `\"Account not found\"` from RPC. This is not an error — `wallet_receive` will automatically build an open block (sets `previous` to zeros), sign it via OWS, generate PoW, and broadcast.\n\n> **OWS DOES support Nano block signing.** Never assume otherwise.\n\nWhen receipt is requested or needed to fund a send, call `wallet_receive`. Do not treat an unopened account as a blocker: `wallet_receive` handles the open block.\n\n**Via MCP:**\n```json\n{ \"name\": \"wallet_receive\", \"arguments\": { \"wallet\": \"my-wallet\" } }\n```\n\n**Via CLI (required flags only):**\n```bash\nbunx -y xno-skills@4.7.2 receive --wallet \"my-wallet\"\n```\n\nFull options: [receive](references/receive.md)\n\n**Unopened account — explicit representative:**\nIf no `defaultRepresentative` is configured via `config_set`, pass `representative` explicitly on the first receive.\n\n### ⚠️ CLI `block` commands are NOT senders\n\n`xno-skills block receive` / `block send` output **unsigned hex only** — no PoW, no signing, no broadcast. A block without PoW is always rejected. **Never fall back to these when `wallet_receive` or `wallet_send` fails.**\n\n| | MCP `wallet_receive`/`wallet_send` | CLI `block receive`/`block send` |\n|---|---|---|\n| Builds block | ✅ | ✅ |\n| Signs via OWS | ✅ | ❌ |\n| Generates PoW | ✅ | ❌ |\n| Broadcasts | ✅ | ❌ |\n\n---\n\n## Sending Funds\n\nThe account must be opened (have a receive block) and have sufficient balance.\n\n**Preflight**: Call `wallet_balance` for the source wallet before each send. If its confirmed balance is insufficient but its receivable amount can cover the requested send, call `wallet_receive` and recheck before sending. Do not receive unrelated pending funds solely because they exist.\n\n**Via MCP:**\n```json\n{ \"name\": \"wallet_send\", \"arguments\": { \"wallet\": \"my-wallet\", \"destination\": \"nano_...\", \"amountXno\": \"0.01\" } }\n```\n\n**Via CLI (required flags only):**\n```bash\nbunx -y xno-skills@4.7.2 send --wallet \"my-wallet\" --to \"nano_...\" --amount-xno 0.01\n```\n\nFull options: [send](references/send.md)\n\n**Validate the destination address first** (see Address Validation section).\n\n**Spending limits**: Every `wallet_send` and `payment_refund` is gated by `maxSendXno` (default: 1.0 XNO).\n\nIf a send is blocked by this limit, report the current limit and ask the human/operator whether they want to change it. Never call `config_set` to raise `maxSendXno` unless they explicitly asked to modify the spending limit.\n\nOnly when the human/operator explicitly asks to change the spending limit:\n```json\n{ \"name\": \"config_set\", \"arguments\": { \"maxSendXno\": \"5.0\" } }\n```\n\n---\n\n## Payment Requests\n\nFor tracked inbound funding workflows:\n\n### Step 1 — Check existing wallets and balance first\nIf sufficient funds already exist, skip creating a request.\n\n### Step 2 — Create request\n```json\n{\n \"name\": \"payment_create\",\n \"arguments\": { \"walletName\": \"my-wallet\", \"amountXno\": \"0.1\", \"reason\": \"testing payment flow\" }\n}\n```\nReturns: `nano:` URI, target address, and request ID.\n\n### Step 3 — Present to operator\nTell the user the amount, reason, and address. Offer a QR code (see QR Generation section).\n\n### Step 4 — Wait and receive\nAfter the user says funds are sent:\n```json\n{ \"name\": \"payment_receive\", \"arguments\": { \"id\": \"\" } }\n```\nReturns status: `pending`, `partial`, `funded`, or `received`. If `partial`, tell the user how much more is needed.\n\n### Step 5 — Confirm\nReport the received amount, updated balance, and that funds are ready.\n\n**Rules:**\n- Always check existing wallets first; don't create unnecessary wallets.\n- Never claim receipt without calling `payment_receive` — pending is not received in Nano.\n- If the operator asks \"did you get it?\", always re-check.\n\n**History:**\n```json\n{ \"name\": \"wallet_history\", \"arguments\": { \"wallet\": \"my-wallet\", \"limit\": 20 } }\n```\n\nFull options: [payment_create](references/payment.create.md), [payment_receive](references/payment.receive.md), [wallet_history](references/history.md)\n\n---\n\n## Returning Funds\n\n**Core safety rule: never guess the refund destination.** Always confirm with the operator.\n\n### Step 1 — Identify what to return\n\nIf linked to a payment request:\n```json\n{ \"name\": \"payment_refund\", \"arguments\": { \"id\": \"\", \"execute\": false } }\n```\n\nOtherwise, check history:\n```json\n{ \"name\": \"wallet_history\", \"arguments\": { \"wallet\": \"my-wallet\", \"limit\": 20 } }\n```\n\n### Step 2 — Evaluate and confirm\n\n- **Single source**: Present the address and amount. Ask: \"I received X XNO from `nano_...`. Shall I return it?\"\n- **Multiple sources**: List all candidates with amounts, ask which to refund.\n- **No sources**: Report \"No incoming transactions found to refund.\"\n\nAlways show the **full address** — never abbreviate.\n\n### Step 3 — Execute\n\n```json\n{\n \"name\": \"payment_refund\",\n \"arguments\": { \"id\": \"\", \"execute\": true, \"confirmAddress\": \"nano_...\" }\n}\n```\n\nOr use `wallet_send` directly if not linked to a payment request.\n\n**Edge cases:**\n- \"Return everything\": list all accounts with balances, confirm before draining.\n- \"Return to [specific address]\": validate the address first, then confirm amount.\n- Spending limit blocks refund: report the current limit and ask whether the human/operator wants to change it. Never raise `maxSendXno` unless they explicitly request that configuration change.\n\nFull options: [payment_refund](references/payment.refund.md)\n\n---\n\n## QR Generation\n\nGenerates a terminal-friendly ASCII QR code for a Nano address, optionally with an amount.\n\n**Via MCP:**\n```json\n{ \"name\": \"util_qr\", \"arguments\": { \"address\": \"nano_...\", \"amountXno\": \"1.5\" } }\n```\n\n**Via CLI (required args only):**\n```bash\nbunx -y xno-skills@4.7.2 qr nano_1abc...\n```\n\nFull options: [qr](references/qr.md)\n\n> **CRITICAL — stdout truncation**: Agents often have stdout truncated (e.g. ``). To display a full QR code:\n> 1. Use `--json` and parse the `\"qr\"` field, or\n> 2. Redirect to a temp file (`> /tmp/qr.txt`) and read it with a file-reading tool.\n\n---\n\n## Address Validation\n\nAll validation is **offline** — no network required.\n\n**Valid address format:**\n- Prefix: `nano_` (65 chars total) or `xrb_` (64 chars, legacy — still valid)\n- Alphabet: `13456789abcdefghijkmnopqrstuwxyz` (no `0`, `l`, `v`, or `i`)\n- Last 8 chars: Blake2b-40 checksum of the p\n\nArchive v4.7.1: 25 files, 20259 bytes\n\nFiles: references/balance.md (309b), references/block_change.md (401b), references/block_receive.md (472b), references/block_send.md (419b), references/change-rep.md (335b), references/convert.md (275b), references/diag.md (248b), references/history.md (275b), references/info.md (316b), references/mcp.md (1066b), references/qr.md (383b), references/receive.md (340b), references/rpc_account-balance.md (442b), references/rpc_account-info.md (354b), references/rpc_probe-caps.md (470b), references/rpc_receivable.md (338b), references/send.md (301b), references/sign.md (299b), references/submit-block.md (366b), references/validate.md (260b), references/verify.md (347b), references/wallets.md (189b), skill-card.md (3045b), SKILL.md (27763b), _meta.json (123b)\n\nArchive v4.7.0: 25 files, 19980 bytes\n\nFiles: references/balance.md (309b), references/block_change.md (401b), references/block_receive.md (472b), references/block_send.md (419b), references/change-rep.md (335b), references/convert.md (275b), references/diag.md (248b), references/history.md (275b), references/info.md (316b), references/mcp.md (1066b), references/qr.md (383b), references/receive.md (340b), references/rpc_account-balance.md (442b), references/rpc_account-info.md (354b), references/rpc_probe-caps.md (470b), references/rpc_receivable.md (338b), references/send.md (301b), references/sign.md (299b), references/submit-block.md (366b), references/validate.md (260b), references/verify.md (347b), references/wallets.md (189b), skill-card.md (2883b), SKILL.md (27150b), _meta.json (123b)\n\nArchive v4.6.1: 25 files, 20314 bytes\n\nFiles: references/balance.md (309b), references/block_change.md (401b), references/block_receive.md (472b), references/block_send.md (419b), references/change-rep.md (335b), references/convert.md (275b), references/diag.md (248b), references/history.md (275b), references/info.md (316b), references/mcp.md (1066b), references/qr.md (383b), references/receive.md (340b), references/rpc_account-balance.md (442b), references/rpc_account-info.md (354b), references/rpc_probe-caps.md (470b), references/rpc_receivable.md (338b), references/send.md (301b), references/sign.md (299b), references/submit-block.md (366b), references/validate.md (260b), references/verify.md (347b), references/wallets.md (189b), skill-card.md (3782b), SKILL.md (27150b), _meta.json (123b)\n\nArchive v4.6.0: 25 files, 20241 bytes\n\nFiles: references/balance.md (309b), references/block_change.md (401b), references/block_receive.md (472b), references/block_send.md (419b), references/change-rep.md (335b), references/convert.md (275b), references/diag.md (248b), references/history.md (275b), references/info.md (316b), references/mcp.md (1066b), references/qr.md (383b), references/receive.md (340b), references/rpc_account-balance.md (442b), references/rpc_account-info.md (354b), references/rpc_probe-caps.md (470b), references/rpc_receivable.md (338b), references/send.md (301b), references/sign.md (299b), references/submit-block.md (366b), references/validate.md (260b), references/verify.md (347b), references/wallets.md (189b), skill-card.md (3497b), SKILL.md (26970b), _meta.json (123b)\n\nArchive v4.5.2: 25 files, 19843 bytes\n\nFiles: references/balance.md (309b), references/block_change.md (401b), references/block_receive.md (472b), references/block_send.md (419b), references/change-rep.md (335b), references/convert.md (275b), references/diag.md (248b), references/history.md (275b), references/info.md (316b), references/mcp.md (593b), references/qr.md (383b), references/receive.md (340b), references/rpc_account-balance.md (442b), references/rpc_account-info.md (354b), references/rpc_probe-caps.md (470b), references/rpc_receivable.md (338b), references/send.md (301b), references/sign.md (299b), references/submit-block.md (366b), references/validate.md (260b), references/verify.md (347b), references/wallets.md (189b), skill-card.md (3911b), SKILL.md (26426b), _meta.json (123b)","readmeExcerpt":"Skill: Nano (XNO) Owner: casualsecurityinc Summary: Nano (XNO) cryptocurrency wallet operations, transaction analysis, and explorer lookups. Use for send/receive, balances, pending funds, address validation, unit conversion, tx/hash/account lookup, explorer links, and Nano block-lattice questions. Prefer xno-mcp first; use xno-skills CLI as fallback. Configured OWS wallets ARE the assistant's own wallets — never clai","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"1. xno-skills (global install — preferred)\n2. bunx -y xno-skills@5.0.0 \n3. pnpm dlx xno-skills@5.0.0 \n4. npx -y xno-skills@5.0.0 "},{"language":"bash","snippet":"xno-skills --help # or: bunx -y xno-skills@5.0.0 --help"},{"language":"json","snippet":"{ \"name\": \"wallet_list\", \"arguments\": {} }"},{"language":"json","snippet":"{ \"name\": \"wallet_balance\", \"arguments\": { \"wallet\": \"my-wallet\" } }\n{ \"name\": \"rpc_account_balance\", \"arguments\": { \"address\": \"nano_...\" } }"},{"language":"bash","snippet":"bunx -y xno-skills@5.0.0 balance --wallet \"my-wallet\"\nbunx -y xno-skills@5.0.0 rpc account-balance
"},{"language":"json","snippet":"{ \"name\": \"wallet_receive\", \"arguments\": { \"wallet\": \"my-wallet\" } }"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: nano\ndescription: \"Nano (XNO) cryptocurrency wallet operations, transaction analysis, and explorer lookups. Use for send/receive, balances, pending funds, address validation, unit conversion, tx/hash/account lookup, explorer links, and Nano block-lattice questions. Prefer xno-mcp first; use xno-skills CLI as fallback. Configured OWS wallets ARE the assistant's own wallets — never claim you cannot receive or hold Nano.\"\ntriggers:\n - nano\n - xno\n - nano transaction\n - xno transaction\n - transaction analysis\n - largest transaction\n - nanocurrency\n - nano_\n - xrb_\n - block lattice\n - block explorer\n - explorer link\n - transaction link\n - tx link\n - tx hash\n - block hash\n - xno-skills\n - xno-mcp\n - wallet\n - wallets\n - send nano\n - receive nano\n - send xno\n - receive xno\n - balance\n - check balance\n - pending\n - qr code\n - payment qr\n - nano qr\n - xno qr\n - request payment\n - invoice\n - refund\n - return funds\n - send back\n - convert units\n - raw to xno\n - xno to raw\n - validate address\n - nano address\n - sign message\n - verify message\n - representative\n - pow\n - proof of work\n - open account\n - frontier\n - top up\n - fund wallet\n - how much xno\n - how much nano\ncomplements:\n - ows # Open Wallet Standard — wallet lifecycle (create, import, rename, delete)\nrequires_network: true\n---\n\n# Nano (XNO)\n\n## Scope & Disambiguation\n\nThis skill applies **exclusively to the Nano cryptocurrency protocol** (ticker: XNO, block-lattice ledger, [Nano.org](https://nano.org)).\n\n**Activate for**: nanocurrency, XNO, `nano_` addresses, block-lattice, ORV, xno-skills, xno-mcp.\n\n**Do NOT activate for**: Ledger Nano (hardware wallet), GNU nano (text editor), Nanopay, or any other product that uses the word \"nano\" unrelated to XNO. If ambiguous, ask for clarification.\n\n**Legacy terminology**: \"Rai\", \"RaiBlocks\", `xrb_` addresses — historical only (pre-2018). Always normalize to Nano / `nano_`.\n\n---\n\n## Wallet Ownership & Agent Authority\n\nWallets returned by `wallet_list` are wallets configured for this assistant environment. Treat them as **assistant-controlled wallets** for Nano operations.\n\n**The assistant may**:\n\n- list wallets;\n- inspect balances, pending funds, history, and representatives;\n- receive funds into an assistant-controlled wallet;\n- provide an assistant-controlled receiving address;\n- send funds when the user explicitly requests it.\n\n> **Never say** \"I don't have a wallet\", \"I can't receive funds\", or \"the skill only operates wallets you control\" when `wallet_list` exposes configured wallets.\n\n**Disambiguation**: \"Send me Nano\" means send to an **assistant-controlled wallet**, unless the user names another recipient. Do not reinterpret it as a request to send to a hypothetical personal wallet, and do not refuse on that basis.\n\nBefore any wallet operation, call `wallet_list`. If the user says they want to send Nano to the assistant, list the wallets, identify a suitable receiving wallet/address, and p"},{"path":"_meta.json","content":"{\n \"ownerId\": \"kn7dfxwgbd2zfpzbcba5n1sj89835ct5\",\n \"slug\": \"nano\",\n \"version\": \"5.0.0\",\n \"publishedAt\": 1791462565129\n}"},{"path":"references/balance.md","content":"# xno-skills balance\n\n```\nUsage: xno-skills balance [options]\n\nShow balance and pending amount\n\nOptions:\n --wallet OWS wallet name\n --count Max receivable blocks to return if pending > 0 (default: 10)\n -j, --json Output in JSON format\n -h, --help display help for command\n```"},{"path":"references/block_change.md","content":"# xno-skills block change\n\n```\nUsage: xno-skills block change [options]\n\nBuild an unsigned change block\n\nOptions:\n -a, --account
Nano account address\n --representative
New Nano representative address\n --url RPC URL override\n -j, --json Output JSON with block hex + metadata\n -h, --help display help for command\n```"},{"path":"references/block_receive.md","content":"# xno-skills block receive\n\n```\nUsage: xno-skills block receive [options]\n\nBuild an unsigned receive block\n\nOptions:\n -a, --account
Recipient Nano address\n --hash Hash of the pending send block\n --amount-raw Amount in raw\n --amount-xno Amount in XNO\n --url RPC URL override\n -j, --json Output JSON with block hex + metadata\n -h, --help display help for command\n```"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Nano (XNO) cryptocurrency wallet operations, transaction analysis, and explorer lookups. Use for send/receive, balances, pending funds, address validation, unit conversion, tx/hash/account lookup, explorer links, and Nano block-lattice questions. Prefer xno-mcp first; use xno-skills CLI as fallback. Configured OWS wallets ARE the assistant's own wallets — never claim you cannot receive or hold Nano. Skill: Nano (XNO) Owner: casualsecurityinc Summary: Nano (XNO) cryptocurrency wallet operations, transaction analysis, and explorer lookups. Use for send/receive, balances, pending funds, address validation, unit conversion, tx/hash/account lookup, explorer links, and Nano block-lattice questions. Prefer xno-mcp first; use xno-skills CLI as fallback. Configured OWS wallets ARE the assistant's own wallets — never clai","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":871,"uniquenessScore":49,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-09T08:00:54.251Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-09T08:00:54.251Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T03:35:20.538Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}