Polkadot (DOT) Price, Charts & Market Data

DOT is the native token of the Polkadot Relay Chain. It underpins the network’s core functions:

Securing the network via staking (NPoS): DOT holders can nominate validators or run a validator to help finalise blocks and keep the system honest. Staked DOT backs validator behaviour and earns staking rewards; misbehaviour can be penalised (slashing). See: Nominated Proof-of-Stake and Slashing for mechanics and risks.

On-chain governance (OpenGov): DOT is used to propose and vote on referenda across multiple “tracks”, delegate voting power, and participate in protocol upgrades and system-chain decisions. See: OpenGov and How can users participate in governance… for details on tracks, deposits and delegation.

Network fees and required deposits: Transactions on the Relay Chain consume fees paid in DOT, and accounts must maintain a minimum balance (existential deposit) to remain active. Some on-chain actions also require refundable DOT deposits (e.g., identity). See: What are DOT’s on-chain utilities… for fee types and deposits.

Acquiring Relay Chain compute (“coretime”) in Polkadot 2.0: Projects obtain execution time on Relay Chain cores by purchasing coretime with DOT; these DOT are burned. This model replaces long-term slot leases/crowdloans. See: What changes with Polkadot 2.0… and How can a team launch a chain… for economics and routes to deploy.

System funding via the on-chain Treasury: Treasury inflows (portion of block rewards, fees, tips, slashes) are denominated in DOT and can be spent—through governance—on approved proposals. See: How does the on-chain Treasury operate… for process and scope.

Cross-chain movement and ecosystem use: DOT can be teleported between the Relay Chain and system parachains like Asset Hub using XCM; cross-chain transfers may incur fees on both source and destination chains. Some parachains/apps accept DOT natively; others require bridged/wrapped representations. See: Asset Hub and How does DOT interoperate with other networks… for specifics and caveats.

If you’re looking for the specific fee model, minimums, deposits and staking flows, continue with “What are DOT’s on-chain utilities (staking, fees, governance and deposits)?”

