Espresso co-founder loses $30k in USDC after exploit of legacy Thirdweb smart contract
Cryptocurrency entrepreneur Jill Gunter has revealed that more than $30,000 worth of USDC was drained from her wallet after attackers exploited a vulnerability in an old Thirdweb smart contract that had not been fully retired.
Gunter, a co-founder of the Espresso blockchain project and a veteran of the crypto space for roughly a decade, shared that the theft occurred while she was literally working on a presentation about privacy and security in digital assets for an event in Washington, D.C. At the same time she was preparing to speak about cyber risks, her own funds were quietly siphoned away.
According to her account, the stolen funds were moved from her wallet and eventually routed through Railgun, a privacy-focused protocol designed to obscure on-chain transaction histories. The assets taken consisted of more than $30,000 in USDC stablecoin.
How the theft unfolded
In a detailed breakdown of the incident, Gunter explained that the critical transaction targeting her wallet address, jrg.eth, took place on December 9. The day before, she had transferred the tokens into that wallet to be ready for an upcoming angel investment she planned to make that week. In other words, the funds were not sitting idle for months; they had just been moved in, and within roughly 24 hours they were gone.
On-chain data showed that the USDC was taken from jrg.eth and sent to another address, labeled 0xF215. However, the transaction itself involved an interaction with a separate contract at address 0x81d5. That detail prompted Gunter to investigate further, since it implied the theft was not simply a result of a direct transfer or a standard phishing transaction, but rather a smart contract–based exploit.
The legacy bridge contract at the center of the issue
By reviewing her own historical activity and the contract’s behavior, Gunter concluded that 0x81d5 corresponded to a Thirdweb bridge contract she had interacted with in the past. She noted that her only prior use of that contract had been a small, seemingly harmless transfer of just $5. Yet that one interaction turned out to be sufficient: during that earlier transaction she had granted the contract broad token permissions, which later became the foothold for attackers.
Thirdweb subsequently confirmed to her that this specific bridge contract had been flagged as vulnerable back in April. The flaw allowed anyone to move tokens from users who had previously approved essentially unlimited spending rights to the contract. In other words, if a user had once clicked “approve” without setting a limit, malicious parties who discovered the bug could later pull assets directly from that wallet, long after the original interaction.
The contract has since been marked as compromised on major blockchain explorers, signaling that it should no longer be used and that it represents an active security risk. However, in this case, the old “legacy” contract had not been fully decommissioned at the moment of the exploit, leaving earlier token approvals in place and still exploitable.
Thirdweb’s response and admission of oversight
Thirdweb later released a statement explaining that the theft stemmed from a failure to completely shut down this legacy bridge contract during its vulnerability response process in April 2025. While the company had identified the bug at that time and taken steps to mitigate it, the older contract was not fully disabled, leaving a lingering attack surface.
In its public communication, Thirdweb said it has now permanently disabled the affected legacy contract and emphasized that, following this fix, there should be no remaining user wallets or funds at risk from this specific issue. The incident, however, highlights how difficult it can be to fully unwind risky permissions once they are granted on-chain, especially when multiple versions of a contract have been deployed over time.
Previous security concerns around Thirdweb contracts
This is not the first time Thirdweb has faced scrutiny over smart contract vulnerabilities. In late 2023, the company disclosed a broad vulnerability in a widely used open-source library integrated into many of its contracts. The problem had a large blast radius: according to analysis from blockchain security firm ScamSniffer, more than 500 token contracts were impacted by that earlier issue, and at least 25 were successfully exploited in the wild.
Security researcher Pascal Caversaccio from SEAL, a blockchain security organization, criticized the way Thirdweb handled public disclosure of that 2023 vulnerability. He argued that publishing a list of affected contracts effectively gave malicious actors a roadmap, allowing them to quickly target unpatched deployments before project teams could respond. The tension between transparency and operational security remains a recurring theme in Web3 vulnerability management.
Gunter’s reaction: “occupational hazard” in crypto
Gunter said she does not yet know whether she will be reimbursed for the stolen funds. She described this type of incident as an “occupational hazard” for those who work deeply in the cryptocurrency industry, where interacting with cutting-edge tools often means accepting real security risks.
Despite the personal loss, she committed to directing any funds that might eventually be recovered to the SEAL Security Alliance. Rather than treating the event solely as a private misfortune, she framed it as an opportunity to support organizations working to improve the overall security of the ecosystem. She also encouraged others to consider donating to security-focused initiatives, highlighting that systemic improvements benefit the entire industry, not just individual victims.
What this incident says about smart contract risk
The attack on Gunter’s wallet underscores a crucial, and often misunderstood, aspect of decentralized finance: granting token approvals to a smart contract is not a one-time event that disappears after a transaction completes. If a user approves a contract to spend an unlimited amount of a token, that permission can persist indefinitely, even if they never use the contract again. Should the contract later prove to be vulnerable—or should its keys or logic be compromised—any approved funds can become a target.
This dynamic flips the conventional security model on its head. Rather than only worrying about safeguarding a private key, users must also track which contracts are authorized to act on their behalf, sometimes months or years after an initial interaction. For frequent DeFi users, NFT traders, and developers, those accumulated approvals can number in the dozens or hundreds, turning their primary wallet into a patchwork of potential attack vectors.
Lessons for everyday crypto users
For regular users, several practical takeaways emerge from this incident:
1. Regularly review token approvals. Many tools allow users to see which contracts have permission to move their tokens and to revoke those approvals. Periodic audits of approvals can significantly reduce exposure to legacy contract risks.
2. Avoid unlimited approvals when possible. While approving “max” token spending is convenient, especially for traders, it is often safer to set specific limits or use wallets and dapps that support more granular permissioning.
3. Use separate wallets for different purposes. Keeping investment capital, long-term holdings, and experimental DeFi or NFT activity in distinct wallets can reduce the fallout if a single contract or dapp is compromised.
4. Treat old interactions as live risks. Even if a protocol is no longer actively used, any standing approvals to its contracts can remain active unless explicitly revoked.
Gunter’s experience is a high-profile reminder that even knowledgeable insiders are not immune to the compounding risk created by historical approvals and legacy contracts.
Implications for developers and infrastructure providers
For builders, the episode is a case study in the importance of end-of-life (EOL) procedures for smart contracts. Once a contract is known to be vulnerable, simply deploying a new version is not enough; teams must also:
– Proactively communicate with users about revoking approvals.
– Technically disable or “brick” old contracts where possible.
– Implement permission patterns that limit the fallout if a contract is later found to be buggy.
– Maintain internal inventories of deployed contracts and their dependencies to avoid leaving forgotten code active on mainnet.
Moreover, developers who integrate third-party libraries and frameworks face an additional supply chain problem: a single bug in an upstream dependency can silently propagate into hundreds of downstream projects, as the 2023 Thirdweb-related vulnerability demonstrated.
The paradox of privacy tools in crypto crime
The route taken by the stolen funds—ending up in Railgun—also illustrates a persistent tension in blockchain design. Privacy protocols exist to give legitimate users financial confidentiality in a world of fully transparent ledgers. Yet those same tools can be deployed by attackers to launder stolen assets and obscure their tracks.
This dual-use nature does not necessarily condemn privacy technology, but it complicates the narrative around “clean” and “dirty” tools in crypto. Policymakers, developers, and security researchers must contend with the fact that meaningful privacy and effective law enforcement are often in direct tension, especially when the base layer of the financial system is globally accessible and permissionless.
A broader warning for the “next billion” crypto users
Incidents like this one raise uncomfortable questions about mainstream adoption. As some in the industry talk about onboarding the next billion users, the reality is that even highly experienced participants, including founders and security-conscious professionals, still fall victim to technical quirks and incomplete remediation processes.
If navigating token approvals, contract deprecation, and upstream library vulnerabilities is challenging for an expert, it is effectively impossible for a casual user with no technical background. Without better defaults, safer infrastructure, and stronger guardrails, the industry risks pushing complexity and security responsibilities onto people who are ill-equipped to handle them.
Turning a personal loss into a systemic wake-up call
Gunter’s public disclosure adds to a growing body of real-world examples showing how smart contract risks, token approval design, and vulnerability response processes can intersect in unpredictable ways. While the financial loss is relatively modest in the context of large-scale DeFi exploits, the symbolic weight is significant: a seasoned founder preparing to speak about crypto privacy loses funds because a legacy contract was never fully shut down.
Whether or not she is eventually reimbursed, the episode serves as a timely warning for users to reexamine their own security habits—and for infrastructure providers and developers to treat contract decommissioning and approval hygiene as first-class responsibilities, not afterthoughts.