On February 4, 2026, Hans Moog (@hus_qy) announced a significant pull request in the kaspanet/vprogs repository (#7) that brings the long-awaited L1-bridge to life. This component is a foundational piece for Kaspa’s verifiable computation vision, allowing Layer-2 nodes to reliably and deterministically follow changes in the Kaspa Layer-1 chain state — without polling, without data loss during disconnects, and with built-in resumption support.

Kaspa has long stood out in the Layer-1 space thanks to its blockDAG architecture powered by GHOSTDAG, delivering extremely high throughput (now at 10 blocks per second post-Crescendo upgrade) and near-instant confirmations. But high transaction speed alone isn’t enough for the next generation of decentralized applications. To support complex DeFi protocols, verifiable gaming logic, AI computation marketplaces, and more, Kaspa needs scalable programmability without compromising its core strengths: speed, decentralization, and security.

Enter vProgs (Verifiable Programs) — Kaspa’s proposed architecture for off-chain computation with on-chain verification. The core idea is elegant:

• Kaspa L1 acts purely as a sequencer and data-availability layer

• Heavy logic runs off-chain on vProgs nodes (think of them as sovereign L2 / L1.5 instances)

• Results are submitted back to L1 with zero-knowledge proofs for trustless verification

• L1 never executes complex smart-contract logic — it only enforces ordering, resource accounting, and proof validation

A critical challenge in this model has always been: how does an L2 / vProgs node stay perfectly in sync with L1 state changes — especially during network hiccups, restarts, or chain reorganizations — without missing events or introducing race conditions?

Pull Request #7 delivers the answer

https://github.com/kaspanet/vprogs/pull/7
“Feat: L1 bridge for following Kaspa chain state” by @hmoog (Hans Moog)

Key highlights from the PR:

• Introduces vprogs-node-l1-bridge — a dedicated, event-driven bridge that connects to a Kaspa L1 node via wRPC

• Subscribes to VirtualChainChanged (vcc v2 API) and PruningPointUtxoSetOverride notifications

• Maintains an in-memory view of the selected-parent chain (doubly-linked ChainBlock list) from a finalized root to the current tip

• Emits structured L1Events for: new blocks, reorganizations (reorgs), finalizations, and more

• Lock-free & resumable design using crossbeam::SegQueue + tokio::Notify — safe for high-throughput producer-consumer patterns

• Supports checkpoint-based resumption: provide a saved root/tip pair → the bridge automatically backfills missing history on reconnect before resuming live events

• Robust error handling that distinguishes recoverable RPC issues (auto-reconnect) from fatal ones (e.g., rollback past finalization)

• Comprehensive integration test suite simulating real chain behavior, disconnections, reorgs, and catch-up scenarios

Hans Moog shared his experience in the announcement:

“I think I am among the first people that was able to build on the newly introduced vcc v2 API and I have to say that this API makes it really easy for outside consumers to subscribe to state-changes coming from the L1 in a structured way.”

He also gave strong praise to @IzioDev and @coderofstuff_ for their excellent work on the underlying vcc v2 improvements.

One practical suggestion from Hans for the broader Kaspa ecosystem:

“...we should expose more concrete error types because right now I need to parse strings to determine if its a recoverable error or not which is a bit annoying to maintain if we ever change those strings. It would be cool to have more concrete error types instead of just a generic RpcError.”

Why this matters for Kaspa’s future

1. vProgs moves from concept → prototype-ready: developers can now realistically build and test L2 nodes that stay tightly coupled to L1.

2. Dramatically improves scalability — L1 remains lightweight and focused on fast sequencing + data availability.

3. Enables truly trustless inter-layer communication — no centralized oracles or fragile bridges required.

4. Unlocks powerful use-cases: ZK-verified rollups native to Kaspa’s DAG, sovereign verifiable applications, high-speed DeFi, and even verifiable off-chain AI inference.

This PR is still open and under review (as of early February 2026), but it represents serious progress toward making vProgs production-viable.

What’s next?

If you’re a developer interested in Kaspa’s programmability layer:

• Star and watch the repo: https://github.com/kaspanet/vprogs

• Dive into PR #7 and the test suite — great place to understand the design

• Follow @hus_qy, @IzioDev, @coderofstuff_ and the Kaspa research channels for updates

• Join the Kaspa Discord or research forum to discuss or contribute

Kaspa isn’t just building a faster money layer — it’s quietly constructing one of the most ambitious programmable settlement infrastructures in crypto. The L1-bridge is a concrete milestone showing the team is delivering, piece by piece.