nano

Nano（XNO）

対象範囲と区別

このスキルの対象はNano 暗号通貨プロトコルのみです（ティッカー：XNO、ブロックラティス台帳、Nano.org）。

次の場合に有効化してください：nanocurrency、XNO、nano_ アドレス、ブロックラティス、ORV、xno-skills、xno-mcp。

次の場合は有効化しないでください：Ledger Nano（ハードウェアウォレット）、GNU nano（テキストエディター）、Nanopay、または XNO と無関係に「nano」という語を使用するその他の製品。曖昧な場合は、確認を求めてください。

旧用語：「Rai」、「RaiBlocks」、「xrb_」アドレスは、歴史的な名称です（2018 年以前）。常に Nano／nano_ に統一してください。

---

ウォレットの所有権とエージェントの権限

wallet_list が返すウォレットは、このアシスタント環境用に設定されたウォレットです。Nano の操作では、これらをアシスタントが管理するウォレットとして扱ってください。

アシスタントが行えること：

• ウォレットを一覧表示する；
• 残高、保留中の資金、履歴、代表者を確認する；
• アシスタントが管理するウォレットで資金を受け取る；
• アシスタントが管理する受取アドレスを提示する；
• ユーザーが明示的に依頼した場合に資金を送金する。

wallet_list で設定済みのウォレットが確認できる場合、「ウォレットを持っていません」、「資金を受け取れません」、「このスキルではユーザーが管理するウォレットしか操作できません」と決して言わないでください。

意図の確認：「Nano を送って」という依頼は、ユーザーが別の受取人を指定しない限り、アシスタントが管理するウォレットへの送金を意味します。これを、仮定上の個人ウォレットへの送金依頼だと解釈し直したり、その理由で断ったりしないでください。

ウォレットを操作する前に、必ず wallet_list を呼び出してください。ユーザーがアシスタントに Nano を送りたいと言った場合は、ウォレットを一覧表示し、受取に適したウォレット／アドレスを特定して、完全なアドレスを提示してください（省略しないでください）。ユーザーが資金の受け取りを要求するか、支払いワークフローで必要になるまでは、受け取りを開始しないでください。

---

全般的な実行ポリシー

このポリシーは、このスキルにおけるすべての Nano タスクに例外なく適用されます。

1. まず MCP ツールを使用する

環境で xno-mcp ツール（wallet_list、wallet_send、wallet_receive、wallet_balance、util_convert、util_qr、util_validate、rpc_account_balance、payment_create など）が利用できる場合は、必ず最初に使用してください。これらのツールは OWS 経由で署名、PoW、ブロードキャストを自動的に処理します。

クライアントが MCP に対応している場合は、「stdio」タイプの MCP サーバーとして設定してください。

推奨 — グローバルインストール（ハンドシェイク失敗の原因となる npx の同時実行問題を回避できます）：

npm install -g [email protected]
xno-skills mcp

フォールバック（グローバルインストールができない場合のみ）：

npx -y [email protected] mcp

通常 npx を使わない理由：複数のエージェントセッションが同時に起動すると、パッケージの解決中に npx が失敗し、2 つ目のプロセスが MCP ハンドシェイクの完了前に終了することがあります。グローバルインストールすれば、この競合を回避できます。

MCP を主な実行方法としてください。ツール、スキーマ、結果がクライアント向けに構造化されているためです。付属の CLI スクリプト（xno-skills）は、MCP が利用できない場合、またはクライアントが MCP サーバーに接続できない場合のフォールバックとしてのみ使用してください。MCP と CLI は、基盤となるコードパスをまったく同じものに使用します。異なる製品が 2 つあるのではなく、アクセス方法が 2 つあるだけです。

2. MCP が利用できない場合のみ CLI にフォールバックする

xno-mcp ツールが利用できない場合、またはユーザーが CLI の使用を明示的に求めた場合は、次の優先順位で xno-skills CLI を使用してください：

1. xno-skills <command>              (global install — preferred)
2. bunx -y [email protected] <command>
3. pnpm dlx [email protected] <command>
4. npx -y [email protected] <command>