DOT uses a fixed annual issuance that began at ~8% of supply at enactment and is now a constant ~120 million DOT per year, causing the percentage inflation rate to decline over time as total supply grows. Of each year’s issuance, 15% is minted directly to the Treasury and 85% funds staking rewards (paid out per era). These parameters were introduced by OpenGov (Referendum #1139) and implemented in runtime code.

Emissions cadence and distribution: New DOT are created continuously and accounted for at the end of each era (~24 hours on Polkadot), then distributed to validators and nominators according to the staking reward mechanism; the Treasury’s 15% share is minted directly to its system account. With the fixed-issuance model, this split is no longer adjusted by the network’s staking participation, simplifying rewards compared with the prior design.

Burns that offset gross issuance: Two sources reduce net supply growth: coretime purchases (in Polkadot 2.0) are burned, and the Treasury can also burn funds via governance. As a result, effective annual inflation equals the fixed issuance (~120M DOT) minus amounts burned in a given year.

How this differs from the previous model: Before the 2024 change, Polkadot targeted roughly 10% annual inflation, with rewards modulated around an “ideal” staking rate and any shortfall flowing to the Treasury (“staking inefficiency”). The new model removes that adjustment and replaces it with the fixed 15% Treasury share noted above.

No hard cap (subject to governance): DOT does not have a maximum supply built into the protocol. Issuance parameters are subject to change via on-chain governance; the 2024–2025 updates were enacted through that process. For current settings and any active change proposals, consult the relevant OpenGov referenda.

2020 redenomination (unit change only): On 21 August 2020 (“Denomination Day,” block #1,248,328), DOT was redenominated at 1 old DOT = 100 new DOT. This was a change of units, not of value or ownership: balances and prices scaled by 100×, and the base unit (Planck) per DOT moved from 10¹² to 10¹⁰ Planck. The network’s economics were otherwise unchanged.

Staking (securing the network): DOT can be bonded to secure the network under Nominated Proof-of-Stake (NPoS). Holders either nominate validators or run a validator; rewards are paid per era, and misbehaviour can be penalised (slashing). Polkadot’s validator set is elected using Phragmén-based algorithms, and users can also participate through nomination pools if they prefer a simpler path with lower amounts. Specific mechanics such as unbonding times, slashing conditions and election details are covered in the NPoS and Slashing sections.

Fees (paying for transactions): On the Relay Chain, transactions pay fees in DOT taken from the transferable balance (not from bonded funds). Fees comprise a base fee, length fee, and weight-based fee, plus an optional tip that can increase inclusion priority; a congestion multiplier can adjust fees upward or downward based on recent block fullness. In practice, wallets show the estimated fee before you sign.

Cross-chain actions may involve fees on both source and destination chains. For example, teleporting DOT between the Relay Chain and Asset Hub incurs a destination fee and does not enforce the “keep-alive” safeguard, so balances must remain above the destination chain’s minimum to avoid reaping.

Governance (OpenGov): DOT is used to propose and vote on referenda in OpenGov. Proposals require a decision deposit; voting uses conviction-weighted balances (tokens are time-locked for added voting weight). Users may also delegate voting power, including per-track delegation. Operational how-to (voting, delegating, managing locks) is covered in the OpenGov sections.

Deposits and minimum balances: Polkadot enforces an existential deposit (ED)—a minimum free balance to keep an account alive. If a free balance falls below ED, the account can be reaped and any dust burned. Current guidance lists 1 DOT ED on the Relay Chain and 0.01 DOT on Polkadot Asset Hub (values are chain-specific and subject to change). Keep-alive checks help prevent accidental reaping during regular transfers; teleports don’t apply this safeguard.

Some features require reserved deposits (bonds) that are held while the feature is active and typically returned when it’s removed. Example: on-chain identity now managed on the People parachain requires a refundable deposit and a registrar fee; clearing the identity unreserves the deposit (funds reside on People until teleported back). Governance-related deposits (e.g., decision deposits) are covered under Governance.

The Relay Chain is Polkadot’s central chain. It provides the network’s shared security and global consensus, and is intentionally minimal in application logic: it exists to host and coordinate many parallel chains rather than to run end-user features itself. In Polkadot’s design, the Relay Chain ensures a single, globally consistent view of state across connected shards (“parachains”).

Parachains are application-specific chains that run in parallel and connect to the Relay Chain. They maintain their own state and logic but inherit security from the Relay Chain’s validator set. Parachain nodes called collators gather transactions and produce candidate blocks with proofs; Relay Chain validators then check availability and validity before those parachain state transitions are accepted into the shared state. This separation lets parachains specialise while the Relay Chain handles consensus, finality and coordination.

Parachains can communicate with one another using Polkadot’s cross-consensus messaging (XCM), with the Relay Chain coordinating the routing/verification layer so chains can exchange data and assets safely. Deep mechanics of XCM are covered in the XCM section.

Polkadot also includes system parachains (system chains) for core protocol functions—e.g., Asset Hub for fungible and non-fungible assets—moving functionality off the Relay Chain while still benefiting from shared security. These system chains are allocated by on-chain governance.

With Polkadot 2.0, projects access Relay Chain compute via cores (“coretime”). System chains receive cores by governance, while other chains obtain coretime on the open market; the fundamental relationship remains the same: parachains execute their logic, and the Relay Chain validates and finalises their state transitions.

XCM (Cross-Consensus Messaging) is Polkadot’s language for sending intent-based messages between consensus systems (Relay Chain, parachains, and—via bridges—other networks). It defines what should happen, independent of any specific runtime pallets. XCMP (Cross-Chain Message Passing) is the transport protocol for parachain↔parachain messages; relay↔parachain traffic uses UMP (upward) and DMP (downward). Messages are asynchronous.

Transfers: the two native XCM patterns

• Teleport: supply moves directly between trusted locations without a reserve keeper. Typical use: DOT between the Relay Chain and Polkadot Asset Hub. Teleports require mutual trust configuration on both chains.
• Reserve-based transfer: the asset’s reserve chain tracks total supply; the origin locks/burns a representation, the reserve adjusts balances, and the destination mints/credits a representation. This is the common pattern for moving assets to parachains that are not the reserve.

In practice, many teams prefer reserve transfers for safety and accounting clarity; teleports are typically enabled only for tightly trusted routes (for DOT: Relay Chain ↔ Asset Hub).

Channels and routing: Parachain↔parachain messages travel over channels. Today, most networks use HRMP (Horizontal Relay-routed Message Passing), which provides the same interface as XCMP but stores messages in the Relay Chain; XCMP is the more efficient end-state. HRMP channels are unidirectional; full two-way connectivity needs one channel in each direction and must be opened/accepted by both chains.

Fees, weight and execution: An XCM must “buy execution” on the destination chain (pay for weight, i.e., compute). Which assets are accepted for fee payment and how much weight is required are destination-chain policies. Standard extrinsics include teleportassets and reservetransfer_assets, which specify the destination, beneficiary, assets and fee item.

User-level behaviour and safeguards:

• Existential deposits & keep-alive: teleports don’t enforce the “keep-alive” check. Ensure your post-fee balance on the destination stays above its existential deposit or the account can be reaped. Teleports also include a destination-chain fee.
• Asynchrony & ordering: delivery isn’t instantaneous; ordering is only guaranteed within a channel.

For bridges to external networks and wrapped DOT, see the interoperability section later on.

Asset Hub is Polkadot’s system parachain (previously “Statemint”) for issuing, holding and transferring assets, including fungible tokens and NFTs. It is designed as a common-good chain with lower fees and a smaller existential deposit than the Relay Chain, and it uses DOT as the native token for fees and deposits. On Polkadot Asset Hub the existential deposit is 0.01 DOT (ten times smaller than the Relay Chain’s), and assets can be flagged as sufficient (no DOT balance required to hold them) or non-sufficient (the account must meet the DOT existential deposit).

Operationally, Asset Hub is where users and teams can create assets, manage metadata and perform transfers; official guidance also highlights it as a convenient venue for handling non-native tokens and NFTs. (Kusama’s Asset Hub has smart-contract execution enabled; on Polkadot, native EVM/PVM smart contracts are planned on the Polkadot Hub system chain rather than Asset Hub.)

When does teleporting DOT make sense?

Teleporting is the trusted XCM route configured between the Relay Chain ↔ Asset Hub for DOT. It is useful when you specifically need DOT on Asset Hub, for example to:

• Pay lower fees or meet the 0.01 DOT existential deposit for holding non-sufficient assets on Asset Hub, or
• Use features and applications that run on Asset Hub itself.

Key behaviours to know before a teleport:

• A destination-chain fee is deducted from the teleported amount; the remainder must still be ≥ the destination’s existential deposit or the funds will be lost.
• Teleports do not enforce “keep-alive”, so you must ensure your post-fee balances stay above the existential deposit on both sides if you intend to keep the accounts active.
• Do not teleport directly to an exchange deposit address (most exchanges cannot detect teleports).

For the mechanics of teleports vs reserve-based transfers and broader cross-chain routing, see the XCM/XCMP section. If a planned Asset Hub migration or maintenance is in progress, teleports and XCM transfers may be temporarily unavailable; check current Support notices for status.

Purpose and role: Polkadot and Kusama are independent networks with separate tokens (DOT, KSM) built on similar code. Kusama is the “canary network”: a live, economically real environment where new features land first and move faster; Polkadot prioritises stability and reliability for production deployments.

Governance cadence: Both run OpenGov, but Kusama generally uses shorter timelines (track-dependent) from decision to confirmation/enactment, enabling quicker upgrades; Polkadot’s timelines are more conservative. Parameters are per-track and can change by governance.

Staking timing: The unbonding period is ~28 days on Polkadot and ~7 days on Kusama. Eras—the periods used for validator payouts—are ~24 hours on Polkadot and ~6 hours on Kusama. These differences affect reward cadence and how long funds remain locked after unbonding.

Minimum account balance (existential deposit): To keep an account active, Polkadot requires 1 DOT and Kusama requires 0.000333333 KSM (values may change via governance). Asset Hub parachains use even smaller EDs.

Upgrade path: Major protocol changes and features are trialled on Kusama first under real conditions; once proven, they are deployed to Polkadot. This preserves agility on Kusama while keeping Polkadot conservative for long-term operation.

Both networks share the same architectural model (Relay Chain + parachains) and OpenGov tooling; the differences above reflect goals (speed vs stability) and operational parameters (timers, minimums) rather than fundamental design.

NPoS is Polkadot’s staking model in which two roles secure the network: validators run nodes that produce and validate blocks; nominators back selected validators with their DOT. Both share rewards and the risk of penalties if a backed validator misbehaves. Elections choose an active validator set and assign nominator stake to it each era.

Election cycle and timing: On Polkadot an era is ~24 hours. The active validator set for the next era is computed during the final part of the current era and enacted at era change; rewards are then calculated per era.

How nominators participate: A nominator can support up to 16 validators. The election algorithm may allocate a nominator’s stake only to a subset of those choices, aiming for a balanced and well-backed set; not every nominated validator will receive backing in the final solution.

How validators are elected (objective and algorithm): Validator elections optimise three goals at once: (1) maximise total stake securing the set, (2) maximise the minimum stake behind any elected validator, and (3) minimise stake variance across the set. Polkadot computes solutions off-chain and submits them on-chain through the Election Provider (multi-phase), with signed and unsigned phases and an on-chain fallback if needed. The network implements proportional committee-election rules derived from Phragmén research and solved off-chain via the multi-phase Election Provider, replacing earlier sequential-Phragmén approaches.

Stake assignment and payouts (at a glance): Once winners are chosen, the election solution specifies how nominator stake is distributed across the elected validators. Validators are paid per era based on activity, and nominators paid via their backed validator(s). Operational details of rewards are covered under staking specifics.

Accountability: Because nominators actively back validators, nominators can be slashed if a validator they helped into the active set commits certain faults. For conditions and percentages, see the dedicated Slashing section.

For unbonding times, pools and reward mechanics, continue in the staking sections; this entry focuses strictly on the election model and validator selection.

Slashing is an on-chain penalty applied when a validator violates consensus rules. The penalty burns a percentage of the stake assigned to that validator slot (the validator’s self-bond plus any nominator stake allocated to it). The size depends on the offence; slashed funds are sent to the Polkadot Treasury. Nominators are penalised only if their stake was backing the offending validator at the time.

Offences that can trigger slashing (examples): Polkadot enumerates validator offences and associates each with a typical response. Representative items include:

• Equivocation (BABE/GRANDPA/BEEFY): double-signing blocks or votes. Slash range 0.01%–100% depending on severity and how many validators are involved; validator is disabled.
• Backing invalid parachain block: para-validator backed an invalid block. 100% slash; on-chain disabling.
• ForInvalid vote: secondary checker voted for an invalid block. 2% slash; disabling.
• AgainstValid vote: voted against a valid block. 0% slash (no stake loss) but disabling applies.

Unavailability vs slashing: Routine outages usually lead to forced chilling (validator is stopped) rather than slashing. On Polkadot, an “offline” slash is only considered if a network-level event occurs—e.g., ≥10% of the active validator set goes offline simultaneously. Support guidance also notes that “prolonged” offline (around 4 hours) typically results in chilling, not a slash.

Who pays and how much: Slashes are percentage-based on the validator slot’s exposed stake (self-bond + the portion of each nominator’s bond allocated to that validator). Nominators’ losses are pro-rata to their exposure to the offending validator; stake backing other validators is unaffected. This percentage model intentionally scales with stake and encourages diversified backing.

Application, delay and reversals: Polkadot defers many slashes for roughly one unbonding period (~28 days). During this window, governance can cancel a slash if it stemmed from a protocol bug or similar non-fault condition; otherwise it is applied before funds can be withdrawn after unbonding.

Where slashed funds go: All slashed DOT are credited to the on-chain Treasury, which funds network initiatives via OpenGov.

Related reading: for validator selection and stake assignment see the NPoS section; for unbonding and pools see the staking sections.

When you stop staking, bonded DOT become “unlocking” and are withdrawable only after the 28-day unbonding period finishes. You must then execute Withdraw Unbonded to make them transferable. (Kusama uses 7 days.)

Exception: Fast Unstake. If your account hasn’t been exposed to any active validator for the last 28 eras, you can use Fast Unstake to skip the 28-day wait. If you were exposed, you must serve the normal period.

Staking pools vs direct nomination

Entry requirements & rewards eligibility:

• Direct nomination (solo): to earn rewards your bonded amount must clear the dynamic minimum active nomination threshold; this moves over time.
• Nomination pools: designed to let smaller holders participate; official docs state as little as 1 DOT can earn via pools (subject to pool size and activity).

Control & custody:

• Direct: you pick validators yourself.
• Pool: your DOT stay in your account (bonded), but the pool’s nominator chooses validators; mis-selection can impact rewards and you still share slashing risk.

Operations (joining, switching, exiting):

• Unbonding time: both forms honour the same 28-day unbonding on Polkadot. Pool exits also wait 28 days before withdrawal.
• Switching pools: you must unbond first (28 days on Polkadot; no rewards during this period).
• Rebonding during unbonding: direct nominators may rebond at any time before the 28 days end; pool members cannot rebond during the unbonding period.
• Reward handling: when a pool member unbonds, any pending rewards are auto-claimed to your transferable balance at withdrawal. Some pools offer auto-compound; it’s opt-in.

Current guidance notes you can vote in OpenGov while staked in a pool, and you can also join a pool with tokens already locked for governance. (This changed from earlier limitations.)

For penalties tied to validator behaviour, see Slashing.

Existential deposit (ED) and account minimums:

• Relay Chain ED: 1 DOT is required to keep a Polkadot account alive. If the free balance drops below 1 DOT, the account can be reaped (removed) and any dust is lost.
• Asset Hub ED: 0.01 DOT on Polkadot Asset Hub (chain-specific and set by governance). Assets there can be sufficient (no DOT needed to hold them) or non-sufficient (account must meet the DOT ED).

Keep-alive protection: Wallets such as Polkadot-JS enable “keep alive” by default: a transfer that would take your account under the ED is blocked. You may disable it to send the full balance and reap the sender account.

Fee model on the Relay Chain:

Polkadot uses a weight-based fee system. A transaction’s fee is the sum of:

• Base component (overhead for any extrinsic)
• Length fee (scales with the byte size)
• Weight fee (scales with the execution weight of the call)
• Optional tip (user-set to increase inclusion priority)
• A dynamic fee multiplier adjusts fees slightly up or down based on recent block saturation (congestion).

How you see/estimate fees: Wallets and SDKs surface an estimate before you sign (e.g., paymentInfo in polkadot.js). Fees are deducted from the transferable balance (not from bonded funds).

Practical notes:

• Reactivating a reaped account: just transfer in at least the chain’s ED (e.g., 1 DOT on the Relay Chain).
• Chain-specific EDs: ED varies by chain; Asset Hub’s ED is lower than the Relay Chain’s. Check current values in official support docs.
• Cross-chain moves: XCM operations (e.g., teleports) also charge a destination-chain fee and do not enforce keep-alive; ensure the post-fee balance on the destination meets its ED. See the XCM section for mechanics.

For staking-related minimums and unbonding times, see the staking sections; this entry focuses on account-level fees and minimum balances.

OpenGov is Polkadot’s on-chain governance system. Proposals (“referenda”) are binding: once a referendum passes, it is automatically enacted on-chain after its enactment period. Multiple referenda can run in parallel.

Tracks and origins: Every referendum is submitted on a track that matches an origin (the privilege level needed for the action). Each track defines: the decision deposit required, time windows (prepare/decision/confirmation/enactment), approval/support curves (thresholds that must be met), and usually a capacity for how many items can be in the deciding stage at once. High-privilege tracks (e.g., Root) have stricter thresholds and longer times than low-impact tracks (e.g., Small Tipper).

Some calls can be whitelisted by the Polkadot Fellowship and then executed via the Whitelisted Caller track, which uses faster parameters once the referendum passes. Track behaviours and examples are documented in the OpenGov “origins” guide.

Voting and conviction: Token holders vote Aye/Nay/Abstain with DOT. Voters may optionally apply conviction voting (a time-lock multiplier) to increase voting power by locking tokens for longer; locks start when the referendum ends and unlock after the chosen conviction period elapses. OpenGov allows different conviction choices on different simultaneous referenda.

Delegation and multi-delegations: Instead of voting directly, holders can delegate voting power. OpenGov supports per-track (multi-)delegation: you can delegate different amounts (and convictions) to different delegates on different tracks. You cannot delegate a track where you already have non-expired votes (or an existing delegation) until those are cleared. Official interfaces expose track pickers and conviction settings when configuring a delegation.

Referendum lifecycle (at a glance):

• Submission & prepare period – a referendum is submitted to a track; voting can open, but votes don’t count toward the outcome until after the prepare period. A decision deposit must be placed for the item to enter the deciding stage.
• Decision period – the item is actively decided. Passing requires satisfying the track’s approval and support curves.
• Confirmation period – thresholds must remain satisfied for a minimum confirmation window.
• Enactment period – once confirmed, the call is queued and then automatically executed on-chain after the track’s enactment delay.

Any DOT holder can participate in OpenGov: you can submit proposals (referenda), vote directly, or delegate voting power. Activity happens on “tracks” that define the origin (privilege), required decision deposit, thresholds and time windows. Track parameters vary and are set by governance.

Propose (create a referendum):

1. Choose the right track for the action you want executed (e.g., Root for high-impact calls, Tippers/Spenders for Treasury items).
2. Submit the referendum and ensure a decision deposit is placed; this deposit is tracked on-chain and is required for the item to enter the deciding stage after its lead-in period. Deposits are shown per referendum in UIs and are refundable under the track’s rules.

Requirements: a Polkadot account with enough DOT for fees and the track’s decision deposit. On-chain identity is optional but often used by proposers for credibility; setting identity requires a refundable deposit and a registrar fee on the People parachain.

Vote (direct participation):

• Choices: Aye, Nay, Abstain, Split (allocate across Aye/Nay), or SplitAbstain (allocate across Aye/Nay/Abstain).
• Conviction voting: optionally lock DOT for longer to multiply voting power; locks start after the referendum ends and expire per the chosen conviction. Locks overlap, so the same balance can secure multiple votes or be staked. You can also remove your vote while the referendum is ongoing to unlock immediately; otherwise, clear expired locks after they elapse.

Staked or pooled DOT can still vote: OpenGov supports voting while solo-staked or via nomination pools, following runtime updates that enabled pooled accounts to participate.

Delegate (per-track, multi-delegation): If you prefer not to vote on each item, you can delegate voting power. OpenGov allows multi-delegation by track: pick different delegates for different tracks, with distinct amounts and convictions. You cannot delegate a track where you have non-expired votes (or an existing delegation) until you clear them. Delegations can be managed in official UIs (Polkadot-JS, Polkassembly, Nova, PolkaGate).

Practical tooling:

• Polkadot-JS UI: propose, vote, delegate and clear expired referendum locks.
• Polkassembly/Subsquare/Nova/PolkaGate: discover referenda, cast votes (including Split/Abstain), and configure per-track delegations.

For thresholds, time windows and deposit sizes, consult the specific track when you propose or delegate; these parameters differ by track and can change via governance.

The Treasury is an on-chain pool of funds controlled by OpenGov. It receives inflows automatically and can only disburse funds through governance-approved actions. Funds live in a system account; no external account can move them directly.

How the Treasury is funded (inflows):

• Transaction fees: 80% of each extrinsic’s fee goes to the Treasury; 20% goes to block producers.
• DOT issuance: 15% of annual inflation is directed to the Treasury.
• Slashes: a share of slashed stake from validator offences is credited to the Treasury.
• Direct transfers: users may send assets to the Treasury account (uncommon, e.g., reimbursements).

How spending works (outflows):

• Treasury proposals (spends): governance approves referenda that transfer funds to a beneficiary. Payouts occur on the schedule defined by the spend period; at each spend period end, a fraction of unspent funds is burned.
• Tips: small, fast payouts via the Small/Big Tipper tracks.
• Bounties & child bounties: one-off “parent” bounties reserve a pot that curators later distribute through child bounties to specific tasks or events—useful when multiple payments are needed over time. Curators post a deposit, can receive a curator fee, and manage payouts within the bounty’s duration.

Governance tracks used for Treasury spending: OpenGov manages Treasury outflows through six tracks, each with its own origin and parameters: Treasurer, Big/Medium/Small Spender, and Big/Small Tipper. Larger spends use stricter tracks with tighter thresholds and capacity limits; tips are intended for smaller awards.

Multi-asset Treasury support: The Treasury can hold and spend assets other than DOT (e.g., USDT/USDC) when those assets are onboarded on Asset Hub and a conversion rate is set by governance on the Treasurer track. Approved multi-asset spends specify the asset, chain and amount; milestone-based spends and manual claim windows are supported.

Sub-treasuries (budget delegation): Governance can allocate part of the main Treasury to sub-treasuries tied to collectives or system chains. Each sub-treasury follows its own rule set for disbursing funds, reducing the need for many standalone referenda on the main tracks.

For how to create, vote on, or delegate Treasury proposals, see the OpenGov sections.

The Polkadot Fellowship is an on-chain collective of technical contributors that stewards the protocol’s runtime and technical standards. It operates on Polkadot’s Collectives system chain and coordinates work both on-chain and via public repositories (e.g., RFCs for proposed changes). While the Fellowship maintains Polkadot and Kusama runtimes, it does not gate protocol changes—any DOT holder can propose a runtime upgrade on the Root track in OpenGov.

Membership and ranks: Fellowship members hold ranked membership, and internal voting uses these ranks to weigh responsibility and signal technical review. Public dashboards for the Collectives chain expose member ranks and Fellowship activity.

Whitelisting & the Whitelisted Caller track: For time-critical or low-risk, well-audited actions (commonly runtime releases), the Fellowship may whitelist a specific call hash. This enables the Whitelisted Caller track in OpenGov to dispatch that call with Root authority after a referendum passes. The track uses faster timelines and different approval/support curves than Root, providing a controlled fast path for vetted items.

How upgrades are enacted: On Polkadot, runtime upgrades are executed only through Root or Whitelisted Caller referenda. The Fellowship’s role is to review and, where appropriate, whitelist releases so they can be enacted via the faster track; otherwise, upgrades proceed through the standard Root process.

Open development process: Technical proposals and design work are tracked in the Fellowship’s public RFC repository; Fellowship signals (approve/decline) and on-chain decisions are visible to token holders and voters.

Agile Coretime (blockspace as a market)

Polkadot 2.0 replaces long-term slot leases and crowdloans with a coretime market. Projects obtain execution time on Relay Chain “cores” in two ways:

• Bulk Coretime: a monthly “region” (initially ~28 days, 5,040 timeslices) sold on a specialised Coretime chain. Ownership is recorded as a non-fungible asset and can be reassigned or resold.
• Instantaneous Coretime: short bursts purchased from a pool when needed (pay-as-you-go).

Sales use a descending-price “lead-in” (Dutch-style) during each period; a regular price is adjusted over time by governance-defined rules so pricing converges to demand. A secondary market for regions is part of the design. Revenue from coretime sales is burned under an approved Fellowship RFC. Net issuance therefore equals gross issuance minus burns.

Cost impact: teams plan spend by buying exactly the capacity they need, with clearer pricing signals and no multi-year lockups. Auctions/crowdloans are deprecated on Polkadot since Agile Coretime went live.

Async Backing (throughput & latency improvements)

Asynchronous Backing decouples parachain block production from the latest Relay Chain block, letting collators pipeline multiple candidates and overlapping backing with inclusion. In practice this:

• lets parachains author blocks every ~6s (vs 12s before)
• increases the execution window (from ~0.5s to ~2s) allowing ~4× larger blocks
• yields up to ~8× higher throughput on its own and ~10× with PoV-reclaim (which accounts for real proof sizes) >These changes shipped in 2024 (Kusama first, then Polkadot).

Performance impact: higher sustained TPS and faster inclusion for parachains that enable it; chains that do not need the extra capacity can opt in later.

Elastic Scaling (using multiple cores per chain)

Elastic Scaling lets a single chain use multiple cores in parallel (vertical scaling) instead of one-core-per-parachain. It works with async backing and new collator/validator parameters to raise throughput further and cut latency. As of August 2025, Elastic Scaling is being finalised for mainnet enablement via OpenGov (Kusama first, then Polkadot).

Performance impact: rollups/parachains with heavy load can spread work across several cores, improving headroom without fragmenting to multiple chains.

Summary of effects:

• Costing & planning: predictable, market-driven coretime replaces long leases; teams buy monthly regions or on-demand slices; coretime revenue burns partially offset issuance.
• Throughput & latency: async backing raises block frequency and block capacity; elastic scaling adds multi-core execution for further gains. Together they increase sustained throughput without changing Polkadot’s shared-security model.

1) Build your chain:

* Use the **Polkadot SDK** (Substrate + Cumulus) and start from the parachain template. This gives you a FRAME-based runtime, collator node and XCM hooks ready to adapt.
* Connect locally to a Relay Chain to validate block production and XCM basics; the official tutorial shows how to **connect a local parachain**.

2) Testnet proving & obtain a ParaID:

