Worked example · 2024-04

Hedgey Finance claim-function input-validation exploit — multi-chain — 2024-04-19

Loss: approximately $44.5M total impact, in a structurally distinctive distribution: ~$2M extracted directly from Hedgey Finance's own contract surfaces and ~$42M of cross-protocol contagion against the depositors-of-unclaimed-allocations whose vesting voucher contracts had been weaponised. Hedgey Finance is a token-vesting protocol whose primary product is NFT-based vesting voucher contracts: a depositor (typically a protocol's treasury or governance multisig) deposits tokens against a schedule and recipients hold NFT vouchers that allow claim of the underlying tokens per the schedule. The drained surface was both (a) Hedgey's own contracts and (b) the depositor wallets / contracts whose unclaimed allocations were sitting in Hedgey-managed vesting positions across multiple chains.
Recovery: none of material consequence on the on-chain layer. Proceeds were laundered through Tornado Cash within the days following the incident. Hedgey paused the affected contract surface within roughly an hour of the on-chain attack window; user-facing guidance circulated to depositors-of-unclaimed-allocations whose positions remained at risk.
OAK Techniques observed: OAK-T9.004 (Access-Control Misconfiguration) — primary, in the claim-function input-validation sub-class: the Hedgey claim-function did not adequately validate that the caller's claim parameters corresponded to a legitimate, fully-funded, currently-claimable allocation against the caller's NFT voucher; an attacker could call the function with crafted parameters that referenced a pre-existing claim-state and extract tokens beyond the legitimate per-voucher entitlement. The bug was an input-validation gap, not a generic missing-modifier; the function executed under the correct caller authority but did not constrain the parameter set to validated ranges. OAK-T9.002 is not the primary precondition — the exploit did not require flash-loan working capital; the working capital was the pre-existing depositor-funded vesting allocation graph that the bug allowed the attacker to drain. OAK-T7.001 (Mixer-Routed Hop — proceeds were laundered through Tornado Cash).
Attribution: pseudonymous. No public named-individual attribution. Pre-event funding routed through Tornado Cash; post-event laundering also routed through Tornado Cash. There is no public OAK-G01 / state-actor attribution for this incident.
Key teaching point: Vesting / claim / airdrop infrastructure is a cross-protocol contagion surface — a single bug in a shared infrastructure contract amplifies into multi-protocol loss across the depositor cohort. The Hedgey case is the canonical 2024 worked example for the claim-function input-validation sub-class of T9.004 and the cleanest 2024 demonstration that shared-infrastructure contracts (vesting providers, airdrop providers, multi-tenant treasury managers) are higher-blast-radius surfaces than per-protocol contracts because a single bug fires against the union of depositor allocations across all tenants. The Hedgey loss distribution — ~$2M direct, ~$42M cross-protocol contagion — is the canonical evidence; ~95% of the loss landed on third-party protocols that had used Hedgey as their vesting infrastructure rather than on Hedgey itself.

Summary

Hedgey Finance is a token-vesting and locked-token-trading protocol deployed across multiple EVM chains (Ethereum, Arbitrum, Optimism, Polygon, others). Its primary product is a family of NFT-based vesting voucher contracts: a depositor (a protocol treasury, a governance multisig, an early-stage project distributing locked tokens to investors) deposits an allocation of tokens against a vesting schedule and recipients hold NFT vouchers that allow them to claim the underlying tokens as the schedule unlocks. The Hedgey contracts hold the deposited tokens in custody during the vesting period and execute the per-voucher claims as recipients invoke them.

On 2024-04-19 an attacker exploited an input-validation gap in Hedgey's claim function. The function did not adequately validate that the caller's claim parameters — voucher ID, claim amount, schedule reference — corresponded to a legitimate, fully-funded, currently-claimable allocation against the caller's actual NFT voucher entitlement. By calling the function with crafted parameters that referenced pre-existing claim state on other depositors' allocations, the attacker could extract tokens beyond any legitimate per-voucher entitlement, effectively claiming against allocations the attacker did not own.

