[RFC] Enable onchain referral/revenue share mechanism for both Users and Integrators

General Discussion Ideas
1

Hey all,

I’d like to bring to up a topic for discussion which I think is important for the growth to the Lazy Summer Protocol, both in terms of Users and TVL - referral/revenue share.

One of the most common questions, which is also to be expected, from potential integrators of the Lazy Summer Protocol is “Is there any revenue share options?” - and so far, the answer to this has been, it’s possible but not set up yet. Likewise, with a recent user survey of existing Lazy Vault users, a referral program was a popular request - particualy with the option to earn additional SUMR. And I think it’s time we set something up and got going with it.

This was already anticipated within the design of the Vaults, and as part of each Vault already deployed there is a referral code option within the deposit function, which required an integer number. As such, this can be applied immediately to all existing Vaults if and when approved.

Summary

My proposal is to create two types of referral mechanism; one for users to refer other users, and one for integrators. Within this proposal, I suggest both are managed by Summer.fi from a referral code creation point of view, and data analysis and reward calculation each month - including proposing the payouts. Because the codes are operated by integers, I will propose a range to use - so if needed, other third parties could also be approved to introduce their own referral programs if needed and wanted by governance.

At the start of each month, Summer.fi will propose a report and merkle roots that can be added onchain and, if approved by governance, paid out (by claiming) the earned referral bonuses. Each month, the final decision will lie with governance, and will be verifiable onchain - but summer.fi will do the work to manage and prepare the payouts for their approved range of referral codes.

It is proposed to make referral payments in assets of the deposit, and SUMR tokens.

For integrators, it is proposed that governance allow them full discretion over how they wish to use the proceeds of the referral rewards, including sharing them with users, or keeping the full rewards for themselves or anything in-between.

Integrator referral proposal

  • Id range: Starting at 1, and increasing up to 1,999,999. This gives us 2m integration codes for up to 2m different integrations. More than enough.
  • Referral rates:
    – Stable Vaults (USDC, USDT, EURC etc): 10bps per asset of TVL, annualised.
    – Volatile Vaults (ETH etc): 5bps per asset of TVL, annualised.
    – Both of these would be calculated on a per second basis over the period.
  • SUMR Rewards: As an integrator, you would also earn SUMR rewards referring users. These would be based on amounts of TVL you have referred, as an annualised figure, and tiered to incentivise future deposits. The amount of SUMR, for deposits over the period;
    – Up to $10,000 → 0.1%
    – Up to $100,000 → 0.2%
    – Up to $250,000 → 0.3%
    – Up to $500,000 → 0.4%
    – Over $500,000 → 0.5%
    – Prior to SUMR trading, it is proposed the same FDV value assumed within the Summer.fi app is used, which is $250M

User referral proposal

  • Id range: Starting at 2,000,000, and increasing up to 9,999,999. This gives us 8m referral codes. These would be generated by the Summer.fi UI and could also be exposed and generated via an API for other integrators to make use of. Governance can approve more if it requires when it gets to that point.
  • Referral rates:
    – Stable Vaults (USDC, USDT, EURC etc): 7.5bps (5bps for referrer & 2.5bps for the receiver) per asset of TVL, annualised.
    – Volatile Vaults (ETH etc): 4bps (2.5bps for referrer & 1.5bps for the receiver) per asset of TVL, annualised.
    – Both of these would be calculated on a per second basis over the period.
  • SUMR Rewards: As an referrer, you would also earn SUMR rewards referring users. These would be based on USD amounts of TVL you have referred, as an annualised figure, and tiered to incentivise future deposits. The amount of SUMR, for deposits over the period;
    – Up to $10,000 → 0.1%
    – Up to $100,000 → 0.2%
    – Up to $250,000 → 0.3%
    – Up to $500,000 → 0.4%
    – Over $500,000 → 0.5%
    – Prior to SUMR trading, it is proposed the same FDV value assumed within the Summer.fi app is used, which is $250M
Reward Integrators User referrals (referrer) User referrals (referral)
% of deposited asset (Stable Vault) 0.10% 0.05% 0.025%
% of deposited asset (Volatile Vault) 0.05% 0.025% 0.0125%
SUMR up to $10,000 0.10% 0.10% -
SUMR up to $100,000 0.20% 0.20% -
SUMR up to $250,000 0.30% 0.30% -
SUMR up to $500,000 0.40% 0.40% -
SUMR over $500,000 0.50% 0.50% -

For the avoidance of doubt, if approved, Summer.fi will not use a referral code for it’s UI nor embed a default code into the SDK that is made available to integrators.

Tagging @Recognized_Delegates for their input and feedback on the proposals.

C

2 Likes
2

Nice and timely proposal @chrisb — this referral system aligns well with the protocol’s long-term growth goals, and what seems like a community requested program.

A few thoughts worth considering before the SIP:

  • Reward Funding Source: It might be helpful to clarify whether SUMR rewards will come from the current emissions budget or require a new allocation. If the latter, a parallel SIP for a dedicated referral rewards vault or budget might be needed.

  • Onchain Verification: I like the use of merkle roots for reward distribution, but I wonder if there’s a lightweight way to make referral code assignment/ownership transparent onchain as well (to avoid potential misuse or disputes).

Since referral codes are represented by integer IDs, it would be valuable to track who owns which code directly onchain.

Would it be possible to track TVL-based referral earnings directly in the contract? This could allow referrers to claim rewards permissionlessly once governance approves the Merkle root.

  • Security/Abuse Mitigation: Given the direct incentive structure, do you envision any rate-limiting or abuse-prevention mechanisms — particularly for self-referrals or sybil-style loops?

