The Garden Finance Hack Shows Why DeFi Risk Is No Longer Just About Code
When a DeFi bridge loses money, the usual assumption is that a smart contract has failed. A line of code was wrong, a validation check was missing, an oracle was manipulated, or an attacker found a way to move assets through the system that its designers had not anticipated.
The Garden Finance incident points to a more complicated problem. The cross-chain bridge reportedly lost around USD 11 million after one of its solvers was compromised. Garden said user funds were safe and that the affected solver was separate from the core protocol, while the team temporarily shut down its application and offered a 10 percent bounty for the return of the stolen funds. The incident was reported in October 2025 and resurfaced in later coverage as an example of solver-related bridge risk.
This usually matters. A bridge can have audited contracts, a clear user interface and a decentralised message, yet still depend on off-chain participants, operational processes and third-party actors that users may barely understand. In this case, the word “solver” is not a technical footnote. It is the central issue.
A solver is usually an actor that helps fulfil transactions by providing liquidity, routing orders or matching intent across systems. In intent-based and cross-chain infrastructure, solvers can make the user experience faster and smoother. The user expresses what they want to happen, and the system relies on specialised actors to make it happen in the background.
That model is powerful. It is also more complex than the simple promise of trustless finance.
The Weak Point May Sit Outside The Smart Contract
DeFi often markets itself around code. Smart contracts are visible, auditable and, in theory, predictable. That has encouraged the idea that risk can be assessed mainly by looking at protocol design and contract security.
The Garden Finance case is a reminder that modern DeFi systems are not only smart contracts. They are networks of contracts, bridges, relayers, solvers, market makers, wallets, interfaces, governance processes, cloud services, private keys, multisigs, monitoring tools and human operators. A weakness in any of those layers can become the practical point of failure.
This is especially true for bridges. Cross-chain infrastructure has always been one of crypto’s most difficult security categories because it connects separate ecosystems that were not originally designed to trust one another. A bridge has to verify that something happened on one chain and then allow a corresponding action somewhere else. That creates a large attack surface.
Academic research on cross-chain bridge hacks has repeatedly identified bridges as critical but vulnerable infrastructure, with losses linked to design weaknesses, validation failures and operational controls. The Ronin Bridge attack in 2022, which resulted in losses of almost USD 600 million, remains one of the most visible examples of the scale of bridge risk.
But not every bridge incident is a pure smart-contract exploit. Increasingly, the risk is operational: compromised keys, weak access controls, poor monitoring, dependency on privileged actors or unclear responsibility between the protocol and the entities around it.
That is why the phrase “user funds are safe” does not end the discussion. It may be true in the narrow sense that deposits were not directly drained. But users, liquidity providers and counterparties still need to understand which parts of the system carry risk and who stands behind them when something fails.
Solvers Make DeFi Easier, But Harder To See
Intent-based systems and solver networks are part of a broader effort to make DeFi more usable. Instead of asking users to understand every route, pool, bridge, gas fee and execution step, protocols can allow users to define the outcome they want. Solvers then compete or operate to deliver that outcome.
For a user, that feels simpler. For the infrastructure, it is anything but simple.
The more the system abstracts away complexity, the more important it becomes to know who is performing the hidden work. Are solvers permissionless or approved? Are they financially bonded? Can they be removed quickly? What happens if one is compromised? Are there limits on exposure? Is there independent monitoring? Is the protocol responsible for solver behaviour, or does it treat the solver as an external participant?
These questions are not always visible from the front end of a DeFi application. A user may see a smooth bridge transaction. Behind it, the system may rely on actors with different incentives, different security standards and different levels of transparency.
That is the uncomfortable part of the Garden Finance incident. It shows that DeFi can move risk away from the user interface without removing it from the system. The experience may look clean, but the underlying risk map may be more fragmented than users realise.
The Reputation Question Is Also Serious
Garden Finance had already attracted scrutiny before the solver incident. In June 2025, blockchain investigator ZachXBT accused the Bitcoin bridge of facilitating flows linked to stolen funds, including assets allegedly tied to the Lazarus Group. Garden disputed the framing, but the accusation raised broader questions about bridge monitoring, illicit flows and the responsibilities of infrastructure that enables cross-chain movement.
This context matters because bridges sit at the intersection of liquidity, speed and anonymity. They are useful for legitimate users who need to move assets across chains. They are also attractive to attackers who want to move stolen funds, obscure trails or exploit fragmented compliance standards.
That does not mean every bridge is negligent. It does mean that bridge operators need to treat monitoring, incident response and abuse prevention as core infrastructure, not public-relations issues to be addressed after an event.
For DeFi, reputation is not separate from security. A protocol can survive a technical incident if users believe the response is fast, transparent and credible. It may struggle if the incident reveals ambiguity about who operated what, where responsibility sits and how much of the system was actually under the protocol’s control.
Audits Are Necessary, But Not Enough
The reflex after a DeFi exploit is often to call for more audits. That is understandable. Smart-contract reviews, formal verification and external security assessments remain important. But the Garden Finance incident shows why audits cannot be the entire answer.
An audit can assess code. It may not fully assess the operational behaviour of solvers, custody arrangements, private-key management, incident-response capacity, off-chain infrastructure or the economic incentives of external participants. Even where those areas are reviewed, they can change after deployment.
DeFi security therefore needs to move from a one-time audit mindset to a continuous risk-management model. That means monitoring live transactions, setting limits, testing operational controls, rehearsing incident response, reviewing privileged access and understanding how dependencies behave under stress.
Research on DeFi attacks has shown that incidents are not limited to one technical category. They include oracle manipulation, governance abuse, flash-loan attacks, access-control failures, bridge compromises and operational weaknesses. A 2022 systematic review of DeFi attacks examined 181 real-world incidents and found that practical attack patterns often diverged from what academic work had focused on most heavily.
That gap still matters. DeFi risk is not static. As the architecture changes, the attack surface changes with it.
What Bridge Users Should Ask
Most users cannot inspect a bridge’s full technical architecture. But they can ask better questions before moving significant value through one.
The first question is whether the bridge is custody-light or custody-heavy. Who controls the assets while they are in transit? Are funds locked, minted, routed, swapped or fulfilled by liquidity providers? The answer changes the risk.
The second question is how the system handles failures. If a solver disappears, is compromised or refuses to settle, what happens? Is there a fallback? Is there an insurance fund? Are users made whole? Is the protocol contractually or economically responsible?
The third question is whether the protocol has clear public incident history and communication. A bridge that explains failures clearly is not automatically safer, but transparency gives users more information. Silence, vague updates and overly narrow denials should be treated cautiously.
The fourth question is whether the bridge has concentration risk. If a small number of solvers, operators or keys can affect large volumes, the system may be more fragile than the word “decentralised” suggests.
The fifth question is whether the user actually needs to bridge. Many losses in crypto happen because users move assets into systems they do not understand for a marginal gain. If the reason for using a bridge is unclear, the risk may not be worth taking.
What Protocols Should Change
For protocols, the Garden Finance incident points to a more demanding standard.
Solver networks need clearer governance. Protocols should define how solvers are approved, monitored, limited and removed. If solvers are described as independent, the boundary between the solver and the protocol should be transparent enough for users to understand.
Exposure limits should be stricter. A compromised participant should not be able to drain a large amount before the system reacts. Caps, circuit breakers and anomaly detection can reduce the scale of damage.
Incident response should be rehearsed. In DeFi, every minute matters. Protocols need a plan for pausing front ends, notifying users, tracing funds, coordinating with exchanges and engaging security firms. A improvised response can make a bad incident worse.
Public communication should be precise. Users do not need theatrical reassurance. They need to know what happened, which funds are affected, what remains at risk, which systems are paused and what the team is doing next.
Finally, protocols should treat operational security as part of product quality. Solver infrastructure, key management, cloud access, internal permissions and monitoring systems are not secondary to the protocol. They are part of the protocol’s real-world security.
The Larger Lesson For DeFi
The Garden Finance hack is not one of the largest crypto incidents by historical standards. It is much smaller than the Ronin Bridge attack, the Poly Network exploit or the Bybit theft. DeFiLlama’s hacks database still shows billions of dollars in cumulative losses across DeFi and bridge incidents, underlining how persistent the problem remains.
Its importance is more specific. It shows that as DeFi becomes more abstracted and user-friendly, risk becomes harder to locate. The user may no longer interact directly with every technical step, but someone or something still performs those steps. If that actor is compromised, undercapitalised, poorly monitored or badly governed, the system can fail even if the user experience looks polished.
That is the next challenge for DeFi infrastructure. Better interfaces will not be enough. More efficient solvers will not be enough. Faster bridges will not be enough. The sector needs clearer accountability for the operational layer that sits between users and protocols.
The promise of DeFi has always been that users should not have to rely on opaque intermediaries. But when bridges depend on solvers, relayers and off-chain operators, the industry has to be honest about where trust has re-entered the system.
The Garden Finance incident is a reminder that decentralisation is not a label. It is a risk architecture. If the architecture still depends on privileged actors, the security model has to reflect that. Otherwise, DeFi will continue to discover the same lesson after every exploit: the weakest point is not always in the code. Sometimes it is in the part of the system everyone assumed was only infrastructure.