* Prove upgrades and XCM on **Paseo** (the community testnet with coretime features).
* Reserve a **ParaID** on the target relay chain via the registrar: first `reserve` (pays a chain-defined deposit), then later `register` with your validation code (WASM) and genesis head. Deposits are configured per chain in the registrar pallet. (On testnets the docs show the exact constants; on mainnet values are set by governance.)

3) Acquire Coretime (Polkadot 2.0):

* **Bulk Coretime (a “Region”):** purchase a ~28-day region representing 5,040 timeslices on a specific core, sold on the Coretime chain. Ownership is tracked on-chain and can be reassigned or resold; sales use a descending-price lead-in toward a “regular price”.
* **Instantaneous Coretime:** short, on-demand capacity drawn from a pool when you need bursts rather than a full region.
* **Accounting:** revenue from coretime sales is burned per Fellowship RFC-0010, so teams budget DOT for purchases; there is no lockup/crowdloan.

4) Register & activate on the Relay Chain:

* With ParaID, runtime **WASM** and **genesis head** prepared, submit registration and activate your chain. On Polkadot, routine project onboarding uses the registrar; system chains (e.g., Coretime, Asset Hub) are registered via OpenGov (often the Whitelisted Caller track), as shown in the Coretime chain registration referendum.

5) Operate your network:

