Building On-Chain DAOs: OpenZeppelin and Tally for Effective Development

Introduction

A Decentralized Autonomous Organization (DAO) is an innovative legal framework that operates without a centralized governing body. Instead, its members work together towards a shared objective, striving to act in the entity’s best interests. Initially popularized by cryptocurrency enthusiasts and propelled by the advancements in blockchain technology, DAOs revolutionize decision-making by adopting a grassroots management approach [1].

DAOs aim to eliminate the need for centralized authorities or intermediaries by leveraging blockchain technology and decentralized consensus mechanisms. All decisions are made collectively by its members through voting mechanisms, and the execution of those decisions is carried out automatically by the underlying smart contracts infrastructure.

However, the process of constructing and overseeing a DAO can pose notable difficulties, highlighting the pivotal importance of DAO tools. These essential software solutions encompass a diverse range of technologies that empower DAOs to function, organize, and regulate themselves with utmost effectiveness. These tools have emerged as indispensable elements for the triumph of countless DAOs, fostering improved efficiency, transparency, and security in their day-to-day activities.

Throughout this article, Syndika’s Blockchain Team will focus more on a specific duo that has gained prominence in the realm of decentralized governance – Tally and OpenZeppelin Governor. These two platforms have established themselves as influential tools for managing and executing on-chain voting processes, offering robust features and seamless integration with DAO ecosystems.

By delving deep into the intricacies of these tools, our objective is to provide valuable insights to developers, assisting them in their quest to construct innovative and advanced DAO platforms.

 

Main Principles of DAO Governance

On-chain vs Off-chain Voting

When it comes to the voting and decision-making process, DAOs utilize various substrates to facilitate these crucial activities.

Figure 1 – Comparison between on-chain and off-chain voting mechanisms [6]

 

For some DAOs, the entire voting process takes place on-chain, meaning that the votes are directly recorded and stored on the blockchain. Subsequently, the outcomes of these votes are automatically executed through smart contracts. On the other hand, certain DAOs rely more heavily on off-chain voting approaches and off-chain platforms, such as polling software, to conduct their voting procedures. A combination of both on-chain and off-chain approaches (hybrid) has become increasingly prevalent within the DAO ecosystem.

When it comes to on-chain/off-chain voting platforms, there are several notable and widely embraced options available [2]:

• On-chain voting
  Aragon (front-end UI to a smart contract), Governor Bravo (open-source code), Tally (frontend to Governor Bravo and OpenZeppelin Governor), and DAOhaus (front-end UI to a smart contract) are platforms that can be used to create or plug-and-play smart contracts that automatically execute votes on-chain;

• Off-chain voting
  Off-chain votes, which share the will of the voters without automatically executing an action, are often called signaling votes. Snapshot is the most popular platform for this. DAO members sign in with their wallets to cast token-weighted votes. This approach offers several benefits, including lower transaction costs, faster voting processes, and scalability. 

While on-chain voting offers transparency, immutability, and decentralization, it can be expensive and face scalability challenges. In contrast, off-chain voting provides faster and user-friendly experiences, potentially lowering transaction costs. However, it requires trust in the off-chain system and may need consensus mechanisms or cryptographic proofs to guarantee voting integrity.

Vote Delegation

Token holders have the ability to transfer their voting power to another user through a vote delegation, without relinquishing control over their underlying assets. This delegation can be revoked at any time, ensuring that protocol advocates remain aligned with the interests of their supporters. 

By implementing vote delegation, the cost of participating in governance is significantly reduced. Token holders can avoid the time-consuming process of individually reviewing each proposal and bypass the transaction fees associated with submitting their votes on the blockchain. 

Delegation enables smaller token holders to pool their stakes, granting them a stronger voice in governance discussions. For instance, many protocols impose minimum vote requirements for proposal submission and approval. Through vote delegation, regular users have the opportunity to meet these thresholds despite their limited personal resources [22].

Governance Process

