DEV Community: Jerome Barton

Why Has My CoW Swap Limit Order Not Filled Yet?

Jerome Barton — Thu, 22 Oct 2026 12:54:59 +0000

A limit order can stay open after spot touches your price. It needs a trade that meets your limit and covers the cost of settling the order, so the displayed market price alone does not guarantee a fill.

Your limit is a minimum or maximum, not a trigger

A limit order sets the worst price you will accept: a maximum for a buy, or a minimum for a sale. It does not promise to trade the moment a price chart reaches that level.

For example, say you set a sell order for 10 tokens at a minimum of $100 each. A market price of $100 may still be too low if executing the order would cost more than the price improvement available. The order waits until the trade can meet your limit and cover settlement costs.

The cowswap interface shows an “Executes at” price alongside your limit, helping you see the price the order currently needs. That estimate changes with network fees, order size, and market price, so check it when you need to judge how close a trade is.

Settlement costs can keep a touched order waiting

A cowswap limit order is signed in your wallet and submitted without an on-chain transaction to place it. CoW Protocol says it charges no fee for placing the order; instead, execution waits for a better price that can cover network fees.

This creates a practical trade-off: a small order may need a larger price move than a large order, because the settlement cost is spread over fewer tokens. Fees also change with network conditions. The order review and “Executes at” display are more useful than assuming one fixed percentage will always apply.

Spot prices can differ across markets, and a brief price touch may not last long enough for a solver to include your order in a settlement. Solvers are the services that find and submit trades for execution. If the price moves back before a suitable settlement is found, the order can remain open.

Partial fills can leave a small remainder

Limit orders are partially fillable by default, so some of your order can trade while the rest stays open. This helps a larger order fill as liquidity becomes available, rather than requiring the whole amount to trade at once.

For example, if buyers can take 7 of your 10 tokens at an acceptable price, those 7 may settle while 3 remain. A very small remainder may not fill if its value is too low to cover settlement costs. Check the open order’s remaining amount before placing another order, or you could sell more than intended.

You can turn partial fills off in the swap panel settings if you want the order to fill entirely or not at all. That can simplify tracking, but it may make the order less likely to complete.

Use the order panel to decide what to do next

Check “Executes at” first, then compare it with the current price and your own deadline. If the required price is still acceptable, leave the order open and check its expiry; if it is no longer acceptable, request cancellation before placing a replacement.

Off-chain cancellation is free, but it is not immediate: the order could settle before the cancellation is processed. An on-chain cancellation costs gas and can still lose a race against a settlement, so review the order status before acting again.

Keep the order if its execution price and expiry still fit your plan; cancel and reset it if either has changed.

What Is Stablecoin Redemption Access and How Does It Work?

Jerome Barton — Thu, 22 Oct 2026 03:15:59 +0000

One token contract can decide whether a stablecoin holder can ask its issuer for dollars directly or must first rely on a bridge, exchange, or other intermediary. For an integrator, the distinction affects which assets to accept, how to describe redemption, and what recovery path a user has if a route or market stalls.

What Does Issuer Redemption Access Mean?

Issuer redemption access means the token is issued on that network by the stablecoin issuer, which offers eligible customers a way to redeem it under its account and compliance rules. It does not mean every wallet holder can send tokens to the issuer and receive cash instantly; retail users may need an exchange or other service, and business access may require approval.

A bridged representation has a different claim path. A bridge locks or otherwise secures tokens on one network and creates corresponding tokens on another, or uses a bridge-specific mechanism to move value; the issuer generally does not issue the destination token just because it has the same ticker or tracks the same dollar.

This is the distinction to preserve when a user chooses a route through bungee bridge: a cross-chain route can deliver a familiar stablecoin symbol while the destination contract has a different issuer and redemption path. The route answers how tokens move; it does not, by itself, establish who will redeem the destination asset.

How Can You Tell Native and Bridged Tokens Apart?

Identify the token by chain and contract address, then verify that exact contract against the issuer’s current supported-network and redemption information. Symbols are not unique identifiers, and a token named USDC on Polygon may be native USDC or a bridged version such as USDC.e; the same caution applies on Optimism.

For each asset your application accepts, record these fields in its token configuration:

Network and chain ID.
Token contract address and decimals.
Issuer or bridge responsible for the asset on that network.
Issuer-supported mint and redemption route, including eligibility conditions.
Bridge or conversion route required to reach an issuer-supported token.

Check issuer documentation when adding a chain or changing a token mapping. Circle, for example, distinguishes native USDC from bridged USDC.e on Polygon and says Circle Mint supports native USDC there; on OP Mainnet, it likewise lists native USDC separately from an unsupported bridged version. That support can change, so treat it as configuration data to revalidate, not a permanent property of the ticker.

What Does Redemption Mean for a Cross-Chain Route?

A route aggregator selects available bridge and swap steps to reach a destination token, while issuer redemption is a separate downstream process. A typical path might move a bridged stablecoin on Polygon through a bridge, swap it for native USDC on Optimism, and leave the user holding a token that the issuer supports on that chain; each step has its own execution, liquidity, and eligibility conditions.

When you integrate a route, compare the precise destination contract against your accepted-asset list and tell the user what they will receive. Bungee Link can preselect source and destination chains and tokens, but preselection is not a guarantee that a particular stablecoin representation is issuer-redeemable. The token address in the route and the redemption policy in your application must agree.

How Should You Price the Difference and Handle Exceptions?

