CLAIMS.yml

last_checked: 2026-06-02
recheck_after: 2026-06-05
claims:
  proof_of_work:
    status: live
    summary: Kaspa is mined Proof of Work.
    source: https://github.com/kaspanet/rusty-kaspa
  utxo:
    status: live
    summary: Kaspa uses a UTXO model; Ethereum uses an account model.
    source: https://github.com/kaspanet/rusty-kaspa
  ghostdag:
    status: live
    summary: GHOSTDAG is Kaspa's live blockDAG ordering rule.
    source: https://research.kas.pa/
  crescendo_10_bps:
    status: live
    summary: Kaspa's Crescendo-era 10 BPS network is live; Michael Sutton framed throughput as roughly 8-9x higher and confirmation-time improvement around 30%, not instant finality or a clean 10x confirmation improvement.
    source: https://github.com/kaspanet/rusty-kaspa/releases
    forbidden_copy:
      - 10 BPS gives automatic 10x finality
      - Kaspa mainnet payments are instantly final
  l1_status_snapshot_2026_06_02:
    status: measurement_sensitive
    recheck_after: 2026-06-05
    summary: A June 2, 2026 L1 status check showed the public Kaspa REST API on kaspa-mainnet, virtual DAA score 449,675,496, 26,167,933 blocks, 2.75 KAS block reward, and about 27.48 billion KAS from the public supply endpoint. Treat these as time-stamped network readings, not timeless constants.
    source: https://api.kaspa.org/info/blockdag
    forbidden_copy:
      - June 2 snapshot values are permanent
      - A public REST API reading is stronger than node or release evidence
  emission_schedule_may_2026:
    status: live_design
    summary: Kaspa's emission schedule steps down monthly. The official schedule shows 27.5 KAS per second beginning May 8, 2026, then 25.9565436 KAS per second beginning June 7, 2026, and 24.49971475 KAS per second beginning July 7, 2026. With the 10 BPS mainnet, the current API block reward is 2.75 KAS per block. Do not describe July 2026 as a one-time emission cliff.
    source: https://kaspa.org/wp-content/uploads/2022/09/KASPA-EMISSION-SCHEDULE.pdf
    forbidden_copy:
      - Kaspa has a July 2026 emission cliff
      - July 2026 suddenly stops Kaspa issuance
  tps_and_speed_context:
    status: measurement_sensitive
    recheck_after: 2026-07-01
    summary: TPS, throughput, and speed claims need measurement context. Distinguish block rate, block capacity, policy limits, lab or testnet throughput, sustained capacity estimates, organic demand, fees, and confirmation confidence before repeating a number as normal mainnet behavior.
    source: https://github.com/kaspanet/rusty-kaspa/releases
    forbidden_copy:
      - testnet TPS is mainnet TPS
      - lab TPS is normal mainnet use
      - real-time means instant irreversibility
  base_rtd:
    status: live_framing
    summary: Kaspa.org now frames real-time decentralization as Kaspa's north star; Hashdag frames RTD first as Kaspa's real-time Bitcoin-style PoW value proposition.
    source: https://kaspa.org/lore
  fair_launch_origin:
    status: narrative_guardrail
    summary: Kaspa's fair-launch origin should be described as source-backed history: PHANTOM/GHOSTDAG research, DAGLabs-era commercialization attempts, Polychain/Accomplice-era VC funding, an April 2021 testnet, failed hardware/presale paths, a messy gamenet-to-mainnet path, and a November 2021 proof-of-work launch with no premine, insider allocation, or pre-sales. The Kaspa Wiki prehistory page estimates the post-launch DAGLabs/Polychain-related early-miner amount at under 3% of supply, 840 million KAS, with its longer note saying probably closer to 2.5% and under 850 million KAS. Treat this as an early-miner estimate, not a premine or exact official allocation table. Fair launch lowers official allocation risk; it does not mean no early core contributors mined, and it does not prove perfect distribution, adoption, price, or future execution.
    source: https://kaspaexplained.com/kaspa-origin-story
    forbidden_copy:
      - DAGLabs and Polychain had a premine
      - Polychain background is irrelevant to Kaspa's launch story
      - Fair launch means no early insiders mined
      - Fair launch proves perfect distribution
  original_kaspad_codebase:
    status: narrative_guardrail
    summary: The safest public wording for the original implementation is that Kaspad was written in Golang and described by Yonatan Sompolinsky's Hashdag archive as an adaptation of the Bitcoin client btcd. Do not state a specific Bitcoin Core version unless a stronger source is added.
    source: https://hashd.ag/raw
  adoption_strategy:
    status: narrative_guardrail
    summary: Fast money and Base of Liquidity language are thesis framing, not an adoption plan by themselves. Generic merchant/POS payments should not be treated as the whole 2026 adoption vector; evaluate useful products, visible on-chain activity, liquidity, coordination-market direction, and durable app usage.
    source: https://x.com/DailyKaspa/status/2052716697262374936
    forbidden_copy:
      - Base of Liquidity is Kaspa's adoption plan
      - Generic merchant payments are Kaspa's killer app
      - Fast payments alone prove adoption
  coordination_markets:
    status: research_direction
    recheck_after: 2026-07-01
    summary: Coordination markets are a highlighted Kaspa product direction in current narrative context, but production systems still need concrete commitment, oracle, settlement, privacy, liquidity, and app-rail designs before being described as live.
    source: https://x.com/DailyKaspa/status/2052716697262374936
    forbidden_copy:
      - Coordination markets are live on Kaspa
      - Staghunt is production-ready on Kaspa
  app_project_claims:
    status: builder_guardrail
    recheck_after: 2026-07-01
    summary: App/project claims are not L1 protocol-status evidence. Igra/Kaskad-style L2 or ecosystem app launches can be useful ecosystem context, but they do not prove native Kaspa L1 smart contracts, Toccata mainnet activation, or mature Kaspa-native DeFi. Mention app projects only when the L1 fact itself matters, such as transaction payload behavior, accepted transaction evidence, or fees paid to miners. Otherwise, leave them out.
    source: https://docs.kaspa.org/integrate/transaction-payload
    forbidden_copy:
      - App activity proves Toccata is live
      - Project tooling proves native Kaspa smart contracts are live
      - A wallet or frontend feature is protocol activation evidence
  toccata:
    status: targeted
    recheck_after: 2026-06-05
    summary: Toccata is a targeted L1 hard-fork track with a public June 5-20, 2026 mainnet window. Kaspa.org Build describes it as live on TN12 ahead of mainnet activation. Rusty Kaspa's tn10-toc2 pre-release scheduled the first Testnet-10 Toccata activation point for May 18, 2026 at 16:00 UTC, DAA score 467,579,632. The tn10-toc3 pre-release scheduled a final TN10 Toccata ZK hardening layer for May 28, 2026 around 16:00 UTC, DAA score 476,232,000. A June 2, 2026 TN10 REST check showed virtual DAA 480,274,326. KIP-16, KIP-20, and KIP-21 are merged and listed as implemented and activated in TN10; KIP-17 remains open. This is testnet and proposal/release evidence, not mainnet activation.
    source: https://github.com/kaspanet/rusty-kaspa/releases/tag/tn10-toc3
    forbidden_copy:
      - Toccata is live
      - TN12 covenant evidence proves mainnet activation
      - TN10 activation proves mainnet activation
      - tn10-toc2 is a mainnet release
      - merged TN10 KIPs prove mainnet activation
  tn10_toccata_activation_test:
    status: testnet_only
    recheck_after: 2026-06-05
    summary: Rusty Kaspa's tn10-toc2 pre-release scheduled the first Toccata hard-fork activation point on Testnet-10 for May 18, 2026 at 16:00 UTC, DAA score 467,579,632. The tn10-toc3 pre-release scheduled final Toccata ZK hardening on Testnet-10 for May 28, 2026 around 16:00 UTC, DAA score 476,232,000. A June 2, 2026 check of the Testnet-10 REST API showed virtual DAA 480,274,326, above both scores. Use this as testnet evidence for the activation path and node behavior, not as proof that Toccata is live on mainnet.
    source: https://github.com/kaspanet/rusty-kaspa/releases/tag/tn10-toc3
    forbidden_copy:
      - TN10 activation proves mainnet activation
      - Testnet-10 Toccata means mainnet Toccata is live
      - tn10-toc2 is a mainnet release
      - tn10-toc3 is a mainnet release
      - TN10 passed the activation score, so Toccata is live on mainnet
  tn12_covenant_evidence:
    status: testnet_only
    recheck_after: 2026-06-05
    summary: >
      The TN12 covenant lab has accepted proof transactions for vault recovery,
      vault delayed withdrawal, assurance release/refund, escrow release/refund/cancel,
      role-separated positive paths (all 7), batch-assurance 3-pledge release, and
      40 payload events, including scheduler-intent, scheduler-bid, scheduler-execution, and scheduler-covenant-binding receipts, plus accepted playground role-wallet funding, two user-to-pool deposits, and one pool-to-user payout. The public results and playground pages explain the evidence and role flow without upgrading it into mainnet or production custody. Adversarial rejection evidence covers 13 cases across 5 mutation
      types (wrong-signer, wrong-selector, wrong-output-lock, wrong-output-amount,
      single-party-cancel) confirmed rejected by the TN12 node with script-level errors.
      All evidence is TN12/Toccata lane only — not mainnet, not Toccata-activated mainnet.
    source: https://github.com/parker2017code/tn12-covenant-vault-demo
    forbidden_copy:
      - TN12 proofs mean covenants are live on mainnet
      - Adversarial rejections prove mainnet covenant enforcement
      - TN12 txids are mainnet txids
  vprogs:
    status: roadmap
    recheck_after: 2026-07-01
    summary: vProgs are roadmap architecture for apps that prove richer logic while sharing Kaspa ordering, including later cross-app atomic composition. They are not a mature live app ecosystem. The public vprogs repo shows April 2026 ZK framework progress, but it remains early framework/prototype evidence.
    source: https://github.com/kaspanet/vprogs
    forbidden_copy:
      - vProgs are live
  cross_app_composition:
    status: roadmap
    recheck_after: 2026-07-01
    summary: Full cross-app actions mean atomic composition, where several app states can succeed or fail as one combined operation. Toccata provides covenant, ZK, sequencing, and based-zk foundations, but same-operation app-to-app composition belongs to later vProgs architecture.
    source: https://medium.com/@michaelsuttonil/kaspa-covenants-toccata-hard-fork-outlook-a4d81a40900c
    forbidden_copy:
      - Toccata enables full cross-app atomic composition
  based_apps:
    status: targeted
    recheck_after: 2026-07-01
    summary: Based apps are the richer-state app lane around Kaspa L1 sequencing, commitments, proofs, settlement, or exits. They can start as deterministic replay over accepted transactions and add based-zk proof checks when verification is required. Direct L1 covenant examples such as vaults, escrow, and assurance do not require an L2.
    source: https://gist.github.com/michaelsutton/5bd9ab358f692ee4f54ce2842a0815d1
    forbidden_copy:
      - Kaspa apps require an L2
      - Based apps are live production Kaspa app rails
      - Every based app is a ZK app
      - A rollup PoC means vProgs are live
  zk_external_anchors:
    status: builder_guardrail
    recheck_after: 2026-07-01
    summary: ZK verification proves a statement about chosen public inputs; it does not by itself prove external-chain canonicality, prices, oracle events, or real-world facts. Bridge and oracle-style apps still need an agreed anchor such as a source-chain light client, finality certificate, accumulated-work view, oracle, reporter set, or challenge process.
    source: https://docs.kaspa.org/programmability
    forbidden_copy:
      - A ZK proof by itself proves what happened on another chain
      - OP_ZK_PRECOMPILE makes any external bridge trustless automatically
  vprogs_solana_like_experience:
    status: roadmap_framing
    recheck_after: 2026-07-01
    summary: Solana-like means a cohesive, Rust-friendly developer and user experience; it does not mean importing Solana execution or making L1 execute every app.
    source: https://www.youtube.com/live/GaJmYV8OHfQ
  native_defi:
    status: roadmap
    recheck_after: 2026-07-01
    summary: Native Kaspa L1 DeFi depends on future Kaspa-native programmability foundations and useful app tooling; it is not live today. Kaskad/Igra-style L2 lending can be described as ecosystem or L2 DeFi context, but it is not evidence that native Kaspa L1 DeFi, Toccata mainnet, or vProgs are live. Do not describe the pending L1 path as Ethereum-style or EVM-compatible execution unless a primary source adds that support.
    source: https://kaspaexplained.com/why-kaspa-matters
    forbidden_copy:
      - Native DeFi is live
      - A mature live Kaspa-native app ecosystem already exists
      - Kaspa has live EVM-compatible L1 contracts
      - Kaskad proves native Kaspa L1 DeFi is live
      - Kaspa is waiting for Ethereum-style L1 smart contracts
      - Ethereum-style native app execution is planned on L1
      - live EVM-style L1 execution
  dagknight:
    status: research
    recheck_after: 2026-07-01
    summary: DAGKnight is a parameterless/adaptive consensus upgrade direction after Toccata, not current mainnet behavior. The public rusty-kaspa dagknight branch is implementation/prototype evidence, not activation evidence.
    source: https://kaspa.org/lore
    forbidden_copy:
      - DAGKnight is live
      - Kaspa has instant finality
  one_hundred_bps_partition_resilience:
    status: research
    recheck_after: 2026-07-01
    summary: Kaspa.org places 10 millisecond blocks, 100 BPS work, and partition-resilient local payment flows in a proposed 2027 hard-fork bucket. Treat this as roadmap/research until specifications, code, releases, and activation evidence exist.
    source: https://kaspa.org/lore
    forbidden_copy:
      - Kaspa is 100 BPS today
      - Partition-resilient payments are live
      - DAGKnight lets transactions confirm during a netsplit today
  dagknight_latency_policy:
    status: research
    recheck_after: 2026-07-01
    summary: DAGKnight latency settings should be reasoned from adversarial or worst-case latency assumptions. Smooth observed network latency is not enough.
    source: https://www.youtube.com/live/GaJmYV8OHfQ
  pruning_and_missing_history:
    status: live_design
    summary: Kaspa's consensus tracks UTXO state; spent transaction history may be pruned or absent from explorers, and that does not make Kaspa a privacy chain.
    source: https://www.youtube.com/live/GaJmYV8OHfQ
  rtd_derived_systems:
    status: research
    recheck_after: 2026-07-01
    summary: RTD-derived oracle, TangVM, miner attestation, and coordination-market flows are downstream research or architecture ideas.
    source: https://hashd.ag/raw
    forbidden_copy:
      - TangVM is live
      - Kaspa oracle flows are live