Voting power (in a token-weighted DAO) is determined by the number of tokens delegated to each address. Users must delegate their tokens through a transaction to participate in governance voting. They can either delegate to a third party or self-delegate for direct voting participation.

Proposals serve as the fundamental unit of governance, containing executable code for specific protocol adjustments. To prevent spam, only users with voting power above the proposal submission threshold can submit proposals. The threshold, typically set at 1% of total tokens, can vary depending on the protocol. Protocols can optionally set a proposal delay parameter to allow time for users to update their vote delegation before voting begins.

Voting occurs within a predefined period established by the protocol. For example, Compound has a ~2.5 day voting period, while Uniswap uses a 7-day period. When the voting period ends, the system checks if the “yes” votes exceed the protocol’s quorum threshold (e.g., 4% of total tokens for Compound) to determine if the proposal passes.

Figure 2 – Chronology of a proposal [11]

 

If the quorum threshold is met and the vote receives majority support, the passed proposal enters a timelock queue. The timelock delays code execution for a specified period (typically 2 days), providing users with the opportunity to withdraw funds if they believe the proposal is malicious or unacceptable. Unlike Compound Governor, the OpenZeppelin Governor can function without a linked timelock.

If the proposer’s voting power drops below the proposal submission threshold at any point until the end of the voting or timelock period, the proposal can be canceled. Finally, once the entire process concludes, the proposal is executed, implementing relevant code or parameter changes in the protocol.

Figure 2 depicts the general flow of the proposal process, with specific timelines aligned with Compound governance but subject to variation in other protocols.

Overview of DAO Frameworks

DAOs embody an amalgamation of frameworks that facilitate collaborative actions between humans and computers in the online realm, providing a skeleton through which humans harness the potential of blockchain technology to coordinate communal choices and manage capital.

A DAO framework defines the specific set of structured interactions that humans and smart contracts use to make and execute decisions in service of the DAO’s purpose. Essential to any DAO framework are the governance frameworks and processes it employs [4].

The most prominent framework in this sense is OpenZeppelin Governor which is an open-source DAO framework for modular on-chain governance. By using the OpenZeppelin Governor, developers can integrate robust and customizable governance features into their smart contracts and DAOs, empowering community members to have a say in the project’s direction, protocol upgrades, and resource allocation. 

Aragon is another example of a powerful DAO framework that provides infrastructure for individuals and communities to govern themselves, make collective decisions, and manage resources in a decentralized and transparent manner. At its core, Aragon offers a set of smart contracts and software applications that empower users to create and operate their own DAOs [5]. 

Numerous software tools have emerged with the goal of reducing the barriers to entry for individuals interested in creating and participating in DAOs. These tools offer user-friendly interfaces, customizable templates, and pre-built functionalities, among which are Tally, Snapshot, Gnosis Safe, DAOhaus and others.

To exemplify, Tally serves as a comprehensive platform specifically designed for decentralized on-chain governance, where ownership lies in the hands of the users themselves. As a prominent partner of OpenZeppelin, Tally provides an intuitive user interface that simplifies the process for DAO members to navigate through proposals, cast their votes, and visualize their voting power. 

Why use OpenZeppelin Governor?

Compound’s Governor has become one of the most widely used governance frameworks. OpenZeppelin’s new Governor framework shares many similarities in design, with some architectural changes and improved standardization that may bring benefits to supported protocols. Key distinctive features include compatibility, flexibility & customization, and extensive community support.

Compatibility

OpenZeppelin’s Governor system was developed with a strong focus on ensuring compatibility with existing systems that were built upon Compound’s GovernorAlpha and GovernorBravo. As a result, you will discover that many modules are presented in two variations, with one specifically tailored to be compatible with those systems.

To illustrate, by default, an OpenZeppelin Governor contract does not possess an interface that aligns with Compound’s GovernorAlpha or Bravo. While events are fully compatible, the functions related to the lifecycle of proposals, such as creation and execution, have different signatures that are designed to optimize storage usage. Though, it is possible to choose a higher level of compatibility by inheriting from the GovernorCompatibilityBravo module. This module encompasses proposal lifecycle functions like “propose” and “execute”.

