Perpetual Protocol (Curie) Exploit — Missing Access Control on `OrderBook.updateFundingGrowthAndLiquidityCoefficientInFundingPayment()`

Source & credit. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. Standalone Foundry PoC and full write-up: 2026-07-PerpetualProtocol_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/PerpetualProtocol_exp.sol.

Vulnerability classes: vuln/access-control/missing-auth · vuln/access-control/missing-modifier · vuln/logic/incorrect-state-transition

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder. Full verbose trace: output.txt. The attack lives entirely inside a CREATE constructor (the deployed runtime is a one-instruction revert stub), so the faithful replay deploys the exact creation bytecode from the real incident tx at the pre-attack block and lets the constructor run. Verified vulnerable source for both hit deployments: OrderBook (sources/OrderBook_a0d996, sources/OrderBook_6ba447).

Key info#

TL;DR#

Perpetual Protocol V2 ("Curie") is a perpetual-futures DEX that reuses Uniswap V3's concentrated-liquidity math as its virtual AMM. Its OrderBook contract tracks each liquidity maker's cached "time-weighted premium" (twPremium) checkpoints so that funding payments can be settled lazily. Every state-mutating OrderBook function that is meant to be called only by a trusted internal contract carries a caller check — except one: updateFundingGrowthAndLiquidityCoefficientInFundingPayment(), whose only intended caller is the market's Exchange contract, has no check at all.

The attacker, in a single CREATE-only transaction, against two independent Perpetual Protocol V2 deployments (both trading a vETH market on Optimism) in one shot:

1. Calls ClearingHouse.addLiquidity() with a dust order — base = 2, quote = 1 wei (output.txt:1576) — just to create a maker OpenOrder entry the OrderBook will track funding-growth checkpoints for.
2. Calls the unguarded OrderBook.updateFundingGrowthAndLiquidityCoefficientInFundingPayment() directly (not through Exchange), passing a fabricated twPremiumX96 = 10^70 (output.txt:1880) — roughly 10³¹× larger than the real, oracle-derived value seen moments earlier in the same trace (~3.549×10³⁹, output.txt:1639). This permanently overwrites the dust order's lastTwPremiumGrowthInsideX96 / lastTwPremiumGrowthBelowX96 checkpoints with the poisoned value.
3. Calls Vault.withdraw() (output.txt:1894), which triggers ClearingHouse.settleAllFunding() → Exchange.settleFunding() → OrderBook.…FundingPayment() again, this time with the real (small) global funding growth (output.txt:1942). The funding-payment formula diffs the real value against the poisoned checkpoint, producing an astronomically large owedRealizedPnl credit.
4. Vault.withdraw() sees a free-collateral check that is now trivially satisfied and pays out the vault's entire real USDC.e balance to the attacker.
5. Steps 1–4 repeat against the second, independently-deployed market/vault in the same tx.

Result: Vault #1 loses 71.777612 USDC.e, Vault #2 loses 2,990.435495 USDC.e, and the attacker EOA's balance rises from 0 → 3,062.213107 USDC.e (output.txt:2678–output.txt:2681) — exactly the sum of both vaults' losses, with no capital risked beyond gas.

Background — Perpetual Protocol V2 ("Curie") architecture#

Perpetual Protocol V2 builds a perpetual-futures market on top of Uniswap V3's tick/liquidity math, using a set of cooperating contracts per deployment:

This incident hit two separate deployments of this exact architecture — both trading a market whose base token is named vETH (Perpetual Protocol's standard virtual-asset naming convention) — confirmed by fetching each contract's verified source independently:

Both OrderBook implementations are separately deployed, separately verified bytecode (different addresses, no shared proxy) — yet both independently carry the exact same missing check, confirming this is a defect baked into the deployed codebase used for both instances, not a one-off configuration mistake.

The vulnerable code#

OrderBook.sol gates every function meant to be called only by a specific privileged caller. addLiquidity, removeLiquidity, removeLiquidityByIds, and updateOrderDebt all call _requireOnlyClearingHouse() as their first line (sources/OrderBook_a0d996/contracts_OrderBook.sol:99,178,200,275):

// contracts/base/ClearingHouseCallee.sol (base contract; shared by OrderBook, Exchange, Vault, ...)
function _requireOnlyClearingHouse() internal view {
    // only ClearingHouse
    require(_msgSender() == _clearingHouse, "CHD_OCH");
}

replaySwap() — the function whose only intended caller is Exchange — likewise gates itself inline (sources/OrderBook_a0d996/contracts_OrderBook.sol:290-292):

function replaySwap(ReplaySwapParams memory params) external override returns (ReplaySwapResponse memory) {
    // OB_OEX: only exchange
    require(_msgSender() == _exchange, "OB_OEX");
    ...

But updateFundingGrowthAndLiquidityCoefficientInFundingPayment() — whose only intended caller is also Exchange (it is invoked from Exchange._updateFundingGrowth(), itself called from Exchange.settleFunding()) — has no caller check whatsoever (sources/OrderBook_a0d996/contracts_OrderBook.sol:232-263):

/// @inheritdoc IOrderBook
function updateFundingGrowthAndLiquidityCoefficientInFundingPayment(
    address trader,
    address baseToken,
    Funding.Growth memory fundingGrowthGlobal          // <-- caller-supplied, ZERO validation
) external override returns (int256 liquidityCoefficientInFundingPayment) {
    bytes32[] memory orderIds = _openOrderIdsMap[trader][baseToken];
    mapping(int24 => Tick.GrowthInfo) storage tickMap = _growthOutsideTickMap[baseToken];
    address pool = IMarketRegistry(_marketRegistry).getPool(baseToken);

    uint256 orderIdLength = orderIds.length;
    (, int24 tick, , , , , ) = UniswapV3Broker.getSlot0(pool);
    for (uint256 i = 0; i < orderIdLength; i++) {
        OpenOrder.Info storage order = _openOrderMap[orderIds[i]];
        Tick.FundingGrowthRangeInfo memory fundingGrowthRangeInfo =
            tickMap.getAllFundingGrowth(
                order.lowerTick,
                order.upperTick,
                tick,
                fundingGrowthGlobal.twPremiumX96,                     // attacker value flows straight in
                fundingGrowthGlobal.twPremiumDivBySqrtPriceX96
            );

        liquidityCoefficientInFundingPayment = liquidityCoefficientInFundingPayment.add(
            Funding.calcLiquidityCoefficientInFundingPaymentByOrder(order, fundingGrowthRangeInfo)
        );

        // thus, state updates have to come after — PERMANENTLY POISONS the order's checkpoint
        order.lastTwPremiumGrowthInsideX96 = fundingGrowthRangeInfo.twPremiumGrowthInsideX96;
        order.lastTwPremiumGrowthBelowX96 = fundingGrowthRangeInfo.twPremiumGrowthBelowX96;
        order.lastTwPremiumDivBySqrtPriceGrowthInsideX96 = fundingGrowthRangeInfo
            .twPremiumDivBySqrtPriceGrowthInsideX96;
    }

    return liquidityCoefficientInFundingPayment;
}

Tick.getAllFundingGrowth() uses the caller-supplied twPremiumGrowthGlobalX96 directly to derive twPremiumGrowthBelowX96 / twPremiumGrowthInsideX96 (sources/ClearingHouse_b0f82b/contracts_lib_Tick.sol:87-89):

fundingGrowthRangeInfo.twPremiumGrowthBelowX96 = currentTick >= lowerTick
    ? lowerTwPremiumGrowthOutsideX96
    : twPremiumGrowthGlobalX96 - lowerTwPremiumGrowthOutsideX96;   // attacker's 1e70 lands here

For comparison, the official open-source reference implementation gates this exact function (perpetual-protocol/perp-curie-contract, contracts/OrderBook.sol):

function updateFundingGrowthAndLiquidityCoefficientInFundingPayment(
    address trader,
    address baseToken,
    Funding.Growth memory fundingGrowthGlobal
) external override returns (int256 liquidityCoefficientInFundingPayment) {
    _requireOnlyExchange();     // <-- present upstream, ABSENT in both deployed contracts
    ...

Both deployed OrderBook implementations (market #1 and market #2) omit this line entirely — this is a genuine access-control regression versus the reference codebase, not a design choice.

Root cause#

1. The intended caller-restriction (_requireOnlyExchange()) was dropped from updateFundingGrowthAndLiquidityCoefficientInFundingPayment() in both deployed OrderBook implementations, while every sibling privileged function (addLiquidity/removeLiquidity/removeLiquidityByIds/updateOrderDebt → _requireOnlyClearingHouse(); replaySwap → inline _exchange check) retains its guard. The function became callable by anyone, with fully attacker-controlled funding-growth values.
2. The function both computes AND permanently writes state in the same call, with no plausibility bound on the input. A legitimate call passes an oracle/TWAP-derived twPremiumX96 (observed real value: ~3.549×10³⁹, output.txt:1639); the function accepts and stores literally any int256, including 10⁷⁰ — a value no real market condition could ever produce.
3. The poisoned checkpoint is asymmetric and persistent. Once order.lastTwPremiumGrowthInsideX96/…BelowX96 is overwritten with the attacker's value, the next legitimate settlement (triggered by anyone — here, the attacker's own Vault.withdraw()) diffs the real, small global growth against the poisoned checkpoint, producing a funding-payment coefficient whose magnitude is dominated entirely by the fabricated value, not by any real market movement.
4. Vault.withdraw() trusts owedRealizedPnl as genuinely-settled state — by design, it force-settles funding immediately before checking free collateral (sources/Vault_015f7e/contracts_Vault.sol:122-152), so any account whose funding bookkeeping is corrupted can pass the free-collateral check for an arbitrarily large withdrawal — up to the real USDC.e sitting in the vault (and beyond, via the insurance fund, if the vault balance were insufficient).
5. A single dust liquidity order (base=2, quote=1 wei) is enough to create an OpenOrder entry for the OrderBook to track and poison — the attack needs no meaningful capital, only gas.

Preconditions#

• OrderBook.updateFundingGrowthAndLiquidityCoefficientInFundingPayment() is external with no caller restriction (confirmed on-chain via verified source for both hit deployments).
• The attacker holds (or creates, via a dust addLiquidity) at least one open maker order on the target market so the poisoning call has an OpenOrder entry to corrupt.
• Vault.withdraw() (or any other path that calls ClearingHouse.settleAllFunding) re-settles funding using the poisoned checkpoint before checking free collateral.
• The target vault holds real USDC.e to drain.

No flash loan, no oracle manipulation, no privileged role, no timing dependency — the exploit is fully permissionless and self-contained in one transaction's constructor.

Attack walkthrough (with on-chain numbers from the trace)#

All figures are raw base units from output.txt; USDC.e has 6 decimals.

Profit / loss accounting (USDC.e, this tx)#

Diagrams#

Sequence of the attack (per market, run twice in one tx)#

Why the guard gap matters — sibling functions vs. the vulnerable one#

State poisoning then exploitation at settlement#

Remediation#

1. Restore the caller check. Add _requireOnlyExchange(); as the first line of updateFundingGrowthAndLiquidityCoefficientInFundingPayment(), matching both the sibling OrderBook functions' pattern and the upstream reference implementation. This alone closes the exploit entirely — the function was never intended to be user-callable.
2. Bound the accepted funding-growth values. Even with the caller restricted to Exchange, defense-in-depth would clamp twPremiumX96 / twPremiumDivBySqrtPriceX96 to a sane range derived from realistic price/time bounds, so a compromised or buggy Exchange cannot poison OrderBook state either.
3. Add an invariant check before paying out in Vault.withdraw(). Sanity-bound owedRealizedPnl (e.g., against the position's notional size and a maximum realistic funding rate) before trusting it to authorize a withdrawal — a defense-in-depth backstop against any future accounting-corruption bug elsewhere in the funding pipeline.
4. Differential audit against the reference implementation. Since this defect is a regression versus the public perp-curie-contract reference source (which has the _requireOnlyExchange() check), a systematic diff between deployed bytecode/source and the upstream reference for every access-controlled function would have caught this before deployment.
5. Redeploy the affected OrderBook implementations with the check restored, and audit every other maker-order-mutating function in both deployments for the same class of gap.

How to reproduce#

The PoC runs fully offline via the shared harness, serving the fork from a local anvil snapshot (anvil_state.json) on 127.0.0.1:8550 — exactly what createSelectFork("http://127.0.0.1:8550", ATTACK_BLOCK - 1) in the test points at (test/PerpetualProtocol_exp.sol:125). No public RPC is used.

_shared/run_poc.sh 2026-07-PerpetualProtocol_exp -vvvvv

• Chain: Optimism archive state at block 154,311,431 (one block before the attack), served from the local anvil instance (port 8550).
• EVM: evm_version = "cancun" (foundry.toml).
• Result: [PASS] testExploit() — attacker EOA USDC.e balance rises from 0 to 3,062.213107, both vaults drained to 0.

Expected tail:

Ran 1 test for test/PerpetualProtocol_exp.sol:PerpetualProtocolExp
[PASS] testExploit() (gas: 2263963)
Logs:
  attacker EOA USDC before: 0.000000
  vault#1 USDC before: 71.777612
  vault#2 USDC before: 2990.435495
  attacker EOA USDC after: 3062.213107
  attacker profit: 3062.213107
  vault#1 USDC after: 0.000000
  vault#2 USDC after: 0.000000

Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 65.33ms (59.74ms CPU time)

(Balances logged at output.txt:1568–output.txt:1570 and output.txt:2678–output.txt:2681; suite result at output.txt:2692.)

Reference: on-chain incident tx 0xb0a8a3cc76fb17bf965ab1dee3b76b62f79ca72def31e12f8ad8b1711625df08 (Optimism, block 154,311,432, 2026-07-16); root-cause and constructor-argument analysis per the original DeFiHackLabs PoC comments in test/PerpetualProtocol_exp.sol.

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2026-07-PerpetualProtocol_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: PerpetualProtocol_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

• DeFiHackLabs incident explorer: search "Perpetual Protocol (Curie) Exploit".
• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.