Polkadot Protocol and Common Good Parachains

I’m starting this as a new thread, but it’s mostly a response to this question in “Substrate Ecology v0.1”:

Current communication of what is / isn’t a Common Good Parachain - is unclear. This is to expected, but the impacts of these emerging definitions has real impact, on historic development and moving forward and so a definitive effort to share the current thinking of those definitions is vital.

Starting a new thread because (a) I think it’s a topic that deserves more discussion on its own, and (b) it’s related to other discussions, like the Snowbridge funding proposal.

A Bit of History

As far as I recall, the idea of common good chains was first presented by Gav at the same time as parathreads, at DOTcon in 2019. Fast forward about 18 months, I wrote an article that roughly divided these common good chains into two buckets: system level and public utility.

In both Gav’s presentation and my article, the idea of CGPs was still mostly an idea. There were no parachains at all on Kusama or Polkadot, so we hadn’t seen how the chains would function in practice technically or in relation to the auction system of the networks.

As expected, we all learn when turning theory into practice. The two I will address here are:

  1. Opinionation spectrum

  2. Opinionated territoty

Opinionation Spectrum

I originally thought of chains fitting cleanly into a “system” or “public utility” bucket. However, sometimes it’s natural to group functionality that may be related into one chain, but that falls under different categories.

For example, take Statemint. The fungible assets and NFT functionality clearly falls more on the “utility” side. NFTs are just not part of the core Polkadot protocol that makes the network function. However, balances are, and Statemint supports holding and transacting in DOT (at much lower existential deposit and transaction fees than the Relay Chain). In the future, the goal is to use this chain to lock balances that would be used in staking, governance, &c. So it is difficult to put Statemint into a bucket, but we can certainly put these subsystems into buckets.

I think of this functionality being on an opinionation spectrum.

(Thanks to @shawntabrizi for a graphic that’s not drawn with colored pencils.)

Unopinionated System

On one end, one can consider “pure” unopinionated functionality. This end is quite clearly defined: There can only be one. This functionality simply must exist for Polkadot to be Polkadot. Whether these subsystems are in the Relay Chain or parachains is purely architectural. Some examples:

  • Balances: There is some fixed amount of DOT in the network at any given time.
  • Staking: Having multiple staking pallets distribute stake to different sets of validators defeats a primary purpose of the staking system: knowing who the validators are at a given time.
  • Governance: Likewise, we don’t want multiple governance systems to access the Root origin; having them would just be more avenues of access for malicious proposals.
  • Para Leases: Polkadot should have a single, common way to permissionlessly register a parachain and acquire a lease.

For clarity, there may be many ways to participate in or access these subsystems. For example, users can run a validator themselves, nominate directly, or create or join a pool. Likewise parachains could become a parathread, bid directly in an auction, run a crowdloan, &c. These participation/access means should not necessarily be limited to one, but the network needs canonical info for these low level systems.

Core Protocol

As we move to the right, we run into functionality that is core to the network, and therefore part of the Polkadot protocol, but where multiple implementations can actually complement each other.

  • Treasury: Perhaps this should go with “unopinionated system” because the ability for governance to spend for various initiatives is singular. I think the general ability is essential to the system, but it could be split into smaller treasuries with specific mandates and spending processes (e.g. paying contributors with Fellowship evaluation vs. funding ecosystem events).
  • Bridges: A fundamental assumption behind Polkadot is that many blockchains will exist in the future, and it’s a naive assumption to think they will all be in Polkadot. Just like there are Windows, Mac, Android, Linux, &c. operating systems, there will be other consensus systems. Bridges are in the Polkadot Whitepaper as a core part of the network and will be important to keep Polkadot relevant in the future. That said, it’s possible to have more than one bridge. Unlike staking, there’s nothing technically wrong with multiple bridges to other networks.
  • Collectives: This one is why I call it a “spectrum” and not “buckets”. I’d consider the ability to create on-chain collectives as part of the core protocol, but there could exist many means of doing so.However, there are some collectives where only one makes sense, e.g. the Technical Fellowship. Having multiple technical fellowships distracts from their purpose of being a body of expert contributors to the core protocol. But there could be many generic DAO-creation chains.
  • Crowdloans: Although Polkadot has one auction system, there can be many ways to participate in those auctions, including many ways to let individuals organize and participate in the auction as a unitary body. Polkadot does include a Crowdloan pallet, but it’s by no means the only way to implement the functionality. Polkadot could include a default implementation in a common good chain, but that doesn’t stop other implementations from popping up.

If you are thinking, “Hey, guy! There were already lots of alternative {‘liquid crowdloans’, ‘Bridges’, ‘DAOs’} on Polkadot.” Yes, hold that thought, I’m getting there.


Now we are in major opinionationland. Things like asset registration, NFT functionality, reputation systems, certifications, &c. In this area, the functionality is less about “core Polkadot protocol” and more “accessibility using the DOT token”. We might consider these non-essential to the pure ability of Polkadot to validate state transitions of its parachains, but more-or-less essential to be relevant as a foundational system in Web3.

