什么样的项目适合申请dao? What kind of projects are suitable for DAO?

中文
1

(for english translation please click the :globe_with_meridians:translation icon at the bottom)

看到最近一些dao的讨论想到这个问题，我觉得值得探讨一下。

首先最重要的，应该是能够直接带来生态发展，吸引人加入生态的东西。其次是能展现ckb独特性或者价值的东西，因为也有机会吸引人带来发展。这个东西是应用还是基建，我觉得不是重点，重点是能带来生态的扩大。

然后一个很重要的是结果可积累。一种可积累，是项目自身很有机会做到可以自我维持，能自我维持就能一直做下去积累用户。另一种可积累，是项目不会一直维持，但是能留下开源代码之类的东西，虽然一个阶段后项目就不在了但是知识和工具能留下来，后面的项目会越来越方便。持续积累也是一种发展。

再就是我觉得申请人最好是在提申请之前就在社区有一些参与感，活跃度。如果没有，那大概率只是为了拿钱，运气好的话也能拿钱办事，运气不好拿钱不办事。但总的来说申请人其实是游离在ckb社区之外的，这样的人很难做到上面所说的两点，展现ckb价值或是持续积累。当然不光是申请之前，申请之后也应该有比一般人更高的活跃度。支持这样的人，社区会积累真正的人才，也是一种发展。

不知道想的对不对，抛砖引玉。

10 Likes
4

我就是随便聊聊，也不一定有多严谨的逻辑，算是陪你把这个话题往前走一下。最近社区里关于 DAO 项目申请的讨论比较多（包括 Rosen Bridge 以及 DAO 1.1），也让我反过来思考了一些类似的问题。

1）关于顶层设计和认知差异
我个人的理解是，顶层设计在白皮书里其实已经写得比较清楚了，只是我们现在更多只能从各自的视角去猜整体框架，所以难免存在认知差异，每个人也都会觉得自己是站在“更合理”的一侧。
这让我想起 20 多年前刚参加工作的时候，我自己什么框架、系统都不太懂，只知道缺人就拼命干，身上背的系统也越来越多。后来领导画了一张整体架构图，把各个系统之间的关系、上下层位置都讲清楚了，我才第一次真正理解：原来每个系统在整体里都是有明确位置的。
所以我想说的是，类似 CKB 这样的系统，顶层设计很可能早就已经完成了，什么样的项目适合放在什么位置，架构层面大概是有判断的。后续更多是“往架构里添肉”的问题，讨论的重点也就变成了项目本身是否可行、是否合适。

当然我的认知问题也会出现误判，例如对DAO1.1的态度，我一开始觉得”没项目申请为什么要建一个新系统去管理？”，后面变成了“这个系统应该是在顶层设计架构里面的一个未来基础设施，应该建，但是为什么现在建？”，再往后变成了“现在建也可以，能不能压缩一部分预算？”，最后变成了同意。我想每个人都是有自己认识的缺失的，例如我现在对区块链技术还是个半吊子，所以我在技术标准的发言中，都非常审慎。

2）关于时机与通用架构
站在 adoption 的角度看，我个人会更倾向于认为，未来真正重要的，可能还是那些有机会在 Web2 场景获客的项目，吸引Web2优秀开发者，而不是仅仅面向吸引 Web3 内部的炒币用户。比如基于 Fiber SDK 的应用，如果未来能承载更大规模的真实使用，那意义会更大。
但这类项目往往依赖通用基础设施的成熟，所以时机点也很关键。就像城市招商一样，先把水、电、路打通，后面的事情才好展开。

3）关于项目评估和试错方式
之前在 DAO 2.0 的讨论里我也提过，传统项目里通常会有前期评估（能不能做、谁来做、做成的概率如何），以及事后评估（结果和预期差距多大，经验是否能沉淀下来）。当然 DAO 场景和传统体系不完全一样，这些方法不一定完全适用。
但从风险控制的角度，我个人还是更偏向于小步试错：先用相对小的资金验证方向，跑通之后再追加资源，这样损失更可控。相比之下，一次性把预算全部打出去，风险会更集中一些。感觉社区太害怕失去项目申请者了，我不太认可这个概念。

4）关于预算和审核的一点个人感受
这个更多是个人感受。之前在实际工作中做过几年项目审核，每年也看过不少项目，预算被压缩、被调整其实是常态。但在 DAO 场景里，有时会感觉预算压降的空间比较有限，而社区资金承担的风险又相对集中。社区资金的风险远大于项目申请者损失，利益不对等。究其原因还是感觉社区太害怕失去项目申请者。
当然，如果项目本身足够有吸引力，大家自然会更愿意支持。只是从机制上看，我个人会觉得：如果能有更清晰的阶段目标和调整空间，可能会让整体试错成本更低一些。

以上都是一些随手写下来的想法，可能也有不少认知偏差，主要是陪你把讨论接下去，供参考，也欢迎指正。

5 Likes
5

我最近也有这种感受，原来在券商也会申请一些项目和激励，这些项目更多是为了拿到激励而去做，不用承担市场的后果和责任。如果是正常的项目，市场获得的回报会远远大于资金支持本身，不会特别用力和费劲的去支持这点补贴。我感觉spark这种形式就很好，资金不多，但是能看到很多有意思的应用，这些应用如果团队是靠谱的，基金会或者社区给与一定的辅导，甚至商业上的资源支持，效果远远大于大家都在造轮子，做锤子，找钉子。

5 Likes
6

我个人的一个看法是，这类问题之所以反复出现，可能和 Community Fund DAO 当前所面对的真实参与结构有关。

现阶段更多还是内部流量，以及一部分以 Community Fund DAO 激励为主要目标的参与者，而真正来自外部、面向真实用户和真实需求的流量还比较有限。在这样的阶段，项目天然更容易围绕激励机制来设计，而不是围绕市场反馈来生长。

也正因为如此，我自己在看 Community Fund DAO 的资金申请时，会下意识地偏向一种 Guard Dog 的心态：优先关注风险边界、资金使用的可控性，以及是否有相对清晰的验证路径。

另一方面，我也越来越觉得，Community Fund DAO 本身就是一个非常复杂的治理课题。它不仅需要有足够多、足够有活力、是真正想做事的开发者来持续申请项目；同时也需要有足够多具备独立判断能力的审核者长期关注、参与讨论和审核，二者共同作用，才能形成正向反馈。

有时候我也会想，Community Fund DAO 的“前台入口”是否有机会进一步向开发者日常活动的场景延伸，比如更多地结合 GitHub 等开发平台，让项目的技术推进、讨论和验证更自然地暴露在社区视野中。也许这样，能在一定程度上缓解你提到的那种“围绕激励而非围绕问题”的情况。

我个人更期待的是，当 CKB 被更广泛地认知之后，会有更多年轻、有激情、是“因为想做事而来”的开发者加入。那时 Community Fund DAO 才更容易推向正循环，真正回到“资助真实开发者、解决真实问题”的初衷。

回到我上面的发言，对应的就是第二点：“时机”问题。

2 Likes
7

需要个大前提，被广泛认知，怎么被广泛认知 这个方法是啥，坐等开发者上门 肯定行不通

1 Like
8

I would say to follow the Nervos Community Catalyst and the developer onboarding program there. I think these kind of efforts are the way to reach developers, rather than mass marketing (which is good for “name brand” awareness though)

https://x.com/NervosCatalyst

6 Likes