The proximate cause — per Cyfrin, BlockSec, and Hedgey-team post-incident analysis — is a missing relationship check between the caller's NFT voucher ownership and the claim parameters, plus a related accounting-state issue that allowed the same allocation slot to be claimed against multiple times. The combination converted the bug from a per-voucher over-claim into a multi-allocation drainage that scaled across the full set of depositor-funded positions held in the Hedgey contract surface at the time of the exploit.

The total impact — ~$44.5M, of which only ~$2M was on-Hedgey-treasury and ~$42M was depositor-funded allocations — is the structurally distinctive feature. Hedgey itself was not the principal loss-bearer; the depositor protocols whose vesting allocations were sitting in Hedgey contracts were the principal loss-bearers. The cohort of affected depositor protocols spans early-stage projects, DAOs, and protocol treasuries; the per-tenant loss distribution follows the size and unlock-state of each tenant's allocation at the time of the exploit window.

For OAK's purposes the case is a clean T9.004 claim-function-input-validation extraction with shared-infrastructure cross-protocol contagion as the loss-amplification mechanism. The novel OAK contribution of the worked example is documenting that shared-infrastructure contracts amplify per-bug blast radius across the tenant cohort and that vesting / claim / airdrop providers are a discrete cohort-monitoring class for which the contagion-surface property needs explicit threat modelling.

Timeline (UTC)

