Cbridge

Cbridge separates transfer submission from confirmation of receipt

Cbridge requires wallet confirmation to submit a transfer, while Transfer History lets you follow its progress toward destination receipt. Review the selected networks, token, amount, receiving address and receiving estimate before signing. When a token approval is necessary, that approval authorizes spending; the transfer still needs its own confirmation. After submission, distinguish the source transaction from the destination transaction, since they establish different parts of the transfer. If the record reports a refundable failure, follow its refund action and check the return transaction. A submission notice, a completed transfer and a completed refund each describe a different outcome for your funds.

Transfer submission and the refund alternative

The normal transfer path ends with tokens reaching the destination address. A refundable failure takes a different path: the bridge prepares a return of the affected assets. Compare the recorded status and receiving chain before deciding which outcome you’re checking.

Use the refund action only when the transfer record identifies a refundable failure. A transfer awaiting confirmation or fund release hasn’t reached that state merely because its estimate has elapsed. Repeating the transfer creates another transaction; it doesn’t repair the existing record.

Approval and transfer confirmation have different effects

The wallet prompt determines what you’re authorizing. A spending approval and a bridge transaction can appear close together, but their effects differ.

Permission to spend a token

An ERC-20 approval grants a specified spender an allowance over a token balance. It doesn’t itself deliver tokens to another chain. Check the spender and allowance in the wallet’s approval details. An existing sufficient allowance can remove the need for another approval, so the number of prompts isn’t a reliable measure of progress.

Authorization to submit the transfer

The documented interface presents Confirm Transfer before the wallet’s transaction confirmation. That wallet request authorizes the bridge operation. Read its details before signing, especially when the wallet reveals a contract interaction rather than a simple token payment. If a pool-based transfer will deliver native currency to a contract, first confirm that the recipient contract can receive it. Once the transaction executes, changing the form doesn’t change its recorded parameters.

The selections that belong in the final review

The transfer estimate belongs to a particular source chain, destination chain, token and amount. Changing a selection changes the request that the bridge must evaluate.

Network, asset and receiving address

The wallet must use the source network for the outgoing transaction. Confirm the destination separately: the same address format doesn’t identify the network where funds should arrive. ERC-20 pool-based transfer parameters include the receiver, source token address, amount and destination chain identifier. Those details determine the instruction that the contract receives.

Keep enough of the source network’s gas asset for the transaction. A transferable token balance alone doesn’t establish that the wallet can pay execution costs.

Receiving estimate and applicable limits

The receiving estimate accounts for the selected transfer’s bridge rate and fees. Review the latest estimate before submission because those inputs can change during approval. For pool-based transfers, slippage settings help determine the minimum acceptable receiving amount. Review that minimum before confirming. Slippage tolerance doesn’t apply to mapped-asset transfers.

Amount limits and pool capacity can also prevent submission. A token’s presence in the selector doesn’t establish that every amount is available. Resolve an estimate error before approving the outgoing transfer rather than treating it as a message that confirmation will bypass.

Transfer History states and their completion meaning

Transfer History combines the transfer identifier with sending information, receiving information and status. Its underlying status codes distinguish progress from completion and refund preparation from a finished return. The following values identify selected documented states; they aren’t timing estimates.

The record also distinguishes waiting for State Guardian Network confirmation from waiting for destination release. Neither state establishes that a refund is available.

Receipts that establish what happened

A source transaction receipt establishes what executed on the sending chain. The destination receipt establishes the receiving transaction. Match the history entry to its transaction details rather than relying on a wallet notification or a remembered amount.

View image file

Check the chain, transaction outcome, receiving address and token movement. The history data separates source sending information from destination receiving information, including each side’s chain, token and amount. That separation matters when the received amount differs from the amount sent.

A saved screenshot preserves what the interface displayed at that moment. The transaction hash identifies a transaction that you can inspect again. Keep the source hash alongside the transfer identifier: for pool-based transfers, the bridge derives its transfer identifier from transfer parameters, so it isn’t simply another name for the transaction hash.

Refund confirmation after a liquidity failure

Insufficient destination liquidity can make a transfer refundable. The refund action belongs to that failed transfer’s record, and the bridge must prepare the required refund information before the return transaction can proceed.

A pool-based refund requires an on-chain withdrawal transaction using refund information supplied by the gateway. The wallet confirmation authorizes that transaction. Check its execution and the returned assets on the source chain; requesting a refund doesn’t establish that the assets have returned.

If the interface hasn’t made confirmation available, a fresh outgoing transfer won’t accelerate preparation. Keep the original identifier and transaction hash available so that any investigation concerns the affected transfer.

Delays after the source transaction succeeds

A successful source transaction can precede destination release by an additional waiting period. The bridge applies security limits, including configured delay thresholds and limits on volume within a defined period.

Those conditions explain why a source receipt doesn’t establish an arrival deadline. A transfer above an applicable delay threshold may enter delayed execution. Network processing and bridge confirmation also affect progress. Read the transfer’s actual status rather than assigning the same waiting time to every route.

For a record stuck at Submitting, first establish whether the source transaction confirmed. A confirmed source transaction with an unchanged bridge status needs different investigation from a transaction still waiting on the sending chain.

The next action follows the recorded outcome

Continue with the destination task after confirming receipt of the intended asset at the intended address. If the transfer ended in a refund, any new attempt needs a fresh estimate and review of the condition that caused the failure.

Keep unresolved transfers separate from new transfer decisions. An elapsed estimate alone establishes neither delivery nor recovery.

Questions and answers about Cbridge