Create a voting escrow veHATs contract

[jellegerbrandy]

We will want the rewardcontroller alloc points (and perhaps also other settings) controlled by a voting escrow contract.

[jellegerbrandy]

• users with locked tokens will take part of governance - so users should be able to delegate tokens

[jellegerbrandy]

Examples:

• Vyper implementation of curve: https://github.com/curvefi/curve-dao-contracts
• The solidly contracts by Andre Cronje: https://github.com/solidlyexchange/solidly/tree/master/contracts - medium post here: https://andrecronje.medium.com/ve-3-3-44466eaa088b. Their voting escrow contract ve.sol seems at fisrt sight a port from the curve contracts, but has added new things like logic for nfts: https://github.com/solidlyexchange/solidly/blob/master/contracts/ve.sol
• Cream finance voting power calculation is straightforward: https://github.com/CreamFi/cream-voting-power/blob/master/contracts/CreamVotingPower.sol and token locking
• tranchess seems to ahve portedd the curve contracts to solidity: https://github.com/tranchess/contract-core/blob/main/contracts/governance/VotingEscrow.sol
• https://github.com/chimera-defi/SharedDeposit/blob/main/contracts/governance/voteEscrow.sol

[lirona]

Examples:

• Vyper implementation of curve: https://github.com/curvefi/curve-dao-contracts

i think it would be great to implement this in a simpler version, to remove totalSupplyAt and balanceAt (which are there for aragon compatibility, unless we will want to use aragon) and like this we can save just the last point (for global and every user) and no need to keep all point history and epochs, and we can get rid of all the block tracking and extrapolation. it will also simplify the checkpoint logic (need to update in the loop for every scheduled slope change since last update, and not every week). also some other minor improvements like have the for loop in the checkpoint run until current week and not 255 times (so can never break, the curve contract will break if unused for 5 years)
there are a few projects that have translated this contract to solidity, but kept it as is (like InsureDAO, snowwhitedev
)
and a lot of projects that copied the vyper contract (pickle finance, hundred-finance, angle protocol )

• The solidly contracts by Andre Cronje: https://github.com/solidlyexchange/solidly/tree/master/contracts - medium post here: https://andrecronje.medium.com/ve-3-3-44466eaa088b. Their voting escrow contract ve.sol seems at fisrt sight a port from the curve contracts, but has added new things like logic for nfts: https://github.com/solidlyexchange/solidly/blob/master/contracts/ve.sol

the repo seems to have vanished (as the creators decided to take down the project) but i think boba network forked it:
https://github.com/bobanetwork/boba/blob/develop/packages/boba/ve-boba/contracts/ve.sol
anyway i don't think we need these extra features (and don't think we would want to have the voting power transferable)

• Cream finance voting power calculation is straightforward: https://github.com/CreamFi/cream-voting-power/blob/master/contracts/CreamVotingPower.sol and token locking

simple but doesn't calculate total voting power. i think this is a pretty good idea actually, because unless we need to know the total voting power (can't think rn what for), it really doesn't matter for the voting mechanism. i think would be the best to implement something like this, with the deposit/withdraw/extend etc.

• tranchess seems to ahve portedd the curve contracts to solidity: https://github.com/tranchess/contract-core/blob/main/contracts/governance/VotingEscrow.sol

they have done a v2 already:
https://github.com/tranchess/contract-core/blob/main/contracts/governance/VotingEscrowV2.sol
which improves a lot the classic curve contract and adds a calibrateSupply function to deal with accumulated rounding errors

• https://github.com/chimera-defi/SharedDeposit/blob/main/contracts/governance/voteEscrow.sol

an ERC20Votes contract which mints voting tokens (which can be transferred and delegated) so voting power doesn't diminish during locking period. still not sure why diminishing values are better actually.. it also has the option to withdraw before lock expires and pay a penalty relative to how far is the expiration

[lirona]

• there's also the FraxFinance vyper expansion of the curve contact ("veFPIS is basically a fork, with the key difference that 1 FPIS locked for 1 second would be ~ 1 veFPIS, As opposed to ~ 0 veFPIS (as it is with veCRV)"): https://github.com/FraxFinance/frax-solidity/blob/master/src/hardhat/contracts/Curve/veFPIS.vy

• and the rust curve voting escrow implementation of astroport (with blacklisting): https://github.com/astroport-fi/astroport-governance/blob/main/contracts/voting_escrow/src/contract.rs

[lirona]

ben's comments about the tranchess v2 contract:

1. it's written for solidity less than 8, so need to update safemath into regular math.
2. their upgradeability is a bit weird, but do we even want it to be upgradeable?
3. they have some some pausemanage contract it inherits from to manage pausing it with a separate puser role, so do we even need it? and if so I think we could replace most or all of their code with OZ code...
4. They have a check that a smart contract cannot use create a lock unless it is whitelisted in a whitelisting contract. Do we want that?
5. They have some value checks like if the callback address is a contract, should we remove unnecessary value checks like that to save gas?
6. Since their contract is already v2 it has some code that was meant for the upgrade process, but we should remove since for us there's no existing contract.

[lirona]

ben's comments about the tranchess v2 contract:

1. it's written for solidity less than 8, so need to update safemath into regular math.
2. their upgradeability is a bit weird, but do we even want it to be upgradeable?
3. they have some some pausemanage contract it inherits from to manage pausing it with a separate puser role, so do we even need it? and if so I think we could replace most or all of their code with OZ code...
4. They have a check that a smart contract cannot use create a lock unless it is whitelisted in a whitelisting contract. Do we want that?
5. They have some value checks like if the callback address is a contract, should we remove unnecessary value checks like that to save gas? 6. Since their contract is already v2 it has some code that was meant for the upgrade process, but we should remove since for us there's no existing contract.

don't think we would want to have it upgradeable or pauseable, but let's discuss
as for the check for contracts on lock creation, this is something from the original curve contract, which checks this on creation, increase amount and increase lock time, and their explanation for it is to prevent it from being traded or tokenized, and the whitelist is to allow widely used multisigs.

[jellegerbrandy]

1. yes
2. no upgradeability
3. no pausing
4. whitelist for createlock contracst is good to keep the locked tokens non-transferable
5. not sure let's look case-by-case
6. ok