Flexibility & Customization

Compound’s GovernorAlpha and GovernorBravo contracts have undoubtedly achieved great success and popularity. However, one drawback is that projects with unique requirements often resort to forking the code in order to customize it, which introduces a significant risk of potential security vulnerabilities. In contrast, OpenZeppelin Contracts have implemented a modular system of Governor contracts to eliminate the need for forking. This approach allows for accommodating diverse requirements by simply writing small modules utilizing Solidity inheritance.

Community support

OpenZeppelin Governor is widely embraced and supported by a vibrant community, thanks to its trusted standing as a dependable governance platform within the decentralized ecosystem. The OpenZeppelin community actively nurtures engagement among developers, auditors, and contributors, creating a dynamic space for collaboration and the exchange of knowledge. The community’s active involvement extends beyond mere support, as they continuously enhance and update the Governor’s contract code, incorporating new features and addressing community-requested improvements in forthcoming releases.

What is Tally?

Tally serves as a comprehensive front-end solution for on-chain DAOs, offering a wide range of voting and governance analysis features. By leveraging Tally, DAO creators can enhance the usability of their governance contracts by connecting them to user interface components. This empowers them to build effective interfaces that enable their members to actively participate in on-chain voting, delegate their voting rights to trusted third parties, and access valuable insights into past proposals.

Tally extends its support to DAOs operating on various mainnets (e.g. Ethereum, Polygon, Optimism) and testnets (e.g. Sepolia, Mumbai, Goerli) proving its versatility and scalability.

A notable strength of Tally lies in its ability to provide transparent outcomes for previous proposals. Through this tool, the public can easily access information about the voters, their respective voting rights percentages, and their stance (“for”, “against”, or “abstained”) on each proposal. This transparent approach fosters accountability and supports an inclusive decision-making process within the DAO ecosystem.

Tally’s intuitive dashboard offers users a convenient way to monitor governance activities across multiple DAOs in which they are involved. This centralized view enhances the management of governance responsibilities and enables users to make informed decisions within the decentralized landscape.

Basic Layout of Governor DAO

The subsequent sections pertain to the Governor contracts provided by OpenZeppelin, as well as commonly employed ERC20/ERC721 extensions that play a crucial role in establishing an on-chain governance framework.

Governor Contracts

Governor contracts refer to smart contracts that are designed to facilitate decentralized governance within a blockchain-based ecosystem. These contracts typically govern decision-making processes, enabling token holders or members of a DAO to participate in voting, proposal submission, and the execution of various actions.

A typical Governor DAO uses three contracts: 

• Token
• Governor
• Timelock

Figure 3 illustrates the main features and functionalities associated with each contract within a DAO ecosystem and how these components communicate with each other.

Figure 3 – Architecture of Governor contracts

 

The Token contract serves as a ledger for tracking token balances within the DAO. In addition to recording token holdings, this contract also keeps track of delegations and voting power associated with the tokens by keeping a history (checkpoints) of each account’s vote power.

The next component – the Governor contract, holds significant importance in the decision-making procedures of the DAO. Acting as a crucial platform, it facilitates the creation of proposals and enables members to exercise their voting privileges in relation to these proposals. To determine the final result of the voting process, the Governor contract relies on voting power snapshots derived from the Token contract. Moreover, once a proposal garners successful approval, the Governor contract proceeds to transmit it to the Timelock contract, which then carries out the execution of the proposal.

The Timelock contract acts as a crucial component in the DAO’s governance system by introducing a time delay before proposal execution. This delay ensures that proposals undergo a specified waiting period, allowing members to review and potentially challenge them if necessary. The Timelock contract also represents the DAO’s primary account, responsible for holding and managing its assets.

Contract Setup

