Get Started

Learn how to navigate and use the Tally platform.

Technical Documentation

Learn about deploying a Governor contract and how to customize it for compatibility with the Tally interface.

Token Launch Features

Modular Architecture

Tally's system is designed with flexibility in mind. You can launch just the token, pair it with staking and governance from day one, or progressively enable those components later. This modularity ensures technical teams aren’t locked into premature decisions while still laying a foundation for future expansion.

Full Lifecycle Support

From contract deployment to governance activation, Tally supports your team across every phase of launch:

• ERC20 token contract deployment (mint/burn, cap, upgradeable, etc.)

• Optional components: transfer restrictions, vesting, lockups

• Multichain support (bridged or canonical setups)

• Progressive rollout flows: e.g. claim site + staking before transferability

• Optional governance setup and delegation frameworks

Production Ready Contracts

Tally's contracts are widely used and actively maintained. They're deployed across Ethereum mainnet and major L2s and used in production by protocols like Hyperlane, ZKsync, Wormhole, and more. Security and regular audits are first principles in Tally's deployment process.

Custom Launch Infrastructure and Custom UI

Tally offers branded, custom-built claim and staking frontends tailored to your protocol. UI and UX are developed in close collaboration with your team to ensure brand alignment and user clarity.

Community Support and Integrations

Tally helps your team prepare for a clean launch:

• Pre-launch links and interfaces

• Educational and onboarding materials

• Page scaffolding

Launch Tokens with Governance

Tally offers protocols the ability to launch tokens with governance from day 1. Launching with governance includes everything in the traditional token launch package. Teams can also add governance at a future date.

End-to-end Governance Application

Tally provides a comprehensive governance solution. These features are complete and ready to be used by the community.

Custom Domain: A version of our governance platform that can be hosted at a custom domain.

Voting: Secure, transparent, and efficient voting mechanisms to ensure that all governance decisions reflect the will of the community.

Proposal Execution: Automated execution of approved proposals.

Proposal Drafting and Collaboration: Collaborative proposal creation through tools designed to enable multiple contributors to work together seamlessly.

Proposal Creation with Arbitrary Executables: Proposals can be created with customizable executable actions, allowing for a wide range of governance activities and decisions to be automated and enforced onchain.

No-Code Transfers: Easy and secure fund transfers within the community without requiring any coding skills.

Notifications: Real-time notifications about important events, proposals, and decisions within the community.

DAO Analytics: Detailed analytics and insights into community activities, member engagement, proposal outcomes, and overall performance.

Gnosis Safe Management: Gnosis Safe integration for secure and efficient management of community funds and assets.

Wallet Support: Native support for a wide range of wallets, ensuring accessibility and convenience for all community members.

Public API: Tally's comprehensive public API can power custom governance applications and integrate with other tools and platforms within the Ethereum ecosystem.

Governance Smart Contract Development

Tally will deploy your governance smart contracts, including Governor with Flexible Voting extension and Timelock. These will operate with your governance token seamlessly.

Advising on Governance Parameters: Establishing robust governance parameters is essential for effective decentralized governance. Tally will provide detailed guidance on setting the following key parameters to ensure smooth and effective operation of your governance system:

• Proposal Threshold

• Quorum Requirement

• Voting Period

• Voting Delay

• Execution Delay

Tally provides a comprehensive Delegate Registration flow, designed to streamline delegate acquisition.

Governance Launch Announcement: Tally will launch a targeted campaign ~1 week prior to the launch, with a dedicated launch page (e.g.,https://www.tally.xyz/gov/DAOname) to build awareness.

Delegate Sign-up Process: Tally will implement an intuitive sign-up flow for users interested in becoming delegates.

When delegation is not part of the initial claim process, the likelihood of subsequent delegation diminishes significantly. Inactive tokens sitting in wallets hinders active governance participation and that’s why we really recommend delegation go hand in hand with airdrop claim flow.

To ensure a smooth and convenient transition from token claim to active governance participation, Tally provides a post-claim delegation experience.

Custom Token Claim Interface: Tally will create a custom UI for users to claim the governance token and immediately delegate their tokens to ensure governance participation from the onset.

Seamless Delegate Discovery and Selection: Tally will develop a user-friendly interface that guides token holders through the process of discovering and selecting delegates, immediately following the token claim experience.

Delegate Profile Pre-population: Tally will automatically populate delegate profiles with information gathered during the call for delegates phase, streamlining the selection process for token holders.

Transparent Voting Power Display: Tally will provide users with clear insights into their voting power alongside detailed information on incoming and outgoing delegations.

Governance Launch Communications and Strategy

Tally has the largest media presence in the onchain governance space, with DAO Talk podcast, The Tally Newsletter, our Twitter, and the Tally blog. We are excited to leverage these platforms to spread the word about the protocol's launch, vision and strategy, and needs for delegation.

A custom claim page is essential for a successful token launch. Tally’s custom claim pages provide a secure, branded gateway for distribution while protecting users from scams and phishing attempts. Custom claim pages create trust, brand uniformity, and a solid foundation to ensure a smooth token launch campaign.

Tally creates a custom UI for users to claim the governance token and immediately delegate their tokens to ensure governance participation from the onset.

Included: Custom Domain, Delegate Registration

Tally provides a comprehensive Delegate Registration flow, designed to streamline delegate acquisition.

Governance Launch Announcement

Tally will launch a targeted campaign ~1 week prior to the launch, with a dedicated launch page (e.g. https://www.tally.xyz/gov/DAOname) to build awareness.

Delegate Sign-up Process

Tally will implement an intuitive sign-up flow for users interested in becoming delegates.

Newsletter Announcements

Tally will feature the DAO's call for delegates in The Tally Newsletter, reaching an audience of over 1500 governance enthusiasts and potential delegates

DAO Talk Interview

Tally will host an in-depth podcast interview with a key protocol leader(s) to publish via the DAO Talk podcast feed.

To ensure a smooth and convenient transition from token claim to active governance participation, Tally provides a post-claim delegation experience to enhance user engagement and simplify the delegation process.

Custom Token Claim Interface

Tally will create a custom UI for users to claim the governance token and immediately delegate their tokens to ensure governance participation from the onset.

Seamless Delegate Discovery and Selection

Tally will develop a user-friendly interface that guides token holders through the process of discovering and selecting delegates, immediately following the token claim experience.

Delegate Profile Pre-population

Tally will automatically populate delegate profiles with information gathered during the call for delegates phase, streamlining the selection process for token holders.

Transparent Voting Power Display

Tally will provide users with clear insights into their voting power alongside detailed information on incoming and outgoing delegations.

A Governor contract expects a particular interface from its token contract. An OpenZeppelin Governor requires a token contract that implements the ERC20Votes interface or the ERC721Votes interface.

If the token is already deployed and it cannot be upgraded, the best workaround is to deploy a token wrapper contract that adds the voting interface to an existing token.

UX tradeoffs

Users will have to wrap their tokens to vote, and then unwrap them to use them in places that expect the unwrapped version. They may also be confused about where their token went after wrapping if their wallet doesn’t know about the wrapped version.

One thing to note is that setting up voting already requires setup: token holders have to delegate their votes – even to themselves – before voting. The wrapping step could be combined with delegation to keep the process simpler for token holders.

Why Value Accrual?

Blockchain protocols need sustainable token economics and aligned holders to succeed.

Value accrual offers several key benefits:

• Stakeholder alignment: Align tokenholders with protocol success

• Sustainable tokenomics: Establish a foundation for ongoing value creation

• Enhanced retention: Encourage long-term participation in the ecosystem

• Protocol resilience: Secure the protocol with economic assets

Protocols must move beyond initial hype cycles. Value accrual mechanisms help by distributing value directly to participants who secure and govern the network.

Why use Staking for Value Accrual?

Tally's value accrual product is a complete staking solution for protocols.

Staking on Tally distributes protocol revenue or native issuance to tokenholders. It's the foundation for open, trust-minimized systems.

Optionally, the rewards can be incentives for particular actions. Rewards can depend on particular behavior, like validating the network, long-term holding or governance activity.

Tally staking offers:

1. Flexible staking infrastructure: Implement staking for your protocol’s specific needs.

Tally's solution works for protocols at any stage. It supports new token launches and established projects. This guide covers both strategic direction and technical details.

How does it work?

1. Staking contracts distribute rewards over time

Rewards can come from anywhere. The most common sources are 1) protocol revenue and 2) issuance of the protocol's native token. The rewards can be in any ERC20 token or even in more than one token.

Tally's staking contracts distribute rewards among eligible staking users over time.

2. Tokenholders stake protocol tokens for a share of the rewards

Tokenholders stake the staking token: the protocol's native token. Then, they earn a share of the rewards proportional to their share of all staked tokens over time. They can stake, claim rewards, and unstake at any time.

Staking supports governance. If the staking token is also a governance token, holders can use their staked tokens in governance. That way, tokenholders don't have to choose between governance and receiving rewards.

Optionally, the staking system can have eligibility criteria stipulate particular actions from tokenholders to get rewards. For example, it could require that staked tokens be active in governance to earn rewards. There's a large design space for incentivizing token-aligned services.

Learn more

Returning Fees

Tally's staking system allows protocols to return protocol fees to token stakers. This creates direct economic alignment between protocol usage and token holder rewards.

How it works:

• Protocol governance decides what percentage of fees to distribute to stakers

• Fee distribution can be automated through smart contracts

• Rewards can be paid in native tokens, ETH, stablecoins, or other assets

Governance Integration

Unlike other staking systems that force users to choose between earning yield and participating in governance, Tally's solution supports both.

How it works:

• Staked tokens can delegate their voting power

• Optionally, rewards depend on the tokens being active in governance

Other protocols like Rarible and Arbitrum are exploring making staking rewards conditional on delegating to an active delegate, further incentivizing governance participation.

Network/Protocol Validation

Tally's staking system is compatible with staking and restaking protocols that provide validated services.

How it works:

• Native tokens can be used to secure actively validated services

• Compatible with protocols like EigenLayer and Symbiotic

• Aligns token holder incentives with network security

Stake Streaks

Stake streaks reward long-term holders, creating incentives for extended token holding periods and reducing market volatility.

How it works:

• Stakers' earning power increases over time

• Rewards scale based on continuous staking duration

• Encourages long-term protocol alignment, and reduces token velocity

Standard Features

Advanced Features

Advanced features are available for organizations looking for more complex governance solutions. Advanced features include:

FAQ

How often do rewards get distributed, and how is earning power recalculated?

The REWARD_INTERVAL is configurable when deploying a new reward source. When there’s a new reward, the staking system updates everyone’s reward schedules based on earning power. The rewards are distributed over a period of time, the REWARD_DURATION.

