A Multi-Hop Payment is a routing technique in a payment channel network, such as the Lightning Network, that allows a payer to send funds to a recipient through a path of intermediate nodes, even when the two parties do not share a direct, open channel. This is achieved by constructing an HTLC (Hashed Timelock Contract), a conditional payment that locks funds at each hop with a cryptographic secret, enabling trustless forwarding. The process is analogous to packet routing on the internet, where data finds a path through multiple routers to reach its destination.

Multi-Hop Payment
What is Multi-Hop Payment?
A mechanism enabling a payment to traverse a network of payment channels, allowing users to transact without a direct, funded channel between them.
The core cryptographic primitive enabling this is the hashlock and timelock. The payer generates a secret preimage and shares its hash within the HTLC. Each intermediary node in the path agrees to forward the payment, locking their funds with the same hash condition. Only when the final recipient reveals the secret to claim the payment does it propagate backwards, allowing each intermediary to sequentially claim the funds from the previous hop. Timelocks ensure that if the payment fails, all locked funds are automatically refunded, preventing capital from being stuck indefinitely.
This architecture is fundamental to achieving scalability and fungibility in layer-2 networks. It eliminates the need for a complete mesh network where every user must have a direct channel with every other user, which would be capital-intensive and impractical. Instead, liquidity can be concentrated in well-connected routing nodes, creating efficient payment corridors. Key challenges include liquidity balancing across channels, privacy considerations as intermediaries see payment amounts, and the economic incentives for nodes to provide routing services for a fee.
How Multi-Hop Payments Work
A technical breakdown of the multi-hop payment mechanism, a core protocol for routing transactions across decentralized networks without direct peer-to-peer channels.
A multi-hop payment is a cryptographic transaction that is routed through a series of intermediate nodes, or hops, to connect a sender and receiver who do not share a direct payment channel. This process is fundamental to Layer 2 scaling solutions like the Lightning Network for Bitcoin and similar state channel networks, enabling fast, low-cost, and private transfers. It solves the critical problem of network liquidity by utilizing the interconnected web of existing channels without requiring every user to be directly connected.
The mechanism relies on Hash Time-Locked Contracts (HTLCs), which create a conditional payment path. The sender generates a cryptographic secret and its hash, then constructs a route where each hop forwards the HTLC, locking funds with the hash. Only when the final recipient reveals the secret to claim the payment can each preceding hop sequentially claim their funds back from the next node in the chain. This use of atomicity ensures the entire payment either succeeds completely or fails, with all funds returned, preventing loss during routing.
Key advantages of this architecture include enhanced privacy, as intermediaries only see their immediate predecessor and successor, not the full path, and improved capital efficiency by leveraging the network's aggregate liquidity. Operational challenges involve pathfinding algorithms to discover efficient routes and managing channel balance to avoid failed payments due to insufficient local liquidity. This design is a cornerstone of scalable, user-friendly blockchain payments, abstracting away the underlying complexity of the channel graph.
Key Features of Multi-Hop Payments
Multi-hop payments are a routing mechanism that enables transactions across multiple blockchain channels without requiring direct liquidity between the sender and final recipient. This section details its core operational components.
Onion Routing & Sphinx
Multi-hop payments use onion routing, a cryptographic technique where the payment is wrapped in layers of encryption, analogous to an onion. Each intermediary node (or hop) peels off one layer to reveal the next destination and a new encrypted packet, while the final payment details remain hidden. This is typically implemented using the Sphinx packet format, which ensures privacy, integrity, and compact packet size. No single node sees the complete path or the final recipient.
Source-Based Routing
The sender is responsible for discovering and constructing the entire payment path before initiating the transaction, a model known as source-based routing. Using network gossip and channel liquidity information, the sender's node calculates a viable route, specifying each intermediary node and the corresponding HTLC (Hashed Timelock Contract) parameters for each hop. This contrasts with hop-by-hop routing, where each node finds the next step, and is fundamental to the deterministic execution of Lightning Network payments.
Hashed Timelock Contracts (HTLCs)
Atomic execution across multiple hops is enforced by Hashed Timelock Contracts (HTLCs). The sender creates a cryptographic payment hash (a hash of a secret preimage). For each hop in the path, a conditional payment contract is created:
- Condition: Reveal the preimage that hashes to the payment hash.
- Timelock: A deadline by which the condition must be met. This creates a chain of interdependent contracts. The secret is revealed upon payment to the final recipient, unlocking funds backwards along the path, ensuring the transaction either completes fully or fails entirely.
Pathfinding & Liquidity Discovery
A critical feature is the algorithm that finds a path with sufficient liquidity. Nodes use a gossip protocol to broadcast information about public channels (capacity, fees) but not their real-time balances. Pathfinding algorithms (e.g., Dijkstra's) must therefore probabilistically infer available liquidity. Advanced techniques include probing (sending small test payments) and using multi-part payments (MPP) to split a payment across several paths. Efficient pathfinding is essential for payment success and cost optimization.
Fee Incentives & Economics
Each intermediary node in a multi-hop path charges a small routing fee for forwarding payments, creating a market for liquidity provision. Fees typically consist of:
- Base fee: A fixed amount per forwarded HTLC.
- Fee rate: A variable amount proportional to the payment value (measured in ppm - parts per million). These fees incentivize nodes to lock capital in channels and maintain uptime. The sender's pathfinding algorithm must balance fee costs, path length, and success probability.
Failure Handling & Error Codes
If a payment fails at any hop (due to insufficient liquidity, offline node, or expired timelock), the entire transaction is rolled back. The failing node sends an error message back along the path to the sender, encrypted in reverse. Standardized error codes (e.g., TEMPORARY_CHANNEL_FAILURE, FEE_INSUFFICIENT) allow senders to update their network view and retry with a different path. This fail-safe mechanism protects funds and provides feedback for the routing algorithm.
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos

Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
Multi-Hop Payment vs. Alternative Transfer Methods
A technical comparison of multi-hop payments against other common methods for transferring value across blockchain networks.
| Feature / Metric | Multi-Hop Payment | Centralized Exchange (CEX) Bridge | Atomic Swap | Canonical Bridge |
|---|---|---|---|---|
Core Mechanism | Series of conditional payments across a network of payment channels | Custodial deposit/withdraw between exchange wallets | Hash Time-Locked Contract (HTLC) between two parties | Lock-and-mint or burn-and-mint via smart contracts |
Custodial Risk | ||||
Counterparty Trust Required | ||||
Native Cross-Chain Asset Transfer | ||||
Typical Latency | < 1 sec to 60 sec | 5 min to 60 min | ~10 min to several hours | 5 min to 30 min |
Typical Cost Structure | Routing fees per hop (e.g., 0.01% - 0.1%) | Withdrawal fee + spread (e.g., 0.1% - 0.5%) | On-chain fees for both chains | Bridge protocol fee + gas (e.g., 0.05% - 0.3%) |
Liquidity Requirement | Requires sufficient inbound/outbound liquidity in channel network | Requires exchange hot wallet liquidity | Requires direct counterparty with matching asset/amount | Requires liquidity in bridge vaults or minters |
Primary Use Case | Fast, low-cost microtransactions; rebalancing channels | User-facing large asset transfers between major chains | Peer-to-peer, trustless exchange of disparate assets | Moving assets to/from a chain's canonical representation |
Interoperability | Limited to networks supporting same payment channel protocol (e.g., Lightning) | Wide, but limited to assets listed on the CEX | Theoretically any two chains supporting HTLCs | Specific to a predefined pair of chains (e.g., Ethereum ↔ Arbitrum) |
Frequently Asked Questions
Multi-hop payments are a core mechanism in decentralized networks like the Lightning Network, enabling fast, low-cost transactions across multiple payment channels without requiring direct liquidity between sender and receiver.
A multi-hop payment is a transaction that is routed through a series of intermediate nodes in a payment channel network, such as the Lightning Network, to connect a sender and receiver who do not share a direct payment channel. It works by using Hash Time-Locked Contracts (HTLCs), which create a conditional payment that is only finalized once a cryptographic proof of payment is passed back along the route. This mechanism allows users to transact with anyone in the network, leveraging the collective liquidity of all connected channels without requiring a direct funded channel between the two parties.
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.


