Does a refund revoke the token allowance from the original approval?

The bridge's refund calls do not revoke any remaining ERC-20 token allowance. The token contract tracks spending permission separately from the bridge's withdrawal or mint. A successful refund therefore does not establish that the spender's remaining allowance is zero. Changing that permission requires a separate allowance update.

Is the refund transfer ID the same as the wallet transaction hash?

The bridge transfer ID and the blockchain transaction hash identify different records. The status query takes the bridge identifier, which follows the original transfer's parameters and contract version. A source-chain transaction hash identifies the transaction containing that transfer. Keeping both identifiers avoids substituting a transaction hash for the expected transfer ID.

What happens if the same authorized refund is submitted twice?

The pool contract rejects a withdrawal identifier it has already processed. Its duplicate protection also covers a withdrawal placed into delayed release. The V2 vault and pegged bridge similarly record processed claim identifiers. Resubmitting the authorization cannot bypass that protection or force queued tokens to release early.

Can another account redirect Celerbridge refunds by submitting the claim?

Submitting an existing signed authorization does not let the submitting account replace its receiving address. The verified message specifies the receiving account, token, and amount. The documented contract calls take that message with its signatures, rather than a separately chosen refund recipient. Changing those signed details invalidates the authorization.

When should a refundable transfer be escalated to support?

Contact support if the transfer remains in TRANSFER_TO_BE_REFUNDED for more than 30 minutes without progressing to usable refund data. This escalation point concerns stalled preparation, not a promised completion deadline. Keep the original source-chain transaction hash available so support can identify the affected transfer and investigate its processing state.

Does request Refund also remove a liquidity provider's pool position?

Request Refund concerns a failed bridge transfer, while removing a liquidity provider's position uses a separate withdrawal flow. Transfer refunds use getTransferStatus and its refund authorization. Contract LP withdrawals involve WithdrawInbox and their own liquidity-status query.

Could a token restriction cause a refund without a slippage error?

Token restrictions can appear as refund reasons independently of slippage. The gateway distinguishes an unsupported or unavailable token, a disabled token transfer, and an unsupported destination chain. These reasons explain failures when the transfer status calls for a refund; an estimation error alone does not establish a refundable on-chain transfer.

Can a contract receive a refund paid as a native gas token?

A receiving contract must accept native token payments within the payout call's gas allowance for a native-token refund to finish. The pool and OriginalTokenVaultV2 unwrap the configured wrapped-native asset before paying the receiver. A rejected payment reverts the transaction attempting the payout, including a delayed-release transaction. Holding transaction gas does not establish this receiving capability.

Celerbridge

Celerbridge refunds through on-chain claims after transfer failure

Celerbridge refunds return assets from eligible failed transfers in Celer's cBridge through an on-chain claim. The gateway prepares refund data, and Celer State Guardian Network validators authorize the contract operation. A failed pool transfer uses a withdrawal; failed xAsset transfers can require releasing locked original tokens or minting replacement pegged tokens. Refund eligibility and prepared authorization must precede submission. A transfer still awaiting delivery needs a different diagnosis, while a submitted refund transaction still needs confirmation and, where applicable, delayed release.

The short version: Confirmed refund transactions can still leave tokens awaiting release when the bridge contract applies a configured delay.

Gateway preparation, SGN signatures, and source-chain contracts

The gateway connects the recorded failure with validator authorization, while the source-chain contract performs the withdrawal or mint needed to return the affected assets. The gateway prepares the refund message and associated signature data. Celer State Guardian Network (SGN) validators provide authorization the contract checks. A wallet transaction submits that authorization for execution. The original transfer type determines which contract can perform the refund, so a generic withdrawal call cannot replace every refund operation.

Gateway preparation runs separately from the wallet's on-chain submission. An application polls getTransferStatus to discover when the required data becomes available. A request to recover funds can therefore remain in preparation before the wallet has a usable transaction to confirm.

When does a failed transfer qualify for a refund?

A transfer enters the refund flow when its status becomes TRANSFER_TO_BE_REFUNDED; the distinct TRANSFER_FAILED status describes a failure requiring no refund. In the gateway's status mapping, these are codes 6 and 2, respectively. A failed transaction label alone does not establish refund eligibility. A failure before assets enter the bridge requires a different interpretation from an accepted transfer awaiting recovery.

Insufficient destination liquidity or restrictive slippage can cause a pool-based transfer to need a refund. The reason describes what prevented delivery; the refund status establishes which recovery stage applies. Waiting for SGN confirmation or destination fund release remains part of transfer processing until the reported state changes.

