Decentralization of the Reserve Protocol Guardian

Introduction

We will outline a way to decentralize the Guardian role for Reserve rToken DAOs. Unfortunately our research points out that there is no simple, singular way to allow for robust decentralized substitution of this role. We will show, however, that combining two methods can make the cost of attacks extremely high, and, as we think, prohibitive..

Status quo

The Reserve Protocol currently recommends a modified version of OpenZeppelin’s industry-standard smart contract called Governor Alexios. This report concerns itself with three roles defined in Governor Alexios, the Pauser, Freezer and Guardian roles, which can shift the governance system into defined, non-normal states.

Trading or issuance can be suspended, or the system can be frozen, either for a short or a longer duration via the freezeShort() and freezeLong() functions. The table below from the Reserve documentation details the differences between the states.

Action	Trading Paused	Issuance Paused	Frozen
Issue RToken	Enabled	Disabled	Disabled
Redeem RToken	Enabled	Enabled	Disabled
Staking RSR	Enabled	Enabled	Enabled
Unstaking RSR	Disabled	Disabled	Disabled
Cancel Unstake RSR	Enabled	Disabled	Disabled
Withdraw RSR	Disabled	Disabled	Disabled
RSR Rewards Payout	Enabled	Enabled	Enabled
Trading	Disabled	Enabled	Disabled
RToken Melting	Enabled	Enabled	Enabled

As the name implies, freezing is the most severe limitation of the system, allowing nothing but staking more RSR and rToken Melting while still paying out RSR staking rewards. In essence, the rToken can only be overcollateralized further while still paying out the corresponding incentives.

The Guardian role can be set to any Ethereum address and invoke any of the limited states. It is designed as a security mechanism that can halt the system before malicious or damaging proposals can execute, protecting collateral and rescuing the rToken from a governance attack.

Without further ado we propose two mechanisms that can be combined to replace a Guardian multisig.

Emergency Freeze Module

Taking a page out of MakerDAO’s “orderly self-destruct” Emergency Shutdown Module, the Freeze Module would be triggered if more than a set threshold of RSR are staked inside it. The governance system would stop everything but redeeming rTokens, plus staking more RSR to secure the DAO for a set duration of blocks. Successful proposals that in the execution queue would be abandoned. Removing stRSR from the module would not be possible for the duration of the initial freeze.

We recommend a minimum of one month for the initial freeze, so that stRSR holders could work through the challenges that allowed the attack. The delay would also introduce a very high opportunity cost for potential attacks.

Once the initial freeze period passes stRSR can be unstaked from the module, and only if the total deposited stRSR falls below the set threshold would governance resume. The system can also be enhanced by introducing a multiplier so that prolonging the veto state only happens if additional stRSR are staked in the veto escrow, and even if no further stRSR is deposited into the Freeze module.

Setting the veto length parameter

The intent of the Freeze Module is to allow a minority of stRSR holders to thwart a governance attack by three means:

Attackers know that even if they manage to get their malicious proposal through regular governance it would likely not be executed, because a watchful minority could trigger the Freeze Module.
Since stRSR can not be unstaked for the duration of the initial freeze, an attacker’s capital used to buy RSR to defeat a veto would be illiquid for that period, introducing an opportunity cost that depends on factors outside their control, such as RSR price volatility.
All proposals in the execution queue get abandoned, meaning that an attacker would have to start from square one, while defenders could muster more RSR to defeat the attack during the IP stage.

Given the current default governance timelines an attacker is looking at:

Three day RFC phase (may be skipped)
Two day review period
Three day voting period
Three day execution timelock

For a total minimum of eight days delay, if the attack skips the RFC phase. We have seen that successful governance attacks sometimes do not skip the RFC phase, but pretend their proposal is something that it is not, while obfuscating the damaging payload in the code. See this description of the $180m Beanstalk protocol hack for a play by play breakdown of how this can work.

The Freeze Module adds a substantial amount of friction and delay on top of this timeline. We recommend a minimum of one month as a starting place, because it would quadruple the delay for the attacker at the very least, and give defenders considerable time to respond.

Setting the threshold parameter

The ideal threshold is one where a minority of a rToken DAO’s stRSR is sufficient to prevent an attack, but the still high enough so that it deters “hooligans” from wreaking havoc by freezing an rTokens governance “just for the lulz”.

A threshold that works for a nascent rToken would not work for a well-established DAO with nine or ten figure TVL and vice versa.

