Kernel funds the functions Filecoin depends on to keep producing blocks, proving storage, and staying observable. It is treated as a near-fixed cost rather than a growth bet: the goal is not more features, it is that nothing essential quietly stops being maintained.
| Tier | Functions | Coverage · 90d | Funding posture |
|---|---|---|---|
| Only provider. Network halts without it. No substitute exists. | 5 | 100.0% | Must fund — non-negotiable |
| Network-critical, but alternatives exist. We need at least one. | 24 | 99.7% | Fund for redundancy — 2+ implementations |
| Load-bearing. Multiple dependents. Silent failure cascades. | 2 | 100.0% | Fund maintenance, not features |
Most of what Filecoin runs on is maintained by small teams, and much of it has no second implementation. When one of those goes unfunded, nothing breaks on the day it happens — the repo just goes quiet, the maintainer moves on, and the network carries a dependency nobody is watching. Kernel exists to make that failure mode visible and to pay for it not to happen.
The program starts from a map, not a wishlist. Every capability the network needs is written down as a function, independent of which repo currently provides it. Each function is placed in a tier according to how replaceable it is, and each tier carries a different funding posture — some are non-negotiable, some are funded for redundancy, some are funded only for maintenance.
Funding follows an annual term with audits rather than milestones, because keeping something working is a continuous obligation and not a deliverable. Teams are assessed against agreed metrics for resilience and operational continuity: is the function still healthy, still maintained, still measurable.
Every commitment on this page names a threshold, a reading cadence and a public endpoint anyone can call — so the audit is a lookup, not a conversation.
Kernel grants run on an annual term. Audits fall mid-term and at close, and each one checks the agreed resilience metrics rather than a feature list.
Next round opening
Applications close in November, awards are published in December, and the new term begins in January. Existing grantees re-apply on the same cycle.
FY26 term begins (complete)
Mid-term audit cleared (complete)
Health reporting live (in progress)
Close-out audit · FY27 intake opens (upcoming)
Applications close (upcoming)
Awards published (upcoming)
FY27 term begins (upcoming)
A function's tier is decided by substitutability, not by how much anyone likes it. That single judgement then drives how much scrutiny it gets, whether redundancy is required, and how negotiable the budget is.
5 functions
Only provider. Network halts without it. No substitute exists.
Ledger, resource, and programmability — what the blockchain and the physical-storage-backed ledger need in order to keep running at all.
24 functions
Network-critical, but alternatives exist. We need at least one.
Core offerings — disk space from miners, storage primitives in smart contracts — that let participants engage with the irreplaceable components.
2 functions
Load-bearing. Multiple dependents. Silent failure cascades.
Supports and improves access to the critical components, and speeds up development of revenue-generating work.
The same commitments, read two ways. By project asks what each funded team is on the hook for; by function asks what the network needs and whether anyone is watching it. The percentage is reading coverage — the share of the periods a metric's own cadence expects that carry a value, counted from the day unattended collection started rather than from 90 days ago, with days lost to an outage of our own platform excluded outright. Open any row for the metrics behind it — what is collected, when, and every reading taken.
SLA thresholds are still being negotiated. This page reports what is being measured, not whether a target was met. Monitoring follows the signed agreements: a function is measured once an agreement names a metric for it.
Aggregate health matters less than coverage. A function with no maintainer and no metric is invisible to this page, which is exactly what makes it dangerous.
Every reading on this page is derived from the commitments in the Kernel registry.
Metrics for individual projects and repos live in the explorerKernel uses a few words in a specific way. Getting them straight is most of understanding the program.