When	Event	OAK ref
Pre-event	Hedgey Finance deploys NFT-based vesting voucher contracts across multiple EVM chains; depositor protocols across the cohort deposit allocations into Hedgey-managed vesting positions; the depositor graph builds up over time	(T9.004 surface — shared-infrastructure tenant graph)
Pre-event	Hedgey's claim-function deployed with input-validation gap that does not adequately constrain caller-supplied claim parameters relative to caller's NFT voucher entitlement; bug latent	T9.004 surface (latent)
Pre-event	Attacker funds wallet via Tornado Cash; analyses Hedgey claim-function surface and identifies the input-validation gap and accounting-state path	(off-OAK pre-event observation)
2024-04-19 (attack tx window)	Attacker calls Hedgey claim-function with crafted parameters that reference pre-existing claim state on depositor allocations the attacker does not legitimately own; tokens extracted from depositor allocations to attacker-controlled wallets	T9.004 extraction
2024-04-19 (window)	Attacker repeats the pattern across multiple depositor allocations and multiple chains; cumulative outflow ~$44.5M across the cohort	T9.004 repeat / cross-protocol contagion
2024-04-19 (within hour)	On-chain monitoring (Cyfrin, BlockSec PhalconHQ, depositor-protocol operations teams) flags anomalous outflows from Hedgey contracts	(defender response / community detection)
2024-04-19 (within hour)	Hedgey operations team confirms the exploit; pauses the affected claim-function across chains; depositor-protocol operations teams evaluate per-tenant exposure	(operator response, multi-tenant)
2024-04-19 onward	Hedgey publishes public acknowledgement; user-facing communication circulates to depositors-of-unclaimed-allocations regarding remaining at-risk positions; per-tenant remediation plans coordinated	(operator response, multi-tenant)
2024-04-19 onward	Cyfrin, BlockSec, SlowMist publish post-incident write-ups converging on the input-validation root cause and documenting the shared-infrastructure contagion mechanism	(transparency / cohort signal)
Days following	Attacker laundering routes proceeds through Tornado Cash	T7.001 (off this example's framing)
2024-04 onward	Hedgey claim-function patched and redeployed; per-tenant treasury reconstitutions coordinated where possible	(operator response)
Continuing	No public recovery; no civil-forfeiture action	(recovery state)

What defenders observed

The bug shape was a missing relationship check between voucher ownership and claim parameters. The Hedgey claim function executed under the correct caller authority — the caller had to be authenticated as an NFT-voucher holder — but did not constrain the claim parameters to the specific allocation that the caller's voucher legitimately entitled them to. The attack was not a missing-modifier or a missing-authentication problem; it was a missing-correctness-of-authentication-against-parameters problem. T9.004 input-validation sub-class threat modelling needs to cover both forms: the binary form (modifier missing entirely; anyone can call) and the relational form (authentication present but caller-parameter-relationship not validated; authenticated callers can over-claim). The Hedgey case is the canonical 2024 worked example for the relational form.
The shared-infrastructure cross-protocol contagion mechanism is the principal corpus-level lesson. Hedgey itself absorbed only ~$2M of the loss; the remaining ~$42M landed on depositor protocols that had used Hedgey as their vesting infrastructure. The blast-radius amplification factor is roughly 22x — the per-protocol bug fired against a tenant graph 22x its own treasury size in expected value. This amplification is structural to the shared-infrastructure pattern: a single contract bug becomes a multi-tenant loss event across the depositor cohort. Defender threat models for shared-infrastructure contracts (vesting providers, airdrop providers, multi-tenant treasury managers, multi-tenant routing aggregators, multi-tenant lending isolators) should explicitly account for tenant-cohort-aggregate-TVL as the loss-exposure metric, not the provider's own treasury size.
Vesting / claim / airdrop infrastructure is a discrete cohort. The cohort spans Hedgey, Sablier, Token Table, Llama Pay, vesting wrappers around Merkle-distributor-pattern airdrops, and similar shared-infrastructure providers. The shared property — depositor protocols entrusting allocation custody to a shared contract surface — creates a shared threat surface (any contract bug fires against the tenant graph) and a shared mitigation surface (per-tenant custody isolation, time-bounded claim windows, multi-sig recovery paths, audit-coverage proportional to aggregate tenant TVL). The Hedgey case is the canonical 2024 evidence that the cohort-level audit-coverage discipline was not calibrated to aggregate tenant TVL; whether the cohort has tightened post-Hedgey is a question for ongoing cohort surveillance.
Multi-tenant operator response is operationally complex. Unlike a per-protocol exploit where the loss-bearer and the operator are the same entity, the Hedgey case required coordinated operator response across (a) Hedgey itself, (b) depositor protocols whose allocations were drained, and (c) recipient-side users whose unlocked-but-unclaimed allocations were the loss-mechanism. Worked examples for shared-infrastructure exploits should preserve this multi-tenant operator-response dimension; the response coordination is part of the defender lesson.
Detection latency was operator-acceptable; recovery latency was effectively infinite. Hedgey paused within roughly an hour of the on-chain attack window. Funds were already moving toward Tornado Cash. The pause primitive protects future drains but does not unwind completed extraction; the standard 2024-EVM-mainnet recover-nothing-via-Tornado-Cash pattern applies — the same shape as Onyx, Li.Fi, WOOFi 2024.

What this example tells contributors writing future Technique pages

T9.004 covers claim-function input-validation as a distinct sub-class. Hedgey 2024 is the canonical 2024 worked example. The diamond-pattern facet sub-class at Li.Fi 2024 and the delegatecall-pattern sub-class at Prisma 2024 are the other principal T9.004 sub-classes for which 2024-era worked examples exist; the T9.004 technique page should distinguish all four (the three plus the access-control-modifier-missing sub-class at Poly Network 2021) explicitly.
Shared-infrastructure contracts are a discrete cohort with explicit cohort-level threat-modelling implications. The Mitigations layer for OAK should include a cross-cutting Mitigation entry for shared-infrastructure-provider tenant-cohort-aggregate threat modelling: blast radius is a function of aggregate tenant TVL, not provider treasury size; audit coverage and reverification cadence should scale with aggregate tenant TVL; per-tenant custody isolation is a primary mitigation pattern. Hedgey 2024 is the canonical worked example.
Tenant-cohort-aggregate-TVL is a first-class threat-model parameter for shared-infrastructure contracts. Worked examples for shared-infrastructure contract incidents should report this metric explicitly and contrast it with the provider's own treasury size to capture the amplification factor. The Hedgey case's ~22x amplification factor is the canonical 2024 evidence.
Cohort-monitoring of the vesting / claim / airdrop infrastructure sub-class is a discoverable defender practice. The set of shared-infrastructure providers in production at any time is enumerable; the set of those providers whose claim-and-distribution code paths have undergone audit recently is checkable; the set of tenant protocols depositing into each provider is enumerable on-chain. Cohort-level surveillance is operationally feasible. The Hedgey case is the 2024 evidence that it was not yet operational at coverage sufficient to catch the claim-function bug pre-deployment.
Pseudonymous attribution is the realistic attribution status for this class. Funding through Tornado Cash, laundering through Tornado Cash, no industry forensics provider has produced a named-individual claim. Contributors should not over-claim attribution simply because the on-chain forensics are detailed.

Public references

[hedgeypostmortem2024] — Hedgey Finance protocol-side post-incident statement covering the claim-function exploit, multi-tenant remediation coordination, and depositor-side guidance.
[cyfrinhedgey2024] — Cyfrin / Solodit post-incident technical write-up emphasising the claim-function input-validation root cause and the shared-infrastructure contagion mechanism.
[blocksechedgey2024] — BlockSec PhalconHQ forensic analysis of the Hedgey exploit including transaction-trace breakdown of the per-allocation drain sequence and chain-by-chain loss distribution.
[slowmisthedgey2024] — SlowMist incident analysis covering funding-source tracking and Tornado Cash laundering pattern.
[rektheadgey2024] — Rekt News public-facing summary framing the case as a shared-infrastructure-contagion exploit with cross-protocol blast radius.
[peckshieldhedgey2024] — PeckShield headline figures and on-chain analytics for the Hedgey 2024 drain, including the per-tenant loss attribution.

Citations

[hedgeypostmortem2024] — Operator post-incident statement; primary source for affected-function identification, multi-tenant remediation framing, and operator timeline.
[cyfrinhedgey2024] — Forensic technical analysis; primary source for the input-validation root cause and contagion-mechanism framing.
[blocksechedgey2024] — Transaction-trace forensic breakdown; primary source for per-allocation drain sequence and chain-by-chain distribution.
[slowmisthedgey2024] — Funding-source tracking and laundering pattern; primary source for pseudonymous attribution status.
[rektheadgey2024] — Public-facing summary; secondary source for shared-infrastructure-contagion framing.
[peckshieldhedgey2024] — Headline figures and per-tenant attribution; primary source for the ~$2M direct / ~$42M cross-protocol loss split.

Discussion

Hedgey Finance 2024 is OAK's canonical case for the claim-function input-validation sub-class of T9.004 and for the shared-infrastructure cross-protocol contagion loss-amplification mechanism. The case is structurally distinctive in the OAK 2024 corpus: most 2024 EVM exploits land on a single protocol's treasury (Onyx $3.8M, WOOFi $8.5M, Prisma $11.6M); Hedgey landed across the depositor cohort with ~22x amplification factor relative to Hedgey's own treasury exposure.

The shared-infrastructure framing generalises beyond Hedgey. Vesting providers (Hedgey, Sablier, Token Table, similar), airdrop infrastructure (Merkle-distributor-pattern services, custom claim providers), multi-tenant treasury managers, and similar shared-infrastructure contracts share the structural property that depositor protocols entrust allocation custody to a shared contract surface. Any single contract bug in the shared surface fires against the union of depositor allocations, with blast radius proportional to aggregate tenant TVL rather than provider treasury size. The defender mitigation patterns are well-known in principle (per-tenant custody isolation, time-bounded claim windows, multi-sig recovery paths, audit coverage scaled to aggregate TVL); the Hedgey case is the canonical 2024 evidence that they were not uniformly in operation across the cohort.

The ~$2M direct / ~$42M cross-protocol loss split is the analytically important feature for the OAK Mitigations layer. Defender threat-modelling-by-protocol is structurally insufficient for shared-infrastructure cohort exposure: the depositor protocol's threat model should include "shared-infrastructure providers we deposit into" as an explicit dependency, with the dependency's per-bug blast-radius calibrated against the depositor's allocation, not against the provider's own treasury. The 22x amplification factor at Hedgey is the cohort-level evidence that this dependency-modelling discipline was not yet operational at coverage sufficient to catch the cohort-level exposure before the April 2024 incident.

For OAK's broader credibility, including Hedgey 2024 in v0.1 closes a gap: it adds a 2024 shared-infrastructure-contagion worked example, documents the claim-function-input-validation sub-class of T9.004, and contributes a cross-protocol-blast-radius case to a corpus that otherwise emphasises per-protocol single-treasury exploits. The case extends the T9.004 technique page coverage of access-control misconfigurations across the four principal sub-classes for which 2021–2024-era worked examples exist (modifier-missing, diamond-pattern facet, delegatecall-pattern, claim-function input-validation).