Squid: 자산이 아닌 가치의 이동, 가장 안전한 크로스체인 인프라

5년간 누적된 28억 달러 규모의 브릿지 손실이 자산을 체인 간 직접 이동시킨다는 공통된 가정 위에서 반복되어 왔음을 정리하고, Squid가 그 가정을 깨고 자산을 직접 옮기지 않는 정산 레이어로 작동하는 구조를 분석한다.

Yemo Koo

Jun 16, 2026

Contents

1. 브릿지 손실 이후의 안전성 검증 2. 기존 브릿지 인프라의 3가지 자산 이동 구조 2.1. Lock-and-Mint 2.2. Burn-and-Mint 2.3. 유동성 풀 기반 3. 28억 달러의 브릿지 손실이 보여준 4대 패턴 3.1. 프라이빗 키 탈취 3.2. 서명 검증 우회 3.3. 메시지 검증 로직 결함 3.4. 단일 검증자 의존 4. 자산이 아닌 가치의 이동 5. Squid의 정산 흐름과 유동성 구조 5.1. Squid의 정산 흐름 5.2. 유동성과 담보의 분리 6. Squid의 안전 장치와 무사고 운영 이력 6.1. Squid의 안전 장치 6.2. Squid의 무사고 운영 이력 7. 결론

1. 브릿지 손실 이후의 안전성 검증

이전 글에서는 자산 정합성, 정책 집행 일관성, 운영 회복력, 발행·환매 통제라는 4대 기관급 요건을 정의하고, Squid가 이를 인프라 단계에서 충족하는 구조적 근거를 분석하였다. 이번 글은 그 분석에서 한 걸음 더 들어가, 그 인프라가 어떻게 안전한가에 답한다.

2022년 이후 누적 브릿지 손실은 28억 달러를 넘으며, Web3 전체 해킹 손실의 약 40%가 브릿지 영역에서 발생했다. 2026년에도 대형 브릿지 사고는 반복되었다. 대표적으로 4월 KelpDAO와 LayerZero 통합에서 약 2억 9,200만 달러 규모의 손실이 발생했다. 이 사건은 단일 검증자 의존 구조의 결함이 손실로 이어진 패턴이었으며, 탈취된 자산이 인접한 대출 프로토콜의 담보로 잡혀 약 1억 7,700만 달러 규모의 bad debt가 연쇄적으로 발생했다. 단일 결함이 시스템 한 곳에서 그치지 않고 다수의 인접 인프라로 전파될 수 있다는 점을 보여준 사례다.

본 리서치는 브릿지의 아키텍처 레벨 안전성을 다음 네 단계로 정리한다. 첫째, 기존 브릿지 인프라의 3가지 구조와 각 구조의 신뢰 가정을 분석한다. 둘째, 5년 누적 28억 달러 손실에서 도출되는 4대 패턴을 정리한다. 셋째, 4대 패턴의 공통점은 토큰의 공급 또는 보관 상태를 변경한다는 가정 위에 있다는 점이며, 이 가정을 깨면 다른 인프라가 가능해진다는 발상의 전환을 제시한다. 넷째, Squid가 자산을 옮기지 않고 가치만 정산하는 레이어로 어떻게 동작하는지, 그 결과 어떤 안전 장치와 운영 이력이 만들어지는지를 정리한다.

2. 기존 브릿지 인프라의 3가지 자산 이동 구조

브릿지는 사용자가 source 체인의 자산을 destination 체인으로 이동시키는 역할을 한다. 이 단순한 기능을 구현하는 아키텍처는 기존에 크게 세 가지 형태로 발전해왔으며, 각 형태는 서로 다른 신뢰 가정과 공격 지점을 갖는다.

2.1. Lock-and-Mint

Lock-and-Mint는 가장 전통적인 브릿지 구조다. 사용자가 source 체인의 컨트랙트에 자산을 locked 상태로 예치하면, destination 체인의 컨트랙트가 그에 상응하는 wrapped 자산을 mint 한다. 사용자가 원자산으로 돌아가기 위해서는 wrapped 자산을 burn하고, source 체인에 잠겨 있던 자산의 lock이 해제되어야 한다. 핵심 신뢰 가정은 lock 컨트랙트가 안전하게 자산을 보관하고 mint 권한이 적절히 제어된다는 것이다. 그러나 lock 컨트랙트에 묶이는 자금이 클수록 단일 컨트랙트가 명확한 공격 표적이 된다. Wormhole의 3억 2,600만 달러 손실과 Ronin의 6억 2,400만 달러 손실이 이 카테고리의 대표 실패 사례다.