Does the system support partial delegation?

Yes, stakers can create multiple staking positions. Each staking position can have its own delegate.

Does the Tally interface support multiple staking positions, and is it live?

Is staking compatible with onchain governance, like ERC20Votes tokens and Governor contracts?

Yes! Staking is compatible with standard governance tokens and Governor contracts out-of-the-box.

The staking system delegates the voting power of staked governance tokens. It uses the same methods that regular tokenholders do, so no changes to the underlying system are needed.

How does the system handle vote checkpoints/snapshots?

The underlying governance token handles snapshotting. Staker puts the governance tokens for each delegate into a separate account, called a “surrogate”. Then, it calls delegate() on the underlying governance token to distribute voting power. This way, the underlying governance system does not have to change.

How does unstaking work, and is there a time delay?

The current version of Staker lets tokenholders withdraw instantly. Withdrawal delays create an incentive for dangerous LSTs, which can blow up if there’s a duration mismatch.

Can the LST participate in governance?

Yes! The LST can delegate its voting power directly, like a normal governance token. If the holder doesn't delegate the votes, the LST uses the delegation strategy instead. That way, LST voting power is always active in governance.

Is there liquidity risk of LST vs the underlying token?

Liquidity risk is minimal, because unstaking is instant. If there is a price difference between TOKEN and stTOKEN, arbitrageurs can arbitrage it away.

Can stGOV be used in restaking and DeFi?

Yes, that's one of the primary motivations. LST holders can have it all. They can participate in governance, earn rewards for doing so, and use their position as collateral. The LST is a rebasing token, but it's easy to wrap it into a non-rebasing LST.

Who approves the default delegation strategy(s)?

The underlying governance does. e.g. Arbitrum governance would pick the delegation strategy for `stARB`. If Arbitrum governance does not approve one, Tally Protocol's governance picks a default.

Is there risk of delegation strategies capturing governance?

Delegation strategies have no special powers that might present a danger. Token holders are free to change delegation strategies at any time. Poorly implemented delegation strategies do not pose a feedback loop danger. In the worst case, users withdraw their tokens or delegate them by hand.

What is Multichain Governance?

Your DAO, everywhere. MultiGov lets DAOs meet token holders where they are. DAO members can govern an on-chain DAO from any chain. MultiGov supports DAOs on Solana, Ethereum and EVM-compatible L2s. Multichain DAOs will lower barriers to participation and reach users everywhere.

Single-chain vs MultiGov

Until now, DAOs operated their governance on a single chain.

On L1

Many of the oldest and largest DAOs have their token, Governor and treasury all on Ethereum mainnet. Rising L1 gas costs make that setup increasingly expensive. MultiGov gives voters a way to lower gas costs.

On a single L2

Newer protocol DAOs might launch on one network. Once they find product-market fit there, they often want to expand to other ones. MultiGov gives protocols a way to meet users where they are.

Benefits of MultiGov:

• Save on gas costs

• Govern protocol across chains

• Meet community where they are

• DAO can follow the protocol to new networks

Implementation: the hub-and-spoke model

MultiGov DAOs use a hub-and-spoke model. This model combines well-understood building blocks – governor, token bridges, and message-passing.

On each "spokes" of a MultiGov DAO, there's a bridged gov token and a spoke Governor. The bridged gov token keeps track of voting power on that chain. When there is a proposal, the voters on that spoke chain vote on a spoke Governor. Votes on each spoke Governor can be aggregated and bridged back to the hub chain.

The Wormhole DAO

The Wormhole DAO, powered by $W token holders, will be the first to use this pioneering multichain governance system. Wormhole's DAO will enable token holders on any supported chain to engage in the governance process. This approach to governance will enhance the user experience, making community contributions easier.

Why Tally?

Tally is the software layer for tokenized organizations. Winning teams use Tally to launch tokens, govern protocols, and grow with staking. Foundations, delegates, and token holders use Tally to manage $81+ billion in value for onchain protocols.

Launching a token is a public commitment that sets the foundation for an organization’s economic model, governance structure, and long-term credibility. Tally ensures teams launch tokens the right way with secure, modular contracts; a clear, phased rollout path; and purpose-built interfaces for claims, staking, and governance. Whether you're issuing a governance token or building utility into your protocol, Tally gives you the tools to do it cleanly, transparently, and at scale.

With Tally, protocols can:

With Governance Launch, Tally deploys the protocol’s governance smart contracts, including Governor and Timelock. These smart contracts enable fully decentralized onchain governance.

Included in Tally’s Governance Launch Service

Token with ERC20 Votes Deployment

Tally will deploy your token, a non-fungible, non-transferable token that can be minted and revoked by the Governor. ERC20Votes extension ensures that your governance token supports vote delegation and efficient tracking of voting power over time.

Governor and Timelock Contracts Deployment

Tally will deploy the Governor and Timelock contracts. The Governor contract facilitates the proposal and voting process, while the Timelock contract enforces a delay between the proposal's passage and its execution.

• Flexible Voting Tally’s flexible voting setup prepares protocols for more advanced governance structures. Flexible voting enables sophisticated governance models like MultiGov and partial delegation.

Governance Parameters Advisory

Tally provides detailed guidance on setting key parameters to ensure smooth and effective operation of the protocol’s governance system:

• Proposal Threshold, Quorum Requirement, Voting Period, Voting Delay, & Execution Delay, and more.

This new building block allows arbitrary delegate contracts to be developed which can unlock all kinds of new use cases, such as:

• Voting with tokens while earning yield in DeFi

• Voting on L2 with bridged tokens

• Shielded voting (i.e. secret/private voting)

• Cheaper subsidized signature based voting

Glossary

Core Concepts

Value Accrual: The process by which a token captures and distributes value generated by an associated protocol or network, creating sustainable tokenomics.

Staking: The act of locking up tokens in a smart contract to participate in network validation, governance, or earning rewards.

Tokenomics: The economic model of a token, including its supply, distribution, utility, and incentive mechanisms.

Rewards: Tokens or other assets distributed to participants for contributing to the network, such as through staking.

Yield: The rate of return earned on staked tokens, typically expressed as an annual percentage.

Staking System Components

Staker Contract: The main smart contract that manages token deposits, withdrawals, and rewards distribution.

Earning Power: A metric that determines a staker's proportional claim on rewards, which may be equal to or modified from their staked amount.

Earning Power Calculator: A component that determines how rewards are distributed to stakers based on various criteria.

Reward Notifier: A contract that informs the staking system about new rewards and triggers their distribution.

Delegation Surrogate: A contract that holds staked tokens and delegates their voting power to a specified address.

Reward Stream: The mechanism by which rewards are distributed gradually over time rather than all at once.

Reward Duration: The time period over which rewards are distributed (default 30 days in the Tally system).

Governance Integration

Delegation: Assigning voting power to a specific address without transferring token ownership.

Delegatee: The address that receives voting power through delegation.

Governance Token: A token that grants voting rights in a protocol's governance system.

Governance Staking: Staking that preserves governance voting rights while earning rewards.

Auto-Delegation: A system that automatically delegates voting power according to configurable rules.

Liquid Staking

Liquid Staking Token (LST): A token representing a staked position that can be transferred or used in DeFi while the underlying tokens remain staked.

stGOV: Tally's liquid staking token implementation for governance tokens.

Rebasing LST: A liquid staking token whose balance automatically increases as rewards accrue.

Fixed LST: A liquid staking token with a fixed balance where the token-to-underlying exchange rate changes as rewards accrue.

Withdraw Gate: A contract that enforces a configurable delay when unstaking to prevent reward gaming.

Reward Mechanisms

Reward Source: The origin of rewards distributed to stakers (e.g., protocol fees, treasury, or token emissions).

Protocol Revenue: Fees generated by a protocol's operations that can be distributed to stakers.

Stake Streak: A mechanism that increases rewards based on how long a user has been staking continuously.

Bump: The process of updating a deposit's earning power, which may be incentivized with a small reward.

Reward Rate: The speed at which rewards are distributed per unit of time.

Advanced Concepts

Oracle-Based Earning Power: A system where external data feeds influence staking rewards, such as delegatee activity scores.

Overwhelming Support Auto-Delegate: A delegation strategy that only votes on proposals with significant consensus.

Dual Staking: The ability to use staked tokens for multiple purposes simultaneously, such as with EigenLayer.

Restaking: Using already-staked tokens to secure additional protocols or services.

Technical Terms

ERC20: The standard interface for fungible tokens on Ethereum.

ERC20Votes: An extension to ERC20 that supports vote delegation.

EIP-2612: A standard allowing gasless approvals using signed messages.

Permit: A function that processes signed approvals without requiring separate transactions.

OnBehalf: Methods that allow actions to be performed on behalf of users via signatures.

Regardless of voting system used (on or off chain, weighted by users or token holdings), the vote itself doesn't trigger execution of the proposal's effects. Instead, the vote serves as instructions for the multisig signers to execute the proposal using their admin priveledges.

Tally supports a variety of onchain voting mechanisms.

Private voting encrypts individual votes onchain while maintaining verifiable final results. Votes are encrypted when cast and only decrypted after the voting period ends, revealing the final tally while preserving voter privacy.

Users can create an onchain proposals of a snapshot proposal on the Tally platform. Voters should use the diff checker to view check what differences are made, if any, in the new onchain proposal on Tally.

Partial delegation is a voting mechanism that allows token holders to split voting power across multiple delegates rather than assigning it all to a single delegate. For example, if a user controls 1000 tokens, the user could delegate 400 tokens to Delegate A, 400 tokens to Delegate B, and self-delegate the remaining tokens.

To support protocols on a new network, Tally needs to integrate that network into its system. This integration enables all organizations on the new network to utilize our platform's features and services. The integration process typically takes 5-10 business days to complete.

Implementation

Steps

1. Node integration: Tally integrates the network's (and testnet's) archive node RPC endpoints with our indexers.

2. Self-serve DAO addition: Tally adds support for the new network in our self-serve flow, allowing new DAOs on this network to be easily added to our platform.

3. Block explorer integration: Tally integrates the network's block explorer into our system for seamless transaction and address lookups.

4. API support: Tally provides API access to the network's data for all DAOs added to the platform.

Getting Started

If you're interested in having your network integrated, please contact Tally’s sales team (sales@tally.xyz) with the required information. Once Tally has the necessary details, the integration process can begin as soon as the next business day.

Support

For any questions or assistance during the integration process, please reach out to our dedicated support team via email at support@tally.xyz.

Council elections are a pivotal aspect of decentralized governance, ensuring that the guardianship of a DAO remains in the hands of its community. Elections serve as a testament to the democratic ethos of DAOs, allowing stakeholders to have a say in selecting the individuals who will be at the forefront of safeguarding their interests.

