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.

Why Cassis

Bitcoin is not one network anymore

Lightning, Liquid, Cashu, Fedimint, Arkade, Rootstock: bitcoin now lives on many layers, and many more are coming. Each one makes its own tradeoffs between speed, cost, privacy and trust. There is no single best layer, only the right one for you.

Cassis is a generic protocol that connects them all. Pick the layer that suits you, and pay anyone on any other layer. Payments hop across layers atomically: they either complete end to end or refund, so nobody can take the money and run.

One protocol for every layer

Any layer that supports hash time-locked contracts can join the network. No bespoke bridges.

Keep your tradeoffs

Stay on the layer you trust. Cassis never forces you onto someone else’s.

Atomic across layers

A payment settles on every layer it touches, or on none of them. Never stuck halfway.

The payment lifecycle

Prepare, execute, commit.

Prepare

Upon receiving an invoice from the payee, the sender computes the route and sends a PREPARE message directly to each routing node on it, via Iroh, to confirm they're willing to route the payment.

Execute

The sender creates the first HTLC and sends an EXECUTE message to the first hop node. That node creates the next HTLC and replies to the sender, which then contacts the second hop — and so on.

Commit

When the HTLC chain reaches the receiver, it replies with a COMMIT carrying the preimage while using it to claim its own HTLC. The sender relays the preimage to every hop so they settle immediately; otherwise each hop learns it when the next hop claims its HTLC.

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.