Worked example · 2022-10

Team Finance liquidity-locker migrate() exploit — Ethereum / BNB Chain — 2022-10-27

Loss: approximately $14.5M extracted across multiple locked liquidity pools on Team Finance — a third-party liquidity-locker service that issues custodial commitments to lock LP-tokens for projects that wish to publicly demonstrate retail-protective post-launch liquidity-retention. The drained pools held LP positions for the WTH, CAW, USDC, and TSUKA token pairs, with the largest losses on the CAW and TSUKA positions. The attacker exploited an unvalidated input parameter in the V2-to-V3 migrate() function that Team Finance had recently introduced to allow lockup-customers to migrate their locked LP-tokens from Uniswap V2 to V3 without breaking the lockup commitment.
Recovery: approximately $7M of the ~$14.5M was returned by the attacker, who self-identified as a "whitehat" in transaction memos, in a partial-bounty negotiation framework similar to the Mango Markets / Euler / Crema patterns. Affected projects subsequently received the vast majority of their funds back per the Team Finance team's public-line statements; the loss-residual after the partial return is approximately $7.5M against the $14.5M extraction figure.
OAK Techniques observed: OAK-T2.002 (Locked-Liquidity Spoof) extended via the third-party-locker-as-failed-trust-substrate sub-pattern — primary. The structural failure is at the locker-service layer: Team Finance's customers had used the locker as a defensive-baseline claim to retail (i.e., "our LP is locked at Team Finance for N months, therefore the rug-pull risk is bounded"), and the locker's own contract-layer flaw inverted that claim by allowing the attacker to drain the locked positions through a privileged-pathway exploit. OAK-T9.004 (Access-Control Misconfiguration / input-validation failure) chains as the proximate extraction primitive — the migrate() function passed unvalidated user-supplied parameters directly into the Uniswap V3 migrator without range / authority checks, and the attacker constructed input parameters that drained the locked positions to an attacker-controlled V3 pair with skewed pricing. The case is the cleanest v0.1 example of T2.002 trust-substrate failure where the attack vector is at the locker-side, not the project-side.
Attribution: pseudonymous (whitehat-framed). The attacker self-identified as a whitehat in transaction memos and returned approximately $7M of the $14.5M extraction. No public real-world-identity attribution was made at v0.1 cutoff. The whitehat-framing matches the contemporaneous Mango Markets (Eisenberg, October 2022) and earlier Crema Finance (July 2022) self-identification-via-on-chain-memo pattern, though without the named-individual follow-up that the Mango case eventually produced.
Key teaching point: third-party liquidity-locker services are themselves a T2.002 trust-substrate that can fail, and the failure mode is not at the project-side (which is what the locker was meant to bound) but at the locker-side. Team Finance is the canonical worked example for this sub-pattern: the locker customers had not deceived their own retail in the standard T2.002 framing — they had legitimately committed their LP-tokens to a third-party custodian, and the third-party custodian itself was the trust-substrate that failed via a contract-layer flaw in the migration pathway. Defenders writing T2.002 detection signals should preserve this distinction: the standard T2.002 detection surface (project-side locker-claim verification) does not cover the locker-side-failure sub-pattern, and adding it requires transitive trust assessment of the locker contract's own audit posture, upgrade-authority exposure, and migration-pathway surface. The Team Finance case demonstrates that a commercially-audited locker (CertiK and others were involved at various points in Team Finance's audit history) can still expose customers to extraction via a newly-introduced migration-pathway flaw, and that the auditing-of-the-locker-itself layer is the load-bearing transitive-trust-assessment for the project-side T2.002 framing to actually deliver retail protection.

Summary

Team Finance is a Web3 token-launch services platform whose flagship product is a third-party liquidity-locking service. Projects deposit Uniswap (or other DEX) LP-tokens into Team Finance lockup contracts, choose a lock-duration, and use the resulting Team Finance lock-record as a public-line commitment to retail that the project's LP cannot be withdrawn or rugged for the lock-duration window. The lockup pattern is a discrete sub-class of OAK-T2.002 (Locked-Liquidity Spoof) — when used legitimately, it is a trust-substrate; when misused, it is an evasion vector.

