# Shimmer EVM Governance Attack analysis

We analyze potential attack scenarios of how malicious actors could try to access the community Treasury Tokens secured by the Governance Contracts.

To spend tokens from the Governance contract, a spending proposal must reach **THE MAJORITY of votes**. Once this condition is fulfilled, Tokens can leave the Governance contract.

Throughout the last couple of years, the DAO community has seen endless attempts of attacks, and also, some always retaining general issues with community governance and participation have appeared. We have addressed many of those issues while we designed the principles for Governance on IOTA for the Build vs. Burn vote and refined them for Shimmer by creating the Shimmer Governance framework.

Generally speaking, the Shimmer Governance framework with all its rules and conditions also applies to the Shimmer EVM. However, we have to adopt some parts of it due to the different technical capabilities of the Shimmer EVM and the involvement of Smart Contracts.

One important thing to remember here is always the ratio of **cost of attack vs. profit from attack** to see if attacks make economic sense.
Our Governance design aims to reduce this ratio to 0 so that there is no possible way for an attacker to end up with a profit from an attack.


#### **Possible attack scenarios and risks and how we plan to mitigate and eliminate them.**

### **1. Proposal spamming:**
In this case, actors overwhelm the system and the voters with many useless or spammy proposals.
Voters would have to filter through the spam to find the proposals of genuine interest, which is tiresome and would likely lead to them losing interest in Governance.
The Shimmer Governance Framework protects against this issue by having a **3 Phase process** and a clearly defined **scope of Governance** that allows proposals only through the Governance forum (Phase1) and only if they meet specific conditions checked by a team of Governance moderators that are **permitted to reject submissions that do not meet this standard**.
- The Hornet participation plugin and the Firefly Wallet still allow everyone to create proposals and ask people to vote on them. Still, as we have clearly defined, the default IF nodes only accept Phase 3 proposals that went through the process described in the Governance framework; voters do not see custom proposals if they dont actively implement them in Firefly.
Also, as we do not have any automated execution on L1, it solely depends on manual actions to implement a change. **Therefore L1 is protected from this spam scenario.**
- **This looks a bit different for the Open Zeppelin Governor in the Shimmer EVM**. By its default settings, anyone is allowed to create on-chain proposals in the system, and as the execution of proposals in the default settings is possible for anyone, there could be a risk of spamming, and snaeking malicious proposals through the proccess of which voters may not be aware of.

- **++We avoid this by:++**

- An **Allowlisted** address for the Governance moderator's MultiSig Wallet is the only address that should be allowed to put an proposal in the system. As a safety measure in the case that the MultiSig Wallet of the Governance moderators becomes unuseable (due to loss of keys, death of a member etc etc) we should have a second allowlisted address that should reside with members of TEA as an emergency backup to not lockdown the system.

| Problem | Mitigation parameter | Setting on L1 | Setting on EVM | Risk of happening |
| --- | -------------------- | ------------- | -------------- | --------- |
| Uncontrolled proposal creation | Limit ability to create on-chain proposal | Moderators filter spam, Default Nodes only implement correct proposals, only manual execution | only 2 allowlisted addresses (multisig) can issue proposals | very low

### **2. Malicious / Faulty Proposals:**
This means the proposal would lead to an outcome that creates **temporary or lasting damage to the network**. This is a high risk in Protocols that allow parameter changes of their applications through Governance, as executable code is allowed to change protocol settings through Governance and, therefore, can harm a system.
Faulty Proposals could also mean that **funds can be sent to a malicious actor** or that a wrong address implemented in the proposal would lead to **funds being sent to an undesired/unrecoverable address**

- **++We avoid this by++**
- **Our Governor system cannot change any external code.** It can only spend tokens from the treasury address and change parameters of the governance system itslef, so we are at no risk of changing protocol parameters of, lets say the Shimmer EVM.
- As **all Proposals should go through the defined Governance process with 2 phases of discussions before the On-chain vote**, it is possible for anyone to check for wrong or malicious spending addresses or governance parameters in the proposal.
This is also the task of the Governance moderators while they check the proposal in the acceptance phase. As the moderators will also put the final proposal into the system via their MultiSig Wallet (3 of 4 or even extended to more signers), **they will again have to check it for absolute correctness**. The instructions in the descriptions of their tasks will again highlight how important it is that all moderators **verify that the spending address/parameters in the executable proposal are correct**.

