DEV Community: Kendra Koepp

How to add liquidity to a volatile token pair

Kendra Koepp — Thu, 22 Oct 2026 13:09:11 +0000

Adding liquidity means depositing two tokens into a pool so traders can swap between them, while you earn a share of trading fees. With a volatile pair, the key choice is how wide a price range to cover, since a narrow range can stop earning fees when prices move.

Which type of pool suits a volatile pair?

A full-range position keeps liquidity available across a very wide span of prices, so it needs less watching. A concentrated position puts your funds within price limits you choose; it can earn more fees per dollar while the price stays inside those limits.

For a pair that can swing sharply, I would start with a broad range or full-range position unless I could check it often. On SpookySwap, V3 lets you set that range, while its full-range option needs less active management; the SpookySwap liquidity screen shows the available pair and fee choices.

Fees vary by pool tier: V3 offers 0.01%, 0.05%, 0.30%, and 1.00%. A higher tier may suit an exotic or lightly traded token, but compare the pool’s trading activity and liquidity first. A high fee earns little if few trades use that pool.

Also check the token contract addresses and whether the pair has real trading activity. A token with a transfer fee, which takes a cut when it moves, may need a V2 pool instead. SpookySwap’s docs say such tokens cannot be used in its V3 pools.

How do you add the tokens?

Follow these steps after choosing the network and pool. Keep some of that network’s coin in your wallet to pay gas, the network transaction fee.

Open the liquidity page and connect your wallet. Confirm the wallet is on the same network as the tokens. Pools on different networks hold separate funds.
Select the exact token pair and pool tier. Check both contract addresses, especially for unfamiliar tokens with look-alike names. Compare the pool’s liquidity and recent trades before depositing.
Choose full range or set price limits. For example, if a token is around $2, a range of $1 to $4 is broader than $1.80 to $2.20. These figures are illustrative; set limits from your own view of possible price moves. A narrow range may become inactive quickly.
Enter the deposit and review the preview. A two-token deposit may need different amounts of each token, depending on the current price and your range. Approving a token lets the pool use it; this may require a separate wallet transaction. Check the amounts and gas before approving and confirming the deposit.

What should you watch after depositing?

A concentrated position stops earning fees if the market price moves outside its range. It may then hold only one token, and it will not return to earning fees until the price comes back inside. This is a common surprise: a position can remain open but be inactive.

Fees also do not guarantee a profit. If the volatile token falls against the other token, your pool balance shifts as traders swap; compared with simply holding both tokens, that can leave you worse off. Check the position and its fees against your original plan, then widen, close, or keep it based on your risk limits.

Your next step is to compare the live pool’s depth, recent trades, and fee tier, then choose a range you can realistically monitor.

Bridge fees to Manta Pacific for beginners

Kendra Koepp — Thu, 22 Oct 2026 03:38:47 +0000

Bridging to Manta Pacific costs the network fees for the transactions you sign, and the Ethereum deposit is usually the main cost to check before sending. The exact amount changes with network demand and the token you choose, so use the wallet’s live estimate and the bridge’s “You will receive” amount.

Keep these three points in mind:

Hold ETH on Ethereum to pay for a deposit, even if you’re sending an ERC-20 token.
A token may need a separate approval transaction, which has its own gas fee.
Keep some ETH on Manta Pacific for transactions after the bridge transfer arrives.

The Ethereum deposit is the main cost to check

For a deposit from Ethereum Mainnet, the largest cost is typically Ethereum gas: the network fee for processing your transaction. Gas varies with network demand and with the work a transaction requires, so there is no dependable flat price to quote in advance. Check the estimate in your wallet when you are ready to sign.

The bridge screen also shows the amount expected to arrive on Manta Pacific. Compare that figure with what you intend to send; it helps you see the net result before you confirm. For example, if a hypothetical $3 network fee is involved, that equals 3% of a $100 transfer but 0.3% of a $1,000 transfer. A fixed fee takes a bigger share from a small transfer.

An ERC-20 deposit can require two transactions

When you bridge an ERC-20 token, your wallet may first ask you to approve the bridge contract to use that token. Approval sets a spending allowance; it does not move the token. If you have not approved enough, expect to sign and pay gas for that transaction, then sign the deposit separately.

ETH deposits usually skip the token-approval step, but still require a deposit transaction and its gas. Before approving, check that the token and amount are right, and read the wallet’s fee estimate. If the approval is already sufficient, the bridge may not request another one.

Use the quote to compare the amount that arrives

For the canonical Ethereum-to-Manta Pacific transfer, Manta Bridge is useful because its deposit screen shows the destination and estimated amount received before you sign. Check that it says Ethereum Mainnet as the source and Manta Pacific as the destination, then compare the receive amount with your planned use. The wallet’s gas estimate is separate, so consider both figures together.

