首頁

快訊深度數據 Skill&API

當grant花盡之後，以太坊開發者工具該怎麼辦？

閱讀本文需 19 分鐘

過去的問題是「誰應該被資助」；現在的問題開始變成「已經被證明重要的團隊，如何不被下一筆 grant 決定生死」。

原文標題：《當 grant 花光之後，以太坊開發者工具怎麼辦？》
原文來源：ETHPanda

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、某个项目获得资助。在这里，公共产品更像是生态系统资金流动。

Project Odin 提供的是第三个入口：公共产品团队的长期经营。

对中文社群来说，这个角度更贴近开发者和协议方。如果一个协议长期依赖于某个开源库、风险数据平台、编译器、验证工具或安全基础设施，就不能只在资金短缺时求助。更合理的做法是将这些依赖项纳入其生态预算中：哪些工具对我们是关键依赖？是否应提供长期支持？是否需要购买支持合同？是否应参与依赖项资助？是否应在治理预算中保留公共产品支出？

将其视为慈善问题并不准确，这更接近供应链问题。公共产品之所以重要并不是因为「值得捐赠」，而是因为许多团队在日常开发、安全、数据和治理决策中都依赖它。既然这种依赖是真实存在的，支持它就不仅仅是一种善意表达，也是一种生态系统风险管理。

如果一个协议愿意为流动性挖矿、激励措施、增长和品牌推广投入资金，却不愿为其依赖的基础工具付费，那么它省下的不是成本，而是将成本转嫁给了维护者和整个生态系统。Project Odin 值得关注的原因正是因为它将这个问题从「谁愿意赞助」向前推进了一步：究竟是谁真正依赖这些团队，谁应该更早地参与它们的可持续性设计。

Project Odin 无法解决所有公共产品融资问题。目前，它只针对少数战略性受资助团队提供结构化支持计划。但它明确了一个长期以来被搁置的问题：公共产品项目不能仅在申请资助时证明自己具有价值，还必须在日常运营中找到真正依赖自己的人、愿意持续支持自己的人，以及怎样的收入不会损害其公共属性。

这也许是以太坊公共产品讨论进入下一阶段的一个信号。过去的问题是「谁应该获得资助」；而现在的问题开始转向「那些已被证明重要的团队，如何不受下一笔资助决策的影响」。