DEV Community: Merissa Stemler

How Validators Agree a Deposit Really Happened

Merissa Stemler — Fri, 23 Oct 2026 18:56:53 +0000

If you send crypto to a cross-chain swap, validators first check that the deposit happened on its source blockchain and then agree to record it. That check takes time because a new block can sometimes be replaced in a chain reorganisation. Knowing the steps helps you tell a normal confirmation wait from a deposit that needs investigating.

What are validators checking?

Validators check for a specific event, such as a transaction sending funds to an address the protocol is watching. They independently read the source blockchain using their own connections to its data, then report the transaction details to the protocol’s coordination chain. Those details can include the transaction ID, asset and amount.

That report is called a witness. It is a statement that a particular event occurred, rather than a cryptographic proof that the source blockchain can never change. Each validator in the active Validator Network must make its own observation; the process is not meant to rely on one operator’s report.

Validators also wait for the source chain to meet a confirmation rule, known as a safety margin. A confirmation means another block has been added after the block containing the deposit. The extra blocks lower the chance that a reorganisation will remove the deposit, but they cannot make that chance zero.

How does one observation become an accepted event?

After the required safety margin, validators submit witness transactions to the protocol’s coordination chain. A transaction submitted to a blockchain is often called an extrinsic; here, it carries a validator’s report into the chain’s shared record. Other validators compare the report with what they observed.

In Chainflip, that coordination chain is the State Chain, and the reports concern events on separate external blockchains. The State Chain accepts a witnessed event once enough validators in the active set report it consistently: the documented standard set has 150 validators, with 100 reports needed. That shared threshold is what turns individual observations into a protocol decision.

If a validator reports different details from the others, its report does not help reach the threshold. The network can also punish a validator for a false report or for repeatedly failing to report events that the required majority observed. This makes agreement depend on independent observations and an on-chain threshold, rather than on trusting the first validator to notice a transaction.

What happens in a Bitcoin deposit example?

Suppose you send Bitcoin to a deposit address for a swap. First, the transaction appears in a Bitcoin block. Validators look for it at the watched address, check the transaction details, and wait for the protocol’s Bitcoin safety margin: the current documentation lists two additional blocks.

Then each validator submits its witness to the State Chain. When 100 of the 150 validators have reported the same deposit, the event is recorded as real for the protocol. That record lets the protocol account for the incoming funds and continue processing the swap; it does not mean the Bitcoin transaction has become impossible to reverse.

For Chainflip users, this is a different step from the swap itself: the deposit first has to be recognised by validators, while the State Chain handles protocol accounting and swap instructions. If you are comparing how protocols handle cross-chain deposits, Chainflip is one example of a system that waits for external-chain observations to reach a validator threshold before treating an incoming transfer as recorded.

What should you do while the network waits?

Check that your wallet shows the transaction as broadcast, then use its transaction ID to confirm it appears on the correct source blockchain and pays the intended deposit address. Compare the amount and address with the deposit instructions you were given. A wallet’s “sent” status means it submitted a transaction; it does not by itself show that validators have accepted it.

Allow time for both the source chain’s confirmation rule and the validator reports to complete. These waits vary by chain: Bitcoin blocks average about ten minutes, while other chains use different block times and confirmation rules. A slow block or temporarily unavailable validator connection can delay recognition, even when your transaction is valid.

If the transaction is in a block but the protocol has not recorded it after the expected wait, keep the transaction ID and check the service’s status information before taking action. Do not send a second deposit just because the first one is still waiting; the original may be recognised later. The key detail is whether the source chain still includes your transaction and whether enough validators have witnessed it.

For a chain with deterministic finality, validators may be able to accept a deposit after it is final in a block, without waiting for extra blocks. For a chain where blocks can be reorganised, expect a safety margin and a longer wait. That difference in the source chain’s finality is what should change your expectation—not the number of confirmations shown by a wallet alone.

Why Is My Portal Bridge Transfer Still Pending?

Merissa Stemler — Fri, 23 Oct 2026 01:13:31 +0000

A cross-chain bridge can show a transfer as pending after the source transaction succeeds because the destination still needs a separate claim. The key question is whether a signed proof is ready and whether anyone has submitted it on the destination chain.

In Portal Bridge, check the source transaction first, then look for a destination transaction. When the source is confirmed but the destination step is missing, use Portal Bridge cross-chain transfers to resume that transfer; the signed proof identifies the original send, so you should not start another one.

Manual redemption uses gas from your destination wallet

With a manual transfer, you submit the final claim yourself and pay the destination chain’s transaction fee. The bridge’s validators, called Guardians, watch the source transaction and sign a proof called a VAA; that proof lets the destination contract release or mint the tokens.

A confirmed source transaction does not mean the tokens are already spendable. Once the VAA is ready, your wallet must submit it on the destination chain. For a transfer to Arbitrum, for example, you need ETH on Arbitrum to pay the claim’s gas, even if the token you are moving is USDC.

To estimate the cost, multiply gas used by the gas price. Say a claim uses 120,000 units of gas at 20 gwei: that is 0.0024 ETH. This is an illustration, not a current quote; the wallet’s estimate depends on the destination network and how busy it is. A failed claim can still use gas, so check the amount before signing.

Manual redemption suits someone who has destination gas and wants to control when the claim is sent. It may not fit if you have no native coins on that chain. The Wormhole docs describe the proof and separate completion step; the destination block explorer shows whether a claim transaction succeeded.

