Scope

Request

Constant

Rank

Polkadot

<h2 id="span-style-color-inherit-font-weight-bolder-span-style-font-size-16px-how-does-the-polkadot-fellowship-shape-technical-governance-span-span">How Does the Polkadot Fellowship Shape Technical Governance?</h2>
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 <a href="https://www.coingabbar.com/en/polkadot-opengov-explained-decentralized-governance" rel="noopener noreferrer nofollow">Polkadot OpenGov</a> 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.
<h2 id="span-span-style-font-size-16px-what-is-the-polkadot-technical-fellowship-span-span">What Is the Polkadot Technical Fellowship?</h2>
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 <a href="https://polkadot.com/" rel="noopener noreferrer nofollow">Committee from Polkadot's</a> earlier governance model.
Its job is narrow: judge&nbsp;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.
<h2 id="span-span-style-font-size-16px-how-the-polkadot-fellowship-is-structured-span-span">How the Polkadot Fellowship Is Structured</h2>
The Fellowship runs on a defined mix of on-chain rules and off-chain collaboration.
<h3 id="span-span-style-font-size-16px-fellowship-members-and-technical-experts-span-span">Fellowship Members and Technical Experts</h3>
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.
<h3 id="span-span-style-font-size-16px-polkadot-collectives-and-on-chain-governance-span-span">Polkadot Collectives and On-Chain Governance</h3>
The Fellowship operates on-chain through the&nbsp;<a href="https://wiki.polkadot.com/learn/learn-polkadot-technical-fellowship/" rel="noopener noreferrer nofollow">Polkadot Collectives system chain</a>, a parachain that records rank changes and votes.
<h3 id="span-span-style-font-size-16px-off-chain-discussions-and-rfc-process-span-span">Off-Chain Discussions and RFC Process</h3>
Technical debate happens before anything reaches the chain, through the Fellowship's GitHub repository, where the RFC process plays out.
<h2 id="span-span-style-font-size-16px-polkadot-fellowship-ranks-explained-span-span">Polkadot Fellowship Ranks Explained</h2>
Membership isn't flat. The Fellowship uses a numbered rank system, sometimes called "Dan" levels, running from 0 through 9.
<div>
 <table>
 <colgroup>
 <col width="116">
 <col width="386">
 </colgroup>
 <tbody>
 <tr>
 <td>Rank</td>
 <td>Role</td>
 </tr>
 <tr>
 <td>0</td>
 <td>Entry-level member</td>
 </tr>
 <tr>
 <td>1</td>
 <td>Member</td>
 </tr>
 <tr>
 <td>2</td>
 <td>Proficient</td>
 </tr>
 <tr>
 <td>3</td>
 <td>Fellow</td>
 </tr>
 <tr>
 <td>4</td>
 <td>Architect</td>
 </tr>
 <tr>
 <td>5</td>
 <td>Architect Adept</td>
 </tr>
 <tr>
 <td>6</td>
 <td>Grand Architect</td>
 </tr>
 <tr>
 <td>7</td>
 <td>Free Master</td>
 </tr>
 <tr>
 <td>8</td>
 <td>Master Constant</td>
 </tr>
 <tr>
 <td>9</td>
 <td>Grand Master</td>
 </tr>
 </tbody>
 </table>
