A research paper discussing a revolutionary new consensus mechanism that will potentially be introduced in Kaspa. This new DagKnight consensus which is an evolution of the GHOSTDAG protocol will theoretically lay down the groundwork for even faster transaction and confirmation times. You can see the paper here.

Thanks to a 24-hour fundraising blitz, development is now underway for you to be able to send & receive your $KAS quickly, securely and easily from the safety of your Ledger.  To safeguard your $KAS holdings on the industry standard hardware wallet platform is just another step towards our goal of creating a common and safe use currency. Completed!! 

A rewrite of Kaspas programming language from Golang to Rust is currently being conducted by developer Michael Sutton. This switch will provide a significant boost in Kaspas overall performance/speed, allowing for unheard of transactions and blocks per second with conservative estimates of around 10bps. This rewrite is an integral part of the foundation to achieve Kaspas future goal of reaching 100bps!

Currently, Kaspa is written in a programming language called GoLang. You can think of this as sort of modeling clay. It serves the purpose of designing the shape and proving the concept, but it’s not really anything you would ever see in a museum. Rust is a high performance programming language which allows for intense race ready concepts to be implemented which fully utilize modern computing hardware.This enables such things as parallelism – the ability to process different blocks on different CPU threads simultaneously. Instead of modeling clay you may think of Rust as artisan grade, glazed and kiln fired ceramic.

We have all heard of blocks in crypto, but what are they – really? Think of a ziplock sandwich bag with a handful of fortune cookie papers inside – but instead of some generalized well-wishing, each one contains a note with an address crediting some coins to another address. Once a miner guesses the answer to the next block, all of those transactions are sealed in the ziplock bag and permanently stapled to the zip lock bag that came before it, forming a chain of bags – I mean blocks.

In Bitcoin and every other coin we are currently aware of, these blocks occur at regular intervals and are only allowed to happen one at a time – forming a chain of blocks in a straight line. When you send some coins – it’s like your transaction is waiting at the bus stop waiting for the next bus to take your transaction away and lock it in – for Bitcoin the bus comes every 10 minutes. For Ethereum, the bus comes every 15 seconds – a lot better.

For Kaspa right now, the bus now comes about every 0.1 second – BUT – we also allow up to 18 blocks to occur at the same time. Once the Kaspa code is completed in Rust high-performance language, we may increase the block time to about 32 blocks per second. All of a sudden, your transaction is no longer waiting for a bus – there are 32 supercars arriving every second to collect passenger transactions and rocket them off.

The transaction and the confirmation happens instantly, there is nothing to wait for anymore when using crypto if you utilize Kaspa.

KIP: 2
Layer: Consensus (hard fork), API/RPC
Title: Upgrade consensus to follow the DAGKNIGHT protocol
Author: Yonatan Sompolinsky – Michael Sutton <msutton@cs.huji.ac.il>

Motivation

DAGKNIGHT (DK) is a new consensus protocol, written by the authors of this KIP, that achieves responsiveness whilst being 50%-byzantine tolerant. It is therefore faster and more secure than GHOSTDAG (GD), which governes the current Kaspa network. In DK there’s no a priori hardcoded parameter k, and consequently it can adapt to the “real” k in the network. Concretely, in DK, clients or their wallets should incorporate k into their local confirmation policy of transactions (similarly to some clients requiring 6 confirmations in Bitcoin, and some 30 confirmations).

Goals

• Complete the R&D work necessary to implement DK for Kaspa.
• Implement DK on Kaspa as a consensus upgrade.
• Add support and API for wallets’ transaction acceptance policy, to correspond to DK’s confirmation speed.

Deliverables

Applied research

• Adapt the consensus algorithm to enforce a global maximum bound on network latency (can be taken with a huge safety margin; does not affect confirmation times), which is necessary for difficulty and minting regulation, pruning, and more.
• Devise efficient algorithms to implement the DK procedures — the current pseudocode is highly inefficient. The implementation will partially utilize the existing optimized GHOSTDAG codebase, as the latter is a subprocedure of DK.
• Research the optimal bps in terms of confirmation times, and provide a recommendation. (optional)

Implementation

Implement DK on the Kaspa rust codebase as a consensus upgrade.
Design a transaction confirmation policy API and implement the supporting functionality in the node.
Documentation of consensus changes and API additions.

Backwards compatibility

• Breaks consensus rules, requires hardfork
• Adds (and potentially breaks) RPC API

You can see the paper here.

Currently there is no P2P communication for archival nodes that allow them to exchange normally pruned data.  Improvements to archival Nodes will allow for Kaspa to have a more thorough block explorer to revisit past transactions beyond Kaspa’s pruning point. Currently due to Kaspa’s pruning mechanism, transactions on standard nodes can only be visited three days in the past. With Archival Nodes this will no longer be an issue allowing for more historical data sets to be retrieved.

Who builds them: Ecosystem teams (for example, Igra Labs, Kasplex), with design input from Kaspa Research

Kaspa is actively positioned as a base layer for based ZK-rollups. In this model, smart contracts and applications run off chain on a separate Layer 2, and periodically submit succinct validity proofs to Kaspa. Kaspa verifies those proofs and provides ordering, settlement, and security.

The official features page describes this direction explicitly, stating that Kaspa is “performant and responsive enough to handle a large volume of based ZK-rollups” and to support a large, diverse L2 ecosystem that inherits Kaspa’s security and censorship resistance. Kaspa

A formal design, “On the design of based ZK rollups over Kaspa’s UTXO-based DAG consensus”, outlines how such rollups can use ordered history roots and ZK-related opcodes to anchor securely to Kaspa’s blockDAG.

What It Is: A zero-knowledge rollup architecture where Kaspa L1 provides sequencing, settlement, and data availability. Designed to support atomic rollup composability and scalable privacy-preserving apps.

Why It Matters: Kaspa is aiming to scale via rollups without sacrificing decentralization or finality. By anchoring all L2 activity directly to L1, it maintains full integrity and composability.

What It Is: A block-building model where miners offer kickbacks to users in exchange for ordering or inclusion rights—formally capturing value that is currently extracted privately.

Why It Matters: Most MEV systems are predatory. This flips the model: competition benefits users directly while still compensating miners fairly.

What It Is: An L1-native attestation system where miners vote on external data (e.g. prices, weather, events) in real time. Builds toward secure oracle feeds tied to PoW.

Why It Matters: Oracles are essential but typically centralized. This embeds truth-sourcing into consensus itself, using Kaspa’s high-frequency block production.

Verifiable Programs (vProgs) allow off-chain computations to be proven and verified inside a Kaspa transaction. This enhances the expressiveness of L1 without adding a VM or global state. vProgs enable conditional logic, authenticated computation and advanced constraints while preserving Kaspa’s execution-free architecture.