DEV Community: Gogu

How to Execute ParaSwap API Swaps Safely

Gogu — Tue, 03 Nov 2026 15:01:56 +0000

You can execute a ParaSwap API quote safely by binding the transaction to the intended wallet, chain, token amounts, and minimum output, provided you refresh the quote before signing. The integration has two stages: get a route, then build transaction data from that route. Understanding how ParaSwap builds swap routes helps explain why the route returned by the first call must stay paired with the trade details used in the second.

Build the transaction from the exact quote

Use the quote response as the source of truth for transaction construction. Request a route from /prices with the network, source and destination token addresses, and source amount in the token’s smallest units; for example, 1 USDC is 1,000,000 units when the token has six decimals. Then pass the returned priceRoute unchanged to /transactions/{network}, along with the same token addresses and the wallet’s address.

Do not rebuild the route from only its displayed output amount. The response includes routing and contract data needed to create valid calldata, and the transaction builder can use that route to check balances, allowances, and gas. A quote is not a reservation: pool prices can move between the API call and execution, so a transaction may revert if its minimum output is no longer available.

Set slippage according to the trade and the user’s tolerance, then let the builder encode the resulting minimum output. For a sell quote of 1,000 USDC for 0.5 ETH, a 0.5% slippage limit means the swap must return at least 0.4975 ETH. The trade-off is direct: a tighter limit protects the user’s price but is more likely to revert during volatile markets.

Check approvals and transaction fields before signing

For an ERC-20 input token, the wallet must approve the route’s tokenTransferProxy to spend the required amount; approving the router address instead may not authorize the transfer. Prefer an exact-amount approval for a one-off swap, or reuse a larger allowance only when the user knowingly accepts that ongoing permission. Native ETH input does not need an ERC-20 approval.

Before presenting a signature request, confirm the wallet is connected to the requested chain and that the built transaction targets the expected contract. Check its to, data, and value fields, and make sure the input amount and recipient match the user’s intent. Estimate gas with the wallet or current node state; a gas estimate from the quote can change before submission.

Refresh quotes when trade details change

Fetch a new route whenever the user changes the amount, token pair, network, or slippage choice. Treat a route from a previous screen state as stale even if only a short time has passed: the pool state may have changed, and the quote’s block number helps identify when it was computed. If the build call fails its checks, refresh the quote and rebuild instead of repeatedly sending the same calldata.

For a concrete before-and-after, suppose the user first quotes 1,000 USDC for 0.5 ETH, then increases the trade to 2,000 USDC. Reusing the first route with the new amount can mismatch the route and transaction parameters; the safe sequence is to request a new quote for 2,000 USDC, build from that response, and show the new minimum received amount before signing.

Keep the integration flow small and explicit

Implement the swap as a short sequence the wallet can review: request the quote, show output and minimum received, build calldata with the chosen slippage, obtain any required approval, then submit the swap transaction. ParaSwap’s API can supply the route and transaction data, but the integrator still owns the user-facing checks and signing flow.

Read the wallet’s chain and address, then verify both match the requested swap.
Fetch a fresh quote using token addresses and base-unit amounts.
Show the quoted output, slippage limit, and minimum output to the user.
Build transaction data from the unchanged route and the chosen slippage.
Request the required approval, then simulate or estimate gas and submit the swap.

In my view, the key integration decision is to refresh on every material input change and make the minimum output visible before signing. That keeps the API route, the user’s consent, and the submitted transaction aligned.

How Do Cross-Chain Swaps Use Intermediate Assets?

Gogu — Fri, 23 Oct 2026 13:59:38 +0000

A routed swap converts your asset through one or more intermediate assets. It can reach a destination token that has no direct, liquid trading pool with what you hold, but each extra hop adds a fee and another price to check.

Think of changing currencies at an airport: you might exchange pounds for euros, then euros for yen because that route offers a better overall rate. In a crypto swap, each exchange is a hop through a pool, and the amount received from one hop becomes the input to the next. A route might be BTC → USDC → ETH. Unlike a route confined to pools on one chain, Chainflip can use sequential pools to swap native assets across chains; its route executes one pool at a time, usually within the same State Chain block.

Each hop sets the amount for the next

A multi-hop route is a sequence of trades, not one trade at a made-up combined rate. The router first estimates how much the first pool returns, then uses that amount to calculate the second pool’s output. Uniswap Developers’ multi-hop guide describes this pattern for swaps across pools: the route identifies the intermediate token and the pools used at each step.

For example, imagine a route that trades 1 BTC for USDC, then USDC for ETH. The first pool’s price, depth and fee determine the USDC amount available for the second trade. If the BTC–USDC pool returns fewer dollars than expected, the second hop starts with less USDC and produces less ETH too.

In Chainflip’s case, the protocol’s Swapping Basics describes multi-pool routes such as BTC → USDC → ETH. The swaps are carried out sequentially, usually in one State Chain block. That coordination avoids asking the user to submit a separate trade for the intermediate asset, but it does not erase the two pool trades or their individual costs.

The route wins only if its combined output is better

An intermediate asset helps when its pools provide enough liquidity to beat a direct route after costs. A direct BTC-to-ETH pool may be shallow or unavailable, while BTC-to-USDC and USDC-to-ETH pools may each have more trading depth. The route can then produce more ETH despite taking two steps.