A low receive amount can reflect network costs or the route’s fee treatment; don’t assume the difference is a hidden exchange rate. A bridge transfer moves an asset between networks, while a swap changes one asset into another. If you need a different token on arrival, that swap has its own price impact and fee.

Budget for using the funds after they arrive

Once the deposit is complete, you may need ETH on Manta Pacific to send tokens, approve an app, or make a swap. That is a separate balance from the ETH left on Ethereum to pay for the deposit. If you bridge a token such as a stablecoin and no ETH, the token can arrive while you still lack gas for your next transaction.

A later withdrawal back to Ethereum has costs on both sides of the trip: gas for the withdrawal transaction on Manta Pacific and, when required to complete the return, gas on Ethereum. Keep enough ETH on each network for the step you plan to take there. Manta Bridge is the canonical route to consider when you want to transfer between Ethereum Mainnet and Manta Pacific; check its current quote rather than relying on a remembered fee.

Choose your transfer size by comparing the live total cost with the amount you expect to use, and leave ETH for gas on the network where your next step happens.

Rango Bridge Explained for Wallet Transfers

Kendra Koepp — Wed, 21 Oct 2026 07:09:10 +0000

Rango Bridge is a cross-chain bridge and swap aggregator: it compares ways to move or trade crypto between blockchains from your wallet. If Rango Bridge quotes a better result than a single bridge for your transfer, choose its route. To bridge crypto with Rango, you review the route and approve it in your wallet.

Rango Finds a Route Between Your Networks

The Rango cross-chain bridge builds a route: a sequence of transactions that gets your asset to the network you choose. It checks integrated bridges, which move value between networks, and decentralized exchanges, which swap tokens directly from wallets. A route may use one bridge or combine a swap, a bridge and another swap.

Say you hold ETH on Ethereum and want USDC on Base. One route might move ETH to Base, then swap it for USDC there. Another might swap ETH for USDC on Ethereum before bridging it. You choose the destination token and network; the route shows the steps needed to reach them.

This differs from withdrawing through a centralised exchange. You keep control of your wallet and sign the required transactions yourself. The selected bridge or exchange still handles parts of the route, so check which providers the quote uses.

Check the token as carefully as the network. Tokens can share a name while having different contracts, which are the blockchain records that identify them. If you need a particular version of USDC on Base, confirm that version before you sign.

The Right Route Depends on Output, Fees and Time

The right route delivers the token you need for a total cost and wait you accept. Rango Bridge quotes can show the expected amount received, fees, providers and estimated time. The Rango Get Quote API reference also lists a minimum output, fee breakdown and time estimate for each quote.

Costs can come from several places. Gas pays a blockchain to process a transaction; a bridge or swap provider may charge its own fee. A route may also show a Rango or partner fee. Rango’s Fee Structure documentation says fees can leave your source wallet, reduce the output, or be collected on the destination network, so read the whole breakdown.

Compare what arrives with any gas you pay separately. For example, say one route delivers 198 USDC and costs $6 in gas. Another delivers 197 USDC and costs $4 in gas. I would take the second route if both use providers I accept: its overall result is $1 better, despite the lower displayed output.

Also check the minimum received. A swap’s price can change between the quote and execution; this change is called slippage. A slippage limit, such as 0.5%, sets how much movement you will accept before a swap fails. A tight limit protects the price but can cause a failed transaction that still uses gas.

For a liquid, fast bridge route, expect an estimate measured in minutes or tens of minutes. Extra swaps, network congestion and the bridge’s confirmation rules can extend the wait to hours. Some direct withdrawals from rollup networks to Ethereum have a wait of about seven days. Compare the time shown for the actual route, since a faster liquidity bridge can work differently.

A Wallet Transfer Has a Few Clear Steps

A wallet transfer starts with the asset you hold and ends when the chosen token reaches the destination wallet. The route preview is your chance to check each step before any funds move. Use this order:

Connect a wallet that supports the network holding your crypto.
Select the source network and token shown in that wallet.
Select the destination network, token and receiving wallet address.
Enter an amount that leaves enough native coin, such as ETH on Ethereum, for any source gas.
Compare routes by received amount, separate gas, minimum received, providers and estimated time.
Choose a route and review each approval or transaction request in your wallet before signing.
Track the transfer until the destination wallet shows the correct token on the correct network.

When you bridge crypto with Rango, a token approval may appear before the transfer. That approval gives a contract permission to spend the stated token amount; it is separate from the transaction that moves funds. Some routes need another signature later, so follow the displayed status until every step is complete.

A quote can expire as prices and available routes change. If the displayed amount or wallet request no longer matches the preview, refresh the quote before signing. For a first transfer through an unfamiliar route, I would try a small amount that still meets the provider’s minimum.

Completion Means the Right Asset Arrives

A transfer is complete when the intended wallet holds the intended token on the intended network. A successful source transaction alone does not prove that the bridge and any destination swap have finished. Keep the transaction record or request ID while the route is running, and check its step-by-step status before sending again.