*The entire implementation of Governor DAO, including Governor, Timelock, and Token can be found on Syndika Github. For detailed specifications please consult the OpenZeppelin docs.

Token

The governance setup within the DAO assigns voting power to each account based on a token that complies with EIP-5805 compatibility. This requires the token to implement specific voting methods, namely “getVotes” and “getPastVotes”. When proposals are being voted upon, governors can utilize these methods to calculate and count votes effectively [7].

To meet the mentioned criteria, the token needs to incorporate OpenZeppelin’s ERC20Votes or ERC721Votes extension, depending on the type of token. 

The ERC20Votes/ERC721Votes logic on the token contract is responsible for voting power bookkeeping that can’t be done on another contract. That bookkeeping involves several things: updating voting power when there’s a delegation or transfer, taking a snapshot of the voting power at the start of each proposal, and emitting event logs for indexers whenever there’s a change in delegation or voting power [8]. 

Each “transfer” and “delegate” call updates the counts of voting power, so that it’s computationally cheap to save a voting power snapshot for a proposal. Governor needs a voting power snapshot to prevent double-voting. It would be too computationally expensive for an external contract like Governor to keep track of which tokens have already voted without a snapshot, because an attacker could move around tokens to vote multiple times with the same token [8].

Sometimes it is difficult to deal with durations expressed in the number of blocks because of inconsistent or unpredictable time between blocks. Since v4.9, all voting contracts (including ERC20Votes and ERC721Votes) rely on IERC6372 for clock management. In order to change from operating with block numbers to operating with timestamps, all that is required is to override the “clock” and “CLOCK_MODE” functions [14].

The ERC20Permit allows approval to be made via signatures as defined in EIP-2612. 

In cases where your existing project possesses a live token that lacks the ERC20Votes functionality and is non-upgradeable, there is an alternative solution available. By utilizing ERC20Wrapper, it becomes feasible to wrap your token into a governance token, thereby enabling token holders to engage in governance activities by wrapping their tokens on a 1-to-1 basis. 

Similarly, if you have ERC721 tokens that do not offer this governance functionality, you can employ a combination of ERC721Votes and ERC721Wrapper to transform them into voting tokens [8].

Governor

Core logic is determined by the Governor contract. When deploying a Governor, it is necessary to clarify these moments:

1. How is voting power determined?
2. How many votes are needed for quorum?
3. What options do people have when casting a vote and how are those votes counted?
4. What type of token should be used to vote?

The answer to the first question resides in the use of GovernorVotes module, which hooks to an IVotes instance to calculate the voting power of an account based on the token balance they possess when a proposal becomes active. To implement this module, the token address needs to be provided as a constructor parameter. Additionally, the GovernorVotes module detects the clock mode (ERC6372) employed by the token and applies it accordingly within the Governor framework.

For solving the second issue we will use GovernorVotesQuorumFraction which works together with ERC20Votes to define quorum as a percentage of the total supply at the block a proposal’s voting power is retrieved. This requires a constructor parameter to set the percentage. For Governors on Tally, the quorum is usually somewhere in the range of 1-10% of circulating token supply. 

In order to answer the third question, we will use GovernorCountingSimple, a module that offers 3 options to voters: For, Against, and Abstain, and where only For and Abstain votes are counted towards quorum.

The type of token used for measuring the voting power can be either ERC20 or ERC721 depending on the dApp’s necessities. As can be observed from previous sections, OpenZeppelin offers tooling for both of them.

These parameters must be also set for the Governor contract:

• votingDelay – how long after a proposal is created that voting power is fixed (a larger delay gives users time to unstake tokens)
• votingPeriod – how long a proposal remains open to vote

The specifications for these parameters are determined based on the unit defined in the token’s clock. Assuming that the token operates on block numbers with an approximate block time of 12 seconds, we can establish the values of “votingDelay” as 1 day, equivalent to 7200 blocks, and votingPeriod as 1 week, which corresponds to 50400 blocks. 

