Feedback
Sign in./start

Site navigation

Theme

Learn

  • Roadmaps

Build

  • Projects
  • Developer Tools

Contribute

  • Open Source Projects
  • Issues
  • Reviews
  • First Contribution
  • BountiesSoon
  • Feedback

Prove

  • Builders

Ecosystem

  • Partners
  • Get Funded↗
  • HackathonsSoon
Sign in./start-building

Become an Open Source Builder. Learn. Build. Contribute. Prove.

Feedback welcome — open a GitHub issue.

Learn

RoadmapsStart Building

Build

ProjectsDeveloper Tools

Contribute

Open Source ProjectsIssuesReviewsFirst ContributionSupportFeedback

Prove

Builders Directory

Account

Sign in

Legal

PrivacyTermsCredits

© 2026 Pull // code MIT · curriculum CC BY-SA 4.0

PrivacyTermsCredits

lesson // lightning

Multipath Payments

Split large payments across multiple paths for reliability and size.

advanced4 days

Public lesson — sign in to track progress on this roadmap.

./sign-in

On this page

Learning objectives

  • Explain why single-path payments hit capacity limits
  • Describe MPP/AMP at a builder level
  • Know invoice/feature bit requirements for split payments

study // plan

Lessons are primers. Start with Step 1 (required reading) when present, then follow the numbered steps in the article. Depth comes from primary sources, labs, reflection, and evidence.

Research on Bitcoin Search
multipath paymentsAMPHTLC splittingBOLT4 MPP

Step 1 // Required reading

Complete these before the numbered steps in the lesson body. Links are listed here once — not repeated below.

  • boltBOLT4 Basic Multi-Part Payments

Reflection prompts

  1. Explain Multipath Payments to a teammate without jargon - what problem does it solve?
  2. What would break in production if you misunderstood Multipath Payments?
  3. Which BOLT (or implementation doc) is the source of truth for this topic, and what did you verify there?

Lab // Split rationale brief

Complete Steps 2–3. Write when you would enable MPP for a product amount. Note feature negotiation. Optionally pay a large-enough Polar invoice that forces a split if your stack supports it.

evidence required

  • ·One paragraph: when single-path fails and MPP helps
  • ·Feature-support note for payer and payee stacks you care about
  • ·Link to BOLT4 MPP section you used
  • ·Optional: Polar/CLI multipath pay proof
  1. 01

    Worked mental model

    Re-read the diagrams in this lesson once out loud in plain language. If you cannot explain the flow to a friend without jargon, pause and revisit the Mastering Bitcoin / Mastering Lightning chapters linked in Resources. Chapter references are intentional, not decorative.

  2. 02

    Hands-on habit

    Every protocol idea should be paired with one local experiment. That habit turns reading into builder instinct.

    1. Reproduce the happy path on regtest (or Polar for Lightning)
    2. Break it on purpose (wrong fee, expired invoice, offline peer)
    3. Write down what error you saw and which layer produced it (wallet, node, mempool, peer)
  3. 03

    Glossary check

    Pick three terms from this lesson and define them in one sentence each without opening notes. Weak definitions mean the lesson is not finished yet.

  4. 04

    Resource order

    Use Resources in order: narrative book chapter first, then BIP/BOLT for precision, then implementation docs for commands. Jumping straight to RPC flags without the mental model creates brittle knowledge.

Multipath payments split one logical payment across several HTLC paths that share a payment secret/hash scheme so the receiver can reassemble atomically.

Complete Step 1 // Required reading in the study plan above, then continue here.

Step 2 — Core idea: several vans beat one blocked truck

Large payments often cannot fit through one channel’s available balance. MPP raises success rates and effective capacity without opening enormous channels.

Analogy: Moving a couch through a city — sometimes three smaller vans beat one truck that does not fit the alley.

Loading diagram…

Several HTLCs settle one logical payment.

Feature negotiation

Both ends need compatible features. Test across LND/CLN/LDK combinations you support.

Done when: You can explain atomic reassembly at the receiver in one sentence.

Step 3 — When to split (lab)

Write the product rationale and feature-support note. Optional hands-on if your lab supports MPP.

Done when: Lab evidence (rationale + support note + source) is complete.

Next lesson

Failure Handling — retries, error onions, and safe refund UX.

further reading

  • docsLND multipath payments
  • articleBitcoin Optech: Multipath payments

progress // sign in

Reading is public. Sign in to mark lessons complete, sync across devices, and unlock your roadmap.

./sign-in-to-track

discussion

Discussion

prevPathfindingnextFailure Handling

On this page

Press Shift + ? for keyboard shortcuts.

Press R to research on Bitcoin Search.

No questions yet — be the first to ask.