SSS DeFi PUBLIC TEST
Open App
Blog / Research
Research 2026-04-12 KongSwapICPDeFi

What We Learned from KongSwap: A Product-Led Postmortem

A product-led review of KongSwap’s rise, innovation, speed narrative, governance controversy, and sunset process — and what on-chain trading systems like SSS should learn from it.

cover
Executive Summary
  • KongSwap once showed real traction, strong product perception, and a compelling speed narrative on ICP.
  • Its decline exposed deeper issues around governance legitimacy, security handling, shutdown design, and long-term trust.
  • SSS should prioritize safety, observability, and governance maturity before token-first expansion.

What We Learned from KongSwap: A Product-Led Postmortem

By SSS DeFi Product Manager

In crypto, failed projects are not rare. What is rare is the ability to review failure seriously, calmly, and systematically.

The reason for writing about KongSwap is not simply that it sunset. It is that Kong once looked like one of the more compelling DeFi projects on ICP. It publicly promoted 2.5-second average swaps, 99.9% success rate, zero gas, and a bridgeless multichain vision on its homepage. In its own comparison article, Kong also highlighted metrics such as 8-second average swaps, roughly $6.07M TVL, roughly $488.7K in 24-hour volume, around 7,800 holders, and about $2M raised via SNS. In other words, Kong was not a project that never worked. It was a project that looked, for a time, as if it might work — and still did not make it to durable success.

That is exactly why it is worth studying.

In March 2026, Kong announced in its sunset post that it would fully sunset on April 6. The official explanation was that product-market fit was not yet strong enough. Users were told to remove LP positions, withdraw tokens, and disconnect Internet Identity before the cutoff date. After that point, the platform would no longer be accessible, and Kong said it could not guarantee that assets would still be recoverable.

That made the event much more than a normal product shutdown. It became a real case study in product design, governance, security, exit planning, and community trust.

What KongSwap got right

If we describe Kong only as a failed project, we would be missing the point. Kong got several important things right.

First, it chose a strong ICP-native narrative: speed, on-chain execution, multichain reach, and low-friction UX. Kong did not present itself as just another DEX. It tried to frame itself as a faster and more advanced on-chain trading experience. That positioning worked because it aligned with what ICP can do differently from many other environments.

Second, Kong tried to build more than a swap interface. Public materials show that the project extended beyond swapping into pools, staking, governance, APIs, and ecosystem tools such as Kong Locker. That broader ecosystem thinking matters. Kong’s problem was not a lack of ideas. If anything, it had too many strong ideas at once.

Third, Kong did build real product momentum for a period of time. Its own public materials emphasized “doing more with less,” and third-party sites such as DefiLlama still reflect that the protocol once had meaningful traction. That matters, because it means Kong’s story is not about a project that never found product interest. It is about a project that generated interest, showed real promise, and still failed to convert that momentum into long-term institutional trust.

Why Kong looked close to success

Many projects fail because they never achieve traction at all. Kong was different.

At one stage, it had nearly everything that makes a DeFi project look promising:

  • a sharp technical narrative,
  • a strong speed story,
  • ICP-native differentiation,
  • ecosystem extensions,
  • and enough public data to support the story.

Its own whitepaper described a single-backend-canister architecture, using stable memory to manage pools, trades, user accounts, staking, and claims. It also described a workflow involving pre-swap checks, post-swap validation, rollback, and claims handling.

This is important.

Kong’s speed advantage did not appear to come from an internal unified ledger in the way SSS is designing one. It appears to have come from a different philosophy:

  • concentrate core state,
  • shorten the processing path,
  • reduce cross-module coordination,
  • optimize for perceived speed,
  • and use rollback or claims handling to absorb exceptions.

That approach can absolutely produce a fast product experience. And Kong proved that.

It also creates a different kind of fragility: when core state and value movement are highly concentrated in a central backend canister, any flaw in permissions, state transitions, or exception handling can have system-wide consequences.

Where Kong really lost

How Kong moved from momentum to fracture

It is not enough to say that Kong failed because PMF was weak. That was the official reason, but it does not explain the scale of the community reaction.

In the sunset announcement, Kong said the decision was based on product-market fit and emphasized that the team would not withdraw project treasury funds. That is a legitimate product-side explanation.

But the community quickly focused on a different set of questions:

  • If this was an SNS / DAO-governed project, who actually decided to shut it down?
  • What happens to the treasury?
  • Why was there no clear proposal path?
  • Why did the repository disappear?
  • Why did a project described as decentralized appear, at its most critical moment, to still depend on a narrow control structure?

That was the first rupture: the gap between governance narrative and governance reality.

The second rupture came through the public bounty disclosure. Evan McFarland stated that on March 9 he disclosed a critical, permissionless, full-drain vulnerability affecting Kong’s backend canister, with roughly $1.5M at risk in ICP and ckUSDT. He said he helped fix the issue without exploiting it and later requested a $30,000 bounty, after which the situation escalated into a broader public dispute involving treasury access, governance, and responsibility.

Regardless of how one judges the bounty amount, the larger lesson is clear: when a serious security issue hits a project that is already operationally fragile, security becomes inseparable from trust, governance, and legitimacy.

In Kong’s case, the failure chain seems to have looked something like this:

  • On the official side: PMF was not strong enough, and the will to continue weakened.
  • On the governance side: there was no sufficiently trusted process for shutdown, treasury handling, or transition.
  • On the security side: the system was publicly associated with a full-drain dispute and an immature bounty response.
  • On the user side: a shutdown notice is not the same thing as a durable, well-designed exit path.
  • On the trust side: parts of the community came away feeling that the DAO framework had not produced real accountability.