Additionally, it is possible to impose a proposal threshold that limits the creation of proposals to accounts with sufficient voting power.

Timelock

To enhance the resilience and efficacy of governance decisions, it is advisable to incorporate a timelock mechanism. This feature enables users to withdraw from the system if they dissent from a decision before it is implemented. OpenZeppelin suggests utilizing both the TimelockController and GovernorTimelockControl modules to effectively incorporate this element into the governance system.

The TimelockController acts as a timelocked controller. When set as the owner of an Ownable smart contract, it enforces a timelock on all “onlyOwner” maintenance operations. This gives time for users of the controlled contract to exit before a potentially dangerous maintenance operation is applied [9].

The incorporation of the GovernorTimelockControl module establishes a connection between the execution process and an instance of TimelockController. This introduces a delay, enforced by the TimelockController, to all proposals that receive successful approval (in addition to the voting duration). For the Governor to function correctly, it requires the roles of both proposer and ideally executor. By following this model, the TimelockController takes charge of executing the proposal instead of the Governor. Therefore, it is crucial to associate assets and permissions with the TimelockController, as any assets sent to the Governor will become inaccessible! [10]

Setting Governor Parameters

Within a Governor contract, there exist several crucial parameters that significantly impact the lifecycles of its proposals. These parameters can be envisioned as a delicate balancing act, striving to match the right equilibrium between facilitating the passage of proposals and ensuring robust protection against malicious proposals. Here are some guidelines to assist in choosing the right parameters for optimal performance [15].

Proposal Threshold

The Proposal Threshold is the amount of voting power that an account needs to make a proposal. Tally Governors often set it between 0% and 2% of the token supply to prevent spam and ensure proposers have economic exposure or delegate trust. Some DAOs lower the threshold to 0 for broader participation. Selecting a suitable threshold depends on the voting power distribution, which may be uncertain at the DAO’s early stages. Typically, Tally DAOs aim for a medium-sized group of 5-10 delegates exceeding the threshold.

Quorum

The Quorum represents the threshold of “For” votes, sometimes including “Abstain” votes, required for a proposal. Determining an appropriate quorum is challenging since it relies on the voter turnout, which may be difficult to predict. A too-high quorum could hinder the passage of any proposals, while a too-low quorum could expose the Governor to spam attacks. On Tally, Governors typically set the quorum within the range of 1-10% of the circulating token supply.

Voting Period

The voting period determines the duration of voting for each proposal. At the conclusion of this period, the proposal either passes or fails. Typically, most DAOs opt for a voting period spanning between 3 to 7 days. A period shorter than 3 days leaves room for someone to potentially push a proposal unnoticed during weekends or periods of low activity. Conversely, a period closer to 7 days allows sufficient time for everyone to thoroughly review a proposal.

Voting Delay

The voting delay is the time between proposal submission and voting. Most Governors have no delay, while those that do choose a period of one day or less. This delay provides time for token holders to delegate or acquire votes. However, most DAOs prefer to forgo the delay to avoid slowing down the proposal process.

Timelock Delay

The timelock delay is the minimum time between proposal passing and execution. DAOs choose values ranging from 0 to 7 days, balancing agility and security. A delay of 0 is recommended for treasury-focused Governors, while those with emergency veto roles should have at least a 3-day delay. Governors managing DeFi protocols often opt for a 7-day delay to accommodate user fund withdrawals.

Governance Use-Case

In this section, we will explore the process of deploying a DAO and integrating its functionalities with UI components, specifically in the context of Tally. Additionally, we will simulate the lifecycle of a proposal, providing a step-by-step demonstration of how proposals progress through various stages.

*For complete code implementation please check this repo from Syndika Github.

Adding a DAO 

Firstly, the Governor system of contracts should be deployed on-chain. All components were already described in Contract Setup. The whole script for deployment can be found here.

In order to add a DAO on Tally, select the “Add a DAO” button on the Tally home page. Enter your DAO’s info: its name, description, and Governor Contract details, and then click “Add Governor”.

 