Through a transparent and structured process, they aim to identify and empower those with the expertise, vision, and commitment to navigate the challenges that may arise, all while upholding the principles and objectives of the DAO. It's not just about choosing leaders; it's about reinforcing trust, fostering accountability, and ensuring that the DAO's security apparatus remains robust and responsive.

With Tally's custom-built council elections, elevate your DAO's council elections to the highest standards of excellence and integrity.

What is a council?

Why should I care?

What is a council?

In the rapidly evolving world of DAOs, a council serves as a mechanism for stability and security. It consists of designated members with the authority to make necessary changes to the protocol during emergencies. The council's role is not only to govern but also to address potential threats, ensuring the DAO's security and adaptability.

Roles and Responsibilities

A council is comprised of a certain number of members who are entrusted with the responsibility of making urgent modifications to the protocol during emergencies. Their roles are usually outlined as follows:

• Emergency Actions: Addressing critical situations that demand immediate attention, such as potential risks to users' funds. To execute emergency actions, a consensus of a certain number of members is required.

• Routine Operations: Apart from emergencies, the council also supervises routine software updates, maintenance, and parameter adjustments, which are considered as "Non-Emergency Actions".

Election Process

To ensure accountability and infusion of fresh perspectives, the members of the Security Council are elected democratically on a semi-annual basis. Tally can customize all aspects of the election process. Typically, it is structured as follows:

• Nomination: Initially, contenders register to become nominees, requiring a certain percentage of votes.

• Compliance Period: A period for the foundation to vet the nominees.

• Election Period: A period where delegates vote for the nominees, with the voting weight decreasing linearly over the last two weeks.

• Results and Implementation: Following the election, the top nominees become the new members of the Security Council, with the results undergoing various time locks before the new members are integrated into the council.

Security Measures

A Security Council operates within a framework that emphasizes security by design, incorporating the following elements:

• Constrained Access: Access to the Upgrade Executor, a core component of the governance system, is strictly limited to prevent unauthorized or malicious activities.

• Reuse of Existing Architecture: Leveraging existing secure infrastructure to avoid the introduction of new contracts that would require additional security measures.

• Adherence to Specifications: The implementation strictly adheres to the guidelines outlined in the DAO's official documentation, ensuring the intended security properties are met.

Why should I care?

As a stakeholder in a DAO, the establishment of a Security Council—and an efficiently run election—should matter to you for several reasons:

• Security and Integrity: A council acts as a safeguard, protecting the system and its users from potential threats and vulnerabilities.

• Adaptability: It ensures that the DAO remains versatile and capable of adapting to changing circumstances without compromising its foundational principles.

• Democratic Governance: Elections at regular intervals foster a democratic environment, allowing for the inclusion of new skills and perspectives, and preventing the entrenchment of power.

• Resilience: In the face of emergencies, a council's swift actions help maintain the stability and functionality of the DAO, thereby preserving users' trust and investments.

Users can easily draft proposals using proposal templates that are set up by their DAO. Instead of manually locating, copying, and pasting a contract address for a custom action, users can conveniently create a proposal using their DAO’s custom contract address book. Additionally, proposals created using proposal templates are also more easily identifiable on the proposal page since they have human readable names.

Every blockchain interaction - whether casting a vote, delegating voting power, or creating governance proposals - requires participants to pay transaction fees (commonly known as "gas fees") on the underlying blockchain network. These fees represent a significant barrier to participation, potentially excluding valuable contributors and skewing governance decisions toward those with greater financial resources.

Introducing Relay: Removing Financial Barriers to Participation

Relay is a sponsorship system where DAOs can cover the transaction costs for their members' governance activities like voting and delegating. DAOs can now cover the costs that would otherwise prevent members from participating in crucial decisions.

How Relay Works

The technical foundation of Relay rests on OpenZeppelin Defender, a trusted security framework in the blockchain world. When a DAO enables Relay, they set aside a specific budget for governance transactions. As members participate in governance activities, Relay automatically handles the complex process of paying transaction fees, making the experience seamless for users - they can simply focus on making thoughtful governance decisions.

Tally maintains this service through a small fee on each transaction, ensuring the system remains sustainable while keeping costs manageable for DAOs. This approach is similar to how payment processors charge small fees to maintain their infrastructure while providing valuable services.

Benefits

Tally has processed hundreds of thousands of governance transactions, with associated gas fees reaching hundreds of thousands of dollars. These numbers represent not just costs, but potential barriers to participation. Each transaction fee could have been a reason for a valuable member to stay silent instead of contributing their perspective.

When DAOs sponsor transactions through Relay, they're making a powerful statement about their values. They're saying that every voice matters, regardless of a member's ability or willingness to pay gas fees. This commitment to inclusivity strengthens the entire governance ecosystem in several ways:

1. Enhanced Participation Metrics: By eliminating financial barriers, DAOs can expect increased engagement across their membership base, leading to more representative governance decisions.

2. Demographic Diversification: The removal of transaction cost barriers enables participation from a broader spectrum of community members, including those in regions where gas fees might represent a significant expense.

3. Governance Efficiency: With reduced friction in the voting and proposal processes, DAOs can achieve quicker decision-making cycles while maintaining high participation rates.

4. Long-term Sustainability: By investing in their members' ability to participate, DAOs strengthen their governance mechanisms and ensure continued operational vitality.

Optimistic Governance lets a small group of decision-makers propose changes, subject to a veto from the larger DAO. This accelerates operational efficiency by automating routine decisions while maintaining appropriate oversight.

It's best to build Optimistic Governance on battle-tested governance contracts like Governor and Timelock. These modular contracts plug into a rich ecosystem of DAO apps and tools like Tally.

Implementation

To implement Optimistic Governance, combine battle-tested governance contracts:

• One Council NFT contract that determines membership in the Optimistic Council.

• One ERC20 contract that determines voting power for vetoes.

• Two Governor contracts, the Optimistic Governor and the Veto Governor.

• One Timelock contract that holds the DAO assets and/or protocol.

Modifications from standard OZ Governor setup

• The Optimistic Governor has PROPOSER_ROLE role on the Timelock

• The Veto Governor hasCANCELLER_ROLE role on the Timelock. The veto Governor's voting period must be shorter than the timelock delay, so that it can cancel proposals in time

The parameters for gasless voting in the ENS DAO:

• Wallet must have ENS name registered as the wallet’s primary name

• Wallet must have at least 100 ENS in delegated voting power

• 8 votes per wallet (subject to increase)

Token holders can delegate their voting power, whether to themselves or a trusted delegate, with Relay generously covering the associated gas fees for these delegation transactions. The mechanism operates seamlessly as DAOs allocate a dedicated budget to Tally for the facilitation of these transactions.

However, certain restrictions are in place to ensure fair participation. To utilize this gasless delegation service, token holders must meet specific criteria, including holding the minimum token requirements stipulated by each DAO. For token holders who do not meet these eligibility criteria, conventional delegation remains an option, with the responsibility of covering gas fees falling on the individual.

The restrictions for free delegation are as follows:

1. Tally will only relay for token holders who hold at least a minimum number of governance tokens. The minimums vary per DAO: 10 ENS, 10 UNI, 30 GTC, 40 ARB, or 50 POOL.

2. Tally will only relay a delegation transaction once per wallet per DAO.

Currently, the following DAOs sponsor free delegation:

Delegates receive a karma score in their delegate profile reflective of how actively they participate in governance. Users can see the percentage of how often a delegate participates in governance both on and offchain, as well as how active they are in the DAO’s forums.

Voting

Secure, transparent, and efficient voting mechanisms to ensure that all governance decisions reflect the will of the community.

Proposal Execution

Automated execution of approved proposals.

Proposal Drafting and Collaboration

Collaborative proposal creation through tools designed to enable multiple contributors to work together seamlessly.

Proposal Creation with Arbitrary Executables

Proposals can be created with customizable executable actions.

No-Code Transfers

Easy and secure fund transfers within the DAO without requiring any coding skills.

Wallet Support

Native support for a wide range of wallets, ensuring accessibility and convenience for all DAO members.

Public API

Tally's comprehensive public API can power custom governance applications and integrate with other tools and platforms within the EVM ecosystem.

DAO Analytics

Detailed analytics and insights into DAO activities, member engagement, proposal outcomes, and overall performance.

Currently, there is no cost for adding a DAO yourself on Tally however, a 0.25% fee will apply when proposals are executed. This fee does not apply for customers who partner with Tally for custom governance.

For assitance during the integration process, please reach out to our dedicated support team via email at support@tally.xyz.

The DAO page shows details about a specific DAO, including current and past proposals, assets, and delegates.

DAO Homepage

On the DAO Home page, key information & metrics are shown. You'll also see a button to Delegate vote on the right hand side along with your voting power information.

Proposals Page

The Proposals page shows a list of proposals associated with the DAO. Any active proposals will be shown at the top, with a chronological list of past proposals below. Click Load more to see more.

Click on a proposal to go to the relevant Proposal Page.

Community Page

The Community page offers an overview of the DAO's delegates. The Top Delegates chart shows the current top 5 delegates' voting power over time,

Clicking on a delegate's name will take you to the relevant Tally Profile.

Treasury

The Treasury page displays information on the DAO's top assets.

Below, the Gnosis Safes section displays information on any linked Gnosis Safes. Click on a Safe to access its Gnosis Safe Page.

Admins

More

You can access Contract Parameters from the More section.

Gnosis Safe is a smart contract multi-sig wallet running on Ethereum that requires a minimum number of people to approve a transaction before it can occur. This added layer of security helps to protect against the loss or theft of funds.

Creating a Gnosis Safe on Tally creates the exact same instance of Gnosis’s smart contract that Gnosis’s own app does, with the added benefit of managing it from the same Tally DAO that you may be using for Governor and Tokenless DAOs. Having your Gnosis Safe linked on Tally will also allow users to take advantage of Tally features such as the Create Proposal tool and Recipes.

Tally Zero is a completely decentralized voting application that uses React and IPFS via thirdweb. This app allows you to connect to any governor address and vote on a proposal in a completely decentralized way.

What is Tally Zero?

Features

Decentralization

Tally Zero is built using React and IPFS via ThirdWeb, which ensures that the application is completely decentralized. This means that it does not rely on any central authority or single point of failure, making it resilient and secure.

Onchain Voting on the application allows users to connect to any governor address and vote on a proposal in a completely decentralized manner. This ensures that the voting process is transparent, secure, and tamper-proof.

Zero Dependency

