EVM Treasury Governance:
Dear Community!
This Doc introduces the planned functionality and upgrades to Shimmer and later IOTA Governance through smart contracts in the EVM to secure our large Community Treasuries.
This concept results from my observations and studies of Governance in the Web3 and DeFi space during the last two years and the analysis of dozens of DAO Communities and hundreds of Governance votes. It also incorporates a lot of feedback that we had in our community governance group over many of our weekly meetings, where we discussed this concept and the proposed implementation in large detail. Furthermore, a lot of technical input was gained in consultations with our ISC smart contract Team (thanks, Dave) and EVM Ecosystem Builders of our community.
In the Community Governance Group, we have extensively discussed this topic, proposed solutions, and aligned that this is how we want to move forward to give the Shimmer community, and later the IOTA community, decentralized control over their Treasuries.
We concluded that the currently most secure and suitable system for the Shimmer and IOTA community would be to trust the widely used Open Zeppelin Governor system, which has proven itself over the last few years to be capable of securing community owned assets worth billions of dollars and allowing the maximum form of decentralized control for a community of token holders over its assets. Good function overview also here
Intro:
The Shimmer community owns tokens given to them through a governance vote at the network’s genesis.
The IOTA Community owns tokens given them through a Governance vote conducted in June 2022 following the Chrysalis network update in April 2021.
The most secure and decentralized way to collectively control some tokens as a community is through a Governance system that secures these tokens in a smart contract and spends these tokens only if a vote conducted by the token holders permits a fund transfer. Then, the smart contract acts on this granted permissions and transfers the funds to an address as defined in the governance proposal.
The Ethereum community has developed a range of “Governor Smart Contracts” (Compound, Open Zeppelin, Maker DAO, AAve, Balancer, etc.) that have become the standard to secure large community treasuries for many years.
We aim to adopt one of the most used ones (Open Zeppelin Governor) to secure the Shimmer Community Tresury tokens (currently 3,5% of the Shimmer supply) and later the IOTA Community Treasury (nearly 55 Million IOTA).
Given the vast amount of capital those contracts should secure, only the most secure and tested solutions should be used, and a thorough analysis of the whole system, its dependencies, and risks has been undertaken and is continuously ongoing.
Since we already have a specified Governance system based on voting through Firefly on L1, we aim to reassemble our already existing Governance system and principles used ideally. But, as the EVM’s technicals differ from the UTXO-based Tangle Ledger, some things cannot be copied 1:1. Therefore, for Governance decisions happening in this system in the EVM, some principles and parameters must be adapted.
The general Plan looks like this:
- We have defined the needed functionality for this system
- We have an experienced Dev in the IF that will start building the solution for the community
- The user-facing application in which votes will happen (Webapp / Frontend) will be a commonly used DAO toolTally that is leveraged by many larger Web3 protocols to conduct their on-chain governance (they are happy to integrate Shimmer EVM for a Grant).
- We deploy the system on the Shimmer EVM Testnet and conduct rigorous testing with the community
- We conduct an Audit of the created contracts and resolve potential issues
- The system will be deployed on Shimmer EVM
- Transfer of Community Assets from Shimmer L1 into the EVM Governance contract.
- Deployment of the same system on the IOTA EVM once this network is available
The Shimmer EVM Governance system must offer the following functionalities.
1.) Asset protection
Under no other circumstances besides a correct proposal and governance vote, funds from the treasury address can be released. The system must be resilient against attack scenarios
2.) Proposal creation
Someone must be able to create a proposal that asks voters to decide on fund spending,, i.e., “Should 10 million SMR tokens be sent to address xxxx?”
3.) Voting
Voters need to be able to decide on this proposal, i.e., “Yes”, “No”, and “Abstain.”
4.) Proposal execution
Once a decision to spend the tokens has been reached, the system must be able to execute the proposed transaction automatically upon being called.
5.) Parameter adjustment
Certain parameters of the system (like quorum and timings) can be adjusted, but only through a correct proposal and governance vote
A descriptive overview of the functionality offered by the Open Zeppelin Governor contracts and potential difficulties for our approach:
ERC20 Token:
Voting power in the system is fundamentally based on Shimmer tokens. Our L1 governance specifications define one vote as 1000 Glow per milestone. As we do not have a time-based accumulation of votes in the EVM Governance, and therefore this metric cannot be used for the EVM Governance, we can change this to the most common standard: 1 Shimmer token equals 1 vote.
Important to mention is, that the tokens used as Governance Token in the Open Zeppelin Governor system must use the ERC20votes extension:
This extension keeps a history (checkpoints) of each account’s vote power. Vote power can be delegated by calling the delegate function directly or providing a signature to be used with delegateBySig. Voting power can be queried through the public accessors getVotes and getPastVotes
As our current ERC20 SMR mockup created through the magic contract (the SMR that you automatically receive when you deposit SMR from Firefly into the Shimmer EVM chain) does not include this extension, we must use wrapped SMR, a token that provides the ERC20votes extension.
To participate in governance, voters must first wrap their SMR tokens into wSMR before participating in any Governance vote.
As this wrapped Shimmer is also natively used in many of the DeFi protocols operating in the EVM, this is not much of a hustle, and wrapping/unwrapping SMR/wSMR is easy.
This means actually: Voting Power is defined as one vote = 1 wSMR instead of 1 “native” SMR.
Total EVM SMR token supply and voting Quorum:
A particular and somehow unique property of our “dual network system” where the native Token can move freely between L1 and L2 is that we have no idea how the total SMR supply of 1.8 Billion SMR will be distributed over those two networks.
It may happen that only a fraction of the total SMR supply will be transferred from users into the Shimmer EVM. It can also happen that the available supply in the Shimmer EVM changes rapidly because users withdraw their tokens back to L1. Concerning Governance, this presents us with a challenging situation!
A Governance system usually defines a participation threshold of voting power that a proposal must overcome to make it a legit and eligible governance decision (quorum). This makes sense because:
- A very small quorum causes the risk that votes of no interest to most network participants still pass a vote successfully and must be executed even if only a few people participate.
- A too-large quorum inherits the risk of a “governance freeze” where the community cannot activate enough voting power to make any decision, even with the best intentions.
As you then also cannot change the Quorum through a vote anymore, you are “stuck”. - Defining a good quorum is, therefore, a delicate topic.
Our experience from the first 3 On Chain voting Events in our history has shown us that our currently defined quorum for votes happening on the Tangle has been a good setting with a requirement that minimum 5% of the total supply of Tokens must participate in the vote to make it a valid governance decision.
The participation in Governance votes in IOTA and Shimmer so far has been:
- IOTA BUILDvsBURN: 17,41%,
- Shimmer Ecosystem Funding Vote: 9,77%,
- Shimmer Community Grant Committee, Growth Committee, and Member selections: 6,4% - 7,4%.
This should signal that 5% of the supply will likely be achievable for important Governance decisions.
- Now the question for us is:
Once a governance vote happens, how much of these tokens will actually be in the Shimmer EVM & wrapped into wSMR at the point the snapshot of voting weights will be taken?
The “snapshot” is a defined time at which the governance system determines which addresses with which balances of Governance tokens can participate in the vote.
The standard Open Zeppelin Governance contracts define the quorum as a percentage of the total supply of the ERC20 token used to vote.
This makes a lot of sense in networks with a slightly changing supply through the burning and minting of tokens and inflation models, as the quorum always adapts to the “real” existing supply over time.
But for our EVM, this means that if only 100 million SMR would be wrapped into wSMR at Snapshaot time, it would result in the quorum being only 5 million wSMR.
If the whole supply of SMR (1.8 Billion SMR) would sit in the EVM and have been wrapped into wSMR, the quorum to make a vote valid would be over 90 million wSMR.
This is an obvious problem, and as we cannot predict the number of tokens that will be active in the Shimmer EVM to participate in Defi or other activities, we will need to change the Open Zeppelin code and implement a fixed number of wSMR tokens that defines the quorum for every governance vote.
The next option in the Open Zeppelin contracts is the source used for the quorum calculation. It can either only account “For” votes or it can take the sum of “For” and “Abstain” votes into the quorum calculation.
This differs from our current approach on L1, which defines the quorum count as “All casted votes”.
We decided to use the predefined GovernorCountingSimple module of the Open Zeppelin contracts. This gives a voter three options (For, Against, Abstain) and counts “For” and “Abstain” votes in the quorum.
Therefore, we have to set the fixed quorum amount to consider this, as now only the “For” and “Abstain” votes count for the quorum calculation. Because a vote always needs a simple majority (50%) to pass, the quorum for votes in the EVM should be 2.5% instead of the 5% we use on L1. A fixed quorum requirement must be set as 45 million wSMR.
45 million wSMR tokens must either vote with “Yes”, or “Abstain” in a vote to pass the quorum and let the Governance system accept the outcome of the vote.
Quorum Parameter adjustment
The next question is whether we want to allow Token holder Governance to change this parameter?
If we make it upgradeable, a Governance proposal could be issued that sets it to a very dangerous (too low or too high) level. If we dont make it upgradeable, we have no chance to correct a misconception of our initial estimation here in the future besides completely redeploying the whole system to a new Governance contract.
Therefore, we decided to make it upgradeable through Governance and trust our network to make educated decisions and our “off-chain” processes that serve as a system of checks and balances to prevent a risky or wrong proposal from entering the stage as a voteable proposal.
To mitigate the risks of voting tactics in which a potential malicious actor or just a lazy whale waits till the last seconds of the voting period to cast a vote and moves the count above the required quorum, we also implement the GovernorPreventLateQuorum function. This adds an additional period of 24 hours to the voting period to allow other voters to step in and react to such a move that establishes a quorum just shortly before the end of a vote.
Voting delay:
This parameter defines the period between proposal creation and the snapshot time where the voting power of all voters in the system will be fixed.
This is a critical parameter because it defines who can vote with how many tokens in the vote.
This happens by taking a snapshot of all balances at a specific timestamp after submitting the proposal by calling the propose function, defined as voting delay.
Taking learnings from our L1 Governance functionality, this voting delay should be at least seven days.
This gives voters enough time to do the following:
- Receive the information that a vote is happening
- Move Tokens from the Tangle into the EVM
- Wrap those tokens from SMR into wSMR
- Delegate the voting power of those tokens either to themselves or to a trusted actor (EVM account)
Voters must have all the tokens they want to use for this vote prepared in this manner untill the VotingDelay period ends.
Later adjustments to the voting power of an account are not possible.
Meaning they must withdraw their wSMR tokens from any smart contract into their wallet if they want to participate in the vote.
This additional burden will likely cause lower participation than expected for some votes. It might also influence the liquidity and function of DeFi protocols in the EVM if a large amount of Tokens is removed from the protocol for the snapshot.
The good thing is that after the snapshot (happening at a specific timestamp), users can move their tokens freely and do as they please again (As opposed to our L1 voting system that forces them to hold tokens in the vote if they want to gain substantial voting power) because their voting power is based on the holdings at the time of the snapshot.
Taking the snapshot, we can implement a specific safety measure against the so-called Flash Loan Attacks.
Because we will have only Allowlisted accounts to call the propose function (our Governance moderators after the proposal has passed Phase 2 of our Governance Process, we can randomize the exact timestamp at which a proposal gets added to the system and therefore render Flash Loan attacks impossible.
If we set voting delay to 0, the snapshot happens once the propose function is manually called by the last required signer of the multisig Wallet, and therefore, an attack cannot be prepared and executed.
This means that we will always have an announcement period of 7 days before the snapshot, where we communicate the need for voters to get their Governance tokens into their wallets and set up the necessary delegation to be included.
Voting Period:
This period begins directly after the snapshot took place. During this period, voters can vote by issuing a voting call to the governor contract through the Tally voting application.
Following our approach from L1, this period will be another seven days.
Remember that people who have not followed the project closely enough and have missed the announcements around the vote will only have a chance to enter the vote if they held wSMR tokens at their address at the time of the snapshot and had an active delegation set up.
We should also advertise that people not interested in participating in Governance delegate their tokens to someone else. A dedicated information section and easy Delegation procedure is needed to enable big participation in these governance votes.
Proposal Threshold:
The original Open Zeppelin Governance system allows every account to call the propose function of the Governor’s contract and, therefore, create a governance proposal.
But, the Governor settings also allow us to define a Threshold of how many tokens an account must control (through ownership and delegation) to be allowed to create a proposal in the system. This serves basically as spam protection.
Our specified Governance processes do not allow such functionality, which would allow anyone to randomly create a governance vote without first moving through the defined Governance process (Phase 1 & Phase 2).
All Proposals that reach “Phase 3 (on-chain voting)” must have followed a specific process, and we do not allow any arbitrary proposal that has not qualified through passing Phase 1 and Phase 2 of our Governance process to become a binding On-Chain vote.
Therefore, we should modify this functionality of the Governor system to allow only specific accounts to create proposals.
We have a defined “Governance moderator” group that checks if proposals follow our defined standards and has the right to decline proposals that do not fulfill these standards.
We will, therefore, do the following to account for this process:
- Allowlist Two addresses to be the only addresses allowed to create proposals in the system. This will be the multi-signature Wallet controlled by those community members who are Governance moderators.
- To mitigate the risk of a lockdown by this group because of lost private keys, etc., we propose to give other addresses allowlisted status (could be a multisig Wallet held by TEA).
Timelock:
A timelock contract adds a specified timeframe after the voting period in which no execution of the vote result is possible.
Without a timelock, the proposed spending of assets from the treasury will happen as soon as the voting period is over and anyone calls the function to execute the proposal. Adding a timelock is standard practice in Governance and has several advantages:
- Rage quitting - Voters who are unhappy with the outcome of the vote can sell their tokens and leave the network before the voted changes take effect.
- Much more important: The vote can be reviewed, and any potential malicious activities could still be uncovered before funds are transferred, allowing for potential emergency actions to protect the system.
Also to consider: The standard implementation of the timelock contract is that every account in the network can call the function to execute the proposal once the timelock period is over.
The timelock has three roles defined in its access control system:
The Proposer role is in charge of queueing operations: this is the role the Governor instance should be granted, and it should likely be the only proposer in the system.
The Executor role executes already available operations: we can assign this role to the special zero address to allow anyone to execute (if operations can be particularly time sensitive, the Governor should be made Executor instead).
Lastly, there is the Admin role, which can grant and revoke the two previous roles: this is a very sensitive role that will be granted automatically to the timelock itself and optionally to a second account, which can be used for ease of setup but should promptly renounce the role.
This option of a second account to be admin would make it possible to have an “emergency intervention” to safeguard (or freeze) the treasury. If we gave this role to a Tangle Ecosystem Association MultiSig or the Community “Governance moderator” MultiSig, we would have a last chance to save the treasury from being drained by a malicious actor.
This is an extremely sensitive decision. It needs further discussion!
I would propose to use the following parameters in the system:
| Parameter | Value |
|---|---|
| Token | wSMR (ERC20votes) |
| Quorum | 45 million wSMR |
| PreventLateQuorum | 24 hours |
| Voting Delay | 0 Seconds, seven days off-chain enforced through rules |
| Voting period | 7 days |
| Timelock period | 3 days |
| Whitelisted Proposer | Governance Moderator Multisig, Tangle Ecosystem Association Multisig |
| Second Timelock Admin | Governance Moderator Multisig |
I hope this gave you a comprehensive overview of what we plan to build over the next couple of weeks to give SMR Tokens holders full access to their Token Treasury.
More Details about the used Smart Contract can be found in the Shimmer Open Zeppelin Governor Contracts document,
A detailed description of potential attack scenarios and the planned ways to mitigate/eliminate those attack vectors can be found in the Shimmer EVM Governance Attack analysis document.
