링크가 복사되었습니다.

링크복사
공유
댓글

Squid | 브릿지를 직접 만들지 않고 크로스체인 마켓을 운영한다, 화이트라벨 Solver

코인이지

2026.09.23 16:17:18

Squid | 브릿지를 직접 만들지 않고 크로스체인 마켓을 운영한다, 화이트라벨 Solver

지갑이나 거래 서비스가 크로스체인 스왑을 제공하려면 화면에 ‘Swap’ 버튼 하나를 추가하는 것만으로는 부족합니다.

여러 체인에 자산을 배치하고, 실시간 가격을 계산하며, 사용자의 주문을 받을 시스템과 목적지 체인에서 자산을 지급할 실행 엔진이 필요합니다. 부족해진 유동성을 다시 채우고, 브리지와 메시징 시스템, 거래 상태까지 관리해야 합니다.

Squid는 일반적인 API·SDK 통합뿐 아니라, 파트너가 Squid의 크로스체인 인프라 안에서 자체 Solver 네트워크와 멀티체인 유동성을 운영할 수 있는 화이트라벨 구조를 제공하고 있습니다. 파트너는 Squid Intents의 주문 시스템을 이용하면서도 자체 브랜드와 가격 정책, 유동성 운영 방식을 유지할 수 있습니다.

크로스체인 거래에서 Solver는 무엇을 할까?

Squid Intents에서 사용자는 어떤 브리지와 DEX를 거쳐야 하는지 직접 정하지 않습니다.

사용자가 원하는 출발 자산과 도착 자산을 지정하고 소스 체인에 자산을 예치하면, RFQ 방식의 경매가 시작됩니다. 여러 마켓메이커가 목적지 체인에서 얼마를 제공할 수 있는지 경쟁하고, 가장 좋은 조건을 제시한 Solver가 주문을 실행합니다.

Solver는 목적지 체인에서 자신의 유동성을 이용해 사용자에게 자산을 지급합니다. 이후 시장에서 반대 거래를 실행하거나 다른 경로를 활용해 포지션을 헤지하고, 체인 사이의 재고를 조정합니다.

예를 들어 사용자가 Arbitrum의 USDC를 Base의 ETH로 바꾸려 한다면, Solver는 Base에서 ETH를 즉시 제공할 수 있어야 합니다. 거래가 끝난 뒤에는 Arbitrum에서 받은 USDC와 Base에서 지급한 ETH 사이의 포지션을 정리해야 합니다.

Squid Intents는 이러한 견적 경쟁과 실행 조정을 오프체인에서 처리하고, 검증된 결과를 온체인 토큰 전송으로 정산합니다. 복잡한 경로를 사용자가 직접 실행하는 대신, 유동성을 가진 Solver들이 원하는 결과를 제공하기 위해 경쟁하는 구조입니다.

단순 통합과 화이트라벨 Solver는 다르다

일반적인 Squid 통합에서는 지갑이나 디앱이 Squid API·SDK·Widget을 연결합니다.

서비스는 Squid가 제공하는 경로와 견적을 사용자 화면에 표시하고, 사용자는 해당 서비스 안에서 크로스체인 거래를 실행할 수 있습니다. 개발자는 체인별 브리지와 DEX를 직접 연결하지 않아도 됩니다.

화이트라벨 Solver는 여기서 한 단계 더 나아갑니다.

파트너가 단순히 Squid의 거래 기능을 보여주는 것이 아니라, 자체 유동성과 가격 알고리즘을 이용해 주문을 채우는 공급자가 됩니다. 사용자는 파트너의 브랜드와 인터페이스를 이용하지만, 뒤에서는 파트너가 운영하는 Solver가 Squid Intents의 RFQ 주문에 참여합니다.

공식 문서상 화이트라벨 파트너는 자신만의 Solver 네트워크와 멀티체인 유동성을 Squid의 크로스체인 라우팅 인프라 안에 배치할 수 있습니다. 이를 통해 브랜드와 사용자 경험뿐 아니라 주문에 사용되는 유동성과 가격 정책도 더 직접적으로 통제할 수 있습니다.