Calculate both the route result and the redemption route before treating two representations as interchangeable. For a quick check, say a user sends $10,000 of a bridged token that trades 0.4% below one dollar: its market value is about $9,960 before any bridge or swap costs. A route quote returning $9,970 of native stablecoin improves the executable exit by about $10 versus that market mark, but does not make the input token directly redeemable.

That distinction matters during stress. If the bridge is paused, the underlying chain is congested, or the bridged token loses its peg, the conversion path may be delayed or cost more than the quote suggested. If an issuer stops supporting deposits of a legacy bridged contract, sending that contract to an issuer account may fail or become unrecoverable even if a wallet still displays the familiar symbol.

Keep a status per chain and contract, not per symbol: issuer redemption available, conversion needed, or redemption unsupported. Before enabling deposits or withdrawals, test the exact contract and amount against the current issuer terms and route quote; recheck after network upgrades, bridge migrations, or issuer notices. That gives support teams a specific recovery instruction instead of a generic promise that “the stablecoin is redeemable.”

Choose native issuer-issued tokens when direct issuer support is a product requirement; accept bridged representations only when you can name and maintain the conversion path users will need.

Blackhole Swap Explained: Market, Limit, and TWAP Orders

Jerome Barton — Wed, 21 Oct 2026 06:45:56 +0000

Blackhole Swap is the token-swapping service on Blackhole, an Avalanche C-Chain decentralized exchange with several liquidity-pool designs and order types. The choice that matters most is whether you need execution now, a minimum acceptable price, or smaller trades spread over time. Pool depth and the quoted output then determine which route makes sense for the amount you want to trade.

What are the main Blackhole Swap choices?

The main choices are a market swap, a dLIMIT order, and a dTWAP order. They can draw on the exchange’s pool liquidity, but they differ in when a trade executes and which conditions you control.

For a Blackhole DEX swap, set Core wallet or MetaMask to Avalanche C-Chain and keep some AVAX for gas. Open blackholeswap.app, connect the wallet, and select the input and output tokens by contract address if either ticker is ambiguous. Enter the amount before choosing an order type; the displayed output is the useful starting point for comparing them.

Market swap — best for execution now. The transaction trades against available liquidity when it lands on-chain, subject to your minimum output. It does not fit when the current quote is poor or a large order would move the pool price sharply.
dLIMIT — best when price matters more than timing. Set the input, output, and limit price; execution requires an available price at least as good as your limit. It does not fit an urgent trade: reaching the displayed market price does not guarantee that enough liquidity is available to fill the order.
dTWAP — best for spreading a sizeable trade over time. Choose the number of portions and the interval between them, with a market or limit condition for the portions. It does not fit when you need the whole position immediately, and later portions can face a different market price.

A dTWAP limit condition adds a useful constraint: portions wait for an acceptable price, so the order may remain partly unfilled. A market dTWAP prioritizes the schedule instead. Neither schedule guarantees a better average price than one market swap; its potential advantage is giving liquidity time to recover between portions.

How do the pool types change a quote?

The Blackhole Avalanche exchange has classic constant-product, stable, and concentrated-liquidity AMMs. A route may use one pool or pass through an intermediate token, so the relevant comparison is the final output for your size, after every hop’s fee. Avalanche Builder Hub describes the exchange’s swap routing as optimized, but the quote still depends on liquidity available when the transaction executes.

A classic volatile pool follows the constant-product curve, roughly x × y = k. If its USDC side holds 100,000 USDC, an illustrative 10,000 USDC input moves far along that curve: before fees, it buys about 9.09% less of the other token than the starting spot price suggests. That is price impact built into the quote, not a later change covered by slippage tolerance.

A stable pool uses a flatter curve near the expected peg, making it suited to correlated assets such as two dollar stablecoins. Its advantage shrinks as balances become uneven or a token loses its peg. A concentrated-liquidity pool instead places depth within price ranges; it can quote tightly near the current price, then worsen abruptly if your trade crosses a thin tick range.

That last edge case makes total pool value a weak shortcut for large trades. A pool can show substantial liquidity while little of it sits along your trade’s path. Genesis Pools serve a different purpose: they assemble launch liquidity before ordinary trading begins, so contributing to one is not an alternative market-swap route.

What do fees and slippage actually tell you?

A Blackhole Swap quote reflects pool fees and the price impact of the proposed trade. Pool fees vary by market and route; across active pool types, a useful order-of-magnitude range is roughly 0.01% to several tenths of a percent per hop, with some pools higher. Check the fee shown for the selected route rather than applying one exchange-wide rate, and add Avalanche gas paid in AVAX.

Slippage tolerance protects against deterioration after the quote is formed. Set it against the quoted output, not against an external spot price: a 0.5% tolerance on a quote of 501.2 tokens gives a minimum of 498.694 tokens. Around 0.1%–0.5% may be workable for a liquid, quiet pair; thin or fast-moving pairs can require more, but raising tolerance also permits a worse fill.

Compare routes by net output and by how that output changes with order size. For example, if a 10,000 USDC trade quotes 500 AVAX directly and 501.2 AVAX through an intermediate token, the second route is better at that moment even if it has two fee-paying hops. If doubling the trade size produces a much worse rate, available depth is probably the deciding cost; splitting the order may be worth evaluating.

DefiLlama’s Blackhole pool accounting also separates fees paid by traders from rewards received by liquidity providers and veBLACK voters. That distinction matters when reading a pool page: a high displayed reward rate does not imply a low swap fee or deep execution liquidity.