* **Collators:** run at least two reliable collators; scale and geo-distribute as load grows. (Validators are on the Relay Chain; parachains provide collators.)
* **XCM & HRMP:** open HRMP channels to peers (e.g., Asset Hub) and configure XCM (accepted fee assets, reserve locations). For DOT routing, note current guidance around Asset Hub as DOT reserve during the migration.
* **Upgrades:** ship runtime upgrades through your chain’s governance; the Relay Chain validates them during inclusion. (For Relay-level parameters and OpenGov mechanics, see the governance sections.)

6) Rollups vs parachains (where “rollup” fits here):

* Teams often implement “rollups” as parachains using the SDK (settling and being verified by the Relay Chain) to inherit availability/validity and XCM. If you target a rollup-as-a-service on an existing parachain, you’ll coordinate with that host rather than buy coretime yourself; the Relay-attached route still follows the steps above. (Architecture choice is project-specific.)

Minimum requirements (checklist)

Technical:

• Polkadot SDK runtime (WASM) + chain spec, genesis head, and ParaID.
• Collator nodes, RPC endpoints, telemetry/monitoring.
• XCM configuration and at least one HRMP channel for integrations.

Economic:

• DOT budget for coretime (Bulk or Instantaneous) and transaction fees; understand that coretime spend is burned.
• Registrar deposit to reserve/register ParaID (amount is chain-specific).

