Closed sherlock-admin2 closed 7 months ago
1 comment(s) were left on this issue during the judging contest.
auditsea commented:
The issue describes about not checking min/max value from Chainlink for data staleness, but this is not required
Invalid, minPrice/maxPrice has been deprecated. In fact there is a minimum check here for the stabel coin collateral where as long as price is greater than zero here, it is an acceptable range. If depegging happens, it must have meant market factors are in place to reflect accurate prices.
Escalate I think this should be a duplicate of #17 as it also described the depeg event. If you look at issues #19 and #182, which are duplicates of the before-mentioned issue, you can see that they describe the same issue I described.
In the case of a depeg the Ubiquity Dollar could be uncollateralized as there is no collateral left to back it up.
Escalate I think this should be a duplicate of #17 as it also described the depeg event. If you look at issues #19 and #182, which are duplicates of the before-mentioned issue, you can see that they describe the same issue I described.
In the case of a depeg the Ubiquity Dollar could be uncollateralized as there is no collateral left to back it up.
You've created a valid escalation!
To remove the escalation from consideration: Delete your comment.
You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.
@evmboi32 agree i need to relook all duplicates of this issues to ensure the correct impact are described and not generic min/max. But the severity and validity of #17 is TBC
@evmboi32 I believe all the above issues mentioned above are duplicates of #17 albeit they are pointing to more serious and complete depegs.
Based on other comments revolving around this: https://github.com/sherlock-audit/2023-12-ubiquity-judging/issues/72#issuecomment-1914433231
From my understanding, the system experiences a profit, not a loss, on a cycle of mints and redeems.
If that's not contested, this submission is invalid.
Result: Invalid Has duplicates
evmboi32
medium
Oracle price boundaries not checked
Summary
Users cannot burn their dollar tokens for collateral if collateral depegs or oracle reports an incorrect price.
This happened just last month when the chainlink reported an incorrect price https://twitter.com/spreekaway/status/1733358874269249578
USDC
depegged to~$0.83
last yearUSDT
depegged a few timesDAI
also fell during theUSDC
depegLUSD
is generally quite volatileThe depegging of the stable coin is rare but it happens. But when it does it can cause unforeseen consequences.
Vulnerability Detail
When updating the oracle price for collateral it is not checked if the price is within expected bounds
Since the collateral should be
DAI
orLUSD
from the beginning i don't think it is safe to assume that the price should be~$1
at all times. If a de-peg happens the price could fall sharply or if the oracle reports an incorrect price.Let's look at the following scenario:
LUSD
is the collateral and its current price is$1
User1
mints dollar callingmintDollar()
and mints1000 dollar
tokens.User2
mints dollar callingmintDollar()
and mints1000 dollar
tokens.LUSD
depegs to$0.5
User2
decides to redeem his dollars to collateral (maybe unaware of the fall in price or he speculates that the token will repeg) calling theredeemDollar()
with1000
dollar tokens1000 / 0.5 = 2000 LUSD
, which is the whole collateral on the contract.0.99
but users are unable to burn tokens to raise the price as there is no collateral to redeem.Coded POC
Add this file to the
./packages/contracts/test/diamond/facets/Depeg.t.sol
folderAnd run with
forge test --match-path ./test/diamond/facets/Depeg.t.sol -vv v --fork-url RPC_URL
Impact
Users can be left unable to burn their tokens for collateral as there would soon be no collateral left. The process of burning collateral is meant to raise the price of the dollar token. But if the tokens cannot be burned then the price cannot go back up.
Code Snippet
https://github.com/sherlock-audit/2023-12-ubiquity/blob/main/ubiquity-dollar/packages/contracts/src/dollar/libraries/LibUbiquityPool.sol#L523-L562
https://github.com/sherlock-audit/2023-12-ubiquity/blob/main/ubiquity-dollar/packages/contracts/src/dollar/libraries/LibUbiquityPool.sol#L284-L294
Tool used
Manual Review
Recommendation
Don't allow mints or redemptions if the price falls out of range. Add the
minPrice
andmaxPrice
to the pool storage for each collateral and then do the checks. This could be set for exampleminPrice = 0.99
andmaxPrice = 1.01
. If you plan to support assets such asWBTC/USD
it is a good idea to check theWBTC/BTC
feed to make sure that it is still pegged to theBTC
.