Native liquidity is supply of a token that its issuer makes available directly on a network, so the token there is the issuer's own and every venue on that chain trades the same asset. Bridged liquidity comes from a bridge instead, either as a wrapped version backed by tokens locked on another chain, or as pools of tokens the bridge holds on each chain and pays out from. The difference decides which token a holder receives, what it depends on, and whether liquidity stays together or splits across versions.
Last updated: September 28, 2026.
How does bridged liquidity work?
Bridged liquidity takes one of two forms.
In a lock-and-mint bridge, the original token is locked in a contract on its home chain and the bridge mints a wrapped version on the destination. The wrapped token is issued by the bridge, not the original issuer, and it is backed by the locked tokens.
In a liquidity-pool bridge, the bridge keeps a supply of the token on each chain. A user deposits on the source chain and receives tokens from the pool on the destination. The amount that can move depends on how much the destination pool holds, and pools have to be rebalanced as funds flow in one direction.
How does native liquidity work?
The issuer makes its own token available on each network. It can mint directly on each chain, or use a burn-and-mint standard that moves supply between chains. Tokens are burned on the source chain and the same amount is minted on the destination, so total supply stays the same and no pool is needed.
LayerZero's OFT standard works this way. An existing token can use an OFT Adapter, which usually escrows tokens on the token's original chain while OFT contracts on other chains mint and burn. Cross-chain token standards compares the main approaches.
| Model | What arrives on the destination | What it depends on | Effect on liquidity |
|---|---|---|---|
| Lock and mint | A wrapped version from the bridge | The bridge's contracts and locked tokens | Trading splits between original and wrapped |
| Liquidity pool | Tokens paid out from the pool | Enough tokens in the destination pool | Capital sits in pools on each chain |
| Issuer-native, including burn and mint | The issuer's own token | The issuer's contracts and messaging setup | One version of the asset on each chain |
Why does fragmentation matter?
When the same asset exists in several versions on one chain, trading depth splits between them. A buyer of one version cannot always use the other's liquidity, and applications have to choose which versions they accept. Users can end up holding a token that a venue or wallet does not recognize as the asset they meant to hold.
Native liquidity reduces this by giving each chain one issuer version that venues and wallets can standardize on, though bridged versions can still exist alongside it. Native vs bridged tokens explains how to tell the two apart, and stablecoin chain support covers what native support on a network means for a stablecoin.
FAQ
Is a liquidity-pool bridge the same as a wrapped-token bridge?
No. A pool bridge pays out tokens it already holds on the destination, which can be the native token. A wrapped-token bridge mints its own version.
Does native liquidity remove every dependency?
No. It changes what the token depends on. A burn-and-mint token relies on the issuer's contracts and on how cross-chain messages are verified and delivered.
Can a token move from bridged to native liquidity?
Yes. An issuer can adopt a native standard on a network where its token was previously bridged. How existing bridged holders move over is the issuer's decision.
Keep one version of the asset
For an asset and the networks its holders need, request a custom briefing.