2.2. Burn-and-Mint

Burn-and-Mint는 Circle CCTP와 LayerZero OFT(Omnichain Fungible Token) 표준이 채택한 구조다. Source 체인에서 자산을 lock하지 않고 직접 burn하며, destination 체인에서 새로 mint 한다. 자금이 한쪽에 묶이지 않으므로 단일 컨트랙트에 집중된 자금이라는 공격 지점은 감소한다. 대신 source 체인의 burn이 실제로 일어났음을 destination 체인의 mint 컨트랙트가 어떻게 검증하는가의 문제가 새로운 신뢰 요소로 도입된다. 검증은 보통 별도의 검증 네트워크가 수행하며, 검증 네트워크 자체의 견고성이 전체 시스템의 안전성을 결정한다. 2026년 4월 KelpDAO와 LayerZero 통합에서 발생한 2억 9,200만 달러 손실이 검증 정족수 설계 결함의 대표 사례다.

2.3. 유동성 풀 기반

유동성 풀 기반 구조는 양쪽 체인에 미리 유동성 풀을 두고, source 풀 입금이 destination 풀 출금을 유발하는 방식이다. LayerZero V2 위에 OFT 표준과 자산 풀을 결합한 Stargate가 50개 이상의 체인을 지원하는 형태로 운영되며 대표 사례에 해당한다. 빠른 정산을 제공하지만 풀 깊이에 따른 슬리피지가 발생하고, 대규모 이동 시 풀에 묶인 자금이 단일 공격 지점으로 작동한다. 양쪽 풀의 균형을 유지하기 위한 리밸런싱 메커니즘이 추가 신뢰 가정으로 도입된다.

세 구조는 모두 토큰의 공급 또는 보관 상태가 변경된다는 점에서 공통점을 가진다. 자산 이동 자체가 공급 또는 보관 변경 이벤트와 결합되어 있으며, 그 결합의 어느 한 지점이 무너지면 시스템 전체가 무효화된다. 다음 장에서는 이 공통점이 어떻게 5년 누적 28억 달러 손실로 이어졌는지를 4대 패턴으로 정리한다.

3. 28억 달러의 브릿지 손실이 보여준 4대 패턴

브릿지 해킹은 기존 브릿지 구조의 아키텍처 결함이 반복적으로 노출되고, 거기에 사회공학 공격(social engineering)이 결합해 진화해왔다. 본 장은 브릿지 해킹의 근본적인 원인을 4대 패턴으로 정리한다.

3.1. 프라이빗 키 탈취

밸리데이터나 서명인의 프라이빗 키가 탈취되어 공격자가 정당한 서명을 위조하는 패턴이다. 2022년 3월 Ronin 사례가 대표적이다. Sky Mavis는 9개의 밸리데이터 중 5개가 합의하면 모든 트랜잭션을 승인하는 멀티시그 구조를 운영했으나, 공격자가 사회공학 공격으로 5개 키를 모두 확보하면서 6억 2,400만 달러의 손실이 발생했다. 동일 카테고리에 Harmony Horizon(2022.6, 1억 달러), Multichain(2023.7, 1억 2,600만 달러)이 속한다. 공통점은 신뢰가 소수의 키에 집중되어 있다는 것이다.

3.2. 서명 검증 우회

검증 로직 자체에 결함이 있어 공격자가 유효하지 않은 서명을 유효한 것으로 통과시키는 패턴이다. 2022년 2월 Wormhole 사례에서 3억 2,600만 달러가 손실되었다. 공격자는 서명 검증 함수의 입력값 검증 누락을 이용해 위조 서명으로 mint를 실행했다. 코드 단의 결함이지만 그 코드가 전체 시스템의 단일 신뢰 지점으로 작동했기 때문에, 단일 결함이 시스템 전체를 무효화했다.

