Submission Details
Severity:
Hard-coded Exchange Rate in StabilityPool
Summary:
In StabilityPool.sol, getExchangeRate() returns a constant 1e18, ignoring actual pool conditions.
Vulnerability Details:
function getExchangeRate() public view returns (uint256) {
return 1e18;
}
This bypasses any real ratio of rToken to deToken, potentially misleading depositors.
Impact:
If the protocol intended a floating exchange rate, users will face inaccurate redemptions. If 1:1 is truly intended, this is not a bug, but it must be clearly documented.
Tools Used:
Manual inspection of
StabilityPooldeposit/withdraw logic
Recommendations:
If it should be dynamic, replace with a function computing
(rTokenBalance / totalDeTokenSupply).If truly 1:1, confirm that design is stable and documented.
Updates
Lead Judging Commences
inallhonesty 6 months ago
Submission Judgement Published Assigned finding tags:
StabilityPool::getExchangeRate hardcodes 1:1 ratio instead of calculating real rate, enabling unlimited deToken minting against limited reserves
inallhonesty 6 months ago
Submission Judgement Published Assigned finding tags:
StabilityPool::getExchangeRate hardcodes 1:1 ratio instead of calculating real rate, enabling unlimited deToken minting against limited reserves
Prize pool breakdown
Total prize
77,280 USDC
nSLOC
3,86420
USDC / LOC
74,000
3,280
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.