PDP 33: Bribe centric config set

Posted on behalf of the mStable ProtocolDAO

This forum post and MCCP 11 proposes 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.

Summary

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, Source 2

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 with it 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 $MTA price as our overall network effects will dramatically increase

The bribe market is still unsaturated/inefficient. This is changing 1 and is likely to get more saturated in the coming weeks, so capitalising asap is important.

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.