3.3. 메시지 검증 로직 결함

브릿지가 크로스체인 메시지를 검증하는 방식 자체에 아키텍처 결함이 있는 패턴이다. 2022년 8월 Nomad 사례에서는 1억 9,000만 달러가 손실되었다. 원인은 한 차례의 컨트랙트 업데이트가 trusted roots 값을 0x00으로 초기화한 데 있었다. 이 값이 untrusted 메시지의 기본값과 동일했기 때문에 모든 untrusted 메시지가 유효한 것으로 통과되었다. 첫 공격자의 트랜잭션이 공개되자마자 수십 명이 동일한 calldata로 자금을 추출하는 연쇄 인출 공격 양상으로 번졌다.

3.4. 단일 검증자 의존

검증 네트워크가 단일 노드 또는 매우 적은 수의 노드에 의존하는 패턴이다. 2026년 4월 KelpDAO와 LayerZero 통합에서 발생한 2억 9,200만 달러 손실 사건이 이 패턴의 가장 최근 사례다. 문제의 근본은 KelpDAO의 OApp이 1-of-1 DVN(Decentralized Verifier Network) 설정을 사용했다는 점이었다. 단일 검증자 노드가 실패하거나 장악되면 destination 컨트랙트가 위조 메시지를 유효한 것으로 인정하는 구조였다. 공격자는 LayerZero Labs 개발자에게 사회공학 공격으로 세션 키를 탈취하고, 내부 RPC 노드를 장악한 뒤 외부 노드를 DDoS하고, 단일 검증 네트워크에 허위 데이터를 주입했다. 탈취된 약 116,500 rsETH 중 상당량이 Aave에 담보로 사용되어 1억 9,000만 달러 규모의 WETH 차입으로 이어졌고, 결과적으로 Aave에 약 1억 7,700만 달러 규모의 bad debt가 발생했다. 단일 결함이 브릿지 자체를 넘어 인접 프로토콜로 전파된 사례다. LayerZero는 이후 자사 DVN이 고가치 자산을 1-of-1 검증자 구성으로 보호하도록 허용한 점을 실수로 인정하고, 1-of-1 DVN 구성에 대한 지원을 중단하겠다고 밝혔다. KelpDAO는 이후 rsETH 브릿지를 Chainlink CCIP로 이전했고, Solv Protocol도 7억 달러 이상의 tokenized BTC 인프라를 Chainlink CCIP로 이전했다.

4개의 패턴이 보여주는 공통점은 두 가지다. 첫째, 모든 사례에서 단일 결함이 전체 시스템을 무효화했다. 아키텍처의 redundancy가 부재했고, 사고 시 격리가 불가능했다. 둘째, 모든 사례가 토큰의 공급 또는 보관 상태를 변경한다는 동일 가정 위에 있다. Lock 컨트랙트, mint 권한, 검증자 네트워크, 풀 잔액, 메시지 검증 로직 모두 토큰 이동 과정 중에 동작하며, 그 단계 중 어느 한 지점이 무너지면 전체 시스템이 무효화된다.

문제 해결의 방향은 두 가지로 나뉜다. 동일 가정 안에서 각 결함을 보완하는 방향과, 가정 자체를 다른 것으로 바꾸는 방향이다. 다음 장은 후자의 방향을 정리한다.

4. 자산이 아닌 가치의 이동

3장에서 정리한 4대 패턴의 공통 가정은 "자산을 한 체인에서 다른 체인으로 옮긴다"는 것이다. 어느 방식이든 자산 이동 과정에서 토큰의 공급 구조, 보관 상태, 또는 풀 잔액 중 하나가 변경되며, 그 변경을 검증·집행하는 지점이 단일 실패 지점으로 작동할 수 있다. 같은 가정 안에서의 개선 시도는 5년에 걸쳐 누적되어 왔다. 밸리데이터 수를 늘려도 Ronin 패턴은 사회공학 공격에 노출된다. 서명 검증 로직을 강화해도 Wormhole 패턴은 단일 함수 결함에서 출발한다. DVN을 다중화해도 KelpDAO 패턴은 운영 보안의 사각지대에서 발생한다. 이처럼 같은 가정 안에서의 개선은 같은 종류의 결함을 다른 형태로 다시 노출시킨다.

