Funding one liquidity pool from two chains

To fund one liquidity pool from two chains, the protocol must bring both deposits into a shared accounting system or move them onto the same chain. A token sent to a pool contract on Ethereum cannot also count as liquidity in a separate contract on another chain: each contract tracks its own balances. Cross-chain systems solve this with a coordination layer that records deposits from each network and defines how trades and withdrawals settle.

That distinction changes what “one pool” means. In a conventional automated market maker, a pool is a contract on one chain, and its assets and trades live there. In a cross-chain design, the pool may instead be a shared accounting position backed by assets held in vaults on several chains. Chainflip’s protocol overview describes this model: its State Chain records balances and trades, while vaults hold assets on external networks. For a beginner’s account of how Chainflip handles native cross-chain swaps, see the separate explainer.

Can two chains fund the same pool directly?

Only if the pool’s protocol is built to recognize deposits from both chains. In an ordinary single-chain AMM, the answer is no: a deposit on another chain is outside that contract’s balance sheet. Uniswap’s documentation, for example, describes each v3 pool as a unique contract instance; its deployment references also warn that contract addresses differ across networks. A pool with the same token pair on two chains is therefore two pools, with separate liquidity and pricing.

There are two common ways to make liquidity usable across chains. A bridge can move an asset, or issue a representation of it, onto the chain where the pool operates. The user then supplies both assets to that chain’s pool. This keeps the trading pool familiar, but introduces the bridge and the bridged asset as additional dependencies. The second approach is a protocol-level system that accepts assets on their native chains and coordinates the resulting balances in a common ledger. That avoids requiring the user to bridge both assets into one AMM contract, but depends on the protocol’s accounting, validators, and settlement process.

These designs should not be treated as interchangeable. A shared interface or pool name does not prove that liquidity is unified. Before depositing, check whether the protocol says assets from both networks contribute to the same market and whether trades on that market can draw on both balances.

How does a shared cross-chain pool receive deposits?

In Chainflip’s documented liquidity-provider flow, each asset is deposited through its own channel, then credited to the provider’s account on the State Chain. The provider nominates the asset and a refund address, opens a deposit channel for it, and sends funds from the relevant chain. Validators witness the transaction before the account balance is credited. The official liquidity-provider instructions say deposit channels close after 24 hours and advise opening a new channel for each deposit.

After ingress, the assets are available as balances in the protocol’s accounting system; the provider still has to create a position in a market. Chainflip supports range orders, whose price-range logic is similar to Uniswap v3, and limit orders. In practical terms, funding the account is not the same action as supplying funds to an active order. The provider must have enough of the relevant asset balances and submit the order parameters for the pair.

• Confirm the exact asset and network for each deposit; a ticker alone does not identify the right chain or token.
• Use the protocol’s current deposit channel and follow its refund-address instructions.
• Wait for the deposit to be credited to the protocol account, then verify the pair and order settings before placing liquidity.
• Check how withdrawals are requested and where each asset will be sent.

The operational benefit is that the provider can make one market position from assets that originated on different chains. The trade-off is that the pool is no longer just a smart contract whose balance can be inspected on one network. The protocol must correctly observe deposits, update its ledger, and authorize settlement from the relevant vaults. Chainflip’s protocol overview describes vaults controlled by validator threshold signatures, which makes validator and protocol operation part of the model’s trust assumptions.

What should a liquidity provider compare before funding?

Compare the cross-chain route with consolidating assets on one chain. A conventional AMM position is easier to reason about at the contract level: the pool and its balances are on the chain where trades execute. A unified cross-chain account can reduce bridging steps and let liquidity serve a market spanning native assets, but it adds protocol-level settlement and accounting dependencies. Neither structure removes market risk. If the relative price of the pair moves, the asset mix supporting an AMM position can change; concentrated range positions also depend on where the market trades relative to the chosen range, as Uniswap’s v3 design documentation explains.

For most users, the better choice is the route whose custody, accounting, and exit path they can verify—not simply the one with the shorter deposit flow. Read the current protocol instructions for supported assets and channels, confirm which market receives the balances, and understand how an order is closed before committing funds. Then watch for changes to supported networks, deposit-channel rules, pool depth, order behavior, and withdrawal settlement. Those signals show whether the operational convenience still matches the risks and liquidity available.