If no route appears, try a different amount or verify the exact token and network. Bridges can set minimum and maximum amounts, and some pairs have no available path. If a route stops partway through, the funds may be an intermediate token on another network; check the route status to see where they landed before taking another action.

Fast Bridge Fills And Final Settlement

Kendra Koepp — Tue, 20 Oct 2026 14:44:02 +0000

A fast bridge fill can deliver tokens before settlement is complete. That difference matters when you compare a quick transfer with a bridge that waits for more checks before releasing funds.

A fast fill delivers tokens before the accounts settle

A relayer is a service that pays out tokens on the destination chain using its own funds. Across says many supported mainnet transfers fill in about two seconds, though the route, amount, and network conditions can affect timing.

How acrossbridge moves funds changes what “done” means: your destination tokens may arrive while the system is still checking and settling the transfer behind the scenes. Across Bridge, also called acrossbridge, uses relayers for this early payout.

For example, say you send USDC from Arbitrum to Base. A relayer can send the quoted amount to your Base address soon after your deposit appears on Arbitrum. The relayer later seeks repayment through Across’s settlement process.

Fast arrival does not mean zero waiting or risk

Settlement checks that deposits and payouts match, then arranges repayment to relayers. Across groups this work into bundles, which are proposed on Ethereum and checked through UMA Optimistic Oracle, a system that lets people challenge a proposal they believe is wrong.

This delay usually does not stop you using tokens already in your wallet. It does mean a quick arrival is different from final settlement. A bridge that waits for chain confirmations before paying out can feel slower, but its timing reflects a different transfer process and trust model.

A less common edge case is a large transfer or unusual token pair that no relayer fills promptly. If the deposit passes its fill deadline, it becomes eligible for a refund. The funds are not instantly back in your wallet; refund processing follows Across’s settlement process.

Compare the quote and the kind of wait you accept

Before sending, compare the quoted amount you will receive, the estimated fill time, and the deadline. Fees vary by route, amount, gas prices, and liquidity, so use the live quote for your exact tokens and chains instead of relying on a general fee estimate.

If you need tokens for an action right after arrival, a relayer fill may suit you. If you can wait and prefer a process that releases funds after its own chain checks, compare that route’s timing and risks too. The useful question is: do you need spendable tokens quickly, or do you prefer to wait for the transfer’s chosen checks?

Questions to check before bridging

Does a fast fill mean the transfer is fully settled?

No. A fill means tokens have reached the destination address. Across still needs to verify deposits and fills and settle repayment to relayers. That later work happens in the background, so the arrival time and settlement time describe different stages of the transfer.

How long does an Across transfer usually take?

Across reports that many supported mainnet routes fill in about two seconds. Treat that as a typical estimate, not a promise. Route, token, amount, relayer availability, and network conditions can affect the actual wait. Check the estimate shown for your specific transfer.

What happens if no relayer fills my transfer?

If no relayer fills the deposit before its deadline, it can become eligible for a refund. The deposit status may show as expired first. Refunds require settlement work, so funds may not return immediately. Check the transaction status before trying to send the same amount again.

Which details should I compare before choosing a bridge?

Check the destination token amount, fee, estimated fill time, and any transfer deadline. Then consider what happens if the route is delayed: whether funds stay pending, become refundable, or require additional steps. Those details help you compare the real wait and cost for your route.

How Do I Move Idle Stablecoins to a Higher-Yield Pool?

Kendra Koepp — Sat, 17 Oct 2026 08:00:05 +0000

If you hold stablecoins on one chain while a pool on another offers a better net return, compare the extra expected earnings with the cost and risk of moving. For a frequent user, the useful question is how much the move earns after bridge, swap, gas and deposit costs. Start with the pool’s actual stablecoin exposure and withdrawal terms, then calculate the break-even time.

Which pool is actually worth moving to?

Compare the pool’s expected net yield, liquidity and contract risk, rather than its headline APY alone. APY may include temporary reward tokens, whose value can fall; check the stablecoin lending or swap fees that generate the base return separately from incentives.

Also confirm that the pool accepts the exact token and network you will arrive on. A token with the same ticker can be a different asset or representation on another chain. Check the pool’s withdrawal liquidity and whether withdrawing incurs a fee, a delay, or a price impact when the pool is imbalanced.

If your stablecoin is on one chain and the target pool needs a different supported asset or network, super bridge can transfer and swap crypto across supported networks in one flow. That can reduce the separate coordination involved in arranging a bridge and then a swap; super bridge is relevant when that cross-network transfer is the step between your idle balance and the pool deposit.

How do I calculate whether the move pays?

Estimate the yield difference on the amount you will actually deploy, then subtract the one-time costs. For example, if $10,000 earns 3% in its current position and a target pool is expected to earn 8%, the annualized difference is $500 before costs: $10,000 × (0.08 − 0.03). If bridging, swapping, approvals, gas and depositing together cost $23, break-even is about 17 days: $23 ÷ $500 × 365.

