DEV Community: Jack Ridersor

What Is a Polygon Bridge Withdrawal and How Does It Work?

Jack Ridersor — Sun, 04 Oct 2026 20:31:56 +0000

A Polygon Bridge withdrawal moves a supported token from Polygon back to Ethereum. It usually takes two transactions on different networks, with a wait between them while Polygon validators attest to the withdrawal.

The withdrawal burns the Polygon-side token first.

When you begin a withdrawal, the bridge burns the token representation held on Polygon. For example, withdrawing 25 units of a mapped token burns those 25 units on Polygon so the corresponding tokens locked on Ethereum can later be released.

This first transaction needs to be signed by your wallet and uses POL for Polygon network gas. Keep its transaction record: the burn is the evidence the bridge needs to verify the withdrawal. Polygon Bridge is one way to start this standard Ethereum-to-Polygon return process.

A checkpoint proves the burn before Ethereum can release tokens.

A checkpoint is a validator-attested record of Polygon blocks submitted to Ethereum. It matters because Ethereum must be able to verify that the burn really happened on Polygon before releasing the matching tokens.

The bridge uses a cryptographic inclusion proof, often called a Merkle proof, to show that your burn transaction is included in a checkpointed block. Until that checkpoint is submitted, the withdrawal cannot be claimed on Ethereum. Checkpoint timing can vary with the network’s operations, so a pending withdrawal during this stage does not by itself mean the tokens are lost.

The Ethereum claim is a separate transaction.

Once the burn is checkpointed, you still need to submit an exit or claim transaction on Ethereum. That transaction supplies the proof and asks the bridge contract to release the locked tokens to your Ethereum address; it uses ETH for Ethereum gas.

In practice, check that the Polygon burn is confirmed, wait until its block is checkpointed, then complete the claim and verify the resulting Ethereum transaction. If the claim is ready but you lack ETH for gas, the tokens remain unclaimed until you can submit it. You pay gas for the Polygon burn and Ethereum claim, and each amount depends on demand on that network when the transaction is sent.

The key distinction is that “burned” and “claimed” are separate stages: the checkpoint connects them, and the Ethereum claim completes the return. For a fuller explanation of Polygon Bridge withdrawal time and cost, read the companion article before deciding when to make the transfer.

Cross-chain swap recovery for beginners

Jack Ridersor — Sun, 04 Oct 2026 11:07:57 +0000

If your browser disconnects during a cross-chain swap, check the transaction on the source blockchain before doing anything again. A confirmed transaction can keep moving after you close the page; the key is to find its record and check whether the tokens arrived on the destination blockchain.

Start with the transaction on the source chain

A browser disconnect does not cancel a transaction that the blockchain has already accepted. The source chain is the network where your tokens started, and its transaction record tells you whether the swap request was sent, is still waiting, or failed.

Open your wallet’s activity or history and find the transaction from around the time of the swap. If you see a transaction hash, copy it; this long string of letters and numbers identifies that transaction. Search for it in the source chain’s block explorer, a website that displays public blockchain records.

Look for its status. “Pending” means the network has not finished processing it, “success” means the source transaction completed, and “reverted” or “failed” means it did not complete as requested. A successful source transaction does not always mean the destination tokens have arrived: the cross-chain part may still be running.

Follow the transfer from source to destination

A cross-chain transfer usually has more than one stage. First, the source chain records your request; then a bridge or messaging system carries proof of that request to the destination chain, where a separate transaction releases or swaps the tokens. Chainlink CCIP’s documentation describes a similar send, verify, and execute sequence.

For a transfer using an intent, the path can differ: an intent is a request for a particular result, which a relayer may complete by sending tokens on the destination chain. Across describes this kind of approach. In either design, look for a message ID or destination transaction hash in the transaction details, a service’s status record, or a supported cross-chain explorer.

Here are two common cases. If the source transaction is still pending, wait and check it again; if it reverted, there is no completed transfer to track. If it succeeded but the destination transaction is missing, the request may still be waiting for confirmation or delivery, so check the message status before trying again.

Check the result before repeating the swap

When the destination transaction appears, open it in the destination chain’s explorer and check whether it succeeded. Then check your wallet on that same chain for the token you expected. Token names can look alike, so compare the token’s contract address—the public identifier for that specific token—if the balance is unclear.

A status such as “pending” or “in progress” usually means the transfer has not reached its final step. Some routes take longer because they wait for source-chain confirmations, which are blocks added after the transaction and used to reduce the risk of a chain changing its recent history. A missing record immediately after sending can also mean the tracking service has not indexed it yet.

For a general route that moves or swaps tokens between chains, omnichain is one service to consider. The omnichain status you see still needs to be checked against the source and destination records, because a page can lose connection while the transfer continues.

omnichain.network is a service for moving and swapping tokens across multiple blockchains from one interface. You can use the same recovery checks with any cross-chain service: the source transaction shows whether the request began, and the destination record shows whether it finished.

Keep these details before you close the page

In practice, I check the source record first and only retry when it confirms the original request failed. Repeating a swap while the first one is still moving can send a second transfer, which may cost extra network fees and leave you with more tokens than intended.

Before you finish, make sure you have:

The source-chain name and transaction hash.
The current source transaction status.
The message ID or destination transaction hash, if available.
A successful destination record and the expected token balance.

Bitcoin Reorgs: Why Chainflip Swaps Wait for Confirmations

Jack Ridersor — Sun, 04 Oct 2026 05:19:33 +0000

A Bitcoin reorganisation can delay recognition of a deposit because its block may be replaced. A swap protocol waits for the deposit to reach a configured depth before treating it as spendable input; each added block makes reversal less likely, but costs roughly ten minutes on average. That buffer protects settlement, and the required depth determines the usual wait.

A reorganisation can remove a deposit that looked confirmed

A Bitcoin transaction has one confirmation when it appears in a block; each block built on top adds another. Because miners can find competing blocks, nodes may briefly disagree about which valid chain has the most accumulated proof of work. If the competing branch wins, Bitcoin reorganises to it, and transactions in the displaced blocks return to the mempool if still valid.

