# \[RFC\] Set Quorum to 40% of votable supply

**URL:** <https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88>\
**Category:** Request for Comment \[RFCs\]\
**Tags:** rfc, base, quorum\
**Created:** [February 18, 2025, 10:57am UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88 "2025-02-18T10:57:27Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Raphael\_Anode](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/raphael_anode/32/476_2.png) [@Raphael\_Anode](https://forum.summer.fi/u/Raphael_Anode)\
**Post date:** [February 18, 2025, 10:57am UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/1 "2025-02-18T10:57:27Z")

</div>

We wanted to start a discussion on setting the quorum to achieve maximum governance security while still allowing votes to pass.

After SIP0 the quorum is set to 35% of delegated supply (“votable supply”) or 112.35M tokens.

This means that the top 2 delegates can pass proposals.

 ![image](https://canada1.discourse-cdn.com/flex009/uploads/summer/original/1X/a45a43ece9a7b1f5349e49dd6dc32cea0780aa33.png)

While this allows proposals to pass with ease, it only takes two concerted “wrench attacks” or compromised multisigs to “hack” governance.

We propose setting the quorum to 128.4M $SUMR or 40% of delegated supply to ensure that it takes at least a third delegate to pass a proposal.

This post is intended to spark a discussion; we’re not committed to putting this on-chain yet.

---

<div class="post-metadata">

**Author:** ![MasterMojo](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/mastermojo/32/8_2.png) [@MasterMojo](https://forum.summer.fi/u/MasterMojo)\
**Post date:** [February 19, 2025, 3:02am UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/2 "2025-02-19T03:02:18Z")

</div>

This makes sense. We had 308.22M votes come in for these first couple votes. I don’t see a problem with increasing quorum to 40%.

---

<div class="post-metadata">

**Author:** ![rsokolowski](https://avatars.discourse-cdn.com/v4/letter/r/4bbf92/32.png) [@rsokolowski](https://forum.summer.fi/u/rsokolowski)\
**Post date:** [February 19, 2025, 8:48am UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/3 "2025-02-19T08:48:19Z")

</div>

Given the turnaround for the two votes we had, why not something even higher (like 50%) ?  
Stakers are incentivized to vote, hence there should be no issue with having quorum.

---

<div class="post-metadata">

**Author:** ![Raphael\_Anode](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/raphael_anode/32/476_2.png) [@Raphael\_Anode](https://forum.summer.fi/u/Raphael_Anode)\
**Post date:** [February 19, 2025, 6:14pm UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/4 "2025-02-19T18:14:30Z")

</div>

We thought about that but decided against it to make it easier for a dedicated group of smaller delegates and token holders to pass a proposal even without or against the larger delegates.

Open to 50% as well if there is broader support.

---

<div class="post-metadata">

**Author:** ![FBrinkkemper](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/fbrinkkemper/32/7_2.png) [@FBrinkkemper](https://forum.summer.fi/u/FBrinkkemper)\
**Post date:** [February 20, 2025, 2:56pm UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/5 "2025-02-20T14:56:41Z")

</div>

To avoid having this same discussion every other month, I would support a general rule for updating quorum to always require 3+ delegates.

For now that means 40%, but when there would be significant changes in delegated tokens, anyone would be able to propose a new vote to update it to be in-line with the 3+ delegate rule (max 1 vote per month or something like that).

---

<div class="post-metadata">

**Author:** ![Raphael\_Anode](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/raphael_anode/32/476_2.png) [@Raphael\_Anode](https://forum.summer.fi/u/Raphael_Anode)\
**Post date:** [February 20, 2025, 5:47pm UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/6 "2025-02-20T17:47:38Z")

</div>

I love that! This would need to be a social contract of sorts, since it’s hard to encode in a smart contract.

But I support this notion.

---

<div class="post-metadata">

**Author:** ![Javier](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/javier/32/5_2.png) [@Javier](https://forum.summer.fi/u/Javier)\
**Post date:** [March 2, 2025, 12:19pm UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/7 "2025-03-02T12:19:41Z")

</div>

I fully support the proposal to set the quorum to 40/50%, but I also want to highlight Frank’s comment.

> [@FBrinkkemper](#):
>
> To avoid having this same discussion every other month, I would support a general rule for updating quorum to always require 3+ delegates.

Voting for quorum on a daily basis will be exhausting for everyone, so I wonder what other alternatives we have. @0xtucks I’d love to hear your opinion on the technical side on implementing something like a 3-delegate rule. Or what other alternatives we have.

---

<div class="post-metadata">

**Author:** ![FBrinkkemper](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/fbrinkkemper/32/7_2.png) [@FBrinkkemper](https://forum.summer.fi/u/FBrinkkemper)\
**Post date:** [March 3, 2025, 3:00pm UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/8 "2025-03-03T15:00:11Z")

</div>

Hi Javier,

I suggest this not as a technical enforce, but rather as an addition/update to SIP0, and thereby making it part of the governance processes.

---

<div class="post-metadata">

**Author:** ![Raphael\_Anode](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/raphael_anode/32/476_2.png) [@Raphael\_Anode](https://forum.summer.fi/u/Raphael_Anode)\
**Post date:** [March 3, 2025, 3:22pm UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/9 "2025-03-03T15:22:24Z")

</div>

If this can be dynamic even better. We’ll wait for clarity here before moving this to a formal SIP.

---

<div class="post-metadata">

**Author:** ![Javier](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/javier/32/5_2.png) [@Javier](https://forum.summer.fi/u/Javier)\
**Post date:** [March 4, 2025, 10:53am UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/10 "2025-03-04T10:53:14Z")

</div>

Agree

> [@Raphael\_Anode](#):
>
> If this can be dynamic even better. We’ll wait for clarity here before moving this to a formal SIP.

@FBrinkkemper, I believe you already have something quite clear in your mind. Would you draft it, and we can comment on it if neccesary?

---

<div class="post-metadata">

**Author:** ![Raphael\_Anode](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/raphael_anode/32/476_2.png) [@Raphael\_Anode](https://forum.summer.fi/u/Raphael_Anode)\
**Post date:** [March 6, 2025, 10:05am UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/11 "2025-03-06T10:05:04Z")

</div>

> [@Javier](#):
>
> I believe you already have something quite clear in your mind. Would you draft it, and we can comment on it if neccesary?

We would love to have this automated if possible. Something like: set to 40% of votable supply, or to 10% more than top two delegates combined…

Is that doable from a smart contract perspective?

---

<div class="post-metadata">

**Author:** ![Raphael\_Anode](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/raphael_anode/32/476_2.png) [@Raphael\_Anode](https://forum.summer.fi/u/Raphael_Anode)\
**Post date:** [March 13, 2025, 1:46pm UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/12 "2025-03-13T13:46:47Z")

</div>

IndexCoop had an interesting idea for a _dynamic_ quorum.  
Quorum is lower for proposals that are uncontentious, but as soon as the ratio of yes/no votes decreases it rises.

The rationale there being that a contentious vote needs more support to be ratified since the community isn’t unanimously in favor.

There’s a top and bottom boundary, which can be set to sensible values.

Imo this should be implementable in a smart contract, it’s simple math around parameters that are known anyhow.

Original post here: [IIP-153: Implement Dynamic Quorum for Metagovernance - Proposal - The Index Coop](https://gov.indexcoop.com/t/iip-153-implement-dynamic-quorum-for-metagovernance/4187)

Tagging @Javier and @FBrinkkemper for input here.

---

<div class="post-metadata">

**Author:** ![0xtucks](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/0xtucks/32/17_2.png) [@0xtucks](https://forum.summer.fi/u/0xtucks)\
**Post date:** [March 19, 2025, 1:51pm UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/13 "2025-03-19T13:51:18Z")

</div>

These are all good ideas.

Given quorum is calculated as a % of the total supply. This will require fairly frequent updates to keep aligned.

Perhaps we can set a cadence here where quorum is set to the maximum of say 40% of delegated tokens or 10% over the top of the two largest delegates.

As of today (19/03/2025):

- 40% of delegated tokens = 130.58M
- The top two delegates plus 10% = 140.91M

So, we’d take 140.91 as the quorum threshold. Current supply is 975.13M due to bridged SUMR.

So, the quorum % would be 140.91 / 975.13 = 14.45% (up from 4%)

I’m happy to create these proposals according to these rules short term. And can automate it fairly.

Lmk thoughts.

@Raphael_Anode I don’t think 50% is unreasonable given we’re consistently seeing proposals passing with north of 200M participating votes.

---

<div class="post-metadata">

**Author:** ![Raphael\_Anode](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/raphael_anode/32/476_2.png) [@Raphael\_Anode](https://forum.summer.fi/u/Raphael_Anode)\
**Post date:** [March 20, 2025, 10:53am UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/14 "2025-03-20T10:53:04Z")

</div>

Yeah I think 40% plus 10% seems the most inclusive. We’ll work to get this on-chain next week. We can update the quorum quarterly. I think that’s sufficient.

---

<div class="post-metadata">

**Author:** ![Javier](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/javier/32/5_2.png) [@Javier](https://forum.summer.fi/u/Javier)\
**Post date:** [March 23, 2025, 6:30pm UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/15 "2025-03-23T18:30:23Z")

</div>

Thanks for the discussion, @0xtucks and @Raphael_Anode!

Given the calculations, I agree that the updated quorum threshold should be **140.91M / 975.13M = 14.45%**. Since the **quorum denominator is 100** , the closest possible **quorum numerator must be either 14 or 15**??.

 ![image](https://canada1.discourse-cdn.com/flex009/uploads/summer/original/1X/02d350f7b46fb6f5db17994df259e008a837c521.png)

[https://basescan.org/address/0xbe5a4dd68c3526f32b454fe28c9909ca0601e9fa#readContract](https://basescan.org/address/0xbe5a4dd68c3526f32b454fe28c9909ca0601e9fa#readContract)

I believe to reflect the intended **14.45%** , **15** would be the closest rounding since we usually have quite a lot of votes, effectively setting quorum at **15% instead of 14.45%**. If we round down to **14** , we’d technically be slightly below the target.

Would love to get final confirmation on which way we prefer to round, but either way, I’m aligned with the new quorum adjustment and the quarterly updates!

---

<div class="post-metadata">

**Author:** ![Javier](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/javier/32/5_2.png) [@Javier](https://forum.summer.fi/u/Javier)\
**Post date:** [March 25, 2025, 1:56pm UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/16 "2025-03-25T13:56:15Z")

</div>

@0xtucks @Raphael_Anode I’m ready to push this proposal onchain.  
James please check if it’s correct.

I will propose `newQuorumNumerator` to **`15`** on [https://basescan.org/address/0xbe5a4dd68c3526f32b454fe28c9909ca0601e9fa](https://basescan.org/address/0xbe5a4dd68c3526f32b454fe28c9909ca0601e9fa)

 ![Screenshot 2025-03-25 at 2.49.21 PM](https://canada1.discourse-cdn.com/flex009/uploads/summer/original/1X/b379fe7c28fb62225fc69d755f95f8acea877772.png)

Simulation:

 ![Screenshot 2025-03-25 at 2.54.18 PM](https://canada1.discourse-cdn.com/flex009/uploads/summer/original/1X/dc5e6747ea17870b6709cd6e1cdd7f0d72a7983c.png)

> **[Tenderly Dashboard](https://dashboard.tenderly.co/JavierSummer/project/testnet/e3aaa1fe-1cce-4956-9942-321008142b63/simulator/e8d7f62d-39f1-4916-9277-b96744915c9a)**
>
> Tenderly is a full-stack infrastructure for the entire dapp lifecycle, offering the only node RPC with built-in development environments and tools. Sign up now!

---

<div class="post-metadata">

**Author:** ![Raphael\_Anode](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/raphael_anode/32/476_2.png) [@Raphael\_Anode](https://forum.summer.fi/u/Raphael_Anode)\
**Post date:** [March 25, 2025, 2:46pm UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/17 "2025-03-25T14:46:37Z")

</div>

Let’s do it! Thank you ser for taking this across the finish line 🏁

---

<div class="post-metadata">

**Author:** ![0xtucks](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/0xtucks/32/17_2.png) [@0xtucks](https://forum.summer.fi/u/0xtucks)\
**Post date:** [March 25, 2025, 3:22pm UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/18 "2025-03-25T15:22:58Z")

</div>

Looks good. Thank you for arranging. @Javier

---

<div class="post-metadata">

**Author:** ![Javier](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/javier/32/5_2.png) [@Javier](https://forum.summer.fi/u/Javier)\
**Post date:** [March 26, 2025, 9:04pm UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/19 "2025-03-26T21:04:26Z")

</div>

The proposal is now on-chain: [Tally | Lazy Summer DAO (Official) | SIP 0.1: Quorum Update](https://www.tally.xyz/gov/lazy-summer-dao-official/proposal/19517781499367190379456124186803279256864616798536646186680121027950767823455)

---

<div class="post-metadata">

**Author:** ![0xtucks](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/0xtucks/32/17_2.png) [@0xtucks](https://forum.summer.fi/u/0xtucks)\
**Post date:** [March 28, 2025, 2:08pm UTC](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88/20 "2025-03-28T14:08:20Z")

</div>

Please don’t be alarmed by the tenderly simulation failing.

The issue lies with the manner in which Tally simulation proposal execution.

The simulation is executed from the perspective of the timelock which for 90% of proposals is just fine.

However, when targeting the governor contract a crucial step is missed.

Assuming the proposal is successful. The execute method on the Governor contract will be called. In the body of this method, calldata is hashed and added to an array on the Governor contract.

```auto
       if (_executor() != address(this)) {
            for (uint256 i = 0; i < targets.length; ++i) {
                if (targets[i] == address(this)) {
                    _governanceCall.pushBack(keccak256(calldatas[i]));
                }
            }
        }

```

When the timelock then executes the queued proposal, and targets the Governor, calldata is retrieved from array and matched with the calldata being passed by the timelock.

```auto
      if (_executor() != address(this)) {
            bytes32 msgDataHash = keccak256(_msgData());
            // loop until popping the expected operation - throw if deque is empty (operation not authorized)
            while (_governanceCall.popFront() != msgDataHash) {}
        }

```

It’s an additional layer of security when making updates to the SummerGovernor.

Secondly, it’s tricky for Tally to set this up as part of their tenderly simulations. It would require them to have specific handling for Governor targeted Timelock executed setups. Would require:

- the use of testnets where the proposal is forced queued
- and time jumped to when the proposal is eligible for execution
- and the simulation would need call into the governor, and not the timelock, for the specific transaction

[Next page](https://forum.summer.fi/t/rfc-set-quorum-to-40-of-votable-supply/88.md?page=2)