How do you place and verify the trade?

Start with the desired output token’s contract and a trade size, then compare the market quote with any limit price or TWAP schedule you are willing to accept. On a normal market run, review the route, fee, price impact, minimum received, and gas estimate before signing. For an ERC-20 input, a first trade may require an approval transaction before the swap transaction.

Suppose you plan to exchange 10,000 USDC for AVAX and see the 501.2 AVAX route above. With 0.5% tolerance, confirm that 498.694 AVAX is an acceptable floor, then approve only the intended spending amount if approval is needed. Submit the swap, wait for C-Chain confirmation, and check the wallet’s actual AVAX balance or transaction receipt rather than treating the earlier quote as the fill.

For a dLIMIT order, check which token the limit price is denominated in before submitting; reversing a pair reverses the number you expect to see. For dTWAP, review portion count, interval, and any per-portion limit, then monitor order history for partial execution. A Blackhole token swap placed as an advanced order can remain open after your wallet confirms the placement transaction.

Why might the chosen order fail or remain open?

A market swap can revert if the available output falls below your minimum before execution, or if the approval, balance, or gas is insufficient. Refreshing the quote and reducing the trade size can reveal whether depth caused the problem. Repeatedly widening slippage without checking price impact can turn a failed trade into an expensive fill.

A limit order can remain open because its price is unavailable, available liquidity is insufficient, or execution costs make a fill impractical. A TWAP order can finish only partly if later portions fail its limit or the scheduled period ends. Check the order’s current status and any remaining input before placing another order, so the combined amount does not exceed what you meant to trade.

What do traders ask next?

Does a low pool fee mean the cheapest swap?

No. A lower fee can be outweighed by weaker depth, an extra hop, or a concentrated pool running out of active liquidity along your trade. Compare the final output for the same input amount and inspect price impact. The route with the smallest fee percentage need not deliver the most tokens.

Should I use a market swap or a TWAP for a large order?

Compare a full-size market quote with quotes for smaller portions first. If splitting materially improves the rate, a TWAP gives the pool time to replenish between trades, but exposes later portions to market movement and possible non-execution. If the full-size quote is already close to the smaller quotes and timing matters, the market order may meet your criteria.

How to Buy a Basename With a Relay Bridge

Jerome Barton — Tue, 20 Oct 2026 14:32:54 +0000

If your ETH is on another chain, use a relay bridge to move enough to Base, then register the available Basename from the Base names app. Treat the bridge and the registration as two separate transactions: the bridge funds your Base wallet, while the registrar checks availability and mints the name.

Check the name and registration cost on Base

Basenames are ENS-based names ending in .base.eth, registered on Base; they are not ordinary DNS domains. Search the exact label in the Base names app and check the displayed price and term before bridging, since a name that is available now can be claimed while your transfer is in flight.

Base’s Basenames FAQ lists annual fees by label length: 3 characters, 0.1 ETH; 4 characters, 0.01 ETH; 5–9 characters, 0.001 ETH; and 10 or more, 0.0001 ETH. Discounts may apply to eligible wallets, so use the registrar’s live quote rather than assuming the list price is your final cost.

Bridge ETH to the wallet and network that will own the name

For example, if you hold ETH on Ethereum mainnet and want northstar.base.eth, select Ethereum as the source, Base as the destination, and ETH as the asset. A relay bridge submits the source transfer, waits for the route’s required source confirmation or finality, then has a relayer deliver the destination-side transfer; compare the quoted output and deadline because the route fee, confirmation threshold, and relayer model differ.

Check the relay bridge security model before signing, since the route’s verification and recovery assumptions determine what happens if the relayer stalls or the destination call fails. Send to the same wallet that will register and own the name, and leave a Base ETH balance above the name quote for transaction gas; receiving the registration price exactly can leave the purchase unexecutable.

Register only after the destination funds arrive

Confirm the destination balance. Wait until the bridge marks the transfer complete and your wallet shows ETH on Base. A submitted source transaction is not proof that the destination funds are spendable; if the route is pending, use its status and transaction references rather than submitting another transfer.
Recheck the exact label and price. Search again in the Base names app immediately before registration. The transfer cannot reserve a label, and a name taken during transit requires you to choose another name rather than retry the same purchase.
Set the intended owner and term. Connect the wallet that should hold the name, choose the registration duration, and inspect any resolver or primary-name options. ENS registration contracts distinguish token ownership from resolver records, so confirm the owner address and the address record shown in the transaction before signing.
Submit the registrar transaction on Base. Check that the wallet prompt shows Base, the registrar as recipient, the expected ETH value, and a reasonable gas limit. After confirmation, verify the name’s owner and expiry in the app; set or verify its address record before using the name to receive funds.

Handle delays and failed destination calls

Ethereum-to-Base relayer routes commonly quote a wait of minutes, but source congestion, finality policy, and liquidity can extend it; the quote is route-specific, not a guarantee. A completed source transfer with no destination credit usually means the relay is still processing or needs a retry, while a reverted registration leaves the name unregistered and may still consume Base gas.

Base’s Basenames FAQ gives the fee tiers, while the OP Stack specifications describe the chain’s deposit and message mechanics. For this purchase, the practical trade-off is route convenience against reliance on that route’s relayer and verification system: use a quote that delivers ETH to Base, then make the registrar’s onchain availability check the final gate.

How to move stablecoins from a rollup to Ethereum mainnet

Jerome Barton — Sat, 17 Oct 2026 07:48:18 +0000

If you need stablecoins on Ethereum mainnet for a payment or app, bridge them from the rollup where they sit. A rollup is a separate network that groups transactions and posts data to Ethereum, often at lower cost.

What does “settle on mainnet” mean?

It means having the stablecoins available on Ethereum itself, rather than on the rollup. Mainnet is Ethereum’s base network; an app on mainnet generally cannot spend tokens that are still on a rollup.

First check which token the recipient needs. Stablecoins can share a name or symbol while having different contract addresses, which are the token’s on-chain identifiers. Ask for the exact token and network if you are unsure.

For example, if a bill requires 500 units of a stablecoin on Ethereum, having 500 on a rollup is not enough. A bridge must move the value to Ethereum, and the destination token must be one the recipient accepts. Manta bridge can help move or swap assets across networks in one flow, so it may suit this task when your token and route are available.

Which route fits your deadline?

The native route uses the rollup’s own bridge to send tokens back to Ethereum. It usually costs less in extra service fees, but timing depends on the rollup. For optimistic rollups, Ethereum.org describes a challenge period of roughly seven days: the wait gives people time to dispute an invalid batch.

A faster route uses a liquidity provider: a service pays you on Ethereum before the native withdrawal finishes, then claims the delayed withdrawal later. That convenience can cost more, and availability depends on the token and route. A validity-proof rollup uses cryptographic proof to show its transactions are valid, so its withdrawal timing follows proof and finalisation steps instead of the same seven-day challenge window.

The deciding question is when the recipient needs the funds. If a week is acceptable, the native route may suit you. If you need them sooner, compare a fast bridge quote with the amount and arrival time your payment requires.

How do you make and check the transfer?

Use this order so you know what should arrive before you send:

Confirm the destination. Ask whether the recipient needs Ethereum mainnet and which stablecoin contract they accept. Copy the address carefully; a transaction sent to the wrong address may be hard or impossible to recover.
Choose the route. Use the native bridge if its wait fits your deadline. Otherwise, compare a cross-chain bridge quote for the same source token and destination network. Manta bridge is one service that can move or swap assets across networks in a single flow.
Check the received amount. Say you need 500 stablecoins and the quote estimates 506 arriving from a 510 transfer. The 4-unit difference is an example, not a promised fee; compare the actual quote, timing, and token identity before proceeding. Network fees can change with activity, and the Ethereum transaction needs ETH for gas, the fee paid to process it.
Send and verify. Approve the transfer in your wallet and wait for the source transaction to confirm. Then check the destination transaction on an Ethereum block explorer such as Etherscan, and make sure the recipient’s address received the expected token. A source confirmation alone does not prove the destination transfer completed.

I would use the native route when the deadline allows it, because it avoids paying for speed. If the payment is due sooner, I would choose a faster route only after checking the destination token and the amount that will arrive.

How to Verify a Crypto Service Status Page Before Retrying

Jerome Barton — Fri, 16 Oct 2026 20:28:20 +0000

If a quickswap transfer is pending or failed, verify the service’s official status and check your transaction on the relevant blockchains before retrying; a green status page alone does not prove your transfer is complete. First identify which stage is waiting, then match that stage to a current incident.

Find the official status page and check its time, scope, and latest update.
Use transaction hashes to distinguish a slow transfer from a failed one.
Retry only when the first attempt’s outcome is clear.

Check that the status page is official and current

Open the status page from a source you already trust, such as the service’s saved bookmark or its verified site, rather than following a link in an unsolicited message. Check the page’s domain carefully: a convincing imitation can be used to steer users toward malicious sites.

Read the incident timeline, not just the overall label. Note the update time and timezone, which components are affected, and whether the incident is marked investigating, monitoring, or resolved. “Monitoring” usually means a fix is in place and being watched; it is different from a confirmed resolution. A page with no current incident is useful evidence, but it cannot rule out an unreported problem.

Look for a match to the part of the service your transfer needs. A cross-chain swap may depend on the sending network, a bridge or relay, and the receiving network, so a listed issue affecting only one component may explain a delay while the rest appears operational.

Match the incident to your transfer’s stage

A cross-chain transfer has more than one meaningful status. The source transaction can be submitted, included in a block, and later considered final; a bridge or relay may then process the message before the destination transaction appears. A successful source transaction therefore does not by itself prove that the destination asset has arrived.

Compare the incident’s start and update times with your own transaction timestamps. Say your source transaction was included at 14:04 UTC, an incident affecting relaying began at 14:06, and it is now 14:18. That is 14 minutes between source inclusion and your check, with the relay incident starting two minutes after inclusion; it makes a downstream delay plausible, but it does not establish the transfer’s outcome.

On each relevant chain, search the transaction hash in a reputable block explorer and confirm that it belongs to your wallet and intended transfer. Ethereum.org explains that an included transaction can still move through later stages toward finality, while a block explorer reports whether a transaction is pending, successful, or failed. If the source shows success but there is no destination transaction, keep treating the transfer as in progress until the bridge’s own status or destination chain provides evidence of completion.

Use status evidence to decide whether to wait

Keep the original transaction hash and compare the service update with the on-chain record. If the official page reports an incident affecting the stage your transfer has reached, and the source transaction succeeded, waiting for another update is usually safer than creating a second transfer. The service status describes a broader issue; the hash tells you what happened to your particular transaction.

For example, if the source explorer shows “pending,” the transaction has not yet been included in a block. If it shows “failed,” inspect the transaction result before doing anything else: the source action did not complete, though a network fee may still have been charged. If it shows success and the receiving asset is absent, check whether the bridge is still processing the message and whether a destination transaction has appeared.

When the transfer is between chains, your quickswap status check is most useful when it narrows down which leg could be delayed; the quickswap swap service is a way to move and swap assets across blockchains in one flow. Keep the transaction hash handy so you can compare the service’s reported stage with the source and destination records.

Retry only after the first attempt has a known outcome

Do not treat a slow page, a missing destination transaction, or a “resolved” incident as proof that the first attempt failed. Check the source transaction first, then look for any destination transaction or service record tied to it; a successful source leg may still be awaiting downstream processing after the status page turns green.

If the first source transaction is confirmed as failed, check whether the service reports the attempt as failed or eligible to retry before submitting again. If it remains pending, a second attempt can create a separate transaction and may lead to duplicate activity if the first one later completes. The status history described by Atlassian Statuspage can help explain an incident’s progression, but the chain records decide what happened to a specific transaction.

How long do wallet nonce queues delay token approvals?

Jerome Barton — Fri, 16 Oct 2026 14:00:56 +0000

A nonce queue delays an approval until earlier transactions from the same account clear. For a treasury, the wait can be seconds or indefinite: the decisive factor is the oldest unresolved nonce on that chain, not the approval’s own gas estimate.

Why can an approval be stuck behind another transaction?

An EOA’s nonce is a sequential counter for transactions on one chain. A node can include nonce 42 only after nonce 41 has been included, so a slow payout, underpriced swap, or failed-to-propagate transaction can hold up every later transaction from that address on that chain. Ethereum’s transaction documentation describes the nonce as the account’s sequential transaction counter.

An ERC-20 approval is an on-chain transaction calling approve(spender, amount); it changes the token’s allowance when executed. If a treasury signs a payout at nonce 41 and an approval at nonce 42, the approval cannot execute first even if it offers a higher fee. For a cross-chain payment or treasury rebalance, a thor swap service handles the asset move and swap across chains in one flow, but any required EVM approval still waits on the source account’s nonce queue.

The queue is local to the account and chain. A pending Ethereum transaction does not block the same address on an L2, and a Bitcoin transfer has no EVM nonce queue. Teams using thor swap should therefore check the source-chain account’s pending transactions before diagnosing a cross-chain route as slow.

How long does the queue take, and what can you do?

There is no fixed delay. If the head transaction is adequately priced and the network is processing it, the approval may follow after one inclusion interval; if the head transaction is underpriced, dropped by a node, or repeatedly replaced incorrectly, later nonces can remain blocked for minutes or much longer.

For example, suppose nonce 41 is a payout sent with a max fee below current base fee, while nonce 42 is a token approval with a competitive fee. Before: the approval sits queued because 41 is not executable. After: the operator replaces 41 using the same nonce and a fee high enough for current conditions, or cancels it with a same-nonce self-transfer; once 41 is included, 42 becomes eligible. A cancellation is not guaranteed until the replacement is mined.

Replacement rules are client and network dependent. Geth’s transaction-pool documentation describes replacing a transaction with the same sender and nonce at a higher gas price; under EIP-1559, wallets may need to raise both max fee per gas and priority fee to satisfy node policy. Check the nonce and fee fields against the chain’s current base fee, and avoid signing additional transactions from the same account until you know which nonce is next.

If the approval itself reverts, it still consumes its nonce once included; inspect the receipt and allowance before resubmitting. ERC-20’s EIP-20 specification says a new approval overwrites the spender’s existing allowance, and some tokens require setting allowance to zero before changing it. A failed approval can therefore mean a token-specific allowance rule, not a queue delay.

How should a treasury prevent approval delays?

Separate operational flows by signer where policy permits, and reserve a small number of addresses for predictable payout batches. Before a recurring cross-chain transfer, reconcile each EVM address’s confirmed and pending nonce with a trusted RPC, verify native-token gas balance, and confirm whether the exact spender already has sufficient allowance. Reuse of a dedicated signer improves nonce hygiene but concentrates key and balance risk.

For frequent transfers, use the narrowest practical allowance and plan for a separate approval transaction when the token does not support signed approvals. Permit-style approvals can avoid the standalone on-chain approval when both token and application support them, but support is not universal. I would favor a dedicated signer and explicit pending-nonce monitoring over blanket unlimited approvals: it makes blocked work easier to isolate while limiting the allowance at risk.

Does a pending approval block transactions on other chains?

No. EVM account nonces are tracked independently on each chain, so an Ethereum queue does not block that address’s transactions on Arbitrum or BNB Smart Chain. The same key may be used on multiple chains, but each chain has its own account state and pending transaction pool. Check the chain where the approval was submitted.

Can I speed up an approval by sending it again?

Only if the replacement uses the same sender and nonce and satisfies that network’s replacement fee policy. Resending with a higher nonce adds another queued transaction; it does not bypass the earlier one. Wallet labels such as “speed up” usually attempt a same-nonce replacement, but confirm the nonce before signing.

Does a reverted approval leave the nonce available?

No. Once a transaction is included, its nonce is consumed even if execution reverts. The allowance may remain unchanged, so inspect the transaction receipt and token allowance before retrying. A retry must use the next valid nonce and may need different calldata or allowance handling if the token enforces a zero-first change.

What should I do first when a cross-chain transfer is waiting?

Find the oldest pending transaction from the source address on the source chain, then check its nonce, receipt status, and fee against current conditions. I would resolve that head transaction before changing the approval or starting another transfer, because later transactions cannot execute around it.

