Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dutchTradeDisabled[erc20] gives governance an incentive to disable RSR auctions #20

Open
code423n4 opened this issue Aug 18, 2023 · 6 comments
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working MR-M-02 satisfactory satisfies C4 submission criteria; eligible for awards selected for report This submission will be included/highlighted in the audit report sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/reserve-protocol/protocol/blob/3.0.0-rc5/contracts/p1/Broker.sol#L213-L216

Vulnerability details

The mitigation adds different disable flags for GnosisTrade and DutchTrade. It can disable dutch trades by specific collateral. But it has serious problem with overall economic model design.

The traders Broker contract are under control of the governance. The governance proposals are voted by stRSR stakers. And if the RToken is undercollateralized, the staking RSR will be sold for collaterals. In order to prevent this from happening, the governance(stakers) have every incentive to block the rsr auction. Although governance also can set disable flag for trade broker in the previous version of mitigation, there is a difference made it impossible to do so in previous versions.

In the pre version, there is only one disable flag that disables any trades for any token. So if the governance votes for disable trades, the RToken users will find that they can't derive any gain from RToken. So no one would try to issue RToken by their collateral. It is also unacceptable for governance.

But after the mitigation, the governance can decide only disable the DutchTrade for RSR. And they can initiate a proposal about enable RSR trade -> open openTrade -> re-disable RSR trade to ensure their own gains. And most importantly, this behavior seems to do no harm to RToken holders just on the face of it, and it therefore does not threaten RToken issuance.

So in order to prevent the undercollateralized case, dutchTradeDisabled[erc20] gives governance every incentive to disable RSR auctions.

Impact

When RToken is undercollateralized, disabling RSR trade will force users into redeeming from RToken baskets. It will lead to even greater depeg, and the RToken users will bear all the losses, but the RSR stakers can emerge unscathed.

Proof of Concept

StRSR stakers can initiate such a proposal to prevent staking RSR auctions:

  1. Call Broker.setBatchTradeDisabled(bool disabled) to disable any GnosisTrade.

  2. And call setDutchTradeDisabled(RSR_address, true) to disable RSR DutchTrade.

Tools Used

Manual review

Recommended Mitigation Steps

The dutchTradeDisabled flag of RSR should not be set to true directly by governance in the Broker.setDutchTradeDisabled function. Add a check like that:

require(!(disabled && rsrTrader.tokenToBuy()==erc20),"xxxxxxx");

Assessed type

Context

@code423n4 code423n4 added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working MR-M-02 labels Aug 18, 2023
code423n4 added a commit that referenced this issue Aug 18, 2023
@c4-sponsor
Copy link

tbrent marked the issue as sponsor confirmed

@c4-sponsor c4-sponsor added the sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") label Aug 24, 2023
@tbrent
Copy link

tbrent commented Aug 24, 2023

Anticipating restricting governance to only be able to enable batch trade, or dutch trade.

@tbrent
Copy link

tbrent commented Aug 24, 2023

^ accidentally mentioned the wrong issue; please ignore

@c4-judge c4-judge added the satisfactory satisfies C4 submission criteria; eligible for awards label Aug 28, 2023
@c4-judge
Copy link

0xean marked the issue as satisfactory

@liveactionllama
Copy link

Per discussion with the judge @0xean, this is a new/unique finding. Adding the selected for report label for awarding and reporting purposes.

@liveactionllama liveactionllama added the selected for report This submission will be included/highlighted in the audit report label Sep 6, 2023
@pmckelvy1
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working MR-M-02 satisfactory satisfies C4 submission criteria; eligible for awards selected for report This submission will be included/highlighted in the audit report sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Projects
None yet
Development

No branches or pull requests

6 participants