Without going into detail on these, a few would be:

  • Fungible asset registries (e.g. Statemint): Perhaps this is closer to core protocol. Again, spectrum.
  • Non-fungible asset registries (also Statemint)
  • Smart contracts (Perhaps also closer to core protocol)
  • Reputation, identity services (e.g. Encointer)
  • Certification/attestation services
  • Random oracles
  • Large and/or encrypted file storage
  • Domain registries

This area tends to get controversial quite fast. On one hand, one of the great things about Polkadot is that end-users don’t actually have to know about Polkadot or parachains or DOT. They might use some application built on many parachains without any knowledge of the underlying consensus provider.

On the other, when application builders come into the Polkadot ecosystem, it can be an extra step to go from learning about Polkadot to then choosing a parachain to build on.

My utopic vision for the role of common good chains of this type is that they are stepping stones. “Can Polkadot do NFTs?” → “Yes! Dive right in on Statemint.” Then, once someone sees that it’s easy to get started, they might realize that one of the other “free market parachains” has NFT functionality that’s more appropriate/interesting to them, so they migrate to RMRK, BitCountry, Phala, Unique Network, Efinity, or {insert those I forgot}. To me, this means that any of these chains, if being built as a common good, must be built in close collaboration with the community and with migration paths to other chains.

We are early, and I realize we have a lot of progress to make to get to that state. But at least in my own efforts, that’s the direction in which I am trying to go.

Functionality Over Chains

All the bullet points above were subsystems, not chains. It’s expected that one chain could include a few of those subsystems from different points on the spectrum. Let’s say we make an “execution core allocation” parachain that allocates leases to parachains via auction, assigns certain execution cores for parachains, parathreads, dynamic scheduling, boost capacity, &c. It would be reasonable to include the Auctions pallet (pure system) and the Crowdloan pallet (core protocol) in the same chain. You can’t really put the entire chain into a bucket anymore.

This does not mean, however, that other crowdloan systems cannot exist. As we have seen in the auctions on Polkadot, several “liquid crowdloan” protocols came up from other teams. That’s cool, and we should encourage that. Polkadot can provide the Crowdloan pallet in a common good parachain, and others can develop more featureful crowdloans with different trust models and different rewarding, bidding, refunding, locking, &c. strategies. Parachains and contributors can choose the systems that they think give them the best chance of winning.

Opinionated Territory

So, why does one Crowdloan pallet get to be the “default” and be part of the Polkadot protocol? Similarly, why would one bridge be included in a common good chain while another not?

That is ultimately up to governance to decide. But as a common good, a feature is part of the Polkadot core protocol. As discussed, many of these features can have more than one implementation. Besides being accessible using only the token of the core protocol (DOT), features that are part of the core protocol should abide by the core principles of the network. Primarily, these would be prioritization of trust minimization and unstoppability above all else.

That means no trusted accounts (including multisigs), no sudo-privileged councils, respect of the network’s governance for privileged operations (like upgrades, choosing collectives’ membership), and acceptance of the DOT token for economic security.

Teams going the “free market” route have the additional hurdle of acquiring funding for their lease, but much more freedom in technical, social, and economic design spaces. We’ve already seen that freedom exercised in many ways on Polkadot. Parachains often launch with sudo to control their upgrade/launch process. Many of the liquid crowdloan protocols have multisigs that control contributors’ tokens. Many of the bridges deployed on parachains have multisig authorities. And of course, many parachains have their own tokens and economic incentives. These all allow those protocol developers to innovate fast, build their own communities (that may not even be interested in Polkadot), and try new things at a pace not supported by Polkadot’s governance processes.

None of that is to say that that kind of innovation isn’t valuable or welcome. It’s just a design tradeoff. To have a large design freedom, projects need to build their own community and convince investors or crowdloan participants to back them enough to win a slot. To become a common good, you need to convince the DOT stakeholders that your subsystem is safe and aligns with the entire network’s interests.

This Polkassembly comment makes my point perfectly:

Since the inception of beefy, teams have been waiting to implement the usage but have gone the centralized bridge route.

Yes, which they had every right to do. They have built communities, won parachain slots in auction, and launched those bridges, because they saw a market opportunity and their users trust them to operate a centralized bridge.

But centralized bridges are not part of the Polkadot protocol.

I think there is a misconception that teams who go the common good route have taken a shortcut and are skipping a major hurdle to get on Polkadot. In my opinion, getting a common good lease should be more difficult, because you are held to the standards of all DOT holders to deliver trust-free, mission critical core components. We have seen some teams (e.g. Interlay) start with the intention of launching as a common good later decide to compete in an auction because the common good route was too restrictive.

I also don’t mean to suggest that going the auction route is easy. It’s not, and I hope that with the development of more dynamic scheduling mechanisms like parathreads, the barrier to launch a chain on Polkadot will come down greatly.

Wrapping Up

Back to this: “Current communication of what is / isn’t a Common Good Parachain - is unclear.”

First, the only entity that can communicate this is the Polkadot network via on-chain referendum.

Polkadot is an amazing technology for scaling Web3. The act of putting core functionality into a parachain is an instance of Polkadot using its own technology, not “taking” a lease that would otherwise go to an auction. This is not a zero-sum game. Moving core functionality to parachains will actually make more parachain execution cores available.

