[RFC] eUSD Revenue Share Programme Update 24-09-2026

[ham]

Summary

An update to the existing ongoing proposal of sharing eUSD Revenue with participating fintechs, Ugly Cash and Sentz. The proposed proposal, if enacted, would update the Revenue Share in order to maintain compliance with the rules of the original revenue share proposal and the subsequent revenue share update proposal which saw 10% of Fintech Revenues redirected to stRSR holders.

Original Revenue Share Programme Proposal.

Fintech Revenue Share Adjustment (90/10) Proposal.

Problem Statement

The eUSD Revenue Share Programme distributes revenue to participating fintechs using a rules-based and predictable framework, with allocations determined by relative eUSD balances at biweekly snapshot intervals. Revenue predictability is important to fintech participants, who rely on stable and transparent distributions when integrating eUSD into their products and planning incentives.

Over time, changes in eUSD supply and balance distribution cause revenue shares to drift from those ratified through governance vote. Without periodic updates, this drift creates misalignment.

Rationale

This proposal updates revenue shares strictly in line with the existing programme rules on a biweekly cadence. Until a revised Revenue Share Programme is ratified, updates will continue under this standard to preserve predictability, minimise governance overhead and maintain confidence for all participants.

Snapshot

The percentages are calculated based on the amount of eUSD the Fintech Apps are holding relative to the eUSD Market Cap. The data and formulas used to generate the tables above can be inspected here.

Timeline

Risks

The degree of eUSD overcollateralisation depends on several factors including collateral basket APY, the amount of RSR staked, the price of RSR and the share of revenue directed to stRSR.

Under the previous programme, 100% of revenue generated from fintech-held balances was allocated to fintech participants. As fintech balances grew relative to non-fintech balances, the share of revenue flowing to stRSR declined, reducing staking APY for RSR stakers.

Lower staking yields could lead some stakers to reduce or exit their positions, decreasing the amount of RSR securing eUSD and increasing tail risk in the event of a collateral default. The recently ratified 90/10 revenue split mitigates this by directing a portion of fintech-generated revenue to stRSR holders, strengthening incentives for RSR staking and better aligning fintech growth with system security.

Operational risks also exist around wallet submissions used to calculate and distribute revenue share. Fintechs submit both balance wallets and a designated revenue wallet for streaming payments. If balance wallets are incomplete or incorrect, revenue share calculations could be inaccurate. Likewise, if a revenue wallet is submitted incorrectly, revenue could be streamed to the wrong address. These risks are mitigated by requiring fintechs to confirm submitted wallets, with all balances publicly verifiable on-chain at any time.

[ham]

@R72 @0xd15co @josh @Raphael_Anode

Is it worth considering a minimum percentage delta to determine whether each revenue share RFC needs to graduate to an IP?

In this RFC, UC’s revenue share increases by just 0.15%, which equates to roughly $35 in additional yield over the next 14-day cycle. For context, a 1% change in UC’s revenue share would be worth roughly $250 over the same period, with the dollar impact for Sentz and stRSR being considerably lower.

My thinking is that we would continue posting the RFC every two weeks, but only graduate it to an IP if any stakeholder’s share has moved by at least 1 percentage point relative to the current on-chain revenue share. If the threshold isn’t met, the existing revenue share would simply remain in place for another cycle.

At the next bi-weekly snapshot, the newly calculated shares would again be compared against the actual on-chain revenue share, rather than the previous RFC calculation. This means smaller changes would effectively accumulate until they become large enough to justify an update.

I think this would preserve the responsiveness of the bi-weekly programme during periods of sustained growth or contraction, while reducing unnecessary governance overhead during periods of relative stability.

Would be interested to hear your thoughts.

[Raphael_Anode]

@ham

Is it worth considering a minimum percentage delta to determine whether each revenue share RFC needs to graduate to an IP?

Hi Ham! We amended the original proposal a while back, so only changes of minimum 2.5% relative trigger a vote. A $35 dollar delta is negligible. So I would advise against putting this to an IP.

[ham]

Ah do you have a link to that amendment?

I can’t rememeber that discussion, and haven’t been following it since i’ve taken over posting the Revenue Share proposals but defintely appropriate.

[Raphael_Anode]

Sure thing. You can find it here: [IP] Change in eUSD Revenue Share operational parameters

[0xd15co]

I wasn’t aware there was already a 2% threshold, let alone that this IP proposed 5%. I’m still in favor of a reasonable threshold, though. Why not use the 5% the majority voted for in 2025?

@ham The date in the title of this RFC should be 24-09-2026 btw.

[Raphael_Anode]

The original proposal called for 2% change. The question was 2% absolute or relative change?

2% absolute means very few adjustments, it’s a very high bar.

2% relative or 5% relative are both better and lead to more fine tuned feedback.

5% would mean fewer adjustments and longer intervals to either more or less revenue share with UC. This could be totally fine now, given they’re at almost 2/3rds of revenue share.

Will put this to a vote soon.

[ham]

With @0xd15co here, I was clearly aware of the threshold given my comments, but has slipped my mind since. Unless my memory is betraying me, I’m fairly sure Sawyer was posting IPs on a consistent two-week cadence, although it’s difficult to say without checking whether that was because he was following this proposal or simply because UC was growing quickly at the time. You should have reminded us @Raphael_Anode and saved us all a few clicks!

I’ve done some number crunching on this. The absolute and relative changes can now be found in the first sheet of the snapshot workbook, and I’ll start including both in the biweekly snapshots I post on the forum.

As for the vote, I think the context has changed somewhat since your proposal was published. UGLYCASH has grown its balance significantly and now accounts for a much larger share of eUSD. UGLYCASH biweekly revenue is now approaching $20,000, so eUSD yield is likely becoming a meaningful revenue stream for the business.

In that context, I think a 5% relative threshold is still within the realm of suitability, but now feels towards the upper end. At ~$20,000 of biweekly revenue, a 5% relative change represents roughly $1,000 per cycle, whereas a 3% threshold represents roughly $600. I think 3% strikes a better balance, keeping the Revenue Share Programme reasonably accurate while still filtering out immaterial changes and reducing unnecessary governance load.

If a 3% relative change threshold was in effect during the last 16 cycles, I estimate we’d have reduced the amount of IPs by roughly one third.

@0xd15co Thanks, updated now

[Raphael_Anode]

Let’s settle this via a simple forum poll and we’ll keep everyone accountable on this from now on.

Do you support a relative 3% threshold of change in revenue share before a change is moved to an on-chain poll?

• Yes
• No

[R72]

Proposed changes to the yield distribution are according to agreed Revenue Share Programme and the updated yield distribution ratio between Fintechs and RSR stakers. Vote(d) in favor. Also agree to a applying/enforcing a 3% minimum percentage delta for bringing the RFC to an actual IP for efficiency purposes (reducing administrative/governance overhead).