Tally Zero is designed to be a zero-dependency application. This means that it does not rely on any external services or applications to function. Even if other front ends are down, Tally Zero will still be operational, ensuring that people can always vote onchain.

IPFS Deployed

The application is deployed on IPFS, a peer-to-peer hypermedia protocol designed to make the web faster, safer, and more open. This ensures that the application is accessible from anywhere in the world and is resistant to censorship.

How To

Case Study

In June 2023, AWS had a compute outage that affected Tally during a big vote in Aribtrum DAO. Voting through the outage was made possible by Tally Zero.

Whether you're a developer, a data enthusiast, or an organization aiming to integrate governance into your platform, the Tally API is designed with you in mind.

Why choose the Tally API?

• Comprehensive Data Access: Dive deep into the world of Governor DAOs. From listing Governors to exploring on-chain proposals and accounts with delegations, we've got you covered.

• Versatility: Dreaming of building a notification system for DAO proposals? Or perhaps integrating governance mechanics into your next big game? The Tally API supports a myriad of applications.

• Ease of Use: With our GraphQL-based API, you only request the data you need. Plus, with GraphQL's self-documenting nature, you'll find it a breeze to navigate and understand our API's capabilities.

• Robust Support: Our community and support channels are always ready to assist. Whether you're just getting started or need advanced technical support, we're here for you in our Discord.

How to Use the Tally API

Get an API key

You'll need to include that API key as an HTTP header with every request, i.e. {"Api-Key": "YOUR_KEY_HERE"}

Quickstart example

API docs

Graphql playground

Note that the playground also includes undocumented endpoints. Using them is not recommended for production apps, because they are subject to change without notice.

Rate limits

Once you've signed in to Tally, you can click your profile name at the top right to access the profile drop-down menu.

Tally Profile

Your DAOs

The Your DAOs page shows all the DAOs you're a member of.

Your DAOs shows a list of all of the DAOs you're a member of, split into two sections: DAOs you manage (DAOs where you have the SuperAdmin or Admin role), and DAO memberships. Click on any DAO to navigate to its DAO Page.

Profile

A Tally Profile shows details about that wallet's DAO Memberships and POAPs. It also includes information the user has added via Settings.

At the top, you'll see a voter's display name, wallet address, and linked Twitter account. You'll also see a Delegate button, which allows you to delegate your voting power to that address.

Below, you'll see that voter's DAO Memberships, with information on their voting power and delegations for each DAO.

The POAPs section displays POAPs held by the address.

Settings

Update the information shown on your Tally Profile by accessing Settings from the drop-down menu or clicking the Edit Profile button from your Tally Profile.

Click the Edit button to make changes.

The information you enter in Settings is public to everyone. The data in your Tally Profile is a mix of onchain data and off-chain data. Editing your Tally Profile adds off-chain data to the onchain data for your address. In some cases, it overrides the onchain data (e.g. your Tally name and avatar override your address’s ENS name and avatar, if any).

• Update your Tally username.

• Choose a PFP from your wallet or upload an image.

• Update your Bio to tell us a bit about you!

• Link your Twitter account.

• Generate a Tally API key. Visit our API Portal to learn more!

Log Out

Click Log out to sign out of your Tally Profile.

To submit an onchain proposal, you must have sufficient voting power to meet the DAO's Proposal threshold. This figure can be found on each DAO Page by expanding the Contract Parameters section near the top of the page.

Create a Proposal

If you haven't yet connected your wallet, Tally will prompt you to do so. Most governance frameworks require a proposal threshold - a minimum amount of voting power - to create a proposal. Make sure you connect with the tokens required to create a proposal in it. Then click Continue.

Enter a Title for your proposal, then add a Description. Explain the intent behind the proposal and include any helpful context for the voters.

Add actions to be executed if the proposal passes. You can select Tally's Transfer Tokens recipe for a proposal that calls for the transfer of tokens, or select the Custom Action button.

Note: Governor Alpha/Bravo has a limit of 10 actions. There is no limit for OpenZeppelin Governor.

If you choose the Transfer tokens recipe, enter the Target wallet address, select the Token you would like to transfer, and enter the Value of the token you would like to transfer. Enter a Memo to describe the purpose of the transfer, and optionally, upload a Media image such as an invoice. Tally will populate an infographic as a preview of the recipe.

For a Custom action, enter the Target contract address or upload your ABI file if the contract is not on Etherscan. Select the desired Contract method, and enter the call data for that method.

Actionless Proposals: If you choose to skip this step, and create a proposal with no actions, a transfer of 0 ETH to you (the proposer) will be added, as Governor requires one executable action for the proposal to be submitted onchain.

Preview your proposal, then select Save draft or Publish. If you're ready to submit the proposal onchain, you'll also need to sign the transaction to the chain using your wallet. Draft proposals are created offchain and can later be submitted onchain at any time. Draft proposals can be created and submitted by different users.

Running Proposal Simulations

Having successful validations will give proposers, voters, and executors confidence that the proposal is valid. The Proposal Simulations feature is currently in beta and runs via the Tenderly Simulator API. Tally simulates the execution of the proposal assuming it is successful and queued on a fork of your DAO's network. From there, Tally runs each executable payload, impersonating the treasury (usually the timelock).

When creating a proposal on Tally, the API will automatically run a simulation for the executable payload provided. You can view the result of this simulation in the Executable code tab of the proposal details. Each function will have its own result.

If one function fails, it is likely that the proposal execution will fail. If the function failed, click View raw result to inspect the response from the Tenderly Simulator API for additional insights. If the function fails or in cases when state changes may impact the success of a function, you may also want to re-run the simulation of the proposal.

For example, a DAO proposes to transfer 1 ETH to an address, but their treasury has 0 ETH. As you might expect, the simulation result fails. From there, the DAO funds their treasury with 2 ETH; click Re-run to re-simulate the proposal. You should now expect a successful proposal!

Custom Actions on Tally provide a versatile way to create and manage DAO proposals with complex requirements. These actions enable users to execute a variety of operations within a single proposal. Custom actions include any onchain action that Tally does not have a custom UI for (ex: token transfers).

Tally has recipe books for the following custom actions:

Each action involves targeting specific contract addresses, selecting appropriate contract methods, and setting calldata according to the needs of the specific operation being proposed. This flexibility allows for a wide range of governance activities to be conducted seamlessly.

Using Custom Actions

To include custom actions in your proposal on Tally, enter the Target contract address or upload your ABI file if the contract is not on Etherscan. Select the desired Contract method, and enter the call data for that method.

You can make a proposal on Tally to deploy Uniswap v3 on a fresh EVM chain.

The first step of launching Uniswap V3 on a fresh EVM chain is to deploy the smart contracts that comprise the protocol. To simplify this process, Uniswap Labs has devised deployment scripts and management CLI, ensuring a smooth rollout of the required contracts onto a new EVM chain.

Simply set up and fund a deployment account to cover the gas charges (estimating 40-50M gas). Then, execute a single command within the CLI. This will sequentially deploy each contract, marking checkpoints that can be rolled back if complications arise.

How to make a proposal to deploy Uniswap v3 on a fresh chain

Make a proposal on Tally using Custom Actions.

• Target contract address: 0x4976fb03C32e5B8cfe2b6cCB31c09Ba78EBaBa41 (the public ENS resolver address)

• Contract method: setText

• Calldatas:

  • node: 0x0b9638d2c5bd4528d603562a1fa1e734fe1b88e680f448d779531e9bc2b55f12 (the hash of v3deployments.uniswap.eth)

  • key: network key of chain you're deploying to

  • value: address of v3 factory on that network

Resources

Grants by Hedgey come in a few forms, so it is important to decide beforehand which version is most appropriate for your grant needs. Grants is at its core a simple distribution mechanism to distribute tokens to the grantees, with a public dashboard, and bake in time based milestones when the grantees will receive the tokens. Grants can be either revocable, or non-revocable, include ability to participate in governance with Tally, or can prevented from governance participation. Other key features include linear (streaming) or periodic time-based distribution schedules.

Revocable vs Non-revocable Grants

For your grants distribution, you will need to make a decision on whether grants are revocable or not. A good rule of thumb is that for retroactive public goods funding, and other retroactive grants mechanisms, the milestones have already been achieved; so, the non-revocable grant is a great distribution mechanism to distribute tokens over time automatically, instead of simply disbursing tokens directly.

Conversely, revocable grants are a solution for grantees that are expected to perform tasks and achieve milestones, or distribute incentives and rewards, in the future. With a revocable grant, if the grantee does not meet their milestones, or for any other reason, the DAO can claw back the tokens from the grantee based on their vesting schedule - which is often configured to align with the time based milestones.

Preparation

Before creating the grants proposal, you should prepare the data that will be pasted into Tally and be delivered to the Hedgey smart contract upon execution of the approved proposal.

Requirements:

1. Token Contract Address: <ERC-20 Token Contract Address>

2. Hedgey Batch Contract Address: 0x3466EB008EDD8d5052446293D1a7D212cb65C646

3. Hedgey Grants Contract: <Hedgey Smart contract - depends on revocable & voting grid below>

1. Distribution Frequency / Period: This determines (in seconds) how frequently tokens are distributed to grantees. For the “streaming” version, this would be 1, where a small amount of tokens is distributed and claimable each second. Here are some other handy periods:

1. Grant Recipients Details:

   1. Recipient Address

   2. Total amount of Tokens to be distributed

   3. Start date (in unix time)

   4. Cliff date (in unix time)

   5. Rate: the amount of tokens that vest in each period

How to Create the Grants Distributions

With your prepared data at hand, navigate to the Tally portal and create your proposal. In the "Custom Actions" section, you will need to input two actions: the first is the ERC-20 token allowance approval, and the second is the actual Hedgey Grants creation transaction.

Action #1

1. Target Contract address: the Address of your DAO Token or ERC-20 Token to be used for grants

2. Contract method: ‘approve’

3. Calldatas: spender: 0x3466EB008EDD8d5052446293D1a7D212cb65C646 (the Hedgey Batch Planner contract address)

4. amount: the total amount that you will deploy in the grants batch

Action #2

Paste in the BatchPlanner contract 0x3466EB008EDD8d5052446293D1a7D212cb65C646, and then we need to select one of two methods.

If you are distributing Revocable Grants, choose the “batchVestingPlans” method. If you are distributing Non-revocable Grants, choose the “batchLockingPlans” method.

Inputs are as follows:

• Locker: <Hedgey Contract Address>

• Token: address of your DAO token

• totalAmount: the total amount of tokens to be distributed to grant recipients

