How Onchain Liquidity Migrates: From Pool Balances to Immediate Execution Capacity

A user delivers an asset on chain A and expects to receive another asset on chain B a few seconds later. The interface shows a single confirmation button, but behind the scenes someone must advance funds on the destination chain. The source-chain assets have not yet settled when the destination-chain payment is made. During that interval, the executor bears price, inventory, finality, and reimbursement risk.

That advance changes how liquidity is measured. Discussions of onchain liquidity once tended to focus on pool balances or a protocol's total value locked. As cross-domain transactions grow, knowing whether funds sit in a particular pool no longer fully answers whether a user can trade. The more useful question is: how much capital can an order access immediately within given time, price, and risk limits?

This article follows the execution of a cross-domain order. The user first specifies the desired outcome; the order enters a competitive network; an executor draws on inventory to make the destination-chain payment; and the settlement system subsequently reimburses the funds. The shift in liquidity concerns its unit of measurement: static balances are increasingly understood as execution capacity subject to time constraints.

Funds in a pool may still be out of an order's reach

Suppose an address or pool holds $10 million. That figure describes its asset balance, but does not say how much can serve a specific order. The asset may be wrong, the funds may already be pledged, access permissions may be restricted, or the destination chain may lack the required inventory. From a user's perspective, funds that cannot complete a trade at the required time and price hardly qualify as available liquidity.

Let x be the order size, τ the maximum acceptable completion time, and δ the maximum acceptable price impact. Effective liquidity can be expressed as:

Here, x is the order size; Tfill(x) is the time from submission to completion for that size; PI(x) is the price impact relative to a benchmark price observable at submission; τ and δ are the acceptable limits on time and price impact; and α is the minimum confidence level for completion. Equation (1) defines effective liquidity as the largest order size satisfying all three constraints. Comparisons across systems must use the same asset pair, time window, benchmark price, and confidence level.

A static pool places capital where trading will occur before orders arrive. Inventory must be pre-positioned for every chain, asset, and price range so that users can trade directly with the pool. This structure is clear and its balances are easy to observe. As the number of assets and chains grows, however, the same capital is divided among more and more compartments. One can be idle while another is still short of funds.

Intent execution moves part of the allocation process to after an order arrives. Funds need not be distributed evenly across every possible path; a solver can choose inventory, venues, and settlement routes in response to the order. This expands the range over which capital can be allocated, while placing route selection and short-term funding with the executor. Pools do not disappear: solvers may still use them for swaps. The pool shifts from being the only market the user faces to being one liquidity source available to the execution network.

Pool balances still matter because they bound the capital the system can draw upon. A balance becomes a trade only when the path, permissions, and executor are all available. Liquidity therefore acquires another dimension: accessibility for execution. Where capital sits is a state; who can use it, when, and for which order is a capability.

An order passes through four moments

A user wants to pay x units of an asset on chain A and receive at least y units of an asset on chain B. The system can express that request as an order:

The order does not prescribe every execution step. It specifies only the input, minimum output, source, destination, and deadline. A participant specializing in order execution is commonly called a solver. It reads the order, checks destination-chain inventory, estimates trading costs and settlement risk, and then decides whether to quote.

From the user's confirmation to the eventual return of funds to the solver, an order records four timestamps: authorization or locking at t₀, the solver's acceptance at t₁, destination-chain payment at t₂, and reimbursement becoming finally available at t₃. The user experience depends mainly on t₂−t₀, while the executor's capital remains tied up for t₃−t₂. A page may show completion within seconds while the solver's risk window continues for minutes or longer.

These two intervals are often combined into a single cross-chain transaction-time metric. Rapid receipt of assets proves only that the destination-chain fill was timely; it does not prove that source-chain settlement was equally fast. If the system publishes only the user's waiting time, outstanding advances accumulating in the execution network remain hidden. When reimbursement slows during a peak period, the solver's ability to quote is often affected before users feel the impact.

Within observation window H, let U_j be the amount of the jth advance awaiting recovery and Δt_j its duration. The capital-time committed across orders can be expressed as ［2–3］:

Capital-time is measured in units of capital multiplied by time. Consider two $1 million orders: one is reimbursed in ten minutes, the other in two hours. Users see the same amount received, but the executor bears very different capital-time commitments. Dividing capital-time by the window length H gives average committed capital over that same window. Dividing the total value of completed orders, V_filled,H, by that average then gives a turnover ratio on a consistent measurement basis:

Higher turnover may result from faster settlement and better netting, or from taking greater risk. In short-term data, both appear as the same funds serving more orders. Liquidity-efficiency analysis must therefore read turnover alongside unsettled balances, failure rates, and worst-case reimbursement times. Pursuing speed alone pushes risk into the still-unsettled tail.