But each hop usually charges a pool fee, and each trade moves the pool price against the order to some degree. A route with two deep pools can still be better than one thin direct pool; a route with a shallow second pool can give back the advantage. For a small trade, the extra pool fee may outweigh a modest price improvement. For a large trade, price impact in either leg can dominate.

Compare the final output after all listed fees and network costs, rather than comparing the first exchange rate you see. The key figure is the amount you expect to receive at the destination, alongside its minimum amount if the quote provides one. A longer route is useful only when that net result beats the shorter alternative.

Two hops mean two places for the price to move

Price impact is the effect your trade has on a pool’s price; slippage is the difference between the quoted result and what execution delivers after prices change. A multi-hop route faces both at each step. If either pool’s price shifts before execution, the intermediate amount changes and the final output can move further.

Stablecoins are common intermediates because they make it easier to connect pools, but their value is not guaranteed to remain equal to a dollar. If the intermediary loses its peg, or one leg suddenly has little liquidity, a route that looked attractive at quote time may deliver a poor result or fail its minimum-output condition. Check that the named intermediate asset is the one you expect and that the quoted route still shows the same destination asset and amount before confirming.

Cross-chain swaps also involve deposits and delivery on different networks, so execution can take longer than a single on-chain trade. On Chainflip, for example, the source deposit must be witnessed before the State Chain processes the swap, and the destination asset is then sent out to the specified address. Review the destination network and address carefully; a good route cannot correct an address entered for the wrong chain.

Check the whole route before you confirm

Before sending funds, inspect the route’s intermediate asset, final output, fees, minimum received and destination details. If the quote changes materially while you are deciding, refresh it; the pool balances and prices behind its calculations can change. Be especially cautious when one hop has visibly low liquidity or when the intermediary is unfamiliar.

A quote is an estimate with a defined tolerance, not a promise of a fixed exchange rate. The minimum-output setting determines how much worse execution may be before the swap stops, where that control is available. Setting it too tight can make an otherwise reasonable swap fail during ordinary price movement; setting it too loose accepts a larger loss than the quote suggests.

Use an intermediate route when its final net output is better and both hops, the intermediary and destination details check out.

How to Track Pool Fees Between LP Withdrawals

Gogu — Thu, 22 Oct 2026 21:03:49 +0000

If you are integrating liquidity withdrawals, track fees using the pool’s accounting model and the position’s share, because fees can accrue between transactions without a separate claim. The first job is to identify whether a pool keeps fees in its reserves or records them separately; the withdrawal calculation depends on that distinction.

Where do pool fees accrue?

In a constant-product pool that keeps swap fees in its reserves, each trade leaves some value in the pool for liquidity providers. A provider’s share is represented by its fraction of the pool’s liquidity tokens, so the accumulated value is reflected in the reserves when the position is withdrawn.

If you are integrating a v2-style pool on Biswap DEX, first confirm that the specific pool uses this model and read its fee settings from the deployed contracts. Biswap is a useful context for this check because a DEX can expose different pools and services; do not infer one pool’s fee behavior from the product name alone.

Other designs account for fees separately. In a concentrated-liquidity pool, for example, fee growth may be tracked per token and per position; reducing liquidity and collecting owed fees can be separate actions. An adapter that assumes every withdrawal includes every fee can therefore undercount a position’s claim.

How does a reserve-based withdrawal include fees?

For a reserve-based pool, a withdrawal pays the position’s pro-rata share of each reserve at the time the transaction executes. If the position owns fraction s of the pool, the gross amounts are approximately s × reserve0 and s × reserve1, subject to the contract’s integer rounding and any pool-specific rules.

For example, suppose a pool starts with 10,000 A and 20,000 B, and a swap adds 100 A while taking out about 197.43 B at an illustrative 0.30% fee. The pool ends near 10,100 A and 19,802.57 B. A provider who owns 1% at withdrawal receives roughly 101 A and 198.03 B before rounding, rather than the original 1% of the starting reserves.

That change is not a clean fee total: the trade also changes the pool’s token mix and market price. To estimate fees alone, compare the position against a counterfactual with the same trades but no fees, and value both token balances at the same external price. The result depends on the pool’s fee split, trade path, and price movement.

What should an integration measure?

Measure the amount a position can actually withdraw, and keep fee attribution as a separate calculation. On a reserve-based pool, read reserves and total liquidity supply at a consistent block, then calculate the provider’s share using the pool’s actual withdrawal rules. On a position-based pool, read the position’s liquidity, fee-growth checkpoints, and tokens owed according to that implementation.

Biswap integrations should also distinguish gross pool fees from protocol fees, if the pool diverts part of each swap. A displayed swap fee rate may describe what the trader pays, not what liquidity providers retain. Check the contract’s fee parameters and fee destination rather than treating the quoted rate as the provider’s net yield.

How do you implement the withdrawal check?

Use this sequence before showing an estimated withdrawal or recording realized fees:

Identify the pool contract. Resolve the chain, pair, and pool address from the supported deployment registry.
Read the accounting model. Determine whether fees remain in reserves or accrue to position-level fee counters.
Fetch one consistent snapshot. Read reserves, supply, position liquidity, and fee checkpoints at the same block number.
Calculate the gross claim. Apply the pool’s withdrawal formula and integer rounding to estimate token amounts.
Separate estimated fees from other changes. Compare against a clearly defined baseline and use the same external prices for both values.
Simulate the actual transaction. Include any separate collect call, minimum-output settings, transfer behavior, and gas cost in the user-facing result.

