대액 스왑 분할: 상한·리스크·가격 실측

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 출구 루트)

상한은 사이트가 아니라 코리도에 속한다

명백히 초과한 금액으로 세 코리도를 찔러 경계를 되읽었습니다. USDT-TRC20→XMR은 180,000을 통과시키고 181,000을 거절했으며, 그 거절의 maxAmount는 175,082.69597로 한 시간 전의 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, 앞의 두 개의 43%입니다. 즉 17.5만은 플랫폼 규칙이 아니라 세 코리도가 우연히 같은 구간에 떨어진 결과입니다. 이 숫자로 ZEC 대액을 계획하면 주문이 거절됩니다. (XMR→USDT 출구 루트)

금액 축에는 비용이 두 가지뿐이다

같은 시각 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 이상에서는 사실상 0입니다. 깊이 비용은 훨씬 평평한 별개의 곡선으로 20,000에서 175,000까지 0.078%밖에 줄지 않습니다. 175,000을 87,500 두 건으로 나눠 같은 분에 견적하면 0.044% 더 받습니다(291.29782484 대 291.17025440 XMR, 약 75달러). 대신 TRC20 입금 수수료 6.4285 TRX(2.13달러)가 한 건 더 붙습니다. 계산상으로는 분할이 이기지만, 0.044%는 두 번의 클릭 사이 가격 잡음 안에 들어갑니다.

배치마다 드는 세 가지: 입금 수수료, 창, 가격 고정

TRC20 전송은 64,285 에너지를 태우고 getEnergyFee=100 sun에서 6.4285 TRX, 0.331084달러 기준 2.13달러입니다. 받는 주소가 새것일 때——주문마다 새 입금 주소가 생성되고 첫 USDT 입금은 잔액 슬롯을 0에서 쓰기 때문에——130,285 에너지, 13.0285 TRX, 4.31달러가 됩니다. BTC 쪽은 자릿수가 다르게 쌉니다. 141 vB가 1 sat/vB에서 141 sat, 0.11달러입니다(06:03 멤풀 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였습니다. 즉 여섯 배치 가격을 미리 계산해 두고 하나씩 주문하면 첫 건 이후는 모두 만료된 가격이고, 각 주문은 서버에서 다시 견적한 뒤 고정합니다. '주문 30분'을 '30분 동안 생각해도 된다'로 읽으면 안 됩니다. 눈으로 본 숫자의 수명은 2분입니다.

배치 수를 정하는 것은 레이트 리밋

주문 API는 IP당 시간당 6건, 전체 시간당 120건이며 같은 페어·금액·주소 조합을 90초 안에 다시 보내면 상류를 건드리지 않고 거절합니다. 600,000 USDT를 180,000 네 건으로 나누면 한 시간 창에 들어갑니다. 같은 금액을 50,000 열두 건으로 나누면 생성만 2시간, 두 개의 창, 열두 번의 가격 고정이 필요합니다. 배치 수를 결정하는 것은 거의 평평한 환율 곡선이 아니라 이 제한입니다. (XMR→USDT 출구 루트)

분할해도 출처는 깨끗해지지 않는다

주문마다 입금 주소는 따로 나오지만 TRC20의 지불 주소와 BTC의 입력 집합은 공개됩니다. 상류의 주소 심사는 주문 단위로 돌기 때문에 플래그가 붙은 출처를 여섯 건으로 쪼개면 거절 여섯 번과 기록 여섯 건이 늘 뿐, 한 번의 거절이 사라지지 않습니다. 환불 주소도 늘어납니다. 환불은 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%였고, 이웃한 두 지점 사이에서 3분에 0.125% 움직인 구간도 있습니다. 반면 '87,500 두 건 대 175,000 한 건'의 분할 우위는 -0.028%~+0.064%로 흔들렸고 첫 쌍에서는 마이너스였습니다. 잡으려는 깊이 비용 0.078%와 비교하면 견적 한 번의 갱신이 더 큽니다. 몇 분에 걸친 분할은 가격 전략이 아니라 상한을 피하는 수단이며, 드리프트는 이겨야 할 우위가 아니라 예산에 넣어야 할 비용입니다.

분할이 옳을 때, 그저 쇼일 때

정당한 이유는 셋입니다. 금액이 코리도 상한을 넘을 때(오늘 USDT-TRC20은 180,000과 181,000 사이), 상류가 건별 리스크 한도를 두어 타임아웃이 아니라 명시적 above maximum으로 나타날 때, 또는 시간 가중 집행을 원해 배치마다 다른 가격을 잡는 것을 받아들일 때. 상한 아래, 5,000에서 180,000 사이에서 환율만 보고 나누는 것은 창 리스크와 주소 관리를 0.04%의 잡음과 맞바꾸는 일입니다. (XMR→USDT 출구 루트)

여섯 단계와 흔한 실수 네 가지

1) 목표 금액에 5,000을 더해 경계를 찔러 보고, 거절되면 오류의 숫자를 규칙이 아니라 출발점으로 삼아 내려갑니다. 2) 배치마다 5,000 이상으로 고정비 구간을 피합니다. 3) 한 시간 창 안에서 모든 배치를 만듭니다(최대 6건). 입금 주소를 기록합니다. 4) 환불 주소는 배치마다 따로 씁니다. 같은 지갑의 하위 주소면 충분하지만 재사용은 안 됩니다. 5) 생성 순서대로, 가장 오래된 주문부터 입금합니다. 6) 주문 id를 저장합니다. 지연 입금은 6시간 소급으로 회수됩니다.

흔한 실수는 네 가지입니다. 시간당 6건을 하루 6건으로 읽기. 모든 배치에 환불 주소 하나를 공유하기. 1,000 단위까지 쪼개 배치마다 약 1%를 내기. 분할이 심사를 피한다고 믿기——피하지 못하고 기록만 N배가 됩니다. 상한 안에 들어가는 금액이라면 한 건이 더 싸고 단순합니다. 상한이나 리스크 한도가 강제할 때만 나누고, 각 배치는 만든 순간의 가격으로 계산하십시오.