Allbridge Native Versus Legacy Wrapped Token Transfers
Allbridge Core transfers supported stablecoins through native cross-chain standards, while deprecated Classic supported both native and bridge-issued wrapped tokens. The native label describes the asset delivered; it does not identify a single transfer mechanism. Classic is scheduled to stop in November 2026.
Native Output and Bridge-Issued Representations
A native stablecoin transfer delivers the supported canonical asset on the destination network. A Classic wrapper represented an asset through the bridge's own minting and backing model. Both could refer to the same underlying currency, yet their token identities and redemption mechanisms differed.
Native also describes a blockchain's gas coin. A canonical stablecoin is not automatically the asset used to pay network transaction fees. Native stablecoin delivery and a destination gas top-up therefore address different needs. The token's role on its network matters alongside its relationship to the bridge.
Core's Asset-Specific Transfer Standards
Core selects its transfer standard from the supported asset and network pair. Its main stablecoins are USDC, USDT and USDe. Support for those assets does not make every network pair available.
USDC Through CCTP
Circle's Cross-Chain Transfer Protocol (CCTP) moves USDC through a burn-and-mint model. Core also supports CCTP V2 on applicable routes. The source burn and destination mint transfer native USDC without creating a Classic wrapper. Circle's attestation service verifies the source event for destination execution.
USDC-Backed Assets Through xReserve
xReserve supports USDC-backed stablecoins, so one side of a supported route can use a backed token rather than USDC itself. Circle's xReserve provides attestations for USDC deposits and for withdrawals after a verified burn of the backed token. Describing every such output simply as USDC would hide a material difference in token identity.
USDT and USDe Through OFT
LayerZero's Omnichain Fungible Token (OFT) standard handles Core's supported USDT and USDe transfers. LayerZero supplies the cross-chain verification for those routes. The destination receives the supported stablecoin through its OFT integration, without creating a Classic bridge wrapper.
Classic's Native and Wrapped Combinations
Classic supported native-to-native, native-to-wrapped, wrapped-to-native and wrapped-to-wrapped transfers. In its contract-based routes, a validator checked the source lock or burn before the destination contract unlocked or minted the corresponding asset. These combinations described token forms; they did not create four interchangeable paths for every asset.
Native Inputs
Native-to-native transfers locked the source asset and unlocked the requested token from the destination contract's liquidity. The recipient received a native asset even though the bridge depended on liquidity held in its contracts.
Native-to-wrapped transfers also began with locked source assets, but the destination contract minted a representation. The locked assets backed that new representation. Minting established a destination token balance; it did not turn the wrapper into the underlying native asset on that chain.
Wrapped Inputs
Wrapped-to-native transfers burned the wrapped input and unlocked native tokens from the destination contract. The burn removed the submitted representation from circulation. Unlocking depended on the validator confirming the source burn.
Wrapped-to-wrapped transfers burned the input representation and minted a representation on the destination chain. The process moved a wrapped balance between networks without redeeming it into a native asset. This distinction mattered when identifying which token a receiving application could accept.
Does a Successful Send Confirm Destination Delivery?
A successful send confirms the source-chain operation, while destination delivery requires its own verified execution. In Core, the cross-chain message proves a source burn or lock; it does not move tokens itself. Classic's contract-based routes required validator confirmation before the destination contract unlocked or minted assets. A source transaction identifier therefore does not, by itself, establish a destination token balance.
Backing and Verification Responsibilities
Core's contracts prepare transfers and collect fees, while CCTP, xReserve or OFT contracts perform the token movement. The current model does not hold user liquidity in bridge-owned pools. The destination asset follows the supported token protocol rather than Classic's wrapper model.
Classic's contracts held the assets that backed its wrapped representations or supplied native payouts. Its validator checked the lock or burn and supplied the authorization needed for contract-based receiving. A wrapper consequently depended on both its backing and the bridge's verification path.
Pool Retirement and Classic's Scheduled Shutdown
Core's liquidity pools were discontinued in July 2026. Pool-based transfers ended after that month's security incident, retiring the old Core liquidity and messaging model.
Classic is deprecated, with shutdown scheduled for November 2026. That schedule concerns Classic; it does not retire Core's native-transfer model. The announced month does not specify a final operating day for every historical route.
Can Core Transfer Any Classic Wrapped Token?
Core can transfer a legacy balance only when its exact token and network pair qualify as supported inputs. Core's native-transfer paths and Classic's wrapper-redemption paths belong to different systems. Burning a Classic wrapper was part of Classic's supported wrapped-to-native or wrapped-to-wrapped transfers. That burn required the associated validation and destination execution; it was not a standalone conversion into any native stablecoin. An existing balance needs a supported transfer or conversion path for its exact representation.
Next's Swap and Native Gas-Token Scope
Next combines swaps and bridging for supported tokens and handles native gas-token transfers. Its routing can use OFT, CCTP or intents. This broader flow differs from Core's native stablecoin transfer model, which does not perform a swap. Next can therefore involve an asset conversion alongside bridging. Moving a native gas token or receiving a different asset can call for this combined flow rather than a stablecoin-only transfer.
Choosing the Required Token Representation
A supported CCTP route delivers native USDC; Classic's native-to-wrapped model minted a bridge representation. CCTP follows USDC's transfer protocol, while Classic's wrapper depended on locked assets. Those outputs carry different compatibility requirements, even when both balances refer to the same underlying currency.
- Match canonical stablecoin delivery to a supported Core route for the exact destination asset.
- On an xReserve route, identify whether the destination asset is USDC or a USDC-backed token.
- Establish support for an existing Classic wrapper before selecting its transfer or conversion path.
- When interpreting a legacy native payout, identify whether Classic released destination contract liquidity.
- Confirm that the intended destination application accepts the exact token representation that the bridge delivers.
A completed bridge transfer can leave tokens that the intended destination application cannot accept.
Allbridge: the short answers
Does Native Stablecoin Status Mean One Contract Address Across Chains?
Native stablecoin status does not imply a universal token address across networks. Each supported network has its own token contract, mint or equivalent asset identifier. The destination asset must match that network's accepted representation. Classic wrappers likewise had network-specific identifiers, so comparing a ticker without its network and token identity can confuse separate assets.
Who Completed Classic's Native or Wrapped Payouts on XRP Ledger?
XRPL Sender handled Classic's destination payout on XRP Ledger after checking the finality of the required NEAR record. The receiving request passed through validation and an outgoing-transactions ledger on NEAR. This was Classic's special bridge-completed receiving case, separate from its manual destination-contract model. Transfers leaving XRP Ledger followed their own receiving flow on the destination chain.
How Did Classic's Gas Bonus Differ From Core's Optional top-up?
Classic's delegated receiving included bonus gas only under its supported low-balance conditions, while Core offers an optional gas top-up. In Classic, the destination wallet's gas balance had to fall below the chain's bonus amount for that bonus to apply. The feature concerned gas for later transactions, separate from whether the delivered token was native or wrapped.
Does Wormhole in an Old Core Record Identify a Classic Wrapped Token?
Wormhole messaging in an old Core record identifies a former Core messaging option, not Classic's token representation. Core's Allbridge Messaging and Wormhole options belonged to its pool-based transfers and were deprecated after the July 2026 security incident. A messaging provider explains how chains verify a transfer; it does not, by itself, establish that an asset is wrapped.
Which Security Assessment Applies to a Legacy wrapped-token Route?
Classic's security documentation lists Hacken and Kudelski Security audits. Each applies only to the implementation and scope that its report examined. The Quarkslab Soroban assessment concerned that implementation of Core. It does not automatically validate Classic's contracts, validator or wrapped-token backing. Separate products can share a brand while relying on different contracts and verification mechanisms, so one report cannot establish the security of every legacy representation.