グローバルの xno-skills バイナリが利用できない場合は、次の方法に進んでください。対話型プロンプトで処理が停止しないよう、bunx／pnpm dlx／npx では必ずバージョン（@4.5.2）を固定してください。

サブコマンドを推測する前に、--help を実行してください：

xno-skills --help              # or: bunx -y [email protected] --help

3. ウォレットのライフサイクル → ows スキルのみ

ウォレットの作成、インポート、名前変更、削除については、ows スキルに委任してください。このスキルから ows CLI コマンドを直接実行しないでください。

4. 次の操作は絶対に行わないでください

• Nano プロトコルとやり取りするカスタム Node.js／TypeScript スクリプトを作成しないでください。
• RPC 呼び出しに curl を使用しないでください。
• Proof of Work を手動で計算したり、指定したりしないでください。PoW は自動で行われます。
• 回避策として、npx で無作為またはサードパーティ製の npm パッケージを取得しないでください。
• ニーモニックやシードをエクスポートしないでください（ows wallet export）。OWS は秘密情報を暗号化して保持します。OWS の目的は、エージェントに秘密鍵を決して見せないことです。
• 人間またはオペレーターから支出上限の変更を明示的に依頼されない限り、maxSendXno を変更しないでください。送金や払い戻しがブロックされても、自動的に上限を引き上げてよい理由にはなりません。

5. エクスプローラーのリンクには blocklattice.io を優先する

アカウント、ブロック、トランザクション、またはエクスプローラーのリンクを求められた場合、別のエクスプローラーが明示的に指定されない限り、常に blocklattice.io を優先してください。

---

安全に関するルール

• 状態の検証：ブロックを手動で構築する前に、必ず RPC で残高とフロンティアを取得してください。直前のハッシュを捏造してはいけません。
• PoW は自動：MCP ツールと CLI はどちらも内部で PoW を処理します。PoW を手動で指定または生成しないでください。
• 送信前の状態確認：wallet_send の前に、wallet_balance を使って送信元ウォレットの確認済み残高と受取可能額の合計を確認してください。確認済みの資金だけでは指定された送金額に足りず、受取可能額が必要な場合は、wallet_receive を呼び出してから再確認してください。無関係な資金が保留中というだけで、受取ブロックを送信しないでください。
• 「Account not found」の場合も処理を継続：これは、新規作成された未オープンのアカウントでは正常な状態です。そのまま続行してください。wallet_receive は、自動的にオープンブロック（previous をゼロに設定）を構築し、OWS で署名して PoW を生成し、ブロードキャストします。自分には権限がない、または OWS は Nano ブロックに署名できないと結論づけてはいけません。
• ニーモニックのエクスポート禁止：ユーザーから明示的な指示がない限り、ows wallet export を呼び出したり、サードパーティ製ウォレットへのエクスポートを提案したりしないでください。
• サプライチェーン：[email protected] と @open-wallet-standard/core のみを使用してください。他の npm パッケージは使用しないでください。
• ストップロス：操作を完了しないままツールを 5 回呼び出した場合は停止し、試した内容と失敗した内容を報告して、指示を求めてください。厳格な上限：同じ失敗するツールの再試行は最大 3 回、config_set による RPC エンドポイントの切り替えは最大 2 回です。

---

ウォレットの検出

重要：必ず最初に wallet_list を呼び出してください。 ウォレット操作を行う前に、OWS のウォレットがどれかを特定してください。ウォレット名を推測してはいけません。

{ "name": "wallet_list", "arguments": {} }

新しいウォレットを作成するには、ows スキルに委任してください。その後、Nano のすべての操作を行うためにここへ戻ってください。

MCP リソース（受動的な読み取りで、ツール呼び出しは不要）：

• wallet://{name} — ウォレットの概要とプライマリアカウントの状態
• wallet://{name}/account/{index} — 特定のアカウントインデックスの保留中ブロックと詳細

---

残高の確認

MCP ツール経由：

{ "name": "wallet_balance", "arguments": { "wallet": "my-wallet" } }
{ "name": "rpc_account_balance", "arguments": { "address": "nano_..." } }

