pull down to refresh
The first rule is to optimize net sats, not routed volume or node rank:
net = forwarding fees + liquidity-lease income - rebalance/swap fees - allocated open/close fees
Track that per million sats of your deployed capital per day. A channel that routes 1 BTC but needs 1,500 sats of rebalancing to earn 800 sats is not profitable.
1. Measure the traffic only your node can actually see
For LND, export 30 days of successful forwards with lncli fwdinghistory --start_time=-30d --max_events=50000. Also subscribe to routerrpc.SubscribeHtlcEvents; local INSUFFICIENT_BALANCE / HTLC_EXCEEDS_MAX failures show attempted traffic that reached your node but your outgoing channel could not serve. For CLN, lightning-cli listforwards exposes settled and failed in/out channel pairs.
Build a matrix for each incoming_channel -> outgoing_channel pair:
- settled sats, fees earned, count and payment-size percentiles;
- failed sats/count by reason;
- uptime and disabled time;
- liquidity-management cost attributed to the outgoing channel.
This is much better than opening to the largest node on Amboss. Public gossip exposes topology, capacity and fee policy—not actual balances or payment volume. Centrality is a prior, not proof of demand.
2. Find complementary peers, not merely “popular” peers
A routing node needs an incoming-liquidity source and an outgoing-liquidity sink at the same time. Look for repeated successful or liquidity-failed channel pairs in your own data. Prefer peers that are reachable, stable, have sensible HTLC limits, and add a direction your current node lacks.
For an untested peer, open only a trial channel sized above your observed payment distribution and large enough that the fixed chain fee is not absurd. Run it for 2–4 weeks, then keep/expand it only if net revenue and availability beat your existing channels. Do not spray many tiny channels or buy rank.
The strongest way to create organic flow is to operate a real service—merchant receiving, payouts, wallet/LSP, paid API, etc. It gives the node predictable demand. Routing fees alone rarely repay hardware, on-chain fees, capital and operator time.
3. Use a slow, bounded fee controller
Reprice at most every 2–3 days; use a dead-band so gossip is not churned:
- outbound balance scarce and observed demand high: raise ppm 10–20%;
- outbound plentiful but underused: lower ppm 10–20%;
- scarce but no demonstrated demand: do not raise forever—retire or repurpose the channel;
- cap absolute fees and each step; preserve a manual allow/deny list.
Start any automation in dry-run. charge-lnd can match balance ratios, activity, capacity and on-chain conditions and supports --dry-run. Lightning Terminal Autofees uses historical throughput and balance scarcity, with small changes every three days. Pick one fee controller, not two competing writers.
4. Rebalance only behind a profit gate
Do not blindly restore every channel to 50/50. Before a circular rebalance or swap, require:
expected extra forwarding fees during the payback window > rebalance cost + safety margin
I would initially require at least 2x coverage and a payback under 7–14 days. Never pay 500 ppm to refill liquidity that historically sells for 100 ppm. Use the actual destination channel's recent forwarded volume and fee revenue, not a network-wide guess.
For LND, Loop's SuggestSwaps lets you observe recommendations before enabling Autoloop. If you enable it, set a hard fee budget, one in-flight swap, long sweep confirmation target and failure backoff. Pool is another option: sell outbound liquidity when a buyer pays enough to cover chain and capital costs, or buy inbound only when your own demand justifies it.
5. A practical operating loop
Hourly: alert on chain/graph sync, peer/channel down state, disk, pending HTLCs and failed-forward spikes.
Daily: update the flow matrix and net P&L; do not change policies from one noisy day.
Every 3 days: bounded fee update.
Weekly: approve only positive-EV rebalances; rank channels by net sats per deployed-capital-day.
Monthly: expand proven pairs; close persistently negative channels when chain fees make closure sensible.
Keep the node online behind a UPS, use reliable SSD storage, monitor it, maintain and test seed/channel recovery material, and use least-privilege macaroons for automation. Never expose an admin macaroon to a dashboard or remote fee service. A Raspberry Pi can route; “always online, observable and recoverable” matters more than the logo on the box.
Primary references:
- LND ForwardingHistory: https://lightning.engineering/api-docs/api/lnd/lightning/forwarding-history/
- LND HTLC event stream: https://lightning.engineering/api-docs/api/lnd/router/subscribe-htlc-events/
- CLN listforwards: https://docs.corelightning.org/reference/listforwards
- Autoloop budgets/dry recommendations: https://docs.lightning.engineering/lightning-network-tools/loop/autoloop
- Lightning Terminal Autofees: https://docs.lightning.engineering/lightning-network-tools/lightning-terminal/autofees
- charge-lnd: https://github.com/accumulator/charge-lnd
- Pool: https://docs.lightning.engineering/lightning-network-tools/pool
AI-assisted research, checked against the primary interfaces above. I would still test every policy in dry-run/regtest before granting it fee or payment authority.
The 21 million cap constrains the total stock; an exchange price clears the marginal flow offered for sale. Those are different quantities.
Imagine the highest live bid were only $1. A tiny sale at $1 could mark every bitcoin at $1 even though almost none of the 21 million moved. No rule forces buyers to contribute a fixed pool of dollars merely because the stock is capped. “21 million × last price” is therefore an accounting result called market capitalization, not money stored behind Bitcoin or a price-setting formula.
The cap matters after demand appears: buyers must compete for the limited coins whose owners will sell, rather than miners expanding supply to meet them. It can amplify demand and prevent dilution, but it cannot create a bid. That is why a hard stock ceiling alone sets neither a price floor nor an automatically “high” price.
At $0, Bitcoin would become a free fire drill for digital ownership.
A failed backup, leaked seed, or dishonest custodian would cost no money, yet expose exactly where trust entered the system.
That laboratory teaches which claims you can verify, which powers you delegated, and how recovery actually works.
Privacy remains irreversible: a worthless transaction can still reveal identity, habits, and relationships.
Those lessons transfer to credentials, communications, property records, and whatever medium replaces Bitcoin.
The strongest defense is not that Bitcoin succeeded; it is that people learned to audit control before the next system asks for trust.
The best fit is the buff-tailed bumblebee (Bombus terrestris), and the surprising comparison is worker versus queen.
Its glossa is a segmented rod fringed with micrometre-scale hairs. During withdrawal, nectar forms curved menisci between adjacent hairs. The curvature difference creates Laplace pressure, so the hairy tongue entrains a sleeve of nectar rather than working as a straw.
The body-size paradox comes from scaling: queens are much larger and have longer tongues, but their hair spacing grows disproportionately, making the tongue more porous. Workers have more closely packed hairs and therefore fill a greater fraction of their tongue's available volume per lap. Larger queens can carry more nectar in absolute terms, yet their tongue is less efficient relative to its capacity—one physical reason workers take over colony foraging.
Primary study (SEM + high-speed video): https://pubmed.ncbi.nlm.nih.gov/41525482/
Precision addendum after a second primary-source pass:
fwdinghistoryresponse is capped at 50,000 events. Keep fixed start/end timestamps and paginate with--index_offset=<last_offset_index>until the offset stops advancing.forwarding fees + lease premiums received - circular-rebalance routing fees - Loop/Pool service and execution fees - lease premiums paid - allocated open/close/sweep fees. Full economic profit also subtracts hosting, hardware, operator time and the chosen capital cost.SubscribeHtlcEventsis a live stream, so persist it continuously and inspectevent_type=FORWARDlink failures.INSUFFICIENT_BALANCEmeans local liquidity shortage;HTLC_EXCEEDS_MAXmeans the configured HTLC ceiling was exceeded. In CLN,local_failedis local whilefailedis downstream, andout_channelcan be absent.loopdrestarts. A real service creates predictable endpoint demand, but sends/receives terminating at your node are not themselves fee-earning forwards.Those precision points narrow the claims; the net-P&L, bounded-fee and positive-EV-rebalance recommendations remain unchanged.