結論からいうと、HashiはSui上でBitcoinをhBTCとして利用するための基盤で、mainnet 1.0の成果物は公開されましたが、それだけで全利用者がすでに使える、あるいは5億ドル超のBTCが預け入れられたという意味ではありません。公式発表は2026年10月末からの段階展開と、20超の参加者による5億ドル超の「資本コミットメント」を示しています。
この記事では、発表のどこまでが確定し、何が今後の確認事項なのかを最初に切り分けます。そのうえで、BTCを預けてhBTCを受け取り、hBTCを焼却してBTCへ戻す流れ、MPC委員会とGuardianによる鍵管理、停止・復旧の仕組み、利用前の注意点を初心者向けに順番に解説します。価格見通しや売買推奨ではなく、仕組みとリスクを判断するための記事です。
| 現在地 | 確認できること | 利用前に見る場所 |
|---|---|---|
| できること | mainnet 1.0の成果物、ハッシュ、ビルド証明は公開済み | GitHubの公式リリース |
| 発表済み | 2026年10月末からの段階展開 | Sui公式発表と利用アプリの告知 |
| 現時点で要確認 | 一般利用の範囲、対応アプリ、実預入額、入出庫の稼働状態 | 公式画面、コントラクト状態、Sui・Bitcoinの取引ID |
したがって、記事を読んだだけで利用可能と判断せず、操作直前に対象アプリのネットワーク表示、入出庫の停止表示、提示された預入アドレス、最小額と待機時間を確認します。
Hashi mainnet 1.0で何が発表されたのか
「mainnet 1.0公開」という言葉だけを見ると、すべての機能が一斉に一般開放されたように感じます。しかし、今回の情報は二つに分けて読む必要があります。一つはSui Foundationが示した段階展開の計画、もう一つはMysten Labsが公開した検証可能なソフトウェア成果物です。予定、コードの準備、実際の利用開始は同じ出来事ではありません。
10月末から始まる段階展開
Sui Foundationは2026年10月8日、Hashi mainnetを同月末から段階的に展開すると発表しました。「段階的」とあるため、対象者、対応アプリ、利用枠が同時に全面開放されるとは限りません。利用を検討する場合は、発表日だけでなく、実際に使う公式画面、対応アプリの案内、オンチェーン上の状態を直前に確認する必要があります。
発表ではAnchorage Digitalが連合に加わり、機関向けの導線を提供するとされています。ただし、機関向け導線の存在と、一般利用者が同じ条件で利用できることは別です。地域、本人確認、サービスごとの条件もHashiの技術仕様だけでは決まりません。
mainnet 1.0は検証可能な成果物の公開
Mysten Labsのリリースには、mainnet 1.0のバイナリ、Dockerイメージ、ハッシュ、ビルド証明が掲載されています。運用者は取得物が公開された成果物と一致するかを確かめられます。一方、リリース説明は、この公開がHashiそのものをデプロイするものではないと明記しています。
つまり「ソフトウェアを検証できる状態」と「利用者がBTCを預けられる状態」は分けて考えます。署名済みコミットやSHA-256、Docker digest、GitHub attestationは供給経路の確認材料ですが、稼働後の障害や統合先の安全性まで保証するものではありません。
testnetからmainnetまでの経緯
Hashiは2026年3月に構想と初期参加企業が公表され、6月には参加者の拡大と7月のグローバルtestnet計画が示されました。7月22日のtestnet開始では、実BTCを使うBitcoin Mainnetではなく、Bitcoin SignetとSui Testnetを組み合わせて統合や運用を試す段階でした。testnetで動いたことは重要な進捗ですが、本番資産を扱うmainnetの安全性を自動的に証明するものではありません。
5億ドル超はTVLではなく資本コミットメント
発表の「5億ドル超」は注目度の高い数字ですが、意味を広げてはいけません。調査資料で確認できるのは、20超の参加者からの資本コミットメントです。Hashiへすでに預けられたBTCの時価、オンチェーンTVL、融資の実行額、利用者の利益を示す数字ではありません。
5億ドル超が示す範囲と示さない範囲
コミットメントは、参加者がHashiのエコシステムへ資本を供給する意向や枠を示すものとして読めます。しかし、企業ごとの金額、投入時期、条件、資本がすべて同時にオンチェーンへ移るかは公表資料から確定できません。したがって「HashiのTVLは5億ドル」「5億ドル分のBTCが保管済み」と言い換えるのは不正確です。
| 表現 | 今回確認できるか | 理由 |
|---|---|---|
| 5億ドル超の資本コミットメント | 確認できる | Sui Foundationの発表内容 |
| 5億ドル超の預入済みBTC | 確認できない | 実預入額とは記載されていない |
| 5億ドル超のTVL | 確認できない | オンチェーン残高の集計ではない |
| 5億ドル超の融資実行額 | 確認できない | 貸付実績を示す数字ではない |
20超の参加者と機関向け導線
構想発表ではBitGo、Bullish、FalconX、Ledgerなどの参加が示され、その後Cumberland、Fluid、SwissBorgが加わりました。参加企業が多いことは、保管、流動性、取引、ウォレット、融資といった役割の広がりを示します。ただし、参加表明は各社の全顧客向けサービス開始や、一定額の預入保証を意味しません。
初期用途として想定されるBTC担保融資
Hashiの初期用途として示されているのがBTC担保のステーブルコイン融資です。利用者がBTCをhBTCとしてSui上へ持ち込み、対応する融資プロトコルで担保に使う構想です。これはBTCを売却せずにオンチェーン金融へ接続する選択肢になり得ますが、借入には清算、金利、オラクル、流動性、スマートコントラクトのリスクが伴います。
HashiがBTCとhBTCの入出庫を支えても、統合先の融資条件まで保証するわけではありません。担保率、清算基準、価格参照方法、金利の変動、利用可能なステーブルコインは、実際に使うプロトコルごとに確認します。DeFiの基本はDeFiの仕組みとリスクでも整理しています。
HashiとhBTCの基本構造
Hashiの全体フロー
- Bitcoin側：利用者が専用アドレスへBTCを預ける
- 共同管理：BTCはHashiのMPC委員会とGuardianの管理下に置かれる
- Sui側：確認と待機後、対応するhBTCが発行される
- 償還開始：利用者がSui上でhBTCを焼却し、BTCの出庫先を指定する
- Bitcoin側：共同署名された取引によりBTCが出庫される
この流れではBitcoin側、Sui側、両者をつなぐHashiの状態を別々に確認します。以降のMPCやGuardianは、2番と5番で裏付けBTCを単独支配させないための仕組みです。
Hashiは、新しいBitcoinチェーンを作る仕組みではありません。Bitcoin上のBTCを共同管理し、その状態に対応するhBTCをSui上で発行・償還する処理を調整するオーケストレーターです。二つのチェーンをまたぐため、Bitcoin側の確認とSui側の処理が連動します。
BTCを管理するオーケストレーターとしてのHashi
公式ドキュメントは、Sui validator由来の委員会が閾値暗号を用いてBitcoin鍵を共同管理すると説明しています。閾値暗号では、一つの完成した秘密鍵を一人が保持して動かすのではなく、複数の参加者が鍵のシェアを使って署名を成立させます。単独運営者だけでBTCを動かしにくくする設計です。
預入BTCに対応して発行されるhBTC
利用者が指定されたBitcoinアドレスへBTCを送り、必要な確認と待機処理が終わると、対応するhBTCがSui上で発行されます。公式FAQはhBTCがHashi管理下のBTCに1対1で裏付けられる設計を説明しています。ここでの「1対1」は発行と裏付けの設計を指し、市場価格が常に完全一致することや、出庫が常に即時完了することを保証する表現ではありません。
反対方向では、Sui上のhBTCを焼却し、Bitcoin側でBTCの送信を受けます。発行と焼却を対にすることで、同じ裏付けを残したままhBTCだけが増え続けることを防ぐ構造です。
自己管理から共同管理へ移る点に注意
最も重要な違いは鍵の管理です。自分のBitcoinウォレットでBTCを持つ場合、原則として自分の秘密鍵で支出を承認します。Hashiへ預けた後のBTCは、利用者自身の鍵だけでは動かせず、MPC委員会とGuardianを含む設計の管理下へ移ります。
hBTCを自分のSuiウォレットで保有していても、Bitcoin側の裏付け資産まで自己管理しているわけではありません。ウォレットの違いは暗号資産ウォレットの種類を参照し、「トークンを操作できる鍵」と「裏付け資産を動かす鍵」を分けて考えてください。
BTCの預入からhBTC発行・償還まで
まなぶ「BTCを送った瞬間に、同じ量のhBTCが届くんですか？」
クリプ「すぐとは限らないよ。Bitcoinの確認と不正検知の待機を経てから、Sui側で発行されるんだ。」
入出庫は単純なトークン送金ではなく、二つのネットワークとHashiの検証を通ります。送金前には必ずSui MainnetとBitcoin Mainnetの組み合わせを確認してください。testnetではSui TestnetとBitcoin Signetを使うため、テスト用アドレスへ実BTCを送ってはいけません。
BTCを預けてhBTCを受け取る3段階
- 入金先を導出する：利用者のSui上の受取先などに対応する専用のBitcoin預入アドレスを取得します。
- BTCを送る：対応ネットワーク、アドレス、最小額を確認し、Bitcoin取引を送信します。
- Sui上で発行を確定する：Bitcoinの確認後、Hashiが預入を承認し、待機期間を経てhBTCの発行処理が進みます。
暗号資産の送金は取り消しが難しいため、アドレスを手入力せず、先頭と末尾、ネットワーク、金額を照合します。一般的な確認手順は暗号資産を安全に送金する方法でも確認できます。
hBTCを焼却してBTCを引き出す流れ
出庫では、利用者がSui上で出庫先のBitcoinアドレスと数量を指定し、hBTCを焼却します。その後、必要なスクリーニングや待機を経て、MPC委員会とGuardianがBitcoin取引へ署名し、Bitcoinネットワークへ送信します。
hBTCの焼却後、BTCが届くまでには時間差があります。Guardianのレート制限、委員会の再構成、緊急停止、Bitcoinのブロック確認や混雑が影響し得ます。画面が保留中でも同じ要求を繰り返さず、取引ID、出庫先、数量、日時を保存して公式の状態を確認します。
最小額・確認数・待機時間・手数料
設計文書にある既定値では、入出庫の最小額は3万sat、Bitcoin確認は6ブロックです。預入の承認から発行までには既定10分の遅延があり、出庫には既定1時間の取消待機があります。これらは設定値であり、実運用で変更される可能性があるため、送金時の画面と最新文書を優先してください。
Hashiのプロトコル手数料はないと説明されていますが、費用が完全にゼロという意味ではありません。Sui上の操作にはガスが必要で、BTC出庫ではBitcoin採掘者手数料を負担します。統合先の融資や交換サービスが独自手数料を設定する可能性もあります。
| 項目 | 設計文書の既定値・説明 | 確認点 |
|---|---|---|
| 最小入出庫額 | 3万sat | 実行画面の最新値 |
| Bitcoin確認 | 6ブロック | 混雑時の所要時間は一定でない |
| 預入確定前の待機 | 10分 | 異常検知と停止のための時間 |
| 出庫取消待機 | 1時間 | 処理状況と取消可能範囲 |
| 費用 | プロトコル手数料なし | Suiガス、採掘者手数料、統合先費用は別 |
MPC委員会とGuardianが守るBTC
Hashiの安全設計は「一社が鍵を持つ」形ではなく、委員会による分散鍵管理とGuardianの共同署名を組み合わせます。ただし、関係者を増やせば自動的に安全になるわけではありません。攻撃耐性と、正常時に処理を続けられる可用性の両方を見る必要があります。
MPC委員会による分散鍵管理
MPCはMulti-Party Computationの略で、複数の参加者が秘密情報全体を一か所へ集めずに計算や署名を成立させる技術です。HashiではSui validator由来の委員会がBitcoin鍵のシェアを共同管理します。一参加者の侵害だけで直ちに全BTCを動かせないことが狙いです。
一方、委員会の十分な割合が応答できなければ署名が進まない可能性があります。安全性のために設けた閾値は、障害時には処理停止の要因にもなります。分散管理は「停止しない」保証ではなく、単独支配を避けつつ合意して動かす設計です。
Guardianを加えた2-of-2の通常経路
各預入先はTaprootアドレスで、通常の支出経路では委員会とGuardian双方の署名が必要です。委員会だけ、Guardianだけでは通常経路のBTCを動かせない2-of-2構造により、二つの役割が相互に確認する形になります。
Guardianは出庫の共同署名に加え、レート制限やスクリーニングにも関わります。異常な流出を抑える材料になる一方、Guardianの障害や接続問題は出庫遅延につながり得ます。また、Guardianの公開鍵とBitcoinチェーンIDは稼働開始時に固定され、ガバナンス提案で変更できないと設計文書にあります。
60日後に使える委員会単独の回復経路
Taprootの設計には、通常経路が長期間使えない場合に備え、60日後に委員会単独で利用できる回復経路があります。Guardianが恒久的に利用不能になったとき、BTCが永久に動かせなくなる問題を避けるための仕組みです。
ただし、回復可能性にはトレードオフがあります。通常時はGuardianとの共同署名で委員会単独の支出を防ぎますが、60日経過後は委員会側の統制がより重要になります。「Guardianがあるから委員会を信頼しなくてよい」「回復経路があるから停止リスクがない」のどちらも正しくありません。
緊急停止と委員会再構成の仕組み
まなぶ「クリプ先生、停止機能があるなら資産は必ず安全なんですか？」
クリプ「停止は被害拡大を抑える道具だけど、欠陥ゼロの保証ではないよ。止まる範囲と再開条件も一緒に見よう。」
Hashiは異常時に処理を止めるガバナンス機能と、Suiのepoch交代に合わせて鍵シェアを新しい委員会へ移す再構成を備えます。これらは長期運用に必要な安全装置ですが、利用者から見ると入出庫が一時的に進まない原因にもなります。
5%で停止し3分の2で再開するガバナンス
設計文書の既定値では、委員会投票力の5%で緊急停止を発動でき、再開には3分の2、すなわち66.67%の投票力が必要です。停止の敷居を低くして初動を速め、再開には広い合意を求める考え方です。これらも設定として扱われるため、稼働時の最新状態を確認する必要があります。
低い停止閾値は異常時の反応を早めますが、誤検知や一部参加者の判断でもサービスが止まりやすい側面があります。高い再開閾値は慎重な復旧に役立つ一方、参加者の障害や意見不一致で停止が長引く可能性があります。
epoch交代に伴う鍵シェアの再構成
Suiではvalidator集合がepochごとに変わり得ます。Hashiは新しい委員会へMPC鍵シェアを移す再構成を行います。新委員会の確定には委員会投票力の3分の2のBLS署名が必要です。再構成中は一部の入出庫処理が止まり、完了できない場合は次epochで中止して再形成できる設計です。
鍵の管理者を更新できることは長期運用に必要ですが、移行処理は複雑です。新旧委員会の参加、ネットワーク接続、鍵シェアの受け渡しがそろわなければ遅延します。利用者は「チェーンが動いているのに出庫だけ進まない」状況も想定し、短時間で必ず換金できる前提を置かないことが重要です。
利用者が見るべきなのは、運用者向けの個別指標そのものより、公式ステータス、対象取引の状態、SuiとBitcoin双方の取引IDです。停止後でも、すでに署名済みのBitcoin取引は送信され得るため、停止時刻だけで異常と決めず、署名・送信・確認の各段階を区別します。
\n\nHashiの利用前チェックと安全性の見方
\n利用判断では、同じ注意を何度も並べるのではなく、利用可否、償還性、管理・停止、統合先の四つに分けます。参加企業の名前やコミットメント額だけでは、個々の利用者がいつ入出庫できるか、どの損失まで補償されるかは決まりません。
\n| 判断軸 | 何を見るか | なぜ重要か |
|---|---|---|
| 利用可否 | 対応アプリ、Sui Mainnet／Bitcoin Mainnet、入出庫の停止表示 | 成果物公開だけでは自分が操作できるとは限らない |
| 償還性 | 発行残高、保管状態、出庫要求の状態、Bitcoin取引ID | 1対1の裏付けと、必要時にBTCを受け取れることは別 |
| 管理・停止 | MPC委員会、Guardian、停止・再開、変更履歴 | 不正支出を防ぐ仕組みが正常な出庫を待たせる場合もある |
| 統合先 | 担保率、清算価格、金利、流動性、コントラクト | hBTC発行後の融資や交換にはHashiとは別のリスクが加わる |
利用可否：公式導線で画面とネットワークを見る
\n既知のSuiまたはHashi公式サイトから利用アプリへ進み、検索広告やSNSの返信にあるリンクは入口にしません。接続前にURLを確認し、画面上でSui MainnetとBitcoin Mainnetの組み合わせ、入出庫が受付中か、提示された専用預入アドレス、最新の最小額・確認数・待機時間を見ます。testnetやSignetの表示があれば実BTCを送ってはいけません。
\n預入時は、専用アドレスの先頭と末尾、金額、Bitcoin側の取引IDを保存します。発行待ちではBitcoinの確認数とSui側のhBTC受取先を確認します。出庫時は、焼却を承認する前にBitcoinの受取先、数量、費用見積もりを照合し、実行後はSui側の要求IDとBitcoin側の取引IDを記録します。このように各段階で見る対象を決めれば、「オンチェーンを確認する」という抽象的な注意を具体的な操作に変えられます。
\n償還性：裏付けと実際に戻せる状態を分ける
\nhBTCの1対1裏付けは、発行残高に対応するBTCをHashiが管理するという設計です。それは市場価格の完全一致や即時償還の約束ではありません。確認対象は、hBTCの発行残高、Bitcoin側の保管状態、出庫要求を受け付けているか、共同署名と送信が進んでいるか、Bitcoin上で確認されたかという順序です。
\n市場でhBTCを別資産へ交換できることと、Hashiを通じてBTCへ戻せることも別です。出庫要求後に待ち時間が長い場合は、同じ要求を重ねず、取引ID、出庫先、数量、日時を保存します。そのうえで公式の停止表示、アプリの告知、Suiエクスプローラー、Bitcoinエクスプローラーの順に照合します。問い合わせる場合も、この記録が処理段階を特定する手掛かりになります。
\n\n管理・停止：不正支出耐性と可用性を分ける
\nMPC委員会とGuardianの通常経路は、一方だけによる支出を難しくする点で不正支出への耐性を高めます。一方、双方の協力が必要なため、どちらかが応答しなければ正当な出庫も進まない可能性があります。安全性は「勝手に動かされにくいか」、可用性は「必要なとき正しく動かせるか」と分けて評価します。
\nmainnet 1.0のハッシュ、Docker digest、ビルド証明は、取得した成果物の出所や一致を検証する材料です。しかし、正しい成果物に欠陥がないこと、鍵の保管やアクセス制御が常に適切なこと、統合先まで安全なことを保証しません。監査や検証の表示を見るときは、対象の版と範囲、未解決事項、アップグレード後の変更履歴、障害時の案内を確認します。
\n停止機能は異常時の被害拡大を抑える一方、預入や出庫を待たせることがあります。60日後の回復経路はGuardianが長期間使えない場合の固定化を避けますが、その時点では委員会側の健全性がより重要です。通常経路、停止中、回復経路では権限と条件が変わるため、「分散型だから安全」「回復経路があるからすぐ戻せる」と単純化しないことが重要です。
\n統合先：清算・金利・流動性を別に調べる
\nhBTCを融資や交換に使うと、Hashiの入出庫リスクに、統合先の清算、金利、オラクル、流動性、スマートコントラクトのリスクが重なります。Hashiが正常でも、担保価値の下落や価格参照のずれで清算されることがあります。逆にBitcoin側のBTCが保管されていても、統合先からhBTCを取り戻せなければHashiでの償還へ進めません。
\n実行前に、担保率と清算価格、借入金利が固定か変動か、返済に必要な資産、hBTCを引き出せる流動性、障害時の窓口を確認します。複数のプロトコルを経由する場合は、hBTCを受け取り、運用し、引き出し、焼却し、BTCへ戻るまでの経路を書き出します。どの段階が停止すると資金移動が止まるかを説明できない場合は、金額を増やさない判断が必要です。
\n利用目的別に優先する確認項目
\n- 短期の入出庫：受付状態、最小額、待機、費用、出庫先形式を優先する
- hBTCの長期保有：裏付けの確認方法、委員会とGuardianの運用、停止・更新履歴を継続して見る
- 融資や交換：統合先の担保率、清算、金利、オラクル、流動性を追加で見る
- 機関向けサービス：本人確認、保管責任、出庫審査、利用地域、連絡窓口、補償の有無を契約で見る
どの目的でも、初回は少額で表示、受取先、所要時間を確かめます。Suiガス用残高とBitcoin採掘者手数料を見込み、最低額ぎりぎりの送金を避けます。送金先やネットワークを誤ると回復できない可能性があるため、一般的な確認手順は暗号資産を安全に送金する方法も参照してください。
\nHASHIトークンの販売やエアドロップは偽物
\n公式設計文書は、Hashiが発行するのはhBTCであり、「HASHI」という販売、プレセール、エアドロップ、実用、ガバナンス用トークンは存在しないと警告しています。「mainnet記念」「早期参加者向け」と称して購入や接続を促す案内には応じないでください。hBTCを受け取る場合も、名前やロゴだけで判断せず、公式導線からトークン情報とコントラクトを照合します。
\n\nシードフレーズや秘密鍵は入力せず、内容を理解できない署名は承認しません。公式サイトに似たドメイン、SNSの認証風表示、参加企業のロゴは正規性の証明にならないため、ブックマークした公式入口から確認します。
\n\nまとめ：公開済み成果物と実稼働の状態を分けて確認する
\nHashiは、共同管理するBTCに対応してSui上でhBTCを発行し、焼却後にBTCを出庫する基盤です。mainnet 1.0の成果物は公開済みですが、自分が使うアプリの利用範囲、入出庫状態、実預入額は操作時に確認する必要があります。発表の5億ドル超はTVLではなく資本コミットメントです。
\n利用前は、公式導線でネットワークと停止表示を確かめ、預入アドレス、最小額、待機時間、費用を照合します。さらに、1対1の裏付けと償還性、不正支出への耐性と可用性、Hashiと統合先のリスクを分けて判断してください。
