✅ [RFC] mStable Alliance Referral program

This post follows up on the referral program discussion started earlier by @juan

It is inspired by Idle Finance referral program and aims at designing a smart mechanism for B2B referrals

TLDR

  • Even though organic synergies between protocols are certainly happening in DeFi, referrals schemes could be highly beneficial initiatives to both parties, fostering mStable product utilization
  • Rewards would originate from the protocol fees and then be proportionally distributed to partners according to the new liquidity they deposit into Save on a monthly basis
  • Referrals can be tracked on-chain by adding a referral address in the Save contract
  • mStable would like to do more than just fee sharing and introduce the mStable Alliance, allocating some $MTA to bootstrap the program & offer exclusive rewards

Rationale

B2B partnerships in DeFi make a lot of sense as protocols build on top of each other. mStable belongs in the infrastructure layer of DeFi with Save as its core product. Save can be used to onboard new users from a wide variety of sectors: exchanges, wallets, dApps, CeFi, DAOs

Even though organic synergies between protocols are certainly happening in DeFi, referrals schemes could be highly beneficial initiatives to both parties, fostering mStable products utilization.

Referrals provide an economic answer to initial onboarding barriers for integrators and partners

Sushi, Aave, Synthetix, Idle Finance all have undertaken such affiliate partnerships as we speak

                                                                           ***

Moreover, Save utilization rate is far from its potential judging by the quality & sustainability of its yield compared to other protocols.

A great way to attract, incentivize and reward such “building on top” behaviors would be a kickback/referral program triggered whenever an external deposit happens

This program would be an opportunity for partners to become an integrated part of the mStable ecosystem and get rewarded for deposits that are generated on their behalf. Anyone could join the program by embedding an Ethereum address as a referral when users deposit assets in Save through their own interface.

Working mechanics

Contract update

  • A referral address option could be added on the Save wrapper contract to track third-party deposits on Save.
    Fee channeling

Fees would be collected, deposited into the current Balancer buyback & make pool, and paid in $MTA or mUSD in some circumstances. Every time a deposit is made on Save through a partner interface (with an embedded referral address), fees start to accrue.

Once per month, payments will be processed towards the vesting contracts. Each partner will have its own vesting contract. Tokens are vested on a linear basis over 3 months and the partner can claim them anytime.

Tokenomics

The MTA token gets a positive effect from this program: fees are periodically routed to a buyback & make pool on Balancer, which increases pool liquidity and create some buying pressure on MTA

mStable products generate a revenue line of which 90% goes to savers and 10% to the protocol itself. Giving away between 20% and 50% of this revenue seems to be reasonable as B2B referrals could strongly increase the amount deposited into save (there is only $20m deposited into Save to date)

Collected fees are gathered & put into work which is very cash efficient for the protocol. As the mStable ecosystem will grow, B2B will be creating a new source of revenues for the protocol

Fee sharing rationale

Tiers are what determine the percentage of profit shared with the partner. They would be adjusted to Partner Deposited Assets into Save (PDAS) to value their exposure to Save

It could lead to the following structure:

* Tier 1 🥉 – PDAS < $ 1M: 20% of the fees
* Tier 2 🥈$ 1M < PDAS < $ 2.5M: 25% of the fees
* Tier 3 🥇 $ 2.5M < PDAS < $ 5M: 30% of the fees
* Tier 4 🎖 PDAS > $ 5M: 50% of the fees

mStable DAO will be able to change those parameters as the program grows

Payment execution threshold

The minimum threshold for executing the fee-sharing: 500 $MTA accrued fee

Introducing the mStable alliance

The tier categories aforementioned could be further explored with additional rewards given as partnership depth increases

We propose to introduce the mStable alliance, access for partners to exclusive rewards

Tier 1 = :3rd_place_medal: Standard partner

Tier 2 = :2nd_place_medal: Plus partner

Tier 3 = :1st_place_medal: Premium partner

Tier 4 = :medal_military: Metal partner

All current partners get automatically promoted to Tier 4

Please find below an overview of what the mStable Alliance program could give access to:

Time frame

  • Week 1: discussion
  • Week 2: Snapshot vote about budget & parameters
  • Week 3: Nominate a dedicated Alliance Committee to whitelist partners & execute the rewards transaction every month (this could be then automated on-chain if the program turns out to be successful)

Discussion

With that in mind, mStable wonders how to structure the nature and the emission of these referrals rewards:

  • Creating a gauge for B2B referral, emphasizing governance & MTA staking
  • Giving away the shared fees in $MTA
  • Giving away the shared fees in mUSD
  • No fees sharing, all revenue goes to the protocol and then partners access revenues through staking (Stakers would get a part of protocol revenues)
  • Lock-up $MTA as partners enter the mStable Alliance, unlock them as they start staking
  • Initially bootstrap the program with a grant