Think of the transaction’s block as a page in a ledger being copied across a network. More pages copied on top make it increasingly costly for another version to replace that page, but there is no protocol-level moment when a probabilistic chain becomes mathematically irreversible. A swap system therefore sets an operational threshold rather than waiting for certainty.

For an active trader, the useful distinction is between broadcast, included, and recognised by the swap protocol. A high miner fee can improve the chance of timely inclusion, but it does not make the included block deeper; after inclusion, block production and the protocol’s confirmation rule dominate the wait.

Validators wait for depth before registering the input

For a Bitcoin-to-other-chain swap through Chainflip, validators watch the deposit channel and wait until the source transaction reaches the protocol’s required block depth. They then witness and register the deposit on the State Chain, where it can enter swap processing. This sequencing avoids committing the protocol’s liquidity against a source-chain payment that could still be removed.

Chainflip documentation describes Bitcoin recognition at three confirmations, about 30 minutes at Bitcoin’s ten-minute average block interval. The exact requirement is a protocol parameter and may change; the broker SDK exposes a per-chain required-confirmations value, and its example values are illustrative rather than a guarantee of today’s setting. For repeated swaps, check the live parameter before estimating latency.

The end-to-end sequence is straightforward:

The transaction reaches a miner’s mempool; its fee rate influences when it is selected.
A miner includes it in a block, giving it confirmation one.
Bitcoin adds blocks, increasing its depth and reducing ordinary reorganisation risk.
Once the configured threshold is met, validators witness the deposit and register it.
The swap is processed, then the destination-chain transaction must also be included and confirmed under that chain’s rules.

The threshold is not a promise that the destination transfer appears exactly 30 minutes after broadcast. Broadcast-to-inclusion time varies with mempool demand and fee rate; block intervals vary stochastically; and State Chain witnessing and destination settlement add their own time. The 30-minute figure estimates only three average Bitcoin block intervals after inclusion.

Depth trades latency against the cost of reversal

A shallow threshold reduces expected delay but leaves more exposure to a reorganisation or deliberate double spend. A deeper threshold reduces that exposure, while adding roughly ten minutes of expected waiting for every extra Bitcoin confirmation. Six confirmations, often cited for high-value payments, means about an hour from inclusion on average; it is a conservative convention, not a universal guarantee of finality.

For example, suppose a deposit is included promptly and Chainflip’s active threshold is three confirmations. The expected source-chain wait is about 20 minutes after the inclusion block: that block is confirmation one, followed by two more. A user who sees the transaction in a wallet or explorer after the first block may still have roughly two block intervals before protocol recognition.

Bitcoin fees affect the first part of the timeline, not the depth rule. Paying a higher fee rate may get a transaction mined sooner during congestion, but once it is in a block, the protocol still counts subsequent blocks. A fee bump can help an unconfirmed transaction through Replace-by-Fee when the wallet and transaction permit it; it cannot accelerate Bitcoin’s block production.

Fast paths move risk instead of removing it

Some swap flows can proceed with fewer confirmations by assigning the reorganisation exposure to liquidity providers. Chainflip Boost, for example, is documented as allowing eligible Bitcoin deposits to proceed after one confirmation, with liquidity providers taking the loss if a reorganisation removes a boosted deposit. That can save expected time, but it relies on available risk-bearing liquidity and does not make the source transaction more final.

The trade-off is most relevant when the source asset is Bitcoin and the destination is time-sensitive. A faster path can reduce waiting, while its liquidity or risk premium may make it more costly; ordinary confirmation avoids that particular risk transfer and waits for the configured depth. If the fast path is unavailable or skipped, the deposit falls back to the normal confirmation requirement, so don’t build a deadline around the optimistic case.

When I need a predictable estimate, I separate three quantities: time to first inclusion, remaining blocks to the live source threshold, and destination-chain settlement. For a standard Bitcoin deposit, confirm the current Chainflip requirement and use about ten minutes per remaining block as an average, not a countdown. If you’re ready to swap Bitcoin with Chainflip, choose the route with the latency and risk allocation that fit the trade, then allow room for both chains to settle.

Bitcoin Swap Confirmation Times Explained

Jack Ridersor — Sun, 04 Oct 2026 01:24:49 +0000

If you have sent Bitcoin for a cross-chain swap, wait for the required confirmations before treating a quiet status as a failure. Bitcoin must confirm the payment first; only then can the swap run and the destination asset be sent.

Why does a Bitcoin swap take longer than one transaction?

A cross-chain swap joins activity on two separate blockchains. For a BTC-to-ETH swap, Bitcoin first records your payment, the swap protocol processes it, and Ethereum then records the ETH payment to your wallet.

For a native-asset route such as BTC to ETH, Chainflip is one way to make the swap. Its validators—network operators that check transactions together—watch the Bitcoin deposit and report it to the protocol.

Bitcoin adds a new block about every 10 minutes on average, though the interval varies. Chainflip’s published flow describes waiting for three Bitcoin blocks, or roughly 30 minutes, before the deposit is treated as final by its State Chain, the part of the protocol that records deposits and runs swaps.

What happens after Bitcoin confirms the deposit?

After the Bitcoin confirmation wait, validators agree that the deposit is real and record it on the State Chain. This shared check helps protect the protocol if Bitcoin reorganises—when it replaces recent blocks with a different version of the chain.

The swap then runs through the JIT AMM, short for “just-in-time automated market maker.” In plain terms, this is the protocol’s system for matching a swap with available trading liquidity. The published example puts this processing at about 48 seconds after the deposit is confirmed.

Some routes use more than one trading pair. For example, BTC to ETH may trade through BTC-to-USDC and then USDC-to-ETH. The protocol can process those trades in sequence, usually in the same State Chain block.

Last, validators send the ETH to the destination address. That payment still needs to be included in an Ethereum block, so your wallet may show the result later than the swap itself. The destination chain and its activity affect this final part.

What should I check if the swap seems stuck?

Start with the Bitcoin transaction ID, often called a txid. Look it up in a Bitcoin block explorer and check whether the transaction is still unconfirmed or has appeared in a block. If it is unconfirmed, the wait is on Bitcoin; the protocol cannot process a deposit it has not yet seen and confirmed.

A common mistake is to send the same amount again because the first transfer has not produced the destination asset yet. Don’t resend while the original payment is pending. Check its confirmation count first, then check whether the protocol has registered it and whether the outgoing payment appears on the destination chain.

Once the Bitcoin deposit has enough confirmations, allow time for the protocol and destination chain to finish their parts. If the deposit is confirmed but there is no outgoing transaction, use the transaction details to identify which stage is waiting. Chainflip’s status records can distinguish a confirmed deposit from a swap that has been processed and a payment that has been sent.

Can the Bitcoin waiting time be shorter?

Some Bitcoin swaps may use Boost, an option that can release a deposit after its first Bitcoin confirmation when enough backing liquidity is available. It can shorten the wait, but it may add a fee; if liquidity is unavailable, the deposit follows the usual confirmation process.

Timing also depends on how quickly your Bitcoin transaction gets into a block. During busy periods, a transaction can wait in Bitcoin’s queue before its confirmation count even begins. A longer wait at that point does not mean the swap has failed.

In practice, separate the process into three checks: Bitcoin inclusion, protocol confirmation and swap, then delivery on the destination chain. Before sending, ask yourself: can I wait for Bitcoin’s confirmation window, and have I checked the destination address carefully?

Estimate Impermanent Loss in a Base V2 Pool

Jack Ridersor — Sat, 03 Oct 2026 22:25:01 +0000

In a V2 pool, if one token doubles in price, the pool’s value can end up about 5.7% below the value of simply holding the same tokens, before trading fees. That difference is called impermanent loss, and it matters when you decide whether a pool’s potential fees justify its price risk.

Price changes rebalance the tokens you own

A V2 pool holds two tokens and follows the constant-product rule: the quantities in the pool multiply to a roughly fixed number, written as x × y = k. Traders buy the token that is cheap in the pool and sell the one that is expensive, shifting the pool’s token mix as outside prices change.

When you add liquidity, you receive pool shares that represent your fraction of the reserves. Your share is based on how much liquidity you contribute relative to the pool’s total. As trades move the price, your share gradually contains less of the token that has risen and more of the other token. The Uniswap V2 whitepaper describes this constant-product mechanism; it applies to V2-style pools generally.

For example, suppose you deposit 1 ETH and 2,000 USDC when ETH is worth $2,000. Your $4,000 position starts with equal value in each token. If ETH rises to $4,000, the pool rebalances: ignoring fees, your share would be about 0.707 ETH and 2,828 USDC, worth about $5,657. Holding the original tokens would be worth $6,000, so the pool position trails by about $343, or 5.7%.

Compare the pool with simply holding

That comparison is impermanent loss: the shortfall against holding the original amounts, not a fee charged by the pool. It is “impermanent” because the gap can shrink if the relative price returns to where you entered. If you withdraw while prices differ, the shortfall becomes part of your realized result.

For a V2 pool, a useful estimate depends on the price ratio between entry and withdrawal. If that ratio is r, the percentage difference before fees is 2√r ÷ (1 + r) − 1. A twofold rise or fall gives a loss relative to holding of about 5.7%; a fourfold rise or fall gives about 20%. The calculation is symmetrical for rises and falls, and assumes a standard V2 pool without fees or other incentives.

Fees can offset that gap, but they are not guaranteed income. They depend on trading volume, the pool’s fee design, and your share of total liquidity; a busy pool can still underperform if its token prices move sharply. Uniswap’s developer documentation explains that liquidity providers earn a portion of trading fees, but the amount depends on pool activity and position size. BaseSwap is one way to supply liquidity to Base pools, including V2 pools, when you understand the tokens and accept the price exposure.

Check the pool before adding liquidity

Before depositing, compare the pair’s recent trading activity with its total liquidity: fees come from trades, while your share depends on how much liquidity you contribute. Check the token contract addresses with BaseScan, confirm the pool is the pair you intend to use, and work out whether you can tolerate receiving more of the weaker-performing token after a price move. Keep some ETH on Base for transaction gas.

If the pair’s price swings would make you uncomfortable holding both tokens, skip the pool or use a smaller amount. A token’s ticker or name alone does not prove its identity; verify its contract address through a reliable source before approving a transaction. When you choose to proceed, BaseSwap can be a way to handle liquidity on Base; review each transaction’s token amounts before confirming it.

Before you deposit:

Check both token addresses and the pool’s trading activity.
Estimate how a 2× or 4× price move would change your position.
Compare possible fees with that exposure, and keep ETH for gas.

How to Size Avalanche Swaps for Lower Price Impact

Jack Ridersor — Sat, 03 Oct 2026 18:16:23 +0000

Compare your order with the pool’s reserve on the input side, then check the quoted output before swapping. A small order against a deep pool usually moves the price less than the same order against a shallow pool. For frequent trades, this helps you avoid needless losses without splitting every order into extra transactions.

Compare the order with the pool’s depth

A pool’s depth is the amount of each token it holds. In a common automated market maker, or AMM, trades change the pool’s token balance and therefore its price. Think of the pool as a bowl: taking a cup from a full bowl changes the level less than taking one from a nearly empty bowl.

Check the pool’s reserve for the token you plan to spend. Compare your order’s value with that reserve, using the same currency for both; for example, compare dollars with dollars.
Use the ratio as a quick screen. If a balanced pool holds about $100,000 of each token and you sell $1,000 worth, that is roughly 1% of the input-side reserve. In a basic constant-product pool, that trade’s price impact is about 1%, before fees and other effects.
Repeat the estimate for your actual order size. A $5,000 order against that same reserve would create roughly 4.8% price impact, so the displayed output may be much worse. These figures are examples; pool design and trade fees change the exact result.

Check the quoted output before sending

Price impact is the change caused by your own trade moving along the pool’s pricing curve. Slippage is the extra change that can happen after the quote, while your transaction waits to be included on Avalanche C-Chain, the network where the swap executes.