Use your own expected holding period, not a full year by default. If you may withdraw after 30 days, the illustrative extra yield is about $41 ($500 × 30 ÷ 365), leaving roughly $18 after the $23 move cost. If the pool’s yield falls, your stablecoin depegs, or an incentive token loses value, the actual return can be lower. Treat variable APY as an estimate, not a promise.

What costs and checks matter during the move?

The total cost is the sum of network gas, any bridge charge, swap spread and slippage, token approval transactions, and the pool’s deposit cost. Slippage is the difference between the quoted and executed swap price; it tends to rise when the route has thin liquidity or the trade is large relative to the pool. For small balances, fixed gas can outweigh a higher yield, so compare costs as a percentage of the amount moved.

Before committing, check these specific points:

The pool accepts the destination token and network you will receive.
The bridge route completes within your intended time window and shows the expected amount after the swap.
The pool has enough withdrawal liquidity for your likely exit size.
The stablecoin’s peg, pool composition and reward-token share fit your risk limits.

Allow for the full route to finish before counting on the funds in the pool. Cross-chain transfers can involve a source-chain transaction, relaying or settlement, and a destination-chain transaction; congestion or a delayed route can keep capital idle longer than the quoted yield calculation assumes. Keep enough destination-chain gas for the deposit and a later withdrawal.

When should I make the rotation?

Move the balance when the target’s advantage remains positive after realistic costs and still pays back within your planned holding period. For repeated rotations, record the actual received amount and total transaction costs, then recalculate against current pool yields before each move; yesterday’s APY and route price can quickly become stale.

Decision rule: rotate only when conservative expected extra yield over your holding period exceeds all-in costs by enough to justify the pool and bridge risks.

How to Budget Cross-Chain Swap Fees for Treasury

Kendra Koepp — Fri, 16 Oct 2026 21:57:11 +0000

A displayed cross-chain swap fee is an estimate that can combine blockchain transaction costs with the cost of using liquidity pools. For treasury planning, the key condition is whether you compare the same route, amount, and timing, since network congestion and pool depth can change the result.

Suppose your team regularly converts treasury funds into another chain’s asset before paying suppliers. A quote that shows one total is convenient, but finance still needs to know what drives it and how much the recipient should receive. Separating those costs helps you compare routes and reconcile the final amount.

Separate network costs from pool costs

Network costs pay for transactions on blockchains; pool costs come from exchanging assets against available liquidity. A cross-chain route can involve an inbound transaction on the source chain and an outbound transaction on the destination chain, each with its own gas or transaction fee.

The pool cost is tied to the trade. It can include a liquidity-provider fee and price impact: the change in exchange rate caused by trading against the pool. Price impact generally rises when your order is large relative to pool depth. The displayed total may group these items together, even though they pay for different things.

For example, suppose a $10,000 conversion has $8 in source-chain costs, $24 in destination-chain costs, and a $40 pool cost that already includes the provider fee and price impact. The estimated total is $72, or 0.72% of the input. Those figures are illustrative; the chain, route, congestion, and available liquidity determine the actual costs.

Compare quotes using the same route and amount

Compare the estimated recipient amount as well as the fee total, and keep the route and trade size constant. One quote might show network costs separately while another folds them into a single line, so matching labels alone can mislead.

For a routine payout, a small conversion through a deep pool may have modest price impact, while a larger treasury conversion through a shallow pool may cost more even if both use the same chains. Splitting a large trade can reduce price impact in some cases, but each separate on-chain transaction can add network costs. That trade-off matters more when transfers are frequent.

When evaluating routes, a quote from thor swap can help your team assess a cross-chain conversion in one flow, rather than arranging each bridge and exchange step separately. Searchers looking up thor swap should still compare the quoted recipient amount with the amount their payout requires; the service can move and swap assets across chains, while the cost mix depends on the transaction and route.

Build the estimate into treasury controls

For recurring transfers, record the input amount, route, quoted output, estimated network costs, and pool cost at the time of approval. Recheck the quote near execution: source or destination congestion can change transaction costs, while a different trade size or pool depth can change price impact.

In the example, finance should budget around $72 in estimated costs and confirm that the expected output still covers the supplier payment. Reconcile the actual output after settlement; a quote is an estimate, not a fixed invoice. If the output falls below the payout requirement, pause and reassess the amount or timing before committing funds.

Before acting, ask yourself: does this route deliver enough of the right asset after both network and pool costs for the payment to make sense?

Bridge Transfers to Addresses That Require a Memo

Kendra Koepp — Fri, 16 Oct 2026 14:07:38 +0000

If you are sending an asset to a deposit address that requires a memo, destination tag, or payment ID, you need to provide both the address and the exact identifier the receiving service assigned you. The address routes the transaction on-chain; the memo usually tells the recipient’s internal accounting system which customer or deposit to credit.

