Polkadot is a high profile project set to launch its mainnet by the end of 2019, in the midst of an onslaught of new projects taking off or growing around the same time (Blockstack, ETH 2.0, Dfinity, NEAR, AVA, Spacemesh, Hashgraph, Libra, et al. give or take a year). Recently, Web3 Foundation released Kusama Network which is an experimental network aimed to act as the proving ground for most attributes of Polkadot including governance, staking and even deploying a parachain. Kusama is set to launch this Summer.
Polkadot is marketed as an interoperability platform (let blockchains communicate) but in reality it’s also a platform to host blockchains, smart contracts and a myriad of other use cases.
Since Polkadot is an interoperability platform the positive view is the project will allow blockchains to interoperate and grow the entire pie and ecosystem for everyone. The negative view is Polkadot parades as an interoperability platform, absorbs projects from other chains and canabalizes growth on other platforms for its own gain. In reality the market will land somewhere in the middle, with intense public competition where projects may overlap.
Polkadot is a next-gen project with an incredible team and intense brainpower driving it. The description of Polkadot is a network of interconnected blockchain networks: a main relay chain interconnects parachains and the entire network benefits from a shared security model. I commend the team for their advances and I have no doubt the project will unlock a new design space and opportunities that will catch us all by surprise. There is clear value in allowing parachains built on the Polkadot to be fully customizable (set consensus, fees, block-times, governance, block-sizes, etc.) to address a variety of use cases.
Regardless, it is our job to stay skeptical and ask questions to provide clarity and better the community. I offer this post in the best light to advance the discussion around the project.
In this post, I want to focus on some of the more interesting aspects of Polkadot that I thought warranted further discussion. I spend a lot of time following the developers as I believe attracting them is critical to any platform’s success.
A Rocky History
Growing restless with the slow decision making of the Ethereum community and wanting a sharded blockchain, Gavin Wood decided to develop Polkadot years ago while at the same time building Parity. The project has come a long way, with a testnet live, Substrate (a blockchain development framework) making it easy to create blockchains and apps very easily with 29 projects building using substrate already and even more to come. Parity also released Kusama. Polkadot is a central piece in building the Web 3.0: a user-owned internet.
A key benefit of Polkadot is allowing developers to launch chains and applications leveraging its shared security model, without having to worry about attracting enough miners or validators to secure their own chains. This can drive experimentation, but we note Polkadot will have to first attract a global base of validators but this is likely achievable given DOT holders will be eager to obtain rewards by securing the network.
Polkadot also allows developers to create cross-chain and cross-parachain applications and use cases. Polkadot aims to offer 1,000 txs/sec and this can be multiplied when multiple parachains are leveraged for scaling. We note the implementation of cross-parachain communications is not completed at this time (it isn’t on Ethereum either), there appears to be an MVP, and to my knowledge it’s not clear if the main relay chain itself can coordinate and validate hundreds of chains, each with 1,000 txs yet.
Substrate also sets Polkadot apart; the framework offers the ability to write a blockchain in any language that compiles to WebAssembly (Rust, C/C++, C#, Go) so you don’t have to learn Solidity or Michelson.
Despite its results; Parity (Polkadot’s parent) has had a rocky history;
- A bug in Parity’s Ethereum multi-sig wallet locked away $150M of their ICO funds
- The tumultuous history to free these frozen funds (changing Ethereum’s blockchain would be very contentious)
- The lead release manager for Ethereum, a Parity employee (Parity championing Polkadot is a clear conflict of interest) leaving Ethereum to start a mysterious project that is marketed as Ethereum on Polkadot.
- The turmoil over Aragon, an Ethereum focused project using its treasury funds to purchase DOTs to diversify its treasury, with the read through being these would likely be used to secure a parachain.
At the end of the day, problems usually harden a community and attract attention. Some projects’ largest problem is they have never had a problem.
Smart Contract War and Developer Attraction
In late 2018 I argued Polkadot was competing with every smart contract platform (Ethereum, Tezos, and their futuristic friends launching soon), and I believe this is becoming clearer. Add onto this Substrate (easily deploy blockchains/apps on Polkadot) and Cumulus (makes it easy to make any substrate runtime into a Polkadot compatible parachain), and its very clear Polkadot is in the ring.
Polkadot’s more recent materials describe two ways for developers to launch their applications: as a smart contract on an existing parachain (leverage Edgeware) or as its own parachain. The former offers faster deployment with less functionality, while launching one’s own parachain allows for max customization (set inflation policies, a treasury, governance, custom fees) while leveraging the shared security of the Polkadot platform.
In the land of smart contract platforms (just like with mobile operating systems — Android and iOS or the cloud — AWS and Azure), whoever attracts the most developers wins, since these developers can endlessly experiment to find the next killer use cases. With Polkadot; there are three main hurdles for adopting developers;
- To launch your application “on” existing parachains the functionality on existing parachains must be present (chicken-and-the-egg issue). Example; you cant launch DeFi Saver as a smart contract if there isn’t a parachain on polkadot that is a decentralized exchange (DeFi Saver uses Uniswap)— unless you interoperate outside of Polkadot, but that drives network effects away from Polkadot and introduces additional complexities for developers.
- To launch as a parachain developers have to have enough money to do so, while taking on the volatility risk in purchasing DOT tokens, thus boxing out all potential experimentation that requires a launching a standalone parachain for those projects which can’t afford the lease. Uniswap, a popular Ethereum app, was created by its founder who was messing around for two months, and he didn’t have to deploy capital to secure a parachain. However, Polkadot will support crowdfunding for parachains that have garnered support from stakeholders.
- The governance effects of DOT tokens are not completely clear. If token holders can allow or prevent someone in deploying a parachain, outside of the actual auction process of securing one, this could limit experimentation.
While I raise these concerns as I believe they impede the limitless experimentation that could happen on Polkadot which is central to its success, there are two remedies that may help.
First, it makes sense that applications deployed as smart contracts or in a piecemeal nature could interoperate with other chains for the functionality they need (leverage Kyber on Ethereum as a DEX), but this could drive network effects to split, or to the most used chain. In theory this may not occur due to the use of bridges, users of a DApp on another blockchain can gain users that need their services on Polkadot or parachains could copy the state of other chains and bridge new transactions if the community wants this capability, but these both offer technical considerations. Developers would also have to decide why they would want to leverage Polkadot in the first place instead of building their app on one chain, but I understand Polkadot unlocks a new design space.
Second, it may not be that expensive to lease a parachain, but this is still a hurdle. For illustrative purposes, lets walk through an example. If we assume 100 parachains, a 10M DOT supply, and various DOT prices (top axis of the below table) and varying levels of DOTs locked in parachains (all DOTs can’t be locked up as you need them for other uses — transactions, bonding, etc), per my illustrative model below it may cost between $1M and $28M to secure a parachain, on average, although prices will likely increase if supply runs low due to the auction nature of securing a parachain. This is obviously a simplistic model and pricing will vary widely based on the above factors, but it offers an view into the potential dynamics of parachain pricing.
The other wrench is it’s unlikely the percent of DOTs locked in parachains will ever be high (>50%) given a large percent are needed for staking to secure the network and some percent of DOTs are needed to transact with on the network. Thus, the percent of DOTs locked in parachains may be lower, but the price per DOT higher due to demand, boxing out potential projects.
I still believe $1M — $28M could be a lot for developers if they need the full functionality of a parachain, creating a hurdle for developers to actually lease them. One may argue only legit projects with funding should have parachains, but how can we judge which are successful if they can’t afford the parachain to experiment with in the first place?
While the above raises a serious concern, there are three potential mitigants for the community to explore; launch on Kusama, launch a Substrate “solo” chain and bridge to Polkadot, launch on an existing smart contract parachain.
Some other mitigants could be for Polkadot to launch with support for more parachains (goal is 1000+, but this is a multi-year process) to reduce costs, potentially allow projects to share the cost of parachains (this could be socially and technically complex), or have Polkadot more aggressively subsidize parachains for teams in the early days beyond the few they have set as common good parachains (smart contracting parachains and bridges to other blockchains). Another idea is to start a project on an existing parachain, like Edgeware to prove its viability before raising funds to lease a parachain.
Since every DOT holder will be airdropped an equal amount of KSM tokens (Kusama’s native token), developers should be able to quasi-test economic conditions and hopefully optimize Polkadot before it launches.
Cautious on Parachain Slots
Polkadot plans to launch with a finite number of parachains (5–10 at first and slowly increasing to 100 over the following 18 months) so that there is a cap on computational overhead and a competitive market for parachain slots is created. This is correlated with the number of validators on the platform which will likely be around 50–100 and scale to 1,000 over the 18 months. Anyone can lease a slot and if they win at auction and the winner is free to use the parachain as they wish, unless it’s deemed malicious by Polkadot’s governance system.
My main concern is the 2 year limit on parachains; broken into 4 periods each spanning 6 months. Think of a popular use case or application built on a parachain that gets axed because it doesn’t have just enough money to secure its future — this can have negative consequences and externalities all the way up the ecosystem stack on all of the potential projects that are not launched.
When a parachain’s term is ending a project can
- Hold a referendum on the relay chain to include a parachain indefinitely. I believe the bar for this would be very high.
- Continue to stake DOTs, bid in the auction process, and hope you have more than the next bidder
- Users migrate to another parachain
- Fundraise, (initial parachain offering) to secure funds for the bidding process
- End your lease, migrate to your own chain to be secured on its own, move to another, or shut the project down.
While I believe this is a novel curation approach to open the parachain leasing process up to the world, the term lengths introduce a serious concern.
Say Parachain X, which is a viral stablecoin application loses its slot on Polkadot. The viral use case powered by that stablecoin is now lost, (this could be substantial in funds), and the network effects to the other composability building blocks (DEX, Prediction markets, etc.) which also require this stablecoin lose since the application they are powering fails.
This is of course hypothetical; if a stablecoin was that successful it might not face this issue, but remember, no matter how successful a parachain will always be seeking funding in order to pay for its slot. Net, I believe Polkadot should explore longer terms for parachains beyond 2-years so that teams can focus on building instead of having to focus on campaigning for reelection cycles.
Further, parachains are meant for pieces of legitimate infrastructure (think DEXs and prediction markets now) so the 2 year limit makes this more worrisome since these pieces of infrastructure will be powering all of the applications built on top of them, as long as they maintain their lease.
These building blocks simply exist on Ethereum and their safety is defined solely by the protocol’s operation: not the exogenous force of losing a parachain slot. On Polkadot (and Ethereum) this is a base security issue, but Polkadot has the added issue and cost of projects having to also secure a parachain.
Voting on Polkadot Could Face Hurdles
Polkadot offers an innovative approach to crypto governance; on-chain voting by token holders with a token holder elected council to make sure progress occurs in the case of tough decisions or low turnouts. Adaptive quorums are in place to keep thresholds flexible on passing changes based on high or low turnouts. I think its an innovative approach and commend the team for pushing the bounds here.
A major concern in crypto communities is centralized power; where minority holders get voted out or have no say. While Polkadot’s makeup of whales vs small holders is unclear since it hasn’t launched, I think the system does favor minority holders in a sense, while enabling progress. Lets take an example.
Polkadot allows holders to time-lock their DOTs over longer periods of time for correspondingly higher voting power (4, 8, 16, 32, 64 weeks for 1x, 2x, 3x, 4x, 5x vote power). If we assume 70% of DOT holders comprise minority holders and 30% major holders in Polkadot (an illustrative example, given a similar dynamic exists in Ethereum), in most cases minority holders will overpower majority holders — granted this is based on a hypothetical 70/30 breakdown and assuming all DOTs are being voted (this is irrelevant since the percent staked would impact both tranches by the same amount).
Assuming minority holders comprise 70% of votes, and majority 30%, we can run through a few scenarios on voting power. Obviously, if each group locks for the same periods, minority voters will always overpower majority holders given the percentages.
Now lets look at opposite locking periods for each group — i.e. when minority holders are 5x locking period, majority is 1x and vice versa. In every situation, minority holders overpower majority holders outside of the last scenario where all majority holders 5x their lockup while all minority holders 1x theirs, but this is unlikely to happen.
At first, this gives credit on Polkadot that minority holders have power in the system, but this contends with the factor that majority holders could lock up their tokens for the max lock-up period (shown in scenario 5) and override other token holders, assuming the earlier percentage breakdowns. This entire system is further complicated by vote buying (darkDAO issues, whales (Aragon example), and the coordination issues of smaller holders moving the spectrum majority holders need to control the network to a lower threshold.
On the other hand, on-chain governance in Polkadot (the formalization of the governance process in my opinion) could address signaling and organizational issues faced by off-chain systems like Ethereum (what upgrades does the community want), but comes with potential bribing (vote my way for a fee) and plutocracy issues (richest people vote one way).
The other take here is that minority holders face the coordination issue (getting a massive number of parties to all lock for the same time and to vote the same way) this is an issue not faced by smaller groups that hold large percentages. Take an extreme example: If a group of whales hold only 5% of DOTs and lock for the max period to obtain 5x power, and every other holder locks for 2x (below mid-point, but assuming majority locks for lower periods of time, or doesn’t vote at all), this group of whales would more than 2x its diluted voting power to 12%. It may seem like an extreme example, but incremental power over a major system where many DOT holders may not even vote goes a long way (real example, especially in cases of split decisions).
More on Governance: Polkadot’s Council
Polkadot’s council of 6–24 people (could be less or more over time) could be a centralization risk for the entire network. The council has the ability to
- Veto incoming proposals (these can be resubmitted, and the council member who vetoed can not veto again)
- Gain prioritized voting rights over the network
- A proposal that is unanimously voted in favor by the council benefits from negative bias; a supermajority of nay votes is needed to reject the decision (i.e. potentially the entire popular DOT vote has to come out to negate unanimous council decisions).
Even if there was a contentious decision, the goal of Polkadot’s adaptive quorums (higher vote thresholds when less DOT holders vote and vice versa) should be to handle low voter turnout, not a council that renders them useless and the governance value of their DOTs less valuable.
There are are some centralization brakes in place for the council to the benefit of token holders:
- Council is elected by DOT holders
- The council changes over time due to elections (elections every two weeks but monthly is more likely and term length equals two weeks times the number of council members. This could introduce voter apathy if the elections are too frequent).
- Loss weighted voting favors runners up in future election periods.
- Delayed enactment of any decisions so DOT holders can leave if an unpopular decision is put in place (but those who lock up their DOTs can not leave, disincentivizing long lock-up times and more voting power for DOT holders)
On EOS, the main 21 block producers have to actively communicate to keep its blacklist up to date, or the list of hacked accounts these block producers freeze. While this communication appears beneficial to protect users, it is a massive form of active communication and centralization between block-producers. While Polkadot has terms for its council to drive turnover of council members, at any given point in time there is nothing stopping these council members from colluding. Polkadot may also suffer from the signaling of the centralized council (the President voted this way, so as a DOT holder I should vote this way too — a similar issue could be present in off-chain systems).
One way to potentially help mitigate issues could be to tweak the multiple voting rounds in Polkadot to push forward a change. It would make sense if the length in-between multiple voting rounds were long enough to be voted on by two somewhat different councils to reduce the power of the council at the time. Also, this could make upgrades less frequent so the community has time to review them. The issue the community must explore is if this change could make it too long for changes to be enacted since council turnover could take months or years.
Net, I think the council does more harm than good (centralization risks, disenfranchising DOT holders) and will be an ingrained point of contention for the life of Polkadot. My take is stakeholders in polkadot will be more dissatisfied if a centralized council pushes unpopular decisions more than they will be happy that a council can ensure progress happens since the former is felt in the chest.
Economic Value of Governance Value Is Unclear
Its impossible to place a value on the governance properties of a token. In my mind it should be non-zero since the tokens themselves have power over the network, but I think the real value of token-governance (on-chain governance) comes from the potential to better coordinate and organize stakeholders to advance the platform. Polkadot could potentially benefit from this if it avoids bribing/plutocracy issues.
MakerDAO is a popular lending platform whose token MKR, has built in governance rights (voting on stability fee changes to ensure its stablecoin DAI to $1), along with quasi DCF rights as MKR is burned over time. The platform has had many governance events in changing the stability fee.
If governance rights have value on MKR, the results are mixed. The average immediate price change for MKR token, one day after the vote vs one day prior, is on average only 1.1% higher.
Hence, governance rights are not driving MKR’s price higher (buyers entering to purchase MKR for rights), or they are buying and selling after the event, or they just don’t care.
Granted, this is only one data point; and it is murky since the price of DAI takes time to adjust and MKR may react positively after the fact if a governance vote helps drive a positive change in DAI — but net the voting aspect isn't driving demand for MKR. Net, I think it’s unclear to assign any specific economic value to DOTs in a governance aspect, beyond the value of faster coordination around upgrades which could drive a faster evolution process, and value for the overall network. The positive is that unlike many other tokens, DOTs have use cases in Polkadot and are not strictly governance tokens.
Zooming out; we need to track where the developers are headed. If throughput itself was the deciding factor, Ethereum’s developers would have moved to EOS (higher scale, low decentralization) or AWS, but they haven’t. This argument is also being eroded as the dozen of Ethereum Layer-2 scaling solutions grow, ETH 2.0 is driving towards sharding, Bitcoin’s lightning Network grows — to name a few. Attracting developers goes beyond throughput.
Polkadot offers an new ecosystem for developers, especially in regards to governance, parachain leasing dynamics and in offering a new design space, so people should take it very seriously. Despite this; I think Polkadot has outstanding questions that may impede developer adoption, especially with regard to governance.
Expect changes as we approach the Web 3 summit, and eventually as Polkadot evolves and grows which, while I have my concerns, could offer a completely new Polkadot as changes are enacted. The launch of Kusama this summer allows the community to test out most issues and concerns which could drive changes to the main version of Polkadot before it launches.
Polkadot’s wording, shown below, for the Kusama release leads me to believe that “chaos” is a hedge and potential issues will be a driver leading to changes in the eventual live Polkadot network. This isn’t a bad thing as lets developers test their wildest ideas before the main Polkadot network launches, and for Polkadot to make changes or optimize before it launches.
Follow me on Twitter
Disclosures: Disclosures: This post is strictly informational and educational and is not investment advice or a solicitation to buy or sell any tokens or securities or to make any financial decisions. Do not trade or invest in any project, tokens, or securities based upon this podcast episode. Tom currently owns tokens in ETH, BTC, XTZ, LEO, DCR, VRA and STX.
Delphi Digital: Delphi Digital is an independent research boutique providing institutional-grade analysis on the digital asset market.