DEV Community: Anna Botsford

Berachain bridge: Why Completed Tokens May Not Appear

Anna Botsford — Fri, 06 Nov 2026 03:34:16 +0000

Berachain bridge can report a transfer completed while your wallet shows no tokens because the bridge’s status and the wallet’s balance display are separate; only destination-chain evidence can establish whether the expected asset reached your address. An empty wallet view does not prove the tokens are lost. Equally, a completed label does not prove they arrived in the account you meant to use. Start with your transfer receipt, the intended recipient address, and any destination transaction hash shown in the receipt.

A Completed Label Describes the Transfer Workflow

A completed label tells you what the service believes happened in its transfer workflow. It does not continuously verify what your wallet displays or what the recipient holds now. The Berachain bridge status may reflect destination execution, while your wallet independently retrieves balances and decides which tokens to show. Those two views can disagree if the wallet has not indexed the token, is showing another account, or is connected to another network.

Think of the status as a delivery notice and the wallet as an inventory screen: the notice can say delivery happened before the screen lists the item. The destination chain is the record you use to test that notice. The analogy stops there, because crypto can move again after delivery. A transaction showing that tokens arrived does not, by itself, explain a zero balance today.

The Destination Record Shows Whether Your Address Received Tokens

The destination transaction is the deciding evidence for delivery. A source-chain transaction proves that you sent assets into a transfer process; it does not prove that the intended wallet received assets on the other chain. For a Berachain cross-chain bridge transfer, open the destination transaction in an explorer for the destination network and compare it with the receipt. The useful observations are:

Transaction status: A successful destination transaction establishes that the recorded action executed there. A successful source transaction alone cannot establish destination delivery.
Asset identity: For a token, the token contract address in the destination transfer record identifies what moved. A familiar symbol on its own is insufficient because different contracts can use the same symbol.
Recipient: The destination token transfer must show the expected asset going to the address you intended. A successful transfer to another address is delivery elsewhere, even if your wallet shows nothing.
Later activity: Transfers out of that recipient address after the incoming transfer can explain why the current balance is zero. The arrival record and the present balance answer different questions.

For an ERC-20 token, look at the successful transaction’s token transfer record, including its contract address and “to” address. If the destination asset is native rather than a token contract, inspect the recorded value movement instead. If the receipt supplies no destination hash, look for the incoming asset in the intended address’s destination-chain history or obtain the hash from the transfer record. Until you can verify delivery, treat the discrepancy as unresolved rather than a wallet display issue.

Wallet Settings Can Hide an Existing Destination Balance

A correctly delivered token can remain invisible when the wallet is displaying the wrong account, network, or token contract. Compare the wallet’s currently selected address with the destination recipient, character for character. Having the right wallet app open is not enough if a different account is selected. Likewise, a balance on Berachain will not appear in an Arbitrum network view, and a bridge from Berachain must be inspected on its actual destination network.

Token lists create another gap. A wallet may recognize one WETH contract while omitting the contract involved in your transfer, even though both entries use the same symbol. Match the contract in the destination transaction to the asset you expected, then import that verified contract into the wallet if the explorer shows your address holds it. Importing tells the wallet what to display; it does not move tokens or recover assets sent to another address. If the explorer shows a balance but the wallet still does not, the wallet’s data provider or token index may need time to update.

Delivery Elsewhere and a Later Transfer Need Different Responses

A destination record naming another recipient is an address problem, not a hidden-token problem. If that address is another account you control, select that account and inspect it on the destination network. If you do not control it, preserve the receipt and transaction hash for an investigation. Adding the token contract to the originally intended account will not change where the destination transaction sent it.

An incoming transfer to the correct address can also coexist with a zero current balance. Follow that address’s subsequent activity for the same token contract. An outgoing transfer, swap, or deposit into another contract can account for the difference; a token approval alone grants permission and does not itself show that the tokens left. This distinction matters because the arrival transaction may be genuine while the wallet’s current zero balance is also accurate.

The Next Step Depends on What the Destination Chain Proves

If the intended address still holds the verified asset, focus on the wallet: select that account and network, then add the token contract if needed. If the asset arrived and later left, investigate the later transaction rather than repeating the bridge transfer. If delivery to the intended address cannot be verified, keep the receipt, both transaction hashes if available, the expected contract, and the recipient address together when reporting the unresolved transfer. Never provide a wallet recovery phrase as part of that investigation.

Keep the receipt beside the explorer record when retracing a move crypto to Berachain. Revisit Berachain bridge to compare its completion claim with the destination hash, recipient, and token contract, because the claim alone cannot establish what your account received. That comparison lets you distinguish a hidden balance from delivery elsewhere or delivery that remains unproven.

3 Checks to Confirm a BaseSwap Swap on Base

Anna Botsford — Thu, 05 Nov 2026 14:37:59 +0000

