0x는 Solana 스왑 API를 다음에서 운영합니다. Quicknode

Quicknode

2026년 9월 10일 — 읽는 데 5분 소요

공유하기

선호하는 소스로 추가

많은 온체인 앱에서 스왑 경로 선택은 대개 스왑 제공업체가 제시한 호가에 따라 결정됩니다. 0x의 라우팅 엔진은 ‘정산’을 기준으로 최적화되는데, 즉 거래가 실제로 체결되는지, 그리고 최종 정산 금액이 약속된 금액에서 얼마나 벗어나는지를 중점적으로 고려합니다. 이러한 기준은 데이터에 큰 부담을 줍니다. Solana 에서 호가의 신뢰도는 그 호가가 산정된 계정 상태만큼만 유효합니다.

2026년 8월, 0x는 이러한 체계적인 접근 방식을 Solana 에 도입했습니다. Solana 의 0x Swap API가 오픈 베타에 진입했으며. 이는 9년 이상의 온체인 거래 경험을 바탕으로 한 최초의 비-EVM 네트워크로, 이미 거래 경로를 설정할 준비가 된 사용자들과 함께 출시되었습니다. 여기에는 대출 프로토콜 내 스왑에 0x를 사용하는 Kamino, 베타 기간 동안 수백만 달러 규모의 거래량을 처리한 0x의 자체 메타 애그리게이터인 Matcha Meta, 그리고 제공자들이 처리된 거래량을 기준으로 경쟁하도록 하는 메타 애그리게이터인 Titan이 포함됩니다.

Solana 용 Swap API를 재구축한 것이 의미하는 바

EVM 체인에서 Swap API는 서명 준비가 완료된 트랜잭션을 반환합니다. Solana 의 경우, 0x는 다른 방식을 채택했습니다. 즉, 통합자가 실시간 계정 상태를 기준으로 가격이 책정된 개별 명령들을 모아 제출할 트랜잭션을 구성하는 방식입니다. 다중 홉(Multi-hop) 경로는 Solana 의 제한 범위 내에 들어갈 만큼 간결한 주소 조회 테이블(Address Lookup Tables)을 통해 컴파일됩니다. 이 명령어 세트는 진행 과정에서 토큰 계정을 생성하며, 래핑 단계 없이 네이티브 SOL을 처리합니다. 토큰-2022 라우팅은 7월 비공개 베타 테스트에서 스테이블코인, 토큰화된 주식 및 런치패드 토큰에 적용되었습니다. 이 모든 과정은 다음을 통해 직접 전달되는 최신 계정 상태에 의존합니다. Quicknode를 통해 직접 전달되는 최신 계정 상태에 의존합니다.

Solana 의 견적에 따른 워크로드는 트랜잭션 전송이 아닙니다. 0x는 이를 “본질적으로 대규모 계정 추적”이라고 설명합니다. 즉, 계정, 구독, 그리고 풀 상태를 최신으로 유지하는 직접 RPC 조회 등이 이에 해당합니다. 0x의 API는 약 3,000개의 활성 WebSocket 연결을 유지하며, 초당 100건 이상의 계정 업데이트를 처리합니다. 페치 경로는 구독만큼이나 중요한 역할을 합니다. 0x는 Solana 에서 이를 Swap API의 낮은 지연 시간을 보장하는 데 필수적인 요소라고 설명합니다. Solana 슬롯 시간은 점점 짧아지고 있으며, 2026년 8월에는 400ms에서 350ms로 단축될 예정이며, 200ms를 목표로 단계적으로 단축될 예정입니다 . 각 슬롯마다 호가 뒤에 있는 풀을 이동시킬 수 있으므로, 새로운 호가가 표시될 수 있는 시간은 점점 좁아지고 있습니다. 업데이트 속도가 느리면 오래된 호가가 생성됩니다. 구독이 끊어지더라도 오류 메시지는 발생하지 않지만, 결과적으로는 동일한 현상이 발생합니다.

0x는 이번 출시가 다음 세 가지 요소에 달려 있었다고 밝혔습니다: 높은 계정 업데이트 처리량 하에서도 유지되는 안정성, 끊기지 않는 구독 연결, 그리고 높은 요청 부하에서도 낮은 지연 시간을 유지하는 응답입니다. 이 세 가지 요소의 배경에는 0x가 출시하는 모든 서비스에 적용하는 기준인 월간 가동률 99.5%가 자리 잡고 있습니다. 이러한 신뢰성 덕분에 여러 체인의 팀들이 0x를 경유하여 서비스를 운영하며, 동일한 기준이 0x의 제공업체들에게도 적용됩니다 . 0x는 이를 지원하는 것이 “타협의 여지가 없다”고 밝혔습니다 .

