Gnosis Moves to Contain Active Exploit Affecting Gnosis Pay

What Happened To Gnosis Pay?

Gnosis is working to contain an active exploit affecting its Gnosis Pay product after co-founder Martin Köppelmann acknowledged a hack involving the system’s delay module and said the project would cover user losses. Köppelmann initially urged users to withdraw funds, a warning later amplified by blockchain security firm PeckShield, which said users were strongly advised to withdraw all funds, including EURe and GNO, and check their exposure. The guidance then changed. Köppelmann deleted the initial warning and said most users would not be able to withdraw their funds. He later said the Gnosis team is “actively working to contain the damage” and pledged that users would be made whole. That commitment may limit user losses, but it does not answer the central technical questions: how much has been stolen, which contracts or users were affected, and whether the weakness sits in the Zodiac delay module, its deployment inside Gnosis Pay, or the wider system design. Gnosis is one of the older Ethereum infrastructure projects, known for smart contract wallet tools and Gnosis Chain, an Ethereum Virtual Machine-compatible network used for payments and decentralized finance. That makes the incident more sensitive than a typical protocol exploit because Gnosis Pay sits close to the user-facing payments layer rather than only a DeFi yield product.

Why Is The Delay Module Under Scrutiny?

The exploit has drawn attention to the role of the delay module, a security component meant to queue transactions before execution. In theory, a delay layer gives users or operators time to detect and stop suspicious activity before funds move. In practice, the incident suggests that shared transaction infrastructure can become a concentration point if an attacker finds a way to push malicious withdrawals into user queues. Former Near protocol core developer Vadim Zacodil said Gnosis Pay’s design routes user self-custody through a shared delay layer that queues outgoing transactions from many Safes at once. Under that structure, a bug or exploit can place malicious withdrawals into thousands of user queues at the same time, even if individual private keys are not compromised. That distinction matters for investors and users assessing self-custody claims. The assets may still sit in smart contract accounts controlled by users, but operational safety can depend on shared modules, relayers, transaction queues, and the project team’s ability to pause or contain malicious execution. In this case, the effective protection appears to come from Gnosis’s ability to intervene at the infrastructure level and commit treasury resources to cover losses. That is helpful for affected users, but it also shows that self-custody products can still carry platform-level risk when common modules handle critical transaction flow.

Investor Takeaway

The Gnosis Pay incident shows that smart wallet security depends on more than private key control. Shared modules, transaction delays, and platform-operated infrastructure can create failure points that affect many users at once.

How Does This Affect Trust In Smart Wallet Infrastructure?

The incident lands at a difficult time for smart contract wallet infrastructure. It follows a separate exploit involving a third-party module connected to Safe, the wallet infrastructure originally incubated within the Gnosis ecosystem and now developed separately by Safe Labs. In that earlier case, a SquidRouterModule contract interacting with Safe wallets was abused to drain about $3.2 million from roughly 86 Safes across Ethereum and Base. Safe Labs and Squid said the vulnerability was outside their core protocols, but the episode still placed attention on the risks created by external modules built around widely used wallet systems. The Gnosis Pay exploit reinforces the same market concern. Smart wallets are becoming central to crypto payments, account abstraction, treasury management, and institutional DeFi access. Their appeal comes from programmability, recovery tools, spending controls, and more flexible transaction logic than standard wallets. But those same features require additional contracts and modules that must be configured correctly and monitored continuously. For users, the risk is not always obvious. A wallet may appear self-custodial while still relying on shared infrastructure for delayed execution, routing, automation, or cross-application permissions. If that shared layer fails, the damage can spread across many accounts before users understand their exposure.

What Are The Market Implications?

The immediate market impact depends on the final loss figure, which contracts were affected, and whether Gnosis identifies the issue as a configuration problem or a deeper architectural flaw. Until those details are public, the incident remains an open risk event for Gnosis Pay and related infrastructure. For Gnosis, the pledge to make users whole may reduce reputational damage if executed quickly and transparently. But covering losses is only the first step. The project still needs to explain the exploit path, the affected module behavior, why the initial withdrawal guidance changed, and what controls will prevent a repeat incident. For the wider market, the incident may increase due diligence on wallet modules and payment products that advertise self-custody. Exchanges, fintech partners, and institutional users will likely focus less on whether a wallet is technically non-custodial and more on which shared contracts can move, delay, or queue user funds. The timing is also notable because crypto exploit losses had recently fallen. CertiK data showed total losses dropped to about $68.3 million in May, down roughly 90% from April and marking the third month this year with losses below $100 million. A high-profile incident affecting a payments product could shift attention back to infrastructure risk even as aggregate exploit losses had been falling. The key lesson is that wallet security is becoming a systems question. Private keys, Safe accounts, modules, relayers, and emergency controls all form one risk stack. The Gnosis Pay exploit shows that when one shared layer breaks, self-custody alone may not be enough to protect users from coordinated withdrawals.