pull down to refresh

Kurrent ProtocolKurrent Protocol

Kurrent is a research implementation of a Kaspa-native latest-state channel protocol. It explores whether Kaspa covenant and transaction-introspection capabilities, as represented by the KIP-10/KIP-17/KIP-20 direction, can support Eltoo-style settlement semantics: participants negotiate updates locally, and the chain is used to enforce the latest accepted state when settlement or dispute is required.

This repository is deliberately evidence-driven. A passing local-devnet run must produce real Kaspa and Lightning Network artefacts: raw transactions, witnesses, txids, preimages, logs, typed model validation, and verifier reports.

Current status:

  • Local devnet gate: passed in the prepared local environment.
  • Production-readiness gate: failed/blocked until the production evidence pack is complete.
  • Mainnet readiness: not claimed.
  • Native Lightning route-hop integration: not claimed.

Why Kurrent ExistsWhy Kurrent Exists

The Eltoo paper, by Christian Decker, Rusty Russell, and Olaoluwa Osuntokun, frames a Layer 2 channel as a sequence of locally negotiated contract states. The key idea is that old states must become unenforceable after they have been replaced by newer states. Eltoo does this with enforceable state numbers and floating transactions, using SIGHASH_NOINPUT in its Bitcoin construction.

Kurrent borrows the latest-state principle, not the exact Bitcoin mechanism. Instead of implementing Bitcoin eltoo byte-for-byte, it investigates how a similar non-punitive settlement model can be expressed against Kaspa covenant and transaction-introspection capabilities.

In plain terms:

  • participants update channel state off-chain;
  • each new accepted state must advance the state number exactly once;
  • stale or non-continuing spends must be rejected;
  • the latest state can settle on Kaspa simnet;
  • all claims are backed by replayable local evidence.