SUP Transferability: Planning Discussion

[graven]

The post aims to start formal discussions on SUP transferability.

With informal discussions popping up in Discord and a draft SIP, I would like to invite input from key stakeholders, including the community, delegates, and representatives of the Foundation, to ensure that we have captured the key considerations of SUP transferability and coordinate necessary activities before a DAO proposal is put forth.

It’s a big milestone for the DAO. We need to do this right, at the right time, for it to be the ecosystem accelerant that we all want it to be.

What, Why, and When

• SUP transferability is a key step in the protocol’s decentralization and allows SUP holders to participate in liquidity and economic activities.
• Transferability of SUP may entice more users to participate in SPR.
• Transferability depends on a DAO vote, but there are important technical and practical considerations to ensure the timing of transferability is in the best interest of the DAO.

Considerations

• Audit: Prior to transferability proposal execution, the Security Council needs to ensure the changes to the relevant smart contracts (e.g., the reserve system) have been built, thoroughly tested, and audited.
• Liquidity: The Foundation should ensure adequate token liquidity to support healthy market dynamics.
• User Experience: The Foundation should ensure relevant documentation and frontend interfaces are updated, integrations with wallet providers are in place, etc.

Open Questions

1. Macro Considerations: What are the main external and environmental considerations?
2. User Pipeline: Has SUP been widely enough distributed to committed Superfluid users (knowing that transferability will change the profile of the user pipeline)?
3. Season Coordination: Should this be synchronized at the turn of a future SPR season?

[jameskbh]

Thanks for opening this discussion. Adding my 2 cents here.

AFAIK, regarding $SUP tokenomics and token distribution, this is the main document. There, we seeÇ

@dopamino

SUP Token

Purpose

• SUP will be the governance token of Superfluid protocol
• Token Functionality
  • Voting - All token holders can vote on general proposals like protocol upgrades.
  • Rewards - To ecosystem application users.
  • Staking - Stakers earn SUP rewards, and can vote on funding allocations.
  • Fees - Superfluid V1 has no fees. V2 most likely will have fees which will accrue to the DAO.
• Initially non-transferable pending a DAO vote. However this restriction does not affect token holders’ governance participation.

@dopamino

Milestones

• Q1 2025 - Token launched, Token Distributions begin
• Q1 2025 - Inaugural Ecosystem Campaigns (’Season 1’)
• Future milestones subject to DAO votes
  • Token Transferability
  • Ecosystem campaign allocations (quarterly)
  • Funding for protocol V2 development
  • Protocol fee switch (in Superfluid Protocol V2)

I want to share how SAFe handled this process, so we can compare it. The TTE (Token Transferability Event) was tied to some KPIs/Milestones, which helped to define thresholds that made sense for it. Questions:

• Is the DAO willing to set up this?
• If so, which metrics make sense in this case? (Token distribution %, relevant governance actions completed, token utility definition within the protocol/ecosystem, etc).

