A Lightning payment succeeds when there is a path through the network with enough liquidity, on the right side of each channel, to carry the amount. Two things make that hard. Liquidity has to be in the right places, and the sender has to estimate where it is, because the split of each channel's balance is not public.
Amboss has published three papers on these problems. They are listed on our research page, and two of them, MPFlow and Bayesian Binary Search, already run in production. This post summarises what each paper found and why it matters to a team that depends on payments arriving the first time.
At a glance
| Paper | Venue | Problem | Published result |
|---|---|---|---|
| MPFlow | arXiv preprint | Where should a node place a fixed budget of liquidity? | 4,640 channel-open decisions in production, allocating 267.3 BTC (over $16 million) across 30 managed nodes |
| Bayesian Binary Search | Algorithms (MDPI), peer-reviewed, 2025 | How can a channel's hidden balance be found with fewer probes? | 3 to 6% probing efficiency gain in production |
| Channel Balance Interpolation | arXiv preprint, 2024 | Can a channel's balance split be predicted from public data alone? | 10% better than the equal-split baseline |
MPFlow: placing liquidity where it moves the most value
A channel can only route what its liquidity allows. If a node opens channels in the wrong places, payments fail or take longer and more expensive paths. The question MPFlow answers is narrow: given a fixed budget, which channels should a node open so that the most value can flow through it?
The paper treats this as an optimisation problem on a graph. It measures a node's routing capacity with max-flow, a classical result in network theory for the most value a network can move between two points. A small graph neural network, trained with reinforcement learning, learns which new channels raise max-flow the most.
During training, the largest hubs in the network were removed from the model's view. That forced it to learn where capacity is actually needed, rather than defaulting to "connect to the biggest node". On real Lightning Network snapshots, MPFlow outperformed strong heuristic baselines, including degree and betweenness centrality, across multiple random seeds and network states it had not seen in training. In controlled tests on a 5,000-node snapshot, it achieved up to 11.3% higher throughput than leading autopilot algorithms.
MPFlow is deployed for peer recommendations. According to the paper, it has executed 4,640 channel-open decisions that allocate 267.3 BTC, worth over $16 million, across 30 managed nodes. It runs on live network conditions, not a static snapshot.
- Abstract: MPFlow
- Plain-English overview: Scaling Bitcoin payments with intelligence
- Paper: arXiv 2607.08703
Bayesian Binary Search: finding balances with fewer probes
The total size of a Lightning channel is public. How that total is split between the two sides is not. To route well, a node needs an estimate of that split, and one way to get it is to probe the channel with test payments of different sizes.
Probing usually uses binary search: try half, then half of the remaining range, and so on. Binary search assumes every amount is equally likely. On Lightning that is rarely true, because balances cluster in predictable ways.
Bayesian Binary Search (BBS) first learns where balances are likely to sit, using probabilistic machine learning methods. It then splits the search range where the probability mass is, rather than at the midpoint. On Lightning channel balance probing, BBS delivered a 3 to 6% efficiency gain, and it is in production at Amboss. Fewer probes mean faster operations and less load on the network.
The paper was published in the peer-reviewed journal Algorithms in 2025, in collaboration with Stillmark.
- Abstract: Bayesian Binary Search
- Plain-English overview: Smarter search with Bayesian Binary Search
- Paper: Algorithms 18(8), 452
Channel Balance Interpolation: estimating balances without probing
Probing costs time and network resources. The third paper asks whether balance splits can be estimated from public information alone, using features of the nodes and channels involved.
A common default is to assume each side holds half the channel. The paper evaluates several machine learning models against two heuristic baselines. The best model outperformed the equal-split baseline by 10%. Better starting estimates mean pathfinding can rule out unlikely routes before any payment is attempted.
- Abstract: Channel Balance Interpolation in the Lightning Network
- Paper: arXiv 2405.12087
Why this matters to a payments team
A business accepting payments does not need to know how liquidity is placed or how balances are estimated. It needs payments to arrive. The three papers address the two conditions behind that outcome: liquidity in the right places, and good information about where it is.
Our research informs the infrastructure behind Amboss. Amboss Payments is a managed service: your developer integrates an API, funds settle to your own wallet, and Amboss handles the Lightning infrastructure. If you would like to discuss the research or how it applies to your payment flows, contact the team.
Sources
- Amboss research page, amboss.tech/research: paper list, venues, and the published results 4,640, 267.3 BTC, 30 managed nodes, $16M+, 3 to 6% and 10% (accessed 2 November 2026).
- MPFlow abstract and MPFlow on arXiv announcement: method, baselines, hub-exclusion curriculum, production deployment.
- Scaling Bitcoin payments with intelligence: 11.3% throughput result on a 5,000-node snapshot.
- Bayesian Binary Search abstract and overview: method, 3 to 6% efficiency gain, Algorithms (MDPI), Stillmark collaboration.
- Channel Balance Interpolation abstract: 10% improvement over the equal-split baseline.