In late 2022, Team Finance introduced a migrate() function to allow lockup-customers to migrate their locked LP-tokens from Uniswap V2 to Uniswap V3 — the natural product-side response to the V3 launch and to broader DEX-side migration pressure. The migrate() function accepted user-supplied parameters that specified the V3 migration target (the V3 pair address and the migration position parameters). The function passed those parameters directly into the Uniswap V3 migrator without sufficient range / authority validation.

On 2022-10-27, an attacker exploited the unvalidated-input flaw in migrate(). By calling migrate() with constructed parameters that pointed at an attacker-controlled V3 pair with deliberately-skewed pricing, the attacker drained approximately $14.5M of locked liquidity from four pools (WTH, CAW, USDC, TSUKA) into the attacker-controlled V3 positions, then extracted the value from those positions through the V3 swap surface. The attacker subsequently returned approximately $7M of the $14.5M extraction, self-identifying as a "whitehat" in transaction memos.

The case is OAK's canonical worked example for the third-party-locker-as-failed-trust-substrate sub-pattern of T2.002. It closes the previously-empty T2 2022 zero-incident cell in the coverage matrix and is structurally distinct from the project-side T2.002 cases (Saddle, Crema, Nirvana, Cashio) that the v0.1 corpus already anchors: Team Finance's customers had not deceived their retail at the project-side; the failure was at the locker-side that those customers had legitimately relied on as a defensive-baseline claim.

For OAK's broader purposes, the Team Finance case also illustrates a T2.002 transitive-trust-assessment requirement that v0.1 defender-side documentation has under-emphasised: when a project's T2.002 risk is bounded by reliance on a third-party locker, the locker itself becomes a load-bearing trust-substrate whose own audit / upgrade-authority / migration-pathway surface determines whether the project-side T2.002 claim actually delivers retail protection. The locker's audit posture, the locker's migrate() (or other privileged-pathway) function set, and the locker's upgrade-authority configuration are all transitive-trust signals that the project-side T2.002 detection surface does not currently cover.

Timeline (UTC)

When	Event	OAK ref
Pre-2022	Team Finance establishes its liquidity-locker product as a T2.002 trust-substrate for token-launch projects on Ethereum and BSC	(operator setup; T2.002 surface latent)
2022 (months prior)	Team Finance introduces `migrate()` function to support customer migration of locked LP-tokens from Uniswap V2 to V3	T2.002 / T9.004 surface
2022-10-27	Attacker calls `migrate()` with constructed parameters targeting an attacker-controlled V3 pair with skewed pricing; drains ~$14.5M of locked LP from WTH / CAW / USDC / TSUKA pools	T2.002 trust-substrate failure + T9.004 input-validation extraction
2022-10-27 (within hours)	Team Finance team detects the drain; pauses affected functions; begins on-chain forensics with industry providers (Halborn, Hacken, others)	(operator response)
2022-10-27 / 2022-10-28	Attacker posts whitehat-framed memos in transaction calldata; begins partial-return negotiation	(whitehat-framing; partial-recovery framework)
2022-10-28 onward	Approximately $7M of the $14.5M returned to Team Finance / affected projects	(partial recovery, ~48% of total)
Subsequent weeks	Team Finance replaces prior auditor with CertiK; engages multiple audit firms; enhances backend-system architecture and software-development QA processes	(operator-side post-incident response)
Continuing	No public named-individual attribution at v0.1 cutoff; whitehat self-framing held; ~$7.5M loss residual unrecovered	(final state)

What defenders observed

