# It's possible to create pairs that cannot be taken over

Unvalidated initial pair parameters let an attacker create a Goat Trading pair whose takeOverPool() always reverts on overflow, permanently locking it.

- Payout: Contest reward
- Severity: medium
- Program: Goat Trading
- Credited: y4y
- Disclosed: 2024-03-10
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-03-goat-trading-judging/issues/69
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-03-goat-trading%3AM-5
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** GoatV1Factory.createPair / GoatV1Pair.takeOverPool
**Root cause:** createPair() never validates initial parameters (virtualEth, bootstrapEth, initialEth, initialTokenMatch); extreme values cause overflow in _tokenAmountsForLiquidityBootstrap's k*bootstrapEth multiplication during takeOverPool().
**Steps:**
1. Call `createPair()` with `virtualEth = type(uint112).max`, `bootstrapEth = type(uint112).max`, `initialEth = type(uint112).max`, `initialTokenMatch = type(uint112).max`
2. Any later `takeOverPool()` call reaches `_tokenAmountsForLiquidityBootstrap`
3. `tokenAmtForAmm = (virtualEth * initialTokenMatch * bootstrapEth) / (totalEth * totalEth)` computes 2^336, reverting on overflow
4. Pair can never be taken over, permanently DOSed
**How found:** Code review of createPair() noting initial parameters are unvalidated, then tracing takeOverPool() into _tokenAmountsForLiquidityBootstrap and spotting the unchecked multiplication of three uint112 values.
**Exploitation:** Attacker creates a pair with max-value initial parameters; the overflow in the takeover math makes takeOverPool() revert for all callers, bricking the pair.
**Insight:** When a factory accepts user-supplied numeric config that later feeds multiplications, check whether the product of max values of each type exceeds the result type width — uint112*uint112*uint112 overflows uint256.