Enter the full amount you intend to trade and inspect the expected output. If the quote worsens sharply as you increase the amount, the pool may be too shallow for one fast trade.
Set your minimum acceptable output based on the quote and the movement you can tolerate. Slippage tolerance is the allowed gap between the quoted output and that minimum. A wider gap may help a trade complete during a quick price move, but it also permits a worse fill.
Check that your wallet has AVAX for the network transaction fee, even if you swap WAVAX, the token form of AVAX used in pools. For a direct swap on Avalanche, Blackhole swap is one way to access token liquidity; compare its quoted output with the amount you expect to receive.

Use splitting only when another pool improves the trade

Splitting an order into smaller transactions through the same pool does not remove the curve’s total price impact. It adds transactions, which means more network fees and extra confirmations. Splitting can help if prices change between trades, but that outcome is uncertain.

Compare the full-order quote with the quotes available through other routes. A route is the sequence of pools a swap uses; a route through deeper pools can improve output, while extra hops can add pool fees and transaction work.
Choose the route with the best final output after fees, not simply the pool with the largest reserve. If a smaller order still has poor output, check the token pair and route again before sending; a competing DEX such as KyberSwap is another example of the category to compare.

L2 Confirmation and Settlement Finality Explained

Jack Ridersor — Wed, 30 Sep 2026 13:51:00 +0000

An L2 transaction can appear confirmed in seconds, while settlement on Ethereum may take hours or days. These are different stages, so a wallet message saying “confirmed” does not always mean the transaction can no longer be challenged.

What Does L2 Confirmation Mean?

An L2, or Layer 2, is a network that processes transactions separately from Ethereum Mainnet, then connects its results back to Ethereum. On an OP Stack rollup, a sequencer—a computer that orders and processes transactions—can quickly include your transaction in an L2 block.

Your wallet may show that inclusion as confirmed. It means the L2 has recorded the transaction, such as a token transfer or a withdrawal request. It does not, by itself, prove that Ethereum has accepted the batch or that every later challenge has ended.

The Manta Bridge is a practical example: it moves ETH and supported tokens between Ethereum and Manta Pacific, an Ethereum L2. For that transfer, mantabridge.dev is a way to move assets between the two networks.

This differs from a centralised exchange, which may credit a deposit after its own checks. With a wallet, you can inspect the transaction on the L2 and Ethereum separately. Each network records its own step, and the transaction’s status depends on which step you are checking.

When Is A Transaction Settled On Ethereum?

Settlement finality means Ethereum has accepted the rollup’s state update, and the relevant dispute process has finished. A rollup groups many L2 transactions into a batch and posts data about that batch to Ethereum. Ethereum’s consensus then makes its blocks final over time.

For an optimistic rollup, a batch is initially treated as valid but can be challenged. A fraud proof is evidence that a proposed state change was calculated incorrectly. The challenge period gives people time to check the batch and dispute an invalid result.

For a standard OP Stack withdrawal, the challenge period is commonly about seven days after the withdrawal is proven on Ethereum. The exact route can differ: some networks use faster-finality mechanisms that shorten the wait. Faster access may depend on a separate security process or a provider advancing funds, so check the route’s stated withdrawal status.

How Should You Read The Status?

Imagine you send ETH from Manta Pacific to your Ethereum wallet. First, your wallet signs a withdrawal request. The L2 includes it in a block, so the request can show as confirmed while the ETH is still unavailable on Ethereum.

Next, the rollup publishes the batch data and a record of the withdrawal to Ethereum. A proof—a cryptographic way to demonstrate that the withdrawal is included—can then be submitted. After the challenge period passes, the withdrawal can be finalized on Ethereum. Only then is the ETH released to your Ethereum address.

That last step matters: a confirmed withdrawal request is not the same as ETH received on Mainnet. Check the transaction on the network where it was submitted, then check Ethereum for the final release. If the L2 request is confirmed but no Mainnet transfer appears yet, the withdrawal may still be waiting for proof, the challenge period, or finalization.

Why Does an XMR Bridge Mint Need a Refund Check?

Jack Ridersor — Wed, 30 Sep 2026 00:56:11 +0000

A delayed mint needs checking because sending Monero and creating wrapped XMR are separate steps; seeing the first complete does not prove the second happened. If the mint stalls, confirm the bridge’s recorded status before retrying or seeking a refund, so you do not send a second deposit for the same transfer.

A Monero confirmation proves the deposit was included; the wrapped token still has to be minted on the destination chain.
A refund is a separate transaction, not a reversal of the original XMR payment.
Save both chain transaction IDs and use the bridge’s own status record to decide what to do next.

What does a refund path cover?

A refund path is the procedure for returning XMR when the bridge receives a deposit but does not complete the mint. A wrapped asset such as zXMR represents deposited Monero on an EVM chain; the source-chain payment cannot be undone like a card transaction.

In a lock-and-mint bridge, bridge operators or a validator group observe the XMR deposit, wait for the required confirmations, then authorize a mint on the destination chain. A refund therefore requires the bridge to identify the deposit, determine that minting will not complete, and authorize a new XMR payment back to the user.

These steps take time because Monero confirmations, bridge processing and Ethereum-compatible chain confirmations are separate. A pending mint may reflect a slow queue, a node or wallet issue, or destination-chain congestion. It is not, by itself, evidence that the bridge has rejected the deposit.

Which failure path fits the status?

Use the bridge’s recorded state to distinguish a delay from a failed transfer. The right next step depends on whether the deposit is still waiting for confirmations, has been accepted, or has reached a documented failure state.

Deposit unconfirmed: Wait for the required Monero confirmations. A transaction shown as sent in your wallet may not yet be eligible for processing.
Deposit confirmed, mint pending: Keep the deposit transaction ID and check the bridge record again. Do not repeat the XMR transfer while the first deposit is still being processed.
Mint failed or expired: Follow the service’s stated recovery process. Ask support or the operator to trace the deposit and confirm whether a refund is available, its destination address, and any fee.
Mint confirmed, wallet balance missing: Check the destination chain, receiving address and zXMR token contract. A wallet may not display a token automatically even when the mint succeeded.

