What are Non-native Cryptocurrencies?

Non-native assets are representations of an existing cryptocurrency that are deployed on a blockchain other than where the cryptocurrency was originally issued. Because different blockchains operate on distinct programmatic environments and infrastructure, cryptocurrencies cannot move freely between chains by default; they require an intermediary mechanism (such as a bridge or wrapper) to exist and function on another network.

The result is a token that mirrors the value of the original but is technically a distinct contract, maintained by a different issuer, and subject to its own set of risks. The most common non-native cryptocurrencies are as follows:

• Bridged Assets: Cryptocurrencies are “transferred” from their source chain to another chain via a bridge protocol, where they are locked/ burnt on the origin chain and minted in correspondence on the destination chain. For example, whilst native USDC is issued and managed by Circle on supported blockchains, USDC on Berachain is bridged and issued by Stargate. Another example, whilst SOL itself is issued and managed by Solana Foundation, its CEX-issued representations, like Binance-Peg SOL is issued and managed by Binance via custody.

• Wrapped Assets: Cryptocurrencies deposited into a smart contract in exchange for a 1:1 representative token, typically to meet a different token standard on the same or another chain. An example would be Wrapped ETH (WETH), which makes ETH compatible with ERC-20-based DeFi protocols and smart contracts.

• Staked assets / Liquid Staking Tokens/ Liquid Restaking Tokens: Staked assets (including LSTs and LRTs) are tokens issued when users stake their assets into a protocol, representing their staked position while continuing to earn rewards. These tokens are considered non-native as they are issued by third-party protocols and represent a claim on underlying staked assets, rather than the original asset itself.

• LP Tokens/ Vault Receipt Tokens: LP Tokens and Vault Receipt Tokens are issued when users deposit assets into liquidity pools or DeFi vaults, representing their share of the underlying assets. These tokens reflect positions managed by protocols and may change in value based on pool performance or yield strategies. As they are issued by protocols rather than the original asset issuer, they are classified as non-native.

How are Non-native Cryptocurrencies Created?

For most bridged assets, they typically follow a common core process regardless of the underlying bridge design:

• The original cryptocurrency is locked or burned on the source chain.

• A cross-chain message or proof is relayed to the destination chain to verify the transaction.

• A corresponding token is minted or unlocked on the destination chain.

Wrapped assets follow a simpler on-chain flow: the user deposits the original cryptocurrency into a wrapping contract, which locks the underlying asset and mints an equivalent wrapped token. The process is reversible - burning the wrapped token returns the original.

Different bridging methodologies exist, each with its own trust assumptions and risk profiles - from centralised custodial bridges (e.g. Binance-Peg tokens) and liquidity-based bridges (e.g. Celer cBridge, Multichain) to trustless general messaging protocols (e.g. Axelar, Wormhole) and native bridges (e.g. OP Stack Standard Bridge). Some protocols, such as Circle's CCTP, use an attestation-based burn-and-mint mechanism that allows USDC to move across chains in a way that is officially endorsed by Circle, though only on supported chains.

Who is Responsible for Non-native Cryptocurrencies?

Anyone with the ability to deploy a smart contract can issue a non-native cryptocurrency. There is no inherent gatekeeping mechanism that prevents a third party from creating a bridged or wrapped version of any cryptocurrency.

In practice, issuers include bridge protocols, centralised custodians (e.g., CEXs), DeFi protocols, DAOs, and multisig-controlled systems. 

On CoinGecko, the issuer is defined by control, not branding - specifically, the entity that:

• Controls custody, minting, or burning mechanisms

• Can upgrade, pause, or modify the contract

• Is responsible for responding to exploits and de-pegs

For bridged and wrapped assets, the issuer is the entity with ownership over the bridge or wrapping contract, not necessarily the team behind the original cryptocurrency. For example, while USDC is issued by Circle on natively supported chains, a bridged version of USDC on an unsupported chain is issued and controlled by the bridge protocol (e.g., Stargate, Axelar), not Circle.

The canonical representation of a cryptocurrency on a given chain is usually determined by a combination of official endorsement by the original project, ecosystem or governance consensus, and market adoption.

What are the Risks of Non-native Cryptocurrencies?

Non-native assets carry additional risks compared to their native counterparts, primarily due to the added layers of infrastructure and third-party control involved. Key risks include:

• Smart contract exploits - vulnerabilities in the bridge or wrapper contract can be exploited, leading to loss of funds and depegging of the non-native token.

