[RFC] SUMR token upgrade to allow for updated Governance Staking Module

General Discussion Request for Comment [RFCs]
, ,
1

Title: [RFC] SUMR token upgrade to allow for updated Governance Staking Module

This RFC was co-authored by @chrisb and @halaprix

1. Summary:

As part of the discussions [RFC] When, and under what circumstances should SUMR transfers be enabled, one of the most critical components of this from the discussion so far was upgrading the governance staking module to provide additional utility to SUMR.

This RFC is open that discussion and also provide some context around some of the steps that need to take place (i.e upgrading the SUMR token) for some of the proposed idea’s from the ongoing transferability discussion to become possible. It is also hoped that this RFC will open the door to the idea’s and community sentiment around what potential components could go into Governance Staking V2.

2. Context & Motivation:

Currently, the Governance Staking Module is a simple Deposit and Withdraw module, with a single APY that you earn while staking. It is a simple yes or no if your staking, and right now it works perfectly fine while the token is non-transferable.

The problems start to occurs that once the SUMR token is transferable, there needs to be more utility to the SUMR token, and in the best interest of the performance of the token, the right incentives to lock SUMR up for the longer term with differing rewards. This is currently not possible with the current staking module.

The next problem lies in the SUMR token contract, and it’s limited ability to be staked and still be used for governance voting power. Currently, the SUMR token, when staked, can be used to delegate and vote with. If a new staking module was deployed today, and SUMR staked to it - users would be earn whatever the rewards are, but they would not be able to vote with it.

Another problem though is the current SUMR token is not upgradable, so a new SUMR token will need to be deployed. This RFC looks to propose releasing a new SUMR token (similar to what Morpho did just prior to them enabling transferability too) which will allow the new SUMR token to be a fully upgradeable token, and give governance full flexibility moving forward of adding new features and utility to it.

One thing to note is that if we release a new SUMR token, then we are going to need to a new Governance Contract and new Timelock on each chain too. Not a big issue, but another piece in the puzzle to contend with. This can be done in a nice migratable way too though, so that both old and new SUMR tokens can be used as voting power - so any existing voting weight to delegates from the current SUMR token would continue to be counted in the new gov contract too.

Once this is all done though, it would be the new SUMR token would be the one that becomes transferable and tradable, requiring existing SUMR token holders to swap their tokens for the new version prior to being able to sell or stake them in the new staking module. This is something we (Summer.fi) can add functionality in for to make it very easy.

3. Proposal:

This RFC is to propose a rough chain of events, which conclude with an updated Staking Module.

  1. Align the community on redeploying the SUMR token as an upgradable token. For simplicity and ease, I put forward the recommendation that we simply deploy a new SUMR token that in effect is exactly the same as the current token but is upgradeable. From this point, we can then proceed to add the required functionality to it, such as the staking module which full details can be flushed out in this RFC.
  2. Redeploy Governance and Timelock contracts on supported chains, with the functionality that enables the community to provide voting power with both the existing SUMR token, and the new one.
  3. Allow upgrading from the current, non-transferrable SUMR token to the new one.
  4. Add new staking functionality to the new SUMR token that allows for governance participation while staking, lock-up periods for additional APY, and potentially other reward incentives beyond just SUMR (maybe some of the protocol revenue?)

4. Open Questions:

  1. Does the community align on replacing the SUMR token with an upgradable token, controllable by governance?
  2. What are the risks present in doing this?
  3. Beyond the new staking module design allowing for lockups etc, what should the detailed look of the new governance staking module do. Should this be a separate RFC or all included in one but broken out into multiple SIPs?

5. Next Steps:

  • Gather community feedback
  • Iterate based on discussion
  • Promote to relevant SIPs (with clear, formal specification)
6 Likes
2

Thanks @chrisb and @halaprix for this proposal. The overal approach feels aligned with where we want to go: enabling SUMR transferability in a way that safeguards long-term governance integrity and expands token utility.

Deploying a new upgradeable SUMR token seems like the cleanest path forward, especially given the limitations of the current non-upgradable contract.

It allows us to build staking V2, as well as future-proofs SUMR against new needs that will inevitably emerge.

However, migration processes need to be extremely smooth.

For me peronsally, the Morpho process was a bit confusing.

Is it possible to make a single-step UI flow in the Summer app to swap + stake. This is one of those areas where UX can make or break participation, especially as we approach transferability.

