Proposal tracker
KIPs and KCCs
Two separate processes decide what Kaspa becomes. One changes the protocol, one does not. This page reads both straight from their repositories, so what you see is the current state rather than a label somebody typed once.
A Kaspa Improvement Proposal changes consensus, node behavior, or a client API. It ships when it is implemented and activated, and until then its status word is the honest answer. A Kaspa Call for Conventions is the opposite: an agreement between builders about how to encode a token, name a field, or shape an ABI, with no consensus change at all. The KCC README draws the line itself: "KCCs do not propose changes to Kaspa consensus or core-node behavior. Such changes belong in Kaspa Improvement Proposals (KIPs)."
The distinction matters because the two get confused constantly. A merged KIP marked Active is protocol law. An open KCC pull request is a draft one person wrote and others are arguing about, and calling it a standard is how people end up building against something that never lands.
Protocol
Kaspa Improvement Proposals
Status words come from the index table in the KIP repository. Implemented means it is running. Active means merged and adopted as the specification. Proposed and Draft mean the argument is still open. Rejected means it was considered and turned down, which is worth as much as the rest.
| 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 |
| 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 Crescendo hardfork | Consensus | Active |
| 15 | Canonical transaction ordering and sequencing commitments | Consensus | Active |
| 16 | ZK precompile opcode | Consensus, Script Engine | Active |
| 17 | Covenants 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 read from the KIP repository on July 29, 2026. This table refreshes from the repository when the page loads.
KIPs 16, 17, 20, and 21 were marked Active on July 15, 2026, after Toccata carried them onto mainnet. KIP-2, the DAGKnight upgrade, has been Proposed for years and is still Proposed: it runs on an internal devnet, and there is no testnet and no date. Ten further KIPs sit open as pull requests, including browser extension wallet APIs, a compute budget for script execution, and a quantum-resistance script type.
Read the KIP repository for the full text of any proposal, including the rejected one.
Conventions
Kaspa Calls for Conventions
The KCC repository was created on July 15, 2026. Exactly one pull request has merged since: the README that describes the process. Every specification is still an open pull request, which means no KCC has been accepted and none is a standard yet.
| Proposal | Opened | State |
|---|---|---|
| KCC-0020 fungible token covenant specification | 2026-07-15 | Open pull request |
| KCC-0001 covenant definition, concepts, byte layout and ABI | 2026-07-15 | Open pull request |
| KCC-0402 covenant payment channels | 2026-07-19 | Open pull request |
| KCC-0002 control principal references in program ABIs | 2026-07-20 | Open pull request |
| KCC-0021 covenant token metadata specification | 2026-07-23 | Open pull request |
| KCC-0008 through KCC-0024 multi-token, token, and commerce standards | 2026-07-25 | Open pull request |
| KCC-0025 license agreement | 2026-07-28 | Open pull request |
Baseline read from the KCC repository on July 29, 2026. This table refreshes from the repository when the page loads.
The four-digit repository numbering is canonical. Forum shorthand like "KCC20" is convenient and is not the identifier in the repository, which matters when someone claims a token already follows a ratified standard. Nothing has been ratified.
KCC-0020 is the one to watch. It is the most argued-over thread on the builder forum, and its shape has already leaked into working code: the Argent compiler ships a kcc20_asset.ag example defining a transferable asset covenant whose owner can be either a public key or a covenant ID. A convention appearing in a compiler's test suite before it is accepted is normal, and it is not acceptance.
Read the KCC repository, or follow the discussion on kas-smiths.org.
How this page stays honest
Where these numbers come from
Both tables above are written into the page as a baseline, verified by hand on the date stamped under each one. When the page loads it asks the two repositories for their current state and replaces the baseline if anything moved, then says when it last checked. If GitHub is unreachable or rate-limits the request, the baseline stays and the stamp tells you it is a baseline. Nothing here is generated from memory.
A status word on this page is never evidence that something works. It is evidence of where a document sits in a process. For what is actually running on mainnet, use the live status page, and for the difference between a primitive being activated and an application being usable, see what still has to be built.