After You Send Crypto Across Chains: What Happens Next

Jerome Barton — Fri, 16 Oct 2026 08:56:29 +0000

A cross-chain transfer takes two network transactions and a bridge message to move your assets. The first transaction commits your funds on the source network; a bridge then arranges for the corresponding assets to reach your destination address.

See how bridges account for assets on both networks.
Learn why a confirmed send may still be in progress.
Know what to check before sending and what to do if arrival is delayed.

What does a bridge do with your assets?

A bridge coordinates a transfer between networks that keep separate records of balances. Your wallet address may look the same on both networks, but a balance on Ethereum does not automatically exist on Mantle; the bridge has to arrange a matching result on the destination network.

One common design locks your tokens in a contract on the source network and releases or creates a corresponding representation on the destination. Another burns tokens on the source and mints them on the destination. A liquidity-based route can instead pay you from funds already available on the destination, while settling the source side separately.

These designs explain why the asset name alone is not enough. A token with the same ticker on two networks may be represented by different contracts, so check that the destination asset is the one accepted by the app where you plan to use it.

Why can a confirmed send take longer to arrive?

A source transaction confirmation means the source network recorded your instruction; it does not prove that the destination network has completed its part. The bridge must observe the source transaction, establish that it is valid under its security rules, and then submit or enable the corresponding destination action.

That middle step can involve waiting for network finality, which is the point at which a transaction is treated as settled enough to act on. Some routes use an intermediary, often called a relayer, to pass the message or provide destination liquidity. Network congestion, security checks, and the route design all affect the wait, so there is no single arrival time that applies to every transfer.

For example, if you send USDC from Ethereum to Mantle, your wallet may show the Ethereum transaction as confirmed while the Mantle balance is still pending. Check the transaction on both networks and look for a completed destination transfer; do not send a second transfer just because the first one has not appeared yet.

What happens if you bridge and swap in one flow?

A bridge-and-swap route combines getting value onto the destination network with exchanging it for a different asset there. The route may execute a swap before the bridge, after it, or through a liquidity provider that pays out the requested destination asset; the exact sequence depends on the service and route.

Suppose you want an asset on Mantle but hold ETH on Ethereum. A route may use your ETH to obtain an asset that can cross, deliver value on Mantle, then swap it into the asset you requested. Each conversion can affect the amount received through exchange rates, price movement, and swap fees, in addition to the network costs for the transactions involved.

If you want to compare this kind of route, a Mantle bridge service can move and swap crypto across networks in a single flow, so you can consider the destination asset as part of the transfer rather than plan a separate swap yourself. Check which asset you will receive and on which network before you approve the source transaction.

What should you check before sending, and if it is delayed?

Before sending, confirm the source network, destination network, asset, and receiving address. Make sure you can pay the source network’s gas fee, the transaction cost paid to process an action, and leave enough destination gas if you will need to move or swap the received asset afterward.

When choosing a Mantle bridge route, compare the expected destination amount and the asset you will receive, not only the quoted speed. The route may include a bridge fee, network fees, or swap costs, and the displayed estimate can change before execution if prices or liquidity move.

If the source transaction is confirmed but the destination transfer is pending, use the transaction record and route status to identify which stage has stopped. Recovery options differ: some routes complete automatically after a delay, while others may require a claim or support from that route’s operator. Never share your recovery phrase or approve an unrelated transaction to “release” funds.

Before you act, ask yourself: do I understand what asset will arrive, on which network, and what I will need to do with it next?

From exchange to wallet: how to check a bridge quote

Jerome Barton — Fri, 16 Oct 2026 04:40:03 +0000

If you are moving crypto from an exchange into your own wallet, check the amount that should arrive and what you must approve before you sign. A bridge quote is an estimate of a route that moves value between chains and may swap it into a different token along the way.

For example, a service such as ParaSwap cross-chain swap combines the bridge leg and destination swap, so compare the final token amount across the whole route rather than judging a bridge in isolation. The quote helps you decide if that result suits your needs; it does not guarantee the market price will stay fixed until execution.

What does a bridge quote tell me?

A quote should identify the asset you send, the destination chain and token, and the estimated amount you receive. It may also show route costs separately, such as the source-chain transaction gas, a bridge charge, and destination-chain gas. Gas is the fee for processing a transaction on a chain; Ethereum.org explains that smart-contract transactions require gas.

Compare the expected destination amount after costs, not just the exchange rate or the amount sent. Say a route starts with $500 worth of an asset and estimates $492 worth of the destination token. That $8 difference is illustrative: it could reflect swap pricing, bridge costs, or gas, and the quote should help you see which costs are included.

Check the token’s network and identity as well as its ticker. A token name like “USDC” alone is not enough to establish that you are receiving the version you intended on the destination chain. If your wallet does not show it after arrival, the token may need to be added using its verified contract address for that chain.

Which numbers should I compare before signing?

Compare the estimated receive amount, the costs deducted from it, and the slippage setting. Slippage is the permitted movement in price between quoting and execution. A tighter tolerance can make a trade fail if the market moves; a looser one can let the trade complete at a worse price. Price impact is different: it is the effect the trade itself has on the available market price.

Look at the route too. A route with multiple swaps or transfers can involve more steps that must complete, while a simpler route may return less. ParaSwap is one example of a service that lets a reader move assets across chains and swap into a destination asset in one flow; the useful comparison is the final result and the route costs, not the number of hops by itself.