Pool withdrawals and xAsset token restoration

Pool-based refunds return assets through the bridge pool, while xAsset refunds reverse the relevant locking or burning operation. The original movement of tokens determines the recovery mechanism.

Refunds from xLiquidity pools

In xLiquidity, the source pool receives tokens while a destination pool supplies the cross-chain payout. An eligible failed transfer uses the source-chain bridge's withdraw function for recovery. The gateway supplies the authorized message, signatures, signer addresses, and signing powers. The function name also appears in liquidity removal, although a failed-transfer refund has its own gateway status and authorization. Liquidity providers (LPs) use a separate management flow when removing a pool position.

Refunds after xAsset deposits or burns

The xAsset model has different recovery directions because its original and pegged tokens have different roles. Recovery either releases an existing locked asset or restores tokens already burned.

Releasing a locked original token

A failed deposit-to-mint transfer can leave original tokens locked in OriginalTokenVault on the source chain. Its refund uses the vault's withdraw operation with gateway-provided authorization. This releases assets from the vault involved in the deposit. Calling the pool bridge would target the wrong mechanism, even though both paths use a function named withdraw.

Replacing a burned pegged token

When a failed transfer has already burned pegged tokens, recovery uses PeggedTokenBridge.mint to restore corresponding tokens on the burn chain. xAsset v2 also supports transfers between compatible pegged chains, so a burn does not always target the original-token chain. The refund still follows the contract and version involved in the failed burn.

Refund parameters and the progress they describe

A refund query combines an identifier for the original transfer with fields describing eligibility, prepared authorization, and source-chain waiting. The gateway's numeric status values describe processing states, while a confirmation-block count measures a blockchain requirement. Neither field supplies a universal refund completion time.

Refund parameters and the progress they describe in brief
Parameter	Role in the refund	Documented value or format	Refund progress or confirmation condition
`transfer_id`	Identifies the original bridge transfer	String supplied to the status query	Selects the transfer being monitored
`status`	Reports the refund stage	6: eligible; 7: preparing; 8: ready; 9: confirming; 10: refunded	Readiness precedes on-chain confirmation
`refund_reason`	Explains a refundable failure	`XferStatus` reason code	Applies when the transfer is to be refunded
`wd_onchain`	Carries the serialized refund authorization	Encoded string for contract input	Supplies claim data with the signature fields
`block_delay`	Reports source-chain confirmation waiting	Number of source-chain blocks	Counts blocks, without fixing elapsed minutes
Prepared authorization enables submission; source-chain confirmation and applicable release controls determine later progress.

The refund request in transfer history

For transfers failing because of insufficient destination liquidity or unfavorable slippage, cBridge's transfer history provides the Request Refund action. The interface also explains the failure. This control belongs to the recorded transfer and starts its recovery request. A wallet error, rejected approval, or abandoned transaction alone does not establish a refundable bridge transfer.

How long does refund preparation take?

Gateway preparation takes several minutes in the documented refund flow, while on-chain confirmation and any configured release delay contribute separate waiting periods. The preparation estimate covers assembling transaction data. It does not include every later step required for tokens to reach the receiving account. A wallet awaiting usable authorization and a wallet awaiting confirmation have different outstanding requirements, even when both display an unfinished refund.

Source-chain confirmation follows that network's block progression. The block_delay field expresses a waiting-block requirement, so translating it into minutes requires the relevant chain's timing. Heavy traffic and bridge rate limits can also delay processing. A duration associated with an ordinary cross-chain transfer should not become a refund deadline.

Authorization bytes and contract arguments

The prepared refund data contains a serialized message and validator signatures, with signer addresses and signing powers preserving the authorization's meaning. Developer integrations convert these returned values into the contract's expected types. Base64-encoded message and signature strings become bytes, signer bytes become addresses, and signing powers become numeric values. Encoding conversion preserves the message; editing its recipient, token, or amount changes what the validators authorized.

The pool withdrawal requires signatures representing more than two-thirds of its current signing power. Validator weight determines this threshold, so counting signatures alone cannot establish sufficient authorization. Signatures, signer addresses, and powers must retain their corresponding order. The contract verifies the message in a domain incorporating its chain and address, which prevents treating authorization for one deployment as interchangeable with another deployment.

Applications can perform these conversions before presenting the refund transaction for wallet confirmation.

The authorized amount and transaction gas

