Kaspa
Networks · Layer-1Token Transparency Filing
Project & Team
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
Kaspa is a proof-of-work Layer-1 transaction network built to address the throughput and settlement-speed limitations of linear blockchain architectures while preserving Bitcoin-style security and decentralization. It accomplishes this through a blockDAG (Directed Acyclic Graph) structure governed by the GhostDAG/PHANTOM consensus protocol, which enables parallel block creation and ordering rather than a single sequential chain.
(Source: About Kaspa, Kaspa Features, PHANTOM GHOSTDAG)
(b) Operational priorities
Development and operations are community-led and funded through open Discord votes, community crowdfunding, and a Dev Fund structure. The community funded the Rust rewrite (100,000,000 KAS raised via a 3/6 multisig committee) and DAGKnight implementation (70,000,000 KAS raised). The Dev Fund wallet is administered by four publicly voted treasurers (msutton, Tim, The SheepCat, and demisrael) operating a 2/4 multisig, with all spendings published in the Discord #devfund channel and executed according to results of public votes in the #funding-pools or #votes channels.
(Source: Kaspa's Community Governance, Contributors, Kaspa Wiki – Funding Process)
(c) High-level project overview
Kaspa is a proof-of-work blockDAG where all mined blocks are included immediately in the ledger and ordered through the GhostDAG protocol. The Crescendo hardfork transitioned the network from 1 block per second to 10 blocks per second on May 5, 2025. The upcoming Toccata hardfork, with mainnet activation scheduled for June 5–20, 2026, introduces native KRC-20 tokens, programmable transaction rules via SilverScript covenants, and zero-knowledge verification at the base layer.
(Source: rusty-kaspa, Kaspa Home, Toccata Hardfork coverage)
(d) Primary token functions
KAS is the native Layer-1 proof-of-work coin. It is used to pay transaction fees (currently 0.0001 KAS per UTXO), compensate miners via block rewards under the published emission schedule, and serve as the network's unit of account. KAS does not support staking or governance-weighted voting.
(Source: Tokenomics, Emission, and Mining, Messari – Kaspa)
(e) Control surface reliance
The core Kaspa protocol has no central legal entity, no foundation controlling the codebase, and no formal on-chain governance mechanism. Protocol upgrades and funding decisions are made through community discussion and Discord votes. The Dev Fund multisig (2/4) is the primary administrative control surface. Adjacent ecosystem organizations — the Kaspa Eco Foundation (KEF), which appointed DWF Labs as market maker beginning 2025, the Kaspa Industrial Initiative Foundation (Kii, a Dutch foundation), and the Kaspa Alliance for Transparency (K.A.T. Foundation) — operate independently of the core project. DAGLabs and Polychain Capital both waived all Kaspa intellectual property rights prior to the November 2021 fair launch.
(Source: Kaspa Home, Media Kit, KASPlex FAQ, Kaspa Wiki – DAGLabs, Kaspa Eco Foundation / DWF Labs appointment, Kaspa Industrial Initiative Foundation)
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 |
|---|---|---|---|
Yonatan Sompolinsky | Labs | Founder | Post-doctoral researcher at Harvard University researching transaction ordering protocols and MEV; DAGLabs founder; co-inventor of the GHOSTDAG protocol with Professor Aviv Zohar. |
Michael Sutton | Labs | Core Developer | Distributed systems researcher; M.Sc. in computer science from Hebrew University, where he researched parallel algorithms and distributed systems. |
Shai Wyborski | Labs | Kaspa Researcher | Co-author of the GHOSTDAG paper; Ph.D. candidate at Hebrew University and Ben-Gurion University researching classical and quantum cryptography. |
Mike Zak | Labs | Core Developer | Cryptocurrency and distributed systems developer. |
Blockworks note: Labs/DevCo |
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
No DAO legal entity owns or controls Kaspa IP. Non-code content on the official website is licensed under CC BY 4.0 and code content is licensed under MIT. The media kit states that the KASPA logo must not be edited, distorted, recolored, or reconfigured. DAGLabs and Polychain Capital both waived all intellectual property rights to the project prior to launch. No public source identifies any entity as current trademark or repository owner beyond these open-source license terms.
(Source: Terms & Conditions / Privacy Policy, Media Kit, Kaspa Wiki – Prehistory)
(b) Contract/admin powers
No formal DAO wrapper or on-chain governance executor exists. The operative administrative control surface is the community Dev Fund: a 2/4 multisig wallet administered by four Discord-voted treasurers (msutton, Tim, The SheepCat, and demisrael), with spending authorized by majority Discord vote in #funding-pools or #votes channels and published in #devfund. The Rust rewrite fund used a separate 3/6 multisig administered by a Rust Committee elected by Discord vote.
(Source: Contributors, Kaspa Wiki – Funding Process)
(c) Locked-token rights (conditional)
No token-locking or staking mechanism exists that grants additional governance rights. Kaspa uses proof-of-work mining and does not support staking.
(Source: Kaspa's Community Governance, Messari – Kaspa)
(d) Value accrual & holder rights
No public mechanism has been identified by which KAS tokenholders receive protocol revenue, treasury distributions, or fee-sharing. KAS holders receive no disclosed programmatic claim on network fees or community treasury assets.
(e) Dissolution authority
No formal dissolution mechanism has been identified for the community governance structure. The project has no legal wrapper, DAO charter, or documented wind-down procedure.
Blockworks note: The project does not operate a DAO or formal on-chain governance system. The answers below reflect the community governance structure that exists in practice.
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.
(f) Current economic arrangements and distribution policies
Blockworks note: The project does not operate a launch-era primary foundation. Items (a) through (f) do not apply.
DAGLabs, the historical development company, dissolved shortly after the November 7, 2021 fair launch. No successor foundation entity was involved in KAS issuance. Three independent adjacent ecosystem organizations (KEF, Kii, K.A.T. Foundation) exist but were not involved in KAS issuance and are expressly independent of the core project.
(Source: The Kaspa Founding Contributors, Media Kit, KASPlex FAQ, Kaspa Wiki – Prehistory)
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.
(f) Current economic arrangements and distribution policies
Blockworks note: The project does not operate a current primary DevCo. Items (a) through (f) do not apply.
DAGLabs, founded in 2018 and funded with approximately $8,000,000 from Polychain Capital (lead), Accomplice, and Genesis Mining, was the historical development company. It dissolved in mid-2021 before the November 7, 2021 mainnet launch. Both DAGLabs and Polychain Capital waived all intellectual property rights to Kaspa at dissolution. No successor DevCo legal entity has been identified in public materials. The official rusty-kaspa repository is published under the MIT license with no legal entity identified as owner.
(Source: The Kaspa Founding Contributors, Kaspa Wiki – Prehistory, Kaspa Wiki – DAGLabs, Media Kit, rusty-kaspa, Terms & Conditions / Privacy Policy)
Token Supply & Allocations
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
Kaspa launched on November 7, 2021 with no pre-mine, no pre-sale, and no pre-allocation. Zero tokens were distributed at launch outside of open mining. The pre-deflationary issuance phase began at mainnet start with random block rewards of 1 to 1,000 KAS per block for the first approximately two weeks, then settled at 500 KAS per second after the first hard fork. All supply has entered circulation through open proof-of-work mining since that date.
(Source: Kaspa's Fair Launch, Tokenomics, Emission, and Mining, TOKENOMICS)
(b) Recipient categories & use of funds
No pre-allocated recipient categories exist. All KAS has been issued through open proof-of-work mining under the published block-reward schedule. There are no insider, team, investor, foundation, or ecosystem reserve buckets.
(Source: Kaspa's Fair Launch, Tokenomics, Emission, and Mining, TOKENOMICS)
(c) Initial price per token (if applicable)
No fixed public offering price was set. Kaspa launched with no ICO, no pre-sale, and no coin allocations. Price was determined by open market mining and exchange activity from day one.
(Source: Kaspa's Fair Launch, TOKENOMICS)
(d) Ticker / market symbol
KAS
(Source: Kaspa Home)
(e) Total supply & supply regime
Maximum supply is 28,704,026,601 KAS. Supply is not fixed at a static amount but approaches that cap through a continuously decreasing emission schedule. Block rewards decrease monthly by a factor of (1/2)^(1/12), producing an effective annual halving. As of June 2026, approximately 27.5 billion KAS are in circulation, representing approximately 95.8% of the maximum supply. The remaining approximately 1.2 billion KAS will be mined through an emission curve extending to approximately 2037 for economically meaningful rewards, with the block reward falling below 1 Sompi (the smallest indivisible unit) approximately 36 years from mainnet start at the current 10 BPS rate. Once mining emissions conclude, the protocol transitions to a fee-based miner reward model.
(Source: Tokenomics, Emission, and Mining, TOKENOMICS, Tokenomist – Kaspa, KuCoin – KAS)
(f) Initial vesting / release schedules
No vesting schedules exist and no categories are subject to vesting. All KAS supply enters circulation through open mining under the published emission curve. No insider, team, or investor allocations were made at launch.
(Source: Tokenomics, Emission, and Mining, TOKENOMICS)
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").
-
Executed airdrop: One exchange-promotional airdrop was executed subsequent to launch: on September 27, 2022 at 10:30 UTC, MEXC and Kaspa ran an M-Day marketing event distributing 3,570,000 KAS to eligible MEXC users. The covered segment was MEXC futures traders who executed at least 10,000 USDT in USDT-M futures volume during the designated trading period. Allocation used a lucky-draw ticket system, with higher trading volume yielding more tickets. No per-address dataset from this distribution has been identified in public sources.
(Source: Kaspa FAQ, Kaspa Trading schedule on MEXC Released)
-
No airdrop planned or conducted: No TGE airdrop has ever been conducted and the project does not plan to execute one. Kaspa had no token allocation at launch and therefore conducted no per-address TGE airdrop distribution.
Transactions & Market Structures
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: DWF Labs (appointed by KEF, effective 2025)
- Token Allocation Committed: Not publicly disclosed
- Term Duration: Not publicly disclosed
- Structure Name: Not publicly disclosed
Blockworks note: The Kaspa Eco Foundation (KEF) appointed DWF Labs as one of the market makers for KAS beginning in 2025. The material terms of that agreement — including any token allocation or loan, agreement duration, and agreement structure — have not been publicly disclosed. No other market-maker agreements have been identified in public sources for the core Kaspa project.
Material terms of the DWF Labs market-making arrangement, including token allocation or loan amount, duration, and financial vehicle (loan, option, retainer), have not been publicly disclosed by KEF or DWF Labs.
(Source: Coindar – Kaspa Partners With DWF Labs, ChainCatcher, DWF Labs on X)
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: Community-voted crowdfunds were raised to support listings on Gate.io and MEXC. Material terms of those arrangements — including token allocations, lockup durations, liquidity program terms, and any native-token listing fees — have not been publicly disclosed.
(Source: Kaspa's Community Governance)
Financial Disclosures & Risks
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.").
Blockworks note: No prior token sales occurred. Kaspa had no ICO, no SAFT, no SAFE, no OTC sale, and no discounted market-maker token sale. DAGLabs raised approximately $8,000,000 from Polychain Capital (lead), Accomplice, and Genesis Mining between 2018 and mid-2021 as equity or research funding for the development company, not as a token sale. DAGLabs and Polychain Capital waived all intellectual property rights to Kaspa before the November 7, 2021 launch. No KAS tokens were sold as part of that fundraising.
(Source: Kaspa Wiki – Prehistory, Kaspa Wiki – DAGLabs, Messari – Kaspa, CoinMarketCap – Kaspa)
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
2022-09 — Kaspa mainnet consensus layer (kaspad node software, Go implementation).
(b) Exploit vector summary
A vulnerability in the transaction signature-operation count (sig_op_count) handling was identified in the Go kaspad codebase. The attack vector bore similarity to Bitcoin transaction malleability but operated in reverse: the sig_op_count field was not included in the transaction hashing process, creating the theoretical ability to net-split non-upgraded nodes from upgraded ones or to conduct transaction-level attacks requiring insider knowledge of the consensus codebase. The vulnerability was identified internally during the Rust rewrite process, which served as an audit.
(c) Quantified impact
No funds were lost. The vulnerability was patched before exploitation.
(d) Remediation/response taken
Core developer Michael Sutton published a post-mortem on September 30, 2022. The fix was deployed in two phases: an interim mitigation and a permanent hard fork at DAA score 27,905,000, which activated on September 28, 2022 at 09:20 UTC. The fix was shipped in kaspad version 0.12.7. The hard fork required a supermajority of nodes to upgrade rapidly to prevent net-split risk during the transition window.
(e) Current status
Resolved. The patched consensus rules have been in effect since September 28, 2022. The network subsequently migrated to the Rust rusty-kaspa implementation, which eliminated the Go codebase where the vulnerability existed.
(f) References (optional)
(Source: Kaspa Security Patch and Hard Fork – September 2022, kaspad v0.12.7 release)
Blockworks note: One protocol-level security incident has been publicly disclosed.
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
The official Kaspa terms state that access to Kaspa websites and services may not be legal for certain persons or in certain countries and that users are responsible for compliance with local laws. Regulatory changes in any jurisdiction could restrict public access to Kaspa services, affect exchange listings, or impose compliance obligations on ecosystem participants. The core project has no legal entity, while adjacent organizations (KEF, Kii, K.A.T. Foundation) operate in separate jurisdictions, meaning regulatory action could fall unevenly across these distinct entities. Users in all jurisdictions bear sole responsibility for determining whether acquiring, holding, mining, or transacting in KAS complies with applicable laws and for satisfying their own tax obligations. The project has made no representations regarding how tokenholders will be taxed in any jurisdiction.
(Source: Terms & Conditions / Privacy Policy, Media Kit, KASPlex FAQ)
(b) Protocol, Technology & Security Risks
The official Kaspa terms warn users of risks including financial loss, blockchain technology failures, hacking, and technical difficulties that may take days, weeks, or months to resolve or may not resolve. Kaspa's recommended node software is the Rust rusty-kaspa implementation; the Go codebase has been deprecated. The Crescendo hardfork raised throughput from 1 to 10 blocks per second as of May 5, 2025, and the Toccata hardfork introducing native KRC-20 tokens, SilverScript covenants, and zero-knowledge verification is scheduled for mainnet activation June 5–20, 2026. Each major protocol upgrade introduces implementation risk, including the potential for consensus bugs, chain-split risk if nodes and mining pools fail to coordinate upgrades, denial-of-service vectors from new opcode paths, and tooling gaps across wallets and indexers. No formal public bug bounty program or third-party audit of the rusty-kaspa codebase has been identified in public materials.
(Source: Terms & Conditions / Privacy Policy, rusty-kaspa, Kaspa Features, Toccata hardfork coverage)
(c) Token Economics, Unlocks & Incentive Risks
Kaspa launched with no ICO, no vesting phase, no premine, no pre-sales, and no coin allocations. The maximum supply is 28,704,026,601 KAS. Approximately 27.5 billion KAS (approximately 95.8% of max supply) are in circulation as of June 2026, with the remaining supply to be mined through a continuously declining emission curve extending to approximately 2037. Annual block reward halving occurs through monthly reductions of factor (1/2)^(1/12). As block rewards approach zero, miner compensation transitions to transaction fees alone. Protocol security under a fee-only model depends on sustained blockspace demand sufficient to make mining economically viable. KAS does not support staking, so no staking-yield assumptions factor into the security model.
(Source: Tokenomics, Emission, and Mining, TOKENOMICS, Kaspa's Fair Launch, KuCoin – KAS, Tokenomist – Kaspa)
This Token Transparency Filing is provided for general informational purposes only and does not verify or warrant the accuracy of individual answers.