A useful edge case is a token that charges a transfer fee or rebases balances. The amount sent by the pool may then differ from the amount received, or the reported balance may shift without a swap. For such assets, base estimates on the pool’s verified token behavior and transaction simulation; reserve arithmetic alone may mislead.

Questions integrators ask next

Are LP fees the same as impermanent loss?

No. Fees are value retained or credited by the pool under its fee rules, while impermanent loss describes how a liquidity position’s value differs from simply holding its deposited assets as prices move. A position can earn fees and still underperform that hold-only comparison. Report fee revenue and price-driven performance separately.

When should an integration update its fee estimate?

Update the estimate whenever the user changes the pool, position size, or withdrawal block. For a live display, refresh the underlying state at a recent block and label the result as an estimate until the withdrawal confirms. For historical reporting, use the transaction’s execution block and actual token transfers to record realized amounts.

Does withdrawing liquidity automatically collect fees?

It depends on the pool contract. In reserve-based designs, the withdrawal normally returns a share of current reserves, which already reflect retained fees. In position-based designs, fees may be tracked separately and require a collect operation. Verify the specific contract’s behavior before presenting one combined “withdraw” amount.

Your next step is to write a pool-specific accounting adapter, then validate its estimate against a simulated withdrawal at the same block. Treat Biswap pools according to their deployed contracts and fee rules, and expose separate figures for withdrawable tokens and estimated fee contribution.

How to read arbitrage between Avalanche pools

Gogu — Thu, 22 Oct 2026 08:43:39 +0000

When two pools quote the same pair at different effective prices, compare executable output after fees and price impact; arbitrage trades tend to close the gap only while the spread covers every cost. For a trade you are placing now, check the pair, pool fee, active liquidity and quote size before treating a displayed price difference as an opportunity.

Arbitrage buys the asset where it is cheaper and sells it where it is dearer.
Each trade moves the pool price, so the initial spread overstates the profit available.
Fees, gas and execution risk set the point where correcting the gap stops paying.

What makes two pools disagree?

Each pool prices a pair from its own reserves or active liquidity, and trades update that state independently. In a constant-product pool, reserves x and y follow xy = k, so the marginal price of X in units of Y is y/x; a trade also incurs price impact as it moves along the curve.

A large buy in one pool can lift its X price while another pool remains untouched. Prices can also diverge after a move on another venue, a change in pool liquidity, or simply because the pools serve different order flow. The Uniswap v2 whitepaper sets out the constant-product mechanism; the exact curve and fee rules depend on the pool implementation.

How does an arbitrage trade realign them?

If pool A offers X for less Y than pool B, an arbitrageur buys X from A and sells it into B. The first leg removes X from A and adds Y, raising A’s price; the second adds X to B and removes Y, lowering B’s price. The price gap narrows from both sides.

For example, suppose the two pools initially quote X at 100 Y and 106 Y. A bot does not earn the full 6 Y difference on every unit: buying X makes it progressively more expensive in A, while selling X makes it progressively cheaper in B. The best trade size is where the next unit’s expected spread is consumed by both pools’ swap fees, curve impact and execution costs.

Blackhole Swap gives you the live Avalanche pool route to inspect, so you can check whether a price difference remains at the size you intend to trade. Its pool’s quote is local to that pool state; a price shown elsewhere may use a different pool, route or block. Compare the actual output amounts rather than relying on headline spot prices.

When is the gap large enough to trade?

Use the pool’s configured fee, not a DEX-wide assumption: fee rates vary by pool and can materially change the break-even spread. With two pools charging, say, 0.3% each, a tiny gap is already consumed by roughly 0.6% in fees before price impact or gas; the exact threshold depends on trade size and pool depth.

On Avalanche C-Chain, account for transaction gas in AVAX as a fixed cost against the trade’s expected profit. A route through two pools may execute atomically in one transaction, but another searcher can capture the opportunity first, or a state change can make the transaction revert or return less than your minimum output. Slippage tolerance is your limit on acceptable execution, not a forecast of the trade’s likely price impact.

Angeris and co-authors’ work on constant-function market makers explains why arbitrage aligns pool prices subject to trading costs, rather than forcing exact equality. The residual gap is a no-trade band: when fees, gas and risk exceed the remaining spread, rational arbitrageurs stop, so pools can stay slightly apart.

What should you check before signing?

For an ordinary swap, use the quoted output for your exact amount, check the fee and price impact, and set a minimum received amount that reflects how much movement you can tolerate. If you are evaluating an apparent arbitrage, estimate both legs against current pool state and include gas, token transfer taxes or restrictions, and the possibility that the second venue’s liquidity is concentrated outside the price range you need.

I would trade only when the net spread remains positive after both pool fees, impact and gas, with enough margin for a competing transaction or state change. Otherwise, use the better available quote and leave the cross-pool correction to searchers whose execution costs are lower.

Mantle Bridge Allowances for Repeat Treasury Deposits

Gogu — Thu, 22 Oct 2026 00:04:11 +0000

If your treasury sends the same token from Ethereum to Mantle Network each week, Mantle Bridge needs an ERC-20 spending allowance that can cover those deposits. Approve a defined run of transfers, check the remaining allowance before each deposit, and renew it when the run ends. This avoids paying for an approval every time while keeping the spending cap tied to your plan.

