Helping SNS DAOs Succeed: Milestones Based Treasury Withdrawals

[Leadership]

Helping SNS DAOs Succeed: Milestones Based Treasury Withdrawals

There’s been a lot of chatter in the community lately around the current state of SNS projects. With so many diverse voices in play, one recurring theme keeps surfacing: the need for clearer accountability and transparency from the teams driving the SNS DAOs.

The good part is that despite the differences — whether it’s the core team of builders, the participants in the decentralization sale, or the community members actively engaging in the DAO — everyone shares a common goal: to ensure the success of the SNS projects. Every stakeholder has invested countless hours, energy, and in many cases, capital, into making these projects a reality. No one wants to see them fail.

The key challenge lies in the perceived lack of transparency, as the core team is often focused solely on executing the technical roadmap. This means that community participants often lack clear visibility into the project’s path to success, and all they see are attempts to withdraw funds from the SNS treasury without a clear picture of where things are headed.

If the community introduced a milestone-based treasury withdrawal model, it would help teams stay focused on clear goals and give the community a chance to review actual progress prior to approving more funding. Most SNS teams already withdraw funds from the treasury in tranches, meaning they request funding over time rather than all at once. What’s often missing, though, is a clear explanation of their goals when making these requests.

For this to work, we need clear, concrete milestones. Without them, it’s hard to know if a project is truly making progress. Milestones would need to span beyond the technical roadmap and may cover traction metrics such as user adoption, governance participation, community engagement, and how funds are being used — all of which are just as important for long-term success.

When a team asks for the next tranche of funding, we recommend the SNS teams to have a clarity on the following:

• Product Development: What features is the team planning to ship, until when and will these features help generate user traction?
• User Traction: Do the metrics show growth in active users, retention, and on-chain activity?
• Community Growth: Is there meaningful conversation happening on Discord, OpenChat, Twitter/X, Telegram etc.? Are the communities growing?
• Governance: Are proposals actively being made and voted on by the community — for example, before changes to the product roadmap or rebranding?
• Financial Accountability: What will they do with the funds being requested?
• Liquidity and Listings: Is the team making progress in listing the token on centralized exchanges and building sustainable liquidity on DEXs?
• Transparency and Metrics Visibility: Is the team regularly sharing updates, dashboards, or other data that clearly show project progress and usage trends?

The overall idea is that there is a clear and realistic plan for what comes next if funding is approved. As a community, if we start having this kind of structure in place it’ll make it easier for all of us to support the best projects, while also making sure the DAO treasury is being used wisely.

Below is a starter template that we propose to the community. Would love to hear what others think — especially teams who’ve gone through this process already, or members from the community who have been contributing to the DAO.

As a final suggestion: As anyone can submit a treasury transfer proposal, it is important that voters can verify the legitimacy of the proposal and the principal that the tokens are sent to. Examples are sending the proposal from a publicly known neuron, or confirming the legitimacy of the proposal and/or principal on a well-known communication channel. Please indicate in the proposal how it can be validated.

SNS Treasury Request Template:

The template covers

• A description of what was achieved with the previous tranche (see columns “committed” and “achieved”)
• A commitment of what will be delivered with the newly requested tranche (see column “new target”)

1. Funding Tranches

• Previous tranche: <date> <amount>
• Requested amount to be withdrawn with this proposal: <amount>

2. Product Development

Metric	Previous tranche		Requested tranche
	Committed	Achieved	New Target
Features completed	• e.g. Wallet integration • e.g. Feature X (deployed live at URL) • e.g. UI/UX upgrade	Wallet integration () Feature X () UI/UX upgrade ()
Work Effort (person weeks)	Design - 3 Engineering - 7 Operations - 3 … Total

• Live Canister URL:
• GitHub Repo / Commits Summary:
• [In case the committed targets were not met]: Briefly describe the reasons and how do you plan to improve this in the future
• [For New Target Features] Briefly describe how do you envision these features to help drive user traction:

3. User Traction

Metric	Previous tranche		Requested tranche
	Committed	Achieved	New Target
Monthly Active Users (MAU)	e.g. 15,000
Daily Active Users (DAU)	e.g. 3,000
Engagement (DAU:MAU)	e.g. 0.2
30 day Retention Rate	e.g. 17%
Power Users (e.g. ≥10 uses/month)	e.g. 6%
Revenue	e.g. Pre revenue
Revenue Growth Rate	E.g. N/A

[In case the committed targets were not met]: Briefly describe the reasons and how do you plan to improve this in the future

4. Community Growth