</div>
The&nbsp;<a href="https://polkadot-fellows.github.io/dashboard/" rel="noopener noreferrer nofollow">Fellowship dashboard</a> 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.
<h2 id="span-span-style-font-size-16px-how-fellowship-membership-works-span-span">How Fellowship Membership Works</h2>
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&nbsp;<a href="https://www.coingabbar.com/en/polkadot-treasury-funding-ecosystem-model" rel="noopener noreferrer nofollow">Polkadot treasury</a> 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.
<h2 id="span-span-style-font-size-16px-how-polkadot-fellowship-voting-works-span-span">How Polkadot Fellowship Voting Works</h2>
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&nbsp;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.
<h2 id="span-span-style-font-size-16px-how-fellowship-rfcs-work-span-span">How Fellowship RFCs Work</h2>
<h3 id="span-span-style-font-size-16px-what-is-a-fellowship-rfc-span-span">What Is a Fellowship RFC?</h3>
An RFC, short for Request for Comment, is a formal proposal to change a&nbsp;standard.
<h3 id="span-span-style-font-size-16px-how-developers-submit-an-rfc-span-span">How Developers Submit an RFC</h3>
A developer drafts the change and opens it in the Fellowship's&nbsp;<a href="https://github.com/polkadot-fellows/RFCs" rel="noopener noreferrer nofollow">public RFC repository</a>, laying out the problem and the fix.
<h3 id="span-span-style-font-size-16px-fellowship-review-and-voting-span-span">Fellowship Review and Voting</h3>
Members review the draft and vote, with rank-weighted voting giving senior members more say.
<h3 id="span-span-style-font-size-16px-rfc-approval-and-rejection-span-span">RFC Approval and Rejection</h3>
An approved RFC becomes a recognized standard; a rejected one gets reworked or dropped.
<h3 id="span-span-style-font-size-16px-from-rfc-to-network-governance-span-span">From RFC to Network Governance</h3>
RFCs mostly coordinate technical design among developers. Network-wide adoption can still fall under OpenGov, not the Fellowship alone.
<h2 id="span-span-style-font-size-16px-what-role-does-the-fellowship-play-in-opengov-span-span">What Role Does the Fellowship Play in OpenGov?</h2>
The Fellowship doesn't run Polkadot's governance; it feeds&nbsp;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.
<h2 id="span-span-style-font-size-16px-polkadot-fellowship-vs-polkadot-opengov-span-span">Polkadot Fellowship vs Polkadot OpenGov</h2>
<div>
 <table>
 <colgroup>
 <col width="115">
 <col width="242">
 <col width="262">
 </colgroup>
 <tbody>
 <tr>
 <td>Feature</td>
 <td>Technical Fellowship</td>
 <td>OpenGov</td>
 </tr>
 <tr>
 <td>Main focus</td>
 <td>Technical expertise</td>
 <td>Network governance</td>
 </tr>
 <tr>
 <td>Participants</td>
 <td>Ranked technical members</td>
 <td>Polkadot stakeholders (DOT holders)</td>
 </tr>
 <tr>
 <td>Voting basis</td>
 <td>Fellowship rank weight</td>
 <td>Token-based conviction voting</td>
 </tr>
 <tr>
 <td>Main role</td>
 <td>Technical signaling, RFC approval</td>
 <td>Final governance decisions</td>
 </tr>
 <tr>
 <td>Handles RFCs</td>
 <td>Yes</td>
 <td>No</td>
 </tr>
 </tbody>
 </table>
</div>
The two systems complement rather than compete. The Fellowship checks whether something is technically sound; OpenGov decides whether the network adopts it.
<h2 id="span-span-style-font-size-16px-why-the-polkadot-fellowship-matters-span-span">Why the Polkadot Fellowship Matters</h2>
Blockchains that lean purely on token-weighted voting for&nbsp;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&nbsp;<a href="https://www.coingabbar.com/en/polkadot-agile-coretime-explained-new-blockspace-model" rel="noopener noreferrer nofollow">Agile Coretime</a>, which reshaped how Polkadot allocates blockspace.
<h2 id="span-span-style-font-size-16px-limitations-of-the-polkadot-fellowship-span-span">Limitations of the Polkadot Fellowship</h2>
The Fellowship's authority has clear boundaries, by design.
<ul>
 <li>Scope is limited:It focuses on core protocol technology, not every project built on Polkadot.</li>
 <li>RFC approval isn't implementation: An accepted RFC sets a standard; shipping it is a separate engineering step.</li>
 <li>Relay-chain governance has the final say: On network-wide changes, even ones approved technically.</li>
 <li>Technical merit and consensus stay separate on purpose: So no small expert group can push changes the community hasn't voted on.</li>
</ul>
<h2 id="span-span-style-font-size-16px-polkadot-fellowship-governance-workflow-span-span">Polkadot Fellowship Governance Workflow</h2>
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&nbsp;<a href="https://www.coingabbar.com/en/polkadot-jam-upgrade-future-network-architecture" rel="noopener noreferrer nofollow">Polkadot JAM upgrade</a> through technical review.
<h2 id="span-span-style-font-size-16px-conclusion-span-span">Conclusion</h2>
The Polkadot Fellowship keeps deep technical judgment inside <a href="https://www.coingabbar.com/en/complete-polkadot-ecosystem-guide-dot-technology-overview" rel="noopener noreferrer nofollow">Polkadot's governance</a> without replacing token-holder oversight. Its&nbsp;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.&nbsp;
Anyone tracking Polkadot's roadmap should watch Fellowship activity closely, since a&nbsp;change often takes shape here first.
Disclaimer:&nbsp;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.

Polkadot Fellowship Explained: Developer Governance Structure

Table of Contents

Coingabbar

Other articles published on Sep 26, 2026

Join our free newsletter for daily crypto updates!