Worked example · 2025-10

Garden Finance solver-key compromise — multi-chain — 2025-10-30

Loss: approximately $10.8M extracted from Garden Finance's cross-chain Bitcoin bridge across Ethereum, Arbitrum, Base, and Solana. The attacker compromised a single solver's private key — solvers are the market-maker entities that execute user intents (cross-chain swap orders) on Garden's intents-based architecture — and used the compromised key to drain solver-held liquidity across all four chains. The extracted assets were predominantly stablecoins (USDC, USDT) and wrapped BTC (WBTC), most of which were swapped to ETH post-extraction. Garden's native GARDEN token traded at approximately $0.53 at the time of the incident, with a market cap of ~$6.8M, making the $10.8M extraction materially larger than the protocol's own token-market value.
Recovery: no public recovery reported at v0.1 cutoff. Garden co-founder Jaz Gulati confirmed on October 31 that the team was "working with security partners to trace the event" and that the protocol layer was unaffected. Garden sent an on-chain message to the attacker offering a 10% whitehat bounty; no public evidence of the attacker accepting the offer.
OAK Techniques observed: OAK-T10.001 (Validator / Signer Key Compromise) — primary; the attacker possessed a solver's private key, which authorised the extraction of solver-held liquidity across all four chain deployments of the bridge. The solver is the functional equivalent of a signer/validator in Garden's intents-based architecture: the solver key authorises the execution of user cross-chain swap intents and controls the liquidity that fulfills those intents. OAK-T9.004 (Access-Control Misconfiguration) — secondary; the architecture concentrated multi-chain solver authority in a single key without per-chain key separation, timelock on solver-operations, or per-transaction velocity limits.
Attribution: pseudonymous — no named individual or group publicly attributed at v0.1 cutoff. ZachXBT was the first to report the incident on-chain and noted that the attacker address had links to the Garden team's own infrastructure, raising the possibility of insider or operator-adjacent access. The Garden team's on-chain whitehat-bounty offer (10%) was consistent with a negotiation posture rather than a law-enforcement referral posture. No public OAK-G01 attribution.
Key teaching point: Solver/relayer key compromise is the T10.001 surface for intents-based bridges. Garden's intents-based architecture replaced traditional validator multisigs with a solver network, but the solver retained a private key whose compromise enabled bridge-wide drainage — the same structural risk as a validator-key compromise on a traditional bridge, repackaged in an intents-based design. The mitigation surface (per-solver key separation, solver-stake slashing for unauthorised outflows, timelock on solver operations, per-chain key sharding) is structurally analogous to T10.001 mitigations for validator-set bridges.

Summary

Garden Finance operated a cross-chain Bitcoin bridge using an intents-based architecture with trustless settlements. Users expressed intents to swap Bitcoin for assets on destination chains; solvers (market makers) competed to fulfill these intents, holding liquidity across Ethereum, Arbitrum, Base, and Solana. The architecture was marketed as "zero custody risk for users" — the solver held the liquidity, not the protocol — but the solver's private key was the de facto custody-and-signing surface for the solver's multi-chain liquidity pool.

On October 30, 2025, an attacker holding a solver's private key extracted approximately $10.8M in solver-held liquidity across all four chain deployments. The extraction was a single-actor operation: one compromised solver key authorised outflows from the solver's liquidity positions on Ethereum, Arbitrum, Base, and Solana. The extracted assets were predominantly stablecoins (USDC, USDT) and wrapped BTC (WBTC); most were swapped to ETH post-extraction.

Garden co-founder Jaz Gulati confirmed the incident on October 31, characterising it as "isolated to a single solver, with no impact on the protocol at all" and stating that the protocol's design "continues to work as intended." The Garden team sent an on-chain message to the attacker offering a 10% whitehat bounty and "resolving this situation peacefully." ZachXBT, who first reported the incident, noted that an address related to the Garden team had interacted with the attacker's address and that >25% of Garden's total activity prior to the hack had been linked to stolen funds (including the Bybit and Swissborg exploits).

The incident is the canonical 2025 worked example for the solver/relayer-key-compromise sub-pattern of T10.001: a bridge whose signing/authorisation surface is the solver network rather than a validator multisig, but where compromising a single solver key nonetheless enabled multi-chain extraction.

Timeline (UTC)