How Does Mantle Bridge Use an Allowance?

The allowance lets a specified Ethereum bridge contract take up to a specified amount of one token from one wallet. Your wallet first submits an approve transaction to the token contract. The later deposit transaction uses that permission to move the tokens into the bridge; approval alone does not send anything to Mantle Network.

Choose Ethereum as the source, select the token and its mapped destination asset, then inspect the spender and amount shown in your wallet. In an Ethereum Mantle bridge deposit, the Ethereum contract draws on that allowance when you confirm the deposit. The Mantle cross-chain bridge then credits the corresponding asset on Mantle after the Ethereum transaction and cross-chain message are processed. Check the destination token contract as well as its ticker, especially for USDT, which can have distinct versions on Mantle.

Allowances belong to a particular wallet, token contract and spender on Ethereum. A second treasury wallet cannot use the first wallet’s approval, and an approval for one token does not cover another. Native ETH deposits do not use ERC-20 approval; an ERC-20 such as Ethereum-side MNT or USDT generally does.

How Much Should You Approve for Repeated Deposits?

Approve the total amount you expect to deposit before the next scheduled allowance review. Suppose your payouts team plans four weekly deposits of 25,000 USDT from one treasury wallet. A 100,000 USDT cap covers that run; after two successful deposits, a standard ERC-20 allowance would have 50,000 USDT remaining.

I would use that fixed cap for a known four-week schedule and renew it at the next review. If an unscheduled fifth deposit matters operationally, a 125,000 USDT cap buys room for it, but also leaves more permission outstanding. An unlimited approval avoids renewals, yet gives the spender continuing access to future balances of that token, so it needs a stronger reason than saving one transaction.

Read the current allowance before setting a new cap. Under the ERC-20 specification, approve replaces the previous value: setting 100,000 when 10,000 remains produces a 100,000 cap, not 110,000. The specification recommends setting a nonzero allowance to zero before changing it to another nonzero value; Ethereum USDT can require that reset. Schedule the reset and new approval when no deposit is in flight, and account for both Ethereum gas transactions.

For each Mantle Bridge run, compare the remaining allowance with the deposit amount before asking signers to act. Record the token contract, spender, approved cap and expected deposits alongside your treasury schedule. That record makes an unexpected approval request or a larger-than-planned deposit visible before anyone signs it.

What Do Approvals and Transfers Typically Cost and Take?

An approval costs an Ethereum transaction fee, while each deposit has its own Ethereum transaction fee. For scale, an illustrative approval using 50,000 gas at an effective price of 10 gwei costs 0.0005 ETH; four such approvals would cost 0.002 ETH, versus 0.0005 ETH for one approval covering four deposits. Actual gas use and gas price vary, so check the wallet estimate when you schedule the run.

Deposits typically become available on Mantle within minutes after Ethereum inclusion and bridge processing, though congestion can extend that wait. Your team also needs ETH on Ethereum for approvals and deposits, plus native MNT on Mantle to move or pay out the received tokens. Do not release a payout batch merely because the approval confirmed: verify the deposit transaction and the Mantle balance first.

Withdrawals reverse the direction, but their timing is set by Mantle’s settlement process rather than your deposit allowance. Mantle Network’s current documentation describes validity proofs verified on Ethereum, with no challenge period after verification. Allow for proof processing and any required Ethereum claim, and use the withdrawal’s claimable status for a treasury deadline instead of assuming it will clear as quickly as a deposit.

What Else Should Your Team Check Before the Next Run?

Check that the intended token is offered for the chosen direction and that the receiving wallet accepts its mapped Mantle token. Have one operator reconcile the Ethereum transaction and destination balance while another checks the next allowance against the schedule. These checks matter most when several staff members can initiate deposits from the same treasury wallet.

Does a withdrawal use the Ethereum deposit allowance?

No. The Ethereum allowance authorizes deposits from that wallet to the specified spender; it does not reserve tokens for a later withdrawal. A withdrawal starts on Mantle, needs MNT for Mantle gas, and may require a separate claim on Ethereum paid in ETH. Plan its timing and fees as a separate treasury movement.

Why does the bridge ask for approval again?

The remaining cap may be below the next deposit, or the wallet, token contract or spender may differ from the earlier run. Check all three before signing. If you are increasing a nonzero USDT allowance, the token may require a zero-allowance transaction first; allow time and ETH for that reset and the new approval.

Should You Split a Large Token Swap on Avalanche?

Gogu — Wed, 21 Oct 2026 22:18:13 +0000

Split a large Avalanche swap only when separate quotes show a better net result after extra fees, or when you need to limit how much trades at one price. For a single pool, splitting one order into several back-to-back transactions usually does not reduce the total price impact; it adds gas and execution steps. Compare the full-size quote with the proposed chunks before acting.

What does splitting a swap actually change?

Splitting changes the size and timing of each transaction, but it does not automatically give you more liquidity. In a pool, a larger trade moves the pool price further; smaller trades sent one after another into that same pool still consume its liquidity in sequence.

For a constant-product pool, the trades’ combined effect is broadly similar to one trade of the same total size, before accounting for changing prices and fees. Splitting can help if chunks reach different pools, or if market conditions change between trades, but either outcome depends on the route and timing—not simply on using smaller amounts.

