# Domain pricing relies on pool price, which can be manipulated

Initia usernames module prices domains from Dex pool spot reserves, letting an attacker manipulate the pool to underpay or force others to overpay.

- Payout: Contest reward
- Severity: high
- Program: Initia
- Credited: 0xluk3
- Disclosed: 2025-04-10
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2025-01-initia-move#h-01
- Library page: https://bugbountylibrary.com/r/c4%3A2025-01-initia-move%3AH-01
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm technique:source-review vuln:business-logic vuln:oracle-manipulation

**Target:** Move usernames module get_cost_amount / Dex get_spot_price
**Root cause:** Domain cost is derived directly from Dex pool reserve ratio (spot price) rather than a manipulation-resistant oracle or TWAP.
**Steps:**
1. Call usernames get_cost_amount, which invokes dex::get_spot_price on the INIT pair.
2. Observe get_spot_price computes base_weight*quote_pool / quote_weight*base_pool from live reserves.
3. Skew pool reserves via flash loan or large deposit to move spot price.
4. Register/extend domain at manipulated low price, or let other users overpay.
**How found:** Code review of get_cost_amount traced the price to dex::get_spot_price and recognized reserve-based spot pricing as a known manipulable pattern.
**Exploitation:** Attacker flash-loans or deposits into the Dex pool to skew reserves, then registers or extends a domain at the depressed spot price, or leaves the pool skewed so other users overpay.
**Insight:** When a pricing function calls a Dex spot-price view, check whether it reads raw reserves; even with flash-loan locks, direct deposits or alternate pools can still skew it.
