acrossbridge: Why destination calls can reject a bridge fill

Choose a plain token transfer when the destination only needs to receive funds; add a contract call only when the next action must happen automatically. A destination contract call is an instruction to another blockchain program, such as “deposit these tokens,” that runs as the bridge fill arrives. If that instruction fails, the fill may fail too.

What does a rejected destination call mean?

The relayer’s destination transaction tried to deliver tokens and run your requested action, but the contract refused or could not finish it. A relayer is a service that pays out tokens on the destination chain first, then seeks repayment later.

Think of the fill as a courier asked to deliver a parcel and get a receipt from the recipient. If the recipient refuses the parcel, the courier cannot complete that delivery attempt. On-chain, the token transfer and call usually happen in one transaction, so a failed call rolls back that attempt’s token transfer too.

This does not usually mean the bridge deposit vanished. It means no successful fill was recorded from that attempt. The deposit can remain pending while another attempt is possible, subject to its deadline.

What can make the call fail?

The destination contract checks the call against its own rules and current state. A request that looks valid when you submit it may fail by the time a relayer executes it.

  • Wrong target or function: the address is not the intended contract, or the call uses a function the contract does not support.
  • Bad parameters: the call names the wrong token, recipient, or amount. A fixed amount can also exceed the tokens actually delivered.
  • Changed conditions: a price limit, deadline, balance requirement, or permission check no longer passes.
  • Not enough gas: gas is the fee and computing allowance for the transaction. The call may need more than the relayer allows.
  • Temporary contract issue: the target contract may be paused, busy, or unable to serve the request at that moment.

For example, suppose a bridge delivers 100 USDC and calls a lending contract to deposit all 100. If the transaction instead supplies 101, the lending contract can reject it. A call that relies on “use the balance received” can avoid that fixed-amount mismatch, where the bridge integration supports it.

What happens after a failed attempt?

The deposit can still be filled before its deadline if a later attempt succeeds. A temporary failure may clear; a wrong address or incorrect parameter will usually keep causing trouble because each attempt uses the same requested action.

If no fill succeeds before the deadline, the deposit becomes eligible for a refund. The refund is not instant: it is processed through Across settlement and can take hours. Check the deposit status and refund address, and do not treat a failed destination transaction as proof that a refund has already arrived.

Across also supports destination actions with a configured fallback recipient. In this setup, the handler catches a failed action and sends remaining tokens to that recipient, so the bridge fill can complete without the intended action. This preserves delivery, but the user may need to finish the action separately.

How should you compare transfer options?

Check whether the service supports the exact destination action, whether failures revert the fill or send tokens to a fallback, and what happens when the deadline passes. For a contract you control, test the actual callback with the delivered token, amount, and message; a callback is the function the bridge invokes on the recipient contract.

Across is intent-based: you specify the destination and desired result, then relayers compete to fulfill it. That can be fast, but it does not make a destination contract accept a call that breaks its rules. A plain bridge transfer avoids that extra failure point, though it leaves you to make the destination call afterward.

If you only need tokens on another chain, acrossbridge can serve that transfer; choose a bridge with destination calls when the automatic action is essential and its failure path fits your needs. Before sending, verify the target, parameters, gas allowance, fallback behavior, deadline, and refund address. Choose a plain transfer for reliable delivery, and choose an embedded call only when its automation is worth the added rejection risk.

Comments

Post a Comment

Popular posts from this blog

TRON Swap Energy: What to Know Before You Trade

A TRON swap can need tens of thousands of Energy units, and a complex contract call can need much more. Energy is TRON’s measure of the computing work a smart contract performs; it is separate from Bandwidth, which covers transaction data. Knowing which resource is short helps explain why a swap may cost TRX or fail. Why can a swap need more Energy than expected? A token swap runs through smart contracts, which are programs that update balances and carry out trades. Each step uses Energy, so a route involving several contracts may need more than a simple token transfer. The exact amount depends on the contracts, the route, and the state of your wallet. A less obvious factor is the receiving token account’s history. A contract may need extra work the first time it writes a balance for an address. So two otherwise similar swaps can use different amounts of Energy, even when they trade the same token. For a TRON swap, check the wallet’s transaction estimate before approving. The estimate ...
Read more

How to Set Slippage on a Syncswap Swap

Image
To set slippage on a Syncswap swap, choose the smallest tolerance that leaves room for the quoted price to move before your transaction executes. Syncswap is a decentralized exchange and liquidity hub on zkSync Era, where a Smart Router can move a trade through one or more pools. The setting matters because the price shown when you prepare a swap is not necessarily the price used when the transaction is confirmed. The main trade-off is straightforward: a tight limit protects your price but increases the chance that the transaction reverts; a wide limit makes execution more likely but gives the market more room to deliver less than expected. Choose between protection and execution A low tolerance suits a liquid pair, a normal market, and a trade that is not urgent. If the quote is for 1.0000 units of the output token and the tolerance is 0.10%, the transaction should require at least 0.9990 units. A move beyond that threshold causes the swap to fail instead of accepting the worse price...
Read more

Slashing vs. Multisig: What XMR Bridge Users Can Trust

Image
Slashing can punish provable misconduct, but it cannot return XMR already stolen. Multisignature custody spreads control across key holders; slashing only costs their posted bond after a rule breach is detected. To wrap XMR into zXMR, use the ZeroFi XMR bridge to start the transfer, then check what the bond can actually cover. What does slashing deter? Slashing deters actions that a bridge can prove and punish. It means taking some or all of a node operator’s posted stake after a rule breach, such as signing two conflicting messages. It does not automatically stop a key holder from joining a group theft. Nor does it guarantee repayment: the bond may be smaller than the stolen XMR, or the bridge may lack clear evidence to trigger a penalty. For example, if a bridge holds 100 XMR and the operators’ total slashable bond is worth 5 XMR, a successful theft could still leave users short. Those figures are illustrative, not ZeroFi terms. Slashing changes the cost of misconduct; it is not de...
Read more