When is splitting worth the extra transaction?

Split when the expected improvement in execution is greater than the extra network fees and the risk of waiting between transactions. A route that uses several pools may already divide the trade internally; check the quote’s route details before manually sending multiple swaps.

For example, say a $1,000 order’s quote improves by $0.20 when you split it, and an extra transaction costs around $0.05 in AVAX. The apparent $0.15 saving only holds if the second quote remains available and the token price does not move against you while you wait. Avalanche Builder Hub explains that C-Chain fees vary with network conditions; a Snowtrace transaction record is a useful real-world check, but your wallet’s current estimate is the one to use.

How can you compare the options quickly?

Use the same total input and destination token for each comparison, and compare the expected output after fees. On Blackhole Swap, check the full-size quote first, then compare it with the chunk sizes you are considering; the route preview helps show whether a split changes the pools used. Also check the displayed minimum received, since that sets the execution floor for each transaction.

Record the full-size quote’s expected output and minimum received.
Quote each proposed chunk, keeping the total input unchanged.
Add the extra AVAX network fee for every additional transaction.
Compare the net outputs and check whether the chunks use different pools.

For a frequently repeated trade, make this comparison at the size you actually send: pool depth and route selection can change with trade size. Blackhole Swap quotes can also change before execution, so treat the split as worthwhile only if the improvement is larger than the extra cost and small quote movements would not erase it.

What can go wrong when trades are split?

Each transaction is a separate execution, so later chunks may receive a worse rate, fail their minimum-received limit, or arrive after the market has moved. You also pay a network fee for a failed transaction if it was submitted and consumed gas. Keep enough AVAX for all planned transactions, and avoid splitting into so many pieces that fees and monitoring outweigh the potential gain.

A useful edge case is a volatile token with shallow liquidity: splitting over time may reduce the amount exposed to one execution price, but it also leaves the untraded balance exposed to price changes. If you need the full position now, a single transaction with a carefully chosen minimum received may be more predictable than several delayed fills.

Does splitting reduce slippage?

Not necessarily. Back-to-back trades against the same pool still use its liquidity in sequence, while waiting between trades adds price-movement risk. A split helps only if its routes or timing produce a better net output than the full-size quote.

How many chunks should I use?

There is no fixed number that suits every pool or trade. Compare the whole order with two or three practical chunk sizes, then stop if added gas and execution steps outweigh the quoted improvement. If the router already uses multiple pools, manual chunks may add cost without improving the route.

What should I check before sending?

Check the total expected output, minimum received, route, and AVAX fee for every transaction. Confirm the quotes still make sense just before signing, especially if the token is moving quickly. Before acting, ask yourself: does this split improve the net result enough to justify another fee and the time between trades?

Why Is My Cross-Chain Swap Missing From My Wallet?

Gogu — Tue, 20 Oct 2026 14:01:59 +0000

A cross-chain swap moves an asset from one blockchain to another, sometimes changing it into a different token along the way. The key check is the swap’s status: a wallet can hide a token even after the destination transfer succeeds.

Start with the transaction record, not the balance shown on your wallet’s home screen. For example, a Mayan bridge swap can show its destination result in the swap explorer while your wallet still hides the token.

Check the swap tracker first

A swap tracker tells you whether the transfer is still running, finished, or returned to the source chain. Open the service you used and search with the source transaction hash, the long code shown after you submitted the swap.

Read the status and destination details together. “Completed” should include the destination chain and the amount sent; “in progress” means the destination step may still be underway; “refunded” means the funds returned to your original wallet on the source chain.

For instance, if you swapped ETH on Ethereum for SOL on Solana, check that the record names Solana and shows the expected SOL amount. A successful Ethereum transaction alone confirms only that the first step happened.

Use the destination explorer to confirm delivery

If the tracker says the swap completed, look up your receiving address on the destination chain’s block explorer. A block explorer is a public website that displays transactions recorded on a blockchain.

Check the token transfers for an incoming amount and make sure the recipient address matches your wallet. Compare the chain and token too: the same token name can exist at different addresses, and a token on one chain is not automatically the same as one on another.

If the tracker gives a destination transaction hash, search for that hash directly. If it does not, use your receiving address and check its latest activity. The destination record is the deciding evidence that the asset arrived on that chain.

If the transfer arrived, make the token visible

A wallet may not display every token it holds, so check the destination chain and add the token if needed. In MetaMask, switch to the correct network, choose the option to import a token, and enter the token’s contract address.

Get that address from the swap record or the destination chain’s trusted explorer. Check that the token address and chain match before adding it; a name or symbol alone can point to a different asset.

Say the explorer shows 12 units of a token sent to your address, but the wallet balance is blank. If the chain and token address are correct, adding that token should make the existing balance appear; it does not send another transfer.

If it is still running or was refunded

If the tracker says “in progress,” keep checking that same record rather than starting a second swap. Completion time depends on the route and the chains involved, so there is no single wait time that fits every transfer.

If it says “refunded,” check your original wallet on the source chain for the returned asset. You may need that chain’s native token to pay the network fee for another attempt; the fee depends on the chain and current demand.

If the tracker stays unchanged well beyond its stated estimate, use the service’s support channel and provide the source transaction hash. Never share your recovery phrase or private key to get help; neither is needed to check a transaction.

Trust the destination transaction record first: it shows whether your asset arrived, while your wallet only controls how that balance appears.