Figure 4 – Example of adding a DAO on Tally

 

Creation of a Proposal

A proposal within the Governor contract represents a series of actions that will be executed if it gains approval. Each action comprises a target address, calldata that encodes a function call, and an optional ETH amount to be included. Furthermore, a proposal incorporates a description that is easily understandable to humans [12].

Suppose we have a specific use-case in mind: we aim to create a proposal that involves updating values in a contract. This proposal will encompass a solitary action, targeting the contract named TargetContract. The calldata for this action will be the encoded function call “setValue(uint256)”, and no ETH will be attached to it.

Typically, the creation of a proposal involves utilizing an interface like Tally. However, in this instance, we will demonstrate the process of creating a proposal using Ethers.js and Hardhat.

First we get all the parameters necessary for the proposal action.

    const PROPOSAL_DESCRIPTION = "This is proposal #1";

    const SET_VALUE = 333;

    const targetContract = "0xf9D7aa83209C5Ae66aCc8136dF7721889590278D"; 

    let encodedFunctionCall = targetContract.interface.encodeFunctionData("setValue", [SET_VALUE]);

 

Now we are ready to call the “propose” function of the Governor. Note that we don’t pass in one array of actions, but instead three arrays corresponding to the list of targets, the list of values, and the list of calldatas.

    const proposeTx = await daoGovernor.propose(

      [targetContract],

      [0],

      [encodedFunctionCall],

      PROPOSAL_DESCRIPTION

    );

 

By following this process, a fresh proposal will be generated, accompanied by a unique proposal ID. The proposal ID is obtained by hashing the proposal data together and can be found in an event within the transaction logs [3].

Vote casting

Once a proposal is active, delegates can cast their vote. Note that delegates are the ones who carry voting power: if a token holder wants to participate, they can set a trusted representative as their delegate, or they can become a delegate themselves by self-delegating their voting power.

Votes are cast by interacting with the Governor contract through the “castVote” family of functions. Voters would generally invoke this from a governance UI such as Tally.

Figure 5 – Example of vote casting on Tally

 

It is also possible to cast a vote programmatically, e.g. by calling “castVoteWithReason” with specific parameters.

    const voteTx = await daoGovernor.castVoteWithReason(proposalId, voteOption, voteReason);

    await voteTx.wait();

Proposal execution

After the completion of the voting period, if the quorum requirement (sufficient participation of voting power) is met and the majority of votes are in favor, the proposal is deemed successful and eligible for execution. Once a proposal successfully passes, it can be queued and executed conveniently from the same platform or interface where the voting took place.

Figure 6 – Example of proposal execution on Tally [13]

 

You can also perform this process manually if desired.

If a timelock was established, the initial step towards execution is queuing. It’s worth noting that both the “queue” and “execute” functions necessitate passing all the proposal parameters, rather than just the proposal ID. This is because this data is not stored on the blockchain to save gas. However, it’s important to mention that these parameters can always be obtained from the events emitted by the contract. The only parameter that is not sent in its complete form is the description, as only its hashed form is required to compute the proposal ID.

For queuing, we call the “queue” function:

    const descriptionHash = ethers.id(PROPOSAL_DESCRIPTION);




    const queueTx = await daoGovernor.queue(

      [targetContract],

      [0],

      [encodedFunctionCall],

      descriptionHash

    );

    await queueTx.wait();

 

This action triggers the interaction between the Governor and the Timelock contract, leading to the queuing of actions for execution following the designated delay.

Once the specified duration has elapsed, based on the timelock parameters, the proposal becomes eligible for execution. If no timelock functionality was initially set up, this step can be performed immediately after the proposal successfully passes.

Executing the proposal will set the predefined value “333” in the TargetContract.

    const executeTx = await daoGovernor.execute(

      [targetContract],

      [0],

      [encodedFunctionCall],

      descriptionHash

    );

    await executeTx.wait();

 