• Custody and issuer failure - centralised bridges or custodians can be compromised, shut down, or become insolvent, leaving bridged assets unredeemable.

• Depegging - if confidence in the bridge is lost, the non-native token may trade below the value of the underlying asset, even if the original remains unaffected.

• Liquidity disruptions - deposit and withdrawal halts on compromised bridges can affect the price data aggregated from other chains, creating inaccuracies in market data.

Critically, these risks are independent of the underlying native asset. The Horizon and Multichain bridge hacks are notable proofs that vulnerabilities in the bridge infrastructure may cause bridged assets to depeg while the original native cryptocurrency remains entirely unaffected.

Notable Examples of Non-native Cryptocurrencies

• Bridged stablecoins: For example, Stargate Bridged USDC (Berachain) is issued by Stargate on a blockchain (Berachain) not natively supported by Circle. Similarly, Bridged USDT exists across many chains where Tether does not natively issue the token, with various bridge protocols acting as the effective issuer.

• Bridged native gas tokens: For example, Wormhole Bridged SOL is a bridged representation of SOL issued by Wormhole on non-Solana chains. Binance-Peg SOL is a custodial representation issued by Binance and is an example of how centralised exchanges can issue their own custodial representations of tokens.

• Wrapped assets: For example, Wrapped ETH (WETH) is the canonical wrapped version of ETH, enabling it to function in ERC-20-based DeFi.

• Staked assets / Liquid Staking Tokens/ Liquid Restaking Tokens: Lido’s stETH is a prominent example, which represents ETH staked via Lido.

• LP Tokens/ Vault Receipt Tokens/ Yield-bearing Tokens: One example is Steakhouse USDC Morpho Vault, which is a yield-bearing "share" token that represents users’ ownership in the Steakhouse USDC vault.

Why Does CoinGecko List Non-native Cryptocurrencies Separately?

CoinGecko separates non-native assets from their native counterparts for the following reasons:

• Price integrity: In the event of price de-pegs due to a bridge exploit, consolidating it with the native asset's price data would skew aggregated prices and mislead users about the true value of the original. Separate listings will contain the impact of any disruption to the affected asset only.

• Data accuracy: Non-native tokens may have significant trading volume on certain chains due to various reasons. If merged with the native cryptocurrency, this volume could disproportionately influence price aggregation, particularly if the bridged asset is compromised.

• User transparency: Distinct listing pages make the issuer, mechanism, and risk profile of each asset variant clear. Users can make informed decisions about which version of a token they are holding or trading, and understand that a Bridged USDC is not the same as a natively issued USDC redeemable 1:1 with Circle.

How to Identify and Find Non-native Cryptocurrencies on CoinGecko

Users can identify and explore non-native cryptocurrencies on CoinGecko through several methods:

1. Browse by Categories

CoinGecko groups common rehypothecated asset types into dedicated categories. For examples:

• Bridged Assets - https://www.coingecko.com/en/categories/bridged-tokens 

• Wrapped Assets - https://www.coingecko.com/en/categories/wrapped-tokens 

• Liquid Staking Tokens - https://www.coingecko.com/en/categories/liquid-staking 

These categories provide a structured way to explore assets of similar types and mechanisms.

2. Rehypothecated Tokens Ranking Page

You can view a curated list of non-native and rehypothecated assets ranked by market capitalization on the dedicated page:

• Rehypothecated Tokens Ranking - https://www.coingecko.com/en/top-market-cap-rehypothecated 

This page aggregates various non-native asset types across chains for easier discovery and comparison.

3. Search by Contract Address

Each non-native token exists as a unique smart contract on a specific blockchain. You may paste the token's contract address into the CoinGecko search bar, directly locating the exact token instance.

This is the most precise way to identify a specific variant of a token across different chains.

4. Search by Naming Conventions

Non-native tokens on CoinGecko follow standardized naming conventions. You can:

• Search using keywords like “bridged” or “wrapped”, depending on the asset class

• Combine them with the token ticker (e.g., “Bridged USDC”, “Wrapped ETH”)

• Check the associated network/chain in the result

This helps distinguish between multiple versions of the same underlying asset across different chains.

References

List of Native USDT: Tether - Supported Protocols

List of Native USDC: Circle - Multichain USDC

Got more questions?

Please submit a ticket to our support team if you have any questions. Thank you.