[IP] Change in eUSD Revenue Share operational parameters

Abstract

This proposal aims to improve the FinTech revenue share, originally proposed here, by adjusting the changes that qualify for an on-chain proposal. A new on-chain proposal gets posted when there is a 5% relative change in the FinTech’s share of eUSD holdings. In addition, there are new operational processes suggested when a FinTech adds or removes addresses for consideration.


Problem statement

Currently, eUSD revenue share is rebalanced upon changes in FinTech balances greater than an absolute 2% of supply. In six months, this has not happened once. Still, revenue share has been adjusted once. While the balances of these FinTech apps have changed over the last six months, lack of clarity around when to adjust the percentages has led to confusion and FinTechs had no direct feedback from their holdings to incentivise them to increase holdings…

In addition, there is an operational gap when new addresses are added to FinTech addresses that are monitored. This leads to a lack of clarity and transparency in participating addresses.


Rationale

We propose changing the threshold to soften the conditions that trigger an on-chain proposal to adjust revenue share among FinTech apps:

  • From an absolute 2% monthly change in market share to a relative 5% month-over-month change in eUSD balances held.

E.g., UglyCash held 3.8% of the eUSD total supply in November, and 4.5% in December. That represents an absolute 0.7% increase in market share, which would not trigger a revenue sharing rebalance under the current system. However, that 0.7% represents a relative 18% in MoM rate of change, which is above the threshold of 5% and would trigger an on-chain proposal to rebalance the revenue share for eUSD.

We also propose a new operational procedure, where FinTech apps have to announce any addition/removal of addresses participating in the revenue share through a forum post, that includes the addresses involved and a proof of ownership with a link to a signed Etherscan message or other signed message on the relevant blockchain.


Risks

This is an operational proposal and doesn’t add technical risk. Some gas usage for on-chain polls might be downstream from executing this proposal. Conversely, FinTechs would have a tighter feedback loop on eUSD held.

I am in favor of this change to the RevShare agreement:

  • Yes
  • No
0 voters
1 Like

I really like the chart! Thank you for the visualization.

This proposal feels morally right but I am struggling to see tangible relevance to northstar metrics I believe we most care about: safety, TVL, # of integrations and Monthly Active Users (MAUs).

With limited attention span in the community, this is a reminder (at least to me) on the importance of tempering proposed changes accountable to northstar metrics. This concern stems from the universal challenge of prioritizing activity vs results, to which I suggest prioritizing the latter.

If I am missing something on the results framing, please let me know. Otherwise I would abstain from the vote.

1 Like

great proposal, makes sense to me!

1 Like

Great Proposal! I think this gives clear direction for the FinTech RevShare proposal

1 Like

Hey James. As governance facilitators it is not in our purview to check if proposals align with a north star or not, unless the DAO has put explicit rules in place via a ratified vote that all proposals must do so.

It’s important to differentiate that this proposal is not an endorsement of the RevShare mechanism, but an operational improvement to the current form, which left quite a few governors scratching their heads each month, including us.

This proposal gives clear actionable guidelines in line with the spirit of the original proposal.

if you feel the whole mechanism isn’t conducive to furthering these north stars, it might be good to submit an RFC to repeal the RevShare.

We would of course support you as far as possible in the creation.

Hope this clarifies what this proposal tries to do - streamline operations - vs what it doesn’t do - endorse the mechanism.

1 Like

Agree with the proposal, both the month-over-month percentage change mechanism (apart from the exact %, see below) and the requirement for FinTechs to communicate changes in the addresses to be taking into consideration for the revenue share.

With regards to the proposed month-over-month percentage, I have a slight concern that 5% month-over-month would certainly in prolonged times of growth (which we can expect I think for some of the FinTechs) is triggered every month. That would bring a monthly-recurring governance effort (and cost!) for stakers. It may lead to reduced ‘enthusiasm’ from smaller stakers to vote for this onchain every time - and as a result, broad support for the proposal might not necessarily be visible in on-chain voting. I am leaning a bit more towards a relative 10% month-over-month, but I am happy to support the 5% as well. Let’s see how it pans out in practice.

One final (small) thing. Have trouble to understand the example in the proposal. I don’t see Ugly Cash having 3,8% share in November. Think you meant October from looking at the chart, but perhaps I am missing something.

1 Like

I think this is a good idea. This will allow the frequency of the revenue share rebalancing to follow more closely the actual TVL growth the Fintech is bringing (to the extent it increases the proposed 5% in relative terms, which seems like a reasonable threshold), which itself allows the Fintech to obtain the necesessary funding to keep incentivizing user growth at the same proportional level, in turn fueling the reinforcing feedback loop intended to keep growing the eUSD total market cap as a whole. Let’s go for it!

3 Likes

Thanks for bringing this to the forums @rspa_StableLab, I’m all for this proposal since it providers significant clarity to RSR Stakers and FinTechs alike.

On first look I echoed @R72 concerns but on deeper reflection feel that any sustained growth by these FinTech companies should be rewarded promptly since we all ultimately benefit with the associated increase in eUSD TVL.

However, like R72 implied this is an evolving process. If we are pushing proposals every month at significant cost to stakers then we can easily revaluate and increase the relative change that will trigger an on-chain proposal.

2 Likes

Thanks for the support. We will include this in the next parameter update change end of January.

On-chain polls need to affect at least one parameter or they can not be submitted, which is why we will include this operational change for ratification with the next parameter update.

Meanwhile we accept the forum poll as guidance for how to approach the FinTech revShare.

1 Like