Solana 를 실행하는 방법: 세 가지 인프라 호출

Swap API를 최초의 비-EVM 네트워크에 도입하는 과정에서는 세 가지 뚜렷한 결정이 필요했습니다. 0x의 ‘ Solana ’equipe 에서는 각 결정에 대해 구체적으로 다루었습니다.

첫 번째는 Solana 전문 업체를 이용할지, 아니면 멀티체인 제공업체를 이용할지 여부였습니다. 0x는 대량의 구독 및 요청 데이터를 처리하는 것을 가장 중요하게 여겼습니다. 일부 제공업체는 Solana 에서 이를 처리할 수 있지만, 0x의 평가에 따르면“ Solana 만 처리할 수 있을 뿐”이며, 이는 RPC 벤더 스택을 복잡하게 만드는 대가를 치러야 합니다. 기능 면에서 0x는 Quicknode 의 제품이“우리가 필요로 하는 바에 대해 잘 구상되어 있고 성능도 뛰어나다”고 판단했습니다. 가장 까다로운 테스트는 동시에 수많은 구독을 지원하는 동시성 테스트였습니다. equipe 는 이를“진정으로 까다로운 과제였으나, Quicknode 가 이를 해결했다”고 평가했습니다. 기존 EVM 파트너십은 수년간의 실적과 지원 경험을 제공했으며, 이는 0x가 운영하는 모든 제품에 걸쳐 단일 파트너와 단일 패키지를 사용할 수 있음을 의미했고, 스택 내에 또 다른 Solana 전용 벤더가 추가되는 것을 방지했습니다.

두 번째는 얼마나 많은 용량을 확보해야 하며, 몇 개의 리전에 걸쳐 확보해야 하는지였습니다. 0x는 자체 평가를 진행했습니다. 초기 테스트에서 Quicknode Pro 네트워크는 0x가 측정한 제공업체 중 p90 지연 시간이 가장 낮은 수준 중 하나를 보였습니다. 이후 equipe 는 Quicknode Dedicated Clusters 로 전환되었습니다. 이는 두 리전에 걸쳐 용량을 확보하고, Pro 네트워크로 폴백하는 방식입니다. p90 지연 시간은 약 70% 감소했습니다.

세 번째 방안은 회사의 본능과는 정반대였다. 이곳은 ‘빌더 우선(builder-first)’을 지향하는 equipe 이며, 잠시나마 자체 Solana 노드를 운영할 가능성도 검토되었다. 그러나 비용과, 더 중요한 것은 전문성이라는 두 가지 요인이 결정을 좌우했다. equipe 에 따르면,“ Solana 에는 특정 전문 지식이 필요한 부분이 많다.” 노드 운영을 Quicknode 에 맡김으로써, 0x의 엔지니어들은 오직 0x만이 해결할 수 있는 유일한 문제, 즉 Solana 를 위한 스왑 API 재구축에 집중할 수 있게 되었는데,“이 작업 자체만으로도 결코 쉬운 일이 아니었다.”

오픈 베타가 시작된 이후로

첫 번째 신호는 0x의 equipe 에 대한 별도의 개입 없이 발생했습니다. 개별 통합 업체들은 0x 측에서 아무런 변경 사항 없이 초당 수십 건의 요청에서 200 RPS로 처리량을 확장했습니다. 0x는 이러한 성장을 자사 API의 아키텍처와 그 기반이 되는 RPC 제공자의 덕분으로 보고 있습니다.

7월, 비공개 베타 기간 동안 매주 12~14개의 서로 다른 팀이 Solana endpoint 에 접속했습니다. 8월에는 매주 33개 팀 (2.4배~2.8배 증가)이 접속했습니다. Solana 에 처음으로 요청을 보낸 팀의 수는 하루 1개에서 3개로 늘어났습니다. 0x 게이트웨이의 지연 시간은 안정적으로 유지되었으며, 통합 업체 수가 두 배 이상 증가했음에도 불구하고 p50은 약 15ms, p95는 약 80ms 수준을 기록했습니다. 같은 7월부터 8월까지의 기간 동안 서버 오류율은 0.19%에서 0.017%로 떨어졌으며, 이는 11배 감소한 수치입니다. 503 오류는 완전히 사라졌습니다.

Quicknode 이미 EVM 측에서 0x의 Swap API를 제공하는 업체였습니다. 이제 이러한 협력 관계를 통해 해당 API가 지원하는 최초의 비-EVM 네트워크와, Solana 의 호가 산정 기준이 되는 계정 상태도 함께 제공됩니다.

Solana 워크로드에 대해 equipe 담당자에게 문의해 주십시오.