Skip to content

User Flows

This page describes how the Nitro framework can be used at increasing levels of scalability.


A very simple interaction involves just two parties, Alice and Bob, who transact off-chain. After prefund states are exchanged, at least one of them deposits into the adjudicator in priority order. Then, after postfund states are exchanged, the channel may be executed according to the rules of the channel. Then, Alice and Bob may agree to finalize, conclude and liquidate the channel.

Outcome priority


The basic flow shown above is essentially a very small, two party state channel network. Nitro protocol allows for far larger and more powerful networks to be built which bring major scalabilty advances.

The first step for any particular node in the network is to join by creating a so-called Ledger Channel (purple). This is a two-party channel connecting the node to an existing nitro node, backed by at least one on-chain deposit. The existing nitro node is likely to be a so-called "hub" node, meaning that it tends to command a large amount of capital and be very well connected to other nodes.

Joining the network

The execution rules of a ledger channel are typically very simple and are designed to govern the "application" of funding other channels. Imagine that Alice and Bob have never connected to each other directly by sharing an on chain deposit. They can establish a virtual channel V (orange) between themselves, and fund it by making making appropriate updates in a pair of ledger channels connecting them through a mutual hub:

A single hop virtual channel

The user flow for a virtual channel is like so:

Advanced User Flow

Note how the highlighted "running" stage is identical as for the basic user flow above. Not also that the adjudicator contract on L1 is not involved in any part of opening, funding, executing or defunding the virtual channel.


This construction scales to multi-hop scenarios, which involve multiple hub connections like so:

A two hop virtual channel