## The Protocol

Votium is a whitelisted protocol where CRV stakers may permanently lock their CRV to receive a derivative called votiCRV. After staking their votiCRV/CRV LP tokens (easier than single staking? downside of getting less CRV locked), they will receive a share of Curve 3CRV fees as well as bribes from Votium distributed weekly on top of liquidity mining VOTI rewards. The token is earned by locking CRV at a xx:xx ratio.

### Peg mechanism
To ensure the peg on votiCRV/CRV pool, 15% of the protocol voting power is directed towards the Curve pool for it. Another 5% of the voting power is hardcoded towards a VOTI/ETH pool. This means liquidity mining can focus entirely on rewards CRV lockers.

### VOTI Token
VOTI token has multiple fold utility:
- revenue share from vlCVX bribes (performance fee)
- revenue share from veCRV bribes (performance fee)
- VOTI owners can delegate part of the Votium voting power to themselves or another protocol
- Governance over the protocol (change of performance fee)

### vlVOTI Spec

- Should adhere to OZ [IVotes](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/utils/IVotes.sol) interface
- Quick and easy, no Aragon needed, can use Governor contract
- Governance will have a linear decay built-in, from proposal start time to end, to prevent voters from waiting till end to vote
- Scaled Voting Power based on lock duration (i.e. lockAmount * x/X is Voting power, where x = duration, X = MAXTIME)
- Minimum Lock Time: 2 weeks ?
- Maximum Lock Time: 32 weeks ?
- Low lock times constants: https://twitter.com/bantg/status/1527839201064009728
- Rage quit option
- penalty based on lock time left, i.e. 50% of lock time left == 50% penalty ?
- tokens from penalty get redistributed to lockers ?
- This means the vote locker contract is more like a vault, where users lock and receive a non-transferable share? (ERC-4626)
- other option is to just burn the tokens (implicit benefit to lockers, as the totalSupply is reduced)
- Voting power is constant throughout lock duration (not like CRV VotingEscrow, more like CVX Locker)
- Won't do dumb storing multiple locks like CVX, just keep track of 1 lock history through time
- built-in vote delegation
- Governance can use the delegated balance
- whereas balanceOf will be the user's own voting power ?
- this way boosting can use balanceOf / totalSupply and governance can use getVotes / getTotalVotes
- Also allows for easier governance
- Ability to increase lock duration
- only lock owner
- Ability to increase lock amount
- anyone can deposit for another user
- lock for others via permission (via eip712 signature)
- other option is to only allow the contract owner to lock for others
- But the nice part about using signatures is, can allow other contracts to lock for a user
- Especially nice for airdrop locking

# @dev Vote Locker potential interface
def lock(): ...  # lock gov tokens
def lockBySig(): ...  # allow someone else to create a lock for a user (particularly smart contracts)
def unlock(): ...  # unlock gov tokens after lock expiry
def quit(): ...  # unlock gov tokens w/ penalty

def increaseLockTime(): ... # increase lock time, pushing unlock time further into future (only lockee can call)
def increaseLockAmount(): ...  # increase locked amount, increasing boost balance (voting power of delegate as well)

def balanceOf(): ...  # boost balance
def balanceOfAt(): ... # boost balance at block N
def totalSupply(): ...  # boost total supply
def totalSupplyAt(): ...  # boost total supply (returns the same as `getPastTotalSupply`)

# IVotes
def getVotes(): ...  # user vote balance now (how much they've been delegated)
def getPastVotes(): ...  # get vote balance at block N
def getPastTotalSupply(): ... # total vote supply at block N
def delegates(): ...  # who does user delegate voting power to (only 1 delegate)
def delegate(): ...  # change delegate (default no-one)
def delegateBySig(): ...  # delegate using a signature
# NOTE: by default, even if a user does not have a delegate, their voting power still counts towards totalSupply
# this is equivalent to abstaining. Users must delegate to themselves if they'd like to participate in governance

# STRETCH: operates similar to a vault, where boost/votePower is a share (potentially a rebasing vault)
# enables gov tokens that are taken as penalty, to be redistributed to remaining lockers
# Issue: we don't know when new tokens were deposited ... resolution: assume they were deposited at checkpoint time
# See https://github.com/axeolotal/evault/blob/main/contracts/VaultCVXCRV.vy for example of rebasing vault implementation

### Revenue share
As the revenue from bribes will be in multiple tokens, there will be an option with a higher management fee where users may elect to have their bribes exchanged for votiCRV/CRV LP tokens to essentially auto-compound bribes and fees into it *(Front running concerns).

### Tokenomics
- 73% liquidity mining
- 1% whitelist airdrop
- 1% Votium users airdrop (Potential additions: veCRV/vlCVX/cvxCRV stakers/uCRV users/0xconcentrator)
- 15% team
- 5% advisors
- 5% treasury

Potential token sale? Use funds to bootstrap liquidty in govToken/ETH LP (https://www.paradigm.xyz/2022/04/gda)
Potentially allow LP as a voting/boost power ? Two vote lockers ? Single sided gov locker, LP gov/ETH locker?

Supply cap, but continual emissions ? Distribution mechanism ? Gauge system ?

Airdrop recipients have claimed tokens locked

### Questions?
Do we let VOTI users decide how to use the voting power to maximize bribes or is it done automatically to maximize bribes the way Votium already does it?
Are there concerns with frontrunning?
Reaching a good level of decentralization is important, can it be done?

### Products

- Bribe Aggregation
- Better bribe platform
- Single Sided Rebasing Vaults (cvxCRV, CVX, vlCVX, CRV)
- Multichain ????
- would need to start locking CRV for veCRV (veCRV wrapper)
- boost selling
- convex of multichain
- if locking CRV need to maintain contract address across chains

### Threats / Concerns
As this doesn't compete with Convex for liquidity, Convex should be supportive of the protocol. Curve will welcome it as it will mean a higher voting decentralization.

There needs to be some form of lock up on VOTI that would allow using the voting power for non gauge related votes (no lock up would prove problematic as it would be equivalent to liquid voting which community is against)

### Works
- Vinnie redesign, front help from Rav snack
- Audit with Chainsecurity/Peckshield
- Smart contract by ??
- Curve support stamp