Compound Governor Bravo

How to deploy a Governor Bravo or Alpha that's compatible with Tally

Tally supports Compound Governor Bravo and Alpha, but we consider it deprecated. If you are deploying a new Governor, we recommend OpenZeppelin's Governor. OZ Governor is more actively maintained and has all of Bravo's features.

If you're already using a direct fork of Governor Bravo, then your organization 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:

State variables

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

Quorum

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

Tally expects a quorum constant:

Note that the OpenZeppelin interface uses a function instead of a constant for quorum.

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:

Note that the OpenZeppelin interface uses a function instead of a constant for voting delay.

Voting Period

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

Note that the OpenZeppelin interface uses a function instead of a constant for voting period.

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:

Last updated

Was this helpful?