Happy to hear your thoughts about this

4 Likes

Thanks @TClochard - this is great, well done putting this together.

  • I think having integration partners (in my view Save’s core target customer) earn MTA makes a ton of sense. Make a gauge on the emission controller specifically for the alliance program would make the most sense I think.
  • I think it would be good to incentivise integration partners participate in governance. This is because they are precisely those are impacted by governance decisions the most. They also can represent their user base.
  • One way to do this is give them a revenue stream only once they have staked say 80% of their rewarded over a period of 6 months. This is essentially a quest.
  • Might make sense to just pool 1% of all save APY and distribute that to integration partners pro rata. Therefore there’s a sustainable APY spread and economic reason to integrate mStable.

Keen to hear others thoughts on this

2 Likes

I especially like the last point, about pooling a small fraction of save APY for integration partners. I think giving them a scaling cut of profit from the additional mUSD they’re minting is a good feedback loop. The exact percentage can be tweaked depending on the tier they’re in.

While I understand the parts about integrators earning MTA, I don’t like this idea very much. If the integrators want to participate in governance (which is good and desirable) then they should use the (hopefully) upcoming bonding mechanism to buy into the protocol, or purchase MTA off of the open market. This is a rare chance to create actual demand-side pressure on the token, and we shouldn’t pass it up.

2 Likes

I like the idea about integrators buying MTA, I suppose my main question is where do the other MTA rewards go and why?

We could think of moving all rewards to a bond buying program like OHM (which we are trialing soon) and give deeper discounts to integration partners. I just wondering whether startups would want to have the balance sheet risk of purchasing a token even when discounted.

This is a great initiative! This was a long time on my mind as well but with you, @TClochard in the position of BD are much better equipped to formalize this. I think we see more and more that we need to focus on more B2B or D2D partnerships.

Why would we want to create a gauge? I thought we gonna share the gov revenue.

I think protocol would prefer mUSD/mBTC just because these are better to evaluate. But MTA could be a nice bonus. They could earn this still from the Vault. This would give the partner also a voice in governance since they become a “user” of the protocol as well. They should have a voice, very nice!

This would be a hard sell. Why would the protocol not just stake then? Their effort that they increase the revenue would be shared/diluted among all stakers. So they receive less…

Not sure what you mean.

And this grant would be awarded to a new partner? Would need grantsDAO signer approval though.

In general, very nice concept! Keen to hear also @itsJeremiahS and @juan opinion.

I’m sympathetic to this actually. I do feel strongly though that, if they want to have a hand in governance, they should buy in like everyone else. Further, I think that the sorts of people such a partnership would attract will understand pretty well the ethos at play here.

But I’m not a business development guy, so my opinion isn’t worth much here. I don’t have the experience to assert “this wouldn’t be a blocker.” It’s just a rare chance to create buy-side pressure and we should take it if we can.

1 Like

Totally agree buying should be default. @TClochard let’s do some research with partners to test this. Obviously them paying for it would be the ideal scenario (even if it was from their APY spread)

I favour mUSD/mBTC as well @Dimsome. But MTA is very interesting as well.
Not sure if it’s possible but could we stake MTA for a specific wallet? ie, instead of writing something new, we could reuse the MTA locking mechansm as the fee’s vesting.

  • 3 months sounds good but could be longer for better benefits.

I see two options:

  1. Buy MTA (at discount?), and stake them for few years to be onboarded into the program, fees should be in mUSD/mBTC
  2. Fees collected go through the progress @TClochard described and are paid in MTA.

My point would be that, if I buy and stake MTA I prefer not to get paid in MTA, but something else to be less exposed to a single asset.

But on the other hand If my fees are in mAsstets then we would need a mechanism to onboard similar to staking MTAs.

Great to catch up on this discussion guys. Alot of what I would have touched on has already been covered by others in this thread.

Perhaps its just because smart contract vulnerability is on my mind today after the Cream exploit, but I assume the actual upgrades to the contract will be very simple and won’t be a concern from an attack vector perspective? Probably one for you here @Dimsome and the devs

I like this idea a lot, great work @TClochard

  • Partners earning MTA makes sense, echo others with adding them to a gauge.
  • I think % fee share would make sense in imUSD. It keeps the fees yield bearing and serves as an incentive for partners to purchase/hold MTA to earn a boost from the Vault.
2 Likes

