2 月 27 日,Ethereum Foundation 资金协调团队成员 Raul Romanutti 发表了一篇文章,标题是《一切安好,直到 grant 烧完》(This Is Fine (Until the Grant Runs Out))。文章介绍了 Project Odin —— 一个面向少数、战略性、曾获得 EF 大额资助的团队的结构化可持续性支持计划。
只看信息点,Odin 容易被归入「EF 又推出了一个公共品资助计划」。但它和常见 grant 不太一样:项目方拿到的不是一笔新的启动资金,也不是一次公开申请机会,而是一套面向存量被资助团队的长期陪跑机制。EF Blog 将目标放在两年时间框架:帮助这些团队建立可信的可持续路径,降低对单一资金来源的长期依赖;其中驻场战略顾问的陪跑与执行周期约为 12 个月。
Odin 关心的是 grant 之后的那段路。
0xRahul 推文里提到的重点也在这里。他没有把问题讲成「EF 还要不要资助公共品」,而是把焦点放在开发者工具团队的可持续性上:大型、复杂、重度使用的开源工具,不能长期靠热情或短期 grant 维持。
过去中文社区讨论公共品,更多围绕 Gitcoin 捐赠、RetroPGF 发放、EF 资助名单,或者某个项目是否适合被捐。Project Odin 指向的阶段更靠后:一个公共品项目已经证明自己重要之后,如何不被下一笔 grant 牵着走?
grant 仍然重要,但问题开始变了
先把一个误读排除掉:Project Odin 不是 EF 停止资助公共品的信号。
从近年的公开信息看,EF 仍在持续资助协议研究、客户端、密码学、ZK、开发者工具、教育和公共品实验。EF Ecosystem Support Program 在 2026 年 Q1 Allocation Update 中列出的项目,仍覆盖 EthereumJS maintenance、BuidlGuidl、WalletConnect clear signing library、L2BEAT 2026、DISC-NG Geth、Lighthouse、Vero、formal verification 等多个基础设施和工具方向。类似的季度资助清单,过去几年一直在出现。
grant 没有消失,只是它本身解决不了所有问题。
对于早期项目,grant 可以降低启动成本;对于研究型工作,grant 可以覆盖不容易商业化的探索;对于社区教育和公共基础设施,grant 仍然是重要资金来源。但如果一个已经被大量项目依赖的工具团队,长期只有一个主要资金来源,风险就会变得集中。
EF Blog 中提到,很多团队并不缺技术能力,短板出现在筹款、对外沟通、组织设计、法律结构等非技术能力上。团队会写编译器、会做研究、会维护网络栈,但未必有精力去回答这些问题:谁最依赖我们?哪些用户愿意签长期支持合约?哪些工作可以被企业采购?哪些收入不会影响项目中立性?
Odin 试图补上的,就是这部分能力。
开发者工具为什么最容易卡在这里
0xRahul 在长推中列了四种传统开发者工具模式:大公司开源、绑定更大的产品、商业 SaaS、无偿维护。
这四种模式放到 Ethereum 里,都有明显限制。
大公司开源的工具往往很强,但长期取决于公司战略。公司愿意投入时,生态受益;公司方向变化时,维护优先级也会跟着变化。对 Ethereum 这类强调可信中立的生态来说,把关键工具寄托在单一公司的长期兴趣上,并不稳。
绑定大产品的工具也类似。它可以服务好某个产品线或平台用户,但很难保持完全开放。Ethereum 的开发者工具需要跨钱包、跨客户端、跨 L2、跨协议使用,封闭花园会削弱它的公共属性。
商业 SaaS 可以解决一部分问题,但不是所有问题。很多 crypto 团队本身还在早期,研发预算有限。更重要的是,编译器、语言、基础库、网络栈、透明度平台这类工具,价值往往体现在整个生态的安全和效率上,很难直接按单个用户收费。
最后是无偿维护。小型库或个人工具可以短期靠兴趣推进,但大型基础设施不行。编译器需要长期测试和安全响应,语言需要路线图和社区治理,P2P 网络栈需要跨项目协调,风险监控平台需要持续数据维护。这些都不是一次性工作。
开发者工具经常落在一个尴尬位置:它们太底层,没人愿意失去;又太公共,很难自然产生收入。
Project Odin 做的不是「加速器」
EF Blog 把 Odin 描述为结构化支持计划,但它和创业加速器不是一回事。
加速器通常服务于增长型公司,目标是产品、市场、融资和规模化。Odin 不要求公共品团队讲出一个 venture scale 的故事,它关心的是这些团队能否在多轮资金周期中持续交付,逐渐成为更稳定的机构。
Odin 的基本机制是,每个团队都会有一位驻场战略顾问。这个顾问不是来做一次培训,而是长期参与团队的可持续性规划和执行。整个过程大致包括三个阶段:
- 第一阶段是梳理现实选项。团队目前靠什么活着?过去尝试过哪些融资方式?生态里谁从它受益?有哪些资金渠道可用?每种渠道的代价是什么?
- 第二阶段是验证路径。比如和潜在资助方、合作伙伴、企业用户、DAO delegate 或协议团队展开对话,判断哪些方向不是纸面方案。
- 第三阶段是执行。包括准备筹款或合作材料,搭建合作管线,必要时设计支持合约、服务协议或其他可重复的收入形式。
这套流程听起来不如「公共品」叙事动人,但它解决的是项目最现实的一段:团队不能每次都在 runway 快结束时才开始找下一笔钱。
Vyper 是为什么被选中的
Vyper 是 Project Odin 的首个试点参与者。
这个选择并不意外。Vyper 是面向 EVM 的 Pythonic 智能合约语言,强调安全、简洁和可读性。EF Blog 中提到,Vyper 历史峰值时保护过超过 270 亿美元链上价值。即使今天,它仍然支撑着数千个合约和数十亿美元 TVL。
语言和编译器是典型的公共基础设施。它们一旦出问题,影响不是单个应用,而是所有依赖它们的协议和开发者。但从商业模式看,这类项目并不好处理:核心语言应该保持开放,安全和形式化验证能力又需要持续投入,单靠社区捐赠很难支撑长期团队。
Vyper 团队新建立的 Foundation for Verified Software,正好把这个问题摆到台面上。FVS 官网显示,该机构关注形式化验证研究、开放工具和生态支持,当前项目包括 Vyper、Vyper-HOL、Verifereum、HOL4。EF Blog 也将 Vyper / FVS 放在 Odin 首个试点参与者的位置讨论。
这还不是已经跑通的商业化样板。更准确地说,它是一种正在实验的组织形态:基金会承接长期研究和开源工具,团队再围绕形式化验证、审计、培训、支持合约或企业 POC,探索能否形成稳定收入。
放在中文社区语境下,Vyper 不只是「一个语言项目拿到 EF 支持」。随着 DeFi、L2 和机构资金对合约安全要求越来越高,形式化验证这类能力也可能从研究议题,逐渐变成可被采购的专业服务。
libp2p 和 L2BEAT:两个对照案例
EF Blog 开头提到了 libp2p。它是很多 Web3 系统使用的 P2P 网络栈,也被 Ethereum clients 用于节点发现、消息传播、区块和验证者投票传播。EF Blog 将它作为近期资金压力案例之一,用来说明被广泛依赖的开源基础设施,也可能在资源不足时进入求助状态。
这个案例说明了底层依赖的资金困境:越底层,使用者越多,直接付费关系反而越不清楚。每个项目都希望 libp2p 稳定,但很难说哪一个项目应该承担主要维护成本。
L2BEAT 则提供了另一个角度。
L2BEAT 是中文社区非常熟悉的透明度工具,长期追踪 L2、桥、DA、ZK 等风险与数据。它不是 Odin 的试点,但它公开披露资金来源,适合作为资金组合案例来看。
根据 L2BEAT 的捐赠页面,它的资金来源包括 Partnership Fund、Ethereum Foundation grants、Optimism RPGF、Gitcoin、参与 L2 governance frameworks 的奖励与补偿、专项 grant、会议赞助、报告和 dashboard 探索、直接社区捐赠等。
这个列表很有意思。它说明公共品团队未必只有两条路:要么完全靠 grant,要么变成 SaaS。一个长期提供中立数据和专业判断的团队,可以从多个生态角色那里获得支持。但前提是,它需要把资金来源说清楚,让外界能够持续审视它的激励结构。
把资金机制组合起来,而不是只押一个答案
近两年,中文社区已经比较熟悉 Gitcoin、Optimism Retro Funding、Protocol Guild、Drips 这些公共品资助机制。它们经常被放在「资金来源多元化」和「可持续收入流」的语境下讨论。
但这些机制解决的问题并不相同:Gitcoin Grants 更适合汇聚社区信号,也能帮助早期公共品获得曝光和启动资金;Optimism Retro Funding 奖励已经产生影响的工作,适合补偿过去贡献;Protocol Guild 针对 Ethereum L1 core R&D 贡献者,建立了更长期的链上资助机制;Drips 关注 dependency funding,希望资金能沿依赖关系流向上游开源项目。
对大型开发者工具团队来说,关键不是在这些机制里选出唯一答案,而是理解每种资金的适用边界。QF 需要项目反复拉票,Retro Funding 的结果存在不确定性,DAO grants 受治理周期和 token 波动影响,直接捐赠通常难以覆盖稳定团队成本。
Project Odin 的重点也不在于发明一个新资金机制,而是帮团队把已有机制和潜在收入组合起来:grant 可以支持研究,retro funding 可以奖励影响,DAO 或协议可以提供专项支持,企业用户可以购买服务或支持合约,合作伙伴可以共同开发 POC。
这些听起来都是普通经营问题,但对不少公共品团队来说,普通经营能力本身就是短板。Odin 真正补上的,正是把「项目有价值」翻译成「谁依赖它、谁愿意持续支持它、什么收入不会损害它的公共属性」的能力。
换句话说,grant 之外不是一句口号,而是一套更具体的资金组合、合作关系和组织能力。
中文社区可以怎么理解
中文社区过去看公共品,常常有两个入口。
一个入口是捐赠。比如 Gitcoin 每一轮开始时,会有项目推荐、捐赠教程、交互指南。公共品在这里更像社区参与行为。
另一个入口是新闻。比如 EF 公布季度资助清单、Optimism 开启 Retro Funding、某个项目获得 grant。公共品在这里更像生态资金流向。
Project Odin 提供的是第三个入口:公共品团队的长期经营。
对中文社区来说,这个角度更贴近开发者和协议方。一个协议如果长期依赖某个开源库、风险数据平台、编译器、验证工具或安全基础设施,就不能只在它缺钱时转发求助。更合理的做法,是把这些依赖列进自己的生态预算里:哪些工具对我们是关键依赖?是否应该提供长期支持?是否需要购买支持合约?是否应该参与 dependency funding?是否应该在治理预算里保留公共品支出?
把它说成慈善问题并不准确,它更接近供应链问题。公共品不是因为「值得被捐」才重要,而是因为很多团队已经在日常开发、安全、数据和治理判断中依赖它。既然这种依赖是真实存在的,支持它就不只是善意表达,也是一种生态风险管理。
如果一个协议愿意为做市、激励、增长和品牌花钱,却不愿意为自己依赖的基础工具付费,它省下来的并不是成本,而是把成本转移给了维护者和整个生态。Project Odin 之所以值得关注,也正是因为它把这个问题从「谁愿意资助」往前推了一步:谁真正依赖这些团队,谁就应该更早参与它们的可持续性设计。
Project Odin 不会解决所有公共品融资问题。它目前也只是面向少数战略性被资助团队的结构化支持计划。但它把一个长期被推迟的问题讲清楚了:公共品项目不能只在申请 grant 时证明自己有价值,也要在日常运营中找到谁真正依赖自己、谁愿意持续支持自己,以及什么样的收入不会损害自己的公共属性。
这或许是以太坊公共品讨论进入下一阶段的一个信号。过去的问题是「谁应该被资助」;现在的问题开始变成「已经被证明重要的团队,如何不被下一笔 grant 决定生死」。
