Skip to main content

Seamless payments across layers

Bitcoin is no longer one network. It now lives in multiple layers.

Cassis is an open protocol that uses HTLCs and multi-hop routing to ensure every Bitcoin user is always within reach of any other.

Get started How it works

HTLC-atomic

Every hop is a hash time-locked contract. All legs settle or none do.

Choose your layer, route seamlessly

Every layer keeps its own security and privacy tradeoffs.

Reference implementation

Open-source in Rust. Run it, audit it, build against real code.

How Cassis works

Routed with hash time-locked contracts

A Cassis payment is a chain of HTLCs sharing one hash. The receiver generates a random secret R and hands the sender its hash H. Every intermediary along the path locks funds against the same H, each with a strictly shorter timeout than the hop before it.

When the receiver claims the final hop by revealing R, the secret propagates upstream hop by hop and every contract settles. If any leg stalls, its timeout expires and funds simply refund. Nobody can take the money and run.

One hash binds the whole route

Every hop references the same H, so claims are cryptographically tied to a single secret.

Timeouts decrease upstream

Each earlier hop has more time than the next, guaranteeing a refund path if the route fails.

Settlement cascades backwards

The preimage reveal lets each hop claim downstream before settling upstream. Atomic by construction.

The payment lifecycle

Prepare, hashlock, commit.

Prepare

Upon receiving an invoice from the payee, the sender computes the route and contacts the routing nodes involved in the route directly, via Iroh, confirming that they're apt to route.

Hashlock

The sender creates the first HTLC in the route and contacts the first hop node. That node creates the second HTLC (for the second hop) and replies back to the sender, which then contacts the second hop — and so on.

Commit

When the HTLC chain gets to the receiver it responds with the preimage at the same time as it uses that preimage to claim his HTLC. In the fast path the sender contacts every hop to tell them the preimage, otherwise they figure out by themselves.

Routes across the bitcoin stack

Any source, any destination

Currently Cassis has implementations for Arkade, Liquid, Fedimint, Rootstock, Cashu and Lightning, but new layers can be easily added, as long as they support creating HTLCs.

Arkade to Cashu

Arkade → Liquid → Cashu

An Arkade user pays a Cashu user. That specific Cashu mint doesn't have a bridge to Arkade directly (it could!) so the payment is routed through its Liquid bridge.

Rootstock to Lightning

Rootstock → Fedimint → Lightning

A specific Fedimint has a bridge to Rootstock, so a Rootstock user is able to hop through that and send a payment to any Lightning payee.

Users are free to use only the layers they are comfortable with, with the trust model they choose. See the full layer list.

Why Cassis

A decentralized and open routing ecosystem.

Anyone can operate a routing node and connect any networks they want. Routes are published to Nostr and payers fetch those and use the information to build the route locally at the time of the payment.

Anyone can route

Run a router on any networks you hold satoshis on and collect a fee from successful payments.

Announced on Nostr

Routers publish their node announcements as Nostr events.

Source-routing

Payers collect the node announcements and compute the route locally.

Pseudonymous actors

Identities are anonymous but stable, so routing reliability can be inferred. Payer identity can be ephemeral or stable.

Iroh Transport

Communication between payer and routing nodes is done via Iroh, fully encrypted, with optional Tor support.