[RFC] Staking V2 Launch Parameters incl. Revenue Share

General Discussion
, ,
1

1. Summary:

This RFC will be to outline the proposed initial parameters for the new SUMR Staking V2 Module, and then receive feedback from the community in order to align and go to vote on the dates outlined in this post: Staking V2 & Governance Upgrade, leading to SUMR Transferability - Proposed Timeline and Actions

2. Context & Motivation:

Staking V2 represents one of the biggest upgrades to the Lazy Summer Protocol since it launched in February this year. And not just because it’s a precursor to SUMR transferability, but because for the first time, it will enable SUMR token holders to benefit from the value created by the protocol by passing a share of Earnings to SUMR holders in USDC. It will also allow those that express a longer term commitment to the protocol to earn a greater share.

As well as the revenue share number, there are multiple other parameters to decide upon, such as caps on different lockup periods, penalties for early withdrawals and more. It is going to critical we as a community get these numbers right in order to create the right dynamics for SUMR holders to be able to maximise value.

3. Proposal:

It is proposed that the DAO deploy the new SUMR Staking V2 module, which will allow SUMR token holders to stake, and if they choose to, lock-up their tokens in order to receive boosted rewards - both in SUMR and USDC (from the revenue share).

The following setup parameters are proposed at launch;

Variable Value Can be changed by Gov after deploy
Allow No-Lockup Staking True Yes
Minimum Lockup Period 14 days Yes (by adjusting bucket caps)
Maximum Lockup Period 1,095 days (3 years) Only reduced using bucket caps
Reward at No-lockup 1x multiple No
Reward at Max-lockup 7.26x multiple No
Reward growth structure Quadratic No
Minimum Penalty 2% (110 days or less) No (except disabling)
Maximum Penalty 20% (at 1,095 days) No (except disabling)
Penalty decay Linear No
Penalty destination Back to protocol treasury No

The following buckets are proposed too, with caps;

Bucket SUMR Caps Can be changed by Gov after deploy
0 days (No lockup) 15,000,000 Yes
0 - 14 days 0 Yes
14 - 90 days 15,000,000 Yes
90 - 180 days 22,500,000 Yes
180 - 365 days 22,500,000 Yes
365 - 730 days 50,000,000 Yes
730 - 1,1095 days (max period) 1,000,000,000 (Total supply of SUMR) Yes

This represents a total of 97.5m SUMR tokens that can be staked and locked for less than 2 years. There is no cap (why it’s the total supply) on the 2-3 year period.

Also, at the start, it has 0 day lockup cap - primarily for helping and ensuring users can deposit for the governance transition - but Governance, after launch, may want to change the cap to 0 for the 0 day lockup, forcing SUMR holders to stake for a minimum of 2 weeks at anytime. However, it is expected that the short cap would likely be filled very quickly though, so maybe have a small cap also creates some sort of forced lockup as people withdrawing from it may think it could be difficult to deposit back into it.

Proposed Reward Emissions

Reward Amount Can be changed by Gov after deploy
SUMR Rewards 5,000 a day Yes
USDC Revenue Share 20% of Revenue (~188k a year right now) Yes (but as a SIP and not a variable wihtin the contract)

Right now, the protocol is operating at around a ~28% profit margin from all of the public, DAO managed vaults, monetizing around 55-60bps per $ deposited. As of today, the annualised revenue is around $940k, so at 20% revenue share - 188k a year will be distributed. The revenue share is expected to be set up monthly, based on the previous months revenue number - expected to be around 15-16,000 USDC for the first month.

Revenue Share Payout handling
It is also proposed that the Revenue Share payouts are handled via Merkl (as we use this approach for another of other rewards within the protocol). Upon the first available voting window (normally the first Wednesday) of the month, a member of the Labs Co team will post the revenue earned by the protocol, and how much should be distributed as part of the revenue share in a Sub-SIP to the forum. If not contentious, a member of the Labs Co will then create the transaction data for a new merkl campaign and submit it to vote. The merkl campaign will be setup to start from the 1st of the previous month 00:00 UTC through to 23:59 of the last day of the previous month. The previous months revenue will then be distributed to those stakers who had been staking the previous month and based on their balance throughout the month to calculate their share.

With this approach, it means the first payout will be made in December, based on Novembers revenue share figure - and those staking in November will be earning the revenue made by the protocol in November.

4. Open Questions:

  • Is the community and delegates happy with the proposals and values being proposed, in particular those that are set on deploy and cannot be changed without a new contract deployment.
  • In particular, are the bucket caps suitable for launch? Do they balance enough space to meet demand, but at the same time, create demand to encourage users to stake quickly incase they fill.
    – Right now we have proposed 15M SUMR tokens for the zero-lockup period, which will still get rewards. Do we want to go with this, or potentially make the minimum stake 2 weeks.
  • Any other parts the community might have been expecting but are not present?

5. Next Steps:

There will be another RFC to put forward parameter details for Governance v2, which is connected to the Staking Module.

Any questions, please don’t hesitate to post a reply on here, or reach out to me.

ChrisB

Tagging all @Recognized_Delegates for your important contribution

9 Likes
2

I think this is a great way to have a solid demand case for $SUMR, and the profit share is a flywheel effect. I assume 20% is calculated in such a way that it gives the core team enough room to operate well.

This could be a good way to further transparency, so that governoors can adjust this percentage over time to ensure staking is max attractive.

That being said, this could also be expanded in a kind of gauge voting system where protocol share go to pools, which can be voted on via stake $SUMR. This would allow protocols to co-incentivize their vaults and give $SUMR composable utility.

3 Likes
3

So the 20% number at the moment is based on the protocol having earnings/profit margin of around 28% right now. The core team/labs co is currently covered by the tip-stream setup. At the moment, around 28% of all revenue is going to the treasury to be used as governance see’s fit, this is why the 20% number was proposed here because it’s quite high but we need it high as possible IMO to generate a competitive APY to create demand for staking.

Exactly this. And it will be important for governance to monitor the earnings % to ensure the correct amount is roughly paid out. Another option could be to share as a % of earnings, but maybe we can move to that after it’s got going - it will be harder to simulate the yield in the UI unless we consider all expenses fixed.

1 Like
4

Thanks, @chrisb, for this comprehensive setup for Staking V2 and an exciting milestone for SUMR utility.

As I was doing my due diligence you have already answered my question above. The Lazy Summer DAO (its treasury) is earning around 30% (from 1% Lazy Summer Protocol management Fee). With your proposed 20% distribution to the SUMR stakers it will def. slow down the treasury expansion (depending on the TVL growth). At the same time, it will be redistributed directly to the users which is the aim here! Great!

Also, I agree with your note on the 0-day bucket: keeping a small cap at launch (15 M) makes sense for transition flexibility, but it should probably closed or be reduced shortly after transferability. At the same time, I am thinking that once short/mid buckets fill, latecomers will be forced into 2–3 year locks. That could backfire if liquidity preference remains high early on.

Perhaps the 365–730 day cap could be slightly increased (e.g., +10 M) to absorb medium-term demand before forcing 3-year commitments.

The linear decay of penalties from 20% → 2% feels intuitive, but given SUMR’s newness, maybe we should consider whether a grace threshold (e.g., 0% penalty for the first 7 days post-launch) could help early users adjust to the system before fully committing.

2 Likes