그렇다면 토큰의 공급이나 보관 상태를 건드리지 않고도, source 체인의 자산은 그대로 둔 채 destination 체인에서 사용자가 원하는 자산을 받을 수 있다면 어떨까. 이 접근은 두 가지 질문으로 이어진다. 첫째, destination 체인에서 사용자에게 자산을 전달하는 주체는 누구인가. 둘째, source 체인의 사용자 자산은 어떤 역할을 하며, 어디에 묶이는가.

Squid의 답은 명확하다. Destination 체인에서는 전문 마켓 메이커인 solver가 자기 inventory에서 자산을 직접 전달하며, Source 체인의 사용자 자산은 escrow에 묶여 정산 담보로 작동한다. 다시 말해, 사용자가 보낸 자산은 source 체인의 escrow에 잠긴 채 그대로 머무르고, destination 자산은 solver의 별도 inventory에서 사용자에게 전달된다. 이 과정에서 토큰의 공급은 변경되지 않으며, 사용자 자산이 체인 간 직접 이동하거나 mint, burn, wrap되지 않는다. 다음 5장과 6장에서는 이 구조가 실제로 어떤 메커니즘으로 구현되는지 살펴본다.

5. Squid의 정산 흐름과 유동성 구조

5.1. Squid의 정산 흐름

Squid는 사용자의 거래 의도(intent)를 RFQ(Request-for-Quote)로 처리하고, 전문 마켓 메이커(solver)가 자기 inventory에서 destination 자산을 직접 전달하는 escrow + solver 실행 레이어로 작동한다. 토큰의 공급 상태에 어떤 시점에도 손을 대지 않으며, source 체인의 자산은 escrow에 묶인 채 정산 담보로 작동한다. 하나의 크로스체인 스왑은 다음 네 단계로 종료된다.

1단계 LOCK: 사용자가 거래 의도를 제출하면, 사용자의 source 체인 자산은 escrow에 잠기며 정산 담보로 보관된다. 잠긴 자산은 escrow에서 풀려나기 전까지 사용자도, solver도, 제3자도 접근할 수 없다.

2단계 FILL: 등록된 solver가 destination 체인에서 사용자가 요청한 자산을 자기 inventory에서 직접 전달한다. solver는 자기 inventory를 먼저 소모하는 방식으로 자산을 전달하므로, source 체인의 사용자 자산이 아직 escrow에 잠겨 있는 상태에서 destination 체인의 자산이 사용자에게 먼저 도착한다.

3단계 CONFIRM: Source 체인과 destination 체인 사이의 정산 메시지가 solver의 destination 전달을 검증한다. 이 메시지 전송은 LayerZero를 포함한 외부 메시징 인프라 위에서 동작 가능하며, 메시징 인프라의 선택은 경로별로 달라질 수 있다.

4단계 SETTLE: Source 체인의 escrow가 잠겼던 사용자 자산을 solver에게 release하며, solver는 destination 체인에서 사용한 inventory를 보전받고, 이에 더해 solver 수수료를 수취한다. 사용자 입장에서의 크로스체인 스왑은 이 단계로 종료된다.

위 단계들은 두 가지 핵심 속성을 갖는다. 첫째, solver는 destination 자산을 먼저 전달하지 않고서는 source 체인의 사용자 자산에 접근할 수 없다. 이 순서는 Squid Intents의 escrow 및 settlement architecture에 의해 강제되며, solver의 정직성에 의존하지 않는다. 둘째, 만약 solver가 liveness를 잃거나 주문 체결에 실패하면 사용자 자산은 solver에게 release되지 않으며, 약 10분 내 refund가 시작된다. 환불된 자금은 quote에 명시된 주소로 반환된다.

단계	동작	상태 변화
1. LOCK	source 체인 escrow에 사용자 자산 잠금	사용자 자산 escrow lock
2. FILL	solver가 destination 체인에서 inventory로 자산 전달	destination 자산 사용자 도착
3. CONFIRM	source와 destination 사이 정산 메시지로 체결 검증	체결 사실 검증 완료
4. SETTLE	source escrow가 solver에게 자산 release, solver 수수료 수취	escrow 해제, solver 정산 완료
환불 경로	solver가 liveness를 잃거나 주문 체결에 실패하면 약 10분 내 환불 시작	사용자 자산 반환