| Problem | Mitigation parameter | Setting on L1 | Setting on EVM | Risk of happening |
| --- | -------------------- | ------------- | -------------- | -------- |
| Sending funds to the wrong address | manual verification | Governance moderators must check and verify as defined in their tasks | Governance moderators must check and verify as described in their duties, 3 of 4 Multisig signers needed to put a proposal into the system | very low

### **3. Governance Takeover (51% attack)**
In this scenario, an attacker would **gain control over the majority of votes** used. If the attacker manages to put a proposal in the system to send all the treasury funds to himself and then controls the majority of votes, the Treasury tokens are lost.
This is a very complex topic and depends on many different factors.
- **To understand the potential risks better some more details for our specific Shimmer EVM case:**
- **The amount of Votes an account can use in the system derives from DELEGATED Governance tokens at the time the snapshot of voting power for a proposal is taken**
- The Governance Token used to vote is **wrapped Shimmer**
- An account can **delegate** its wSMR holding to itself and receive delegations from other accounts
- **Let's first look at ways an account can increase its holdings of Governance tokens:**
- You can get wSMR by **wrapping native SMR tokens into wSMR** through a smart contract. Therefore, the supply of wSMR is depending on the SMR supply in the EVM. And the liquidity is aligned with the available liquidity of SMR in the EVM. **This means the first way of gaining voting power is by owning/buying a lot of SMR on the open market** and converting it into wSMR.
- This means an rational attacker would buy SMR whenever the price is low and accumulate it over time.
- Another way to access SMR tokens is by **borrowing them in a Lending protocol**. Here you need to deposit a collateral (usually 150% worth of the asset you are borrowing) and can receive the asset you desire. You will **pay a fee** for the period you borrow this asset. Depending on the way you aquired the needed collateral **the costs of borowing** for an attacker might be low (if you came to your collateral by beeing an early adopter of the asset or you have created it yourself and the asset currently "pumps")
- SMR tokens should have generally good liquidity in the EVM; therefore, **borrowing more significant amounts of them seems possible if done over a longer accumulation period**. This will incur severe fees if the assets are borrowed longer than a few days but may still be a profitable action as besides the fees and the opportunity costs of locking your collateral the profits from an attack may outweight this costs.
- **Special case: [Flash Loans](https://www.researchgate.net/figure/Example-flash-loan-attack-against-Maker-DAO-All-steps-can-be-executed-within-one_fig3_339374442)**
Flash loans are **uncollateralized loans** that allow borrowers to borrow funds for a short time, typically in a matter of seconds. **The loan is repaid in full within the same transaction it was borrowed**, without any collateral or credit checks required.
In our case, an attacker would **borrow the complete existing liquidity pool** for wSMR at the **block the snapshot for voting power takes place** and repays it in the same block back to the lending protocol.
- **Lastly: Price manipulation of wSMR via Oracle exploits**. If an attacker can manipulate the oracle that tells a Dex the price of SMR in his favor, the attacker can buy all available SMR tokens at that Dex for a fraction of the regular price. If the same oracle serves several Dexes, this attack can be caried out at several Dexes simultaneously.
- **Now let us add possible attack vectors to gain a large amount of delegated voting power instead of buying or lending the tokens:**
- **Social engineering:** To get votes delegated, an attacker must convince many other accounts to point their voting delegation to him. Several ways to achieve this have been exploited in different projects.
- **Campaigning:** Influencing the public perception of voters in favor of the attacker. With the proper preparation and a budget for marketing, it may be possible to influence a community in a specific way. Your goal as an attacker is to convince voters that you genuinely represent them and that they can trust you to vote in their best interest. As this is nothing "forbidden" or criminal to do in an DLT, this can be a severe threat to a community treasury.
- **Bribing:** DeFi has developed systems that pay governance token holders for pointing their voting delegation to the actor that offers the highest rewards (see [Curve wars & bribing](https://incentivized.substack.com/p/how-bribes-drive-the-curve-wars)). As Shimmer EVM is permissionless, we could imagine seeing such a system evolve.
**This targets the group of token holders that would usually not participate in Governance** because they are not interested in it or prefer to keep their tokens in yield farming instead of removing them from rewarding activities to have them in their wallet for the voting weight snapshot. An attacker can now set up bribes to pay them to delegate to him. **This is likely cheaper than buying governance tokens** on the open market. The barrier to accepting a bribe for a token holder otherwise uninterested in Governance may also be low. **For a rational actor purely profit-driven, any bribe higher than the expected rewards from yield farming opportunities for a voting period would make sense to accept**. For an attacker, a bribing protocol is an interresting tool as it significantly reduces the cost of an attack.

**++How we plan to mitigate the risks of these attack vectors (Governance takeover)++**:
- **a) Only Whitelisted proposers:**
- As mentioned above, it greatly reduces the risk that an attacker can introduce a malicious proposal
- **b) Definition of a quorum:**
- A quorum determines how many "For" and "Abstain" votes must have been issued in a vote to make it **a valid decision**. By setting a higher quorum, you automatically increase the cost of an attack because an attacker must increase the amount of capital involved to gain control over votes.
- We propose to set this quorum to **45.000.000 wSMR tokens** which currently represents a financial investment of around 3,3 million dollars if accumulated over a longer time.
- But we also have actors in the system that **did not pay for their SMR tokens**. They received them "for free" through staking. So if you already received millions of SMR through staking, your **costs to buy yourself in to overcome the quorum are lower**. Combining this with the costs of borrowing tokens, bribing voters, and other campaigning efforts to accumulate voting weight, it is clear that **a high quorum alone cannot prevent sophisticated and targeted attacks** from draining treasury Tokens.
- **c) Voting periods:**
- Time plays a crucial factor in making community members aware of an upcoming Governance vote. They need to have enough time to **understand a proposal and prepare their funds to participate in a vote**. This will make it possible for them to act in their best interest. We propose giving voters **seven days to delegate their voting weights** (to themselves or someone else) before voting weight snapshots are taken.
- Additionally to the seven days' time to delegate, **another seven days voting period** gives every voter enough time to cast their votes.
- This mitigates a lot of issues. Combined with accurate information and education about governance and upcoming votes, **we believe this is a good way of making it challenging and especially expensive for an attacker to gain such a large amount of votes** that the community could not counter such an attack with their own voting power.
- **d) Analytics:**
- We aim to integrate Shimmer EVM with **[Tally](https://www.tally.xyz/user/connect?redirect=/user/your-daos)** as the user interface for Governance. Tally offers deep **analytics on voting power and delegation**. This helps voters understand how power in the network is distributed. It can be a helpful tool to determine which account has how much potential weight in an upcoming decision and how they have behaved in previous votes.
- **e) Delegation:**
- A significant influence on this whole process is the public participation in governance. As this is usually very low, a way to **increase the possible active votes in the system** (and therefore directly increase the cost of an attack by gaining the majority of votes) **is the Delegation system**.
**We should encourage every token holder to delegate their 'unused' voting power to trusted actors of our ecosystem** if they are not interested to follow the governance proccesses themselves.
This delegates can be community leaders, Projects building on Shimmer, IF members, etc. **The more tokens holders can be convinced to delegate voting powers, the more resilient the system becomes against anonymous outsiders that aim to attack the treasury**. An essential part of this is educating about delegation and a straightforward process. Again, an excellent User Interface like Tally will be crucial.
- **The attack vector of bribing is still not mitigated with this feature** but reduced mainly as we assume that **bribing goes against the "moral compass"** of a large group of our community members (it's actually illegal in "normal" voting and therefore perceived as a form of corruption). So as long as the bribes are not of high monetary value, **we believe that many community members would delegate to someone they trust rather than someone that wants to "buy" an election.**
- Delegation in itself has, of course, its risks, as it could **lead to an enormous centralization of voting power** on a single entity (let's say the IF) - if most community members would delegate their voting power to a single actor, we lose the decentalisation in the system. Again, this can be addressed with proper education and information.
- **f) Unpredictability of the snapshot time**
- To counter the possibility of flash loans, it is crucial that **the attacker does not know at which specific time** (block or timestamp) **he needs to have the loaned assets in his account**. Most Governance systems and the Open Zeppelin Governor standard implementation work with a voting delay (timespan between proposal submission and snapshot). This gives an attacker usually the exact time point when the flash loan must be performed. We propose to change that. We are **randomizing the snapshot time** because we have only Allowlisted accounts to create a proposal. A multisig controlled by the moderators will issue the proposal. If we tell voters only the day the snapshot will happen, an attacker cannot perform a successful flash loan because the exact timestamp is unknown.
- This would work like this: Instead of an On-Chain 7-day period where voters have time to prepare their voting weights and delegation, this period is only an "announced" period. **So we perform clear communication that the snapshot will happen in 7 days**. Voters delegate in these seven days. Then on the day of the snapshot, the moderators, one after the other, sign the Multisig proposal submission, **and only if the last signature of the required 3 happens, the proposal is submitted**. We then either set the proposal delay period to just 1 second or completely remove this period (set it to 0). Meaning the snapshot will happen once the proposal is submitted by the last signer. This might be sufficient as we can arrange that the moderators do this at **unpredictable times** and we assume that they are not the attackers themselves (yes it involves trust). Of course, it is possible that an attacker then attempts to bribe the moderators. Still, **as human interactions with the chain cannot be 100% predicted**, it is highly impossible for the attacker to perform the flash loan synchronized at the exact second the 3rd moderator submits the contract and calls the contract to place the proposal. Especially with this low blocktime and the additional randomizing of tx orders in the consensus of ISC.
- **g) TimeLock**
- The Timelock is a crucial part of those governance contracts. **It adds a "freeze" period after the voting period has ended** and before the proposed action can happen. This gives the network time to react in the worst-case scenario of a malicious proposal bypassing all the measures mentioned above and needs to be executed. Network participants would be able to sell their Tokens if they are unhappy with the outcome. Even a hard fork of the network could be prepared. It also gives users time to validate the correctness of the voting result and make the community aware of malicious activities. **A good practice is setting this period to a minimum of 3 days**.
- **h) TimeLock admin**
- It is possible to grant **a second account besides the Governor contract itself admin rights for the timelock**. The admin account can change the addresses that defines the proposer and the executor role of the Timelock contract
- 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).
- The admin can **revoke this permission** from the Governor's contract. Giving these admin permissions to a Multisignature Wallet controlled by the trusted actors could allow us to invoke an "**emergency stop**" to the system by removing the executor role during the timelock period. **This will prevent funds from being spent from the timelock.**

