Kurrent: an eltoo-inspired latest-state channel on Kaspa

L1/L2
1

Hi, Arthur Zhang (@a19q3) here. I am a DSL architect by trade and an independent researcher, mostly working around PoW consensus, covenant-style scripting, and state-channel constructions.

A bit of context

I have been building a small research implementation called Kurrent over the last couple of months, it is basically an eltoo-style latest-state bilateral channel, expressed against Kaspa’s KIP-17 / KIP-20 covenant surface plus DAA-relative sequence maturity.

Last week Yonatan kindly invited me here after I posted an early Kurrent thesis. He also pointed out a gap I should have surfaced more explicitly: the punitive-vs-replacement trade-off should not be assumed away. Since then I have pushed the experiment further in a more Kaspa-native direction.

The revised research note is here:

The implementation is also close to a stricter live-devnet evidence pass.

Current progress

How It Works, Roughly

Kurrent is trying to build a latest-state channel without the Lightning-style penalty mechanism.

In a traditional penalty channel, if someone publishes an old state, the counterparty may punish them by taking their funds. Kurrent tries a different route: an old state is not punished by confiscation; it is simply made lose the race against a newer state.

The channel has one shared on-chain object, which I call the contest output. Every channel state refers back to that same contest output. A newer state is allowed to spend it in a way that an older state cannot beat once the newer spend is confirmed.

So the core rule is simple:

there is one contest output, and only one state can successfully spend it.

If a stale state is published, the honest party must respond within the agreed time window by publishing a newer state. Once the newer state spends the contest output and reaches finality, the stale settlement path is excluded.

This means Kurrent is non-confiscatory, but not watch-free. It removes the forfeiture penalty, but it replaces that with an active monitoring requirement.

（I will probably avoid over-expanding the mechanism here, partly to avoid punishing everyone’s eyesight :slight_smile: . The note linked above has the full technical version.）

The non-confiscatory / liveness trade-off.

Yonatan sort of reminded me of this last week on Telegram, and I want to make it explicit here. The replacement-only discipline removes revocation-secret forfeiture, but it shifts the burden to active monitoring and timely inclusion inside the response window.

So Kurrent is non-confiscatory, not watch-free. The higher certificate alone cannot reverse a stale settlement once that stale settlement has already been accepted. The construction so far therefore separates the consensus safety predicate from the deployment-level liveness assumption.

What I have, evidence-wise.

At the moment there is a short research note setting out the design frame, and a replayable local-devnet evidence pack: raw transactions, witnesses, txids, observed preimages, and a typed Rust protocol model that re-verifies the on-chain artefacts.

The factory surface remains research-only in this note: materialisation invariants and proof obligations, not a production compressed-commitment construction.

Open Threads

  1. Does the bilateral channel need KIP-21?

    My current reading is no: the basic two-party channel only needs the contest output, the covenant rules, and the relative time window. KIP-21 seems useful for observability, indexing, and more compact evidence, but not necessary for the core fund-safety argument.

    I would appreciate pushback here, especially if there is a hidden dependency I am missing.

  2. How should a factory be compressed safely?

    The current factory model is deliberately not production-grade. It verifies the full state directly, which is useful for finding mistakes but not enough for a real compressed factory.

    A production version needs a compact commitment to the internal balances and channel states, plus proofs that materialisation cannot create extra value, omit obligations, or interfere with untouched channels.

    I currently think KIP-16 may be the natural place to wrap such proofs, but the proof format, cost model, and dependency assumptions are still open.

  3. What is the right response window?

    The safety of this design depends on giving the honest party enough time to notice and respond to a stale publication.

    After Crescendo, a rough estimate is:

    T_Δ ≈ 0.1 s · Δ

    So Δ = 600 is about 60 seconds, while Δ = 60 is about 6 seconds.

    The important question is not just what works in a clean devnet, but what is conservative enough under real network delay, congestion, node downtime, and monitoring failure.

  4. Is multi-party worth exploring now?

    The core idea should generalise from two participants to many participants: instead of two balances, the state carries a balance vector.

    But threshold signing, participant changes, and key rotation introduce new complexity. My current view is that the fixed two-party version should remain the mainline, and multi-party should only be prototyped after the bilateral safety argument is solid.

Happy to take criticism and answer questions. :coffee: