Polkadot Wiki

Polkadot Wiki

  • Get Started
  • Learn
  • Build
  • Maintain
  • Kusama
  • Contribute
  • Languages iconEnglish
    • Русский
    • 中文
    • Help Translate

›Polkadot Comparisons

General

  • Getting Started
  • Claims
  • Redenomination of DOT
  • Grants
  • Thousand Validators Programme
  • Polkadot Ambassador Programme
  • Research Pages
  • Community
  • Contributing
  • Contributors
  • Glossary
  • Using ENS with DOT/KSM accounts
  • Ledger Application
  • How to Protect Yourself from Scams
  • Frequently Asked Questions (FAQs)

Learn

  • Polkadot Launch Phases
  • Basics

    • Architecture
    • Polkadot Accounts
    • Account Generation
    • Backing up and Restoring Accounts
    • DOT
    • Security of the network
    • Polkadot Consensus
    • Nominator
    • Validator
    • Collator
    • Governance
    • Identity
    • How to transfer Balances
    • Transaction Fees
    • Polkadot Host (PH)
    • Treasury
    • How to use W3F Registrar

    Parachains

    • Parachains
    • Parathreads
    • Bridges
    • Parachain Slots Auction
    • Parachain Crowdloans

    Advanced

    • Staking
    • Proxy Accounts
    • Availability and Validity
    • Randomness
    • Cross-chain Message Passing (XCMP)
    • SPREE
    • WebAssembly (Wasm)
    • Sequential Phragmén Method
    • Simple Payouts

    Cryptography

    • Cryptography Explainer
    • Polkadot Keys

    Polkadot Comparisons

    • Comparing Polkadot and Kusama
    • Ethereum 2.0
    • Cosmos
    • Dfinity
    • Other comparisons

Build

  • Builder's Portal
  • Development Guide

    • Polkadot Builders Starter's Guide
    • Parachain Development Kits (PDKs)
    • Parachain Implementer's Guide
    • Cumulus
    • Building Parachains on Rococo
    • Smart Contracts
    • Oracles
    • Polkadot Wallets

    Integration Guide

    • Integration Initiation
    • Polkadot Protocol
    • Node Management
    • Node Interaction
    • Transaction Construction

    Tools

    • Tool Index

    Resources

    • Hackathon

Maintain

  • Network Maintainers
  • Parameters
  • Nodes and Dapps

    • Set up a Full Node
    • Networks
    • Set up Secure WebSocket for Remote Connections
    • Resolving Errors

    Nominator Guides

    • How to Nominate on Polkadot
    • Unbonding and Rebonding

    Validator Guides

    • How to run a Validator on Polkadot
    • Validator Payout Overview
    • Using systemd for the Validator Node
    • Secure Validator
    • How to use Polkadot Secure Validator Setup
    • Set Up a Sentry Node
    • How to Upgrade Your Validator
    • Monitor your node
    • How to Chill

    Governance Guides

    • Participate in Democracy
    • Join the Council
    • Voting for Councillors
Edit

What is the difference between Polkadot and Kusama?

Although they share many parts of their code, Polkadot and Kusama are independent, standalone networks with different priorities.

Kusama is wild and fast; great for bold experimentation and early-stage deployment. Polkadot is more conservative, prioritizing stability and dependability.

What the two networks have in common

Kusama was released as an early version of the same code to be used in Polkadot, which means they share the same underlying architecture: a multichain, heterogeneously-sharded design based on Nominated Proof of Stake (NPoS). Both networks also share key innovations like on-chain governance, hot-swappable runtimes for forkless, on-chain upgrades, and Cross-Chain Message Passing (XCMP) for interoperability. Governance on both Polkadot and Kusama is designed to be decentralized and permissionless, giving a say in how the network is run to everyone who owns the native token (DOT for Polkadot, KSM for Kusama). Therefore, over time the networks will evolve independently, converging or diverging according to the decisions of their respective communities.

Key differences

There are a few important distinctions to be made.

polkadot_vs_kusama

Speed

The first key technical difference between Polkadot and Kusama is that Kusama has modified governance parameters that allow for faster upgrades. Kusama is up to four times faster than Polkadot, with seven days for token holders to vote on referendums followed by an enactment period of eight days, after which the referendum will be enacted on the chain. This means stakeholders need to stay active and vigilant if they want to keep up with all the proposals, referenda, and upgrades, and validators on Kusama often need to update on short notice.

On Polkadot, votes last 28 days followed by an enactment period of 28 days. This does not mean that the Kusama blockchain itself is faster, in the sense of faster block times or transaction throughput (these are the same on both networks), but that there's a shorter amount of time between governance events such as proposing new referenda, voting, and enacting approved upgrades. This allows Kusama to adapt and evolve faster than Polkadot.

Lean setups

Teams wishing to run a parachain need to bond tokens as security. The bonding requirement on Kusama is likely to be lower than on Polkadot.

Use cases

Polkadot is and always will be the primary network for the deployment of enterprise-level applications and those that entail high-value transactions requiring bank-level security and stability. The initial use case for Kusama is as a pre-production environment, a “canary network”. Building on Kusama first allows teams to test things out in a live, fully decentralized and community-controlled network with real-world conditions and lower stakes in the event of problems or bugs than on Polkadot.

Many projects will maintain parachains on both networks, experimenting and testing new technologies and features on Kusama before deploying them to Polkadot. Some teams will decide just to stay on Kusama, which is likely to be a place where we see some exciting experimentation with new technologies going forward. Projects that require high-throughput but don’t necessarily require bank-like security, such as some gaming, social networking, and content distribution applications, are particularly good candidates for this use case.

Kusama may also prove to be the perfect environment for ambitious experiments with new ideas and new innovations in areas like governance, incentives, monetary policy, and DAOs (decentralized autonomous organizations). Future upgrades to the Polkadot runtime will also likely be deployed to Kusama before Polkadot mainnet. This way, not only will we be able to see how these new technologies and features will perform under real-world conditions before bringing them to Polkadot, but teams who have deployed to both networks will also get an advance look at how their own technology will perform under those upgrades.

Going forward

Ultimately, Kusama and Polkadot will live on as independent, standalone networks with their own communities, their own governance, and their own complementary use cases, though they will continue to maintain a close relationship, with many teams likely deploying applications to both networks. In the future, we’re also likely to see Kusama bridged to Polkadot for cross-network interoperability. Web3 Foundation remains committed to both networks going forward, providing crucial support and guidance to teams building for the ecosystem.

Explore more

  • About Kusama
  • The Kusama Wiki
  • Kusama on Polkadot-JS Apps
Last updated on 12/31/2020 by Bruno Škvorc
← Polkadot KeysEthereum 2.0 →
  • What the two networks have in common
  • Key differences
    • Speed
    • Lean setups
    • Use cases
  • Going forward
  • Explore more
General
  • About
  • FAQ
  • Contact
  • Build
  • Grants and Bounties
  • Carrers
Technology
  • Technology
  • Token
  • Telemetry
  • Substrate
  • Whitepaper
  • Lightpaper
Community
  • Community
  • Documentation
  • Brand Assets
  • Blog
  • Element Chat
  • Medium

Subscribe to the newsletter to hear about Polkadot updates and events.

Polkadot Network
  • © 2021 Web3 Foundation
  • Impressum
  • Disclaimer
  • Privacy
  • Cookie Settings
  • Testnet disclaimer