Swap Receipts: Match Cross-Chain Swaps to Your Tracker

Gogu — Sat, 17 Oct 2026 02:28:31 +0000

If you have swapped coins and your tracker shows a loss, match each receipt to the asset movement before editing anything. A receipt is a record of one transaction on one blockchain, not a complete summary of a cross-chain swap.

A receipt proves a transaction, not the whole swap

Start with the transaction hash, a unique code for finding that transaction on its blockchain. Check the wallet address, network, date, and whether the transaction succeeded. The Ethereum JSON-RPC specification explains that a transaction receipt can include its status, gas used, and event logs—records of actions such as token transfers.

Those details help confirm what happened, but they may not show a neat “you swapped X for Y” summary. The fee is usually paid in that network’s native coin, so record it separately from the amount swapped. A successful receipt also does not prove that every later step on another chain is complete.

Match each chain’s records to one swap

For a cross-chain swap, look for the outgoing asset on the first chain and the incoming asset on the destination chain. A tracker may show these as two separate movements. Compare the wallet addresses, amounts, and timing, then group the matching entries as one swap where your tracker allows it.

For example, say you send 0.01 BTC and later receive 0.25 ETH. Before, your tracker may list a BTC send and an ETH deposit, making your balance history look like a sale and a separate gift. After you match them, record the BTC as the asset given up, the ETH as the asset received, and any network fees as their own costs.

When researching thor swap, the thor swap service is a cross-chain service that moves and swaps crypto across chains in one flow; that context helps explain why the records can appear on different networks. Keep each chain’s transaction hash with the matched entries, since one hash cannot verify activity on every chain.

Fix mismatches before saving the record

If the received amount differs from your estimate, check for a fee, a partial fill, or a second transfer before changing the tracker. A partial fill means only part of the planned swap completed. If the destination transaction is missing, wait for it to appear or check its status on that chain; do not mark the swap complete from the outgoing receipt alone.

Trackers can also mistake your own wallet-to-wallet transfers for income or a sale. Mark a movement as a transfer only when both addresses are yours, and keep the fee attached to the correct chain. This matters when thor swap research leads you to compare a service’s one-flow description with your tracker’s separate chain records.

Use this rule: match by wallet, chain, amount, and transaction hash first, then group the records only when both sides of the swap are verified.

3 route choices for cross-chain swap integrators

Gogu — Fri, 16 Oct 2026 18:01:36 +0000

Choose the route with the best net destination output that meets your latency and failure-risk limits; the fewest hops alone is a weak rule. For an integrator, that means comparing executable quotes and settlement assumptions at the same input size, then rechecking them before submission.

Take the direct route when destination depth is real

A direct route sends the source asset to the destination chain and swaps there, avoiding intermediary execution and settlement. It is best when destination liquidity supports the requested size at acceptable price impact; it does not fit when a thin pool makes the destination swap materially worse than a staged route.

Rank quotes by expected destination amount after all costs: source gas, any approval, bridge or relayer charges, destination gas, and swap impact. Check whether quoted output is fixed or depends on a destination swap, and compare the same slippage tolerance and deadline. A quote that omits a destination transaction is not comparable to one that includes it.

Use one intermediary when it removes a bottleneck

A single intermediary is useful when it has deeper liquidity or a more reliable connection to the destination than the direct path. It adds another settlement boundary and usually another transaction, so it is a poor fit if the extra execution cost or delay erases the output improvement.

Suppose an app routes 10,000 USDC from Ethereum to Base, and its live quote sources offer these candidates:

Ethereum → Base → destination swap
Ethereum → Arbitrum → Base → destination swap
Ethereum → Polygon → Base → destination swap

Compare simulated destination balances, not pool prices in isolation. Include each chain’s gas conversion and the time each leg waits for its required source confirmation; legs may settle sequentially. For an acrossbridge-style flow, acrossbridge serves the user need of moving and swapping crypto assets across chains in one flow, while the integrator still needs to assess which route is suitable for its transaction.

Use multiple hops only when the gain survives risk

Multi-hop routing can reach liquidity unavailable on a direct path, but every hop adds another quote, transaction, and failure condition. Prefer it only when the improvement remains meaningful after all costs and your application’s risk constraints; skip it when the gain is marginal or the user needs predictable completion time.

For example, if the direct route returns around 9,962 USDC and the Arbitrum path around 9,980 USDC after estimated gas, the 18 USDC gain is illustrative, not a reason by itself to route through an extra chain. Price in the possibility of stale liquidity, a reverted intermediate swap, or a source reorg before the next leg is accepted. Ethereum.org distinguishes proof-of-stake finality from probabilistic confirmation, while Chainalysis describes how bridge designs vary; model finality and recovery per leg rather than treating “confirmed” as a universal state.

Set hard limits for minimum output, quote age, and maximum end-to-end time, then discard routes that fail any limit. Re-quote when the input size, pool state, or gas estimate changes. My default is direct execution when its depth is adequate, one intermediary when it clearly improves execution, and multiple hops only for a material, measured gain.

Destination Swap Pools: Why Rebalancing Changes Your Output

Gogu — Fri, 16 Oct 2026 12:28:52 +0000

Pool rebalancing can change how much of your chosen token you receive after a cross-chain transfer. The key is that the bridge’s available inventory and the destination swap pool’s liquidity are separate: the bridge gets assets across, then the destination trade meets the pool’s current prices and depth.