CLI 経由（必須のフラグのみ）：

bunx -y [email protected] balance --wallet "my-wallet"
bunx -y [email protected] rpc account-balance <address>

すべてのオプション：balance、rpc_account-balance

公開されているゼロ設定の RPC ノード（xno-skills のデフォルトで自動的に使用）：

• https://rainstorm.city/api（プライマリ）
• https://nanoslo.0x.no/proxy（セカンダリ）
• https://rpc.nano.to（サード）

保留中の資金は使用できません。ユーザーから受け取りを依頼された場合、または依頼された操作に必要な場合に限り、受け取ってください（「資金の受け取り」セクションを参照）。

資金の受け取り（未開設のアカウントを含む）

Nano の送金は、受取人が受け取りブロックを公開するまで 保留中 と表示されます。受け取りが完了するまで、資金は使用できません。

新規／「未開設」のアカウントチェーンは正常な状態です。 RPC から "Account not found" が返されます。これはエラーではありません。wallet_receive は自動的にオープンブロックを構築し（previous をゼロに設定）、OWS 経由で署名し、PoW を生成してブロードキャストします。

OWS は Nano ブロックの署名に対応しています。 対応していないと決めつけないでください。

受け取りが要求された場合、または送金の資金を用意する必要がある場合は、wallet_receive を呼び出してください。未開設のアカウントを障害として扱わないでください。wallet_receive がオープンブロックを処理します。

MCP 経由：

{ "name": "wallet_receive", "arguments": { "wallet": "my-wallet" } }

CLI 経由（必須フラグのみ）：

bunx -y [email protected] receive --wallet "my-wallet"

すべてのオプション：receive

未開設アカウント — 代表者を明示的に指定： config_set 経由で defaultRepresentative が設定されていない場合は、最初の受け取り時に representative を明示的に渡してください。

⚠️ CLI の block コマンドは送金機能ではありません

xno-skills block receive ／ block send が出力するのは 未署名の hex のみ で、PoW、署名、ブロードキャストは行いません。PoW のないブロックは必ず拒否されます。wallet_receive または wallet_send が失敗したときに、これらを代替手段として使用しないでください。

	MCP wallet_receive/wallet_send	CLI block receive/block send
ブロックを構築	✅	✅
OWS 経由で署名	✅	❌
PoW を生成	✅	❌
ブロードキャスト	✅	❌

---

資金の送金

アカウントが開設済み（受け取りブロックがある）で、十分な残高が必要です。

事前確認：送金の前に毎回、送金元ウォレットの wallet_balance を呼び出してください。確定済み残高が不足していても、受け取り可能額で要求された送金額をまかなえる場合は、wallet_receive を呼び出してから残高を再確認し、送金してください。関係のない保留中の資金があるというだけで、受け取らないでください。

MCP 経由：

{ "name": "wallet_send", "arguments": { "wallet": "my-wallet", "destination": "nano_...", "amountXno": "0.01" } }

CLI 経由（必須フラグのみ）：

bunx -y [email protected] send --wallet "my-wallet" --to "nano_..." --amount-xno 0.01

すべてのオプション：send

まず送金先アドレスを検証してください（「アドレスの検証」セクションを参照）。

送金上限：すべての wallet_send と payment_refund は、maxSendXno（デフォルト：1.0 XNO）によって制限されます。

この上限によって送金がブロックされた場合は、現在の上限を伝え、変更するかどうかを人間／オペレーターに確認してください。支出上限の変更を明示的に依頼されていない限り、maxSendXno を引き上げるために config_set を呼び出さないでください。

人間／オペレーターから支出上限の変更を明示的に依頼された場合に限り：

{ "name": "config_set", "arguments": { "maxSendXno": "5.0" } }

---

支払いリクエスト

入金を追跡するワークフローの場合：

ステップ 1 — まず既存のウォレットと残高を確認する

すでに十分な資金がある場合は、リクエストの作成をスキップしてください。

ステップ 2 — リクエストを作成する