Metric	Previous tranche		Requested tranche
	Committed	Achieved	New Target
Social communities	e.g. X: 25,000 followers OpenChat: 2,000Discord: 1500TG: 1000Nuance: 7blogs with 10,000+ views
Key partnerships (list)	e.g, Dappradar
Exchange listings	E.g. Gate.io

5. Governance

Metric	Previous tranche		Requested tranche
	Committed	Achieved	New Target
Avg SNS proposals submitted (governance)	E.g. 7
Avg. active voting participation for proposals	e.g. 60%
Combined voting power of developer neurons	e.g. 17%

[In case you are envisioning any material changes to the SNS such as product pivot, rebranding, etc.]

• Have you sought approval from the community (via a motion proposal): /
• Describe what you are planning in detail

6. Financial Accountability

Metric	Previous tranche		Requested tranche
	Committed	Achieved	New Target
Number of core team members	E.g. 3
Team Salaries (total)	e.g. 20K/month
Marketing Spend	e.g. $15,000
Bounties/Incentive	e.g. $0
Infra (e.g. cycles)	e.g $1,500
Others	E.g. $0

[In case the committed targets were not met]: Briefly describe the reasons and how do you plan to improve this in the future

7. Liquidity and listings

Metric	Previous tranche		Requested tranche
	Committed	Achieved	New Target
DEXs supported	e.g. ICPSwap, Kongswap
TVL across main pools	e.g. $150K
Liquidity contributed to the main pools from DAO treasury	e.g. 10,000 ICP + 150,000 SNS governance tokens
Liquidity incentives deployed	E.g. $5,000
CEXs support	e.g. Gate.io
CEX Volume/month	e.g. $1,000,000

[In case the committed targets were not met]: Briefly describe the reasons and how do you plan to improve this in the future

8. Transparency and Metrics Visibility

• Are the main metrics employed by the team visible and accessible to everyone on platforms such as Token Terminal, Dappradar, etc? If not, why?

Please feel free to include any links to dashboards, screenshots, Figma designs, external metrics (e.g., Dappradar, DeFiLlama), Twitter/X posts, or anything else that helps the community better understand your progress and position.

[Trils]

Is this a text template to use or will these milestones be enforced by the NNS? Scammers have no problem to lie about progress, DEX liquidity, team members, etc… We’ve seen it before.
So what will this text template do?

[radu]

Many thanks for the message. The goal of those templates is help the SNS become accountable in front of their communities. While not directly eliminating malicious behaviour, explicit communication around measurable targets and results will add more transparency to how SNS projects build their products and manage their treasuries. We tried to, and hope the community will to, the importance of verifiable and transparent metrics as well as being listed on platforms like Token Terminal and show their metrics there. Hope this answers your question, happy to elaborate more if needed.

[Trils]

Thanks for your reply but I’m sure i will not be the only one finding this a bit thin.
Good teams will have no problem showing progress and it will be verifiable by the community. The bigger problem is in scammers that can still roam free within the current NNS guidelines.
There need to be stricter rules enforced like the grants from Dfinity. Milestones unlock tranches of the grant, well for teams it could unlock a portion of the treasury…

[radu]

That is exactly the thinking behind this and this is just a first step taken in this direction.

[Lomesh-dfn1]

Milestones unlock tranches of the grant

That is exactly the idea behind this.

When a team launches an SNS, the community should expect them to clearly articulate their roadmap, including a detailed plan for how the first tranche of funding will be used.

Receiving the next tranche shouldn’t be a simple treasury withdrawal proposal (as it happens in most cases today) but it should include all the information the community needs to assess progress. This template can help teams share updates in a structured, transparent way thereby helping their communities to decide on the next tranche.

[tiago89]

Thanks for putting this together

If all community and known neurons demand this format, transparency could improve. But as @Trils pointed out, the problem is complex and requires a comprehensive approach.

A true solution is too complex to be embedded at the protocol level within the SNS framework, we can’t make it more complex than it is. The protocol is good, but what’s missing are modular tools that DAOs can easily deploy and manage based on their specific needs.

Personally, I see IC Toolkit as the best next step to address this.

Imagine modules for roles, teams, payroll, contributions, metrics, and investments — developed and maintained by multiple teams, not just one. The standards already exist (thanks to @skilesare and others), and the project is in place (thanks to @rem.codes).

Now, we just need that final push to make the modules registry and economy a practical reality. This would finally empower Open Organizations to be both effective and efficient.

That’s my 2 cents, I am currently trying to help them from the PT / FR HUB and urge others to also try to help the best way they can.