Overall, a very sensible and scalable structure. It’s good to see both integrators and community users included here — and I think with a few light touch additions around reporting and anti-abuse, this could become a nice growth lever.

Keen to support this once it moves to SIP!

– jensei

3

The strategic importance of this proposal makes sense to me and I agree the implementation of onchain referral is critical to incentivise the next phase of integration and user powered protocol growth.

The proposed referral rates seem broadly reasonable. However, I do have a concern about the use of absolute basis point (bps) values as the foundation for the referral mechanism.

Since protocol fees are derived as a percentage of TVL, and that percentage is set by governance and subject to change, there’s a risk that fixed bps referral rates (on TVL) could become misaligned with protocol revenues. For example, if integrators are promised a fixed bps return based on TVL, but governance later adjusts fee rates downwards, the protocol might no longer generate sufficient fees to meet those referral obligations.

To reduce this risk and better align incentives between the protocol and integrators, it may be worth exploring a relative model, where referral rewards are expressed as a percentage share of total fees generated, rather than fixed bps on TVL.

Pros of the current approach (absolute bps on TVL):

  • Simpler to communicate to integrators and may help close deals more easily in the near term.

Cons:

  • Governance changes to the fee rate could render existing referral terms uneconomical. Renegotiating or modifying absolute bps rates retroactively may be complex and harm integrator trust.
2 Likes
4

I agree with the proposal as written and believe it to be urgent.

The time between the setup of the program and the initialization of third party apps can be significant so any time saved now is beneficial.

I support the proposed rates, and assume that if this percentage ever would become an issue, then there can be follow up votes to reduce it. However, these seem reasonable even when rates would drop to eg. 1%.

1 Like
5

You’re right, that wasn’t clear. Right now, the Summer DAO Timelock (Treasury) (On base) currently holds the community allocation of just over 206.4M SUMR tokens on Base. It would be some of these tokens used in order to pay the SUMR rates. There is currently more SUMR on other chains, both in the reward contracts allocated for the current fleet rewards, and in the timelocks on those chains (~12M).

For the asset payouts, these would come from the fee revenue of the Vaults. Because these will be collected within the Timelocks on each chain, I would propose that when uploading payment proofs, the proposal contains instructions to also move money from the relevant chains to Base - so all referral claims are made on Base - the primary chain of Lazy Summer Protocol.

Personally, I’m not sure another SIP would be needed, I think one to just cover off this, and allocate spending from the timelock each time.

The difficulty here is that it would require a transaction in order to put it onchain, which does break the UX a little. Although it could have a contract and registry which increases the number - but this then could also be sybilled by someone for all the numbers (although that exists in the offchain version too). I guess the question is around UX vs requiring it to be trackable onchain.

If we had a contract registry, then we could certainly keep track through subgraphs and maintain a transparent way for anyone to build a dashboard of earnings per address - because all referrals are onchain, anyone can see what referral codes are earning how much and when. But this wouldn’t change the permissionless claiming nature - once the Merkle root is approved by governance, it would be claimable permissionlessly anyway - regardless if the addresses are trackable onchain or not.

So the way I have proposed the referral, I don’t think there is any abuse of the referral system beyond users being able to self refer themselves with a different address - though this exists in any referral system today whether onchain or offchain with multiple emails, codes etc. And because the referrals are based on TVL, and not one-off payments for a deposit etc, there is no loop concern - and actually, because the SUMR payments actually increase with more TVL, it actually makes it more costly for users to use multiple codes to refer.

Except for the bit further above, the only issue that can occur is someone basically taking all the code ranges with millons of different addresses. If this occurs, we can probably think of different ways to do it. Maybe even requiring a position to be open on Summer for 10 days or something before you can create a code - but I think that isn’t needed unless it is later.

1 Like
6

As @FBrinkkemper says here, I think we just reduce the referral rates if the fee rates ever change. There is no concept of ‘renegotiating’ I don’t believe - and we talk about the fee being able to change through a governance vote easily, so I don’t see why the referral fee should be treated differently. We make to comments to it being fixed, or even how long it lasts etc. Governance can (and likely would) change these things over time.

With the increasing integer approach, we can even get to a point where we start to drop the rate for new referers based on codes above X for example.

But I do think for simplicity, and ease for people to understand how much they will currently be earning now - having a number that is clear is better UX and more likely to be successful.

2 Likes
7

I think this is needed for growth. I am for this proposal.

1 Like
8

Given nothing is needed for voting this onchain (i.e. nothing at a smart contract level needs executing until the first payouts) I would like to put forward an idea of a show of hands poll of proceeding with the proposed numbers and methodology so that we, Summer.fi, can start to provide some potential integrators with details of the referral mechanism and start to build it out.

Unless any objections, particularly from @jensei incase this is breaking some process, I will create a poll this coming Monday, 5th May. Once there has been ample time to vote on the poll (say 3 days), we can assess if there is consensus on a single route forward.

Would appreciate any further comments in the meantime, especially to comments that have been responded to above.

Thanks again, and pinging @Recognized_Delegates once more for any final feedback :slight_smile:

4 Likes
9

Thanks @chrisb — I support the idea of gauging community support now, especially to move forward with integrators.

While Tally is built for onchain execution, it can still be useful for soft signaling if we’re clear it’s non-binding and purely to record sentiment, especially when the decisions, like this referral mechanism, will potentially impact protocol behavior.

I would suggest to continue using established [SIP5.X] & Tally here for legitimacy, visibility, and an immutable record of sentiment from the DAO.

At the same time, if we want to keep friction low at this stage and other @Recognized_Delegates are on the same boat – a wisely setup poll would work as well.

–jensei

2 Likes