HOP
Introduction
Section titled “Introduction”HOP is Polkadot's cross-chain hop protocol — a mechanism for moving assets and messages between chains in the Polkadot ecosystem with more flexibility than a plain XCM transfer. The use case is "hop a transfer through one or more intermediate chains to reach its destination," with HOP handling the per-hop routing, proofs, and cleanup of intermediate state.
For most Product developers, HOP is not something you will reach for in day-one flows. The standard payment patterns — Balances.transfer_keep_alive for merchant flows, Coinage for personhood-aware payments — cover the common cases without needing HOP. HOP becomes relevant when a Product crosses chain boundaries in a way standard XCM does not cleanly handle.
Where HOP Fits
Section titled “Where HOP Fits”Three places HOP shows up in a Product context:
- As a building block under cross-chain payments: Coinage and other payment flows can route through HOP underneath when the sender and recipient are on different chains. The Product surface (Coinage,
Balances.transfer_keep_alive) is what a Product calls; HOP is the layer beneath that makes the cross-chain part work. - As a primitive for cross-chain messaging beyond payments: Moving non-asset payloads (state references, capability handles) across chain boundaries in flows that need more flexibility than plain XCM.
- As a target for node-operator and runtime-developer work: Running a HOP-enabled node, integrating HOP into a new Substrate chain. These node-operator and SDK-integration paths are forthcoming separately.
Where to Go Next
Section titled “Where to Go Next”-
How It Works
The conceptual protocol — what a "hop" is, how multi-hop routing is constructed, and the verifier model.
-
Sender Journey
The sender side of a HOP transfer: building, dispatching, and tracking a multi-hop send.
-
Recipient Journey
The recipient side: receiving a HOP transfer that landed on a chain via one or more hops.