大口スワップは分割すべきか：上限・リスク・価格の実測

2026年10月29日06:01 UTC、200,000 USDT-TRC20をXMRに替える見積を取ったところ、APIは「amount above maximum、maxAmount 175,277.530607」と返しました。2分後、同じ通貨ペア・同じ画面で180,000は299.54872164 XMRの価格を出します。エラー内の上限は、サイトが実際に提示できる額より4,722 USDT低い。これは不具合というより、複数プール同時見積の副作用です。エラー本文のmin/maxは最初に失敗したルートのもので、サイト全体の上限ではありません。 (XMR→USDT 出口ルート)

上限はサイトではなくコリドーに属する

明らかに過大な額で3つのコリドーを叩き、境界を読み戻しました。USDT-TRC20→XMRは180,000を通し181,000を拒否、その拒否のmaxAmountは175,082.69597で、1時間前の175,277.531547より195 USDT低い。数字はプールのリアルタイム枠であって定数ではないからです。XMR→USDTは296.307762260273 XMR（下限0.03008666）で590.75ドル換算175,044。BTC→XMRは2.18507345 BTC（下限0.00017917）で80,152ドル換算175,138。ZEC→XMRは60.79096903 ZEC（下限0.02167768）で1,251.05ドル換算76,053、前2つの43%です。つまり「17.5万」はプラットフォームの規則ではなく、3本がたまたま同じ帯に落ちただけ。この数字でZECの大口を計画すると拒否されます。 (XMR→USDT 出口ルート)

金額軸のコストは2種類しかない

同時刻のUSDT-TRC20→XMR、9段の見積：100→0.14873867 XMR、1,000→1.64868、5,000→8.31170063、20,000→33.29237287、50,000→83.22767913、100,000→166.41787711、150,000→249.53778562、175,000→291.08189961、180,000→299.54872164。20,000段の実効レート0.0016646186を基準にすると、残存率は89.35%、99.04%、99.86%、100.00%、100.00%、99.97%、99.94%、99.92%、99.97%です。 (XMR→USDT 出口ルート)

読み方は単純です。100ドルの注文は固定費を約10.65ドル（券面の10.65%）失い、1,000ドルで0.96%、5,000ドルで0.14%、20,000以上ではほぼゼロ。深さのコストは別のもっと平坦な曲線で、20,000から175,000までで0.078%しかありません。175,000を87,500二本に分けて同じ分に詢价すると0.044%多く取れます（291.29782484対291.17025440 XMR、約75ドル）。ただしTRC20の入金手数料6.4285 TRX（2.13ドル）が1本増えます。計算上は分割が勝ち、実際には0.044%は2回のクリック間の価格ノイズの中に埋もれます。

1バッチあたりの3つのコスト：入金手数料・窓・価格固定

TRC20送金は64,285エネルギーを焼き、getEnergyFee=100 sunで6.4285 TRX、0.331084ドル換算で2.13ドル。宛先が新規の場合——注文ごとに新しい入金アドレスが生成され、最初のUSDT入金は残高スロットをゼロから書くため——130,285エネルギー、13.0285 TRX、4.31ドルになります。BTC側は桁が違って安く、141 vBが1 sat/vBで141 sat、0.11ドル（06:03のmempoolは52,347件・21.07 MvB、推奨4段すべて1 sat/vB）。窓はEXPIRE_MSが作成から30分、遅延入金は6時間の遡り、24時間で強制失効。価格は注文作成時に固定されるので、バッチごとに違う数字を掴みます。 (XMR→USDT 出口ルート)

見積は120秒、注文の窓は30分

06:14:56の見積はvalidUntil 2026-10-29T06:16:56.831Z、ちょうど120.0秒後。06:17:30の応答は06:19:30.522でした。つまり6バッチ分の価格を先に計算してから順に注文すると、1本目以降はすべて期限切れで、各注文はサーバ側で再見積してから固定します。「注文は30分」を「30分考えていい」と読んではいけません。目にした数字の寿命は2分です。

バッチ数を決めるのはレート制限

注文APIはIPあたり6件/時、全体120件/時。同一の通貨ペア・金額・アドレスの90秒以内の再送は上流に触れず拒否します。600,000 USDTを180,000×4本なら1時間の窓に収まる。同じ額を50,000×12本にすると、作成だけで2時間、2つの窓、12回の価格固定。バッチ数を決めるのは、ほぼ平坦なレート曲線ではなくこの制限です。 (XMR→USDT 出口ルート)

分割しても出所はきれいにならない

注文ごとに入金アドレスは分かれますが、TRC20の支払アドレスもBTCの入力集合も公開されます。上流のアドレス審査は注文単位なので、フラグの立った出所を6本に分けても、拒否6回と記録6件が増えるだけで、1回の拒否が消えるわけではありません。返金アドレスも増えます。返金はrefundAddressへ、元の資産・元のネットワークにしか戻らないので、N本はN回の入力ミスの機会です。しかも6件/時はIP単位なので、バッチは同じネットワーク指紋を共有します。

24分間のドリフト実測：ノイズが深さに勝つ

06:14:56〜06:36:19 UTCに3分間隔で175,000と87,500の見積を取り、8点を記録しました。175,000の実効レートは0.0016657209〜0.0016694333、幅は0.223%。隣接する2点の間だけで3分に0.125%動いた区間もあります。一方「87,500二本 対 175,000一本」の分割優位は-0.028%〜+0.064%で振れ、最初のペアでは負でした。取ろうとしている深さコスト0.078%と比べれば、見積1回の更新のほうが大きい。数分にまたがる分割は価格戦略ではなく上限を避ける手段で、ドリフトは勝ち取る優位ではなく予算に入れるコストです。

分割が正しい場合、ただの演出である場合

正当な理由は3つ。金額がコリドー上限を超える（本日のUSDT-TRC20は180,000と181,000の間）。上流が1件あたりのリスク上限を設けており、タイムアウトではなく明示的なabove maximumとして現れる。あるいは時間加重で執行したいので、各バッチが別の価格を掴むことを受け入れる。上限以下、5,000から180,000の範囲でレートのためだけに分けるのは、窓リスクとアドレス管理を0.04%のノイズと交換しているだけです。 (XMR→USDT 出口ルート)

6ステップと4つのよくある誤り

1）目標額+5,000で境界を探り、拒否されたらエラーの数字を出発点にして下へ試す（規則として信じない）。2）各バッチは5,000以上にして固定費帯を避ける。3）1時間の窓の中で全バッチを作成し（最大6件）、入金アドレスを記録する。4）返金アドレスはバッチごとに別にする——同一ウォレットのサブアドレスで足りるが、再利用はしない。5）作成順に、古い注文から入金する。6）注文IDを保存する。遅延入金は6時間の遡りで拾えます。

よくある誤りは4つ。6件/時を6件/日と読む。全バッチで返金アドレスを共有する。1,000単位まで刻んで各バッチで約1%を払う。分割で審査を回避できると思う——回避はできず、記録がN倍になるだけです。上限内に収まる額なら1本のほうが安くて簡単です。上限やリスク制限に迫られたときだけ分け、各バッチは作成した瞬間の価格で計算してください。