{
  "name": "payment_create",
  "arguments": { "walletName": "my-wallet", "amountXno": "0.1", "reason": "testing payment flow" }
}

戻り値：nano: URI、送金先アドレス、リクエスト ID。

ステップ 3 — オペレーターに提示する

金額、理由、アドレスをユーザーに伝えてください。QR コードの提示も提案してください（「QR コードの生成」セクションを参照）。

ステップ 4 — 待機して受け取る

ユーザーから資金を送金したと伝えられた後：

{ "name": "payment_receive", "arguments": { "id": "<request-id>" } }

ステータスとして pending、partial、funded、received のいずれかが返されます。partial の場合は、残りの必要額をユーザーに伝えてください。ウォレットアドレスに複数の Nano 送金が保留中の場合は、rpc_receivable を確認し、対象の sendHash を指定して payment_receive を再試行してください。保留中の送金がどの追跡対象リクエストに属するか、推測してはいけません。

ステップ 5 — 確認

受け取った金額、更新後の残高、および資金を利用できる状態であることを伝えます。

ルール：

• まず既存のウォレットを必ず確認し、不要なウォレットを作成しないでください。
• payment_receive を呼び出さずに、受け取ったと伝えてはいけません。Nano では保留中の送金は受け取り済みではありません。
• オペレーターから「受け取りましたか？」と聞かれた場合は、必ず再確認してください。

履歴：

{ "name": "wallet_history", "arguments": { "wallet": "my-wallet", "limit": 20 } }

すべてのオプション：payment_create、payment_receive、wallet_history

---

資金の返金

最も重要な安全ルール：返金先を推測してはいけません。 必ずオペレーターに確認してください。

ステップ 1 — 返金対象を特定する

支払いリクエストに紐付いている場合：

{ "name": "payment_refund", "arguments": { "id": "<request-id>", "execute": false } }

それ以外の場合は、履歴を確認します：

{ "name": "wallet_history", "arguments": { "wallet": "my-wallet", "limit": 20 } }

ステップ 2 — 評価して確認する

• 送金元が 1 つ：アドレスと金額を提示します。「nano_... から X XNO を受け取りました。返金しますか？」と尋ねます。
• 送金元が複数：金額とともに候補をすべて列挙し、どれに返金するか尋ねます。
• 送金元がない：「返金対象の入金トランザクションが見つかりません。」と伝えます。

完全なアドレスを必ず表示してください。省略してはいけません。

ステップ 3 — 実行する

{
  "name": "payment_refund",
  "arguments": { "id": "<request-id>", "execute": true, "confirmAddress": "nano_..." }
}

または、支払いリクエストに紐付いていない場合は、wallet_send を直接使用します。

例外的なケース：

• 「すべて返金して」：残高のあるアカウントをすべて列挙し、全額を送金する前に確認します。
• 「[specific address] に返金して」：まずアドレスを検証し、その後、金額を確認します。
• 支出限度額によって返金がブロックされた場合：現在の限度額を伝え、人間／オペレーターが変更を希望するか尋ねます。設定変更を明示的に依頼されない限り、maxSendXno を引き上げてはいけません。

すべてのオプション：payment_refund

---

QR コードの生成

Nano アドレスのターミナル向け ASCII QR コードを生成します。金額を指定することもできます。

MCP 経由：

{ "name": "util_qr", "arguments": { "address": "nano_...", "amountXno": "1.5" } }

CLI 経由（必須引数のみ）：

bunx -y [email protected] qr nano_1abc...

すべてのオプション：qr

重要 — stdout の切り詰め：エージェントでは stdout が切り詰められることがよくあります（例：<truncated 14 lines>）。QR コード全体を表示するには：

1. --json を使用して "qr" フィールドを解析する、または
2. 一時ファイル（> /tmp/qr.txt）にリダイレクトし、ファイル読み取りツールで読み取ります。

---

アドレスの検証

すべての検証はオフラインで実行されます。ネットワークは不要です。

有効なアドレス形式：