Idefix and Obelix two (hypothetical) rToken DAOs

Let’s look at two rToken DAOs Idefix and Obelix.

Idefix is a rToken DAO with 100,000 USD worth of TVL and 50,000 USD worth of stRSR
Obelix has 5,000,000,000 USD worth of TVL and 250m worth of stRSR

Let’s further assume that both have their quorum set at 4% meaning that it takes at least 2k USD worth of stRSR to pass a proposal on Idefix and 10m worth for Obelix.

Furthermore the stRSR of Idefix is mostly from the deployer and one or two of their peers. In this case triggering the emergency freeze should need at least ten times quorum (or just 20k USD worth of stRSR). It is imperative that a nascent rToken DAO remains flexible and has a fast-paced governance. For them a malicious triggering is painful, and the potential gain for a governance attack is low.

But ten times quorum would be 100m worth of stRSR for Obelix! MakerDAO’s ESM currently costs about 450m worth of MKR to trigger, so it is not outlandish to have a threshold that high. MakerDAO can not recover once the ESM is triggered, though, but the proposed Freeze Module can resolve peacefully. We propose setting the threshold for a DAO of Obelix size at two times quorum. Still high enough to make a spam attack very costly, but within reach of dedicated stewards of the DAO.

Optional: Setting a multiplier to extend a veto

A multiplier should make it harder to freeze a rTokenDAO forever by a malicious extension of the veto. Further RSR has to be deposited into the module, which becomes inaccessible for as long as the total amount deposited is higher than threshold times multiplier.

The multiplier can be smaller than 1, 1, between 1 and 2, or bigger than 2. Here is how this plays out:

Multiplier < 1: The threshold for extending the veto is even lower than the initial threshold. If no stRSR get withdrawn then the freeze automatically gets extended. This ensures the DAO is safe even if no additional RSR is staked, but makes it impossible to recover from a malicious triggering of the Freeze Module.
Multiplier = 1: Exhibits many of the same dynamics as a multiplier that is smaller than 1. But in this scenario withdrawing a smaller portion of the stRSR in the Freeze Module would break the Freeze. This seems to be the worst of both worlds and can not be recommended.
Multiplier between 1 and 2: Extending the veto means additional stRSR has to be locked up in the escrow. A multiplier between 1 and 2 means that the additional stRSR required is relatively small, compared to higher multipliers. We believe this is the right parameter choice because defenders can choose to buy themselves more time, but have to actively opt-in to do so. Further research is needed to discern the right choice here. Smaller rToken DAOs will use higher values than well-established ones.
Multiplier > 2: This makes extending the veto hard, as at least the same amount of additional stRSR is required as it was to trigger the Freeze in the first place. We think that multipliers this high only make sense for relatively small DAOs who want to make sure governance resumes at the first possibility, except in rare circumstances.

Below is a diagram of the Freeze Module’s mechanics:

Veto Module – Dual Token Governance

It could be argued that RSR governance of rTokens contains a principal-agent dilemma. RSR tokens are used for overcollateralizing rTokens, and RSR stakers can join multiple rToken DAOs. This could lead to a situation where the loss of one rToken might have much less impact on a RSR staker than on a rToken holder. The RSR staker would only lose a portion of their funds, while the rToken holder would lose everything (or substantially more).

We propose to implement a Veto Module triggered by depositing rTokens into a veto escrow contract. Once a sufficient threshold of rTokens is reached, the governance system enters a veto state, where the proposal vetoed is barred from execution for an additional veto timelock.More rTokens can be deposited into the veto escrow to strengthen the veto, but also into an anti-veto escrow, voting against the veto with rTokens.

After the veto timelock a proposal:

Gets abandoned if there are more rTokens in the veto escrow than in the anti-veto escrow.
Gets abandoned in case of equal amounts in both escrows.
Gets executed in case of more rTokens in the anti-veto escrow than the veto-escrow.

Token holders can remove their rTokens from both escrows whenever they want, but are faced with a small cooldown delay. We propose a two day default period for this parameter, to give deposits some weight and dampen the volatility of the escrows.

In addition governance could set a multiplier for pro-veto rTokens deposited so that overcoming a veto needs multiplier x tokens in veto escrow rTokens. A veto’s downside is slowing governance down, but the downside of a malicious proposal is a full-fledged governance attack with a complete drain of the collateral pool. rToken DAO governance could decide it is sensible to have an asymmetry in counting votes for or against a veto. We recommend setting the multiplier to 1 as a default and flag this for further research.