A common mistake is to see a familiar ticker and approve without checking the destination network or receive amount. Fix that by matching the destination token and chain to your plan, then decide whether the displayed minimum receive amount is acceptable. If you need at least a specific amount, do not sign a quote whose minimum falls below it.

What am I approving in my wallet?

Read each wallet prompt as a separate action. An ERC-20 approval gives a spender permission to use up to an allowance of your token; the Ethereum ERC-20 standard defines this allowance mechanism. Check that the token and spender match the action you intend, and be cautious if the approval amount is broader than the amount you plan to swap.

After any approval transaction confirms, the swap or bridge transaction may still need its own signature. Keep enough of the source chain’s native token for gas unless the transaction clearly shows another arrangement. If you reject a prompt or the quote changes materially, pause and review a fresh quote rather than signing from memory.

The answer changes if you need a guaranteed destination amount or are moving a token with a strict deadline: use a route only if its displayed minimum and timing uncertainty fit that need. Otherwise, compare the net receive amount, token identity, and approvals before committing.

How to Compare Cross-Chain Swap Routes

Jerome Barton — Thu, 15 Oct 2026 23:15:09 +0000

If you need an asset on another network, compare the amount you will receive there—not just the quoted exchange rate—to choose between a cross-chain swap and bridging first, then swapping. The better route depends on total costs, available liquidity and how many separate transactions you must manage.

Keep these three points in view:

Compare the final destination amount after every fee and swap.
Check that you can receive and use the asset on the destination network.
Prefer fewer steps when the results are close and the route is clear.

What are you comparing?

A cross-chain swap combines moving value between networks with exchanging it for the asset you want. A separate route means bridging an asset first, then making a swap on the destination network. That can give you more control over the swap, but it also means handling separate transactions and checking each one.

For either route, follow the value from the asset you send to the amount you can actually use at the destination. Biswap is a cross-chain bridge and swap service that handles moving and exchanging assets across networks in one flow; consider the Biswap crypto bridge when that combined task is what you need. Biswap is relevant here as a route option, so compare its quoted destination amount with the separate steps available to you.

How do you compare the real cost?

Use the destination amount as your score. Include the source-network transaction fee, bridge or service charge, swap fee, price impact (the way your trade size shifts the pool price) and any destination transaction fee you must pay before using the funds. Liquidity pools hold tokens for swaps; shallow pools can give you a worse rate, especially for a large trade.

For example, suppose you start with $1,000. A combined route quotes $982 arriving, including its charges. A separate route estimates $4 for the first transaction, $5 for bridging, $8 for the destination swap and $2 for the final transaction: $1,000 − $4 − $5 − $8 − $2 = $981. The combined route is ahead by $1 on these estimates. Recheck both quotes just before acting, since prices and pool depth can change.

What should you check before choosing?

Write down the exact asset and network you will send, and the asset and network you need to receive.
Get a destination amount for the combined route and estimate every fee for the separate route.
Check that the receiving wallet supports the destination network and asset; matching token names do not guarantee they are the same asset.
Choose the route with the stronger usable result. If the amounts are close, I would pick the simpler route with fewer transactions to track.

For Bitcoin to an asset on Arbitrum, for example, make sure your comparison ends with funds on Arbitrum that your wallet can use, not merely a transfer that has left Bitcoin. Biswap may suit this job when you want the move and exchange handled together; choose it only if its destination quote and asset match your needs.

How to Set a Confirmation Policy for Cross-Chain Treasury Transfers

Jerome Barton — Thu, 15 Oct 2026 18:36:33 +0000

A confirmation policy for cross-chain treasury transfers defines when a sent amount may be treated as settled and spent. The key rule is to wait for the route’s required source-chain finality, then verify the destination credit and reconcile the asset before releasing payroll or supplier funds; a block count alone does not describe every bridge’s settlement.

A bridge transfer can involve source-chain settlement, message verification or liquidity, and a destination-chain transaction. That differs from a single-chain payout, where one chain’s settlement status may be enough; Biswap is a cross-chain bridge and swap service for moving and exchanging assets across networks. The same treasury policy should cover routes through Biswap and other providers.

Define settlement by the route’s actual stages

Use the route’s settlement stages—not a single universal confirmation number—to decide when a transfer is complete. Bridges differ: some wait for source-chain finality before releasing funds, while liquidity-based routes may pay the destination first and settle between providers later.

Map the route. Record the sending network, destination network, asset on each side, and how the route verifies the transfer. A token with the same ticker can have different contracts or representations; confirm the recipient is expecting the intended asset.
Set the source-chain threshold. Use the route’s stated requirement and your exposure limit. Ethereum.org describes Ethereum slots as 12 seconds and finality as taking about 15 minutes; a transaction appearing in a block is therefore not the same as finalized settlement.
Set the destination threshold. Require the receiving transaction to succeed and reach the commitment level your policy specifies. Solana’s RPC documentation distinguishes confirmed from finalized; for a high-value treasury payment, make finalized the release condition unless your risk owner has approved a faster rule.
Write down the evidence. For every transfer, retain the source transaction ID, route or provider reference, destination transaction ID, token and network, amount sent, amount received, and status checked. These fields let finance distinguish a delayed transfer from a failed one.

Match the waiting rule to the amount and purpose

Set a threshold that reflects how much the business could lose or disrupt if a transfer is reversed, delayed, or misdirected. A small test transfer can confirm the destination address and asset, but it does not prove that a larger payment will settle under the same conditions.

