Watchlists
Screener
Monitoring
Projects
Analytics
Research
News
More
Project
© Blockworks 2026
Product
ResearchNewsIntelScreenerRankingsWatchlistsCharts
Company
NewsletterPodcastsEventsBrand Assets
Resources
Terms of ServicePrivacy PolicyPrivacy CenterDocumentationPricing
Terms of ServicePrivacy PolicyPrivacy CenterDocumentationPricing
NewsletterPodcastsEventsBrand Assets

Kusama

Networks · Layer-0
OverviewChartsMonitoringResearchNewsMarkets
OverviewChartsMonitoringResearchNewsMarkets

Token Transparency Filing

B1 v1.1 · Filed 01 Sep 2026Partial - 9 gaps
This page was compiled by Blockworks using publicly available information reviewed consistent with the TTF. Certain categories of information are more likely to include undisclosed items (e.g., non-announced fundraisings or material relationships).

Project & Team

01

Description of Project

Provide a concise narrative that clearly states each of (a)–(e) below.

  • (a) Problem the project solves — The problem the project is solving.
  • (b) Operational priorities — Provide a high-level description of how the project expects to support ongoing development and operations over time.
  • (c) High-level project overview — How the project works at a high level.
  • (d) Primary token functions — The primary functions of the token (e.g. gov participation).
  • (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.

(a) Problem the project solves

Kusama addresses the absence of a production-grade, real-economic-value environment for testing blockchain upgrades, governance mechanisms, and parachain deployments before those features advance to a mainnet with higher security requirements. Teams deploying on Polkadot need a live, adversarial environment with real financial stakes to expose failure modes that testnets with no economic weight cannot surface. Kusama fills that gap as a canary network, giving developers access to a live relay chain with real validator sets, real staking, and real governance before code reaches Polkadot.

(Source: Kusama Getting Started, Networks)

(b) Operational priorities

Kusama's ongoing operation is sustained through three mechanisms: on-chain staking incentives that compensate validators and nominators proportional to KSM staked, a protocol-level treasury that accumulates KSM through transaction fees, slashing, and staking inefficiencies, and treasury referenda that allocate those funds to development, infrastructure, and ecosystem initiatives approved by KSM tokenholders.

(Source: Kusama Inflation Model, Polkadot OpenGov, Treasury)

(c) High-level project overview

Kusama is a live, Nominated Proof-of-Stake relay chain with real economic value. It launched in August 2019, started as a Proof-of-Authority network, transitioned to Proof-of-Stake on October 28, 2019, and began parachain slot auctions on June 15, 2021. The network shares nearly the same codebase as Polkadot and is designed to move faster, deploying upgrades and parameter changes ahead of Polkadot to expose defects in a live setting.

(Source: Networks, Kusama Timeline)

(d) Primary token functions

KSM is the native token of Kusama. KSM is used for transaction fees, staking to secure the relay chain, participation in on-chain governance via stake-weighted referenda, and the purchase of coretime on the network.

(Source: Kusama Getting Started, Networks)

(e) Control surface reliance

Kusama is governed entirely by KSM tokenholders through on-chain OpenGov referenda. All protocol changes require stake-weighted referendum passage. Proposals are initiated by the public and proceed through origin- and track-specific flows that define approval thresholds, required deposits, preparation periods, voting periods, confirmation periods, and enactment periods. The Technical Fellowship can authorize the Whitelisted-Caller origin for Root-level calls but cannot execute those calls without a full OpenGov referendum passing.

(Source: Kusama Getting Started, Polkadot OpenGov, OpenGov Origins, Technical Fellowship)

02

Known Project Team

For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the: (a) full names, (b) official titles, (c) and prior experience of key team members. For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.

Full Name

Entity

Official Title

Prior Experience

Björn Wagner

Labs

CEO of Parity Technologies Limited (confirmed by the October 21, 2022 leadership update, in which he agreed to serve as CEO going forward)

Founder of Parity's Ecosystem Development division, per the same update

Gavin Wood

Labs

Chief Architect and majority shareholder of Parity Technologies Limited, per the October 21, 2022 leadership update

Co-founder of Ethereum and former CTO; co-founded Parity/EthCore; led Polkadot development with the Parity team

Fabian Gompf

Foundation

CEO of Web3 Foundation

Previously VP of Ecosystem Development at Parity Technologies; Web3 Foundation states he was key in shaping both Parity Technologies and Polkadot as a network and ecosystem

Thomas Fecker Boxler

Foundation

CFO and member of Web3 Foundation's Executive Management Team, effective March 1, 2023

Came from Serpentine Ventures AG as COO/CFO; previously co-founded or scaled a quantitative asset manager, a global macro hedge fund, a digital-asset liquidity provider, and an investment-management boutique

Gavin Wood

Foundation

Founder of Web3 Foundation and creator of Polkadot and Kusama

Ethereum co-founder and former CTO

No named DAO executive or fixed on-chain officeholder roster was identified in verified public sources. Kusama governance operates through a public proposal and referendum system organized by origins and tracks, with no appointed officeholder positions. (Source: Polkadot OpenGov, OpenGov Origins)

DAO

Blockworks note: The principal public foundation surface for Kusama is Web3 Foundation (Web 3.0 Technologies Stiftung, Zug, Switzerland). The principal public development-company surface is Parity Technologies Limited (England and Wales). No named DAO executive or fixed on-chain officeholder roster comparable to a corporate management roster exists for Kusama governance.
(Source: Web3 Foundation CEO Appointment, Parity About Us, Parity Terms, Parity Registry, Parity Leadership Update, Polkadot Is Live, Web3 Foundation CFO Appointment)

03

DAO Structure

Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).

  • (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
  • (b) Contract/admin powers — List onchain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
  • (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
  • (d) Value accrual & holder rights — If any, describe the current rights of tokenholders over revenue distribution and the treasury.
  • (e) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., onchain vote threshold, board resolution of a legal wrapper).

(a) IP ownership & control

Web 3.0 Technologies Foundation holds registered trademarks for KUSAMA (U.S. Serial No. 79275219, filed September 17, 2019, covering downloadable computer software for decentralization of internet software protocols) and POLKADOT, among other marks. The polkadot-sdk repository, which contains the Kusama runtime and relay-chain code, is maintained by Parity Technologies under a split license: Substrate Primitives, Frame, and pallets are licensed under Apache 2.0, and the Substrate Client is licensed under GPL v3.0 with a classpath linking exception. The Polkadot/Kusama relay-chain node code is licensed GPL 3.0 only. No public disclosure identifies a formal IP assignment agreement between Web3 Foundation and Parity Technologies or between either entity and the Kusama DAO.

(Source: Kusama Trademark (Justia), polkadot-sdk GitHub, polkadot-sdk Substrate README)

(b) Contract/admin powers

All protocol changes on Kusama require passage of a stake-weighted OpenGov referendum. Proposals are public, and each proposal is routed through an origin and track that determines approval threshold, required deposit, preparation period, decision period, confirmation period, and enactment period. Origins classify proposals by privilege. The Technical Fellowship holds the authority to whitelist calls for the Whitelisted-Caller origin, enabling Root-level execution, but whitelisted proposals must still pass a full OpenGov referendum. Treasury funds are held in a system account that no external key controls; they are accessible only through enacted referendum logic on the relevant treasury track.

(Source: Polkadot OpenGov, OpenGov Origins, Governance Reference, Technical Fellowship, Treasury)

(c) Locked-token rights (conditional)

KSM holders can increase their effective voting weight by voluntarily locking tokens under conviction voting, where longer lock durations multiply voting power. Delegation allows a tokenholder to assign their voting power on specified governance tracks to a chosen delegate without surrendering control of the underlying tokens or validator nominations.

(Source: Kusama Getting Started, Polkadot OpenGov, Governance Reference)

(d) Value accrual & holder rights

KSM holders vote on all referenda governing protocol changes, treasury disbursements, and inflation parameters. Conviction voting allows holders to multiply voting weight by locking tokens for defined periods. Delegation lets holders assign voting power by track to specialists without transferring token custody. KSM holders also earn staking rewards proportional to their participation when staking at or below the ideal staking rate.

(Source: Governance Reference, Polkadot OpenGov, Kusama Getting Started, Networks)

(e) Dissolution authority

No public mechanism for dissolving or winding up the Kusama DAO has been identified in verified sources. Kusama is a live public network with no designated dissolution authority. KSM holders could theoretically governance-vote to halt the network, but no formal dissolution mechanism, threshold, or legal wrapper has been publicly defined.

04

Primary Foundation

For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.

  • (a) Entity — Type and jurisdiction.
  • (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
  • (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
  • (d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
  • (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
  • (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.

(a) Entity

Web 3.0 Technologies Foundation is a Swiss foundation (Stiftung) registered in the Canton of Zug under the commercial register as Web 3.0 Technologies Stiftung. The Foundation was established in 2017 in Zug, Switzerland. It employs more than 50 staff and operates across education, governance, ecosystem development and funding, research, marketing, finance, risk and asset management, treasury, security operations, legal, HR, and operations.

(Source: Web3 Foundation Legal Disclosures, Web3 Foundation Annual Report)

(b) IP ownership & control

Web 3.0 Technologies Foundation holds registered trademarks for KUSAMA (U.S. Serial No. 79275219, filed September 17, 2019), POLKADOT (multiple registrations), W WEB3 FOUNDATION, PARACHAIN, PARATHREAD, and related marks. No public disclosure identifies what software repositories, if any, the Foundation owns as distinct from Parity Technologies, nor whether a formal IP licensing or assignment agreement between the two entities exists in the verified public record. No subsidiary entities of Web3 Foundation have been identified in the verified public record for this filing.

(Source: Web3 Foundation Trademarks (Justia), Web3 Foundation Trademarks (Justia, second filing))

(c) Powers over DAO, treasury, protocol-controlled resources, and token administration

No formal powers over Kusama's on-chain governance, treasury, or token administration have been publicly disclosed for Web3 Foundation. The Foundation participates in the Kusama network as a validator nominator under its Decentralized Nodes program: the Foundation nominates validator stash accounts using Foundation-held tokens, retains all associated voting rights, and may terminate participation without prior notice. All of those nominations and votes are subject to the same OpenGov rules that apply to any other KSM holder.

(Source: Decentralized Nodes Terms)

(d) Powers over DevCo

No public disclosure identifies formal mechanisms by which Web3 Foundation can direct or override Parity Technologies' decision-making. Gavin Wood is the founder of Web3 Foundation and the majority shareholder of Parity Technologies. That common founding relationship creates potential indirect influence, but no contractual control right from the Foundation over the DevCo has been identified in verified sources.

(e) Contract/admin powers

The Foundation's publicly disclosed administrative role in Kusama is limited to validator nominations under the Decentralized Nodes program. The published program terms state that nominations are made at the Foundation's sole discretion, that the Foundation nominates validator stash accounts using Foundation-held tokens, retains all associated voting rights, and may terminate participation without prior notice. No other Kusama contract or on-chain admin powers held by Web3 Foundation have been identified in verified public sources.

(Source: Decentralized Nodes Terms)

(f) Current economic arrangements and distribution policies

Web3 Foundation supports teams and open-source projects through grants, advocacy, research, and governance. Its Decentralized Futures program funds both for-profit and non-profit projects in the Polkadot ecosystem targeting financial self-sustainability. An executed Kusama referendum (Referendum 498) approved a Web3 Foundation commitment to deploy 10 million DOT from its own treasury, over at least two years, for the benefit of the Kusama ecosystem, including transfers to the Kusama on-chain treasury and support for Kusama-based bounties, collectives, and DAOs. Web3 Foundation's CEO publicly confirmed in July 2024 that the Foundation maintains more than five years of financial runway and does not depend on Polkadot or Kusama's on-chain treasury for operational funding. No Kusama-specific contractual payout formula or formal economic right over protocol-controlled resources beyond the Referendum 498 commitment and the Decentralized Nodes program has been identified in verified sources.

(Source: Web3 Foundation Annual Report, Kusama Referendum 498)

Blockworks note: The primary foundation is Web 3.0 Technologies Foundation (operating name: Web3 Foundation), the entity that launched Kusama, conducted the Polkadot pre-sale from which KSM genesis allocations were derived, and holds the KUSAMA trademark.

(Source: Web3 Foundation CEO Appointment, Web3 Foundation Legal Disclosures, Web3 Foundation Annual Report)

05

Primary Dev Co

For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.

  • (a) Entity — Type and jurisdiction.
  • (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
  • (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
  • (d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
  • (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
  • (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.

(a) Entity

Parity Technologies Limited is a private limited company registered in England and Wales under company number 09760015, incorporated September 3, 2015, with registered office at 1 Sans Walk, London, England, EC1R 0LT. The company previously operated under the name ETH CORE LIMITED. Named affiliates listed on the Parity terms page include Parity Technologies Deutschland GmbH, Unstoppable Open Source Technologies Lda, and Parity Technologies Singapore Pte. Ltd.

(Source: Parity Terms, Parity Registry)

(b) IP ownership & control

The polkadot-sdk GitHub repository, maintained by Parity Technologies under the paritytech organization, contains the Kusama runtime and relay-chain node code. That code is split-licensed: Substrate Primitives, Frame, and pallets are Apache 2.0, while the Substrate Client is GPL v3.0 with a classpath linking exception, and the Polkadot/Kusama relay-chain node is GPL 3.0 only. Copyright headers in the repository identify "Parity Technologies (UK) Ltd." as the copyright holder. No public disclosure identifies whether Parity Technologies holds any registered trademarks for Kusama-related IP; the KUSAMA trademark is held by Web3 Foundation. No formal IP licensing or assignment agreement between Parity Technologies and Web3 Foundation has been identified in the verified public record.

(Source: polkadot-sdk GitHub, polkadot-sdk Substrate README, Web3 Foundation Trademarks (Justia))

(c) Powers over DAO, treasury, protocol-controlled resources, and token administration

No formal on-chain admin powers held by Parity Technologies over Kusama's DAO governance, treasury, or token administration have been identified in verified public sources. Parity participates in Kusama governance as a stakeholder and as the primary code contributor whose releases inform runtime upgrade proposals, but those contributions do not grant Parity any elevated on-chain authority beyond what any KSM holder possesses.

(d) Powers over Foundation

No public disclosure identifies formal mechanisms by which Parity Technologies can direct or override Web3 Foundation decision-making. Gavin Wood holds majority shareholder status and 75% or more of voting rights in Parity Technologies, and he is the founder of Web3 Foundation, creating a common founding relationship but no disclosed contractual control right from the DevCo over the Foundation.

(Source: Parity PSC, Parity Officers)

(e) Contract/admin powers

No Kusama-specific on-chain contract admin powers held by Parity Technologies Limited have been identified in the verified public record. Dr. Gavin James Hoyle is the person with significant control over Parity Technologies Limited at the Companies House registry level, holding 75% or more of shares, 75% or more of voting rights, and the right to appoint or remove directors. Those are corporate governance rights over the DevCo entity, not on-chain admin powers over Kusama.

(Source: Parity PSC, Parity Officers)

(f) Current economic arrangements and distribution policies

No governance-approved, contractual, or programmatic mechanism directing Kusama protocol-controlled resources, treasury assets, fees, or token distributions to Parity Technologies Limited has been identified in verified public sources. Parity's CEO publicly confirmed in July 2024 that Parity Technologies maintains significant financial runway independent of the Polkadot or Kusama on-chain treasury. Parity may submit treasury proposals to Kusama OpenGov for specific development work, as any contributor can under the open governance framework, but no standing contractual or programmatic disbursement arrangement has been publicly disclosed.

(Source: Parity About Us, Web3 Foundation and Parity Dismiss Treasury Fears)

Blockworks note: The primary DevCo is Parity Technologies Limited, which jointly launched Kusama with Web3 Foundation, maintains the polkadot-sdk repository used to run Kusama's runtime and relay chain, and is publicly identified as the driving force behind Polkadot and Kusama's technical progress.

(Source: Parity About Us, Parity Terms, Parity Registry)

Token Supply & Allocations

06

Initial Allocation

Disclose launch and initial supply details in a single initial allocation schedule covering the token's launch.

  • (a) Launch supply totals — The total number of tokens issued at launch, the total number of tokens locked at launch or the total number of tokens unlocked at launch.
  • (b) Recipient categories & use of funds — The recipient categories with brief explanations as to how the category will use the tokens so an auditor can distinguish each bucket.
  • (c) Initial price per token (if applicable) — The initial price per token at TGE. If the token launched via a liquidity bootstrapping mechanism, auction, or other price-discovery process rather than a fixed offering price, describe that mechanism and the final market set price instead. If no fixed price was set, state so.
  • (d) Ticker / market symbol — The ticker/market symbol.
  • (e) Total supply & supply regime — The total supply and whether the supply is fixed (if not explain inflation rate or deflation rate).
  • (f) Initial vesting / release schedules — The initial vesting/release schedules (identify which categories/recipients are subject to vesting and the high-level timing logic).

(a) Launch supply totals

Kusama launched in August 2019 with an initial genesis supply mirroring the Polkadot DOT genesis allocation. The genesis supply was approximately 10,000,000 KSM. The Kusama genesis block announcement stated it was anticipated there would be 10 million DOTs in the Polkadot genesis block and that the KSM genesis distribution would be exactly as for DOT. The split between locked and unlocked KSM at genesis has not been separately published by Web3 Foundation or Parity Technologies in the verified public record. (Source: Announcing the Kusama Network, Kusama Timeline)

(b) Recipient categories & use of funds

The Kusama genesis distribution mirrored the Polkadot DOT genesis structure. The Polkadot genesis allocation was approximately: 50% (5,000,000 DOT equivalent) to participants in the 2017 public DOT sale via Dutch auction, giving KSM claim rights to those same participants on a 1-for-1 basis; approximately 30% (3,000,000 DOT equivalent) to Web3 Foundation, retained or distributed at its sole discretion and used to fund Kusama and Polkadot development, grants, and research; approximately 11% to further pre-genesis sales and distributions prior to the public mainnet launch; and the remaining ~9% to early contributors and related parties. Separately, 1% of genesis DOT tokens (10,000,000 DOT) was committed by Web3 Foundation for use by the Kusama network, a commitment fulfilled via Referendum 498. One percent of the initial KSM supply was reserved as an incentivization grant for Kusama stakeholders and community; the mechanics of that reservation were not finalized at launch. (Source: Announcing the Kusama Network, Gate.io KSM Listing Notes, Polkadot Forum Genesis Allocation Thread, Kusama Referendum 498)

(c) Initial price per token (if applicable)

KSM did not launch with a fixed offering price. The token was distributed through a claim process tied to DOT indicator token holdings and through a Web3 Foundation faucet for recipients who did not hold DOT. The first publicly reported secondary-market open price for KSM was approximately $1.71 in December 2019. (Source: Kriptomat Kusama Overview)

(d) Ticker / market symbol

KSM (Source: Kusama Getting Started, Networks)

(e) Total supply & supply regime

KSM is an inflationary token with no fixed maximum supply. Inflation is set at 10% annually. The inflation rate splits between stakers and the treasury depending on the ratio of staked KSM to total supply relative to the ideal staking rate. When the staking rate equals the ideal rate (approximately 50% of supply staked), validators receive the full new issuance; above or below that rate, a portion redirects to the treasury. As of era 9394, the total KSM issuance was 18,027,516.981152 KSM. The inflation rate is a governance-adjustable parameter, changeable by on-chain referendum. (Source: Kusama Inflation Model, Chain State Values)

(f) Initial vesting / release schedules

No verified project-issued vesting or release schedule for launch-era KSM recipient categories has been identified in the public record. KSM distributed through the DOT indicator token claim process was delivered to claimants directly at or after genesis with no protocol-level vesting applied. Web3 Foundation's allocation of approximately 30% of the genesis supply was retained at Foundation discretion with no publicly disclosed lock or vesting schedule.

07

Airdrop Process

Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly.

  • (a) Planned but not yet executed airdrop — If the project has planned but not yet airdropped, commit to publishing a recipient wallet list in a public channel and provide it to Blockworks quarterly until the initial TGE airdrop is fully completed. Additionally, generally state the possible target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
  • (b) Executed airdrop — If the project has already airdropped, point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count. Additionally, clearly state covered user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
  • (c) No airdrop planned or conducted — If the project does not plan to conduct an airdrop for TGE and has never conducted one, state so plainly (e.g., "We have never conducted an airdrop to date and do not plan to execute one").
  • Planned but not yet executed airdrop: N/A

  • Executed airdrop: N/A

  • No airdrop planned or conducted: Kusama has not conducted a separate airdrop program and does not plan to execute one. Token distribution at genesis occurred through a claims process, not an airdrop: participants in the 2017 Polkadot DOT pre-sale who received DOT allocation indicator tokens could claim an equivalent amount of KSM by completing the claims process while connected to the Kusama network. Web3 Foundation also operated a faucet to distribute KSM to participants who did not hold DOT indicator tokens; that faucet has since been decommissioned. Official scam guidance from the project warns that any giveaway messages using DOT or KSM branding are a known scam pattern.

    (Source: Claims Guide, Polkadot Claims Process, Polkadot Support Claims Tutorial, Scams)

Transactions & Market Structures

08

Market Maker Agreements & Deals

Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. For each market maker, include in a table:

  • (a) Market maker's name — the market maker's name;
  • (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply;
  • (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable,
  • (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model) without describing trading strategy or expected outcomes.

If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.

  • Market Maker Name: Bifrost / vKSM liquidity program
    • Token Allocation Committed: 50,000 KSM treasury liquidity subsidy, repayable with interest back to the Kusama Treasury, as base liquidity for the KSM-vKSM pair
    • Term Duration: 18 months
    • Structure Name: Governance-approved vKSM liquidity subsidy
  • Market Maker Name: Brale / KSM Collective KSM:dUSD pair
    • Token Allocation Committed: Brale committed $300,000 of dUSD; KSM Collective contributed $300,000 worth of KSM for the other side of the pair; one proposed structure contemplated 50% of LP fees returning to KSM Collective
    • Term Duration: No public term duration identified in verified sources
    • Structure Name: Kusama Asset Hub KSM:dUSD liquidity arrangement

Blockworks note: Kusama itself has not executed a classic bilateral market-maker agreement.

(Source: Kusama Referendum 477, Kusama Referendum 480, Kusama Referendum 471)

09

CEX / DEX Agreements & Deals

Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table:

  • (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair);
  • (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply;
  • (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable,
  • (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership.

If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.

Blockworks note: No governance-approved, contractual, or project-level CEX or DEX listing agreements have been identified in the verified public record for Kusama. KSM trades on secondary markets under no disclosed project-level listing arrangement.

Financial Disclosures & Risks

10

Prior Token Sales & Fundraising

Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide:

  • (a) Series Name
  • (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.)
  • (c) Date of sale (at least month & year)
  • (d) Number of tokens sold (or % of total supply)
  • (e) Vesting schedule

If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").

  • Series Name: Polkadot DOT indicator token public sale (Dutch auction); verified Kusama claims guidance ties eligible pre-2020 DOT sale participants to proportional KSM claim rights at genesis
    • Investment Vehicle: October 2017 (public DOT Dutch auction); Web3 Foundation launched the Kusama claims process in 2019 and the Polkadot public claims process on February 10, 2020
    • Date Of Sale: Approximately 5,000,000 DOT equivalent (50% of the anticipated 10,000,000 DOT genesis supply) sold in the 2017 auction; the corresponding KSM claim rights were 1-for-1 to DOT held at the Kusama genesis block. A separate KSM-denominated sale count has not been published.
    • Number of tokens sold: No protocol-level vesting schedule applied to the claim-based recipient class. Web3 Foundation's approximately 3,000,000-DOT-equivalent foundation allocation carried no disclosed lock or vesting schedule.

Blockworks note: (Source: Polkadot Claims Process, Claims Guide, Announcing the Kusama Network, Gate.io KSM Listing Notes, DOT Morph Announcement)

11

Previous Exploits Affecting The Native Token

If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").

  • (a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
  • (b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
  • (c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
  • (d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
  • (e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
  • (f) References (optional) — References (optional): link(s) to post-mortem/advisory/PR.

(a) Date & component affected

  1. 2020-01-04, Kusama runtime upgrade
  2. 2023-09-01, Kusama parachains
  3. 2024-02-15, Kusama finality
  4. 2025-02-25 to 2025-02-28, Kusama staking rewards
  5. 2025-05-09, Kusama dispute storm
  6. 2025-08-24, Kusama block production
  7. 2025-10-21, Kusama staking after AHM
  8. 2026-04-15 disclosure, Kusama relay chain slashing vulnerability

(b) Exploit vector summary

  1. A not-yet-live Polkadot mainnet runtime was uploaded to Kusama during a runtime upgrade following a Kusama/Polkadot logic split and incorrect runtime naming, which halted block production and bricked the chain.
  2. All parachains on Kusama stopped producing blocks while the relay chain continued finalizing, after a dispute concluded invalid for a candidate that had already been finalized, freezing the chain until governance intervened.
  3. A disabled validator raised a dispute that remained active without resolution, causing a finality stall; a second stall occurred around 23:57 UTC.
  4. pallet-staking used locks instead of reserve or hold, allowing users staking in both direct staking and nomination pools to count overlapping stake amounts and receive double rewards while staking only half the required total.
  5. Kusama runtime v1.5.0 enabled v2 candidate receipts while approximately 40 validators remained on versions older than v1.17; those older validators initiated disputes that degraded performance and caused finality lag culminating in a full stall.
  6. A dispute against a valid parachain block disabled validators that voted against the valid candidate and triggered a stall tied to a bug in the parainherent.create_inherent runtime API.
  7. A bug in pallet-staking-async caused validator self-stake not to be correctly recorded on-chain after AHM execution, leaving validators unrewarded and non-slashable for self-stake in recent eras.
  8. Forged MMR verification proofs could enable BEEFY fork-voting offense reports before PR #11738 was merged; the attack required no validator cooperation, private keys, bond, or deposit. The chain does not halt; services degrade; the maximum concurrent session-disabled count is 199 out of 600 validators; slashing applies after 28 days.

(c) Quantified impact

  1. No loss of funds was identified in the cited source.
  2. All parachains stalled beginning around 06:14 UTC. No loss of funds was identified.
  3. The first finality stall lasted approximately one hour. No loss of funds was identified.
  4. No evidence of active exploitation was identified in the post-fix report. No Kusama-specific loss-of-funds total was published.
  5. Finality lag began at 09/05/2025 14:30 UTC; GRANDPA stopped finalizing at 18:50 UTC; the complete stall lasted approximately 11 hours; finality did not catch up for the following 23 hours. No loss of funds was identified.
  6. No blocks were produced from 08/24/2025 12:28:24 UTC to 12:39:36 UTC; block 29798497 was later built with empty InherentData; the network fully recovered at 12:48:30 UTC. No loss of funds was identified.
  7. For a number of eras, validators had not been rewarded and were not slashable for their self-stake. No final loss-of-funds figure has been published.
  8. The vulnerability existed in production code introduced May 13, 2024. The chain does not halt; services degrade with up to 199 validators concurrently disabled. No exploited loss on Kusama has been identified in verified sources.

(d) Remediation/response taken

  1. The recovery required a rollback before the problematic upgrade and a time-bubble procedure for validators; the plan executed successfully on January 7, 2020.
  2. Governance submitted Referendum 263 to execute force_unfreeze; the regression was fixed and additional automated testing was proposed.
  3. Fix #3358 was applied; the rule was changed so a dispute is marked active only after at least one vote from a non-disabled validator.
  4. Participation in both systems was blocked immediately; the initial patch merged February 26, 2025; runtime upgrade referenda were submitted February 27, 2025; Kusama upgraded February 28, 2025; the long-term fix migrated pallet-staking to use holds in stable2503.
  5. An emergency fix disabled dispute logic and v2 candidate receipt handling on the node side as Kusama-only release stable2503-3; Referendum 524 executed the on-chain disablement of v2 receipts; validators upgraded to stable2503-4 by May 15, 2025.
  6. The fix was implemented in polkadot-sdk pull request #9564, backported to release lines 2503 and 2507, and proposed for Kusama as runtime 1.7.1 via Referendum 584.
  7. A fix was prepared in polkadot-sdk pull request #10051; validators were encouraged to calculate missing rewards and seek a treasury tip; Kusama Asset Hub runtime upgrade 1.9.3 incorporated changes to fix incorrect self-stake accounting (Referendum 608).
  8. Fix PR #11738 merged April 13, 2026; Referendum #1877 was cancelled the same day; an emergency runtime upgrade was recommended.

(e) Current status

  1. Resolved.
  2. Resolved.
  3. Resolved.
  4. Resolved.
  5. Resolved.
  6. Resolved.
  7. Referendum 608 executed; self-stake accounting fix deployed. No full post-incident accounting of validator make-whole outcomes has been published.
  8. Fixed in code as of April 13, 2026. Final Kusama deployment status beyond the emergency upgrade recommendation has not been independently confirmed in the verified public record.

(f) References (optional)

  1. Kusama Timeline
  2. Stalled Parachains Postmortem, Kusama Referendum 263
  3. Kusama Finality Stall Postmortem
  4. Double Staking Reward Bug
  5. Kusama Dispute Storm Postmortem
  6. Kusama Stall Postmortem
  7. Kusama Staking PSA, Kusama Referendum 608
  8. Relay Chain Vulnerability Disclosure
12

Material Risk Factors (Regulation, Technology, Token Economics)

Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.

  • (a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:

  • Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?

  • Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?

  • Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?

  • Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?

  • (b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:

  • Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?

  • Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?

  • (c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:

  • Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?

  • Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?

(a) Regulatory, Legal & Tax Risks

Web 3.0 Technologies Foundation, registered in the Canton of Zug as Web 3.0 Technologies Stiftung, operates the primary Kusama-facing website and acts as the data controller for ecosystem initiatives related to Polkadot and Kusama. The Foundation's published legal disclosures state that it assumes no liability for the correctness, timeliness, reliability, or completeness of information and that it excludes liability for data transmitted over the internet to the extent permitted by law. Those disclosures reflect the Foundation's active legal, privacy, and data-processing obligations that are subject to Swiss law and, where applicable, to cross-border regulatory requirements in jurisdictions where users access Kusama. Changes to Swiss foundation law, EU data protection regulation, or cross-border AML and securities frameworks could affect Foundation operations, disclosures, or structural obligations.

(Source: Web3 Foundation Legal Disclosures, Kusama Terms, Kusama Privacy Policy)

The DOT token sold in Polkadot's pre-launch period was initially characterized as a security by Web3 Foundation. Web3 Foundation subsequently announced after a process with the U.S. Securities and Exchange Commission that DOT had transformed and was no longer considered a security. KSM, which was distributed proportionally to DOT indicator token holders, has not been the subject of a separate published SEC analysis. The regulatory status of KSM in the United States and other jurisdictions has not been definitively established in the verified public record.

(Source: DOT Morph Announcement)

No Kusama-specific public tax guidance for tokenholders has been published by Web3 Foundation or Parity Technologies. Published legal disclosures state that no information on the relevant sites should be construed as legal or professional advice. KSM tokenholders are responsible for assessing and meeting their own tax obligations in their respective jurisdictions. Staking rewards, governance participation, and secondary-market transactions involving KSM may each carry separate tax treatment depending on the jurisdiction.

(Source: Web3 Foundation Legal Disclosures)

(b) Protocol, Technology & Security Risks

Kusama is an experimental, production-grade network designed to move faster than Polkadot and to carry real economic value. The network's incident history demonstrates that runtime, governance, migration, staking-accounting, and validator-logic defects can cause material disruption on a live, economically active network: a January 2020 runtime error halted the chain and required a rollback; a September 2023 dispute resolution error froze all parachains until governance force_unfroze the chain; a February 2024 disabled-validator dispute bug caused multi-hour finality stalls; a February 2025 staking pallet bug allowed overlapping stake accounting enabling double rewards; a May 2025 validator version mismatch around v2 candidate receipt activation caused an 11-hour finality stall followed by a 23-hour recovery period; an August 2025 parainherent API bug produced a block production stoppage; an October 2025 AHM execution bug caused self-stake to be incorrectly recorded for multiple eras; and an April 2026 proof-verification vulnerability in the BEEFY protocol allowed forged slashing offense reports against Kusama relay-chain validators before the code fix merged.

(Source: Networks, Kusama Timeline, Stalled Parachains Postmortem, Kusama Referendum 263, Kusama Finality Stall Postmortem, Double Staking Reward Bug, Kusama Dispute Storm Postmortem, Kusama Stall Postmortem, Kusama Staking PSA, Asset Hub Migration 2025, Relay Chain Vulnerability Disclosure)

Core Kusama and Polkadot SDK components are covered by the Parity Bug Bounty program. Web3 Foundation engaged Atredis Partners to perform a platform security assessment of the Polkadot runtime. Web3 Foundation's security page states that reported issues may be eligible for rewards at the Foundation's sole and absolute discretion. The Technical Fellowship provides a Whitelisted-Caller path that can accelerate certain high-privilege OpenGov actions while still requiring referendum passage. Validator slashing ranges from 0.01% to 100% of the slashed validator's bond depending on severity, with a 27-day grace period before application. These mechanisms reduce but do not eliminate risk: the incident record confirms that live runtime and validator-behavior failures occurred after code releases and that the April 2026 proof-verification vulnerability remained in production code for approximately 23 months before being disclosed and patched.

(Source: Kusama Bug Bounty, Security Audits, Atredis Security Assessment, Web3 Foundation Security Report, Technical Fellowship, Offenses and Slashes, Kusama Finality Stall Postmortem, Kusama Dispute Storm Postmortem, Relay Chain Vulnerability Disclosure)

(c) Token Economics, Unlocks & Incentive Risks

KSM inflates at 10% annually. The split between staking rewards and the treasury changes dynamically based on the ratio of staked KSM to total supply versus the ideal staking rate. Keeping tokens unstaked imposes an opportunity cost through dilution. Staking rewards increase when the staking rate is below the ideal rate and decrease when it is above it, creating a feedback mechanism that incentivizes participation near the target rate. If participation falls materially below the ideal rate, a larger share of issuance routes to the treasury rather than to stakers, reducing staker yield and potentially affecting validator economics.

(Source: Kusama Inflation Model)

Inflation and all related monetary parameters are governance-adjustable through stake-weighted referenda. Treasury access requires a successful enacted referendum on the relevant treasury track. Governance-approved changes to inflation, staking economics, or treasury outflows could affect tokenholders in ways the market does not anticipate.

(Source: Kusama Inflation Model, Polkadot OpenGov, Treasury)

Executed governance referenda show direct treasury-funded liquidity engineering around KSM markets. Referendum 477 approved a 50,000 KSM treasury liquidity subsidy for 18 months as base liquidity for the KSM-vKSM pair, repayable with interest. Referenda 471 and 480 document a KSM:dUSD pair arrangement in which Brale committed $300,000 of dUSD and KSM Collective contributed $300,000 of KSM, with one proposed structure directing 50% of LP fees to KSM Collective. These arrangements make KSM market structure partially dependent on treasury decisions, third-party execution, and off-chain fee-sharing agreements.

(Source: Kusama Referendum 477, Kusama Referendum 480, Kusama Referendum 471)

This Token Transparency Filing is provided for general informational purposes only and does not verify or warrant the accuracy of individual answers.

Project
OverviewChartsMonitoringToken DisclosuresResearchNewsMarkets
Curious what full access looks like?
Access premium insights on ETH and BTC pages for free.
BTCETH