复盘 KongSwap，我们从中学到了什么
从产品经理视角，系统复盘 KongSwap 的发展、创新、速度优势、治理争议与 sunset 过程，并结合 SSS 当前的产品底座与未来治理设计方向，讨论链上交易系统如何真正赢得长期信任。
- KongSwap 不是一个天然失败的项目；它曾经展示过真实的产品势能、速度优势和 ICP 原生叙事。
- 它更深层的失败不只是 PMF 不足，而是治理叙事、责任边界、安全响应和退出机制之间的错位。
- 对 SSS 来说，长期信任必须建立在安全、可观测性、可退出路径和成熟治理设计之上，而不是 token 优先的叙事。
复盘 KongSwap，我们从中学到了什么
作者：SSS DeFi 产品经理
在加密行业，失败并不稀缺；真正稀缺的，是对失败进行认真、克制、系统复盘的能力。之所以写 KongSwap，不是因为它“关停了”，而是因为它曾经一度很有代表性：它主打过 2.5 秒平均 swap、99.9% 成功率、zero gas、bridgeless multichain；在它自己的公开对比文章里，Kong 还给出过 8 秒平均 swap、约 607 万美元 TVL、约 48.9 万美元 24 小时成交额、约 7800 持币地址、约 200 万美元 SNS 融资 的成绩单。换句话说，Kong 不是一个“从未成功过”的项目，而是一个一度看起来接近成功、却没能走到长期成功的项目。
也正因为如此，它的复盘才有价值。官方在 2026 年 3 月宣布：KongSwap 将于 4 月 6 日完全 sunset，原因是 product-market fit 还不够成熟；用户需要在截止日前撤出 LP、提走余额，之后平台将不再可访问，且不能保证资产仍可恢复。这已经不是普通的产品迭代，而是一次关于产品、治理、安全、退出机制与社区信任的综合考题。参考原帖：Sunsetting KongSwap — Please Remove Your Liquidity by April 6th
一、KongSwap 做对了什么
如果只是把 KongSwap 写成“失败案例”，那是对事实的不尊重。它至少做对了三件重要的事。
第一，它抓住了 ICP 上最容易形成差异化的叙事：快、全链上、多链、低摩擦。Kong 官方长期强调的不是“我们也有一个 DEX”，而是“我们有 lightning fast 的全链上交易体验”。这类叙事之所以有效，是因为它正好对应了 ICP 最强的一面：不是简单复制 EVM 产品，而是利用 ICP 的执行模型做出不同的用户感知。参考：KongSwap 官网首页
第二，它不是只做一个交易页，而是尝试做一个更大的 DeFi 产品系统。公开资料显示，Kong 不止有 Swap 和 Pools，还围绕着 staking、governance、API、Kong Locker 等模块去扩展自己的产品边界。特别要说明的是，Kong Locker 更准确地说并不是 KongSwap 官方主产品，而是一个与 KongSwap 高度耦合的第三方生态扩展工具。从公开材料看，它属于 Alexandria 项目，并且和 lbry.app / LBRY.app / DAOPad.org 处在同一认证源生态中；同时，Kong 社区讨论中也曾明确把 locked liquidity 描述为 Kong 官方“不正式支持”的第三方服务。这一点很重要，因为它既体现了 Kong 周边生态的创造力，也暴露了“第三方扩展与平台责任边界”之间的张力。参考：Kong Locker 文档 ｜ Bounty Disclosure 讨论
第三，它一度确实做出了可观的产品势能。Kong 官方在 2025 年的文章中用“更少资源、更高效率”来概括自己的成长路径，而第三方数据平台也长期收录了 KongSwap。即便到今天，DefiLlama 仍能看到它的 TVL、Fees 与 DEX Volume 记录；但 CoinGecko 的交易所页面又显示它当前已经是 0 个 coin、0 个 pair、24h volume 为 0。这组对比特别说明问题：Kong 不是没有高光时刻，而是没能把高光时刻沉淀成长期制度能力。
二、它为什么一度“看起来很接近成功”
很多项目失败，是因为从一开始就没有 traction。Kong 不是。它真正值得研究的地方，是它曾经具备几乎所有“看起来会赢”的特征：速度亮眼、品牌鲜明、ICP 原生叙事正确、还有一定的数据支持。官方 KB 甚至把 Kong 和 ICPSwap、ICDex、Sonic 做了速度对比，并把自己定位成 ICP DEX 里“更高效率”的后来者。参考：Comparing ICP DEXes: KongSwap vs. ICPSwap vs. Sonic vs. ICDex
更重要的是，Kong 并不是单纯靠前端包装来制造“快”的幻觉。它公开的白皮书写得很清楚：Kong 依赖一个 single canister backend，用 stable memory 管理池子、交易、用户账户、staking、claims，并通过 pre-swap checks、post-swap validation、rollback 和 claims handling 来维持交易流程的完整性。换句话说，Kong 的速度优势，很大程度上来自于后端状态机的集中化，而不是内部统一账本。它更像是“把核心路径做短，把用户感知做强，再用 rollback / claim 机制来兜底异常”。参考：Kong Whitepaper / Documentation
这也是为什么 Kong 会给很多人留下“很快、很顺”的印象。它证明了一件事：在 ICP 上，即使不先做统一内部账本，也能通过集中状态机、缩短路径和减少外部依赖，把交易体验做得很快。 但它也同时埋下了另一层风险：一旦核心 backend canister 的权限、状态机或异常处理路径出现问题，风险会高度集中。
三、Kong 真正输在哪里
如果只用一句“PMF 不足”来解释 Kong 的结局，是不够的。PMF 不足是官方给出的直接原因，但它并不能解释为什么社区反应会这么剧烈。Kong 官方 sunset 帖说得很清楚：团队为社区一起走过的旅程感到自豪，但当下不是继续运营的合适时机，因此选择负责地 wind down。官方还强调，团队不会从 treasury 中提取资金。参考：Sunsetting KongSwap — Please Remove Your Liquidity by April 6th
但社区很快把问题指向了另一个层面：如果这是一个 SNS / DAO 项目，为什么关闭、repo、treasury、接管这些关键问题，看起来没有通过一个清晰的 DAO 流程处理？ 在 sunset 讨论中，社区明确追问 treasury 里仍有大量 ICP、为什么没有 proposal、为什么 repo 被拿下、为什么一个号称 DAO 化的项目在最关键的时刻看起来仍像由少数人拍板。参考：Sunsetting 讨论串
随后，bounty disclosure 又把这个问题进一步放大。Evan 公开称，自己在 3 月 9 日向 KongSwap 团队披露了一个 可无权限耗尽 backend canister 中 ICP 和 ckUSDT 的 critical full-drain 漏洞，潜在风险规模约 150 万美元；他协助紧急修复、未造成损失，之后提出 3 万美元赏金请求，但围绕 treasury、治理和 repo 又引发新的争议。无论外界如何评价赏金金额，至少有一点是确定的：一个核心后端级别的高危安全事件，和一个即将 sunset 的项目撞在一起，最终暴露出来的就不再只是技术问题，而是治理、责任和信任问题。 参考：The real reason for the KongSwap Sunset | Bounty Disclosure
换句话说，Kong 的失败不是一个原因，而是一条链条：
- 官方层面：PMF 不足，持续经营意愿下降。
- 社区层面：DAO 是否真实有效、treasury 如何处理、repo 是否可持续，缺乏足够制度化答案。
- 安全层面：核心后端暴露过 full-drain 级争议，且赏金与响应机制并不成熟。
- 用户层面：在 sunset 临近时，仍有人反馈资产显示异常、求助提现，说明“有公告”并不等于“退出路径已经制度化”。
- 信任层面：一些社区成员最终把它总结成“DAO 成了没人负责的工具”，这比项目本身的关停更伤生态。
四、这件事对社区和 SNS / DAO 管理的真正启发
Kong 事件最大的价值，不在于证明“DAO 不行”，而在于提醒大家：DAO 不是天然答案，它只是把控制权、责任与流程显性化的一种制度工具。 DFINITY 官方对 SNS 的定义 很明确：SNS 的目标是让 dapp 由社区控制，通过 proposals 来决定治理、升级乃至 treasury transfer。
问题在于，理想设计和现实治理之间，经常隔着很长一段距离。外部研究也早已指出，很多 DAO 的 token 持仓和实际投票权都并不真正分散，top holders 和 delegates 往往集中度很高，这使得“去中心化治理”在关键时刻可能表现出和传统中心化组织非常相似的脆弱性。参考：ECB Working Paper - Governance in DAOs
所以 Kong 给 SNS / DAO 的启发，不是“不要做 DAO”，而是至少要把四件事提前制度化：
- 谁在什么条件下有权暂停、退出、接管或重组项目
- 用户资产退出权是否独立于普通治理争议
- 安全事件如何快速响应、如何支付赏金、如何公开披露
- 即使团队退出，代码、接口、文档和只读状态是否仍可持续
这些问题不在顺风期看，会觉得抽象；但只要一到逆风期，它们就会立刻变成决定信任生死的核心问题。
五、这对 SSS 意味着什么
这也是为什么，SSS 当前并没有急于发币。作为 SSS DeFi 的产品经理，我更愿意把时间花在把底层能力做扎实，而不是过早把注意力引向 token 叙事。原因不是不重视社区治理，而恰恰相反：我们更重视治理，所以不希望在产品底座、资产安全、退出机制、数据透明与故障处理能力尚未成熟时，就先把 DAO 和 token 叙事推到前面。
从系统设计上看，SSS 的路线和 Kong 并不相同。Kong 更像“集中后端状态机 + rollback / claims 兜底”的快路径；而 SSS 正在走的是“统一内部记账 + 回执 / 对账 / 退出路径 + 资产控制”的可信路径。就当前系统建设方向而言，SSS 已经把一些关键的反失败能力放进了底层设计：例如暂停与降级能力、面向只提现方向的生存模式、审计与对账路径、幂等思路、资产状态记录与风险隔离意识。这些并不意味着问题已经解决，而是说明产品底座不是只围绕“成交”，而是同时围绕“最坏场景如何不出大事”在设计。
更重要的是，SSS 希望在研究现有多个 SNS 项目经验和教训后，再去设计一套更进阶的 SNS DAO：更去中心化，但也更安全、更高效、更有明确责任边界。 这意味着治理设计不能只是“把 token 发出去”，而必须把以下内容一起设计进去：
- 用户退出权的优先级
- 紧急安全响应权的边界
- treasury 的使用透明度
- 代码与文档的长期可接管性
- 安全披露与 bounty 机制
- 当团队不再主导时，系统是否仍然可读、可查、可退
如果没有这些，DAO 很容易只在宣传材料里成立，而在危机时刻失去意义。
六、复盘 Kong，真正想说明什么
站在产品经理的角度，Kong 的案例最值得记住的，不是“某个项目失败了”，而是：
好产品不等于好制度。
快体验不等于可信系统。
DAO 叙事不能超前于治理现实。
不可逆设计必须先想清楚最坏场景。
真正赢得长期信任的，不是高光时刻的速度，而是最坏时刻的行为。
Kong 之所以值得认真写，不是因为它“做错了”，而是因为它曾经做对了很多事，却依然没能穿越完整周期。这对整个 ICP 生态、对所有未来会走向 DAO 化的 DeFi 项目、也对 SSS 自己，都是非常有价值的一课。
七、SSS 的价值与愿景
SSS 想做的，从来不只是另一个交易页面，而是一套真正值得长期信任的链上交易系统。
这套系统会始终围绕三个核心原则展开：
Safe，Simple，Swift。
其中，Safe 永远放在第一位。
因为在资金系统里，安全不是一个功能，而是其他一切功能的前提。
没有安全，速度没有意义；没有安全，增长也不会长久。
与此同时，SSS 也始终坚持另一件事：
打造接近 CEX 体验的链上交易系统，把用户体验放在极高的位置。
用户不应该在“好用”和“可信”之间做二选一。
真正好的链上交易系统，应该既让人觉得顺滑、快速、清晰，也让人知道在最坏情况下，资产在哪里、记录在哪里、退出路径在哪里。
这也是我们希望持续赢得更多关注与支持的原因。
不是因为我们已经把所有问题都解决了，而是因为我们愿意用更专业的视角、直面问题的态度和更具体的制度建设，去一步步把这些问题真正解决。
关键来源（Key Sources）
Kong 相关
- KongSwap 官网首页
- Comparing ICP DEXes: KongSwap vs. ICPSwap vs. Sonic vs. ICDex
- KongSwap API Documentation and Candid Definitions
- KongSwap Terms of Service
- KongSwap Disclaimer
- Kong Whitepaper / Documentation（GitHub）
- Sunsetting KongSwap — Please Remove Your Liquidity by April 6th（DFINITY Forum）
- The real reason for the KongSwap Sunset | Bounty Disclosure（DFINITY Forum）
- DefiLlama - KongSwap
- CoinGecko - KongSwap Exchange