Cowrie Research

gamma-strategies-stable-lst-vault-price-threshold-misconfiguration-lp-overmint-2024-01-04

12 min read

Gamma Strategies Stable/LST Vault Price-Threshold Misconfiguration / LP Overmint (2024-01-04)

  • Name: Gamma Strategies stable/LST vault price-threshold misconfiguration / LP overmint
  • Date: 2024-01-04
  • Protocol: Gamma Strategies
  • Chain: Arbitrum
  • Category: vault deposit-guard misconfiguration / oracle configuration failure / flash-loan price manipulation / LP-share overmint
  • Loss: about $6.18 million across four Arbitrum vaults
  • Summary: Gamma’s affected Arbitrum vaults relied on deposit-proxy guardrails that were supposed to reject deposits when pool price moved too far from TWAP. After Gamma’s 2023 stable/LST hardening pass, an offchain automation error configured some vaults with an economically absurd tolerated move — roughly -50% / +100% instead of the intended 2% band. The attacker used flash loans to push pool prices up to that protocol-approved ceiling, deposited at the manipulated ratio, received too many vault LP claims, and looped deposit/withdraw paths until the vaults had handed out millions in excess value.
  • Trigger / entry point:
    • Gamma’s public vaults exposed deposit flows through deposit-proxy logic that enforced four anti-flash-loan style checks: token-ratio conformity with the pool, a spot-vs-TWAP price-change threshold, per-deposit caps, and a ban on single-sided deposits.
    • On 2023-09-14, Gamma rolled out new stable/LST deposit-safety settings with longer TWAP intervals and what should have been a tighter 2% style price-change threshold.
    • The offchain automation that emitted those settings instead mis-set the admissible price window on the affected vaults to approximately -50% / +100%.
    • That meant a strongly manipulated spot price could still be considered deposit-safe by the vault so long as it stayed inside the accidentally wide configured band.
  • Root cause:
    • The decisive failure was not that Gamma lacked deposit-protection logic. The failure was that the protocol’s own safety configuration turned a manipulated spot price into acceptable minting input.
    • Gamma’s vaults for stablecoin and pegged-asset pairs assumed the deposit proxy would reject economically implausible spot deviations before new shares were minted.
    • An arithmetic error in the team’s automation scripts silently broadened that admissible window enough that flash-loan price distortion remained inside policy, even though the intended production setting was only about 2%.
    • In short: Gamma published the wrong risk boundary onchain, and vault minting then treated attacker-shaped prices as protocol-approved truth.
  • Exploit path:
    1. The attacker funded address 0x5351536145610aa448a8bf85ba97c71caf31909c and began the exploit around 03:30 UTC on 2024-01-04, with example attack transaction 0x025cf2858723369d606ee3abbc4ec01eab064a97cc9ec578bf91c6908679be75 at Arbitrum block 166874977.
    2. Using flash loans from Uniswap and Balancer, the attacker pushed the relevant pool price in affected Gamma-managed stable and LST vaults upward toward the configured threshold.
    3. The attacker then deposited into Gamma vaults while the manipulated price still satisfied the mistakenly broad deposit-proxy bound.
    4. Because the vault deposit logic accepted the distorted ratio as safe, the attacker received a disproportionately high amount of LP / vault share exposure for the assets deposited.
    5. They looped the same manipulate spot -> deposit at attacker-favorable ratio -> withdraw against real inventory sequence repeatedly; Gamma’s own postmortem says the gDAI-DAI leg alone was iterated across five transactions from the same attacker address.
    6. Gamma later identified four materially affected Arbitrum vaults: gDAI-DAI on Uniswap, wstETH-WETH on Camelot, USDT-USDC.e on Camelot, and USDC-USDC.e on Ramses.
  • What the attacker needed to be true:
    • The attacker needed a deposit path whose minting logic depended on spot price remaining within a configurable TWAP-deviation threshold.
    • That threshold had to be set wide enough that flash-loan manipulation could stay inside the supposedly safe band.
    • The targeted vaults needed enough live TVL that overminted LP claims could be withdrawn into meaningful real assets.
    • Deposits had to remain enabled; Gamma’s emergency mitigation was simply to shut deposits off, which removed the attack surface immediately.
  • Technical anatomy worth remembering:
    • This was not a pure AMM price manipulation incident where another protocol blindly trusted a raw spot feed. Gamma had a defense layer, but the defense layer itself was misconfigured.
    • The exploit therefore belongs with oracle-configuration failures more than with ordinary thin-market price printing. The protocol’s own protective wrapper declared attacker-shaped prices acceptable.
    • The manipulated object was not a borrow-market collateral feed; it was the vault’s own deposit-admission and share-minting path. That still makes it a solvency problem, because the vault minted ownership claims against a false relative price.
    • Gamma’s postmortem is especially useful because it narrows the mistake to generated configuration, not abstract code quality: longer-TWAP stable/LST safeguards were added for safety, but the emitted numbers broadened the live admissible band enough to authorize the attack.
    • That makes the offchain automation itself part of the security boundary. A miscomputed threshold in a script became onchain balance-sheet truth the moment deposits trusted it.
  • Representative transactions and artifacts:
    • Attacker EOA: 0x5351536145610aa448a8bf85ba97c71caf31909c
    • Example attack contract: 0x4b57adc00ac38f74506d29fc4080e3dc65b78a69
    • Example attack transaction: 0x025cf2858723369d606ee3abbc4ec01eab064a97cc9ec578bf91c6908679be75
    • Example start block: 166874977
    • Affected vaults and reported losses:
      • gDAI-DAI 0.01% (Uniswap Arbitrum) vault 0x33985Ca762541e2412F454c6F2e7EC677645D1dF — about $2.74M
      • wstETH-WETH (Camelot Arbitrum) vault 0x3D53aC3Abec01827cAaE5Bc934d46b171cEa2206 — about $771K
      • USDT-USDC.e (Camelot Arbitrum) vault 0x61A7b3dae70D943C6f2eA9ba4FfD2fEcc6AF15E4 — about $1.357M
      • USDC-USDC.e (Ramses Arbitrum) vault 0x80709a760Ff54112bD3e0CE31C104d912bA51774 — about $1.313M
  • Response / mitigation:
    • Gamma immediately shut down deposits across public vaults because the exploit path depended on fresh deposits, while still allowing withdrawals.
    • The team publicly attributed the root cause to a miscalculation in offchain automation scripts that set vault deposit safety parameters.
    • Gamma later said it had sent an onchain message to the attacker from Gammastrategies.eth and published a recovery spreadsheet plus revenue-funded reimbursement plan for affected users.
    • Gamma also announced an OpenZeppelin audit focused on deposit-proxy configurations before reopening deposits.