Governance touchpoints:

• None for ordinary registrar-based onboarding beyond your own chain’s governance; system chains are onboarded by OpenGov (example: Coretime chain registration).

Native DOT vs wrapped/derivative DOT:

• Native DOT lives on Polkadot itself (Relay Chain and system chains like Asset Hub). Inside Polkadot, DOT moves with XCM either by teleport (Relay ↔ Asset Hub for DOT) or by reserve-based transfers when DOT is represented on other parachains. Governance is migrating DOT’s reserve location used in XCM configs from the Relay Chain to Asset Hub, so parachains should treat Asset Hub as DOT’s reserve going forward.
• Wrapped/derivative DOT exists outside Polkadot (e.g., on Ethereum) or as ERC-20–compatible forms inside an EVM parachain. On Moonbeam, DOT appears as xcDOT, an XC-20: an ERC-20-compatible representation whose underlying DOT stays locked in a sovereign account on its reserve chain, while the ERC-20 interface is used locally.

XCM inside Polkadot vs bridges to external networks:

• XCM (in-ecosystem): a message format and set of patterns for asset movement between the Relay Chain and parachains. For DOT, teleporting is enabled on the trusted path Relay ↔ Asset Hub; movements to other parachains usually use reserve-based transfers, with the reserve chain accounting for total supply.
• Bridges (out of ecosystem): to reach networks like Ethereum, Polkadot uses bridges hosted on Bridge Hub. Snowbridge is the official, light-client-based Polkadot↔Ethereum bridge. Today it mints bridged ERC-20s on Asset Hub’s ForeignAssets pallet, then uses an XCM reserve transfer to deliver tokens to a target parachain, so XCM and the bridge work together.