Three checks—the transaction hash, its status, and the tokens received—show whether a BaseSwap swap completed. A transaction hash is the unique code for one wallet action. You can use it to check the result without guessing from a wallet notification.

Find the transaction by its hash.

Open your wallet’s activity and select the swap to find its transaction hash. Copy the full code, then search for it in a Base block explorer, such as BaseScan. Check that the wallet address and network shown match your own.

Before you judge the amount received, separate the swap cost from the price change. Knowing the BaseSwap trading fees helps explain why the final amount can be lower than the first quote. A quote is an estimate; the explorer records what the transaction actually did.

If the wallet shows no hash, it may not have sent the transaction. Check that you signed the request and that your wallet is set to Base, then look again in its activity. A pending wallet prompt is not proof that the swap reached the network.

Read the status and the token movement.

A successful status means the transaction ran without failing, but check the token movement to confirm the swap result. On the transaction page, look for the token transfers: the amount sent from your wallet and the amount sent back to it. A token is a digital asset, and a transfer is its recorded movement between addresses.

For example, say you swap 0.01 ETH for a Base token. Check that the transaction takes about 0.01 ETH from your address and returns the token to that same address. Compare the received amount with the wallet’s token balance, allowing for any tokens you already held.

Use the wallet address and transfer details together. A transaction can include several token movements, especially if it routes through another token. The relevant result is the amount of your chosen token that reached your wallet, not simply the first transfer listed.

If the transaction succeeded but the token balance looks unchanged, check that your wallet is displaying the correct token and network. Some wallets do not show every token automatically. The explorer’s transfer record can confirm receipt even when the wallet’s token list needs refreshing.

Handle pending and failed swaps carefully.

A pending status means the transaction has not finished, so wait before trying again. Sending another swap too soon can leave you with two transactions to track. Refresh the explorer after a short wait and check whether the same hash changes to success or failure.

A failed status means the swap did not complete, though the network may still charge a fee for processing it. Your input tokens usually remain in your wallet because a failed transaction’s token changes are undone. Check the wallet balance and the explorer’s failure details before retrying.

If the swap fails again, review the quote, the token pair, and the amount before signing another attempt. On BaseSwap, the final check is still the same: verify the transaction status, then confirm the received tokens in the transfer record. That shows both whether it completed and what reached your wallet.

Why does BaseSwap show USDC and USDbC separately?

Anna Botsford — Sat, 31 Oct 2026 01:59:17 +0000

BaseSwap shows two dollar tokens because native USDC and USDbC use two different contracts on Base. A contract is the address that identifies a token on a blockchain. Names and logos can look alike, but the contracts decide what you receive.

What does each token represent?

Native USDC is issued by Circle on Base. USDbC represents USDC moved from Ethereum through a bridge, which locks the original tokens and creates matching tokens on Base. Circle does not issue or directly redeem USDbC.

Circle lists native USDC on Base at 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913. It lists bridged USDbC at 0xd9aAEc86B65D86f6A7B5B1b0c42FFA531710b6CA. Compare the whole address, not just its first or last few characters.

The difference matters when you send tokens onward. A service asking for native USDC may not accept USDbC, even though both usually trade near one dollar. A swap between them changes your token; it does not move funds between networks.

How do you check tokens in BaseSwap?

Check that your wallet uses Base, then match each token’s full contract against Circle’s published Base addresses. Start before withdrawing from a centralised exchange. Select the Base network and confirm which form of USDC the withdrawal delivers.

Say you withdraw 200 USDC to your own wallet. Once it arrives, inspect the received token’s contract in your wallet or a Base block explorer. A successful test transfer proves delivery, but only the contract check proves which token arrived.

After that check, connect your wallet to BaseSwap on Base and select the token you hold. In BaseSwap V2, check the input and output contracts again before approving a trade. An approval lets the swap contract spend the amount you allow; it may require its own transaction.

Keep some ETH on Base for network fees, often called gas. ETH held on Ethereum cannot pay those fees on Base. Your wallet should show the approval amount and the fee before you sign.

Which swap or liquidity pool should you choose?

Choose by the token you need afterward and the amount the current quote says you will receive. A liquidity pool is a shared supply of tokens that swaps draw from. A small pool can give a worse rate when your trade changes its balance.

Read the route as well as the final amount. For example, a 200 USDbC trade might pass through two V2 pools to reach USDC. Each V2 pool typically charges 0.25%, or about one dollar across both steps, before price impact and gas.

Price impact is the change your trade causes in the pool’s price. Slippage is further movement between the quote and execution. Check the minimum received: it is the lowest output you agreed to accept, not a promised rate.

Providing liquidity is a different choice from swapping. A USDC pool and a USDbC pool hold different tokens, even when their prices look similar. Check both contracts before depositing; when you withdraw, you receive the pool’s current mix of tokens.

If no quote appears, or the minimum received is too low, wait and check the pool and route again. The practical test is simple: verify the contracts, confirm the destination accepts the token, then judge the live output after fees.

