Allbridge

Allbridge transfer confirmation extends beyond the source transaction

Allbridge transfer checks distinguish permission to spend, the actual send transaction and receipt at the destination. Where the selected token requires approval, confirm its allowance before submitting the transfer. After sending, follow the transfer record through to the destination transaction and reconcile the recipient's token balance. A successful approval alone does not move the transfer forward automatically, and source confirmation does not establish destination receipt. Allbridge Core supports pool-based stablecoin transfers and, on eligible routes, transfers through the token's own cross-chain mechanism. Check the recipient, token identity and fee breakdown before signing, while changes remain possible without committing the transfer.

Approval grants permission before the transfer spends tokens

An approval changes what a contract may spend from the connected wallet, so its successful transaction proves permission rather than delivery to another chain. The wallet can therefore show a successful operation while the intended bridge transfer has not started. Read the transaction's operation alongside its status. An approval record and a send record answer different questions, even when both appear in the same wallet history.

An ERC-20 allowance specifies how many tokens a spender may withdraw from an owner's account. Check the token contract, spending contract and permitted amount together. Permission for another spender does not authorize the selected transfer. Core's wallet interface requests the amount needed for approval-based transfers; integrations and existing allowances require their own checks. Approval availability also depends on the source chain's token mechanism.

Wallet state and transfer details before signing

The sending wallet needs the selected asset and sufficient transaction resources, while the destination address must accept the token the chosen route delivers. These prerequisites belong before approval or sending. A matching ticker alone does not establish compatibility across networks or different token contracts.

Source account and available balance

The connected account must match the account holding the input tokens. Check the source network as well as the displayed balance. A wallet can display assets across several networks, although a transaction spends from a particular account on a particular chain. Record the selected token's identity rather than relying entirely on its symbol.

Transaction resources require a separate check. Approval and sending can each consume source network fees where approval applies. Paying an available bridge fee from the transferred asset does not automatically fund every wallet transaction. The wallet confirmation shows the network charge for the operation it is about to submit.

Destination address and accepted asset

The recipient must match the destination network and intended account. Core permits a destination wallet connection or a pasted receiving address. Compare the complete address before signing and complete any required token-receiving setup, such as a Stellar trustline, before sending. A syntactically valid address does not establish who controls it, and a token balance on one network does not establish a balance on another.

Fee choices and expected receipt

The transfer details determine which charges reduce the asset amount and which use a separate payment asset. Include any selected destination gas top-up when reviewing the expected receipt. Pool-based routes use stable-swap pricing, so pool balances affect the received amount separately from fees. Circle's Cross-Chain Transfer Protocol (CCTP) and LayerZero's Omnichain Fungible Token (OFT) routes bypass these pools. Compare token quantities after applicable deductions, rather than comparing the wallets' changing currency valuations.

The send confirmation as the commitment boundary

The wallet's send confirmation is the last routine opportunity to reject incorrect transfer details before signing and submitting the operation to the source network. Reject a mismatched recipient, token or amount at this point. An earlier approval may remain even when you abandon the send. Once the source transaction executes successfully, editing the form cannot alter that transfer. Retain its transaction hash immediately; closing a dialog does not reverse an executed transaction.

Open full-size image

Source execution and destination delivery

A successful source transaction establishes the source-side operation, while completion also requires the selected protocol's verification and a successful destination transaction crediting the recipient.

Open full-size image

The source record

The source record should identify the correct sending account and successful transfer operation. Distinguish execution success from a wallet merely submitting a transaction. Save the source chain with its hash, since a hash without network context can lead to an unsuccessful lookup. Core transfer status queries use this combination to locate the transfer.

Source execution passes the transfer into its underlying protocol. Pool-based routes deposit the source stablecoin into a liquidity pool and calculate its virtual value in vUsd for settlement from the destination pool. CCTP routes burn USDC, while OFT routes burn or lock tokens according to their implementation. The cross-chain message provides evidence of this operation. It does not itself constitute the destination token credit.

The destination record

The selected route's relayer or executor submits the receiving transaction on the destination chain. The destination record should show successful execution and a token credit to the specified recipient. A source transaction can succeed while this later operation remains pending. The route's verification requirements and destination execution determine progress, so an estimated duration cannot substitute for the receiving record.

Receipt reconciliation in token units

Reconcile the recipient's credited token amount with the transfer record, accounting for applicable fees, the selected gas purchase and any pool price impact. For pool-based routes, destination pool balances can change before execution, so the final receipt may differ from the initial estimate. Core displays the transfer fee breakdown before execution. Compare the destination token identity as well as its quantity. An aggregate wallet balance can include unrelated activity, so use the specific receiving transaction when other transfers overlap. A changing currency valuation does not establish a missing token amount.

Should I submit a transfer or keep tracking the existing one?

Submit a new transfer only after confirming that no earlier send for the same intended transfer is pending, successful or of unknown status. Consider a transfer whose required approval has succeeded, but whose destination balance remains unchanged. Check whether a send transaction exists and whether it is pending, successful, failed or of unknown status. The same intended recipient, asset and receipt requirement apply in either case.

Transfer stage	Record to check	Control over the funds
Prepare the transfer	Source balance, supported token pair, recipient and fee breakdown	The sender can revise the proposed transfer before submission.
Authorize spending, if required	Successful approval and sufficient allowance for the selected spender	Tokens remain in the source account, subject to the granted spending permission.
Submit the source transfer	Send transaction hash and successful source execution	The transferred tokens enter a liquidity pool or undergo the selected route's burn or lock operation; the sender can no longer spend them.
Verify and deliver across chains	Transfer progress and destination transaction	Protocol verification and destination execution govern delivery to the specified recipient.
Reconcile the receipt	Correct destination token, recipient credit and received quantity	The recipient account holds the credited tokens.

If approval succeeded and no send was submitted, recheck the proposed transfer before signing its send transaction. If a send is pending or its status is unknown, resolve that record before starting another transfer. If the send failed, confirm that failure and address its cause before retrying. If the send already succeeded, retain that record and follow its destination progress. Sending again creates another transfer rather than accelerating the first. Confirm completion when the intended destination credit reconciles with the transfer record.

Open full-size image

A completed transfer with an apparently empty wallet

A successful destination record alongside an apparently empty wallet calls for account and token reconciliation before any further bridge transaction. Compare the credited recipient with the account currently displayed in the wallet. Confirm the destination network and exact token identity. A wallet's asset display may omit a token even though the account holds it; adding its display entry does not move funds.

If the destination record credits a different address, refreshing the wallet cannot recover that transfer. Recovery depends on who controls the credited account and the receiving service's capabilities, if any. If the records disagree or destination execution remains unresolved, preserve the hashes and error text for investigation. Provide the public transfer details without signing an unrelated transaction or disclosing wallet secrets. The original send remains the starting point for a lookup in Core Explorer.