iVESTDAO LP misclassification drain from reserve-accounting bug

1. Incident Overview TL;DR

On BSC, an adversary-drivable route through a non-designated iVESTDAO/WBNB Pancake pair 0x2607118d363789f841d952f02e359bfa483955f9 allowed buys to bypass iVESTDAO’s LP trading and vesting guards. Using a single adversary-crafted transaction, attacker EOA 0x4645863205b47a0a3344684489e8c446a437d66c drained WBNB from this pair while iVESTDAO’s internal invariants did not trigger for those trades.

iVESTDAO only enforces its LP trading toggles, buy-size bounds, and vesting logic when transfers originate from a single hard-coded _liquiditypool address 0x624B57FF42683F1C4582B55495A65D1B09654282; swaps routed through the alternative iVESTDAO/WBNB pair 0x2607118d363789f841d952f02e359bfa483955f9 are treated as ordinary transfers and completely bypass these safety checks.

2. Key Background

iVESTDAO token 0x786fcf76dc44b29845f284b81f5680b6c47302c6 is a verified ERC20 with custom buy-from-LP logic that aims to gate trading, cap transaction sizes, enforce minimum purchase amounts, and record vesting schedules whenever users buy from a designated liquidity pool. PancakeSwap V2 pairs such as 0x2607118d363789f841d952f02e359bfa483955f9 and the configured _liquiditypool 0x624B57FF42683F1C4582B55495A65D1B09654282 are standard AMM pools that can both hold the same token pair (iVESTDAO/WBNB) but have distinct contract addresses. The adversary uses a helper contract 0x8f921e27e3af106015d1c3a244ec4f48dbfcad14, deployed and exclusively controlled by EOA 0x4645863205b47a0a3344684489e8c446a437d66c, to orchestrate approvals and multi-hop swaps across WBNB, iVESTDAO, the Pancake router, and intermediary contracts.

3. Vulnerability Analysis & Root Cause Summary

The iVESTDAO contract attempts to protect users and treasury by applying trading and vesting rules only when from == _liquiditypool, but it fails to recognize that other iVESTDAO/WBNB pairs can also serve as liquidity sources. As a result, buys executed via pair 0x2607118d363789f841d952f02e359bfa483955f9 bypass these guards and allow an adversary to drain WBNB with no vesting or trade gating.

4. Detailed Root Cause Analysis

4.1 Invariant and Breakpoint

Invariant. For any iVESTDAO purchase originating from a liquidity pool that holds the iVESTDAO/WBNB pair, the transfer from the pool contract to the buyer must be subject to global trading toggles, per-buy amount limits, and vesting logic so that no account can freely extract large amounts of WBNB-backed liquidity without satisfying these constraints.

Breakpoint. In iVESTDAO._transfer(address from, address to, uint256 amount), the branch that enforces LP-specific checks is guarded by if (from == _liquiditypool). During the exploited tx, the actual sender of user-facing iVESTDAO transfers is the Pancake pair 0x2607118d363789f841d952f02e359bfa483955f9, which is not equal to the hard-coded _liquiditypool 0x624B57FF42683F1C4582B55495A65D1B09654282. This causes execution to skip _transferFromLP and fall through to the generic _tokenTransfer path, leaving LP-originating buys completely ungated.

4.2 Victim Contract Code Snippets

Seed contract snippet (iVESTDAO liquidity pool configuration):

address public _liquiditypool= 0x624B57FF42683F1C4582B55495A65D1B09654282;
    address public LiquidityShield = 0x6E801db20b180E267cd1f2A01d27763B68B54e53;
    address public DAOwallet = 0x0CaB1Cd11967a95Edb7331e00c2c328eF0a4D344;
    address public _vestin

Seed contract snippet (LP-specific transfer path with trading and vesting guards):

