Security Audit Report

An attacker first calls mint() with only validatorToken, creating a pool with zero reserveUserToken (Finding 1). Because the contract accepts single-token initialization, no userToken is locked. The attacker then directly transfers a large amount of userToken to the contract address, inflating pool.reserveUserToken without issuing proportional liquidity shares. On the next mint() call, the weighted liquidity formula uses the inflated reserveUserToken in the denominator but only the attacker's small new validatorToken deposit in the numerator, yielding disproportionate LP shares. The attacker burns these shares via burn() (Finding 4) to extract both tokens. The zero-amount burn griefing path (Finding 15) further enables the attacker to manipulate the totalSupply/reserve ratio before executing the drain, maximizing extraction. Combined severity is critical because each step reinforces the next.

The inverted fee formula in rebalanceSwap() (Finding 6) means users pay less than fair value for userToken. An attacker can amplify this by first calling executeFeeSwap with identical token addresses (Finding 5/25) to inject tokens into a self-referential pool, manipulating the reserve ratios. The attacker then calls rebalanceSwap on the manipulated pool to extract validatorToken at the discounted rate. Because reserveUserToken is artificially inflated by the identical-token swap, the pool has more apparent liquidity, and the inverted fee formula allows the attacker to drain it faster than the fee revenue can compensate.

An attacker holding minimal LP tokens (as few as 1 wei, obtainable via the single-token mint vulnerability in Finding 1) can repeatedly call burn() with liquidity=1. If pool.reserveUserToken or reserveValidatorToken is small relative to totalSupply, _calculateBurnAmounts() returns (0, 0) (Finding 15, Finding 24). The burn succeeds, decrementing totalSupply and liquidityBalances[attacker] by 1 each call, while reserves remain unchanged. This asymmetric decay is compounded by the mint() formula (Finding 13) which divides by totalSupply: once totalSupply approaches zero, any subsequent mint() call either reverts on division by zero or mints an astronomically large share, allowing the attacker to claim the entire reserve in one final burn.

All transfer() and transferFrom() calls lack return value checks (Finding 16). If a token's transfer fails silently (returns false instead of reverting), the pool's reserve counters are decremented as if the transfer succeeded. Combined with the fee formula asymmetry (Findings 2, 6, 7), an attacker can repeatedly trigger silent transfer failures during outbound transfers in executeFeeSwap(), accumulating reserve decrements without actual token outflows. The resulting reserve undercount makes the pool appear less liquid than it is, suppressing the prices computed by the mint() weighted formula and allowing subsequent LPs to mint shares cheaply. These cheaply-minted shares can then be burned to claim the real (underdecremented) token balance.

Step 1: Attacker calls mint() with 1 wei validatorToken to initialize a pool (exploiting the single-token init flaw). The pool has reserveUserToken=0 and tiny reserveValidatorToken. Step 2: Attacker directly transfers a large amount of userToken to the contract address, inflating the pool's effective userToken balance without updating reserveUserToken (the reserve only updates on mint/swap calls). Step 3: Attacker calls mint() again with minimal validatorToken; the weighted-denominator formula assigns disproportionately large liquidity shares because the reserve ratio is skewed. Step 4: Attacker calls burn() to extract both tokens, draining the pool. If other LPs have deposited in the interim, they lose everything. As an alternative attack vector, attacker calls burn(1) repeatedly to drain totalSupply toward zero without removing reserves, causing future mint() pricing to break catastrophically.

The inverted fee formula in rebalanceSwap() (Finding 6) means users pay less than fair value for every userToken received. Combined with the fee asymmetry between executeFeeSwap (0.3% fee) and rebalanceSwap (effectively a discount), an attacker can: (1) Call executeFeeSwap to convert 10,000 userToken into 9,970 validatorToken, paying 30 units as fee. (2) Call rebalanceSwap requesting 9,970 userToken output; the inverted formula computes amountIn = (9970 * 9985) / 10000 + 1 = 9,956 validatorToken. Attacker pays 9,956 and receives 9,970 userToken. (3) Net result after round trip: started with 10,000 userToken, now has 9,970 + 14 = net position showing 14 validatorToken profit. Repeated at scale, this drains all validatorToken reserves. The protocol's own fee structure enables the attack with no special privileges required.

executeFeeSwap and rebalanceSwap lack the userToken != validatorToken check present in mint/burn. An attacker calls executeFeeSwap(TOKEN_A, TOKEN_A, X): the contract takes X TOKEN_A from the caller, adds X to reserveUserToken, subtracts 0.997X from reserveValidatorToken, and sends 0.997X TOKEN_A back. Net: attacker spent 0.003X tokens, pool's reserveUserToken increased by X while reserveValidatorToken decreased by 0.997X. Repeating this skews the reserve ratio arbitrarily. Once the reserve ratio is sufficiently distorted, the attacker calls mint() with minimal validatorToken, receiving inflated liquidity shares due to the skewed denominator in the weighted formula. Finally, burn() drains the pool at the artificially inflated ratio, stealing from all honest LPs.