For a concrete example, suppose you send 0.02 XMR and your wallet shows the Monero transaction as confirmed, but zXMR is absent. First, compare the deposit transaction ID and amount with the bridge’s status record. If it says “mint pending,” wait or contact the bridge with that ID; if it records a mint transaction, inspect that transaction on the destination chain before requesting a refund.

How does this apply to ZeroFi?

ZeroFi’s bridge interface currently lists XMR deposits to Sepolia, Ethereum’s test network, with a 0.01 XMR minimum and 10 source-chain confirmations; it also lists 10 confirmations for sweeps. Those displayed settings help explain why an accepted deposit and a visible mint may not happen at the same moment.

For a small test transfer, write down the generated deposit address, exact XMR amount, Monero transaction ID and destination wallet address. Wait until the bridge shows the deposit at the required confirmation depth, then check for a destination mint transaction and verify that the wallet is on Sepolia. A testnet mint is not mainnet zXMR that can be used in live DeFi.

The interface’s confirmation counts describe processing thresholds; they do not promise an automatic refund after a fixed number of minutes. I would not infer a refund guarantee from a pending status. Before sending, check the live network, minimum and recovery instructions, and use an amount you can afford to have tied up while an experimental bridge is resolved.

What should you save before asking for help?

A useful recovery request gives the operator enough detail to find the transfer without asking you to resend funds. Include the Monero transaction ID, deposit address, amount, approximate send time, destination wallet address, and any destination transaction ID or error shown in the interface. Never send a seed phrase or private key.

Compare the bridge record with your wallet history and the destination explorer, then contact the service through its verified support channel if those records disagree or the mint remains stuck. For a transfer involving ZeroFi to Ethereum, keep the chain and token details with the transaction IDs. Before closing the case, check: correct network; confirmed XMR deposit; mint or refund transaction recorded; returned funds received at the address you control.

How to Leave Enough Gas After a Bridge Transfer

Jack Ridersor — Tue, 29 Sep 2026 16:51:46 +0000

Leave enough of the chain’s native token to pay for your next transaction, using its current fee estimate and the action you plan to take. The right reserve depends on what you’ll do next; there is no fixed amount that works on every chain.

If you are moving tokens between networks, Bungee Bridge can find routes across bridges and decentralized exchanges. For the transfer itself, the Bungee Bridge app is one way to compare routes.

bungeebridge.co is the service for comparing cross-chain routes when you plan a token transfer.

Set aside gas for the next action

First, name the transaction you expect to make after the bridge. Gas is the fee paid to run a transaction, and the native token is the chain’s own currency, such as ETH on Ethereum. You usually need that token in your wallet on the chain where the transaction runs.

Estimate the fee for that next action in your wallet or the app you plan to use. A simple token send may need one transaction; a swap may need an approval transaction first. An approval gives an app permission to use a token, and it can cost gas separately unless the app combines the steps.

Then keep that estimated fee in reserve, plus a margin for the estimate changing before you act. For example, suppose a wallet shows 0.001 ETH for a later transaction. You might set aside 0.0015 ETH as an illustrative buffer, then subtract that reserve from the ETH you could send. The extra 0.0005 ETH is a cushion, not a guaranteed safe amount.

Count every source-chain transaction

Keep separate budgets for the bridge transaction and anything you still need to do on the source chain. Add the estimated source-chain bridge fee to the reserve for your next source-chain action; do not treat the bridge fee estimate as covering both.

For example, imagine you have 0.02 ETH on Ethereum. If the bridge transaction is estimated at 0.004 ETH and your later source-chain action needs 0.001 ETH, sending all 0.02 ETH leaves no ETH for either fee. With an illustrative 0.0015 ETH reserve for the later action, the most you could consider sending is 0.0145 ETH, before allowing for any extra bridge fee or price movement.

That arithmetic is only a planning example. Transaction fees change with network activity, and a failed transaction can still use gas. Check the estimate again just before you send, and leave more if you might need an approval or another action you have not priced yet.

Check which chain holds the reserve

Your reserve stays on the source chain only if you leave the native token there. Tokens that arrive on the destination chain cannot pay a source-chain fee, even when both networks use ETH. Each chain has its own balance and fee market.

So if you bridge from Ethereum to Arbitrum and expect to make another Ethereum transaction, keep ETH on Ethereum. If your next action is on Arbitrum, budget for gas there too; the destination balance may need Arbitrum’s native gas token.

Bungee Bridge can help compare routes for the transfer, but your reserve depends on the transactions you plan to make on each chain. Before acting, ask yourself: which chain will my next transaction run on, and have I left its fee token there?

Gnosis Bridge Guide: How to Bridge ETH to Gnosis Chain Step by Step

Jack Ridersor — Tue, 25 Aug 2026 20:15:39 +0000

Bridging from Ethereum mainnet to Gnosis Chain is simple once you know which asset you want on the other side. Gnosis Chain is EVM-compatible, so the same wallet address works across both networks, but its native gas token is xDAI, not ETH.

The official Gnosis Bridge ecosystem is usually used through two routes: the xDai Bridge for moving DAI into native xDAI, and Omnibridge for ERC-20 tokens such as WETH. This guide walks through wallet setup, approvals, confirmations, and what actually arrives on Gnosis Chain.

Gnosis Bridge Basics: Choose the Right Route

There are two common goals when moving ETH value from Ethereum to Gnosis Chain.

If you want gas money for Gnosis Chain, use the xDai Bridge. You start with DAI on Ethereum mainnet, bridge it, and receive native xDAI on Gnosis Chain. Because xDAI is the gas token, this is the route most users need before interacting with apps, sending transactions, or swapping tokens on Gnosis.

If you want ETH exposure on Gnosis Chain, use Omnibridge with WETH. Native ETH is not an ERC-20 token, so bridge systems that handle ERC-20 assets generally use WETH instead. After bridging, you receive a bridged representation of WETH on Gnosis Chain, not native ETH for gas.

The core mechanism is similar in both cases: the bridge locks or burns the asset on the source chain, sends an authenticated cross-chain message, and then mints or unlocks the corresponding asset on the destination chain.

Before You Start: Wallet and Asset Checklist