3 Checks Before Claiming a Mantle Bridge Withdrawal

Anna Botsford — Sat, 24 Oct 2026 12:06:50 +0000

A Mantle Bridge withdrawal is complete only after the Mantle transaction settles and you send the Ethereum claim. For frequent transfers, the useful distinction is between the withdrawal being recorded, its state being proven on Ethereum, and the funds being released by your claim.

1. Confirm the withdrawal transaction settled on Mantle

The first check is the Mantle transaction receipt: a wallet signature alone does not prove the withdrawal was submitted successfully. After it confirms, the bridge has recorded a cross-chain withdrawal message, and the source balance should reflect the amount withdrawn.

Save the Mantle transaction hash and check its status in the bridge history or Mantle explorer. If the transaction reverted, inspect the receipt before trying again; a retry may need more MNT for gas or a corrected token selection. If it succeeded, keep tracking that withdrawal rather than starting a duplicate.

2. Wait for the withdrawal state to be verified on Ethereum

The withdrawal becomes claimable after Mantle’s state containing it is proven and verified by Ethereum’s settlement contract. Mantle’s current network documentation describes ZK validity proofs and says verified batches finalize without a challenge period; older guides describing a seven-day optimistic challenge window do not describe this current model.

That does not mean the funds arrive as soon as the Mantle transaction confirms. Proof generation, batch submission and Ethereum verification still take time, and the wait can vary with network processing. Use the withdrawal’s current status to tell whether it is still pending settlement or ready for the next step.

For a typical operator moving stablecoins back to Ethereum several times a week, the bottleneck is usually waiting for that status change, not resubmitting the transfer. When comparing Mantle bridge fees, account for both the Mantle transaction and the later Ethereum claim; the claim needs ETH even if the withdrawal itself is in ETH.

3. Claim on Ethereum and verify the destination balance

Once the withdrawal is ready, switch the wallet to Ethereum and submit the separate claim transaction. The claim releases the escrowed asset to the withdrawal recipient; it is not an automatic continuation of the Mantle transaction, so closing the bridge page does not perform it for you.

Keep enough ETH in the claiming wallet for Ethereum gas. If the claim is ready but the wallet cannot submit it, fund that same wallet with ETH, return to the existing withdrawal in the bridge history, and claim it there. After confirmation, check the recipient’s Ethereum balance and token contract rather than relying only on a success message in the interface.

The practical trade-off is predictable: the canonical route makes you wait for settlement and pay Ethereum gas to claim, while a faster route may price liquidity and add separate contract assumptions. For routine transfers, initiate the canonical withdrawal when you can tolerate the settlement wait, then batch your follow-up activity so you do not pay Ethereum gas for avoidable extra transactions.

Does the old seven-day wait still apply?

Mantle’s current documentation describes ZK validity proofs, with verified batches finalizing on Ethereum without the former challenge period. A withdrawal can still take time while its state is proved, submitted and verified, so check its live status rather than assuming it will be claimable immediately or scheduling around an old seven-day estimate.

Can I make a pending withdrawal arrive faster?

Once the Mantle withdrawal transaction is confirmed, you cannot speed up its proof and settlement by resubmitting it. Watch for the claimable status, then submit the Ethereum claim promptly. If speed matters more than the canonical settlement path, compare any alternative route’s net amount, liquidity and trust assumptions before choosing it for a future transfer.

Why bridge withdrawals wait for a Merkle proof

Anna Botsford — Sat, 24 Oct 2026 00:20:21 +0000

A Merkle proof is a compact receipt that lets a bridge check a withdrawal against a record on Ethereum. It works only after the Polygon block containing the withdrawal has been included in a checkpoint, a record validators submit to Ethereum.

What does the proof prove?

The proof shows that a specific burn happened on Polygon. A burn destroys the bridged tokens there, so they cannot also remain in your Polygon wallet after you claim them on Ethereum.

Think of a Merkle tree as a filing system that combines many records into one fingerprint, called a root. A Merkle proof carries the path from one record to that root; the bridge can check the path without receiving every record in the filing system.

Polygon Bridge turns that check into a two-step withdrawal: first burn the tokens on Polygon, then claim them on Ethereum after the proof is ready. The proof is what connects those two actions, even though they happen on separate networks.

How does the proof release tokens?

When you start a withdrawal, the bridge burns the tokens on Polygon and records the event in the transaction receipt, a record of what the transaction did. Validators later checkpoint the relevant Polygon block on Ethereum.

Once that checkpoint exists, the bridge can assemble a proof linking the burn receipt to the block and the block to the checkpoint. The RootChainManager, the Ethereum contract that handles exits, checks this evidence before releasing the matching tokens from escrow, the bridge’s locked pool.

That check also prevents a second claim. After the first successful exit, the bridge marks the withdrawal as used, so the same proof cannot unlock the tokens again.

Why can’t I claim straight away?

