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.

Target: May 5, 2026

What It Is:
An upgrade to Kaspa’s UTXO model that allows transactions to include predefined spending conditions which must be satisfied before funds can be moved.

These conditional constraints enable logic such as destination restrictions, release schedules, or multi-stage authorization to be enforced directly at the protocol level, without requiring a global execution environment.

Why It Matters:
Covenants introduce programmable coordination into Kaspa transactions, allowing ownership and transfer of value or data to depend on agreed conditions.

This enables applications such as smart wallets, vaults, native assets, and externally verified program logic to operate within Kaspa’s consensus model while preserving its execution-free architecture.Covenants Hard Fork

What It Is:
A high-level programming language and associated development toolkit designed for authoring covenant-based logic within Kaspa transactions.

SilverScript allows developers to define conditional spending rules and coordination logic in an application-like format, which can then be compiled into covenant constraints enforceable by Kaspa consensus.

The accompanying SDK provides tools for building, testing, and integrating these programmable transaction conditions into wallets, applications, or coordination systems.

Why It Matters:
SilverScript lowers the technical barrier for developing programmable transaction logic on Kaspa by abstracting covenant construction into a more accessible authoring environment.

This enables developers to build coordination tools such as smart wallets, vaults, shared treasuries, or conditional asset flows without interacting directly with low-level transaction scripting.

What It Is:
A consensus-level transaction opcode that enables Kaspa to verify zero-knowledge validity proofs submitted by external execution environments.

Allows Layer 1 to validate externally computed state transitions without executing the underlying logic directly on chain.

Why It Matters:
Forms the verification bridge between Kaspa consensus and externally computed application logic, enabling based ZK-rollups and verifiable off-chain execution while preserving L1 settlement guarantees.

Who builds it:
Kaspa Core Research, with ecosystem teams contributing tooling and applications.

vProgs introduce a framework for verifying program logic inside Kaspa transactions without requiring a traditional virtual machine or global shared state.

Rather than executing application logic on chain, vProgs allow off-chain computations to produce cryptographic proofs which can be validated by Kaspa consensus. This enables transactions to enforce advanced constraints based on externally computed results while preserving Kaspa’s execution-free architecture.

Capabilities Introduced:

• Conditional transaction logic based on verified computation

• Authenticated off-chain execution

• Support for application-level constraints without full on-chain execution

• Verification of zk-based rollups and external program logic

• Foundation for programmable shared state within Kaspa’s UTXO model

vProgs are being developed in phases:

vProgs v1

Provides a verification scaffold for external execution environments, including based ZK-rollups, allowing applications to anchor securely to Kaspa through validity proofs.

vProgs v2 (Planned)

Intended to introduce an L1-enshrined execution framework for shared state applications, enabling programmable coordination directly within Kaspa consensus without permanent reliance on Layer 2 systems.

This phased approach supports:

• External execution environments that inherit Kaspa’s security through proof verification

• Future native programmability governed directly by Kaspa consensus

Target: End of Q3 2026

What It Is:
A consensus upgrade that introduces latency-adaptive block ordering to Kaspa’s blockDAG protocol.

DAGKnight allows nodes to reach agreement based on observed network conditions rather than fixed latency assumptions, improving consistency of transaction ordering across distributed environments.

This enables Kaspa to safely increase block production rates while maintaining decentralized participation and security under variable real-world connectivity.

Why It Matters:
By adapting to network latency in real time, DAGKnight supports faster confirmation intervals without sacrificing the honest-majority guarantees of Proof-of-Work.

This upgrade is expected to move Kaspa toward sub-100 millisecond block intervals and improve resilience during periods of network instability, forming a foundation for future enhancements such as confirmation progress under network partition and high-frequency coordination systems.

Planned: 2026 to 2027

What It Is:
A proposed upgrade to the Verifiable Programs framework that introduces a native execution environment governed directly by Kaspa consensus.

vProgs v2 is intended to support shared application logic whose validity can be verified and coordinated within Layer 1, allowing programmable coordination across transactions without requiring permanent reliance on external execution environments.

Why It Matters:
By enabling verified coordination logic to operate within consensus itself, vProgs v2 may support more advanced coordination systems such as conditional asset flows, automated settlements, or shared policy enforcement between merchants, enterprises, or institutional users.

This represents a step toward native programmability in Kaspa’s UTXO model, while preserving decentralized participation and settlement guarantees at the base layer.

What It Is:
Consensus enhancements aimed at maintaining transaction confirmation progress during network partitions.

Combines hashrate-adaptive finality windows with conditional payment channel techniques.

Why It Matters:
Current partially synchronous consensus provides safety during network instability but may pause confirmation progress.

Future improvements aim to support practical liveness under degraded network conditions, enabling secure local transaction flows even during temporary connectivity loss.

This is one of the biggest enterprise-relevant roadmap items in YTonatan’s article.

Especially for:

Infrastructure
Telecom
Energy
Disaster recovery systems

What It Is:
A conditional transaction framework allowing local payment flows to continue during network instability or partition events.

Payments may be finalized once global consensus is restored.

Why It Matters:
Supports continued transactional coordination in degraded connectivity environments while maintaining final settlement guarantees.

Useful for geographically distributed infrastructure systems or temporary offline environments.

What It Is:
A coordination mechanism allowing participants to bid for the right to trigger conditional transaction logic or verified program execution based on external state updates.

Execution priority is determined through advance auctioning of trigger rights.

Why It Matters:
As conditional logic becomes enforceable within Kaspa transactions, multiple actors may seek to execute the same valid state transition.

Auction-based scheduling allows the network to determine execution ordering transparently, helping reduce latency arbitrage and execution centralization while preserving open participation.

What It Is:
A transaction ordering mechanism that allows participants to compete for the right to execute valid conditional transactions based on predefined rules or external state updates.

When multiple parties are eligible to trigger the same authorized action, such as releasing funds after a milestone or updating state based on an attested event, execution priority can be determined through transparent bidding.

Why It Matters:
As Kaspa introduces conditional spending and externally verified program logic, shared coordination environments may require neutral methods for determining who executes a valid transaction.

Auction-based trigger selection supports open participation while helping reduce latency-based execution advantages in systems that depend on automated or event-driven settlement.

What It Is:
A Layer 1 attestation framework in which participating miners can report and vote on external events or shared state observations within consensus epochs.

Using Kaspa’s high-frequency block production and Real-Time Decentralization, each epoch can act as a temporary voter base for resolving real-world inputs such as:

• Market outcomes

• Environmental conditions

• Event confirmations

• Time-based thresholds

These attestations can then be referenced by conditional transaction logic or externally verified program execution.

Why It Matters:
Many application-level coordination systems depend on external inputs, typically provided by centralized oracle networks.

By allowing majority-based attestation within consensus, Kaspa can support real-time resolution of external state updates without introducing separate validator classes or trusted intermediaries.

This enables conditional logic tied to real-world events to be enforced directly through transaction constraints or verified program outputs.

What It Is:
A proposed execution framework allowing programs to depend on public state variables and trigger automatically when those values update.

Logic may be linked to real-world events or consensus-attested outcomes.

Why It Matters:
Enables reactive application logic such as:

• Automated liquidation thresholds

• Event-based settlements

• Oracle-driven coordination

• Real-time prediction market resolution

Designed to reduce reliance on external execution actors for maintaining contract logic.