Proposal tracker
KIPKaspa Improvement Proposal: specifies, reviews, merges a protocol change.s and KCCs
A KIP changes consensus. A KCC is a builder encoding agreement, no consensus change: its README says it, "KCCs do not propose changes to Kaspa consensus or core-node behavior." A merged, Active KIP is law; an open KCC PR is still argued.
Kaspa Improvement Proposals
15 total, 11 Active. Implemented: running. Active: merged and adopted. Proposed/Draft: still open. Rejected: turned down.
KIP 1–6, the foundational batch (2 of 6 active)
| KIP | Title | Layer | Status |
|---|---|---|---|
| 1 | Rewriting the full node in Rust | Consensus, Node | Implemented |
| 2 | Upgrade consensus to follow DAGKNIGHT | Consensus, API/RPC | Proposed |
| 3 | Block sampling for efficient DAA with high BPS | Consensus | Rejected |
| 4 | Sparse difficulty windows | Consensus | Active |
| 5 | Message signing | Applications | Active |
| 6 | Proof of Chain Membership | Consensus, Applications | Draft |
KIP 9–15, consensus and script-engine expansion (5 of 5 active)
| KIP | Title | Layer | Status |
|---|---|---|---|
| 9 | Extended mass formula for mitigating state bloat | Consensus, Mempool, P2P | Active |
| 10 | New transaction opcodes for enhanced script functionality | Consensus, Script Engine | Active |
| 13 | Transient storage handling | Consensus | Active |
| 14 | The CrescendoThe May 2025 upgrade that sped Kaspa's mainnet from one block a second to ten. hardfork | Consensus | Active |
| 15 | Canonical transaction ordering and sequencing commitments | Consensus | Active |
KIP 16–21, the Toccata batch (4 of 4 active)
| KIP | Title | Layer | Status |
|---|---|---|---|
| 16 | ZK precompile opcode | Consensus, Script Engine | Active |
| 17 | CovenantsA rule attached to a coin that the network itself checks on every spend, not a server's promise. and improved scripting capabilities | Consensus, Script Engine | Active |
| 20 | Covenant IDs | Consensus, Script Engine | Active |
| 21 | Partitioned sequencing commitment with O(activity) proving | Consensus, Chain-Block UTXO Validation | Active |
Baseline: KIP repository, 27 October 2026; table refreshes live on load.
KIPs 16, 17, 20, 21 were marked Active in the repository on 15 July 2026, after Toccata mainnet activation: KIP-16, KIP-17, KIP-20, KIP-21.
KIP-2, the DAGKnight upgrade, has stayed Proposed for years: devnet only, no date; demo below runs it against GHOSTDAG. KIPs 7, 8, 11, 12, 18, 19, 22-25 are open PRs, hence the table gaps. Repository.
Try it
A margin fixed in advance, against one that tracks the network
A marginBlocks arriving at once before one looks like an attack. The paper calls it k., too low, rejects honest blocks; too high wastes time.
10 blocks per second (Kaspa mainnet's Crescendo-era rate)
Runs past mainnet's rate on purpose.
rusty-kaspa ships a lookup table that stops at 32 blocks per second. The formula behind it runs at any rate; the table is the limit, not the math. Push λ up while D stays fixed and PHANTOM's own confirmation time under attack grows exponentially in the paper's own bound, the harder reason to stop, not a shrinking security threshold: that decay is Nakamoto Consensus's problem, not PHANTOM's.
Assumed worst case: 5.0 s (mainnet's real setting) → margin needed: 124 blocks (mainnet's real margin)
5 s is rusty-kaspa's own
NETWORK_DELAY_BOUND constant (consensus/core/src/config/constants.rs, checked 2026-08-25). KIP-14, the Crescendo hardfork, sets D = 5, δ = 0.01 and states the resulting margin is "recalculated to be 124." Neither number is a choice this page made; both are what mainnet runs today.
0.5 s (margin this actually needs: 18 blocks)
Not a measured figure.
No published measurement of Kaspa's real block propagation exists to cite, so 0.5 s opens as a representative assumption, not a measured figure; real propagation varies with peer distance and network load. Move the slider or pick a scenario below.
10%
Hypothetical, not observed.
Mainnet has no known attacker; this dial imagines one so the guarantees below mean something. 10% opens as a serious but not fringe threat, below the 50% share both formulas assume never happens.
GHOSTDAG Live · fixed margin Fixed table, stops at 32 bps.
margin it is configured for
margin these conditions need
Worst case, guaranteed
The DAG KNIGHT paper's own no-visible-attack bound (§1.5.2), computed at a stated 1% error tolerance. Uses Dmax, the assumed delay set by the D slider above, held fixed regardless of what the network is actually doing.
No honest block looks like an attack at this delivery speed.
DAGKnight Research · adjustable margin Tracks actual latency.
margin it is running right now
Worst case, guaranteed
The same DAG KNIGHT no-visible-attack bound (§1.5.2) as GHOSTDAG's, at the same 1% error tolerance. Uses Dt, the actual-latency slider above, tracked instead of assumed in advance.
Nobody has to retune this by hand when the network slows down.
Neither number above is what a payment waits for. Both bound the worst case.
A transaction is typically included in about a second. Inclusion lands a tx; confirmation is when reversal stops being a risk (demo). Figure: What is Kaspa?
DAGKnight: calm versus under attack Research
Same formula, same dials: DAGKnight against itself, no visible attack against one visibly under way.
No visible attack
Every block looks honest right now.
predicted wait
Attack visibly under way
An attacker is actively forking the DAG.
predicted wait
What this costs
Not shipped, not parameter-free, efficiency unsolved.
Caveats and sources
| Caveat | Detail |
|---|---|
| Not shipped | KIP-2 remains Proposed. The unmerged dagknight branch was still active through its 8 September 2026 head, ad45e241; no Rusty Kaspa release activates it, and mainnet remains GHOSTDAG. |
| Not actually parameter-free | The paper still requires a client-set bound D covering the latency an attacker could cause, not what the network currently shows (Pass-Shi, Theorem 14). A calm network doesn't license a low D. |
| A visible attack doesn't slow every payment | A transaction with no visible conflicting spend still confirms on the optimistic timeline above even while the pessimistic case plays out elsewhere in the DAG (§4, footnote 14). |
| Efficiency is unsolved | KIP-2 itself lists DAGKnight's pseudocode as "highly inefficient" and its rewrite unfinished, a stated reason this is still research four years on. |
| The 32-BPS ceiling belongs to GHOSTDAG, not DAGKnight | rusty-kaspa's Bps<BPS>::ghostdag_k() is a hardcoded match on precomputed values for 1 through 32; past that the fallback arm reads panic!("see gen_ghostdag_table for currently supported values") (consensus/core/src/config/bps.rs, checked 2026-08-22). |
| Which is why the slider keeps going | GHOSTDAG needs a k chosen in advance for a given rate; past 32 means computing a new k and hard-forking. Removing that a priori k is KIP-2's whole premise, so DAGKnight has no table to run out of. |
| The upper range is not a target | KIP-2 lists the optimal block rate as open research, no number recommended. The repeated "100 blocks/sec, netsplit-resilient" figure traces only to kaspa.org's marketing pages, unconfirmed by any KIP, release, or core-contributor statement. |
| No published cost figure, but real efficiency work | Contributor coderofstuff (106 of the 129 commits the dagknight branch holds beyond master) builds the UMC-voting redesign on personal fork branches, then merges into kaspanet's own dagknight branch; dk-umc-proposed merged August 14, 2026. |
| The write-up explaining it isn't kaspanet's | It names KIP-2's "highly inefficient" bottleneck: the paper's recursive UMC-voting algorithm at O(n squared) worst case, with an O(n times K) amortized replacement proposed, on an unofficial personal wiki. The code is real, unmerged to master, not the shipped algorithm. |
Model, formula, and citations
| Topic | Explanation |
|---|---|
| GHOSTDAG's k | rusty-kaspa's own derivation: k = min k̂ such that P(anticone > k̂) < δ, from x = 2·D·λ (D = assumed max delay, λ = blocks/second) via a Poisson-tail sum. Mainnet's constants are NETWORK_DELAY_BOUND = 5s and GHOSTDAG_TAIL_DELTA = 0.01 (consensus/core/src/config/{constants,bps}.rs). At λ = 10, D = 5s, k = 124, matching bps.rs's table (below). |
| Does a higher block rate lengthen confirmation? | Yes, per the paper (§1.2): "many blocks are created in parallel, blocks suffer from larger anticones, and transactions take longer to confirm," adding "Kaspa's convergence time remains in the order of tens of seconds even when its latency is way below 10 seconds." |
| The guarantee readouts | Compute the paper's no-visible-attack bound (§1.5.2), O((ln(1/ε)/λ + D)/(1−2α) + D²λ), at ε = 0.01, growing with λ at fixed D. The fixed side substitutes Dmax (the D slider); the adaptive side substitutes Dt (the actual-latency slider): that's the whole difference between the two readouts. |
| Sompolinsky's "about 8x," reproduced without inventing a constant | On moving from 10 to 100 blocks a second under GHOSTDAG (Bitcoin Takeover S17 E36, 31:06): "confirmation of transactions will take tens of seconds at least, about 8x long." At a fixed 2 s delay the bound above gives 43 s at ten blocks a second, his "tens of seconds," and 402 s at 100, a 9.3× increase. |
| A second, independent check | With D fixed at 5 s, the margin formula verified against bps.rs takes k from 124 blocks at 10 per second to 1,074 at 100, an 8.66× increase. Ten blocks buys ten times the speed only if k stays fixed, and GHOSTDAG's own proof forces k up with λ. |
| Table 1, transcribed | The paper compares four ordering rules' asymptotic convergence time, in blocks (multiply by λ⁻¹ for seconds). Dmax is an a priori worst-case latency bound fixed in advance; Dt is a bound on current, recent latency (table below). |
| SPECTRE's "does not converge" | Why it isn't a candidate: it solves only "weak liveness," not the general consensus problem KNIGHT solves (§1, closing paragraph). |
| PHANTOM's Dmax versus Dt | PHANTOM converges only in terms of Dmax, a worst-case latency chosen in advance, rather than the current Dt that KNIGHT and SPECTRE track (§4: PHANTOM "converges in terms of Dmax = D only"). |
| The gauges | Come from GHOSTDAG's own anticone-tolerance formula, verified against rusty-kaspa's compiled table. This page reads the paper's Figure 4 shape rather than simulating DAGKnight's k-cluster selection; the worst-case bound one click down leaves its constant c unstated in the paper, so that side is a rough shape. |
| bps | 1 | 2 | 5 | 10 |
|---|---|---|---|---|
| k (D = 5 s) | 18 | 31 | 67 | 124 |
| Protocol | Visible attack | No visible attack |
|---|---|---|
| Nakamoto Consensus | O((ln(1/ε) + Dtλ) / max{0, (1−α)/(1+Dtλ) − α}) | same, asymptotically |
| PHANTOM | O(exp(c₁·Dmaxλ/(1−2α)) + ln(1/ε)/(1−2α)) | O((ln(1/ε) + Dmaxλ)/(1−2α)) |
| SPECTRE | does not converge | O((ln(1/ε) + Dtλ)/(1−2α)) |
| KNIGHT | O(exp(c₂·Dtλ/(1−2α)) + ln(1/ε)/(1−2α)) | O((ln(1/ε) + Dtλ)/(1−2α) + (Dtλ)²) |
| Source | Detail |
|---|---|
| Sompolinsky & Sutton, "The DAG KNIGHT Protocol" | IACR ePrint 2022/1494, rev. 24 Feb 2023 (version history). §§1.2, 1.3, 1.4, 1.5.2, Theorem 14, Figures 3 to 4. |
| Sompolinsky, Bitcoin Takeover | S17 E36 (31:06). Episode page unlocatable as of 24 Aug 2026; show listing linked instead. |
| KIP-2 | Status: Proposed. No technical revision since 30 Nov 2022. |
| rusty-kaspa | bps.rs, params.rs, constants.rs, checked 2026-08-22. |
| kaspanet/rusty-kaspa | dagknight commit log, checked 2026-08-22. |
| Unofficial | coderofstuff/rusty-kaspa, dk-wiki, checked 2026-08-22. |
Conventions
Kaspa Calls for Conventions
Builder agreements on encoding. Five documents are merged. The KCC-0 process document is Final after PR #25 merged. On 21 October 2026 KCC-1, KCC-2, and the KCC-20 token standard moved to Final (PR #39, PR #40, PR #41). KCC-23, a metadata convention, merged as Draft on 14 October. Final means builders agreed on a shared format. It is not a consensus rule, and each wallet or app still has to adopt it.
The five merged KCCs and their status
| Proposal | Opened | State |
|---|---|---|
| KCC-0 KCC purpose, format, lifecycle and finalization criteria | 2026-08-25 | Merged, Status: Final |
| KCC-0001 covenant definition, concepts, byte layout and ABI | 2026-07-15 | Merged, Status: Final (21 Oct 2026) |
| KCC-0002 authority schemes for program ABIs | 2026-07-20 | Merged, Status: Final (21 Oct 2026) |
| KCC-0020 fungible token covenant specification | 2026-07-15 | Merged, Status: Final (21 Oct 2026) |
| KCC-0023 metadata JSON bound to a covenant ID | 2026-09-12 | Merged 14 Oct 2026, Status: Draft |
Open pull requests (7)
| Proposal | Opened | State |
|---|---|---|
| KCC-0402 covenant payment channels | 2026-07-19 | Open pull request |
| KCC-12 | 2026-09-11 | Open pull request |
| Reputation, bond, and identity registry covenants | 2026-09-21 | Open pull request |
| Mobile wallet session and pairing API (unnumbered KCC) | 2026-10-02 | Open pull request |
| Covenant v2 initial draft | 2026-10-03 | Open pull request |
| Pay-to-public-key-hash via P2SH | 2026-10-19 | Open pull request |
| KCC-3 hierarchy for HD wallets | 2026-10-20 | Open pull request |
The KCC-0402 author cites k402 and live mainnet payment channels. The open proposal does not establish a Final convention or broad adoption.
Closed without merging
| Proposal | Opened | State |
|---|---|---|
| KCC-0021 token metadata | 2026-07-23 | Closed 25 Sep 2026; no KCC-21 merged |
| KCC-20 conformance vectors | 2026-08-29 | Closed 27 Sep 2026; this PR did not merge |
| KCC-2 ECDSA schemes | 2026-09-02 | Closed without merging |
| KCC-0008 through KCC-0024 multi-token, token, and commerce standards | 2026-07-25 | Closed, not merged (three attempts) |
| KCC-0025 license agreement | 2026-07-28 | Closed, not merged |
Baseline: KCC repository, 27 October 2026. The checked fallback and client fetch cover open PRs; merged lifecycle labels remain separately sourced from the files and repository index.
KCC-0001 defines a covenant's byte layout. Covenant breaker demo: attacks a vault, shows the stopping rule.
KCC-0020 is Final as of 21 October 2026, and it now ships conformance test vectors. Its Final text treats extension_commitment as part of fungibility: the standard transfer combines only states with identical commitments.
Try it
Why two states do not consolidate
You and Sam hold cells with different extension commitments. The standard transfer treats them as different fungibility classes.
A made-up token; the standard is real, this token is not.
You
Sam
9 coins. One shared supply.
With the same extension commitment, the standard transfer can combine these cells.
Different fungibility classes require matching extension commitments for the standard transfer.
What the spec's own authors said about this
A fictional stand-in for KCC-0020: the standard transfer combines cells only when their extension commitments match.
“My view is that the combination of extended state, alongside token-specific entry points, allows for various use cases which are not only write-once, nor only for a singleton token. The standard transfer function, though, is meant to transfer fungible tokens, hence, it assumes that inputs and outputs state (excluding ownership and amount) must be identical (or else could not be treated as fungible)” Sivan Helfer (Manyfestation), KCC-0020 co-author · github.com/kaspanet/kccs/issues/14
“I can relate bcs example extensions that come to mind indeed illustrate this. for instance a frozen bool indicator which can be used by stable coin issuer for black listing, indeed renders the token as temporarily non fungible.”
Michael Sutton, KCC-0020 co-author · github.com/kaspanet/kccs/issues/14
“I had one conceptual exception, but I think it means it's a wrong pattern. The example would be some contract using the ext state for storing receipt-like information… It mutates all the time but isn't part of the state that matters. I guess this pattern only makes sense if it was well defined as part of the std, and not as an opaque virtual state” Michael Sutton, KCC-0020 co-author · github.com/kaspanet/kccs/issues/14
“I agree that kind of pattern should either be defined in the standard or implemented in a non state storage (maybe the payload, as you once suggested).” Sivan Helfer (Manyfestation), KCC-0020 co-author · github.com/kaspanet/kccs/issues/14
PR #16 merged on 27 August 2026 and made identical extension_commitment a condition of fungibility for the standard transfer. Issue #14's reporter said the discussion cleared up the model and that neither proposed fix was right. KCC-0020 became Final on 21 October 2026 with this rule intact.
| Open question or boundary | What it does to a token | Where it stands |
|---|---|---|
| Distinct fungibility classes | The standard transfer refuses to consolidate inputs whose extension commitments differ and preserves the commitment. | PR #16 merged 27 Aug 2026; issue #14 remains open for clarification |
| Partial conformance | The only production implementer calls its deployed KCC20V2 "partially aligned, not fully conforming." | Issue #11, closed by its author 22 Aug 2026, statement not withdrawn |
| Forking templates | One launchpad's 74 live tokens span four template generations with no migration path, only burn and reissue. | kas-smiths.org, 0xKnitser, 15 Aug 2026 |
| No common metadata convention | Name, ticker and image lived off-chain in one launchpad study. Of 19 logos, 5 were dead within days and 3 more served HTML. | KCC-0021 closed 25 Sep; KCC-23 merged as Draft 14 Oct for general metadata binding |
| Borrowed receive | Anyone can change your coin's outpoint, which invalidates a pre-signed spend and forces a rebuild. | kas-smiths.org, Shawn, 10 Jul 2026; no fix merged |
The source record behind each boundary
| Topic | Thread |
|---|---|
| Distinct fungibility classes | Issue #14 opened 21 August over extended-state consolidation. Authors clarified that different commitments intentionally define different fungibility classes; the reporter then said neither proposed fix was right and shifted to wording and indexer questions. PR #16 merged 27 August to encode the standard-transfer rule. The issue remains open. |
| Partial conformance | Issue #11 (KaspaCom, opened 26 Jul 2026): the only production KCC implementer stating conformance in writing, its deployed KCC20V2 "should be described as partially aligned, not fully conforming" with KCC-0001, 0002, 0020, 0021. Closed 22 Aug 2026 after the KCC-0021 author explained its metadata layer is behavior-independent; that answers the question but doesn't withdraw the statement. |
| Forking templates, and metadata | One launchpad's 74 live tokens span four template generations with no migration path, only opt-in burn and reissue (kas-smiths.org, 0xKnitser, 15 Aug 2026). The KCC-0021 proposal closed without merging on 25 Sep 2026, superseded by KCC-23, a general metadata binding merged as Draft on 14 Oct 2026. The KCC-0021 author says token field meanings remain to be specified. The same post found 5 of 19 launchpad logos dead within days, 3 more serving HTML instead of an image. |
| Borrowed receive | Shawn, kas-smiths.org, 10 Jul 2026: "borrowed receive lets anyone change your UTXO's outpoint, which griefs pre-signed, outpoint bound transactions." A month later: "the v1 sighash folds the spent input's own outpoint into the signed message unconditionally," and AnyoneCanPay "only zeroes the other inputs' outpoints, never the signed input's own." Authorization needs something checked against the covenant's own state; nothing has merged. |
KCC repository or kas-smiths.org. Status here marks process, not proof: for what's running, use live status.