Daily Crypto Briefs 
CASABLANCA, June 6, 2026
Gnosis Pay Safes were drained of about $265,000 in EURe and GNO after attackers exploited a Delay Module signature-verification flaw, CertiK said, putting fresh scrutiny on the smart-contract plumbing behind self-custody crypto payment cards.
The June 1 incident affected Gnosis Pay accounts on Gnosis Chain, where users hold funds in Safe smart accounts rather than a normal custodial card balance. The attack did not require a conventional exchange breach; it abused the module path that helps Gnosis Pay authorize delayed card-related transactions.
Market snapshot: CertiK’s incident analysis said the attacker deployed 41 attack contracts on May 29, queued 41 transactions on June 1, then executed them after the module cooldown. The stolen assets were EURe and GNO, and CertiK said the exploit wallet later bridged about $246,000 in USDT from Ethereum to Hyperliquid.
CertiK said “the attack vector was a signature-verification flaw” in the Gnosis Pay Delay Module. The firm said the module accepted malicious transactions as authorized after crafted calldata pushed verification through a Biconomy Safe and an attacker-controlled contract.
The timing matters because payment-card crypto products are moving from novelty to infrastructure. Daily Crypto Briefs recently covered MetaMask’s Mastercard crypto card rollout, and Gnosis Pay sits in the same broader race to make wallet balances spendable at real-world merchants.
The practical issue is not whether self-custody failed in principle. It is whether the programmable layers added for convenience, spending limits, transaction delays and card settlement create a larger surface that users can misread as simple wallet safety.
What remains unknown from the public materials reviewed Saturday is the final reimbursement timeline, whether Gnosis Pay or Zodiac will publish a fuller post-mortem, and what permanent module changes will be required before affected card-linked Safes return to normal operation.
CertiK Traces Gnosis Pay Exploit
CertiK’s report described a staged attack that started before funds moved. The attacker deployed 41 specialized contracts on May 29 and used them on June 1 to make the Delay Module accept transactions that should not have passed authorization checks.
The technical hinge was EIP-1271, a standard that lets smart contracts validate signatures. In plain terms, the attacker built contracts that returned the value the verifier expected, then used nested signature data so the Delay Module checked the wrong path.
CertiK said the module’s moduleTxSignedBy() function parsed r, s and v values from attacker-controlled msg.data. That allowed the verification process to move through a legitimate Biconomy Safe before reaching an attacker-controlled contract that always returned the EIP-1271 magic value.
After the transactions were queued, the attacker waited out the cooldown and executed each transfer. CertiK said the result was 41 transactions moving EURe and GNO from affected Gnosis Pay Safes to attacker wallets.
The loss size is modest compared with the largest DeFi exploits, but the search interest is likely stronger than the dollar amount suggests. The victim product connects crypto wallets to payment-card use, and the affected tokens were not obscure test assets. They were payment and ecosystem assets inside a consumer-facing account model.
Delay Module Weakness Hits Card Safes
Gnosis Pay’s account documentation says the product uses Delay and Roles modules to enforce spending rules and transaction flows. The Delay Module is designed to add a three-minute delay to non-card transactions, while the Roles Module defines which assets, limits and recipients are allowed.
That design is meant to reconcile two goals that often pull against each other: users want to keep custody of funds, but card payments need delegated execution so a purchase can move through the payment network without the user manually signing every step at checkout.
Gnosis Pay’s account documentation says each user receives a Safe smart-contract wallet deployed on Gnosis Chain and that funds are never held by Gnosis Pay or a third party. The same documentation says modules extend Safe functionality and enforce spending rules while keeping funds in self-custody.
This is where the incident becomes more important than a normal hot-wallet theft. A self-custody product can still rely on contracts that decide when a transfer is valid, who can initiate it and which fallback handlers are trusted. If that logic is wrong, the user can retain ownership on paper while still facing unauthorized execution.
The theme overlaps with the broader wallet-security pressure Daily Crypto Briefs tracked in the Ledger and Trezor wallet-sniffer case. In both cases, the headline risk is not simply private-key theft. It is the surrounding tooling that turns wallet control into everyday behavior.
Gnosis Pay Recovery Watchpoints
The first checkpoint is a complete public post-mortem. CertiK supplied the clearest technical reconstruction available in the sources reviewed, but Gnosis Pay and the module maintainers still need to show what was patched, which configurations were exposed and how future card Safes will differ.
The second checkpoint is user migration. Gnosis Pay’s GP Safe documentation says a Gnosis Pay Safe includes a core Safe account plus modules for delay, roles and access validation. Any recovery plan that issues new card-linked Safes has to preserve card usability while removing the unsafe configuration.
The third checkpoint is reimbursement detail. CertiK quantified the loss, but the exact process for identifying affected users, restoring balances and handling disputed edge cases was not fully disclosed in the sources reviewed for this article.
For payment infrastructure, the credibility test is operational. Crypto card and stablecoin products are increasingly being judged on whether they can make blockchain balances feel like normal money, a shift also visible in Coinbase’s x402 payment-standard push.
The Gnosis Pay incident shows the other side of that transition. As crypto payments become easier for consumers, the security model becomes harder for most users to inspect. The next public updates should clarify whether the exploit was limited to the disclosed module path, whether all affected balances are restored, and whether Gnosis Pay can resume card functionality without reintroducing the same execution risk.
Stay up to date
Get the latest crypto insights delivered to your inbox
Primary sources and further reading
| Source | Title |
|---|---|
| | CertiK: GnosisPay Incident Analysis |
| | Gnosis Pay docs: Accounts |
| | Gnosis Pay docs: About GP Safe |
Fact-checked by: Daily Crypto Briefs Fact-Check Desk
Frequently Asked Questions
What happened in the Gnosis Pay exploit?
CertiK said an attacker used a signature-verification flaw in the Gnosis Pay Delay Module to queue and execute 41 transactions that moved EURe and GNO from affected Safes.
How much was stolen from Gnosis Pay Safes?
CertiK estimated the loss at about $265,000 across EURe and GNO tokens.
Did the Gnosis Pay exploit affect self-custody?
The incident involved self-custodial Safe accounts using Gnosis Pay modules. It does not mean users had transferred funds to a custodial exchange account, but it shows module logic can still create execution risk.
What should users watch after the Gnosis Pay incident?
The next checkpoints are any full post-mortem from Gnosis Pay or Zodiac, reimbursement details, module updates and migration instructions for affected card-linked Safes.