What is a Kaspa Improvement Proposal (KIP)?

Any decentralized protocol that aims to improve its ecosystem and embrace continuous development must address a fundamental challenge: how to propose, evaluate, and adopt upgrades without relying on a central authority. In a proof-of-work network like Kaspa, where consensus rules determine security, transaction validity, and miner incentives, informal discussion is not enough. Changes require a structured process that is transparent, technically rigorous, and publicly auditable. A Kaspa Improvement Proposal (KIP) exists to solve this problem.

A Kaspa Improvement Proposal is a formal technical document that proposes changes to the Kaspa network. It defines how new ideas move from discussion to implementation while preserving decentralization, proof-of-work security, and predictable consensus behavior. KIPs provide a shared reference point for developers, miners, and node operators when evaluating protocol changes.

Kaspa uses a BlockDAG architecture rather than a single linear blockchain, allowing parallel block production and fast confirmations. This design introduces additional complexity at the consensus and networking layers, making a disciplined upgrade process essential. KIPs ensure that changes to this system are specified clearly, reviewed publicly, and implemented in a controlled manner.

What are Kaspa Improvement Proposals?

Kaspa Improvement Proposals are the primary mechanism for coordinating protocol development. What makes it more unique is that any community member can submit a KIP. Furthermore, there is no foundation or steering committee that approves proposals by decree. Instead, acceptance emerges through technical review, public discussion, and demonstrated safety.

Each KIP is submitted to the official Kaspa GitHub repository as a Markdown document. The proposal outlines the motivation for the change, the technical specification, design rationale, and expected impact on the network. These documents are written to be precise enough that independent developers can implement or audit the change.

KIPs may address a wide range of topics, including consensus rules, node performance, transaction validation, scripting functionality, and application-level features. The process mirrors the role of Bitcoin Improvement Proposals in Bitcoin, but is adapted to Kaspa’s higher throughput and DAG-based architecture.

The KIP Lifecycle

The KIP process follows a defined sequence designed to minimize risk and encourage review.

Drafting

The proposer writes a detailed specification describing the problem and the proposed solution. This includes technical details, backward compatibility considerations, and potential effects on miners and nodes. Ambiguous proposals rarely progress beyond this stage.

Community Discussion

Once published, the proposal is discussed openly in Kaspa research forums and developer channels. Participants examine assumptions, identify edge cases, and suggest refinements. Many proposals undergo multiple revisions during this phase.

Review and Acceptance

Core contributors and researchers evaluate whether the proposal aligns with Kaspa’s principles, including proof-of-work security, decentralization, and resource efficiency. There is no formal vote. Consensus forms through technical agreement and demonstrated feasibility.

Implementation

Accepted proposals are implemented in Rusty Kaspa, the Rust-based full node software. Depending on the scope of the change, deployment may require a coordinated network upgrade.

Status Tracking

Each KIP is assigned a status such as Draft, Proposed, Active, Implemented, or Rejected. This status is maintained in the repository, creating a permanent public record of the proposal’s outcome for users interested in the protocol’s incoming upgrades. 

Categories of KIPs

KIPs are commonly grouped by the system layer they affect.

Consensus

Consensus proposals define block ordering, validation rules, and difficulty adjustment behavior. These are the most sensitive changes, as errors can affect network security.

Node

Node-level proposals improve performance, memory usage, and maintainability of full nodes. These changes aim to increase throughput without raising hardware requirements.

API and RPC

These proposals enhance interfaces used by wallets, explorers, and indexing services to interact with Kaspa nodes.

Applications

KIPs focused on applications introduce features such as message signing and cryptographic proofs that can be used without altering core consensus rules.

Mempool and Peer-to-Peer Networking

These proposals adjust transaction propagation and mempool behavior to improve reliability during periods of high load.

Script Engine

Script engine proposals expand transaction scripting capabilities while preserving a UTXO-based and stateless design.

Recent discussions also include zero-knowledge verification opcodes and covenants, reflecting a cautious approach to programmability.

Notable Kaspa Improvement Proposals

As of the time of writing, the Kaspa repository contains eleven documented KIPs, with additional proposals in research and testing.

KIP 1 Rust Full Node Rewrite

KIP 1 migrated the Kaspa full node from Go to Rust. This improved performance, memory safety, and long-term maintainability. It also enabled later scalability upgrades.

KIP 2 DAGKNIGHT Consensus Upgrade

KIP 2 proposes upgrading Kaspa’s consensus from GHOSTDAG to DAGKNIGHT. The goal is to improve resilience against Byzantine behavior and network attacks while supporting faster confirmations. The proposal remains under active research.

KIP 4 Sparse Difficulty Windows

KIP 4 introduced a more efficient difficulty adjustment approach for high block rates. It replaced an earlier sampling proposal that was rejected due to security concerns.

KIP 9 Extended Mass Formula

KIP 9 refined transaction mass calculations to limit UTXO set growth. This discourages abusive transaction patterns and stabilizes node resource usage. It has been tested on Kaspa test networks and is active.

KIP 14 The Crescendo Hardfork

KIP 14 increased Kaspa’s block rate from one block per second to ten. It also activated state management improvements and performance optimizations. Deployed in 2025, it established Kaspa’s current throughput baseline.

KIPs 16, 17, 18, and 19 Community Proposals

KIPs numbered 16 through 19 are community-driven proposals currently in formal pull request or testing stages. These include zero-knowledge proof verification opcodes, UTXO-level covenants, transaction sequencing commitments, and inbound peer eviction policies. These features are being tested on Testnet 12 and aim to support native assets and off-chain computation without introducing global state.

What are the Core Themes in KIPs?

Several consistent priorities appear across Kaspa Improvement Proposals.

Scalability With Predictable Costs

Early KIPs focused on increasing throughput while keeping node operation accessible. Changes were evaluated not only for performance gains but also for their effect on decentralization.

State Discipline

Kaspa developers have emphasized limiting the growth of the persistent state. Proposals such as extended mass rules and covenants are designed to add functionality without expanding the global state.

Constrained Programmability

Rather than adopting a general-purpose virtual machine, Kaspa’s approach relies on limited scripting, covenants, and verifiable computation. This reduces the attack surface and simplifies consensus validation.

Open Research Culture

Many recent proposals emerged from public research discussions rather than formal roadmaps. This reflects the role of KIPs as coordination tools rather than top-down directives.

The Importance of KIPs

Kaspa Improvement Proposals provide the structure needed for a decentralized network to evolve safely. They document technical decisions, expose trade-offs, and allow independent verification of proposed changes.

For miners and node operators, KIPs explain how upgrades affect consensus and resource requirements. For developers, they offer a stable reference for building applications and infrastructure.

Conclusion

Kaspa Improvement Proposals are the foundation of Kaspa’s upgrade process. They define how a high-throughput proof-of-work BlockDAG network can change without central control. From the Rust node rewrite to the Crescendo hardfork and ongoing work on covenants and zero-knowledge verification, KIPs reflect a consistent emphasis on security, scalability, and disciplined design. 

By relying on written specifications and public review, the KIP process enables Kaspa to evolve while preserving its core technical principles.

Sources: 

• Kaspa Pull Requests: Formal Community Proposals
• Github Repository: All Improvement Proposals
• Kaspa Commons X post: What is a KIP?
• Developer Knowledge Base: KIP status update