You have to wait for the checkpoint before the proof can pass. A recent burn may be visible on Polygon, but Ethereum cannot verify it through the bridge until validators have committed its block.

For a typical user, expect a wait of tens of minutes, though checkpoint timing can vary. After it is ready, the Ethereum claim itself usually takes minutes once included in a block. Polygon’s support pages describe the burn and later claim as separate steps; PolygonScan lets you inspect the burn transaction and its block.

Before starting, check that you have POL for the Polygon transaction and ETH for the Ethereum claim. You pay network fees on both chains, and the Ethereum fee changes with congestion. Your wallet shows the current estimate before you sign each transaction.

What should I check before claiming?

Use the withdrawal status in Polygon Portal to see whether the checkpoint has arrived and the claim is ready. Check that the Ethereum wallet address is the one you intend to receive the tokens at, and keep the Polygon burn transaction handy if you need to find the withdrawal again.

There is an important edge case: once the burn is confirmed, you cannot cancel the withdrawal or return those tokens to your Polygon wallet. If Ethereum fees are high, you can wait to claim; Polygon support says the pending claim does not expire, and the tokens remain in the bridge contract.

Polygon Bridge makes the checkpoint the practical dividing line: before it, wait; after it, review the claim and its Ethereum fee, then sign when you are ready. Check the burn transaction first, confirm the checkpoint status, and keep enough ETH for the final claim.

How to Fund an Ethereum NFT Mint From Mantle

Anna Botsford — Fri, 23 Oct 2026 20:05:31 +0000

Check the mint page for its network, price, start time, and wallet requirements before moving your ETH. You need ETH on Ethereum to mint there; ETH held on Mantle is like cash in a wallet across town, so move it first and leave enough for both the mint and Ethereum gas.

What should you check before bridging?

Confirm the mint is on Ethereum Mainnet and note the exact cost per NFT. Check whether the page lists a separate mint fee, requires a wallet allowlist, or limits how many tokens you can mint; a mint on another network will need funds there instead.Look at the sale time and wallet you plan to use, too. If the mint is time-sensitive, start early: the bridge transfer and its final claim can take time, and a wallet connected to Mantle cannot pay an Ethereum mint transaction.
Work out how much ETH to withdraw, including a gas reserve. For example, if one NFT costs 0.08 ETH and the mint page estimates 0.004 ETH for gas, you need at least 0.084 ETH on Ethereum, plus a cushion for a busier block or a second transaction.Gas prices change, so check your wallet’s estimate near mint time rather than treating an old estimate as a quote. If the mint might require an approval transaction as well as the mint itself, budget gas for both; the page or wallet should show whether approval is needed.

How do you move the ETH back to Ethereum?

Open the official bridge from Mantle’s site and connect the wallet holding your ETH on Mantle. Select Mantle as the source, Ethereum as the destination, and ETH as the asset; check that the receiving address is the wallet you will use for the mint.Before confirming, compare the amount with your budget and check the displayed fee and expected timing. The bridge transfer is not a swap: it moves the bridged ETH balance back to Ethereum, where you can spend it on the mint.
Keep some MNT on Mantle to pay the withdrawal transaction fee. Then confirm the withdrawal in your wallet and save the transaction hash; a successful Mantle transaction starts the exit but does not by itself mean the ETH is ready to spend on Ethereum.If you are planning this for a mint, begin well before the sale opens. The bridge’s current FAQ says withdrawals can take up to about 12 hours, so don’t count on finishing the transfer in the final minutes. The precise status in Bridge History is the useful signal for your withdrawal.
When the withdrawal is ready, switch your wallet to Ethereum and complete the separate claim transaction. You need ETH already on Ethereum to pay that claim’s gas—even when the withdrawal itself is ETH—so leave a small mainnet balance in the wallet before you start.This is the step people often miss: the Mantle transaction initiates the exit, while the Ethereum claim releases the funds to your mainnet balance. If you close the bridge page, return to its History view and continue the original withdrawal instead of starting another one.

How do you confirm the ETH is ready for the mint?

Switch your wallet to Ethereum Mainnet and check its ETH balance in the wallet or a block explorer. Make sure the available amount covers the mint price, the claim and mint gas already paid or still due, and your reserve; a pending bridge entry is not spendable ETH.If the balance does not appear, check Bridge History and the transaction status on both networks using the saved hash. Confirm that the claim completed and that the destination address matches your mint wallet before trying again.
Return to the mint page, reconnect the same wallet on Ethereum, and follow its mint steps. Read the final wallet prompt: confirm the network, recipient contract, quantity, and total value before signing, and don’t approve a transaction you did not expect from the mint page.After the transaction is confirmed, check the mint page or your wallet for the NFT. If the sale has not opened yet, keep the ETH on Ethereum; bridging it back to Mantle would add another transfer when you need it on mainnet.

When should you choose a different plan?

