当grant花光之后，以太坊开发者工具怎么办？

null

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 决定生死」。