An automatic relay submits the claim for you

An automatic transfer uses a relayer, a service that submits the destination claim on your behalf. The route usually accounts for the relayer’s fee in its quote, and some routes let you include a small gas drop-off: native coins sent with the transfer for later transactions.

This option suits someone who cannot pay destination gas upfront, if the route and token support it. It may cost more than a manual claim, and the transfer can remain pending while the source proof is prepared or the relayer works. Check the route’s quoted amount and any gas drop-off before approving the source transaction.

Check the stage before you retry

Use the source transaction hash to find out whether the send succeeded. If it reverted, no claim can complete from that attempt; if it succeeded, look for the VAA or a destination transaction before taking another step. A signed VAA is proof of the send, not proof that tokens reached your wallet.

If the VAA is ready but no destination transaction appears, connect the wallet that matches the intended recipient, switch it to the destination network, and make sure it has that network’s native gas token. Retry the claim once and inspect its receipt in the destination explorer. A failed receipt means the claim did not complete, though the transaction may have spent gas; a successful receipt means the transfer is complete, even if the bridge page has not refreshed.

Confirm the source transaction succeeded.
Check whether the VAA is ready and the destination claim exists.
For a manual claim, fund destination gas; for an automatic route, review its fee and drop-off.
Retry only the unfinished destination step, then verify its receipt.

DEX Aggregator Routes: Pricing Shared Pools Fairly

Merissa Stemler — Thu, 22 Oct 2026 12:49:57 +0000

Split trades can reach more pools if the router counts shared reserves once. This matters when you are comparing ways to swap a large amount: separate routes can improve your price, but overlapping routes can make available liquidity look deeper than it is.

Splitting a trade can soften its price impact

A router can divide your order among pools to avoid pushing the whole amount through one pool. A liquidity pool holds tokens for people to trade, and its price shifts as those reserves change.

For example, imagine two separate pools each hold 1,000 A and 1,000 B, with no fees. Selling 200 A into one pool returns about 167 B; selling 100 A into each returns about 182 B combined. The split gets a better price because neither pool takes the full trade.

If you are comparing a larger swap across separate sources, ParaSwap can quote routes that split the order. Compare the estimated amount you receive after network costs, since extra pool calls can use more gas—the fee paid to process a transaction.

Shared reserves can make a route look better than it is

Shared reserves are tokens that more than one candidate route would draw from. A route is the sequence of pools a swap follows; two routes may seem separate while relying on the same pool for one step.

Suppose one candidate sends A through an A/B pool, then B/C. Another sends A through that same A/B pool. The router cannot safely add both quoted outputs as if each route had an untouched A/B pool: the first trade changes that pool’s reserves and price for the next one.

A sound quote simulates the combined trade against each pool’s changing state, then checks the final output and minimum acceptable amount. This is the edge case that decides whether a split is real: routes must use independent liquidity, or the router must account for their overlap.

Choose by net output and route overlap

For a small trade, one direct pool may win because the price improvement from splitting does not cover the added gas. For a larger trade, splitting across independent pools can offset price impact enough to leave you with more tokens after costs.

Pool design affects that cost. The Uniswap v4 whitepaper describes a single contract that manages many pools and tracks temporary balance changes before settlement. That shared contract can reduce work between pools, but each pool still has its own state and reserves; one pool’s liquidity is not automatically available to another.

The ParaSwap API is one way to compare routes across sources, but the useful result is the net quote for your amount and chain. Choose a split when its gain after gas is clear and the routes do not count the same reserves twice; choose differently when the trade is small, routes overlap, or the quote’s minimum output is too low for your needs.

Treasury Swap Slippage for Occasional Users

Merissa Stemler — Thu, 22 Oct 2026 01:02:06 +0000

Set a treasury swap’s price boundary before requesting execution. That boundary tells you how much worse the final exchange rate may be than the one you reviewed. If you only swap a few times a year, a written target and a quick quote check can prevent a rushed trade from spending more of the treasury’s value than intended.

Separate price impact from slippage before setting a limit

Price impact is the change in price caused by the size of your trade; slippage is the difference between the price you saw and the price you actually receive. They are related, but a tight slippage setting cannot fix a poor quote or thin liquidity. For a treasury swap, compare the expected output with an independent market reference, then decide the lowest output the team will accept.

For example, if a quote offers 50,000 units of a stablecoin for the treasury’s tokens, a 0.5% tolerance implies a minimum of 49,750 units, before any separate fees. Treat that figure as an illustrative boundary, not a recommended setting. The right limit depends on the trade size, token volatility, available liquidity, and how quickly the team needs execution.

Choose a limit that fits the trade and its deadline

Set the minimum acceptable output in the asset the treasury will receive, and record it in the approval request. A narrow limit protects the exchange rate but may leave the order unfilled; a wider limit makes execution more likely while accepting a worse result. I would decide that trade-off before opening the swap screen, not while a quote is counting down.

For a stablecoin-to-stablecoin trade, the reference price may be close to one-to-one, but token depegs and pool imbalance can make that assumption unsafe. For a volatile-token trade, refresh the reference price immediately before approval and use a deadline that reflects the treasury’s need. If execution is optional, a limit order can wait for the price; if it is time-sensitive, the team may need to accept a wider boundary or reduce the trade size.

Check the quote’s route and execution model