Use the canonical Mantle Bridge deposit route when you want the direct Mantle-to-Ethereum withdrawal and can wait for its proof, processing, and claim steps. For a mint with a fixed opening time, the practical choice is to withdraw early enough that a delay does not leave you short at checkout.Decide differently if the sale is imminent, the bridge status is still pending, or you lack MNT for the Mantle transaction or ETH for the Ethereum claim. In that case, first check whether you can fund the mint wallet directly on Ethereum; only use another route if you understand its fees, settlement, and security assumptions.

How to Diagnose a Cross-Chain Transfer Delay

Anna Botsford — Fri, 23 Oct 2026 01:57:17 +0000

Network congestion can slow a cross-chain transfer at either end. A transfer also needs proof from the sending chain and a transaction on the receiving chain, so “pending” can mean different things.

A transfer moves through several separate steps

A bridge first records your transfer on the source chain, the network where your tokens start. Depending on the route, tokens may be locked or burned, and the bridge creates a message that describes the transfer.

That message needs confirmation from the source chain before the bridge can safely act on it. In Wormhole’s wrapped-token route, Guardians, a network of validators, sign a proof called a VAA. The destination chain then uses that proof to release or mint tokens.

Each step can wait for a different reason. Your wallet may be waiting for the first transaction to enter a block; the bridge may be waiting for the source chain’s required confirmation; or the destination transaction may still need to be submitted.

Congestion delays the step that needs block space

Congestion means many users are trying to use a chain at once. Transactions compete for limited space in each block. On networks such as Ethereum, a higher priority fee can help a transaction compete for inclusion, but it cannot guarantee a specific time.

For example, imagine you send tokens from Ethereum while blocks are busy. Your wallet may show a pending transaction before the source transfer is recorded. After it is recorded, the bridge may still need to wait for the required confirmation before it can proceed. A quiet Base destination cannot remove a delay on Ethereum.

Congestion can also hit at the other end. The bridge may have finished its proof, while the transaction that delivers your tokens is waiting for space on the destination chain. So a slow transfer does not always mean the bridge itself is stuck.

The route and chain decide how long to allow

There is no single wait time that applies to every cross-chain transfer. It depends on the source and destination chains, the route, their current load, and the confirmation rules that route uses. A route that waits for stronger source-chain finality can take longer than one designed to complete quickly.

Portal Bridge offers different transfer routes, so a fast-transfer estimate does not describe every possible transfer. Some routes use intents, where a service fulfils the transfer across chains; others use wrapped-token transfers, where a signed proof supports release or minting on the destination. Check the selected route and its displayed estimate before sending.

Congestion can raise the source transaction’s network fee if you choose a higher priority fee. A destination transaction may also require a network fee, especially if you must complete it yourself. These are separate from any route or service fee shown before you confirm.

Check the transaction before trying again

Start with the source transaction hash, the unique ID for the transaction on the sending chain. Open it in that chain’s block explorer and check whether it is pending, confirmed, or failed. If it failed or never entered a block, the transfer did not start successfully.

If the source transaction is confirmed, do not send the same transfer again just because the destination balance has not changed. Check the bridge’s transfer status or Wormholescan for the next step. If a proof is ready but delivery is incomplete, the route may need a destination transaction or a manual completion.

For a Portal Bridge transfer, use the source transaction hash to check its progress and resume the transfer if the interface offers that option. Make sure you have the destination wallet selected and enough of that chain’s native token for any required transaction fee. If the source transaction failed, only retry after checking the amount, destination address, and current fee estimate.

Sending Crypto to an Exchange? Add the Right Tag

Anna Botsford — Thu, 22 Oct 2026 12:54:51 +0000

When an exchange asks for a destination tag or memo, enter the exact value it gives you before sending. The tag tells the exchange which customer account to credit when many customers share one receiving address.

Check the asset, network, address, and tag on the receiving exchange.
Enter the tag in the matching field before you approve the transfer.
For a first transfer, consider sending a small test amount.

A tag sorts deposits sent to one shared address

A destination tag is an extra number or text value attached to a crypto payment. A memo is a similar field, though its name and format depend on the network and wallet.

Some custodial wallets—services that hold crypto for customers—use one blockchain address for many accounts. The address gets the funds; the tag or memo tells the service which customer balance to update. The XRP Ledger documentation describes this as a way to identify the person behind a payment to a shared address.

A transfer to an exchange may need a tag, while a transfer to your own wallet often does not. Your own wallet usually has its own address, so it can identify your funds without a separate customer number. A thor swap search can lead to this same check: a swap route may handle the asset exchange, but the receiving exchange can still require its own tag. For the route question, compare a thor swap aggregator with a direct transfer: neither choice replaces a tag requested by the final recipient.

Check the receiving details before choosing a route

Open the receiving wallet’s deposit screen for the exact coin you plan to receive. Copy its address and tag or memo, then check the network name shown there; the same coin can sometimes move on more than one network.