표 1. Squid의 정산 흐름 4단계와 환불 경로

이 흐름에서 토큰의 공급 상태는 source 체인에서도, destination 체인에서도 변경되지 않는다. Source 체인의 사용자 자산은 escrow에 잠겼다가 정산 조건 충족 시 solver에게 release되며, mint, burn, wrap 어느 이벤트도 발생하지 않는다. Destination 체인의 자산은 solver의 inventory에서 사용자에게 이전될 뿐, 새로 mint되지 않는다. Squid는 토큰 자체를 옮기지 않는다.

5.2. 유동성과 담보의 분리

Squid가 escrow를 채택한다는 점에서 중간 자산이 escrow에 묶여 풀처럼 작동하는 것처럼 보일 수 있다. 그러나 Squid의 escrow는 유동성 풀이 아니라 정산 담보이며, 유동성은 escrow와 별개의 레이어에서 공급된다. Squid의 유동성·정산 인프라는 다음 세 레이어로 분리되어 있다.

레이어	기능	유동성 출처
DEX aggregation	같은 체인 내 token A에서 token B로 스왑	외부 DEX (Squid 소유 X)
solver/Intent inventory	체인 간 가치 전달	마켓 메이커 inventory + 신규 체인 재단 시드
Escrow	정산 담보 (유동성 풀 X)	사용자 source 자산 임시 보관

표 2. Squid의 3-layer 인프라 모델

DEX aggregation 레이어는 같은 체인 안에서의 token A에서 token B로의 스왑을 처리한다. 사용자가 source 체인의 token A를 보내고 destination 체인의 token B를 받기 원하면, source 체인에서 token A를 가치 전달용 자산으로 스왑하는 단계와 destination 체인에서 받은 자산을 token B로 스왑하는 단계가 각각 DEX aggregation으로 처리된다. 유동성은 Uniswap, Curve, Osmosis 등 130개 이상의 외부 DEX 풀에서 끌어오며, Squid는 이 풀을 소유하지 않는다.

Solver/Intent inventory 레이어는 체인 간 가치 전달을 담당한다. Source 체인에서 destination 체인으로 가치를 전달하는 유일한 통로는 이 레이어이며, 유동성은 등록된 solver의 inventory에서 공급된다. Squid는 solver들이 자기 inventory를 운영하면서 정산을 처리하도록 매칭 인프라를 제공할 뿐, solver의 자본 자체를 운영하지 않는다. 신규 통합 체인에서 마켓 메이커 inventory가 충분히 두텁지 않은 경우에는 재단이 네이티브 자산과 스테이블코인을 회수 가능한 운전자본 형태로 시드해 초기 유동성을 보조한다.

Escrow 레이어는 정산 담보를 담당한다. 사용자의 source 체인 자산이 크로스체인 스왑이 완료될 때까지 임시 보관되는 공간이며, destination 체인의 자산 지급에는 어떤 시점에도 사용되지 않는다. Escrow에 묶인 자산은 solver가 liveness를 잃거나 주문 체결에 실패하면 사용자에게 반환되거나, 체결 완료 시 solver에게 release되는 경로로만 처리된다. destination 체인에서 사용자에게 자산을 전달하는 주체는 항상 solver의 inventory이며, escrow는 source 측 자산과 destination 측 정산을 상계하기 위한 담보로 작동할 뿐 자산 자체를 새로 생성하거나 다른 자산으로 변환하지 않는다.

이 구분은 브릿지 안전성의 출발점이다. Escrow가 유동성 풀이었다면 escrow의 잔액 자체가 공격 지점이 되며, 풀 깊이가 슬리피지에 영향을 미치고, 풀 균형을 유지하는 리밸런싱 메커니즘이 별도 신뢰 가정으로 도입된다. 그러나 Squid의 escrow는 사용자별로 격리된 정산 담보이므로, 한 사용자의 escrow가 다른 사용자의 정산에 영향을 미치지 않으며 풀 깊이라는 개념이 존재하지 않는다.