Review the token pair, network, input amount, expected output, minimum output, and any displayed fee before signing. To make that review concrete, compare the quote in cowswap with the treasury’s recorded target, because a batch auction can use solver-chosen routes and the final result must still meet the order’s terms. A displayed estimate is not the same thing as an executed trade.

CoW Swap’s batch auctions collect orders and let solvers compete to execute them using on-chain liquidity; some trades can also benefit from Coincidence of Wants, where orders directly offset one another. That process affects how a swap is routed, but the treasury still needs a clear acceptable output. Check whether the interface shows a minimum received amount or a limit price, and make sure it matches the approved boundary. If it does not, stop and resolve the difference before signing.

Recheck the order before approving it

Before you submit, confirm that the quote is still current and that the approval covers the intended token and amount. Token approvals can authorize a contract to spend tokens, so use the amount needed for the trade if the wallet or interface allows it. A quote that has expired, a changed output, or an unexpected approval is a reason to review the transaction again.

After execution, compare the settled output with the recorded minimum and save the transaction details with the treasury’s records. If the order expires or fails, do not simply loosen the limit: check whether the market moved, the quote was stale, or the size exceeded available liquidity. Then obtain a fresh quote and have the team approve the revised terms.

Compare the quote with an independent market reference.
Set and record the minimum acceptable output before signing.
Check the pair, network, amount, fees, and approval.
Confirm the settled output or investigate a failed order.

Portal Bridge Routes: What Each Transfer Type Delivers

Merissa Stemler — Tue, 20 Oct 2026 23:44:53 +0000

Portal Bridge is a cross-chain transfer interface for moving supported tokens between blockchains. The condition that matters most is which token contract you need on arrival: a Wormhole-wrapped asset, an issuer-native token, or the output of a swap.

Match the route to the exact destination token, not its ticker alone.
Choose manual or automatic redemption according to gas access and the quoted fee.
Check finality, recipient address, and minimum received before signing.

The Route Determines the Asset You Receive

A Portal Bridge route specifies both how value crosses chains and what settles in the recipient wallet. Wrapped Token Transfers (WTT) lock a token on its home chain and mint a Wormhole-wrapped representation elsewhere; sending it home burns that representation and releases the original. A native route can instead deliver a token issued or recognized directly on the destination chain.

The distinction matters most when depositing into a lending market or exchange. Two tokens labeled USDC can have different contract addresses and different acceptance rules. Read the destination contract address in the route preview, then compare it with the contract the receiving application accepts.

Five Route Types Cover the Main Choices

The Wormhole Portal Bridge interface can show different routes for the same chain pair as the selected asset changes. Availability also depends on token support, destination liquidity, and whether a relayer serves that route. These are the practical categories:

Manual WTT — Best for a supported token when you can fund gas on both chains and redeem the signed message yourself. It does not fit when the recipient lacks destination gas or requires a native token.
Automatic WTT — Best for the same wrapped-asset outcome with destination redemption handled by a relayer. It does not fit when the token lacks relayer support or the relay charge consumes too much of a small transfer.
Native USDC through CCTP — Best when both chains support Circle’s burn-and-mint route and the recipient needs native USDC. It does not fit a chain pair outside CCTP coverage; a WTT fallback would produce Wormhole-wrapped USDC.
Issuer-managed Native Token Transfers (NTT) — Best when the token issuer has deployed its own cross-chain system and the receiving application recognizes that token on both chains. It does not fit arbitrary tokens; the issuer must have enabled the route.
Native-asset or swap routes — Best when the desired output is canonical ETH, USDT, or another quoted destination asset rather than a wrapped copy. They do not fit when the required pair lacks liquidity or the quoted price impact exceeds the benefit.

Manual and automatic describe who submits the destination transaction; WTT, CCTP, NTT, and swap routes describe how the asset is delivered. Treat those as separate choices. A route can look easier because it is automatic yet still deliver the wrong token contract.

A Transfer Becomes Complete at Destination Redemption

On Portal Bridge, a WTT source transaction locks the original token, or burns an existing Wormhole-wrapped token, and emits a transfer message. Wormhole Guardians observe the finalized transaction and sign a Verifiable Action Approval (VAA). That signed message is what lets Portal Bridge transfers proceed to redemption: the destination contract verifies it, then mints the wrapped asset or releases a token held in custody.

For manual WTT, you submit the VAA and pay destination gas; for automatic WTT, a relayer submits it under the quoted terms. A pending source transaction, an available VAA, and a completed destination transaction are distinct states. If delivery stalls, look up the source hash in Wormhole Explorer before sending again; an unredeemed VAA may still be claimable.

WTT also normalizes transfer amounts to eight decimal places. For a token with 18 decimals, an amount such as 1.123456789 is carried as 1.12345678, with the smaller remainder left on the source chain. A token must also have its metadata attested on a destination chain before its wrapped version can first be created, so an obscure asset may need that extra step.

Fees and Wait Times Depend on the Route

Portal Bridge transfer fees are a combination of source gas, destination gas or a relay charge, and any route-specific fee or swap spread shown in the quote. Manual redemption saves the relay charge but requires native gas in the destination wallet. Automatic redemption can include a gas drop-off, which converts part of the arriving value into destination gas and reduces the token amount received.

Say you send 1,000 native USDC from Base to Arbitrum through an automatic CCTP quote showing a 0.30 USDC relay charge and no other deduction. The displayed arrival would be about 999.70 USDC before an optional gas drop-off; Base gas is paid separately. Those numbers are illustrative: inspect the live quote, especially for small transfers where a fixed charge is a large percentage.