Smart-Contract Integration with Tally UI

At present, Tally extends its support to two prominent contract libraries: OpenZeppelin Governor and Compound Governor Bravo. In this section, we will delve into the interface specifications that DAOs’ contracts should adhere to in order to ensure compatibility with Tally. The primary focus will be on the OpenZeppelin framework, which serves as a widely adopted and recognized standard fully supported by Tally [16]. 

OpenZeppelin Governor

Event Signatures

Tally’s API effectively monitors and indexes event logs emitted by Governor contracts. To ensure compatibility with Tally, your contract should maintain identical event signatures as implemented in the OpenZeppelin Governor.

Table 1 – Required Event Signatures for Governor [17]

Function Signatures

Tally’s frontend app helps users make web3 calls to your Governor contract. The app lets users create Proposals as well as vote on, queue, and execute them. In addition, the app reads the state from the contract with function calls. 

To ensure compatibility with Tally, your Governor contract should implement the following function signatures:

Table 2 – Required Function Signatures for Governor [18]
*Methods marked with an asterisk either require supplementary modules or are additional functionalities.

 

If your OpenZeppelin Governor contract utilizes a Timelock, it should also include the signature for the “queue” method to be compatible with Tally.

Tally relies on the quorum to determine if a proposal has achieved a majority vote. Therefore, the Governor contract should have a “quorum” function. Additionally, Tally supports the optional “quorumNumerator” and “quorumDenominator” functions. If the quorum of the Governor is based on the token supply, it is recommended to implement these functions as well. In case the Governor lacks either “quorumNumerator” or “quorumDenominator,” Tally will fallback to the “quorum” function and assume a fixed quorum.

To accurately calculate the completion of the voting period without continuously querying the blockchain, Tally requires knowledge of the voting period. Hence, the Governor contract must include a “votingPeriod” function that provides this information.

Proposal state lifecycle

Tally’s app expects the following proposal states. If your Governor uses a custom proposal lifecycle, those states won’t show up correctly on Tally [19].

enum ProposalState {

    Pending,

    Active,

    Canceled,

    Defeated,

    Succeeded,

    Queued,

    Expired,

    Executed

}

 

Governor Parameter Changes

To ensure that Tally accurately indexes any parameter changes made by Governors, such as proposal times and required voting power, it is important to implement the corresponding event signatures. This allows Tally to effectively track and update the indexed data associated with your Governor contract.

 

Table 3 – Required Event Signatures for Governor’s parameter changes [20]

Tokens: ERC20 and NFTs

For seamless integration with Tally, tokens are expected to adhere to relevant standards such as ERC-20 or ERC-721. Additionally, the token contract should implement the EIP-5805 standard for delegation and voting power checkpointing, as required by Tally.

Event Signatures

Tally’s API listens to event logs from token contracts when indexing them. Your token contract will need to maintain the same event signatures. Transfer events should be standardized accordingly.

 

Table 4 – Required Event Signatures for Governor’s token [21]

Function Signatures

To enable voting and delegation functionalities, your token contract should incorporate the necessary functions. If you’re utilizing an ERC20 token, you can employ the ERC20Votes or ERC20VotesComp extensions available in the OpenZeppelin token contracts library. Alternatively, for ERC721 tokens, OpenZeppelin’s draft ERC721Votes extension can be utilized. The Tally frontend interface assists users in executing these function calls to delegate their voting rights.

Table 5 – Required Function Signatures for Governor’s token handling [18]
* Applicable for ERC20 only

 

Conclusion

In recent years, the rise of DAO platforms has posed a significant challenge for software engineers to develop tools that meet the diverse requirements of this emerging field. However, amidst this complex landscape, the partnership between OpenZeppelin and Tally has emerged as a pivotal solution, revolutionizing the development of on-chain DAOs by offering unparalleled effectiveness and efficiency. By tackling the intricacies and obstacles associated with decentralized governance, these tools empower developers to construct resilient and autonomous systems.