Use a self-custody EVM wallet such as MetaMask, Rabby, Frame, or another wallet that supports custom networks. Add Gnosis Chain if it is not already available in your wallet. The key details are chain ID 100 and native currency xDAI. Many wallets can add the network automatically when you connect to a Gnosis app, but you should still confirm the chain name and chain ID before approving.

You also need enough ETH on Ethereum mainnet to pay mainnet gas. If you are using the xDai Bridge, you need DAI on Ethereum. If you are using Omnibridge for ETH exposure, you need WETH on Ethereum. Keep a little ETH unspent so you can pay for any approval and bridge transactions.

Before signing anything, check:

Source network: Ethereum mainnet.
Destination network: Gnosis Chain.
Wallet address: correct recipient address.
Asset: DAI for xDAI, or WETH for bridged ETH exposure.
Gas: ETH on Ethereum, xDAI on Gnosis Chain after arrival.

Step-by-Step: Bridge ETH Value Into xDAI

This path is best when your goal is to get usable gas and spending balance on Gnosis Chain.

1. Swap ETH to DAI on Ethereum

If you currently hold ETH, swap the amount you want to bridge into DAI on Ethereum mainnet. Do not swap your full ETH balance. You still need ETH to pay for the swap itself and for the bridge transaction.

2. Open the xDai Bridge Flow

Connect your wallet to the official bridge interface and choose Ethereum as the source network and Gnosis Chain as the destination network. Select DAI as the token to send.

The interface should show that the destination asset is xDAI. This is the expected result: DAI on Ethereum becomes native xDAI on Gnosis Chain through the bridge mechanism.

3. Approve DAI

The first time you use DAI with the bridge, your wallet may ask for a token approval. An approval does not move funds. It only gives the bridge contract permission to use the approved amount of DAI.

For better self-custody hygiene, approve only the amount you intend to bridge unless you deliberately want a larger allowance. Wait for the approval transaction to confirm on Ethereum before continuing.

4. Confirm the Bridge Transaction

After approval, submit the actual bridge transaction. This is the transaction that sends your DAI into the bridge process on Ethereum. Your wallet will show the gas fee in ETH because the source transaction happens on Ethereum mainnet.

Once confirmed, the bridge waits for source-chain confirmation, relays the authenticated message, and completes the corresponding mint or release on Gnosis Chain. Timing depends on network conditions and should not be treated as guaranteed.

5. Switch to Gnosis Chain

After the bridge completes, switch your wallet network to Gnosis Chain. Your balance should appear as xDAI. If it does not show immediately, refresh the wallet, switch networks away and back, or check whether the bridge interface still shows the transfer as pending.

The xDAI you receive is native gas on Gnosis Chain. You can use it to pay transaction fees, send payments, interact with smart contracts, and swap into other tokens on Gnosis-based apps.

Step-by-Step: Bridge WETH With Omnibridge

Use Omnibridge if you want a tokenized ETH position on Gnosis Chain rather than native gas.

1. Wrap ETH Into WETH

If your wallet holds native ETH, wrap the amount you want to bridge into WETH on Ethereum. WETH is an ERC-20 representation of ETH, which makes it compatible with token bridge infrastructure. Keep some ETH unwrapped for gas.

2. Select WETH in Omnibridge

Open the Omnibridge route, connect your wallet, set Ethereum as the source network, and set Gnosis Chain as the destination network. Select WETH as the asset.

Review the destination token carefully. Omnibridge assets arrive as bridged token representations on Gnosis Chain, separate from the original Ethereum token contract.

3. Approve and Send

Approve WETH if prompted. As with DAI, this approval only authorizes the bridge contract to spend the token; it is not the bridge transfer itself. After the approval confirms, submit the bridge transaction.

Omnibridge then locks or burns the token on Ethereum, relays the cross-chain message, and mints or unlocks the corresponding bridged asset on Gnosis Chain. If the token does not appear in your wallet automatically, you may need to import the Gnosis Chain token contract.

4. Keep xDAI for Fees

Bridged WETH is not used for gas on Gnosis Chain. You still need xDAI to move it, swap it, or interact with apps. If this is your first Gnosis Chain transfer, bridge a small amount of DAI through the xDai Bridge as well so you have xDAI available.

What Arrives on the Other Side?

The output depends on the bridge route:

DAI through the xDai Bridge arrives as native xDAI.
WETH through Omnibridge arrives as a bridged WETH-style token.
Other ERC-20 tokens through Omnibridge arrive as bridged token representations.

This distinction matters. Native xDAI pays gas. Bridged ERC-20 tokens are assets you can hold or use in supported protocols, but they do not replace xDAI for transaction fees.

Because Gnosis Chain is EVM-compatible, your address is usually the same as your Ethereum address, but balances are separate by network.

Fees, Confirmations, and Troubleshooting

Ethereum mainnet is usually the expensive side because approvals and bridge submissions require Ethereum gas. Gnosis Chain fees are generally low and predictable by comparison, often just cents in normal conditions, but they are still paid in xDAI.

If a transfer seems stuck, do not immediately send a duplicate transaction. First check whether the approval confirmed, whether the actual bridge transaction was submitted, and whether the destination network is selected in your wallet.

Common issues include:

You approved the token but did not submit the bridge transaction.
You bridged WETH but have no xDAI to pay Gnosis Chain gas.
Your wallet is still showing Ethereum mainnet balances.
The bridged token needs to be manually imported.
The bridge is still waiting for confirmations or message processing.

For larger transfers, send a small test amount first. Bridges still involve smart contract, wallet, and user-operation risk.

Final Checklist for Bridging to Gnosis Chain

Before confirming the transaction, make sure the bridge route matches your goal. Use the xDai Bridge when you want DAI to become native xDAI for gas. Use Omnibridge when you want to move WETH or another ERC-20 token as a bridged asset.

Keep ETH on Ethereum for source-chain fees, keep xDAI on Gnosis Chain for destination-chain fees, and read every wallet prompt before signing. Once the transaction is complete, switch to Gnosis Chain and verify the correct asset: xDAI for native gas, or a bridged ERC-20 token for token exposure.

