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 |
Dated KIP fallback checked September 11, 2026; the table refreshes live when GitHub responds. If the fetch fails, this fallback may be stale.
KIPs 16, 17, 20, 21 went Active 15 July 2026, at Toccata mainnet: KIP-16, KIP-17, KIP-20, KIP-21.
KIP-2, the DAGKnight upgrade, has stayed Proposed for years: devnet only, no date; the demo below runs it against GHOSTDAG. The static table omits open proposals; use the repository pull-request list for the current set. If the live fetch fails, the dated fallback above may be stale.
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 | Mainnet runs GHOSTDAG. KIP-2 is Status: Proposed; the dagknight branch is active, unmerged, with latest observed work on September 8, 2026. No testnet, no activation date. |
| 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 builds the UMC-voting redesign on personal fork branches, then merges into kaspanet's own dagknight branch; dk-umc-proposed merged August 14, 2026, and later prototype work continued through September 8, 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-09-11. |
| kaspanet/rusty-kaspa | dagknight commit log, checked 2026-09-11. |
| Unofficial | coderofstuff/rusty-kaspa, dk-wiki, checked 2026-08-22. |
Conventions
Kaspa Calls for Conventions
Builder agreements on encoding. Four merged since July 15, 2026, all still Status: Draft; none is a finalized standard.
The four merged KCCs, each still Status: Draft
| Proposal | Opened | State |
|---|---|---|
| KCC-0 KCC purpose, format, lifecycle and finalization criteria | 2026-08-25 | Merged, Status: Draft |
| KCC-0001 covenant definition, concepts, byte layout and ABI | 2026-07-15 | Merged, Status: Draft |
| KCC-0002 authority schemes for program ABIs | 2026-07-20 | Merged, Status: Draft |
| KCC-0020 fungible token covenant specification | 2026-07-15 | Merged, Status: Draft |
Open pull requests (6)
| Proposal | Opened | State |
|---|---|---|
| PR #4, KCC-0402: Covenant Payment Channels | 2026-07-19 | Open pull request |
| PR #6, KCC-0021: Covenant Token Metadata Specification | 2026-07-23 | Open pull request |
| PR #20, KCC-0020: first-cut conformance vectors | 2026-08-29 | Open pull request, draft |
| PR #23, KCC-2: add p2pk-ecdsa schemes (0x05/0x06) | 2026-09-02 | Open pull request |
| PR #24, KCC12 | 2026-09-11 | Open pull request |
| PR #25, Change status from Last Call to Final for KCC0 | 2026-09-11 | Open pull request |
Both authors claim adoption the repository doesn't confirm: KCC-0021 cites kascov, KaspaRocket; KCC-0402 cites k402, live mainnet payment channels.
Closed, not merged (2)
| Proposal | Opened | State |
|---|---|---|
| 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 |
Dated KCC fallback checked September 11, 2026. Live fetch below refreshes only open PRs; if it fails, this six-row fallback may be stale. Merged and closed states stay as described.
KCC-0001 defines a covenant's byte layout. Covenant breaker demo: attacks a vault, shows the stopping rule.
KCC-0020 is the most argued-over forum thread; the Argent compiler already ships a kcc20_asset.ag example, normal before acceptance. A token issued against the draft inherits unresolved issues documented in the KCC repository, including the still-open issue #14.
Try it
Update one holder, then try to pay the other
You and Sam hold the same token; update just one of you, and that stops being true.
A made-up token; the standard is real, this token is not.
You
Sam
9 coins. One shared supply.
Either of you could pay the other any amount. A coin is a coin.
A price or balance that assumed one supply now has to track two.
What the spec's own authors said about this
A stand-in for KCC-0020: lets an issuer update some holders' cells, not others. Not a universal bug: one pattern is intended, one co-author-conceded wrong.
“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
KCC-0020, Sivan Helfer, Michael Sutton, Romain Billot, Status: Draft. The spec moved on 27 August 2026: PR #16 made an identical extension_commitment a condition of fungibility for the standard transfer, and issue #14 is still open. Source: kcc-0020.md.
| Known defect | What it does to a token | Where it stands |
|---|---|---|
| Supply split | Only a cell's own holder can authorize a state update, so an issuer cannot move every holder at once. Updated and un-updated cells never consolidate again. | Issue #14 open; PR #16 revised the spec |
| 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 on-chain metadata | Name, ticker and image live off-chain. Of 19 logos on one launchpad, 5 were dead within days and 3 more served HTML. | KCC-0021 is an open, unmerged pull request |
| 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 full thread behind each of the five
| Topic | Thread |
|---|---|
| Supply split | Issue #14 (Knitser, opened 21 Aug 2026, open): the transfer consolidation rule requires every input to carry the same extended-state commitment, but the state-update entrypoint can only be authorized by each cell's own holder, so updating some cells and not others permanently splits supply into groups that never consolidate. Co-authors Manyfestation and Sutton defend one version as intended (Sutton's stablecoin-blacklist flag), but Sutton flagged a second, ephemeral receipt-like data, as "a wrong pattern"; both agreed it needs a spec fix. ShawnPearce (23 Aug 2026) noted the other candidate home, the transaction payload, has its own catch: the v1 sighash commits it unconditionally, so a borrower who signs controls the payload the owner's cell is recreated with. Knitser called the explanation clarifying; Manyfestation opened PR #16 the same day, and PR #18 later revised the same spec. 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). No metadata standard exists without KCC-0021 (open, unmerged): 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.