The structural risk surface was the third-party-locker's migrate() privileged pathway. Standard T2.002 detection at v0.1 emphasised project-side signals: did the project actually lock its LP, for how long, with what locker. The Team Finance case demonstrates that all three project-side answers can be correct (yes, locked; for the publicly-claimed duration; with a commercially-recognised locker) and the project's retail can still be drained via a flaw in the locker contract's own privileged-pathway surface. Defenders writing T2.002 detection signals should add a transitive-trust-assessment layer covering the locker's audit history, the locker's upgrade-authority configuration, and the locker's privileged-pathway function set (including any recently-introduced functions like migrate()).
Recently-introduced privileged pathways are elevated-risk surfaces. Team Finance's migrate() function was a recent addition driven by the Uniswap V3 launch and the natural product-side need to support customer migration. As at the broader v0.1 worked-example pattern (Beanstalk April 2022 — recently-deployed governance proposal handler with insufficient authority validation; Hedgey April 2024 — recently-deployed claim-flow helper with input-validation gap), recently-deployed privileged-pathway functions on otherwise-stable contracts are an elevated-risk surface that defender-side review should prioritise. Contributors writing future T9.004 / T2.002 worked examples should call out the recently-introduced-function-as-elevated-risk-surface pattern as a recurring observation.
The whitehat-framing is real but partial. The attacker's self-framing as a whitehat (~$7M return / ~48% recovery) sits in the established 2022-cohort recovery-framework pattern (Mango ~$60M return / ~67% recovery; Euler ~$200M return / ~100% recovery; Crema partial-return). The Team Finance recovery is in the 40-50% partial-bounty band — a structurally-distinct outcome from the wealth-bracketed partial-return Cashio framework. Contributors writing future recovery-framework documentation should treat 40-50% partial-return-with-whitehat-framing as a discrete band within the 2022-cohort recovery-pattern set; it is neither the full-return Euler outcome nor the no-recovery Multichain outcome.
The locker's prior audit posture did not predict the failure. Team Finance had a prior auditor at the time of the incident; the post-incident response included replacing the auditor with CertiK and engaging multiple additional audit firms. The defender lesson is that an audit at the locker-side does not automatically transfer trust-substrate validity to the locker's product-claim layer — the audit must specifically cover the privileged-pathway function set that the customer-side T2.002 claim relies on, and a newly-introduced function like migrate() may post-date the audit window. Contributors writing T2.002 transitive-trust-assessment documentation should note the audit-vintage-vs-function-vintage axis as a primary signal.
The lock-duration commitment was not the defective component. Crucially, the Team Finance locker correctly enforced the lock-duration commitments on the token side — the attacker did not bypass the time-lock and did not unlock LP that should have been locked. The flaw was in the migration-pathway logic that transferred locked LP from V2 to V3; the locked LP arrived at an attacker-controlled V3 pair (where it could be drained by the attacker) instead of at the customer's intended V3 pair. Contributors writing T2.002 documentation should preserve this distinction carefully: the failure was not in the time-lock primitive but in the migration-pathway authorisation logic. The time-lock was invariant; the destination of the migration was not.

What this example tells contributors writing future Technique pages

T2.002 detection requires a transitive-trust-assessment layer for third-party lockers. The standard v0.1 T2.002 detection surface (project-side locker-claim verification — "is the LP locked, where, for how long") is necessary but not sufficient. The Team Finance case motivates an additional transitive-trust-assessment layer: the locker's audit history, the locker's upgrade-authority configuration, the locker's privileged-pathway function set, and the locker's vintage of audit relative to the vintage of the privileged-pathway functions actually executed at customer-deposit time. Contributors writing future T2.002 worked examples or detection-signal documentation should add this transitive-trust-assessment layer explicitly.
The third-party-locker-as-failed-trust-substrate sub-pattern is structurally distinct from project-side T2.002. The v0.1 corpus already anchors project-side T2.002 cases (Saddle Finance, Crema Finance, Nirvana Finance, Cashio). The Team Finance case is the v0.1 anchor for the locker-side sub-pattern where the project-side claim is correct but the locker-side trust-substrate fails. Contributors proposing a T2.002.x sub-Technique split (locker-side-failure vs project-side-failure) should anchor on Team Finance for the locker-side and on Cashio / Saddle for the project-side.
Recently-introduced privileged-pathway functions on otherwise-stable contracts are an elevated-risk surface that recurs across T2 / T9 / T11 worked examples. Contributors writing future worked examples should preserve this observation in the What defenders observed section: recently-deployed migrate(), claim-flow helpers, governance-proposal handlers, and similar privileged-pathway additions on stable contracts have a higher-than-average rate of input-validation / authority-validation failure and warrant elevated audit-attention.
The 40-50% partial-return-with-whitehat-framing is a discrete recovery-band within the 2022-cohort recovery patterns. Contributors writing future recovery-framework documentation should treat this band as distinct from the full-return (Euler) and no-return (Multichain) outcomes. The partial-return band tracks a self-framing-as-whitehat negotiation pattern that Mango, Euler, Crema, and Team Finance share at the 2022-cohort level; the Team Finance ~48% recovery rate is in the middle of this band.

