重要な考え方：異なるネットワーク上の「$1」が、なぜ同じ品質のお金ではないのか
nativeステーブルコインとブリッジ由来の「ラップ版」をすばやく見分け、3つの点を確認できるようになります：
それがどのトークンなのか、担保はどこにあるのか、そして
ステーブルコインはDeFiや取引所での決済を支えていますが、マルチチェーンの世界では、同じティッカーでも同じ信頼性が保証されるわけではありません。
画面上では
目的： nativeおよびbridgedステーブルコインの仕組みを整理し、ブリッジで典型的に起こる障害点を示し、 担保、数量制限／出金ステータス、出口ルート悪化の初期サイン（ディスカウント、遅延や待ち行列の増加）をどこで確認すべきかという実務上の目安を示します。
この記事で使う用語：以降で繰り返し出てくる2つの定義です。
Nativeステーブルコイン：そのネットワーク上で発行体自身が発行するトークンであり、発行と償還のルールも発行体が定めます。 エコシステム内では通常、プロトコルや取引所が基準にする「カノニカル」版です。
Bridgedステーブルコイン：ブリッジによって「ラップ版」として作成されたトークンです。担保は多くの場合、別のネットワーク上にあり （通常はロックされた元のコインの形）、償還できるかどうかはブリッジの稼働状況、制限、利用可能な流動性に依存します。
送金前に：1分でできる3つの確認
— コントラクトアドレス → エクスプローラーでトークンを開き、似たティッカーの別バージョンと混同しないようコントラクトを照合します。
— 由来 → そのネットワークで誰がトークンを発行したのか、発行体なのかブリッジなのかを確認します（発行体／ブリッジのドキュメントやエコシステム内の表示で確認）。
— 戻り道 → 「メイン」のネットワーク、または流動性のある取引所へ、停止・厳しい制限・ボトルネックなしに戻れる実際のルートがあるか確認します。
Native vs Bridged：実際の操作で何が変わるのか
違いは名前ではなく、出口の仕組みにあります。誰がトークンを発行しているのか、償還がどう設計されているのか （発行体でのredemption / ブリッジ経由のburn → release）、担保がどこにあるのか、 そして停止や制限なしに流動性のある市場（CEX／「カノニカル」ネットワーク）へ素早く移れるルートがあるのかです。
Nativeステーブルコイン — そのネットワーク上で発行体が発行するため、「流動性へのルート」は通常より単純です。 取引所での直接入出金が利用できることが多く、ウォレットやDeFiでの統合も多く、 主な依存先は発行体のルール、償還の可用性、そしてそのネットワーク自体の安定性です。
Bridgedステーブルコイン — ブリッジによって成り立つ、宛先ネットワーク上の別個のトークンです。 あなたが保有しているのはラップ版であり、それが$1に近いのは3つの条件が満たされている間だけです。担保が実際にロックされていること、 ブリッジが逆方向の変換を実行できること、そしてディスカウントなしに退出できるだけの流動性がDEXプール／板にあることです。
- ロック → カノニカル（native）トークンが元のネットワークで固定されます（ブリッジコントラクトまたはカストディアン）。
- 発行 → 宛先ネットワークで同額のブリッジ版がミントされます。
- 戻し → ブリッジ版がバーンされ、元のトークンがアンロックされます。ただし停止、制限、待ち行列がない場合に限ります。
| 項目 | Native | Bridged |
|---|---|---|
| 誰が発行するか | 発行体 （Circle、Tetherなど） |
ブリッジ／プロトコル （外部インフラ） |
| 担保の所在 | 発行体側 （準備金と償還ルール） |
元のネットワーク （コントラクト／カストディアン内の担保） |
| 主なリスク | 発行体の判断 （コンプライアンス、償還の可用性） |
ブリッジ障害 （コード、鍵、バリデーター、停止） |
| 最初に「壊れる」もの | 操作の可用性 特定アドレス向け |
変換と流動性 （ディスカウント、待ち行列、停止） |
| 実務上の結論 | 保管に向く また大口決済にも向く |
移動用途に向く また短期のDeFi用途にも向く |
ミニルール：保管や大口決済では、nativeが選ばれることが多いです。 特定の操作のために別ネットワークへ一度だけ「移動」する場合、bridgedも許容できます。ただし、戻り道と制限を理解している場合に限ります。
ブリッジのアーキテクチャ：ネットワーク間の「送金」でリスクはどこに潜むのか
代表的な4つのブリッジ方式を見て、「$1 = $1」がどの地点で崩れるのかを確認します。 mint/burnのルール、プール流動性の厚み、管理者権限（pause/upgrade）、そしてメッセージ確認の各ポイントです。
🔒 Lock/Mint — 別ネットワーク上の担保に対する「受領証」
最も一般的なモデルです。資産そのものが別ネットワークへ「移動」するのではなく、元の資産を担保にしたラップ版がそこで発生します。
- 何が起きるか：カノニカル（native）トークンがネットワークAでロックされる → ネットワークBで同額のラップ版がミントされる。
- あなたにとっての意味：ラップ版の価格は、担保が実際にロックされ、ブリッジが逆操作（burn → release）を正しく実行できる限り維持されます。
✅ 強い点
- 単純なロジック → 担保がロックされ、別ネットワークに同等のラップ版が存在します。
- 透明性 → 何がトークンを裏付けていて、どのコントラクトに担保があるのかが通常わかりやすいです。
- 普及度 → 多くのネットワークやトークンで最もサポートされている形式であることが多いです。
❌ 壊れる点
- Mint/Burnルール → 検証や発行ロジックのミスは、無担保発行のリスクになります。
- 管理者アクセス → pause/upgradeや管理ロールが、ブリッジを単一障害点にします。
- TVLの集中 → 大きな担保の「金庫」は、攻撃の優先標的になります。
確認：ラップ版で大きな金額を保有する前に、誰がmint/burnを管理しているのか、停止／アップグレード権限が何かを確認してください。
Lock/Mintでは、リスクは「金庫」と管理権限にあります。liquidity poolsでは、資産はすでに宛先ネットワークにあるため、リスクは流動性へ移ります。ストレス時に$1近辺で退出できるだけの厚みがあるかが問題になります。
💧 Liquidity pools — 「現地」にあるが、流動性で支払う
トークンはすでにローカルの流動性プールに入っているため、宛先ネットワークですぐに受け取れます。
- 何が起きるか：ネットワークBのプールからトークンを受け取る → プールの偏りは後で解消されます（クロスチェーンのプールリバランス／裁定）。
- あなたにとっての意味：主なリスクは出口価格です。不均衡があると、スリッページやディスカウントを支払うことになります。
✅ 強い点
- 速度 → ラップ版の発行を待たずに、資産を「現地」で受け取れます。
- 集中の低下 → 1つの巨大な保管コントラクトへの依存が小さくなります。
- シナリオが単純 → 手順が少なく、UXもわかりやすいことが多いです。
❌ 壊れる点
- スリッページ → プールが偏ると、退出コストが目に見えて高くなります。
- ディスカウント → ストレスシナリオでは、「ドル」が額面を下回って取引されることがあります。
- 裁定への依存 → 均衡回復には資本と活発な市場が必要です。
注目点：ブリッジ自体は「動いて」いても、プールが薄ければ、リスクは送金ではなく出口価格にあります。
プールは速度をもたらしますが、出口価格は変動します。Burn/Mintはこの弱点を取り除こうとする方式です。トークンを担保付きでコピーするのではなく、ネットワークAでバーンし、確認済みイベントに基づいてネットワークBで発行することで「移動」させます。
🔥 Burn/Mint — 「金庫」は減るが、同期への要求は高まる
トークンはコピーされません。一方のネットワークでバーンされ、確認済みイベントに基づいてもう一方で発行されます。
- 何が起きるか：ネットワークAでバーン → メッセージ検証後、ネットワークBで発行。
- あなたにとっての意味：担保を置く「金庫」は減りますが、発行権限と確認の信頼性が重要になります。
✅ 強い点
- 担保付きコピーなし → 移動はイベントに基づくburn - mintで構成されます。
- 標的の減少 → 担保ごと「抜かれる」巨大な保管庫がありません。
- 混乱の減少 → 同じ資産の2つの「バージョン」がエコシステムに長く残る可能性が低くなります。
❌ 壊れる点
- 発行権限 → 宛先ネットワークで誰がmintできるのかが中心的なリスクです。
- イベント検証 → 確認の不具合は発行／償還を壊します。
- 移動の停止 → 確認が停止すると、送金はネットワーク間で「詰まり」ます。
安全条件：このモデルが有効なのは、mint権限が透明で、確認が単独オペレーターや「手動」対応に依存しない場合だけです。
Burn/Mintは「トークンに何が起きるのか」に答えます。Message passingは「ネットワークBが、ネットワークAで実際にイベントが起きたとどう知るのか」に答えます。したがって次に重要なのはティッカーではなく確認の品質です。誰がメッセージを作成／署名し、それがどう検証されるのかです。
📨 Message passing — 「証明の配送」としてのブリッジ
ブリッジが運ぶのはトークンではなく、「ネットワークAでイベントが起きたので、ネットワークBで操作してよい」という確認です。
- 何が起きるか：イベントがネットワークAに記録される → ネットワークBでmint／アンロック（release）またはコントラクト関数の呼び出しが許可されます。
- あなたにとっての意味：安全性は、誰がメッセージを確認し、その確認をブリッジがどれだけ厳密に検証するかに依存します。
✅ 強い点
- 柔軟性 → トークンを「運ぶ」ことなく、イベントを確認してアクションを起動できます。
- オムニチェーンUX → ネットワーク間で一貫した体験（移動、呼び出し、同期）を作りやすくなります。
- ラップ版の減少 → 同じ資産の「バージョン」数を減らせる場合があります。
❌ 壊れる点
- 確認 → メッセージ検証が弱いと、偽造への道が開きます。
- 信頼の前提 → バリデーター、リレイヤー、オラクルがインフラリスクの層を追加します。
- 監査の複雑さ → コンポーネントが増えるほど、メッセージ検証でミスが起きる可能性が高まります。
評価の出発点：きれいなインターフェースではなく、「誰がどのようにメッセージを確認するのか」から始めてください。
bridgedステーブルコインのリスク：「安定」が壊れる4つの領域
bridgedステーブルのリスクを4つの領域に分けて、弱点を素早く見つけます。 発行体、ブリッジ、流動性、操作／トークンのバージョンです。ここで大きな金額を保有する前に何を確認すべきかを理解します。
Bridgedステーブルコインは、信頼の第2層を追加します。「ドル」に加えて、移動インフラも存在するからです。 以下は、障害が最も起きやすい4つの領域と、それぞれの具体的な確認項目です。
🧾 ステーブルコイン
- 本質 → 担保の質と、発行体でのredemption（償還）が実際に利用できるか。
- 何が問題になるか → 準備金への疑念や償還制限 → ディスカウントと「神経質な」流動性。
- シグナル → レポートの悪化／更新頻度の低下、PoR／証明書の疑わしい変更、銀行／カストディアンに関するニュース。
- 確認 → どの準備金が示されているか、償還はどう設計されているか、アドレス／法域による制限はあるか、
native （bridge back）またはCEXへの直接ルートがあるか。
🔑 ブリッジ
- 本質 → 「ラップ版」のmint/burnの安全性と、クロスチェーンイベント確認の信頼性。
- 何が問題になるか → ハッキングや確認の偽造 → 無担保発行、出金停止、担保喪失。
- シグナル → 頻繁な停止、突然のアップグレード、遅延の増加、multisig／ロール（誰がpause/upgrade/mintできるか）の透明性不足。
- 確認 → 誰がpause/upgradeを管理しているか、multisigとtimelock（変更遅延）があるか、監査、検証モデル、インシデント後の公開post-mortem／更新があるか。
🌊 流動性
- 本質 → 「理論上」ではなく、このネットワークであなたの金額を$1近辺で退出できるか。
- 何が問題になるか → 退出がスリッページになり、パニック時には$1ではなくディスカウントになります。
- シグナル → stableプールの偏り、深さの低下、スプレッド拡大、出来高減少。
- 確認 → あなたの金額に対するプール／板の深さと、
native ／カノニカル版があるネットワーク、または大手取引所（CEX）への代替ルートの有無。
🧭 操作とバージョン
- 本質 → 同じティッカー ≠ 同じトークンです。重要なのはネットワークとコントラクトアドレスです。
- 何が問題になるか → 「別バージョン」への入金、誤ったネットワークへの送信、他人のコントラクトへの送付。
- シグナル → ウォレット／DEX内のティッカー重複、プロトコルや取引所でのバージョン対応の違い。
- 確認 → エクスプローラー上のコントラクトアドレス、正確な名称／ラベル（Bridged/Wrapped）、そしてブリッジ経由で
native へ戻る道（bridge back）がどこで利用できるか。
担保と制限はどこで見るか：確認チェックリスト
6つのステップをたどれば、トークンのコントラクトがどれか、担保がどこにあるか、 誰が発行／停止を管理しているか、そしてストレスシナリオで出口価格がいくらかを把握できます。
-
バージョンとコントラクト →
ティッカーではなくアドレスを基準にしてください。エクスプローラーでトークンを開き、正確な名前とコントラクトを照合します。
Bridged/Wrappedの表記や
.e /.axl のサフィックスは、ブリッジ版であることを示す場合が多いです。 - 「ドル」がどこにあるか → 担保メカニズムの説明を探してください。担保はどのネットワークに保管されているのか、あなたのネットワークでどのコントラクトがトークンを発行しているのか、ブリッジ経由の戻し（burn → release）はどう設計されているのか。 この仕組みを一文で説明できないなら、ここで大きな金額を保有しないほうがよいでしょう。
- 「担保 ↔ 発行」の一致 → 元のネットワークでロックされたカノニカル（native）トークンの量（担保）と、宛先ネットワークで発行されたラップ版の量を比較します。不一致は赤信号です。 Dashboardは役立ちますが、基準となる数値は保管庫（vault）とミンター（minter）のアドレスをエクスプローラーで再確認するほうが安全です。
- 誰が「スイッチ」を握っているか → pause（停止）、upgrade（ロジック更新）、mint/burnロールがあるか確認してください。 次に重要なのは、これらの権限を誰が管理しているかです。multisig + timelock（変更遅延）なのか、単一の鍵／管理者なのか。 単一の鍵 = 突然の停止や「出口閉鎖」のリスクです。
- 制限（caps）と待ち行列 → capsとは、発行／出金に対する日次クォータまたは最大数量です。パニック時には制限がすぐ使い切られ、ハッキングがなくても 出金は待機に変わります。自分の金額に対するcapと、上限到達後に何が起きるのか（待ち行列／停止／オペレーターによる手動出金確認）を確認してください。
-
出口価格 →
DEXプール／板の深さを「全体」ではなく、あなたのサイズに合わせて評価してください。大きなスリッページなしで変換するのにいくらかかるか、
そして
native または取引所へ向かう代替ルート（bridge backを含む）が、ボトルネックなしにあるか確認します。
事例：pegを失った理由と、それがbridged／nativeにとって重要な理由
ここには2種類の失敗があります。ステーブルコインのモデルが壊れる場合と、移動と「出口」が壊れる場合です。 それぞれの事例で、原因、障害点、実務上の結論を見ていきます。
📍 ステーブルコインのモデルが裏切るとき
次は別のシナリオです：基礎となるステーブルは安定していても、ブリッジと逆変換の可用性にリスクが現れることがあります。
🧷 ブリッジが壊れる、または「出口」が閉じるとき
総括：nativeステーブルの弱点は、モデルと準備金にあることが多いです（特に大量償還時）。bridgedでは、移動インフラと出口の可用性にあります。金額が大きいほど、変換ルート、制限、ボトルネックを事前に把握しておくことが重要です。
USDCとUSDC.e：出口ルールが異なる2つの「ドル」
USDCとUSDC.eの違いはティッカーではなく「出口」にあります。誰がトークンを発行しているのか、担保はどこにあるのか、そしてブリッジが一時停止されたら何が起きるのか、という点です。
一部のネットワークでは、まずブリッジ版のUSDC.eが登場しました。カノニカルな（native）USDCは元のネットワークでロックされ、 目的のネットワークでは同額のラップ版が発行されます。その後、native USDC（そのネットワークで発行体が直接発行するもの）が登場すると、 よく似た2つのバージョンが並存し始めます。そして両者は、流動性、サービスでの対応、ブリッジ経由の返却（bridge back）やCEXへの出金速度に関するリスクが異なります。
| 比較する項目 | Native USDC | USDC.e (bridged) |
|---|---|---|
| 誰が発行するか | このネットワーク上の発行体 | ブリッジ（ラップ版） |
| 「出口」は何に依存するか | 発行体のルールと償還の可用性 | 元ネットワークの担保 + ブリッジの稼働状況（mint/burn、確認） |
| サービスでの対応 | そのネットワークの「主要」標準になりやすい | 場所によっては受け入れられないことがある |
| ストレスシナリオ | 通常、出口価格がより安定しやすい | pause/caps/待ち行列の際にディスカウントされやすい |
平穏な市場では、その差はほとんど目立ちません。しかしブリッジが一時停止されたり、上限（caps）に達したり、出金待ちの列が伸びたりすると、 ラップ版はディスカウントされることがあります。たとえUSDCそのものに問題がなくてもです。 そのため確認すべきなのは「ティッカー」ではなく、redemption（償還）の仕組みと、実際に戻れる経路です。つまり、カノニカルなネットワークへのbridge back、またはCEXへの出金です。
問題の早期シグナル：depegが起きる前に何を見るべきか
「パニック前」の観察ポイントです。どこを見ればよいのか、どの兆候が出口の高コスト化、制限、または一時的な利用不能を示すのかを確認します。
✅ 反応すべきシグナル
-
ブリッジが遅い、またはmaintenanceに入る：
遅延が増え、ステータスに期限が示されず、待ち行列が発生します。
何をするか： bridged版で保有する金額を減らし、通常運用に戻るまでは大きな金額を入れないようにします。
-
ステーブルペアのTVLが落ちる：
TVL（ロックされた価値）が、このステーブル版の主要プールから流出します。深さが低下し、出口が高くなります。
何をするか： 自分の金額でのスリッページと、代替ルートの有無を確認します。
-
ステーブルプールが偏る：
バランスが一方向に傾きます。市場が特定のステーブル版から「乗り換えている」状態です。
何をするか： 返却ルートを事前に準備します。出口価格がまだ許容できるうちに、カノニカルなネットワークへのbridge back、またはCEXへの出金を想定します。
-
ブリッジの権限やパラメータが変わる：
multisig署名者の変更、アップグレード、pauseの有効化、上限の変更、または運用アドレスからの操作の急増です。
何をするか： 大口送金を止め、ステータスと変更理由が明確になるまでリスクを減らします。
-
ディスカウントが何時間も続く：
価格が$1を下回る状態が長く続くなら、それは一時的なノイズではなく、出口リスクの評価です。
何をするか： 分割して退出し、薄い流動性に大きな数量をぶつけないようにします。
何を選ぶべきか：Nativeが適する場面、Bridgedが妥当な場面
ここでの選択は、出口のコントロール（bridge back、CEX、出口価格）に関わります。保管では信頼できる変換ルートがより重要であり、 マルチチェーンの用途では互換性と速度が重要です。ただし、一時停止（pause）、上限（caps）、そして自分の金額に対する出口価格を考慮する必要があります。
🟩 Nativeステーブルコイン
ネットワーク上で発行体が直接発行している場合、保管や決済に適しています。 ルール： 金額が大きいなら、nativeから始めます。
- シナリオ： 保管、決済、担保/マージン、取引所への出金、または法定通貨チャネルへの移動。
- 確認： 準備金とレポート、redemption（発行体での償還）、このネットワークのCEX/ウォレット/主要DeFiプロトコルでの対応。
✅ メリット
- 障害点が少ない → 出口に必須のレイヤーとして別個のブリッジを必要としません。
- ネットワーク標準 → プロトコル、ウォレット、取引所で「デフォルト」として受け入れられやすい。
- 流動性を予測しやすい → ブリッジの問題による一時停止/待ち行列に巻き込まれる可能性が低くなります。
❌ デメリット
- コンプライアンス上の制限 → 中央集権型の発行体では、特定アドレスの凍結が起こり得ます。
- 発行体のポリシー → 取り扱いルールは「上から」決まり、変更される可能性があります。
- ネットワーク対応範囲 → nativeはどこにでもあるわけではなく、bridged版より遅れて登場することもあります。
実務上： ネットワークでnativeが利用できるなら、大口資金や決済ではそれが基本オプションになりやすいです。
🟦 Bridgedステーブルコイン
「移す → 使う → 出る」というシナリオ、つまりクロスチェーンが必要な場合や、そのネットワークにnativeがない場合に適しています。 ルール： その操作に必要な分だけを持ちます。
- シナリオ： ネットワーク間の通過、短期のDeFi操作、公式発行がないエコシステム。
- 確認： 誰がpause/upgradeを管理しているか、どのcaps（上限）が適用されるか、流動性があるか、自分の金額で出口にいくらかかるか。
✅ メリット
- 新しいネットワークへのアクセス → nativeがまだ開始されていない場所でも利用できます。
- 素早い移動 → エコシステムやアプリ間で資本を移動しやすくします。
- 用途に合わせやすい →
native /カノニカルなネットワークへの返却ルート（bridge back）またはCEXへの出金が分かっている場合に便利です。
❌ デメリット
- 障害点 → ブリッジのミスやハッキングは、担保とラップ版への信頼に直接影響します。
- 出口の制限 → pause/caps/待ち行列によって、退出が時間的にブロックされることがあります。
- 市場ディスカウント → ストレスシナリオでは、返却（bridge back）の不確実性により、ラップ版は$1から外れやすくなります。
実務上： bridgedは操作のための強力なツールですが、長期保管の候補としては弱いものです。
❓ FAQ: Native vs Bridged — 保管や送金の前に確認する短い答え
実行前の短い確認です。bridged版をどう見分けるか、なぜディスカウントが出るのか、caps（上限）を見る理由、そしてpause（一時停止）/upgrade（アップグレード）の何がリスクなのかを整理します。
ネットワーク上のステーブルコインがブリッジ版で、ネイティブではないとどう判断するか？
インターフェース上のティッカーだけを頼るのは危険です。重要なのはネットワークとコントラクトアドレスです。
ブリッジ版の兆候は、Bridged/Wrappedという表示、
実務上の基準はシンプルです。「担保はどこにあるか」と「返却（bridge back）はどう行われるか」に短く答えられないなら、出口リスクは高くなります。 たとえ現在のレートが$1に近くても同じです。
カノニカルな（native）版が安定しているのに、bridgedステーブルコインが$1未満で取引されることがあるのはなぜか？
ディスカウントは通常、「ドルの品質」ではなく、出口のリスクとコストを反映します。
ディスカウントの典型的な理由は、有効化されたpause（一時停止）、使い切られたcaps（上限）、出金待ちの列、DEXプール/板の深さの低下、 そしてスリッページ（slippage — スリッページによる損失）の増加です。
ブリッジの上限（caps）とは何か、なぜ重要なのか？
Caps（上限）とは、一定期間の発行/出金、または資産/ルートごとの総量に対する制限です。 目的はインシデント時の被害を抑えることですが、ストレスシナリオではcapsがしばしば「ボトルネック」になります。 上限が埋まり、出金が時間的に後ろへずれる（待ち行列）か、枠が更新されるまで利用できなくなります。
そのためcapsの評価は、金額との関係でこそ重要です。小さな送金には十分な上限でも、 「今ここで」大口退出するには致命的に足りない場合があります。
ブリッジのpauseとupgrade機能は何が危険なのか？
Pause（一時停止）は入金/出金を止め、upgrade（アップグレード）は、多くの場合proxy（更新可能なコントラクト）を通じて、 コントラクトアドレスを変えずにブリッジのロジックを変更できるようにします。 これは脆弱性を素早く塞ぐ助けになりますが、ガバナンス上のリスクも加わります。multisigとtimelock（変更前の遅延）が重要です。
システムを止めたり、発行/検証ルールを「手動で」変更したりすることが簡単であるほど、 ストレス時の主なリスクが価格ではなく、出口の可用性になる可能性が高くなります。
どちらがよいか：ブリッジの「ラップ版」か、burn-and-mintによる移転か？
Burn-and-mint（燃やす → 発行する）は、イベントを通じて資産を移転します。トークンは一方のネットワークでバーンされ、メッセージ確認後に別のネットワークで発行されます。 この方式は、lock/mintモデルで攻撃対象になる、担保入りの「大きな金庫」への依存を減らします。
ただしリスクが消えるわけではありません。リスクは確認の品質（誰がメッセージに署名/検証するか）と発行権限（誰がmintできるか）へ移り、 さらにpause/upgradeという管理機能にも残ります。実務上の基準は同じです。管理がどれだけ透明で、返却ルートがどれだけ現実的かです。
最終結論：ティッカーではなく出口経路で選ぶ
ティッカーはリスクそのものではありません。 重要なのはトークンの由来、インフラの管理、そしてストレスシナリオでの出口価格です。
NativeとBridgedのステーブルコインはインターフェース上では同じに見えることがありますが、構造は異なります。 Nativeは、そのネットワークで発行体が発行します。流通と償還のルールも発行体が定めます。 Bridgedはラップ版です。元ネットワークで担保が実際にロックされている（そしてそれが確認できる）こと、 ブリッジがmint/burn（発行/バーン）を正しく実行していること、そして返却ルートが利用できることによって価格が支えられます。
目立つ金額をbridged版で持つ前に、3つの質問に答えてください。 一時停止 — 入金/出金が止まったら何が起きるか。 ルート — カノニカルなネットワークへ具体的にどうbridge backするのか、またはCEXへどう出金するのか。 コスト — caps（上限）、待ち行列、または自分の金額に対するスリッページによって出口が食われないか。 ルートと上限を説明できないなら、エクスポージャーを下げるべきです。
基本ルール：