[Trils]

This will do nothing imo, not everyone is following the project on this forum or on X. Look at Yral, a nicely written out roadmap with milestones and costs for a 33 member team but have barely released anything… they changed names 3 times already i think. Anything can look good on paper and this template is not gonna change anything.

It is a complex problem but we have Alien tech here and some pretty smart people, like Tiago89 suggested maybe we need some community tool that can handle the treasury payouts. After the SNS is launched it immediately transfer X percentage to this wallet and it can only release tranches when milestones are met. I’m thinking about the Orbit wallet Dfinity just created, maybe have an independant user together with the dev team in the multisig wallet…

[zensh]

This is a great improvement, but it will take a long time to implement.
For now, when voting on SNS fund withdrawals, we should first review whether previously withdrawn funds were used as planned and delivered the expected results. If not, we should vote against it.
@radu @Lomesh-dfn1

[monetaryTheorist]

Let me make two bold assumptions, followed by an unconventional solution:

1. Progress Theater vs True Verification
Current systems make it nearly impossible for communities to audit technical execution or growth metrics. Scammers can easily manipulate these metrics, forcing SNS to create increasingly complex verification systems – essentially recreating the bureaucratic mess of traditional finance while still failing to prevent fraud. Going down this way is an endless and exhausting cheater vs regulator game.

2. Price > Product Reality
Communities ultimately prioritize token value over deliverables. Imagine two scenarios:

• Project A: No development updates, but token price 10x
• Project B: Flawless execution, but token price -90%
  Which project do you think would satisfy holders more? We’ve all seen brilliant technical projects drown in market apathy while meme coins thrive.

The current SNS setup relies on the team to add liquidity. And when the SNS token holders are disappointed and want to exit, there is no or little liquidity.

Radical Solution: The Unbreakable Liquidity Pool
For an SNS project with token $ABC (team tokens vesting over years and SNS token holders receive tokens immediately after the sale or with vesting periods shorter than the team):

1. Day 1 Liquidity Lock
   Convert all raised ICP to GLDT (or USDG or a basket of stable coins) immediately upon launch
   Establish full-range ABC/GLDT liquidity pool controlled exclusively by NNS
   Make pool parameters immutable – no SNS proposal can alter liquidity rules

2. Skin-in-the-Game Economics
   Teams/participants receive vested tokens released gradually
   Financial realization ONLY occurs through market sales:

• Strong project → Community holds/buys ABC → Team profits
• Failed execution → ABC depreciates → Team gains minimized

This creates a self-regulating economy where:

• Scammers gain little without price appreciation
• Teams are financially compelled to maintain credibility
• Community sentiment directly impacts developer payouts
• Eliminates verification bureaucracy through market forces

The brutal simplicity? Let the liquidity pool become the ultimate truth machine. Either the market validates the project through price action, or the initiative dies quickly rather than dragging out as zombie development.

[apotheosis]

SNS Dao leaders should be more public about who they and what their goals are.
Clearer communication is an honorable endeavor… templates can be faked / hacked.

Maybe just ask that all SNS DAO leaders have a formal ‘investment contract’ with the DAO BEFORE launch, and clear legal steps for what is a breach of trust. No coding required, limited trust, using the age old system of courts.

“I shall not dump and pillage the treasury like a villain… if I do so you can find me here”.

[bytesun]

I agree, but as I understand it, the current problem is that developers have enough voting power to pass any proposals in favor of their demands.

[TusharGuptaMm]

Thank you, Dfinity team. This is a positive step toward bringing more transparency and accountability to SNS projects - especially relevant for us as we also plan to launch SNS for RuBaRu.

Decentralization inherently makes systems more fluid, with both advantages and disadvantages. While bad actors will always try to exploit open systems, having a structured template like this allows governance participants to conduct at least some level of due diligence.

With my experience, I’ve seen even large investment firms and VCs get misled by founders who are only chasing money and have no real intent to deliver - ultimately damaging their own credibility. Additionally, maybe introducing founder KYC could be a another step toward ensuring commitment and putting real skin in the game.

[rem.codes]

toolkit is working on a service which also could be used for transparent treasury management, the service is called “payroll” where the DAO can;

• hire people to the DAO via proposal (or fire them)
• Subscribe to services
• Do one time contracten work (with proof of delivery)

When somebody get “hired” to the DAO they need to “sign” by setting the service canister as a hotkey on a neuron, this hotkey would also be used for the recurring treasury requests for executing the payroll.

