hats-finance / Common--Stableswap-0xd4d9a2772202ce33b24901d3fc94e95a84b37430

Apache License 2.0
0 stars 0 forks source link

oracle retrieves token price from issued chain #33

Open hats-bug-reporter[bot] opened 1 month ago

hats-bug-reporter[bot] commented 1 month ago

Github username: -- Twitter username: -- Submission hash (on-chain): 0x1b039b1a53537f96b520b44285a2facc9cf750b63e939d4dec658f6a2dfb6b04 Severity: high

Description:

Description

The protocol is planning on deploying on the Aleph Zero chain. The Aleph Zero chain retrieves their prices from Kintsu, which simply put, is a protocol that allows for LST, they fetch their prices from an oracle project called Switchboard, as per their announcement.

Switchboard is a protocol that retrieves price oracles, with token oracle prices based on the chain where the token was issued, similar to DefiLlama.

Example:

This however can lead to a huge problem in cases of depegging occurring. This could happen for many reasons, For example, if there's an exploit in the bridging mechanism that permits the minting of uncollateralized tokens on Solana, the value on the main chain would remain unchanged, while the value on Solana would plummet towards zero. Consequently, the tokens on Solana would still be valued based on the price on the main chain, resulting in an incorrect price reflection.

Example:

This will lead to countless issues, Users are now able to exploit the depegged token and trade it against other tokens to net profit, on the other hand, the honest users will trade Token B -> Token A and will receive Token A based on the pricing of the main chain, which is totally incorrect.

These are the most recent bridge hacks we found, these happen quite frequently and are due to the issue of depegging:

X Bridge Hack - 4/2024
Orbit Bridge hack - 12/2023
Heco Bridge Hack - 11/2023

Recommendation

Use an alternative Oracle for tokens that are bridged, to make sure they retrieve their price oracles from the chain itself and not from the main chain. Chainlink has a good alternative, otherwise some logic has to be found to handle this.

whoismxuse commented 1 month ago

To add on to this, it is especially problematic for shareholders. If shareholders want to cash out their shares for their respective tokens, they can call remove_liquidity_by_amounts. However, inside this function, the shares_to_burn are calculated by retrieving the rate, which is retrieved from the price oracle. The issue is that this price oracle will still point to the $1 price.

            self.update_rates();
->            let rates = self.get_scaled_rates(&self.pool.token_rates)?;

            // calc comparable amounts
            let (shares_to_burn, fee_part) = math::rated_compute_lp_amount_for_withdraw(
->                &rates,
                &amounts,
                &self.reserves(),
                self.psp22.total_supply(),
                Some(&self.pool.fees),
                self.amp_coef(),
            )?;

This means that anyone who is a shareholder up until the point of a depeg will experience a tremendous amount of loss.

With this addition, I think it should indeed be a HIGH since shareholders will suffer a huge loss.

JanKuczma commented 1 month ago

External contracts malfunctioning/not working as intended is out of scope as stated in the scope section in the audit description.

Also, here is some more clarification.

StablePool smart contract is meant for stable tokens, pegged to some common value (e.g. fiat currency) or pegged to each other (e.g. baseToken x liquidStakingBaseToken).

The RateProvider (Rate Oracle) is used for the latter type of tokens, which allows adjusting the exchange rate according to the exchange ratio offered by the protocol that stands behind the rated token. The RateProviders are NOT price oracles that provide prices of some token in terms of some other unrelated token.