쉽게 말하면 일반 통합이 Squid의 거래 기능을 서비스 안에 넣는 것이라면, 화이트라벨 Solver는 Squid의 주문·정산 인프라 위에서 자체 크로스체인 마켓을 운영하는 것에 가깝습니다.

자체 Solver를 운영하려면 무엇이 필요할까?

화이트라벨 구조는 위젯을 붙이는 것처럼 바로 시작할 수 있는 기능이 아닙니다.

첫 번째 조건은 온체인 유동성입니다. 공식 문서에서는 하나 이상의 EVM 호환 체인에 주문을 처리할 수 있는 자산을 배치해야 한다고 설명합니다. 목적지 체인에 충분한 자산이 없다면 사용자에게 약속한 수량을 지급할 수 없습니다.

두 번째는 Orderbook과 Execution Engine입니다.

Solver는 들어오는 주문을 확인하고 현재 시장가격과 가스비, 보유 자산, 재조정 비용을 바탕으로 견적을 만들어야 합니다. 주문에 낙찰되면 목적지 체인에서 자산을 전송하고 이후 포지션을 헤지하는 실행 시스템도 필요합니다.

세 번째는 Squid Intents의 주문 생명주기를 따르는 기술 연결입니다. 파트너 시스템은 REST 또는 WebSocket 엔드포인트를 지원하고, RFQ → Fill → Settlement로 이어지는 규칙에 맞춰 주문 상태를 처리해야 합니다.

공식 절차도 완전한 셀프서비스 방식은 아닙니다. 파트너는 Squid와 운영 요건과 유동성 투입 규모를 협의한 뒤 프로덕션 환경에 진입해야 하며, 출시 이후에는 Squid Intents의 모니터링과 지원을 받을 수 있습니다.

따라서 화이트라벨 Solver는 일반 개발팀보다는 이미 마켓메이킹 경험과 여러 체인의 유동성, 안정적인 거래 시스템을 가진 사업자에게 더 적합한 구조입니다.

Solver는 어떻게 수익을 만들까?

Squid는 화이트라벨 Solver의 주요 장점으로 스프레드와 수수료, 주문에서 발생하는 수익을 직접 확보할 수 있다는 점을 제시합니다.

Solver는 사용자가 받고자 하는 자산의 수량을 제시할 때 현재 시장가격뿐 아니라 가스비와 헤지 비용, 체인 간 자산 재배치 비용, 운영 위험을 함께 반영합니다.

예를 들어 목적지 체인에서 ETH가 부족해질 가능성이 있거나, 주문 이후 포지션을 정리하는 비용이 높다면 이를 견적에 포함할 수 있습니다. 반대로 해당 체인에 유동성이 풍부하고 빠르게 헤지할 수 있다면 더 경쟁력 있는 가격을 제시해 주문을 확보할 수 있습니다.

화이트라벨 파트너는 독자적인 가격 알고리즘을 사용하거나, 특정 체인과 거래쌍에 추가 유동성 인센티브를 제공할 수도 있습니다. 기존 거래 터미널이나 DeFi 프론트엔드에 연결하거나, 현재 운영 중인 마켓메이킹 사업을 크로스체인 주문으로 확장하는 활용 방식도 공식 문서에 제시돼 있습니다.

다만 주문이 들어올 때마다 자동으로 수익이 보장되는 것은 아닙니다.

다른 Solver보다 좋은 가격을 제시해야 경매에서 주문을 확보할 수 있고, 견적을 잘못 계산하면 사용자가 지불한 스프레드보다 헤지와 재조정에 더 많은 비용이 들 수 있습니다. 수익은 거래량뿐 아니라 가격 책정 능력과 자본 효율성, 실행 속도에 따라 달라집니다.

브리지를 직접 만들지 않아도 된다는 의미

기존에 사업자가 독립적인 크로스체인 거래 서비스를 만들려면 여러 브리지와 메시징 프로토콜을 직접 통합해야 했습니다.

각 체인의 스마트컨트랙트와 토큰 규격, 거래 확정 시간, 실패 처리 방식도 개별적으로 관리해야 합니다. 새로운 체인이 추가될 때마다 별도의 개발과 보안 검토가 필요할 수 있습니다.