Inventory does not always replenish itself where it is needed. Over a period of sustained flows from chain A to chain B, a solver's inventory on chain B falls while assets awaiting recovery accumulate on chain A. The solver must restore inventory through reverse-direction orders, rebalancing trades, or external capital transfers. Day-to-day cross-domain liquidity management therefore resembles running distributed warehouses: total inventory may be ample while shelves in one city empty during the evening rush.

If orders in opposite directions arrive together, the executor can net them internally. With $1 million of demand from chain A to chain B and $800,000 in the reverse direction, additional rebalancing is theoretically needed only for the $200,000 net flow. A broader order network offers more opportunities to find offsetting demand, while very short waiting times or mismatched assets reduce the scope for netting. Liquidity migration thus gains a network effect: more orders bring not only volume but potentially less external capital movement per trade.

Netting does not require two orders to arrive in the same second. An executor can hold inventory briefly within its risk limits while waiting for reverse flows. Longer waits increase exposure to price movements and changes in chain state. The executor must choose between rebalancing cost and inventory risk: immediately trading back into target inventory costs more but shortens the risk window; waiting for natural reverse flows may improve capital efficiency, or may leave exposure accumulating in a one-way market.

A quote therefore includes several costs. In addition to destination-chain conversion and transaction fees, a solver accounts for committed capital, failure probability, rebalancing costs, and the margin it retains against tail risk. The minimum acceptable fee for a cross-domain order can be written approximately as:

Cexec is the actual execution cost; Ccapital is the opportunity cost of funds while reimbursement remains outstanding; Crebalance is the cost of restoring inventory; Crisk is the risk allowance for tail losses from reorganizations, verification failures, price jumps, or delayed reimbursement; and Πmin is the executor's required minimum profit ［3］. Solvers have different inventories and routes, which produces competing quotes for the same order. An executor that happens to have reverse flows faces a lower Crebalance and may offer a better price. This is a concrete way in which a larger order network can improve liquidity efficiency.

One possible execution architecture combines inventory vaults, programmable pool components, solvers or relayers, and settlement contracts. Inventory vaults hold capital that can be accessed repeatedly; programmable pool components handle same-chain fees, routing, or risk conditions where the architecture uses them; solvers or relayers provide immediate funds on the destination chain; and settlement contracts reimburse them once the conditions are satisfied ［2］. The specific components depend on the protocol's authorization, quoting, and settlement design. This combination should not be presented as a universal industry stack.

The order format also affects whether more executors can discover opportunities to deploy their capital. If every protocol uses a different data structure, authorization method, and payment semantics, solvers must build and audit each integration separately, leaving much capital able to serve only a few order sources. ERC-7683 seeks to address this fragmentation: through a Resolver, protocols translate custom orders into a common representation that solvers can read to inspect steps, payments, and assumptions. As of August 26, 2026, the standard remained a draft. It standardizes only how solvers understand orders; it neither unifies custody arrangements nor guarantees the security of the underlying settlement mechanism ［1］.

The Resolver's role here is translation and explicit disclosure. A protocol can retain its own authorization, auction, and settlement logic while expressing the steps a solver must execute, the payments it expects to receive, and any assumptions that cannot be verified automatically. A solver still has to inspect the Resolver's address and implementation. If the translator supplies incorrect instructions, a common format makes those instructions easier to read; it does not make the errors disappear.

Standardization also changes where competition takes place. Once several solvers can understand an order, they may compete on output amount, completion speed, or execution guarantees. Ranking only by the highest output may let executors win orders by accepting more aggressive settlement risk; ranking only by speed may sacrifice price. The order distributor's ranking rule directly influences the kind of capital the network favors. Beyond public quotes, exclusive order flow and private routing may give a few solvers persistently better netting opportunities, further strengthening their scale advantages.

A common format reduces the cost of understanding an order. Whether a new solver can enter still depends on destination-chain inventory, risk models, execution infrastructure, and a reliable reimbursement path. The standard is like a waybill that more carriers can read; each must still provide the vehicles, goods, and roads.

As liquidity migrates, risk moves too

Pool-based markets concentrate risk in contracts and pricing within the pool. Intent execution gives more responsibility to offchain competitors: solvers must decide which orders to accept, manage inventory across chains, and bear changes in state between the advance of funds and final settlement.

This structure can improve the user experience while creating new concentration risks. If a handful of executors control most inventory, order flow, and proprietary routes, smaller solvers may be able to read orders without having enough opportunities to fill them. A page may show broad multichain coverage, yet very few independent executors may be able to keep quoting under stress.

