Skip to main content

CCIP Token Support

SkyBridge CCIP supports any ERC-20 token - you do not need to apply for listing or deploy anything yourself. When you bridge a token for the first time, the bridge handles the rest automatically.

How any token gets bridged​

When you bridge an ERC-20 via CCIP:

  1. Source chain - the bridge locks (or burns, for previously bridged tokens) your tokens inside the Diamond.
  2. CCIP network - Chainlink nodes relay the cross-chain message.
  3. Destination chain - the BridgeReceiverFacet receives the CCIP message and either:
    • Unlocks tokens from escrow (if this chain was the origin)
    • Mints new SkyToken tokens (if this chain is not the origin)

On first arrival, if no SkyToken contract exists for that token on the destination chain, the bridge automatically deploys one using CREATE3. This means the SkyToken contract for a given token has the same address on every chain it ever reaches.

The SkyToken model is what lets SkyBridge carry any ERC-20 to any chain - including chains the token's issuer never deployed to. For tokens whose issuers have registered with Chainlink CCIP, SkyBridge can additionally deliver the canonical token directly on the lanes Chainlink supports. See Canonical tokens vs. SkyTokens below.

SkyToken​

SkyToken is the ERC-20 contract the bridge deploys on destination chains. Key properties:

  • Standard ERC-20 - works in any wallet or DeFi protocol that accepts ERC-20s
  • Bridge-controlled mint/burn - the bridge (Diamond) controls mint/burn by default. The owner field is set to address(0) at deployment; the Diamond holds DEFAULT_ADMIN_ROLE and can rotate the CCIP admin via setCCIPAdmin (requires CCIP_OPERATOR_ROLE)
  • CCIP admin - getCCIPAdmin() returns the Diamond address, enabling Chainlink's CCIP token admin registry to recognize the bridge as the authorized operator
  • Deterministic address - same CREATE3 address for the same token across all chains

Canonical tokens vs. SkyTokens​

SkyBridge represents bridged tokens with its own SkyToken (above) - a universal model that works for any ERC-20 on any chain, including chains the token's issuer never deployed to. That universal reach is the point: you're never blocked from a chain just because the issuer hasn't shipped there.

On top of that, some issuers register their token directly with Chainlink CCIP - an official cross-chain pool maintained on Chainlink's network (for example LINK, wstETH, and wstLINK, on the chains their issuers support). On the lanes Chainlink covers, SkyBridge hands you the canonical token - the real, issuer-backed asset - routed through that official pool.

SkyBridge picks the right one automatically on every bridge, with no listing step. At bridge time it checks Chainlink's token registry for the asset you're sending:

  • The issuer's Chainlink pool covers your destination → you receive the canonical token, routed through that official pool.
  • No Chainlink pool covers your destination → you receive a SkyToken - SkyBridge <token> (s<symbol>), for example SkyBridge wstETH (swstETH) - backed 1:1 by the tokens locked on the source chain, extending the asset to a chain it couldn't reach on its own.

Example​

Bridging wstETH:

  • To a chain where Chainlink maintains a wstETH pool → you receive canonical wstETH.
  • To BNB Chain, where there's no Chainlink wstETH pool → you receive SkyBridge wstETH (swstETH), which brings wstETH to a chain it otherwise couldn't reach.

The SkyBridge app shows a notice at review time whenever you'll receive a SkyToken, so you always know which form of the asset you'll get before you confirm.

Canonical coverage grows over time​

Because the check reads Chainlink's live registry at the moment you bridge, canonical coverage expands on its own: as issuers add CCIP pools for new chains, those lanes begin delivering the canonical token automatically, with no SkyBridge update. SkyTokens go on covering everything else - every token, on every chain SkyBridge supports.

Known caveats​

These apply to any token you bridge via CCIP - check them before bridging an unfamiliar token:

Fee-on-transfer tokens​

Tokens that automatically take a percentage of each transfer (e.g., some reflection tokens) can cause accounting issues. The bridge records the amount you send, but the actual amount that arrives at the Diamond may be less due to the built-in fee. The recipient receives the post-fee amount, which may not match what was shown in the UI at the time of bridging.

Centralized-function tokens​

Tokens with owner-controlled functions - such as the ability to freeze balances, blocklist addresses, or forcibly transfer funds - retain those functions on the origin-chain contract but not on the bridge-deployed SkyToken. The bridge deploys a standard SkyToken, so centralized controls do not carry across chains.

SkyToken vs. standard bridge tokens​

Bridge-deployed SkyToken contracts are not interchangeable with tokens deployed by other bridges (e.g., the Optimism Standard Bridge). If both a SkyToken version and an OP Standard Bridge version of the same token exist on a destination chain, they are different contracts at different addresses. You can trade them on L2 DEXs since both represent the same underlying 1:1 value, but they are distinct ERC-20s.

Checking a token before you bridge​

  1. On the source chain, check whether the token implements a fee-on-transfer mechanism (you can check via a block explorer or the token's documentation).
  2. If unsure, try a small test transfer first.