For example, if an exchange gives you an XRP address and a destination tag, you need both when sending XRP to that deposit. If you send XLM, the exchange may call its identifier a memo instead. Stellar documentation explains that custodial services can use a shared account and a memo ID to match incoming payments to customer accounts.

Compare that with sending XRP to a self-custody wallet—one where you control the keys. The wallet may ask only for an address. Follow the receiving screen’s instructions rather than adding a guessed tag; the wrong extra information can also cause problems.

Enter the tag in its own field and review the transfer

Paste the address into the address field and the tag or memo into its own field. Some wallets label the field “Destination Tag,” “Memo,” or “Memo ID.” Keep any leading zeroes, and do not paste the tag onto the end of the address.

Before approving, compare the asset, network, address, tag, and amount with the receiving screen. If you are using a swap service, check that its final delivery details let you enter every required field. If the tag field is missing, pause and check with the service; a quoted route alone does not confirm that it can pass the tag through.

A test transfer can help when you are unsure. Send a small amount first, then wait for the exchange to show the deposit in your account before sending the rest. The test still has a network fee—the charge for recording a transfer—and may need to meet the exchange’s minimum deposit.

A missing tag can delay credit even when the transfer arrives

If the tag is missing or wrong, the blockchain may still deliver funds to the shared address, but the exchange may not know which customer to credit. The XRP Ledger can reject a payment without a tag when the receiving address has that rule enabled; other cases may need manual support.

Check the transaction status and details in the sending wallet, then contact the receiving service through its official support channel. Give it the transaction ID, asset, network, amount, destination address, and any tag you used. Do not send a second payment just because the first one is not visible yet.

For your next step, open the receiving deposit screen and confirm all five details before you move funds. When a thor swap route ends at a custodial wallet, treat that wallet’s tag requirement as part of the destination, just like its address and network.

Choosing a CoW Swap Order Cancellation Method

Anna Botsford — Thu, 22 Oct 2026 02:52:46 +0000

Choose off-chain cancellation when saving gas matters; choose on-chain cancellation when you want the order invalidated on the blockchain. Both can lose a race with a trade that is already being settled, so speed matters either way.

What changes when I cancel off-chain or on-chain?

Off-chain cancellation asks CoW Swap’s order book—the online list of open trades—to stop offering your order. It costs no network transaction fee, often called gas, but relies on the order book processing your request.

On-chain cancellation sends a transaction to the settlement contract, the blockchain program that checks and completes trades. The contract records that your order is invalid, so a later trade cannot use it. You pay the network’s gas fee for that transaction.

Think of the difference as crossing your name off a shop’s list versus changing the official record. The first is quicker and free when the shop acts promptly. The second creates a public record, but you still wait for the network to confirm it.

Which method should I pick?

For a routine change of mind, I’d pick off-chain cancellation. It avoids a fee, and the interface makes the request straightforward. In the cowswap interface, open your pending order and choose “Cancel order”; check that the right order is selected before confirming.

Choose on-chain cancellation if you prefer the order’s invalidation to be recorded by the contract instead of relying on the order book. It may suit a time-sensitive order when you can submit the transaction promptly and accept the gas cost. That cost changes with the network and congestion, so check the wallet’s fee estimate before signing.

Neither choice guarantees the order stops instantly. Solvers—automated traders that compete to complete orders—may already have included it in a batch auction, a process that checks a group of trades together. If a settlement transaction gets confirmed first, cancellation cannot undo the completed trade.

What is the race, and how do I check the result?

Cancellation races the trade through two different paths. With off-chain cancellation, the order book must process your request before a solver’s settlement can use the order. With on-chain cancellation, the invalidation transaction must be confirmed before the settlement transaction.

For example, if you request off-chain cancellation just after a solver has prepared a settlement, the order may still be included. An on-chain request also has a delay: until the network confirms it, the order can remain valid. A higher priority fee may help your transaction get processed sooner, but it cannot promise that cancellation wins.

After requesting cancellation, check the order’s status in the activity panel or CoW Explorer. For on-chain cancellation, also check that the transaction succeeded on the correct network. If the order shows as filled, compare its settlement time with your cancellation request; a later status update alone does not prove which happened first.

Are there cases where one method is unavailable?

Yes. Orders that use CoW Swap’s Eth-flow route for native ETH can only be cancelled on-chain. That route places the order through a contract that holds the ETH, so the cancellation must also reach the blockchain; a free off-chain request is not available for it.

Also, cancelling an order does not revoke your token approval. An approval lets the protocol spend approved tokens for valid orders; cancelling invalidates one specific order. Revoking the approval is a separate action and is not a substitute for cancelling the order.

For most ordinary orders, I’d start with the free off-chain request and check its status. Pick on-chain cancellation when contract-recorded invalidation matters enough to justify gas, and act quickly with either method.

TRON swap: How to Compare Routes and Complete a Trade

Anna Botsford — Wed, 21 Oct 2026 00:55:44 +0000

