[RFC] When, and under what circumstances should SUMR transfers be enabled

[chrisb]

Hi all,

As many of you probably know, from July 1st, governance can vote to enable transferability of the SUMR token, and as such, start trading on the trading. What I want to do here is start the conversation around what the community, and in particular, delegates, see as the timeline for doing so, and if there are any circumstances or milestones in place prior to this happening. Of course, someone could just put forward a proposal to enable this, and this post is not to advocate against that - I simply want to align Summer Community to allow for the best possible performance of the token once it becomes tradable.

There are many members here with a vast background across DeFi, and I expect some very useful experiences, and I would really like to hear all the thoughts everyone has.

Below I want to share some of my own idea’s, which should not be seen as any sort of exhaustive list, of what I think some trigger points could be. Some of these will likely need to link off to separate RFCs for more in-depth discussion around them if they want to be considered further. Crucially though, I want this to be a kickoff point to bring ideas, thoughts and opinions into the open.

1. Minimum TVL - Do we want to have a TVL value, where we feel the product flywheel is sufficient to enable transferability… be 150m, 175m, 200m etc… something solid that says “From this point, we should be in a good place for the token launch”

2. Treasury deployment - Do we want to have something in place to utilise the treasury, such as buybacks or a strategy of putting it towards liquidity on certain avenues. This I think is probably directly related to the amount - but what, from a technical point of view do we want to have in place before enabling the token transferability that will help support the trading of the token at the start.

3. Protocol Treasury - currently, at the time of writing, this sits at around $88k. What sort of value do we think needs to be in the, if there needs to be a value, in order to enable the trading of the SUMR token to support DEX liquidity perhaps.