OpenZeppelin’s battle-tested smart contract libraries provide a solid foundation for secure and reliable smart contract development, ensuring the integrity and trustworthiness of the DAO’s operations. With a wide range of pre-audited and well-documented modules, developers can leverage OpenZeppelin’s expertise to build and deploy smart contracts with confidence.

Meanwhile, Tally’s governance and decision-making platform offers an intuitive interface for managing voting processes within a DAO. Its seamless integration with blockchain networks allows for transparent and tamper-resistant voting, enabling DAO members to participate and contribute to the decision-making process effectively. Tally’s features, such as delegated voting and real-time analytics, enhance the efficiency and inclusiveness of DAO governance.

By harnessing the power of OpenZeppelin and Tally, developers can unlock the full potential of on-chain DAOs. These tools provide the necessary infrastructure to build decentralized systems that foster trust, fairness, and community-driven decision-making. As the DAO ecosystem continues to evolve, it is imperative for developers to stay updated with the latest tools and technologies that empower them to build resilient and successful DAO platforms.

Summing up, the combined forces of OpenZeppelin and Tally offer a powerful toolkit for the effective development and management of on-chain DAOs. As we embrace the future of decentralized governance, these tools will undoubtedly play a crucial role in shaping the landscape of DAOs, enabling individuals and communities to collaborate and govern themselves in a truly decentralized and autonomous manner.

 

Any questions? Need help?

If you have any questions or require assistance in outsourcing software development in the Web3 and blockchain space, Syndika is here to help. We are a top-notch software development agency specializing in Web3 and blockchain technologies. With our expertise in business technology consulting, we can guide you through the process of leveraging blockchain solutions and outsourcing developers with the necessary skills. Feel free to reach out to Syndika, your trusted partner in Web3 and blockchain software development.

 

References

1. https://www.investopedia.com/tech/what-dao/
2. https://aragon.org/how-to/build-your-dao-tooling-stack
3. https://docs.openzeppelin.com/contracts/4.x/governance#create_a_proposal
4. https://blog.tally.xyz/a-pocket-guide-to-dao-frameworks-8d7ad5af3a1b
5. https://blog.aragon.org/dao-framework-how-to-code-a-dao-with-aragon-smart-contracts/
6. https://docs.tally.xyz/knowledge-base/tally/on-chain-vs-off-chain
7. https://docs.tally.xyz/user-guides/deploying-governor-daos/deploy-a-governance-token#how-to-deploy-a-compatible-token
8. https://docs.tally.xyz/user-guides/deploying-governor-daos/add-a-governor-to-an-existing-token
9. https://docs.openzeppelin.com/contracts/4.x/api/governance#TimelockController
10. https://docs.openzeppelin.com/contracts/4.x/api/governance#GovernorTimelockControl
11. https://wiki.tally.xyz/docs/openzeppelin-governor
12. https://docs.openzeppelin.com/contracts/4.x/governance#proposal_lifecycle
13. https://docs.openzeppelin.com/contracts/4.x/governance#execute_the_proposal
14. https://docs.openzeppelin.com/contracts/4.x/governance#token_2
15. https://docs.tally.xyz/user-guides/deploying-governor-daos/pick-good-governor-parameters
16. https://docs.tally.xyz/user-guides/tally-contract-compatibility
17. https://docs.tally.xyz/user-guides/tally-contract-compatibility/openzeppelin-governor#event-signatures
18. https://docs.tally.xyz/user-guides/tally-contract-compatibility/openzeppelin-governor#function-signatures
19. https://docs.tally.xyz/user-guides/tally-contract-compatibility/openzeppelin-governor#proposal-state-lifecycle
20. https://docs.tally.xyz/user-guides/tally-contract-compatibility/openzeppelin-governor#governor-parameter-changes
21. https://docs.tally.xyz/user-guides/tally-contract-compatibility/tokens-erc20-and-nfts#event-signatures
22. https://wiki.tally.xyz/docs/vote-delegation