A TRON swap exchanges tokens on the TRON blockchain, often using TRC-20, its common token format. TRON swap works when both assets are on TRON and the amount you receive makes sense after costs. Compare a wallet-connected swap with a custodial exchange by checking the final amount and who holds your tokens.

How Does a TRON swap Work?

A wallet-connected swap sends your tokens to a smart contract, code that carries out the trade. It usually trades against a liquidity pool, a supply of both tokens provided by other users. The pool’s balance sets the price, so a large trade can move it.

After you connect a TRON wallet, select the tokens and enter an amount, you get a quote. If you are spending a TRC-20 token for the first time, you may need to approve it first. Approval is a separate transaction that lets the swap contract use a stated amount of that token.

You then confirm the trade in your wallet. The contract takes the input and sends the output to your wallet when the transaction succeeds. Some routes pass through an intermediate token if there is no suitable direct pool.

What Will the Trade Cost?

The total cost includes the pool fee, any price impact and the network cost. Some TRON pools charge 0.3% per trade; others use fee tiers from 0.01% to 1%. A route through two pools can incur two pool fees.

Price impact is the change your own trade causes in a pool. Slippage is a further price change while your transaction waits to execute. Say a quote offers 2,000 JST for 100 USDT with a 1% slippage limit. The trade should deliver at least about 1,980 JST or fail; check the displayed minimum before signing.

TRON charges Bandwidth for transaction size and Energy for contract work. Staked or delegated resources can cover these costs; otherwise, the network burns TRX. For example, an estimated 100,000 Energy costs around 10 TRX at the current rate if you have no Energy, plus any Bandwidth shortfall. Keep enough TRX for approval and the swap: even a failed transaction can consume resources.

How Do You Choose and Complete a Route?

Choose a route by comparing its minimum output, network cost and pool depth for your trade size. A deeper pool usually means less price impact. Compare the amount you expect to receive after all costs, especially when one route uses an extra pool.

A swap on TRON through a wallet-connected exchange lets you keep control of your tokens until you sign. A custodial exchange instead holds your deposit and trades within your account; check its trading fee, withdrawal fee and supported withdrawal network. A trade inside that account may settle there first, with a separate blockchain withdrawal needed to reach your wallet.

Before depositing or signing, confirm the token’s contract address, its unique on-chain identifier. Names and symbols can be copied, and USDT exists on several networks. If you want TRC-20 USDT in a TRON wallet, select the TRON network for withdrawal and check the address carefully.

Start with the route that gives an acceptable minimum output at an acceptable total cost, then verify the result in your wallet. For an unfamiliar token or service, try a small amount first so you can check the full path before sending more.

Destination-Chain Reorganizations and Bridge Transfers in 2026

Anna Botsford — Tue, 20 Oct 2026 14:29:48 +0000

A destination-chain reorganization can erase a bridge credit while the source transfer remains. This happens when the destination network replaces recent blocks with a different version of its history, removing the block that recorded the incoming transfer.

A how a relay bridge moves funds explanation follows the message from one chain to another; this article focuses on what can happen after the destination chain first records it. The key distinction is that a transaction can appear successful before the block containing it is secure enough for the bridge or its user to rely on.

What does a destination-chain reorganization undo?

A reorganization, often shortened to “reorg,” happens when a blockchain switches to a different branch of recent blocks. Transactions in discarded blocks are removed from the accepted history; they may be tried again, but their earlier effects no longer count. Ethereum.org’s glossary describes a reorg as a switch to a different canonical chain.

For a bridge transfer, imagine you send tokens on a source chain and the bridge locks them in a smart contract. A relayer node sees that event and submits a corresponding instruction on the destination chain, where a contract releases or creates tokens for you. If the destination block containing that credit is later discarded, the destination contract state rolls back too.

The source and destination chains keep separate records. Reversing the destination credit does not automatically unlock the tokens on the source chain, because the source contract has no built-in knowledge that the other chain’s history changed. You can therefore see a completed source transaction alongside a missing or pending destination transfer.

How can the transfer be reversed after it looks successful?

“Included” means a transaction appears in a block; “finalized” means the network’s consensus rules treat that block as settled. The bridge may act on a source event once it has enough confirmations, but confirmations reduce reorg risk rather than removing it in every network. The exact threshold and meaning of finality depend on the chain and the bridge’s rules.

Suppose a bridge sees a deposit, then credits you on the destination chain while that chain’s block is still recent. A competing branch becomes the accepted one, and the credit block is dropped. The relayer’s earlier report of success was accurate for the branch it saw, but it is no longer accurate for the chain’s current history.

Any later transactions that depended on that credit can also be affected. If you traded the bridged tokens in a block that is discarded along with the credit, that trade is discarded too. If the trade was recorded in a block that remains canonical but the credited tokens are absent, it may fail when retried because your balance is no longer sufficient.