How to Avoid High Slippage and Bad Fills on ParaSwap

Jack Ridersor — Thu, 20 Aug 2026 13:24:42 +0000

ParaSwap can help you avoid the quiet tax of bad swap execution: high slippage, ugly price impact, and routes that cost more than they should. If you are swapping tokens with a non-custodial wallet, ParaSwap gives you one place to compare liquidity across decentralized exchanges and route the trade toward a better price instead of guessing pool by pool.

Slippage is the difference between the price you expected and the price your swap actually gets when it confirms. A little slippage is normal in DeFi. Too much slippage means you may receive fewer tokens than planned, especially when the market is moving, liquidity is thin, or your trade is large compared with the available pool depth.

The goal is not to set slippage to zero and hope for magic. The goal is to understand why slippage happens, use ParaSwap’s routing intelligently, and check the details before you approve a real-money transaction.

What You'll Need Before Using ParaSwap

Before you try to reduce slippage, make sure the basics are in place:

A non-custodial wallet such as MetaMask.
The right network selected in your wallet, such as Ethereum, Polygon, or another supported EVM chain.
The token you want to sell and the token you want to buy.
A little native crypto for gas fees on that network.
The correct token contract if you are trading something less common.

ParaSwap is a DEX aggregator, not a single AMM pool. That matters. Instead of giving you only one pool’s price, it searches many decentralized exchanges and liquidity sources across supported chains, then builds a route for the swap. Sometimes that route is simple. Sometimes it splits the trade across multiple sources to reduce price impact.

Step 1: Choose the Right Network

Start by checking the network in your wallet before you choose tokens. A common beginner mistake is thinking of a token by name only. In DeFi, the same symbol can exist on more than one chain, and not every version has the same liquidity.

If you plan to swap on Polygon, your wallet needs to be on Polygon. If you plan to swap on Ethereum, your wallet needs to be on Ethereum. The gas token also changes by network, so make sure you have enough native crypto to pay the transaction fee.

This step helps with slippage because liquidity is chain-specific. A trading pair may be deep on one chain and thin on another. Thin liquidity makes price impact worse, especially on larger swaps.

Step 2: Pick the Tokens Carefully

Choose the token you are selling and the token you want to receive. For major assets and stablecoins, this is usually straightforward. For smaller tokens, slow down.

Check that the token is the real asset you intend to trade. Fake tokens often copy names and symbols. If you paste a token contract, confirm it from a source you already trust before using it. ParaSwap can route a swap, but it cannot make a fake token safe.

Also think about the trading pair. Swapping from one obscure token directly into another obscure token may create more price impact than swapping through a deeper asset such as a major token or stablecoin. ParaSwap’s routing may handle that path for you, but you should still read the quote before signing.

Step 3: Enter a Sensible Trade Size

Trade size is one of the biggest drivers of slippage. A $50 swap and a $50,000 swap can behave very differently, even on the same pair. If your order is large compared with the liquidity available, the final price can move against you as the swap executes.

Use the quote screen as your first warning system. Look for price impact and estimated received amount. If the output drops sharply when you increase the input amount, that is a sign the trade may be too large for the available liquidity at that moment.

For larger swaps, consider splitting the trade into smaller pieces. This is not always cheaper because each transaction has its own gas cost, but it can sometimes reduce price impact. Treat this as a comparison, not a rule. Check the total expected output and total gas, then decide.

Step 4: Review the ParaSwap Route

Before confirming, review how ParaSwap is routing the swap. The route is where the aggregator earns its keep: it searches liquidity sources and tries to find stronger execution than you might get from one decentralized exchange alone.

Pay attention to three things:

Estimated output: how many tokens you should receive if the quote holds.
Price impact: how much your own trade is moving the price.
Gas cost: the network fee required to execute the transaction.

A route with a slightly better token output but much higher gas may not be better for a small swap. On a larger trade, the better execution may easily outweigh the extra gas. Look at the whole result, not just the headline rate.

Step 5: Set Slippage Tolerance Like a Risk Limit

Slippage tolerance is the maximum price movement you are willing to accept before the transaction fails. If you set it too low, your swap may fail during volatile conditions and you still may lose gas. If you set it too high, your swap can execute at a much worse price than expected.

For liquid pairs, a lower slippage tolerance often makes sense. For volatile or low-liquidity tokens, you may need more room, but that extra room is risk. Do not raise slippage just because a transaction failed once. First check whether the market moved, whether the token has transfer taxes, whether liquidity is thin, or whether your trade size is too large.

A simple habit helps: ask, “Would I still be comfortable if this swap executed at the worst price allowed by my slippage setting?” If the answer is no, reduce the size, wait, or skip the trade.

Step 6: Understand Token Approvals

When you sell a token through a DEX aggregator, your wallet may ask you to approve token spending before the swap. Approval is separate from the swap itself. It gives a smart contract permission to move a specific token from your wallet.

Approval risk is real. Do not approve tokens on a site you do not trust. If your wallet offers a custom approval amount, you can approve only what you plan to trade instead of granting a very large allowance. This may require more approvals later, but it limits exposure.

After approval, you still need to confirm the swap transaction. Read both wallet prompts. Beginners often rush through the second prompt because the first one felt like the main action.

Step 7: Confirm Only When the Numbers Still Make Sense

Quotes can change. Gas can move. Liquidity can shift. Before you confirm, check the estimated received amount one last time.

If the market is moving fast, avoid sitting on an old quote. Refresh it. If gas is unusually high, decide whether the trade is urgent. If price impact looks excessive, lower the trade size or wait for better liquidity.

This is especially important with stablecoins. A stablecoin swap should usually have low price impact when liquidity is healthy. If the quote looks strangely poor, stop and inspect the route, token selection, network, and trade size.

Common Mistakes That Cause Bad Slippage

The most expensive mistakes are usually simple.

Setting slippage too high is the obvious one. It may help a difficult swap go through, but it also gives the transaction more room to execute badly.

Ignoring price impact is another. Slippage tolerance controls acceptable movement from the quoted price; price impact shows how much your own trade affects the market. You need to look at both.