4. Liquidity Incentives - what, if any incentives do we want to move to any liquidity markets. Aerodrome immediately comes to the front of my mind as a simple one. The token is issued on Base, and Aerodrome is regularly in the top 3 DEX markets across Ethereum and Solana ecosystem, and the highest trading avenue on Base (source: https://dune.com/hagaetc/dex-metrics). Aerodrome also provides easy ways to incentivise markets, which we could easily do with SUMR for example.

5. Updated staking module - currently, our SUMR staking module as part of governance is very simple, due to the simplistic nature of the token not being transferrable. There are no lockups, there are no benefits for keeping it in longer etc. The staking modules goal at the start was to be an incentive to claim the airdropped SUMR tokens, and delegate them in governance in order to get the flywheel going. As the token moves to become tradeable, it would be wise, in my opinion, to expand the current staking module, creating lock-up incentives and penalties for withdrawing early.

There are likely some other things, how many holders of the tokens etc - there are a number of stats across the various dune dashboards kept up to date by the Summer.fi team. The SUMR token one can be seen here: https://dune.com/lazysummer/sumr-claims

Again, I want to emphasise that these are just very high level thoughts, not an exhaust list of options, and I would very much welcome, and encourage, delegates and the community to input some of their thinking for the enabling of transferability of the SUMR token.

I believe once we are aligned, we can then clearly communicate and work towards enabling the transferability and continue the growth of the Summer Protocol to $1Bn

Tagging @Recognized_Delegates

[rspa_StableLab]

Very interesting context here are SAFE’s proposal for transferability:

[SEP #3] Towards clarity on milestones before voting on enabling...

They tied it to completion of a set of milestones.

And Morpho’s, which came at a time when the team felt it was ready and had distributed enough rewards:

Vote to Enable Transferability of the MORPHO Token

[JC545]

Appreciate this post, I think it’s a really valuable one to get out ahead of the transferability conversation and start building some alignment.

I agree that a milestone based approach makes sense. Rather than trying to list out everything that might be relevant I wonder if we could prioritise a smaller set of the most important ones, the things that really need to be in place before transferability goes live. Some kind of prioritisation framework could be helpful here, even if informal, for example distinguishing between

• “must-haves” or things that if not in place could harm the token’s credibility or functionality post-transferability. e.g. minimum liquidity, updated staking
• “alignment” milestones, things that are important for decentralisation and credibility but not necessarily blocking. They affect legitimacy and long-term health. e.g governance participation or token distribution levels
• “nice-to-haves” or things that are helpful for optics or signalling strength, but aren’t necessarily essential to transferability. e.g. protocol treasury targets or TVL levels.

Using a framework like this might give us a clearer view on what should block transferability vs. what would be nice to have.

The other piece I’ve been thinking about is around liquidity and trading, specifically how we make sure the token can trade in a healthy, credible way from day one. Aerodrome makes sense as a venue, especially given it’s Base native, but I think it’s worth opening up the discussion to some other mechanisms and tools that could be layered in alongside that.

A few that come to mind: protocol-owned liquidity (maybe locked for 6–12 months), something like a Balancer-style LBP for early price discovery, or using Uniswap v3 / Arrakis-style vaults to concentrate liquidity around a target price range. There’s also perhaps the option of incentivised LP campaigns for the community.

I think a broader conversation around liquidity provision and market structure to explore additional options might be a valuable discussion.

[FBrinkkemper]

Thanks @chrisb for opening the floor for this discussion. Generally - I think there is no perfect way of making this decision. The transfer ability can come too soon, where the token lands flat, and people loose interest and can come too late, where people have already lost interest. Both can harm/kill projects.

Ultimately I think the choice should be drive by long term protocol growth. The advantage of being early could be that it might be beneficial in achieving collaborations with e.g. integrators if they also are receiving something transferable.

Regarding the metrics - I’m doubtful any of the mentioned metrics rightfully capture the ‘long term protocol growth’ objective besides the updated staking module. Therefore I think all of those others should be nice to haves, whilst the updated staking module is key in aligning that long term value of tokenholders, users, and protocol.

Aside from that I think the community should be open to proposals for radical investments of the community SUMR allocation. E.g. matching incentives coming from the foundation for integrators, or a recurring massive raffle towards protocol users, or other growth oriented initiatives. No idea is too wild here.

[jensei]

Super timely @chrisb and, in my view, one of the most important strategic conversations for Lazy Summer as we move into the second half of 2025.

SUMR transferability is a phase shift in how this protocol is perceived, used, and governed. I appreciate the way you’ve outlined key considerations, and I’d like to build on that with both some context from adjacent DAOs and some concrete suggestions.

---

Context from across the DAOspace

A few learnings from similar transitions might help shape our direction here:

Element Finance (ELFI):
Element delayed ELFI token transferability until they felt the product had “found its market” and their tokenomics could drive retention rather than speculation. They also launched with vesting + incentives baked into liquidity pools to manage volatility early on. Notably, they waited until governance had real stuff to govern.

Comparatively, I definitely think that Lazy Summer DAO has a lot to govern as well as the project getting mature as we speak. Here I would love to highlight the launch of the token transferability to have some baked in incentives to prevent a dump.

Optimism (OP):
Rather than launch with liquidity mining, OP leaned heavily on mission-aligned grants and retroactive incentives. They spent time framing the purpose of the token before worrying about trading.

I know we are governing here a DeFi protocol rather than a L2/network. At the same time, there are lessons to be learned here as well. Should we look into grants / incentives across DeFi (our integrators)? I believe what NAMADA does when it comes to campaigning/distributing their token via retro-active public-goods funding is a great way to get the token to the right hands (e.g.: defi collectives, builder collectives, etc.)

Arbitrum (ARB):
ARB launched with immediate transferability — and while the rollout was a success in some ways, it’s clear the tokenomics had not caught up to utility. The speculative spike (and decay) is worth learning from.

Besides these, I have looked through SAFE, MORPHO, SUP, …

---

In line with your thinking, here’s what I’d personally like to see as part of our path toward SUMR transferability:

On the Product Side:

Let’s align token utility with protocol depth.

• Set a TVL milestone — something meaningful like $300M to $500M, with diversified vault adoption (across Base, Ethereum Mainnet, Arbitrum, Sonic, and others).
  *The product is there! We need more meaningful integrations and we hit these milestones, sooner than later.

• Ensure governance activity is healthy (delegation %, vote participation, proposal throughput). *This seems like we are on it, and doing well, we have voted on delegate compensation and it is important to keep tracking the performance and decentralization of the DAO.

• From my personal experience, being in person with the users, with the builders, and with the community is where the magic happens. Here, I would suggest a strong marketing push via presence at as many ecosystem events as possible - conferences, hackathons, meetups.

** DAO Treasury / LPs:**

Before listing, be able to back it.

• I suggest we set a protocol treasury floor, e.g. $240k to $400k in liquid tokens (stables + ETH). This allows for strategic deployments like liquidity bootstrapping of SUMR tokens as well as continued delegate funding, and grants.

• Design a liquidity strategy:

  • SUMR/wETH or SUMR/USDC pool on Aerodrome or Base-native DEX.
  • Seed with protocol-owned liquidity or incentivized LPs.
  • Use SUMR staking yield as sweetener (via veSUMR gauges?).

SUMR Staking v2:

Make holding SUMR more meaningful, not just tradable.

• Redesign SUMR staking (maybe via Tally) with:

  • Optional lock-ups (longer = higher weight)
  • Boosted voting power based on time-weighted stake
  • Distribute protocol rewards

This aligns incentives between SUMR holders, long-term alignment, and meaningful protocol participation (delegates).

Comms.:

We should not surprise the market, we should lead it.

• Put out a clear timeline: e.g. “Goal is to enable SUMR transfers in Q3, pending governance vote.”
• Set expectations for phased utility unlocks, not a “number go up” moment.
• Share the WHY behind SUMR — governance, vault direction, emissions management, fee sharing — not just a ticker.

This I see highly related to the recent post by @samehueasyou:

@samehueasyou

TL;DR: Make your community rich, and they’ll do your marketing for you.

This does not mean that we don’t have to push and execute a very well structured and planned communication, before enabling the transferability of the token.

---

I would suggest we turn this RFC into a Transferability Readiness Checklist, and use it as the basis for a phased rollout plan. I’m happy to help draft this into a more formal SIP when the time is right.

An important note I would like to highlight, is to make sure we are ready to react to anything that comes our way. Due to permissionless nature of our governance, anyone can propose a vote to enable transferability of the token.

*I do not suggest to coordinate a decision making, all I suggest is making sure @Recognized_Delegates have understanding what impact such decision will have.

–jensei

[Eren_DAOplomats]

It’s the right call to focus on what actually matters for long-term growth, not just surface level metrics. We’ve all seen how quickly opportunistic TVL can come and go.
The only thing that creates real, lasting demand for $SUMR is deep utility.
That’s why our top priority should be fast-tracking an upgraded staking module that offers real yield or directs emissions like SUMR staking v2 as told by @jensei .
Let’s give $SUMR a clear job first. After that, enabling transfers becomes a much safer and more obvious next step.

[brandromeda]

“The only thing that creates real, lasting demand for $SUMR is deep utility”.

This is very very true. I don’t want to yeet my $SUMR airdrop but without a solid utility, most people will do this (including me). I like the protocol and I’ve been a user for a long time. I’d love to be able to collect a decent yield with my existing holdings and participate in the future of protocol.

[vumichien]

Thanks @chrisb for kicking off this crucial discussion - the timing couldn’t be better as we approach the July 1st milestone.

After reading through all the thoughtful responses, I’d like to add a few perspectives that might complement what’s already been shared:

On the Milestone-Based Approach: I strongly agree with @JC545’s prioritization framework distinguishing between “must-haves,” “alignment milestones,” and “nice-to-haves.” This prevents us from getting stuck in analysis paralysis while ensuring we don’t skip critical foundations.

Building on @jensei’s Comprehensive Framework: The $300M-$500M TVL target feels appropriate, but I’d suggest we also consider TVL retention metrics - not just peak numbers but sustained growth over 60-90 days. This helps differentiate between mercenary capital and sticky protocol adoption.

Enhanced Staking Module - The True Priority: Every response has highlighted this, and for good reason. However, I’d propose we consider a two-phase staking approach:

• Phase 1: Quick implementation of basic lock-ups with voting weight multipliers
• Phase 2: More sophisticated yield distribution and gauge systems post-transferability

This prevents the perfect being the enemy of the good while still providing meaningful utility from day one.

Liquidity Strategy - Beyond Aerodrome: While Aerodrome is the obvious choice for Base, we should also consider cross-chain liquidity planning. Given Summer.fi’s multi-chain presence, having SUMR liquidity accessible where users actually interact with vaults could be valuable. Perhaps start with Base but have a roadmap for expanding.

Community Readiness Signal: Beyond the technical milestones, I’d suggest tracking community sentiment - maybe through delegate polling or broader community surveys. The transition to transferability affects everyone holding SUMR, so ensuring community buy-in feels important for legitimacy.

Proposal for Next Steps: I support @jensei’s suggestion to turn this into a formal “Transferability Readiness Checklist.” Could we establish a working group to draft this, with target dates for each milestone? This would give the community clear visibility into progress and help prevent rushed decisions.

Looking forward to seeing how this evolves - the thoughtful approach here gives me confidence we’ll get this right.

[rspa_StableLab]

Here’s another good discussion on transferability from Superfluid, who’re deciding the same thing atm

SUP Transferability: Planning Discussion

[El_Nino]

IMO it doesn’t make any sense to enable SUMR transferability without having a decent utility in place. Long term goals should be the priority.

[vaaluel]

I think token should just be made tradeable. Let believers buy cheap and early while non believers are not forced to hold

[nakamoto]

thanks for all the solid discussion above

while i agree that token transferability should have some guidelines and goals attached to it i also think we should have a simple plan for “what if the vote passes really soon”

i’ve participated in this process for SAFE dao and a few others and personally it seemed to drag on (though the result was fine in the end)

i vote for transferability soon - but i also wonder what the majority token holders think?

but that’s what this forum is for

hope to hear more opinions soon

[chrisb]

Thank you to everyone that has replied and added their comments here so far. Today is an important milestone day that gives governance the power to now enable transferability when it is ready to do so. It is then, more important than ever that we keep this conversation going and identify the key points around when transfers should be enabled so it can be clearly communicated to the wider community and user base.

On some comments in particular;

Working group

@jensei

I would suggest we turn this RFC into a Transferability Readiness Checklist, and use it as the basis for a phased rollout plan. I’m happy to help draft this into a more formal SIP when the time is right.

@vumichien

Could we establish a working group to draft this, with target dates for each milestone? This would give the community clear visibility into progress and help prevent rushed decisions.

I think this is a great shout, and I very much like the idea of a working group that focuses on this and comes back to governance with updates and progress. I think it would be important to clearly identify the deliverables for this group, and expected timeline. @jensei I think it would be good to put the RFC for that forward asap and the proposal for selecting the participants and deliverables.

One thing I would like to add though is making sure we do not create a slow, overly engineered process that has too many sticking points. Momentum on both the Protocol and the SUMR token is going to be key - and I think we are probably all aligned in wanting to make the token transferable as soon as practically possible.

Community Readiness

@vumichien

Community Readiness Signal: Beyond the technical milestones, I’d suggest tracking community sentiment - maybe through delegate polling or broader community surveys. The transition to transferability affects everyone holding SUMR, so ensuring community buy-in feels important for legitimacy.

I think this is a really important one that shouldn’t be ignored either - waiting too long as the existing farmers/holders will move on and forget about it. We need a way IMO to keep track of this - perhaps the working group could put something forward and report on this each time too. But it’s an important one that in someways goes against the other measurable items such as TVL etc.

Other incentives/growth ideas

@FBrinkkemper

Aside from that I think the community should be open to proposals for radical investments of the community SUMR allocation. E.g. matching incentives coming from the foundation for integrators, or a recurring massive raffle towards protocol users, or other growth oriented initiatives. No idea is too wild here.

I think this is a great shout too, and something we as a community should explore more to use the large community SUMR allocation to further incentivise adoption and integrations.

Upgraded Staking Module
This seems a very important one, if not the most important, from a lot of the comments, and I couldn’t agree more. We need a strong viable use-case for the SUMR token beyond just governance, that provides long term alignment and meaning participation.

We (Summer Labs Co) have been discussing this internally recently too, and an RFC for an upgrade to the Staking Module (and SUMR token to enable more functionality like this moving forwards) will be proposed. I will share a link here when it’s out.

–

IMO, the next steps should be;

• Put out the RFC for the working group to define deliverables, framework and next steps - @jensei
• Understand current community sentiment to ensure we don’t have misaligned expectations - Not sure who yet.
• Put out the RFC for the updated Staking Module (and token upgrade) - @chrisb

tagging all @Recognized_Delegates for your continued input and discussion

[MasterMojo]

@chrisb

This seems a very important one, if not the most important, from a lot of the comments, and I couldn’t agree more. We need a strong viable use-case for the SUMR token beyond just governance, that provides long term alignment and meaning participation.

We (Summer Labs Co) have been discussing this internally recently too, and an RFC for an upgrade to the Staking Module (and SUMR token to enable more functionality like this moving forwards) will be proposed. I will share a link here when it’s out.

I 100% agree - Looking forward to this proposal as I feel Utility season is here for tokens, and $SUMR could kick things off!

[jensei]

@chrisb

@jensei I think it would be good to put the RFC for that forward asap and the proposal for selecting the participants and deliverables.

This is super exciting and I am already drafting some thoughts. Will do my best to bring this proposal up as soon as possible!

---

Also really looking forward to the updated Staking Module RFC!

–jensei

[chrisb]

As part of this discussion, and to extend on one of the most highlighted points being upgrading the staking, I have proposed an RFC to continue the specific discussions → [RFC] SUMR token upgrade to allow for updated Governance Staking Module

One of the critical components of this is the need to upgrade the SUMR token in order to meet some of the requirements being suggested above - so it will be critical to keep in mind as well during this discussion.

[vaaluel]

I think crunchy_vertex on discord is pretty on point

[crunchy_vertex]

Hi all , I have shared my thoughts regarding transferability in our discord channel but thought I’d post it here as well . Why I think its important to do it soon :

1. Market Discovery and Liquidity,Until SUMR is tradeable, it has no price discovery—users can’t know its market value. Once listed, liquidity pools (e.g., on Aerodrome, Uniswap) will set a real-time price, letting users value rewards, governance power, and their positions.
2. User Confidence and Engagement,users earning SUMR through staking, vaults, or Sonic vaults are holding an illiquid asset. If too much time passes without liquidity users may lose interest or move capital elsewhere. It creates uncertainty over the real value of points or rewards.
3. Protocol Legitimacy and Governance Activation,SUMR is a governance token—but without liquidity or tradability, its utility is frozen. Transferability unlocks: Community voting DAO decision-making (e.g., emissions, parameters) Full transition into decentralized control
4. Network Effects and Composability,Other protocols (e.g., lending markets, yield optimizers) can’t integrate SUMR unless it’s liquid and price-aware. Listing enables: SUMR-backed loans LP staking strategies Inclusion in DeFi indexes or derivatives
5. Defensive Timing (Preventing Dump Risk),The longer SUMR remains untradeable, the more backlog of potential sellers accumulates. A gradual unlock strategy, paired with early tradability, helps: Smooth out selling pressure Foster early market makers Encourage long-term holders to participate in governance

just my two cents

[pete]

@jensei

Design a liquidity strategy:

• SUMR/wETH or SUMR/USDC pool on Aerodrome or Base-native DEX.

Regarding the SUMR liquidity strategy, I would like to throw another idea into the mix: Yield Forwarding

If the DAO was open to pairing SUMR with superOETHb (Origin Protocol’s high-yielding ETH LST that is supported on the Summer ETH Base vault) instead or in addition to wETH, we could turn on Yield Forwarding for the pool (more info here and here). With Yield Forwarding we can take the underlying yield generated from the superOETHb in the pool and have it sent directly to a DEX’s gauge as a bribe on the pair - this basically creates a constant bribing system on the pair, funded by superOETHb itself rather than being paid by Summer.

Alternatively instead of going straight to bribes, the yield can be forwarded directly to the Summer DAO treasury - so the DAO would be earning the pool’s trading fees, plus the superOETHb yield on top. Here is a simple graphic of the two different applications:

Presumably the pool volume should be similar on a SUMR/superOETHb pool as it would be on a SUMR/wETH pool since superOETHb is 1:1 with ETH. About 30 different projects have set up pools with Yield Forwarding enabled and have been enjoying the passive yields across Base, Sonic, and mainnet.

[samehueasyou]

fascinating and worth considering cc @chrisb @halaprix