Polkadot doesn’t have one center of power off-chain. It has three. Parity builds the protocol. The Web3 Foundation sets strategy, funds the ecosystem, and -since 2025- votes directly in OpenGov. The PCF signs the contracts and holds the IP. The one body meant to be an independent technical check on all of this describes itself, through its own founder, as “powerless… an oracle and nothing more.” Its founding document hasn’t caught up with any of this. It still names, word for word, an algorithm the network is retiring.
This isn’t a new complaint. It’s the same pattern I already raised about the Polkadot App, showing up one layer deeper.
What already happened with the App
There’s an open Wish for Change on Subsquare (#457), addressed to the PCF as the entity holding treasury funding under Refs #1082, #1573 and #1591. The facts:
- Ref #1573 sent roughly 1,029,730 USDT to the PCF, 748,800 USD of it (72.7%) for software development. The proposal itself admitted the project was behind schedule and gave no launch date.
- Ref #1591 paid 632,000 USD for a year of PCF operations, explicitly funding a public dashboard, monthly updates, and two tokenholder-elected director seats.
- The PCF’s own bylaws require quarterly transparency reports.
- None of it shipped. No dashboard, no monthly updates, the two director seats appear unfilled, and the App itself -announced at Decoded in 2024- still has no roadmap, no financial reconciliation, no launch date. A direct request for answers went unanswered before the Wish for Change was filed.
I’m not asking anyone to relitigate that here. I’m citing it because it’s evidence of a pattern: the PCF ships product faster than anyone can hold it accountable for it.
The same pattern, one layer deeper
On July 23, Polkadot announced the Products Devnet, built with the Paseo team and the PCF. Per the PCF’s own developer docs, the Product SDK gives apps “typed access to the host: wallet, signing prompts, storage, and chain access” described in the same breath as infrastructure “expected to be part of Polkadot’s mainnet in the future.”
Within days, Parity posted:
“The Polkadot Product DevNet is independently operated by the Polkadot Community Foundation. All questions, support requests, complaints or other issues relating to its availability, operation or use should be directed to the Polkadot Community Foundation.”
The support repo it links to, products-devnet-issues, has one contributor. The PCF’s GitHub organisation lists no public members. There is no visible way to know who is technically accountable for a system that intermediates user wallets and signing.
To be precise about the actual stakes: it’s a devnet, tokens have no real value, nothing is at risk today. This is the same shape of problem as the App, caught one step earlier, before real money is involved instead of after. That’s exactly why it’s worth fixing now.
Three entities, one document that names none of them
Parity builds the protocol and, increasingly, the product layer, while contractually stepping back from what it built the moment the PCF deploys it. The Web3 Foundation’s own description of itself is strategy, grants, brand, governance coordination; in 2025 Gavin Wood confirmed it has also become an active OpenGov voter, adding direct governance weight on top of everything else it already does. The PCF is a Cayman foundation company, designed by an outside consultancy before the community ever voted on it, whose own governing documents describe it as executing “actions directed to it via OpenGov referenda.” Nothing in that mandate claims technical protocol expertise. It is now also the named operator of the wallet layer.
What the Fellowship actually is
Two things are true at once. The Fellowship holds real, specific power: the runtime itself lives in polkadot-fellows/runtimes, and changes to it go through Fellowship review and merge rights. That’s genuine authority over what code the network runs.
Outside that lane, its founder was blunt. Introducing Gov2 and the Fellowship, Gavin Wood said:
“The fellowship is powerless; it has no power whatsoever to change the protocol. The only thing it can do is to declare that it believes a particular proposal is safe and time critical. It is an oracle and nothing more, and it places it in a whitelist.”
Reasonable design, for a body meant to whitelist urgent runtime fixes in 2022. It says nothing about three off-chain entities that didn’t exist in their current form when it was written, including one that now runs the layer where user funds will eventually sit.
The Manifesto hasn’t moved and it says so itself
It’s still titled Draft 5. Section 2.4.1 defines Fellowship expertise as node internals, “consensus algorithms concerning the Relay-chain (BABE & GRANDPA),” XCM, runtime and pallet internals, standard RPCs. It explicitly excludes tooling that’s “required but not primarily used” for network operation, naming subxt and ink! as the examples.
Here’s the part worth sitting with: BABE is already being replaced. JAM, Polkadot’s own next-generation protocol, swaps BABE for SAFROLE as the block-production mechanism (GRANDPA stays for finality). That’s not a hypothetical, it’s the roadmap Gavin Wood himself is currently building. The document defining what Fellowship members are experts in still names, by name, the mechanism JAM is retiring. Sit that next to Async Backing, Agile Coretime, Elastic Scaling, and the ongoing Asset Hub Migration, moving core logic off the Relay Chain entirely and “the Relay-chain” stops being the stable center of gravity the Manifesto assumes throughout.
And under a literal reading, a host API for wallet, signing, and storage falls into the same excluded bucket as subxt: needed, but not the Fellowship’s job. Defensible in 2022. Not a good outcome in 2026.
None of this is inference. The document admits it. As of today, the Philosophy & Principles section still reads: “Note: This section needs somestantial improvment in the coming months” typo included, unfixed. The closing Meta-notes section still says: “This section captures the current train of thought and is better moved to an online forum for community discussion,” followed by a list of open questions (“Introduce sponsors,” bring in shadowing requirements, and so on) that, years later, still reads like a to-do list nobody closed.
Where I think this gets pushed back on, and why I’m making the case anyway
The Fellowship was kept narrow on purpose, so a self-selecting technical body wouldn’t end up with power over legal entities and treasury money it was never built to govern. Expanding it carelessly just trades one centralization risk for another, that’s the strongest objection, and it deserves to be named up front rather than left for the comments.
It’s also fair to say nothing has gone wrong yet. No funds are at risk on a devnet. This is a preventive ask, not a response to a loss.
And Fellowship members are, by design, protocol and runtime people. A body good at judging consensus algorithms isn’t automatically good at judging wallet security. Any expanded scope needs to actually bring in reviewers qualified for it, not just hand the job to whoever’s already there.
All three of those point toward keeping this narrow and explicit, not toward leaving the gap open.
What I’m asking for
Not for the Fellowship to run the PCF, vote for the Web3 Foundation, or take on legal work outside its competence. Two separate, scoped things:
-
A scoped RFC (through the existing
polkadot-fellows/RFCsprocess) establishing Fellowship technical review over any host API or SDK that handles wallet, signing, or storage for third-party Products before it reaches mainnet, whoever operates it, with a floor requirement that any entity governance hands this kind of infrastructure to maintains a public technical contact and a real vulnerability-reporting process. The RFC should say explicitly that this needs security and UX-qualified reviewers, not just protocol specialists. -
A real revision pass on the Manifesto, opened first as an issue on
polkadot-fellows/manifesto, to define -or explicitly disclaim- the Fellowship’s relationship to the PCF, the W3F’s OpenGov vote, and the product layer, instead of leaving it to be improvised each time it comes up. While at it: replace the named BABE/GRANDPA reference with language that tracks the actual consensus mechanism in use, so the next protocol transition doesn’t leave this section stale again.
As a starting point for §2.4.1, not a final draft:
Additionally, the following are considered within the Fellowship’s advisory remit for the purpose of pre-mainnet security review, though not part of its core ranked-expertise domain: host APIs, SDKs, or platform primitives, however operated, and by whichever entity that provide third-party applications with wallet custody, transaction signing, or key-adjacent storage functions intended for eventual use on the Polkadot Main Network.
Posting here first, on purpose, before touching either repo. Between RFCs and manifesto there have been a handful of issues and PRs, total. A proposal that shows up there without discussion first is easy to dismiss regardless of whether it holds up. Looking for reaction on: whether (1) and (2) should be one track or two, whether current Fellowship members think the RFC process is the right vehicle for (1) versus a Wish for Change addressed directly to the Fellowship, and whether the suggested §2.4.1 language is even in the right place.