Polkadot Fellowship Explained: Developer Governance Structure
How Does the Polkadot Fellowship Shape Technical Governance?
Every blockchain needs someone to judge whether a proposed technical change is safe. For Polkadot, that job sits with the Polkadot Fellowship, a body of vetted developers who review, rank, and sign off on the network's technical direction.
The Fellowship works alongside Polkadot OpenGov rather than replacing it. It isn't a token-holder vote; it's a separate, developer-led structure focused on technical judgment.
This article covers what the Fellowship is, how its ranks work, how RFCs move through it, and where it fits inside Polkadot's governance model.
What Is the Polkadot Technical Fellowship?
The Polkadot Technical Fellowship is a self-governing group of protocol experts and core developers for the Polkadot and Kusama networks. It was established in 2022, replacing the Technical Committee from Polkadot's earlier governance model.
Its job is narrow: judge quality, not popularity. Members evaluate code, protocol design, and upgrades based on expertise, not token holdings. Unlike the smaller, closed Technical Committee, it gives any qualified developer a clear path to join and rise through its ranks.
How the Polkadot Fellowship Is Structured
The Fellowship runs on a defined mix of on-chain rules and off-chain collaboration.
Fellowship Members and Technical Experts
Members range from newcomers with a few genuine code contributions to long-time developers who've shaped major parts of the protocol, each holding a numbered rank that reflects their track record.
Polkadot Collectives and On-Chain Governance
The Fellowship operates on-chain through the Polkadot Collectives system chain, a parachain that records rank changes and votes.
Off-Chain Discussions and RFC Process
Technical debate happens before anything reaches the chain, through the Fellowship's GitHub repository, where the RFC process plays out.
Polkadot Fellowship Ranks Explained
Membership isn't flat. The Fellowship uses a numbered rank system, sometimes called "Dan" levels, running from 0 through 9.
Rank | Role |
0 | Entry-level member |
1 | Member |
2 | Proficient |
3 | Fellow |
4 | Architect |
5 | Architect Adept |
6 | Grand Architect |
7 | Free Master |
8 | Master Constant |
9 | Grand Master |
The Fellowship dashboard describes ranks within this framework. Lower ranks are common; top tiers are rare and take years of verifiable work.
Rank isn't handed out casually. Members seeking retention or promotion must meet activity and agreement thresholds in the manifesto, and serve a minimum of 12 months at their rank before requesting promotion. Higher ranks can also require an in-person interview before the vote.
How Fellowship Membership Works
Joining isn't automatic. The only way to become a member is through a referendum: a candidate is proposed, members weigh in, and the decision is confirmed on-chain.
A dedicated induction interface, funded through a Polkadot treasury allocation, now helps candidates apply. Membership isn't permanent, either; members periodically submit evidence to retain or promote their succession, and demotion is possible if contributions dry up.
Promotion up to level 4 happens through a Fellowship referendum voted on by members two ranks higher. Promotion from rank 5 upward needs a full OpenGov referendum instead.
How Polkadot Fellowship Voting Works
Fellowship votes aren't one-member-one-vote. Weight increases non-linearly with succession, so a rank 6 member's vote carries far more weight than a rank 1 member's.
Community write-ups summarizing the manifesto commonly express this with a formula close to w(r) = r(r + 1) / 2, where a rank 3 member carries a weight of roughly 6 and a 5 member roughly 15. Treat these as illustrative, not an official constant.
The top rank tiers still require a referendum rather than peer approval alone, to stop the group from becoming a clique. Some actions, like approving whitelist calls, are restricted to members above a set rank.
How Fellowship RFCs Work
What Is a Fellowship RFC?
An RFC, short for Request for Comment, is a formal proposal to change a standard.
How Developers Submit an RFC
A developer drafts the change and opens it in the Fellowship's public RFC repository, laying out the problem and the fix.
Fellowship Review and Voting
Members review the draft and vote, with rank-weighted voting giving senior members more say.
RFC Approval and Rejection
An approved RFC becomes a recognized standard; a rejected one gets reworked or dropped.
From RFC to Network Governance
RFCs mostly coordinate technical design among developers. Network-wide adoption can still fall under OpenGov, not the Fellowship alone.
What Role Does the Fellowship Play in OpenGov?
The Fellowship doesn't run Polkadot's governance; it feeds judgment into it, managing membership, approving RFCs, and whitelisting OpenGov proposals on the whitelist track.
Whitelisting changes a proposal's execution path. OpenGov lets the Fellowship authorize a "Whitelisted-Caller" origin, letting an approved call execute with root-level privileges, currently limited to rank three and above. Even so, whitelisting isn't final approval; a whitelisted proposal still has to pass the normal referendum process.
Polkadot Fellowship vs Polkadot OpenGov
Feature | Technical Fellowship | OpenGov |
Main focus | Technical expertise | Network governance |
Participants | Ranked technical members | Polkadot stakeholders (DOT holders) |
Voting basis | Fellowship rank weight | Token-based conviction voting |
Main role | Technical signaling, RFC approval | Final governance decisions |
Handles RFCs | Yes | No |
The two systems complement rather than compete. The Fellowship checks whether something is technically sound; OpenGov decides whether the network adopts it.
Why the Polkadot Fellowship Matters
Blockchains that lean purely on token-weighted voting for decisions run into a real problem: most token holders aren't equipped to judge deep protocol design. The Fellowship folds real technical expertise into governance without handing full control to one company.
It also gives developers a career path, moving contributors from an entry-level rank toward real influence. Fellowship members have driven upgrades from the inside, including work on Agile Coretime, which reshaped how Polkadot allocates blockspace.
Limitations of the Polkadot Fellowship
The Fellowship's authority has clear boundaries, by design.
Scope is limited: It focuses on core protocol technology, not every project built on Polkadot.
RFC approval isn't implementation: An accepted RFC sets a standard; shipping it is a separate engineering step.
Relay-chain governance has the final say: On network-wide changes, even ones approved technically.
Technical merit and consensus stay separate on purpose: So no small expert group can push changes the community hasn't voted on.
Polkadot Fellowship Governance Workflow
A simplified version of how a technical idea moves through the system:
Developer → RFC → Discussion → Fellowship Review → On-Chain Signal → Governance/Implementation
A developer drafts an RFC, the community discusses it, ranked members vote, and an approved outcome becomes a maintained standard or moves toward OpenGov consideration. This pipeline has carried efforts like the Polkadot JAM upgrade through technical review.
Conclusion
The Polkadot Fellowship keeps deep technical judgment inside Polkadot's governance without replacing token-holder oversight. Its system rewards sustained contribution, its RFC process gives developers a structured way to propose changes, and its relationship with OpenGov, reviewing and whitelisting rather than deciding outright, keeps the two systems balanced.
Anyone tracking Polkadot's roadmap should watch Fellowship activity closely, since a change often takes shape here first.
Disclaimer: This article is for informational purposes only and does not constitute financial or investment advice. Governance structures and rank frameworks can change over time, so readers should verify current details on Polkadot's official documentation before relying on them.