In case that SUMR becomes transferable without this functionality, it could introduce friction for delegates and token holders who want to remain engaged.

One open question for me is how tightly governance controls the upgradeable SUMR contract. It’s super important to understand, define and publish the upgrade path controls** clearly (e.g.: who can trigger upgrades, what security timelocks exist, etc.)

Also, we should weigh potential risks of having two SUMR tokens circulating during the transition. Is there a cliff or deadline post which only new SUMR counts for governance or staking?

Overall, I am fully supportive of this direction. I’d suggest breaking out seperate RFC only if the toipic becomes too bloated, otherwise distinct SIPs once there’s general consensus here makes most sense to me.

–jensei

4 Likes
3

Thanks for putting forward this important RFC—this is a critical milestone for the future of SUMR and Summer.fi governance, although I wish this discussion had started sooner. I support the idea of replacing the SUMR token with an upgradable version and below is my detailed feedback and a few suggestions for how to refine and progress the proposal.

:white_check_mark: Strengths of the RFC

  • Timely Strategy: Linking transferability to enhanced token utility is the right move. Without it, SUMR risks becoming a governance-lite asset.
  • Governance Continuity*: Supporting both legacy and new tokens during the transition is respectful of current delegators and aligns with community values.
  • Modular Roadmap*: Separating the SUMR upgrade, governance contract updates, and staking module into discrete phases is pragmatic and executable.

:warning: Key Risks & Suggestions

1. Migration Risks

  • Challenge: Token migration uptake may be slow or uneven.
  • Suggestion: Incentivize early migration through boosted staking rewards or bonus governance weight for early adopters.

2. Complexity of Dual-Token Governance

  • Challenge: Maintaining dual-token governance could become messy over time.
  • Suggestion: Introduce a sunset period after which the old token loses governance power, ensuring a full transition to the new SUMR.

3. Undefined Staking V2 Design

  • The RFC references lockups, reward scaling, and governance integration but doesn’t detail their mechanics.
  • Suggestion: Split this into modular SIPs:
    • SIP 1: Core staking logic (lockups, APY curves)
    • SIP 2: Governance mechanics (voting while staked)
    • SIP 3: Multi-asset incentives (protocol revenue, etc.)

:brain: Additional Ideas for SUMR Utility

  • Voting Escrow Model (veSUMR): Lock longer for more power. Widely adopted and aligns incentives.
  • Access/Gating: Offer protocol feature access or boosted rates to stakers or long-term holders.
  • Revenue Sharing: Introduce protocol fee distribution to SUMR lockers or voters

:pushpin: Key Community Questions

  1. What is the best way to balance governance continuity with the need to fully transition to a new token?
  2. Should ve-models be included from the start or introduced later?
  3. What’s the ideal reward model to drive staking and governance engagement long-term?

:white_check_mark: Suggested Next Steps

  • Publish a phased SIP roadmap for staking V2 design.
  • Launch a community poll around token migration incentives, staking lockups, and ve-model preference.
  • Share a simple one-pager explaining what holders need to know about the migration path ahead.

Looking forward to the next iteration of this proposal!

4

Thanks for the RFC @chrisb @halaprix

  1. I believe replacing the SUMR token is in the community’s best interest. The fact that the current token is not upgradable will stunt the growth of the protocol in the long term, and will devalue the token due to the lack of utility. I also think that the old token should be taken out of circulation / burned when exchanged for the new token. There should also be a maximum migration period of about a year for SUMR holders to move to the new token.

  1. No matter how much you try to simplify the process, there will still be hiccups, as well as people having a difficult time completing the migration. This cannot be avoided, unfortunately, but I do share the sentiment that we should aim to make the migration process as smooth as possible.

  2. One RFC makes sense, with multiple SIPs broken out under it. Individual SIPs can address different functional areas of the governance staking module.

1 Like
5

Thanks everyone – everything discussed so far looks solid :white_check_mark:, and I don’t have much to add at this stage. Just one small but important point I’d like to emphasize:

We should make sure to clearly communicate to the community that while the SUMR token will become upgradable :counterclockwise_arrows_button:, the tokenomics – such as Total Supply – will remain unchanged :bar_chart:.
This helps ensure full transparency and avoids any potential misunderstanding, especially among less technical community members.

Clarity here will go a long way in maintaining trust and confidence :handshake:

1 Like