Should the initial veto be overcome after the 14 day veto timelock, a vetoed proposal should have a “rage quit” execution time lock during which rToken holders can withdraw their collateral. This allows rToken holders to walk away unscathed in the event that they do not agree with a governance decision by RSR holders. We suggest a default of seven days, which is more than double the default three day execution time lock of non-veto RSR governance and should give rToken holders who want out enough time to untangle DeFi positions and redeem.

Vetoes also perform an important social function by alerting rToken holders about controversial or malicious proposals and should rally a considerable amount of rTokens that participate in the veto.

Using rTokens instead of RSR to trigger a veto means that a potential attacker would have to buy or borrow as many rTokens as needed to overcome anti-veto opposition. This increases the cost of the attack considerably. It also reduces the principal-agent tension between RSR stakers and rToken holders further by giving rToken holders direct influence over governance decisions (if only in the negative).

A summary of the actions happening as soon as a proposal is opposed with enough rTokens in the escrow contract to put the governance system in veto state:

The execution time lock of the whole system increases to at least 14 days. 14 days is what MakerDAO uses for high-impact proposals and has been sufficient so far.
The vetoed proposal is blocked from execution for 14 days
Emergency Whitelist actions can still be performed
After the veto timelock there is a further seven days execution timelock where rToken holders can redeem and “rage quit”.
The proposal is abandoned if the rTokens in the veto escrow > anti-veto escrow after 14 days.

Here is a diagram of the proposed governance flow including the veto module.

The diagram below represents the perspective of a rToken holder who doesn’t want a proposal to pass:

Their worst case scenario for a rToken holder is redeeming all collateral (and of course the gas cost) in case a proposal they disagree with passes all stages of the governance process.

Other proposals that are accepted by RSR token holders via governance votes can still be executed, though. We propose to extend the time lock for all proposals in case a veto is active to increase the friction of certain kinds of attacks, which we will detail later. An emergency whitelist of actions that can be performed without a timelock would further enhance the proposed security scheme.

To understand the possible vectors of attack we suggest a systematic approach, There are four main ways for proposals to interact with the veto module.

We will address each of the scenarios in order.

Benevolent Proposal / Benevolent Veto

This is the simplest case. An orderly proposal passes and does not get vetoed, leading to an execution after the regular time lock expires. We expect rToken DAOs to be in this scenario and state for the vast majority of time. Every other scenario constitutes an attack of sorts.

Benevolent Proposal / Malicious Veto

In this case an attacker uses rTokens to trigger a veto, so that a benevolent proposal does not execute, even though it would be in the interest of the majority of RSR holders. This could be a disgruntled DAO wanting to stop a collateral basket change removing their product from a major rToken, for instance.

Without an anti-spam mechanism, this kind of attack is almost free. While the same proposal could be resubmitted, an attacker with sufficient rTokens can stall governance for a long time, hampering important basket changes or other timely governance decisions.

We propose an anti-spam cost for submitting a veto that gets overturned that is:

at least 1000 USD worth of rTokens or 1% of the rToken supply, whichever is lower, or
At the most 100,000 USD or 0.001% of the rToken supply, whichever is lower.

Malicious Proposal / Benevolent Veto

In this scenario an attacker tries to pass a malicious proposal by buying or lending enough RSR to overcome opposition in the on-chain polls. rToken holders who become aware of the proposal’s true intentions can now trigger a veto during the execution time lock by transferring rTokens into the veto escrow until the threshold is triggered. Not all rTokens have to come from one address, so rToken holders can pool resources.

Once the veto threshold is reached, the malicious proposal is barred from execution for the veto timelock. The attacker would now have to buy more rTokens then are in the veto escrow to overcome the veto. But rToken holders can further increase the amount needed by depositing more rTokens into the veto escrow.

A further potential attack could be to keep submitting the same malicious proposal over and over again until rToken holders run out of tokens to deposit in the veto escrow. Given the longer execution time lock for all new proposals as soon as the system is in veto state, this would take long and give rToken governance room to defend themselves by purchasing and staking more RSR to increase the chance of blocking these proposals during the IP stage.

Another potential attack can be performed with sheer size. Given an attacker with sufficient resources, rTokens could be minted by depositing further and further collateral until the defenders run out of funds. The newly minted rTokens would be deposited into the anti-veto escrow to ensure successful execution of the malicious proposal (say a complete drain of all collateral). This attack could still be economically profitable as long as the total value exploited is higher than the cost.