6. Squid의 안전 장치와 무사고 운영 이력

6.1. Squid의 안전 장치

Squid의 안전성은 solver의 정직성이나 브랜드의 평판에 의존하지 않는다. 사용자 자산이 손실되지 않는 이유는 아키텍처가 그렇게 설계되었기 때문이며, 그 설계는 주요 안전 장치를 기반으로 작동한다.

리스크	구조적 방어
solver가 destination 자산을 전달하지 않고 escrow 인출 시도	escrow는 체결 검증을 통과해야만 release, solver가 liveness를 잃거나 주문 체결에 실패하면 약 10분 내 refund
실행 중 라우트 실패	fallback 주소로 자금 회수
비정상 라우팅 경로	기본 guardrails 작동 (bypass는 선택 적용)
finality 리스크	Pre-finality risk는 사용자가 아니라 solver가 부담

표 3. Squid의 주요 안전 장치

위 안전 장치를 통해 solver가 자산을 전달하지 않고 인출을 시도하더라도 escrow는 체결 검증 없이 release되지 않으며, 라우트가 실행 중 실패해도 지정된 fallback 주소로 회수되고, 비정상 경로는 guardrails에서 차단된다. Pre-finality risk도 사용자가 아니라 solver가 부담하는 구조다.

이 설계는 앞서 살펴본 주요 브릿지 리스크에 대한 완화 매핑으로 정리할 수 있다.

Squid의 아키텍처 선택	완화되는 리스크
TEE 기반 정산 레이어	서명 검증 우회, 메시지 검증 로직 결함
RFQ + Solver Network	소수 검증자 키에 집중되는 자산 이동 승인 리스크
토큰 공급 미변경 (escrow + solver)	lock contract, mint authority, pool balance에 집중되는 공격 지점
100+ 체인에 대한 per-chain contract deployment 불필요	각 체인의 컨트랙트 공격 지점

표 4. Squid의 아키텍처 선택과 주요 브릿지 리스크 완화 매핑

6.2. Squid의 무사고 운영 이력

이러한 아키텍처 위에서 Squid는 2023년 메인넷 출시 이후 보안 사고 0건의 운영 이력을 유지하고 있다. 무사고 운영 이력은 브릿지 해킹 패턴이 반복적으로 발생하는 시기에 같은 패턴에 노출되지 않은 아키텍처를 운영해온 결과다. 2026년 5월, Squid 공식 인프라와 무관한 한 사건이 일부 미디어에서 Squid 해킹 사건으로 보도되며 혼동이 발생했다. 이 사건은 Squid 사용자와 통합 파트너의 자산에 어떤 영향도 미치지 않았으며, 사실관계는 다음과 같다.

2026년 5월, Base와 Ethereum에서 SquidRouterModule이라는 이름의 제3자 Gnosis Safe 모듈이 공격을 받았다. 약 2시간에 걸쳐 86개의 Gnosis Safe wallet에서 합산 약 320만 달러가 유출되었다.

핵심은 이 모듈이 Squid가 개발·배포·운영한 컨트랙트가 아니라는 점이다. SquidRouterModule은 Squid의 라우터를 포함한 여러 프로토콜을 통합한 제3자 스마트 월렛 제품이었다. Squid 팀과는 어떠한 협력 관계도 없었으며, Squid는 해당 모듈의 개발·배포·운영 어디에도 관여하지 않았다. Squid의 공식 라우터 컨트랙트는 0xce16F69375520ab01377ce7B88f5BA8C48F8D666이다. 이 컨트랙트는 SquidRouterModule과 코드 구조, 호출 경로, 권한 관리, 검증 메커니즘 어디에서도 동일하지 않으며, 이번 사건과 어떤 코드 경로로도 연결되지 않는다.

따라서 Squid가 해킹되었다는 일부 보도는 사실과 다르다. Squid의 무사고 운영 이력은 본 사건의 영향을 받지 않는다. 본 사건에서 짚어둘 시사점은 한 가지다. 제3자가 프로토콜의 이름을 차용할 때 사용자가 신뢰 경계를 혼동하지 않도록 프로토콜 identity가 명확히 정의되어 외부에 노출되어야 한다. Squid는 공식 라우터 주소와 공식 통합 경로를 명확히 고지하고, 통합 파트너와 제3자 모듈을 구분하여 운영한다.