In addition to that (as I mentioned briefly here, liquidity provisioning, and token listing are usually in place (or well-defined) to make the TTE something meaningful.

I would like to see more discussion around those items.

[Kaf_StableLab]

Thanks for opening this up @graven!

Just want to echo what both @graven and @jameskbh pointed out: transferability makes sense, but it’s important we get the timing and setup right.

The SafeDAO example James mentioned is a great one, they used a structured set of milestones (like ratifying a constitution and defining token utility) to guide the process. It helped align expectations and gave the vote more legitimacy.

Something similar could be helpful, not overly complex, just a few clear signals that we’re ready. Maybe things like:

• Core contracts reviewed and audited
• SUP utility in V2 clearly communicated
• Liquidity planning underway
• Governance participants aligned on expectations

If the community finds value in it, I’d be happy to help outline a simple signaling SIP to frame this discussion.

[vijay]

Thanks for this well though through post!

Given the transferability vote is now live, I would encourage voters to abstain from voting until the following questions have satisfactory answers.
We have 2 weeks on the current proposal to consider and discuss, I hope @imran as well as foundation team such as @dopamino, @0xFran and @hellwolf will chime in.

Security - Is the foundation team confident that the security position of the tradability code is sufficient? e.g. audits and bounties
Liquidity - Has the foundation set up appropriate processes for liquidity provision
User experience - Is the frontend for the liquidity provision ready and tested?
Macro factors - Is market timing good to make this token tradable?

[imran]

@vijay Thank you for raising these important points—each of them deserves attention.

However, I respectfully disagree with encouraging voters to abstain. The purpose of the 14-day voting window is precisely to allow the community to express their stance while continuing the discussion. Abstaining delays momentum and creates uncertainty, especially for a topic that has already gone through significant community engagement and support.

On the specific concerns:

• Security: The tradability code is already part of the standard ERC-20 implementation—well understood and widely tested.
• Liquidity: While foundation support helps, the community and markets often drive liquidity organically after transferability. This shouldn’t be a blocker.
• Frontend/User Experience: These elements can evolve continuously. Transferability enables utility; UX will follow and improve in tandem.
• Macro Timing: Timing is rarely perfect. What matters most is enabling free movement now so that the token can integrate into broader ecosystems.

Let’s use this window to refine concerns, but I believe the vote itself should move forward decisively.

[imran]

Thank you everyone for this thoughtful and nuanced discussion. I deeply appreciate the engagement from @graven, @jameskbh, and others.

I’d like to offer a consolidated response to the key points raised across this thread and help clarify the current intention of SIP-5 while reinforcing a path forward that balances ambition with responsibility.

---

On Vision and Legitimacy

SUP transferability is not just a technical update—it’s a symbol of the DAO’s maturity, a gateway to economic participation, and a foundation for deeper alignment between contributors, builders, and capital. That said, we all share a responsibility to get it right, not just to enable movement, but to ensure that when movement begins, it is meaningful, secure, and value-aligned.

---

Security & Smart Contract Audit Readiness

As noted by @graven and others, security is non-negotiable. It’s important to clarify:
SIP-5 does not immediately implement a technical change, but instead acts as a community mandate that authorizes the DAO and Foundation to prepare for and execute transferability, subject to the necessary security review and operational readiness.

If the vote passes:

• Security Council oversight will still apply to any contract changes.
• The DAO can delay implementation until audits, bounties, or hardening of any smart contract upgrades (e.g., reserve system, if relevant) are complete.
• We can embed a final readiness checkpoint prior to execution.

---

Liquidity Provisioning & Market Setup

Token transferability without liquidity planning could create an unstable or misleading user experience. This is a valid concern, and I support the idea of the Foundation:

• Coordinating LP incentives or DEX/CEX onboarding strategies
• Ensuring there’s market depth and price discovery
• Communicating clearly what to expect post-transferability

That said, the DAO should not be locked from deciding transferability at a governance level while waiting for the Foundation to act. Instead, a yes vote gives the DAO authority to initiate and lets the implementation date remain flexible until liquidity setup is complete.

---

User Experience & Frontend Coordination

Several of you rightly emphasized the importance of frontend readiness—wallet integrations, explorer tags, documentation, and user-facing portals. Again, SIP-5 does not require these to be completed at vote time, but rather mandates the DAO to start coordinating this work.

A successful “Yes” vote should trigger:

• A collaborative plan to finish user-facing updates
• A clear go-live communication plan
• Optional phased rollout or “soft unlock” depending on interface readiness

---

Distribution Metrics & Ecosystem Maturity

As @jameskbh and @graven noted, SafeDAO tied transferability to milestones. I believe that’s a great reference point. However, Superfluid is already in a stronger position in terms of engagement, thanks to Season 1 and the deep involvement of protocol-aligned users.

Rather than creating a rigid milestone framework now, SIP-5 can serve as the governance-level trigger to authorize implementation, while:

• Allowing for a Foundation-aligned execution window
• Encouraging a public checklist of readiness metrics (audits, liquidity, UI)
• Requiring transparent reporting before the final “unlock” occurs

---

Macro Conditions & Market Timing

Macro timing is a fair point. But it’s also inherently unpredictable. SIP-5 provides flexibility—it doesn’t demand immediate unlock but allows us to be ready when the conditions make sense. That may be this summer, next quarter, or tied to Season 2.

The key is: we don’t need to delay the decision just because timing isn’t ideal today. A DAO should be able to make a forward-looking call and activate implementation only when it aligns with market readiness.

---

Suggested Refinement Going Forward

If the community prefers, I’m open to proposing a follow-up “Readiness Signaling SIP” (as suggested by others) that:

• Defines optional checkpoints (e.g., audits complete, liquidity plan live)
• Gives transparency without blocking SIP-5
• Reinforces DAO <> Foundation coordination

This allows SIP-5 to act as the mandate, and the next SIP to define the “go-live” triggers or governance guardrails, without causing decision fatigue or slowing progress.

---

In Closing

SUP transferability is not the end—it’s a beginning. And we have a rare opportunity to show how a DAO can move deliberately, but decisively.

SIP-5 respects:

• Constitutional process
• Legal and technical constraints
• The DAO’s right to vote on SUP’s core function

But also opens the door to further checks and safeguards before final execution.

Let’s proceed with boldness—but not recklessness. I’m fully committed to working with the Foundation, Security Council, and every stakeholder here to ensure a secure, coordinated, and successful unlock of SUP that supports Superfluid’s mission for years to come.

Thank you all for your time, your trust, and your thoughtful engagement.

[Euphoria]

The following reflects the views of the Lampros DAO governance team, based on our combined research, analysis, and ideation.

Thanks for opening this thoughtful discussion, and to everyone who has shared their views so far. We appreciate @imran’s detailed response addressing many of the concerns raised so far.

@imran

Rather than creating a rigid milestone framework now, SIP-5 can serve as the governance-level trigger to authorize implementation, while:

• Allowing for a Foundation-aligned execution window

We agree with keeping flexibility in the execution timeline, but we feel it would be helpful to complement this with some distribution and engagement metrics ahead of the unlock. For example:

• What percentage of SUP is currently delegated or active in governance?
• How broadly was Season 1 participation distributed across the holder base?
• Are there any concentration risks we should be aware of?

If the foundation can publish these metrics, it can help the DAO assess whether the current distribution aligns with the goals of enabling broader participation and economic utility.

@imran

Optional phased rollout or “soft unlock” depending on interface readiness

We’d also suggest considering a capped rollout mechanism (e.g., transfer limits per wallet or daily transfer caps) instead of allowlists. This approach avoids centralizing access while still offering the DAO time to monitor liquidity behavior and adjust if needed. If done transparently, it can help reduce volatility risks while maintaining fairness across users.

We’re aligned with the direction SIP-5 sets, but believe these additional steps would improve execution quality and ensure that when SUP becomes transferable, the ecosystem is well-prepared both technically and socially.

[imran]

You can check here about your questions here in reserve mechanism section Superfluid DAO Governance and Tokenomics @Euphoria

[Areta]

Thanks for bringing up this discussion @graven.

@jameskbh

I want to share how SAFe handled this process, so we can compare it. The TTE (Token Transferability Event) was tied to some KPIs/Milestones, which helped to define thresholds that made sense for it

@jameskbh brings up a great point. We were directly involved in supporting SafeDAO’s token transferability event (TTE) and milestone-based approach was one of the core pillars of the process. Below is a snapshot of the milestones that had to be met before Safe’s TTE (more info here)

Happy to share more insights from our learnings in Safe and contribute to the discussion over the coming days and weeks.

[Kaf_StableLab]

I understand now that SIP-5 doesn’t implement transferability directly, but rather authorizes the DAO and Foundation to prepare for it. While I respect the idea of “authorize now, prepare responsibly,” I’m personally more comfortable with the inverse: prepare visibly first, then authorize with confidence.

[vijay]

Unfortunately it seems you have some incorrect understanding of a few factors, I think it’s important to clarify:

@imran

• Security: The tradability code is already part of the standard ERC-20 implementation—well understood and widely tested.

Tradability code includes the Reserve contract, as documented elsewhere, which includes instant withdrawal, streaming and liquidity providing mechanics. It’s not simple and justifies caution and audit.

@imran

• Liquidity: While foundation support helps, the community and markets often drive liquidity organically after transferability. This shouldn’t be a blocker.

Liquidity management is essential for the health of the DAO and foundation, as it will provide long term stability to the funding of both going forward. If liquidity is poorly managed, there is a high risk neither will remain healthy.

@imran

• Frontend/User Experience: These elements can evolve continuously. Transferability enables utility; UX will follow and improve in tandem.

As above, needs to support net new features to enable anyone to actually use the withdrawal, streaming, staking or LPing workflows.

@imran

• Macro Timing: Timing is rarely perfect. What matters most is enabling free movement now so that the token can integrate into broader ecosystems.

Can you expand on this one? How might the token be used elsewhere?

@imran

Let’s use this window to refine concerns, but I believe the vote itself should move forward decisively.

I think your latter post expands on options for these in a better way than your first one, even if it looks rather AI-generated, although I don’t see the point in dividing into two votes in that case. I don’t think any delegate or substantial tokenholder is broadly against transferability, so why not just vote to approve transferability once we agree the signals point to success? It’s not possible to amend your current proposal which is now being voted on.

[imran]

Sorry, You are right that there are technical layers in the Reserve contract that deserve careful handling, and I agree that liquidity and UX should be responsibly managed. My intent wasn’t to downplay those, but to ensure we don’t indefinitely delay the DAO’s ability to decide.

Glad we’re aligned on transferability in principle. I’m supportive of using this vote to signal readiness and refining details in parallel, so we can move forward with shared confidence.

[0xFran]

Thank you @graven for opening this important conversation.

While there are some things in SIP #5l I agree with, and I’m generally in favour of moving forward with transferability, I’d argue a few important details are missing in this proposal.

Transferability is a big milestone for the DAO, probably the largest, as it will test demand and will put a price on the protocol. As mentioned, it’s not something that should be happening without proper consideration, coordination, and preparation.

As such, I will not support this SIP #5. For now.

That said, I do believe we are in a good spot.

1. The token has already reached over 35K users, and I expect this to accelerate significantly after TTE

2. The Reserve system set in place in the tokenomics mechanically reduces sell pressure, making it easier to sustain ongoing distributions of rewards. I am very bullish on this and hope it will allow us to keep growing sustainably.

3. The flywheel has started to turn, with users exploring multiple apps in SPR campaigns, looking to maximise their SUP allocation.

4. In terms of liquidity, the latest changes to the smart contracts (which the Foundation team has just handed off to audit) not only enables tokens inside lockers to be used to LP in Uniswap markets, but also provides built-in incentives to do this

5. We’re seeing significant community involvement and participation, both here in the forum, on discord, and on farcaster (not so much on twitter) which make me hopeful for future seasons of SPR as well

In terms of tokens distributed to the community, we’re currently around 5% if I’m not mistaken, and should reach ±10% by the end of the season. This is in line with what most project airdrops look like and should be enough for a healthy market dynamic.

The majority of the allocated campaigns for S02 haven’t gone live yet. This is due to a mix of apps not having launched yet and some coordination issues.

Getting all these apps and campaigns started is the Foundation’s priority right now.

[imran]

Are you suggesting the ideal timing for transferability would be after Season 2 completes, or once key milestones like audits, liquidity setup, and broader distribution are achieved (regardless of the season timeline)? @0xFran

[dopamino]

Thanks everyone for your comments on this thread so far.

Voting on SIP #5 is due to end Wednesday.

If SIP #5 does not pass, I wanted to suggest the following approach :

• Working Group - A “Transferability proposal working group” is created on a dedicated space in the Forum, to work on drafting the text for a future Transferability proposal.

• Members - Members of that group would include the above team who have contributed so far to the TTE planning discussion (@graven, @jameskbh, @Kaf_StableLab, @vijay, @imran, @euphoria, @areta, @0xFran) as well as any other of the say top 10 delegates who have not commented but may wish to participate. This group seems to represent broad categories of stakeholders across community, developers, delegates (specifically with experience of governance at other successful projects) and core team.

• The working group would work in the dedicated space to draft the text of a future TTE proposal to be put to the DAO. I can create the space and drop there a first draft for comments, incorporating points raised in this thread so far across : Distribution, Token utility, Liquidity, Security, UX, Macro, Governance participation

Lmk your thoughts on this approach please.