That is why Kong’s story matters. This was not a simple product shutdown. It was a stress test of whether a DeFi system could remain trustworthy when conditions turned bad.

What this means for SNS / DAO design

The biggest takeaway from Kong is not that “DAOs do not work.” It is that a DAO is not an answer by itself.

The official promise of SNS is straightforward: the dapp should be governed by the community through on-chain proposals, covering things like upgrades, treasury flows, and governance rules. In theory, that is powerful.

In practice, however, governance quality depends on things that many projects underdesign:

  • who actually controls emergency actions,
  • whether user exit rights are independent from political disputes,
  • whether treasury access can be exercised responsibly and visibly,
  • whether the codebase and documentation remain usable after the founding team steps back,
  • whether security response paths exist before a crisis happens,
  • and whether governance remains meaningfully decentralized under real token concentration conditions.

This is not only an ICP issue. Wider research on DAO governance has repeatedly shown that token ownership and voting participation are often far more concentrated than the rhetoric suggests.

So the lesson is not “do not build a DAO.”
The lesson is: if shutdown authority, emergency response, treasury policy, code continuity, and user exit are not designed in advance, a DAO structure can amplify trust failure instead of preventing it.

A note on Kong Locker and responsibility boundaries

It is important to be precise here.

Kong Locker should not be described as an official KongSwap core product. Based on public materials, it appears to have been developed by Evan as part of the broader Alexandria ecosystem. Its documentation explicitly labels it “An Alexandria Project.”

That distinction matters. At the same time, Kong Locker was deeply coupled to Kong’s ecosystem and value flows. It enabled permanent LP locking using blackholed canisters, with governance-related implications through DAOPad and identity relationships across KongLocker, lbry.app, LBRY.app, and related services.

This creates an important product lesson:

A project may not officially “own” every extension built around it. But if an extension is tightly bound to the platform’s assets, liquidity, or governance assumptions, then a shutdown can still create real user harm even when formal responsibility boundaries are ambiguous.

That is not simply a legal question. It is a product and trust question.

What SSS takes from this

This is also why SSS is not rushing to launch a token.

That is not because we do not value community governance. It is because we do.

For a trading system, we believe the foundation must come first:

  • product reliability,
  • asset safety,
  • exit paths,
  • operational transparency,
  • failure handling,
  • and system-level trust.

Only after those layers are stronger should tokenization and DAO governance move to the center of the narrative.

This is one of the most important lessons from Kong and from many SNS projects more broadly: governance should not outrun the product’s ability to behave responsibly under stress.

Architecturally, SSS is also taking a different route.

Kong’s model appears closer to centralized backend state plus rollback / claims handling.
SSS is building toward a more unified internal accounting model, auditable receipts, reconciliation paths, and clearer control of liabilities and withdrawals.

That does not make SSS automatically safer. It means only that SSS is choosing a different tradeoff:

not merely “fast,” but credibly fast.

From the current system and code direction, SSS is already trying to put several anti-failure ideas into the base layer:

  • pause and degradation paths,
  • withdraw-oriented survival modes,
  • audit and reconciliation logic,
  • idempotency thinking,
  • clearer state tracking for user assets,
  • and a stronger emphasis on recoverability and observability.

That does not mean the work is finished. It means the product foundation is being built with failure in mind, not only growth.

And that matters.

Because if SSS eventually introduces a DAO, we do not want to simply reuse a governance template and call it decentralization. We want to study the lessons of existing SNS projects and design a more advanced SNS DAO model:

  • more decentralized,
  • safer in emergencies,
  • more operationally effective,
  • and clearer about responsibility boundaries.

That is a harder path. But in our view, it is the only path worth taking.

What product managers should really learn from Kong

From a product perspective, the most important lessons are not dramatic. They are practical.

A good product is not the same thing as a good institution.

A fast user experience is not the same thing as a trustworthy system.

A DAO narrative cannot run ahead of governance reality.

Irreversible mechanisms must be designed with worst-case scenarios in mind, not only best-case intent.

And the projects that earn long-term trust are not the ones that look most impressive in their peak moments. They are the ones that still behave responsibly in their worst moments.

That is why Kong is worth studying.

Not because it failed, but because it got enough right to make the later failure deeply instructive.

SSS Response Framework

The value and vision of SSS

SSS is not trying to build just another trading page. It aims to build a trading system that deserves long-term trust.

That vision is built on three core principles:

Safe. Simple. Swift.

And among them, Safe comes first.

Because in a financial system, safety is not one feature among many. It is the condition that makes every other feature meaningful. Without safety, speed does not matter. Without safety, growth will not last.

At the same time, SSS believes just as strongly in user experience.

We want to build a trading system with CEX-level usability, while preserving the trust, verifiability, and controllability of an on-chain system.

Users should not have to choose between “easy to use” and “worthy of trust.”
A truly strong on-chain trading system should deliver both:

  • smooth interaction,
  • fast response,
  • clear state,
  • and confidence that even in the worst case, users know where their assets are, how records are tracked, and what their exit path is.

That is also why we hope to earn more attention, more discussion, and more support over time.

Not because every problem is already solved, but because we are willing to face these problems directly — with a more professional mindset, a more honest attitude toward difficult questions, and more concrete system design to address them.

Key sources

Kong / KongSwap

Kong forum threads

SNS / DAO references

SSS

— SSS DeFi Product Manager

Disclaimer:

This post is for informational purposes only and does not constitute investment, legal, or tax advice. Nothing herein is an offer, solicitation, or recommendation. Please do your own research.

CEX Experience · DEX Trust
Feel it today
Swap Now