Finality often sets the wait. Ethereum.org puts Ethereum finality at roughly 15 minutes, so a conventional transfer originating there can take that long before redemption proceeds; a faster liquidity or intent route may quote seconds by using a different delivery mechanism. Other chains, relayer queues, and destination congestion change the total. Compare the quoted arrival time with the route’s finality assumptions, not only its advertised fastest case.

The Destination Check Comes Before the Signature

Set the source chain and asset, destination chain, recipient address, and amount, then inspect every available route’s output contract and minimum received. Portal Bridge can send to a connected destination wallet or a separately entered address; verify the chain as well as the address, particularly when sending to a treasury or exchange deposit. An address that looks valid is no proof that its owner can use the arriving token.

Approve token spending if prompted, review the source transaction, and retain its hash. For a manual route, keep the destination wallet funded and complete the claim after the VAA appears. For an automatic route, wait for the destination transaction before treating the transfer as settled; if it stalls, check the recorded state and recovery option rather than repeating the source payment.

Four Questions Settle the Route Choice

How does the transfer work?

WTT locks or burns on the source chain, waits for a Guardian-signed VAA, and mints or releases on the destination. CCTP burns native USDC and mints native USDC after Circle’s attestation. Issuer-managed and liquidity routes use their own contracts and settlement terms. The destination token contract in the quote tells you which outcome you are accepting.

How long does it take and what does it cost?

Expect source gas plus either destination gas or a quoted relay charge. A fast route may settle in seconds when liquidity and execution are available; a route waiting for Ethereum finality can take around 15 minutes or longer. Use the live estimate and minimum received for the exact amount and chain pair, since congestion and relay pricing move.

What limits apply?

Support is specific to the token, chain pair, and route. Automatic delivery may require a minimum amount sufficient to cover relay costs, while a swap route may face liquidity and slippage limits. WTT requires destination token registration and carries at most eight decimal places of transfer precision. Check these constraints before approving a large or unusually small amount.

Which option fits the destination?

If the receiving application specifies a contract, choose a route that delivers that contract. If it accepts a Wormhole-wrapped asset and you have destination gas, manual WTT can be straightforward; otherwise compare automatic delivery with its charge. For native USDC or another canonical asset, inspect native and swap routes first, then judge their quote against the wrapped alternative.

I would start with the required destination contract, then compare the routes that actually deliver it. I would send only after checking the minimum received, gas arrangement, and recipient address in the final quote.

For Monthly Cross-Chain Payouts, Reconcile Both Chains

Merissa Stemler — Tue, 20 Oct 2026 14:29:56 +0000

For monthly cross-chain payouts, match each source-chain debit to a confirmed destination-chain credit before marking it complete. A submitted transaction or a balance change on one chain alone does not show that the recipient received the expected amount.

What counts as a completed transfer?

A transfer is complete for treasury purposes when the source action is recognized by the bridge mechanism, the destination action has succeeded, and the recipient’s available balance reflects the net amount due. Those are separate events, often recorded in separate transactions, so one transaction hash cannot prove the whole path.

Record the source transaction hash, destination transaction hash, and any bridge message ID as different identifiers. The message ID, when available, ties the cross-chain instruction together; the two hashes identify the transactions on their respective chains. Ethereum’s JSON-RPC documentation describes how a transaction receipt includes its status and generated logs, which can confirm what happened in that transaction.

A successful source receipt may show that tokens were locked, burned, or sent to a contract, depending on the mechanism. It does not prove that the destination transaction has executed. When a payment is still waiting for source-chain confirmation, how a relay bridge carries a transfer explains why a debit alone does not prove delivery; for reconciliation, keep the transfer open until you can verify the destination result.

Which records should your team match?

Match transfers on a set of fields, not on amount alone. At minimum, capture the sending and receiving chain, token contract or asset identifier, sender, recipient, source amount, destination amount, fee, both transaction hashes, message ID if present, and timestamps. A spreadsheet can work for a small batch, but use one row per transfer and retain the underlying receipts or exports.

Amounts need normalization before comparison. Chains store token quantities in base units, while treasury systems usually show decimal amounts; compare the displayed values only after applying the correct token decimals on each chain. Also distinguish the gross amount sent from the net amount received, since a fee, exchange, or rounding rule can make them differ.

For example, a business sends 12,000 units to fund a payout wallet and the recipient receives 11,988 after a 12-unit fee. Reconcile the source debit of 12,000 to the destination credit of 11,988 and the documented fee of 12; do not treat the 12-unit difference as a missing payment. If the expected fee is not visible in the records, leave the row unresolved until the fee rule or destination event explains it.

How do you handle pending, failed, or mismatched transfers?

Use explicit statuses so a batch report distinguishes “submitted,” “source confirmed,” “destination pending,” “complete,” and “exception.” A source transaction can succeed while a later destination step remains delayed or fails, and a wallet interface may show only one side of that sequence. Set the completion threshold in advance, including how many confirmations or what finality signal your policy requires on each chain.

On Ethereum, transaction documentation describes blocks progressing from inclusion toward finality; a receipt with success status is useful evidence of execution, while finality provides stronger assurance that the block will not be changed. Other chains use different confirmation and finality rules, so apply the relevant chain’s rule instead of copying an Ethereum wait time. The transfer mechanism’s own status can help locate a message, but verify the destination transaction and recipient balance independently.