The refund message specifies the asset, receiving account, and amount the contract can return, while transaction gas belongs to the blockchain submission. An earlier destination receive estimate describes the proposed forward transfer. It is a different quantity from an authorized source-chain refund. Bridge rates and transfer fees help explain that earlier quote, without establishing the eventual refund amount by themselves.

For a direct wallet submission, the sending account needs the source chain's gas asset to pay the transaction fee. Holding the transferred token alone may not satisfy that requirement. Gas consumed by an approval, transfer attempt, or refund transaction remains a separate expense from the recovered tokens.

Contract versions and active safeguards

A refund must target the deployment associated with the failed transfer, including its applicable vault or pegged-bridge version. A deposit through OriginalTokenVaultV2 requires that vault version for recovery. A burn through PeggedTokenBridgeV2 requires the corresponding bridge version. The gateway exposes vault_version and bridge_version separately: 0 identifies original contracts, and 2 identifies V2 contracts. Contract pause controls can also block execution despite prepared authorization, so refund readiness does not override an active pause on the contract receiving the claim.

A confirmed claim can still await delayed token release

In the pool contract's delayed path, a withdrawal exceeding a positive token-specific threshold enters a release queue during the successful on-chain claim transaction. The contract records the withdrawal as processed and queues its token payment for later execution. The pool contract can emit WithdrawDone after queueing tokens for delayed release. Consequently, that event alone does not establish a completed wallet credit.

View full-size image

The contract's executeDelayedTransfer operation must be called on-chain after the configured delay period has elapsed to perform the later token payment. Governance controls the threshold and period, so a fixed duration cannot describe every deployment. The V2 vault and pegged bridge also implement delayed execution for applicable withdrawals or mints. Recovery finishes with the authorized token payment or mint to the receiving account. Until release occurs, queued funds remain unavailable for another transfer.

Frequently asked questions

Does a refund revoke the token allowance from the original approval?: The bridge's refund calls do not revoke any remaining ERC-20 token allowance. The token contract tracks spending permission separately from the bridge's withdrawal or mint. A successful refund therefore does not establish that the spender's remaining allowance is zero. Changing that permission requires a separate allowance update.
Is the refund transfer ID the same as the wallet transaction hash?: The bridge transfer ID and the blockchain transaction hash identify different records. The status query takes the bridge identifier, which follows the original transfer's parameters and contract version. A source-chain transaction hash identifies the transaction containing that transfer. Keeping both identifiers avoids substituting a transaction hash for the expected transfer ID.
What happens if the same authorized refund is submitted twice?: The pool contract rejects a withdrawal identifier it has already processed. Its duplicate protection also covers a withdrawal placed into delayed release. The V2 vault and pegged bridge similarly record processed claim identifiers. Resubmitting the authorization cannot bypass that protection or force queued tokens to release early.
Can another account redirect Celerbridge refunds by submitting the claim?: Submitting an existing signed authorization does not let the submitting account replace its receiving address. The verified message specifies the receiving account, token, and amount. The documented contract calls take that message with its signatures, rather than a separately chosen refund recipient. Changing those signed details invalidates the authorization.
When should a refundable transfer be escalated to support?: Contact support if the transfer remains in TRANSFER_TO_BE_REFUNDED for more than 30 minutes without progressing to usable refund data. This escalation point concerns stalled preparation, not a promised completion deadline. Keep the original source-chain transaction hash available so support can identify the affected transfer and investigate its processing state.
Does request Refund also remove a liquidity provider's pool position?: Request Refund concerns a failed bridge transfer, while removing a liquidity provider's position uses a separate withdrawal flow. Transfer refunds use getTransferStatus and its refund authorization. Contract LP withdrawals involve WithdrawInbox and their own liquidity-status query.
Could a token restriction cause a refund without a slippage error?: Token restrictions can appear as refund reasons independently of slippage. The gateway distinguishes an unsupported or unavailable token, a disabled token transfer, and an unsupported destination chain. These reasons explain failures when the transfer status calls for a refund; an estimation error alone does not establish a refundable on-chain transfer.
Can a contract receive a refund paid as a native gas token?: A receiving contract must accept native token payments within the payout call's gas allowance for a native-token refund to finish. The pool and OriginalTokenVaultV2 unwrap the configured wrapped-native asset before paying the receiver. A rejected payment reverts the transaction attempting the payout, including a delayed-release transaction. Holding transaction gas does not establish this receiving capability.

13-Oct-2026 · updated