Settlement delays can also propagate through the execution network. Chain congestion, verification failures, or disputes over state extend Δt, increasing the capital commitment in equation (3). To protect their funds, solvers raise quotes, reduce maximum order sizes, or temporarily withdraw from a route. Users eventually see higher fees or failed trades. The underlying cause may be slower reimbursement temporarily reducing accessible capital, rather than a fall in total funds.

A more difficult case arises when the destination chain has already paid but the source-chain state subsequently becomes invalid. The source chain may reorganize, an authorization may be revoked, verification may stop working, or the settlement contract may find that the order conditions were not met. The user has received the asset, but the solver has lost its normal reimbursement path. A system can use bonds, delayed confirmation, challenge periods, or insurance reserves to share the loss; every protection adds cost or waiting time. Immediate liquidity depends on an executor being willing to keep this uncertainty on its own balance sheet.

Liquidity dashboards therefore need to extend from balance metrics to execution metrics. Total value locked can still describe the capital base. Order fill rates, price impact, completion times, the number of independent solvers, outstanding settlement advances, and failure-related refund rates describe whether that capital is actually serving users. A simplified state vector is:

Here, capitalₜ records the observable capital base; fillRateₜ and fillTimeₜ record whether orders complete promptly; solverCountₜ reflects independent participation in the execution network; unsettledₜ shows advances not yet recovered; and failureRateₜ reveals actual performance during periods of stress.

These metrics must also be broken down by order size and market conditions. A high fill rate for routine small trades does not prove that the system can withstand large one-way flows during congestion. A short average completion time may also conceal a few orders whose funds remain unrecovered for a long time. The pressures that threaten solver survival lie in the tails: how many orders can still be filled when inventory is tightest, how much capital is tied up when settlement is slowest, and how much quoted prices deteriorate when a major executor exits.

The ratio of executable order size under stress to executable order size in normal conditions can also serve as an approximate measure of execution resilience:

If a network can normally fill a $1 million order within the target time but can fill only $100,000 during congestion or one-way flows, Resilience is approximately 0.1. This ratio is comparable only when the asset pair, order direction, τ, δ, α, observation window, and completion criteria are identical, and the stress scenario is specified in advance. Once those conditions are fixed, changes across scenarios for the same network can reveal a contraction that static balances do not show.

Stress tests should also simulate the exit of a major solver. solverCountₜ counts registered or observed participants; actual independence depends on whether they share funding sources, routing services, and settlement dependencies. Five brands sharing one inventory provider may all disappear when that provider stops operating. An execution network needs to disclose observable dependencies so that participant counts do not become a busy-looking facade.

Equation (6) gives an operational data representation for Valflux's liquidity thesis: the data layer for users and agents should express liquidity as an executable state, rather than returning only a pool balance. capitalₜ describes the capital base; fillRateₜ, priceImpactₜ, and fillTimeₜ describe its ability to complete orders; unsettledₜ and failureRateₜ expose the part of the funding cycle in which advances remain unrecovered. When choosing a route, an agent can then compare expected receipt, completion probability, and settlement risk together, instead of assuming that higher TVL makes a route more reliable.

This also defines Valflux's proposed protocol direction for cross-domain markets: put order formats, execution quotes, and settlement outcomes into a single verifiable record so that liquidity providers' capabilities can be compared continuously. Solvers that reliably complete orders over time can build stronger execution reputations. Routes that rely on a single inventory source, frequently cancel orders under stress, or show persistently lengthening reimbursement times should receive lower routing weights. These are market-design principles proposed by Valflux; the specific fields, scoring methods, and permissions over funds remain subject to the actual product version.

The next stage of competition in onchain liquidity is likely to appear in changes to these fields. If the same amount of capital can cover more order sources, settle faster, and keep operating when one solver exits, it has gained stronger cross-domain execution capacity. If broader coverage depends mainly on a few executors continually advancing funds, the multichain label on the dashboard will quickly reveal its limits when settlement slows or inventory becomes unbalanced.

References

1. ERC-7683, “Cross Chain Intents,” Ethereum Improvement Proposals, Draft, created 2024-04-11; status checked 2026-08-26. https://eips.ethereum.org/EIPS/eip-7683.

2. Across Protocol, “Intent Lifecycle in Across,” official documentation, sections on fill and settlement (accessed August 26, 2026). https://docs.across.to/guides/concepts/intent-lifecycle.

3. Across Protocol, “Fees in the System,” official documentation, sections on capital opportunity cost and capital at risk (accessed August 26, 2026). https://docs.across.to/introduction/fees.