Zimppy は、シールド決済と透明決済の両方に対応する、Zcash 向けの Machine Payment Protocol（MPP）決済方式です。オンチェーンで一度入金すれば、リクエストごとのチェーン操作なしに無制限の即時ベアラーリクエストを実行できます。
Zimppy.xyz は、AIエージェントおよび自動化されたマシン間（M2M）ワークフローのために特別設計された、プライバシー優先の決済インフラです。基盤通貨として Zcash を使用し、Machine Payment Protocol（MPP） を実装することで、シールド（完全プライベート）決済と透明決済の両方を実現します。
すべての取引がオンチェーンで公開される従来のブロックチェーン決済システムとは異なり、Zimppy は暗号学的プライバシーを保ちながらリクエストごとのレイテンシーを排除する、セッションベースのアーキテクチャを中心に設計されています。そのため、行動メタデータを漏らすことなく、API、データ、コンピューティング、AIツールの料金をプログラムから支払う必要があるAIエージェントに特に適しています。
/.well-known/payment 検出機密性の高いワークフロー、法務調査、医療クエリ、財務分析、競合情報を扱うAIエージェントにとって、公開決済はすべてメタデータ漏洩につながります。Zimppy は、デフォルトでプライベートな唯一のMPP決済方式です。
| 特性 | パブリックチェーン（USDC、ETH） | Zimppy シールド | Zimppy 透明 |
|---|---|---|---|
| 送信者 | 可視 | 暗号化 | 可視 |
| 受信者 | 可視 | 暗号化 | チャレンジごと（リンク不能） |
| 金額 | 可視 | 暗号化 | 可視 |
| メモ | 可視 | 暗号化 | 該当なし |
| リプレイ防止 | なし | メモバインディング | チャレンジごとのTアドレス |
| サービス利用パターン | リンク可能 | プライベート | リンク不能（新しいアドレス） |
「しかし Zcash のブロック時間は75秒です。」
セッションがこれを解決します。 オンチェーンでの待機は、入金時に一度だけ発生します。その後のすべてのリクエストは即時です。
Agent -> deposit 100,000 zat (one on-chain tx, ~75s)
Agent -> open session (bearer token issued)
Agent -> request -> response (0ms - no chain interaction)
Agent -> request -> response (0ms - no chain interaction)
Agent -> request -> response (0ms - no chain interaction)
... hundreds of requests ...
Agent -> close session (refund unused balance)
一度支払い、即時に呼び出し、おつりを受け取る。 リクエストごとのレイテンシーはゼロです。
Machine Payment Protocol（MPP） は、自律的なソフトウェアエージェント（AIエージェント、ボット、スクリプト）が、人間の介入なしにAPIアクセスの決済要件を検出、交渉、履行できるようにする標準化プロトコルです。
MPP は HTTP の 402 Payment Required フローに従います。
402 Payment Required と署名済みチャレンジ（金額、受取人、メモ）を返します。Authorization: Payment {txid} を付加してリクエストを再送します。200 OK と Payment-Receipt ヘッダーを返します。/.well-known/payment エンドポイントセッションは主要な利用パターンです。エージェントはオンチェーンで一度残高を入金し、ベアラートークンを受け取って、その後のすべてのリクエストでレイテンシーゼロの決済を行います。
Agent -> deposit 100,000 zat (on-chain, ~75s one-time)
Agent -> open session (bearer token issued)
Agent -> GET /api/query + bearer (instant, balance deducted)
Agent -> GET /api/query + bearer (instant, balance deducted)
Agent -> close session (refund unused balance on-chain)
最適な用途： 高頻度API呼び出し、LLM推論、繰り返し行うデータクエリ。
Server-Sent Events（SSE） を介して配信される、トークン単位課金のコンテンツです。サーバーはストリーミングする単語またはトークンごとにセッション残高から差し引きます。
Agent -> open session with deposit
Agent -> GET /api/stream (SSE)
Server -> stream word by word, deducting per token
Agent -> close session, refund remaining
最適な用途： LLMのストリーミング応答、リアルタイムデータフィード、トークン単位課金AIツール。
リクエストごとに単一のシールド決済を実行します。完全な HTTP 402 フローが呼び出しごとに実行されます。リクエスト頻度が低い場合や高額な場合に適しています。
Agent -> GET /api/resource
Server -> 402 + challenge (amount, recipient, memo)
Agent -> shielded ZEC with memo "zimppy:{challenge_id}"
Agent -> GET /api/resource + Authorization: Payment {txid}
Server -> decrypt with Orchard IVK, verify amount + memo
Server -> 200 OK + Payment-Receipt
最適な用途： 高額な単発リクエスト、低頻度のAPI呼び出し、プレミアムデータエンドポイント。
法務AIエージェントが、有料の判例データベースをクエリします。Zimppy のシールドセッションを使用すれば、法律事務所の身元も具体的なクエリ内容もオンチェーンに公開されず、インフラレベルで弁護士・依頼者間の秘匿特権を保護できます。
Agent opens session (100,000 zat deposit)
-> GET /api/cases?q=patent+infringement+2024 (instant)
-> GET /api/cases?q=prior+art+semiconductor (instant)
-> GET /api/document/US11234567B2 (instant)
Session closed, unused balance refunded
医療診断エージェントが複数の臨床データベースをクエリします。シールド決済により、患者クエリのパターンがプロバイダー間でリンクされることを防ぎます。
アルゴリズム取引エージェントがリアルタイム市場データAPIに料金を支払います。透明決済ではチャレンジごとに新しいTアドレスを使用するため、データベンダー間での利用パターンの相関を防止します。
MCP（Model Context Protocol）サーバーが有料AIツールを公開します。各ツール呼び出しで Zimppy チャージが発生し、収益化されたAI機能のマーケットプレイスを実現します。
LLM要約サービスは、SSEストリーミング経由で出力トークンごとにエージェントへ課金し、残高を自動的に差し引き、未使用の前払い残高を返金します。
npm install zimppy # CLI + wallet
npm install zimppy-ts # TypeScript SDK
[dependencies]
zimppy-core = "0.5" # Rust verification engine
zimppy-rs = "0.5" # Rust SDK (charge, session, axum)
Zimppy CLI は完全なウォレットインターフェースを提供します。すべてのコマンドは npx zimppy から利用できます。
npx zimppy wallet create
暗号鍵を生成し、シードフレーズを表示します。これは安全に保管してください。紛失した場合は復元できません。
npx zimppy wallet whoami
Unified Address（UA）、Tアドレス、現在の残高、アクティブなネットワークを表示します。
npx zimppy wallet balance --all
すべての ZIP-32 アカウントのアカウント別残高内訳を表示します。
Zcash 対応の任意のウォレットまたは取引所から、Unified Address に ZEC を送信します。シールド入金は直接 Orchard アカウントに入ります。
# Send ZEC to any address (shielded or transparent)
npx zimppy wallet send <addr> 42000
# Move transparent funds into Orchard (shielded)
npx zimppy wallet shield
# Transfer between your own accounts
npx zimppy wallet transfer 0 1 50000
# Switch active wallet identity
npx zimppy wallet use work
npx zimppy request <url>
完全な 402 -> 支払い -> 再試行フローを自動的に処理します。セッションは透過的に開始・管理されます。
import { Mppx } from 'mppx/server'
import { zcash } from 'zimppy-ts/server'
const mppx = Mppx.create({
methods: [await zcash({ wallet: 'server' })],
realm: 'my-api',
secretKey: process.env.MPP_SECRET_KEY,
})
const result = await mppx.charge({
amount: '42000',
currency: 'zec',
})(request)
if (result.status === 402) return result.challenge
return result.withReceipt(Response.json({ data }))
ポイント：
zcash({ wallet: 'server' }) はサーバーのシールドウォレットを読み込みますmppx.charge() は完全な402チャレンジ／検証ライフサイクルを処理しますresult.withReceipt() は暗号学的な決済レシートをレスポンスに付加しますimport { Mppx } from 'mppx/server'
import { zcashTransparent } from 'zimppy-ts/server'
const mppx = Mppx.create({
methods: [await zcashTransparent({ wallet: 'server' })],
// per-challenge T-address generated automatically (replay-safe)
})
各チャレンジで新しいTアドレスが生成されるため、決済リクエストはセッション間でリンク不能になります。
import { Mppx } from 'mppx/client'
import { zcash } from 'zimppy-ts/client'
const mppx = Mppx.create({ methods: [zcash({ wallet: 'default' })] })
// Session opened automatically; 402 is handled transparently
const res = await mppx.fetch('https://api.example.com/resource')
クライアントは 402 レスポンスをインターセプトし、自動的にセッションを開始してリクエストを再試行します。呼び出し元のコードに決済固有のロジックは必要ありません。
use mpp::server::axum::*;
use zimppy_rs::ZcashChallenger;
struct Price;
impl ChargeConfig for Price {
fn amount() -> &'static str { "42000" }
}
async fn handler(charge: MppCharge<Price>) -> WithReceipt<Json<Value>> {
WithReceipt {
receipt: charge.receipt,
body: Json(data),
}
}
ポイント：
MppCharge<Price> は、ハンドラー実行前に決済を検証する Axum エクストラクターですWithReceipt は、暗号学的な決済レシートでレスポンスをラップしますChargeConfig は価格設定ロジックを定義します。リクエストパラメータに応じて動的に設定できますuse mpp::client::Fetch;
use zimppy_rs::ZcashPaymentProvider;
let provider = ZcashPaymentProvider::new(wallet_config, &rpc);
let resp = client
.get("https://api.example.com/resource")
.send_with_payment(&provider)
.await?;
send_with_payment は、任意のHTTPクライアントを自動402処理、セッション管理、Zcash 決済履行の機能で拡張します。
| コマンド | 説明 |
|---|---|
npx zimppy wallet create | 鍵を生成してシードフレーズを表示 |
npx zimppy wallet whoami | アドレス（UA + Tアドレス）、残高、ネットワークを表示 |
npx zimppy wallet balance --all | アカウント別残高内訳 |
npx zimppy wallet send <addr> <zat> | シールドまたは透明の ZEC を送信 |
npx zimppy wallet transfer <from> <to> <zat> | アカウント間の内部送金 |
npx zimppy wallet shield | 透明資金を Orchard（シールド）へ移動 |
npx zimppy wallet use <name> | アクティブなウォレットIDを切り替え |
npx zimppy request <url> | 自動 402 -> 支払い -> リクエスト再試行 |
Zimppy ウォレットは、人間が管理するブラウザー拡張機能ではなく、AIエージェントによるプログラム利用のために設計されています。鍵は CLI または SDK により管理され、アカウントは ZIP-32 アカウント導出を通じてローテーションでき、ウォレットは取引ごとの人間の承認なしに完全自動の決済フローをサポートします。
複数のエージェントが ZIP-32 アカウントローテーションを使用して同じウォレットから操作できます。各エージェントには、分離された残高追跡、アカウント間送金機能、アカウント別残高レポートを備えた独自のアカウントが与えられます。これにより、単一のウォレットインフラから多数のエージェント群を管理できます。
シールド決済は、NU5 によって導入されたシールドプールである Zcash の Orchard プロトコルを使用します。サーバーは、支出鍵を公開せずに受信ノートを復号できる Incoming Viewing Key（IVK） により決済を検証します。リプレイ攻撃はメモバインディングにより防止されます。各チャレンジには暗号学的に検証される一意の zimppy:{challenge_id} メモが埋め込まれます。
セッションアーキテクチャは、オンチェーン承認の待機時間をリクエストごとのレイテンシーから切り離します。一度の入金（約75秒）の後、すべてのベアラートークンリクエストは、セッション終了時までブロックチェーン操作なしに即時処理されます。
ネイティブの SSE（Server-Sent Events） 対応により、トークン単位課金コンテンツを実現します。出力長が可変であり、実際の消費量に応じた課金が求められるLLM推論APIに最適です。
/.well-known/paymentcrates/
zimppy-core/ Zcash verification engine (Orchard decryption, replay protection)
zimppy-wallet/ Native Zcash wallet (zingolib)
zimppy-rs/ Rust SDK (ChargeMethod, SessionMethod, PaymentProvider, axum extractors)
zimppy-napi/ Node.js native bindings (NAPI-RS)
packages/
zimppy-ts/ TypeScript SDK (charge, session, SSE)
zimppy-cli/ CLI with auto-pay and session management
zimppy-core - 暗号学的コア。サーバーのIVKを使用する Orchard ノート復号、メモ解析、リプレイ防止ロジック、チャレンジ検証を処理します。パフォーマンスと正確性のために Rust で記述されています。
zimppy-wallet - zingolib を基盤とするネイティブ Zcash ウォレットです。鍵、アカウント、シールド／透明残高、トランザクション送信を管理します。
zimppy-rs - Rust SDK。ChargeMethod、SessionMethod、PaymentProvider トレイトに加え、使いやすいサーバー統合のための Axum エクストラクター（MppCharge、WithReceipt）を提供します。
zimppy-napi - Rust コアを Node.js に公開する NAPI-RS バインディングです。これにより TypeScript SDK は、JavaScriptで Zcash プリミティブを再実装せずに同じ暗号エンジンを使用できます。
zimppy-ts - TypeScript SDK。NAPI バインディングをラップし、チャージ、セッション、SSEストリーミングフロー向けに慣用的な async/await API を提供します。
zimppy-cli - コマンドラインのウォレットおよびリクエストツールです。自動支払い（402 -> 支払い -> 再試行）、セッション管理、すべてのウォレット操作をサポートします。
| サンプル | 説明 |
|---|---|
examples/fortune-teller/ | チャージ、セッション、ストリーミングのデモ - Rust サーバー + クライアント |
examples/llm-summarizer/ | トークン単位課金 LLM ストリーミングデモ |
examples/mcp-server/ | 有料AIツールを備えた MCP ツールサーバー |
examples/ts-server/ | TypeScript MPP サーバーのリファレンス実装 |
| 機能 | 説明 |
|---|---|
| セッション | 一度入金、即時ベアラーリクエスト、終了時に返金 |
| ストリーミング | SSE経由のトークン単位課金コンテンツ |
| チャージ | HTTPリクエストごとのシールドまたは透明決済（402フロー） |
| 透明決済 | チャレンジごとのリプレイ防止機能を備えたTアドレス + shield コマンド |
| マルチアカウント | ZIP-32 アカウントローテーション、アカウント間送金、アカウント別残高 |
| CLI ウォレット | 送金、シールド、送金振替、balance --all、whoami、自動支払い |
| デュアルSDK | TypeScript と Rust |
| 仕様準拠 | HMAC-SHA256 チャレンジ、RFC 9457 エラー、/.well-known/payment 検出 |
詳細は zimppy.xyz をご覧ください