Introduction
Crypto payment cards have spent the better part of three years marketed as the quiet bridge between onchain balances and ordinary spending. The pitch is structurally appealing: a user holds stablecoins in a smart-contract account, a card program authorizes a Visa or Mastercard transaction, and a settlement engine converts and remits fiat to the merchant acquirer. Gnosis Pay, launched in 2023 as a self-custodial Visa debit product built on Gnosis Chain, is one of the more thoughtful implementations of that pattern. It pairs a Safe-based account with an EU-licensed issuer, and it treats the card as a programmable spending module on top of the user’s onchain wallet rather than a custodial wrapper around it.
In late 2025, that architecture was tested. An exploit targeting Gnosis Pay drained funds from affected users, and co-founder Martin Köppelmann stated publicly that Gnosis would cover all user losses out of its own treasury. The dollar magnitude was modest by the standards of bridge or lending exploits — but the structural questions it raises are not. A payments product sits at a junction that very few DeFi protocols occupy: it touches a card network, a regulated issuer, a merchant terminal, a settlement contract, and a self-custodial wallet, all in one transaction flow. Each of those is an attack surface, and most of them are not on the surface area DeFi security tooling has been built to defend.
We use this incident to do three things. First, we map the Gnosis Pay architecture and isolate where the exploit appears to have entered. Second, we compare Gnosis’s full-reimbursement response with the playbooks used after Ronin, Wormhole, Euler, and Radiant. Third, we ask what the incident says about the medium-term security posture of crypto-native payment rails — a category that has more product-market fit than its loss history suggests it should.
A payments stack is not a DeFi stack
Most DeFi exploits over the past four years can be sorted into a small number of categories: oracle manipulation, bridge signature compromise, reentrancy or accounting bugs in lending markets, governance capture, and private key theft from multisigs. The boundaries differ but the topology is consistent — a single smart contract or signing set holds value, an attacker finds a way to make it release that value, and the loss is realized onchain in one or a few transactions.
A card-issuance product does not have that topology. It is, at minimum, a five-layer system. At the bottom sits the user’s onchain account — in Gnosis Pay’s case, a Safe with a spending module that grants the issuer conditional access to balances. Above that is a settlement contract or relayer that converts authorized spend into the form the issuer needs. Above that sits the issuer-processor, which speaks the ISO 8583 message format that card networks use for authorization, clearing, and settlement. Above that is the card network itself — Visa, in Gnosis Pay’s case — and above that, the merchant acquirer and terminal.
Each of those layers has its own trust model. The Safe and spending module are onchain code, auditable line-by-line. The settlement relayer is typically off-chain infrastructure that listens to authorization messages and brokers them into onchain debits. The issuer-processor is a regulated entity running traditional financial software, with its own database of card states, balances, and risk rules. The network rails operate under chargeback, dispute, and reversal logic that has no analog in DeFi at all.
The implication is that the attack surface of a crypto payment card is not the union of “smart contract risk” and “card fraud risk” — it is the cross-product. A vulnerability can sit at any of the layers, but it can also sit at the seams between them: in the message that the processor sends to the settlement relayer, in the assumption the spending module makes about who can authorize a debit, in the timing window between a network-level authorization and an onchain settlement, or in the dispute path when a transaction is reversed off-chain but not on-chain. These seams are where novelty lives, and they are not well covered by the audit and monitoring stack the industry has built for pure DeFi.
Where Gnosis Pay’s design concentrates risk
Gnosis Pay’s headline design choice is that the user keeps custody. The card does not hold a balance; the user’s Safe does, and a module grants the card program the right to debit it under specified conditions. That choice eliminates the largest historical risk of crypto card products — the custodial issuer going insolvent or being hacked and taking user balances with it — but it relocates risk into the spending module and into whatever off-chain authorization signals trigger debits.
Concretely, the system has to answer a question on every swipe: is this authorization a legitimate request from the issuer-processor for a real, network-confirmed card transaction, or is it something else? Getting that answer wrong, in either direction, is fatal. Approve too liberally and an attacker who reaches the authorization channel can drain wallets without ever touching a real card. Approve too conservatively and legitimate transactions decline, breaking the product. The exploit appears to have lived inside that question.
The exploit, reconstructed from what is public
We deliberately keep this section conservative. Detailed root-cause writeups for the Gnosis Pay incident were still being finalized at the time of writing, and we will not attribute mechanics that have not been confirmed. What we can do is sketch the class of failure consistent with the disclosed facts and use that to reason about defenses.
What is public: an exploit related to Gnosis Pay caused user losses; Gnosis stated it would absorb those losses in full from its treasury; the affected scope was limited enough that the firm judged self-funded reimbursement to be feasible without external recovery actions. The losses were not described as the result of card-network fraud (i.e., a stolen physical card or skimmer), nor as a compromise of user private keys, nor as a Safe-level signature compromise. That narrows the candidate failure modes meaningfully.
The remaining surface — module logic, authorization plumbing, and the seam between off-chain processor signals and onchain debits — is exactly the part of the stack we flagged above as historically under-defended. An exploit at this seam typically takes one of three forms.
The first is authorization replay or forgery: an attacker finds a way to produce authorization messages the spending module accepts as if they came from the legitimate processor, either by reusing prior signed messages, by exploiting insufficient nonce or domain separation, or by compromising a signing key in the off-chain path. The onchain code does precisely what it was asked to do; the failure is upstream.
The second is scope creep in the module’s permission set: the spending module is granted broader allowances than the card program needs, and an attacker who reaches the authorization channel can use that excess scope to debit more than any single legitimate transaction would have permitted. This is the EVM analog of a card with no per-transaction limit.
The third is edge-case logic in conversion or fee handling: a bug in how the module computes the debit amount, the FX conversion, or the relayer fee creates a value-extraction path that requires no signature forgery at all — only a crafted sequence of legitimate-looking inputs.
We do not know which of these — or which combination — applies to the Gnosis Pay case. But the three share a property that matters for the rest of this analysis: none of them are the kind of bug a standard DeFi audit, focused on a single contract’s invariants, is well-shaped to catch. They live in the interaction between contract code and off-chain trust assumptions, and they require a different review discipline.
Why the loss was bounded
One feature of the Gnosis Pay design that appears to have worked is loss containment. Card programs operate under network-imposed per-card daily limits, and the spending module enforces those limits onchain. Whatever the entry vector, the attacker could not simply drain every Safe connected to the program in a single transaction; they were bounded by the program’s authorization envelope. This is the structural reason the incident is being described in dollar figures that the project can absorb, rather than figures that threaten its solvency. The seam was breached, but the rate limit held.
This is worth dwelling on because it is the design lesson most likely to generalize. Onchain enforcement of authorization caps — per-card, per-window, per-merchant-category — is a cheap, well-understood mechanism, and it converts an “any seam breach drains everything” failure mode into an “any seam breach drains a bounded amount before the program can pause.” That is a much more survivable posture.
The full-reimbursement decision in context
Köppelmann’s statement that Gnosis would cover all affected user losses puts the incident into a small and specific category of crypto post-mortems. Reimbursement decisions after exploits sit on a spectrum, and where a team lands on that spectrum is one of the strongest signals available about how it understands its own product.
At one end is Ronin (March 2022, around $620M drained from the Axie sidechain bridge). Sky Mavis, the operator, secured a $150M raise led by Binance and committed to making users whole, treating the loss as an existential brand event rather than a contained product issue. The reimbursement was funded externally and took weeks.
Wormhole (February 2022, around $320M) was reimbursed by Jump Crypto within roughly a day, in what was effectively a market-maker absorbing the loss to preserve the integrity of a bridge it depended on. The capacity to do this was a function of who happened to be backstopping the bridge, not a generalizable model.
Euler (March 2023, around $200M) ended in near-complete recovery after on- and off-chain negotiation with the attacker — an outcome that depended on facts specific to that incident and is not a template.
Radiant Capital (October 2024, around $50M) saw the team commit to a recovery plan and ongoing tracing, but the immediate posture was not full self-funded reimbursement; the project’s runway and treasury simply did not support that.
Gnosis Pay’s position is closest in spirit to Wormhole’s — an entity with a balance sheet absorbing a contained loss to preserve trust in a product it is the natural backstop for — but the scale and the source of funds are different. Gnosis is not a market maker stepping in; it is the issuer of the underlying chain and a long-standing project with treasury reserves, electing to treat the loss as a cost of running a payments product that, by design, asks users to trust a complex multi-layer stack.
What the reimbursement signal tells us
There are at least three readings of a full-reimbursement decision after a payments exploit, and they are not mutually exclusive.
The first is reputational economics: a payments product cannot tolerate even modest unreimbursed losses because it competes against fiat payment instruments where the user expects zero loss exposure. Visa’s own chargeback regime sets the baseline. A crypto card that passes losses to users in a self-custodial wrapper is structurally uncompetitive with one that does not, regardless of which design is technically more “pure.”
The second is affordability: the loss was small enough relative to treasury that absorbing it is cheaper than the alternative. This is true of Gnosis Pay’s case and was true of Wormhole’s; it was not true of Ronin’s, which is why Ronin required outside capital.
The third is liability framing: by reimbursing in full, the project communicates that it treats the spending module and the authorization layer as its own infrastructure, not the user’s. Self-custody, in this framing, means the user controls the keys to their Safe — but the security of the module that the card program installs into that Safe is the project’s responsibility. That is a meaningful boundary to draw, and it is closer to how regulated payment systems already think about issuer liability than how DeFi thinks about smart-contract risk.
We think the third reading is the most consequential. A crypto card product that explicitly accepts liability for the security of the spend layer is making a different promise than a typical DeFi protocol does. It is also exposing itself to a different cost structure — one that scales with the value flowing through the product, not with the size of any single contract’s TVL. Whether that cost structure is sustainable as Gnosis Pay grows is one of the open questions we return to at the end.
What this category of product needs that DeFi tooling does not provide
The defensive posture required for a payments stack is different in kind, not just degree, from the posture required for a lending market or a DEX. Three categories of capability stand out.
Authorization-channel hardening
The single highest-leverage defense for a crypto card program is making the authorization channel between the processor and the spending module unforgeable, replay-resistant, and tightly scoped. In practice this means signed authorization messages with strict nonce and expiry semantics, domain separation that prevents a message authorizing one card from being applied to another, and onchain verification that the message corresponds to a real, network-acknowledged authorization rather than a synthetic input.
The cryptographic primitives for this exist. What does not exist, in any standardized form, is a shared specification for how a card processor should sign authorization messages destined for an onchain module. Each crypto card program implements its own scheme. That diversity is a security cost: every program has to invent and audit its own authorization protocol, and most of them have small teams doing it.
Real-time anomaly detection at the seam
DeFi monitoring has matured around onchain telemetry — large-value transfers, unusual approvals, oracle deviations. A payments stack needs monitoring that spans the seam between the processor and the chain. It needs to detect, in close to real time, when the rate of onchain debits diverges from the rate of network-confirmed authorizations, or when a single card’s debit pattern departs from its historical baseline in a way consistent with module abuse rather than normal spending.
This is closer to how card-network fraud detection already works than to how DeFi monitoring works, and it suggests that the right defensive partners for crypto card programs may be traditional fraud-detection vendors with onchain extensions, rather than DeFi-native security firms with payment-side bolt-ons.
Bounded, pausable authorization scopes
The Gnosis Pay incident’s loss containment came from onchain enforcement of authorization limits. The lesson is that the spending module should expose narrow, time-bounded, and pausable authorization scopes — and that the ability to pause should sit with multiple independent operators with low-latency reaction capability, not behind a governance vote that takes days. The asymmetry between an attacker’s ability to drain at the speed of authorization messages and a defender’s ability to pause is the variable that decides whether a seam breach is a small reimbursement or a project-ending event.
Implications and what to watch
The Gnosis Pay incident is best read not as a verdict on Gnosis Pay specifically but as the first well-documented data point in a category that is still defining its security model. Crypto payment cards have shipped quickly because the consumer use case is obvious and the regulatory path through European e-money licensing is well-trodden. They have not yet accumulated the loss history that would force standardization of the authorization layer, the monitoring layer, or the liability model. This incident pushes that conversation forward but does not resolve it.
Three things are worth watching in the months ahead.
The first is whether the full-reimbursement decision becomes a category norm or stays specific to projects with treasury depth. If it becomes a norm, the implicit liability sits on issuer balance sheets, and the cost of running a card program rises with throughput. That changes the economics of the category and likely accelerates consolidation around issuers large enough to self-insure or willing to buy specialty insurance against this exact failure mode — which, today, is not a well-developed product line.
The second is whether the industry converges on a shared specification for processor-to-module authorization. The cryptographic question is tractable; the coordination question is harder. A standard would lower the per-program audit burden and create a target for which dedicated security tooling can be built. Without one, every new card program reintroduces the same class of seam risk.
The third is the regulatory reading. EU e-money and payments supervisors have so far treated crypto card programs primarily through the lens of the issuing entity and its compliance obligations. An incident in which the loss originates in the smart-contract spend layer, not in the regulated issuer, sits in a jurisdictional gray zone. If supervisors decide that the spend module is part of the regulated payment service — a defensible reading — then onchain code becomes subject to operational-resilience requirements that DeFi has so far operated outside of. That would be a structural shift in how this category is built.
What the Gnosis Pay incident does not show is that crypto-native payment rails are unworkable. It shows that they have a different attack surface than DeFi proper, that the seam between off-chain processor signals and onchain debits is the part of that surface most likely to be probed, and that loss containment through onchain authorization limits is the mechanism that turns a seam breach into a survivable event. The reimbursement decision is the part of the response that gets the headlines. The bounded scope that made the reimbursement affordable is the part that deserves the design attention.
들어가며
크립토 결제 카드는 지난 3년간 온체인 잔고와 일상 지출을 조용히 연결해 주는 다리로 마케팅되어 왔다. 그 구조적 매력은 분명하다. 사용자가 스마트 컨트랙트 계정에 스테이블코인을 보유하고, 카드 프로그램이 Visa 또는 Mastercard 거래를 승인하며, 정산 엔진이 이를 환전해 가맹점 어콰이어러에게 법정화폐로 송금하는 방식이다. 2023년 Gnosis Chain 위에 셀프 커스터디 Visa 직불 상품으로 출시된 Gnosis Pay는 이 구조를 가장 정교하게 구현한 사례 중 하나다. Safe 기반 계정과 EU 라이선스 발급사를 결합하고, 카드를 커스터디 래퍼가 아닌 사용자의 온체인 지갑 위에 얹힌 프로그래머블 지출 모듈로 설계했다.
2025년 말, 이 아키텍처가 시험대에 올랐다. Gnosis Pay를 겨냥한 익스플로잇이 영향을 받은 사용자들의 자금을 탈취했고, 공동창업자 Martin Köppelmann은 Gnosis가 자체 트레저리로 모든 사용자 손실을 보전하겠다고 공개 발표했다. 피해 규모는 브릿지나 대출 익스플로잇에 비하면 크지 않았다. 그러나 이 사건이 제기하는 구조적 질문의 무게는 결코 가볍지 않다. 결제 상품은 DeFi 프로토콜 중에서도 매우 드문 교차점에 위치한다. 하나의 트랜잭션 흐름 안에 카드 네트워크, 규제 발급사, 가맹점 단말기, 정산 컨트랙트, 셀프 커스터디 지갑이 모두 맞닿아 있다. 이 각각이 공격 표면이며, 대부분은 DeFi 보안 툴링이 방어하도록 설계된 영역 밖에 있다.
우리는 이번 사건을 통해 세 가지를 살펴본다. 첫째, Gnosis Pay의 아키텍처를 분석해 익스플로잇이 진입한 지점을 특정한다. 둘째, Gnosis의 전액 보전 대응을 Ronin, Wormhole, Euler, Radiant 사례와 비교한다. 셋째, 이 사건이 크립토 네이티브 결제 레일의 중기 보안 태세에 대해 무엇을 시사하는지 짚는다. 이 카테고리의 손실 이력을 감안하면 현재의 제품-시장 적합성은 오히려 이례적이다.
결제 스택은 DeFi 스택이 아니다
지난 4년간의 DeFi 익스플로잇 대부분은 몇 가지 유형으로 압축된다. 오라클 조작, 브릿지 서명 탈취, 대출 시장의 재진입 또는 회계 버그, 거버넌스 장악, 멀티시그 개인키 탈취가 그것이다. 경계는 다양하지만 구조는 일관된다. 단일 스마트 컨트랙트나 서명 주체가 가치를 보유하고, 공격자가 그 가치를 방출하는 방법을 찾아내며, 손실이 온체인에서 한두 건의 트랜잭션으로 실현된다.
카드 발급 상품은 이런 구조가 아니다. 최소한 5개 레이어로 이루어진 시스템이다. 가장 아래에는 사용자의 온체인 계정이 있다. Gnosis Pay의 경우 발급사에게 잔고 조건부 접근 권한을 부여하는 지출 모듈을 갖춘 Safe다. 그 위에는 승인된 지출을 발급사가 필요로 하는 형태로 변환하는 정산 컨트랙트 또는 릴레이어가 있다. 그 위에는 카드 네트워크가 승인, 청산, 정산에 사용하는 ISO 8583 메시지 포맷을 처리하는 발급사-프로세서가 자리한다. 그 위에는 카드 네트워크(Gnosis Pay의 경우 Visa)가 있고, 최상단에 가맹점 어콰이어러와 단말기가 있다.
각 레이어는 고유한 신뢰 모델을 가진다. Safe와 지출 모듈은 라인별로 감사 가능한 온체인 코드다. 정산 릴레이어는 대개 승인 메시지를 수신해 온체인 출금으로 중개하는 오프체인 인프라다. 발급사-프로세서는 카드 상태, 잔고, 리스크 규칙에 대한 자체 데이터베이스를 운영하는 규제 대상 기관이다. 네트워크 레일은 DeFi에는 유사 개념조차 없는 차지백, 분쟁, 역거래 로직을 따른다.
이는 크립토 결제 카드의 공격 표면이 “스마트 컨트랙트 리스크”와 “카드 사기 리스크”의 합집합이 아니라 그 곱집합임을 의미한다. 취약점은 어느 레이어에든 존재할 수 있지만, 레이어 간 경계에도 존재한다. 프로세서가 정산 릴레이어에 보내는 메시지, 지출 모듈이 출금을 승인할 주체에 대해 갖는 가정, 네트워크 수준 승인과 온체인 정산 사이의 타이밍 공백, 또는 오프체인에서 역거래가 발생했으나 온체인에는 반영되지 않은 분쟁 경로가 그 경계다. 이 경계들이 바로 새로운 위험이 숨어드는 곳이며, 업계가 순수 DeFi를 위해 구축한 감사·모니터링 스택은 이를 충분히 커버하지 못한다.
Gnosis Pay 설계가 리스크를 집중시키는 지점
Gnosis Pay 설계의 핵심은 사용자가 커스터디를 유지한다는 것이다. 카드 자체는 잔고를 보유하지 않는다. 사용자의 Safe가 보유하고, 모듈이 카드 프로그램에 특정 조건 하에 출금 권한을 부여한다. 이 설계는 크립토 카드 상품 역사상 가장 큰 리스크였던 커스터디 발급사의 파산이나 해킹으로 인한 사용자 자산 손실을 원천 차단한다. 그러나 그 리스크는 지출 모듈과 출금을 트리거하는 오프체인 승인 신호로 재배치된다.
구체적으로, 시스템은 모든 카드 긁기마다 이 질문에 답해야 한다. 이 승인은 실제 네트워크 확인 카드 거래에 대한 발급사-프로세서의 정당한 요청인가, 아니면 그 외의 무언가인가? 이 질문에 잘못 답하면 어느 방향이든 치명적이다. 너무 관대하게 승인하면 승인 채널에 접근한 공격자가 실물 카드를 건드리지 않고도 지갑을 비울 수 있다. 너무 엄격하게 제한하면 정상 거래가 거부되어 상품 자체가 작동하지 않는다. 이번 익스플로잇은 바로 이 질문 속에 존재했던 것으로 보인다.
공개된 사실을 바탕으로 재구성한 익스플로잇
이 절은 의도적으로 보수적으로 서술한다. 집필 시점에 Gnosis Pay 사건의 상세한 근본 원인 분석이 아직 최종 확정 단계였으며, 확인되지 않은 메커니즘을 단정 짓지 않을 것이다. 다만 공개된 사실과 일치하는 실패 유형을 그려보고, 이를 바탕으로 방어 수단을 추론할 수 있다.
공개된 내용은 다음과 같다. Gnosis Pay와 관련된 익스플로잇으로 사용자 손실이 발생했고, Gnosis는 트레저리에서 전액 보전하겠다고 발표했으며, 피해 범위는 외부 자금 조달 없이 자체 보전이 가능하다고 판단할 만큼 제한적이었다. 피해는 카드 네트워크 사기(물리적 카드 도용이나 스키머), 사용자 개인키 탈취, Safe 수준의 서명 침해 결과로 묘사되지 않았다. 이로써 후보 실패 유형이 의미 있게 좁혀진다.
남은 공격 표면, 즉 모듈 로직, 승인 배관, 오프체인 프로세서 신호와 온체인 출금 사이의 경계가 바로 위에서 역사적으로 방어가 미흡하다고 지적한 영역이다. 이 경계에서의 익스플로잇은 통상 세 가지 형태 중 하나를 취한다.
첫 번째는 승인 재사용 또는 위조다. 공격자가 이전에 서명된 메시지를 재사용하거나, 불충분한 논스 또는 도메인 분리를 악용하거나, 오프체인 경로의 서명키를 탈취해 지출 모듈이 정당한 프로세서에서 온 것처럼 수락하는 승인 메시지를 만들어낸다. 온체인 코드는 지시받은 대로 정확히 동작하며, 실패는 그 상류에 있다.
두 번째는 모듈 권한 범위의 비대화다. 지출 모듈에 카드 프로그램이 실제로 필요한 것보다 넓은 허용 범위가 부여되어, 승인 채널에 접근한 공격자가 그 초과 범위를 이용해 단일 정상 거래가 허용하는 것보다 더 많이 출금할 수 있다. 이는 거래 한도가 없는 카드의 EVM 버전이다.
세 번째는 환전 또는 수수료 처리의 엣지케이스 로직이다. 모듈이 출금액, FX 환전, 또는 릴레이어 수수료를 계산하는 방식의 버그가 서명 위조 없이도 가치를 추출할 수 있는 경로를 만들어낸다. 정교하게 조작된 일련의 정상처럼 보이는 입력만으로 충분하다.
우리는 이 중 어느 것이, 혹은 어떤 조합이 Gnosis Pay 사례에 해당하는지 모른다. 그러나 세 가지 모두 이후 분석에서 중요한 공통점을 공유한다. 단일 컨트랙트의 불변성에 집중하는 표준 DeFi 감사가 포착하기 어려운 유형의 버그라는 것이다. 이것들은 컨트랙트 코드와 오프체인 신뢰 가정 간의 상호작용 속에 존재하며, 다른 차원의 검토 방법론을 요구한다.
손실이 제한된 이유
Gnosis Pay 설계에서 작동한 것으로 보이는 기능은 손실 봉쇄다. 카드 프로그램은 네트워크가 부과하는 카드별 일일 한도 하에 운영되며, 지출 모듈은 그 한도를 온체인에서 강제한다. 진입 경로가 무엇이든 공격자는 프로그램의 승인 한도에 묶여 있어, 한 번의 트랜잭션으로 프로그램에 연결된 모든 Safe를 비울 수 없었다. 이 사건이 프로젝트의 지급 능력을 위협하는 수치가 아닌, 프로젝트가 흡수 가능한 달러 규모로 묘사되는 구조적 이유가 바로 여기에 있다. 경계는 뚫렸지만, 속도 제한은 유지됐다.
이 점은 깊이 새길 만하다. 일반화 가능성이 가장 높은 설계 교훈이기 때문이다. 카드별, 시간 창별, 가맹점 유형별 온체인 승인 한도 강제는 저렴하고 검증된 메커니즘이며, “경계 침해 시 전부 유출” 실패 모드를 “경계 침해 시 프로그램이 정지하기 전까지 제한된 금액만 유출”로 전환한다. 이는 훨씬 생존 가능한 태세다.
전액 보전 결정을 맥락 속에서 보다
Gnosis가 영향을 받은 모든 사용자 손실을 보전하겠다는 Köppelmann의 발표는 이번 사건을 크립토 포스트모템 중에서도 소수의 특정 범주에 위치시킨다. 익스플로잇 이후 보전 결정은 하나의 스펙트럼 위에 있으며, 팀이 그 스펙트럼 어디에 위치하느냐는 자신의 상품을 어떻게 이해하는지에 대한 가장 강력한 신호 중 하나다.
한쪽 끝에는 Ronin이 있다(2022년 3월, Axie 사이드체인 브릿지에서 약 6억 2천만 달러 탈취). 운영사 Sky Mavis는 Binance가 이끄는 1억 5천만 달러 투자를 확보하고 사용자 전액 보전을 약속했으며, 이를 제한된 상품 이슈가 아닌 실존적 브랜드 위기로 처리했다. 보전은 외부 자금으로 이루어졌고 수 주가 소요됐다.
Wormhole(2022년 2월, 약 3억 2천만 달러)은 Jump Crypto가 하루도 채 안 되어 보전했다. 사실상 해당 브릿지에 의존하던 시장 조성자가 브릿지의 무결성을 지키기 위해 손실을 흡수한 것이었다. 이 가능성은 우연히 브릿지를 백스탑하고 있던 주체에 기인한 것으로, 일반화할 수 있는 모델이 아니다.
Euler(2023년 3월, 약 2억 달러)는 공격자와의 온·오프체인 협상 끝에 거의 전액 회수로 마무리됐다. 이는 해당 사건에 특수한 사실 관계에 따른 결과로, 템플릿으로 삼을 수 없다.
Radiant Capital(2024년 10월, 약 5천만 달러)은 팀이 회수 계획과 지속적인 추적을 약속했지만, 즉각적인 태세는 자체 자금 전액 보전이 아니었다. 프로젝트의 런웨이와 트레저리 규모가 이를 지탱하지 못했다.
Gnosis Pay의 포지션은 정신적으로 Wormhole에 가장 가깝다. 잔고를 가진 주체가 자신이 자연스러운 백스탑인 상품에 대한 신뢰를 지키기 위해 제한된 손실을 흡수하는 것이다. 그러나 규모와 자금 출처는 다르다. Gnosis는 개입하는 시장 조성자가 아니라, 기반 체인의 발급 주체이자 오랜 역사를 가진 프로젝트로서 트레저리 준비금을 보유하고 있으며, 설계상 복잡한 다층 스택에 대한 사용자의 신뢰를 요구하는 결제 상품을 운영하는 비용으로 이 손실을 처리하기로 결정했다.
보전 신호가 말해 주는 것
결제 익스플로잇 이후 전액 보전 결정에는 적어도 세 가지 해석이 있으며, 이것들은 서로 배타적이지 않다.
첫 번째는 평판 경제학이다. 결제 상품은 보전되지 않은 손실이 소액이라도 감당할 수 없다. 사용자가 손실 노출을 기대하지 않는 법정화폐 결제 수단과 경쟁하기 때문이다. Visa 자체의 차지백 제도가 기준선을 설정한다. 셀프 커스터디 래퍼 안에서 사용자에게 손실을 전가하는 크립토 카드는, 설계적으로 얼마나 “순수”한지와 무관하게, 그렇지 않은 것과의 경쟁에서 구조적으로 불리하다.
두 번째는 감당 가능성이다. 트레저리 대비 손실이 작아서 흡수하는 것이 대안보다 저렴하다는 것이다. Gnosis Pay 사례와 Wormhole 사례가 그러했고, Ronin은 그렇지 않았기 때문에 외부 자본이 필요했다.
세 번째는 책임 프레이밍이다. 전액 보전을 함으로써 프로젝트는 지출 모듈과 승인 레이어를 사용자의 인프라가 아닌 자신의 인프라로 취급한다는 의사를 전달한다. 이 프레임에서 셀프 커스터디는 사용자가 자신의 Safe 키를 통제한다는 의미이지만, 카드 프로그램이 그 Safe에 설치하는 모듈의 보안은 프로젝트의 책임이다. 이는 의미 있는 경계 설정이며, DeFi가 스마트 컨트랙트 리스크를 다루는 방식보다 규제된 결제 시스템이 발급사 책임을 이미 바라보는 방식에 훨씬 가깝다.
우리는 세 번째 해석이 가장 중요하다고 본다. 지출 레이어의 보안에 대해 명시적으로 책임을 수용하는 크립토 카드 상품은 일반적인 DeFi 프로토콜과 다른 약속을 하는 것이다. 또한 다른 비용 구조에 자신을 노출시킨다. 단일 컨트랙트의 TVL 규모가 아니라, 상품을 통해 흐르는 가치의 규모에 따라 비용이 늘어나는 구조다. 이 비용 구조가 Gnosis Pay의 성장에 따라 지속 가능한지는 마지막에 다시 다루는 열린 질문 중 하나다.
이 카테고리 상품이 필요로 하지만 DeFi 툴링이 제공하지 못하는 것
결제 스택에 요구되는 방어 태세는 대출 시장이나 DEX에 요구되는 것과 정도가 아닌 종류가 다르다. 세 가지 역량 범주가 두드러진다.
승인 채널 강화
크립토 카드 프로그램에서 레버리지가 가장 높은 단일 방어는 프로세서와 지출 모듈 사이의 승인 채널을 위조 불가능하고, 재사용 불가능하며, 범위가 엄격히 제한되게 만드는 것이다. 실질적으로 이는 엄격한 논스 및 만료 시맨틱을 갖춘 서명된 승인 메시지, 하나의 카드를 승인하는 메시지가 다른 카드에 적용되는 것을 막는 도메인 분리, 그리고 해당 메시지가 합성 입력이 아닌 실제 네트워크 승인 거래에 대응함을 온체인에서 검증하는 것을 의미한다.
이를 위한 암호학적 프리미티브는 존재한다. 표준화된 형태로 존재하지 않는 것은, 카드 프로세서가 온체인 모듈을 대상으로 승인 메시지에 서명하는 방법에 대한 공유 명세다. 각 크립토 카드 프로그램은 자체적인 방식을 구현한다. 이 다양성은 보안 비용이다. 모든 프로그램이 자체 승인 프로토콜을 고안하고 감사해야 하며, 대부분의 팀은 소규모로 이를 수행한다.
경계에서의 실시간 이상 탐지
DeFi 모니터링은 대규모 가치 이전, 비정상적인 승인, 오라클 이탈 등 온체인 텔레메트리를 중심으로 성숙해왔다. 결제 스택에는 프로세서와 체인 사이의 경계를 아우르는 모니터링이 필요하다. 온체인 출금 속도가 네트워크 확인 승인 속도와 괴리되는 시점, 또는 단일 카드의 출금 패턴이 정상 지출이 아닌 모듈 남용과 일치하는 방식으로 역사적 기준선에서 벗어나는 시점을 거의 실시간으로 감지해야 한다.
이는 DeFi 모니터링보다 카드 네트워크 사기 탐지가 이미 작동하는 방식에 가깝다. 따라서 크립토 카드 프로그램에 적합한 방어 파트너는 결제 기능을 볼트온한 DeFi 네이티브 보안 회사보다, 온체인 확장 기능을 갖춘 전통적인 사기 탐지 벤더일 가능성이 높다.
제한적이고 일시정지 가능한 승인 범위
Gnosis Pay 사건의 손실 봉쇄는 승인 한도의 온체인 강제에서 비롯됐다. 교훈은 지출 모듈이 좁고, 시간 제한이 있으며, 일시정지 가능한 승인 범위를 노출해야 한다는 것이다. 그리고 일시정지 권한은 수일이 걸리는 거버넌스 투표 뒤가 아니라, 낮은 지연 시간의 반응 능력을 갖춘 다수의 독립 운영자에게 귀속되어야 한다. 공격자가 승인 메시지의 속도로 자금을 소진하는 능력과 방어자가 정지시키는 능력 사이의 비대칭이 바로, 경계 침해가 소규모 보전으로 끝나느냐 프로젝트를 종식시키는 사건이 되느냐를 결정하는 변수다.
시사점과 주목할 것들
Gnosis Pay 사건은 Gnosis Pay 자체에 대한 판결이 아니라, 아직 보안 모델을 정립하고 있는 카테고리의 첫 번째 잘 문서화된 데이터포인트로 읽히는 것이 가장 적절하다. 크립토 결제 카드는 빠르게 출시되어 왔다. 소비자 사용 사례가 분명하고, 유럽 전자화폐 라이선스를 통한 규제 경로가 잘 정비되어 있기 때문이다. 그러나 승인 레이어, 모니터링 레이어, 책임 모델의 표준화를 강제할 만한 손실 이력은 아직 충분히 축적되지 않았다. 이번 사건은 그 논의를 앞당기지만, 해결하지는 않는다.
앞으로 몇 달간 주목할 세 가지가 있다.
첫 번째는 전액 보전 결정이 카테고리 규범이 될지, 아니면 트레저리 여력이 있는 프로젝트에 한정된 관행으로 남을지다. 규범이 된다면 묵시적 책임은 발급사 대차대조표 위에 얹히고, 카드 프로그램 운영 비용은 처리량에 비례해 증가한다. 이는 카테고리의 경제성을 바꾸고, 자체 보험이 가능하거나 이 정확한 실패 유형에 대한 특수 보험을 구매할 의향이 있는 대형 발급사 중심으로 통합을 가속화할 가능성이 높다. 오늘날 이는 아직 잘 발달된 상품 영역이 아니다.
두 번째는 업계가 프로세서-모듈 승인에 대한 공유 명세로 수렴할지 여부다. 암호학적 문제는 해결 가능하다. 조정 문제가 더 어렵다. 표준이 생기면 프로그램별 감사 부담이 낮아지고, 전용 보안 툴링을 구축할 타겟이 생긴다. 표준 없이는 모든 새로운 카드 프로그램이 동일한 유형의 경계 리스크를 다시 도입한다.
세 번째는 규제 당국의 해석이다. EU 전자화폐 및 결제 감독 당국은 지금까지 크립토 카드 프로그램을 주로 발급 기관과 그 컴플라이언스 의무의 렌즈로 바라봐 왔다. 손실이 규제 발급사가 아닌 스마트 컨트랙트 지출 레이어에서 발생한 사건은 관할권 회색지대에 놓인다. 감독 당국이 지출 모듈을 규제된 결제 서비스의 일부로 판단한다면, 충분히 방어 가능한 해석이지만, 온체인 코드는 DeFi가 지금껏 벗어나 있던 운영 복원력 요건의 적용을 받게 된다. 이는 이 카테고리가 구축되는 방식의 구조적 전환이 될 것이다.
Gnosis Pay 사건이 보여주지 않는 것은 크립토 네이티브 결제 레일이 작동 불가능하다는 것이다. 이 사건이 보여주는 것은, 이 레일이 DeFi와는 다른 공격 표면을 가지며, 오프체인 프로세서 신호와 온체인 출금 사이의 경계가 탐색될 가능성이 가장 높은 부분이고, 온체인 승인 한도를 통한 손실 봉쇄가 경계 침해를 생존 가능한 사건으로 전환하는 메커니즘이라는 것이다. 보전 결정은 헤드라인을 장식하는 대응이다. 보전을 감당 가능하게 만든 제한된 범위가 설계적 관심을 받아야 마땅한 부분이다.
はじめに
暗号資産決済カードは、この3年近くにわたって「オンチェーン残高と日常の支出をつなぐ静かなブリッジ」として売り込まれてきた。そのコンセプトは構造的に魅力的だ。ユーザーはスマートコントラクトアカウントにステーブルコインを保有し、カードプログラムがVisaまたはMastercardの決済を承認し、決済エンジンが法定通貨に変換してマーチャントのアクワイアラに送金する。2023年にGnosis Chain上でセルフカストディ型のVisaデビット商品として立ち上げられたGnosis Payは、このパターンを最も丁寧に実装した事例のひとつだ。SafeベースのアカウントとEUライセンスを持つイシュアーを組み合わせ、カードをユーザーのオンチェーンウォレットを包むカストディラッパーとしてではなく、その上に重なるプログラマブルな支出モジュールとして位置づけている。
2025年末、このアーキテクチャが試練にさらされた。Gnosis Payを標的にしたエクスプロイトにより、影響を受けたユーザーの資金が流出した。共同創設者のMartin Köppelmannは、Gnosisが自社のトレジャリーからすべてのユーザー損失を補填すると公式に表明した。金額はブリッジやレンディングのエクスプロイトの基準からすれば小規模だったが、浮かび上がる構造的問題は軽視できない。決済商品は、DeFiプロトコルのなかでもほとんど例を見ない交差点に位置している。一つのトランザクションフローの中に、カードネットワーク、規制を受けたイシュアー、マーチャント端末、決済コントラクト、そしてセルフカストディウォレットが同時に関わる。そのどれもが攻撃対象となりうるが、大半は業界が構築してきたDeFiセキュリティツールの守備範囲の外にある。
本稿ではこのインシデントを通じて三つのことを行う。第一に、Gnosis Payのアーキテクチャを分析し、エクスプロイトの侵入経路と考えられる箇所を特定する。第二に、Gnosisの全額補償という対応を、Ronin、Wormhole、Euler、Radiantの事後対応と比較する。第三に、このインシデントが暗号資産ネイティブな決済レールの中期的なセキュリティ態勢について何を示唆するかを問う。この分野は、損失の歴史から想像されるよりもはるかに高いプロダクトマーケットフィットを持っている。
決済スタックはDeFiスタックではない
過去4年間のDeFiエクスプロイトの大部分は、少数のカテゴリに分類できる。オラクル操作、ブリッジの署名侵害、レンディング市場の再入力やアカウンティングのバグ、ガバナンス乗っ取り、マルチシグからの秘密鍵窃取などだ。境界は異なっても構造は一貫している――単一のスマートコントラクトか署名セットが価値を保持し、攻撃者がそれを放出させる方法を見つけ、損失がオンチェーンで数件のトランザクションとして確定する。
カードイシュアンス商品にはそのような構造がない。最低でも5層からなるシステムだ。最下層にはユーザーのオンチェーンアカウントがある。Gnosis Payの場合、イシュアーに残高への条件付きアクセスを付与する支出モジュールを組み込んだSafeがそれにあたる。その上に、承認された支出をイシュアーが必要とする形式に変換する決済コントラクトまたはリレイヤーがある。さらにその上にイシュアープロセッサーが位置し、カードネットワークが承認・清算・決済に使うISO 8583メッセージフォーマットを処理する。その上がカードネットワーク本体――Gnosis PayはVisa――であり、最上位にマーチャントのアクワイアラと端末がある。
それぞれの層が独自のトラストモデルを持つ。Safeとスペンディングモジュールはオンチェーンコードであり、一行一行監査可能だ。決済リレイヤーは一般にオフチェーンのインフラで、承認メッセージを監視してオンチェーンのデビットに仲介する。イシュアープロセッサーは規制下の事業体が従来の金融ソフトウェアを動かすもので、カードの状態・残高・リスクルールを独自のデータベースで管理している。ネットワークレールはチャージバック・紛争・取消のロジックの下で動いており、DeFiには対応するものが存在しない。
つまり暗号資産決済カードの攻撃対象は、「スマートコントラクトリスク」と「カード詐欺リスク」の和集合ではなく、それらの積集合なのだ。脆弱性はどの層にも存在しうるが、層の「継ぎ目」にも潜みうる。プロセッサーが決済リレイヤーに送るメッセージ、スペンディングモジュールがデビットを誰が承認できるかについて持つ前提、ネットワークレベルの承認とオンチェーン決済の間のタイミングの窓、あるいはトランザクションがオフチェーンで取り消されてもオンチェーンでは取り消されない場合の紛争経路などだ。この継ぎ目こそが未知の脆弱性が宿る場所であり、純粋なDeFiを守るために構築された監査・監視スタックはほとんどカバーできていない。
Gnosis Payの設計がリスクを集中させる箇所
Gnosis Payの設計上の最大の特徴は、ユーザーがカストディを保持することだ。カードに残高は存在せず、ユーザーのSafeが保持し、モジュールが指定された条件下でカードプログラムにデビット権限を付与する。この選択は、暗号資産カード商品の最大の歴史的リスク――カストディ型イシュアーの破綻やハッキングによるユーザー残高の消滅――を排除する。しかし代わりに、リスクはスペンディングモジュールと、デビットを引き起こすオフチェーンの承認シグナルに移動する。
具体的には、システムはカードを一度スワイプするたびに一つの問いに答えなければならない。この承認は、実際のネットワーク確認済みカードトランザクションに対するイシュアープロセッサーからの正当なリクエストか、それとも別の何かか？この問いへの誤答は、どちらの方向であっても致命的だ。過度に承認してしまえば、承認チャネルに到達した攻撃者は実際のカードに触れることなくウォレットを空にできる。過度に拒否すれば正当なトランザクションが却下され、商品としての機能が損なわれる。エクスプロイトはこの問いの中に潜んでいたようだ。
公開情報から再構成するエクスプロイト
このセクションは意図的に保守的に記述する。Gnosis Payインシデントの根本原因に関する詳細な報告は執筆時点ではまだ確定していなかったため、確認されていないメカニズムを断定的に記述しない。公開事実と整合する障害のクラスを概説し、そこから防御策を検討する。
公開されている事実は以下の通りだ。Gnosis Pay関連のエクスプロイトによりユーザー損失が発生した。Gnosisはトレジャリーから損失を全額補填すると表明した。影響範囲は、外部からの回収措置なしに自己資金での補償が可能と判断できる程度に限定されていた。損失はカードネットワーク詐欺（物理的なカードの盗難やスキマー）の結果でも、ユーザー秘密鍵の侵害でも、Safeレベルの署名侵害でもないとされた。これにより候補となる障害モードは大幅に絞られる。
残る攻撃対象――モジュールロジック、承認の配管、オフチェーンプロセッサーシグナルとオンチェーンデビットの継ぎ目――は、まさに先述した歴史的に防御が手薄な部分だ。この継ぎ目でのエクスプロイトは一般に三つの形をとる。
一つ目は承認のリプレイまたは偽造だ。攻撃者が、スペンディングモジュールが正規のプロセッサーからのものとして受け入れる承認メッセージを生成する方法を見つける。過去の署名済みメッセージの再利用、不十分なナンスやドメイン分離の悪用、またはオフチェーンパス上の署名鍵の侵害などが手段となる。オンチェーンコードは指示された通りに動作しており、障害は上流にある。
二つ目はモジュールの権限スコープの逸脱だ。スペンディングモジュールがカードプログラムに必要以上の権限を付与されており、承認チャネルに到達した攻撃者がその余剰スコープを利用して、正当なトランザクション一件分を超えるデビットを行う。これは一件あたりの上限がないカードのEVM版といえる。
三つ目は変換や手数料処理のエッジケースロジックだ。モジュールがデビット金額・FX変換・リレイヤー手数料を計算する方法のバグが価値抽出の経路を生む。このケースでは署名の偽造は一切不要で、巧妙に設計された正当に見えるインプットの連続があれば足りる。
Gnosis Payのケースにこれらのどれが――あるいはどの組み合わせが――該当するかは不明だ。しかし三つには、この分析の残りの部分で重要になる共通の性質がある。いずれも、単一コントラクトの不変条件に焦点を当てた標準的なDeFi監査が発見しやすい類のバグではない。コントラクトコードとオフチェーンのトラスト前提の相互作用の中に潜んでおり、異なるレビュー手法を必要とする。
損失が限定された理由
Gnosis Payの設計で機能したと見られる特徴の一つは、損失の封じ込めだ。カードプログラムはネットワークが課す一日あたりのカード利用上限の下で動き、スペンディングモジュールはその上限をオンチェーンで強制する。どのような侵入経路であれ、攻撃者はプログラムに接続されたすべてのSafeを一つのトランザクションで根こそぎ奪うことはできなかった。プログラムの承認エンベロープによって制約されていたからだ。このインシデントが、プロジェクトの支払い能力を脅かす規模ではなく、プロジェクトが吸収できる金額として語られている構造的な理由がここにある。継ぎ目は破られたが、レートリミットは維持された。
これは一般化できる設計上の教訓として特に重要だ。オンチェーンでの承認上限の強制――カードごと、時間窓ごと、加盟店カテゴリごと――は、コストが低く十分に理解されたメカニズムであり、「継ぎ目の侵害はすべてを流出させる」という障害モードを「継ぎ目の侵害はプログラムが一時停止するまでの限られた量だけ流出させる」という障害モードに変える。それははるかに生存可能な態勢だ。
全額補償という決断をコンテキストで読む
Köppelmannが表明した「影響を受けたユーザーの損失をすべてGnosisが補填する」という決断は、このインシデントを暗号資産の事後報告の中でも小さく特定のカテゴリに位置づける。エクスプロイト後の補償決断はスペクトラムの上に並び、チームがそのどこに着地するかは、自社プロダクトをどう理解しているかを示す最も強いシグナルの一つだ。
スペクトラムの一端にあるのはRonin（2022年3月、Axieのサイドチェーンブリッジから約6億2000万ドルが流出）だ。オペレーターのSky Mavisはバイナンス主導で1億5000万ドルを調達し、損失をブランドの存続に関わる問題として扱い、ユーザーへの弁済を約束した。補償は外部資金で賄われ、数週間を要した。
Wormhole（2022年2月、約3億2000万ドル）は約1日でJump Cryptoが補填した。実質的には、自社が依存するブリッジの完全性を守るためにマーケットメーカーが損失を吸収したものだ。この対応能力はブリッジを支えていた当事者が誰であったかに依存するものであり、一般化できるモデルではない。
Euler（2023年3月、約2億ドル）は攻撃者とのオン・オフチェーン交渉の末に資金がほぼ全額回収されるという結果に終わった。このインシデント固有の事情に依存した結末であり、テンプレートにはならない。
Radiant Capital（2024年10月、約5000万ドル）ではチームが回収計画と継続的な追跡を約束したが、即座の全額自己補填という態勢はとられなかった。プロジェクトの資金力とトレジャリーがそれを支えられなかったからだ。
Gnosis Payの立場は精神的にはWormholeに最も近い――自社が自然な後ろ盾となる商品に対する限定的な損失を、バランスシートを持つ主体が吸収する。しかし規模と資金の出所は異なる。Gnosisは介入するマーケットメーカーではなく、トレジャリー準備金を持つ歴史あるプロジェクトであり、設計上ユーザーに複雑な多層スタックへの信頼を求める決済商品の運営コストとして損失を扱うことを選んでいる。
補償シグナルが示すもの
決済エクスプロイト後の全額補償決断には、少なくとも三つの読み方があり、それらは相互に排他的ではない。
一つ目は評判の経済性だ。決済商品は、たとえ小額でも補填されない損失を許容できない。なぜなら、ユーザーが損失ゼロを当然とする法定通貨の決済手段と競合しているからだ。Visa自身のチャージバック制度がその基準を設定している。セルフカストディのラッパーの中でユーザーに損失を負わせる暗号資産カードは、設計のどちらが技術的に「純粋」であるかにかかわらず、構造的に競争力を欠く。
二つ目は支払い能力だ。損失がトレジャリーに対して十分に小さく、吸収する方が代替手段より安上がりだった。Gnosis Payのケースでもそうだし、Wormholeもそうだった。Roninはそうではなく、だから外部資本を必要とした。
三つ目は責任の枠組みだ。全額補填することで、プロジェクトはスペンディングモジュールと承認レイヤーをユーザーのインフラではなく自社のインフラとして扱うことを表明している。この枠組みでは、セルフカストディとはユーザーが自分のSafeの鍵を管理することを意味するが、カードプログラムがそのSafeにインストールするモジュールのセキュリティはプロジェクトの責任だ。これは明確な境界線であり、規制を受けた決済システムがすでにイシュアー責任について考える方法に近く、DeFiがスマートコントラクトリスクについて考える方法よりも親和性が高い。
三つ目の読み方が最も重要だと我々は考える。支出レイヤーのセキュリティに対して明示的に責任を負う暗号資産カード商品は、典型的なDeFiプロトコルとは異なる約束をしている。同時に異なるコスト構造にさらされる。それは単一コントラクトのTVLの大きさではなく、商品を流れる価値の量に応じてスケールする。Gnosis Payが成長するにつれてそのコスト構造が持続可能かどうかは、最後に立ち返るべき未解決の問いの一つだ。
この種の商品がDeFiツールにはない何を必要とするか
決済スタックに必要な防御態勢は、レンディング市場やDEXに必要な態勢とは程度の違いではなく種類の違いがある。三つの能力カテゴリが際立っている。
承認チャネルの堅牢化
暗号資産カードプログラムにとって最もレバレッジの高い単一の防御策は、プロセッサーとスペンディングモジュール間の承認チャネルを偽造不可能・リプレイ耐性があり・スコープを厳密に絞ったものにすることだ。具体的には、厳格なナンスと有効期限のセマンティクスを持つ署名済み承認メッセージ、あるカードを承認するメッセージが別のカードに適用されるのを防ぐドメイン分離、そしてメッセージが合成されたインプットではなく実際のネットワーク確認済み承認に対応していることをオンチェーンで検証することが必要だ。
暗号学的なプリミティブは存在する。存在しないのは、カードプロセッサーがオンチェーンモジュール向けの承認メッセージにどのように署名すべきかを規定した標準化された仕様だ。各暗号資産カードプログラムが独自のスキームを実装している。その多様性はセキュリティコストだ。各プログラムが独自の承認プロトコルを考案して監査しなければならず、ほとんどの場合それを担う小規模なチームがいる。
継ぎ目でのリアルタイム異常検出
DeFiのモニタリングは、オンチェーンテレメトリ――大型送金・異常なApproval・オラクルの偏差――を中心に成熟してきた。決済スタックには、プロセッサーとチェーンの継ぎ目にまたがるモニタリングが必要だ。オンチェーンデビットの発生率とネットワーク確認済み承認の発生率が乖離したとき、または特定カードのデビットパターンが通常の支出ではなくモジュール悪用と整合する形で歴史的基準値から逸脱したときに、ほぼリアルタイムで検出できる必要がある。
これはDeFiのモニタリングよりも、カードネットワークの不正検出がすでに機能する方法に近い。このことは、暗号資産カードプログラムにとって適切な防御パートナーは、決済サイドの後付け機能を持つDeFiネイティブなセキュリティ企業よりも、オンチェーン拡張を持つ従来型の不正検出ベンダーかもしれないことを示唆している。
限定的・時間制限・一時停止可能な承認スコープ
Gnosis Payインシデントの損失封じ込めは、承認上限のオンチェーン強制によってもたらされた。教訓は、スペンディングモジュールは狭く・時間的に限定され・一時停止可能な承認スコープを公開すべきということだ。そして一時停止する能力は、数日かかるガバナンス投票の後ろではなく、低レイテンシの対応能力を持つ複数の独立したオペレーターのもとに置くべきだ。攻撃者が承認メッセージの速度でドレインする能力と、防御者が一時停止する能力の非対称性が、継ぎ目の侵害が小規模な補填で済むか、プロジェクトを終わらせるイベントになるかを決める変数だ。
示唆と今後注目すべきこと
Gnosis Payインシデントは、Gnosis Payへの評決としてではなく、セキュリティモデルをいまだ定義しつつあるカテゴリにおける最初の記録に値するデータポイントとして読むのが最善だ。暗号資産決済カードは、消費者向けユースケースが明確であり、欧州の電子マネーライセンスという規制の道筋が整備されているため急速に普及してきた。しかし承認レイヤー・監視レイヤー・責任モデルの標準化を迫るだけの損失の歴史はまだ蓄積されていない。このインシデントはその議論を前進させるが、解決はしない。
今後数か月で注目すべき三つのことがある。
一つ目は、全額補填決断がカテゴリの規範となるか、それともトレジャリー規模のあるプロジェクト固有の対応にとどまるかだ。規範となれば、暗黙の責任はイシュアーのバランスシートに乗り、カードプログラム運営のコストはスループットとともに増大する。それはこのカテゴリの経済性を変え、自己保険が可能なほど大規模なイシュアー、またはまさにこの障害モードに対する専門保険の購入を厭わないイシュアーへの集約を加速させる可能性が高い――そしてそれは今日まだ十分に発達していない保険商品ラインだ。
二つ目は、業界がプロセッサーとモジュール間の承認に関する共有仕様に収束するかどうかだ。暗号学的な問いは対処可能だが、調整の問いはより難しい。標準があれば、プログラムごとの監査負担が下がり、専用のセキュリティツールが構築できる明確なターゲットが生まれる。標準がなければ、新しいカードプログラムが生まれるたびに同じクラスの継ぎ目リスクが再導入される。
三つ目は規制当局の解釈だ。EUの電子マネーおよび決済監督当局はこれまで、暗号資産カードプログラムを主にイシュアー事業体とそのコンプライアンス義務の観点から扱ってきた。損失の発端が規制を受けたイシュアーではなくスマートコントラクトの支出レイヤーにあるインシデントは、管轄のグレーゾーンに位置する。監督当局が支出モジュールを規制対象の決済サービスの一部と判断した場合――これは十分に筋の通った解釈だ――オンチェーンコードはDeFiがこれまで適用外で運営してきたオペレーショナルレジリエンス要件の対象になる。それはこのカテゴリの構築方法に構造的な変化をもたらすだろう。
Gnosis Payインシデントが示していないのは、暗号資産ネイティブな決済レールが機能しないということだ。示しているのは、それらがDeFi本来のものとは異なる攻撃対象を持つこと、オフチェーンプロセッサーシグナルとオンチェーンデビットの継ぎ目が最も探索されやすいその対象の部分であること、そしてオンチェーンの承認上限による損失封じ込めが継ぎ目の侵害を生存可能なイベントに変えるメカニズムであることだ。補填決断は見出しを飾る対応の部分だ。補填を現実的なコストに収めた限定されたスコープこそが、設計上の注目を受けるべき部分だ。
引言
加密支付卡在过去三年里一直被当作链上余额与日常消费之间那座低调的桥梁来营销。其底层逻辑颇具吸引力：用户将稳定币存放于智能合约账户，卡程序授权一笔 Visa 或 Mastercard 交易，结算引擎负责兑换并将法币汇付给商户收单行。Gnosis Pay 于 2023 年推出，是构建在 Gnosis Chain 上的自托管 Visa 借记产品，是这一模式较为成熟的实现之一。它将基于 Safe 的账户与一家持欧盟牌照的发卡机构结合，将支付卡视为用户链上钱包之上的可编程消费模块，而非对其进行托管包装。
2025 年底，这套架构经历了一次真实考验。一场针对 Gnosis Pay 的漏洞攻击导致受影响用户资金被盗，联合创始人 Martin Köppelmann 公开表示，Gnosis 将以自有国库资金全额赔付用户损失。从损失金额来看，与桥或借贷协议被攻击的标准相比尚属有限——但其所引发的结构性问题却不容小觑。一款支付产品所处的节点，是极少数 DeFi 协议才会触及的位置：在单笔交易流程中，它同时涉及卡网络、持牌发卡机构、商户终端、结算合约和自托管钱包。每一层都是潜在的攻击面，而其中大多数并不在行业已有的 DeFi 安全工具所覆盖的防御范围内。
本文以此事件为切入点，做三件事：第一，梳理 Gnosis Pay 的架构，定位漏洞的攻击入口；第二，将 Gnosis 全额赔付的应对方式与 Ronin、Wormhole、Euler、Radiant 事件后的处理思路做横向比较；第三，探讨这一事件对加密原生支付基础设施中期安全状况的启示——这个赛道的产品市场契合度，远超其损失历史所应有的水平。
支付技术栈不是 DeFi 技术栈
过去四年里，大多数 DeFi 漏洞可以归入几类：预言机操纵、桥接签名被攻破、借贷市场的重入或计账漏洞、治理攻击，以及多签私钥被盗。边界各异，但拓扑结构一致——单一智能合约或签名集合持有资产，攻击者找到迫使其释放资产的方法，损失在链上以一笔或几笔交易完成。
发卡产品并非这种拓扑结构。它至少是一个五层系统。最底层是用户的链上账户——以 Gnosis Pay 为例，是一个带消费模块的 Safe，该模块授予发卡机构对余额的条件性访问权限。其上是结算合约或中继器，负责将授权消费转化为发卡机构所需的形式。再上一层是发卡处理商，使用卡网络授权、清算与结算所用的 ISO 8583 报文格式进行通信。更上一层是卡网络本身——Gnosis Pay 的情况是 Visa——最顶层则是商户收单行和终端。
每一层都有其独立的信任模型。Safe 和消费模块是链上代码，可逐行审计。结算中继器通常是链下基础设施，监听授权消息并将其中介为链上扣款。发卡处理商是受监管实体，运行传统金融软件，拥有自己的卡片状态、余额和风控规则数据库。卡网络则依照拒付、争议和撤销逻辑运转，在 DeFi 中完全没有对应的概念。
由此产生的含义是：加密支付卡的攻击面并非”智能合约风险”与”卡片欺诈风险”的简单相加，而是它们的笛卡尔积。漏洞可以藏在任何一层，也可以藏在各层之间的接缝处：处理商发送给结算中继器的消息、消费模块关于谁可以授权扣款的假设、网络级授权与链上结算之间的时间窗口，或者交易在链下被撤销但链上未同步时的争议路径。这些接缝正是新型风险的藏身之所，而行业为纯 DeFi 构建的审计与监控工具，对它们几乎没有覆盖。
Gnosis Pay 设计中的风险集中点
Gnosis Pay 最核心的设计理念是用户保持自托管。卡片本身不持有余额；用户的 Safe 持有余额，模块授予卡程序在特定条件下扣款的权限。这一选择消除了加密支付卡产品历史上最大的风险——托管发卡机构破产或遭攻击导致用户余额一并损失——但也将风险转移到了消费模块，以及触发链上扣款的链下授权信号之中。
具体而言，每次刷卡时系统都必须回答一个问题：这笔授权究竟是发卡处理商针对真实、已经网络确认的卡交易发出的合法请求，还是别的什么？对这个问题的判断一旦出错，无论偏向哪侧都是致命的。授权过于宽松，能触达授权通道的攻击者就可以在从未碰过真实卡片的情况下清空钱包；授权过于严苛，合法交易就会被拒绝，产品直接失效。此次漏洞，似乎正是在这个问题上出了差错。
从公开信息还原漏洞经过
我们刻意保持这一部分的保守态度。Gnosis Pay 事件的详细根因分析报告在撰写本文时仍在最终确认中，对于尚未得到证实的技术细节，我们不会妄加推断。我们能做的，是勾勒出与已披露事实相符的那类故障模式，并以此推演防御思路。
已公开的信息：与 Gnosis Pay 相关的漏洞导致用户损失；Gnosis 声明将以国库资金全额吸收这些损失；受影响范围足够有限，使该团队判断无需外部追偿，可自筹资金完成赔付。损失的描述并非源于卡网络欺诈（即实体卡被盗或被读卡器复制），也非用户私钥泄露，更非 Safe 层面的签名被攻破。这大幅缩窄了候选的故障模式。
剩余的攻击面——模块逻辑、授权管道，以及链下处理商信号与链上扣款之间的接缝——恰恰是我们上文指出的历史上防御最薄弱的部分。此类接缝处的漏洞通常以三种形式出现。
第一种是授权重放或伪造：攻击者找到办法制造消费模块视为来自合法处理商的授权消息，可能通过复用此前签名过的消息、利用 nonce 或域分离不足，或者攻破链下路径中的某个签名密钥来实现。链上代码做了它被要求做的事，失误发生在上游。
第二种是模块权限范围蔓延：消费模块被授予了超出卡程序实际所需的更宽泛的许可，攻击者一旦触达授权通道，就能利用这部分多余的权限扣除超过任何单笔合法交易所允许的金额。这是 EVM 版本的”无单笔限额的卡片”。
第三种是兑换或手续费处理中的边界逻辑漏洞：模块在计算扣款金额、外汇换算或中继器手续费时存在缺陷，形成无需任何签名伪造的价值提取路径——只需一组精心构造的、看似合法的输入序列即可。
我们不清楚上述哪种情况——或哪种组合——适用于 Gnosis Pay 此次事件。但三者共同具备一个对后续分析至关重要的特点：它们都不是标准 DeFi 审计（聚焦于单一合约不变量）所擅长发现的漏洞类型。它们存在于合约代码与链下信任假设的交互之中，需要截然不同的审查方法论。
为何损失得以收敛
Gnosis Pay 设计中一个看起来确实发挥作用的机制是损失遏制。卡程序在卡网络层面受制于每张卡的每日限额，消费模块也在链上强制执行这些限额。无论攻击入口在哪，攻击者都无法一次性清空程序所连接的每一个 Safe；他们受限于程序的授权包络。这正是此次事件损失金额最终在项目可以自行吸收的范围之内，而非威胁其生存的原因。接缝被突破了，但速率限制守住了。
这一点值得深思，因为它是最有可能普遍推广的设计经验。链上强制执行授权上限——按卡、按时间窗口、按商户类别——是一种低成本、已被充分理解的机制，它将”任何接缝被攻破即一切尽失”的故障模式，转变为”任何接缝被攻破只损失有上限的金额，期间程序可暂停”。这是一种生存能力强得多的安全姿态。
全额赔付决策的背景解读
Köppelmann 关于 Gnosis 将全额覆盖受影响用户损失的声明，将此次事件归入了一个数量有限、颇具特殊性的加密行业事后处置案例类别。漏洞发生后的赔付决策存在一个光谱，团队落在光谱哪个位置，是了解其如何定位自身产品的最强信号之一。
光谱的一端是 Ronin（2022 年 3 月，约 6.2 亿美元从 Axie 侧链桥中被盗）。运营方 Sky Mavis 获得由 Binance 领投的 1.5 亿美元融资，承诺让用户免于损失，将此次事件定性为存亡级别的品牌危机，而非局部产品问题。赔付依靠外部资金，历时数周。
Wormhole（2022 年 2 月，约 3.2 亿美元）由 Jump Crypto 在约一天内完成赔付，实质上是一家做市商为保护自己所依赖的桥的完整性而自行吸收了损失。能做到这一点，取决于那时碰巧是谁在为该桥兜底，并非可复制的通用模式。
Euler（2023 年 3 月，约 2 亿美元）在经过链上与链下与攻击者的谈判后，实现了近乎完整的资产追回——这一结果高度依赖于该事件的特殊背景，不具备可复制的模板意义。
Radiant Capital（2024 年 10 月，约 5000 万美元）团队承诺了追偿计划并持续追踪，但初期应对并非全额自筹赔付；项目的资金储备和国库根本无法支撑这一选项。
Gnosis Pay 的处理方式在精神上最接近 Wormhole——拥有资产负债表的实体吸收了一笔有限的损失，以维护其作为所依赖产品天然兜底方的信誉——但资金规模与来源均有所不同。Gnosis 并非一家做市商介入；它是底层链的发行方，一个拥有国库储备的长期项目，主动选择将这笔损失视为运营一款要求用户信任多层复杂技术栈的支付产品的成本。
赔付信号的含义
对于支付漏洞发生后全额赔付的决定，至少有三种解读，且三者并不互斥。
第一种是声誉经济学：支付产品承受不起哪怕轻微的未赔付损失，因为它的竞争对象是法币支付工具，而后者的用户预期是零损失暴露。Visa 自身的拒付制度设定了这条基准线。一张以自托管包装的名义将损失转嫁给用户的加密支付卡，在结构上就是竞争不过不这样做的产品，无论哪种设计在技术上更”纯粹”。
第二种是承受能力：损失相对于国库规模足够小，吸收它比其他替代方案更划算。这适用于 Gnosis Pay 的情况，也适用于 Wormhole；但不适用于 Ronin，这也是 Ronin 需要外部资本的原因。
第三种是责任框架的界定：通过全额赔付，项目传达出一个信号：它将消费模块和授权层视为自身基础设施的一部分，而非用户的自负风险。在这一框架下，自托管意味着用户掌管自己 Safe 的密钥——但卡程序安装在该 Safe 中的模块的安全性，属于项目的责任范畴。这是一条有实质意义的边界，且比 DeFi 对智能合约风险的思维方式更接近受监管支付系统已有的发卡机构责任逻辑。
我们认为第三种解读影响最为深远。一款明确承担消费层安全责任的加密支付卡产品，所做出的承诺与典型 DeFi 协议截然不同，所承受的成本结构也不同——它随产品流量的增长而扩大，而非随任何单一合约的 TVL 扩大。随着 Gnosis Pay 规模增长，这种成本结构是否具有可持续性，是我们在文末将要回归的开放性问题之一。
这类产品需要 DeFi 工具所不具备的能力
支付技术栈所要求的防御姿态，与借贷市场或 DEX 所要求的姿态，在类型上就有所不同，而不仅仅是程度上的差异。三类能力尤为突出。
授权通道加固
对加密支付卡程序来说，单一杠杆效率最高的防御措施，是让处理商与消费模块之间的授权通道做到不可伪造、抗重放，且权限范围严格受限。具体而言，这意味着带有严格 nonce 和过期语义的签名授权消息、防止授权一张卡的消息被应用于另一张卡的域分离，以及链上验证确保消息对应的是真实的、已经网络确认的授权，而非合成输入。
实现这些的密码学原语已经存在。目前缺乏的，是任何标准化形式的规范，来定义卡处理商应如何对发往链上模块的授权消息进行签名。每个加密支付卡程序都在实现自己的方案。这种多样性是一种安全成本：每个程序都必须独立发明并审计自己的授权协议，而承担这项工作的大多数是小团队。
接缝处的实时异常检测
DeFi 监控体系已围绕链上遥测逐步成熟——大额转账、异常授权、预言机偏差。支付技术栈需要的监控，要跨越处理商与链之间的接缝。它需要近乎实时地检测：链上扣款速率何时偏离网络已确认的授权速率，或某张卡的扣款模式何时以与模块滥用而非正常消费相符的方式偏离历史基线。
这更接近卡网络欺诈检测的运作方式，而非 DeFi 监控的运作方式。这也意味着，加密支付卡程序合适的防御合作伙伴，或许是拥有链上扩展能力的传统欺诈检测服务商，而非在支付侧打了补丁的 DeFi 原生安全公司。
有边界、可暂停的授权范围
Gnosis Pay 事件的损失遏制，源自链上对授权限额的强制执行。这带来的经验是：消费模块应暴露狭窄、有时效、可暂停的授权范围——而且暂停能力应分散于多个具有低延迟响应能力的独立运营者手中，而非藏在一个需要数日才能完成的治理投票之后。攻击者耗尽授权消息的速度与防御者暂停响应的速度之间的不对称，决定了一次接缝被突破究竟是一笔小额赔付，还是一场项目终结事件。
影响与值得关注的方向
Gnosis Pay 事件最好被理解为：不是对 Gnosis Pay 本身的最终评判，而是一个仍在定义自身安全模型的赛道中，第一个有据可查的数据点。加密支付卡推进迅速，因为消费者使用场景一目了然，通过欧洲电子货币牌照的合规路径也已相对成熟。这些产品尚未积累足够的损失历史，以推动授权层、监控层或责任模型的标准化。此次事件推动了相关讨论，但尚未给出答案。
以下三个方向值得在未来数月持续关注。
第一，全额赔付决策是否会成为行业惯例，还是仍然只限于有足够国库深度的项目。若成为惯例，隐性责任就落在了发卡机构的资产负债表上，运营一个支付卡程序的成本将随吞吐量上升。这将改变该赛道的经济逻辑，并可能加速整合——向足够大、能够自保的发卡机构，或愿意为这一特定故障模式购买专项保险的机构集中。而目前，这类专项保险产品尚不成熟。
第二，行业是否会就处理商到模块的授权协议形成共同规范。密码学层面的问题是可解的；协调层面的问题更难。一套标准将降低每个程序的审计负担，并为专用安全工具的构建提供明确靶点。若缺乏标准，每一个新的支付卡程序都将重新引入同一类接缝风险。
第三，监管机构的解读。欧盟电子货币和支付监管机构迄今主要从发卡实体及其合规义务的视角审视加密支付卡程序。而此次事件中，损失源自智能合约消费层，而非受监管的发卡机构，这落在一个监管灰色地带。若监管机构认定消费模块属于受监管支付服务的一部分——这是一种有据可依的解读——则链上代码将受制于 DeFi 迄今在其之外运作的运营韧性要求。这将是这一赛道建设方式的结构性转变。
Gnosis Pay 事件所未揭示的是：加密原生支付基础设施不可行。它揭示的是：这类基础设施拥有与 DeFi 本身不同的攻击面；链下处理商信号与链上扣款之间的接缝，是该攻击面中最容易被探测的部分；而通过链上授权限额实现的损失遏制，是将接缝被突破转化为可存活事件的关键机制。全额赔付决策是此次应对中占据头条的部分，而让赔付在经济上可行的有界授权范围设计，才是真正值得深入关注的部分。
Introducción
Las tarjetas de pago cripto llevan casi tres años comercializándose como el puente silencioso entre los saldos onchain y el gasto cotidiano. La propuesta tiene una lógica estructural atractiva: el usuario mantiene stablecoins en una cuenta de contrato inteligente, un programa de tarjeta autoriza una transacción Visa o Mastercard, y un motor de liquidación convierte y transfiere fiat al adquirente del comercio. Gnosis Pay, lanzado en 2023 como producto de débito Visa con autocustodia construido sobre Gnosis Chain, es una de las implementaciones más reflexivas de ese modelo. Combina una cuenta basada en Safe con un emisor con licencia en la UE, y trata la tarjeta como un módulo de gasto programable sobre la wallet onchain del usuario, en lugar de envolverla en una capa custodial.
A finales de 2025, esa arquitectura fue puesta a prueba. Un exploit dirigido a Gnosis Pay drenó fondos de los usuarios afectados, y el cofundador Martin Köppelmann declaró públicamente que Gnosis cubriría todas las pérdidas de sus propias reservas. La magnitud en dólares fue modesta para los estándares de los exploits de bridge o de mercados de préstamos, pero las preguntas estructurales que plantea no lo son en absoluto. Un producto de pagos se sitúa en una encrucijada que muy pocos protocolos DeFi ocupan: en una sola cadena de transacciones confluyen una red de tarjetas, un emisor regulado, una terminal de comercio, un contrato de liquidación y una wallet con autocustodia. Cada uno de esos elementos es una superficie de ataque, y la mayor parte de ellas no están en el perímetro que las herramientas de seguridad DeFi han sido diseñadas para defender.
Utilizamos este incidente para tres propósitos. Primero, trazamos la arquitectura de Gnosis Pay e identificamos el punto por donde parece haber entrado el exploit. Segundo, comparamos la respuesta de reembolso total de Gnosis con los manuales empleados tras Ronin, Wormhole, Euler y Radiant. Tercero, nos preguntamos qué dice el incidente sobre la postura de seguridad a medio plazo de los sistemas de pago nativos cripto, una categoría que tiene más encaje en el mercado del que su historial de pérdidas sugeriría.
Un stack de pagos no es un stack DeFi
La mayoría de los exploits DeFi de los últimos cuatro años pueden clasificarse en un número reducido de categorías: manipulación de oráculos, compromiso de firmas en bridges, bugs de reentrada o de contabilidad en mercados de préstamos, captura de gobernanza y robo de claves privadas de multisigs. Los límites difieren, pero la topología es consistente: un único contrato inteligente o conjunto de firmantes custodia valor, el atacante encuentra la manera de hacerlo liberarlo, y la pérdida se materializa onchain en una o pocas transacciones.
Un producto de emisión de tarjetas no tiene esa topología. Es, como mínimo, un sistema de cinco capas. En la base está la cuenta onchain del usuario; en el caso de Gnosis Pay, un Safe con un módulo de gasto que concede al emisor acceso condicional a los saldos. Por encima hay un contrato de liquidación o relayer que convierte el gasto autorizado en la forma que necesita el emisor. Sobre eso se sitúa el issuer-processor, que habla el formato de mensajes ISO 8583 que las redes de tarjetas emplean para autorización, compensación y liquidación. Por encima está la propia red de tarjetas —Visa, en el caso de Gnosis Pay— y, por último, el adquirente del comercio y la terminal.
Cada una de esas capas tiene su propio modelo de confianza. El Safe y el módulo de gasto son código onchain, auditable línea a línea. El relayer de liquidación suele ser infraestructura off-chain que escucha los mensajes de autorización y los canaliza hacia débitos onchain. El issuer-processor es una entidad regulada que ejecuta software financiero tradicional, con su propia base de datos de estados de tarjeta, saldos y reglas de riesgo. Las redes operan bajo una lógica de contracargos, disputas y reversiones que no tiene equivalente en DeFi.
La implicación es que la superficie de ataque de una tarjeta de pago cripto no es la unión del “riesgo de contrato inteligente” y el “riesgo de fraude con tarjeta”, sino su producto cruzado. Una vulnerabilidad puede existir en cualquiera de las capas, pero también puede estar en las costuras entre ellas: en el mensaje que el procesador envía al relayer de liquidación, en el supuesto que el módulo de gasto hace sobre quién puede autorizar un débito, en la ventana temporal entre una autorización a nivel de red y la liquidación onchain, o en la vía de disputa cuando una transacción se revierte off-chain pero no onchain. En esas costuras habita la novedad, y no están bien cubiertas por el stack de auditoría y monitorización que la industria ha construido para DeFi puro.
Dónde concentra riesgo el diseño de Gnosis Pay
La decisión de diseño más destacada de Gnosis Pay es que el usuario conserva la custodia. La tarjeta no mantiene un saldo; lo hace el Safe del usuario, y un módulo otorga al programa de tarjeta el derecho a debitarlo bajo condiciones específicas. Esa decisión elimina el mayor riesgo histórico de los productos de tarjeta cripto —que el emisor custodial quiebre o sea hackeado y arrastre los saldos de los usuarios—, pero traslada el riesgo hacia el módulo de gasto y hacia las señales de autorización off-chain que desencadenan los débitos.
En la práctica, el sistema debe responder una pregunta en cada pasada de tarjeta: ¿es esta autorización una solicitud legítima del issuer-processor para una transacción real confirmada por la red, o es otra cosa? Equivocarse en esa respuesta, en cualquier dirección, es letal. Aprobar con demasiada laxitud permite que un atacante que alcance el canal de autorización vacíe wallets sin tocar jamás una tarjeta real. Aprobar con demasiada restricción hace que las transacciones legítimas fallen, destruyendo el producto. El exploit parece haber habitado precisamente en esa pregunta.
El exploit, reconstruido a partir de lo que es público
Mantenemos deliberadamente esta sección en un tono conservador. Los análisis detallados de la causa raíz del incidente de Gnosis Pay seguían finalizándose en el momento de escribir este artículo, y no atribuiremos mecánicas que no hayan sido confirmadas. Lo que podemos hacer es esbozar la clase de fallo coherente con los hechos divulgados y utilizarla para razonar sobre las defensas.
Lo que es público: un exploit relacionado con Gnosis Pay causó pérdidas a usuarios; Gnosis declaró que absorbería esas pérdidas íntegramente de sus reservas; el alcance afectado fue lo suficientemente limitado como para que la empresa considerara factible el reembolso con fondos propios, sin necesidad de acciones externas de recuperación. Las pérdidas no fueron descritas como el resultado de fraude en la red de tarjetas (es decir, una tarjeta física robada o un skimmer), ni como la vulneración de claves privadas de usuarios, ni como un compromiso de firmas a nivel de Safe. Eso reduce significativamente los modos de fallo candidatos.
La superficie restante —lógica del módulo, tuberías de autorización y la costura entre las señales del procesador off-chain y los débitos onchain— es exactamente la parte del stack que identificamos anteriormente como históricamente poco defendida. Un exploit en esta costura suele adoptar una de tres formas.
La primera es la repetición o falsificación de autorizaciones: el atacante encuentra la manera de producir mensajes de autorización que el módulo de gasto acepta como si procedieran del procesador legítimo, ya sea reutilizando mensajes firmados anteriormente, explotando una separación de nonces o dominios insuficiente, o comprometiendo una clave de firma en la ruta off-chain. El código onchain hace exactamente lo que se le pidió; el fallo está aguas arriba.
La segunda es la expansión del alcance del permiso del módulo: el módulo de gasto recibe asignaciones más amplias de las que el programa de tarjeta necesita, y un atacante que alcance el canal de autorización puede usar ese exceso para debitar más de lo que cualquier transacción legítima individual habría permitido. Es el análogo en EVM de una tarjeta sin límite por transacción.
La tercera es la lógica de casos extremos en la conversión o gestión de comisiones: un bug en la forma en que el módulo calcula el importe del débito, la conversión de divisas o la comisión del relayer crea un camino de extracción de valor que no requiere falsificación de firmas, sino únicamente una secuencia diseñada de entradas de aspecto legítimo.
No sabemos cuál de estas formas —ni qué combinación— se aplica al caso de Gnosis Pay. Pero las tres comparten una propiedad que importa para el resto de este análisis: ninguna es el tipo de bug que una auditoría DeFi estándar, centrada en los invariantes de un único contrato, está bien equipada para detectar. Viven en la interacción entre el código del contrato y los supuestos de confianza off-chain, y exigen una disciplina de revisión diferente.
Por qué la pérdida fue acotada
Una característica del diseño de Gnosis Pay que parece haber funcionado es la contención de pérdidas. Los programas de tarjeta operan bajo límites diarios por tarjeta impuestos por la red, y el módulo de gasto hace cumplir esos límites onchain. Cualquiera que haya sido el vector de entrada, el atacante no podía simplemente vaciar todos los Safes conectados al programa en una sola transacción; estaba acotado por el perímetro de autorización del programa. Esta es la razón estructural por la que el incidente se describe con cifras en dólares que el proyecto puede absorber, en lugar de cifras que amenacen su solvencia. La costura fue vulnerada, pero el límite de tasa aguantó.
Vale la pena detenerse en esto, porque es la lección de diseño con más probabilidad de generalizarse. La aplicación onchain de límites de autorización —por tarjeta, por ventana temporal, por categoría de comercio— es un mecanismo barato y bien comprendido, y convierte un modo de fallo de “cualquier vulneración de la costura lo drena todo” en uno de “cualquier vulneración de la costura drena una cantidad acotada antes de que el programa pueda pausarse”. Esa es una postura mucho más resiliente.
La decisión de reembolso total en contexto
La declaración de Köppelmann de que Gnosis cubriría todas las pérdidas de los usuarios afectados sitúa el incidente en una categoría pequeña y específica de post-mortems cripto. Las decisiones de reembolso tras exploits se distribuyen a lo largo de un espectro, y el lugar donde un equipo se posiciona en ese espectro es una de las señales más elocuentes disponibles sobre cómo entiende su propio producto.
En un extremo está Ronin (marzo de 2022, alrededor de 620 millones de dólares drenados del bridge de la cadena lateral de Axie). Sky Mavis, el operador, aseguró una ronda de 150 millones de dólares liderada por Binance y se comprometió a indemnizar a los usuarios, tratando la pérdida como un evento existencial de marca más que como un problema de producto contenido. El reembolso se financió externamente y tardó semanas.
Wormhole (febrero de 2022, alrededor de 320 millones de dólares) fue reembolsado por Jump Crypto en aproximadamente un día, en lo que fue efectivamente un market maker absorbiendo la pérdida para preservar la integridad de un bridge del que dependía. La capacidad de hacer esto era función de quién resultó ser el respaldo del bridge, no un modelo generalizable.
Euler (marzo de 2023, alrededor de 200 millones de dólares) terminó con una recuperación casi completa tras negociaciones on- y off-chain con el atacante, un resultado que dependió de circunstancias específicas de ese incidente y no constituye una plantilla.
Radiant Capital (octubre de 2024, alrededor de 50 millones de dólares) vio al equipo comprometerse con un plan de recuperación y un rastreo continuo, pero la postura inmediata no fue el reembolso total con fondos propios; el runway y las reservas del proyecto simplemente no lo permitían.
La posición de Gnosis Pay es más cercana en espíritu a la de Wormhole —una entidad con balance propio absorbiendo una pérdida contenida para preservar la confianza en un producto del que es el respaldo natural—, pero la escala y la fuente de los fondos son distintas. Gnosis no es un market maker que interviene; es el emisor de la cadena subyacente y un proyecto consolidado con reservas de tesorería, que elige tratar la pérdida como el coste de operar un producto de pagos que, por diseño, pide a los usuarios que confíen en un stack complejo de múltiples capas.
Lo que nos dice la señal del reembolso
Hay al menos tres lecturas de una decisión de reembolso total tras un exploit de pagos, y no son mutuamente excluyentes.
La primera es la economía reputacional: un producto de pagos no puede tolerar ni siquiera pérdidas modestas sin reembolsar, porque compite contra instrumentos de pago fiat donde el usuario espera cero exposición a pérdidas. El propio régimen de contracargos de Visa fija la línea de base. Una tarjeta cripto que traslada pérdidas a los usuarios bajo una envoltura de autocustodia es estructuralmente poco competitiva respecto a una que no lo hace, independientemente de qué diseño sea técnicamente más “puro”.
La segunda es la viabilidad económica: la pérdida fue lo suficientemente pequeña en relación con las reservas como para que absorberla resulte más barato que la alternativa. Esto es cierto en el caso de Gnosis Pay y lo fue en el de Wormhole; no lo fue en el de Ronin, que por eso requirió capital externo.
La tercera es el encuadre de responsabilidad: al reembolsar en su totalidad, el proyecto comunica que trata el módulo de gasto y la capa de autorización como infraestructura propia, no del usuario. La autocustodia, en este encuadre, significa que el usuario controla las claves de su Safe, pero la seguridad del módulo que el programa de tarjeta instala en ese Safe es responsabilidad del proyecto. Ese es un límite significativo de trazar, y está más cerca de cómo los sistemas de pago regulados ya piensan sobre la responsabilidad del emisor que de cómo DeFi piensa sobre el riesgo de los contratos inteligentes.
Consideramos que la tercera lectura es la más relevante. Un producto de tarjeta cripto que acepta explícitamente la responsabilidad sobre la seguridad de la capa de gasto está haciendo una promesa diferente a la de un protocolo DeFi típico. También se expone a una estructura de costes distinta, una que escala con el valor que fluye a través del producto, no con el TVL de ningún contrato individual. Si esa estructura de costes es sostenible a medida que Gnosis Pay crece es una de las preguntas abiertas a las que volvemos al final.
Lo que esta categoría de producto necesita y las herramientas DeFi no ofrecen
La postura defensiva que requiere un stack de pagos es diferente en naturaleza, no solo en grado, respecto a la que necesita un mercado de préstamos o un DEX. Tres categorías de capacidad destacan.
Fortalecimiento del canal de autorización
La defensa de mayor apalancamiento para un programa de tarjeta cripto es hacer que el canal de autorización entre el procesador y el módulo de gasto sea infalsificable, resistente a la repetición y con un alcance estrictamente delimitado. En la práctica esto implica mensajes de autorización firmados con semántica estricta de nonce y caducidad, separación de dominio que impida que un mensaje que autoriza una tarjeta se aplique a otra, y verificación onchain de que el mensaje corresponde a una autorización real y reconocida por la red, y no a una entrada sintética.
Los primitivos criptográficos para esto existen. Lo que no existe, en ninguna forma estandarizada, es una especificación compartida sobre cómo un procesador de tarjetas debe firmar los mensajes de autorización destinados a un módulo onchain. Cada programa de tarjeta cripto implementa su propio esquema. Esa diversidad tiene un coste en seguridad: cada programa debe inventar y auditar su propio protocolo de autorización, y la mayoría lo hacen con equipos pequeños.
Detección de anomalías en tiempo real en la costura
La monitorización en DeFi ha madurado en torno a la telemetría onchain: transferencias de gran valor, aprobaciones inusuales, desviaciones de oráculos. Un stack de pagos necesita monitorización que abarque la costura entre el procesador y la cadena. Debe detectar, en tiempo casi real, cuándo la tasa de débitos onchain diverge de la tasa de autorizaciones confirmadas por la red, o cuándo el patrón de débitos de una tarjeta individual se aparta de su línea de base histórica de una manera coherente con el abuso del módulo más que con el gasto normal.
Esto se aproxima más a cómo la detección de fraude en redes de tarjetas ya funciona que a cómo funciona la monitorización DeFi, y sugiere que los socios defensivos adecuados para los programas de tarjeta cripto pueden ser proveedores tradicionales de detección de fraude con extensiones onchain, en lugar de empresas de seguridad nativas de DeFi con complementos para el lado de los pagos.
Alcances de autorización acotados, pausables
La contención de pérdidas en el incidente de Gnosis Pay provino de la aplicación onchain de límites de autorización. La lección es que el módulo de gasto debe exponer alcances de autorización estrechos, acotados en el tiempo y pausables, y que la capacidad de pausar debe residir en múltiples operadores independientes con capacidad de reacción de baja latencia, y no detrás de un voto de gobernanza que tarda días. La asimetría entre la capacidad de un atacante para drenar a la velocidad de los mensajes de autorización y la capacidad de un defensor para pausar es la variable que decide si una vulneración de la costura es un reembolso menor o un evento que destruye el proyecto.
Implicaciones y qué vigilar
El incidente de Gnosis Pay se lee mejor no como un veredicto sobre Gnosis Pay en particular, sino como el primer dato bien documentado en una categoría que todavía está definiendo su modelo de seguridad. Las tarjetas de pago cripto han llegado al mercado rápidamente porque el caso de uso para el consumidor es obvio y el camino regulatorio a través de las licencias de dinero electrónico europeas está bien trazado. Aún no han acumulado el historial de pérdidas que forzaría la estandarización de la capa de autorización, la capa de monitorización o el modelo de responsabilidad. Este incidente impulsa esa conversación hacia adelante, pero no la resuelve.
Tres cosas merecen atención en los próximos meses.
La primera es si la decisión de reembolso total se convierte en una norma de categoría o si permanece como algo específico de proyectos con profundidad de tesorería. Si se convierte en norma, la responsabilidad implícita recae sobre los balances de los emisores, y el coste de operar un programa de tarjeta aumenta con el volumen. Eso cambia la economía de la categoría y probablemente acelera la consolidación en torno a emisores lo suficientemente grandes como para autoasegurarse o dispuestos a contratar un seguro especializado contra exactamente este modo de fallo, que hoy no es una línea de producto bien desarrollada.
La segunda es si la industria converge en una especificación compartida para la autorización de procesador a módulo. La pregunta criptográfica es tratable; la de coordinación es más difícil. Un estándar reduciría la carga de auditoría por programa y crearía un objetivo para el que se puedan construir herramientas de seguridad dedicadas. Sin uno, cada nuevo programa de tarjeta reintroduce la misma clase de riesgo en la costura.
La tercera es la lectura regulatoria. Los supervisores de dinero electrónico y pagos de la UE han tratado hasta ahora los programas de tarjeta cripto principalmente desde la perspectiva de la entidad emisora y sus obligaciones de cumplimiento. Un incidente en el que la pérdida se origina en la capa de gasto del contrato inteligente, y no en el emisor regulado, se sitúa en una zona gris jurisdiccional. Si los supervisores deciden que el módulo de gasto forma parte del servicio de pago regulado —una lectura defendible—, entonces el código onchain quedaría sujeto a requisitos de resiliencia operativa fuera de los cuales DeFi ha operado hasta ahora. Eso supondría un cambio estructural en cómo se construye esta categoría.
Lo que el incidente de Gnosis Pay no muestra es que los sistemas de pago nativos cripto sean inviables. Muestra que tienen una superficie de ataque diferente a la de DeFi propiamente dicho, que la costura entre las señales del procesador off-chain y los débitos onchain es la parte de esa superficie con más probabilidad de ser sondada, y que la contención de pérdidas mediante límites de autorización onchain es el mecanismo que convierte una vulneración de la costura en un evento del que se puede sobrevivir. La decisión de reembolso es la parte de la respuesta que acapara los titulares. El alcance acotado que hizo el reembolso asequible es la parte que merece la atención en el diseño.