zk.moneyは、Ethereumの公開台帳に残る情報を減らしながら送金するため、Aztec Network上で2026年9月29日に再始動した自己管理型ウォレットです。ただし、すべてを隠す完全匿名のサービスではありません。
たとえば「完全匿名になる」と思い、取引所の自分名義アドレスから入金した直後に同額を別アドレスへ出金すると、公開された金額と時刻から入口と出口の対応を推測されるおそれがあります。内部送金が非公開でも、この外側の記録は残ります。
利用前に見るべき点は三つです。内部で隠れるもの、Ethereum上や外部共有で残るもの、そしてサービスが止まったとき自力で戻せるかです。以下では、この順序を軸に条件を確認します。
内部の残高・金額・相手方は公開されない一方、Ethereumとの入出金ではアドレス・金額・時刻が公開されます。本稿では仕組み、利用条件、自己管理、停止時の退出、制裁審査を整理します。利用を推奨するものではなく、判断材料を得るための解説です。
編集・検証情報
- 責任編集：編集部
- 技術確認：編集部（公式ドキュメントおよび公開リポジトリを照合）
- 検証日：2026年10月1日
- 対象：2026年9月29日再始動時点のzk.money／Aztec Alpha
- 更新方針：上限、対応資産、審査、退出手順に変更が確認された場合は公式資料を優先して更新
上限や対応条件は変わる可能性があります。実行時は公式ドキュメントのOverview、Limits、Deposit、Withdraw、Exitを最終確認先としてください。
zk.moneyは3年ぶりに何を変えて再始動したのか
新版は旧版の口座を引き継ぐ更新版ではなく、Aztec Network上に作り直された別サービスです。まず、同じ名称から生じやすい混同を解きます。
2023年に終了した旧版とは別のウォレット
旧版は2023年に終了し、新版へ口座や資金は引き継がれません。同名でも別のウォレットとして扱い、古い操作記事を混同しないことが重要です。
Aztec Network上の自己管理型サービスとして再設計
新版はAztec Network上の自己管理型です。運営が利用者の代わりに資金を保管・移動しない一方、認証情報の管理責任は利用者に残ります。
Aztec上でプライベート決済が成立する仕組み
内部の取引内容を公開せずに正当性だけを確かめ、最終結果をEthereumへつなぐのが基本構造です。ここでは利用時の待機や障害に関係する範囲に絞ります。
ゼロ知識証明は、内容そのものを明かさず条件を満たすことを示す技術です。zk.moneyではこの考え方を使い、取引内容を公開台帳へそのまま載せずに正当性を検証します。基盤となるEthereumのレイヤー2は、Ethereum外で処理した結果を最終的にEthereumへ記録する仕組みです。
秘密関数は端末側、公開関数はシーケンサーが実行
秘密関数は端末側、公開関数はシーケンサーが実行します。秘密そのものではなく、規則に従った処理であることを示す証明を扱います。
秘密状態と公開状態を併用するL2設計
秘密状態はUTXO方式、公開状態はアカウント方式で扱い、ロールアップ証明をEthereumへ保存します。非公開処理と公開処理を併用するL2です。
Ethereumとの入出金は即時完了しない
EthereumとAztecはポータルを介した非同期メッセージで接続されます。境界をまたぐ入出金が一度の同期処理で終わらない理由です。
端末は非公開データを使って「この支払いを行う権限と残高がある」と示す証明を作ります。相手、金額、残高そのものを公開して検査させるのではなく、条件を満たしたという結果をネットワークへ渡すイメージです。公開処理はシーケンサーが順序付けし、複数の処理をまとめたロールアップ証明がEthereumへ送られます。利用者に重要なのは、端末での証明生成、Aztec上での処理、Ethereumでの確定が一瞬の一工程ではない点です。
EthereumとAztecは別の実行環境なので、入金はEthereum側で資産を預けた後、そのメッセージをAztec側が取り込んで内部残高へ反映します。出金は逆に、Aztec側で権利を証明し、必要な署名とL2の確定を待ってEthereum側で資産を解放します。秘密情報を伴う処理をEthereumから直接同期実行させないため、ポータルを介した非同期メッセージになります。したがって、片側の処理が済んでも反対側への反映待ちが生じ、障害時には再試行や稼働回復を待つ場合があります。
zk.moneyが隠す情報とEthereum上に残る情報
プライバシーの境界はAztec内部とEthereumとの出入口で変わります。内部で隠れる情報があっても、公開チェーンの入出金記録まで消えるわけではありません。
内部決済で非公開になる残高・金額・相手方
内部では残高、送金額、相手方が公開台帳へそのまま載りません。ただし当事者による公開や外部サービスの記録まで消えるわけではありません。
入出金時に公開されるアドレス・金額・時刻
Ethereumとの入出金ではアドレス、金額、時刻が公開されます。「内部」と「公開チェーンとの出入口」を分けて理解します。
同額・近接時刻の移動から対応関係を推測される可能性
同額に近い資金を近接時刻に動かすと、対応関係を推測される可能性があります。推測は証明ではなくても、他の公開情報と組み合わさる点に注意します。
内部決済で公開されないのは、Aztec内の残高、送金額、送受信者の対応です。一方、Ethereumからポータルへ資産を送る入金と、ポータルからEthereumアドレスへ戻す出金は公開チェーン上の取引です。チェーンを閲覧できる人は、出入口のアドレス、金額、時刻を確認できます。取引所や決済サービスを使えば、それらの事業者が持つ本人情報やアクセス記録が別に存在する可能性もあります。
「内部で誰から誰へ動いたかが見えない」ことと、「入口と出口に関係がないと証明できる」ことは同じではありません。10,000 DAIの入金後、短時間でほぼ同額が一度だけ出金されれば、観察者は断定できなくても有力な候補として結び付けられます。金額の珍しさ、時間の近さ、SNSでの支払い報告など手掛かりが重なるほど推測は強まります。zk.moneyはこの種のメタデータ相関を自動的に無効化する保証をしていません。
利用時にプライバシーを弱める行動
技術が取引内容を隠しても、アドレスの再利用や公開タグ、SNS投稿など利用者が残す手掛かりは消せません。漏えい経路ごとに対策を分けます。
単回の入金アドレスを再利用しない
入金には単回利用のアドレスを使い、過去の入金先を再利用しません。再利用すると複数の送金元や時刻を一つの入口へ結び付けやすくなります。
公開タグと支払いリンクの扱いに注意する
タグと支払いリンクは便利ですが、SNS名や実在の人物と結び付きやすい識別子でもあります。公開範囲と利用期間を考えて扱います。
恒久的なメッセージングとの紐付けを避ける
実名SNS、メール、業務チャットに支払い内容を残せば、その記録が当事者、目的、時刻の手掛かりになります。必要な記録と一般公開を分けます。
単回入金アドレスは、その入金のために画面が示した宛先です。同じ宛先を複数回使うと、別々だった送金元が共通の利用者に関係すると推測する材料になります。過去のスクリーンショットやアドレス帳から再利用せず、毎回公式画面で新しい表示を確認してください。この注意は旧版との互換性やDAI交換とは別の問題で、目的は入金同士の結び付きを増やさないことです。
タグや支払いリンクは受取先を伝えやすくしますが、公開SNSやプロフィールに固定すると、その識別子と実在の人物・活動が長期間結び付きます。必要な相手へ必要な期間だけ共有し、投稿に金額や正確な時刻を添えないことが実務上の対策です。暗号化されたメッセージでも、相手側の保存や転送まで保証されるわけではありません。技術上の非公開範囲と、自分や相手が外部へ残す情報を分けて考えます。
対応資産・上限・入出金で知っておくべき条件
初期仕様の重要条件は、内部残高がDAI、各取引が2,500ドル未満、通常出金が即時ではないことです。操作前に次の表で全体を確認してください。
| 項目 | 再始動時点の条件 | 利用者が確認すること |
|---|---|---|
| 内部残高 | DAI | USDC・USDTはCurve経由でDAIへ交換される |
| 取引上限 | 入金・内部送金・出金は各2,500ドル未満 | 2,500ドルちょうどは不可。日次の全体入金枠も確認 |
| 公開情報 | Ethereum入出金のアドレス・金額・時刻 | 内部経路を通しても出入口の記録は消えない |
| 通常出金 | 目安約1時間 | 保証時間ではなく、Oxideやネットワークの稼働に依存 |
| 認証 | パスキー | 紛失時は運営も復旧できない |
DAIは米ドル連動を目指すステーブルコインですが、価格が常に1ドルで固定される保証を意味しません。さらにUSDC・USDTからの交換ではCurveの価格差や手数料が影響するため、送信額と内部表示額が完全一致しない場合があります。
初期残高はDAI、USDC・USDTは入金時に交換
初期仕様では内部残高はDAIです。Ethereum上のUSDCとUSDTはCurve経由でDAIへ交換され、入金銘柄のまま残るわけではありません。
入金・内部送金・出金は各2,500ドル未満
各入金、内部送金、出金は2,500ドル未満です。全利用者を合計した日次入金枠もあり、個別上限内でも常に処理できるとは限りません。
Curveでの価格差と非対応資産・他チェーン誤送金のリスク
交換時の価格差を確認します。非対応資産や別チェーンからの誤送金は回収不能になり得るため、資産名だけでなくネットワークと宛先も照合します。
通常出金の目安は約1時間
通常出金は利用者の証明、Oxideの共同署名、L2証明を経てEthereumで解放され、目安は約1時間です。保証時間ではありません。
通常出金では、まず利用者の端末が出金権限を示す証明を作り、Oxideが追加署名します。次に出金処理がAztec側で取り込まれ、L2の状態が確定した後、Ethereum側のポータルから資産が解放されます。公式の約1時間はこの一連の目安で、確定を約束する期限ではありません。ネットワーク混雑、証明処理、ノードやOxideの停止があれば長引きます。
途中で画面を閉じた、表示が更新されないというだけで、同じ出金を直ちに重ねて実行しないでください。まず公式の履歴と案内で現在の段階を確認します。Oxideが利用できない場合は通常経路が進まず、稼働再開または公式Exit資料にある代替経路が必要です。期限のある支払いに直結させず、待機を許容できる資金量にとどめる判断が重要です。
自己管理型でも利用者だけでは完結しない信頼モデル
まなぶ「クリプ先生、自己管理なら自分だけでいつでも出金できるの？」
クリプ「所有と可用性は別なんだ。ノードやOxideが止まった場合の経路も先に確かめよう。」
自己管理型とは運営が自由に資金を動かせない設計を指します。しかし、パスキー、ノード、リレイヤー、Oxideが止まった場合の操作可否まで利用者だけで完結するという意味ではありません。
運営にも復旧できないパスキー管理
パスキーを失うと運営も復旧できません。一般的なパスワード再設定と同じ感覚では扱わず、保存先や端末故障時の扱いを事前に確認します。
ノードとリレイヤーは資金を奪えなくても処理を止められる
ノードやリレイヤーは資金を勝手に動かせなくても、受付や中継を止め得ます。資金の所有と操作経路の可用性は別です。
送金・出金に必要なOxideの共同署名
送金と出金にはOxideエンクレーブの共同署名が必要です。単独で資金を奪うという説明ではありませんが、稼働は可用性の依存先です。
Oxideは、隔離された実行環境で送金・出金へ追加署名する仕組みです。運営が利用者のパスキーなしに単独で残高を移すための鍵ではありませんが、Oxideが一つも動かなければ通常の送金・出金は止まり得ます。同様に、ノードはAztecの状態を読み、リレイヤーは処理を中継します。いずれも「資金を奪える権限」と「処理を受け付けない・中継しないことで止める能力」を混同しないことが大切です。
このため自己管理性の評価は、誰が署名できるかだけでは終わりません。パスキーを自分が維持できるか、通常経路が停止したとき別ノードやデスクトップ版を扱えるか、最終手段の費用と技能を負担できるかまで含みます。復旧不能な認証と、外部構成要素への可用性依存が同時に存在する点が、新版を利用するうえでの中心的なトレードオフです。
サービス停止時に資金を退出させる方法と難度
退出経路は一つではありませんが、代替手段ほど技術的な難度が上がります。「方法が存在する」ことと「自分が緊急時に実行できる」ことを分けて評価します。
サイト停止時はデスクトップ版と別ノードを試す
公式サイト停止時もデスクトップ版と別ノードを使う経路があります。ただし通常のウェブ利用より技術知識が必要です。
公式配布物のハッシュ照合で改ざんを確認する
デスクトップ版は公式配布物の署名やハッシュを照合します。改ざん版に認証情報を盗まれれば、自己管理の設計だけでは防げません。
最終手段の自前エンクレーブにはAWS費用と専門知識が必要
全エンクレーブ停止時はAWS Nitro Enclavesを自前運用できますが、環境構築、登録、費用、専門知識が必要で、容易な救済策とは限りません。
停止時は難度の低い順に、通常のウェブ画面、公式デスクトップ版、別のAztecノード、必要に応じて自前のOxideエンクレーブを検討します。ウェブサイトだけの障害ならデスクトップ版で同じパスキーを使える可能性があります。既定ノードの障害なら別ノードへ接続します。しかし、どの段階でも公式手順、正しいソフトウェア、保持している認証情報が必要で、第三者が無条件に救済する仕組みではありません。
デスクトップ版は配布元だけで判断せず、公式が示すハッシュとダウンロードしたファイルのハッシュを照合します。ハッシュはファイル内容から作る短い照合値で、一文字でも異なれば同じ配布物ではない可能性があります。改ざん版へパスキーを入力すれば、プロトコルの自己管理性とは別の経路で盗難につながります。確認方法を平常時に試し、停止後に初めて学ぶ状態を避けてください。
全Oxide停止時の自前運用は、AWS Nitro Enclavesの環境構築、EthereumとAztecでの登録、クラウド費用やネットワーク費用を伴います。これはボタン一つの緊急出金ではありません。手順書が公開されていても、自分の知識・時間・予算で再現できなければ、実質的に使える退出経路とはいえません。保有額を決める前に、どの段階まで自力で実行できるかを確認します。
制裁スクリーニングとAlpha段階のリスクを踏まえた判断
入出金アドレスはオフチェーンで制裁審査される
入出金先はPredicateの方針に基づいてオフチェーンで制裁審査されます。内部決済が非公開でも、出入口で審査を受けます。
フロントエンドとリレイヤーが処理を拒否できる
フロントエンドとリレイヤーは処理を拒否できます。資金を取得できないことと、通常経路を止められないことは別です。
Alphaの機能完成と安全性の成熟は同義ではない
Alphaは機能がそろった初期版ですが、公式発表は既知の脆弱性とBetaへ向けた更新にも触れます。機能完成は安全性成熟の保証ではありません。
制裁審査は内部の送金内容を公開する仕組みとは別に、Ethereum側の入出金アドレスを対象として行われます。Predicateの方針に基づくオフチェーン審査により、該当すると判断されたアドレスは通常のフロントエンドやリレイヤーで処理を拒否される可能性があります。非公開取引を使えることは、無条件でサービスを利用できることを意味しません。
さらに基盤はAlpha段階です。公式発表がいう「機能がそろった」は、本番利用であらゆる脆弱性が解消されたという意味ではなく、既知の課題とBetaへ向けた更新予定が示されています。対応資産や上限だけでなく、最新のセキュリティ告知、停止状況、Exit手順を確認し、失って困る資金や期限のある支払いを置かないことが現実的な判断になります。
条件を利用判断へ落とし込む3つのケース
ケース1：取引所から入金し、すぐ別の自分のアドレスへ戻す。Aztec内部の移動は公開されなくても、取引所側には本人情報と出金記録が残り、Ethereumには入金と出金のアドレス・金額・時刻が残ります。入口と出口が同額で時間も近ければ、第三者は両者の関連を推測できます。「内部を一度通したから、公開履歴との関係が必ず切れた」とは判断できません。この使い方で求めるプライバシーが、内部取引の秘匿なのか、現実の身元との切断なのかを先に言葉にすると、期待と機能のずれを見つけやすくなります。
ケース2：知人からタグで継続的に支払いを受ける。内部では相手方と金額が公開されませんが、同じタグを実名SNS、仕事用プロフィール、公開チャットで共有すれば、タグと本人の関係は外部に残ります。支払った相手も共有履歴を持ちます。公開範囲を狭めるには、タグやリンクを不特定多数へ固定表示する必要があるか、個別連絡で足りるかを考えます。受取直後に金額や時刻を投稿しないことも、チェーン上の出入口と照合できる材料を増やさないための基本です。
ケース3：緊急時にすぐ資金が必要になる。通常出金には約1時間という目安があり、Oxide、ノード、リレイヤー、L2の確定、Ethereum側の解放が関係します。目安は締切ではなく、障害時には長引きます。公式サイトが止まっても代替経路はありますが、デスクトップ版の真正性確認や別ノードの設定、自前エンクレーブの運用は同じ難度ではありません。短時間で必ず引き出せることが必要な資金と、待機や技術作業を許容できる資金を分けるべきです。
三つのケースに共通するのは、機能名ではなく失敗時の結果から考えることです。公開されたくない情報はどこに残るか、認証を失ったとき誰が助けられるか、通常経路を拒否・停止されたとき自分はどの代替手段まで扱えるかを確認します。答えが曖昧な項目があれば、利用額を小さくする、期限のある用途を避ける、利用を見送るという判断も含めて比較してください。
公式資料をどの順番で確認するか
最初にOverviewとFAQで、現在表示されているサービスが新版であること、旧版の口座や資金を引き継がないこと、内部残高と対応資産を確認します。次にLimitsを開き、取引上限、日次入金枠、制裁審査の条件を実行時点で読み直します。上限は記事を読んだ日の記憶ではなく、実際に操作する日の公式表示を優先してください。入金ではDeposit、出金ではWithdrawを開き、対応ネットワーク、生成された宛先、処理の段階を画面と一つずつ照合します。
停止時の備えはExitとDesktopの資料を平常時に確認します。デスクトップ版を使う可能性があるなら、公式配布元、ハッシュの掲載場所、照合方法まで把握しておきます。別ノードや自前エンクレーブは、手順が公開されていることを確認するだけでは不十分です。自分の環境で必要になるソフトウェア、クラウド契約、登録費用、作業時間を見積もり、緊急時に本当に実行できるかを判断します。
情報が食い違う場合は、ニュース記事や過去の解説より、操作対象と同じ版の公式ドキュメントと公式画面を優先します。ただし公式資料も安全性を保証するものではないため、Alphaの告知、公開リポジトリ、最新の障害・セキュリティ情報を合わせて確認します。本稿の出典カードには、各節の主張を支える資料名、発行元、公開日または更新日の有無、2026年10月1日の閲覧日を付けています。どの主張の根拠かを確認し、仕様値は必ず一次資料へ戻ってください。
画面上の処理状態が不明なときは、焦って別資産や別チェーンでやり直さず、取引識別子、使用したネットワーク、表示された宛先、開始時刻を記録して公式案内と照合します。再試行によって二重操作や追加損失を招かないよう、どの段階で止まったかを先に切り分けます。また、サポートを名乗る人物から秘密情報やパスキーの共有を求められても応じません。正規の資料へ自分で移動し、表示条件と出典の更新日を確認することが、プライバシー機能以前の基本的な防御になります。
利用前に確認したい実践チェックリスト
最後に、公式資料で示された条件を操作前の順番へ並べ替えます。チェック項目は安全性を保証するものではありませんが、思い込みによる誤送金や、退出方法を知らないまま資金を置く事態を避ける助けになります。ウォレットの種類から整理したい場合は暗号資産ウォレットの選び方、認証情報の基礎は秘密鍵の管理方法も参照してください。
入金前：資産・ネットワーク・公開情報を確認する
最初に、新版の公式画面であることを確認し、旧版のアカウントや古い入金先を使わないようにします。次に、送金元がEthereum上の対応資産であるか、入金後にDAIとして扱われることを理解しているかを確認します。USDCまたはUSDTを使う場合は、Curveで交換されるため、送信額と内部で受け取る価値が常に完全一致するとは限りません。非対応資産や別チェーンからの送金は回収不能になり得るので、名称が似ていることだけで判断しません。
入金アドレスは今回の画面に表示された単回利用のものかを確認します。過去の履歴、アドレス帳、スクリーンショットからコピーした宛先は再利用しません。入金額は2,500ドル未満か、全体の日次枠によって受付が制限されていないかも画面で確認します。そして、Ethereum上には送信元、金額、時刻が残ることを前提にします。通常の安全な送金確認は暗号資産の送金手順でも整理しています。
利用中：タグと外部情報の結び付きを見直す
内部送金では残高・金額・相手方が公開されませんが、タグや支払いリンクを誰に共有したかは別の情報です。公開SNSへ恒久的に載せる必要があるのか、個別の相手にだけ伝えれば足りるのかを考えます。取引と同時に金額や時刻を投稿すれば、公開チェーンの入出金と照合する手掛かりにもなります。プライバシー機能は、利用者自身が公開した情報を後から消す仕組みではありません。
また、パスキーの保存状態を定期的に確認します。端末の紛失、故障、買い替えが起きたときに利用できるかを、公式の対応条件に沿って把握しておきます。復旧について不明な点がある状態で大きな残高を置くことは、自己管理の責任を理解したことにはなりません。運営やサポートを名乗る相手からパスキーの提示を求められても渡さないことが基本です。
出金前：時間・審査・停止時の代替経路を確認する
出金は通常約1時間という目安を前提に、期限直前の支払いには使わないほうが混乱を避けやすくなります。出金先はEthereum上の正しいアドレスか、金額は2,500ドル未満か、制裁スクリーニングによって処理が拒否される可能性を理解しているかを確認します。同額を入金直後に出金すると相関を推測される可能性があるため、「内部を通しただけで履歴の関係が必ず切れる」と考えないことも大切です。
通常画面が動かない場合に備え、公式のExit資料、デスクトップ版、配布物のハッシュ確認、別ノードの手順がどこにあるかを把握します。最終手段の自前エンクレーブはAWS費用と専門作業を必要とします。自分が実行できない場合、第三者が必ず代行してくれるという前提は置けません。退出経路の存在と、自分が現実に使える退出経路を区別してから利用額を判断します。
まとめ：完全匿名ではなく、公開境界と退出難度まで確認する
内部決済は非公開でもEthereumとの入出金情報は公開されます。初期残高はDAI、各取引は2,500ドル未満、通常出金の目安は約1時間です。パスキーは運営にも復旧できず、処理はノード、リレイヤー、Oxideの可用性にも関係します。
旧版との違い、公開境界、資産変換、上限、認証情報、停止時の退出難度、制裁審査、Alpha段階のリスクを確認し、自分が理解できる範囲と許容できる損失の範囲で慎重に判断してください。
