Allbridge
Allbridge connects supported blockchains through asset-specific transfer protocols
Allbridge transfers supported stablecoins between blockchains through Core, with compatibility determined by the asset and networks selected. A bridge coordinates transactions across separate networks so the recipient receives the supported destination token. Core uses asset-specific transfer protocols, and the available route determines its mechanism, fees and destination asset. Matching those details matters before committing funds.
A familiar ticker does not establish compatibility between token versions. The destination application must accept the particular asset received. Core and the deprecated Classic product also have different mechanisms, so their transfer instructions are not interchangeable.
Receiving the token the destination accepts
A usable transfer requires a supported starting asset, a compatible destination token and a recipient address valid for the chosen network. The source wallet must hold enough funds for the transfer and applicable transaction costs. Before signing, the route details should identify the destination asset, recipient, deductions and expected receipt. Core then coordinates the source transaction, cross-chain verification and destination transaction. Completion means the destination transaction delivered the specified asset to the intended recipient; a successful source transaction alone establishes only the sending stage.
Core and Classic have different operating scopes
Allbridge Core handles stablecoin transfers, while Classic is a deprecated product with a broader history of native and wrapped token bridging. Classic is scheduled to stop in November 2026. Its historical routes and receiving procedures should not be treated as Core capabilities. A token carrying an older bridge label therefore needs its own compatibility assessment before any transfer.
Core also changed architecture: its liquidity pools were discontinued in July 2026. Descriptions of pool swaps and virtual balances belong to that earlier system.
Network support and token identity
Core supports transfers across EVM networks and several networks with different execution models, but support does not make every token transferable between every pair. EVM means Ethereum Virtual Machine. The supported network families include Ethereum-compatible chains alongside Tron, Solana, Sui and Stacks. Each route still needs a compatible asset and transfer mechanism. Stellar support is temporarily unavailable pending an audit of its CCTP implementation.
Token identity includes its network and contract or equivalent identifier. A wallet label cannot establish that two assets have the same redemption mechanism. The destination token also matters when funding another application: receiving a related stablecoin does not establish that the application accepts it.
The protocols behind a supported route
Core selects the transfer mechanism available for the chosen route, rather than sending every asset through one universal bridge contract. Its interface coordinates fees and relayers around the underlying asset protocol. The distinction explains why changing a token can change the available destination or transfer method.
Circle transfer mechanisms
CCTP and CCTP V2
Circle's Cross-Chain Transfer Protocol supports USDC transfers through burning on the source chain and minting on the destination. Circle's attestation service confirms the source event. CCTP and CCTP V2 are route-specific options; their presence does not establish support for unrelated tokens.
xReserve
xReserve supports routes involving USDC-backed stablecoins. The destination asset can therefore differ from USDC itself. Its backing relationship does not erase its separate identity, which remains relevant to the recipient's intended use.
LayerZero OFT
LayerZero's Omnichain Fungible Token standard provides the mechanism for supported USDT and USDe routes. LayerZero handles cross-chain verification for these transfers. Core's former Allbridge Messaging and Wormhole messaging options belonged to the discontinued pool system.
Which costs reduce the amount received?
The service fee, relayer charge and optional destination gas purchase determine transfer deductions, while the source blockchain separately charges for transaction execution. The relayer charge covers destination execution and varies with costs on that network. Fee payment choices also affect whether the transferred stablecoin balance or another wallet balance bears an expense.
Core's current transfer mechanisms do not incur liquidity-pool price impact. The protocol moves assets through their cross-chain mechanisms without a pool swap. A difference between the sent and received amounts therefore needs a fee explanation, rather than an assumed pool exchange rate.
The displayed breakdown governs the selected transfer. Relayer and optional gas top-up fees can be paid in the source gas token, transferred stablecoin or ABR0 where available. A percentage service charge scales with the amount, while destination execution costs can weigh more heavily on smaller transfers.
Destination gas and the next transaction
The recipient does not need destination gas merely to receive a standard Core transfer because relayers submit the destination transaction. Spending the received tokens later is a separate operation. That action can require the network's gas asset, even when the wallet already contains enough stablecoins for its intended payment.
An optional gas top-up can fund subsequent activity where the route supports it. Compare its additional cost with the destination wallet's existing gas balance. Purchasing gas unnecessarily reduces the funds available elsewhere in the transfer budget.
A hypothetical transfer with a minimum usable receipt
This hypothetical example compares fee payment from the transferred stablecoin with separate payment in the source gas token. Assume a supported route, a valid recipient and a destination application accepting the exact output asset. The wallet already holds destination gas. Every amount and wallet condition in this example is hypothetical.
The starting amount is 846 stablecoin units, and the intended use requires at least 844 units after deductions. Suppose the displayed stablecoin-payment quote deducts 2.7 units in total. The calculation is 846 minus 2.7, leaving 843.3 units. That option falls 0.7 units short, despite offering the convenience of paying charges from one balance.
Suppose the separate-payment quote deducts 0.9 stablecoin units and charges the remaining quoted costs to the source gas balance. Its destination amount is 845.1 units, exceeding the requirement by 1.1 units. This option requires sufficient source gas funds. It is not necessarily cheaper overall; part of its cost comes from another asset.
With the source gas expense acceptable, the second option meets the stated requirement. Before authorizing the transfer, the sender checks the recipient, exact destination asset and current quote. If the quote has changed, the sender recalculates whether the amount received still meets the 844-unit minimum. In this example, the destination transaction delivers 845.1 units of that asset to the intended address.
Wallet transfers and application integrations
The Core interface supports direct wallet transfers, and its software development kit lets applications integrate cross-chain functionality into their own products. Integration changes where the transfer begins, rather than removing token compatibility requirements. Developers configure blockchain connections and work with the SDK to prepare the relevant operations.
A recipient can be specified through a destination wallet connection or by entering the destination address. Connecting that second wallet is therefore not the only way to provide the receiving address. The transfer details still need the correct network and token.
Contract custody and verification risks
Core coordinates transfers without holding user liquidity in its own pools, while the underlying protocol contracts perform token movement. The recipient specified in the transfer determines who receives the destination funds. This makes address accuracy consequential: cross-chain verification confirms the source event, rather than deciding whether the sender chose the right person.
The July 2026 security incident preceded the discontinuation of pool transfers. The present architecture has different dependencies, including asset contracts and cross-chain verification services. Transfers still depend on those contracts and verification services functioning correctly.
A confirmed send with no destination receipt
A confirmed source transaction proves the sending stage succeeded; completion still requires confirmation that the destination transaction delivered the tokens. Core's progress display distinguishes sending, message confirmation and destination receipt. Its history preserves past transfers. Those records help identify which stage remains outstanding.
Expected transfer times reflect historical activity, so an estimate is not a deadline. Preserve the original transaction identifier when investigating a delay. Starting another transfer creates another commitment and does not complete the first one. If assistance is needed, the original record identifies the transfer to investigate; a wallet recovery phrase does not.
Allbridge: the short answers
Does approving tokens begin an Allbridge transfer?
Token approval grants a contract permission to spend tokens; it does not initiate the bridge transfer itself. On supported EVM and Tron flows, approval precedes sending. Core requests approval for the amount needed, and that approval can require its own transaction fee.
Can the transfer continue after I close the browser?
A submitted Core transfer can continue after the transfer screen closes. The browser does not perform the underlying cross-chain verification or destination execution. Transfer history provides access to past records when returning to the application. Closing an unsigned wallet prompt, however, does not submit a transfer.
Do I need ABR0 to bridge stablecoins?
ABR0 is an optional fee-payment choice, rather than a universal requirement for Core transfers. Supported alternatives include paying the applicable charges in the source gas token or deducting them from the transferred stablecoins. The selected route determines the available payment choices.
Are automatic Deposit Addresses still available?
Core's Deposit Addresses feature is deprecated and no longer available. It previously provided addresses with routing instructions for automatic bridging to a chosen destination wallet. Its historical setup instructions do not establish that creating or funding such an address remains a supported transfer method.
Where should former Core liquidity providers look for compensation information?
Former Core liquidity providers should use the compensation facility associated with the discontinued pools. Core's product notice directs affected providers there following the July 2026 discontinuation. That notice does not establish an individual claim amount, eligibility decision or payment date.