xL2DAO Revenue Sharing
Layer2DAO is a DAO that seeks to highlight and bring to the masses high impact Ethereum L2 protocols and projects. The DAO treasury receives revenue through LP provisioning, .L2 domain sales, NFT royalties, and partner projects.
25% of fees generated from anything other than L2DAO tokens will be converted to ETH (if received in a different form of asset) and sent to the vault for stakers to claim. The amount of each staker’s claim is pro-rata to all other stakers in the xL2DAO system.
Your total amount of xL2DAO depends on 2 inputs: the amount of L2DAO you stake, and how long you lock up your L2DAO tokens. The longer you lock up your tokens, the higher your proportional share of xL2DAO and the larger your percentage claim and voting power. The most you can lock your tokens up for is 24 months. If you lock up 1 L2DAO for 24 months, you receive 1 xL2DAO. If you lock up 1 L2DAO for 12 months, you receive 0.5 xL2DAO, and so on. Once your L2DAO is locked up, there is no way to unlock it until the lock period has expired. Be certain that you don’t need access to your L2DAO before you lock it up!
- You can lock up your L2DAO from 2 weeks (= 0.02 xL2DAO / L2DAO) up to 2 years (= 1 xL2DAO / L2DAO).
- You can only lock until Thursdays, if you select any other day, it will lock it for the previous Thursday (e.g if you choose to lock until Friday, June 25th it will lock it until Thursday June 24th)
- As you get closer to your unlocking date, your balance of xL2DAO decreases linearly.
- xL2DAO is non-transferable
- WARNING : You can only have one locking schedule. It means you cannot lock a share of your L2DAO for 1 year and another for 4 months.
- You can extend your locking schedule at any time, but you cannot lock it for more than 2 years since you first locked some L2DAO.
Our contracts are forks of Curve’s veCRV contracts, modified slightly by Ribbon. These contracts have been audited extensively and are some of the most used contracts in DeFi. All contracts can also be viewed on our GitHub.
User voting power
is linearly decreasing since the moment of lock. So does the total voting power 𝑊. In order to avoid periodic check-ins, every time the user deposits, or withdraws, or changes the locktime, we record user’s slope and bias for the linear function
in the public mapping
user_point_history. We also change slope and bias for the total voting power
and record it in
point_history. In addition, when a user’s lock is scheduled to end, we schedule change of slopes of
in the future in
slope_changes. Every change involves increasing the
This way we don’t have to iterate over all users to figure out, how much should
change by, neither we require users to check in periodically. However, we limit the end of user locks to times rounded off by whole weeks.
Slopes and biases change both when a user deposits and locks governance tokens, and when the locktime expires. All the possible expiration times are rounded to whole weeks to make number of reads from blockchain proportional to number of missed weeks at most, not number of users (which is potentially large).