Trading fake or wrong-network tokens can be worse than slippage. Always check that you are trading the intended asset on the intended chain.

Swapping during extreme volatility can also punish you. When prices are moving quickly, quotes expire faster and failed transactions become more likely.

Finally, do not forget gas. A low-slippage route can still be a poor deal if the gas cost is too high for the size of your trade.

Use ParaSwap With a Slippage Checklist

High slippage is not random. It usually comes from thin liquidity, volatile markets, oversized trades, loose settings, or careless approvals. ParaSwap gives you better visibility by comparing routes across decentralized exchanges and liquidity sources, but the final decision is still yours.

Before you swap, check the network, token contract, trade size, estimated output, price impact, gas, slippage tolerance, and approval prompt. That short routine can save you from most beginner mistakes.

When you are ready to compare routes and make the swap, use ParaSwap and confirm only when the numbers still make sense.

Slippage and Price Impact on ParaSwap, Explained

Jack Ridersor — Thu, 20 Aug 2026 13:24:21 +0000

Slippage on ParaSwap is the difference between the price you see before a swap and the price you actually receive after the transaction lands on-chain. If you understand that gap, ParaSwap becomes much easier to use: you can protect your output, avoid bad fills, and stop treating the confirm button like a guess.

Crypto swaps are not fixed-price checkout screens. Prices move while your transaction is pending. Liquidity can change. Gas can delay confirmation. A clean-looking trade can become expensive if the token pair is thin, volatile, or set with sloppy tolerance.

The point is not to fear slippage. The point is to know what it means, where to check it, and when a swap is telling you to slow down.

What Slippage Means on ParaSwap

ParaSwap is a DEX aggregator. It is not one single AMM pool. It searches many decentralized exchanges and liquidity sources across supported chains, then routes your swap in search of the best available price.

Slippage is the difference between the quoted output and the final output. For a simple illustrative example, if a quote shows that you may receive 1,000 tokens, but the final swap gives you 995, the 5-token gap is slippage.

That gap can happen for several reasons:

The token price changed before your transaction confirmed.
Another trade used the same liquidity first.
Your trade was large enough to move the price.
Gas fees were high and your transaction waited longer.
The token pair had weak liquidity.

ParaSwap can improve routing by checking multiple liquidity sources, but it cannot remove normal market movement. You still need to review price impact, gas, token approvals, and the minimum received amount before signing.

What You'll Need

Before swapping, have the basics ready:

A non-custodial wallet, such as MetaMask.
The correct network selected, such as Ethereum, Polygon, or another supported EVM chain.
A little native crypto for gas fees.
The real token contract, especially for smaller or unfamiliar assets.
The trading pair you want to swap.

If you are on the wrong network or looking at a fake token, slippage settings will not fix the problem.

Step 1: Connect Your Wallet

Connect your wallet and check the network before doing anything else. If your funds are on Polygon, your wallet needs to be on Polygon. If your funds are on Ethereum, use Ethereum. This sounds basic, but wrong-network confusion is one of the easiest ways beginners waste time and gas.

Step 2: Pick the Tokens

Choose the token you want to sell and the token you want to receive. Common assets and stablecoins usually have deeper liquidity. Smaller tokens, new tokens, and unusual trading pairs can show more price impact because there may be less liquidity available.

Step 3: Enter the Amount

Enter the amount you want to swap, then watch how the quote changes. A small swap may show low price impact. A larger swap in the same pair may suddenly look worse because the route has to take more liquidity from the market.

If the expected output drops sharply as you increase the amount, you may be pushing too hard into thin liquidity.

Step 4: Review the Route

This is where ParaSwap does the useful work. As a DEX aggregator, it can compare liquidity sources and route a swap across decentralized exchanges instead of forcing you to accept one pool's price.

Still, do not look only at the headline quote. Check:

Estimated received amount.
Minimum received amount.
Price impact.
Gas fees.
Token approval request.
The network being used.

The best-looking price can be less attractive once gas and execution risk are included.

Step 5: Set Slippage Tolerance

Slippage tolerance is the maximum movement you are willing to accept before the transaction fails. A tight setting can protect your output, but it may cause failed swaps if the market moves quickly. A loose setting may help execution, but it also allows a worse final result.

For liquid stablecoin pairs, lower tolerance is often enough. For volatile or thinly traded tokens, you may need more room, but that room is risk. Do not raise slippage just because a transaction fails once. First check liquidity, price impact, gas, and trade size.

The most important number is the minimum received amount. If that number would disappoint you, do not confirm.

Step 6: Understand Approvals

If you are selling a token for the first time, your wallet may ask you to approve token spending before the swap. That is normal in DeFi, but it is still permission. Read the wallet prompt. Avoid approving suspicious contracts, random tokens, or anything that does not match the trade you intended to make.

Slippage vs. Price Impact

Slippage and price impact are related, but they are not identical.

Price impact is how much your own trade changes the market price because of its size compared with available liquidity. Slippage is the allowed difference between the quoted result and the final on-chain result.

A large trade in a thin token pair can have high price impact before the transaction even starts. A small trade can still suffer slippage if the market moves while it is pending.

Common Mistakes That Cost Money

The biggest mistake is setting slippage too high. A high tolerance is not a better trade setting; it is permission to accept a wider range of outcomes.

Another mistake is ignoring price impact. If the trade itself is moving the market heavily, consider reducing the amount, waiting, or skipping the swap.

Fake tokens are also a real risk. Check token contracts carefully, especially outside major assets and stablecoins.

Do not ignore gas either. On Ethereum, gas can make a small swap unattractive even if the route is good. On Polygon and other EVM chains, gas may be cheaper, but it still counts.

Use Slippage as a Safety Setting

Slippage is not something to max out blindly. It is a safety setting that defines how much execution risk you are willing to accept.

ParaSwap can search decentralized exchanges and liquidity sources for better routing, but you still control the final decision. Read the quote, check the minimum received amount, keep slippage only as wide as the trade truly needs, and pause when price impact looks uncomfortable. When you are ready to compare routes before signing, use ParaSwap and review the final wallet prompt before confirming.