• Plans: this is an array (tuple) of each grants plan, which you can paste in the details of each recipient individually

  • Recipient: address of grant recipient

  • Amount: total amount of tokens they will granted (include decimals)

  • Start: Unix time stamp of when the unlocking will start

  • Cliff: Unix time stamp of an optional cliff, if no cliff you can input 0 or the start date

  • Rate: The amount of tokens that unlock each period - use the spreadsheet helper

• Period: the seconds in the period for vesting

• vestingAdmin: the admin of the vesting plans who can revoke plans - only for revocable grants

• adminTransferOBO: this allows the vestingAdmin to transfer plans on the recipients behalf in the case of emergency

• mintType: 7; this is a specific number for the Hedgey dApp to display things properly

For non-revocable grants, still use mintType 7, but the vestingAdmin and adminTransferOBO functions will not be required.

Key features include linear/periodic unlock strategies, onchain governance voting, customizable dates, governance rights to vesting tokens, admin features for transferring vesting plans, delegation of vesting plans to multiple addresses, and beneficiaries' ability to claim tokens at their discretion. The contracts are fully onchain, ensuring interaction even without Hedgey UIs​​.

How to call Hedgey’s Contract

You can create vesting plans one at a time or multiple in the same transaction. You need to add 2 custom actions to a proposal.

Creating Vesting Plans

1. The first custom action is to approve the allowance for the Hedgey contract to spend the tokens to create vesting plans.

   • Target contract address: the address of your DAO governance token, or whatever token you are planning to use for vesting

   • Contract method: approve

   • Calldatas:

     • spender: 0x3466EB008EDD8d5052446293D1a7D212cb65C646 (the Hedgey Batch Planner contract address)

     • amount: the total amount that you will deploy in the vesting batch
2. Create a second custom action with the following.

   • Target contract address: 0x3466EB008EDD8d5052446293D1a7D212cb65C646

   • Contract method: batchVestingPlans

Then, input the parameters as follows:

• Locker: 0x1bb64AF7FE05fc69c740609267d2AbE3e119Ef82 (address of the vesting plans contract)

• Token: address of your DAO token

• totalAmount: the total amount of tokens to be distributed to vesting recipients

• Plans: this is an array (tuple) of each grants plan, which you can paste in the details of each recipient individually

  • Recipient: address of grant recipient

  • Amount: total amount of tokens they will granted (include decimals)

  • Start: Unix time stamp of when the unlocking will start

  • Cliff: Unix time stamp of an optional cliff, if no cliff you can input 0 or the start date

  • Rate: The amount of tokens that unlock each period - use the spreadsheet helper

• Period: the seconds in the period for vesting, so for instance use a 1 for a streaming style period.

• vestingAdmin: the admin of the vesting plans who can revoke plans

• adminTransferOBO: this allows the vestingAdmin to transfer plans on the recipients behalf in the case of emergency

• mintType: 7; this is a specific number for the Hedgey dApp to display things properly.

Note all of the plans batched need to have the same period and vesting admin.

Help with Rates

Consider the following example:

If you have a specified total amount of tokens, for example 100,000, that you are distributing with a 2-year vesting term, the calculation for streaming would be different than for monthly payments.

For streaming: The vesting term spans 63,072,000 seconds, as there are 31,536,000 seconds in a year. Assuming your token has 18 decimals, you would calculate the rate of token distribution per second as follows: (100,000 * (10^18)) / 63,072,000 = 1,585,489,599,188,230. If your token has a different number of decimals, replace 18 with the appropriate number in the formula.

For monthly payments: Over a 2-year vesting term, there are 24 discrete periods (months). The calculation for the rate of token distribution per month would be: (100,000 / 24) * (10^18) = 4,167 * (10^18). This implies that 4,167 tokens will vest each month. However, in the last month, only 4,159 tokens will vest to complete the total distribution of 100,000 tokens.

Test proposals appear on the DAO homepage indefinitely. Tally does not delete test proposals to maintain operational security.

Streaming refers to the continuous transfer of tokens over time from one account to another. Instead of sending a lump sum of tokens in a single transaction, streaming allows for the gradual and real-time transfer of funds.

How to call Sablier's contract

To call Sablier's contract, there are three steps:

2. Enter that address into Tally's Custom action.

1. Pick the method that you want to call.

How to make a proposal to stream ERC-20 tokens

Spending Approval

Before interacting with the Sablier contracts, the first step is to approve the spending of the token you are looking to use. If you want to stream DAI, for example, you will need to approve the spending of a certain amount of DAI. This is not done in our own contracts, but instead, in the contract of the token you are looking to spend.

The ERC-20 implementation has a function called approve, which is the function we are going to call. Let’s say we want to stream 3141 DAI. The approval call will look like this:

Signature: approve(address,uint256)

Calldata:
address: 0xB10daee1FCF62243aE27776D7a92D39dC8740f95
uint256: 3141000000000000000000

Target: 0x6B175474E89094C44Da98b954EedeAC495271d0F
Value: 0

In the example above, the Signature field highlights the function to be called. In the Calldata field, the address field is the contract address of the Sablier contract you are looking to interact with, and uint256 is the amount of tokens you are looking to spend, decimals included.

This is important. Different tokens have different amounts of decimals. For example, USDC has 6 decimals and DAI has 18 decimals.

If the token you are looking to spend has 18 decimals, as is the case with DAI, you will need to add eighteen 0s to the amount you are looking to spend. If you want to stream 542 DAI, that means that the actual amount you will need to put in will be 542000000000000000000.

Note: If the amount you are trying to send already has decimals (for example, 124.5 DAI), you will need to subtract the amount of decimals in the amount from the amount of 0s that you need to add. To make this clearer, if you are looking to stream 124.5 DAI, meaning an amount with 1 decimal, you will only need to add seventeen 0s as opposed to eighteen, as there is already a decimal included in the amount. In this case, the deposit amount will look like this: 124500000000000000000."

Finally, the Target value is the contract address of the token you are looking to stream, with the Value field having no relevance here given we won’t spend any ETH in this transaction; we are merely approving the spending of a certain ERC-20 token.

On every chain Sablier is deployed on, there are two contracts you can interact with to create streams:

• SablierV2LockupLinear: allows you to create linear streams, with or without cliffs.

• SablierV2LockupDynamic: allows you to create streams with dynamic payment curves, including non-linear ones.

We have approved the spending of our token, so we can create the actual stream now.

Stream Creation

In this example, we will focus on LockupLinear as opposed to LockupDynamic, as interacting with the latter is harder. We recommend reaching out to the Sablier team if you are interested in doing that.

There are two ways to create a stream in LockupLinear:

• CreateWithDurations: allows you to create a stream that will start as soon as the stream creation transaction is included in the blockchain, which will run for a specific duration.

• CreateWithRange: allows you to create a stream that will start on a specific date and will end on a specific date.

Both ways support cliffs, and differ only slightly in the way you call them programmatically in Sablier's contracts.

Here is an example of what a function call with CreateWithRange looks like:

Signature: createWithRange(tuple)

Calldata:
tuple: [0xB57Ab8767CAe33bE61fF15167134861865F7D22C, 0xC09c8905cd3112deE53BbFBdeBC1e9C9963BD325, 3141000000000000000000, 0x6B175474E89094C44Da98b954EedeAC495271d0F, true, true, [1689811200, 1689811200, 1721433600], [0x0000000000000000000000000000000000000000, 0]]

Target: 0xB10daee1FCF62243aE27776D7a92D39dC8740f95
Value: 0

As in the previous spending approval example, the Signature field highlights the function we are calling. The Target field represents the contract we are calling, which in this case is the SablierV2LockupLinear contract on Mainnet. And as in our last example, the Value field can be set to 0.

We will now take an interest in the Calldata field, and specifically the tuple it contains.

The structure of the tuple is as follows:

tuple: [
  sender address,
  recipient address,
  amount (decimals included),
  token contract address,
  cancelable (true/false),
  transferable (true/false),
  [
    start date (unix timesteamp),
    cliff date (unix timesteamp),
    end date (unix timesteamp)
  ],
  [
    broker address,
    broker fee
  ]
]

Let’s go over them one by one:

• sender address: this is the address you are funding the stream with, which will also have the ability to cancel the stream.

• recipient address: the address you are looking to stream the funds to. They will be able to subsequently withdraw funds from the stream.

• amount (decimals included): the amount of tokens you are looking to stream, with decimals included, as previously explained. Numbers have to be sent between quotation marks, meaning if a parameter's value is 100.0, it should be written as "100.0".

• token contract address: the contract address of the ERC-20 token you are looking to stream.

• cancelable (true/false): whether or not the stream should be cancelable. We will go over this more in a minute.

• transferable (true/false): whether or not the stream is transferable to someone else. We will go over this more in a minute.

• start date (unix timestamp): the start date of the stream, as a UNIX timestamp. The Unix Timestamp is in seconds, not to be confused with milliseconds.

• cliff date (unix timestamp): the cliff date of the stream, as a UNIX timestamp. We will go over this more in a minute.

• end date (unix timestamp): the end date of the stream.

• broker address: the broker address. If you don’t know what this is, you don't need it. Simply set it to 0x0000000000000000000000000000000000000000 as laid out in the example.

• broker fee: the broker fee. Again, if you don’t know what this is, you don’t need it. Simply set it to 0.

Regarding cancelation, all streams in Sablier V2 have a cancelation setting.

If it’s set to true, that means that the stream can be canceled at any time by the stream creator. The stream creator is the DAO. Canceling the stream will stop it and return the funds which haven’t yet been streamed over to the stream creator. If the DAO wants to cancel a cancellable stream, generally that will require another proposal.

If it’s set to false, the stream is non-cancelable, which means that it cannot be stopped. The recipient is then guaranteed to receive the funds in the stream, no matter what happens. Setting the stream as non-cancelable is an irreversible action, there’s no way to make it cancelable afterwards.

Regarding transferability, all streams in Sablier V2 are represented by an NFT owned by the stream recipient. Whoever owns the NFT is the recipient of the stream.

If transferability is set to true, the NFT (and by extension the stream) is transferable to someone else. This means the recipient could send the stream over to another address they own, or they could send it over to someone else. It also means the stream could be sold on OpenSea by the recipient without the vesting period being over. Or they could theoretically borrow against it in an NFT lending protocol by using it as collateral.

If transferability is set to false, the NFT cannot be transferred to someone else. The recipient will not be able to sell it to someone else on a marketplace like OpenSea, and they won’t be able to borrow against it in an NFT lending protocol.

Regarding the cliff date, it’s a cut-off point for releasing assets. Prior to the cliff, the recipient cannot withdraw, though assets continue to accrue in the stream. If you don’t want a cliff, you simply set the same date there as the start date.

If you want a cliff, you can set a date in the future depending on how long you want your cliff to last. If you want a 1-month cliff, and your stream starts on January 1st, your will cliff date will need to be on February 1st.