When	Event	OAK ref
Pre-October 2025	Garden Finance operates as a cross-chain Bitcoin bridge using intents-based architecture with solver network; solvers hold multi-chain liquidity secured by private keys	T10.001 surface (latent)
Pre-incident	Garden had been flagged by ZachXBT and others for facilitating laundering flows; >25% of total activity linked to stolen funds (Bybit, Swissborg, etc.)	(laundering-rail concern — separate from the hack)
2025-10-30	Attacker compromises a solver's private key; extracts ~$10.8M in solver-held liquidity across Ethereum, Arbitrum, Base, and Solana	T10.001 extraction
2025-10-30 (within hours)	ZachXBT reports the incident on-chain; identifies links between attacker address and Garden team infrastructure	(community detection)
2025-10-30 (same window)	Cyvers publishes initial estimate of ~$6M; later revised upward	(forensics response)
2025-10-30 (same window)	Garden team sends on-chain message to attacker offering 10% whitehat bounty; "fully committed to resolving this situation peacefully"	(operator negotiation posture)
2025-10-31	Garden co-founder Jaz Gulati confirms exploit publicly; states protocol layer unaffected, incident isolated to single solver	(operator disclosure)
Continuing	No public recovery, arrest, or law-enforcement action at v0.1 cutoff	(zero recovery)

What defenders observed

The solver key was the functional equivalent of a bridge validator key. Garden's intents-based architecture replaced the traditional validator multisig with a solver network, but each solver held a private key that authorised the movement of solver-held liquidity. Compromising one solver key was sufficient to drain that solver's entire multi-chain liquidity pool — structurally the same risk surface as compromising a validator key on a traditional bridge, repackaged in an intents-based design. Defenders auditing intents-based bridges should treat solver/relayer keys as the T10.001 surface and apply the same mitigations (key separation, stake slashing, timelocks, velocity limits).
Multi-chain liquidity concentration under a single solver key amplified the extraction. The compromised solver held liquidity across four chains (Ethereum, Arbitrum, Base, Solana), all controllable by the same private key. Per-chain key separation — with each chain's solver liquidity controlled by a chain-specific key — would have limited the extraction to a single chain. This is the same per-chain-key-separation mitigation that applies to traditional bridges (see the Force Bridge June 2025 example for the same finding in a different architectural context).
The 10% whitehat bounty offer was a negotiation posture, not a recovery strategy. Garden's on-chain message to the attacker offered 10% as a whitehat bounty and framed the resolution in terms of "cooperation, not punishment." This negotiation posture is consistent with the industry pattern for pseudonymous-attacker cases where law-enforcement attribution is not imminent — but the absence of a public law-enforcement referral suggests the operator did not have high-confidence off-chain attribution at the time of the offer.
The prior laundering-rail concern is contextually significant but analytically separate. ZachXBT's observation that >25% of Garden's activity was linked to stolen funds predates the hack and concerns the bridge's use as a laundering rail, not the hack's entry vector. The two facts — the bridge was used for laundering, and the bridge was hacked — are distinct OAK surfaces (T7.003 for the laundering-rail concern; T10.001 for the solver-key compromise). The temporal proximity of the laundering-rail exposure and the hack is notable but does not establish a causal link.
No timelock or velocity limit bounded the solver's outflows. The solver could authorise immediate, unlimited outflows across all four chains with no delay and no per-transaction cap. A timelock on solver operations — even a short one (e.g., 6–24 hours) — would have given the operator time to detect the compromise and intervene. A per-transaction or per-day value cap would have limited the extraction velocity and preserved residual funds.

What this example tells contributors writing future Technique pages