My opinion is that anything in a common good parachain is part of the Polkadot protocol, so the primary question that DOT holders should evaluate when considering common good parachain funding and leases is: “Should this functionality be part of the Polkadot protocol?” That question may become political. But if the outcome is “yes, it is part of the Polkadot protocol”, then whether that protocol is hosted on the Relay Chain or in a parachain is an architectural, not political, decision.


Going to link my reply to the other thread here with the example of our project that probably fits better this conversation,

I’m glad you talk about a spectrum, chains have very diverse purposes and we cannot easily put labels on them, is “common good chain” perhaps too generic? It might be useful to have a few more labels laying around, it could help people to have a better sense of what a project is about and what kind of ideals come attached to it.
A separate step is for DOT holders to decide based on said ideals how a chain should join the ecosystem, is it a long term no strings attached lease plus extra funds? perhaps a shorter term lease with a loan to bootstrap a project and let it prove itself? normal auction? creative auction? or even the project having to pay extra “tax” to the community because their business goes against most people’s values?

Talking about ideals and stuff, when you mention “anything in a common good parachain is part of the Polkadot protocol”, I think here we either elaborate more on what protocol means or perhaps change it to something like vision or similar? this stuff is very subjective and will change over time, protocol sounds like something more rigid limited things in the whitepaper and leaves out more creative efforts like what Encointer or now Sequester is proposing which are not part of the original Polkadot scope but holders might want to see them being supported by the ecosystem because of their nature.

No, it is not subjective at all. The protocol is a deterministic, WebAssembly executable over which the network has consensus. The Polkadot protocol includes a governance subsystem to make and enact deterministic changes to itself. There’s nothing vague about it.

The fact that it’s not vague is actually Polkadot’s most powerful attribute. Other blockchain networks have to deal with problems like, “which fork is the ‘main’ chain”; and Polkadot does not precisely because it is a self-describing, deterministic meta-protocol.

I also disagree with you here. We’ve chosen the label “common good chain” for chains that the Polkadot network, through its self-enacting governance protocol, has allocated a lease.

As far as other labels, I don’t see the need to introduce them at the protocol level. For chains that are seeking scheduling either through a full on parachain lease via auction or registering as a parathread for shared execution, they can market/label themselves however they want in order to build their community and get the resources they need to acquire that execution. The auction / scheduling mechanism – like other pure system functions like staking, governance, and balances – is absolutely neutral, and in my opinion must remain so.

1 Like

Maybe I need to rephrase, I’m definitely not suggesting that the protocol is subjective, I’m just disagreeing with the opinion that the label common good parachain should be limited to chains that make up “the protocol”(e.g. wouldn’t this definition leave out Encointer?) is more an invitation to use the label in a more subjective way based on whatever the ideals of the network are at a given point in time. I’m also not suggesting to add new labels for new kinds of chains at protocol level, correct me if I’m wrong but not even CGP exists as a concept in the protocol level? isn’t it just a privileged call to slots.forceLease with an agreed set of parameters that we decide to call that way? So another option could be to stop using the term altogether and evaluate each referenda individually, I might propose a daniel good parachain that includes a batch call asking for funds, a force lease, freezing some funds, giving away some NFTs and a remark with a poop emoji and it will have to be evaluated by the community independently of how I decide to call it.

1 Like

I see. I do think the label was premature, and part of this post was detailing what I’ve learned in the last three years in trying to turn the concept into reality. Certainly my own initial opinions have changed a lot.

I don’t think so, but I can see how it’s on the edge. Encointer’s role of providing one-person-one-vote systems could be valuable to many networks/collectives and seen more on the “utility” end of the spectrum. It’s on Kusama as well, which should be more open to experiments and pushing the boundaries.

No and yes. It is actually a concept in the protocol, there is an IsSystem trait. It’s lightly used, though, and indeed the actual CGP onboarding is a privileged call to force_lease. It might not look pretty, the way that the Treasury usually uses its privileged functions instead of force_transfer, but most root-level operations are force_something.

All the ParaIds under 2000 are reserved for common good chains, which is why all the auctioned chains start at 2000 as the first ID. Under 1000 are even trusted quite highly by the Relay Chain, which is why we have not proposed any common good chains below that (Statemint is 1000). Personally, I would wait until XCM is much more mature before feeling comfortable proposing something like that.


Thanks for sharing this thread @joepetrowski and for comments @olanod.

I’ve updated Substrate ecology to v0.2 with this feedback and on post.

Its becoming clearer where tensions / gaps / definitions are missing - i’ve invented a new term
polkadot protocol (+) which is an attempt at framing chains / projects / functions that are potentially part of the protocol, but not yet definitive in that status, owing to them being in a sort of parachain limbo.

this imo, is the really interesting spot - the gap between protocol (inc definitive CGPs) and Free Market chains, that are not aiming to become CGP and as such part of the core protocol.

One differentiator of CGP to your suggestion is also the TrustedTeleporter status, which is currently hardcoded. This basically means there can be no new GCP without a runtime upgrade AFAIU