Raise an exception when the destination transaction failed, the recipient differs from the approved address, the asset is unexpected, or the net amount falls outside the agreed fee and rounding tolerance. A delayed destination is not automatically a loss, and a failed destination step does not mean the funds are safe to resend; first determine whether the mechanism supports retry, refund, or recovery. Keep the original row open and record the resolution against its identifiers.

A repeatable close process

For recurring treasury transfers, use the same checks for every batch and separate reconciliation from approval to pay. The following sequence creates an auditable record without relying on a single explorer screen or dashboard:

Export the approved payout file with recipient addresses, assets, intended amounts, and an internal payment reference.
After submission, save the source transaction hash, chain, timestamp, and receipt status against each payment reference.
Wait for the source chain’s required confirmation threshold, then record the bridge message ID or equivalent tracking reference.
Check for the destination transaction and verify its status, recipient, asset, and net amount against the approved payout.
Record fees separately, mark only verified credits complete, and send pending or mismatched rows to an exception queue for follow-up.

A relay bridge can add a useful mechanism for recurring transfers, but the accounting control is the match between the two chain records and the approved instruction. The practical decision rule is simple: book a payout as complete only when its destination credit, recipient, and net amount match the approved payment after documented fees.

Why Some Bridge Routes Need Destination Gas

Merissa Stemler — Sat, 17 Oct 2026 07:01:38 +0000

A cross-chain route can require destination gas because delivering an asset and executing a swap on the receiving chain are separate transactions, and the second transaction must be paid for there. If the route or recipient cannot supply that chain’s native asset, the transfer may wait, fail, or complete without the intended swap.

Why does the destination transaction need its own gas?

A bridge moves value between chains, but it cannot spend the source chain’s gas to run a transaction on the destination chain. After the source deposit reaches the required finality, a relayer, solver, or bridge contract must submit a new transaction on the destination network. That transaction consumes the destination chain’s execution resources and is paid for in its native asset.

The distinction matters most on routes that bridge an asset and then swap it. A bridge-only delivery may be a simple transfer; a destination swap calls a router or other contract, which needs gas. If your pending route is meant to bridge first and swap on arrival, Biswap is relevant because it combines the cross-chain move and asset exchange in one flow; check whether the destination action needs native gas before retrying.

biswap.uk is a concrete example of a service that combines a cross-chain transfer and swap, so the destination action can affect what gas the route needs.

Think of the bridge as moving a package to another city: paying the courier for the first leg does not pay the local fee for a service performed after arrival. Some routes include that local fee in their execution design; others leave it to the recipient or require a separate gas provision.

What does “separate destination gas” mean in practice?

It can mean one of two things: the recipient must already hold native gas, or the route must arrange gas for the destination execution separately. These are different operational requirements. A user may not need native gas simply to receive a token, but may need it to make a later transaction from that wallet.

When a relayer submits the destination call, it typically pays gas and expects reimbursement through the route’s quoted economics, such as a deduction from the output or a separate gas provision. If that provision is missing or too small, the relayer may not submit the call. If the recipient must submit or retry a transaction themselves, their wallet needs native gas on that destination chain.

On an EVM chain, transaction cost is approximately gas used × effective gas price. A plain native-token transfer is commonly around 21,000 gas, while a router swap may use roughly 100,000–300,000 or more, depending on the contracts, token approvals, and route. Under EIP-1559, the effective price depends on the base fee and the priority fee; the gas limit is a cap, not the amount automatically charged.

On Solana, fees are paid in SOL and execution uses compute units rather than EVM gas. Creating a token account can also require rent-exempt lamports. So a route that appears funded with the bridged token can still lack the native asset needed for a destination instruction or account creation.

Why can a route stay pending or fail after the source transfer?

“Pending” can describe different stages: waiting for source-chain finality, waiting for a relayer or solver, or waiting for destination execution. A slow source confirmation is not evidence of a destination gas problem. Once the source transaction is final, check the route’s status or transaction records to see whether a destination transaction was submitted and whether it succeeded.

If no destination transaction exists, the executor may be waiting for sufficient gas provision, a quote to remain executable, or a solver to take the route. If a destination transaction reverted, it may have consumed gas even though the intended swap did not complete. The bridged asset may remain in a contract, return to the recipient, or be delivered without the swap, depending on the route’s settlement design.

Do not resend the source transfer just because the destination step is pending: a finalized deposit may still be claimable or executable, and a duplicate can create a second transfer. First distinguish “source not final” from “source final, destination not executed.” If a destination transaction failed, use its receipt or explorer record to identify the revert and the asset’s resulting location before deciding whether to retry.

What should you check before retrying?

Start with the destination chain and the exact action that remains. If the asset arrived but the swap did not, confirm whether it is in your wallet or held by a contract, then check whether retrying requires native gas in your wallet. If execution is handled by a relayer, look for a route status indicating a gas or execution shortfall rather than submitting another source-side transfer.

Confirm the source transaction is final and the destination chain matches the route.
Check whether a destination transaction was submitted; if so, inspect its status and receipt.
Estimate native gas for the remaining action, including token-account creation where relevant.
Keep a buffer: for example, a swap estimated at 180,000 gas may need a higher gas limit, and the required native balance also depends on the live gas price.

I would retry only after the asset’s current location and the failed stage are clear. If the route can execute through a funded relayer, recipient gas may not be the blocker; if the recipient must submit the remaining transaction, funding that destination wallet is usually the deciding step. That answer changes when the source transfer is still unfinalized or the route’s settlement design keeps the asset outside the recipient’s control.

