Allbridge Cross-Chain Routes and Token Support
Allbridge connects blockchains through Core for native stablecoins, Next for broader token transfers and the deprecated Classic bridge. Core uses CCTP, xReserve or OFT to move supported assets without bridge-owned liquidity pools. Its asset list centers on USDC, USDT and USDe, while the selected network pair determines which transfer mechanism and token representation apply.
Core's liquidity pools ended in July 2026, while Classic was deprecated with shutdown scheduled for November 2026. Those changes affect which transfer instructions remain applicable. Receiving mechanics, costs and network availability belong to the particular product and route.
Key takeaway: Allbridge Core relayers handle destination delivery, while an optional gas top-up funds the recipient's later activity on that network.
Core, Next and Classic
Core focuses on dollar-pegged stablecoins, Next also handles native gas tokens and Classic supported native and wrapped transfers. Next combines token swaps and bridging in a single flow where its selected route supports that combination. Its routing can use OFT, CCTP or intents. Core's native-transfer model preserves the supported stablecoin relationship across networks, including the backed-token representations that apply to xReserve routes. Classic used a separate validator-based model, whose historical instructions remain distinct from either product's current route choices.
Token and Network Support
Core supports selected routes for USDC, USDT and USDe across EVM and non-EVM ecosystems.
Its Ethereum Virtual Machine network coverage includes Ethereum, Polygon, Avalanche, Arbitrum, Base, Optimism and Unichain. The non-EVM networks include Tron, Solana, Sui and Stacks. Each route combines an available asset with its supported source and destination networks. Network coverage does not imply that every listed asset has every possible connection. Core selects the available mechanism for the chosen route and identifies the receiving token. Stellar support in Core is temporarily unavailable while its Stellar CCTP implementation awaits an audit. Next separately lists Stellar as a supported network.
CCTP, xReserve and OFT
Core assigns the transfer mechanism to the selected asset and route, which determines how the destination receives its tokens. Circle's Cross-Chain Transfer Protocol (CCTP), including CCTP V2, uses a burn-and-mint process for USDC. A source-chain burn precedes the corresponding destination mint. Circle supplies the attestation that confirms the source event before destination execution.
xReserve supports routes involving USDC-backed stablecoins. One side can use a backed token rather than USDC itself, which changes how the receiving asset should be understood. The route identifies the actual asset that the recipient receives.
LayerZero's Omnichain Fungible Token (OFT) standard handles Core's supported USDT and USDe routes. LayerZero verification confirms the cross-chain message, while the applicable token contracts execute the movement. Core brings these mechanisms under one interface without making their verification systems identical.
Source Transactions and Destination Delivery
Core separates source-chain submission, cross-chain confirmation and destination execution, so a signed source transaction alone does not establish a completed transfer.
The recipient address identifies who can receive the assets on the selected destination network. Core's source contract collects the applicable fees and passes the tokens to the transfer protocol. That protocol burns or locks the source assets. Token-spending approval can precede this transfer on networks that require it; approval authorizes access and does not deliver tokens.
Cross-chain verification then confirms the source event. Circle's attestation service handles CCTP and xReserve, while LayerZero handles OFT verification. The destination transaction follows the relevant confirmation.
Relayers submit Core's receiving transaction, and the destination contracts release tokens to the specified recipient. The recipient therefore does not need a destination gas balance simply to receive this relayed transfer. Later transactions from that wallet have their own gas requirements.
Does Receiving Stablecoins Also Provide Spending Gas?
Core's optional gas top-up can fund later destination-chain activity; an ordinary stablecoin receipt does not itself supply native gas.
In this hypothetical case, a recipient with no destination gas balance selects a Core route that offers the optional top-up. The recipient wants to use the arriving stablecoins in a later transaction.
With the top-up left off, the relayer can still deliver the stablecoins. The recipient ends with those stablecoins and no new native gas from the transfer. Selecting the available top-up adds destination gas tokens alongside the stablecoin delivery.
The top-up purchases gas, not additional stablecoin principal. Its cost belongs in the transfer quote, and its usefulness depends on the amount purchased and the later transaction's gas requirement. Receiving both assets does not establish that every future transaction has enough gas.
Core Fees and Payment Choices
Core lists a 0.1% service fee on the transferred amount and a relayer fee for destination execution. The relayer charge varies with destination gas costs, and an optional gas purchase adds another cost. The service percentage therefore describes only one component of the total transfer cost.
Relayer fees and optional gas-purchase fees can use the source gas token, the transferred stablecoin or ABR0. ABR0 offers a discount on the relayer fee. These choices concern the specified bridge charges; the source blockchain also charges for its transaction. The route's fee breakdown and the wallet confirmation show the applicable costs before signing.
Core's native transfers have no liquidity-provider fee or exchange-rate price impact. The displayed fees and any selected gas purchase determine the deductions, with the payment choice affecting which balance pays them. Next's combined token conversion and bridging have a different scope from this native-transfer model.
Transfer Timing and History
Core displays an estimated transfer time and records progress through source confirmation and destination delivery. The estimate reflects historical timing; actual processing can finish earlier or later. The progress view distinguishes an ongoing transfer from destination completion. Past transfers remain accessible in History, and Core Explorer provides details such as networks and messaging mechanisms. A source transaction identifies the sending event, while a successful destination receiving transaction establishes the later delivery.
Retired Pools and Classic's Scheduled Shutdown
Core discontinued its liquidity pools in July 2026. The retirement followed a security incident. The former model included liquidity provision and pool-related fees, which belong to that retired system. Former liquidity providers have a separate compensation area for their pool positions. A new stablecoin transfer and a claim concerning an old pool position address different obligations.
Classic was deprecated, with shutdown scheduled for November 2026. Its documented model supported native-to-native, native-to-wrapped, wrapped-to-native and wrapped-to-wrapped transfers. Validators checked source locks or burns before destination contracts unlocked or minted assets. Classic's receiving requirements and historical gas bonuses belonged to that model; they do not define the behavior of Core's current token-native transfers.
Developer Access and Contract Risk
Core provides a software development kit (SDK) and integration guidance so applications can incorporate its cross-chain functionality. The SDK gives developers an alternative to relying solely on the consumer interface. An integration still operates within the supported token mechanisms and routes; using the SDK does not create support for an otherwise unavailable asset or network connection.
Core's non-custodial model routes token movement through the underlying protocol contracts without holding bridge-owned user liquidity. Its own contracts prepare transfers and collect fees. This architecture still relies on contract execution, protocol verification and the operation of the relevant blockchains.
Core's Stellar CCTP implementation has its own audit condition, separate from Quarkslab's assessment of the Soroban bridge.
Popular questions about Allbridge
Why Does Core Request Token Approval Before a Transfer?
Core uses token approval on EVM networks and Tron to obtain permission to spend the required amount. Its documented flow requests the exact transfer amount, with a separate signature and transaction fee for approval. Signing that permission does not send or complete the cross-chain transfer. Solana and Sui use different token-handling mechanics, so Core does not require this approval step there.
Must a Recipient Connect a Wallet Before a Core Transfer?
A recipient can supply the destination address without connecting the receiving wallet. Core supports either connecting that wallet or entering its address directly. The sender still uses the source wallet to authorize the transfer. The receiving address must correspond to the selected destination network, because it identifies the recipient of the destination transaction.
Which Classic Transfers Supported Delegated Receiving?
Classic supported delegated receiving on routes where its Finish for me option was enabled. For destinations other than XRP Ledger, its manual flow required a source Send and a destination Receive. When receiving on XRP Ledger, the user requested Receive and the bridge completed that destination leg. Classic was deprecated, with shutdown scheduled for November 2026; these arrangements do not define Core's relayer flow.
How Does ABR0 Relate to the Legacy ABR Token?
ABR0 is Core's fee-payment token, and legacy ABR holders can migrate at a 1:1 token ratio. ABR0 uses LayerZero's OFT standard and can discount the relayer fee when selected for payment. The migration ratio describes token quantities, not either token's market value. Holding ABR0 is optional because Core also supports gas-token and stablecoin payment choices.
Are Private Transfers Available Through Next?
Next labels private transfers as a forthcoming feature. The announced design uses zero-knowledge proofs to conceal transfer amounts and routes. That announcement is separate from the bridge's available token-transfer functionality. An ordinary Next transfer should not be treated as confidential merely because the product also describes a planned privacy feature.