Squid의 화이트라벨 구조에서는 파트너가 이러한 연결 인프라를 처음부터 다시 만들기보다 Squid의 크로스체인 라우팅과 Squid Intents의 주문 구조를 이용합니다. 공식 문서도 복잡한 브리지와 메시징 로직을 재구축하지 않고 확장할 수 있다는 점을 주요 장점으로 설명합니다.

파트너는 사용자를 확보하는 브랜드와 인터페이스, 경쟁력 있는 가격을 만드는 유동성 운영에 집중하고, 체인 간 연결과 주문 생명주기는 Squid의 기반 위에서 처리할 수 있습니다.

이는 단순히 개발 시간을 줄이는 것 이상의 의미가 있습니다.

사용자가 파트너의 앱을 떠나 별도의 브리지로 이동하지 않아도 되고, 사업자는 거래 경험과 수수료 정책을 자신의 서비스 안에서 유지할 수 있습니다. 공통 인프라를 사용하면서도 고객 관계와 거래 경제성은 파트너가 직접 가져갈 수 있는 것입니다.

더 많은 통제권에는 더 많은 운영 책임이 따른다

화이트라벨 Solver는 가격과 유동성을 통제할 수 있지만, 그만큼 운영해야 할 영역도 많아집니다.

여러 체인에 자산을 배치하면 체인마다 재고가 불균형해질 수 있습니다. 특정 체인에서 매수 주문이 계속 발생하면 그곳의 자산이 줄어들고, 반대편 체인에는 사용자가 예치한 자산이 쌓입니다. Solver는 브리지와 거래소, 장외거래 등을 활용해 자산을 다시 배치해야 합니다.

가격 변동 위험도 존재합니다. 견적을 제시한 시점과 실제 헤지가 완료되는 시점 사이에 시장가격이 움직이면 손실이 발생할 수 있습니다. 거래량이 적은 토큰이나 유동성이 얕은 체인에서는 이러한 위험이 더 커질 수 있습니다.

서버 가용성과 보안 역시 중요합니다. Orderbook이나 Execution Engine이 중단되면 견적을 제공하거나 낙찰된 주문을 실행할 수 없습니다. 개인키 관리와 체인별 RPC 안정성, 거래 모니터링, 비상 정지 정책도 직접 구축해야 합니다.

현재 화이트라벨 문서는 파트너가 하나 이상의 EVM 호환 체인에 유동성을 공급하는 것을 전제합니다. 따라서 Squid 전체가 Bitcoin이나 XRPL 같은 네트워크를 지원한다는 사실과, 개별 화이트라벨 Solver가 처음부터 모든 비EVM 체인의 주문을 처리할 수 있다는 주장은 구분해야 합니다.

결국 화이트라벨은 Squid에 유동성을 맡겨 두고 수동적으로 수익을 받는 상품이 아닙니다. 자본과 가격 시스템, 실행 엔진을 직접 운영하는 전문적인 B2B 인프라입니다.

앱이 거래 화면을 넘어 유동성 공급자가 된다

Squid의 일반적인 개발자 도구는 앱이 크로스체인 거래를 사용자에게 제공할 수 있도록 만듭니다.

화이트라벨 Solver는 앱과 거래 사업자가 여기서 더 나아가, 실제 주문을 채우고 가격을 제시하는 시장 참여자가 될 수 있도록 합니다.

파트너는 Squid가 구축한 체인 연결과 Intents 기반 주문 시스템을 활용하면서 자체 브랜드와 유동성, 가격 알고리즘을 유지합니다. 경쟁력 있는 견적을 제공해 주문을 확보하면 스프레드와 수수료를 수익으로 가져갈 수 있습니다.

반면 유동성 재배치와 헤지, 시스템 운영, 보안에 대한 책임도 파트너가 부담합니다.

따라서 Squid의 화이트라벨 Solver가 제공하는 것은 간단한 크로스체인 플러그인이 아닙니다.

브리지와 메시징 인프라를 처음부터 다시 만들지 않으면서도, 자체 브랜드로 크로스체인 주문을 받고 유동성과 가격, 수익 구조를 직접 운영할 수 있는 기반입니다.

목록으로

댓글 2개