Swap Quote Expiry Before Signing, Explained

Merissa Stemler — Fri, 16 Oct 2026 19:32:59 +0000

A swap quote expiry is the time limit on an offered estimate of what you will receive for a crypto swap. It matters most when prices or route conditions can change before your transaction is submitted and confirmed.

What does an expiring quote mean?

A quote is a snapshot: it describes a proposed trade using current prices, available liquidity, fees, and the route chosen to move the assets. Its expiry says how long that snapshot should be treated as current; it does not necessarily mean your wallet or funds expire.

Before signing, check the quote’s timestamp or countdown, the asset and network you are sending from, and the minimum amount you are promised to receive. For a cross-chain swap, confirm the source and destination networks too; checking the Manta bridge supported networks helps ensure the route matches where you intend the funds to go.

Quote expiry and a transaction deadline are related but different. A quote can become stale before a transaction is signed, while a deadline is a condition some swap transactions enforce on-chain: after that time, the transaction reverts instead of executing.

What can change between the quote and the swap?

Prices move as traders buy and sell, and a route may use one or more liquidity pools. If the price moves against your trade, the amount you receive can fall; if available liquidity changes, the proposed route may no longer work. Cross-chain routes also depend on activity and execution across more than one network.

The key protection to understand is slippage tolerance, the amount the final result may differ from the quoted result. A swap may encode a minimum output: for example, with a 1% tolerance on a quote of 1 ETH worth of output, the transaction might accept as little as about 0.99 ETH worth, depending on the exact assets and calculation. A tighter tolerance limits that difference but can make a transaction fail more often.

Expiry alone does not guarantee a particular outcome. If an old quote is submitted, the service may reject it, the transaction may revert, or the swap may execute at a worse price if the transaction still satisfies its minimum-output condition. Some aggregator API documentation recommends refreshing quotes older than 30 seconds, but that is guidance, not a universal expiry rule.

What should you check before signing?

Imagine you are swapping ETH on Ethereum for an asset on Arbitrum. You receive a quote, then pause to compare it with another option. Before signing, refresh the quote if its timer has run out or the displayed terms have changed, and verify that the destination is still Arbitrum and the minimum received still makes sense to you.

Read the wallet’s transaction summary as well as the quote. Confirm the token, amount, destination, and network, and make sure the transaction is the swap you intended to authorize. A wallet signature authorizes a transaction; on Ethereum, a submitted transaction is executed by the network, and a failed on-chain transaction can still use gas. Simply letting an unsigned quote expire does not itself submit a transaction.

If the quote has expired, request a fresh one and compare the new minimum output and route with the old terms before signing. Ethereum’s transaction documentation explains how signed transactions are broadcast and executed, while swap API documentation describes quote refresh and deadlines; together, they show why the quote’s age and the transaction’s actual conditions both matter.

Use an unexpired quote, check its minimum output and destination, and sign only when those terms still match your intent.

How Do You Bridge Assets Out of a Lending Position?

Merissa Stemler — Fri, 16 Oct 2026 13:45:29 +0000

You can bridge assets out of a lending position after you repay enough debt to withdraw them without putting the remaining loan at risk. If you are researching ParaSwap, the key distinction is that the lending position must be managed on its source chain before the released asset can move elsewhere.

Repay debt on the chain where the lending position exists.
Check how a withdrawal changes the position’s health factor.
Bridge only the assets you can withdraw safely, and leave funds for transaction costs.

Repay debt before withdrawing collateral

Collateral is crypto you deposit to secure a loan; debt is what you borrowed, plus any interest accrued. Think of collateral as a deposit held against a loan: you cannot take all of it back while the loan remains unpaid. In lending protocols such as Aave, a withdrawal may be allowed only if the position remains within its risk limits.

First, check the debt balance and the collateral’s value on the source chain. Repay using the token you borrowed, allowing for interest since you borrowed it. Then check how much collateral is withdrawable. A receipt token may represent your supplied collateral, but withdrawing usually means redeeming that position through the lending protocol; moving the receipt token alone does not necessarily release the underlying asset.

Keep the remaining position above its liquidation threshold

A health factor summarizes how much collateral value backs your debt, adjusted for each asset’s liquidation threshold. Below 1, a position can be liquidated; a value just above 1 leaves little room for a price drop. Aave’s public FAQ explains this relationship. For example, if withdrawing half your collateral would leave a health factor of 1.05, I would repay more debt or withdraw less rather than rely on prices staying still.

Once the withdrawal is confirmed, ParaSwap can move the released asset across chains and swap it into a destination token in one flow. That matters because the token you withdraw may not be the one you want to hold on the destination chain. ParaSwap handles the cross-chain move and swap; the lending position still needs to be settled on its original chain first.

Budget for both chains and check the transfer

Allow for the cost of repaying and withdrawing on the source chain, the cross-chain transfer, and a transaction on the destination chain if you plan to use the funds there. The exact costs vary with network demand and the route. Keep a little of the source chain’s gas token for the lending transactions, and some destination-chain gas if you will spend or move the received asset.

Cross-chain transfers also take time: the source transaction must be confirmed, then the bridge route completes on the destination chain. Ethereum.org’s bridge explainer describes this as a transfer between separate networks, so check the destination address and asset before starting. Your next step is to identify the debt token, repay enough on the source chain, and withdraw only what the updated position can support.

