マルチプール経路は停機に強いのか：2642回の実測
2642回の見積もりを集計しました。89.6%は経路が一つだけで、二つ目の経路は廊下ごとの最低額を超えて初めて現れます。実際に注文を救うのは注文作成段階のフェイルオーバーです。数字はすべて実測です。
「アグリゲート」は確認できる数字であって、スローガンではありません。 2026-10-25 08:57 から 11-01 の終わりまで、見積エンジンは2642回の価格提示を記録しました。うち2366回（89.6%）は経路が一つ、275回（10.4%）が二つ、三つは1回だけです。同じエンジン、同じ週で答えは大きく違います。これが全体の結論です。冗長性は「サイトの属性」ではなく「廊下と金額の属性」です。だから本稿はアグリゲーターの是非ではなく、二本目の経路が実際に何を買うのか、いつ現れ、どこで役に立たなくなるかを測ります。
交換が失敗する場所は四つあり、経路が触れるのは最初の二つです。 見積もりで失敗する（誰もそのペアに値段を付けない）、注文作成で失敗する（プールがペア・アドレス形式・金額範囲を拒否する）、決済で失敗する（入金は確認されたが出金が止まる）、あるいは単に遅い（全部正常で四時間後）。経路は見積もり段階と作成段階の仕組みです。100 USDT が入金アドレスに着いてプールが静かになった後、二つ目のプールが遡って助けることはできません。資金はすでに一つの相手方に預けられています。だからマルチプールの画面を正直に読むなら「始められない確率を下げるのであって、終えられない確率を下げるのではない」となります。 (XMR→USDT 出口ルート)
エンジンの動作は五つの定数で説明できます。 三つのプールのアダプタを並列に走らせ、それぞれに8,000msのタイムアウトを掛け、片方の失敗が全体を殺さないよう全決着方式で集め、生き残った見積もりをユーザー受取額の降順に並べ、同一の見積もりは8秒間再利用し、1IPあたり10分で60回までとします。クライアントに返るのは二つだけ。参加した経路数と、勝者が次点に何bps勝ったかです。2026-11-02 06:04 UTC に12の廊下で測ると、完全な見積もりは端到端で456〜1,291msでした。タイムアウトは冗長性の隠れた代価です。一つのプールがソケットで固まれば最大8秒をユーザーの画面から奪います。だからこの定数はコードに埋めず議論する価値があります。
二つの数字は正しく読む必要があります。 routes はその回に何件の提示があったかで、0は返らず1が非常に多く出ます。advantageBps は二番手との差であり、市場価格との差ではありません。したがって0は「悪いレート」ではなく「比較が起きなかった」、900は「市場より9%安い」ではなく「この廊下・この金額で他プールより9%良い」です。市場比較として読むのが最も多い誤解で、両方向に効きます。単一路線の見積もりが0表示でも十分競争的なことがあり、二路線の見積もりが900表示でも他所より悪いことがあります。
2642回の中身。 二つの提示があった275回に絞ると、優位の中央値143bps、10パーセンタイル33bps、90パーセンタイル893bps。バケットでは50bps未満59回、50〜200が102回、200〜1000が88回、1000以上が26回。驚いたのは勝者分布です。この275回のうち二つ目のプールが勝ったのは273回、99.3%でした。つまり実運用の「アグリゲーション」は通常「一人の値付け役＋時々1%以上で勝つ控え」であり、機械の価値は中央値ではなく裾に集中しています。典型的な見積もりだけ見れば差はないと結論します。差は誰もスクリーンショットしない26回にあります。
二番手には床があり、床は廊下ごとです。 2026-11-02 06:05 UTC の USDT-TRC20→XMR は階段状でした。40 USDT は経路一つで 0.04760146 XMR（XMRあたり840ドル相当）、60 は一つで 0.08004357（750）、100 は一つで 0.14492777（690）。130 で二社目が入り二経路、優位927bps、0.211546 XMR（614.52）。200で606bps（613.97）、500で270bps（613.20）、2,000で101bps（613.04）、10,000で63bps（612.96）。数字ではなく形を読むべきです。しきい値を越えると一度だけ約9%を得て、その後は注文あたりの固定費が償却されるにつれ優位は減衰します。その固定費は少額交換を高くするのと同じ仕組みで、競争の両側に課されます。 (XMR→USDT 出口ルート)
カバレッジは十のコードであり、カタログ全体ではありません。 サイトは62ネットワーク・430資産・349コードを並べていますが、06:04 UTC に稼働していた二つのプールが価格を共有するのは十コードだけです。BTC、ETH、BNB、LTC、DOGE、BCH、XMR、ZEC、そしてステーブルコインの USDT と USDC。残りは「まだ扱っているプール」の単独価格です。その十の中にも穴があります。一方のプールは ZEC の入金を受け付けないため、5 ZEC→XMR は経路一つ（10.26414479 XMR）。SOL はそのプールにマッピングがなく、3 SOL→XMR も一つ（0.4529562）。DOGE→XMR の200ドルは一つでしたが、DOGE→BTC の500ドルは二つで125bpsでした。厚みのある廊下と比較すると、0.05 BTC→XMR は二経路43bps（6.381238 XMR）、1 XMR→USDT-TRC20 は二経路216bps（600.933 USDT）、10 LTC は158bps、2 BCH は211bpsです。 (BCH to XMR guide)
注文を実際に救う層は見積もりの下にあります。 注文作成時、サーバーはブラウザが見た価格を無視して比較をやり直し、クライアントはプールを指定できません。そして受取額の高い順に並んだリストを上から試し、あるプールが作成を拒否したら——アドレスの方言違い、そのプールの範囲外の金額、上流障害——黙って次を試し、全部尽きて初めて失敗します。全滅時に出るのは「上流が利用不可」ではなくパラメータ系のエラー（不正なアドレス、下限未満）です。ユーザーが行動できる唯一のメッセージだからです。最後の層はサーキットブレーカーで、環境変数一つでデプロイもコード変更もなしにプールを競争から外せます。執筆時点で三つのうち一つが意図的に停止しており、それが複数の廊下で routes=1 になる理由です。運用プローブでは残る二つが252msと520msで応答しています。
実際の注文に耐える五つの確認。 一つ、金額を決める前に routes を見る。1なら入札で負けているのではなく、二社目の手が届かないだけです。二つ、金額を階段状に試す。二番手には床があり（本日 TRC20 で130 USDT、BTC で0.0016、XMR で0.05）、越えれば一度だけ約9%の価値があります。三つ、アグリゲーションを稼働保証と混同しない。決済は依然一本道なので、refundAddress は自分が持つウォレットにし、入金トランザクションのハッシュはブロードキャストした瞬間に控えます。四つ、本番金額の前に床付近（この廊下なら約27 USDT）で試す。五つ、advantageBps はプール対プールであり市場対ではないと覚えておく。ここにある数字はすべて 2026-11-02 06:04 UTC のスナップショットです。見積もりは秒で動き、権威ある数字はライブページだけです。 (XMR→USDT 出口ルート)