Crypto Gloss

Polkadot: Vision for a Heterogeneous Multi-Chain Framework

Author Gavin Wood
Year 2016
Project Polkadot
License note The paper says the protocol specification is under a Creative Commons license, but does not identify the specific license or version.
Primary source Official Polkadot paper repository and source

This page summarizes and analyzes the linked technical paper for educational reference. It is not a verbatim reproduction, and CryptoGloss does not claim authorship of the original work. The linked source remains the authority for what the 2016 paper proposed.

The repository describes this document as Polkadot’s initial technical vision paper. Its version history records early drafts from October 2016 and version 0.1.0 on November 10, 2016. The preface explicitly says it is not a formal specification or final design. That distinction matters: the paper explains the goals and an early architecture, while today’s network and documentation reflect later implementation and governance decisions.

What the paper proposes

Wood’s central idea was to let distinct blockchains keep their own state-transition rules while coordinating security and communication through a Relay Chain. In the paper, these application-specific chains are called parachains. The goal was to support a heterogeneous system: chains could serve different purposes instead of forcing every application into one uniform execution environment. The paper frames shared security and inter-chain communication as core design goals, not as proof that every chain or message is automatically safe.

The paper is best read as a design proposal. It discusses separating the question of which blocks are canonical from whether a parachain state transition is valid, then describes validators, collators, candidate blocks, availability, and message queues as parts of the proposed system. Its own preface warns that mechanisms and parameters could change as the protocol was tested.

How parachains work in the current design

In the present documentation, collators maintain parachain state, arrange transactions into candidate blocks, and provide Proofs of Validity (PoVs). Relay Chain validators check parachain candidates and participate in the relay-chain consensus process. The parachain keeps its own state and execution rules; the Relay Chain coordinates validation and shared security. This is more precise than saying a parachain simply inherits an unspecified number of validators or receives a blanket guarantee against every failure. See the Polkadot Developer Docs’ guide to parachain consensus and validation.

XCMP in the paper and XCM today

The 2016 paper describes an early cross-chain message-passing design often abbreviated XCMP. Current Polkadot materials use XCM, or Cross-Consensus Messaging, for a standardized format that expresses instructions between consensus systems. XCM defines message meaning and structure; it does not itself deliver a message. A transport or channel must carry it, and the receiving system interprets the instructions under its own rules. Calling XCM a transport protocol, or treating the old paper’s XCMP design as identical to the current system, blurs an important distinction. The current XCM guide explains that separation.

Coretime replaced the old slot-auction model

The paper-era economic discussion described bonding DOT for parachain access. Polkadot later used slot auctions and leases, but those are not the current general access mechanism. The Polkadot Wiki says auctions ended with the Agile Coretime runtime upgrade on September 19, 2024. Current documentation describes bulk coretime and on-demand coretime: bulk access is sold for a defined period, while on-demand access is purchased per block in DOT. This changes how teams obtain block-production resources; it does not change the 2016 paper’s historical description. See the auction-to-coretime history and the Agile Coretime technical guide.

Consensus, governance, and DOT

Polkadot’s current Relay Chain uses Nominated Proof of Stake. The current documentation describes BABE for block production and GRANDPA for finality; they perform different jobs in the consensus design. The paper’s early discussion of validators and nominators is useful background, but it should not be treated as a complete account of today’s protocol. The consensus documentation describes the current roles.

The paper also anticipated on-chain governance, but its proposed institutional structure is historical. Polkadot’s current governance model is OpenGov, which replaced Governance V1 structures such as the Council and Technical Committee. DOT has roles in staking and governance, and current coretime purchases are denominated in DOT; the old paper’s bonding-and-lease description should not be presented as the current slot-allocation process. See the OpenGov overview.

What this paper does not establish

This early vision paper does not document the present software release, current coretime market, current governance tracks, or the complete behavior of XCM transports. It also does not establish real-world adoption or guarantee that applications on different chains will be secure, compatible, or easy to use. For current implementation details, consult the maintained Polkadot developer documentation alongside the original paper.

Social Media Sentiment

One recent discussion in r/Polkadot asked whether coretime and shared security could support lasting use cases. Some commenters emphasized the potential of parachain projects and interoperability; others argued that technical capacity needs to translate into applications people actually use and a smoother user experience. This is a small set of opinions in one thread, not a representative survey or evidence of network adoption. Read the discussion.

Last updated: 2026-10

Related Terms

See Also

Sources