CreateWithDuration differs only slightly, as can be seen in the following tuple:

tuple: [
  sender address,
  recipient address,
  amount (decimals included),
  token contract address,
  cancelable (true/false),
  transferable (true/false),
  [
    cliff duration (seconds),
    total (seconds)
  ],
  [
    broker address,
    broker fee
  ]
]

As you may have noticed, the only different part is the following section:

[
  cliff duration (seconds),
  total (seconds)
]

Instead of having a start date, cliff date, and end date, as in CreateWithRange, the CreateWithDurations function only requires a cliff duration (in seconds), and the total stream duration (also in seconds).

There is no start date or end date required, as the stream will start as soon as the stream creation transaction is validated. Once that’s done, the stream starts and will last for the total duration.

Swap Proposal in 5 Steps

3. Upon proposal passage and execution, the proposal puts the Milkman market order onchain.

5. CoW solvers compete to fill the order at the best price.

More questions? See Swaps: FAQs.

Tally's Custom Action builder supports the tuple[] type, called tuple arrays.

What are tuple arrays?

The tupletype in Soldity is a data structure that contains a fixed number of elements, each of which can be of a different type. For instance, a tuple can contain an integer, a string, and a boolean value all together. The tuple[]type, called a "tuple array", contains a list of tuples.

Building a tuple array

To create a proposal with a tuple array, add Custom Actions to your proposal. Then, use the imported ABI. Tally will infer the type from the ABI and help build the tuple array.

Nested tuples

If a tuple or tuple array is nested in another tuple, enter the nested tuple(s) in plaintext with brackets. This tuple builder contains two nested tuple arrays, contactDetailsand chains , and one nested tuple bountyTerms :

To add tuple arrays and tuples, enter them in plaintext:

Where do the quotes come from?

Quoted price is not guaranteed

Upon proposal creation, you will receive a quote from CoW based on current market conditions. However, market conditions may change by the time of proposal execution, and a new quote from CoW will be used to create your order.

What is a price checker?

The default price checker on Tally uses Uniswap v3 as a price oracle and sets a max slippage. Custom price checkers can implement any logic they want.

Milkman price checker

What happens if the price checker doesn't see a good price?

How does the Uniswap price checker work?

Tally's default price checker uses the Uniswap V3 oracle to get market prices.

If you select this price checker, Tally suggests a max slippage and picks the Uniswap pair(s) to use for the price oracle.

If there is not a direct path (e.g. COMP<>USDT), Tally will try to make a “bridge” with two pairs, e.g. COMP->WETH->USDT instead of COMP->USDT. If that doesn’t work, you’ll have to make a custom price checker route.

Example Using the Uniswap Price Checker

Note that steps 3-7 happen after the Governor proposal.

1. You want to sell 5 COMP to buy USDT

2. You create an order with Milkman. You set the price checker to use the Uniswap v3 oracle oracle and to accept 10% slippage.

3. That milkman order goes onchain. Solvers compete to offer the best price for your order.

4. The best offer from CoW solvers is 100 USDT for 5 COMP.

5. The price checker uses the Uniswap v3 oracle. The Uni v3 price is 21 USDT for 1 COMP.

6. The price checker confirms that the best offer is greater than the market price with slippage. Here’s the logic:

   The offer of

   100 USDT / 5 COMP = 20 USDT per COMP

   is greater than the price checker’s limit of

   21 USDT per COMP * 0.9 slippage = 18.9 COMP

7. The price checker allows the order to execute on CoW protocol

If no solver comes up with a price greater than 90% of the oracle’s market price, then the order will sit unfilled until someone does. This order can also be canceled by whoever has the cancel role. In the context of a Governor proposal, that’s the DAO, as it is the entity that request the swap.

How do I use a custom price checker?

You will need to find the contract address of a price checker and encode the data it can use to determine if the order gets a good price, usually slippage and a swap path. You may need to find a custom price checker that Custom price checkers can do anything, though.

What is in the Swap Recipe executable?

A Swap Recipe usually includes two executable calls.

1. approve Milkman to spend sell token

2. requestSwapExactTokensForTokens on Milkman

1. deposit ETH to WETH contract

2. approve Milkman to spend WETH

3. requestSwapExactTokensForTokens on Milkman

How do I read a swap peceipt?

When casting a vote for a swap, you should check the receipt for accuracy.

The quoted price provides a rough estimate of current market conditions before a swap is filled. The path and slippage show how the price checker will calculate the market price and how much slippage to accept.

After a swap is executed successfully, the Swap Receipt will link to the CoW order and to the order contract.

How do I cancel an order?

To cancel an order, the Governor must call cancel on Milkman via an onchain proposal. Only the governor has authority to cancel an order. Canceling the order returns the assets that were for sale to the treasury.

Why is an order stuck in Pending execution?

This means that the order isn’t placed yet. The governor proposal has not yet been executed. Once the proposal has been executed, it will create an order on CoW via Milkman.

Why is there so much slippage in small orders?

Solvers pay gas to take an order. If the gas costs are large compared to the size of the trade, you’ll need high slippage to ensure that the solvers can make a profit after gas costs.

What are draft proposals?

Want some feedback on your proposal before it goes live? Keen to write it and have someone else submit it?

Draft proposals provide a more efficient and flexible way to get things done in DAOs. Draft proposals allow DAO contributors to save their proposals offchain in an easily digestible format for review before submitting them onchain.

Key Features

1. Gather Feedback: Users can easily gather feedback on DAO proposals before submitting them onchain.

2. Retain Context: All draft proposal metadata is recorded and included in the onchain proposal when submitted.

3. Flexibility in Submission: Draft proposals are created offchain and can later be submitted onchain at any time. This makes it possible for different stakeholders to create the proposal and ultimately submit it.

How to Save a Draft Proposal

How to Delete a Draft

If you've created a draft that you are no longer interested in using, you can delete it from the Preview screen: just open the overflow menu in the top right and select "Delete draft".

Advanced execution refers to the execution of actions specified in a proposal as soon as it is passed.

Basic Execution vs Advanced Execution

In a basic execution scenario, a proposal, once approved by the DAO members, would need to be manually executed by someone, usually a DAO member or a designated executor. This manual step can introduce delays and is dependent on human intervention.

On the other hand, advanced execution involves setting up smart contracts and automated processes to execute the actions specified in a proposal as soon as it is approved. This can include sending funds to a specified address, but can also involve more complex actions such as interacting with other smart contracts, triggering certain functions, or even a series of actions that need to be executed in a specific order.

Use Cases

One common use case for advanced execution involves interacting with a cross-chain bridge in a situation where the exact cost of the transaction is not known in advance. For example, a DAO may have a timelock contract that currently has no funds in it, and they need to send an instruction to a cross-chain bridge. However, the bridge charges a fee for moving messages from one blockchain to another, and the exact cost of this fee is not known until the transaction is executed. As a result, it is not possible to specify the fee when creating the proposal.

In such scenarios, advanced execution can be extremely useful as it allows the DAO to write the smart contract code in such a way that the necessary funds (e.g., ETH) can be sent to the execute function at the time of execution, which then gets forwarded to the timelock contract, and ultimately to the final destination (the cross-chain bridge).

How does this work?

Advanced execution works by allowing the smart contract underlying a proposal to include more sophisticated logic and actions that can be executed automatically once the proposal is approved.

In the example above, the smart contract code for the proposal could be written to include a function that sends ETH to the execute function of the contract. This ETH would then be forwarded to the timelock contract, and then to the final destination (the cross-chain bridge). This way, even though the exact fee for the cross-chain bridge is not known at the time of creating the proposal, the necessary funds can still be sent at the time of execution.

How to use Advanced Execution

When a proposal is created, then you can enter some ETH value to send in the Custom Action’s recipe.

To use advanced execution, you need to include the necessary logic and actions in the smart contract code underlying the proposal.

When creating a proposal, you can specify the amount of ETH (or any other token) to be sent as part of the Custom Action’s recipe. This is the set of instructions that will be executed if the proposal is approved.

For example, you could specify that a certain amount of ETH should be sent to the execute function of the contract as part of the Custom Action’s recipe. This ETH would then be forwarded to the timelock contract and then to the final destination as specified in the smart contract code.

Select Community.

You can search by ENS name or wallet address. You can sort delegates by Voting Power and Received Delegations. You can also choose a Focus Area from the All Focus Areas dropdown menu.

Click the Delegate button to easily delegate your voting power to that DAO member, or click on their profile name to learn more about their participation in the DAO.

Tally is the home for DAO delegation, on Tally you can:

Delegate Voting Power

To vote in a Governor DAO you must delegate tokens to yourself or to another address.

Explore Delegates

Easily explore all delegates in a DAO. Filter by voting power, popular delegates, or the issues you care about (Public Goods, Security, and more).

Campaign as a Delegate

Create a delegate statement, link your twitter, and signal to voters what issues you care about.

Besides creating and voting on proposals, users can also: queue, execute, and cancel.

Queuing and Executing Proposals

Once a proposal passes, you can queue and execute it from the same place you voted:

What does it mean to “queue” a proposal?

Queue prepares a proposal for execution. The queue action sends the proposal to the Timelock contract, which starts the countdown until the proposal can be executed.

Someone needs to call the queue() function because the EVM (Ethereum Virtual Machine) does not support scheduled or automatic calls. Every call must be kicked off by a user.

If a Governor does not have a Timelock, then proposals don’t need to be queued. They can be executed as soon as the proposal passes.

Who can queue a proposal?

Generally, anyone can queue a proposal that has passed! The only exception is that some custom Governor contracts limit who can call queue().

How long will the proposal be queued?

What does it mean to “execute” a proposal?

Who can execute a proposal?

Generally, anyone can execute a proposal that has passed! The only exception is when a custom Governor contract limits who can call execute().

Canceling Proposals

To cancel a proposal, click the three-dot menu to access additional actions. You can also copy the proposal's URL and view contextual information.

When can a proposal be canceled?

It depends! There isn’t a standard version of cancel logic across Governor implementations. Governor Alpha, Governor Bravo and OpenZeppelin Governor each have different behavior.

OpenZeppelin Governor

OpenZeppelin Governor leaves the cancellation up to the developer implementing the contract. Many DAOs implement a Canceller role that gives a list of addresses the power to cancel proposals.

Governor Alpha

If the proposer’s voting power drops below the voting threshold, anyone can cancel that proposal.

Governor Bravo

Same as Governor Alpha. Also, the proposer can always cancel their proposal.

Can a canceled proposal be re-submitted?

Not if it’s the exact same one. To re-submit a proposal, create a new proposal with the same executable code.

