Thank you for taking the Dot Leap!
We cover Polkadot, Kusama, Polkadot-SDK, and all related Web 3.0 projects! Want your content featured? X marks the spot! Alternatively, submit links via telegram.
If you feel like some links are missing or we made a mistake, please tell us! Note that announcements of “coming soon” features and launches, as well as “partnerships” will no longer be featured in Dot Leap.
Video versions of all Dot Leap editions will be posted on our Youtube channel.
Fixing Governance
I talk about this a lot, but I link to various articles when asked so I thought I'd put it all together in one place: problem statement, current attempts at solving it, and my proposal / wish. Let's dive into the problems of on chain governance, by expanding on my original tweet from a while back.
Let's talk governance.
There are 3 main types of blockchain project governance:
1. Nogov - this is what Ethereum has.
2. Unenforceable token voting - this is what @SnapshotLabs is.
3. Auto-enforceable token voting - this is what @Polkadot does with @substrate_io.
There are 3 main types of blockchain project governance:
1. Nogov - this is what Ethereum has.
2. Unenforceable token voting - this is what @SnapshotLabs is.
3. Auto-enforceable token voting - this is what @Polkadot does with @substrate_io.
174
The problem
There are essentially three governance types and two execution types.
Governance type one is Nogov, what Bitcoin and Ethereum have in theory. No one is calling the shots and it's all decentralized. Merges to network clients happen based on merit and discussions in forum, and the network evolves through common sense. In practice, nogov often becomes lobbying, personal attacks, and is largely funded by a single actor for whom the community must hope they have the best interest of the network at heart. Ethereum is a positive example, nogov worked out so far. Bitcoin is a negative one, as the network's development is completely captured by the status quo proponents who specialize in selling the workarounds for the problems they cause (aka the Shirky principle).
Type two is Autocracy or Oligarchy, where a single person or a cabal have full control over the direction of a chain. This is all the L2s, L3s, L10s..., dapps, and consumer facing things in web3, but also in reality oligarchy is to a large degree what Bitcoin and Ethereum are, just without being explicit about it.
Plutocracy is the third type of governance, where token-voting decides everything. A decision is put forward and people vote with however many tokens they have. The majority wins. This type of governance is also sometimes attempted in other systems in order to "include" the community, but due to token distributions in blockchain teams, it's more often a case of ants on the back of an elephant trying to tell it where to go.
The argument for plutocracy is an understandable one - the one with the most stake in an ecosystem should have the most decision power about the ecosystem. The assumption that this person got to the status they're at because of good economic choices in their life is, in most cases, legitimate. Yes, web3 is incestuous and yes, mostly it's the same cabal of 100 people or so getting early or premine allocations because they originally got lucky, but by this point most of those people have learned how to juggle things well and they legitimately want their bags to do well, so they will do their best to make rational choices. This definitely exceeds the expertise of armchair quarterbacking shrimps who think they know best but have never made a meaningful or brave decision in their life, let alone built or founded something.
Naturally there's a spectrum, and mixes happen. Polkadot, for example, is a mix of Plutocracy and Oligarchy, there the Fellowship decides on everything and is the main driver behind the network's changes, but these changes are still put up for vote in OpenGov, the network's governance system. This is where plutocracy kicks in to actually enforce the change.
So these are the main types of governance. Execution-wise, we have only two options: a change is either optional or auto-enforced.
In almost all ecosystems except Polkadot, the outcome of a vote - be it dEmOcRaTiC (forums), plutocratic (snapshot vote), or oligarchic (discord?) - is optional. The implementing team can just say "no, we're not going to do that". The vote is, in other words, non-binding.
Enforceable execution is when a change - once voted in - is inevitable. It's what Polkadot uses. When a new runtime is compiled with the chain changes, or when a parameter change is voted in, it will happen at the specified block no matter what - unless another proposal is voted on to cancel the pending proposal, which is again subject to on-chain governance and auto-execution (the cancelation is automated). This is probably the biggest leap in on-chain governance since the whole blockchain era started, and I wish we saw more auto-enforced decisions around the other ecos.
But auto-enforcing chain-level changes in a plutocratic system can be dangerous. All it takes is a powerful enough whale or autocrat and good timing to literally rug the entire chain by changing balances, modifying the staking process to benefit them, or even introduce hostile changes via a secret rider bill in a bigger runtime change.
Current Solutions
No one has attempted to fix oligarchies (impossible by definition) and there's nothing to do in Nogov (other than coinvoting, which historically had mixed results).
To make plutocratic governance less dangerous and more effective, three main methods were attempted: delegation, turnout biased voting, and opengov.
Delegation is when "shrimps" can delegate their votes to representatives who then use their voting power for them. This is the method the W3F uses to try and fight Giotto and so far it has had some positive results. Delegation is a band-aid on a gunshot wound. Plutocracy is inevitably a system trending towards failure (autocracy), and delegation can only slow it down a bit. Many apps, protocols, and chains use delegation but I suspect these systems will all fail more rapidly once the total crypto user market exceeds the current 30000 users.
Alongside delegation, Polkadot originally introduced Adaptive Quorum Bias where how many people show up to vote (i.e. how many tokens of the total supply) directs how much of a majority is needed for a proposal to pass or fail. This was an excellent upgrade to simple Delegation + Plutocracy in my opinion, as it encouraged more aggressive delegation and aggressive participation: important system-level proposals were fail-by-default and needed a majority to pass, and treasury proposals were pass-by-default and needed a majority to fail. This majority approached 50.1% the more tokens voted. This meant a single whale couldn't easily push a proposal through because he would not have the supermajority on his own.
The next stage of governance evolution - OpenGov - was to divide the entire voting process into different tracks - for treasury, tipping, system (root), and more. Each has its own settings for how much turnout and majority it needs, each has its own settings on who can vote, each has its own voting duration and confirmation period. Turnout bias still applies, but in a slightly different way - there is a minimum of "support" required on each track (turnout) but votes can be Aye, Nay, or Abstain to raise this support, and the majority required to pass a proposal drops over time. If the state of a proposal stays in the goldilocks zone above needed support and within necessary Aye for a period of time, it enters confirmation and gets enacted.
But at its core, OpenGov is still plutocratic and so we get into situations like the one above where a famous ecosystem grifter is asking for 10m from the treasury to drop a shitcoin. Why is this likely to pass? Because the push comes from deep insiders, people who essentially own Polkadot.
Now, is this bad? Not necessarily. I will be the first to admit I suck at making money and marketing, and if I had boarded any of the hype trains in crypto so far, I would have been long retired (helloooo AI+blockchain appchain on Polygon CDK connected to LayerZero and restaking LSTs for seasonal points?). It is extremely likely that these people know what they are doing and will, in the worst case scenario, make themselves a lot of money. In the best case scenario, they will make everyone a lot of money. But is it JUST? No.
So, here we come to my proposal on how to really fix plutocratic governance: by annihilating it. This is a technically intense change (no more than OpenGov, however), and it turns all current governance on its head by completely and totally decoupling monetary power from voting power. Enter GDCM: Gamified Decaying Categorial Meritocracy.
Gamified Decaying Categorial Meritocracy (GDCM)
The foundation is in place - OpenGov tracks. This is a really good baseline. Different decisions need different passing difficulty, have different security and trust implications, and different types of expertise. The granularity is a really good move.
Unfortunately, OpenGov does not value expertise right now, and prioritizes monetary power over domain knowledge. This is where GDCM comes into play.
First, every willing participant of the governance process registers an identity on chain. This can be the People chain, or it can be something like ENS elsewhere. Upon registration, a user is given a modular NFT which can take any visual form. Let's assume, for the sake of this post, that it's a stained glass window.
The window has slots, missing panes.
All users start at Merit Level 0 in all categories and tracks. Exceptionally, some can be granted a non-zero level from the get-go, indicating their active role in the initial shaping of the ecosystem.
Merit is specific to each category (hence, Categorial Merit).
As each participant votes in a given track, their merit grows. As they reach certain milestones, they can get equippable modular NFTs with which to decorate their stained glass window. Some of these would be transferable, ergo, digital swag that users can trade between each other and "pimp out" their windows and earn extra income through a global user economy, while others would be Soulbound 2.0 and stuck to the user's NFT (but still equippable or unequippable for modifiable visuals). Hence Gamified.
As the categorial merit of each user grows, their vote power grows with it. The more you participate in a category, the more voting power you have in it.
Every voting member can also judge the actions of every other member, and in a Community Notes style of consensus-through-polarity, anyone judged to have acted maliciously by generally otherwise disagreeing parties can have his merit forcibly reduced.
As users miss out on voting opportunities, i.e. they do not vote with Aye, Nay, or Abstain, and proposals pass them by, their merit will Decay. This is the most important part. By making sure the users need to stay active to keep their voting power, we solve two really important problems: first mover advantage, and fresh blood.
In governance, it is not uncommon for the entire protocol to become captured by whoever had the most tokens first. Look at Nouns - completely under the control of two people. This first mover advantage is impossible to catch up to - especially in rich-get-richer systems like Proof of Stake where it is impossible for a small fish to catch up to a bigger one. By introducing Decay and relying on the certainty of humans getting tired of whatever they feel passionate about over time, we ensure that these first movers are automatically cleared out or made less relevant, rather than remaining gods indefinitely.
Fresh blood therefore follows. Because of the first mover advantage, there is often very little reason for the smaller holders to join and try to participate. The whispers of these ants simply get ignored in a room of trumpeting elephants. But if we gradually erode the power of inactive merit whales, we automatically make room for fresh blood which can now trivially catch up to - and even exceed - the power of the first movers.
This keeps the protocol alive, forever. Even if the founder leaves, new people will join and lead by example, by merit, by passion. New careers can be built, new pivots can be voted in. All on chain, all self-enforcing auto-execution, all based on gamified merit rather than money.
There are, of course, many elephants in this tiny room.
For one, it would be necessary to pay these users due to the overwhelming amount of time they would have to dedicate to this activity. Thus, an on-chain grant would probably be necessary to finance this. Luckily, there is more than one precedent. Secondly, griefing prevention would be required. While it is possible to limit the number of malicious accounts by enforcing higher "register for governance" deposits, a rich player could still in theory disrupt the process. Lastly, merit through activity alone is not true merit, and the judicial aspect of judging votes would be a necessary corrective measure which is yet to be discussed and simulated to a productive degree, and is currently only theoretical (though work is underway to simulate this at scale - stay tuned).
Outro
Maybe I am overthinking it. Maybe the secret really is just in getting more users and the development nightmare that GDCM is would be overkill.
Maybe if we just got those mythical millions to use tools like Syncra (see dogfooding below), we'd get some progress and balanced outcomes. But... it's more likely that things would start to resemble the current system of democracy. And you know what they say about democracy...
Where are you in the governance debate? Do you even care? Why?
Polkadot and Kusama Updates
Polkadot's Runtime upgrade to v1.1.3 has executed effortlessly. Same for Kusama.
An incredible Polkadot 2.0 breakdown by Alice und Bob.
Agile Coretime coming to Kusama any second now.
Development
Parity's comprehensive development update for March covers all the past month's changes. Some of the most notable ones:
Polkadot’s Asset Hub now has native asset conversion. Crucially, XCM fees can be paid in other assets 💰
Kusama’s “People chain” is merged and ready for launch.
light client interface revamped to be easier to use.
Sidecar's v18.0.0 release allows to decode any kind of XCM message when querying blocks of any chain.
WARGAME - PARATHREAT: This game objective is to help people to identify and fix security vulnerabilities in parachains, pallets, and nodes within the Polkadot SDK. During that journey you will play the Red and then the Blue team.
Cargo Contract's PR 1290 introduces an additional flag --chain that allows you conveniently choose which production chain to deploy a contract to instead of specifying the endpoint URL. Currently, there are endpoints for Aleph Zero, Astar and Shiden according to the list of production chains on the contracts UI. This makes getting started with ink production deployments a lot easier.
Governance
Proposal 590 to remove max pool and max member limits has passed but execution failed.
Proposal 593 to fund system chains sovereign accounts on Polkadot BridgeHub for the Polkadot<>Kusama bridge is passing easily.
Proposal 594 to open a channel between Asset Hub and the Mythos meme chain is passing.
Referendum 487 for revamping the ambassador program passed. Now, things get complicated.
A new interesting governance watchdog program by Paranodes and Saxemberg.
Dogfood of the Day
In this episode, we test Syncra, a DAO creation and usage UI for Substrate chains.
Play Video
⛓ Connected Parachains, dApps, and others
OG Tracker is a tool that tracks deliverables and the ongoing progress of approved OpenGov proposals.
Polkadot Multisig, the open community version of Signet for the ecosystem.
Evrloot's automatic on-chain missions for your passive gaming pleasure.
Spacewalk Bridge is allegedly live, allegedly allowing transfers of Stellar's stablecoins and XLM into Polkadot's "thriving" DeFi ecosystem and back.
Tanssi raises money, attracts attention. Will the chain-as-a-service model work in a world of thriving dappchains, or has the ship sailed with Polkadot being 3 years too early to this model?
Time-triggered cross-chain workflows triggered by Bagpipes and Oak in a no-code workflow builder.
Subconnect by Subwallet - Substrate's answer to WalletConnect.
🌎 Community & Ecosystem
Polkadot's new main character, Giotto. A good X thread breakdown.
Dune's Decentralized Voices dashboard, covering voting power and effect on proposals of these new whales. A nice thread on current insights by Bill Laboon.
Bill Laboon on Crypto Hipster podcast talking about DAOs, DOTs, and the Future of Web3.
Space Monkeys and the Future of Polkadot with Shawn Tabrizi.
Play Video Polkadot Roundup and Polkadot Digest cover ecosystem/dapp and core/infra respectively. Soon, they should replace a big chunk of Dot Leap
Substrate Gaming Organization, which to date has shipped one game, added another chain to a list of .NET SDKs - this time it's Zeitgeist. It is unclear how this is related to gaming, or who is supposed to maintain all these packages as the metadata updates after runtime changes inevitably break them.
How to transfer DED from Polkadot Asset Hub to Hydra DX with SubWallet browser extension.
🔧 Tools and Releases
Subxt 0.35 and 0.35.1 are out. Some small fixes, added no_std support to a couple of crates (subxt-signer and subxt-metadata) and introduces a few quality of life improvements.
Substrate API Sidecar v18 with breaking changes around decoding XCM messages.
Asset Transfer API Registry 0.2.15 with minor fixes, nothing notable.
NFT Review
NFT Review will be closing down in April.
Games and NFT developments in all ecosystems except Polkadot, which seems to be in carcass mode with vultures looking to take bigger and bigger bites out of it, while delivering nothing.
Read more in the online edition.
🗣 Incentivized Feedback
Leave feedback on this edition on X, here on Paragraph, or by hitting reply if you're reading this in your inbox, and you get 5 $LEAP. Your message must also contain your address which has a verified identity record on Polkadot.
That's it for this week - I hope this was as useful for you to read as it was for us to write!
Many thanks to Bill Laboon for his daily digest which helps us not miss some important updates!
DotLeap is put together by Bruno Škvorc.
Got any links for the next edition? Reach out on X, or via email at editor@dotleap.com. or through our ingestion bot on Telegram.
