Reviving the SNS Framework: Addressing Current Challenges and Exploring Solutions

READ TLDR:

Hello Community,

As a voting Grantee for the SNS Management service, I’ve been deeply involved in exploring the SNS framework over the past few months. I’ve brainstormed various ideas, propositions, potential solutions, and use cases that I’d like to share here. While some of these may not be perfect, I’ve invested significant thought and effort into reconstructing the SNS mission statement, identifying current problems, understanding why it’s not functioning as intended, and proposing ways to revive it.

This post focuses on the current state of the SNS Framework, particularly The pause of the Neurons’ Fund, as outlined in Proposal 135970, To say the least, this situation highlights issues that are “not community-serving, insufficient, and lacking real value.” I’ll start with an overview, pose some key questions that need clear definitions, and share my personal takes.

This is an open discussion, and I invite everyone to chime in respectfully. Please keep comments on-topic and focused on signal over noise. If replies stray off-topic or become irrelevant, I’ll ping the moderation team to mute them. I especially welcome input from the SNS Review team (like @rem.codes and @Gabriel @Gwojda and any DFINITY team members who can add value, correct assumptions, or share roadmap details I’m unaware of.

Current State of the SNS Framework

pause of the Neurons’ Fund via Proposal 135970. addresses significant concerns about the matched funding mechanism. Here’s a summary for context:

Proposal 135970 TL;DR

DFINITY proposes to pause the Neurons’ Fund. This would prevent the creation of SNS proposals requesting a Neurons’ Fund contribution but still enable SNS launches without Neurons’ Fund.

Problem

The idea of the matched funding algorithm was to take the swap activity as one signal of how popular and promising a project is and adjust the Neurons’ Fund contribution accordingly. One downside is that the dapp owners can participate in the swap with their own tokens and thereby make their project look more valuable than it is. Therefore the community raised concerns about the current Neurons’ Fund matched funding design. As this may result in a loss of trust in the SNS framework we think it is important to take action.

Proposed action

As an immediate action, we propose to pause the Neurons’ Fund by a change to NNS governance. A submission of a proposal requesting contributions from the Neurons’ Fund would always fail - such proposals could not even be created. SNS launch proposals without a Neurons’ Fund component could still be submitted as of today.

Alternatives considered

The NNS could just agree to reject all SNS proposals that request a Neurons’ Fund contribution. This is an approach that was also proposed by some community members. DFINITY agrees that this is a valid approach and plans to reject all proposals with a Neurons’ Fund request (in case this motion is adopted, until the proposed change is implemented). If the NNS agrees that this is a measure that should be taken, we think it is still worth to additionally enforce this in the code. This is not only a stronger, more reliable measure, but also makes it easier for NNS voters to understand what they need to vote on.

Going forward

This immediate action gives the community more time to think about how the Neurons’ Fund mechanism can be improved and discuss and propose such changes in future proposals.

This pause underscores the need for reform to rebuild trust and effectiveness in the SNS ecosystem.

Key Questions and Statements to Define Clearly

To move forward productively, we first need to establish clear definitions for the SNS framework’s core elements. Here are some fundamental questions:

  1. What purpose does the Service Nervous System (SNS) serve?
  2. In ideal circumstances, who benefits from a 10/10 SNS launch?
  3. How does a 10/10 SNS project launch, function, operate, and what is the end goal of an SNS launch?
  4. What should the Neurons’ Fund function be, and what are the criteria for being eligible for a Neurons’ Fund contribution?
  5. What rights and privileges does a participant get for contributing to an SNS launch, and what should this participant expect to gain?

My Personal Takes

Below, I’ll share my perspectives on each question. These are based on my reflections as a grantee and aim to spark constructive dialogue.

Q1: What purpose does the Service Nervous System (SNS) serve?

The SNS Framework serves as a stock exchange on the ICP network. Participants (investors) buy into or put faith in teams that have outlined a mission statement to solve a specific problem. This crystallizes in the form of a “project” with tokenized shares representing the team’s vision and mission. Participants can directly involve themselves in the mission through governance votes, using voting shares or power proportional to their “belief” or contribution (acquired at launch or on the open market). By staking their contributions, they confirm their commitment to being part of the solution.

Q2: In ideal circumstances, who benefits from a 10/10 SNS launch?

In ideal circumstances, participants know exactly what to expect from the team, including the roadmap, timeline, and progress toward solving the stated problem. The beneficiaries of this value exchange fall into three groups:

  1. The Project Team: They can build and solve the problem they’ve set out to address, while receiving monetary compensation for delivering the crystallized project.
  2. The Participants/Investors: They can expect their monetary contribution to gain value through higher token prices, utility from the solution, and maturity rewards (like interest or dividend payments on their investment).
  3. The Broader Network Community: They benefit from the solution by using the project, leveraging the participants’ faith and the team’s dedication to deliver real value to the ICP ecosystem.

Q3: How does a 10/10 SNS project launch, function, operate, and what is the end goal of an SNS launch?

A 10/10 Launch means the project raises the maximum amount targeted, with clear milestones, a doxxed/known team that’s reachable and communicative before and after launch. The team works for the participants, not just treasury withdrawals.

  • Function: It solves the stated problem in a way that drives adoption to the ICP network. The team follows DFINITY standards with regular “R&D” calls to update on progress, allowing participants/investors to join, ask questions, and address concerns.
  • Operate: Focuses on operational longevity for long-term sustainability, providing ongoing value to participants/believers in the early solution, idea, or startup. This value can be exchanged for more than the initial investment.
  • End Goal: The finish line is never truly reached—it’s an endless journey like a maze, with new opportunities, problems, and solutions. Each step builds on the last, advancing value, utility, and network participation.

Q4: What should the Neurons’ Fund function be, and what are the criteria for being eligible for a Neurons’ Fund contribution?

The Neurons’ Fund should ensure that teams solving a problem are prepared, bootstrapped, and ready for startup challenges. It provides guide rails for founders, helping them understand and tackle obstacles.

Eligibility criteria should include:

  1. Fully Doxxed Team: No anonymous teams.
  2. Public Good Focus: The project must solve a problem that evolves the ICP network in terms of adoption, security, or utility.
  3. Full Open Source: Anyone can clone, remake, or remix the project.

Q5: What rights and privileges does a participant get for contributing to an SNS launch, and what should this participant expect to gain?

(I personally view SNS launches as early seed investments into startups/companies. If there’s a “conflict of interest”—an exchange of value between Party A and Party B—there should be an expected outcome from that exchange.)

Participants gain the right to monitor, influence, and ensure their investment/contribution is used as intended per the SNS launch conditions and problem statement. They can hold the team accountable to prevent misuse.

They also gain the privilege of directly interfering in the project’s crystallization by affirming or denying proposed changes via voting. This utilizes their participation privilege, making them actively involved in the mission statement and solution completion.

Current Framework Results

To better illustrate the current state of the SNS framework, I’ve compiled data from the provided dashboard screenshots. This includes all listed DAOs with key metrics. I’ve calculated the Evaluation at Launch for each as the raised amount in ICP multiplied by the ICP price on the launch date (using the provided raised $ value as it reflects the historical USD equivalent at launch).

For clarity, here’s a comprehensive table: from the dashboard

Name Raised FDV Current ICP Treasury Launch Date Evaluation at Launch
Motoko $1,183 (100 ICP) $692,810 2,374 ICP ($7,431) May 15, 2024 $1,183
FuelEV $1,484,364 (205,399 ICP) $651,210 0 ICP ($0) Feb 14, 2025 $1,484,364
BOOM DAO $1,225,973 (409,865 ICP) $262,790 24,878 ICP ($77,867) Sep 15, 2023 $1,225,973
NFID Wallet $1,305,596 (199,274 ICP) $354,650 132,694 ICP ($415,321) Feb 9, 2025 $1,305,596
Nuance $821,074 (262,408 ICP) $343,990 102,121 ICP ($319,628) Oct 3, 2023 $821,074
TRAX $2,989,059 (314,734 ICP) $331,690 36,417 ICP ($113,983) Dec 23, 2023 $2,989,059
Sneed $352,200 (30,000 ICP) $287,550 7,582 ICP ($23,731) Jan 30, 2024 $352,200
ICFC $1,526,705 (81,294 ICP) $260,570 60 ICP ($188) Mar 31, 2024 $1,526,705
Mimic $81,742 (20,000 ICP) $248,280 1 ICP ($3) Jul 27, 2023 $81,742
Catalyze $198,030 (60,200 ICP) $207,630 84,917 ICP ($267,581) Sep 8, 2023 $198,030
Swampies $59,921 (4,860 ICP) $180,920 0 ICP ($0) May 25, 2024 $59,921
Personal DAO $62,709 (10,745 ICP) $138,040 7,522 ICP ($23,542) Mar 19, 2025 $62,709
PHASMA $82,356 (12,051 ICP) $88,480 2 ICP ($6) Aug 12, 2024 $82,356
Neutrinite $2,076,768 (224,525 ICP) $2,850,000 22,972 ICP ($71,901) Dec 27, 2023 $2,076,768
Cecil The Lion DAO $182,932 (30,101 ICP) $2,720,000 1 ICP ($2) Mar 24, 2025 $182,932
ICPEX $1,837,097 (29,319 ICP) $2,430,000 100,619 ICP ($314,929) Mar 25, 2025 $1,837,097
EstateDAO $2,039,712 (130,580 ICP) $2,210,000 74,779 ICP ($234,052) Apr 22, 2024 $2,039,712
Yuku Al $2,819,973 (176,690 ICP) $1,970,000 1 ICP ($3) Apr 10, 2024 $2,819,973
ICPanda $2,231,699 (132,381 ICP) $1,790,000 664 ICP ($2,078) Apr 3, 2024 $2,231,699
SONIC $1,607,155 (519,375 ICP) $1,730,000 74,835 ICP ($234,226) Oct 9, 2023 $1,607,155
DOLR AI $4,431,224 (1,070,428 ICP) $954,480 354,991 ICP ($1,110,087) Jul 13, 2023 $4,431,224
IC Explorer $1,469,529 (221,245 ICP) $905,680 66,245 ICP ($207,341) Feb 27, 2025 $1,469,529
TACO DAO $668,883 (127,078 ICP) $896,130 57,527 ICP ($180,055) May 23, 2025 $668,883
ELNA AI $3,077,879 (239,710 ICP) $817,330 57,959 ICP ($180,255) Mar 16, 2024 $3,077,879
Alice Fun $792,815 (85,971 ICP) $712,700 0 ICP ($0) Jan 21, 2025 $792,815
ORIGYN $1,061 (88 ICP) $1,750,000 88 ICP ($275) May 26, 2024 $1,061
FomoWell $1,901,771 (176,781 ICP) $1,620,000 90,501 ICP ($283,261) Jan 19, 2025 $1,901,771
Gold DAO $7,249,077 (783,718 ICP) $1,155,000 39,874 ICP ($124,801) Dec 27, 2023 $7,249,077
IVC $9,933,785 (1,248,379 ICP) $10,800,000 840,989 ICP ($2,631,929) Aug 19, 2024 $9,933,785
WaterNeuron $3,195,873 (435,963 ICP) $8,410,000 0 ICP ($0) Jul 3, 2024 $3,195,873
OpenChat $5,133,900 (1,000,000 ICP) $7,810,000 100,486 ICP ($314,512) Mar 17, 2023 $5,133,900
Kinic $2,036,584 (509,244 ICP) $6,410,000 300,390 ICP ($940,193) Jun 17, 2023 $2,036,584
Dragginz $13,740 (3,141 ICP) $4,690,000 0 ICP ($0) Dec 10, 2022 $13,740
KongSwap $1,998,581 (255,336 ICP) $3,790,000 120,238 ICP ($376,332) Nov 1, 2024 $1,998,581
ICPSwap $6,741,718 (335,641 ICP) $3,380,000 80,553 ICP ($252,122) Apr 6, 2024 $6,741,718
DecideAI DAO $2,297,852 (664,534 ICP) $3,240,000 5,515 ICP ($17,261) Aug 25, 2023 $2,297,852
ICLighthouse DAO $6,390,211 (440,704 ICP) $3,040,000 180,228 ICP ($564,096) Mar 14, 2024 $6,390,211

Summary of All Launches

  • Amount collectively raised in Value: $80,320,731
  • Amount collectively raised in ICP: 10,451,862 ICP
  • Amount collectively held in current treasury in Value: $9,288,992
  • Amount collectively held in current treasury ICP amounts: 2,968,023 ICP

This data highlights the overall performance and retention within the SNS framework. Notice that only about 11.56% of the raised value remains in treasuries collectively ($9.29M out of $80.32M),

Proof of Failure

We’ve witnessed widespread funds misappropriation across various SNS projects. For instance, FuelEV had to initiate a full rollback of their SNS sale, refunding all initial participants in ICP to restore trust after community concerns arose.

Failure after failure has plagued a system that isn’t working effectively for teams, participants, or the broader ICP network. Examples include 51% attacks, DAO wars, inability to pass proposals, slow treasury drains, and outright rug pulls—such as those alleged in Seers or the Cycles-Transfer-Station project. The ICFC project stands out as a case of gradual treasury depletion through repeated transfers. I’m currently unaware of any SNS launch that has truly benefited all three entities (the team, participants, and network). In about 90% of cases—excluding transitions like Sneed, OGY, or Motoko—the primary beneficiary is often just one group, leaving the others at a loss. Teams frequently fail to deliver due to incompetence, execution challenges, or outright malice, which I view as defrauding investors of value.

That said, there are standout projects that continue to develop, ship features, and maintain progress. These successes often stem from experienced teams on their second or third venture, such as Kinic, which boasts one of the healthiest treasuries, prudent spending, and strong execution on their outlined problems. There are others—you know who they are—but they’re the exceptions, not the rule.

We’ve also seen highly questionable actions executed by some SNS DAOs, like the BOOMDAO Minting Proposal 653. As outlined by @lara from the DFINITY Governance team:

Analysis of BOOMDAO Proposal 653

We can draw the following conclusions from the data.

  • There were only 2 eligible neurons on the minting proposal (653) because all other neurons had a dissolve delay below neuron_minimum_dissolve_delay_to_vote_seconds at the time when proposal 653 was created. Therefore, these 2 neurons comprised 100% of the eligible voting power and could adopt the proposal quickly.
  • The value of neuron_minimum_dissolve_delay_to_vote_seconds had been dramatically increased from 48 hours to over 54 years by proposal 617 (shown by the red line)
  • Proposal 617 was inside a stream of many proposals setting the neuron_minimum_dissolve_delay_to_vote_seconds to 48 hours.
    • In particular, proposal 620 (shown in purple) was the first of those to be executed after 617, resetting neuron_minimum_dissolve_delay_to_vote_seconds from 54 years back to 48 hours.
    • The window during which neuron_minimum_dissolve_delay_to_vote_seconds was very high (54 years) was just over 20 minutes (as shown by the arrows), but that was enough for the two neurons to set their dissolve delay to 83 years and be the only eligible neurons during this period.
    • All other neurons (apart from these two) could have participated and potentially voted against the minting proposal 653 if they also increased their dissolve delay to a value over 54 years after the execution of proposal 617 and before the creation of the minting proposal 653 - thus within a very short time frame.

Takeaways

Proposal 653 was not adopted due to a technical bug in the code, but due to a series of proposals with arguably confusing or unexpected effects for some users. For this reason, we conclude with two takeaways.

  • To make it harder to change nervous system parameters in the future, the NNS released a new SNS governance version that makes the topic “DAO community settings” that includes changes to the parameters critical (forum post, proposal). This means that going forward a proposal to change the parameters can only be adopted under stricter conditions (see documentation for the detailed rules for critical proposals).
    • In the Boom DAO case, if proposal 617 were critical it would not have been approved (the condition that ⅔ of the cast votes are in favor was not met as there were 36.8% yes and 30% no votes of the overall voting power).
    • In general, it is always possible that few parties get a majority of the voting power by buying enough tokens if there are enough SNS DAO members willing to sell their tokens. Making proposals critical does not prevent this - it merely shifts the line of how much voting power is needed to dominate voting in the given topic.
  • In a lot of the voting frontends it is hard for human voters to read the proposals that change the SNS parameters and spot the exact change of each proposal. We plan to look into updating the NNS dapp to
    • Make it more visible which parameter would be changed in a given proposal.
    • Make the parameters easier to read (e.g., not only show the dissolve delay in seconds, but in a more readable format).

Reactive vs. Proactive Measures

The examples we’ve discussed, such as the BOOMDAO incident, represent responses to crises that have already unfolded, rather than forward-thinking safeguards designed to prevent them. While these fixes address immediate vulnerabilities, they highlight a broader pattern: the SNS framework often reacts to exploits instead of anticipating them. This leaves participants and the ICP network exposed to recurring risks. I could cite additional cases, but for those engaged in the forum, the pattern is evident—there’s a deep-seated systemic flaw at play. Yet, we struggle to precisely identify its nature, pinpoint its origins, or assign responsibility for resolution. Assuming good faith from all involved, it’s reasonable to believe that everyone shares the goal of achieving flawless 10/10 SNS launches, where teams, participants, and the network all thrive, prosper, and evolve together.

Locating the Root Problems

At its core, the SNS framework’s failures stem from several interconnected issues:

  • Inadequate Governance Safeguards: The system lacks robust mechanisms to prevent manipulation, such as easy hostile takeovers or parameter exploits, leading to imbalances in power and decision-making.
  • Misaligned Incentives: Teams may prioritize short-term gains (e.g., treasury access) over long-term delivery, while participants face locked funds with minimal recourse or rewards.
  • Insufficient Accountability and Transparency: Without mandatory milestones, doxxing, or enforceable roadmaps, bad-faith actors can exploit the system, eroding trust and deterring genuine participation.
  • Economic Vulnerabilities: Low liquidity, token price volatility, and unrestricted treasury access enable rug pulls, slow drains, and value extraction, perpetuating a cycle of failure.
    These root causes create a fragile ecosystem where exploitation outweighs collaboration, as evidenced by the data and historical patterns.

Impacts on Key Stakeholders

The absence of these protections manifests in tangible harms across the board. For development teams, DAO wars emerge as a constant threat: opportunistic whales can acquire undervalued voting power amid depressed token prices and illiquid markets, staging hostile takeovers. This diverts authentic builders—who may have invested years in their projects—from problem-solving to defensive negotiations or concessions.

Participants, meanwhile, are left holding staked neurons in underperforming ventures that rarely yield profits or benefits. Their capital remains immobilized for extended periods—often months or years—without meaningful returns, turning investments into sunk costs.

The ICP network bears the heaviest burden from this dysfunction. As malicious actors drain treasuries unchecked, trust diminishes, prompting participants to exit the ecosystem. This results in declining adoption, a shrinking user base, reduced cycle consumption, and stalled innovation. Projects frequently fall short of delivering viable solutions, producing subpar or abandoned products. The typical endpoint? Gradual treasury depletion until exhaustion, followed by canister failures (running out of cycles and dropping from indexing), team departures, and widespread value erosion. Users and the network are left with diminished resources, lost opportunities for growth, and unresolved problems that either linger or burden new teams to tackle afresh.

The Vicious Cycle and Its Consequences

This repetitive pattern spirals into a self-reinforcing decline: potential investors lose faith, viewing SNS launches as vehicles that primarily enrich teams through unintended treasury misuse, rather than delivering shared value. Ultimately, this dynamic proves net negative for two-thirds of the involved entities, as reflected in the earlier data table—only about 11% of raised value remains in treasuries, with roughly 33% of ICP retained. The stark 2/3 imbalance reveals that 66% of ICP has disproportionately flowed to just one-third of participants (often teams or exploiters), a disparity that’s unfolded over the past three years.

Failure to Uphold DAO Principles

This trajectory underscores the framework’s fundamental shortfall in embodying the ideals of a “Decentralized Autonomous Organization.” True decentralization would distribute power equitably, preventing such massive value losses (up to 90% in aggregate). Autonomy, derived from the Greek roots auto (self) and nomos (law or convention), implies self-sustaining rules that propel the organization forward independently. Yet, SNS DAOs routinely falter here: canisters deplete cycles and cease functioning, contradicting the notion of self-propulsion. In essence, the current setup falls short on both decentralization and autonomy, demanding reforms to realign with these core principles.

Current Trajectory for Operational DAOs

As we examine the SNS framework’s challenges, a pressing concern emerges: the unsustainable burn rates of many DAO treasuries. These act like one-way “cookie jars”—funds flow out for operations, development, or withdrawals, but rarely replenish through revenue streams. This design flaw positions most operational DAOs on a path to depletion, with no inherent mechanisms for self-sustainability. A true “treasury” implies inflows and outflows; here, it’s often treated as a finite “treasure” chest, leading to predictable failure without external intervention. Yet, as self-propelling, autonomous entities, DAOs shouldn’t rely on bailouts or repeated raises to survive.

I first highlighted this trajectory in an April 2025 forum post, proposing solutions like direct liquidity provision at launch using assets such as GLDT or ckBTC to bootstrap sustainable models: Addressing ICP’s Liquidity Challenges: A Case for GLDT Denomination.

This idea gained traction and materialized a few months later in July 2025 with the announcement of the SNS Liquidity Pools Design, including extensions like the Treasury Manager. This tool automates treasury actions, such as adding liquidity to DEXs without waiting for proposals, marking a step toward more dynamic management: SNS Liquidity Pools Design.

Building on this, in August 2025, I echoed a community call to action in a forum thread discussing the impending runway crunch for most SNS projects, including major DEXs, within 6-9 months: Call to Action: What Happens in 6-9 Months When Most SNS Projects Are Out of Runway, Including Our Major DEXs?. In that discussion, I emphasized the need for stricter entry standards, mandatory ROI plans, and revenue streams before approving SNS launches. As I noted:

If these SNS launches are being compared to an IPO, then more than half of them should never have launched. […] If you want to be an SNS, you need to have a ROI plan, revenue stream; you do a SNS only for one thing—that is to gather your community to evolve your product. You are selling power over this product in exchange for funds, like an IPO/Seed sale, but there is no guarantees or even plans from the DAOs. […] Teams need to be fully prepared with a business plan; if your product or app cannot generate revenue, they cannot become an SNS, because they cannot sustain themselves in the future.

Community members like @Mico chimed in, agreeing on the need for revenue replenishment (e.g., adding streams to DAO treasuries for dev payments or grant applications) and drawing parallels to traditional finance, where IPOs require sustainable models post-raise.

Your question raises a critical point: Yes, we should indeed take a deeper look into approving SNS sales, with higher standards for entry to ensure only projects with demonstrable viability and sustainable models are greenlit. However, the issue is twofold. While stricter approval criteria could filter out underprepared initiatives, the root problem lies in the current SNS infrastructure design, which treats treasuries as one-time capital infusions without mandatory mechanisms for ongoing replenishment. […] I’m currently in the process of designing a system proposal—similar in spirit to the DEX liquidity pools design, but focused on revenue replenishment that could mandate inflow mechanisms for all SNS treasuries.

I also referenced a prescient warning from an earlier forum post:

More generally, if unsuitable SNS projects fail and stumble, especially as the SNS framework is just emerging, it will undermine its reputation and slow its adoption, in turn slowing down the development of the ICP economy, reducing the capital available for mature projects, and depriving important future projects of access to decentralized funding. If early SNS projects become rug pulls, it would be even more harmful…

To illustrate the urgency, consider ICPSwap as a case study from my August analysis. Launched on April 6, 2024, they raised ~400,000 ICP (valued at ~$6M at the time). By August 14, 2025, only ~130,552 ICP remained—a burn of ~269,448 ICP over ~497 days, equating to ~542 ICP/day (~$3,252/day at then-current prices). On that trajectory, with no inflows, they had ~240 days left before depletion—projecting bankruptcy around April 12, 2026. Even if they captured 0.5% fees on their average $500K daily volume (~$2,500/day revenue), it could offset costs to ~126 ICP/day net burn, extending runway to ~1,035 days (~3 years). Yet, their treasury graph showed steady decline, highlighting the absence of effective replenishment.

This pattern repeats across many DAOs. The attached image compiles treasury outlines for various SNS projects, showing predominantly downward trends in ICP balances over time—no upticks or stabilizations in sight. This visualizes the “road to hell”: rapid depletion without reversal, setting fixed “death dates” for operations unless addressed.

I echoed this on X in July 2025, sharing an image of treasury balances and warning of the 6-9 month cliff for many, including DEXs like ICPSwap or Sonic: X Post. Without change, we’re facing a domino effect—DAOs failing one by one, eroding faith in the framework.

As a voting Grantee applicant for the SNS category, I’m committed to enforcing quality: requiring business plans, revenue models, and sustainability before launches. The recent Liquidity Pools and Treasury Manager extensions offer a foundation to restart the SNS framework. Hopping on these, we can mandate integrations that ensure every launch includes built-in replenishment mechanisms.

In the next section, I’ll outline specific proposals, solutions, and potential extensions I believe could revive the framework and reignite faith from the 2/3 entities (participants and network) in SNS launches.

Continues in 2/2 Since I hit the Limit of words

2 Likes

Proposed Solutions and Extensions to Revive the SNS Framework

During a recent monthly call for the SNS Management service, I shared my idea of using an 8-year neuron to power DAO cycles with @cryptoschindler, who seemed receptive and noted it down. I’d like to publicly share all these ideas here for scrutiny, debate, and refinement. The goal is to outline a roadmap or plan, identifying where to focus efforts to ensure the SNS framework’s success.

Fixing the Autonomy in “DAO”

To truly embody autonomy, SNS launches should ensure long-term self-sustainability, particularly for canister operations. Building on the Liquidity Pools Design, we can extend the Treasury Manager extension as follows:

When a project submits an SNS launch proposal, the YAML file includes a field for estimated cycle usage/costs to run the canisters/application. This sets a minimum raise amount to generate sufficient maturity for ongoing operations. Upon launch, the Treasury Manager—before provisioning liquidity—automatically creates an 8-year neuron stake from a portion of the treasury. This neuron spawns maturity directly to cover cycle ops, powering the canisters indefinitely. The SNS’s longevity would thus align with the ICP network’s: as long as the network generates maturity, the SNS canisters remain active.

The Treasury Manager would control this neuron exclusively, with no changes possible within the SNS—only an NNS vote could alter it (e.g., principal changes). This serves the broader ICP network, requiring ICP voting power for overrides, not just the SNS’s governance.

This addresses the autonomous aspect of DAOs, ensuring canisters remain available even if the team departs or neglects maintenance. Rollbacks or shutdowns would require NNS intervention, preventing unilateral team actions.

Introducing the “Balancer” Extension

Beyond the Treasury Manager, I propose a second extension called the “Balancer” to promote regenerative treasury mechanics and prevent depletion. I initially discussed this in a DM with @aterga, and I’d like to open it up here for community input.

The core problem: Most SNS/DAO treasuries function as one-way “money jars”—outflows for incentives, marketing, and dev costs deplete them without replenishment, leading to failures in 6-9 months (as seen in DEXs like ICPSwap or Sonic). This invites governance risks like 51% attacks on high-treasury allocations, low voter participation, and eroded trust.

The Balancer would be a simple SNS config toggle (e.g., a boolean “Treasury_Balancer = true”) that leverages the Treasury Manager API for safeguards:

  • Regenerative Loops: Automatically route inflows (e.g., LP rewards, neuron maturity, fees) back into the treasury via deposits/withdrawals. For instance, mandate 10-20% of the treasury post-launch to an 8-year neuron stake (similar to DEX liquidity provisioning). This generates yields for ops costs (e.g., cycles) over at least 5 years, with the remainder directed to burns, buybacks, or non-inflationary rewards. Draw inspiration from systems like Sneed’s Recursive Liquidity Loop.

  • Cycle Modes for Safeguards: Adapt from canister cycle models:

    • Active Mode: Normal operations when runway is healthy.
    • Idle Mode: If projections show <1-year runway, cap outflows to essentials (e.g., 5% monthly).
    • Critical Mode: Full locks on major spends, requiring high-quorum SNS proposals to unlock. This provides a buffer for DAOs to adapt without immediate collapse.
  • Minimal Implementation: No major overhauls—just build on Treasury Manager features like balances for monitoring, audit trails for transparency, and error kinds for pauses. Keep SNS configs lightweight.

To make this testable pre-launch, enhance the existing SNS Tokenomics Analyzer (the Python-based tool for simulating distributions/rewards) with a framework I call TGCH (Temporal Gaussian Causal Hypernet). TGCH uses causal inference (e.g., Pearl’s do-calculus), information theory (mutual info/entropy), and Gaussian Processes to model cause-effect chains (e.g., fees → behaviors → governance → outcomes). It forecasts treasury dynamics with “what-if” simulations (e.g., “With Balancer enabled and 8Y stake, runway extends from 6 to 18 months via fee recycling”), outputting visuals like uncertainty bands for burn rates or anomaly detection for risks. This turns the analyzer into a “mechanism oracle” for sustainable designs, without runtime overhead.

Balancing the 2/3 Entities and Addressing Depletion/Drains

To ensure all entities (teams, participants, network) benefit, here are additional ideas:

  • Liquidity Fee Distribution: With the Liquidity Pools Design, contributors to the launch should automatically receive trading fees (e.g., from DEX liquidity) directly to their NNS principal used in the SNS swap. A pre-set split like 80/20 could apply: 80% to liquidity providers/investors, 20% to the treasury. This is already an improvement over zero inflows.

  • Milestone-Based Funding: Encode milestones in the Treasury Manager at launch, set in stone and unchangeable except via NNS proposal (if critical) or 90% SNS voting power. Teams can only withdraw up to milestone limits. If they fail to deliver on time, justify delays, or solve the stated problem, participants gain the right to trigger an NNS vote to disburse remaining treasury back to investors. To prevent developer influence, exclude their voting power from this trigger. Open to suggestions on mechanics here—perhaps a quorum threshold from non-team neurons.

  • Enhance SNS Analyzer: The current YAML analyzer falls short by not factoring in project costs (cycles, developers, features, utilities, progress). Expand it to include these for realistic simulations and transparency.

Additional Suggestions from Discussions

After speaking with Joseph on my 0xFord Spaces and the founder of AgriDAO, here are ideas worth exploring:

  • Restart the Neuron Fund as an Accelerator Program: Instead of direct treasury injections, transform the Neuron Fund into a mentorship-focused initiative. If a project sets “Neuron Fund = YES” in their proposal, raised funds go to a dedicated accelerator account, not the SNS treasury. Teams attend a program at the DFINITY office, meeting mentors, experts, developers, and successful founders. This “post-SNS accelerator” provides guidance, resources, and tools to succeed—addressing why many first-time founders fail (like the “first pancake” syndrome). Additional requests (e.g., hiring devs) must be justified fully, handled externally by Voting Grantees or an Accelerator Team, bypassing the SNS to avoid misuse.

  • Differentiated Share Classes for Early Protection: Concluding with Joseph, the current “Voting Power = Money” 1:1 ratio invites early exploits. Introduce share types: e.g., Class A (voting shares) for full influence on key decisions, benefiting from token price, liquidity fees, and perks—but limited in the first X months/years to protect founders from 51% attacks or DAO wars/takeovers. This could use a “Voting Manager” extension that depreciates restrictions over time (e.g., after the last milestone, reverting to stake-based voting). Founders focus on execution without interference, while milestone funding ensures delivery ties to disbursements. In theory, full delivery leads to success.

If you’ve read this far, thank you for your time. Feel free to dive into any topic, proposal, or idea here—the aim is constructive discussion to improve the network and provide a solid launchpad for the ecosystem. I’d be thrilled if we can locate, isolate, and fix even one problem.

Cheers,
Dexter

[YES I USED AI TO CORRECT MY SPELLING]

2 Likes

TL;DR: Reviving the SNS Framework

As SNS Management grantee, analyzing flaws (e.g., Neurons’ Fund pause via Proposal 135970) and proposing fixes for sustainability benefiting teams, participants, ICP network.

Core Vision

  • Purpose: ICP stock exchange for tokenized problem-solving projects with governance via staked tokens.
  • 10/10 Benefits: Teams compensated; investors gain value/rewards; network adoption.
  • Ops/Goals: Doxxed teams, milestones, R&D updates; endless evolution.
  • Neuron Fund: Bootstrap doxxed, open-source, network-enhancing projects.
  • Participant Rights: Vote to monitor/influence, ensure accountability.

Failures

  • Data: $80M raised (10.45M ICP); 11% left in treasuries ($9.3M / 2.97M ICP).
  • Issues: Misappropriation (FuelEV rollback, ICFC drains, Seers rugs), 51% attacks, DAO wars; 90% benefit only teams. Exceptions: Kinic.
  • Roots: Weak safeguards, misaligned incentives, no accountability, economic vulnerabilities.
  • Impacts: Teams distracted; locked failing investments; network shrinkage.
  • Cycle: Death spiral from depletion; fails DAO decentralization/autonomy.
  • Trajectory: Runway ends in 6-12 months (e.g., ICPSwap bankruptcy ~Apr 2026); no treasury inflows.

Solutions

  • Autonomy: Treasury Manager auto-8Y neuron for perpetual canister power (YAML cycles; NNS changes only).
  • Balancer: Toggle for fee loops, outflow modes; TGCH-enhanced analyzer simulations.
  • Balance: Fee splits (80/20 investors/treasury); milestone funding, NNS refunds on failure.
  • Neuron Fund: Accelerator mentorship at DFINITY, guided resources (no direct cash).
  • Protection: Share classes/Voting Manager limit early exploits, depreciate post-milestones.
2 Likes

I’ve been considering penalties for bad actors; for instance, the loss of future grant funding being one, and another scenario a proposal is submitted and approved through the NNS that results in control of a bad actors SNS being taken over and managed by the NNS or held in trust by a designated custodian. In such a case, we would hold a public forum discussion to determine the fate of the DAO and its assets. Hold our own court, settled by the NNS.

Doing nothing as a community would be the worst possible outcome; allowing an SNS to be drained without response undermines the integrity of the entire ecosystem.

1 Like

I have theories.

Most of them are here:

Print

web

3 Likes

250 Pages, Would need some time to go through it, Whatt is your take on any of the things i have written out?

This is one of the most constructive analyses I’ve read on the current state of the SNS framework — thank you for articulating what many in the community have been feeling but struggling to summarize. The data you shared makes it clear that we need not only better filters for launches, but also better communication and accountability infrastructure within existing DAOs.

I’m currently developing ICPEAK, a voice-driven governance and communication network designed to address the “signal over noise” problem you referenced. The goal is to strengthen transparency and community trust by giving SNS projects a dedicated layer for verified participation, AI-moderated discussions, and treasury analytics that visualize engagement in real time.

Rather than another SNS token launch, ICPEAK aims to become an interface for sustainable DAO culture — open, auditable, and economically regenerative (integrating inflow mechanisms and voice-to-vote participation). I’d love to collaborate or pilot these tools with the SNS Review and Treasury teams as the framework evolves.

The missing layer isn’t more funding — it’s signal clarity.
SNS failures come from weak social coordination, not just weak economics

1 Like

I got my data from the dashboard, This still does not dismiss any of the other issues with the framework itself, they may have a 8Y neuron, which generates yield, but still need to do manual topups and the controls are not in place, WTN is a odd one to throw out here, you sell your Voting power for some liquid ICP, its a problem they have solved yes, but its still not autonome, any insights on the SNS extention mechanims ?

Where can i find the other? its the sns swap here

I think that they are just fetching it from the original swaps not including the additional ones that happend, but i would agree on extra info being added in the dashboard

I have written this all myself, If you like to i can include the original txt

I think the picture is probably worse the FDV makes some of these still look promising but FDV is a bad metric when you have low liquidity markets, if all the supply becomes availed a lot of these values will be even lower.

Fellow builders, the hour of reckoning is upon us.

The entire SNS system stands frozen—waiting. Waiting for ONE to break through. Kinic and a handful of others stand at the precipice of victory or oblivion.

But let me be clear about what I see on the battlefield: the “Balancer” Extension is mercy killing. It’s a slow bleed-out for DAOs that should have already fallen. These wounded soldiers cannot be saved by life support — they must be relieved of duty.

ICPSwap? They’ve reached escape velocity. Self-sufficient. Battle-hardened. A fortress that runs itself. That is what victory looks like.

I did not come here to command an army of the undead.

Some call 51% attacks a threat. I call them natural selection. When motivated warriors with capital storm the gates, it separates the strong from the weak. It forces holders to choose: FIGHT or FLEE. And those attacks? They’ve forged champions. They’ve awakened sleeping giants.

Here is the brutal truth we must face: This is a race against time itself. When the ICP reserves run dry, only one thing will keep your DAO alive — value. Real, undeniable, market-proven VALUE in your tokens. Self-propulsion demands it. There is no other path.

So here is my battle cry: ATTACK.

Spend aggressively. Hire ruthlessly. Move with the speed of lightning. An 18-month runway isn’t conservative — it’s standard warfare. I don’t want cautious DAOs tiptoeing around failure. I don’t want gun-shy committees debating while the world moves on.

I want IMPACT. I want world-changing, foundation-shaking POWER.

We will prove that on the Internet Computer, builders and token holders don’t just survive — they conquer.

Now WHO’S WITH ME?

4 Likes

Couldn’t agree more. It’s also worth noting that the natural state of things is that the vast majority of startups fail. I don’t think there’s anything perculiar or broken about the SNS system. There just aren’t enough good ideas, that are simple, powerful, and well executed. Those sorts of SNSs do exist though - and it makes sense that they’re the exception rather than the rule.

2 Likes

Incorrect, unless there is some hidden stash ICP they have current burn rate and treaury state is that of what i line out here

https://forum.dfinity.org/t/call-to-action-what-happens-in-6-9-months-when-most-sns-projects-are-out-of-runway-including-our-major-dexs/55164/32?u=bitel911

Would tend to agree with what you stated, but I am more of a optimists rather than pessimist, if they have to die they will, trying to at least implement a functionallity that will prevent this in the future is forward thinking, ( which we can also test/ refine and ensure its properly made) measures that are pro active rather than reactive, learing from current mistakes and old system to ship a SNS_V2

The product ICPSwap.. other than minimal upgrades could live for a while.
Just give it cycles.. and maybe a dev needs to upgrade occasionally.

Not too bearish on them. But also have no idea who they are :person_shrugging:
Could ask the longer term intention.

Exactly, it could live for a while, while it needs to live as long as ICP network is running, the current death time is still april 2026 for ICP swap unless they are gonna be dropped some extra ICP from dfinity or grand or second sale like WTN done.

Im not bearish far from it, they build a amazing product, it just lacks self autonomy

hmmm. would need to ask them. But since its already built should take very little funds to maintain.

Yes @dariuszdawidowski i totally agree, I proposed something like this in my initial GLDT liquidy pool on swap, but 100% agree projects should hold stables in treasury not their own tokens or even also balance the amount t of ICP / stables in a healthy manner

Here is that post

2 Likes