Voting Escrow as Oracle
Maverick Protocol expects to incentivize liquidity using MAV token emissions in certain Boosted Positions as part of its Phase 3 implementation. Token emissions to LPs have proven to be an effective tool for decentralizing DeFi protocols.
Maverick’s emissions system already represents an innovation in that it is connected to Boosted Positions, which mean that emissions–like external incentives–will be directed only to LPs in targeted liquidity positions, rather than general pools.
But Maverick also seeks to continue its commitment to maximum efficiency by rethinking the purpose and design of voting escrow mechanics more generally. What follows is a rationale and draft community proposal for the innovations that can be implemented via Maverick in its ve model at Phase 3 launch. These details are presented here as a proposal to invite comment and discussion from the Maverick community and do not represent the final design, which remains subject to change.
Voting Escrow as Oracle
If a protocol’s goal is to implement the optimal allocation of incentives, it could simply have a centralized committee decide where they should be allocated, or even pay an external entity to make those decisions for it.
If the protocol wants to make this process more decentralized, it can let the community decide through voting. This is where voting escrow (ve) comes in: the community uses a ve token to vote on pools and/or positions that should receive emissions. Framed this way, we can think of ve as a distributed oracle for incentive allocation optimization that removes the need to rely on any centralized apparatus.
But in order to be an effective oracle for the optimization of incentive allocation, the ve system needs to be carefully designed. We have already seen a couple of generations of decentralized incentive allocation mechanisms, none of which have been properly adapted to maximize their function as an oracle for optimization.
In the earliest versions of protocol emissions, tokens were distributed agnostically to all LPs, regardless of the value their liquidity was bringing to the ecosystem. While protocols like Sushiswap found this model useful for bootstrapping TVL, it was not the most efficient use of a protocol’s token reserves. In this model, the “voting” is simply the LPs voting with TVL: more TVL meant more emissions to a pool.
Curve innovated on this by instituting their ve system, which only emitted CRV tokens to pools which had been voted on by veCRV holders. This represented a primitive version of ve as oracle, since veCRV voters informed the protocol which pools were “useful” and they were rewarded accordingly.
While the Curve ve model was a vast improvement over a system that distributed emissions widely and naively, its utility as an oracle has proven less valuable over time. Since Curve gauges function according to a simple weighted vote, the pools with the most veCRV voted to them get the biggest share of CRV emissions, which can then be locked to produce more veCRV and increase the voting weight for that pool.
This has created a cycle whereby a pool only needs to be useful once to keep receiving rewards in perpetuity. The utility of ve as oracle has therefore been blunted, since pools receive protocol incentives based on historical value, not immediate or ongoing value.
A more recent model of ve comes from Velo where the protocol directs all the swap fees from a given pool to veVELO voters who voted on that pool. The rationale behind this mechanism is that voters will vote to incentivize the highest-earning pools, but from an oracle perspective this is redundant because no new information is being added by the voters: they simply vote for the pools that have the highest fees. Paying all swap fees to voters for such a simple task of identifying a pool that is yielding high fees drastically overpays the voters.
Even without ve, Maverick already has an oracle mechanism through Boosted Positions. Projects “vote” with their own token incentives on which pools are most useful at any given time, and either renew incentives if they continue to be useful or start a new Boosted Position if priorities have changed. Moreover, because Boosted Positions target specific areas of a pool, the oracle data is far more precise than models that incentivize entire pools at a time.
Maverick’s approach to ve builds upon this Boosted Positions-as-oracle design to maximize the efficacy and efficiency of emissions-directing as a form of oracle for the protocol. With this goal in mind, Maverick is offering the following proposed ve design for comment and discussion by its community of projects and users:
1. Incentives as foundation of emissions
MAV emissions will get directed pro rata to LPs in Boosted Positions (BPs) as a function of two quantities:
- veMAV votes towards that BP
- The amount of external incentives contributed to that BP in the last epoch
No MAV incentives will be emitted to BPs that do not have an external reward added in the previous epoch. This aligns MAV emissions not just with the will of veMAV voters, but also with projects actively cultivating liquidity through BPs–essentially providing two streams of oracle data for the protocol.
As noted above, in other ve systems whales can accumulate large bags of ve token and use them to capture the bulk of emissions. This blunts the effectiveness of ve as an oracle and also freezes out new participants who cannot compete with early adopters in terms of pure ve power.
Maverick aims to solve this problem by making external incentives the primary criteria for emissions: any user that adds token incentives to a BP can expect that BP to receive a match in the form of MAV emissions. veMAV votes towards that BP can be understood as providing a boost to the base incentive match for that epoch.
Only external incentives in the form of MAV tokens will qualify for emissions. Since they will be matched by MAV emissions, this effectively offers projects the opportunity to purchase MAV at a discount for use as incentives. This also removes any need to rely on oracles to determine the value of incentives when computing emissions.
2. Boosts to LP rewards
Maverick proposes to let LPs have the option to stake any MAV emissions as veMAV to receive an emission boost. This boost multiplier will scale with length of stake, with stakes of four years providing the maximum boost to emissions. This mechanism rewards LPs who are willing to make a commitment to the future of the Maverick ecosystem.
LPs will also receive a boost to their emission based on their pro-rata holdings in the BP and their current veMAV balance. Using veMAV balance as a criterion for boosts is expected to create a virtuous cycle that rewards LPs who choose to stake their MAV emissions.
3. Caps on MAV emissions
The amount of MAV emitted will be a function of the liquidity mining schedule and the amount of external incentives sent to BP LPs. Maverick proposes that MAV emissions be capped by an amount that is a function of the amount of external incentives sent to BPs in the emission epoch.
This prevents the protocol from over-emitting in periods of time where LPs and protocols are not active on Maverick. This mechanism is proposed with the belief that it is in the best interest of the protocol and wider ecosystem to maximize the value of MAV rewarded to ecosystem users.
Since the intention of the ve system is to serve as an oracle for the protocol, it makes the most sense to reserve MAV emissions for epochs where there are clear signals about the utility of emissions. When the community is not sending these signals through incentives, emissions will be reduced accordingly. In this way, emissions will be more sustainable in the long term.
Maverick ve in action
It is proposed that MAV emissions be drawn from the Liquidity Mining allocation, which represents 30.85% of the total MAV supply to be emitted. Monthly emissions will be capped at 1% of the remaining supply currently available for Liquidity Mining. So if at the start of a monthly period there is 1,000,000 MAV available in the treasury, the maximum emissions for that period would be 10,000 MAV.
Emissions will be sent to each chain where Maverick’s contracts and UI are live pro rata of that chain’s combined ve balance. For example, in a situation where there was 70,000 veMAV on Ethereum mainnet, and 10,000 veMAV on each of zkSync Era, Base, and BSC, 70% of emissions would be sent to Ethereum and 10% to each of the other chains. Under this design, MAV holders can vote for which chain is more useful by choosing where they stake their MAV.
Half of the emissions in each epoch will be allocated to straight matching of external incentives. Any unmatched emissions will not be emitted, and will instead remain in the treasury for future mining emissions.
- Example 1: A total of 5,000 MAV has been added as external incentives across many BPs. The total emissions available for this epoch is 24,000 MAV. Half of this amount (12,000 MAV) is allocated for matching. 5,000 is less than 12,000, so all 5,000 MAV of external incentives will be matched and the remaining 7,000 MAV will stay in the treasury.
- Example 2: A total of 20,000 MAV has been added as external incentives, and the total emissions available is again 24,000 MAV, meaning that 12,000 MAV is available for matching. In this case, the total external incentives is more than the amount available for matching. Each BP will get a pro rata match from the 12,000, i.e., 12/20 = an effective match multiplier of 0.6x.
The same amount of emissions per epoch will be allocated to a matching boost across all voted BPs (i.e., BPs boosted with veMAV votes). In Example 1, this would be 5,000 MAV; in Example 2, this would be 12,000 MAV.
This voted boost will be pro rata of veMAV votes as distributed across incentivized BPs, but will be capped at 5x the external incentives for each BP. Therefore, the total max boost available is 6x the external incentives (up to 1x from the straight match and up to 5x from the vote boost). So if a project added 1,000 MAV as external incentives to a BP and that BP received maximum veMAV votes, the BP could receive as much as 6,000 extra MAV from emissions (subject to available emissions and the pro rata shares allocated to other BPs through incentives and voting).
Community Feedback
Maverick welcomes feedback from the community on these proposed innovations. The proposed design is intended to ensure MAV is emitted in a manner that is sustainable and provides the greatest possible benefit to the Maverick ecosystem as a whole. Any feedback on the model explained above should be aligned with these goals.
Feedback and discussion should be offered in the #general channel in Maverick’s Discord. Join the discussion here.
About Maverick Protocol
Maverick Protocol is a leading provider of smart contract solutions in DeFi, focusing on enabling projects to customize, automate, and incentivize liquidity effectively, powered by Maverick AMM.
Website | Twitter | Discord | Telegram |Medium | YouTube
DISCLAIMER: The information provided in this Medium Post pertaining to Maverick Protocol (the “Project”), its crypto-assets, business assets, strategy, and operations, is for general informational purposes only and is not a formal offer to sell or a solicitation of an offer to buy any securities, options, futures, or other derivatives related to securities in any jurisdiction and its content is not prescribed by securities laws. Information contained in this Medium Post should not be relied upon as advice to buy or sell or hold such securities or as an offer to sell such securities. This Medium Post does not take into account nor does it provide any tax, legal or investment advice or opinion regarding the specific investment objectives or financial situation of any person. The Project and its agents, advisors, directors, officers, employees and shareholders make no representation or warranties, expressed or implied, as to the accuracy of such information and the Project expressly disclaims any and all liability that may be based on such information or errors or omissions thereof. The Project reserves the right to amend or replace the information contained herein, in part or entirely, at any time, and undertakes no obligation to provide the recipient with access to the amended information or to notify the recipient thereof. The information contained in this Medium Post supersedes any prior Medium Post or conversation concerning the same, similar or related information. Any information, representations or statements not contained herein shall not be relied upon for any purpose. Neither the Project nor any of its representatives shall have any liability whatsoever, under contract, tort, trust or otherwise, to you or any person resulting from the use of the information in this Medium Post by you or any of your representatives or for omissions from the information in this Medium Post. Additionally, the Company undertakes no obligation to comment on the expectations of, or statements made by, third parties in respect of the matters discussed in this Medium Post.
