APP-K8BTJ7WE-SPWUZT — Filecoin Core Infrastructure & Integration Support

1.1 Project Name: Filecoin Core Infrastructure & Integration Support 1.2 Project Github: https://github.com/Zondax/fil-propgf3-infra 1.3 Project Website: https://github.com/Zondax/fil-propgf3-infra 1.4 Team Lead/Point of Contact: Juan Leni, CEO, (slack or telegram) 1.5 Category: Core Infrastructure Contributing to Core Infrastructure?: Zondax has built and run Filecoin integration infrastructure since 2019 some of the oldest continuously-operated tooling in the ecosystem. This proposal sustains the layer that connects Filecoin to the outside world: the Ledger custody stack, the Rosetta integration suite, and the public node, archival, and RPC infrastructure underneath them. This infrastructure carries production traffic for named consumers: Ledger: every FIL holder using a Ledger device. We maintain the Ledger Filecoin device app, the Rust/JS/Go libraries, and the Ledger Live integration through which FIL holders custody and move funds from a hardware wallet. That integration runs on our nodes, without them, it has nothing to talk to. Coinbase integrates Filecoin through the Rosetta–Filecoin suite (lib, proxy, indexing proxy) we maintain, and extracts genesis-to-date chain data from our archival nodes with a dedicated deployment workaround for Coinbase’s extraction now in production. Binance extracts genesis-to-date data from the same archival infrastructure. The Beryx public API and explorer and through them every consumer of that data layer, including FIDL (Traces), the Filecoin Security dashboards, and the ecosystem's data dashboards run on the node and archival infrastructure funded here. The API alone serves ~5M requests/week. Exchanges, storage providers, and builders query the public RPC directly instead of running their own nodes, and we walk them through every network upgrade. And these are only the consumers we can name. The public services don't track user identities; the consumers identified above are those whose volume required explicit rate-limit exceptions Coinbase and the Filecoin Foundation's own security team among them. The references listed in this proposal are themselves frequent users of this infrastructure. Our archival nodes hold complete chain history since genesis and have already let exchanges backfill data they could not reconstruct alone. What stops if this layer stops: FIL custody through Ledger Live breaks for every hardware-wallet holder — there is no alternative maintained integration. Coinbase's Rosetta path falls behind the next Lotus release and its archival extraction ends, as does Binance's. The Beryx API and explorer go dark, taking FIDL's traces source, the Filecoin Security dashboards, and ~5M requests/week of ecosystem queries with them. And the next network upgrade proceeds with no one tracking exchanges and providers through the transition. None of these consumers has a fallback in place, because for six years this layer has been the fallback. Note: this project is hardware- and operations-heavy. A large share of cost is node capacity, archival storage, and devops hours rather than software development, which is why the ask is larger than a thin software-service proposal of comparable scope. 1.6 Open Source Status: Fully Open Source 2.1 Project Summary: This project sustains the parts of Filecoin that connect it to the outside world: the **Ledger** stack FIL holders custody through, the Rosetta implementation Coinbase integrates through, and the public node, archival, and RPC infrastructure that **Binance**, **Coinbase**, the Beryx data layer (and its consumers: **FIDL**, the **Filecoin Security dashboards,** and FVM developers), and independent teams query instead of running their own nodes. Demand on this infrastructure is documented and growing. As recorded in the program's January 28, 2026 review call notes: **Binance** and **Coinbase** extract genesis-to-date chain data from our archival nodes; extraction load has at times consumed the full delivered capacity of the nodes; and per the guidance in that call, Binance and Coinbase are prioritized consumers, with Zondax to flag if sustained load pushes costs past contract terms. A dedicated deployment workaround now serves Coinbase's extraction in production. Zondax's costs have not risen but the capacity this grant funds is fully consumed by the ecosystem it serves. We run it all as one platform, so a single Lotus upgrade can ripple through custody, exchange integrations, and chain data at once , which is why we support exchanges and providers across each upgrade. Running one shared fleet rather than separate stacks keeps the layer affordable: a single grant covers infrastructure that would otherwise take several to fund. The grant sustains that operation through every protocol and SDK change. The gap it fills is operational continuity: the 2026 demand-side strategy assumes the network stays reachable and transactable, and nothing the KPIs measure works when an upgrade quietly breaks this layer. This revision adjusts the scope following the July 21 review discussion, through two named changes: reduced provisioned capacity headroom and redundancy on the node/archival fleet, and upgrade support scoped to the network upgrades expected in the term. The service consequences of both are stated in the risks section. 2.2 Who does this work support?: Onramps, Storage Providers, Application Builders, Application Users, Network Infrastructure 2.3 Total Funding Requested (USD): 237000 2.4 Milestones & Budget: {"title":"Ops Window 1","description":"Grant term: 1 October 2026 to 31 March 2027.\nThis first window covers 1 October to 30 November 2026. \n\n- Maintain the open-source Ledger stack (Filecoin device app + Rust/JS/Go libraries) and the Ledger Live integration against each Ledger SDK/firmware cycle and the supported device matrix (Nano S Plus, X, Flex, Gen5, Stax), so FIL holders can custody and transact.\n- Keep the Rosetta Filecoin suite (lib, proxy, indexing proxy) compatible with each Lotus release for Coinbase integration.\n- Operate the node and archival infrastructure and public RPC (mainnet and calibration) that the above run on and that other teams query directly.\n- Support exchanges and providers across any scheduled Filecoin network upgrade that falls in the window.\n- Proactive bug fixing, security patches, and regression prevention to keep the stack production-grade.","dueDate":"2026-11-30","fundingRequested":"79000 USD","completionCriteria":"- Ledger app and Ledger Live compatible with the current Ledger SDK and functional across the supported device matrix (Nano S Plus, X, Flex, Gen5, Stax)\n- Rosetta suite compatible with the current Lotus release\n- Node and archival infrastructure at ≥ 99.5% monthly availability on public RPC, with complete chain history since genesis\n- Prioritized archival access maintained for exchange consumers (Coinbase, Binance) per the January 2026 guidance\n- Any scheduled in-window network upgrade supported","milestoneUID":"0xa9ce0675fc17255f804617b005a5822c99b6be00f557fa43bb9cb2c8e630ba02"}, {"title":"Ops Window 2","description":"Covers 1 December 2026 to 31 January 2027. Same scope as Ops Window 1, for the period.","dueDate":"2027-01-31","fundingRequested":"79000 USD","completionCriteria":"Same criteria as Ops Window 1, for the period.","milestoneUID":"0x0a534a41b8ac15cd693fa802d98fc8f2459c341dd333ea84a630bd3f1db7b55d"}, {"title":"Milestone 3","description":"This window covers 1 February 2027 to 31 March 2027 and closes out the grant term.","dueDate":"2027-03-31","fundingRequested":"79000 USD","completionCriteria":"Same scope and criteria as Ops Window 1, for the period, plus an end-of-grant continuity summary covering the full term.","milestoneUID":"0xe49c46a7d7ce8810be8e5cfca922d96bcf4f893398a976a17adb2052fec73035"} Objective 1: Indirect Objective 2: Indirect Objective 3: Direct 3.1 Impact pathway: **Primary objective:** Objective 3, Scale Paid Onchain Flagship Client Adoption (Objectives 1 and 2 secondary, indirect). Our work is the precondition for the integrators and clients this objective counts. **Output**: we keep the pieces that carry most of Filecoin's flow to and from the outside world running and current. First is the Ledger stack: the Filecoin device app, the Rust/JS/Go libraries, and the Ledger Live integration, which is how FIL holders custody and move funds from a hardware wallet. That integration runs on our nodes and stops working without them. Second is the Rosetta Filecoin implementation that Coinbase uses to read and integrate Filecoin. Underneath both sits the public RPC and archival infrastructure other teams query directly, and we support exchanges and providers through each network upgrade so none of it breaks. **Outcome**: exchanges, onramps, builders, storage providers, and flagship clients can reliably submit, track, and settle activity on Filecoin, and FIL holders can custody and move funds securely throughout. A client or exchange can only adopt and stay on Filecoin if it has a working custody path, a current integration layer, and reliable data to operate against, which is exactly what we keep running. **Impact**: the KPI we directly protect is the count and retention of active integrations and onboarded clients. If Ledger Live FIL support lapses, Rosetta falls behind a Lotus release, or the archival/RPC layer degrades, integrations break and clients churn or never onboard, a measurable drop against that KPI. Our contribution is indirect because we don't generate the activity the KPIs count, but these are the rails it moves on, and our metrics table is the external check: Ledger stack currency, Rosetta release currency, and node/archival availability are each a leading indicator of whether the adoption path stays open. Our archival history has already let exchanges backfill data they couldn't reconstruct alone. The downside is concrete: a botched upgrade stalls exchange deposits and withdrawals, suppressing onchain activity and confidence. 3.2 Verification metrics: | Metric| Data source | How it's measured | Target (end of grant) | | Ledger device coverage | Ledger app store / GitHub releases | Supported device matrix kept current (Nano S Plus, X, Flex, Gen5, Stax) |Full matrix maintained | | Ledger Live functionality | Ledger Live app (Filecoin account); Zondax/Ledger release notes | FIL send/receive through Ledger Live working on supported devices, current with each Ledger Live and SDK release | Functional and current throughout the term | | Archival completeness | Public RPC queries against historical heights; exchange backfill confirmations | Archival nodes answer queries back to genesis | Complete history maintained | | Network upgrade readiness |Public Filecoin upgrade schedule; GitHub release tags; exchange confirmation | Each mandatory upgrade supported on the node/Rosetta stack within the upgrade window | 100% of in-term windows| | Rosetta release currency | GitHub release tags (rosetta-filecoin-lib/proxy) vs. Lotus releases| Days from a Lotus release to Rosetta compatibility | < 7 days, no missed releases | 3.3 References: Filecoin Foundation Erin O'Connor FILPonto, (Eva Shon) Coinbase (Bryan) Filecoin Security Dashboards (Ken) Filecoin Builders (sarah.thiam) 4.4 Core Team: **Juan Leni:** CEO and founder, Zondax. Overall responsibility for the company and the maximum engineering authority on this work. Long-standing lead of Zondax's Filecoin engagement, including the Ledger Filecoin application and the team's protocol and integration work across multiple L1 ecosystems. **Ainhoa Aldave:** Operations and delivery. Project management, partnerships, and coordination, including communication with exchanges and providers and the day-to-day running of the grant. **Emmanuel Murano:** Engineering Manager. Architecture and engineering oversight across the node infrastructure, Rosetta suite, and Ledger stack; responsible for the operational delivery of the maintained components. 4.5 Has your team received a ProPGF grant or funding from PLFIF before?: No 5.1 Key risks & dependencies: The most significant external dependency is Ledger. Ledger sets the SDK and firmware requirements and controls the release and approval process for the device app, so changes happen on their schedule and to their criteria, not ours: an SDK or firmware change, a new device, or a revised requirement can force app updates and full re-validation across the device matrix, and Ledger ultimately gates whether and when a release ships. We manage this through an established working relationship with Ledger, but the timeline and approval are not fully in our control. The second external dependency is the Lotus upstream API: Lotus periodically changes its API across releases, which forces re-testing and updates across our Rosetta and node-access tooling, and an unexpected breaking change can compress an upgrade window. On the infrastructure side, archival storage and node capacity scale with reindexing needs and can spike during upgrades, the main cost-variance risk; we manage it by running the fleet as one shared operation rather than separate stacks per workload. Team risk is mitigated by internal cross-training and resource rotation, so no single contributor is a single point of failure on the Ledger or node stack. Following the July 2026 review discussion, this proposal's scope was adjusted with two stated consequences. First, node/archival capacity is provisioned at a reduced headroom and redundancy margin: the fleet continues to serve all named consumers, but with less surge capacity for extraction-load spikes of the kind documented in the January 28, 2026 review notes, and with reduced standby redundancy, meaning longer recovery windows in the event of hardware or site failure. Per the guidance in that call, Coinbase and Binance remain prioritized, and Zondax will flag to the program if sustained exchange load pushes costs past these terms. Second, upgrade and provider support is scoped to the network upgrades expected in the term, out-of-cycle events are handled best-effort. The principal funding risk is that this work has no commercial revenue behind it and the prior engagement ends 30 September 2026: it depends on grant funding to continue, and without it the work winds down rather than degrading gradually. Anything else you want to share that we didn't ask?: This application is one of two complementary submissions from Zondax for Batch 3, revised following the July 21 review discussion: the scope was adjusted through reduced capacity headroom and redundancy on the node/archival fleet and upgrade support scoped to the expected network upgrades, with the service consequences stated in the risks section. Beryx is submitted as a separate proposal, similarly revised. The two projects are operationally related but financially and technically distinct: Beryx runs on the infrastructure funded here, alongside the Ledger custody path for every FIL hardware-wallet holder, the Rosetta layer Coinbase integrates through, and the archival extraction serving Binance and Coinbase. Both proposals share an aligned term.