7. 결론

브릿지 해킹은 반복되는 패턴을 보여왔으며, 그 모든 패턴은 체인 간 자산을 옮긴다는 동일한 가정 위에 있다. 기존 브릿지 인프라 구조들은 자산 이동 과정에서 토큰 공급, 보관 상태, 또는 풀 잔액을 변경하며, 그 단계 중 어느 한 지점이 무너지면 전체 시스템이 무효화된다. 같은 가정 안에서의 개선은 같은 결함을 다른 형태로 반복한다.

Squid는 그 가정을 깬다. 사용자의 source 자산은 escrow에 정산 담보로 잠긴 채 토큰 공급 상태가 변경되지 않으며, destination 자산은 solver가 자기 inventory에서 직접 전달한다. Squid의 4단계 정산 흐름은 solver가 destination 자산을 먼저 전달하지 않고서는 source 자산에 접근할 수 없는 순서를 강제하며, solver가 liveness를 잃거나 주문 체결에 실패하면 사용자 자산은 solver에게 release되지 않으며, 사용자에게 반환된다. 또한, 유동성은 DEX aggregation, solver/intent inventory, escrow 3개의 레이어에 분리되어 있으며, escrow는 유동성 풀이 아니라 정산 담보로 작동한다. 이 아키텍처 위에서 주요 안전 장치가 작동하며, 기존 브릿지에서 반복적으로 노출된 주요 공격 지점이 구조적으로 줄어든다. 2023년 메인넷 출시 이후 보안 사고 0건의 운영 이력은 이러한 아키텍처 선택의 결과다.

본 글의 분석은 이전 글에서 정리한 4대 기관급 요건(자산 정합성, 정책 집행 일관성, 운영 회복력, 발행·환매 통제)과도 연결된다. 토큰 공급을 변경하지 않고, 자산을 체인 간 직접 이동시키지 않는 구조는 자산 정합성을 검증하기 쉬운 형태로 만들며, escrow의 정산 담보 역할이 비정상 트랜잭션의 즉시 인출 경로를 차단함으로써 정책 집행 일관성이 충족된다. 100개 이상 체인을 컨트랙트 배포 없이 지원하는 구조가 체인 단위 격리 운영을 가능하게 하고, 4단계 정산 흐름의 이벤트 기록이 audit trail로 작동해 발행·환매 통제의 기반을 제공한다.

기관 발행 주체와 파트너가 크로스체인 인프라를 평가할 때, 자산이 어떤 방식으로 이동하는지는 반드시 검증해야 할 핵심 항목이다. Squid처럼 토큰 공급을 변경하거나 자산을 직접 브릿징하지 않고, solver inventory와 escrow 기반 정산 구조로 대체하는 인프라는 이 검증 부담을 줄인다. 컴플라이언스와 내부 통제가 외부 모듈이 아닌 정산 흐름 자체에서 충족되며, 자산 정합성과 운영 회복력 같은 기관 수준의 요건도 같은 구조 안에서 자연스럽게 확보되기 때문이다. 브릿지의 다음 경쟁력은 자산 이동 과정에서 발생하는 공격 지점을 얼마나 줄이고, 정산 흐름 자체에서 기관 수준의 통제 요건을 얼마나 충족할 수 있는지에 달려 있다. Squid는 그 가능성을 무사고 운영으로 증명한 정산 레이어다.

아티클 핵심 정보 출처

면책 조항

본 보고서의 내용은 단순 정보 제공을 목적으로 하며, 어떠한 경우에도 법률, 비즈니스, 투자 및 세무 자문을 위한 권고나 근거로 사용될 수 없습니다. 본문에 언급된 특정 자산이나 증권은 정보 전달만을 위한 것으로, 해당 자산에 대한 매수·매도 제안이나 투자 권유를 의미하지 않습니다. 모든 투자 결정에 따른 책임은 투자자 본인에게 있으며, 본 보고서는 회계나 법률적 판단의 지침이 될 수 없습니다.

