What are Curve whitelists, what is being whitelisted and who gets to decide the whitelisting? This article seeks to explain exactly these questions.
In former articles we have covered everything, from what Convex, Yearn and [REDACTED] actually are, to the Curve Wars that are happening right as we speak, laying a fundamental understanding of the scenario we are in. Let us thus dig deeper into how Curve operates and what Curve’s whitelist actually does.
Curve is a DAO. As a decentralized autonomous organization, Curve’s governance system is partially off-chain (Snapshot, forums), partially on-chain (gauges, multisig…). Curve is, like many other DAOs, being progressively developed and many discussions are held on topic as to whether it is permissionless enough or if it must further decentralize. Nonetheless, Curve is currently the largest protocol, with more than 20 billion USD total locked value in the protocol. These staggering numbers, in combination with the specific voting system which Curve has implemented, lead to all of the dynamics we have mentioned in previous articles.
In order to examine our current topic, we first need to realize that the first and primary task of the Curve DAO is to keep the protocol afloat by making proper decisions related to setting various settings related to the smart contracts deployed on the Ethereum blockchain, but also others (primarily Ethereum, as a high priority blockchain). But how does this system look “under the hood”? This image, while most likely not the most beautiful thing one may have a first look at, paints the picture fully:
This is how the entire Curve DAO on-chain governance system is interconnected. It is a mix of custom-made contracts (every box pictured, except the common standards we know as ERC20, Minime tokens, etc.) and pre-made governance systems (Aragon DAO).
The important things to take from the picture:
So let’s go through it step by step. A user would first acquire CRV by either buying it on the market or staking his Curve LP tokens for CRV rewards (remember the Gauge incentivizes this). The user then locks his CRV for a certain time period to acquire the amount veCRV he wants. This depends on the locking time, and the current conditions based on how many people lock.
This act of locking CRV for veCRV (read: voting escrow CRV) transfer the CRV to the VotingEscrow contract and locks it there. veCRV can now be staked to a gauge, redirecting more rewards to this gauge based on the ratio of veCRV locked per gauge (the formerly mentioned balanceOfAt() function gives the current voting power based on time passed to the gauges).
This in turn distributes more CRV to them. So where does the whitelist come in?
The question is: Do we want everyone to have access to veCRV? Contracts can be used for malicious intents. And this is a hot topic of discussion. So a solution to one of these problems (protocols unfairly getting more veCRV quickly and then staking for rewards) can be solved by introducing a whitelist.
How does it work? Simple! Don’t let any contract interact with the VotingEscrow contract, which is not whitelisted by the DAO!
Now only whitelisted entities and accounts have access to veCRV. Other than large shareholders, which are anyways not protocols, veCRV is now in the hands of mostly good actors, and exactly those actors which Curve wants! This is the point of the Curve finance whitelist.
Thanks to all of the readers who have followed this post through to the end, we are excited to see you in the [REDACTED] Discord! 🦋