Starkgate: Native and Bridged Tokens

The canonical deposit mechanism transfers ETH or supported ERC-20 tokens from the depositor's Ethereum account into the L1 bridge contract. A message carries the amount and recipient address to the corresponding Starknet bridge, which mints the destination token after processing that message. The Starknet balance represents an asset held by the Ethereum bridge.

A withdrawal burns the Starknet tokens and sends a message identifying the amount and Ethereum recipient. Once the withdrawal has been proven and its message recorded on Ethereum, the L1 bridge can release the funds to that recorded recipient. These are the two sides of the canonical token's backing arrangement.

Circle CCTP burns native USDC on the source network and enables native USDC to be minted on the destination network using Circle's signed attestation. For USDC, native identifies Circle's issuance on that chain. A transfer through a bridge app can therefore deliver native USDC without creating a separate wrapped USDC token.

Minting alone cannot distinguish native from bridged tokens because both CCTP and canonical deposits involve a destination mint. The difference is the destination token's relationship to the underlying asset: a canonical bridged balance represents Ethereum bridge holdings, while CCTP delivers USDC through Circle's native issuance model.

Standard Transfer and CCTP V2 Fast Transfer have different attestation finality requirements within this native USDC model. Their availability depends on the selected route. An Ethereum-origin transfer pays network gas in ETH even when USDC is the asset being moved.

StarkGate's LayerZero integration includes supported assets such as WBTC and SolvBTC. LayerZero's Omnichain Fungible Token standard, or OFT, coordinates token supply across connected chains. Its transfer design permits different contract arrangements.

Direct OFT

The token contract contains the cross-chain transfer logic. A transfer between direct OFT contracts burns tokens on the source chain and mints tokens through the paired contract on the destination chain.

OFT adapter

A separate contract handles cross-chain operations for an existing token. Depending on the implementation, an adapter can lock tokens or use mint-and-burn permissions. The paired destination contract credits the recipient through the configured minting, unlocking or transfer mechanism.

The OFT label identifies a cross-chain token standard. The particular deployment determines whether existing tokens are held by an adapter or authorized contracts burn and mint them. Calling an asset OFT-enabled does not, by itself, resolve its collateral arrangement.

DAI v0 and DAI on Starknet demonstrate why a displayed name is insufficient for classification. StarkWare introduced new DAI bridge and token contracts while retaining the earlier token's name and symbol. The older token is distinguished as DAI v0.

The DAI v0 bridge has deposits disabled, while withdrawals remain possible. Identifying a balance as bridged DAI therefore leaves a material version question unanswered: its contract determines whether it belongs to the legacy or newer bridge system. A matching ticker does not make those balances interchangeable.

• For a canonical Ethereum deposit, identify the Starknet output as a bridged representation and confirm its token contract.
• For a CCTP transfer, confirm that the selected asset is native USDC on the supported source and destination networks.
• For an OFT asset, distinguish the direct token contract from any adapter before assuming a particular locking or minting arrangement.
• For a Starknet DAI balance, distinguish DAI v0 from DAI by contract; the legacy bridge accepts no new deposits.

View full-size image