T10.001 extends to solver/relayer keys on intents-based bridges. The Garden case demonstrates that the T10.001 surface is not confined to traditional validator-multisig bridges. An intents-based bridge replaces validators with solvers, but each solver holds a private key that authorises asset movement — and compromising that key is structurally the same attack as compromising a validator key. Future T10.001 contributions should include solver/relayer-key compromise as a recognised sub-pattern alongside the canonical validator-multisig compromise (Ronin, Harmony Horizon) and the admin-key-concentration sub-pattern (Force Bridge).
Intents-based architecture does not eliminate the key-compromise surface; it redistributes it. Garden's architecture was marketed as trustless ("zero custody risk for users"), but the trust assumption shifted from the protocol to the solver — and the solver's key was a single point of failure for that solver's entire multi-chain liquidity pool. Defenders and contributors should treat "trustless" claims as bounded by the specific trust model: users may have zero custody risk, but solvers hold keys, and key compromise is the solver's (and by extension the protocol's) operational risk.
Per-solver key separation is the mitigation that maps to per-validator key separation. Just as a traditional bridge should not concentrate all validator keys in a single geographic location or a single operator's infrastructure, an intents-based bridge should not concentrate all solver liquidity under a single key. Per-solver key separation, per-chain key sharding, and solver-stake slashing for unauthorised outflows are the intents-based-bridge analogues of the validator-set mitigations documented in the Ronin and Harmony Horizon examples.
The ZachXBT detection pattern — community-sourced on-chain forensics as first responder — is now a standard incident-response pathway. For the third major 2025 incident (after Phemex and Bybit), the first public detection came from an independent on-chain investigator rather than from the protocol operator's own monitoring or a commercial forensics provider. This is a structural shift in the incident-detection surface that Mitigations contributors should engage.

Public references

Cybernews — "BTC Bridge Garden hit by $11M hack" — contemporaneous industry coverage; co-founder Jaz Gulati statement, ZachXBT detection, Cyvers threat-intelligence, whitehat-bounty offer.
Smart Contract Hacking — Garden Hack (2025) — technical incident dashboard; $10.8M figure, attack classification, prior-audit documentation.
BeInCrypto — "Bitcoin Bridging App Hacked For Over $10 Million" — contemporaneous industry coverage.
The Register — "Attackers dig up $11M in Garden Finance crypto exploit" — enterprise-technology press coverage.
The Coin Republic — "Garden Finance Goes Offline After $11 Million Exploit as ZachXBT Links Exploit to Team" — ZachXBT team-linkage analysis.
CryptoTale — "Garden Finance Faces $10M DeFi Bridge Exploit Across Chains" — contemporaneous industry coverage.
QuillAudits — X thread — primary forensic source for the Smart Contract Hacking dashboard entry.
Garden Finance — protocol website.
DefiLlama Hacks — Garden — structured hack data; $10.8M figure, solver-exploit classification.

Citations

[cybernewsgarden2025] — Cybernews coverage; co-founder Jaz Gulati statement, $11M figure, ZachXBT detection, Cyvers intelligence, whitehat-bounty negotiation.
[smartcontracthackinggarden2025] — Smart Contract Hacking incident dashboard; $10.8M figure, private-key-compromise classification, prior-audit documentation.
[beincryptogarden2025] — BeInCrypto coverage; $10M+ figure, bridge-architecture context.
[theregistergarden2025] — The Register enterprise-technology coverage; $11M figure.
[thecoinrepublicgarden2025] — The Coin Republic coverage; ZachXBT team-linkage analysis, on-chain bounty-offer details.
[cryptotalegarden2025] — CryptoTale coverage; multi-chain extraction context.
[quillauditsgarden2025] — QuillAudits X thread; primary forensic source.
[defillamahacks2025] — DefiLlama structured hack data.

Discussion

Garden Finance October 2025 is the OAK v0.1 reference case for the solver/relayer-key-compromise sub-pattern of T10.001. The case extends the T10.001 surface beyond traditional validator-multisig bridges (Ronin, Harmony Horizon) and admin-key-concentration bridges (Force Bridge) to include intents-based bridges where the solver/relayer network replaces the validator set but the key-compromise risk surface is structurally preserved.

The analytical contribution of the Garden case is the demonstration that intents-based architecture redistributes the T10.001 surface rather than eliminating it. Garden's architecture removed the user-facing custody risk — users did not deposit funds into a bridge contract; they expressed intents that solvers fulfilled — but the solver held a private key that controlled multi-chain liquidity, and compromising that key produced the same extraction outcome as compromising a traditional bridge validator key. The "trustless" property was bounded: trustless for users, but not trustless for the solver's key-material custody.

The Garden case also illustrates a community-detection pattern that has become structural in 2025: ZachXBT, an independent on-chain investigator, was the first to detect and report the incident. This follows the Phemex (January 2025) and Bybit (February 2025) pattern where community-sourced on-chain forensics outpaced both operator monitoring and commercial forensics-provider alerting. For Mitigations contributors, this pattern suggests that operator-side real-time monitoring of solver/relayer outflows — with alerting on anomalous single-solver drain patterns — is a high-leverage detection investment that would close the gap between community-detection latency and operator-detection latency.

The prior laundering-rail concern (>25% of Garden's activity linked to stolen funds, per ZachXBT) is contextually significant but analytically separable from the hack itself. The bridge's use as a laundering rail (T7.003 surface) and the bridge's compromise via solver-key theft (T10.001 surface) are distinct OAK entries — but the conjunction is a risk-management signal: a bridge that is already a high-laundering-flow venue may have reduced defender attention to operational-security anomalies, because the laundering-flow noise floor is high and the operator's compliance bandwidth is consumed by the laundering-rail exposure. This is a structural observation, not a causal claim, and future T10.001 contributions should note the conjunction where it occurs without asserting that laundering-rail status caused the key-compromise event.

For bridge operators building or operating intents-based architectures: the Garden case argues for treating solver/relayer keys as the T10.001 surface, applying per-solver key separation with per-chain sharding, enforcing timelocks and velocity limits on solver outflows, and monitoring solver-level outflow patterns for the single-solver-drain signature that is the on-chain manifestation of this sub-pattern.