arXiv CSopen access

On Exercising Governance Power in Decentralized Autonomous Organizations

arXiv:2607.26204v1 [cs.CR] 28 Jul 2026

On Exercising Governance Power in Decentralized Autonomous Organizations Vabuk Pahari

Balakrishnan Chandrasekaran

Johnnatan Messias

Max Planck Institute for Software Systems Germany [email protected]

Vrije Universiteit Amsterdam Amsterdam, Netherlands [email protected]

Max Planck Institute for Software Systems Germany [email protected]

Krishna P. Gummadi

Abhisek Dash

Max Planck Institute for Software Systems Germany [email protected]

Max Planck Institute for Software Systems Germany [email protected]

Abstract—A decentralized autonomous organization (DAO) is a governance entity that allows its stakeholders to manage blockchain-based protocols through smart contracts. The DAO explicitly specifies how stakeholders make and enforce decisions concerning a protocol’s operation in a smart contract, aptly referred to as its governance contract. The design of this governance contract, therefore, has far-reaching implications for the security (trust) and privacy (transparency) of the smart contracts managed by the DAO and its stakeholders. In this work, we (i) explicate the trust and transparency trade-offs of the design choices in implementing a DAO and (ii) highlight how poor choices introduce critical vulnerabilities, using realworld examples as case studies. To this end, we analyze 48 public, actively used Ethereum-based DAOs that control a vast capital. We classify the design choices into a handful of key dimensions that succinctly capture how a DAO’s stakeholders initiate a protocol change, vote on it, and, based on the voting outcome, execute that change. Our analyses crucially uncover a new class of attacks, which we call governance attacks, that directly exploit the fundamental design of a DAO’s governance mechanisms, even if we assume bug-free implementations. Index Terms—Decentralized Autonomous Organizations, Governance, Security

the proposed changes. Stakeholders’ voting rights and powers are typically determined based on the volume of governance tokens that they hold or have “invested” in the DAO. Since the governance tokens are publicly traded—anyone can buy these tokens, anonymously, and acquire governance power—the manner in which governance power is exercised by a DAO’s stakeholders has far-reaching trust and transparency concerns for the DAO and its stakeholders. A DAO’s governance contract, hence, unsurprisingly, adopts various safeguards to protect itself from attackers. A DAO’s safeguards range from “gatekeeping” stakeholders’, by controlling how and when they can exercise their governance power, to introducing “guard rails” for the decentralized decision making process, by empowering (centralized) authorities to control (e.g., veto) the voting outcomes, if required. Although these safeguards are crucial for making the DAOs resilient to attacks, they violate the DAOs’ fundamental design tenet—decentralized governance. In this work, we investigate such DAO safeguards to expose the design choices and trade-offs involved in their implementations. We analyzed the governance contracts underlying 48 DAOs with the largest treasury sizes [6], reviewed their software implementation, and read their developer documentations and specifications. Though virtually all of governance contracts differ from one another in some respects, we identified a set of key dimensions along which their designs differ. These design choices reveal the complex trade-offs that designers of governance contract need to balance between realizing the decentralized self-governance ideals of DAO (in theory) and improving trust and transparency in governance (in practice). We present a two-fold analyses of these design choices and tradeoffs. First, we analyze the formal governance mechanisms, specifically the process by which a referendum is initiated, voted on, certified, and executed in a DAO. Then, we discuss real-world governance attacks against DAOs and highlight how they succeeded (or failed) due to the choices made by the DAO designers. We summarize our key contributions as follows. • We review the (software) implementations of the smart

I. I NTRODUCTION Decentralized finance (DeFi) represents a major shift away from traditional financial systems by eliminating intermediaries in key sectors such as banking, lending, and insurance [1]–[4]. DeFi protocols instead rely on open-source smart contracts deployed on public, permission-less blockchains, which enable transparent, algorithmic interactions among global participants. They emerged around 2017 and have grown rapidly since then, securing more than 150 billion USD in total value locked (TVL) [5] today. The sustainability of this DeFi model depends critically on how the underlying smart contracts are governed (i.e., managed and updated). Today, the governance of DeFi smart contracts is facilitated by Decentralized autonomous organizations (DAOs). DAOs offer well-specified mechanisms—encoded in smart (“governance”) contracts—for their stakeholders to propose protocol changes, vote on such proposals, and, upon succeeding, enact

contracts underlying 48 DAOs and peruse through developer documentations to identify the key admission controls and guard rails used in governance protocols (Table I). • We highlight the design choices in implementing these mechanisms throughout the entire life cycle of a referendum, and we analyze their implications for the trust and transparency of the DAOs. We find, for instance, that while the vetoer mechanism enhances a DAO’s security and delegation improves its efficiency, they both cripple the promise of decentralized governance. • We discover a new class of attacks on DAOs and call them governance attacks. We show that the vulnerabilities exploited in recent attacks persist among many of the DAOs we investigated because of fundamental (mechanism) design issues. Barring changing the design of their safeguards, these implementations can be “patched” to render these DAOs resilient to governance attacks. • We will release the data we gathered and our code for analyzing the data as open-source artifacts upon publication. II. M ETHODOLOGY We selected 48 DAOs for investigation as follows. First, we focused on DAOs whose governance contracts are deployed on Ethereum, the blockchain with the highest on-chain TVL [5]. Second, we selected DAOs with the largest treasury sizes, as reported by DeepDAO in May 2024 [6]. Many of these DAOs correspond to leading DeFi projects by TVL, indicating substantial user trust and influence within the DeFi ecosystem. Third, we excluded private DAOs (e.g., the Graph Protocol [56]), where decision-making authority is limited only to a small subset of stakeholders, a model that is fundamentally at odds with decentralization. Our study, hence, consists of public DAOs, where anybody can participate in governance either by buying governance tokens in the market or doing some work for the DAO. Finally, we excluded DAOs that had not conducted a governance vote in the six months preceding May 2024, thereby removing inactive projects with potentially outdated documentation or discontinued operations. For each of the 48 DAOs selected, we parsed the official documentations to fetch contract addresses and their off-chain voting platforms. Then, we gathered all their governance contracts and governance-token contracts using Etherscan. DAOs publish the relevant contract code on Etherscan, and Etherscan validates the correctness of the code by compiling and checking that its bytecode matches the bytecode of that deployed on Ethereum. We also ran an Ethereum archive node using the Erigon Client to gather data from these contracts. Lastly, we collected off-chain voting data of DAOs using the official Snapshot API [57], [58]. III. E XERCISING G OVERNANCE P OWER The fundamental objective of a DAO is to facilitate its stakeholders to enact changes to it and manage its finances in a decentralized manner. These tasks are accomplished through (change) proposals or referendums, which then solicit the votes (or approvals) of stakeholders, and the voting outcomes

