# Vulnerable Pool initial rate.

Pool address is deterministic, so an attacker can pre-send tokens to it before createPoolADD, skewing the initial rate and minting synths at a huge discount.

- Payout: Audit contest
- Severity: medium
- Program: Spartan Protocol
- Found by: jonah1005
- Disclosed: 2021-09-16
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-07-spartan-findings/issues/23
- Library page: https://bugbountylibrary.com/r/c4%3A2021-07-spartan%3AM-13
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:race-window technique:recon vuln:business-logic vuln:oracle-manipulation

**Target:** poolFactory.createPoolADD / Pool initialization
**Root cause:** Pool address is precomputable and createPoolADD derives the initial token rate from whatever balances already sit at that address, so anyone can seed it beforehand.
**Steps:**
1. Precompute the deterministic Pool address for the intended base/token pair.
2. Front-run the deployer's createPoolADD by transferring tokens (e.g. 2700 BNB) directly to that address.
3. Deployer's createPoolADD executes and the pool initializes at the skewed ratio (iBNB ~10x cheaper).
4. Attacker mints the synth at the cheap rate before price normalizes, capturing arbitrage.
**How found:** Noticed the pool address is deterministic and that createPoolADD computes initial rate from existing balances, implying a front-run window before creation.
**Exploitation:** Attacker sends tokens to the precomputed pool address before pool creation, forcing an extreme initial price; then mints synths cheaply and arbitrages against the corrected rate.
**Insight:** When a contract address is deterministic and initialization reads live balances, check whether an attacker can pre-fund or pre-touch that address before the create/init transaction lands.