Lack of functions to update the external rate provider if any of the rate provider malfunction or compromised or throws error

[hats-bug-reporter[bot]]

Github username: -- Twitter username: -- Submission hash (on-chain): 0xadf024db5ea5e2b065d99a26559a9e879fc9383579833515b7fd9324c0c73ea6 Severity: medium

Description: Description

wheneven the pool is created, the list of rate provider is set. This will be used to Get rate of a particular token with respect to a given base token. The rate rovider plays a important role during the swap, add liquidity and remove liquidity. when we the pool, there are different functions exisits such as fee setter , admin update and so. We found that there were not fucntion to update the rate provider.

stable_pool/lib.rs#L142-L143

        /// Means of getting token rates, either constant or external contract call.
        token_rates: Vec<TokenRate>,

_swap_exact_in , _swap_exact_out, add_liquidity , remove_liquidity_by_amounts - during these operation the rate is updated by calling the update_rates() function he pool contains a token with rate oracle, this function makes which will fetch the rate by making the external call.

The above function relies on the external control to fetch the rates.

These conracts are configures only when the pool is created. After that there are not function exisits to update if any of the rate provider malfunctions or revert.

If they revert, these pool operations wold stuck without further process.

Attack Scenario

Pool operations would stuck.

Attachments

2. Revised Code File (Optional)

It would be better to have a admin controlled function for each pool which makes the external call to fecth the rate. this will be used to update the rate provider contract.

[aktech297]

sorry for spell mistakes.. will correct.. was writing fast..

[JanKuczma]

Thank you for your submission.

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

In case any of the rate providers reverts when calling RateProvider::gate_rate(), the funds are safe as they can be withdrawn using remove_by_share(...) method which does not use rates in calculations.

[aktech297]

Thank you for your submission.

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

In case any of the rate providers reverts when calling RateProvider::gate_rate(), the funds are safe as they can be withdrawn using remove_by_share(...) method which does not use rates in calculations.

Hi, I think, user unexpectedly affected. they can not use the updated rate to withdraw their funds.

Please look our suggestion, it is simple to recommend and solve this issue. May be this could be low severity. let us know if it is fine.

[JanKuczma]

Thank you for the suggestion. The contract was implemented so that in the case of the RateProvider not responding, the liquidity can safely withdrawn with the remove_liquidity_by_shares method. RateProvider is as important as the token addresses in the pool, and it should not be changed after the deployment.

[aktech297]

After reviewing this issue, the issue #27 is duplicate of this one. The #27 talks about the stale price. The current issue (#20) mention about the malfunction of rate provider. which is also part of stale price return from the rate provider.

Refer the current issue title - Lack of functions to update the external rate provider if any of the rate provider malfunction or compromised or throws error

further when we look at these two issues, both are talking about the external contract malfunction which is stated by the sponsor in the comments.

Though both these issues are external contract malfunction, we not sure why one issue is accepted and other one is rejected.

It would be fair to treat both of these issue equally.

If we see the current issue, user can not use the rate provider price value to withdraw or swap or other actions due to its malfunction. As per severity classification mentioned in the contest page, this issue falls at least in the the low category. Issues where the behavior of the contracts differs from the intended behavior (as described in the docs and by common sense), but no funds are at risk.

[whoismxuse]

@aktech297 issue #27 is not a duplicate of this issue.

Honestly, I don't even need to comment here, but I will for the sake of clarity. At this point, you are just spamming nonsensical remarks under several issues that have already been resolved. Nowhere in your findings do you mention anything remotely related to issue #27. Furthermore, it's puzzling that you attempt to disprove valid findings and, when they remain valid, you shift tactics by trying to link unrelated issues to yours, even though they bear no resemblance whatsoever.