필자는 리서치 및 집필 과정에서 인지한 미공개 정보를 이용하여 관련 자산을 거래하지 않음을 원칙으로 하고 있습니다. 본 리포트의 저자 및 카탈라이즈는 보고서에서 다루는 자산 또는 토큰에 대해 개인적·경제적 이해관계를 가질 수 있으며, 특정 네트워크의 전략적 파트너일 수 있습니다.

본 보고서에 기술된 분석 및 의견은 저자 개인의 견해로, 카탈라이즈 또는 관련 기관의 공식 입장을 대변하지 않습니다. 또한, 모든 내용은 리포트 작성 시점을 기준으로 하며 시장 상황 및 신규 정보에 따라 사전 통보 없이 변경될 수 있습니다.

Contents

한국어

Squid: 자산이 아닌 가치의 이동, 가장 안전한 크로스체인 인프라

Yemo Koo

Jun 16, 2026

Contents

1. 브릿지 손실 이후의 안전성 검증

2. 기존 브릿지 인프라의 3가지 자산 이동 구조

2.1. Lock-and-Mint

2.2. Burn-and-Mint

2.3. 유동성 풀 기반

3. 28억 달러의 브릿지 손실이 보여준 4대 패턴

3.1. 프라이빗 키 탈취

3.2. 서명 검증 우회

3.3. 메시지 검증 로직 결함

3.4. 단일 검증자 의존

4. 자산이 아닌 가치의 이동

5. Squid의 정산 흐름과 유동성 구조

5.1. Squid의 정산 흐름

단계	동작	상태 변화
1. LOCK	source 체인 escrow에 사용자 자산 잠금	사용자 자산 escrow lock
2. FILL	solver가 destination 체인에서 inventory로 자산 전달	destination 자산 사용자 도착
3. CONFIRM	source와 destination 사이 정산 메시지로 체결 검증	체결 사실 검증 완료
4. SETTLE	source escrow가 solver에게 자산 release, solver 수수료 수취	escrow 해제, solver 정산 완료
환불 경로	solver가 liveness를 잃거나 주문 체결에 실패하면 약 10분 내 환불 시작	사용자 자산 반환

표 1. Squid의 정산 흐름 4단계와 환불 경로

5.2. 유동성과 담보의 분리

레이어	기능	유동성 출처
DEX aggregation	같은 체인 내 token A에서 token B로 스왑	외부 DEX (Squid 소유 X)
solver/Intent inventory	체인 간 가치 전달	마켓 메이커 inventory + 신규 체인 재단 시드
Escrow	정산 담보 (유동성 풀 X)	사용자 source 자산 임시 보관

표 2. Squid의 3-layer 인프라 모델

6. Squid의 안전 장치와 무사고 운영 이력

6.1. Squid의 안전 장치

리스크	구조적 방어
solver가 destination 자산을 전달하지 않고 escrow 인출 시도	escrow는 체결 검증을 통과해야만 release, solver가 liveness를 잃거나 주문 체결에 실패하면 약 10분 내 refund
실행 중 라우트 실패	fallback 주소로 자금 회수
비정상 라우팅 경로	기본 guardrails 작동 (bypass는 선택 적용)
finality 리스크	Pre-finality risk는 사용자가 아니라 solver가 부담

표 3. Squid의 주요 안전 장치

이 설계는 앞서 살펴본 주요 브릿지 리스크에 대한 완화 매핑으로 정리할 수 있다.

Squid의 아키텍처 선택	완화되는 리스크
TEE 기반 정산 레이어	서명 검증 우회, 메시지 검증 로직 결함
RFQ + Solver Network	소수 검증자 키에 집중되는 자산 이동 승인 리스크
토큰 공급 미변경 (escrow + solver)	lock contract, mint authority, pool balance에 집중되는 공격 지점
100+ 체인에 대한 per-chain contract deployment 불필요	각 체인의 컨트랙트 공격 지점

표 4. Squid의 아키텍처 선택과 주요 브릿지 리스크 완화 매핑

6.2. Squid의 무사고 운영 이력

7. 결론

아티클 핵심 정보 출처

면책 조항

Contents