shape the protocol’s evolution. In Figure 1, we enumerate the lifecycle of a referendum by dividing it into three broad temporal segments: (a) pre-voting period, (b) voting period, and (c) post-voting period. In this section, we elaborate on these temporal segments and discuss the implications of the design choices associated with each segment. A. Pre-Voting Period This period starts from before a referendum is initiated and ends when the voting begins. 1) The birth of a referendum: The right to initiate a referendum is typically bestowed on only a subset of the stakeholders of a DAO, e.g., founders, investors, or users with substantial stake in the protocol. Constraining this right effectively protects a DAO from being spammed by random stakeholders with arbitrary proposals. The stakeholder who initiates a referendum is referred to as the proposer, and their type can be used to classify referenda. Anybody In this approach, anyone can initiate a referendum, regardless of their governance power in the DAO. Only Maker and Dxdao (#3 and #23 in Table I). Voter-initiated DAOs using this approach only allow voters (or stakeholders) with some minimum voting power, called proposal threshold, to initiate a referendum. A voter-initiated referendum is akin to a ballot initiative in California, US [59]; to be deemed eligible for voting, the initiative must garner a threshold number of signatures from the state’s residents. The proposer must have a minimum threshold of voting power. Most protocols also stipulate that the proposer must maintain this threshold voting power until the referendum is enacted, failing which the referendum can be immediately canceled. In our study 19 DAOs use only voter-initiated referenda. Authority-initiated Here, only certain trusted members (identified through their wallet addresses) are allowed to be proposers. This approach is analogous to how only the monarch has the legal authority to call a general election in the UK [60]. In our study, 13 DAOs use only authorityinitiated referenda, and all DAOs with off-chain voting allow for authority-initiated referenda. Trust and Transparency trade-offs If anyone can initiate a referendum, the DAO can be spammed by random proposals. People that do not have any stake in the DAO can initiate malicious proposals, thereby undermining the security of the DAO. Dxdao (#23), hence, uses non-transferable governance tokens, and it also has a decentralized voter distribution—the largest voter in Dxdao has about 5% of the total voting power [61]. Maker (#3), in contrast, uses a centralized process to address the security concerns: Only the ‘core’ team of Maker are involved in the process, and Maker’s governance portal only displays proposals that are put forward by these governance facilitators [62]. Proposal thresholds in voter-initiated referenda serve as an effective “guard rail” to limit, but not eliminate spam proposals [63]. Mandating that a proposer maintain the min-

TABLE I: Our investigation of 48 DAOs and their governance structures. “ID” refers to the assigned id for the DAO, which should be used by the reader when identifying DAOs in the paper. ‘Call for Referendum (Call)’ is one of ‘Voter Initiated (¥)’, ‘Authority Initiated (µ)’, or Anybody ( ). Voting platform (‘VP’) is either on-chain () or off-chain (œ). ‘Voting Format (VF)’ can be ‘Periodic Voting (Â)’, ‘Continuous Polling (¹)’, ‘Voting Type (VT)’ can be ‘Proactive (P)’, ‘Reactive (R)’, ‘Voting Aggregation (VA)’ can be ‘Vote Differential (V)’, ‘Majority (M)’, ‘Threshold (T)’, or ‘Plurality (P)’. ‘Certification (Cert.)’ is one of {‘Centralized (r)’, ‘Optimistic Certification (☼)’, Anybody ( )}. ‘Execution (Exec.) is one of {‘Centralized (r)’, ‘Anybody ( )’}. ‘Veto (Veto)’ is one of {‘Vote Initiator (I)’, ‘Veto Authority (A)’, ‘Nobody (–)’ }.

ID

Protocol

Call

VP

VF

VT

VA

1 2 3 4 4 5 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

Uniswap [7] ENS [8] Maker [9] Lido (Easy Track) [10] Lido Governance [11] Frax Finance Omega [12] Frax Finance Alpha [12] AAVE [13] Compound [14] Radicle [15] 0x Protocol [16] Gitcoin [17] Silo Finance [18] Lyra [19] API3 [20] Ampleforth [21] Instadapp [22] Rari [23] NounsDAO [24] Curve [25] Origin [26] Hop DAO [27] Cryptex [28] Angle Protocol [29] DxDao [30] Nexus Mutual [31] Goldfinch [32] ParagonsDAO [33] Illuvium [34] SuperRare [35] Mantle [36] Res. Hub Fdn. [37] Stargate Finance [38] Uma [39] Cowswap [40] Sturdy Finance [41] Euler [42] SAFE [43] Tokenlon [44] Botto [45] Balancer [46] Sushiswap [47] Gearbox [48] Paraswap [49] Alchemix [50] 1Inch [51] Shutter DAO 0x36 [52] Yearn Finance [53] Shapeshift [54] Decentraland [55]

¥ ¥

                          œ œ œ œ œ œ œ œ œ œ œ œ œ œ œ œ œ œ œ œ œ œ œ œ

  ¹                                               Â

P P P R P R R P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P

M M P M M M M V M M M M M M M M M M M T M M M M T M M T T M M M M M M M M M M M M M M M M M M M M M

µ ¥ µ ¥ ¥ µ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ µ µ¥ µ µ µ µ µ¥ µ¥ µ µ¥ µ¥ µ¥ µ¥ µ µ µ¥ µ µ¥ µ¥ µ µ¥ µ¥ µ¥ µ¥ µ

Cert.

r r r r r☼ r r r r r☼ r r r r r r r r r r r r r r r

Exec.

Veto

r r r r r r r r r r r r r r r r r r r r r r r r

I A – I, A – A – A I, A – – – – A – I I, A I, A I, A – I – – I, A – A I, A I, A I, A I, A I, A I, A I, A I, A I, A I, A I, A I, A I, A I, A I, A I, A I, A I, A I, A I, A I, A I, A I, A I, A

Pre-Voting Period

Who initiates?

Ref. birth

Voting Delay

Authority

Post-Voting Period

Voting Period Vot. platform

Vot. Format

Vot. type

Periodic

Proactive

Vot. aggregation

Single Multiple

Centralized

Execution

Execution Delay

Centralized

on-chain Maj.

Voter

Certification

off-chain

Continuous

Plu.

Vote Diff. Thresh.

Reactive

Anybody

Anybody

Veto

Fig. 1: Lifecycle of a referendum involving its birth, being put to vote, ratification of the voting, and, if approved, its execution. imum voting power until the proposal is executed, however, reduces nefarious referenda, since the proposer themselves must face the outcomes of the referendum. Authority-initiated referendas only allow a select group of stakeholders to initiate a referendum. Even if other users with substantial economic stakes or the majority of stakeholders support a specific change, they cannot initiate a referendum unless they belong to this select group. As a consequence, the decision-making process becomes centralized to this select group; a voter-initiated referenda, in contrast, fosters a diverse pool of proposers. 2) Voting Delay: DAOs often impose a voting delay between initiating a proposal and starting a vote to allow time for community support or opposition, especially if no prior discussions occur. A short delay might give malicious actors a chance to buy tokens and propose a referendum within the same block, leaving little time for others to react. 11 DAOs in our study have voting delays of 1 to 7 days (for 0x (#9)), while 8 have no delay. For example, Lido and Maker allow immediate voting, and ENS, Radicle, and Cryptex start voting in the next block. Most DAOs with off-chain voting (except 4) don’t specify a delay. 3) Pre-proposal Opinion Polling: Some protocols, like Uniswap, AAVE, and Gitcoin (#1, #6 and 10, resp.), use polling as a signaling tool before the official vote. Polling gauges community support for a proposal at no cost, and if approved, the proposal moves to a binding vote. However, this step is a procedural norm, and a user can bypass it to directly initiate an official referendum, which can pass and be executed regardless of polling results. B. Voting Period The voting period is the time when votes can be cast; outside this period, votes are invalid. Some DAOs have a rigid voting period, which cannot be changed, making them susceptible to vote sniping [63], where a voter can delay their votes until the end of the voting period, thereby deciding whether a referendum is passed in the final second. To circumvent such attacks Angle, Origin and Frax extends the voting period by 2 days, if the quorum, i.e. minimum number of votes required for a referendum to pass, was reached late. Lido only allows users to vote against a proposal on the last day of voting. This disincentivizes users from potentially waiting until the last minute to vote and influence the outcome. In all DAOs, except Illuvium, every user’s vote is seen soon as it is cast, and there is a running tally of the vote count. If a voter sees that their desired choice is winning, then they might

not feel obliged to cast their vote, especially because voting incurs a cost [64]. Illuvium, uses Shielded Voting [65], where votes are encrypted and results remains private until the end of the voting period. The voting here is, however, done off-chain, and such a scheme can be expensive to implement on-chain. There is, however, no voter privacy after the election period, as every user’s vote is revealed after the election. Austgen et al. show that private voting reduces the centralizing effect of herding [64], where users vote similarly to some influential members of the DAO [66]. 1) Voting Format: In our study, only Maker (# 3), which uses Continuous (approval) voting, does not have an explicit voting period. Continuous voting [9], requires a referendum to maintain more votes than any other (alternative) referendum to be deemed accepted. A referendum can be accepted at any time in the future, if it receives more votes than the current leading referendum. The same referendum can even be accepted twice. For example, if enough voters move their votes from an old referendum, to a new referendum and back to the old, then the same referendum is accepted twice; but some parameters in a referendum can only be executed once. 2) Voting Type: In all DAOs except for Lido and Frax, a referendum is “proactive”, meaning that a quorum of votes must be in favor for the proposal to pass. A proactive referendum calls for users to record their explicit consent to change the protocol. Since voting power can be bought, quorums serve as a safeguard by reducing the likelihood of such power transfers from influencing the outcome of a referendum. Quorums also prevent proposals with low engagement from passing, ensuring only changes approved by a significant number of users. In contrast, “reactive” referendums (or optimistic voting) are considered to have been passed, unless enough votes are cast against them. These also require a quorum; however, the quorum is voting on preventing, rather than promoting, a change from happening. Since a proposal by default effects a change, reactive referenda can only be initiated by some authority (recall §III-A1). Otherwise, malicious actors can enervate the community by continually requiring them to vet proposals that harm or destabilize the protocol. 3) Voting Platform: Once a referendum is created, stakeholders vote on the referendum to either pass or reject it. A voting platform offers an avenue for the stakeholders to cast their votes, and governance protocols have two platforms, on-chain and off-chain voting, at their disposal. Even in the real world, various voting platforms exist (e.g., in-person, electronic, and mail-in voting), each with its own accuracy, integrity, and accessibility implications. The electronic voting platform, for

Trust and Transparency trade-offs On-chain voting platforms have no additional dependencies on a third party for executing passed proposals. The well-specified rules and automatic proposal executions of the platform can, nevertheless, allow a user to engineer malicious proposals to pass. The Synthetify DAO was attacked, for instance, by a user who acquired enough voting power and passed a malicious proposal that transferred the protocol’s treasury to themselves [63]. The voting costs incurred by stakeholders in an on-chain voting platform may deter participation, especially among users with few voting rights (i.e., small economic stake) [70]. Prior work has shown that the cost per vote for ‘small’ users is significantly higher than that for larger voters, precipitating in low voter turnout and concentration of voting power among few large stakeholders [71]. The off-chain voting platform, in contrast, eliminates the cost barrier, enabling everyone to vote on a proposal. The platform, unsurprisingly, leads to a larger voting participation compared to the on-chain platform [70]. In Figure 2, we observe that in Uniswap, which employs on-chain voting with pre-proposal opinion polling, a larger number of voters participate in off-chain proposals, showing that voters do in fact participate more when there is no cost to voting. Although users of this platform do not pay any poll tax to cast their vote(s), the platform requires a ‘trusted’ third party to execute any passed proposals [72]. Unlike the onchain voting platform, stakeholders’ preferences or votes on a proposal are, hence, non-binding. However, the platform’s dependency on a third party for execution introduces a huge risk: They can choose not to execute the proposal, particularly if they deem it malicious or harmful.

1.0

1.0

0.8

0.8

0.6

0.6

CDF

CDF

instance, can foster greater voter turnout in elections compared to in-person voting, but it introduces other challenges such as voting system security and voter’s susceptibility to coercion [67], [68]. Below, we compare and contrast the properties of the two voting platforms employed by DAOs. On-chain voting In this platform, stakeholders cast their votes directly on a blockchain, ensuring transparency and immutability. Smart contracts can automatically execute protocol changes, depending on the voting results, adhering to governance rules encoded within the contracts. In an on-chain voting platform, all the rules for a referendum, from proposing to execution, is encoded in the smart contract. In our study, 24 DAOs use on-chain voting. Off-chain Voting. Votes in this platform are recorded outside the blockchain, often using a third-party platform, e.g., Snapshot [57]. (All DAOs in our study with off-chain voting use Snapshot.) Snapshot allows a protocol to create a public “space” for discussing its governance, establish voting rules, and determine voting rights based on the on-chain state. Although the voting happens off-chain, Snapshot still uses a user’s (on-chain) wallet address(es) for authenticating their vote(s). Votes are stored on a decentralized storage system [69]. In our study, 24 DAOs use off-chain voting.

0.4 0.2 0.0

0.4 On-chain Vote Off-chain Vote

0.2 0

20

40

60

0.0 80 100

# of votes (in Million)

0

5000

10000 15000

# of voters

Fig. 2: Voting participation and number of votes cast in Uniswap for on-chain and off-chain voting. Procedurally, Uniswap uses an off-chain signaling vote before an official on-chain vote. We see there is a larger voter turnout in offchain votes, possibly because it is free, allowing small users to cast their votes. But, since this is only a signaling mechanism and not official, voters with large votes might not necessarily participate. Hence, there is a much larger number of votes cast in on-chain voting, where users with large voting power are more likely to vote. C. Post-Voting Period 1) Vote Aggregation: Vote aggregation refer to rules for how votes are tallied and the rules for determining the outcome of a proposal. Aggregation rules can significantly impact the outcome of a proposal. A real-world analogy is how measures are ratified in the U.S. Senate: While most measures pass with a simple majority, a two-thirds majority is needed to ratify constitutional amendments [73]. Common aggregation rules include majority, ranked choice, and plurality voting, each with trade-offs om fairness, efficiency, stability, etc [74]. We categorize these rules into single and multiple choice. Single choice In a single-choice referendum, voters either accept or reject a proposal. The proposal must reach a quorum, and majority of voters must vote in favor for the proposal to pass. All DAOs with on-chain voting except for Maker opt for single-choice referenda. Although the majority determines the outcome in single-choice referenda, there are a few key distinctions in how they are determined in practice. (i) Vote Differential requires a minimum difference between votes in favor and those against for a referendum to pass. Majority voting is a simple form of vote differential where this difference is one. Most DAOs use majority voting with only AAVE (#6), requiring a differential of 80,000 votes. (ii) Threshold voting requires a threshold number of votes in favor for a referendum to pass. This method is used by councils, where minimum number of members need to vote in favor for a proposal to pass. Furthermore, Curve (#18) requires a specific threshold of 51% of votes for a proposal to pass instead of a simple majority. Multiple Choice Instead of voting for or against a specific change to the protocol, here, voters declare their preferences towards two or more choices. Off-chain voting protocols allow for multiple choice, albeit most votes are single choice [75]. Plurality voting: Maker is the only DAO with on-chain

voting that uses plurality voting. The DAO accepts a new proposal if it receives more votes than the current proposal (refer §III-B). The winning proposal does not need to receive a majority of votes, but only more than any of the other alternatives, although in practice they do so [76]. 2) Certification and Execution: After a proposal passes, it is certified and executed. The former entails checking the criteria for passing a proposal, while the latter constitutes the actual execution of the proposal. These privileges can be are assigned to a specific authority, with exclusive rights, similar to how the U.S. Congress certifies the results of the presidential election by officially counting the electoral votes [77]. In on-chain protocols, certification and execution are typically written into the smart contract(s) underlying the DAO. Anybody In DAOs with on-chain voting, anybody can invoke the relevant smart contract function to certify a referendum. The function, upon invocation, checks if the referendum meets the (pre-defined) vote aggregation rules (§III-C1), and if it does, certifies the proposal for execution. Once complete, the certification procedure typically moves the proposal to a Timelock contract [14], where it is actually executed. We find that all DAOs with on-chain voting allow anybody to call the function to certify and execute the referendum. Since on-chain mechanisms (i.e., voting, certification, and execution) take place without any intermediaries, DAOs using on-chain mechanisms typically add an Execution Delay, a period between certification and execution. The Execution Delay allows users who are unhappy with the proposal to divest themselves of their stake in the protocol, before the proposal (eventually) executes. Note that proposals can be certified but not executed, as proposals can be cancelled until they are executed (e.g. due to unexpected change in financial markets). 9 proposals in AAVE have been cancelled, for instance, after certification [78]. Centralized Certifier and Executor Some DAOs allow only some “trusted” authority to certify and execute a referendum. As we covered in §III-B3 all off-chain voting DAOs, by design, require a trusted entity to certify and execute a passed referendum on-chain. This trusted entity often takes the form of a multi-signature (or multi-sig) wallet, with the signatories typically being the “well-known” stakeholders of the DAO. Since only the trusted entity can certify and execute proposals, it can essentially cancel any proposal (even ones that passed) by simply not certifying and executing the proposal. SuperRare holds elections to regularly elect signatories to their multi-signature wallet. In all off-chain voting DAOs (except CowSwap and SuperRare), the certification and execution of a referendum are carried out in a single transaction. While DAOs using on-chain voting can assign this privilege to any wallet address, they do not do so in practice: Only one DAO with on-chain voting, Nexus Mutual, has a certification authority. Optimistic certification One approach to rid of the centralization concerns introduced by the need for a trusted entity in off-chain voting DAOs is optimistic certification. In this mechanism, anybody can assert the correctness of off-chain voting results. If this assertion is challenged, then a court

examines the voting and rules on the outcome. Assertions and challenges are backed by collateral, and the losing part forfeits their collateral. While the court could constitute any DAO user, they are composed of token holders of the protocol that developed the Optimistic Certification. This approach obviates the need for a trusted entity for certification, and Kleros [79] and Optimistic Snap (oSnap) [80] are two examples. oSnap was proposed by Universal Market Access (UMA) [81] and is used by Cow Protocol and Superrare [82], [83]. Trust and Transparency trade-offs Since DAOs with offchain voting require a trusted party for executing proposals on-chain, we observe that almost all off-chain voting protocols use a multi-sig wallet for certification and execution. Although optimistic certification counters centralization of decision-making power, its reliance on stakeholders of a different protocol to settle a dispute has crucial implications for their autonomy. Rather than relying on a centralized multi-sig wallet belonging to the members of the DAO, the certification privilege is accorded to stakeholders of a different protocol; the rationale behind the approach is that there is little overlap between the two protocols and the stakeholders of the other protocol will rationally determine the certification of the referendum. In contrast, on-chain voting protocols allow anybody to certify and execute, since they rely on smart contracts for these functionalities; the smart contract checks if the proposal meets the requirements, and, if it does, it certifies and then executes the proposal. This provides a higher level of decentralization and autonomy in decision making, since the rules for governance are clearly written in code and will be executed based on the pre-defined rules. However, such DAOs have a larger attack surface in regards to security [63], because even malicious proposals will be executed if it adheres to the rules. Execution Delays protect users of a protocol from the DAO, which governs the protocol. Since DAOs can make arbitrary changes to the existing protocol, the delay allows users, who disagree with the change, to remove their assets from the protocol before the proposal is executed. However, we find that 9 DAOs with on-chain voting have no execution delays, allowing proposals to be executed immediately after it has passed, making users of the protocol susceptible to an attack from the DAO. The remaining onchain DAOs have an execution delay of at least 1 day with a maximum delay of 3 days. Superrare also requires a KYC for candidates in order to stand up for election to become signatories of their multi-sig wallet [84]. Given a multi-sig wallet’s importance in the DAO, a KYC allows DAOs to prosecute signatories that do malicious actions. D. Veto A vetoer has the authority to veto or cancel referendums before they are executed. Since it takes a long time for a proposal to be executed (from the time it was initiated), changes in market conditions during this time may necessitate canceling a

Trust and Transparency trade-offs Veto power is crucial for DAOs with on-chain voting, where referendums, unless vetoed, are automatically executed. DAOs with off-chain voting typically do not need an explicit vetoer: Since the execution relies on a trusted entity, that entity can veto a proposal by simply not executing it. On-chain voting DAOs in fact need veto mechanisms, especially because they allow anybody to certify and execute a referendum (§ III-C2). Such mechanism prevents two important vulnerabilities. Firstly, there can be a faulty proposal, which could be executed if the bug is discovered after the vote has passed. Secondly, a malicious user can potentially buy a large amount of governance tokens, initiate malicious proposals, vote and then immediately sell their governance tokens, facing little to no economic downside. If the governance contract does not allow for any kind of veto, such referendums must be defeated every time at the cost of voters. While a veto authority protects the DAO against malicious proposals, it also centralizes the DAO, since any arbitrary proposal can be cancelled. Venus, for example, had a majority of registered votes in favor of the proposal to gain control of the DAO’s treasury [85]. However, this proposal was canceled by the DAO’s vetoer. As a result, the DAO’s treasury remained intact, although the choice of the majority (of votes) was rejected. There are numerous examples of DAOs assigning vetoer roles in response to or anticipation of a potential attack [86]–[89]. Giving the referendum initiator veto power may seem harmless, but it allows them to cancel a proposal arbitrarily, forcing others to re-propose and revote, wasting time and money. IV. C ASE S TUDIES : G OVERNANCE ATTACKS Thus far, we identified the key governance mechanisms and the trust assumptions inherent in every design choice. Below,

700000 600000

Total Votes

proposal, since the stakeholders might vote differently now (on the same proposal) given the changes. In our study, 38 DAOs allow for canceling a referendum after it has been proposed. Referendum Initiator Some DAOs allow the referendum initiator to cancel the referendum; logically, it is an easily defensible design choice. A referendum initiated by a stakeholder with sufficient voting power but little technical expertise may include bugs in the implementation. If the initiator vetoes the proposal, but the DAO is still interested in the change brought about by the referendum, another stakeholder (perhaps with relatively more technical expertise) may fix the bugs and re-initiate the proposal. Generally, anybody can cancel a proposal if the initiator’s voting power falls below the proposal threshold §III-A1. In our study, 9 DAOs with on-chain voting assign veto power to the referendum initiator. Veto Authority Some protocols bestow the vetoing power to a specific wallet address, which typically is a multi-sig wallet. The rationale behind such a design is to assign explicitly a stakeholder or entity that is responsible for canceling potentially malicious or faulty proposals. In our study, 11 on-chain protocols assign veto power to a veto authority.

500000

Yes Votes No Votes

400000 300000 200000 100000 0 Voting Begins

Day1

Day2

Voting Ends

Fig. 3: Voting Tally of the malicious proposal in Compound. We see that the number of votes in favor sharply increases shortly before the end of the voting period. we review real-world attacks on governance and identify feasible strategies to prevent them. A. Identifying Governance Attacks Feichtinger et al. analyzes attacks on DAOs and identifies 28 incidents [63]. Of these incidents, we label 16 as Governance Attacks, based on the determination that a change in the governance mechanism would have prevented the attack. The rest resulted from of poor design of the underlying DeFi protocol (e.g., protocol vulnerability), lack of due diligence from the DAO (e.g., spam attack or proposal obfuscation), or could not be eliminated in any governance framework (e.g., bribing and vote buying). 6 out of the 16 governance attacks resulted from a bug in the governance contract and 10 were token acquisition attacks. Of the 10 token acquisition attacks, 5 attacks failed. In each case, a trusted entities could veto or refuse to certify proposals, which highlights the dire need for oversight in a DAO to protect it against malicious proposals. One successful attack (Yuan Finance [90]) even had a vetoer, which did not cancel the malicious proposal. Hence, vetoers must be aware of all ongoing referendums and identify malicious ones before they execute. B. Compound DAO attack We now review the security vulnerabilities that were exploited in an attack on the Compound governance protocol in July 2024. Compound had three flaws that were exploited. Vote Buying In Compound, an entity can simply buy a large amount of tokens and immediately receive voting power. In total, there were in total 29 malicious wallet addresses that purchased a large amount of governance tokens in the previous 4 months [91]. 563,790 tokens were transferred to these addresses through four CEXes Centralized Exchanges (CEXes)—292,570 tokens through KuCoin [92], 230,335 through ByBit [93], 33,992 through HTX [94] and 4,391 through OKX [95]. A further 118,089 tokens were borrowed through the Compound Protocol. Although the attackers held over 680,000 tokens, in the governance forums, the attacker’s expected holding was suspected to be around 325,000 [96]. Voter Apathy and Vote Sniping There were three malicious referendums in total with less votes cast against in each subsequent proposal [91], [97], [98]. Since, the first two referendums failed, voters likely expected the third referendum to fail as well, and did not bother to vote against the proposal. 563,591 votes out of 682,191 (82% of votes for) was cast

within 170 blocks (or 34 minutes) before the end of the voting period, with the final vote being cast 40 blocks (or 8 minutes) before the end of the voting period [91] (as per Figure 3). This suddenly changed the fate of the referendum to pass. This is also known as vote sniping. The referendum narrowly passed by less than 50,000 votes. If measures mentioned in §III-B were taken, such as only allowing votes against a proposal at the end of the voting period, or extending the voting period if quorum was reached late, this attack would likely have failed, since it would have allowed other voters to react. Lack of oversight There was no established oversight, such as a vetoer. Due to the clear vote sniping that took place coupled with the strong dislike of the proposal within the Compound Governance Forums [96], [99], a vetoer would have been justified in cancelling such a proposal. Furthermore, having a vetoer would have disincentivized the attackers to even initiate such a referendum. In fact, as a result of the attack, Compound governance passed a referendum to assign a vetoer to circumvent such future attacks [88]. C. On the Generality of Vulnerabilities The vulnerabilities that were exploited in recent governance attacks [63], [96] still exist across many of the DAOs in our study. Since a large number of governance tokens can be easily bought in public markets, these design choices make DAOs susceptible to governance attacks via vote buying. At the same time, we observe that excluding 4 DAOs—Lido, Frax, Origin, Angle—all DAOs use governance contracts that do not prevent vote sniping. Besides, 15 DAOs in our study do not have any oversight (e.g. certifier, vetoer) to prevent malicious referendums. Even worse, we find 7 DAOs—Uniswap, Radicle, Gitcoin, Silo, Ampleforth, Hop, and Cryptex— vulnerable to a similar governance attack since their design choices have all the three inherent flaws that we discussed above. V. R ELATED WORK Regular updates are essential to meet the evolving needs of decentralized blockchain protocols. Consensus among stakeholders is crucial for these changes, and is often achieved through social norms rather than formal voting. For example, Bitcoin and Ethereum use Bitcoin Improvement Proposals (BIPs) and Ethereum Improvement Proposals (EIPs), respectively, where users, developers and researchers engage in community discussions to determine if a proposal gains enough support for the core developers to implement [100], [101]. However, deep divisions can cause a blockchain to split, reducing its value and security, such as Bitcoin being split into Bitcoin and Bitcoin Cash [102], [103]; and Ethereum into Ethereum and Ethereum Classic [104], [105]. Fracassi et al. showed that EIP proposals and implementations of these proposals are highly centralized [106]. In a separate paradigm, the governance of blockchain systems has been described to be analogous to social contract theory [107] or even corporate governance [108], where consensus is achieved through formal voting. Filippi and Mcmullen [109] highlight two types of governance in blockchain

systems based on where they are operationalized: on-chain and off-chain governance. On-chain governance has fixed, enforceable rules but struggles with unexpected situations, while off-chain governance is flexible and adaptable but harder to enforce. This study focuses on formal voting procedures in DAOs, examining design choices of governance contracts and their implications for decentralization, autonomy, and security. Although DAOs are intended to be decentralized and autonomous, prior work shows significant deviations from these ideals. Recent studies showed that voting power in DeFi projects is very centralized, questioning whether the protocols are truly decentralized [71], [110]–[112]. Sharma et al. studied how 10 DAOs work in practice, and looked at their degrees of decentralization and autonomy [66]. Kiayias and Lazos derived seven fundamental properties of blockchain governance from 10 widely used blockchain platforms, finding that all of them have some deficiency in their governance [113]. Feichtilinger et al. also did an extensive survey on governance attacks on DAOs, and classified each attack along different dimensions [63]. The work highlights the different ways that DAOs can potentially fail, ranging from buggy smart contracts to social engineering. Despite focusing on smart contract bugs and DAO attacks, these works largely overlook how governance contract design choices contribute to various risks. We address this gap by showing how fundamental design decisions lead to centralization and security vulnerabilities across multiple dimensions. Most relevant to this work, Tan et al. posed several open problems relevant to DAOs from various perspectives (e.g. computer science, economics, law) [114]. While the work identifies several unsolved problems, they overlook DAO governance in practice, the various design decisions and their trade-offs. Introducing a new measure for centralization of DAOs, Austgen et al. highlights the impact of voter apathy, delegation, and other factors [64]. While they focus mainly on distribution of voting power, our work takes a holistic view of DAO governance, examining how a DAO’s governance contract has implications on how governance is exercised. In our extensive study of 48 DAOs, by breaking DAO governance into granular components, we uncover design trade-offs, and offer actionable insights for researchers and practitioners for better realization of DAOs. VI. C ONCLUDING R EMARKS In realizing a DAO, numerous design choices must be made, each of which must balance complex trade-offs between efficiency, security, and fairness (or the decentralized nature) of the DAO. The introduction of a vetoer, for instance, improves security but at the cost of eroding decentralization; off-chain voting encourages participation, but requires a centralized party for executing the vote. In this work, we investigated how these fundamental design “knobs” affect various security, fairness, and performance considerations, and we presented an examination of the DAOs “in theory.” Said differently, while prior work [63] looked at vulnerabilities that arise in the implementation of these knobs, our work presents the

fundamental trade-offs inherent in the design. We also discover governance attacks, a distinct class of vulnerabilities, that exploit the governance mechanisms of DAOs, regardless of their implementations. R EFERENCES [1] H. Adams, N. Zinsmeister, M. Salem, R. Keefer, and D. Robinson, “Uniswap v3 core,” 2021. [2] P. Daian, S. Goldfeder, T. Kell, Y. Li, X. Zhao, I. Bentov, L. Breidenbach, and A. Juels, “Flash boys 2.0: Frontrunning in decentralized exchanges, miner extractable value, and consensus instability,” in 2020 IEEE Symposium on Security and Privacy (SP), 2020. [3] K. Qin, L. Zhou, B. Livshits, and A. Gervais, “Attacking the DeFi Ecosystem with Flash Loans for Fun and Profit,” in Financial Cryptography and Data Security, ser. FC ’21, 2021. [4] D. Perez, S. M. Werner, J. Xu, and B. Livshits, “Liquidations: Defi on a knife-edge,” in Financial Cryptography and Data Security, ser. FC ’21, 2021. [5] DefiLlama, https://defillama.com, 2024, accessed on May 15, 2024. [6] DeepDAO, https://deepdao.io, 2024, accessed on May 15, 2024. [7] Uniswap Labs, “Governance – Uniswap Protocol,” https://uniswap.org/ governance, 2023, accessed on April 2, 2023. [8] ENS, “Ens docs,” https://docs.ens.domains/dao, 2024, accessed on May 15, 2024. [9] MakerDAO, “Governance Module – Maker Protocol Technical Docs,” https://docs.makerdao.com/smart-contract-modules/governancemodule, 2023, accessed on April 2, 2023. [10] Lido, “Active motions,” https://easytrack.lido.fi, 2024, accessed on May 15, 2024. [11] ——, “Lido governance process,” https://lido.fi/governance, 2024, accessed on May 15, 2024. [12] Frax Finance, “Frax governance overview,” https://docs.frax.finance/ frax-governance/frax-governance-overview, 2024, accessed on May 15, 2024. [13] AAVE, “AAVE Economics – Governance,” https://docs.aave.com/ aavenomics/governance, 2023, accessed on May 25, 2023. [14] Compound Labs, Inc., “Compound Governance,” https: //docs.compound.finance/governance, 2022, accessed on Dec 10, 2022. [15] Radicle, “How we work,” https://docs.radworks.org/community/ ecosystem, 2024, accessed on May 15, 2024. [16] 0x Protocol, “0x protocol governance,” https://governance.0xprotocol. org, 2024, accessed on May 15, 2024. [17] Gitcoin, “Gitcoin,” https://www.gitcoin.co, 2023, accessed on May 15, 2024. [18] Silo Finance, “Governance,” https://silopedia.silo.finance/silodao/ governance, 2024, accessed on May 15, 2024. [19] Lyra, “Governance,” https://docs.lyra.finance/docs/governance, 2024, accessed on May 15, 2024. [20] API3, “Contracts,” https://docs.api3.org/reference/dao-members, 2024, accessed on May 15, 2024. [21] Ampleforth, “About forth governance,” https://docs.ampleforth.org/ learn/about-forth-governance, 2024, accessed on May 15, 2024. [22] Instadapp, “Voting and governance,” https://guides.instadapp.io/ governance/voting-and-governance, 2024, accessed on May 15, 2024. [23] Rari Foundation, “Governance,” https://rari-foundation.gitbook.io/raridao-knowledge-base/governance, 2024, accessed on May 15, 2024. [24] Nouns, “Welcome to Nouns Center,” https://nouns.center, 2024, accessed on May 15, 2024. [25] Curve, “Curve DAO: Protocol Ownership,” https://curve.readthedocs. io/dao-ownership.html, 2024, accessed on May 15, 2024. [26] Origin DeFi, “Origin DeFi Docs,” https://docs.oeth.com/governance/ overview, 2024, accessed on May 15, 2024. [27] Hop, “Into to Hop DAO,” https://docs.hop.exchange/governance/intoto-hop-dao, 2024, accessed on May 15, 2024. [28] Cryptex Finance, “Reference,” https://docs.cryptex.finance/governance/ reference, 2024, accessed on May 15, 2024. [29] Angle Protocol, https://docs.angle.money/governance/angle-dao, 2024, accessed on May 15, 2024. [30] DxDao, https://dxdocs.eth.limo/docs/Governance, 2024, accessed on May 15, 2024.

[31] Nexus Mutual, https://docs.nexusmutual.io, 2024, accessed on May 15, 2024. [32] Goldfinch Finance, “Governance,” https://docs.goldfinch.finance/ goldfinch/governance, 2024, accessed on May 15, 2024. [33] ParagonsDAO, https://docs.paragonsdao.com/docs/dao/governanceframework, 2024, accessed on May 15, 2024. [34] Illuvium, https://illuvium.io/governance, 2024, accessed on May 15, 2024. [35] SuperRare, “The SuperRare DAO,” https://docs.superrare.com/ whitepapers/master/the-superrare-dao, 2024, accessed on May 15, 2024. [36] Mantle, “Governance,” https://docs.mantle.xyz/governance/parameters/ governance, 2024, accessed on May 15, 2024. [37] ResearchHub, “ResearchHub Docs,” https://docs.researchhub.com, 2024, accessed on May 15, 2024. [38] Stargate Finance, “User Docs,” https://stargateprotocol.gitbook.io/ stargate/v/user-docs, 2024, accessed on May 15, 2024. [39] Uma Project, “UMA Protocol,” https://docs.uma.xyz, 2024, accessed on May 15, 2024. [40] Cow Protocol, “Governance,” https://docs.cow.fi/governance, 2024, accessed on May 15, 2024. [41] Sturdy Finance, https://docs.sturdy.finance/sturdy-dao/governance, 2024, accessed on May 15, 2024. [42] Euler Finance, https://gov.euler.finance, 2024, accessed on May 15, 2024. [43] SAFE, https://safe-global.notion.site/Introduction-to-SafeDAO07f87ad6c9bf456ca5d349e72e85bf3f, 2024, accessed on May 15, 2024. [44] Tokenlon, https://support.tokenlon.im/hc/en-us/sections/ 360011548392-Governance, 2024, accessed on May 15, 2024. [45] Botto, “Governance,” https://docs.botto.com/details/governance, 2024, accessed on May 15, 2024. [46] Balancer, “Governance,” https://docs.balancer.fi/concepts/governance, 2024, accessed on May 15, 2024. [47] Sushiswap, “Current governance model,” https://docs.sushi.com/docs/ Governance/Current%20Governance%20Model, 2024, accessed on May 15, 2024. [48] Gearbox, https://docs.gearbox.finance/governance/setup, 2024, accessed on May 15, 2024. [49] Paraswap, https://doc.paraswap.network/dao-and-governance/daosmission, 2024, accessed on May 15, 2024. [50] Alchemix Finance, https://alchemix-finance.gitbook.io/user-docs/ alchemix-dao/community-governance-process, 2024, accessed on May 15, 2024. [51] 1inch, https://docs.1inch.io/docs/governance/overview, 2024, accessed on May 15, 2024. [52] Shutter DAO 0x36, https://shutter.network/dao, 2024, accessed on May 15, 2024. [53] Yearn Finance, https://docs.yearn.fi/contributing/governance/ governance-and-operations, 2024, accessed on May 15, 2024. [54] ShapeShift, https://shapeshift.notion.site/FOX-Governance-Processe5e999c1f23c4127aeeea1494621c226, 2024, accessed on May 15, 2024. [55] Decentraland, “What is the dao,” https://docs.decentraland.org/player/ general/dao/overview/what-is-the-dao, 2024, accessed on May 15, 2024. [56] Graph Foundation, “The Graph Council,” https://docs.thegraph. academy/the-graph-ecosystem/organizational-structure/the-graphcouncil, 2024, accessed on May 15, 2024. [57] S. Labs, “Snapshot,” https://snapshot.org, 2023, accessed on February 2, 2023. [58] ——, “Snapshot,” https://docs.snapshot.org/tools/api, 2023, accessed on August 2, 2023. [59] California Secretary of State, “Crypto rug pulls: What are they and how to avoid them,” https://www.sos.ca.gov/elections/ballot-measures/ how-qualify-initiative, accessed on 1 June, 2024. [60] Institute for Government, “Calling a general election,” https://www. instituteforgovernment.org.uk/explainer/calling-general-election, 2024, accessed on 1 June, 2024. [61] DxDao, https://dxvote.eth.limo/#/mainnet/info?view=governance, accessed on 1 June, 2024. [62] MakerDAO, “Facilitatordaos,” https://endgame.makerdao.com/subdaos/ types/facilitator, 2023, accessed on May 15, 2024.

[63] R. Feichtinger, R. Fritsch, L. Heimbach, Y. Vonlanthen, and R. Wattenhofer, “SoK: Attacks on DAOs,” in 6th Conference on Advances in Financial Technologies (AFT 2024), 2024. [64] J. Austgen, A. Fábrega, S. Allen, K. Babel, M. Kelkar, and A. Juels, “Dao decentralization: Voting-bloc entropy, bribery, and dark daos,” arXiv preprint arXiv:2311.03530, 2023. [65] Shutter, https://blog.shutter.network/shielded-voting, 2024, accessed on August 1, 2024. [66] T. Sharma, Y. Kwon, K. Pongmala, H. Wang, A. Miller, D. Song, and Y. Wang, “Unpacking how decentralized autonomous organizations (daos) work in practice,” 2023. [67] R. Giustolisi, M. S. Garjan, and C. Schuermann, “Thwarting last-minute voter coercion,” Cryptology ePrint Archive, Paper 2023/1876, 2023, https://eprint.iacr.org/2023/1876. [Online]. Available: https://eprint.iacr.org/2023/1876 [68] L.-H. Merino, A. Azhir, H. Zhang, S. Colombo, B. Tellenbach, V. Estrada-Galiñanes, and B. Ford, “E-vote your conscience: Perceptions of coercion and vote buying, and the usability of fake credentials in online voting,” 2024. [69] P. Labs, “Ipfs powers the distributed web,” https://ipfs.tech, 2023, accessed on February 2, 2023. [70] Lucas Tcheyan, “Governance in DeFi,” https://www.galaxy.com/ insights/research/governance-in-defi, 2024, accessed on May 15, 2024. [71] J. Messias, V. Pahari, B. Chandrasekaran, K. P. Gummadi, and P. Loiseau, “Understanding blockchain governance: Analyzing decentralized voting to amend defi smart contracts,” 2024. [72] A. Zamyatin, M. Al-Bassam, D. Zindros, E. Kokoris-Kogias, P. Moreno-Sanchez, A. Kiayias, and W. J. Knottenbelt, “Sok: Communication across distributed ledgers,” in Financial Cryptography and Data Security, N. Borisov and C. Diaz, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2021, pp. 3–36. [73] United States Senate, “About Voting,” https://www.senate.gov/about/ powers-procedures/voting.htm, 2024, accessed on May 15, 2024. [74] J. Levin and B. Nalebuff, “An introduction to vote-counting schemes,” Journal of Economic Perspectives, vol. 9, no. 1, p. 3–26, March 1995. [Online]. Available: https://www.aeaweb.org/articles?id= 10.1257/jep.9.1.3 [75] Q. Wang, G. Yu, Y. Sai, C. Sun, L. Nguyen, S. Xu, and S. Chen, “An empirical study on snapshot daos,” 11 2022. [76] psybull, “An explanation of continuous voting and the peculiarities of the 7/26 executive stability fee vote,” https://forum.makerdao.com/t/an-explanation-of-continuous-votingand-the-peculiarities-of-the-7-26-executive-stability-fee-vote/193, accessed on 1 June, 2024. [77] U.S. Embassy and Consulates in Brazil, “U.s. congress certifies the electoral college vote,” https://br.usembassy.gov/u-s-congress-certifiesthe-electoral-college-vote, accessed on 1 June, 2024. [78] “Chaos labs risk parameter updates - crv aave v2 ethereum,” https: //www.tally.xyz/gov/aave/proposal/280, 2024, accessed on August 1, 2024. [79] Kleros, https://github.com/kleros/kleros/blob/master/contracts/kleros/ KlerosGovernor.sol, 2024, accessed on 1 June, 2024. [80] Uma Project, “Announcing “oSnap:” Gasless Snapshot voting with on-chain execution by UMA,” https://medium.com/uma-project/ announcing-osnap-gasless-snapshot-voting-with-on-chain-executionby-uma-7374ed729b28, 2024, accessed on May 15, 2024. [81] UMA, https://docs.uma.xyz/developers/osnap, 2024, accessed on August 1, 2024. [82] ——, “Cow dao integrates osnap for decentralized governance,” https:// cow.fi/learn/cow-dao-integrates-o-snap-for-decentralized-governance, 2024, accessed on August 1, 2024. [83] SuperRare, https://snapshot.org/#/superraredao.eth /proposal/0x9223e· · · 66383, 2024, accessed on May 15, 2024. [84] ——, https://snapshot.org/#/superraredao.eth/ proposal/0x1422c· · · a8e8a, 2024, accessed on May 15, 2024. [85] Rikta Mandal, “Venus protocol prevented hostile takeover attempt,” https://www.cryptotimes.io/2021/09/18/venus-protocol-preventedhostile-takeover-attempt, accessed on 15 August, 2024. [86] ENS, “[Temp Check] Enable CANCEL role on the DAO,” https://discuss.ens.domains/t/temp-check-enable-cancel-role-onthe-dao/19090, 2024, accessed on May 15, 2024. [87] alextnetto.eth, “[ep5.13][executable] security council,” https://discuss. ens.domains/t/introducing-veto-ensdao-eth/19088/5, 2024, accessed on August 1, 2024.

[88] “Add proposal guardian to governor bravo,” https://compound.finance/ governance/proposals/304, accessed on 15 August, 2024. [89] The Block, “Indexed DAO to distribute remaining treasury after defeating hijack attempts,” https://www.theblock.co/post/264679/indexeddao-to-distribute-remaining-treasury-after-defeating-hijack-attempts, 2024, accessed on May 15, 2024. [90] Yuan Finance, “Yuan governance attack update and migration plan,” https://medium.com/yuan-finance/yuan-governance-attackupdate-and-migration-plan-3b5d949ab466, accessed on 1 June, 2024. [91] “Trust setup for dao investment into goldcomp,” https://compound. finance/governance/proposals/289, accessed on 15 August, 2024. [92] KuCoin, https://www.kucoin.com, 2024, accessed on 1 June, 2024. [93] ByBit, https://www.bybit.com/en, 2024, accessed on 1 June, 2024. [94] HTX, https://www.htx.com, 2024, accessed on 1 June, 2024. [95] OKX, https://www.okx.com, 2024, accessed on 1 June, 2024. [96] cylon, “Governance security notice: goldcomp proposal 247,” https://www.comp.xyz/t/governance-security-notice-goldcompproposal-247/5220/1, accessed on 1 June, 2024. [97] “Treasury to invest 5 [98] “Trust setup for dao investment into goldcomp,” https://compound. finance/governance/proposals/279, accessed on 15 August, 2024. [99] C. Labs, “Compound community forum,” https://www.comp.xyz, 2024, accessed on May 7, 2024. [100] “Bitcoin Improvement Proposals,” https://github.com/bitcoin/bips, accessed on January, 2025. [101] “Ethereum Improvement Proposals,” https://eips.ethereum.org/, accessed on January, 2025. [102] T. Verge, “The one true bitcoin,” https://www.theverge.com/2018/4/12/ 17229796/bitcoin-cash-conflict-transactions-fight, 2018, accessed on May 12, 2024. [103] CoinDesk, “Segwit goes live: Why bitcoin’s big upgrade is a blockchain game-changer,” https://www.coindesk.com/markets/2017/ 08/23/segwit-goes-live-why-bitcoins-big-upgrade-is-a-blockchaingame-changer, 2017, accessed on May 12, 2024. [104] L. Kiffer, D. Levin, and A. Mislove, “Stick a fork in it: Analyzing the ethereum network partition,” in Proceedings of the 16th ACM Workshop on Hot Topics in Networks, ser. HotNets ’17. New York, NY, USA: Association for Computing Machinery, 2017, p. 94–100. [Online]. Available: https://doi.org/10.1145/3152434.3152449 [105] CoinDesk, “Coindesk turns 10: 2016 - how the dao hack changed ethereum and crypto,” https://www.coindesk.com/consensus-magazine/ 2023/05/09/coindesk-turns-10-how-the-dao-hack-changed-ethereumand-crypto, 2023, accessed on May 12, 2024. [106] C. Fracassi, M. Khoja, and F. Schär, “Decentralized crypto governance? transparency and concentration in ethereum decision-making,” 2024. [107] W. Reijers, F. O’Brolcháin, and P. Haynes, “Governance in blockchain technologies & social contract theories,” Ledger, vol. 1, 2016. [108] D. Allen and C. Berg, “Blockchain governance: What we can learn from the economics of corporate governance,” SSRN Electronic Journal, 01 2020. [109] P. de Filippi and G. Mcmullen, “Governance of blockchain systems: Governance of and by Distributed Infrastructure,” Blockchain Research Institute and COALA, Research Report, 2018. [Online]. Available: https://hal.science/hal-02046787 [110] R. Fritsch, M. Müller, and R. Wattenhofer, “Analyzing voting power in decentralized governance: Who controls daos?” 2022. [111] R. Feichtinger, R. Fritsch, Y. Vonlanthen, and R. Wattenhofer, “The hidden shortcomings of (d)aos – an empirical study of on-chain governance,” 2023. [112] S. Kitzler, S. Balietti, P. Saggese, B. Haslhofer, and M. Strohmaier, “The governance of decentralized autonomous organizations: A study of contributors’ influence, networks, and shifts in voting power,” 2023. [113] A. Kiayias and P. Lazos, “Sok: Blockchain governance,” 2023. [114] J. Z. Tan, T. Merk, S. Hubbard, E. R. Oak, J. Pirovich, E. Rennie, R. Hoefer, M. Zargham, J. Potts, C. Berg et al., “Open problems in daos,” arXiv preprint arXiv:2310.19201, 2023. [115] https://etherscan.io/address/0x36cc7· · · 2ffc6, accessed on 15 August, 2024. [116] https://etherscan.io/address/0x941dc· · · EB1C2, accessed on 15 August, 2024. [117] “Precautionary transfer of timelock admin,” https://compound.finance/ governance/proposals/290, accessed on 15 August, 2024.

[118] bryancolligan, “[alphagrowth] stake compound product,” https://www. comp.xyz/t/alphagrowth-stake-compound-product/5478, accessed on 15 August, 2024.

A PPENDIX A. Compound Case study Attack Timeline On May 6th, 2024, a proposal was put forth by Humpy [115], a known DeFi whale, in the Compound DAO, Prop. #247 [97], which transferred 92,000 COMP tokens to the a Multisig wallet (called GOLD Multisig) [116]. This proposal was rejected with 710,978 voting against and only 95,865 votes for (Humpy was the only large voter to vote for the proposal). On July 15th, a proposal, Prop. #279 [98], was put forth by Humpy again, where the 92,000 COMP tokens are transferred to a goldCOMP smart contract. The proposal was again flagged on the Governance Forum [96]. The goldCOMP smart contract is controlled by the same Multisig, and this was seen by the Compound community as an attack on Governance. This proposal was rejected by the users again with 578,664 voting against and 118,530 voting for. On July 24, 2024, a proposal was put forth in the Compound DAO transferring 499,000 COMP tokens to goldCOMP smart contract (Prop. #289) [91]. This was a significantly large amount of tokens than the previous 2 proposals. The proposal was again flagged on the Governance Forum. However, this proposal passed narrowly with 682,191 voting for and 633,636 voting against. COMP Tokens

700000

Holding Registered

600000 500000 400000 300000 200000 100000 0

ri Ap

l

y 7 Map 24 Pro

e Jun

Date

y Jul

79 89 p 2 op 2 Pro Pr

Fig. 4: Voting Tally of the malicious proposal in Compound. We see that the number of votes in favor sharply increases shortly before the end of the voting period. Voting Anomalies. There are anomalies in the voting pattern and voters of Prop. #289. Firstly, 563,591 votes out of 682,191 (82% of votes for) was cast within 170 blocks (or 34 minutes) before the end of the voting period. The final vote was cast 40 blocks (or 8 minutes) before the end of the voting period. This clearly constitutes vote sniping and, does not allow other voters to respond to the change in the outcome of the vote. Furthermore, some voters might not have voted because of the cost to voting and the proposal was already headed towards their wanted outcome. Since, the previous proposal (Prop. #279) ended with only 118,530 votes for, users might have not have voted on this proposal because they incorrectly assumed that more votes would not be cast. Analyzing the voters that voted for Prop. #289, we identified 29 addresses in total that either voted or were delegators. On March 29, 2024, we see the first significant transfer of COMP tokens to the Humpy address. Before this period, the total amount of COMP tokens held in

these addresses was 853 COMP tokens. In the next 4 month, i.e. until late July, they accumulated a total of 682,181 COMP tokens. Before this period, none of these addresses had ever participated in Compound governance, and had no delegated votes. There were two sources through which the addresses accumulated COMP tokens. The first is through the Compound Protocol, where Humpy borrowed 118,089 COMP tokens. The second is through Centralized Exchanges. There were a total of 292,570 COMP tokens transferred through KuCoin [92], 230,335 COMP tokens transferred through ByBit [93], and 33,992 COMP tokens through HTX [94] and 4,391 COMP tokens transferred through OKX [95]. This accounts for 563,790 COMP tokens in total transferred to these addresses through four centralized exchanges. Furthermore, all addresses (except for Humpy who voted on Prop. #277, #287, # 288), voted only on Prop. #289. Aftermath and Solution In response to the attack, a proposal was put forth to transfer the admin of the Timelock to a MultiSignature Wallet, thereby giving the wallet the right to propose and pass any referendum [117]. However, the malicious proposal itself could not be stopped from being certified or executed, since the Compound did not have any certifiers or vetoers. In light of this, a compromise was reached with the Compound DAO, where both proposals would be canceled. In return, Compound would roll out a staking program, where Compound token holder can stake their tokens in order to receive a portion of the profits made by the protocol [118]. Furthermore, on August 10th (Prop. #304) [88], a proposal was put forward to add a vetoer, which is able to cancel malicious proposals that have passed and are awaiting execution. The proposal passed with 1,398,783 votes for and no votes against.1 This again highlights the fundamental problem of balancing decentralization with checks and balances within a DAO. The fundamental problem with the Compound DAO was that there were no gatekeepers to oversee and interject when there are potentially malicious activities. Hence, this is remedied this by adding a vetoer. Even though gatekeepers centralize the decision making process in a DAO, they provide an important check against malicious proposals. 7 DAOs are susceptible to a similar attack as was carried out on Compound : Uniswap, Radicle, Gitcoin, Silo, Ampleforth, Hop, Cryptex. Each DAO uses Token Holding, and has a large amount of governance tokens available to be bought in public markets (e.g. CEX, DEX). They also lack any mechanism to prevent vote sniping, and lacks any oversight such as a vetoer. B. On-chain Contract Addresses In this section, we present the list of all relevant contract addresses that were analyzed in our study, as presented in Table II. This list includes contract addresses obtained from both the Ethereum blockchain, which contains contracts deployed on-chain, and the Snapshot platform, which is used for governance contracts that employ off-chain voting mechanisms.

1 None of the addresses associated with the attack voted on this proposal.

TABLE II: On-chain and snapshot addresses Protocol

On-chain Address

Off-chain space

Optimism Arbitrum

0xcDF27F107725988f2261Ce2256bDfCdE8B382B10 (on Optimisim) 0xf07DeD9dC292157749B6Fd268E37DF6EA38395B9 (Core) 0x789fC99093B09aD01C34DC7251D0C89ce743e5a4 (Treasury) (On Arbitrum) 0x408ED6354d4973f66138C91495F2f2FCbd8724C3 0x323A76393544d5ecca80cd6ef2A560C6a395b7E3 0x0a3f6849f78076aefaDf113F5BED87720274dDC0 0xF0211b7660680B49De1A7E9f25C65660F0a13Fea (Easy Track) 0x2e59A20f205bB85a89C53f1936454680651E618e (Governance) 0x953791D7C5ac8Ce5fb23BBBF88963DA37a95FE7a (Omega) 0xd74034C6109A23B6c7657144cAcBbBB82BDCB00E (Alpha) 0xEC568fffba86c094cf06b22134B23074DFE2252c 0xc0Da02939E1441F497fd74F78cE7Decb17B66529 0x690e775361AD66D1c4A25d89da9fCd639F5198eD 0x0bB1810061C2f5b2088054eE184E6C79e1591101 0x9D4C63565D5618310271bF3F3c01b2954C1D1639 0xA89163F7B2D68A8fbA6Ca36BEEd32Bd4f3EeAf61 0xe8642cc1249F08756e70Bb8eb4BE0e6c09254fed 0xDb6C812E439ce5c740570578681ea7aaDba5170b (Primary) 0x1c8058E72E4902B3431Ef057E8d9a58A73F26372 (Secondary) 0x05811Ad31cbD5905e4e1427482713E3fb04A4c05 (Old Voting) 0x8a994C6F55Be1fD2B4d0dc3B8f8F7D4E3a2dA8F1 0x0204Cd037B2ec03605CFdFe482D8e257C765fA1B 0x6552C8fb228f7776Fc0e4056AA217c139D4baDa1 0x6f3E6272A167e8AcCb32072d08E0957F9c79223d 0xE478de485ad2fe566d49342Cbd03E49ed7DB3356 (Ownership) 0xBCfF8B0b9419b9A88c44546519b1e909cF330399 (Parameter) 0x1D3Fbd4d129Ddd2372EA85c5Fa00b2682081c9EC (Current) 0x3cdD07c16614059e66344a7b579DAB4f9516C0b6 (Third version) 0x72426BA137DEC62657306b12B1E869d43FeC6eC7 (Second Version) 0x8a5fF78BFe0de04F5dc1B57d2e1095bE697Be76E (First Version) 0xed8bdb5895b8b7f9fdb3c087628fd8410e853d48 0x874C5D592AfC6803c3DD60d6442357879F196d5b 0x4A5C681dDC32acC6ccA51ac17e9d461e6be87900 0x78605Df79524164911C144801f41e9811B7DB73D 0x849D52316331967b6fF1198e5E32A0eB168D039d 0x860a80d33E85e97888F1f0C75c6e5BBD60b48DA9 0xDAEada3d210D2f45874724BeEa03C7d4BBD41674 0x5222FF25F4DFC02d173C2cbd2055EE1D35f291F1 (Treasury 1) 0xE3648e99B6E68A09e28428790D12B357f081dBe0 (Treasury 2) 0xC4cfa2BdAE08416312fAa0B72758E1F3750f81e3 (Treasury 3) 0x65bb797c2B9830d891D87288F029ed8dACc19705 0x7b292034084A41B9D441B71b6E3557Edd0463fa8 0x58C37A622cdf8aCe54d8b25c58223f61d0d738aA 0xcA771eda0c70aA7d053aB1B25004559B918FE662 0xBEb28978B2c755155f20fd3d09Cb37e300A6981f 0xfE6DE700427cc0f964aa6cE15dF2bB56C7eFDD60 0xcAD001c30E96765aC90307669d578219D4fb1DCe 0x1d4F25bC16b68C50B78E1040BC430a8097Fd6f45 0x51C2cEF9efa48e08557A361B52DB34061c025a1B 0x3557BD3d422300198719710Cc3f00194E1c20A46 0x35bb964878d7B6ddFA69cF0b97EE63fa3C9d9b49 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f 0x03a42D37066726FfDc8F2BCd1C422f72A1717882 0xE832C302D1160EAe57045eb9d9Ea14daBd2E229c (Optimism Election) 0xEb3107117FEAd7de89Cd14D463D340A2E6917769 (Protocol Dao) 0xe94B5EEC1fA96CEecbD33EF5Baa8d00E4493F4f3 0x7b065Fcb0760dF0CEA8CFd144e08554F3CeA73D1 0x5A61D9214adEFD7669428a03A4e8734A00E9F464 0xc977CBadD359aE06b236D9581e37fd5A03E54b84 0x8392F6669292fA56123F71949B52d883aE57e225 0x7951c7ef839e26F63DA87a42C9a87986507f1c07 0xdC4e6DFe07EFCa50a197DF15D9200883eF4Eb1c8 0x36bD3044ab68f600f6d3e081056F34f2a58432c4 0xFEB4acf3df3cDEA7399794D0869ef76A6EfAff52 0x90A48D5CF7343B08dA12E067680B4C6dbfE551Be 0x41E83d829459F99Bf4Ee2E26D0D79748Fb16b94F

x arbitrumfoundation.eth

Uniswap ENS Maker Lido Frax Finance AAVE Compound Radicle 0x Protocol Gitcoin Silo Finance Lyra API3 Ampleforth Instadapp Rari NounsDAO Curve Origin

Hop DAO Cryptex Nexus Mutual Mantle Gnosis SuperRare Aevo Research Hub Foundation Stargate Finance Uma Illuvium Cowswap Goldfinch Sturdy Finance Euler SAFE JPEG’d Tokenlon Botto Balancer Galxe Synthetix Sushiswap Gearbox Paraswap ParagonsDAO Alchemix 1Inch Angle Protocol Shutter DAO 0x36 Yearn Finance Shapeshift Decentraland

uniswapgovernance.eth ens.eth x lido-snapshot.eth frax.eth, fpis.eth aave.eth x gov.radworks.eth 0xgov.eth gitcoindao.eth silofinance.eth lyra.eth

ampleforthorg.eth instadapp-gov.eth x x x x

hop.eth cryptexdao.eth community.nexusmutual.eth bitdao.eth gnosis.eth superraredao.eth rbn.eth researchhub.eth stgdao.eth uma.eth ilvgov.eth, ilv.eth cow.eth goldfinch.eth sturdyfi.eth eulerdao.eth safe.eth jpeg’d.eth tokenlon.eth botto.eth balancer.eth gal.eth https://gov.synthetix.io/#/ sushigov.eth gearbox.eth paraswap-dao.eth paragonscouncil.eth, paragonsdao.eth alchemixstakers.eth 1inch.eth anglegovernance.eth shutterdao0x36.eth veyfi.eth shapeshiftdao.eth snapshot.dcl.eth