Layer 1 blockchain
Polkadot ticker DOT
Summary
Nominated proof of stake: DOT holders nominate validators and an election picks the active set. On the relay chain, BABE gives validators roughly 6-second slots through a private lottery, and GRANDPA validators vote to finalize whole chains at once. Parachains, including Polkadot Hub where balances now live, have their own collators that build blocks; relay-chain validators assigned to a core re-execute and back each block, spread erasure-coded pieces so it stays available, and randomly selected approval checkers re-check it before GRANDPA finalizes it. Time on cores is sold as coretime. SASSAFRAS, a proposed successor to BABE, is specified in a Fellowship RFC but was not found deployed. 1231718202229
Design
- System
- Layer 1 blockchainPolkadot is a multi-chain system, not one ledger. This profile treats the relay chain and its system chains (Polkadot Hub, Bridge Hub, People, Coretime, Collectives, Bulletin) as one layer-one network: relay-chain validators produce, check and finalize blocks, and since November 2025 balances, staking and governance live on Polkadot Hub, a system parachain those validators secure. The docs call the relay chain layer-0. Independent parachains are separate chains. The package class is kept.
- Settlement family
- Its own design
- Scarce resource
- Stake (proof of stake)
- State model
- Accounts
- Finality
- Economic finality
- Who makes blocks
- Relay-chain blocks come from the elected active validators; BABE assigns slots by a VRF lottery, with fallback secondary slots so none go empty. The election now runs on Polkadot Hub, and since Referendum 1890 (executed 2026-06-12) validators need at least 10,000 DOT of their own stake. Parachain blocks come from each chain's collators, which propose but do not secure; validity comes from relay-chain validators.
- Fork choice
- Before finality, BABE builds on the fork with the most primary (lottery-won) blocks, so short forks can appear and resolve. Approval checking keeps unapproved parachain blocks out of finalized chains, and GRANDPA finalizes a chain once more than two thirds of validators vote for it; the docs say finalized blocks are irreversible. The wiki says GRANDPA needs two thirds of validators honest under partial synchrony.
Qualifications
- System scope · Partial. Cells cover the relay chain and Polkadot's system chains. Independent parachains such as Hydration share Polkadot validation but have their own collators, tokens, fees and governance, and do not inherit these cells.
- Scaling family · Contested. Parachains are filed with rollups because they execute elsewhere and rely on relay-chain validators for validity, availability and finality. Readers who reserve that label for chains that post proofs or data to a contract on another layer one would call them shared-security chains instead.
- Finality · Applies. The finality cell reflects GRANDPA: reverting a finalized block would require validators to equivocate, which is slashable. Relay-chain blocks that are produced but not yet finalized can still be reorganized.
- Block time · Partial. The relay chain uses roughly 6-second slots; Polkadot Hub has targeted 2-second blocks since the 2.0.5 upgrade (January 2026), and other parachains vary. Any block-level figure must name the chain it describes.
- Throughput · Unknown. No throughput figure is recorded. The docs give parachain block-time targets for chains using more cores; those are latency design goals, not measured capacity.
- Jam transition · Not applicable. Parity's September 2026 plan would move parachain validation to a JAM service and leave the relay chain with no DOT and no user transactions. None of it was live on 2026-09-27; these cells describe the current system.
- Settlement family · Partial. Recorded as other: Polkadot runs its own relay chain, with BABE block production, GRANDPA finality and nominated proof of stake, and system chains and parachains validated by relay-chain validators.
Tradeoffs
- Emphasizes
- Security and Scalability
- Gives up
- Breadth of consensus participation and simplicity. Security is pooled in one bounded validator set (the wiki lists 600 active validators) that must post 10,000 DOT of self-stake and run 8-core, 32 GB, 500 Mbit/s symmetric machines, and every parachain depends on that set staying live. Forkless runtime upgrades by on-chain vote also mean core rules can change quickly.Forum participants have questioned how many independent operators stand behind the active set. One participant grouped validators by on-chain identity and later by shared proxy control and argued that four or fewer operators could reach a third of bonded stake; another participant disputed the method, and neither figure was reproduced here. Parity's staking plan proposes sizing the active set to demand. Each parachain is only as decentralized as its own collator set, which varies by chain.
- Full node at home
- Demanding 56720Balances, staking and governance moved to Polkadot Hub in November 2025, and the docs' Hub node setup also runs an embedded relay-chain node. The production Hub RPC guide lists 8+ cores, 64 GB RAM, about 1.2 TB for a pruned relay chain from snapshot and about 1.2 TB for a Hub archive, and says low-traffic setups can scale down proportionally. The older relay-chain guide's 36-hour sync on a $10 cloud server does not fit that storage figure and looks out of date. No personal-use Hub node spec was found.
- Throughput claims
- No classified figure recorded
Scaling layers
- Parachains on Polkadot cores · Rollup, mainnet 341825
Parachains execute on their own collators; relay-chain validators assigned to a core re-execute each block, keep it available through erasure-coded pieces and spot-check it with random approval checkers before GRANDPA finalizes it. There is no fraud-proof window or proof contract: security rests on the shared validator set and dispute slashing. Collators can still stall a parachain, as happened to 5 of 37 parachains on 2026-03-23.
Capabilities
| Capability | How it is provided | Notes and sources |
|---|---|---|
| Account abstraction | Structured assessment pending | Not yet assessed for any chain. |
| Atomic swaps | Unknown | Not yet assessed under the current definitions; no built-in way for two parties to exchange assets in one all-or-nothing transaction, and no swap mechanism using hash or time locks, was reviewed for the relay chain or Polkadot Hub. Swaps against Hub asset-conversion pools and cross-chain transfers over XCM are not swaps between two parties. 12 |
| Authenticated data publication | Built into the protocolLimited scope | The Bulletin chain, a Polkadot system chain on mainnet (OpenGov Referendum 1938, recorded as executed, upgraded it to runtime 2.4): data is stored in transactions addressed by content hashes, retrievable over IPFS and checkable against those hashes, and kept for about 14 days by default unless renewed. Scope is limited: governance grants storage rights and the docs say the mainnet authorization model is still being finalized, there is no subscription or update mechanism, and the repository calls it a reference implementation not yet fully audited. 151630 |
| Light clients | Built into the protocolFull scope | Consensus produces GRANDPA finality justifications, and the smoldot and Substrate Connect light clients, including in browsers, warp-sync headers and check them instead of trusting an RPC provider. BEEFY adds compact finality proofs for bridges. 1417 |
| Native staking or delegation | Structured assessment pending | Not yet assessed for any chain. |
| On-chain governance | Structured assessment pending | Not yet assessed for any chain. |
| Parallel execution | Structured assessment pending | Not yet assessed for any chain. |
| Payment or state channels | Unknown | No payment or state channel network anchored to Polkadot was reviewed. Messaging channels between parachains are message paths, not payment channels. |
| Programmable spending | Native (protocol or core-team software) Earlier definition | Runtime 2.0.5, enacted on 2026-01-27, added smart contracts to Polkadot Hub. The docs now describe two engines for Solidity contracts: an EVM backend (REVM) and a RISC-V engine (PVM) whose Ethereum-compatible mode they call early-stage. Contract accounts use 20-byte addresses mapped to 32-byte native accounts. Outside contracts, accounts can use multisig and proxy rules. 8920212324 |
| Protocol-verified messaging | Structured assessment pending | Not yet assessed for any chain. |
| Reversible transfers or recovery | Built into the protocolLimited scope | Time-delayed proxies (the proxy pallet): a proxy announces a call that runs only after a set number of blocks, and the controlling account can reject it during that delay, so a delayed transfer can be cancelled. Scope is limited to part (a): the protocol does not reverse a completed transfer, and the wiki documents social recovery only in its Kusama section. 21 |
| Rollups | Partial (layer not stated) Earlier definition | Parachains execute on their own collators and are checked, kept available and finalized by relay-chain validators. They do not post proofs to a contract; see the scaling layer entry. 318 |
| Shielded transfers | Structured assessment pending | Not yet assessed for any chain. |
| Signed partial offers | Unknown | Not yet assessed under this row's current definition. |
Reading these values
- How this feature is provided
- Built into the protocol, core-team software or independent software says where a feature lives and who can change it. These are implementation layers, not quality: core-team software is not closer to the protocol than independent software.
- Structured assessment pending
- The shared review has not assessed this feature for any chain yet (Account abstraction, Native staking or delegation, On-chain governance, Parallel execution, Protocol-verified messaging and Shielded transfers). That does not mean it is absent, and a chain’s profile may already describe it.
- Unknown
- The review has not established this for this chain under the current definition; the note beside it says why. Unknown is not absent and not a low score. A feature reads “Not present” only when a source shows it is absent.
- Earlier definition
- Payment or state channels, Programmable spending and Rollups keep the earlier definition until the next fact-check. There, “Native” does not separate the protocol from core-team software, “Ecosystem software” does not say who publishes it, and “Partial” does not say which layer.
- Reading across rows
- The list of capabilities is incomplete. Do not read these rows as a chain leading or lagging overall.
Ecosystem & custody
| Product type | Status | Notes and sources |
|---|---|---|
| Automated market makers | Native to the protocolPolkadot Hub asset conversion pools, Hydration Omnipool (separate parachain) | Polkadot Hub has an asset-conversion pallet with constant-product pools. Hydration, a separate parachain, runs the Omnipool and stable pools. Liquidity depth and volumes were not reviewed. 1236 |
| Issuer-native stablecoins | Established in the ecosystemUSDC (Circle, Hub asset 1337), USDt (Tether, Hub asset 1984) | Circle and Tether both list Polkadot Asset Hub as a supported network; the docs list both as 6-decimal sufficient assets that can pay fees. dotUSD, a proposed protocol-owned stablecoin, was still being voted on (Referendum 1944) on 2026-09-27 and is not live. 11313435 |
| Algorithmic stablecoins | Unknown | No algorithmic stablecoin with material use was reviewed. HOLLAR on Hydration is described by its issuer as over-collateralized with a stability module, so it is not counted here; the dotUSD proposal's first phase is backed by USDT. 3137 |
| Bridges | Native to the protocolSnowbridge (Ethereum), Polkadot-Kusama bridge, Hyperbridge | Bridge Hub, a system chain, hosts Snowbridge, where Polkadot verifies Ethereum with an on-chain light client and Ethereum verifies Polkadot through BEEFY, and a bridge to Kusama built on GRANDPA light clients. The docs also list Hyperbridge. Transfers among Polkadot parachains use XCM messaging under shared validation, which is not a bridge. Risk: Snowbridge depends on correct light-client code, BEEFY's sampled signature checks, relayers and governance-controlled upgrades. RFC 166, approved on 2026-09-07, specifies an emergency pause that anyone could trigger by posting a large deposit; it is a design document and its deployment was not verified. A rate-limit circuit breaker (RFC 167) was still undecided on 2026-09-15. Hyperbridge's trust model was not reviewed. Bridged tokens are only as sound as their origin chain and path. 13262738 |
| Block explorers | Established in the ecosystemSubscan (relay chain and Polkadot Hub), Blockscout (Polkadot Hub contracts) | Subscan indexes the relay chain and Polkadot Hub; the smart-contract docs list Blockscout as the Hub explorer. Explorer data is provider-indexed, and this listing is not a completeness check. 103233 |
| Hardware wallets | Established in the ecosystemLedger | See custody rows: Ledger's Polkadot page offers account management and staking in the Ledger Wallet app; Trezor's Polkadot page says Polkadot is not currently supported. 3940 |
Hardware-wallet custody
| Device maker | Status | What users can and cannot do |
|---|---|---|
| Ledger | Native supportSame as native: Yes | Can: Set up a Polkadot account and manage DOT in the Ledger Wallet app, per Ledger's Polkadot page Can: Stake DOT from the Ledger Wallet app, per the same pageWhether Ledger Wallet shows Polkadot Hub assets such as USDC and USDt, or signs Hub smart-contract calls, was not checked; third-party Polkadot wallets that pair with Ledger were not reviewed for this row. 39 |
| Trezor | None foundSame as native: No | Cannot: Manage DOT in Trezor Suite: Trezor's Polkadot page says Polkadot is not currently supportedTrezor asks earlier Polkadot users to contact its support team. Third-party signing paths with a Trezor device were not reviewed. 40 |
Public data
iKnow Blockchain has no public-data lookups for Polkadot yet. This is a limit of the service, not a statement about the network.
| Lookup | Status | What it covers and its limits |
|---|---|---|
| Address or account | Not available yet | Public-data lookups for this chain are not built yet. |
| Tokens and assets | Not available yet | Public-data lookups for this chain are not built yet. |
| NFTs | Not available yet | Public-data lookups for this chain are not built yet. |
| Transactions | Not available yet | Public-data lookups for this chain are not built yet. |
Sourced developments
Developments: Review overdue Reviewed Sep 27, 2026; next review was due Oct 7, 2026, 12:00 UTC.
Publication date · newest first
-
Parity outlined how parachain validation would move to JAM
Parity Technologies described four projects for the switch: a production JAM node (PolkaJAM), a minimal relay chain with no DOT and no user transactions, off-chain messaging between parachains, and a Parachain Service that would take over block validation, code upgrades and coretime handling on JAM.
- Proposal:announced plan
- Implementation:in development; the Parachain Service design was presented at the 2026-09-15 OpenDev call
- Release:not released
- Activation:not active
Sources: Parity Technologies (Polkadot Forum) — The Road to JAM (external site) · Polkadot Forum — Polkadot Technical Fellowship OpenDev Call proceedings, 15 September 2026 (external site) · Polkadot Wiki — JAM Chain (external site)
-
System-chain runtime 2.5.0 enacted: two new OpenGov tracks and the Individuality pallets
Referendum 1942 upgraded Polkadot's system chains to Fellowship runtime 2.5.0. On Polkadot Hub it adds two OpenGov tracks: technical_maintenance, for operational settings such as quotas, allowances, limits and fees, and prosperity_emergency, for guarding dotUSD's monetary mechanisms. It also adds the pallets of the Individuality framework to the People chain and Polkadot Hub, enables the privileged force_create call for assets on Polkadot Hub and updates the Hub's contract pallet to pallet-revive 0.19.1.
- Proposal:Referendum 1942 executed on 2026-09-10 after Fellowship whitelisting
- Implementation:implemented in Fellowship runtimes 2.5.0 (spec version 2005000)
- Release:released 2026-09-05
- Activation:active on Polkadot Hub by 13:57 UTC on 2026-09-10; the People chain and other system chains were not checked
Sources: Polkadot Fellowship (GitHub) — Runtimes 2.5.0 (external site) · Polkadot Forum — Runtime release notification for v2.5.0 [07.09.2026] (external site) · Subsquare (Polkadot OpenGov) — Referendum 1942: Upgrade System Chains To 2.5 (external site) · Subscan — Polkadot Asset Hub block 20482000 (external site) · Subscan — Polkadot Asset Hub block 20490000 (external site) · Subsquare (Polkadot OpenGov) — Referendum 1944: dotUSD: A Native Stablecoin for Polkadot (external site)
-
System-chain runtime 2.4.0 enacted: peg stability modules on Polkadot Hub and Bulletin chain storage
Referendum 1937 upgraded Polkadot's system chains to Fellowship runtime 2.4.0, and Referendum 1938 did the same for the Bulletin chain. The release lets Polkadot Hub run several independent peg stability modules for stablecoin issuance, each created by the asset's owner or by Root with a fixed 100 DOT deposit and accepting up to five external assets. It also gives the Bulletin chain the storage logic that lets authorized accounts store data within their allowances, raises the People chain's block weight limit and fixes under-priced XCM weights.
- Proposal:Referenda 1937 (system chains) and 1938 (Bulletin chain) executed on 2026-09-01 after Fellowship whitelisting
- Implementation:implemented in Fellowship runtimes 2.4.0 (spec version 2004000)
- Release:released 2026-08-26
- Activation:active on Polkadot Hub by 18:51 UTC on 2026-09-01; the People, Bulletin and other system chains were not checked
Sources: Polkadot Fellowship (GitHub) — Runtimes 2.4.0 (external site) · Polkadot Forum — Runtime release notification for v2.4.0 [28.08.2026] (external site) · Subsquare (Polkadot OpenGov) — Referendum 1937: Upgrade System Chains To 2.4 (external site) · Subsquare (Polkadot OpenGov) — Referendum 1938: Upgrade Bulletin System Chains To 2.4 (external site) · Subscan — Polkadot Asset Hub block 20135000 (external site) · Subscan — Polkadot Asset Hub block 20150000 (external site)
-
Nominators made unslashable with a two-era unbonding period
Referendum 1910 disabled nominator slashing and cut the nominator unbonding period from 28 days to 2 eras. It followed Referendum 1890, executed on 2026-06-12, which requires validators to hold at least 10,000 DOT of their own slashable stake.
- Proposal:Referendum 1910 executed
- Implementation:staking configuration change on Polkadot Hub
- Release:parameter change by referendum; no separate release reviewed
- Activation:active since 2026-07-06
Sources: Subsquare (Polkadot OpenGov) — Referendum 1910: Staking Configuration Update: Nominator Slashing & Unbonding Parameters (external site) · Subsquare (Polkadot OpenGov) — Referendum 1890: Staking: set min validator bond to 10K DOT (external site) · Polkadot Forum — Changes on Polkadot in March 2026 (external site) · Polkadot Wiki — Chain State Values (external site)
-
Runtime 2.0.5 enacted: capped DOT issuance, Hub smart contracts and 2-second Hub blocks
Referendum 1828 enacted Fellowship runtime 2.0.5, which put Referendum 1710's capped, stepped issuance schedule on-chain, added smart contracts (pallet-revive) to Polkadot Hub and enabled elastic scaling for 2-second Hub blocks. The first issuance step took annual issuance from 120 million to about 55.8 million DOT on 2026-03-14.
- Proposal:Referendum 1710 (issuance) and Referendum 1828 (upgrade) executed
- Implementation:implemented in Fellowship runtimes 2.0.5
- Release:released 2026-01-13
- Activation:enacted 2026-01-27; first issuance step on 2026-03-14
Sources: Polkadot Forum — Polkadot Digest 26 January 2026 (external site) · Subsquare (Polkadot OpenGov) — Referendum 1828: Polkadot Upgrade 2.0.5 (external site) · Polkadot Fellowship (GitHub) — Runtimes 2.0.5 (external site) · Subsquare (Polkadot OpenGov) — Referendum 1710: Hard Pressure Capped & Stepped Supply Schedule (external site) · Polkadot Forum — Changes on Polkadot in March 2026 (external site) · Polkadot Forum — Polkadot Staking Changes: Progress & Timeline (external site)
-
Polkadot balances, staking and governance moved to Asset Hub
The Asset Hub migration moved balances, staking, governance, proxies, multisig and vesting from the Polkadot relay chain to Asset Hub (Polkadot Hub). The existential deposit fell from 1 DOT to 0.01 DOT, and supported assets can now pay fees.
- Implementation:implemented in Fellowship runtimes 2.0.0
- Release:released 2025-10-28
- Activation:completed on Polkadot on 2025-11-04, per the wiki
Sources: Polkadot Wiki — Asset Hub Migration (external site) · Polkadot Fellowship (GitHub) — Runtimes 2.0.0 (external site) · Subscan — Polkadot relay chain explorer (external site)
Topics your AI can explain
Your AI can explain these topics for Polkadot through the connection, with sources.
Known gaps
What this profile's review did not establish:
- Time from block production to GRANDPA finality was not quantified from a primary source. Only the roughly 6-second relay-chain slot and Polkadot Hub's 2-second target were verified; one read of the last 1,000 finalized blocks on 2026-09-27 averaged about 6.0 seconds on the relay chain and about 2.3 seconds on the Hub, a single sample rather than a measured band.
- The active validator count (600) comes from the wiki's chain-state page and matched one read of the relay chain's current session validator list on 2026-09-27; it can change, and Parity's staking plan proposes sizing the set to demand later. How many independent operators run those validators was not measured.
- The wiki's chain-state page still lists a 28-day unbonding period, while Referendum 1910 (executed 2026-07-06) made nominators unslashable and cut their unbonding to 2 eras. Validator unbonding after that change was not verified.
- No official hardware guide for a personal, non-production Polkadot Hub node was found; the posture rests on the production RPC guide and the relay-chain full-node guide.
- SASSAFRAS was not found deployed on Polkadot; the docs describe BABE as the current block-production mechanism.
- No trust-minimized atomic-swap mechanism and no payment or state channel network anchored to Polkadot were reviewed.
- Liquidity depth for Polkadot Hub pools and Hydration was not reviewed.
- Hyperbridge's trust model and current use of the Polkadot-Kusama bridge were not reviewed.
- Ledger support for Polkadot Hub assets and contract calls, and any third-party signing path for Trezor devices, were not tested.
- Whether the Bulletin chain is usable by ordinary users on mainnet, given governance-granted authorization, was not tested.
- The runtime change that added contracts set a native-to-Ethereum ratio of 100,000,000, which implies Ethereum tools see DOT with 18 decimal places instead of the native 10 (see the literacy pack); this was not checked in a wallet.
- Whether the Snowbridge emergency pause from RFC 166 has been deployed was not verified; the RFC text is a design.
- The relay-chain full-node guide's 36-hour sync on a $10 cloud server conflicts with the newer RPC guide's roughly 1.2 TB pruned relay chain; the two docs were not reconciled.
- Filing parachains with rollups is a judgement call and is marked contested.
Sources
Oldest dated source check: Source checked Sep 27, 2026 Next check due Oct 27, 2026.
- Proof of Stake Consensus (BABE, GRANDPA) (external site)
- Relay Chain overview (external site)
- Agile Coretime (external site)
- Elastic Scaling (external site)
- Validator Requirements (external site)
- Set Up a Relay Chain Full Node (external site)
- Run a Parachain RPC Node (external site)
- Smart Contracts on Polkadot Hub (external site)
- Accounts on Polkadot Hub for Ethereum developers (external site)
- Connect to Polkadot Hub (network details) (external site)
- Asset Management on Polkadot Hub (external site)
- Convert Assets on Asset Hub (external site)
- Bridge Hub (external site)
- Light Clients (external site)
- Data Storage (Bulletin Chain) (external site)
- polkadot-bulletin-chain repository (external site)
- Polkadot's Consensus Protocols (external site)
- Parachains' Protocol (ELVES) (external site)
- Chain State Values (external site)
- Asset Hub Migration (external site)
- Proxy Accounts (external site)
- RFC-0026: Sassafras Consensus Protocol (external site)
- Runtimes 2.0.5 release notes (external site)
- Polkadot Digest 26 January 2026 (external site)
- Partial Polkadot Parachains stall on runtime upgrade 2.1.1 - postmortem (external site)
- Polkadot Technical Fellowship OpenDev Call proceedings, 15 September 2026 (external site)
- RFC-0166: Snowbridge Emergency Pause Pallet (external site)
- The Nakamoto Coefficient of Polkadot is At Most 25 (thread, updated June 2026) (external site)
- Referendum 1890: Staking: set min validator bond to 10K DOT (external site)
- Referendum 1938: Upgrade Bulletin System Chains To 2.4 (external site)
- Referendum 1944: dotUSD: A Native Stablecoin for Polkadot (external site)
- Polkadot relay chain explorer (external site)
- Polkadot Asset Hub explorer (external site)
- USDC contract addresses (external site)
- Supported protocols (external site)
- What is Hydration? (external site)
- HOLLAR (external site)
- Snowbridge documentation (external site)
- Polkadot Wallet (external site)
- Polkadot wallet (external site)
Report an error
Found something wrong or out of date? Reporting is free, and every chain goes through the same process. Published corrections appear in the public log.
Funding disclosure
Funding disclosures appear here when an upkeep arrangement exists, in the form “Upkeep funded by [name]; verdicts unaffected.” The funder ledger has not been published yet. Neutrality & funding