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
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.
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.
The Fellowship runs on a defined mix of on-chain rules and off-chain collaboration.
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.
The Fellowship operates on-chain through the Polkadot Collectives system chain, a parachain that records rank changes and votes.
Technical debate happens before anything reaches the chain, through the Fellowship's GitHub repository, where the RFC process plays out.
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.
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.
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.
An RFC, short for Request for Comment, is a formal proposal to change a standard.
A developer drafts the change and opens it in the Fellowship's public RFC repository, laying out the problem and the fix.
Members review the draft and vote, with rank-weighted voting giving senior members more say.
An approved RFC becomes a recognized standard; a rejected one gets reworked or dropped.
RFCs mostly coordinate technical design among developers. Network-wide adoption can still fall under OpenGov, not the Fellowship alone.
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.
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.
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.
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.
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.
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.
