Cbridge fees: Total Route Costs Beyond the Quoted Percentage

Cbridge fees combine a base charge and a protocol charge, while source-chain gas adds a separate transaction cost. A useful comparison holds the sending amount and destination asset constant, then compares the estimated receipt and separately paid expenses. The bridge rate also affects the receiving amount, so a token shortfall doesn’t necessarily consist entirely of fees.

A lower percentage can accompany a higher total cost when another charge outweighs the saving. Keep deductions from the transferred tokens separate from payments made through the wallet, and use the same valuation basis when comparing different currencies.

Comparable quotes for the same destination asset

Route comparisons need the same starting asset, sending amount and intended destination asset to produce a meaningful cost difference. Quotes for different outputs answer different questions, even when their displayed percentages look comparable.

The useful endpoint is the asset balance that the intended recipient can use. If one path requires an additional conversion, its bridge quote covers only part of that task. Include the conversion’s quoted output and any separate transaction expense. Don’t assume that matching token symbols establish matching assets; the destination network and token identity belong in the comparison.

Compare estimates obtained close together. Otherwise, a change in gas or liquidity can look like a persistent pricing advantage.

Gas and approval costs before committing funds

Executing the selected transfer requires enough source-chain gas funding for the transactions it actually needs. Holding the transferred token alone doesn’t establish that readiness when the network charges gas in a different asset.

For an ERC-20 transfer, an existing sufficient allowance can remove the need for another approval transaction. That allowance applies to a particular spender, so permission granted to one contract doesn’t automatically cover another provider. Compare the gas for the actions required by the wallet’s actual allowance, rather than assuming every quote includes the same approval cost.

An approval and the transfer itself have separate transaction confirmations. Any completed approval expense already belongs in the cost record, even if the transfer never follows.

Base charges and percentage charges

The bridge fee calculation adds the base fee to the protocol fee for both xAsset (canonical mapping) and xLiquidity ( liquidity-pool ) transfers. The base fee covers destination-chain gas for delivering the transferred tokens. The bridge collects this component in the transferred token.

The protocol component scales with the transfer amount. For xLiquidity, its calculation uses the amount after bridge-rate conversion. A flat component therefore affects smaller transfers disproportionately, while the proportional component grows with the amount to which it applies.

Here, a base charge means a separately quoted amount, not a permanent tariff. Its value can change between estimates. Use the actual fee amounts for the selected transfer rather than treating a general percentage range as a binding price.

Receiving amounts without double-counted deductions

The estimated receiving amount already reflects the bridge’s quoted output calculation, so adding its deducted fees again overstates the cost. The gap between the sending and receiving amounts needs interpretation before it becomes a monetary total.

When both sides represent economically equivalent token units, that gap captures the combined effect of the bridge rate and token deductions. Add separately paid gas after converting it to the same valuation unit. If the destination asset has a different market value, compare asset values instead of subtracting token counts as though they were interchangeable.

View image file

For a direct transfer, a useful accounting relationship is: estimated economic cost equals input value minus estimated output value, plus separately paid transaction expenses. This relationship measures the whole quoted outcome. It doesn’t identify which portion came from a protocol fee, a base charge or conversion effects.

Transfer size and repeated fixed expenses

A larger transfer spreads a given fixed charge across more token units, reducing that component’s effective percentage. This arithmetic holds only while the charge remains unchanged.

Combining transfers can avoid repeating base charges and source transactions. Splitting them can create those expenses again, even if the combined sending amount stays identical. However, a larger liquidity-pool transfer can receive a different bridge rate or encounter a transfer constraint. The saving in repeated charges therefore needs comparison with the larger amount’s own quote. Multiplying a small-transfer estimate doesn’t establish the price of a larger transfer.

Bridge-rate effects and explicit fees

Liquidity pricing can change the output before explicit fees account for the rest of the difference. For xLiquidity pairs that use a StableSwap curve, pool balance influences the bridge rate. Some pool pairs instead use a fixed conversion rate.

A transfer that improves pool balance can receive a favorable conversion. That benefit can offset part of the transfer cost, but it doesn’t eliminate a separately charged fee. Price impact describes how the trade or transfer size affects quoted conversion; it isn’t another name for the protocol charge.

xAsset uses a pegged conversion relationship, with base and protocol fees still applying. Its conversion rule doesn’t make the net transfer free. Asset configuration determines the available model, so these models aren’t interchangeable pricing options for every token.

Slippage tolerance and the accepted output boundary

Slippage tolerance controls acceptable movement in execution terms; it isn’t a fee automatically collected at the selected percentage. A comparison that adds the full tolerance to every quoted fee confuses an acceptance boundary with an expected expense.

The estimate interface distinguishes the bridge rate, fee amounts and estimated receipt. For xLiquidity, the returned max_slippage parameter incorporates the user-entered tolerance along with fee and bridge-rate effects. The fee amounts, bridge rate and computed max_slippage can change before submission. Slippage tolerance doesn’t apply when is_pegged is true.

Compare expected receipts and acceptable output boundaries separately. A wider tolerance doesn’t improve the quoted price; it permits a wider range of execution outcomes. A very restrictive setting can instead cause failure.

Failed attempts and expenses that remain

A failed transfer can still leave transaction expenses, so a refund outcome needs its own cost accounting. On EVM networks, execution that consumes gas can incur a charge even when the transaction reverts. A wallet rejection before broadcast is a different event.

The bridge provides a refund-request path for certain failures involving destination liquidity or unfavorable slippage. That recovery path doesn’t establish that every previously paid expense returns with the tokens. Keep the returned token amount separate from approval gas, transfer gas and any recovery transaction expense.

Quoted cost and the final transaction record

The final cost uses actual destination receipts and paid transaction expenses, while the original quote explains the decision made before execution. Keep both records in their original units.

For a monetary comparison, apply a consistent valuation convention to the input, output and gas. Otherwise, a token-price change between timestamps can masquerade as an extra bridge charge. Separate any later sale or swap from delivery unless that operation formed part of the original route comparison.

The receiving estimate is a concrete amount worth retaining alongside the fee breakdown. In the estimate response, that amount appears as estimated_receive_amt.