EVM compatibility via Moonbeam (XC-20s):

• XC-20 standard: on Moonbeam, cross-chain assets are surfaced as XC-20s that implement the ERC-20 (and Permit) interfaces. For DOT this is xcDOT. Developers interact with XC-20s using the usual Ethereum tooling while Polkadot handles reserve accounting through sovereign accounts.
• Local vs external XC-20s: tokens whose home/ reserve is Moonbeam are “local” XC-20s; assets like DOT are external XC-20s whose canonical balances remain on their reserve chain (Relay/Asset Hub), with the ERC-20 representation circulating on Moonbeam.

Practical notes:

• When to use what: use XCM for movements within Polkadot (e.g., DOT between Asset Hub and parachains). Use a bridge (e.g., Snowbridge) to move assets to/from external networks like Ethereum; bridged tokens are distinct representations with different trust and risk models than native DOT.
• Ongoing updates: DOT’s reserve-location migration (to Asset Hub) is an active change; parachains and apps should update XCM configs accordingly to ensure transfers and accounting remain canonical. End-user guidance is being published via Polkadot Support and forum updates.

Polkadot was initiated by the Web3 Foundation (W3F), a non-profit based in Switzerland whose flagship project is Polkadot. W3F’s founder is Dr Gavin Wood, who authored the original Polkadot whitepaper in 2016 outlining the heterogeneous multi-chain design.

Development of the protocol and runtime was led by Parity Technologies, the engineering team that worked with W3F to bring Polkadot to mainnet in 2020.

Polkadot’s founding team is commonly cited as Gavin Wood, Robert Habermeier and Peter Czaban. W3F’s launch announcement names Robert Habermeier as a Polkadot co-founder and core developer, and Peter Czaban as a co-founder of Polkadot and Web3 Foundation.

W3F initiated Polkadot’s live network rollout on 26 May 2020, following several years of development; subsequent phases handed control to token holders and enabled DOT issuance on-chain. Supply mechanics and redenomination are covered in the earlier sections.