A solidity implementation of Curve's voting-escrow with additional features outlined below.
Lock delegation Users may delegate ther lock to another user whereby they give the delegatee control over their lock expiration and balance (i.e. voting power). Both users, the delegator and the delegatee, need to have an active lock in place at the time of delegation. Moreover, the delegatee's lock expiration needs to be longer than the delegator's.
Lock quitting A non-expired lock may be quitted by the lock owner anytime. The lock cannot be delegated at the time of quitting and the quitter pays a penalty proportional to the remaining lock duration.
Optimistic SmartWallet approval SmartWallets (i.e. contracts) can create a lock without being approved first. However, the veToken owner maintains a Blocklist where SmartWallets may be blocked from further interacting with the system. The Blocklist only allows the owner to block contracts but not EOAs. Blocked SmartWallets may still undelegate (if delegated prior to the blocking) and quit their lock (by paying the penalty) or withdraw once the lock expired.
This contract has been designed for a specific Token and is not safe for using with other tokens. Specifically, the following is a non-exhaustive list of unsafe usages:
- Contract does not support
Tokenwith maxSupply>2^128-10^[decimals] - Contract does not support fee-on-transfer
Token - Contract does not support
Tokenwith decimals<6
npm installnpm run buildnpm run testNote: We use hardhat and Alchemy web3 provider in order to test against Ethereum mainnet state. Make sure to configure an Alchemy API endpoint with a valid key before running the test script:
export ALCHEMY_API_KEY=[ALCHEMY_KEY]The veToken contract implements the same checkpoint mathematics than the original Curve VotingEscrow.vy contract. The new features leverage this math in order to void or redirect (i.e. delegate) a lock's virtual balance. More details about how the various lock operations interact with Curve's checkpoint math can be found here.