function _transferFromLP(address sender, address recipient, uint256 tAmount, bool isWhale) private {
        (uint256 rAmount, uint256 rTransferAmount, uint256 rFee, uint256 tTransferAmount, uint256 tFee, uint256 tLiquidity,uint256 tBurn) = _getValues(tAmount);
        
        if (!_isExcluded[address(msg.sender)]||!_isExcluded[recipient]){
            require(_MASTER_WALLETSCANTRADE_FLAG,"iVest: Trading is not enabled at this moment.");
        }

        if (!_isExcluded[recipient] && _MASTER_TRANSFERS_ENABLED==true){
            require(tAmount <= _maxTxAmount, "iVest: LP transfer

4.3 How the Misclassification Leads to Exploitation

The verified iVESTDAO contract defines a single address _liquiditypool intended to represent the canonical iVESTDAO/WBNB liquidity pool. In its overridden _transfer function, transfers with from == _liquiditypool are treated as buys from this LP and routed into _transferFromLP, which checks that trading is enabled (_MASTER_WALLETSCANTRADE_FLAG), enforces maximum and minimum buy sizes, records vesting schedules, and applies fee logic that routes tokens to LiquidityShield, DAOwallet, and the vesting pool. Transfers that do not satisfy from == _liquiditypool bypass this path and are processed by _tokenTransfer as ordinary ERC20 transfers.

On BSC, there exists a second Pancake pair 0x2607118d363789f841d952f02e359bfa483955f9 that also holds the iVESTDAO/WBNB pair. When the adversary routes swaps through this pair via the public Pancake router, the pair contract becomes the sender of iVESTDAO tokens to buyers and protocol addresses. Because 0x2607…55f9 != _liquiditypool, iVESTDAO’s _transfer sees from equal to the secondary pair, not the hard-coded pool, so the LP-buy branch is never taken and the LP-specific safety checks and vesting logic are never applied to these trades.

The adversary’s aggregator 0x8f92…d14 arranges repeated swaps against 0x2607…55f9, causing that pair to send large amounts of iVESTDAO to the attacker cluster and protocol addresses while WBNB flows from the pair to the attacker. Balance diffs confirm that the pair loses 338.875088869257198253 WBNB and a huge amount of iVESTDAO, while the attacker’s combined BNB+WBNB holdings increase by 338.196690706544239879 BNB net of gas. Because all calls go through public contracts and the only requirement is that the adversary route through the secondary pair rather than the hard-coded _liquiditypool, any unprivileged adversary who can deploy a helper contract and fund it with WBNB can reproduce this exploit strategy.

4.4 Vulnerable Components and Conditions

Vulnerable components:

• iVESTDAO token contract 0x786fcf76dc44b29845f284b81f5680b6c47302c6, specifically the _transfer and _transferFromLP functions and the hard-coded _liquiditypool address.
• The existence and configuration of the secondary Pancake iVESTDAO/WBNB pair 0x2607118d363789f841d952f02e359bfa483955f9, which is not reflected in iVESTDAO’s internal _liquiditypool variable but is fully usable via the public Pancake router.

ACT exploit conditions:

• There exists at least one iVESTDAO/WBNB liquidity pool contract other than the hard-coded _liquiditypool address, with sufficient WBNB and iVESTDAO reserves, and accessible via a public DEX router.
• iVESTDAO’s _transfer function only treats transfers from the single _liquiditypool address as buys and routes them through _transferFromLP; transfers from any other pair address follow the generic _tokenTransfer path without enforcing trading toggles, size limits, or vesting.
• An unprivileged adversary can fund an EOA with WBNB, deploy or control a helper contract that interacts with the Pancake router, and submit a transaction that routes swaps through the secondary iVESTDAO/WBNB pair.

Violated security principles:

• Broken assumption that a single hard-coded LP address is sufficient to cover all on-chain liquidity sources for a token across a DEX ecosystem where additional pairs can be created permissionlessly.
• Insufficient invariant enforcement for state changes that depend on the economic role of a contract (liquidity pool) rather than its specific address, leading to access-control bypass when identical functionality is reachable via another contract instance.
• Failure to design LP-facing protections in a way that is robust to new pools and routing paths, creating a patchwork of guarded and unguarded liquidity that sophisticated adversaries can selectively target.

5. Adversary Flow Analysis

The adversary deploys and controls a helper contract that orchestrates WBNB-funded swaps through a secondary iVESTDAO/WBNB Pancake pair that iVESTDAO does not recognize as its liquidity pool, allowing buys that bypass trading and vesting guards and enabling extraction of WBNB from the pool in a single transaction.

5.1 Adversary-Related Accounts and Victim Candidates

Adversary-related cluster:

• BSC chainid 56 address 0x4645863205b47a0a3344684489e8c446a437d66c (EOA=true, contract=false): Sender of the adversary-crafted seed tx, direct recipient of the net WBNB profit, and deployer/controller of helper contract 0x8f921e27e3af106015d1c3a244ec4f48dbfcad14 according to address txlists and decompiled access-control checks.
• BSC chainid 56 address 0x8f921e27e3af106015d1c3a244ec4f48dbfcad14 (EOA=false, contract=true): Helper/aggregator contract created by 0x4645…7d66c that approves routers, pulls WBNB, and executes the multi-hop swap sequence; decompiled source shows msg.sender must equal 0x4645…7d66c for main entrypoints, tying the contract’s control to the adversary EOA.

Victim candidates:

• iVESTDAO token at 0x786fcf76dc44b29845f284b81f5680b6c47302c6 on BSC chainid 56 (verified=true)
• iVESTDAO/WBNB Pancake pair (secondary pool) at 0x2607118d363789f841d952f02e359bfa483955f9 on BSC chainid 56 (verified=true)

5.2 Lifecycle Stages and Evidence

Stage – Adversary helper deployment and control:

• Transactions: BSC chainid 56 tx 0xbea712f5c576294eeb953864c4336fa627b4fbef0f28c40a1584cb45b0713c21 in block 41287783 (deploy)
• Effect: EOA 0x4645…7d66c deploys helper/aggregator contract 0x8f92…d14, which will later be used to orchestrate approvals and swaps for the exploit.
• Evidence: Address txlist for 0x8f921e27e3af106015d1c3a244ec4f48dbfcad14 under artifacts/root_cause/data_collector/iter_2/address/56/ and decompiled source at artifacts/root_cause/data_collector/iter_1/contract/56/0x8f921e27e3af106015d1c3a244ec4f48dbfcad14/decompile/.

Stage – Funding and preparation:

• Transactions: BSC chainid 56 tx 0x12f27e81e54684146ec50973ea94881c535887c2e2f30911b3402a55d67d121d in block 41289498 (transfer)
• Effect: Within the exploit tx itself, address 0x9b00a09492a626678e5a3009982191586c444df9 transfers 1,200 WBNB to the helper contract 0x8f92…d14, providing the working capital for the sequence of swaps.
• Evidence: WBNB Transfer logs and trace_callTracer.json under artifacts/root_cause/data_collector/iter_1/tx/56/0x12f2…121d/ show the 1,200 WBNB transfer into 0x8f92…d14.

Stage – Exploit execution via secondary pair:

• Transactions: BSC chainid 56 tx 0x12f27e81e54684146ec50973ea94881c535887c2e2f30911b3402a55d67d121d in block 41289498 (swap)
• Effect: The helper 0x8f92…d14 approves the Pancake router and intermediary contracts, then routes multiple swaps through the iVESTDAO/WBNB pair 0x2607…55f9. The pair transfers large amounts of iVESTDAO to the adversary, LiquidityShield, DAOwallet, the vesting pool, and burn, while WBNB flows from the pair to the helper and then to the adversary EOA and the original funder.
• Evidence: debug_traceTransaction(callTracer) and ERC20 Transfer logs for the seed tx show repeated swap() calls on 0x2607…55f9, iVESTDAO.transfer() calls originating from this pair into protocol and adversary addresses, and WBNB.transfer() calls delivering 338.275088869257198253 WBNB to the adversary EOA and 0.6 WBNB to 0x9b00…4df9 while the pair loses 338.875088869257198253 WBNB.

Stage – Profit realization:

• Transactions: BSC chainid 56 tx 0x12f27e81e54684146ec50973ea94881c535887c2e2f30911b3402a55d67d121d in block 41289498 (transfer)
• Effect: After unwinding the swaps, the adversary EOA holds 338.275088869257198253 WBNB more than before minus 0.078398162712958374 BNB in gas, for a net portfolio gain of 338.196690706544239879 BNB, while the victim pair loses WBNB and iVESTDAO reserves.
• Evidence: Balance diffs in artifacts/root_cause/seed/56/0x12f2…121d/balance_diff.json for WBNB and native BNB at address 0x4645…7d66c and 0x2607…55f9, combined with tx receipt gas usage.

Example trace snippet (swap via secondary iVESTDAO/WBNB pair and downstream iVESTDAO.transfer calls):

"output": "0x000000000000000000000000000000000000000000000000000001007800cc0d000000000000000000000000000000000000000000000016725c40de6ae96b960000000000000000000000000000000000000000000000000000000066b918f0",
                            "to": "0x2607118d363789f841d952f02e359bfa483955f9",
                            "type": "STATICCALL"
                          },
                          {
                            "from": "0x10ed43c718714eb63d5aa57b78b54704e256024e",
                            "gas": "0xce6e6b",
                            "gasUsed": "0x216",
                            "input": "0x70a082310000000000000000000000002607118d36378

6. Impact & Losses

Token-level losses:

• WBNB: 338.875088869257198253
• iVESTDAO: 12352160271636451384209786817778788676651367529321190960497014342566796435615

During the exploit tx, the iVESTDAO/WBNB Pancake pair 0x2607118d363789f841d952f02e359bfa483955f9 loses 338.875088869257198253 WBNB and a very large quantity of iVESTDAO tokens, while the attacker’s net portfolio value increases by 338.196690706544239879 BNB. The protocol’s intended protections (trading toggles, buy-size limits, and vesting) do not activate for these trades, leaving LP liquidity unprotected when accessed through the secondary pair.

7. References

[1] Seed transaction metadata and trace – <REDACTED_LOCAL_PATH> [2] iVESTDAO verified source and ABI – <REDACTED_LOCAL_PATH> [3] Pancake pair 0x2607…55f9 verified source – <REDACTED_LOCAL_PATH> [4] Helper contract 0x8f92…d14 decompiled code – <REDACTED_LOCAL_PATH>