Ethereum.org explains that proof-of-stake finality makes reverting finalized blocks require a major consensus failure. Solana’s transaction guidance distinguishes “confirmed” from “finalized” because a confirmed transaction can still belong to a dropped fork. Those terms are useful examples, not interchangeable labels: check the commitment level and finality rule for the particular chain.

What affects the wait and the cost?

Waiting longer for destination finality lowers the chance that a bridge transfer will be reversed, but adds time before you can safely use the received tokens. There is no universal confirmation count: the bridge chooses a threshold based on its security model, the destination chain’s consensus, and the value or risk it is willing to accept.

For a simple timing estimate, say a network produces a block every two seconds and a bridge waits for 20 confirmations. That is roughly 40 seconds for those blocks, before adding relayer polling, network congestion, and the time for the destination transaction to be included. Actual wait times can be longer, and a bridge that waits for stronger finality may take much longer still.

A reorg does not have one standard fee outcome. You may have paid the source transaction fee already, while a relayer or bridge operator may need to pay again to retry a destination transaction. Whether a user pays a retry fee, receives a refund, or needs to take action depends on the bridge’s terms and its recovery process.

What should you check if the destination credit disappears?

Start with the transfer’s status in the bridge’s tracker, then compare the transaction records on both chains. A source deposit that remains confirmed with a destination transaction missing or marked reverted points to a different issue than a source deposit that itself was removed by a reorg.

Confirm that the source transaction is still in the accepted chain history.
Check whether the destination transaction was included, reverted, or dropped with its block.
Look for a bridge status such as pending, retrying, or awaiting finality.
Check whether the bridge says it retries automatically or requires a manual claim.

Do not send the same transfer again just because the destination balance is temporarily missing; the original message may still be retrying, and duplicate submissions can create confusion or extra fees. Follow the bridge’s recovery instructions and use its official tracker to check whether the original transfer has been completed or can be claimed again.

A destination reorg can remove the receiving side of a bridge transfer without undoing its source-side lock or payment. When using a relay bridge, treat a visible destination credit as provisional until the bridge’s required finality threshold is met, and check both chains if that credit later disappears.

Destination Token Support in Cross-Chain Swaps Explained

Anna Botsford — Sat, 17 Oct 2026 07:10:26 +0000

Destination token support sets which cross-chain swaps your wallet can complete: the route needs an asset it can deliver on your chosen network. If that asset is missing, the route may be unavailable even when you can buy it on a centralised exchange.

Why does the destination token decide the route?

A centralised exchange can hold one balance for you and trade it against many listed coins. With your own wallet, each blockchain has its own ledger, and a token on one chain is not automatically available on another.

A bridge moves value between blockchains. A swap trades one token for another. A cross-chain swap combines both jobs, so the service needs a way to move your starting asset and deliver the token you asked for on the destination network.

Token support means the service has a usable route for that specific asset on that specific chain. A token’s ticker or name alone is not enough: tokens with the same name can have different contract addresses, which are identifiers for tokens on a network. Ethereum.org explains that bridging can create a wrapped token, a network-specific representation of an asset. That representation may not be the version your destination app accepts.

How do bridging and swapping fit together?

Imagine you hold 100 USDC on Ethereum and want a different token on Arbitrum, a separate network. A route could trade some USDC, move value across, then deliver the requested token on Arbitrum. Each step depends on the service having a supported asset and a working exchange route where needed.

Available liquidity—the tokens ready to trade—affects the amount you receive. For example, a quote might turn 100 USDC into 99.6 units of the destination token after a 0.2% service cost and 0.2% price impact. Those figures are illustrative: actual costs depend on the route, market prices, network fees, and available liquidity.

Some systems send a matching token representation across; others use a liquidity provider, a party that supplies tokens to complete a trade. Across Protocol’s documentation describes relayers that send tokens on the destination chain and are repaid later. The exact mechanism varies, but the practical limit is similar: a requested output needs support on the destination side.

That is where fast super bridge swaps can be relevant: super bridge is a cross-chain bridge and swap service for moving assets between supported networks. The key check is whether the destination token you want can be delivered on your chosen chain, not simply whether your starting coin is supported.

What should you check before sending?

Check the route as if you were checking an exchange’s trading pair, then confirm the chain and token version. Take these steps before approving a wallet transaction:

Choose the destination chain first. Confirm you are aiming for the right network, such as Arbitrum or Base.
Check the exact output token. Match its network and, where available, its contract address. Do not rely on the ticker alone.
Read the quoted amount. Compare what you send with what the route says you will receive. The difference can include service costs, network fees, and price impact.
Check destination gas. Gas is the network fee for using the destination chain. You may need its native token to move or spend your received assets afterward.
Send a small test amount if uncertain. This can confirm that the destination wallet recognizes the token before you move more.

If the output token is unsupported, look for a supported token on that chain that you can trade afterward, or choose another destination. The destination token sets the route’s boundary; checking its network and version helps you avoid receiving an asset you cannot use as planned.