Pattern tags

Why the exploit worked

  • Gamma’s vaults did not blindly trust pool spot in the abstract; they trusted a protocol-authored verdict that spot remained inside an acceptable deviation band. Once the automation error widened that band from an intended 2% tolerance to something like -50% / +100%, the guardrail itself became the thing authorizing the manipulated mint.
  • The attacker only needed to push price to the edge Gamma had already declared safe. That is a sharper failure than ordinary flash-loan oracle abuse: the protocol’s own deposit policy converted temporary pool distortion into acceptable share-issuance truth.
  • The exploitable state was durable across repeated loops because deposits stayed open and the same faulty configuration continued to certify each manipulated entry. This was not one lucky threshold crossing; it was a reusable minting surface until Gamma disabled deposits.
  • The balance-sheet boundary also sat partly offchain. Gamma’s September 2023 stable/LST hardening pass changed live deposit-admission semantics through generated configuration, so the security object was not only contract code but also the arithmetic in the automation that emitted those numbers.
  • The preserved design lesson is therefore broader than double-check scripts: when a generated threshold decides whether a vault may mint new ownership claims, configuration rollout, onchain parameter bounds, and share-issuance safety are one security object.

Detection and audit pivots

  • Reconstruct the exact publication path from config script to minted vault shares: automation output -> onchain deposit-proxy threshold -> spot-vs-TWAP admission check -> LP-share mint amount. If any step can widen tolerance enough that attacker-shaped spot stays policy-compliant, the protocol is still self-authoring false mint truth.
  • Ask whether the contract enforces sane outer bounds on price-change thresholds or merely assumes offchain tooling will emit reasonable values. If the intended production answer was 2%, why could an accidentally much wider band still become live authority at all?
  • Test stable and pegged-asset vaults with worst still-admissible prices, not only with intended settings. The right adversarial simulation here is manipulate spot to configured ceiling -> deposit -> withdraw -> repeat, because looping the admission boundary was the cash-out rail.
  • Review rollout discipline for generated risk settings: are new deposit-proxy parameters previewed, canaried, or temporarily capped before they gain full minting authority across live vaults?
  • Separate has anti-flash-loan checks from those checks still describe economically safe state. A vault can look defended in architecture diagrams while remaining exploitable because the defense thresholds themselves drifted into nonsense.
  • Check whether one vault-family configuration can fail broad-and-fast. Gamma’s affected set spanned Uniswap, Camelot, and Ramses, which means the script-emitted threshold family mattered more than any one AMM implementation detail.