Bridge inventory and swap pool liquidity do different jobs

Bridge inventory is the capital available to deliver an asset on the destination chain; swap pool liquidity is the asset balance available for your destination trade. Rebalancing restores an imbalance in one or both inventories, but it does not guarantee a particular swap price.

Think of a centralised exchange order book: the visible price is not necessarily the price for your full order if there are few offers at that level. An automated market maker, or AMM, quotes from a pool’s token balances instead. For a common constant-product pool, the reserves approximately follow x × y = k, so a larger trade shifts the price more as it takes tokens out of the pool.

When a bridge route pays users from destination-side funds, those payouts can leave its inventory short of the asset being sent. A provider may later rebalance by moving funds or making trades. That bridge activity is separate from traders buying or selling against the destination DEX pool, though both can affect the route’s final result. When comparing a wallet-to-wallet route such as ParaSwap, check whether its destination leg is a swap against a pool, because that leg’s depth helps determine what arrives.

Rebalancing changes the price available when your trade executes

A destination swap uses the pool state at execution, not the state you saw when you first considered the route. If a pool has ample liquidity near the quoted price, a modest trade may barely move it. If its relevant reserves are thin, or other traders have already moved them, your trade can receive less than the earlier estimate.

For example, say a route is expected to deliver 10,000 USDC on Arbitrum, where you want ETH. Before other trades, the destination pool might quote 3 ETH. If traders buy ETH from that pool while the bridge transfer is in flight, the pool has less ETH and more USDC; your 10,000 USDC now buys less ETH. If liquidity is later restored or arbitrageurs trade the price back toward other markets, the quote may improve again. These figures are illustrative: the actual change depends on pool depth, trade size, and intervening transactions.

That is why rebalancing is not simply “more liquidity means a better price.” A provider restoring bridge inventory may trade on a different chain or in a different pool. The execution price for your destination swap depends on the specific pool and route used for that leg, plus any other pools in a multi-hop trade.

Quote age and minimum output decide what happens next

A quote is an estimate based on conditions at a moment; a minimum output is the least amount you agree to receive for the swap. The gap between the expected output and that minimum is your slippage tolerance. A wide tolerance makes execution more likely after prices move, but accepts a worse result; a narrow one protects the price but may cause the destination swap to fail.

Before signing, compare the expected destination amount with the minimum, and consider how long the route may take to reach the destination swap. The longer the wait and the more active the pool, the more chance its reserves will change. A small trade in a deep pool usually has less price impact than a large trade in a thin one, even if both quotes were checked at the same time.

There is also an edge case: the bridge transfer can succeed while the destination swap cannot meet its minimum output. Depending on the route’s design, the destination asset may then be returned in the bridge asset or another fallback form. Check what the route says will happen on a failed swap, and make sure you can use the asset that could be returned.

Check the destination leg before sending

Look at the destination token, expected amount, minimum output, and whether the route splits the trade across pools. A split can reach more liquidity, but the combined result still depends on each pool’s current state. For a route ending on Arbitrum, confirm that the output is the token you intend to hold there, rather than relying on the source-chain amount alone.

Compare the quoted output with the minimum output.
Check the destination chain and token.
Consider whether your trade is large relative to the pool’s liquidity.
Review the route’s fallback if the destination swap fails.

For the practical move, use paraswap.pro to bridge your source asset and swap into the destination token in one cross-chain flow.

ParaSwap is relevant when you are planning that combined move, because understanding the destination pool helps you judge the output you are agreeing to receive. Recheck the quote close to signing if the pool is active or the transfer may take time.

Pool rebalancing can shift destination swap prices while your transfer is underway, so judge a route by its destination pool, minimum output, and fallback—not by the source amount alone.

How to Swap Bridged Zcash Into Stablecoins When It Sticks

Gogu — Fri, 16 Oct 2026 07:41:03 +0000

To swap bridged Zcash into a stablecoin, check which of two steps is pending: getting the wrapped ZEC onto a smart contract chain, or swapping it there. RenBridge was discontinued in 2022, so it cannot start a new transfer; if you already hold renZEC, your next step depends on its chain, token contract and available trading liquidity.

Where is the transaction stuck?

A Zcash transfer and a token swap happen on different networks, so a delay in one does not necessarily mean the other failed. Bridging historically meant sending ZEC to a gateway, waiting for the network to verify the deposit, then receiving a token such as renZEC on Ethereum or BSC. A decentralized exchange (DEX) could then trade that token for a stablecoin on the same chain.

Start by finding the transaction hash for the step you submitted. Check its status on the relevant chain’s explorer, and compare the destination address and network with the ones you intended to use. If the source transfer is confirmed but no wrapped token arrived, the bridge leg is the issue; if the wrapped token arrived but the swap did not, investigate the DEX transaction instead.

A short explanation of how RenBridge moved Zcash to Ethereum helps distinguish a historical deposit from a route that can still process one. RenBridge is no longer operating, so a new deposit cannot be completed through it; an old confirmation or saved transaction page does not make the service live again.

What should you check before retrying?

Confirm these details before sending more funds or repeating a swap:

