OAK — OnChain Attack Knowledge

Worked example · 2026-07

Lien Finance — an internal rate function prices attacker-crafted bonds far above the collateral actually backing them — Lien Finance (Ethereum) — 2026-07-24

Loss
$542,144 USDC from Lien Finance on Ethereum.
OAK Techniques observed
OAK-T9.004 (Access-Control Misconfiguration — primary, confirmed mechanism class, recorded here in its contract-correctness / valuation-predicate shape rather than its permissions shape. The defect sits in the pricing logic of the internal _calcRateBondToErc20 function, which valued attacker-crafted bonds at a level that dramatically overvalued them relative to the collateral actually backing them. The attacker did not hold a privilege they should not have had and did not bypass a check — they supplied inputs the valuation function mispriced, and redeemed against its answer. See techniques/T9.004-access-control-misconfiguration.md). OAK-T9.001 (Oracle Price Manipulation — not recorded: no external price feed was involved. The mispricing originated inside the protocol's own bond-rate arithmetic, which is what distinguishes this from an oracle case).
Attribution
pseudonymous. No named individual or group, and no public link to a tracked OAK actor. No laundering path has been publicly detailed.
Key teaching point
A protocol that mints its own instrument must be able to state, as an enforced invariant, that no instrument is worth more than the collateral behind it. Lien's bonds were priced by an internal function rather than an external feed, so there was no oracle to manipulate and no market to move — the attacker simply constructed bonds whose parameters the rate arithmetic handled badly, and the protocol paid out its own valuation. This is the failure mode that oracle-hardening work does not touch, and it is easy to under-weight precisely because "we don't depend on an oracle" reads as a strength. The control is a conservation assertion at the redemption boundary: before honouring a redemption, check that the value being released does not exceed the collateral recorded against the position, and revert if it does. That check is independent of how the rate was computed and would have held regardless of which input combination confused the arithmetic — which is the point, since the specific bad input is the thing nobody found in review. Two supporting practices follow: property-based and fuzz testing of valuation functions across their full input domain, rather than the representative cases unit tests cover, and per-transaction redemption caps that bound the damage when the assertion is the thing that turns out to be missing.

Summary

Lien Finance is a DeFi protocol on Ethereum that issues bond-like instruments redeemable against collateral. Redemption value is computed by an internal rate function, _calcRateBondToErc20, which converts a bond position into an ERC-20 payout.

On 2026-07-24, an attacker crafted bonds whose parameters that pricing logic handled incorrectly. The function priced them at a level that dramatically overvalued them relative to the actual collateral backing, and the protocol honoured the resulting redemption, paying out $542,144 USDC.

No external oracle or price feed was involved: the mispricing arose entirely within the protocol's own valuation arithmetic. The incident fell in the same week as the AFX Trade, Wanchain, Verus, B² Network, and Allbridge Core compromises, a cohort whose confirmed damage exceeded $47M.

Timeline (UTC)

When Event OAK ref
(standing) _calcRateBondToErc20 computes bond redemption value internally, with no enforced invariant bounding payout by recorded collateral (standing T9.004 surface)
2026-07-24 Attacker constructs bonds whose parameters the rate function overvalues relative to their collateral backing T9.004 setup
2026-07-24 Redemption honoured at the inflated valuation; $542,144 USDC paid out T9.004 exploitation

What defenders observed

  • Pre-event (no conservation invariant at redemption). The single missing control. A payout must be bounded by the collateral recorded against the position being redeemed; asserting that bound at the redemption boundary catches every mispricing the rate function can produce, including the ones review did not anticipate (M17).
  • Pre-event (internal valuation functions are under-reviewed relative to oracles). Oracle manipulation has attracted years of dedicated tooling and audit attention. A protocol computing prices from its own arithmetic sidesteps that entire threat model — and, with it, the review reflexes built around it. "No oracle dependency" removes one attack surface and creates another that is inspected less.
  • Pre-event (unit tests cover representative inputs; attackers select adversarial ones). The attacker's bonds were crafted, meaning they occupied a region of the input domain that ordinary usage does not reach. Property-based and fuzz testing of valuation functions — asserting that payout never exceeds backing, across the whole domain rather than at chosen points — is the testing practice that finds this before deployment (M23).
  • At-event (payout-to-collateral ratio is directly observable). A redemption paying out materially more than the position's recorded backing is computable in the same transaction that performs it. Whether enforced as a revert or emitted as an alert, this ratio is the detection signal, and it requires no understanding of the underlying arithmetic defect (M04, M05).
  • At-event (no redemption cap). A per-transaction bound on redemption size would have limited the loss mechanically, independent of the pricing defect.

Public references

Discussion

Lien is the smallest loss in OAK's July 2026 cohort and carries a mechanism disproportionate to its size, because it is the month's only case of a protocol being defeated by its own arithmetic on its own instrument. Everything else that month came from a key, an authority, an encoding, an off-chain parser, or borrowed capital. Here there was no external input to corrupt at all: the attacker chose bond parameters, the protocol computed a number, and the number was wrong.

That places it in a class OAK is thinly stocked on, and one worth watching. Protocols issuing structured instruments — bonds, tranches, principal/yield splits, fixed-rate positions — all carry internal valuation arithmetic of exactly this kind, typically with more edge cases than an AMM curve and considerably less adversarial scrutiny. The nearest corpus neighbours are examples/2026-07-summer-fi-lazy-summer-stale-ark-nav-donation-drain.md, where a stale NAV computation was exploited through a donation, and examples/2026-06-myswap-cl-starknet-fake-token-shared-vault-accounting-drain.md, where vault share accounting was subverted. All three share a signature: the protocol's internal accounting produced a number the protocol then honoured, with no independent check that the number was backed by anything.

The reason to keep small losses like this in the corpus is that severity here is set by the size of the protocol, not by the quality of the defect. The same missing conservation assertion on a system holding a hundred times the TVL produces a hundred times the loss with no change in mechanism. Contributors documenting this class should record the specific function name wherever public reporting supplies it — as here with _calcRateBondToErc20 — since a named function is what lets teams running similar instruments locate the equivalent code path in their own systems and check whether the payout-versus-backing assertion exists.

Techniques demonstrated (2)