Introduction
When the team behind Squid Router, a cross-chain swap aggregator built atop Axelar, responded to a roughly $3.2 million exploit in November 2025 by saying they did not know who had deployed the affected contract, the statement read as evasive on first pass. On second pass it read as something stranger: an honest description of how a meaningful share of DeFi now works.
The contract in question, referred to in disclosures as a SquidRouterModule, carried Squid’s name in its identifier and was reachable through transaction flows that users would reasonably associate with the Squid product. It was not, according to the team, written, deployed, or operated by them. It was a third-party integration that lived in the same neighborhood as the official router and had inherited some of its reputational gravity without inheriting its review process.
This pattern — protocols whose effective attack surface extends well beyond the code their core team maintains — is not new. What the Squid incident makes legible is the structural ambiguity of ownership in modular DeFi: the gap between the contracts a team audits and ships, the contracts that compose with them, and the contracts that users actually interact with under the team’s brand. The exploit was small by historical standards. The governance problem it surfaces is not.
We use the Squid incident as an entry point to examine how third-party modules become load-bearing in protocols designed for permissionless composability, why responsibility tends to evaporate at module boundaries, and what comparable cases across DeFi history suggest about the durability of this failure mode.
What actually happened to Squid
Squid Router is a cross-chain liquidity layer that uses Axelar’s General Message Passing to route swaps and arbitrary calls between chains. In practice it is a coordination layer: a user submits a swap on chain A, Squid routes through DEX liquidity on chain A, hands a payload to Axelar, and a corresponding contract on chain B receives that payload and executes the destination-side logic. The destination-side logic is where the design opens up.
To support arbitrary post-bridge actions — deposit into a lending market, mint an LP position, stake a token, swap into something illiquid — the architecture allows calls to be dispatched to executor or module contracts. Some of those modules are written by the Squid team. Others are written by integration partners, by protocols wanting to expose themselves as a Squid destination, or by anonymous deployers who found that the routing infrastructure would happily forward calls to whatever address satisfied a loose interface.
According to public disclosures around the incident, the exploited contract was one of these adjacent modules rather than the core router. Reporting by The Block summarized the team’s position: the module had not been deployed by Squid, the team could not identify the deployer, and they distanced themselves from operational responsibility for it. Funds were drained through a flaw in how the module handled inbound calls — a pattern broadly consistent with insufficient validation of who could trigger which internal function, though specific technical disclosures remained sparse at the time of writing.
The dollar figure, reported at roughly $3.2 million, places the event well below the year’s largest incidents but well above the threshold where users notice. More importantly, the wallets and flows affected were ones that users had every reason to associate with Squid: the module bore the protocol’s name, sat in its routing graph, and was reachable through what looked like a Squid transaction. From a user’s vantage point, the trust perimeter was the brand. From the team’s vantage point, the trust perimeter ended several hops earlier.
The interface as an attack surface
The deeper technical observation is that interfaces, not just contracts, can be exploited. A routing protocol that accepts any contract implementing a given function signature has effectively published an open call for integrations. Anyone can deploy a contract that satisfies the interface, name it suggestively, and insert it into user-facing flows through aggregator frontends, third-party UIs, or transaction-construction libraries. The protocol team’s review does not extend to these deployments because, by design, no review is required.
This is the same property that makes ERC-20 tokens composable with every DEX without permission — and the same property that produces the long tail of malicious tokens that look identical to legitimate ones in a wallet UI. The cost of permissionlessness is that the interface becomes the trust boundary, and interfaces are easy to satisfy without being safe.
The “we don’t know who deployed this” problem
The most consequential line from the Squid disclosure was not technical. It was the admission that the team could not identify who had deployed the affected contract. As a piece of crisis communication this lands awkwardly, but as a description of operational reality in modular DeFi it is exact.
There are at least three reasons a core team can lose track of what gets deployed under its umbrella.
The first is the integration partner pattern. Many protocols actively encourage third parties to write adapters that connect to their core. The core team reviews the first wave of these adapters — typically the partners they themselves onboard — and then publishes the interface so that future integrations no longer require their attention. Six months later, contracts written by people the team has never spoken to are routing user funds through the protocol. Some are competent. Some are not. The team’s responsibility for any given module is undefined.
The second is the forked-and-relabeled pattern. A third party takes a known-good module from the core team’s repository, modifies a few lines, and deploys it under a name that includes the protocol’s brand. On-chain, the contract is indistinguishable in spirit from an official module. Off-chain, there is no registry pinning the official deployment addresses to the official commit hashes in a way that user-facing tools enforce. The provenance is recoverable in principle and rarely checked in practice.
The third is the stale-frontend pattern. Aggregators, wallets, and frontends that integrated a protocol months or years ago may still route through deprecated modules or through experimental contracts that the team never intended to be production-facing. The frontend keeps working, the contracts keep accepting calls, and the team learns that the deprecated path was still live only after it gets exploited.
All three patterns share a structural feature: the protocol’s effective surface area, defined as the set of contracts that a reasonable user might invoke while believing they are using the protocol, is strictly larger than the protocol’s audited surface area, and the difference is not tracked by anyone.
Why disclosure is so awkward here
When the gap is exposed by an exploit, the team faces a choice with no clean exit. Claiming responsibility for the third-party module implies a duty of care the team never accepted and cannot scalably provide for every future integration. Disclaiming it, as Squid did, reads to users as deflection — they got hurt on what looked like Squid, and being told it was not really Squid does not make the loss feel less direct.
Neither stance is dishonest. They simply reflect that the legal and reputational categories — “the protocol”, “the team”, “the integration” — do not map cleanly onto the on-chain reality of permissionless module deployment. The honest answer to “whose contract was this?” is often “nobody’s, in the sense you mean”.
A short history of third-party perimeter failures
The Squid incident is recent, but the underlying failure mode has a lineage worth tracing. Across the past several years, a recurring pattern of exploits has hit not the core protocol but adjacent code — modules, adapters, routers, integrations — that sat inside the protocol’s effective trust perimeter while sitting outside its audit perimeter.
Aggregator and router adapters
DEX aggregators present the cleanest analogy. An aggregator’s value comes from supporting many venues, and supporting many venues means writing adapters — small contracts that translate the aggregator’s internal call into the specific calldata each venue expects. Multiple aggregators have suffered losses through bugs in individual adapters, where the core routing logic was sound but a single adapter mishandled token approvals, return values, or refund paths. Users approving the aggregator’s main router were exposed to the worst-behaved adapter in the set, not the average one.
The structural lesson is that approvals are coarse and integrations are fine-grained. Once a user has granted an aggregator allowance over a token, every contract that aggregator can call into becomes part of that token’s threat model.
Vault strategies
Yield vault protocols, particularly during the 2020–2021 cycle and intermittently since, illustrated the same problem in a different dialect. A vault’s “strategy” — the contract that actually deploys deposited capital into external protocols — was often written by an independent strategist, reviewed by a different team than the one that built the vault, and upgraded on a cadence the vault’s depositors did not track. Several incidents in this category involved strategies that interacted with a venue in ways the vault auditors had not modeled, or that trusted oracle paths the vault depositors had not signed up for.
Depositors thought they were using “the vault”. They were using the vault’s strategy. The two were not the same security object.
Bridge executors and post-bridge modules
Cross-chain protocols are particularly exposed because the architecture explicitly demands an extension point. Bridging value without bridging action is, for most users, not useful — the point is to do something on the destination chain. That means a destination-side executor contract, and that executor contract has historically been the soft spot. Several cross-chain exploits over the past two years have targeted the destination-side execution layer rather than the message-passing layer itself, including cases where the core bridge proved sound but the executor’s handling of arbitrary calls allowed an attacker to impersonate a legitimate message origin.
Squid’s incident fits comfortably in this lineage. The router and the message-passing layer were not what failed.
Token approvals as the universal accelerant
Across all of these cases, token approvals function as the accelerant. DeFi UX has trained users to grant unlimited approvals to a known router or aggregator address. Those approvals do not expire and do not distinguish between contracts the team wrote and contracts the team’s contracts can call. An attacker who finds a way to make the trusted contract call into an attacker-controlled module — or who deploys the attacker-controlled module in a way that earns the trusted contract’s call — converts the user’s standing approval into a withdrawal authority. This is true even when no contract the user explicitly interacted with was malicious.
The economics of permissionless modules
It is tempting to read this pattern as a failure of diligence: teams should audit every module, should refuse to expose interfaces they cannot police, should curate their integration partners more carefully. This reading is correct in spirit and incomplete in practice. The economics of modular DeFi push against curation in ways worth naming.
Permissionless composability is not a side effect of these protocols. It is the product. A cross-chain router whose destinations are limited to ten team-approved venues is a worse router, in a strict competitive sense, than one whose destinations are open. A DEX aggregator that turns down adapters because they were written by unknown developers loses execution quality to a competitor that accepts them. A lending market that refuses to list collateral until it has audited the underlying token’s contract concedes the long tail of usage to a market that does not.
Each individual team’s incentives push toward larger interfaces, more permissive integration paths, and looser curation, because the competitive cost of restriction is immediate and the security cost of permissiveness is probabilistic and delayed. The teams that grow fastest are the ones that lean into the open surface area; the ones that survive are the subset of those who get lucky on which modules turn out to matter.
Who is supposed to pay for the review?
A related economic question is who funds module-level security review when the module is deployed by a third party. The core protocol team cannot scalably audit every integration without either charging integrators (which deters them) or absorbing the cost themselves (which scales linearly with integration count while protocol revenue does not). The integrators, particularly the anonymous ones, have little incentive to pay for a thorough audit of a contract they may abandon in three months. Users, who bear the actual loss when something fails, are not in a position to commission audits on contracts they did not know existed.
The result is a public-goods failure in which everyone agrees that more review would be valuable and no one’s individual incentive justifies paying for it. The defaults that emerge — light interface specifications, optional self-attestations, after-the-fact disclosures — reflect this gap rather than fixing it.
Reputation as a leaky substitute
In the absence of formal review, reputation does some of the work. Users learn which aggregators have been around longest, which routing protocols have weathered the most stress, which teams disclose incidents promptly. This is real information but it generalizes poorly: the brand-level reputation of a protocol provides almost no signal about the module-level reputation of any specific integration, especially when the module was deployed after the user formed their view of the brand.
The Squid case is a clean illustration. A user who had concluded, reasonably, that Squid was a competent team running a well-architected router was not wrong about the team or the router. They were exposed to a module whose reputation had nothing to do with either.
Designing for explicit perimeters
If the failure mode is structural, the responses have to be structural too. We are skeptical of solutions that depend on every team adopting better hygiene; the incentive analysis above suggests those will erode at the margins. The more interesting question is what design changes would make the perimeter legible to users and tools without sacrificing the composability that makes the protocols valuable in the first place.
A few directions stand out as worth watching.
The first is module registries with cryptographic provenance: on-chain or off-chain registries that map contract addresses to the commit hash, deployer identity, and audit status of the deployed code, in a form that wallets and aggregators could check before signing a transaction. Several efforts along these lines exist but adoption is partial, and the question of who curates the registry — the core team, an independent body, the integrators themselves — replicates the original responsibility ambiguity at one level of remove.
The second is granular approvals: token approvals scoped not to a router address but to specific call patterns, expiration windows, or destination sets. ERC-7702 and related account-abstraction primitives make this technically more tractable than it was, though the UX of granular approvals has historically been bad enough that users default to the loose version. A path here exists but requires wallet vendors to absorb meaningful complexity for benefits that only materialize during exploits.
The third is explicit trust labeling in user-facing surfaces. Aggregators and frontends could expose, at the moment of transaction construction, which contracts in the path are first-party to the protocol the user thinks they are using, which are third-party, and what is known about each. This is a UI problem more than a contract problem, and it has the merit of meeting users where their mental model already lives — at the brand, not at the bytecode.
The fourth, and least satisfying, is resigned acceptance: an industry-wide acknowledgement that modular DeFi protocols carry a permanent third-party tail risk, that some fraction of incidents will involve contracts no core team will claim, and that user-side defaults — small approvals, frequent revocations, brand-skepticism — have to do more work than they currently do. This is where the industry effectively sits today, and the Squid incident did not move it.
Implications and open questions
The Squid module exploit is small enough that its specific dollar figure will not be remembered for long. The pattern it crystallizes — protocols whose effective trust surface extends beyond what any team has reviewed, and whose response to incidents in that extended surface is necessarily awkward — is durable, and it interacts with several trends worth tracking.
The first is the migration of more protocol logic into intent-based and solver-based architectures, where the executor of any given user intent may be selected dynamically from a competitive set. These designs are powerful and they push the third-party perimeter problem to its logical endpoint: the contract that handles a user’s funds at execution time may not have existed when the user formed their intent. The question of which “protocol” the user was using collapses entirely.
The second is the maturation of on-chain insurance and coverage products. If module-level risk cannot be eliminated by audit, it can in principle be priced. Whether coverage markets can develop the granularity to underwrite individual modules — rather than entire protocols — is an open question, and the answer matters for whether third-party integration ecosystems can scale without their tail risk swamping their utility.
The third is governance and legal precedent. As more incidents involve contracts whose deployers are unknown or anonymous, the implicit social contract that the front-facing team is the responsible party will continue to fray. We expect more disclosures that mirror Squid’s — honest, technically defensible, reputationally damaging — and we expect the distinction between “the protocol” and “the protocol’s perimeter” to become a category that users, regulators, and counterparties learn to read.
What we are watching for, in the months ahead: whether any major modular protocol publishes a formal module-attestation standard that wallets meaningfully enforce; whether the next incident in this category produces a clearer answer to the responsibility question than Squid did; and whether the largest aggregators and routers begin to differentiate themselves on perimeter discipline rather than on integration count. The first protocol to win on the security side of that tradeoff will be worth studying. The conditions under which winning that way becomes commercially viable are not yet in place.
들어가며
크로스체인 스왑 애그리게이터 Squid Router를 운영하는 팀이 2025년 11월 발생한 약 320만 달러 규모의 익스플로잇에 대해 “해당 컨트랙트를 누가 배포했는지 알 수 없다”고 밝혔을 때, 처음에는 책임을 회피하는 발언처럼 들렸다. 그런데 다시 읽어보면 더 낯선 무언가가 느껴진다. 오늘날 DeFi의 상당 부분이 실제로 어떻게 작동하는지를 솔직하게 묘사한 말이라는 것이다.
문제의 컨트랙트는 공식 공개 자료에서 SquidRouterModule로 불렸다. 식별자에는 Squid의 이름이 들어가 있었고, 사용자 입장에서는 당연히 Squid 서비스와 연결된 거래 흐름을 통해 접근할 수 있었다. 그러나 팀의 주장에 따르면 이 컨트랙트는 자신들이 작성하거나 배포하거나 운영한 것이 아니었다. 공식 라우터 바로 옆에 자리 잡은 서드파티 통합 컨트랙트였고, 검토 프로세스는 거치지 않은 채 프로토콜의 명성만 물려받은 셈이었다.
핵심 팀이 관리하는 코드를 훨씬 넘어서는 공격 표면을 가진 프로토콜이라는 이 패턴 자체는 새로운 현상이 아니다. Squid 사건이 드러내는 것은 모듈식 DeFi에서 소유권의 구조적 모호성이다. 즉, 팀이 감사하고 배포하는 컨트랙트, 그것과 조합되는 컨트랙트, 그리고 사용자가 실제로 팀의 브랜드를 믿고 상호작용하는 컨트랙트 사이의 간극이다. 이번 익스플로잇은 역대 사례에 비하면 규모가 작다. 그것이 드러낸 거버넌스 문제는 결코 작지 않다.
이 글에서는 Squid 사건을 출발점으로, 무허가 조합성(permissionless composability)을 전제로 설계된 프로토콜에서 서드파티 모듈이 어떻게 핵심 구성 요소가 되는지, 왜 모듈 경계에서 책임이 증발하는지, 그리고 DeFi 역사의 유사 사례들이 이 실패 패턴의 지속성에 대해 무엇을 시사하는지를 살펴본다.
Squid에 실제로 무슨 일이 있었나
Squid Router는 Axelar의 범용 메시지 전달(General Message Passing)을 활용해 체인 간 스왑과 임의 호출을 라우팅하는 크로스체인 유동성 레이어다. 실질적으로는 조율 레이어 역할을 한다. 사용자가 체인 A에서 스왑을 제출하면, Squid는 체인 A의 DEX 유동성을 통해 라우팅하고 Axelar에 페이로드를 넘긴다. 그러면 체인 B의 대응 컨트랙트가 해당 페이로드를 수신해 목적지 측 로직을 실행한다. 이 목적지 측 로직에서 설계가 열려 있다.
대출 마켓에 예치하거나, LP 포지션을 민팅하거나, 토큰을 스테이킹하거나, 유동성이 낮은 자산으로 스왑하는 등 브릿지 이후의 임의적인 후속 작업을 지원하기 위해, 이 아키텍처는 익스큐터 또는 모듈 컨트랙트로 호출을 전달할 수 있도록 허용한다. 일부 모듈은 Squid 팀이 직접 작성한다. 나머지는 통합 파트너, Squid 목적지로 자신을 노출하고 싶은 프로토콜, 또는 라우팅 인프라가 느슨한 인터페이스를 만족하는 어떤 주소로든 기꺼이 호출을 전달한다는 사실을 발견한 익명 배포자들이 작성한다.
사건 관련 공개 자료에 따르면, 익스플로잇된 컨트랙트는 핵심 라우터가 아닌 이런 인접 모듈 중 하나였다. The Block의 보도는 팀의 입장을 이렇게 정리했다. 해당 모듈은 Squid가 배포한 것이 아니고, 팀은 배포자를 특정할 수 없으며, 운영 책임에 대해서도 선을 그었다. 자금은 모듈이 인바운드 호출을 처리하는 방식의 취약점을 통해 빠져나갔는데, 어떤 내부 함수를 누가 트리거할 수 있는지에 대한 검증이 불충분한 패턴과 대체로 일치하지만, 작성 시점에서 구체적인 기술적 공개는 여전히 부족한 상태다.
약 320만 달러로 보고된 이 사건의 규모는 올해 대형 사고들에 비하면 훨씬 작지만, 사용자들이 인지하는 임계치는 충분히 넘는다. 더 중요한 것은, 피해를 입은 지갑과 거래 흐름이 사용자들이 Squid와 연관 지을 충분한 이유가 있었다는 점이다. 해당 모듈은 프로토콜의 이름을 달고 있었고, 라우팅 그래프 안에 자리 잡고 있었으며, Squid 거래처럼 보이는 것을 통해 접근할 수 있었다. 사용자 입장에서는 브랜드가 신뢰의 경계였다. 팀 입장에서는 신뢰의 경계가 몇 홉 전에 이미 끝나 있었다.
공격 표면으로서의 인터페이스
더 깊은 기술적 시사점은 컨트랙트뿐 아니라 인터페이스 자체도 익스플로잇될 수 있다는 것이다. 특정 함수 시그니처를 구현하는 어떤 컨트랙트든 수락하는 라우팅 프로토콜은 사실상 통합 개방 공모를 게시한 셈이다. 누구든 인터페이스를 만족하는 컨트랙트를 배포하고, 거기에 그럴듯한 이름을 붙이고, 애그리게이터 프런트엔드, 서드파티 UI, 혹은 트랜잭션 구성 라이브러리를 통해 사용자 대면 흐름에 끼워 넣을 수 있다. 프로토콜 팀의 검토는 이런 배포까지 미치지 않는다. 설계 상 검토가 요구되지 않기 때문이다.
이것은 ERC-20 토큰을 허가 없이 모든 DEX와 조합 가능하게 만드는 바로 그 속성이기도 하고, 지갑 UI에서 정상 토큰과 구별할 수 없는 악성 토큰의 롱테일을 만들어내는 바로 그 속성이기도 하다. 무허가성의 대가는 인터페이스가 신뢰 경계가 된다는 것이고, 인터페이스는 안전하지 않아도 쉽게 충족될 수 있다.
”누가 배포했는지 모른다”는 문제
Squid 공개 자료에서 가장 중요한 문장은 기술적인 내용이 아니었다. 팀이 해당 컨트랙트의 배포자를 특정할 수 없다는 인정이었다. 위기 소통의 관점에서는 어색하게 들리지만, 모듈식 DeFi의 운영 현실에 대한 묘사로서는 정확하다.
핵심 팀이 자신의 우산 아래 배포된 것들을 놓치게 되는 이유는 크게 세 가지다.
첫 번째는 통합 파트너 패턴이다. 많은 프로토콜이 서드파티에게 자신의 코어에 연결하는 어댑터를 작성하도록 적극적으로 권장한다. 코어 팀은 처음 물결의 어댑터, 즉 직접 온보딩한 파트너들의 것은 검토한다. 그런 다음 인터페이스를 공개하면 이후 통합에는 더 이상 팀의 관여가 필요 없어진다. 6개월 후, 한 번도 대화해본 적 없는 사람들이 작성한 컨트랙트가 프로토콜을 통해 사용자 자금을 라우팅하고 있다. 일부는 역량이 있고, 일부는 그렇지 않다. 어떤 특정 모듈에 대한 팀의 책임은 정의되어 있지 않다.
두 번째는 포크 후 재라벨링 패턴이다. 서드파티가 코어 팀 저장소에서 검증된 모듈을 가져다 몇 줄 수정하고, 해당 프로토콜 브랜드가 포함된 이름으로 배포한다. 온체인에서는 공식 모듈과 실질적으로 구별이 되지 않는다. 오프체인에서는 공식 배포 주소를 공식 커밋 해시와 연결하는 레지스트리가, 사용자 대면 도구가 실제로 강제하는 방식으로는 존재하지 않는다. 출처는 원칙적으로 확인 가능하지만 실제로는 거의 확인되지 않는다.
세 번째는 낡은 프런트엔드 패턴이다. 몇 달 또는 몇 년 전에 프로토콜을 통합한 애그리게이터, 지갑, 프런트엔드가 여전히 더 이상 사용되지 않는 모듈이나 팀이 프로덕션용으로 의도하지 않았던 실험적 컨트랙트를 통해 라우팅하고 있을 수 있다. 프런트엔드는 계속 작동하고, 컨트랙트는 계속 호출을 받아들이며, 팀은 그 경로가 익스플로잇되고 나서야 비로소 그것이 아직도 살아 있었다는 것을 알게 된다.
세 패턴 모두 하나의 구조적 특성을 공유한다. 프로토콜을 사용한다고 믿는 합리적인 사용자가 호출할 수 있는 컨트랙트 집합으로 정의되는 프로토콜의 실효 표면적은, 프로토콜이 감사한 표면적보다 항상 크며, 그 차이를 아무도 추적하지 않는다.
왜 공시가 이렇게 어색한가
이 간극이 익스플로잇으로 드러나면 팀은 깨끗한 출구가 없는 선택에 직면한다. 서드파티 모듈에 대한 책임을 인정하면 팀이 결코 수용한 적 없고 향후 모든 통합에 대해 확장 가능하게 제공할 수도 없는 주의 의무를 내포하게 된다. Squid가 한 것처럼 책임을 부인하면 사용자들에게는 회피처럼 읽힌다. Squid처럼 보이는 곳에서 피해를 봤는데 사실 Squid가 아니었다는 말이 손실을 덜 직접적으로 느끼게 해주지는 않는다.
어느 입장도 부정직한 것이 아니다. 단지 법적·평판적 범주인 “프로토콜”, “팀”, “통합”이 무허가 모듈 배포라는 온체인 현실에 깔끔하게 대응되지 않는다는 것을 반영할 뿐이다. “이 컨트랙트는 누구 것인가?”라는 질문에 대한 정직한 답은 종종 “당신이 의미하는 의미에서는 아무도의 것도 아니다”이다.
서드파티 경계 실패의 간략한 역사
Squid 사건은 최근 일이지만, 그 기저의 실패 패턴에는 추적할 만한 계보가 있다. 지난 몇 년간 핵심 프로토콜이 아닌 인접 코드, 즉 모듈, 어댑터, 라우터, 통합 컴포넌트를 겨냥한 익스플로잇 패턴이 반복적으로 등장했다. 이들은 프로토콜의 실효 신뢰 경계 안에 있으면서도 감사 경계 밖에 위치해 있었다.
애그리게이터 및 라우터 어댑터
DEX 애그리게이터는 가장 명확한 유사 사례를 제공한다. 애그리게이터의 가치는 많은 거래소를 지원하는 데서 나오고, 많은 거래소를 지원하려면 어댑터, 즉 애그리게이터의 내부 호출을 각 거래소가 기대하는 특정 calldata로 변환하는 작은 컨트랙트들을 작성해야 한다. 여러 애그리게이터가 개별 어댑터의 버그로 손실을 입었는데, 핵심 라우팅 로직은 건전했지만 특정 어댑터 하나가 토큰 승인, 반환값, 또는 환불 경로를 잘못 처리한 경우였다. 애그리게이터의 메인 라우터에 승인을 부여한 사용자는 평균적인 어댑터가 아니라 가장 나쁘게 동작하는 어댑터에 노출된 것이다.
구조적 교훈은 이렇다. 승인은 거칠고, 통합은 세밀하다. 사용자가 특정 토큰에 대해 애그리게이터 허용량을 부여하면, 그 애그리게이터가 호출할 수 있는 모든 컨트랙트가 해당 토큰의 위협 모델의 일부가 된다.
볼트 전략
수익률 볼트 프로토콜, 특히 2020–2021 사이클과 그 이후 간헐적으로, 동일한 문제를 다른 맥락에서 보여줬다. 예치된 자본을 외부 프로토콜에 실제로 배포하는 컨트랙트인 볼트의 “전략(strategy)“은 종종 독립적인 전략가가 작성하고, 볼트를 구축한 팀과는 다른 팀이 검토하며, 볼트 예치자들이 추적하지 않는 일정에 따라 업그레이드되는 경우가 많았다. 이 카테고리의 여러 사건은 전략이 볼트 감사자들이 모델링하지 않은 방식으로 거래소와 상호작용하거나, 볼트 예치자들이 동의하지 않은 오라클 경로를 신뢰하는 경우를 포함했다.
예치자들은 자신이 “볼트”를 사용한다고 생각했다. 실제로는 볼트의 전략을 사용하고 있었다. 둘은 동일한 보안 객체가 아니었다.
브릿지 익스큐터와 브릿지 후 모듈
크로스체인 프로토콜은 아키텍처 자체가 명시적으로 확장 지점을 요구하기 때문에 특히 취약하다. 가치만 브릿징하고 액션은 브릿징하지 않는 것은 대부분의 사용자에게 의미가 없다. 목적지 체인에서 무언가를 하는 것이 목적이기 때문이다. 그것은 목적지 측 익스큐터 컨트랙트를 의미하고, 역사적으로 그 익스큐터 컨트랙트가 취약한 지점이었다. 지난 2년간 여러 크로스체인 익스플로잇이 메시지 전달 레이어가 아닌 목적지 측 실행 레이어를 표적으로 삼았는데, 핵심 브릿지는 건전했지만 임의 호출에 대한 익스큐터의 처리가 공격자로 하여금 합법적인 메시지 출처를 사칭할 수 있게 한 사례도 포함된다.
Squid의 사건은 이 계보에 자연스럽게 들어맞는다. 라우터와 메시지 전달 레이어가 실패한 것이 아니었다.
범용 가속제로서의 토큰 승인
이 모든 사례에서 토큰 승인은 가속제로 작용한다. DeFi UX는 사용자들에게 알려진 라우터나 애그리게이터 주소에 무제한 승인을 부여하도록 훈련시켜왔다. 그 승인은 만료되지 않으며, 팀이 작성한 컨트랙트와 팀의 컨트랙트가 호출할 수 있는 컨트랙트를 구별하지 않는다. 신뢰된 컨트랙트가 공격자가 제어하는 모듈로 호출하도록 만들거나, 신뢰된 컨트랙트의 호출을 받는 방식으로 공격자 제어 모듈을 배포하는 방법을 찾은 공격자는, 사용자의 기존 승인을 출금 권한으로 전환할 수 있다. 이것은 사용자가 명시적으로 상호작용한 컨트랙트 중 어느 것도 악의적이지 않더라도 성립한다.
무허가 모듈의 경제학
이 패턴을 단순한 관리 부실로 읽고 싶은 유혹이 있다. 팀이 모든 모듈을 감사해야 하고, 통제할 수 없는 인터페이스를 노출하지 않아야 하며, 통합 파트너를 더 신중하게 선별해야 한다고. 이 읽기는 방향성은 맞지만 현실적으로는 불완전하다. 모듈식 DeFi의 경제학은 주목할 만한 방식으로 큐레이션에 역행한다.
무허가 조합성은 이 프로토콜들의 부작용이 아니다. 그것이 곧 제품이다. 팀이 승인한 10개 목적지로 제한된 크로스체인 라우터는, 엄밀한 경쟁적 의미에서, 목적지가 개방된 라우터보다 나쁜 라우터다. 미지의 개발자가 작성했다는 이유로 어댑터를 거부하는 DEX 애그리게이터는 그것을 수용하는 경쟁자에게 실행 품질을 내준다. 담보 토큰의 컨트랙트를 감사하기 전까지 상장을 거부하는 대출 마켓은 그렇지 않은 마켓에 롱테일 사용량을 양보한다.
각 팀의 개별적인 인센티브는 더 큰 인터페이스, 더 허용적인 통합 경로, 더 느슨한 큐레이션으로 밀어붙인다. 제한의 경쟁적 비용은 즉각적이고, 허용성의 보안 비용은 확률적이며 지연되기 때문이다. 가장 빨리 성장하는 팀은 개방된 표면적을 적극 수용하는 팀이고, 살아남는 팀은 그 중에서 어떤 모듈이 결정적인 문제를 일으키는지에 대해 운이 좋았던 일부이다.
검토 비용은 누가 부담해야 하나
관련된 경제적 질문은, 모듈이 서드파티에 의해 배포될 때 모듈 수준의 보안 검토 비용을 누가 부담하느냐이다. 핵심 프로토콜 팀은 통합자에게 비용을 청구하거나(이는 통합자를 억제한다) 비용을 자체 흡수하지(이는 통합 수에 비례해 선형으로 증가하지만 프로토콜 수익은 그렇지 않다) 않고서는 모든 통합을 확장 가능하게 감사할 수 없다. 특히 익명 통합자들은 3개월 후 버릴 수도 있는 컨트랙트의 철저한 감사 비용을 지불할 인센티브가 거의 없다. 실제 손실을 부담하는 사용자들은 자신이 존재하는지도 몰랐던 컨트랙트의 감사를 의뢰할 위치에 있지 않다.
결과는 더 많은 검토가 가치 있다는 것을 모두가 동의하지만 개별 인센티브가 그 비용을 정당화하지 않는 공공재 실패다. 기본값으로 등장하는 것들, 가벼운 인터페이스 명세, 선택적 자기 증명, 사후 공시 등은 이 간극을 해결하기보다는 반영하는 데 그친다.
새는 대체재로서의 평판
공식적인 검토 없이도 평판이 일부 역할을 한다. 사용자들은 어떤 애그리게이터가 가장 오래됐는지, 어떤 라우팅 프로토콜이 가장 많은 스트레스를 견뎌냈는지, 어떤 팀이 사건을 신속하게 공시하는지를 학습한다. 이것은 실제 정보지만 일반화가 잘 되지 않는다. 프로토콜의 브랜드 수준 평판은 특정 통합의 모듈 수준 평판에 대해 거의 신호를 제공하지 않으며, 특히 해당 모듈이 사용자가 브랜드에 대한 인식을 형성한 이후에 배포된 경우에는 더욱 그렇다.
Squid 사례는 명확한 예시다. Squid가 잘 설계된 라우터를 운영하는 유능한 팀이라는 합리적인 결론에 도달했던 사용자는 팀이나 라우터에 대해 틀리지 않았다. 그들은 그 어느 쪽의 평판과도 무관한 모듈에 노출되어 있었다.
명시적 경계를 위한 설계
실패 패턴이 구조적이라면 대응도 구조적이어야 한다. 모든 팀이 더 나은 위생 관행을 채택하는 데 의존하는 해결책에 대해 우리는 회의적이다. 앞서의 인센티브 분석은 그런 방식이 결국 한계에서 무너질 것임을 시사한다. 더 흥미로운 질문은 프로토콜을 가치 있게 만드는 조합성을 희생시키지 않으면서도 경계를 사용자와 도구에 가시적으로 만들 수 있는 설계 변화가 무엇이냐는 것이다.
주목할 만한 방향 몇 가지가 있다.
첫 번째는 암호학적 출처를 갖춘 모듈 레지스트리다. 컨트랙트 주소를 배포된 코드의 커밋 해시, 배포자 신원, 감사 상태에 매핑하는 온체인 또는 오프체인 레지스트리로, 지갑과 애그리게이터가 트랜잭션에 서명하기 전에 확인할 수 있는 형태여야 한다. 이 방향의 여러 시도가 존재하지만 채택은 부분적이고, 레지스트리를 누가 큐레이션할 것인가, 즉 핵심 팀인지, 독립 기관인지, 통합자 자신인지 하는 문제는 원래의 책임 모호성을 한 단계 위로 복제할 뿐이다.
두 번째는 세밀한 승인이다. 라우터 주소가 아닌 특정 호출 패턴, 만료 기간, 또는 목적지 집합으로 범위가 지정된 토큰 승인이다. ERC-7702와 관련 계정 추상화 프리미티브는 이것을 기술적으로 더 실현 가능하게 만들지만, 세밀한 승인의 UX는 역사적으로 충분히 나빠서 사용자들이 느슨한 버전을 기본값으로 선택해왔다. 여기에 경로는 있지만, 익스플로잇 중에만 실현되는 이득을 위해 지갑 벤더가 의미 있는 복잡성을 흡수해야 한다.
세 번째는 사용자 대면 인터페이스에서의 명시적 신뢰 라벨링이다. 애그리게이터와 프런트엔드는 트랜잭션 구성 시점에 경로 내 어떤 컨트랙트가 사용자가 사용한다고 생각하는 프로토콜에 대해 퍼스트파티인지, 서드파티인지, 그리고 각각에 대해 알려진 것이 무엇인지를 노출할 수 있다. 이것은 컨트랙트 문제라기보다 UI 문제이며, 사용자의 정신 모델이 이미 있는 곳, 즉 바이트코드가 아닌 브랜드에서 사용자를 만난다는 장점이 있다.
네 번째는 가장 만족스럽지 않은 것으로, 체념한 수용이다. 모듈식 DeFi 프로토콜에는 영구적인 서드파티 꼬리 리스크가 따르고, 일정 비율의 사건은 어떤 핵심 팀도 책임 주장을 않는 컨트랙트를 포함할 것이며, 사용자 측의 기본값, 즉 소액 승인, 잦은 승인 취소, 브랜드 회의주의가 현재보다 더 많은 역할을 해야 한다는 산업 전반의 인식이다. 이것이 오늘날 업계가 실질적으로 위치한 곳이고, Squid 사건은 그것을 바꾸지 못했다.
시사점과 열린 질문들
Squid 모듈 익스플로잇은 규모가 작아 그 구체적인 달러 금액은 오래 기억되지 않을 것이다. 그것이 결정화시키는 패턴, 즉 어떤 팀도 검토하지 않은 부분까지 실효 신뢰 표면이 확장되며 그 확장된 표면에서 발생한 사건에 대한 대응이 필연적으로 어색할 수밖에 없는 프로토콜은 지속적이며, 추적할 가치가 있는 몇 가지 흐름과 맞물린다.
첫 번째는 더 많은 프로토콜 로직이 인텐트 기반 및 솔버 기반 아키텍처로 이동하는 것이다. 여기서는 특정 사용자 인텐트의 익스큐터가 경쟁적인 집합에서 동적으로 선택될 수 있다. 이런 설계는 강력하지만 서드파티 경계 문제를 논리적 극단으로 밀어붙인다. 실행 시점에 사용자의 자금을 처리하는 컨트랙트는 사용자가 인텐트를 형성했을 때 존재하지 않았을 수도 있다. 사용자가 어떤 “프로토콜”을 사용하고 있었느냐는 질문은 완전히 붕괴된다.
두 번째는 온체인 보험 및 커버리지 상품의 성숙이다. 모듈 수준의 리스크가 감사로 제거될 수 없다면, 원칙적으로 가격이 매겨질 수 있다. 커버리지 시장이 전체 프로토콜이 아닌 개별 모듈을 인수할 만큼 세밀해질 수 있는지는 열린 질문이고, 서드파티 통합 생태계가 꼬리 리스크가 효용을 압도하지 않으면서 확장될 수 있는지 여부에 대한 답이 여기에 달려 있다.
세 번째는 거버넌스와 법적 선례다. 더 많은 사건이 배포자가 알 수 없거나 익명인 컨트랙트를 포함하게 되면서, 전면에 드러난 팀이 책임 당사자라는 암묵적인 사회적 계약은 계속 무너질 것이다. 우리는 Squid의 방식, 즉 정직하고 기술적으로는 방어 가능하지만 평판에 손상을 입히는 공시가 더 많아질 것으로 예상하며, “프로토콜”과 “프로토콜의 경계” 사이의 구분이 사용자, 규제당국, 거래상대방이 이해하는 범주가 되어갈 것으로 기대한다.
앞으로 몇 달간 우리가 주목하는 것들은 이렇다. 어떤 주요 모듈식 프로토콜이 지갑이 의미 있게 강제하는 공식 모듈 증명 표준을 발표하는지, 이 카테고리의 다음 사건이 Squid보다 책임 문제에 대한 더 명확한 답을 제시하는지, 그리고 최대 규모의 애그리게이터와 라우터들이 통합 수가 아닌 경계 규율을 기준으로 차별화하기 시작하는지다. 그 트레이드오프의 보안 측면에서 승리하는 첫 번째 프로토콜은 연구할 가치가 있을 것이다. 그런 방식으로 이기는 것이 상업적으로 실행 가능해지는 조건은 아직 마련되어 있지 않다.
はじめに
Axelar上に構築されたクロスチェーンスワップアグリゲーター「Squid Router」の開発チームは、2025年11月に発生した約320万ドルのエクスプロイトに対応する中で、「問題のコントラクトを誰がデプロイしたか分からない」と声明を出した。最初に読んだときは言い逃れのように聞こえるが、もう一度読むと、より奇妙な何かが見えてくる——DeFiの相当部分が実際にどう機能しているかを、正直に言い表した一言なのだ。
問題のコントラクトは、開示文書の中で SquidRouterModule と呼ばれていた。識別子にSquidの名を冠し、ユーザーが合理的にSquidのプロダクトと結びつける取引フローからアクセスできた。しかしチームによれば、このコントラクトを書いたのも、デプロイしたのも、運用したのも彼らではない。公式ルーターと同じ「界隈」に存在し、Squidのブランドとしての信用を引き継ぎながら、そのレビュープロセスは引き継いでいないサードパーティの統合だった。
コアチームが管理するコードをはるかに超えて実効的な攻撃対象領域が広がるプロトコル——このパターン自体は目新しいものではない。Squidのインシデントが可視化しているのは、モジュラーDeFiにおけるオーナーシップの構造的な曖昧さだ。チームが監査・リリースするコントラクト、それらと組み合わさるコントラクト、そしてユーザーが実際にチームのブランドのもとで操作するコントラクト——この三者の間に横たわるギャップである。エクスプロイトの規模は歴史的基準から見れば小さい。それが浮かび上がらせるガバナンスの問題は、決して小さくない。
本稿ではSquidのインシデントを入り口として、パーミッションレスなコンポーザビリティを前提に設計されたプロトコルにおいてサードパーティのモジュールがいかに重要な役割を担うようになるか、モジュールの境界で責任がいかに霧散するか、そしてDeFiの歴史上の類似事例がこの障害パターンの根深さについて何を示唆するかを検討する。
Squidに何が起きたのか
Squid Routerは、AxelarのGeneral Message Passingを用いてチェーン間のスワップや任意の呼び出しをルーティングするクロスチェーン流動性レイヤーだ。実態としてはコーディネーション層であり、ユーザーがチェーンAでスワップを送信すると、SquidはチェーンA上のDEX流動性を経由してルーティングし、Axelarにペイロードを渡す。そしてチェーンB上の対応コントラクトがそのペイロードを受け取り、デスティネーション側のロジックを実行する。このデスティネーション側のロジックこそ、設計が開かれている部分だ。
ブリッジ後の任意のアクション——レンディングマーケットへの預け入れ、LPポジションのミント、トークンのステーキング、流動性の低いトークンへのスワップなど——をサポートするため、このアーキテクチャはエグゼキューターコントラクトやモジュールコントラクトへの呼び出しを許容する。一部のモジュールはSquidチームが書いたものだが、その他は統合パートナー、Squidのデスティネーションとして自らを公開したいプロトコル、あるいはルーティングインフラが緩いインターフェースを満たす任意のアドレスへ喜んで呼び出しを転送することを発見した匿名のデプロイヤーによって書かれたものだ。
インシデントに関する公開開示によれば、エクスプロイトされたコントラクトはコアルーターではなく、こうした周辺モジュールの一つだった。The Blockによる報道はチームの立場を以下のようにまとめている——そのモジュールはSquidがデプロイしたものではなく、チームはデプロイヤーを特定できず、その運用責任を否定した。資金は、モジュールがインバウンドコールを処理する方法の欠陥を通じて流出した。これはどの内部関数を誰がトリガーできるかの検証が不十分というパターンと大筋で合致するが、執筆時点では具体的な技術的開示は限られていた。
約320万ドルと報告されたこの損失額は、その年の最大規模のインシデントを大幅に下回るが、ユーザーの目に留まる閾値は十分に超えている。さらに重要なのは、影響を受けたウォレットとフローが、ユーザーがSquidに関連付けるものとして当然視していたものだったという点だ。そのモジュールはプロトコルの名を冠し、ルーティンググラフ内に位置し、Squidのトランザクションに見えるものを通じてアクセスできた。ユーザーの視点からすれば、信頼の境界はブランドだった。チームの視点からすれば、信頼の境界は数ホップ手前で終わっていた。
攻撃対象としてのインターフェース
より深い技術的洞察は、コントラクトだけでなくインターフェース自体もエクスプロイトされうるという点だ。特定の関数シグネチャを実装した任意のコントラクトを受け入れるルーティングプロトコルは、事実上、統合のオープンコールを公開していることになる。誰でもインターフェースを満たすコントラクトをデプロイし、示唆的な名前を付け、アグリゲーターのフロントエンド、サードパーティのUI、あるいはトランザクション構築ライブラリを通じてユーザー向けのフローに組み込むことができる。プロトコルチームのレビューはこうしたデプロイには及ばない——設計上、レビューは不要とされているからだ。
これはERC-20トークンが許可なくあらゆるDEXとコンポーザブルになるのと同じ特性であり、ウォレットのUIでは正規のものと見分けがつかない悪意あるトークンの長いテールを生み出す同じ特性でもある。パーミッションレスのコストは、インターフェースが信頼の境界となることだ。そしてインターフェースは、安全でなくても容易に満たすことができる。
「誰がデプロイしたか分からない」という問題
Squidの開示文書で最も重要だったのは、技術的な内容ではなかった。問題のコントラクトを誰がデプロイしたか特定できないという告白だ。危機対応のコミュニケーションとしては不格好だが、モジュラーDeFiの運用的現実の記述としては正確だ。
コアチームが傘下にデプロイされたものを把握できなくなる理由は、少なくとも三つある。
一つ目は統合パートナーパターンだ。多くのプロトコルはサードパーティがコアに接続するアダプターを書くことを積極的に奨励している。コアチームは最初の波のアダプター——通常は自らオンボーディングするパートナーのもの——をレビューし、その後はインターフェースを公開することで、将来の統合には自分たちの手が不要になるようにする。半年後には、チームが一度も話したことのない人々が書いたコントラクトが、プロトコルを通じてユーザーの資金をルーティングしている。その中には能力のある者もいれば、そうでない者もいる。特定のモジュールに対するチームの責任は、定義されていない。
二つ目はフォーク＆リラベルパターンだ。サードパーティがコアチームのリポジトリから既知の安全なモジュールを取り、数行を修正し、プロトコルのブランドを含む名前でデプロイする。オンチェーンでは、このコントラクトは精神的に公式モジュールと区別がつかない。オフチェーンでは、公式のデプロイアドレスと公式のコミットハッシュを対応付けるレジストリが、ユーザー向けツールに強制される形では存在しない。出所は原則として追跡可能だが、実際にはほとんど確認されない。
三つ目は古いフロントエンドパターンだ。数ヶ月または数年前にプロトコルを統合したアグリゲーター、ウォレット、フロントエンドは、廃止されたモジュールや、チームが本番向けと意図していなかった試験的なコントラクトを通じて、いまだにルーティングを行っている場合がある。フロントエンドは動き続け、コントラクトは呼び出しを受け続け、チームは廃止されたパスがまだ稼働していたことを、エクスプロイトされて初めて知る。
これら三つのパターンに共通する構造的特徴がある。プロトコルの実効的な対象領域——合理的なユーザーがそのプロトコルを使っていると信じながら呼び出す可能性のあるコントラクトの集合——は、プロトコルの監査済み対象領域を明確に上回っており、その差分は誰も追跡していない。
なぜ開示がこれほど難しいのか
このギャップがエクスプロイトによって露わになったとき、チームはどこにも出口のない選択を迫られる。サードパーティのモジュールに対して責任を認めることは、チームが受け入れたことのない、そして将来のあらゆる統合に対してスケーラブルに提供できない注意義務を暗示する。Squidが行ったように責任を否定することは、ユーザーの目には言い逃れに映る——Squidに見えたもので損害を受けたのに、「実はSquidではなかった」と言われても、損失の痛みは変わらない。
どちらの立場も不誠実ではない。単に、「プロトコル」「チーム」「統合」という法的・評判上のカテゴリーが、パーミッションレスなモジュールデプロイというオンチェーンの現実にきれいに対応していないことを反映しているだけだ。「これは誰のコントラクトだったのか」という問いへの正直な答えは、しばしば「あなたが意味する意味での、誰のものでもない」となる。
サードパーティの境界障害の小史
Squidのインシデントは最近のことだが、その根底にある障害パターンには追う価値のある系譜がある。過去数年間、コアプロトコルではなく、その周辺のコード——モジュール、アダプター、ルーター、統合——を標的にしたエクスプロイトが繰り返されてきた。それらはプロトコルの実効的な信頼境界の内側にありながら、監査境界の外側に位置していた。
アグリゲーターとルーターのアダプター
DEXアグリゲーターは最も分かりやすいアナロジーを提供する。アグリゲーターの価値は多くのベニューをサポートすることにあり、多くのベニューをサポートするためにはアダプターを書く必要がある——アグリゲーター内部の呼び出しを各ベニューが期待する具体的なcalldataに変換する小さなコントラクトだ。複数のアグリゲーターが個々のアダプターのバグによって損失を被っており、コアのルーティングロジックは健全だったが、単一のアダプターがトークンのアプルーバル、戻り値、または払い戻しパスを誤って処理していた。アグリゲーターのメインルーターを承認したユーザーは、セット内の平均的なアダプターではなく、最も問題のあるアダプターにさらされていた。
構造的な教訓は、アプルーバルは粗く、統合は細かいということだ。ユーザーが一度アグリゲーターにトークンのアローワンスを付与すると、そのアグリゲーターが呼び出せるすべてのコントラクトがそのトークンの脅威モデルの一部となる。
ボールトのストラテジー
利回りボールトプロトコル——特に2020〜2021年のサイクルとその後の断続的な期間——は、同じ問題を別の文脈で示した。ボールトの「ストラテジー」——実際に預け入れた資金を外部プロトコルにデプロイするコントラクト——は、多くの場合、独立したストラテジストによって書かれ、ボールトを構築したチームとは異なるチームによってレビューされ、ボールトの預け入れ者が追跡していないサイクルでアップグレードされていた。このカテゴリのいくつかのインシデントでは、ボールトの監査担当者がモデル化していない方法でベニューとやり取りするストラテジー、またはボールトの預け入れ者が承諾していないオラクルパスを信頼するストラテジーが関与していた。
預け入れ者は「ボールト」を使っていると思っていた。実際に使っていたのはボールトのストラテジーだった。この二つは同一のセキュリティオブジェクトではない。
ブリッジのエグゼキューターとブリッジ後のモジュール
クロスチェーンプロトコルは、アーキテクチャが明示的に拡張ポイントを要求するため、特に脆弱だ。価値をブリッジするだけでアクションをブリッジしないのは、ほとんどのユーザーにとって有用ではない——目的はデスティネーションチェーン上で何かをすることだ。つまり、デスティネーション側のエグゼキューターコントラクトが必要であり、そのエグゼキューターコントラクトは歴史的に弱点となってきた。過去2年間のいくつかのクロスチェーンエクスプロイトは、メッセージパッシングレイヤーではなく、デスティネーション側の実行レイヤーを標的にしていた。コアのブリッジは健全だったが、エグゼキューターの任意の呼び出し処理が、攻撃者に正当なメッセージ発信源を偽装することを可能にした事例も含む。
Squidのインシデントはこの系譜の中に自然に収まる。失敗したのはルーターでもメッセージパッシングレイヤーでもなかった。
普遍的な促進剤としてのトークンアプルーバル
これらすべてのケースにおいて、トークンアプルーバルが促進剤として機能する。DeFiのUXは、ユーザーが既知のルーターやアグリゲーターのアドレスに無制限のアプルーバルを付与するよう訓練してきた。これらのアプルーバルは期限切れにならず、チームが書いたコントラクトとチームのコントラクトが呼び出せるコントラクトを区別しない。信頼されたコントラクトを攻撃者がコントロールするモジュールに呼び出させる方法を見つけた攻撃者——あるいは信頼されたコントラクトの呼び出しを得られる形で攻撃者がコントロールするモジュールをデプロイした攻撃者——は、ユーザーの既存のアプルーバルを引き出し権限に変換する。これはユーザーが明示的に操作したコントラクトの中に悪意のあるものがなかった場合でも当てはまる。
パーミッションレスモジュールの経済学
このパターンをデューデリジェンスの失敗として読みたい誘惑がある——チームはすべてのモジュールを監査すべきだ、統制できないインターフェースを公開すべきではない、統合パートナーをより慎重に選別すべきだ、と。この読み方は精神的には正しいが、実態として不完全だ。モジュラーDeFiの経済学は、明示すべき理由でキュレーションに反する方向に押し進める。
パーミッションレスなコンポーザビリティは、これらのプロトコルの副作用ではない。それが製品なのだ。デスティネーションがチームが承認した10のベニューに限定されるクロスチェーンルーターは、厳密な競争的意味においてデスティネーションがオープンなものより劣るルーターだ。未知の開発者が書いたという理由でアダプターを断るDEXアグリゲーターは、それを受け入れる競合他社に対して約定品質で負ける。担保となるトークンのコントラクトを監査するまでリストを拒否するレンディングマーケットは、そうしない市場に長いテールの利用を譲り渡す。
個々のチームのインセンティブはいずれも、より大きなインターフェース、より寛容な統合パス、より緩いキュレーションへと向かう。なぜなら制限の競争コストは即座であり、寛容さのセキュリティコストは確率論的で遅延しているからだ。最も速く成長するチームはオープンな対象領域に傾くチームであり、生き残るのはその中でどのモジュールが重要かについて運に恵まれたサブセットだ。
レビューの費用は誰が負担するのか
関連する経済的問題は、モジュールがサードパーティによってデプロイされた場合、モジュールレベルのセキュリティレビューを誰が資金提供するかだ。コアプロトコルチームは、統合者に課金するか（それは彼らを遠ざける）、コスト自体を吸収するか（それは統合数に比例してスケールするがプロトコル収益はそうではない）のいずれかなしには、すべての統合を拡張的に監査することができない。統合者、特に匿名のものは、3ヶ月後に放棄するかもしれないコントラクトの徹底した監査に費用を払うインセンティブがほとんどない。何かが失敗したときに実際の損失を負担するユーザーは、自分が存在を知らなかったコントラクトの監査を委託できる立場にない。
結果として、より多くのレビューが価値があることに誰もが同意しながら、誰の個別インセンティブもその費用を支払うことを正当化しないという公共財の失敗が生じる。それを補うものとして現れるデフォルト——軽いインターフェース仕様、任意の自己証明、事後の開示——はこのギャップを反映しているのであって、修正しているのではない。
漏れの多い代替としての評判
正式なレビューがない状況では、評判がその役割の一部を担う。ユーザーは、どのアグリゲーターが最も長く存在しているか、どのルーティングプロトコルが最もストレスに耐えてきたか、どのチームがインシデントを迅速に開示するかを学ぶ。これは実際の情報だが、一般化が難しい。プロトコルのブランドレベルの評判は、特定の統合のモジュールレベルの評判についてほとんど何のシグナルも与えない——特にそのモジュールがユーザーがブランドに対する見解を形成した後にデプロイされた場合はなおさらだ。
Squidのケースは明確な例示だ。Squidが有能なチームによって適切に設計されたルーターを運営していると——合理的に——結論付けたユーザーは、チームについてもルーターについても間違っていなかった。彼らはどちらとも評判上の関係のないモジュールにさらされていたのだ。
明示的な境界の設計
障害パターンが構造的であれば、対応も構造的でなければならない。すべてのチームがより良い衛生管理を採用することに依存するソリューションには懐疑的だ——上記のインセンティブ分析はそれらが周辺で崩れることを示唆している。より興味深い問いは、プロトコルを価値あるものにするコンポーザビリティを犠牲にすることなく、境界をユーザーやツールにとって可視化するためにどのような設計変更が必要かだ。
注目に値するいくつかの方向性が浮かび上がる。
一つ目は暗号学的な出所を持つモジュールレジストリだ——コントラクトアドレスをデプロイされたコードのコミットハッシュ、デプロイヤーの身元、監査状況にマッピングするオンチェーンまたはオフチェーンのレジストリで、ウォレットやアグリゲーターがトランザクションに署名する前に確認できる形式のもの。この方向のいくつかの取り組みは存在するが採用は部分的であり、レジストリを誰が管理するか——コアチーム、独立した団体、統合者自身——という問いが、元の責任の曖昧さを一段階上のレベルで再現する。
二つ目は細粒度のアプルーバルだ——ルーターアドレスではなく、特定のコールパターン、有効期限、またはデスティネーションセットにスコープされたトークンアプルーバルだ。ERC-7702と関連するアカウントアブストラクションのプリミティブは、以前よりも技術的に実現しやすくしているが、細粒度のアプルーバルのUXは歴史的に十分悪く、ユーザーは緩いバージョンをデフォルトとしてきた。ここに道は存在するが、エクスプロイト時にしか現れない恩恵のために、ウォレットベンダーが相当な複雑さを吸収することが必要だ。
三つ目はユーザー向けサーフェスでの明示的な信頼ラベリングだ。アグリゲーターとフロントエンドは、トランザクション構築の瞬間に、パス内のどのコントラクトがユーザーが使っていると思っているプロトコルにとってファーストパーティか、どれがサードパーティか、そして各々について何が分かっているかを公開できる。これはコントラクトの問題というよりUIの問題であり、ユーザーのメンタルモデルがすでに存在する場所——バイトコードではなくブランド——においてユーザーに会うという利点がある。
四つ目は、最も満足のいかない方法として、諦めの受容だ——モジュラーDeFiプロトコルは永続的なサードパーティのテールリスクを抱えており、インシデントの一定割合はいかなるコアチームも主張しないコントラクトを含むことになり、ユーザー側のデフォルト——小さなアプルーバル、頻繁な失効、ブランドへの懐疑——が現状よりも多くの仕事をしなければならないという業界全体での認識だ。これが今日、業界が実質的に置かれている場所であり、Squidのインシデントはそれを動かさなかった。
含意と未解決の問い
Squidのモジュールエクスプロイトは、その具体的なドル金額が長く記憶されるには小さすぎる。それが結晶化するパターン——実効的な信頼サーフェスがいかなるチームも検討したものを超えて広がり、その拡張されたサーフェスにおけるインシデントへの対応が必然的に難しくなるプロトコル——は持続的であり、追跡する価値のあるいくつかのトレンドと相互作用する。
一つ目は、より多くのプロトコルロジックがインテントベースおよびソルバーベースのアーキテクチャに移行していることだ。そこでは特定のユーザーインテントのエグゼキューターが競争的なセットから動的に選択される場合がある。これらの設計は強力であり、サードパーティの境界問題を論理的な終点まで押し進める——実行時にユーザーの資金を扱うコントラクトは、ユーザーがインテントを形成した時点では存在していなかった可能性がある。ユーザーがどの「プロトコル」を使っていたかという問いは完全に崩壊する。
二つ目は、オンチェーン保険とカバレッジプロダクトの成熟だ。モジュールレベルのリスクが監査によって排除できないなら、原則として価格付けができる。カバレッジマーケットがプロトコル全体ではなく個々のモジュールを引き受けるほどの細粒度を発展させられるかどうかは未解決の問いであり、その答えはサードパーティ統合のエコシステムがテールリスクがユーティリティを圧倒することなくスケールできるかどうかに関わる。
三つ目はガバナンスと法的前例だ。デプロイヤーが不明または匿名のコントラクトを含むインシデントが増えるにつれて、フロントに立つチームが責任ある当事者であるという暗黙の社会契約は崩れ続けるだろう。Squidと同様の開示——正直で、技術的に弁護可能で、評判上は損害を与える——がより多く出てくることを予想しており、「プロトコル」と「プロトコルの境界」の区別が、ユーザー、規制当局、カウンターパーティが読み解くことを学ぶカテゴリとなることを予想している。
今後数ヶ月で注目していること：主要なモジュラープロトコルのいずれかが、ウォレットが意味のある形で強制するフォーマルなモジュール証明標準を公開するかどうか；このカテゴリの次のインシデントがSquidよりも責任の問いに対する明確な答えをもたらすかどうか；そして最大のアグリゲーターとルーターが統合数ではなく境界の規律で差別化を始めるかどうか。そのトレードオフのセキュリティ側で勝つ最初のプロトコルは研究する価値があるだろう。その方法で勝つことが商業的に実現可能になる条件は、まだ整っていない。
引言
2025年11月，跨链聚合协议Squid Router遭遇一起约320万美元的漏洞攻击。Squid Router构建在Axelar之上，事后团队回应称他们并不知道被攻击的合约是由谁部署的。这句话乍听之下像是在推诿，但细想之后却透露出另一种更奇特的意味——这是对当下相当一部分DeFi运作方式的如实描述。
这份披露中提到的合约被称为SquidRouterModule，其标识符带有Squid的名字，用户通过正常的交易流程完全可能触达它，也有充分理由将其与Squid产品关联起来。然而据团队所说，这份合约并非他们编写、部署或运营的，而是一个第三方集成——它毗邻官方路由器而存在，承接了部分品牌信誉，却未经历与官方产品相同的审查流程。
这种模式并不新鲜——协议的实际攻击面远超核心团队所维护代码的范围。Squid事件让一个结构性的模糊问题变得清晰可见：在模块化DeFi中，“所有权”究竟意味着什么？团队审计并上线的合约、与之组合的合约、以及用户在品牌认知下实际交互的合约——这三者之间存在明显的裂缝。此次漏洞所造成的损失，以历史标准衡量并不算大，但它所揭示的治理问题却不容小觑。
我们以Squid事件为切入点，探讨以下几个问题：在无需许可的可组合性设计中，第三方模块是如何成为承重结构的？为什么责任往往在模块边界处消散？DeFi历史上类似案例又说明了什么——这一失效模式是否具有持久性？
Squid事件的来龙去脉
Squid Router是一个跨链流动性层，借助Axelar的通用消息传递（General Message Passing）在不同链之间路由兑换和任意调用。它本质上是一个协调层：用户在链A发起兑换，Squid在链A通过DEX流动性完成路由，将消息载荷交给Axelar，再由链B上的对应合约接收并执行目标端逻辑。而这个目标端逻辑，正是整个架构向外敞开的地方。
为了支持跨链后的任意操作——存入借贷市场、铸造LP仓位、质押代币、兑换成流动性较差的资产等——该架构允许将调用分发给执行器或模块合约。其中一些模块由Squid团队编写，另一些则来自集成伙伴、希望将自己暴露为Squid目标端的协议，或是匿名部署者——他们发现这套路由基础设施会将调用愉快地转发给任何满足宽泛接口的地址。
根据事件披露，被攻击的合约正是这类外围模块，而非核心路由器。The Block的报道总结了团队立场：该模块并非Squid部署，团队无法确认部署者身份，并明确与其划清了运营责任的界限。攻击者通过模块处理入站调用的缺陷完成了资金窃取——这一模式与内部函数调用权限校验不足高度吻合，但撰写本文时，具体技术细节披露仍然有限。
此次损失约为320万美元，远低于年度最大事件的规模，但已足够让用户察觉。更关键的是，受影响的钱包和交易流程完全在用户的Squid认知范围之内：该模块带着协议的名字，处于其路由图中，且可以通过看似正常的Squid交易触达。从用户视角看，信任边界就是品牌；而从团队视角看，信任边界早在几跳之前就已结束。
接口即攻击面
更深层的技术观察是：被利用的不仅是合约，还有接口本身。一个接受任何实现了特定函数签名的合约的路由协议，实际上是在公开征集集成。任何人都可以部署一个满足该接口的合约，起一个具有暗示性的名字，再通过聚合器前端、第三方UI或交易构建库将其插入用户可见的流程。协议团队的审查不会覆盖这些部署，因为按照设计，这里根本不需要审查。
这一属性与ERC-20代币无需许可便可与所有DEX组合的特性如出一辙——同样也是那一长串恶意代币在钱包UI中与合法代币看起来毫无区别的根源。无需许可的代价，是接口成为信任边界，而接口很容易被满足，却未必安全。
“我们不知道是谁部署的”
Squid披露中最关键的一句话并非技术性的，而是团队承认无法确认被攻击合约的部署者。作为危机公关，这句话颇显尴尬；但作为对模块化DeFi运营现实的描述，它却分毫不差。
核心团队对伞下部署物失去追踪，至少有三个原因。
第一是集成伙伴模式。许多协议会积极鼓励第三方编写适配器接入核心协议。核心团队会审查第一批适配器——通常是他们自己引入的合作伙伴——然后公开接口，让未来的集成不再需要他们介入。六个月后，素未谋面的人编写的合约正在通过该协议路由用户资金。有些写得好，有些则不然。团队对任一模块的责任范围，始终模糊不清。
第二是分叉改标模式。第三方从核心团队的代码库中取出一个已知可用的模块，修改几行代码，然后以包含协议品牌的名称部署。链上看，这份合约在精神上与官方模块无法区分。链下，没有任何注册表以用户工具强制执行的方式，将官方部署地址与官方提交哈希绑定在一起。溯源在理论上可行，在实践中却鲜少被核查。
第三是前端过时模式。在数月或数年前就集成了某协议的聚合器、钱包和前端，可能仍在通过已弃用的模块，或团队从未打算投入生产的实验性合约进行路由。前端照常运转，合约照常接受调用，团队往往要等到被攻击之后，才发现那条被废弃的路径依然活跃。
三种模式共享一个结构性特征：协议的实际攻击面——即合理用户在认为自己使用该协议时可能触达的合约集合——严格大于协议已审计的攻击面，而这一差值无人追踪。
为何披露如此两难
当这道裂缝因漏洞而暴露，团队便陷入进退两难的困境。如果承认对第三方模块负责，则意味着承担一项他们从未接受、也无法为每一个未来集成提供的注意义务。如果像Squid那样撇清关系，在用户眼中则是推卸——他们在看起来是Squid的地方受了损失，被告知”那其实不是Squid”并不能让损失感觉减轻一分。
两种立场都不算不诚实，它们只是反映出一个现实：法律与声誉意义上的分类——“协议”、“团队”、“集成”——与无需许可的模块部署所构成的链上现实之间，并不存在清晰的映射关系。对于”这是谁的合约”，诚实的答案往往是”按照你所理解的意思，没有人的”。
第三方边界失效的简史
Squid事件是近期发生的，但其底层失效模式有一条值得梳理的传承脉络。过去数年间，有一类漏洞反复出现——被攻击的不是核心协议，而是周边代码：模块、适配器、路由器、集成——它们处于协议有效信任边界之内，却游离于审计边界之外。
聚合器与路由适配器
DEX聚合器提供了最清晰的类比。聚合器的价值来自于支持众多交易场所，而支持众多交易场所意味着编写适配器——将聚合器内部调用翻译成各场所所需特定calldata的小型合约。多个聚合器曾因单个适配器中的漏洞而遭受损失，核心路由逻辑完好无损，却因某个适配器在代币授权、返回值或退款路径上的处理失误而酿成事故。授权了聚合器主路由器的用户，实际上暴露在该聚合器所有适配器中最脆弱的那一个之下，而非平均水平之下。
结构性教训是：授权是粗粒度的，集成是细粒度的。一旦用户授予了聚合器对某代币的授权，该聚合器能够调入的每一份合约，都已成为那枚代币威胁模型的一部分。
金库策略
收益金库协议——尤其是在2020至2021年周期及此后的零星时期——用另一种语言呈现了同样的问题。金库的”策略”——实际将存入资金部署到外部协议的合约——往往由独立策略师编写，由与金库构建团队不同的团队审查，并以金库存款人并不知晓的节奏升级。这一类别的多起事件涉及策略与交易场所的交互方式，是金库审计人员未曾建模的，或是金库存款人从未预期的预言机路径所致。
存款人以为自己在使用”金库”，实际上用的是金库的策略。两者并不是同一个安全对象。
桥执行器与跨链后模块
跨链协议尤为脆弱，因为其架构本身就明确需要扩展点。对大多数用户而言，单纯跨链传值而不跨链传递动作是没有意义的——重点在于在目标链上执行某些操作。这意味着必须有一个目标端执行器合约，而该执行器合约历来是薄弱环节。过去两年间，数起跨链攻击都将目标锁定在目标端执行层，而非消息传递层本身——其中包括核心桥完好无损、但执行器对任意调用的处理方式允许攻击者冒充合法消息来源的案例。
Squid事件与这一谱系高度契合。失败的并非路由器，也并非消息传递层。
代币授权：无处不在的助燃剂
纵观上述所有案例，代币授权都扮演着助燃剂的角色。DeFi的用户习惯已将人们训练成向已知路由器或聚合器地址授予无限额度。这些授权不会过期，也不区分团队编写的合约与团队合约能够调用的合约。攻击者一旦找到方法让受信合约调用攻击者控制的模块——或将攻击者控制的模块部署成能够获得受信合约调用的形式——便可将用户的已有授权转化为提款权限。即便用户明确交互过的所有合约都并非恶意，这一点同样成立。
无需许可模块的经济逻辑
面对这一模式，人们很容易将其解读为尽职调查的失败：团队应该审计每一个模块，应该拒绝暴露无法监管的接口，应该更审慎地筛选集成伙伴。这种解读精神上没有错，实践中却不够完整。模块化DeFi的经济逻辑在多个层面制约着策展行为，这些制约值得正视。
无需许可的可组合性并非这些协议的副作用，而是产品本身。一个目标地址仅限于十个团队批准场所的跨链路由器，在严格的竞争意义上，是不如开放目标地址的路由器的。一个因适配器开发者身份不明而拒绝接入的DEX聚合器，会在执行质量上输给接受它们的竞争对手。一个拒绝上线抵押品、直到审计完底层代币合约才肯开放的借贷市场，会把长尾用量拱手相让给不做这种要求的市场。
每个团队的个体激励都指向更大的接口、更宽松的集成路径、更低的筛选门槛——因为限制的竞争代价是即时的，而宽松的安全代价是概率性的、滞后的。成长最快的团队是那些全力拥抱开放攻击面的团队；最终存活下来的，则是其中恰好在关键模块上运气不差的那一部分。
谁来为审查买单？
与此相关的另一个经济问题是：当模块由第三方部署时，模块级安全审查的费用由谁承担？核心协议团队无法对每一个集成进行可扩展的审计，除非向集成方收费（这会令人望而却步），或自行承担成本（这将随着集成数量线性增长，而协议收入却未必如此）。集成方，尤其是匿名的那些，几乎没有动力为一份可能三个月后就放弃的合约支付详尽审计的费用。用户——在出问题时承担实际损失的人——根本无从委托对他们不知道存在的合约进行审计。
结果是一场公共品失败：所有人都认同更多审查是有价值的，但没有任何个体有足够的激励去为此买单。由此产生的默认状态——宽泛的接口规范、可选的自我声明、事后的信息披露——反映的是这道裂缝，而非对它的修复。
声誉：一个漏水的替代品
在缺乏正式审查的情况下，声誉承担了一部分职能。用户会留意哪些聚合器资历最深、哪些路由协议经历了最多考验、哪些团队在事件发生后能够及时披露。这是真实的信息，但它的泛化能力很差：协议的品牌级声誉，对于任何特定集成的模块级声誉而言，几乎不提供任何信号——尤其是当该模块是在用户建立品牌认知之后才部署的。
Squid案例是一个清晰的例证。一个合理地认为Squid是一支能力出众、架构严谨的团队所运营的优质路由器的用户，对该团队和该路由器的判断并没有错。他们暴露于一个其声誉与团队和路由器毫无关联的模块之下。
为显式边界而设计
如果失效模式是结构性的，应对措施也必须是结构性的。我们对那些依赖每个团队自我改进卫生习惯的解决方案持怀疑态度——上文的激励分析表明，这类方案会在边际处不断侵蚀。更有趣的问题是：哪些设计变革能够在不牺牲协议核心价值——可组合性——的前提下，让用户和工具对边界有清晰的认知？
有几个方向值得持续关注。
其一是具有密码学溯源的模块注册表：链上或链下注册表，将合约地址映射到所部署代码的提交哈希、部署者身份和审计状态，并以一种钱包和聚合器在签署交易前可以核查的形式呈现。这一方向已有若干尝试，但采用程度参差不齐，且谁来策管注册表——核心团队、独立机构还是集成方自身——这个问题在更高一层复现了原有的责任模糊。
其二是细粒度授权：代币授权的范围不再是一个路由器地址，而是限定于特定调用模式、有效期窗口或目标地址集合。ERC-7702及相关账户抽象原语使这在技术上比以往更为可行，尽管细粒度授权的用户体验历来糟糕到用户默认选择宽泛版本。通往这一目标的路径存在，但需要钱包厂商承担相当的复杂度——而这些复杂度的收益只在遭遇攻击时才会显现。
其三是在用户界面中明确标注信任等级。聚合器和前端可以在交易构建的当下，向用户展示路径中哪些合约属于用户认为自己在使用的协议的第一方，哪些是第三方，以及关于各合约的已知信息。这更多是一个UI问题而非合约问题，其优点在于契合用户现有的心智模型——用户的信任落脚点是品牌，而非字节码。
其四，也是最不令人满意的方向，是坦然接受：行业层面承认模块化DeFi协议永久携带第三方尾部风险，部分事件将涉及任何核心团队都不会认领的合约，用户侧的默认行为——小额授权、频繁撤销、对品牌保持审慎——需要承担比现在更多的责任。这实际上就是当下行业所处的位置，而Squid事件并未改变这一现状。
启示与开放性问题
Squid模块漏洞的金额规模不大，其具体数字不会被记住太久。但它所凝结的模式——协议的有效信任面超出任何团队已审查范围，而对该延伸面上事件的回应必然陷入两难——具有持久性，并与几个值得追踪的趋势相互交织。
其一是越来越多的协议逻辑向基于意图和基于求解器的架构迁移，在这类架构中，执行任何特定用户意图的执行者可能是从竞争性集合中动态选出的。这些设计极具潜力，却将第三方边界问题推向了其逻辑终点：在执行时刻处理用户资金的合约，可能在用户表达意图时根本还不存在。“用户使用的是哪个协议”这一问题，在此处将彻底坍缩。
其二是链上保险和覆盖产品的成熟。如果模块级风险无法通过审计消除，那么理论上可以为其定价。承保市场能否发展出足够的粒度，对单个模块而非整个协议进行承保，目前尚无定论。而这一问题的答案，将决定第三方集成生态能否在不让尾部风险淹没其价值的前提下实现规模化。
其三是治理与法律先例。随着越来越多的事件涉及部署者身份不明或匿名的合约，面向用户的团队是责任主体这一隐性社会契约将持续松动。我们预计会出现更多与Squid类似的披露——诚实、技术上站得住脚、声誉上损失惨重——“协议”与”协议边界”之间的区分，将成为用户、监管机构和交易对手逐渐学会识别的一个类别。
在未来数月，我们将持续关注：是否有主要模块化协议发布一套有意义地被钱包强制执行的正式模块声明标准；这一类别的下一次事件能否给出比Squid更清晰的责任认定；以及最大的聚合器和路由器是否开始以边界规范而非集成数量来建立差异化竞争优势。第一个在安全维度上赢得这场权衡的协议，将值得深入研究。但支撑这种赢法在商业上可行的条件，目前尚未成形。
Introducción
Cuando el equipo detrás de Squid Router —un agregador de swaps entre cadenas construido sobre Axelar— respondió a un exploit de aproximadamente 3,2 millones de dólares en noviembre de 2025 diciendo que no sabían quién había desplegado el contrato afectado, la declaración sonó evasiva a primera vista. A segunda lectura resultó algo más extraño: una descripción honesta de cómo funciona hoy una parte significativa del DeFi.
El contrato en cuestión, referido en las divulgaciones como SquidRouterModule, llevaba el nombre de Squid en su identificador y era accesible a través de flujos de transacciones que cualquier usuario asociaría razonablemente con el producto de Squid. Según el equipo, no fue escrito, desplegado ni operado por ellos. Era una integración de terceros que habitaba el mismo vecindario que el router oficial y había heredado parte de su peso reputacional sin heredar su proceso de revisión.
Este patrón —protocolos cuya superficie de ataque efectiva se extiende mucho más allá del código que mantiene el equipo central— no es nuevo. Lo que el incidente de Squid pone en evidencia es la ambigüedad estructural de la propiedad en el DeFi modular: la brecha entre los contratos que un equipo audita y despliega, los contratos que se componen con ellos, y los contratos con los que los usuarios realmente interactúan bajo la marca del equipo. El exploit fue pequeño para los estándares históricos. El problema de gobernanza que expone no lo es.
Usamos el incidente de Squid como punto de entrada para examinar cómo los módulos de terceros se vuelven estructuralmente críticos en protocolos diseñados para la componibilidad sin permisos, por qué la responsabilidad tiende a evaporarse en los límites de los módulos, y qué sugieren casos comparables a lo largo de la historia del DeFi sobre la durabilidad de este modo de fallo.
Qué ocurrió realmente con Squid
Squid Router es una capa de liquidez entre cadenas que utiliza el General Message Passing de Axelar para enrutar swaps y llamadas arbitrarias entre blockchains. En la práctica es una capa de coordinación: un usuario envía un swap en la cadena A, Squid lo enruta a través de la liquidez de DEXs en esa cadena, entrega un payload a Axelar, y un contrato correspondiente en la cadena B recibe ese payload y ejecuta la lógica del lado de destino. Esa lógica del lado de destino es donde el diseño se abre.
Para soportar acciones arbitrarias tras el bridge —depositar en un mercado de préstamos, crear una posición LP, hacer staking de un token, intercambiar por algo ilíquido— la arquitectura permite despachar llamadas a contratos ejecutores o de módulos. Algunos de esos módulos los escribe el equipo de Squid. Otros los escriben socios de integración, protocolos que quieren exponerse como destino de Squid, o desplegadores anónimos que descubrieron que la infraestructura de enrutamiento reenviaría felizmente llamadas a cualquier dirección que satisficiera una interfaz flexible.
Según las divulgaciones públicas sobre el incidente, el contrato explotado era uno de estos módulos adyacentes y no el router central. The Block resumió la posición del equipo: el módulo no había sido desplegado por Squid, el equipo no podía identificar al desplegador, y se deslindaron de la responsabilidad operativa sobre él. Los fondos fueron drenados a través de una falla en cómo el módulo gestionaba las llamadas entrantes —un patrón ampliamente consistente con una validación insuficiente de quién podía activar qué función interna—, aunque los detalles técnicos específicos eran escasos al momento de escribir este artículo.
La cifra en dólares, reportada en aproximadamente 3,2 millones, sitúa el evento muy por debajo de los mayores incidentes del año, pero muy por encima del umbral en que los usuarios lo notan. Más importante aún, las wallets y flujos afectados eran aquellos que cualquier usuario tenía toda la razón para asociar con Squid: el módulo llevaba el nombre del protocolo, formaba parte de su grafo de enrutamiento y era accesible a través de lo que parecía una transacción de Squid. Desde la perspectiva del usuario, el perímetro de confianza era la marca. Desde la perspectiva del equipo, ese perímetro terminaba varios saltos antes.
La interfaz como superficie de ataque
La observación técnica más profunda es que las interfaces, no solo los contratos, pueden ser explotadas. Un protocolo de enrutamiento que acepta cualquier contrato que implemente una firma de función determinada ha publicado efectivamente una convocatoria abierta de integraciones. Cualquiera puede desplegar un contrato que satisfaga la interfaz, nombrarlo sugestivamente e insertarlo en los flujos de usuario a través de frontends de agregadores, interfaces de terceros o librerías de construcción de transacciones. La revisión del equipo del protocolo no alcanza a esos despliegues porque, por diseño, no se requiere revisión alguna.
Esta es la misma propiedad que hace que los tokens ERC-20 sean componibles con cualquier DEX sin necesidad de permisos —y la misma propiedad que produce la larga cola de tokens maliciosos que, en la interfaz de una wallet, son indistinguibles de los legítimos. El costo de la apertura sin permisos es que la interfaz se convierte en el límite de confianza, y las interfaces son fáciles de satisfacer sin ser seguras.
El problema del “no sabemos quién desplegó esto”
La línea más relevante de la divulgación de Squid no fue técnica. Fue la admisión de que el equipo no podía identificar quién había desplegado el contrato afectado. Como comunicación de crisis resulta incómoda, pero como descripción de la realidad operativa del DeFi modular es exacta.
Hay al menos tres razones por las que un equipo central puede perder el rastro de lo que se despliega bajo su paraguas.
La primera es el patrón del socio de integración. Muchos protocolos alientan activamente a terceros a escribir adaptadores que se conecten a su núcleo. El equipo central revisa la primera oleada de estos adaptadores —típicamente los socios que ellos mismos incorporan— y luego publica la interfaz para que las integraciones futuras ya no requieran su atención. Seis meses después, contratos escritos por personas con quienes el equipo jamás habló están enrutando fondos de usuarios a través del protocolo. Algunos son competentes. Otros no. La responsabilidad del equipo sobre cualquier módulo dado queda indefinida.
La segunda es el patrón del fork renombrado. Un tercero toma un módulo conocido del repositorio del equipo central, modifica unas pocas líneas y lo despliega bajo un nombre que incluye la marca del protocolo. On-chain, el contrato es indistinguible en espíritu de un módulo oficial. Off-chain, no existe ningún registro que vincule las direcciones de despliegue oficiales con los commit hashes oficiales de forma que las herramientas de usuario lo verifiquen. La procedencia es recuperable en principio y rara vez se comprueba en la práctica.
La tercera es el patrón del frontend obsoleto. Los agregadores, wallets y frontends que integraron un protocolo hace meses o años pueden seguir enrutando a través de módulos deprecados o contratos experimentales que el equipo nunca tuvo intención de poner en producción. El frontend sigue funcionando, los contratos siguen aceptando llamadas, y el equipo descubre que el camino deprecado seguía activo solo después de que es explotado.
Los tres patrones comparten una característica estructural: la superficie efectiva del protocolo —definida como el conjunto de contratos que un usuario razonable podría invocar creyendo que usa el protocolo— es estrictamente mayor que su superficie auditada, y esa diferencia no la rastrea nadie.
Por qué la divulgación es tan incómoda aquí
Cuando la brecha queda expuesta por un exploit, el equipo enfrenta una elección sin salida limpia. Asumir la responsabilidad del módulo de terceros implica un deber de cuidado que el equipo nunca aceptó y no puede proveer de forma escalable para cada integración futura. Deslindarla, como hizo Squid, les parece a los usuarios una evasión: resultaron perjudicados en lo que parecía ser Squid, y que les digan que en realidad no era Squid no hace que la pérdida sea menos directa.
Ninguna postura es deshonesta. Simplemente refleja que las categorías legales y reputacionales —“el protocolo”, “el equipo”, “la integración”— no se mapean limpiamente sobre la realidad on-chain del despliegue de módulos sin permisos. La respuesta honesta a “¿de quién era este contrato?” es con frecuencia “de nadie, en el sentido que tú le das”.
Breve historia de los fallos en el perímetro de terceros
El incidente de Squid es reciente, pero el modo de fallo subyacente tiene un linaje que vale la pena trazar. A lo largo de los últimos años, un patrón recurrente de exploits ha golpeado no el protocolo central sino el código adyacente —módulos, adaptadores, routers, integraciones— que habitaba dentro del perímetro de confianza efectivo del protocolo mientras quedaba fuera de su perímetro de auditoría.
Adaptadores de agregadores y routers
Los agregadores de DEXs presentan la analogía más clara. El valor de un agregador proviene de soportar muchos venues, y soportar muchos venues implica escribir adaptadores: contratos pequeños que traducen la llamada interna del agregador en el calldata específico que espera cada venue. Varios agregadores han sufrido pérdidas por bugs en adaptadores individuales, donde la lógica central de enrutamiento era sólida pero un adaptador en particular manejaba incorrectamente las aprobaciones de tokens, los valores de retorno o las rutas de reembolso. Los usuarios que aprobaban el router principal del agregador quedaban expuestos al peor adaptador del conjunto, no al promedio.
La lección estructural es que las aprobaciones son amplias y las integraciones son granulares. Una vez que un usuario ha otorgado allowance a un agregador sobre un token, cada contrato al que ese agregador puede llamar se convierte en parte del modelo de amenaza de ese token.
Estrategias de vaults
Los protocolos de vaults de rendimiento, en particular durante el ciclo 2020–2021 y de forma intermitente desde entonces, ilustraron el mismo problema en un dialecto diferente. La “estrategia” de un vault —el contrato que realmente despliega el capital depositado en protocolos externos— solía ser escrita por un estratega independiente, revisada por un equipo distinto al que construyó el vault, y actualizada en un cadencio que los depositantes del vault no seguían. Varios incidentes en esta categoría involucraron estrategias que interactuaban con un venue de maneras que los auditores del vault no habían modelado, o que confiaban en rutas de oráculo para las que los depositantes del vault no habían dado su consentimiento.
Los depositantes creían que usaban “el vault”. Estaban usando la estrategia del vault. Las dos no eran el mismo objeto de seguridad.
Ejecutores de bridges y módulos post-bridge
Los protocolos entre cadenas están particularmente expuestos porque la arquitectura exige explícitamente un punto de extensión. Hacer bridge de valor sin hacer bridge de acción resulta, para la mayoría de los usuarios, inútil: el objetivo es hacer algo en la cadena de destino. Eso implica un contrato ejecutor en el lado de destino, y ese contrato ejecutor ha sido históricamente el punto débil. Varios exploits entre cadenas en los últimos dos años apuntaron a la capa de ejecución del lado de destino antes que a la capa de paso de mensajes en sí, incluidos casos donde el bridge central demostró ser sólido pero el manejo de llamadas arbitrarias por parte del ejecutor permitía a un atacante suplantar el origen de un mensaje legítimo.
El incidente de Squid encaja cómodamente en este linaje. El router y la capa de paso de mensajes no fueron los que fallaron.
Las aprobaciones de tokens como acelerador universal
En todos estos casos, las aprobaciones de tokens funcionan como acelerador. La UX del DeFi ha entrenado a los usuarios a otorgar aprobaciones ilimitadas a la dirección de un router o agregador conocido. Esas aprobaciones no caducan y no distinguen entre contratos escritos por el equipo y contratos a los que pueden llamar los contratos del equipo. Un atacante que encuentra la manera de hacer que el contrato de confianza llame a un módulo controlado por el atacante —o que despliega el módulo controlado por el atacante de forma que se gana la llamada del contrato de confianza— convierte la aprobación vigente del usuario en una autorización de retiro. Esto es válido incluso cuando ningún contrato con el que el usuario interactuó explícitamente era malicioso.
La economía de los módulos sin permisos
Es tentador leer este patrón como una falla de diligencia: los equipos deberían auditar cada módulo, negarse a exponer interfaces que no pueden controlar, y seleccionar sus socios de integración con más cuidado. Esta lectura es correcta en espíritu e incompleta en la práctica. La economía del DeFi modular empuja en contra de la curaduría de maneras que vale la pena nombrar.
La componibilidad sin permisos no es un efecto secundario de estos protocolos. Es el producto. Un router entre cadenas cuyos destinos se limitan a diez venues aprobados por el equipo es un router peor, en sentido estricto competitivo, que uno cuyos destinos son abiertos. Un agregador de DEXs que rechaza adaptadores porque fueron escritos por desarrolladores desconocidos pierde calidad de ejecución frente a un competidor que los acepta. Un mercado de préstamos que se niega a listar colateral hasta haber auditado el contrato del token subyacente cede la larga cola de uso a un mercado que no lo hace.
Los incentivos de cada equipo por separado empujan hacia interfaces más grandes, rutas de integración más permisivas y una curaduría más laxa, porque el costo competitivo de la restricción es inmediato y el costo de seguridad de la permisividad es probabilístico y diferido. Los equipos que crecen más rápido son los que abrazan la superficie abierta; los que sobreviven son el subconjunto de aquellos con suerte respecto a qué módulos terminan importando.
¿Quién debe pagar la revisión?
Una pregunta económica relacionada es quién financia la revisión de seguridad a nivel de módulo cuando ese módulo lo despliega un tercero. El equipo del protocolo central no puede auditar de forma escalable cada integración sin cobrarles a los integradores —lo que los desincentiva— ni absorber el costo ellos mismos —lo que escala linealmente con el número de integraciones mientras que los ingresos del protocolo no lo hacen—. Los integradores, en particular los anónimos, tienen poco incentivo para pagar una auditoría exhaustiva de un contrato que pueden abandonar en tres meses. Los usuarios, que soportan la pérdida real cuando algo falla, no están en posición de encargar auditorías de contratos cuya existencia desconocían.
El resultado es un fallo de bien público en el que todos coinciden en que más revisión sería valiosa y ningún incentivo individual justifica pagarla. Los mecanismos por defecto que emergen —especificaciones de interfaz ligeras, autoatestaciones opcionales, divulgaciones a posteriori— reflejan esta brecha en lugar de resolverla.
La reputación como sustituto con fugas
A falta de revisión formal, la reputación hace parte del trabajo. Los usuarios aprenden qué agregadores llevan más tiempo operando, qué protocolos de enrutamiento han soportado más estrés, qué equipos divulgan los incidentes con prontitud. Es información real, pero generaliza mal: la reputación de marca de un protocolo no aporta casi ninguna señal sobre la reputación a nivel de módulo de una integración específica, especialmente cuando ese módulo fue desplegado después de que el usuario formó su opinión sobre la marca.
El caso de Squid es una ilustración precisa. Un usuario que había concluido, razonablemente, que Squid era un equipo competente operando un router bien arquitectado no se equivocaba respecto al equipo ni al router. Quedó expuesto a un módulo cuya reputación no tenía nada que ver con ninguno de los dos.
Diseñar para perímetros explícitos
Si el modo de fallo es estructural, las respuestas también deben serlo. Somos escépticos de las soluciones que dependen de que todos los equipos adopten mejores prácticas; el análisis de incentivos anterior sugiere que se erosionarán en los márgenes. La pregunta más interesante es qué cambios de diseño harían el perímetro legible para los usuarios y las herramientas sin sacrificar la componibilidad que hace valiosos a estos protocolos.
Algunas direcciones merecen atención.
La primera son los registros de módulos con procedencia criptográfica: registros on-chain u off-chain que mapeen direcciones de contratos al commit hash, la identidad del desplegador y el estado de auditoría del código desplegado, en una forma que wallets y agregadores pudieran verificar antes de firmar una transacción. Existen varios esfuerzos en esta dirección, pero la adopción es parcial, y la pregunta de quién curada el registro —el equipo central, un organismo independiente, los propios integradores— replica la ambigüedad original de responsabilidad un nivel más arriba.
La segunda son las aprobaciones granulares: aprobaciones de tokens delimitadas no a una dirección de router sino a patrones de llamada específicos, ventanas de expiración o conjuntos de destinos. ERC-7702 y primitivas relacionadas de account abstraction hacen esto técnicamente más viable de lo que era, aunque la UX de las aprobaciones granulares ha sido históricamente suficientemente mala como para que los usuarios recurran a la versión amplia por defecto. Existe un camino, pero requiere que los fabricantes de wallets asuman una complejidad significativa cuyos beneficios solo se materializan durante los exploits.
La tercera es el etiquetado explícito de confianza en las interfaces de usuario. Los agregadores y frontends podrían mostrar, en el momento de construcción de la transacción, qué contratos en el camino son de primera parte respecto al protocolo que el usuario cree estar usando, cuáles son de terceros y qué se sabe de cada uno. Esto es más un problema de UI que de contratos, y tiene el mérito de encontrar a los usuarios donde ya vive su modelo mental: en la marca, no en el bytecode.
La cuarta, y la menos satisfactoria, es la aceptación resignada: un reconocimiento a nivel de industria de que los protocolos DeFi modulares llevan un riesgo de cola de terceros permanente, que cierta fracción de incidentes involucrará contratos que ningún equipo central reclamará, y que los comportamientos por defecto del lado del usuario —aprobaciones pequeñas, revocaciones frecuentes, escepticismo ante las marcas— deben hacer más trabajo del que actualmente hacen. Aquí es efectivamente donde se encuentra la industria hoy, y el incidente de Squid no la movió.
Implicaciones y preguntas abiertas
El exploit del módulo de Squid es suficientemente pequeño como para que su cifra concreta en dólares no sea recordada durante mucho tiempo. El patrón que cristaliza —protocolos cuya superficie de confianza efectiva se extiende más allá de lo que cualquier equipo ha revisado, y cuya respuesta a los incidentes en esa superficie extendida es necesariamente incómoda— es duradero, e interactúa con varias tendencias que vale la pena seguir.
La primera es la migración de más lógica de protocolo hacia arquitecturas basadas en intents y solvers, donde el ejecutor de cualquier intent de usuario puede seleccionarse dinámicamente de un conjunto competitivo. Estos diseños son poderosos y llevan el problema del perímetro de terceros hasta su conclusión lógica: el contrato que maneja los fondos de un usuario en el momento de ejecución puede no haber existido cuando el usuario formuló su intent. La pregunta de qué “protocolo” estaba usando el usuario colapsa por completo.
La segunda es la maduración de los productos de seguro y cobertura on-chain. Si el riesgo a nivel de módulo no puede eliminarse mediante auditorías, en principio puede ser valorado. Si los mercados de cobertura pueden desarrollar la granularidad suficiente para suscribir módulos individuales —en lugar de protocolos enteros— es una pregunta abierta, y la respuesta importa para determinar si los ecosistemas de integración de terceros pueden escalar sin que su riesgo de cola supere su utilidad.
La tercera es el precedente en gobernanza y el marco legal. A medida que más incidentes involucren contratos cuyos desplegadores son desconocidos o anónimos, el contrato social implícito de que el equipo con cara visible es la parte responsable seguirá desgastándose. Esperamos más divulgaciones que se parezcan a la de Squid —honestas, técnicamente defendibles, dañinas para la reputación— y esperamos que la distinción entre “el protocolo” y “el perímetro del protocolo” se convierta en una categoría que usuarios, reguladores y contrapartes aprendan a leer.
Lo que estamos observando de cara a los próximos meses: si algún protocolo modular importante publica un estándar formal de atestación de módulos que las wallets apliquen de forma significativa; si el próximo incidente en esta categoría produce una respuesta más clara a la pregunta de responsabilidad que la que ofreció Squid; y si los grandes agregadores y routers empiezan a diferenciarse por la disciplina de su perímetro antes que por el número de integraciones. El primer protocolo que gane por el lado de la seguridad en ese trade-off merecerá ser estudiado. Las condiciones bajo las cuales ganar de esa manera se vuelva comercialmente viable aún no están en su lugar.