Source status: Is the Zcash transaction confirmed, and did it go to the intended deposit address?
Destination chain: Is your wallet set to the chain where the wrapped token exists?
Token identity: Does the token contract match the asset you meant to receive? A matching ticker alone is not proof.
Swap outcome: Did the DEX transaction fail, or did it succeed with a different output than expected?
Gas: Is there enough of the destination chain’s native coin to submit another transaction?

This check catches a common edge case: a wallet can show a token balance on the wrong network, or hide a valid balance because the token was never added to its display. Switching the wallet’s network and checking the contract balance on an explorer can separate a display problem from a failed delivery.

How do you choose a safe next route?

If renZEC is already in your wallet, first establish whether there is real, usable liquidity for that exact token on that exact chain. A token with a familiar name may be an unrelated asset, and a thin pool can produce severe price impact or leave a swap unfilled. Check the contract address against a reliable record, then compare the quoted output with the pool depth before trading.

For example, suppose you have renZEC on Ethereum and want a dollar-pegged stablecoin. If a verified pool has enough depth, swap only the amount you need and review the minimum output shown by the transaction before signing. If there is no credible pool, do not keep raising slippage: look for a supported conversion route or hold off until one can be verified. A cross-chain bridge-and-swap service can move and swap supported assets across chains in one flow, but use it only if it explicitly accepts your asset and chain.

Record the transaction hash and identify the chain where it was submitted.
Confirm whether the wrapped ZEC reached your address; do not resend a deposit that is already confirmed.
Verify the token contract and check for a live pool with enough liquidity for your trade.
Submit a swap only after reviewing its stablecoin output and minimum received amount.
If the swap succeeded, check the stablecoin balance on that same chain before planning any further transfer.

If a swap failed on-chain, the spent gas is generally not returned, but the input tokens should remain in your wallet unless the transaction actually succeeded. If the bridge deposit is the stuck leg, avoid sending a second deposit to an old RenBridge address; confirm what happened to the first transaction before choosing another route.

Questions to settle before you act

Can I still use RenBridge to mint renZEC?

No. RenBridge was discontinued in 2022, so it cannot process a new ZEC deposit or provide a fresh mint. If you already hold renZEC, treat it as an existing wrapped token and check its current chain, contract and liquidity. Do not assume that historical instructions or an old interface can complete a transfer today.

How long should I wait on a pending swap?

There is no single wait time for every chain or transaction. First check whether the transaction has been included in a block and whether it succeeded. A wallet spinner is not proof of progress. If the transaction is confirmed as failed, waiting will not retry it; if the source transaction is confirmed but a bridge delivery is missing, investigate that bridge leg before acting.

What determines how much stablecoin I receive?

The amount depends on the pool’s price, its liquidity, the trade size and transaction costs. Thin renZEC liquidity can mean a large price impact, so a displayed estimate may differ from the minimum output you accept. Compare the expected stablecoin amount with the pool depth; if the trade would move the price sharply, reduce the size or wait for a better route.

When should I choose a different route?

Choose differently if your token is not verifiably renZEC, the pool is inactive or too shallow, or the route requires a bridge that no longer operates. In those cases, preserve the transaction details and avoid speculative deposits. I would proceed only when the asset contract, destination chain and conversion liquidity all match; that evidence is what changes a retry into a sensible next step.

BTC to ETH Swap: Estimate What You’ll Receive

Gogu — Fri, 16 Oct 2026 01:29:27 +0000

A BTC-to-ETH swap estimate starts with the quoted amount of ETH you will receive. Before sending, check which costs the quote includes and whether the price can change while your Bitcoin transaction confirms.

Your received amount depends on the route and its costs

A cross-chain swap moves value from one blockchain and exchanges it for an asset on another. The route may account for network fees, the exchange rate, and the cost of completing the swap. A network fee pays for processing a transaction on a blockchain; it can change with demand.

Price impact is the change in exchange rate caused by the size of your trade and available trading liquidity. Slippage is the difference between the quoted rate and the rate when the swap executes. A quote may include some costs in its displayed amount, so use the net amount you are told to receive rather than subtracting those costs twice.

Biswap BTC to ETH swap gives a concrete example of a cross-chain service handling the move and exchange as one intended flow. For your own estimate, compare the final ETH amount with what you would expect after fees and possible price movement.

A quick calculation gives you a useful check

Use the quoted market prices to estimate the result, then allow for any costs or rate movement not already included. Say you swap 0.01 BTC when BTC is around $60,000 and ETH is around $2,500: the starting value is about $600, or 0.24 ETH before costs.

For example, if the route costs $4 in network fees and $3 in other charges, $593 remains. Divide $593 by $2,500 to get 0.2372 ETH. If the rate then moves against you by around 0.5%, the result is about 0.236 ETH. These figures are illustrative; use the quote’s own prices and charges.

For a practical check, compare these items with the quote:

The BTC amount you intend to send.
The estimated ETH you expect to receive.
Any network or route costs not included in that estimate.
The exchange rate or slippage allowance used.

Bitcoin confirmation time can change the estimate

A quote is based on prices at a particular moment, but Bitcoin transactions need confirmations: blocks added to the network that show the transaction has been recorded. If confirmation takes long enough for the quote to expire, the route may need a fresh price, and the ETH estimate can change.

Before sending, check how long the quote is valid and what happens if it expires or the route cannot complete. If the expected ETH amount changes, pause and compare the new amount with your calculation before proceeding. The useful figure is the ETH you expect after included costs, with room for price movement during confirmation.