No, the current changes are part of the easier onramp-offramp updates. For the referral, we will be only emitting an event. This could then be used to generate the data off-chain. So there is really no risk here.

On another note: I think one point of confusion currently is the MTA distribution to partners. They could use the Vault to earn MTA as is with their user funds. Why do we want to add a gauge or give more MTA than that? Based on what? Seems a bit unfair to individual users of SAVE.

3 Likes

General review of the post

Everyone seemed to agree it makes a lot of sense to have a referral program as it will incentivise new deposits into Save from third parties as well as putting Save product at the centre of mStable value proposition.

The core aspects of the discussion were about:

  • Type of revenues sharing (% of protocol revenues, given % of Save APY, gauge)
  • Nature of the fees earned (MTA or mUSD)
  • Unlocking / staking mechanisms (Stake to earn policy)
  • Governance implications of the program (Buy MTA or Receive MTA)

Others areas were not explicitly discussed on this post but required specifications

  • Tiers repartition
  • Deposit tracking

Key parameter analysis

a) Giving away the fees in mUSD

  • derived from a given flat % of the Save APY to partners. It would create a valuable organic feedback loop and would then be distributed depending on which tiers they’re in and pro rata of the deposits. This means that the more deposits they generate, the more they earn.
  • derived directly from the 10% protocol fees, shared- up to 50% to partners

Existing boost incentives would incentivise partners to deposit imUSD in the vault and get MTA rewards. Doing so would foster their role in mStable governance.

mStable could offer additionnal specific boosts for referrers (it could easily be done from a Dev- perspective) which would incentivize even more this behavior

b) Giving away fees in MTA

MTA would be bought back through a Buy&Make Balancer pool, create an interesting buy-pressure / source of demand for MTA as well as by default involving referral partners into governance as they get MTA

A downside of this method would be to expose partner with governance token, which cannot be forecasted. For large partners, this is an important blocker.

c) Tiers repartition

Doing more than measuring the Partner Asset Deposited into Save in absolute terms, we could segment tiers depending on the total PADS deposited by referrers relative to the total mUSD supply*. The tiers would therefore be expressed in % through their PADS ration (PADSr)

* Tier 1 🥉 – PDASr < $ 1%: 20% of the fees generated
* Tier 2 🥈 1% < PDASr < 2.5%: 30% of the fees generated
* Tier 3 🥇 2.5% < PDASr < 5%: 40% of the fees generated
* Tier 4 🎖 PDASr > 5%: 50% of the fees generated

*Current mUSD supply = 100m$

d) Deposit tracking & reward calculation

A /referral address argument will be added to the Save contract. Each deposit will generate an event easily traceable. Based on each referrer address, mStable will know when someone deposits and compute a 7 days average PDASr at the end of each month.

Say a partner has a PDAS of $3m, his PDASr is therefore 3%, he belongs to Tiers 3. Let’s assume Save 30day APY is 15%, revenues allocated to B2B is 10%.

Monthly reward: $PDAS * (30days Save APY)/12 * % of revenues allocated to B2B *  tiers associated sharing fees = X$

Monthly reward: $2.5m * (15%/12) * 15% * 40% = 1500$

Decision & remaining questions

mStable and the Partners surveyed would lean more on deriving the fees from a % of the protocol revenues going to a pool and then distributed to partners. Distibution in imUSD would remove the risk of partners dumping MTA as soon as they get their rewards while still allowing them to participate in governance if they put their imUSD in the Vault.

In addition, sharing a fixed % invites partners to deposit into Save as their rewards is linearly proportional to the amount they deposit, giving a clear value proposition to the partner.

  • We could use a grant in $MTA to boostrap the program & attract partners with upfront rewards. We could use too the Emission Controller to have a gauge for the Alliance program and distribute MTA. In any cases special MTA rewards in the program could help participate in a multi-governance flywheel.
  • mStable could offer additionnal specific boosts for referrers were they to put their mUSD in the vault, with MTA rewards vested on a 12 month basis.
  • Which % of the APY would we allocate to protocol (Current is 40% for the Convex bribe, will-it go back to 10%? Shall we derive let’s say 5-10% for the B2B partnership?
  • Shall we implement a stake to earn mechanism? (i.e requiring the partner to stake some amount of MTA to access a higher tier?)

Feel free to add some feedbacks, comment on this before we turn this into a proposal

1 Like

We should now rename this to an RFC. There are still some open questions, but should be ready to draft a formal proposal soon?

1 Like

Thanks for this @TClochard - it’s a good summary. What are the open questions at the moment before we move this forward?

@TClochard Are we ready to formally proposes this yet?

Let’s do this and turn into a MIP