getExchangeRate()
function returns a fixed 1e18
instead of calculating the actual rate based on pool balances. This allows users to mint deToken
at a 1:1 ratio regardless of reserves, leading to potential insolvency.
StabilityPool's getExchangeRate()
hardcodes a 1:1 exchange rate between rToken
and deToken
, completely bypassing the critical pool balance dynamics that should determine the true exchange rate.
See this initial State
StabilityPool has 1000 rTokens
in reserves
2000 deTokens
already minted
True exchange rate should be 0.5
Exploitation Steps
Pool now has 1100 rToken
backing 2100 deToken
Exchange rate remains artificially fixed at 1:1
System becomes increasingly undercollateralized
The code ignores basic economic principles by hardcoding the exchange rate instead of calculating it based on pool reserves.
Similar to Iron Finance's TITAN collapse where fixed price assumptions led to a death spiral. Both cases show how hardcoded exchange rates can break protocol economics and lead to systemic failure.
Unlimited deTokens
minted against limited rToken
reserves. Maximum loss = Total Value Locked (TVL) in StabilityPool
The Terra/UST collapse demonstrated how fixed price mechanisms can lead to catastrophic failure. When Luna's price dropped, UST's algorithmic 1:1 peg became unsustainable, leading to a $40B loss. This mirrors how StabilityPool's fixed 1:1 rate ignores market reality and creates similar systemic risks.
vs
Implement the commented-out logic to compute the exchange rate dynamically
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.