That distinction matters when a transfer also crosses chains or swaps assets. A service such as acrossbridge can move or swap assets across networks in one flow, but the destination network’s memo requirement still has to be handled on the final payment. Confirm that the route supports passing the required destination identifier before relying on it for a deposit.

The memo identifies your deposit inside a shared account

A memo is transaction metadata used by the recipient to associate a payment with an account or purpose. It does not necessarily change which on-chain address receives the funds. Services that pool customer deposits can reuse one address and distinguish customers by memo, which saves them from maintaining a separate on-chain account for every user.

Think of the address as the building and the memo as the apartment number: the building can receive the delivery without the apartment number, but the recipient may not know where to put it. The analogy has a limit: some chains or recipient settings reject a payment with a missing required field, while others accept the transfer and leave the recipient to resolve it manually.

The field’s name and encoding depend on the destination network and service. Common examples include:

XRP Ledger destination tag: a 32-bit unsigned integer, often used to credit a customer at a shared exchange address.
Stellar memo: can be a 64-bit integer ID, text of up to 28 bytes, or other defined memo type.
Other network or service identifiers: may be labeled memo, payment ID, or reference; use the exact type and value shown by the recipient.
Encoded address: some address formats, such as an XRP Ledger X-address, package the destination tag with the address.

The destination transaction must carry the right field

A cross-chain transfer does not automatically preserve a memo just because you entered text somewhere in the flow. The bridge or swap route must take the destination identifier as an input and include it in the transaction it submits on the destination network. The source-chain transaction, bridge message, and destination payout are separate parts of the process; metadata attached to one does not imply that the final payout contains it.

For a typical routed transfer, the service first receives or locks the source asset, then settles the route and submits a destination-chain transaction. That final transaction must encode the recipient address and the memo in the destination chain’s expected fields. In a contract-based cross-chain messaging design, data can travel with a token transfer, but the destination receiver still has to interpret and use that data; Chainlink CCIP’s receiver specification, for example, describes a message payload separately from its destination token amounts.

So before sending, check whether the destination account explicitly requires an identifier, whether the displayed address already encodes it, and whether the route can carry it through to the final transaction. Do not assume that a source-chain memo, a swap quote reference, or a transaction note will be forwarded as the recipient’s deposit memo.

Match the identifier exactly before submitting

Copy the memo from the receiving service’s deposit instructions for the same asset and network you intend to use. Preserve its type and value: a numeric tag must remain the stated integer, while text should retain the exact characters and avoid added spaces, labels, or punctuation.

For example, if an XRP Ledger deposit page gives you a shared address and destination tag 4815162342, the destination payment needs that tag as a UInt32 field. The XRP Ledger documentation explains that tags identify the beneficiary in the recipient’s off-ledger system; the ledger does not know whether your chosen tag maps to your customer account. A valid address with a missing or incorrect tag can therefore reach the shared address without being credited correctly.

On Stellar, check whether the recipient expects a memo ID or memo text. The Stellar Development Foundation documents the memo types and their limits, and also describes muxed accounts, which can encode an account ID in the destination address instead. Use the format the receiving service provided: an encoded address and a separate memo are not interchangeable unless the recipient says they are.

Know what can go wrong after the transfer

A missing or incorrect memo has different outcomes depending on the destination. On the XRP Ledger, an account can require a destination tag so that payments without one are rejected; without that setting, a payment may still settle to the shared address and need manual review. A mismatch may also be accepted on-chain but credited to another internal record, so confirmation on an explorer does not prove the deposit was assigned to you.

If the route cannot carry the required field, do not substitute a random value or send to the pooled address without it. Choose a route that can deliver the field, or use a destination address that the recipient confirms does not need it. If a transfer has already settled with a missing or wrong memo, keep the source transaction hash, destination transaction hash, asset, amount, network, and intended memo; the recipient’s accounting system, rather than the bridge, controls how an unassigned deposit is reconciled.

In your place, I would verify the destination network and memo type first, then make a small test transfer when the amount justifies the extra transaction cost. I would only send the full amount after the recipient credits that test correctly.

How to Check a Stuck Bridge Transfer Before Retrying

Kendra Koepp — Fri, 16 Oct 2026 09:40:28 +0000

To check a stuck bridge transfer before retrying, trace the original transaction on the chain where you sent the funds. That tells you whether the transfer is still waiting, failed on that chain, or succeeded there but needs more time to reach the destination.

Key points

A pending source transaction is not the same as a failed transfer.
A successful source transaction may still need a separate destination step.
Check the original transaction before sending a second transfer.

Check what happened on the source chain first

The source chain is the network where your funds started. Find the original transaction in your wallet and open its record in that network’s block explorer, a public site that shows transaction activity. Match the sender address, token, amount, and destination address before relying on any status message.