Note that tokens you own are not active for voting until you delegate. You must delegate to yourself if you wish to vote on proposals directly with your own tokens.

How to Vote

Click on the Vote button in the upper right corner of the page.

In the Voting pop up, choose your vote— For, Against, or Abstain. (Note that Abstain isn't an option in all DAOs, depending on their contract setup.) If you'd like, add a comment to explain the reason for your vote to the rest of your DAO. Once you're done, click Submit.

Confirm and sign the transaction via your connected wallet (example below shows MetaMask confirmation).

Having trouble voting? There are a few common culprits to rule out...

Are your votes delegated?

Have you waited for Tally to index the onchain event?

Tally may still be indexing the vote—check back in a bit!

Ready to become a DAO delegate? Tell DAO members what you stand for by creating a delegation statement.

How to Create a Delegate Statement

2. Click on the DAO you want to create a statement for.

3. You'll see a Delegation Statement for that DAO directly beneath the header. Click Edit.

4. Click Edit at the top right of the Delegation Statement box.

   1. The next page allows you to populate your Delegate Profile. Click the box to indicate you're actively seeking delegations, then use the text editor to write and preview your full delegation statement. At the bottom, you can auto-generate a summary using AI, or choose to enter it manually.

5. Create a Delegate Profile.

6. Click the Save button at the top right to share your delegate statement live on Tally.

What is Delegation?

For DAOs that use the Governor contract, only delegated tokens can participate in voting. What does this mean for you, a token holder?

You must delegate your tokens to participate in voting. You may choose to delegate to others or to yourself.

If you wish to vote on proposals directly, delegate your voting power to your own address. Or, you can delegate your voting power to another community member and let them vote on your behalf. You can update your delegation at anytime.

Note: To vote on a proposal, votes must be delegated BEFORE the proposal is live. For security reasons, votes delegated during a proposal period cannot be used until the next proposal.

Delegate to Yourself

Delegate to Another Address

Re-Delegate & Un-Delegate

At any point, you have the complete freedom to re-delegate your tokens to a different address by following the same steps you initially used to delegate your tokens. This flexibility ensures that you can adapt to changing circumstances and align your delegation with your current preferences or strategies.

Additionally, you also have the option to undelegate your tokens, thereby reclaiming your voting power to participate directly in the decision-making process. This may be important if a vote you feel particularly strongly about comes up; you can take a more active role in the governance of the DAO whenever you feel it is necessary or appropriate.

All onchain transactions as Safe are supported and sent via the Safe transaction service instead of the connected EOA. Currently, the following transactions are supported:

• Submit proposal from the create proposal flow

• Submit proposal from draft page

• Vote on proposal

• Queue proposal

• Execute proposal

• Delegate voting power

We are also working on support for the following transactions as Safe:

• Vote in Council election

• Register for Council election

• Claim airdrop

Governance tokens like Uniswap's UNI and Wormhole's W can be staked for potential future rewards.

Subscribe to Tally Notifications to get emails when there's a new proposal in a DAO you follow.
Tally supports the following types of notifications:


1. New proposal - receive an email when a new
 proposal begins.

2. Proposals ending soon - if you have not voted on a proposal, receive an email when it has 24 hours remaining before votes close

3. Notification on voting results - receive an email when a proposal ends with the final results

How to enter and verify your email address

Access your Notifications Center

Enter your email address.

Type it into the modal.

Verify your email

We will send one-time verification code to the address you provided to ensure it is
accurate. Check your email inbox for a message from us containing the OTP. 
 It may take a moment to arrive.

Enter your OTP.

Return to the Notifications Center and input the code you received.

Complete verification process

Click confirm to complete the email verification process.

Subscribe to email notifications from a DAO

1. Navigate to the home page.

2. Search for the DAO you want to receive email notifications from.

3. Press the purple subscribe button.

You will receive a notification that you have successfully subscribed 
to email notifications from the specific DAO.

Unsubscribe from email notifications from a DAO.

1. Navigate to the home page.

2. Search for the DAO you want to unsubscribe from email notifications.

3. Press the unsubscribe button

You will receive a notification that you have successfully unsubscribed from email notifications from the specific DAO.

How to Vote with Safe

Sign In As Safe

Tally allows users to perform onchain transactions while signed in as Safe. You can also update your multisig Safe's profile on Tally.

In order to sign in with your Safe, you must first sign in with your personal wallet that is an owner of the Safe. Then, from the profile drop-down menu, select Sign in as Safe:

Next, select the Safe you want to sign in as from the menu:

Now you can update your Safe's profile and make onchain transactions. To learn more about making onchain transactions using your Safe, see Use Tally with a Gnosis Safe.

To switch back to your personal profile, simply select Switch to... from the profile drop-down menu.

You can also sign in as Safe using WalletConnect from the Safe mobile app, following:

Voting Steps

1. Navigate to the desired DAO page.

2. Scroll to the Proposal section

3. Choose the active proposal to vote.

4. Submit your vote.

About Gnosis Zodiac

Introduction

Features

Privileged Management

Once integrated, the Governor DAO becomes a privileged member of the Safe. This privilege includes the ability to add or remove signers on the safe, giving the Governor DAO full control over membership.

Transaction Control

The Governor DAO maintains control over the Safe's funds. It can spend money and execute transactions, allowing the parent DAO to maintain executive authority over its subsidiary structures.

Benefits

This design opens up several unique opportunities for DAO management:

1. It allows for the creation of SubDAOs, where a committee of experts act as signers on the multisig. Even while they operate independently, the parent DAO retains ultimate authority.

2. It is an ideal mechanism for delegating funds to Grants programs. The DAO maintains authority over both the funds and the Grants program administrators, ensuring a chain of responsibility.

3. It helps in avoiding centralization dangers, where Grants program administrators could potentially misuse funds without any onchain recourse.

4. It offers a solution to political disagreements among signers, preventing funds loss due to indecision or conflict.

5. It serves as a vital component in the operation of decentralized Grants programs.

Fund Control Mechanism

Instead of directly transferring funds to the Gnosis safe, the DAO gives the Gnosis safe a spend approval of a certain amount. For instance, rather than transferring $1 million from the treasury, the DAO could give the Gnosis safe a Spend Approval of $1 million. This ensures that the funds only leave the DAO when the multi-sig signers create a transaction. As a result, the funds always remain under the control of the DAO.

How to Create a Sub-DAO

Steps

1. Select your existing parent DAO token during the creation flow.

2. Create a new Governor for the SubDAO with your desired parameters for oversight. You can use the same parameters as the parent DAO or opt for different ones to match your specific needs.

The Safe App will automatically create your Governor SubDAO and add it to your multisig.

Add to Tally

A couple of steps are needed to get your new SubDAO fully represented on Tally.

2. Link the contract address of the Multisig that was created via the Zodiac Governor Module to your Parent DAO, making it easily visible from the parent DAO on Tally.

This upgrade path is particularly useful for progressively decentralizing a DAO. Often, a multisig makes sense for a newer DAO with a smaller treasury. As the stakeholder set expands, organization might find that it needs the security and decentralization of onchain proposals.

This Zodiac upgrade path makes it easy to progressively convert the Safe into a Governor without moving all assets and permissions between contracts.

Contender registration for The Arbitrum DAO Security Council Election begins March 15th.

Security Council Contender Registration Steps

Step 3: Complete contender registration flow.

Step 4: Sign message and submit transaction.

Using Ledger for Security Council Contender Registration

Step 2: Connect ledger via Wallet Connect.

Step 3: Complete contender registration flow.

Step 4: Follow the prompts and sign message in Wallet Connect,

Step 5: Follow the prompts and sign transaction in Wallet Connect,

A typical Governor DAO uses three contracts: a token contract, a Governor contract, and a timelock contract.

Configuring your Governor

Compatibility with Tally

Helpful Links from OpenZeppelin

Configuring your Governor

Core logic is determined by the Governor contract. When deploying a Governor, you need to chose:

1. How voting power is determined

2. How many votes are needed for quorum

3. What options people have when casting a vote and how those votes are counted

4. What type of token should be used to vote

These parameters must be 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

A proposal threshold can also be set, which restricts proposal creation to accounts with enough voting power.

Compatibility with Tally

Check out our guide to ensure your OpenZeppelin Governor is compatible with the Tally platform:

Helpful Links from OpenZeppelin

Using Governor

Tally offers an all-in-one guide explaining how to use Governor in the PDF below.

If you are deploying a token that might govern a DAO in the future, include voting methods. It's easy and safe to add them up front. It's much harder to upgrade or wrap the token to add them later.

How to deploy a compatible token

Deploying a token with voting is safe and easy

Open Zeppelin's ERC20Votes extension is safe and self-contained. It has been audited and is currently deployed in thousands of token contracts.

The main tradeoff is gas usage. Fortunately, users can make that decision themselves.

Users can choose to activate their voting power by calling delegate. When an account is delegated, transfers will also update voting power. That update uses extra gas. Users who do a lot of transfers can always undelegate their tokens to save gas by delegating to the zero address.

How to add a Governor to a token

How to deploy a wrapper

UX tradeoffs

Why does Governor need the voting interface?

How to add a Governor to a token

If a token may someday be useful for running an onchain DAO, deploy it with a voting interface for future Governor compatibility. If the token is already deployed and it cannot be upgraded, the best workaround is to deploy a wrapper token contract that adds the voting interface to an existing token.

How to deploy a wrapper

UX tradeoffs

A token wrapper does come with tradeoffs. Users will have to wrap their tokens to vote, and then unwrap them to use them in places that expect the unwrapped version. They may also be confused about where their token went after wrapping if their wallet doesn’t know about the wrapped version.

One thing to note is that setting up voting already requires setup: token holders have to delegate their votes – even to themselves – before voting. The wrapping step could be combined with delegation to keep the process simpler for tokenholders.

Why does Governor need the voting interface?

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.

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.

Tally supports DAOs on Ethereum, Polygon, Optimism, Arbitrum, Avalanche, Base, Moonbeam, Scroll, BNB Chain, Gnosis, and various testnets.

Tally connects with the on-chain contracts for your DAO in two places. Tally’s servers index the onchain data, and Tally’s web3 site helps users make calls directly to the contracts running on the blockchain.

If you do need to change something, check the dependencies here in the docs to make sure that your changes are compatible with Tally’s data indexing and web3 calls.

Tally currently supports these EVM-compatible networks:

Ethereum

• Ethereum Mainnet

• Ethereum Sepolia Testnet

• Ethereum Holesky Testnet

Polygon

• Polygon Mainnet

• Polygon zkEVM

• Polygon zkEVM Testnet

• Polygon Amoy Testnet

Binance Smart Chain

• Binance Smart Chain Mainnet

• Binance Smart Chain Testnet

Arbitrum

• Arbitrum One

• Arbitrum Nova

• Arbitrum Sepolia Testnet

Optimism

• Optimism Mainnet

Avalanche

• Avalanche C-Chain

• Avalanche Fuji Testnet

Gnosis Chain

• Gnosis Chain Mainnet

Base

• Base Mainnet

• Base Sepolia Testnet

Scroll

• Scroll Sepolia Testnet

• Scroll Mainnet

Moonbeam

• Moonbeam Mainnet

ZKsync

• ZKsync Era Mainnet

• ZKsync Sepolia Testnet

Celo

• Celo Mainnet

Linea

• Linea Mainnet

• Linea Testnet

Mantle

• Mantle Mainnet

• Mantle Sepolia Testnet

Kroma

• Kroma Mainnet

• Kroma Testnet Sepolia

Iota

• ShimmerEVM Testnet

Immutable

• Immutable zkEVM Mainnet

• Immutable zkEVM Testnet

Blast

• Blast Mainnet

• Blast Sepolia Testnet

OKX

• X Layer Mainnet

• X Layer Testnet

Lisk

• Lisk Sepolia Testnet

Zircuit

• Zircuit Mainnet

Darwinia

• Darwinia Mainnet

Crab

• Crab Mainnet

Mode Network

• Mode Mainnet

Gravity

• Gravity Alpha Mainnet

Morph

• Morph Holesky

Berachain

• Berachain bArtio Testnet

Cyber

• Cyber Mainnet

Kinto

• Kinto Mainnet

RARI

• RARI Chain Mainnet

Vana

• Vana Mainnet

• Vana Moksha Testnet

ZetaChain

• ZetaChain Athens 3 Testnet

Rootstock

• Rootstock Mainnet

• Rootstock Testnet

Corn

• Corn Maizenet

• Corn Testnet

Adding chains to Tally

To support a chain, Tally has several must-have dependencies:

• EVM-compatible Network

• A full node for user web3 calls

• An archive node with a high rate limit for indexing

• A block explorer with an Etherscan-compatible API

In addition, these nice-to-have dependencies will unlock all the features and improve the UX:

• Support from major wallets for the network

Event signatures

Tally's API listens to event logs from Governor contracts when indexing them. Your contract will need to maintain the same event signatures that OZ Governor implements:

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 state from the contract with function calls.

To be compatible with Tally, your Governor will need these function signatures:

If your OpenZeppelin governor contract uses a Timelock, it will also need this signature:

Quorum

Tally needs the quorum to calculate if a proposal has passed. That means that Tally requires the Governor to have a quorum() function:

Optionally, Tally also supports the quorumNumerator() and quorumDenominator() functions. Governors with quorums that are a function of token supply should implement these functions:

If the Governor is missing either quorumNumerator() or quorumDenominator(), Tally falls back to the quorum() function and assumes that the quorum is fixed.

Voting Delay

Tally needs to know the voting delay to calculate when voting starts without polling the blockchain. A votingDelay() function on Governor is required:

Voting Period

Tally needs to know the voting period to calculate when a proposal finishes voting without polling the blockchain. A votingPeriod() function on Governor is required:

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 on Tally:

Governor Parameter Changes

Governors can change their own parameters, like proposal times and the amount of voting power required to create and pass proposals. To make sure that Tally indexes your Governor's parameter changes, implement these event signatures:

If your OpenZeppelin governor contract uses a Timelock, it will also need this event:

Quorum Extension

Tally handles the ProposalExtended event, which is emitted by governors that implement the PreventLateQuorum extension:

Clock Mode

If you're already using a direct fork of Governor Bravo, then your DAO should work with Tally out of the box. If you insist on making changes to the base contract, then you can use this guide to make sure that your changes are compatible with Tally's API and web interface.

Event signatures

Tally's API listens to event logs from Governor contracts when indexing them. Your contract will need to maintain the same event signatures that OZ Governor implements:

event ProposalCreated(
    uint id, 
    address proposer, 
    address[] targets, 
    uint[] values, 
    string[] signatures, 
    bytes[] calldatas, 
    uint startBlock, 
    uint endBlock, 
    string description
);

event VoteCast(
    address indexed voter, 
    uint proposalId, 
    uint8 support, 
    uint votes, 
    string reason
);

event ProposalCanceled(uint id);
event ProposalQueued(uint id, uint eta);
event ProposalExecuted(uint id);

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.

To be compatible with Tally, your Governor will need these function signatures:

function castVote(uint proposalId, uint8 support) external
function castVoteWithReason(
    uint proposalId, 
    uint8 support, 
    string reason
) external

function castVoteBySig(
    uint proposalId, 
    uint8 support, 
    uint8 v, 
    bytes32 r, 
    bytes32 s
) external

function state(uint proposalId) public view returns (ProposalState)

function propose(
    address[] memory targets, 
    uint[] memory values, 
    string[] memory signatures, 
    bytes[] memory calldatas, 
    string memory description
) public returns (uint)

function execute(uint proposalId) external payable
function queue(uint proposalId) external
function cancel(uint proposalId) external

State variables

The Tally app need reads state from the public getters of these state variables:

uint public votingDelay;
uint public votingPeriod;
uint public proposalThreshold;
uint public constant quorumVotes;

Quorum

Tally needs the quorum to figure out whether a proposal passed.

Tally expects a quorum constant:

uint public constant quorumVotes;

Voting Delay

For Governor Bravo, Tally uses the voting delay to know when voting starts. Governor Alpha does not have a voting delay. For Governor Bravo, a votingDelay constant on Governor is required:

uint public votingDelay;

Voting Period

Tally uses the voting period to correctly show the end of voting. A votingPeriod() constant on Governor is required:

uint public votingPeriod;

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 on Tally:

enum ProposalState {
    Pending,
    Active,
    Canceled,
    Defeated,
    Succeeded,
    Queued,
    Expired,
    Executed
}

Governor Parameter Changes

Governors can change their own parameters, like proposal times and the amount of voting power required to create and pass proposals. To make sure that Tally indexes your Governor's parameter changes, implement these event signatures:

 event VotingDelaySet(uint256 oldVotingDelay, uint256 newVotingDelay);
 event VotingPeriodSet(uint256 oldVotingPeriod, uint256 newVotingPeriod);
 event ProposalThresholdSet(uint256 oldProposalThreshold, uint256 newProposalThreshold);

Specifically, Tally needs the following methods and event signatures for indexing and web3 calls:

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:

event DelegateVotesChanged(
    address indexed delegate, 
    uint previousBalance, 
    uint newBalance
);
event DelegateChanged(
    address indexed delegator, 
    address indexed fromDelegate, 
    address indexed toDelegate
);

Your contract will need to support transfer events, too. Tally works with both ERC20 transfer events and ERC721 events.

ERC20:

event Transfer(
    address indexed from, 
    address indexed to, 
    uint256 amount
);

ERC721:

  event Transfer(
    address indexed from, 
    address indexed to, 
    uint256 indexed tokenId
);

Function signatures

The Tally frontend helps users make these function calls to delegate their votes:

function delegate(address delegatee)
function delegateBySig(
    address delegatee, 
    uint nonce, 
    uint expiry, 
    uint8 v, 
    bytes32 r, 
    bytes32 s
)
function getVotes(address account) uint256
function name() string
function symbol() string

// ERC20 only:
function decimals() public view returns (uint8) 

Name

The token contract must implement the name() function, so that Tally knows what to call the token.

function name() string

Symbol

The token contract must implement a symbol() function, so that Tally knows the short name of the token.

function symbol() string

Decimals

ERC20 token contracts must implement a decimals() function, so that Tally can correctly render token balances:

function decimals() public view returns (uint8) 

A Governor contract has several important parameters that affect the lifecycles of its proposals. Think about these parameters as a balancing act between ease of passing proposals and security against malicious proposals. That’s an important – and tough – tradeoff to get right!

Here's a guide to picking these parameters to set a DAO up for success by picking the right parameters:

How to pick the Proposal Threshold

The Proposal Threshold is the amount of voting power that an account needs to make a proposal. Governors on Tally usually set the threshold to somewhere between 0% and 2% of circulating token supply.

The purpose of the threshold is to prevent spam proposals and to make sure that anyone making a proposal has either direct economic exposure or trust from delegators. Some DAOs set the proposal threshold to 0 to lower the barriers to participating.

Picking a good Proposal Threshold depends on the distribution of delegated voting power, which might be hard to know before the DAO gets off the ground. Once the distribution of voting power is known, it’s a good idea to have a medium-size group of delegates over the threshold. DAOs on Tally typically set their Proposal Threshold to a place where at least 5-10 delegates have enough voting power to make a proposal.

How to pick the Quorum

The Quorum is the amount of `For` votes – sometimes also including the amount of `Abstain` votes – for a proposal.

Picking a good quorum is tough, because it depends on voter turnout, which might be hard to know in advance. A too-high quorum might make it impossible for a Governor to pass *any* proposals! On the other hand, too-low quorum might open up the Governor to spam attacks, where an attacker repeatedly submits a malicious proposal and forces other voters to repeatedly vote it down.

For Governors on Tally, the quorum is usually somewhere in the range of 1-10% of circulating token supply.

How to pick the Voting Period

The voting period is how voting lasts on each proposal. At the end of the voting period, the proposal has passed or failed. Most DAOs pick a period between 3 and 7 days.

Less than 3 days, and someone can try to sneak through a proposal on a weekend or during a period of low activity. Something closer to 7 days gives everyone time to review a proposal.

How to pick the Voting Delay

The voting delay is the amount of time between when a proposal is submitted and when it goes up for voting. Most Governors have a voting delay of 0. The Governors that do have one usually pick a period of one day or less.

The delay gives token holders time to delegate their voting power before the vote starts or buy more votes. Governor takes a snapshot of all the voting power at the start of voting. Delegation and balance changes after that don’t affect voting power. That said, most DAOs decide that this extra time for managing votes isn’t worth slowing down the proposal.

How to pick the Timelock Delay

The timelock delay is the minimum amount of time between when a proposal posses and when it can be executed. There’s a big agility vs. security tradeoff here, so DAOs pick values all the way from 0 days to 7 days for their timelock delay.

Tally recommends picking a delay of 0 for Governors that only manage a treasury. The security benefit of a delay isn’t as relevant. The exception is if the Timelock has someone with an emergency veto/cancel role. In that case, they probably want at least 3 days to react to potentially malicious proposals.

For Governors that control a DeFi protocol where users might want to withdraw their funds before a big protocol change, we usually see timelock delays closer to 7 days.