4 Costs to Compare Before a Cross-Chain Swap

Merissa Stemler — Fri, 16 Oct 2026 08:48:34 +0000

A cross-chain swap costs four things: a transaction on the source network, a route or swap charge, price impact, and delivery on the destination network. Add them together to estimate what will arrive. The quoted exchange rate alone can hide costs paid on either chain.

1. Count the source transaction and any approval

The source transaction is the first cost: it pays the network to process your deposit or swap request. On Ethereum, this payment is called gas. It depends on how much work the transaction needs and how busy the network is.

Some tokens need a separate approval transaction before a service can use them. That means two source-network payments instead of one. On Arbitrum, a transaction can also include a charge for data posted to Ethereum, so a low layer 2 fee estimate may not tell the whole story.

Check which coin pays the source fee and whether your wallet already has enough. If you plan to send $500 worth of a token but have no ETH for an Ethereum transaction, the token balance alone cannot cover the fee.

2. Separate route charges from the exchange rate

A cross-chain route may involve a charge for moving funds, swapping them, or both. A swap can also include a pool fee: a charge paid when assets are exchanged through a liquidity pool, which holds tokens for traders. These costs may be taken from the input or the amount you receive.

Look for the estimated amount delivered, then compare it with the input after accounting for network costs. For a live comparison, you would use biswap.uk to check how much arrives after the route moves and exchanges the asset.

If you are weighing a route that moves and swaps assets in one flow, Biswap is a practical case to price from the amount delivered, rather than from the exchange rate alone. That keeps the route charge and any swap costs in the same comparison.

3. Estimate price impact on your trade size

Price impact is the way your own trade changes the exchange rate as it passes through a pool. A larger trade against a smaller pool usually has more impact. Slippage is the difference between the expected and final rate; it can grow if prices move before the swap completes.

For example, say a $500 trade has 0.4% price impact. That is about $2 less value before separate charges. A route showing a better rate for a tiny trade may give less for $500 if its available pool is shallow.

Biswap should be compared on the same input amount and destination asset as any other route. A quote for $50 cannot show how a $500 trade will affect the rate.

4. Include destination delivery in the total

The destination network may charge for the final transaction that delivers your asset. The route can subtract this cost from the output, so the receiving wallet may get less than the swap estimate. The destination fee can also change with network demand.

Say a route starts with $500, charges $1.20 on the source, $1.50 in route and pool charges, has 0.4% price impact, and costs $0.35 to deliver. The rough result is $494.95 before market movement: $500 minus $1.20, $1.50, $2, and $0.35.

Compare that estimated final value across routes. A route with cheaper source gas can still deliver less if its price impact or destination charge is higher.

Questions to check before you send

Why is the final amount lower than the quote?

The displayed amount may be an estimate before the destination transaction finishes. Network demand, a changing exchange rate, pool fees, and price impact can all affect the delivered amount. Check whether the quote includes both network fees and whether it shows an expected amount or a minimum amount you will receive.

Should I split a large swap into smaller trades?

Splitting can reduce price impact when a single trade is large compared with the pool. But every extra transaction may add network fees, and the rate can change between trades. Compare the estimated final amount for the full trade with the total expected output and fees for smaller trades.

Which balance should I keep for network fees?

Keep the native coin used for fees on the source network, and check whether the destination network needs a separate balance for later transactions. For example, ETH pays fees on Ethereum, while a token sent there does not automatically cover those fees. The fee coin depends on the network and the transaction.

How Do Mantle Bridge Payouts Handle Destination Reorgs?

Merissa Stemler — Fri, 16 Oct 2026 04:07:17 +0000

A destination-chain reorg can erase a bridge credit for several blocks; on Ethereum, finality usually takes around 13–15 minutes, so a receipt alone is not an irreversible payout signal. For treasury operations, treat source acceptance, destination inclusion and destination finality as separate states. A transfer can be valid on its source chain while its apparent credit is still reversible on the destination.

A destination receipt is provisional until its block is stable

A reorg replaces a chain’s recent canonical blocks, which can remove a transaction and its logs from the active history. The balance change then disappears from the recipient’s canonical state, even if an RPC endpoint previously returned a successful receipt. The source-chain transaction is not automatically undone: the bridge debit or message may remain valid while the destination execution needs to be reconciled.

This distinction matters in a how to move assets with Mantle bridge flow: a transfer can cross from one network to another, and the destination’s confirmation policy determines when treasury can safely book the proceeds. If Mantle is the destination, its sequencer can show a fast soft confirmation before the corresponding state is anchored and settled against Ethereum. Mantle’s SDK exposes a configurable depositConfirmationBlocks parameter for L1 deposits, a reminder that confirmation depth is a policy input, not a universal number.

On Ethereum, a block receipt is not the same as consensus finality. Slots are 12 seconds and epochs contain 32 slots; finality normally takes roughly two epochs, or about 13 minutes under normal participation. The Ethereum Foundation’s documentation describes finalized blocks as economically costly to reverse, not metaphysically impossible to change. For lower-value operational updates, a team may use a shorter confirmation threshold, but should label the resulting credit provisional.

Set the payout threshold by destination and exposure

Use the destination chain’s own finality signal where available; otherwise define a confirmation depth, N, that matches the chain’s block cadence, reorg history and loss tolerance. A rule such as “wait 12 blocks” has no consistent meaning across networks: on a 2-second chain it is about 24 seconds, while on a 12-second chain it is about 144 seconds. Treat a block-count threshold as a risk limit, not a proof that a reorg cannot happen.