| Problem | Mitigation parameter | Setting on L1 | Setting on EVM | Risk of happening |
| --- | -------------------- | ------------- | -------------- | -------- |
|Flashloan attack (uncollateralized loan of Governance tokens) | randomized unpredictable Snapshot timing, manual verification of payout address through moderators, Allowlist | not applicable | manual submission of proposal with ProposalDelay = 0 sec, only Allowlisted accounts for proposal submission | very low - impossible
| Campaigning for voting power / Delegation | Increase cost of attack, Education / Information, manual verification of the payout address through moderators | Not applicable | Only Allowlisted accounts for proposal submission, quorum 45 million SMR | Very low - impossible
| Bribing Voters / Delegators | Increase cost of attack, Analytics of voting powers and delegations, education | not applicable | Only Allowlisted accounts for proposal submission, Quorum 45 million SMR | low - medium

### **4. Specific voting tactics**
These would be measures an attacker takes to dilute its malicious intentions or use weaknesses of the voting procedure itself.
- **Last minute vote swinging / quorum hunting**
- Its completely free for an account at which point in time of the seven day voting period it issues its votes. Assume a proposal is somehow malicious but has still managed to make it into the voting phase. The attacker has accumulated a vast amount of voting power, but maybe not enough to be able to withstand the community voting against him. **As long as the participation in the vote is so low that the quorum is not reached, It may be best for an attacker to not vote until a few seconds before the vote ends**. This could lead the community to not recognize the vote as a threat because the proposla seems to "**anyway fail because it does not reach the quorum**". This kind of thinking will often lead to voters not participate in a vote at all "why bother with all the voing stuff, it is not gonna pass anyway".
**Now, in the last seconds of the vote, the atacker votes for his proposal with enough voting power to achieve the majority of votes and also push participation above quorum**. Other voters would have no time to conquer this move by participating with a counter vote.
- **++We avoid this by:++**
- **LateQuorumFractionDelay**
This function adds an additional time frame to the vote as soon as quorum has been reached. Setting this to a large enough time frame (more than 24 hours) so that other voters could be alarmed and enter the count is a good way of making this attack useless.

| Problem | Mitigation parameter | Setting on L1 | Setting on EVM | Risk of happening |
| --- | -------------------- | ------------- | -------------- | -------- |
| pushing a vote in the last second above quorum and favor of the attacker | additional voting time if the quorum is reached very late in the voice | not possible to avoid | LateQuorumFractionDelay = 24 hours, Only Allowlisted accounts for proposal submission, Quorum 45 million wSMR | very low