MCCP 11: Bribe centric config set
| Author | Alex Scott |
|---|---|
| Discussions-To | https://forum.mstable.org/t/pdp-33-bribe-centric-config-set/669 |
| Status | Implemented |
| Created | 2021-10-12 |
Simple Summary
It is proposed to modify system configuration for a 6 week period, specifically the govFee and RevenueRecipient for mUSD, to redirect a predefined percentage of system revenue to Votium in order to capitalise on the under-utilised vote bribing market and generate circular effects for mUSD.
Abstract
This proposal is based on the following pieces of information:
- Curve emits huge rewards each week, distributed proportionately to votes on their gauges
- Current mStable yield farming methods are inefficient and produce a low ROI for the protocol
- It is possible to “bribe”
veCRV/cvxCRVvoters to vote for a specific gauge. This effectively allows for very high leveraged yield farming opportunities due to the huge CRV emission
mStable trialed this for one week with a $9k bribe through https://votium.app/ (targeting all cvxCRV votes) and seen mUSD supply in the mUSD-3Crv pool increase from 1.2 - 14m.
Source 1: https://curve.fi/musd
Source 2: https://twitter.com/VotiumProtocol/status/1447550501109829633
This proposal seeks to provide a set of experimental configurations that allow mStable to fully capitalise on this opportunity. This will be done in coordination with a large initial injection of $MTA, to ensure that the initial TVL is high and this configuration has sufficient network effects to take effect.
Motivation
As defined in the abstract, current mStable yield farming methods are inefficient. This proposal seeks to generate circular effects for mUSD without the use of the existing $MTA emission.
mStable is in a unique position, because when the mUSD supply rises, so does the system revenue. The system can then use this revenue (collected in $mUSD) to buy $MTA and to fund the next batch of bribes. This causes a positive feedback loop that can grow $mUSD supply (until the market becomes 3-4x more saturated, however even after this point, the bribes should still cause the TVL to float high).
- Having higher system revenue will have knock on effects to SAVE, increasing the TVL and user base there independently
- This should have positive effects on the
$MTAprice as our overall network effects will dramatically increase
The bribe market is still unsaturated/inefficient. This is changing and is likely to get more saturated in the coming weeks, so capitalising asap is important.
Specification
A new IRevenueRecipient will be deployed, with the following features:
- ability to deposit
$MTAinto Votium, once per two weeks - configurable
bribePctvariable, that determines the % of$mUSDheld to be deposited into a childIRevenueRecipient(could be used for sending surplus bribe $ to for example buy CVX for longer term farming) - configurable
IRevenueRecipient, initially set to be the existing Buy & Make pool depositor
The following settings will be changed:
setSavingsRatewill be called with5e17on SavingsManager, setting the percentage of system revenue set aside to be 50% (note: this requires an upgrade to SavingsManager)setRevenueRecipientwill be called, setting themUSDRevenue Recipient to be the above- Swap and Redemption fee on
mUSDwill be changed to4e14and20e14respectively - Caps will be removed on the
Liquidatorfor themUSDintegrations (note: there is currently less than the existing cap available, so this in effect has no change)
During this period, mUSD system revenue from Feeder Pools and Polygon will also flow to the new IRevenueRecipient by default.
Should the parameter set seem to be operating poorly during this period, resulting in a net negative revenue for SAVE (i.e. mUSD TVL goes below $60m), the savingsRate will be updated with a relative amount, between 10% (existing) and 50% (proposed).
Start date will be immediately following successful resolution of this proposal, and last for 6 weeks, after which time the settings will be reverted.
Copyright
Copyright and related rights waived via CC0