• プレフィックス：nano_（合計 65 文字）または xrb_（64 文字、旧形式ですが現在も有効）
• 使用可能な文字：13456789abcdefghijkmnopqrstuwxyz（0、l、v、i は使用できません）
• 末尾 8 文字：公開鍵の Blake2b-40 チェックサム

MCP 経由：

{ "name": "util_validate", "arguments": { "address": "nano_..." } }

CLI 経由：

bunx -y [email protected] validate nano_1abc...

すべてのオプション：validate

信頼できないアドレスに XNO を送金する前に、必ず検証してください。

---

単位変換

XNO は小数点以下 30 桁を使用します。浮動小数点演算は安全ではありません。必ずこのツールを使用してください。

単位	raw 値	換算
raw	1	基本単位
mnano	10²⁴	0.000001 XNO
knano	10²⁷	0.001 XNO
XNO	10³⁰	1 XNO

MCP 経由：

{ "name": "util_convert", "arguments": { "amount": "1.5", "from": "xno", "to": "raw" } }

CLI 経由：

bunx -y [email protected] convert 1 xno       # all units
bunx -y [email protected] convert 1 knano
bunx -y [email protected] convert 1000000000000000000000000000000 raw
bunx -y [email protected] convert 1 xno --json

すべてのオプション：convert

---

メッセージの署名と検証（NOMS / ORIS-001）

MCP 経由の OWS 対応署名 — 現在利用できません

sign_message と verify_message の MCP ツールには、まだマージされていない OWS の上流サポートが必要です。ユーザーから、自分のウォレットを使ってメッセージに署名または検証するよう依頼された場合：

申し訳ありません。OWS 対応の NOMS メッセージ署名は、xno-mcp ではまだ利用できません。上流のプルリクエストに依存しています。この機能をご希望の場合は、次のページで 👍 を付けてください： https://github.com/open-wallet-standard/core/pull/217

低レベル CLI 署名（生の秘密鍵）

生の 16 進数秘密鍵を使った署名は現在 CLI 経由で実行できますが、エージェントが鍵の値を扱ってはいけません。LLM のコンテキストを通じて渡された生の秘密鍵は、ログ、メモリ、あらゆる下流システムにさらされます。パスワードと同様に扱ってください。

エージェントの役割：プレースホルダーを使ってコマンドを作成し、ユーザー自身のターミナルで実行するよう依頼します。

ユーザーに、ローカルで実行する次のコマンドを提示してください：

# Sign — run this yourself, replacing the placeholder with your actual key
bunx -y [email protected] sign "<message>" --key YOUR_PRIVATE_KEY_HEX

# Sign with JSON output
bunx -y [email protected] sign "<message>" --key YOUR_PRIVATE_KEY_HEX --json

検証の場合、秘密情報は含まれないため、エージェントが直接実行できます：

# Verify
bunx -y [email protected] verify <nano_address> "<message>" <signature-hex>

# Verify with JSON output
bunx -y [email protected] verify <nano_address> "<message>" <signature-hex> --json

NOMS 標準（ORIS-001）：署名はマジックヘッダーを含むバイナリペイロードに対して計算されるため、有効な署名が Nano トランザクションブロックとして誤解されることはありません。

注：verify は nano_／xrb_ アドレスと、生の 32 バイト 16 進数公開鍵の両方を受け付けます。

秘密鍵を取得するために、ニーモニックをエクスポートするようユーザーに促してはいけません。秘密鍵の値を受け取ったり、繰り返したり、出力したりしてはいけません。上記のプレースホルダーパターンのみを使用してください。

すべてのオプション：sign、verify

---

Nano プロトコルリファレンス

台帳は、独立したアカウントチェーンで構成されるブロックラティスです。各ブロックは、アカウントの状態（残高、代表者、前のハッシュ）全体を保持するユニバーサルステートブロックです。送金はただちに確定しますが、受取人が受信／オープンブロックを公開するまで、資金を使用することはできません。保留中の資金は、受け取られるまで永久に未請求のままです。

プロトコルの詳細（ステートブロックの構造、オープン／送金／受信／変更の各動作、PoW のしきい値、鍵／アドレスの導出、代表者と ORV）：blocklattice