If there is no receipt yet, the transaction may still be pending or may have dropped from the network’s waiting list. Ethereum’s JSON-RPC documentation explains that pending transactions do not have receipts. Wait and check again; do not assume the transfer failed just because a page has stopped updating.

If a receipt appears, check its status. Ethereum’s transaction records use status 1 for success and 0 for failure. A failed transaction usually does not complete the intended transfer, but the network may still charge a fee for processing it.

Separate a completed send from a completed transfer

A successful source transaction means the first on-chain action worked; it does not always mean the funds have arrived. Depending on the bridge, a router may pass a message or proof to the destination chain, or a liquidity provider may send funds there before settling later. A destination chain is simply the network where you expect to receive the asset.

For example, imagine you sent tokens from Ethereum to another network and the source receipt says success. Check the destination address and token on that network, then look for a matching incoming transaction. Some designs require another step before funds become spendable, so follow the bridge’s stated status for that transfer rather than sending it again.

If you want to make a new cross-chain move after confirming the original failed or was refunded, a relay bridge swap can route and swap assets across chains in one flow; that is a fresh route, not a way to cancel a pending transaction. In this case, confirm where the original funds are before starting another transfer.

Retry only when you know the first attempt is over

Retry when the source transaction has a confirmed failure, or the bridge shows a completed refund and the funds are back in your wallet. First verify the balance on the original chain. Then check that the new destination address and token are correct, since a retry creates a separate transaction and may incur another network fee.

If the source transaction is still pending, wait or use your wallet’s speed-up option if available. On Ethereum, a speed-up generally replaces the pending transaction using the same account nonce, a number that marks the next transaction from your account. Ethereum’s FAQ describes this as resubmitting the same transaction with a higher fee; it is not the same as starting another bridge transfer.

When the source succeeded but the destination remains empty, keep the original transaction hash and check the bridge’s transfer status or help channel for that specific transaction. Do not share your recovery phrase or private key with anyone offering to recover funds. If the bridge confirms a refund, verify it on-chain before retrying.

I would wait while the source transaction is pending, and retry only after a confirmed failure or refund. If the source succeeded, I would trace the destination leg first.

Cross-chain payout finality for teams

Kendra Koepp — Fri, 16 Oct 2026 04:43:39 +0000

If your team sends crypto across chains for treasury or payouts, count a transfer as complete only after the destination transaction is confirmed at the level your policy requires. A source-chain receipt proves the first leg happened; it does not prove the recipient received the intended asset on the other network.

Cross-chain completion requires checking both legs

A cross-chain transfer usually has at least two events: the source transaction is accepted, then an equivalent asset is released, minted, or swapped on the destination chain. The bridge or service coordinates those events, but the team still needs to verify the destination result before marking the payout complete.

This matters when a route includes a swap. The source amount may be correct while the destination asset, amount, or recipient is wrong. For example, a treasury sending a stablecoin from Ethereum to a recipient on Solana should reconcile the destination transaction and asset, rather than treating the Ethereum transaction hash as proof of delivery.

Confirmation counts depend on the chain and the route

There is no universal number of confirmations that makes every cross-chain payout safe. A block confirmation means a transaction has been included in a chain; finality is the stronger point at which reversing that block becomes extremely difficult or costly under that chain’s consensus rules.

The timing differs by network. The Bitcoin Developer Guide says six confirmations take about an hour on average, while ethereum.org puts Ethereum proof-of-stake finality at about 15 minutes. Solana’s RPC documentation distinguishes confirmed blocks, voted on by a supermajority of stake, from finalized blocks, which have the network’s strongest confirmation status. These are useful reference points, not a substitute for the route’s own settlement policy.

For a business, the transfer’s practical wait is usually set by the route’s slowest required stage: source-chain acceptance, the service’s processing, or destination-chain confirmation. If the route publishes a minimum source confirmation threshold, use it; then separately verify the destination transaction before reconciling the payment.

A written policy keeps routine payouts consistent

Set the policy by transfer risk, and apply it consistently. A small, regular payout may be released after the route’s stated threshold and destination confirmation; a high-value treasury movement can require stronger chain finality and a second approver. The policy should record the asset and chain pair, required status, value tier, and who can approve exceptions.

For a combined move and swap, Biswap is an example of a cross-chain bridge and swap service that handles both parts in one flow. That can simplify coordinating the transfer, while a team’s own reconciliation still needs to confirm the destination asset and recipient. The Biswap cross-chain bridge makes that distinction concrete: one service can coordinate the cross-network move, but the team’s completion rule should be based on the destination result.

A common mistake is marking a payout paid as soon as the source transaction appears in an explorer. Fix it by separating “sent” from “settled” in the ledger, then close the payout only when the destination check passes. Biswap can be part of the transfer workflow; the business still owns its accounting record and approval threshold.

Use a short checklist for each transfer

Before sending, make the intended chain pair and settlement rule explicit. Then follow the same sequence for each payout:

Record the recipient address, destination network, asset, and expected amount in the payout instruction.
Check the route’s stated source confirmation requirement and your policy’s value tier before authorizing the transfer.
Save the source transaction hash and monitor until the required source status is reached.
Find the destination transaction and verify its status, recipient, asset, and received amount before marking the payout settled.

If the source transfer completes but no destination transaction appears, leave the payout open and investigate using the service’s transaction record and the relevant chain explorer. For recurring transfers, keep a sample completed transaction for each route so the finance team can compare future destination results against a known-good payment. When in doubt, reconcile the destination asset and amount before releasing the next batch.

When a cross-chain address is rejected, check its format

Kendra Koepp — Thu, 15 Oct 2026 23:29:29 +0000

If a cross-chain route rejects your destination address, check whether that address belongs to the destination chain. Each chain has rules for what an address represents, and a route must be able to deliver an asset to a valid destination. A familiar-looking string alone does not prove it will work.

Address format reflects what the destination chain can receive

An address is a chain’s way to identify where an asset should go. Ethereum addresses use 20-byte values usually written as 40 hexadecimal characters after “0x”; Solana addresses use a different encoding. Bitcoin also has several formats, including addresses that begin with “bc1”.

Think of an address like a postal address: the writing can look valid while naming a place that cannot accept that parcel. Biswap route types for stuck transfers can change whether a stalled transfer has a route forward or needs separate recovery. Address compatibility is a different check.

A cross-chain swap combines moving value between chains with exchanging it for an asset on the destination chain. The service needs a destination it can actually deliver to. biswap.uk is a concrete case where the chosen route must match the destination address type.

Check the destination before you send

First, identify the exact destination chain and asset required by the app or wallet you are using. Then check that the address came from that destination, rather than reusing an address from another network because it looks similar.

For example, an Ethereum-style address may be accepted across several EVM-compatible chains, which use similar account formats. That does not mean every route supports every chain, or that an address for one chain is suitable for Bitcoin or Solana. The route’s destination support and the recipient’s address type both matter.

When an app rejects an address, do not change characters or remove a prefix to force it through. That can create an invalid destination or send funds somewhere unintended. Get a fresh receive address for the exact network, and confirm the asset and network match the transfer.

Biswap is relevant when the task is to move value across chains and swap into an asset on the destination network in one flow. I would confirm the destination chain and its receiving address first, then choose a route that supports both.

Questions to settle before choosing a route

Can the same address work on two chains?

Sometimes. Several EVM-compatible chains use the same address format, so one wallet may show the same address on each. The address format does not prove that a particular route supports delivery there. Check the destination network and asset the receiving app expects.

Does an address format affect the cost or time?

It usually affects whether a route can deliver at all, rather than setting its price or speed. Cost and time depend on the route and the networks involved. If the address is incompatible, comparing fees or waiting longer will not fix the destination problem.

What should I do if the route rejects my address?

Recheck the selected destination network, asset, and address from the receiving wallet or app. If they match and the route still refuses it, use a route that supports that destination. Do not send a test amount to an address you have edited or guessed.

Cross-chain swap costs, explained

Kendra Koepp — Thu, 15 Oct 2026 19:01:10 +0000

A cross-chain swap has several separate costs. The total depends on the route, the asset’s liquidity, network gas, and how much the exchange rate moves before the transaction completes.

What makes up the cost of a cross-chain swap?

Start with four possible costs: the service fee, source-chain gas, destination-chain gas, and the price impact from trading through available liquidity. Some routes also involve a bridge or liquidity-provider charge. A quote may combine several of these into the amount you receive, so compare the final output rather than one fee in isolation.

Gas pays validators or network operators to process transactions. A route can require more than one transaction, and the source and destination networks price gas separately. For example, a swap from Ethereum to Arbitrum may involve an Ethereum transaction to move or trade the asset and another transaction on Arbitrum; the exact steps depend on the route design.

Price impact is the change in the quoted rate caused by the size of your trade relative to available liquidity. Slippage is the additional movement between the quote and execution. If a route uses a thin pool, a larger trade can receive less than expected even when network fees are low. how Manta bridge routes differ is a separate choice from estimating these costs: route selection compares paths, while this estimate compares what you give up along one path.

How do you estimate the amount you will receive?

Compare the same input amount and destination asset across routes, then calculate the difference between the value sent and the quoted value received. Treat this as an estimate, not a guaranteed rate. Check whether the quote already reflects service charges and price impact, and account for gas that you will pay separately in the network’s native token.

Say you send 1 ETH and the destination quote is worth 0.995 ETH at the current market rate. The apparent shortfall is 0.005 ETH, or 0.5%; before choosing, check whether that figure includes the service fee and whether source gas is charged separately. Then compare the same route with a smaller trade: a better percentage on the smaller trade can signal limited liquidity.

