Glossary

• esLBR: An ERC-20 token that designates the weight of a user’s voting rights. The more esLBR a user has in their wallet, the more weight their delegation or vote on a proposal holds.

• Delegation: esLBR holders cannot vote or create proposals until they delegate their voting rights to an address. Delegation can be given to one address at a time, including the holder’s own address. Note that delegation does not lock tokens; it simply adds votes to the chosen delegation address.

• Proposal: A proposal is code that is executed by the governance contract through timelock. It can replace the governance contract, transfer tokens from the community treasury, or perform an almost infinite range of other on-chain actions. In order to create a proposal, an address must have at least 1% (10M esLBR) of all esLBR delegated to their address. Proposals are stored in the "proposals" mapping of the Governor smart contract. All proposals are subject to a 7-day voting period. If the proposer does not maintain their vote weight balance throughout the voting period, the proposal may be canceled by anyone.

• Proposal Threshold: The minimum number of votes required for an account to create a proposal. This can be changed through governance.

• Quorum: In order for a vote to pass, at least 4% of all esLBR (40M) must vote in the affirmative. The purpose of this quorum is to ensure that the only measures that pass have adequate voter participation.

• Voting: Users can vote for or against single proposals once they have voting rights delegated to their address. Votes can be cast while a proposal is in the “Active” state. Votes can be submitted immediately using “castVote” or submitted later with “castVoteBySig” (For more info on castVoteBySig and offline signatures, see EIP-712). If the majority of votes (and a 4% quorum of UNI) vote for a proposal, the proposal may be queued in the Timelock.

• Voting Period: How long does a proposal remain open to votes.Once a proposal has been put forward, Lybra community members will have a 7-day period (the Voting Period) to cast their votes.

• votingDelay: How long after a proposal is created should voting power be fixed. A large voting delay gives users time to unstake tokens if necessary.

These parameters are specified in the unit defined in the token’s clock. Assuming the token uses block numbers, and assuming block time of around 12 seconds, we will have set votingDelay = 1 day = 7200 blocks, and votingPeriod = 1 week = 50400 blocks.

• COUNTING_MODE: A description of the possible support values for {castVote} and the way these votes are counted, meant to be consumed by UIs to show correct vote options and interpret the results. The string is a URL-encoded sequence of key-value pairs that each describe one aspect, for example support=bravo&quorum=for,abstain.

• Timelock: All governance actions are delayed for a minimum of 2 days by the timelock contract before they can be executed.