Public references

[halbornteamfinance2022] — Halborn explainer / forensic analysis of the Team Finance October 2022 hack; primary contract-layer walkthrough and migration-pathway-flaw description.
[hackenteamfinance2022] — Hacken analysis of why Team Finance was exploited despite its prior audit; supplies the audit-vintage-vs-function-vintage framing.
[immunebytesteamfinance2022] — ImmuneBytes detailed analysis of the October 27, 2022 exploit; supplies the four-affected-pool list (WTH, CAW, USDC, TSUKA) and the ~$14.5M figure.
[cryptopolitanteamfinance2022] — Cryptopolitan contemporaneous coverage of the $15M exploit; primary press corroboration.
[unchainedteamfinance2022] — Unchained coverage of the $15.8M loss figure; secondary corroboration with slightly higher pre-recovery loss number.

Discussion

Team Finance is OAK's v0.1 historical-coverage anchor for the third-party-locker-as-failed-trust-substrate sub-pattern of T2.002 and closes the previously-empty T2 2022 zero-incident cell. The case is structurally distinct from every project-side T2.002 worked example in the v0.1 corpus (Saddle, Crema, Nirvana, Cashio): Team Finance's customers had not deceived their own retail at the project-side, and the failure was at the third-party locker-side that those customers had legitimately relied on as a defensive-baseline claim.

The transitive-trust-assessment requirement the case surfaces is the load-bearing analytical contribution. A defender running standard T2.002 detection on a Team Finance customer-project at the relevant period would have correctly verified that the project's LP was locked, at Team Finance, for the publicly-claimed duration — and would still have missed the actual T2.002 risk surface, which lived in Team Finance's own contract-layer privileged-pathway logic. This is the canonical structural failure of single-layer trust-substrate verification: the customer-side defensive-baseline claim was correct, but the underlying trust-substrate (Team Finance's contract layer) was not bounded by the customer-side claim. Contributors writing future T2 Tactic / T2.002 sub-Technique documentation should preserve this transitive-trust-assessment requirement as a first-class detection-signal layer.

The recovery framework (~48% partial return with whitehat framing) places the case in the 2022-cohort recovery-pattern band that Mango, Euler, and Crema also occupy. The Team Finance recovery rate is structurally lower than the Euler outcome (~100%) and structurally higher than the Multichain outcome (~0%); it is middle-of-band for the partial-return whitehat-framed sub-pattern. Contributors writing the recovery-layer documentation for future T2.002 / T9.004 cases should treat this band as a discrete recovery sub-class — the negotiation framework is bilateral with the project / locker team, the on-chain memo channel is the load-bearing communication surface, and the partial-return rate appears to be set by the attacker's own discretionary determination rather than by an enforceable contractual mechanism.

For OAK's broader credibility, including Team Finance in v0.1 closes the T2 2022 historical cell and adds the cleanest available locker-side T2.002 worked example to the corpus. The case also contributes to the v0.x candidate list of recurring observations that contributors should preserve in What defenders observed sections (recently-introduced privileged-pathway as elevated-risk surface; transitive-trust-assessment requirement for multi-layer trust-substrate claims).