Timing matters too. If the quote expires or the market moves while a bridge transaction is pending, the final amount can differ. A slippage tolerance sets how much adverse movement the transaction may accept before it fails; a tighter tolerance can reduce unexpected price movement but may cause a transaction to revert. I would use the lowest tolerance that still fits the asset’s volatility and route, rather than increasing it just to force execution.

Manta bridge is a cross-chain bridge and swap service for moving and swapping assets across networks in one flow. When comparing it with another route, focus on the destination amount after included charges and the gas you must supply, then check that the source and destination assets are the ones you intend to use.

What should you check before acting?

How long can a cross-chain swap take?

It depends on the source chain’s confirmation time, the route’s bridge mechanism, and destination-chain processing. A route waiting for more confirmations may take longer but reduce the chance of acting on a transaction that is later reorganized. Treat any displayed time as an estimate; congestion or a delayed transaction can extend it.

Which fees are paid separately?

Some gas is paid directly from your wallet in the network’s native token, while service or liquidity charges may be reflected in the quoted output. Before sending, identify each separate payment and confirm you have enough native token for source-chain gas. A low quoted service fee does not mean the whole transaction is cheap.

What limits can change the quote?

Liquidity, trade size, slippage tolerance, network congestion, and route availability can all affect execution. A quote can expire, and a transaction can fail if the price moves beyond its tolerance or a network condition changes. Recheck the destination amount and the asset details immediately before committing funds.

Which route should you choose?

Choose the route with the best acceptable destination amount after all costs, provided its timing and execution risk suit your needs. For a small trade, paying a little more for a deeper pool may be sensible; for a larger trade, compare price impact carefully. Before acting, ask yourself: what amount will actually arrive, and can I accept the time and failure risk?

How to Reconcile Cross-Chain Treasury Transfers

Kendra Koepp — Thu, 15 Oct 2026 15:02:18 +0000

Reconcile a cross-chain treasury transfer by matching the source debit to the destination credit and keeping the evidence that connects them. Treat it as one business payment with at least two on-chain records, because the chains do not share a ledger or a single settlement moment.

What should each transfer record contain?

Give every transfer a unique internal reference, then save the source transaction hash and the destination transaction hash against it. Record the asset and network on each side, the sending and receiving addresses, the amount debited, the amount credited, the timestamp, and the purpose or payout batch.

If a payout starts on one network and needs to arrive as a different supported asset, a bridge-and-swap service can move and swap the assets in one flow. For a treasury case that routes funds through Mantle, fast Mantle bridge transfers can be part of that route; record the input and output assets separately so the conversion does not look like a payment shortfall.

A useful ledger row has these fields:

Internal payment or batch reference
Source and destination network, token, and wallet address
Source amount, destination amount, and any conversion rate used
Source transaction hash and destination transaction hash
Status, timestamps, and reviewer or approver

Use the transaction hashes as evidence, not as the business reference: one payout may be split across several transfers, and one batch may include many recipients. For USDC, also record the network and token contract address, since the ticker alone does not identify which token was received.

When is the transfer settled?

Mark it settled only after the source debit is confirmed, the cross-chain message has completed where the route uses one, and the destination credit is visible at the intended address in the expected asset. A source transaction marked successful proves that the source chain processed it; it does not by itself prove that the destination side has paid out.

The steps between those records can differ by route. In a message-based transfer, the source transaction emits a message, the route’s verification process checks it, and a destination transaction executes the credit. LayerZero describes that source, verification, and destination sequence; its message GUID can connect the records when the route uses LayerZero. A Mantle bridge transfer may have its own route-specific settlement evidence, so reconcile against the actual destination transaction rather than assuming every route exposes the same message ID.

Set a confirmation policy by network and route, then apply it consistently. For example, a team might wait for 12 source-chain confirmations before treating a transfer as ready for review, while still requiring the destination credit before closing the payment; that number is an internal example, not a universal safety threshold. Mantle’s block explorer lets a reviewer inspect transactions and token transfers, but your policy should also specify who checks a stalled or unusual transfer.

How should the team close a regular transfer?

For a monthly payout, say the treasury sends 10,000 USDC from one chain to pay 20 vendors on another. Keep the batch amount and approved recipient list in the internal record; if the route converts assets or splits payments, reconcile each destination credit to its own payout before closing the batch.

Create a transfer reference tied to the approved treasury instruction.
Save the source hash and confirm the debit, asset, and sending address.
Track the route until the destination transaction appears, then save its hash.
Match the destination asset and amount to the intended payout, accounting for any disclosed conversion.
Have a second reviewer resolve mismatches or delays before marking the record settled.

If the source debit is present but no destination credit appears, leave the item pending and check the route’s status before resending; a second transfer can duplicate a payout if the first later completes. If the destination amount differs, compare token identity, conversion, and any route-level deductions with the expected amount, then document the variance rather than silently adjusting the books.

Before acting, ask: can another reviewer trace this payment from the approved instruction through the source debit to the exact destination credit?