In the case of the malicious proposal containing a complete drain of collateral, this attack is always profitable since both veto and anti-veto rTokens’ collateral would get drained if the attack is successful. It is only limited by gas cost of minting and the availability of the collateral.

The veto mechanism does not have a way to defend itself against these attacks. The best way to prevent attacks like that would be to have a further fallback option like the Maker ESM module, where RSR stakers could invoke a complete shutdown of the rToken, where all rToken minters would get their collateral back. We proposed the implementation of an Emergency Freeze Module above, which would pair well with the Veto Module.

A further limitation for this kind of attack would be the possibility of rToken holders to “rage quit” and leave during the final execution time lock before a vetoed proposal executes after a veto. This feature also reduces the profit from an attack, because all rToken holders who are aware of the attack would get their collateral to safety.

Malicious Proposal / Malicious Veto

This final case is, in our view, more of a theoretical possibility. An attacker would submit a malicious proposal, buy or lend enough RSR to beat opposition in an on-chain poll and at the same time pretend to rescue the DAO with a weak veto that they are confident they can overcome at the last minute.

This attack has a social component, since the attacker would need to convince other rToken holders that they got it covered and that they’re willing to do what it takes to prevent the attack, knowing that they have no intention of doing so.

The attack relies on the laziness and willingness of rToken holders to believe the attacker’s intentions and to be satisfied with a weak veto.

It can be mitigated by educating rToken holders about this type of attack and setting an adequate threshold for the veto, so that any attack is at least somewhat expensive. Given that there is a “rage quit” timelock even after overcoming a veto, the damage can be substantially reduced even in the event of an attacker successfully social engineering a fake veto. rTokens rage quitting would also reduce the gains an attacker could hope to make, reducing the incentives for the attack in the first place.

Setting the veto threshold

Which brings us to the question of how high the threshold for triggering the veto state should be. We argue that it depends on the TVL of the rToken, since smaller rToken DAOs need to be able to set reasonable thresholds as well.

The veto threshold should be high enough, so that it makes veto spam costly, and governance should be able to change via an IP. We will look at two hypothetical rToken DAOs to get a better understanding of what good parameters could look like.

Idefix (left) and Obelix. Two hypothetical rToken DAO mascots.

Idefix is a rToken DAO with 100,000 USD worth of TVL
Obelix has 5,000,000,000 USD worth of TVL

For Idefix a 1% veto threshold would mean 1,000 USD worth of tokens need to be deposited in the veto escrow. While this might be a small amount and not enough to reliably prevent spam vetoes, we think it is adequate, given the TVL and the potential profit attacks could have. At the same time it is also reasonable to assume that a benevolent actor trying to prevent an attack could deposit more than 1,000 USD worth of Idefix.

A 0.001% threshold would be just 1 USD worth of Idefix, and not enough to prevent scam.

For Obelix a 1% veto threshold would mean that it takes 50 million worth of tokens to prevent a malicious proposal from executing. A threshold this high might prevent a veto when it would be needed.

A 0.001% threshold would still be 50k worth of Obelix. Still a sizable amount, but given the TVL it is reasonable to assume that one or more rToken holders would be able to deposit as much into the veto escrow.

50k worth of collateral is still enough to prevent everyone but the most desperately motivated spammer. After all a veto only slows governance down, which is something a big rToken DAO might want to do anyway. It is hard to imagine a scenario where maliciously triggering the veto state would be worth more than 50,000 USD.

Even though it’s good practice to scale the veto threshold with TVL, it would make sense to introduce an upper cap to the threshold so it never gets too hard to trigger a veto.

We propose using a 1% or 500k USD worth of rTokens as an upper threshold, whichever is less. Conversely the minimum threshold should be 0.0001% or 1,000 USD worth of rTokens, whichever is more.

Conclusion

“If a tax hike makes it to my desk, I’ll veto it in less time than it takes Vanna White to turn the letters V-E-T-O!” – Ronald Reagan

As you can see vetoes have a long-lasting tradition in governments across the world. They present an important safety feature to prevent unintended consequences.

A veto module would decentralize the Guardian role, with all the legal advantages of such an implementation. Combined with the Freeze Module, it offers a high degree of security by making the cost to defend against a governance attack substantially lower than the cost of the attack.

We are calling out to governance researchers and game theorists to poke holes in the proposed system so we can help Reserve Protocol and other DAOs to decentralize the governance role.

Reach out to the author on Twitter DM or via a comment here.