Failure-prevention checklist

  • Put hard outer bounds on deposit-admission thresholds at the contract or governance layer so a stable/LST vault cannot silently move from an intended ~2% tolerance to a production-accepted -50% / +100% price window just because offchain automation emitted nonsense.
  • Separate preview / simulate / compare from activate live mint authority; teams should be able to inspect the exact deposit-proxy parameters and their downstream worst-case share-minting effect without those settings already authorizing production deposits.
  • Launch fresh or changed deposit-proxy configurations under bounded rights: lower deposit caps, temporary mint caps, canary vault subsets, or deposit pauses until the new threshold family proves coherent against independent references.
  • Treat generated config artifacts and script-emitted calldata as security-critical balance-sheet objects. Review the exact live threshold values, the exact vaults they touch, and the exact withdrawal / overmint loop those values could authorize.
  • Add invariant monitoring for admissible price move too wide for asset class, spot accepted near threshold edge, and share issuance jumps following threshold updates; those conditions should alert before repeated manipulate-deposit-withdraw loops can compound losses.
  • Keep a narrow kill switch for the exact publication surface that changed. Gamma’s broad deposit shutdown worked, but the better steady-state design is to freeze one vault family or one threshold regime faster than attackers can loop it across several venues.
  • Rehearse manipulate spot to configured ceiling -> deposit -> withdraw -> repeat simulations whenever deposit guards are changed on stable, pegged, or wrapper-priced vaults. If the worst still-admissible state is monetizable, the guard is already too permissive.
  • Distinguish defensive overlay exists from defensive overlay is economically coherent. Anti-flash-loan or TWAP-based wrappers should be audited like oracle systems because once they gate minting, they are part of solvency truth.

Audit prompts

  • What exact mint-authoritative object does this threshold publish right now: a tolerable spot/TWAP deviation, a deposit ratio envelope, or a full this manipulated state is safe to mint against verdict?
  • Can reviewers compute the worst still-admissible share issuance outcome from the proposed configuration without first making those settings live on production?
  • Which machine-enforced bounds stop an authenticated but absurd threshold from giving stable or pegged vaults effectively open-ended deposit authority?
  • If the threshold is wrong, how fast can the protocol freeze just that vault family or deposit-admission surface relative to the fastest flash-loan manipulation and withdrawal loop?
  • Do rollout procedures compare the exact emitted config values against intended economic policy, or only check that the script ran and the transactions succeeded?
  • Which vault classes inherit the same generated threshold family, and could one automation mistake simultaneously widen mint authority across several AMMs or wrappers?
  • What telemetry would show the guard is authorizing nonsense in real time: deposits landing at the threshold edge, repeated high-slippage mint/withdraw loops, or sudden share issuance against short-lived spot distortions?
  • Does the protocol treat deposit guards, TWAP wrappers, and anti-manipulation thresholds as oracle systems with their own staged rollout, or are they still reviewed as mere convenience configuration?

Lessons that should already be standard

  • A deposit-safety threshold that gates share minting is already balance-sheet infrastructure. It should be reviewed with the same seriousness as a price oracle or collateral factor.
  • We added more safety logic is not a control if the new safety layer can publish economically impossible state directly into mint authority.
  • Offchain automation belongs inside the security boundary whenever it emits parameters the contracts will immediately honor for share issuance or solvency decisions.
  • Stable and pegged vaults need adversarial review at the configured boundary, not just at intended operating points. The exploitable state is often the widest price move the protocol still says is fine.
  • A defensive wrapper can be the exploit primitive. Once a guardrail decides what deposits are safe, guardrail misconfiguration is no longer an operations footnote; it is the incident.
  • Broad emergency deposit shutdown can stop the bleed, but healthy design aims to make bad threshold publication fail small before a multi-vault, multi-AMM loop becomes possible.
  • The threshold was wrong only briefly is not meaningful protection when minting and withdrawal rights can be looped in the same manipulated window.

Why this incident matters

  • Gamma is a clean reminder that protection code exists is not the same as the protocol is protected.
  • The exploit shows how configuration and automation drift can turn a risk control into the exploit primitive itself.
  • It is also a useful case for concentrated-liquidity vaults specifically: share minting and deposit admission are part of the same security boundary as the underlying AMM pricing logic.

Internal linkages

Control surface

Graph View

Backlinks