# How SQRL Markets works

A SQRL Markets workspace runs one SQRL Lightning hub. The hub holds channels to merchants and payment rails, each channel holds a pocket per asset, corridors price every conversion, and every payment converts and settles atomically under one payment hash.

> Part of the SQRL documentation, section "SQRL Markets".
> Rendered page: https://docs.sqrl.tech/markets/how-it-works

## The hub

The hub is a Lightning node that your workspace operates, and the hub's own node is your workspace's node. It holds:

* **Channels** to each counterparty. A channel is a standard Lightning channel that carries Bitcoin plus SQRL assets bound to it.
* **Pockets.** Each asset inside a channel is its own pocket. A channel can hold several pockets, and one pocket cannot cover another.
* **Reserves.** Funds held on-chain by the hub and not yet committed to any channel.
* **AMM pools** that convert between Bitcoin and an asset at the pool's price.

You can run your own hub, or connect to a hub SQRL operates for you. See [Connecting your hub](/markets/getting-started/connecting-your-hub).

## Channels by job

Every channel is labelled by what it does, in [Hub settings](/markets/hub):

| Label | What it does |
|---|---|
| **Merchant** | Pays out to one merchant. Only merchant channels count toward runway. |
| **Rail** | Takes shoppers' payments in. |
| **Routing** | Connects to the wider Lightning network. |
| **Bridge** | Connects to another hub. |

## Corridors

Each direction you convert is a **corridor**, for example ZARX → USDX. A corridor has a spread, a fee, a per-payment cap and a daily cap, and is Active, Paused or Halted. Direct corridors are priced from reference rates; corridors with Bitcoin on one side are priced by the hub's AMM pool. See [Pricing](/markets/fx/pricing).

## The life of a payment

1. **Quote the rate.** The corridor prices the conversion, your charge included. The quote is signed and holds for 30 seconds.
2. **Lock and check.** The rate locks and the shopper is sent an invoice. Corridor caps, merchant limits and screening run before anything moves; a payment they stop waits for a person.
3. **Convert in channel.** Funds arrive, and the payment converts inside the channel. Both sides lock to one payment hash, so a half-finished conversion cannot exist.
4. **Pay out and settle.** The merchant is paid in their currency, the shopper's funds are claimed, and the payment settles with your spread booked.

See [Payments](/markets/payments) for every state.

## Approvals everywhere money moves

Payments that break a limit or need screening are decided by a different person from the one who locked them. Every movement of the workspace's own funds on the hub, from a channel top-up to a withdrawal, is an [operation](/markets/operations) that needs approvals before anyone carries it out.

  A payment either converts and settles in full or does not happen at all. Your liquidity stays in your channels under your keys, and every decision is recorded in an audit log you can verify.