Route hint

A private channel never appears in the public gossip graph, so an invoice has to carry the last leg of the route itself. BOLT 11 makes one hint mandatory when the payee has no public channel, and each hop costs 51 bytes: node id, channel id, base fee, proportional fee, CLTV delta. Withdrawing to a phone wallet with no announced channel works only because those bytes are there.

How it works

A route hint travels in the BOLT 11 tagged field written with the character r, which holds a list rather than a single value.

Each entry is five values laid end to end: a 264 bit pubkey, a 64 bit short_channel_id, a 32 bit fee_base_msat, a 32 bit fee_proportional_millionths and a 16 bit cltv_expiry_delta. That is 408 bits, exactly 51 bytes per hop. Entries run as a forward route from a public node to the payee, and each pubkey names the node at the start of its channel rather than the end.

The last three values are the ones a public node would broadcast in channel_update under BOLT 7. A private channel broadcasts nothing, so the invoice is the only place a payer learns what that hop charges.

The writer rule is narrow: if no public channel is associated with the payee's key, the invoice must carry at least one r field. A writer may include several of them to offer alternative routes, most preferred first. The ceiling is the tagged field itself, whose data cannot exceed 1023 groups of 5 bits, or 639 bytes, leaving room for at most twelve hops in one field.

Hints are advice rather than instruction: the payer may use the sequence of channels given, and the specification calls the field "limited routing assistance". Route blinding in BOLT 4 is the later answer to the same problem. Instead of a clear node id and channel id, the recipient hands the sender an introduction point plus tweaked node ids and blobs encrypted to each hop, so the sender gets a usable path without learning who is on it.

Where you see it

Route hints are what an invoice decoder shows as extra routing information for a private route.

The specification's own mainnet test vector is a 20 milli-bitcoin invoice routed via two hinted hops: channel 66051x263430x1800 at a 1 millisatoshi base fee, 20 parts per million and a 3 block CLTV delta, then 197637x395016x2314 at 2 millisatoshis, 30 parts per million and 4 blocks. Those two hops occupy 164 of the invoice's bech32 characters, more than the payment hash and payment secret put together.

The same structure turns up in practice. Phoenix, one of the 41 wallets we review, keeps its channels with ACINQ rather than with the open graph, and where those channels go unannounced the rule above obliges every invoice to name ACINQ's node. ACINQ's own FAQ, quoted in that review, already concedes it knows the destination and amount of your payments; a hint extends that disclosure outward, since whoever pays you learns which provider you bank with. Withdraw over Lightning from an exchange such as Strike and it is the exchange, as payer, that pays the hinted hop's base and proportional rates, read out of the invoice your wallet issued.

Route hint vs inbound liquidity

A route hint tells a payer how to find you; inbound liquidity decides whether the payment fits once it arrives.

The two fail in ways that look identical from outside, and only one is fixed by editing an invoice. A hint can be perfectly formed and quote the right fees, and the payment still dies at the last hop because your side of that channel has no room. Phoenix publishes the price of fixing that: receiving is free when you already have inbound liquidity, and costs 1% plus mining fees when the wallet has to go on chain to make space. If a payment fails while the sender insists the route resolved, check capacity before you blame the invoice.