An attacker who holds any LP tokens calls burn(1) repeatedly. Each call burns 1 unit of liquidity and (due to rounding in _calculateBurnAmounts) returns 0 tokens to the attacker. The pool's totalSupply and the attacker's liquidityBalance both decrease by 1 each call. If the attacker has 10^6 LP tokens, they can reduce totalSupply by 10^6 with no token cost beyond gas. When totalSupply reaches 0 while reserves remain non-zero, subsequent mint() calls in the non-initial branch compute liquidity = (amountValidatorToken * 0) / denom = 0, then hit the require(liquidity != 0) check and revert. The pool becomes permanently bricked: burn() requires liquidity > 0 and liquidityBalance >= liquidity, but if the attacker drained all LP tokens, no one can burn. The reserves are permanently locked.

The contract does not use SafeERC20 and does not check return values from transfer/transferFrom. If a token's transfer() returns false (e.g., USDC with OFAC blacklisting, or a paused token), the reserve update still executes. For example, in executeFeeSwap: transferFrom(sender, contract, amountIn) fails silently -> pool.reserveUserToken += amountIn (pool believes it received tokens it did not). On the validatorToken transfer: IERC20(validatorToken).transfer(sender, amountOut) fails silently -> pool.reserveValidatorToken -= amountOut (pool believes it sent tokens it did not). The pool now tracks phantom reserves. Combined with the fee asymmetry, an attacker can exploit the phantom reserves by calling rebalanceSwap against the inflated userToken reserve, receiving real validatorToken while paying nothing. This causes direct fund loss for all honest LPs.

In Solidity 0.7.6 (which this contract uses), arithmetic does not have implicit overflow protection. In executeFeeSwap, amountOut is computed as (amountIn * M) / SCALE before _requireU128(amountIn) is called. If a user supplies amountIn close to type(uint256).max / M (approximately 1.16e73), the multiplication amountIn * M silently overflows uint256 and wraps to a small value. After division by SCALE, amountOut is tiny. The user's transferFrom succeeds for the huge amountIn, pool.reserveUserToken is incremented by the huge value (which also overflows uint128 unless _requireU128 catches it), and the user receives nearly nothing. The overflow check sequence is: compute amountOut (may overflow), then check _requireU128(amountIn) and _requireU128(amountOut). Since amountOut wraps to a small number, it passes the uint128 check, but the user already transferred a massive amount. Combined with the identical-token-address bug, an attacker can construct overflow scenarios that corrupt both reserves simultaneously.

The pool does not enforce a constant-product or any other invariant across swaps. executeFeeSwap and rebalanceSwap use flat fee percentages regardless of reserve ratios, meaning an attacker can push the reserve ratio arbitrarily far from equilibrium at the cost of the fee alone. After skewing reserves via repeated swaps, the attacker calls mint() with validatorToken; the weighted-denominator formula (N*reserveUserToken/SCALE + reserveValidatorToken) becomes heavily biased, minting far more or far fewer shares than fair value depending on which reserve was inflated. The attacker then burns to extract disproportionate reserves, net-extracting from honest LPs who cannot exit without loss.

An attacker exploits the zero-amount burn vulnerability (Finding 15) to systematically reduce totalSupply[poolId] to near-zero without withdrawing any reserves. Once totalSupply approaches zero, the attacker calls mint() with a small amountValidatorToken. With a near-zero totalSupply, the mint formula computes an astronomically large liquidity share for the attacker. The attacker then calls burn() with those shares, extracting essentially all remaining reserves. Combined with the inverted rebalanceSwap fee formula (Finding 6) that undercharges callers, the attacker can also pre-drain validator token reserves before executing the share collapse, maximizing the value stolen.

An attacker first exploits the missing userToken != validatorToken check in executeFeeSwap (Finding 5/25) to create a same-token pool entry with an inflated reserveUserToken. They then call the one-sided mint() (Finding 1) with the validatorToken corresponding to the inflated userToken pool, triggering the weighted denominator formula that misprices liquidity shares because reserveUserToken is now corrupted. The attacker receives outsized liquidity shares relative to their deposit, then burns to extract both tokens from the pool, draining honest LPs.

The inverted rebalanceSwap formula (Finding 6) charges users less than fair value on every call. Combined with the executeFeeSwap fee direction mismatch (Finding 7) and the division rounding that systematically favors callers (Findings 4, 11, 12), a sophisticated attacker can construct a cyclic call sequence: executeFeeSwap followed by rebalanceSwap. Each cycle extracts a small net positive value due to the fee rate mismatch (0.3% vs 0.15%) and the inverted formula in rebalanceSwap. Repeated with flash-loan-scale capital, this drains pool reserves continuously without any capital at risk.

The missing ERC20 return value check (Finding 16) allows a transfer-out to silently fail while reserve accounting proceeds as normal. If the validatorToken is a token that returns false on transfer (rather than reverting), executeFeeSwap decrements pool.reserveValidatorToken without the corresponding tokens actually leaving the contract. An attacker can pair this with the zero-burn vulnerability (Finding 15): after the reserve accounting is corrupted, burning LP shares against the now-incorrect reserve values allows the attacker to withdraw more tokens than their actual proportional share, draining honest LP funds.