For example, imagine a business bridges 50,000 USDC to fund a same-day supplier payout. Its destination monitor sees a successful receipt at block 20,000, then that block is orphaned before the payout ledger is finalized. If the business already sent the supplier payment, it has an unreconciled exposure; if it waited for its chosen finality threshold, it can keep the bridge credit pending and avoid paying against a vanished balance.

Choose the threshold based on the amount at risk and the cost of waiting. A practical treasury policy can release small routine transfers after a conservative confirmation depth, while requiring finalized status or manual review for larger payouts. On Ethereum, waiting for finalized typically costs about 13–15 minutes; waiting only for safe is faster but remains exposed to a significant L1 reorg. If the destination is an L2, check whether its RPC distinguishes unsafe, safe and finalized; a sequencer’s immediate inclusion response is not equivalent to parent-chain finality.

Reconcile by transaction identity before retrying

When a destination receipt disappears, first check whether the transaction remains in the canonical chain, is pending, or was dropped. Query a second independent RPC, inspect the current block hash and receipt, and compare the bridge message or transfer identifier with the source event. A transaction that was reorged may be re-included without a new source transfer; submitting another bridge transfer immediately can therefore create a duplicate credit.

If the destination execution is genuinely absent, the next action depends on the route’s design. A relayer may rebroadcast an eligible destination transaction, while a user-submitted transaction may need a replacement using the same account nonce and a suitable fee; neither behavior is guaranteed across services. Keep the source event and message ID as the idempotency key, and reconcile balances and logs before initiating a fresh transfer. When using a Mantle bridge, record destination inclusion separately from source completion so a reorg does not cause an automated payout or retry to run twice.

Track source acceptance, destination inclusion and destination finality as separate states.
Set a chain-specific threshold against the value and timing of each payout.
After a reorg, verify the canonical receipt and reconcile by message ID before retrying.

Choosing a Solana Asset After Bridging BTC

Merissa Stemler — Thu, 15 Oct 2026 23:02:21 +0000

If you are moving BTC to Solana, choose the destination asset by deciding whether you want to keep Bitcoin exposure or leave with an asset you can use on Solana. The route may deliver a token representing BTC, or it may swap into a different token as part of the transfer. Check what the route is set to deliver before sending; the two outcomes are not interchangeable.

Manta bridge is relevant when you want to move assets across chains, and a cross-chain service can combine a bridge and swap in one flow. If you want a Solana token instead of a BTC representation, Manta bridge swaps can be useful when the service offers a route for that source and destination. Decide on the asset first, then check that the proposed destination matches your goal.

Choose between BTC exposure and a Solana asset

A BTC-representing token is designed to track Bitcoin’s value while being usable on Solana; a different destination token gives you that asset’s exposure instead. For example, if you want to hold a BTC-linked balance in a Solana wallet, choose a route that delivers a BTC representation. If you want an asset to use in a Solana app, choose the specific asset that app accepts.

The trade-off is what you own after the transfer. A BTC representation may suit you if keeping BTC exposure matters, but its use depends on the token being accepted where you plan to use it. Swapping to another token may make that next step possible, but your balance will then follow that token’s price rather than BTC’s.

Check exactly what the route will deliver

Read the destination asset name and, when available, its mint address—the unique identifier for a token on Solana. A ticker or familiar-looking name alone is not enough to identify a token: different tokens can use similar labels, and an app may accept only one particular mint. Compare the destination asset with the one shown by the wallet or app where you intend to use it.

Also check whether the route includes a swap. A bridge-only route aims to deliver a representation of the source asset on the destination chain. A bridge-and-swap route also exchanges that value for another asset, so the amount delivered depends on the swap rate and any price movement while the route completes. Manta bridge swaps are worth considering when that combined outcome is the one you actually want.

Source: BTC on the Bitcoin network.
Destination: Solana.
Asset received: the exact token name and mint address, if shown.
Swap: whether the route keeps BTC exposure or exchanges it for another asset.

Understand what happens during the transfer

A cross-chain transfer has to coordinate activity on two separate networks. The Bitcoin transaction first needs to be observed and confirmed; a bridge mechanism then arranges the corresponding value on Solana. Depending on the route, this can involve a BTC-representing token being issued or released, or a swap that delivers a different Solana asset. The bridge and the swap are related steps, but they are not the same operation.

This distinction explains why the destination balance may not resemble the BTC amount you sent. A BTC-representing token can differ slightly in quoted value, while a swapped destination asset can change in value during execution. Network fees and swap costs also affect the final amount; their size depends on network conditions and the route. Review the quoted destination and any stated minimum before authorizing the transfer.

Verify the result before using it

After the route completes, check the destination transaction and confirm that the expected token arrived in your Solana wallet. Match the mint address to the asset you intended to receive, then check that your target app recognizes that same token. A balance with a similar ticker is not enough if the mint differs.

If the transfer is still processing, check the source transaction first: a pending or unconfirmed Bitcoin transaction can hold up the rest of the route. If the source transaction is confirmed but the destination balance is missing, use the route’s transaction reference and the destination transaction record to see where it stands before trying again. Sending a second transfer can create a second independent transaction.

For an occasional transfer, write down the exact destination asset and mint before you start, especially if you plan to use the token in an app afterward. That quick check helps catch the most consequential mistake: completing the bridge successfully but receiving an asset that does not fit your next step.