Route는 Robinhood Chain에서 스왑을 어떻게 빠르고 안정적으로 유지하는가

스왑 라우터가 하는 약속은 하나입니다. 제시한 견적보다 적게 받는 일은 절대 없다는 것입니다.

Route는 Robinhood Chain의 스왑을 구동하며, 거래의 양쪽 끝에서 그 약속을 지킵니다. 거래마다 해당 토큰이 거래되는 온체인의 모든 곳을 확인하고, 합쳐서 최적의 가격이 나오는 풀들로 주문을 나눈 뒤, 자체 executor(온체인에서 스왑을 수행하는 컨트랙트)를 통해 전체를 하나의 트랜잭션으로 정산합니다. 서명하기 전에 Route는 전체 계획을 시뮬레이션하므로 화면에 보이는 숫자는 실제 숫자입니다. 서명한 후에는 트랜잭션이 실제로 포함되는 블록을 기준으로 계획을 다시 세우므로, 시장이 유리하게 움직였다면 그 기회를 놓치지 않고 체결 가격이 개선됩니다.

두 단계 모두 그 아래에 같은 것이 필요합니다. 최신이고, 정확하며, 요청할 때 바로 응답하는 체인 상태입니다.

바로 여기서 Alchemy가 등장합니다. Route의 자체 노드는 라이브 견적 안의 작은 조회처럼 가장 빠른 읽기를 담당합니다. 나머지는 Alchemy가 맡습니다. 백업 읽기, 시뮬레이션 검증, 과거 데이터 스캔으로 Route의 데이터를 최신 상태로, 언제든 접근 가능하게 유지합니다.

Route 한눈에 보기

• Robinhood Chain, Base, BSC, Arbitrum, Optimism, Ethereum에서 동작하는 스왑 라우터
• Robinhood Chain에서만 240만 개 이상의 유동성 풀을 인덱싱
• 스왑 도중 커스텀 코드를 실행하는 풀을 포함한 Uniswap 풀과 런치패드 본딩 커브, 오라클 가격 기반 AMM, 토큰화 주식을 거쳐 라우팅
• route.fun의 트레이더와 파트너 지갑, 트레이딩 앱, vault, 마켓 메이커, 런치패드가 사용

사용 제품: Alchemy Node RPC

과제: 라우터는 제시간에 읽을 수 있는 풀만 사용할 수 있다

견적이 느리면 트레이더는 오래된 숫자를 보고 있는 셈입니다. route.fun에서는 입력할 때마다 견적이 갱신되고, 파트너 앱 안에서는 그 파트너의 타임아웃 안에 응답해야 합니다. 견적이 틀리면 스왑이 리버트되고, 트레이더는 가스비를 잃은 채 처음부터 다시 시작합니다. 아예 실패하면 유동성이 충분한 페어에서도 "no route"가 표시되고, 파트너 입장에서는 자기 제품이 고장 난 것처럼 보입니다.

세 가지 모두 같은 곳에서 비롯됩니다. 240만 개 이상의 풀에서 거래 가격을 계산하는 일은 수학 문제이기 전에 읽기 문제입니다. 각 견적은 후보 풀의 가격을 계산한 다음, 거래가 실제로 지불할 가스 가격으로 전체 계획을 Route의 executor에 통과시킨 뒤에야 요청한 앱에 답을 돌려줍니다. 그 아래에서 Route는 이벤트 로그로 새 풀을 찾고, 이미 알고 있는 풀을 다시 확인하며, 수수료 정산과 분석을 위해 과거 데이터를 스캔합니다.

이는 RPC 제공업체에 세 가지 요구 사항을 부과합니다.

• 견적을 만드는 동안의 빠른 읽기. 상태가 제시간에 돌아오지 않은 풀은 경로에서 빠지고, 가격이 나빠집니다.
• 정확히 맞는 상태. 특정 블록을 기준으로 실행한 시뮬레이션은 체인이 실제로 수행할 동작과 일치해야 합니다. 일치하지 않으면 스왑이 실패하거나, 트레이더가 동의한 최소 수량보다 적게 체결될 수 있습니다.
• 과거 데이터의 양. 풀을 찾고 수수료를 대사하려면 수만 개 블록에 걸쳐 로그를 스캔해야 합니다.

Route는 그동안 읽기를 여러 제공업체에 나누고, 그 차이를 재시도와 중복 요청으로 흡수해 왔습니다. 어느 정도까지는 통했습니다. 그래도 제공업체마다 저마다의 방식으로 장애가 났고, 우회책을 더할 때마다 견적에 걸리는 시간이 다시 늘어났습니다.

