Liquidity provision supports cross-chain transfers and swaps by making assets available on a destination network when a user needs them. A pool can hold inventory for execution, or a relayer can advance destination funds and seek reimbursement later. These are different ways to source liquidity—not complete interoperability systems—and each depends on design-specific execution and settlement arrangements.

What liquidity provision means in cross-chain systems

Here, liquidity provision means supplying or positioning assets so a cross-chain operation can deliver or exchange an asset on a destination network. The focus is narrower than general market liquidity: the relevant question is whether an operation has access to the required destination-side asset through its chosen mechanism.

A liquidity source is only one part of the process. A system also needs an execution path for the transfer or swap and a settlement arrangement connecting the relevant steps. A pool may supply inventory for a swap; a relayer may supply funds before reimbursement. Those mechanisms should not be treated as interchangeable, and neither description alone explains every part of a cross-chain transaction.

Even the word “pool” does not identify one universal design. A Uniswap liquidity pool, for example, is a pairing of tokens held in a smart contract and used for swaps on a decentralized exchange. Other AMMs can use more than two assets, different invariants, lending assets, hooks, or other pool structures. That example helps define a pool-based source of swap inventory, but it does not establish that every cross-chain system uses the same structure.

How cross-chain liquidity enables a transfer or swap

At a high level, a user initiates an operation on a source network and specifies a destination-side outcome. The system then needs a way to execute that outcome. When destination-side funds are available, a mechanism may use them to fulfill the recipient’s side of the operation, while a separate process handles settlement between the relevant participants or networks.

One documented example is Across Protocol’s intent lifecycle. In that model, relayers provide destination-chain funds before later reimbursement, and periodic rebalancing is used to keep chain pools sufficiently funded. This separates the user-facing supply of destination funds from the relayer’s later reimbursement. It is an example of one documented design, not a rule for all relayer systems.

For swaps, a pool may supply the assets used by the exchange path. In an automated market maker (AMM), trades interact with liquidity-pool inventory according to the protocol’s mechanism. This does not, by itself, explain how a source-network operation is connected to the destination-side swap or how settlement is completed. Those steps depend on the particular system and assets involved.

It is useful to distinguish three questions when tracing a flow: where the destination asset comes from, how the operation executes, and how any later settlement or reimbursement occurs. Documentation that answers only one question does not establish the complete lifecycle. The available evidence for the relayer example describes advance funding and later reimbursement, but does not specify universal timing, failure handling, or recovery procedures.

Liquidity provision crypto models and their trade-offs

A pool-based model uses assets deposited into a pool as swap inventory. For example, Uniswap’s pool definition describes a token pairing held in a smart contract for swaps. In a cross-chain setting, the relevant operational question is whether the particular path can access suitable inventory on the network where execution is intended. Pool structure and accounting vary, so the example should not be generalized to every protocol.

A solver- or relayer-based model can instead have a participant supply destination funds before being reimbursed later. The Across lifecycle documentation describes this approach along with periodic rebalancing of pools across chains. This places emphasis on the relayer’s ability to provide destination funds and on the later reimbursement and rebalancing arrangements. Other bridge or liquidity designs may use different mechanisms.

These categories differ in how liquidity is sourced and what settlement assumptions follow. A pool model draws on deposited inventory; the cited relayer model involves funds supplied ahead of later reimbursement. Neither is inherently a complete description of the full cross-chain system, and the categories are examples rather than an exhaustive taxonomy. A design may use additional mechanisms or dependencies not captured by these simplified labels.

For an AMM swap, execution can also be affected by public transaction visibility, ordering, pool depth, and price impact before a transaction is included in a block. These considerations apply to the public-blockchain AMM execution analyzed by the BIS; they should not be assumed to describe every swap or cross-chain design. A system using different execution arrangements may have different dependencies.

Risks at the boundary between liquidity and interoperability

Destination inventory and execution. A pool-based path depends on the inventory available to its execution mechanism. For AMM swaps, pool depth, transaction visibility, ordering, and price impact can affect execution before block inclusion. The existence of a pool does not establish that a particular requested operation can be fulfilled on its terms.

Provider and settlement dependencies. In a relayer model, advancing destination funds and receiving later reimbursement are distinct parts of the lifecycle. A reader assessing such a model should identify the documented settlement condition and which parties or mechanisms are involved. The Across example supports the description of advance funding, later reimbursement, and periodic rebalancing; it does not establish general deadlines or remedies for delayed or unsuccessful settlement.

Liquidity-provider exposure. AMM liquidity providers contribute assets to pools and can receive a share of trading fees while bearing inventory and adverse-selection risk. Pool formulas, fee tiers, price ranges, and loss allocation vary by protocol and position. These are design-dependent exposures, not a prediction of returns or a recommendation to provide liquidity.

Interaction between networks and liquidity mechanisms. A pool or relayer is only one component to inspect. The relevant system documentation must explain how its own execution and settlement fit together. The evidence used here does not establish that any particular design has a specific security review, recovery process, fee, availability level, or performance outcome. Those points require separate, current evidence tied to the system in question.

What to verify before assessing a cross-chain liquidity design

Trace the operation from the user’s request through destination-side execution and any subsequent settlement. Identify the liquidity source: deposited pool inventory, funds advanced by a relayer, or another documented arrangement. Then check what the documentation says about the participant supplying funds, the settlement path, and any rebalancing process. Do not infer a complete lifecycle from a description of only the pool or the relayer.

For a pool-based design, verify which pool and assets the documented execution path uses and what pool structure applies. For a relayer-based design, establish who supplies destination funds and how reimbursement and rebalancing are described. These checks clarify the design’s stated assumptions; they do not verify current balances or guarantee that a specific operation will be available.

Finally, distinguish documented facts from unanswered questions. Look for system-specific explanations of execution, settlement, and failure handling, and seek evidence for any claims about fees, availability, performance, security reviews, or recovery procedures. The accepted evidence here does not support conclusions about those specifics or about legal, tax, or regulatory obligations. Those questions require separate, appropriately scoped sources. The central assessment is therefore practical: determine where liquidity comes from, how it is used on the destination side, and what documented process connects that use to settlement.

Sources and references