代表者の変更

{ "name": "wallet_change_rep", "arguments": { "wallet": "my-wallet", "representative": "nano_..." } }

bunx -y [email protected] change-rep --wallet "my-wallet" --representative "nano_..."

すべてのオプション：change-rep

エクスプローラーリンク

• アカウント：https://blocklattice.io/account/<nano_address>
• ブロック：https://blocklattice.io/block/<UPPERCASE_HEX_HASH>

---

設定とデフォルト

設定は不要です。パブリック RPC ノード、リモートフォールバック付きのローカル優先 WASM／GPU PoW、デフォルトの代表者、最大送信額 1.0 XNO が使用されます。設定は JSON ファイルに保存され、各操作の前に再読み込みされます。config_set または NANO_RPC_URL／NANO_WORK_URL 環境変数による上書きは、再起動なしですぐに反映されます。

デフォルト、上書きの優先順位、設定／リセットの動作：config

---

CLI リファレンス

すべてのサブコマンドは、機械可読な出力を行う --json と、すべてのオプションを表示する --help に対応しています。

サブコマンド	説明	リファレンス
wallets	Nano アカウントを含むウォレットを一覧表示	wallets
balance	残高と保留中の金額を表示	balance
receive	保留中のブロックを受け取る	receive
send	Nano を送信する	send
change-rep	代表者を変更する	change-rep
submit-block	用意されたブロックの 16 進数データに署名して送信する	submit-block
history	トランザクション履歴を表示する	history
info	アカウントの状態と代表者を確認する	info
convert	XNO の単位を変換する	convert
qr	アドレスの QR コードを生成する	qr
validate	アドレスまたはブロックハッシュを検証する	validate
sign	秘密鍵で NOMS メッセージに署名する	sign
verify	NOMS メッセージの署名を検証する	verify
rpc account-balance	RPC 経由でアカウント残高を取得する	rpc_account-balance
rpc receivable	RPC 経由で受取可能なブロックを一覧表示する	rpc_receivable
rpc account-info	RPC 経由でアカウント情報を取得する	rpc_account-info
rpc probe-caps	RPC ノードの機能を調査する	rpc_probe-caps
block send	署名前の送信ブロックの 16 進数データを作成する	block_send
block receive	署名前の受取ブロックの 16 進数データを作成する	block_receive
block change	署名前の変更ブロックの 16 進数データを作成する	block_change
mcp	MCP サーバーを起動するか、設定を表示する	mcp

---

トラブルシューティング

ツールが予期しない動作をする場合は、まず system_diag を呼び出してバージョンと環境を確認してください。

{ "name": "system_diag", "arguments": {} }

次の情報が返されます。

• xnoSkills.version — xno-skills のバージョン
• xnoSkills.path — 解決された実行可能ファイルのパス
• xnoSkills.invocation — 起動方法（npm-global、npx、bunx、source など）
• ows.version — @open-wallet-standard/core のバージョン
• ows.path — OWS パッケージの場所
• environment.mockOws — モックモードが有効かどうか
• environment.nanoRpcUrl — 設定されている場合の RPC URL の上書き値

CLI での同等のコマンド：

xno-skills diag
xno-skills diag --json

diag はネットワーク呼び出しを行いません。Local PoW Recommended が false の場合、または PoW のタイミングが想定と異なる場合は、xno-skills rpc probe-caps <effective-work-url> を実行して、リモートの work_generate サポートを確認してください。

復旧手順 — 「RPC request failed: All endpoints exhausted」、MCP のクラッシュ／「Not connected」エラー、PoW の失敗（POW_FAILED／タイムアウト）：トラブルシューティング

---

クイックスタートの例

1. wallet_list: {}                    → discover "my-wallet" exists
2. wallet_balance: { wallet: "my-wallet" }    → check balance / pending
3. wallet_receive: { wallet: "my-wallet" }    → only if receipt was requested or pending funds are needed
4. wallet_send: { wallet: "my-wallet", destination: "nano_...", amountXno: "0.01" }