그러다 Route의 주 제공업체가 다운됐습니다. route.fun의 견적은 몇 시간 동안 간헐적으로 실패했고, 유동성은 그대로 있는데 트레이더에게는 "no route"가 표시됐습니다. Route는 그날 바로 공개 엔드포인트를 해당 제공업체에서 옮겼습니다.

솔루션: 모든 것 뒤에 하나의 제공업체

Route는 이미 내부 작업, 과거 데이터 스캔, 시뮬레이션에 Alchemy를 쓰고 있었기 때문에, 공개 엔드포인트를 옮길 곳이 필요해지자 Alchemy가 같은 날 이를 맡았고, 견적을 하나도 바꾸지 않고 실패한 읽기를 복구했습니다. 같은 입력, 같은 블록, 같은 검증입니다. 이제 하나의 엔드포인트가 라우터, API, 웹사이트, 개발자 포털, 수익 서비스 뒤에 있습니다.

Route 제품의 세 부분이 이 읽기에 직접 의존합니다.

모든 풀에 걸친 라우팅

Route는 각 주문을 최적의 가격을 내는 풀들로 나눕니다. 예전에는 읽기가 느리면 풀이 경로에서 빠졌고, 그 대가는 트레이더가 치렀습니다. Alchemy의 백업은 300밀리초 이내에 응답하므로 풀이 경로에 남습니다.

트레이더가 믿고 실행할 수 있는 견적

Route는 서명 전에 계획을 시뮬레이션하고, 실행 시점에 JIT 라우팅으로 계획을 다시 세웁니다. 예전에는 상태가 일관되지 않으면 리버트나 최소 수량 미달로 이어졌습니다. Alchemy는 두 단계를 같은 블록에 고정하므로, 견적은 체결이 넘어설 수 있는 하한이 됩니다.

애초에 풀을 찾는 일

Route는 240만 개 이상의 풀을 인덱싱하고 계속 다시 확인합니다. 예전에는 제공업체의 할당량 제한 때문에 스캔이 중간에 끊겼습니다. Alchemy는 한 번의 요청으로 최대 10,000개의 로그를 반환하므로, Route는 예측 가능한 하나의 한도 안에서 수만 개 블록을 스캔할 수 있습니다.

"여러 제공업체를 쓰고 있었는데, 각각 고유한 제한과 장애 양상, 유지해야 할 폴백 로직이 있었습니다. 그래서 Alchemy로 통합해 라우터, API, 다른 체인의 라우터 뒤에 하나의 제공업체, 하나의 요금제만 두었습니다. 스택은 더 단순하고 예측 가능해졌고, 인프라 벤더를 늘리지 않고도 Base, BSC, Arbitrum, Optimism, Ethereum에 Route를 출시할 수 있었습니다."

— Micah (창업자, Route)

결과: Alchemy에서 견적의 99% 이상이 성공

Route는 모든 견적 요청을 기록합니다. 최근 48시간 동안의 파트너 및 웹사이트 트래픽에서 99% 이상이 성공했습니다. 성공하지 못한 요청은 거래하기에 유동성이 너무 적은 토큰에 대한 "no route" 응답이거나, Route 자체가 처리 용량 한계에 도달한 순간이었습니다. RPC 오류는 하나도 없었습니다. 전환 전에는 제공업체의 오류가 트레이더에게 "no route"로 전달됐고, 이를 막기 위해 Route 쪽에서 재시도와 우회책이 필요했습니다.

달라진 것은 읽기가 돌아오지 않을 때 일어나는 일입니다. 예전에는 실패하거나 너무 늦게 도착해 쓸모가 없던 읽기가 이제는 제대로 도착합니다.

다음 단계: 스스로 거래하는 에이전트

다음은 에이전트 기반 실행입니다. Route는 블록마다 가격을 다시 계산하는 라이브 견적 스트림인 SDQ 위에서 동작하는 상시 주문을 만들고 있습니다. 이를 통해 지갑이나 AI 에이전트가 온체인에서 강제되는 지출 한도 안에서, 사람이 조작하지 않아도 Route를 통해 거래할 수 있습니다. 이 기능은 JIT와 같은 읽기 위에서 동작합니다.

Alchemy에서 라우터 구축하기

견적은 그 뒤의 읽기가 버텨줄 때만 유지됩니다. 그 부분을 저희가 맡습니다.

Alchemy 개발자 문서 살펴보기 또는 팀에 문의하기.