Calculated from recorded token losses using historical USD prices at the incident time.
0x12f27e81e54684146ec50973ea94881c535887c2e2f30911b3402a55d67d121d0x2607118d363789f841d952f02e359bfa483955f9BSCOn 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.
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.
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.
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.
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
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.
Vulnerable components:
ACT exploit conditions:
Violated security principles:
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.
Adversary-related cluster:
Victim candidates:
Stage – Adversary helper deployment and control:
Stage – Funding and preparation:
Stage – Exploit execution via secondary pair:
Stage – Profit realization:
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
Token-level losses:
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.
[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>