This way the DAO and “employee” both have the ability to end the contract while the community gets transparency.

Next to that the payments will be lot smaller and also give some certainty to the “employee” by getting a monthly payment.

We already have a lot of coding done for this, we just need to make it foolproof and write tests for it.

[Lomesh-dfn1]

There are two separate stages at play here, and it’s important not to conflate them:

1. Reaching a Decision:
   This is where the community votes on a treasury withdrawal proposal. A critical majority is required for the proposal to pass. If the developer team earns enough community support, the proposal is “Approved”. Until this threshold is met, no funds can move regardless of who is managing them.
2. Triggering Fund Distribution:
   Once the proposal is approved, the actual movement of funds is governed by the SNS DAO. Whether we start using a multisig like Orbit or another tool, the key point is this: if the community has already voted Yes, then the distribution will be triggered as a direct consequence. The choice of tool doesn’t change the outcome and it is the community decision that matters.

The goal of this template is to help the community make informed decisions as it forces the team to share their progress in a more structured way. It does not mean that once a team submits this template they will be automatically receiving the funds. They will still be going through the voting process and if the community feels that a certain team hasn’t made sufficient progress, they should vote against the treasury withdrawal proposals.

PS: Also note that this can be started immediately as it does not require any additional technical work. This does not mean that we should not try to optimize the process further and tools such as “payroll” by ICToolkit could be very relevant once they are available. It will always be a iterative process.

[volibear]

Why don’t we start with simple process such as disclosing grants given to developers and SNS.

I’m sure there are logs. Community can get an idea of how the funds have been used since mainnet, who were in charge of these processes and what work they have done. We can also talk about Special projects and how ICPMN and co were funded by it. Bringing a bad name to entirety of SNS and forcing other builders into zero sum games.

Since DFINITY’s wallets and neurons are private and also (for some reason excluded from Network’s supply definition). It only makes sense for DFINITY to lead by example.

I’ve never seen a crypto Foundation that excludes its own token holdings from Total Token Supply.

[Lomesh-dfn1]

This is very likely because most community members might be following the developer neurons even for critical proposals like treasury transfers.

[Thyassa]

This is amazing!

I can think of several use cases we could have for this!

[apotheosis]

We started looking into this (for Kinic) more and asked some DD in the Openchat. The team open sourced and everything so we can dive in. Looks super promising. Thanks @rem.codes

[apotheosis]

Hi @Leadership

Is this meant to be a proposal?? If so the template needs to be in markdown or another format that can actually be used. Or is it meant to post on the forum?

Generally speaking…

1. What if the only goal of the proposal is to pay market makers or list on an exchange??

2. Metrics are BS almost every time. The only true metrics are:

• Market demand for the DAO tokens..
• Market demand for the DAO’s token…
• That’s about it. Everyone in web3 is judged by one simple metric.

So we can modify this to be much simpler.

---

SNS Treasury Request Template:

The template covers

• A description of what was achieved with the previous tranche (see columns “committed” and “achieved”)
• A commitment of what will be delivered with the newly requested tranche (see column “new target”)

1. Funding Tranches

• Previous tranche:
• Requested amount to be withdrawn with this proposal:

2. Product Development

We built XYZ last quarter. We plan on building xyz this quarter. We believe it will increase token demand via xyz.

3. Progress

Did demand for your token increase since the last request? If so why? If not… why not??

---

The other metrics are meaningless and even misleading.

1. “CEX Volume/month e.g. $1,000,000” all experienced teams know why this metric is meaningless… I remember Dom talked about this in detail somewhere and why it was meaningless. I can explain it if needed.

2. User Traction all of these have no meaning. Easily faked and even if they are not.. are app specific.. What is revenue in this case?? Like how much of the token was used to pay for the product?

3. Community Growth all experienced teams know why this is meaningless. OpenChat activity is a good indicator if all of your users are in the ICP community.. really bad indicator if not. Most of the other things are bot driven. Twitter followers are mostly bots, etc, etc. Only real indicator is demand for the DAO token.

Exchange listings are not community. These are directly derived from paying for listing or getting demand from UTILITY. Getting new exchanges to list ICP projects when they previously have not is a major win! One example, is Kinic on MEXC. First one there

The foundation can support SNS projects to be the first ones on more exchanges.

---

The above template creates poor incentives that will result in poor results. It is creating an incentive for fake volume.. fake followers, and fake users.

Other note - future SNS DAO teams should sign some form of legally binding contract with the DAOs as mentioned above. It would result in much better quality without micromanaging.