For example, before an illustrative $20,000 supplier payout from Ethereum to Solana, send a small test amount and confirm the recipient can identify it. Then send the balance; hold the supplier payment until the source meets the route’s required status and the destination transaction shows the expected token and amount at your chosen commitment level.

Routine, low-value transfers: follow the route’s stated confirmation threshold and reconcile each receipt.
Large or time-critical payouts: require destination finality and a second person’s review of the recipient and asset.
Unusual delays or conflicting statuses: pause the payout and check both transaction IDs before deciding whether action is needed.

Keep a separate timing allowance for operational planning. Ethereum finality can take around 15 minutes under normal conditions, but route processing, congestion, and destination confirmation can add time; do not promise a fixed payout arrival based only on block time.

Handle delays without creating a duplicate payment

If the source transfer appears successful but the destination credit is missing, do not immediately resend. Check the source transaction’s status and the route’s transfer record first: a bridge may still be verifying the message or waiting for its destination transaction.

For Biswap transfers, apply the same internal checks you use for any cross-chain service: reconcile the source and destination records, and escalate unresolved differences through your established process. Before acting, ask yourself: Do we have evidence that this exact amount is settled on the destination network and matches the payment we intend to release?

Estimating Cross-Chain Swap Completion Time

Jerome Barton — Thu, 15 Oct 2026 14:50:37 +0000

A cross-chain swap is complete when the destination asset has been delivered at the settlement level you need. The main timing variable is usually how much confirmation the route requires on the source chain before it risks releasing value on the destination.

Completion has three separate stages

Track the source deposit, the swap execution, and the destination payout as separate events. A source transaction can be included in a block while still too easy to reverse; after it passes the route’s acceptance threshold, the service or protocol executes against available liquidity and broadcasts a new transaction on the destination chain.

Execution inside a liquidity network can take seconds once the deposit is accepted, but that is only the middle stage. The payout still needs to land on its chain, and a transaction hash means it was broadcast—not necessarily included, finalized, or credited at the commitment level your next action requires.

For a BTC-to-ETH example, a thor swap starts with a Bitcoin deposit and ends with an Ethereum payout. A thor swap service handles those cross-chain legs as one routed action; the underlying settlement still depends on Bitcoin’s deposit confirmations and Ethereum’s payout status.

Source-chain risk usually sets the wait

On Bitcoin, each block added after the deposit increases its confirmation count, reducing—but never mathematically eliminating—the chance that a competing chain reorganizes it. Six confirmations is a common high-value benchmark and takes about an hour on average at Bitcoin’s roughly 10-minute block interval; routes may accept fewer for smaller deposits, since the economic cost of a double-spend rises with the amount at risk.

Ethereum has a different clock. A transaction may be included within a block after a short wait, while consensus finality typically takes around 15 minutes under normal conditions. If the route accepts an included transaction before full finality, it can finish sooner, but its risk model is then relying on Ethereum’s short-reorg resistance rather than its strongest settlement guarantee.

On Solana, processed, confirmed, and finalized are distinct commitment levels. Processed is the newest view and can be rolled back; confirmed means a supermajority of stake has voted for the block, while finalized is the strongest commitment. A route choosing confirmed can reduce latency, but the user should not equate it with finalized settlement.

Estimate the slow leg and verify the payout

Before sending, identify the route’s source acceptance policy and the commitment level expected for the destination asset. For a BTC-to-ETH route, budget for the required Bitcoin block depth first, then allow time for execution, Ethereum inclusion, and—if your next action is high value—Ethereum finality. Adding those stages is more useful than relying on a single “average swap time.”

Consider a $500 BTC deposit and a $50,000 deposit. If a route accepts one confirmation for the smaller transfer but requires more confirmations for the larger one, the second transfer can take much longer even when both transactions reach the same Bitcoin block. The trade-off is deliberate: waiting reduces reorganization exposure, while accepting earlier improves speed.

After submission, record the source transaction ID and check that it is on the canonical chain with the expected amount and destination details. Then follow the payout transaction separately. If the source is confirmed but there is no payout, check whether the route is still waiting for its threshold or has reported a failed execution; if the payout hash exists, inspect its status and destination address before retrying. Repeating a deposit while the first route is pending can create a second independent swap.

For L2 destinations, distinguish sequencer confirmation from the chain’s stronger settlement on its parent network. A fast sequencer receipt may be enough to make a small trade, but withdrawals or accounting that require stronger assurance can wait for the L2’s settlement mechanism to progress. The right stopping point depends on what you plan to do with the received asset.

Answers to common settlement questions

Does a transaction hash mean the swap is finished?

No. A hash proves that a transaction was submitted and gives you a way to track it. Check whether the source deposit reached the route’s acceptance threshold, then verify that the destination payout was included and succeeded. For high-value use, wait for the destination chain’s required commitment or finality rather than treating a broadcast notification as settlement.

Why can two swaps on the same route take different times?

Source-chain congestion, transaction fees, block timing, and deposit size can all change the wait. Some routes set confirmation depth according to value or chain-specific reorganization risk. Destination congestion can also delay inclusion after the source has cleared, so identical asset pairs do not guarantee identical completion times.

When should I treat the received asset as spendable?

Use the destination transaction’s status and your next action’s risk tolerance. A low-value trade may be practical after a fast confirmation; a large transfer, exchange deposit, or irreversible payment may justify waiting for stronger finality. Completion is a settlement decision: match the confirmation level to the cost of being wrong.