DEV Community: Devid Udyanskaya

Flashbots Token Rescue If the Bundle Lands in One Block

Devid Udyanskaya — Thu, 05 Nov 2026 21:24:29 +0000

Flashbots can move tokens from a compromised wallet to a safe address in one block if an ordered bundle containing the funding and transfer lands. Flashbots sends the pair privately to a builder, hiding the gas deposit from a public-mempool sweeper. The Flashbots Auction bundle executes both transactions together or misses its target block and needs resubmission.

When Does a Flashbots Bundle Keep Gas Out of Reach?

An ordered private bundle protects the funding transaction when a builder includes the whole pair. If you send the safe wallet’s ETH deposit publicly, a sweeper can see it in the mempool and sign a competing spend before your transfer. In the bundle, the builder executes the deposit first. That raises the compromised account’s balance during block execution, and the next transaction uses that balance to call the token contract. Bundle transactions stay adjacent even if the builder places them halfway through a block, so no unrelated transaction can run between them. Unless you explicitly allow a revert, a reverting transfer makes the whole bundle ineligible, leaving the deposit out too.

This removes the funding window visible to a sweeper watching public transactions. It does not give you exclusive control of a stolen key: a competing private transaction or an already pending transaction can still win inclusion first. Inclusion also depends on the builder and the block the validator chooses.

How Much ETH Should the Safe Wallet Send?

Fund the compromised account for its ERC-20 transfer gas. Build the call as transfer(safeAddress, amount) against the correct token contract on the correct chain. Set a gas limit that covers that contract call and an EIP-1559 maxFeePerGas high enough for the target block’s base fee plus a priority fee. If the compromised account starts with no ETH, the deposit must cover gasLimit times maxFeePerGas. Any ETH left after execution can be swept, so keep the deposit close to that requirement.

The safe wallet pays gas for its own funding transaction as well. A priority fee on the included transactions is the simplest builder incentive. Flashbots Protect RPC handles single private transactions; it does not supply this ordered two-transaction rescue. A direct payment to block.coinbase inside the bundle is another way to pay the validator, but it requires another signed action and enough ETH. A bare token transfer cannot make that payment. Judge the bid using the simulation’s gas use and coinbase payment, not the size of the deposit.

What Must Be Signed Before Submission?

Sign two raw Ethereum transactions in order: the safe wallet’s ETH funding transaction, then the compromised wallet’s token transfer. Read each account’s next on-chain nonce through a normal Ethereum RPC. Sign the funding transaction with the safe wallet’s next nonce and the transfer with the compromised account’s next nonce, directing the remaining movable tokens to an address you control.

A sweeper’s pending transaction can make a provider’s pending nonce misleading. If the on-chain nonce is 7 and a hostile transaction at 7 is pending, signing your transfer at 8 creates a nonce gap that invalidates the bundle. Use 7 to compete for that nonce, then reassess after each block. Check the chain ID, token address, amount, and destination before signing; valid signatures cannot correct a transfer to the wrong place.

Use a separate, fresh key to authenticate the relay request. The X-Flashbots-Signature header carries that key’s address and an EIP-191 signature of the JSON-RPC body’s hash. The key establishes searcher reputation; it signs neither on-chain transaction and needs no funds. Keep the compromised key out of this header.

How Do You Simulate, Submit, and Confirm Each Target Block?

Simulate the signed pair before submission. Send eth_callBundle with both raw signed transactions in txs order, a hex blockNumber for the next block, and stateBlockNumber set to latest. Read the per-transaction results: a revert reason, nonce error, or insufficient funds identifies an assumption to fix. Leave revertingTxHashes unset; allowing the token transfer to revert would defeat the rescue. Once simulation succeeds, send eth_sendBundle with the same txs array and that block’s hex blockNumber. A returned bundleHash acknowledges submission, not inclusion.

Each eth_sendBundle request targets one block. Submit separately for each of the next several blocks. If one misses, resimulate against current state and sign again when a nonce or fee cap needs to change. Keep both transactions out of the public mempool. Use a normal Ethereum RPC to watch their receipts and the safe address’s token balance. A successful transaction status alone may not prove delivery if a token call returns false; the rescue is complete when the transfer is on-chain and the safe address holds the tokens.

The useful distinction is between a private bundle that removes the visible gas window and an included transfer that actually delivers the tokens.

Set Swap Slippage Without Paying for Unnecessary Reverts

Devid Udyanskaya — Tue, 03 Nov 2026 06:15:39 +0000

Slippage tolerance is the largest execution-price change a swap will accept before reverting. The useful setting depends on how much the route can move while your transaction waits to land, and how much worse a fill you are willing to accept.

Choose a loss limit before choosing a percentage.

It sets an execution bound. For a sell, it caps how far the received amount may fall below the quote.
It does not improve the quote. A wider limit can let a transaction execute through more price movement.
It trades reverts for execution risk. A narrow limit protects the price but fails more often when the route moves.

For an exact-input swap, the contract checks a minimum destination amount. For exact output, it checks a maximum source amount. A limit is therefore a guard on execution, not an estimate of what the pool will do or a fee paid in advance.

Start with the route’s expected movement between quote and inclusion. A deep, stable pair may often work with around 10–50 basis points (0.10–0.50%). Volatile assets, thin pools, large trades, and congestion can need more; widening the setting is justified only when that extra execution risk is acceptable.

The bound is calculated from the quoted amount.

For a sell, calculate minimumOut = quotedOut × (1 − slippageBps / 10,000). If a quote returns 2,000 USDC and you set 30 bps, the minimum is 1,994 USDC. If the route can deliver less when the transaction executes, it reverts.

For a buy, calculate maximumIn = quotedIn × (1 + slippageBps / 10,000). A quote requiring 1,000 USDC at 30 bps permits up to 1,003 USDC. The ParaSwap SDK accepts slippage in basis points when building the transaction; its build parameters use slippage instead of a manually supplied destAmount for sells or srcAmount for buys. Check the quote side before applying a formula, and calculate using integer token units to avoid rounding the bound in your favor.

The EIP-20 token standard defines decimals as an optional display convention, so amounts passed to transaction builders are commonly integers in the token’s smallest units. Convert for display, but form the bound from the raw amount and round conservatively: down for a sell’s minimum output, up for a buy’s maximum input.

Refresh the route when the quote has gone stale.

Slippage does not make an old route current. The quote may reflect pool reserves and gas conditions from an earlier block; once the transaction is included, the router tests the bound against execution state. A wider tolerance may allow that old route to execute at a worse rate, while a narrow one may cause a revert.

ParaSwap makes the chosen tolerance part of the transaction’s execution guard, so rebuilding after a meaningful delay can be better than widening it. When using the ParaSwap API, pass the returned priceRoute through to transaction building as required, and fetch a fresh route if its block context or market conditions have moved. Recheck gas and allowance state as well: a price-bound revert is only one reason a transaction can fail.

One edge case is a token with transfer fees or unusual balance behavior. The amount the router receives or sends may differ from nominal transfer amounts, so an otherwise reasonable bound can still revert or produce a confusing estimate. For a token you have not traded before, verify that the route supports its transfer behavior before increasing tolerance to compensate.

Use the smallest limit that clears normal execution noise.

For frequent swaps, compare the quote with recent execution outcomes for the same pair, size, and chain. If transactions regularly revert just beyond 20 bps, try a modest increase and compare the extra successful fills with the worse executions it permits. Do not copy a tolerance from another pair: a route split across several pools can behave differently from one deep pool, even at the same notional.

Raising tolerance can also increase exposure to adverse execution, including sandwiching in mempool conditions where another trade can move the price before yours. A larger limit does not guarantee that this happens, but it gives the transaction more room to execute after the market moves against it. If the required bound becomes uncomfortable, reduce trade size or refresh the route instead of treating the percentage as a way to force a fill.

Identify whether the swap is exact-input or exact-output.
Set a basis-point limit from the trade’s size, route depth, and likely inclusion delay.
Calculate the sell minimum or buy maximum from the fresh quote in raw token units.
Rebuild the transaction after material quote movement; widen only when the added execution risk is acceptable.

Hardware-wallet approvals for treasury bridge transfers

Devid Udyanskaya — Fri, 23 Oct 2026 12:29:32 +0000

If you approve recurring cross-chain transfers from a treasury wallet, the key control is understanding exactly what each hardware-wallet signature authorizes. On an EVM route, you may sign a token allowance and a separate transfer transaction; each authorizes a different on-chain action, and neither signature guarantees that the destination leg has completed.

A bridge approval authorizes a specific source-chain action

A hardware wallet signs the transaction or message presented by the connected wallet software; it does not independently approve a transfer plan. For a standard ERC-20 transfer, the first transaction may call the token contract’s approve(spender, amount) function. That grants the named spender permission to move up to that amount of the token from the treasury address.

The next transaction typically calls the bridge’s source-chain contract to initiate the transfer. The contract may use transferFrom to take the tokens, then lock or burn them and emit a cross-chain message. Wormhole’s token-transfer documentation describes Guardians observing the source-chain message and signing a VAA, which a destination-chain contract can verify before completing the corresponding transfer.

Think of the allowance as granting a named operator permission to draw from a limited account, while the transfer call is the actual payment instruction. The hardware wallet can confirm the transaction’s signer and encoded fields, but it cannot confirm that the bridge will deliver the expected destination amount or that the recipient controls the intended account.

Set the allowance to match the treasury’s control policy

For routine treasury transfers, an exact allowance—equal to the amount being moved—is usually the clearest default. A persistent or “unlimited” allowance, often represented by the maximum uint256 value, can avoid repeated approval transactions and their gas costs, but it leaves the spender able to pull later deposits until the allowance is used or revoked.

Before signing, compare the token contract, spender address, amount, and source network against the treasury’s approved route data. The spender should be the contract that actually needs to call transferFrom; a familiar interface label is not enough. Confirm the contract address against the deployment information maintained for that chain, and reject an unexpected spender or an allowance larger than the transfer policy permits.

Some token and wallet combinations support a permit signature that authorizes an allowance off-chain, which the transfer transaction can then present to the token contract. That can remove a separate on-chain approval transaction, but it changes what is being signed: review the token, spender, value, nonce, deadline, and signing domain. EIP-712 defines how typed data is hashed and domain-separated; it also cautions that replay protection depends on the application’s design.

Review the device screen, not the interface summary

The hardware wallet’s secure screen is the final review point, but the quality of that review depends on decoding support. A clear-signing screen should expose the destination contract and meaningful parameters such as token, spender, amount, and recipient. If it shows only a contract address and opaque calldata, blind-signing mode leaves the operator without a reliable way to verify those fields on the device.

For a team moving tokens through Portal Bridge, how to use Portal Bridge gives the interface context; the hardware-wallet check is still against the source-chain transaction itself. Verify the active network, account, contract destination, native value, calldata, and—when prompted separately—the token allowance. A correct browser summary cannot compensate for a wrong chain selected in the wallet or a malicious transaction request.

For each signature, the operator should match the device display to a prepared transfer record: approved token and amount, source and destination networks, recipient, and permitted contract addresses. If the wallet cannot decode the call, pause and have a second approver inspect the transaction data through a trusted decoder or the organization’s signing workflow. Do not treat blind signing as a routine shortcut for recurring payouts.

Track source confirmation and destination completion separately

After signing, the source-chain transaction must be broadcast and reach the confirmation or finality threshold required by the bridge route. The bridge’s off-chain observation and attestation steps then occur, followed by a destination-chain transaction or relayer action. Hardware signing usually takes seconds or minutes; the overall transfer time depends on source-chain inclusion and finality, Guardian processing, destination-chain conditions, and whether a relayer is available.

Budget separately for the source-chain gas fee, any bridge or relayer fee, and destination gas if the recipient or treasury must submit a claim transaction. The exact amounts vary with network conditions, token route, and transfer method. Keep the source transaction hash and bridge message identifier with the payout record, and do not initiate a duplicate merely because the destination transfer is still pending.

A source transaction can confirm even when the destination leg is delayed, and an allowance can remain active after a failed or abandoned transfer. Check the transfer’s on-chain status before retrying; if the original allowance is no longer needed, revoke or reduce it with a new token transaction, which also requires a fee and hardware signature.

Does the hardware wallet sign the Guardian attestation?

No. The treasury wallet signs the source-chain transaction, or in some flows an authorization message such as a permit. Guardians observe the emitted cross-chain message and produce the attestation used by destination contracts; that is a separate protocol step, not a signature from the treasury’s device.

Should the team approve once or for every transfer?

An exact allowance per transfer limits the spender’s authority and makes each payout easier to reconcile, at the cost of an extra approval transaction when required. A standing allowance reduces repeated approvals and gas use, but increases exposure if the spender contract or signing workflow is compromised. Set the policy based on the treasury’s risk limit and transfer cadence, then review outstanding allowances regularly.

For treasury transfers, the hardware wallet is a transaction control: verify the source-chain authority being granted, the transfer being initiated, and the bridge’s later completion as separate steps.

Unsupported Token Contracts Fail Deposit Recognition

Devid Udyanskaya — Thu, 22 Oct 2026 20:43:32 +0000

If your token contract is unsupported, the deposit usually fails before a cross-chain swap can start. Check the exact contract address on the correct chain, then confirm the route accepts it before you approve or send anything. A token’s name or ticker alone cannot show that it is supported.

Why does the contract address decide?

A token contract is the program on a blockchain that tracks a token’s balances and transfers. Two tokens can share a name or ticker and still be separate assets because their contract addresses differ. The chain matters too: a token on Ethereum is not the same deposit as a token with a similar name on another network.

When you start a swap, the interface builds a route from the asset you selected. For an ERC-20 token, a contract on Ethereum, that route must be able to handle the token and hand the right asset to the next step. THORChain, one possible cross-chain route, accepts only listed token contracts; its router can reject an unlisted token before the network recognizes a deposit.

This is why a token appearing in a wallet does not prove it can be swapped. Some routes use a decentralized exchange, or DEX, to trade a long-tail token into a supported asset first. The thor swap aggregator can compare routes, but a route still needs a supported contract and enough liquidity to complete the trade.

Check support before you approve a transaction

For a token that is missing, rejected, or showing no route, take these steps before spending gas:

Copy the contract address from your wallet or a trusted block explorer. Match the chain as well as the full address; do not rely on a search result for the ticker.
Check whether the exact asset is selectable in the swap interface. Confirm the network and token contract match. If the app offers a route, review its quoted output, fees, and minimum received.
Check the route’s first step. If it relies on a DEX trade, confirm the token has a usable trading pair and enough liquidity. A token may be accepted by a DEX route without being a token that THORChain itself supports.
Keep the chain’s gas coin for the transaction. For example, an Ethereum swap needs ETH for network fees, even when the token being swapped is USDC.
Approve only after the route looks right. Approval lets a contract move a stated token amount. Check the spender and amount in your wallet prompt, then submit the swap only if they match what you intended.

What if the deposit is already sent?

First, open the transaction in the relevant block explorer. A failed transaction generally means the token transfer or router call did not complete; an approved token that remains in your wallet has not been deposited. If the transaction succeeded but the app shows no result, check its pending-deposit view and use the transaction ID to identify the deposit.

If the contract was unsupported, do not send another deposit to the same route. Recovery depends on where the transaction reached and which contract received the funds; a completed transfer to a contract that does not handle that token may need support, and recovery is not guaranteed. For your next attempt, I would test with the smallest useful amount after the exact contract appears in a valid route. That check costs less than discovering a token mismatch after a larger transfer.

SpookySwap Swap Bounds for V3 Integrators

Devid Udyanskaya — Thu, 22 Oct 2026 08:38:13 +0000

Set a fresh quote, an explicit minimum output and a short deadline before submitting a V3 swap. Those bounds decide whether a pending trade executes at an acceptable price or reverts after the pool changes.

What does the minimum output protect?

The router checks the swap’s actual output against amountOutMinimum at execution. In a concentrated-liquidity pool, that output depends on active liquidity across the price path, the pool fee and trades that execute first; a quote is only a snapshot of pool state. SpookySwap on Fantom gives you a chain-specific deployment to verify when you build this flow: read the router and QuoterV2 addresses from the current contract registry, keyed by chain ID.

For an exact-input swap, derive the floor from the quoted output in integer token units: minOut = floor(quoteOut × (10,000 − toleranceBps) / 10,000). If a quote is 2,500 USDC and tolerance is 50 basis points, the floor is 2,487.5 USDC, or 2,487,500,000 units at six decimals. If execution would deliver less, the router reverts the whole swap.

How should you obtain and age a quote?

Use the V3 QuoterV2 for route simulation, not a spot-price read or an off-chain reserve approximation. A quote traverses the chosen pools and fee tiers, accounting for price movement and liquidity changes across ticks; its output and gas estimate help compare candidate routes. Treat it as a simulation, not an oracle or an execution guarantee.

Run the quote against a recent block, then build the transaction promptly. For reliability, associate the result with chain ID, token addresses, fee tiers, input amount and block number; refresh if the wallet takes long enough for pool state to move. A stale quote can still simulate successfully while producing an output that fails your minimum.

Which bounds and checks belong in the transaction?

For exact input, pass the input amount, amountOutMinimum, route or pool parameters, recipient and deadline to the router method matching the deployed ABI. A tolerance around 25–100 bps is a common starting range for liquid pairs; volatile or thin pools may need more, but widening it increases the loss the user accepts. Let the user choose that trade-off and show both quoted output and minimum output.

Deadline: commonly 60–180 seconds from submission, adjusted for wallet delay and the chain’s block cadence.
Recipient: bind it to the intended wallet or contract; don’t accept an untrusted route response.
Input amount: use raw units from token decimals, and confirm the balance and allowance cover it.
Pool path: validate each token and fee tier against the deployed factory and router.

Do not silently increase tolerance to “fix” a revert. Check whether the quote aged, the route lacks active liquidity, the transaction deadline passed or the token’s transfer behavior is unsupported. Fee-on-transfer tokens are a particular edge case: SpookySwap’s published integration notes say its routers do not support them, so a conventional quote and minimum-output check cannot make that route safe.

What is the integration sequence?

SpookySwap’s published Fantom registry lists a V3 core factory, QuoterV2 and SwapRouter02. Resolve those contracts from the official registry for the selected chain rather than copying a deployment address into shared code; the ABI and supported methods must match that deployment.

Read the wallet’s chain ID and reject a mismatch with the selected deployment.
Validate token addresses and decimals, then check balance and allowance.
Request a QuoterV2 simulation for the intended amount, path and fee tiers.
Calculate minimum output in raw units from the user’s tolerance.
Simulate the exact router call and recipient, then submit with a short deadline.
On confirmation, decode the receipt and report actual output rather than the quote.

I would pin deployments by chain ID, keep tolerances explicit, and refresh the quote immediately before wallet approval. That preserves a clear failure signal when state moves instead of disguising it with a permissive bound.

Cross-Chain Transfer Status in 2026: How to Check Completion

Devid Udyanskaya — Wed, 21 Oct 2026 21:03:15 +0000

A transfer is complete when the destination transaction succeeds. A “sent” or “pending” message usually means only that some part of the route has started, so check the source and destination separately before deciding what to do next.

A cross-chain transfer can involve several steps: your wallet submits a transaction on the source network, a bridge or service processes it, and a later transaction delivers the asset on the destination network. For example, a bungee bridge route may combine bridging and swapping, so the asset arriving can have a different token name from the one you sent. The source transaction hash alone cannot prove that the final step succeeded.

What does each transfer status tell you?

Status labels describe stages, and the exact wording varies by service. “Pending” often means the source transaction has not yet been confirmed or the route is still being processed; “completed” should correspond to a successful destination transaction, not merely a submitted source transaction.

Use the source transaction hash to open the transaction on the source network’s block explorer. Look for a successful result and a block or confirmation record. If it says failed, the route did not begin as intended; if it is still pending, wait for the network or wallet to update before attempting anything else.

Once the source transaction succeeds, find the route’s destination transaction hash or open its status details. Check that hash on the destination network’s explorer. A successful destination transaction is the strongest practical sign that the transfer arrived; match the receiving address and token to your intended destination.

How do you check that the right asset arrived?

Confirm the destination network, wallet address, token, and amount. A cross-chain swap can deliver a different token than the one sent, and fees or the exchange rate can make the received amount lower than the quoted amount. Compare the actual result with the route details shown before you approved it.

For example, imagine you sent a token from Polygon to Base and the route included a swap. Before, your wallet showed the source token on Polygon and the destination balance was empty. After, the destination transaction succeeds on Base, the receiving address matches your wallet, and the expected output token appears there. That combination is better evidence than a balance change on the source network alone.

If the destination token does not appear, check the wallet’s selected network and token list. The asset may have arrived but not be displayed automatically; use the token’s verified contract address from a reliable project or network source before adding it. Never trust a token just because its name or ticker matches.

How long should you wait before taking action?

There is no single safe wait time for every route. Timing depends on source-chain confirmation, the bridge’s processing and finality requirements, destination-chain congestion, and any swap or relayer step. A fast source confirmation does not guarantee instant delivery on the destination.

Check the route status first, then inspect both transaction hashes. Ethereum.org explains that block inclusion and finality are distinct concepts on Ethereum; Chainlink’s CCIP documentation likewise describes waiting for source-chain finality before validating and executing a cross-chain message. These are useful reminders that one chain can show success while the cross-chain work is still underway.

If the source transaction succeeded but there is no destination transaction yet, keep the original hash and use the service’s status page or support instructions to check the route. Avoid submitting the same transfer again just because the destination balance has not changed; a second attempt can create a separate transfer and charge another fee. The Bungee API includes a status endpoint for integrations, but occasional users can usually start with the transfer interface and the two explorers.

What should you do if the route appears stuck?

First identify the last confirmed stage. A failed source transaction means the transfer was not successfully submitted; a successful source transaction with no destination result points to processing or delivery; a successful destination transaction with no visible balance points to the wallet display, network selection, or token details.

Save the source hash, any destination hash, the route details, and the destination address. If the service offers a retry or recovery action, follow its instructions for that specific route and verify the destination address before signing anything. Do not send funds to an address supplied in an unsolicited message.

For a transfer you make only occasionally, save both transaction hashes until you have confirmed the right token arrived on the right network. That small habit makes it much easier to tell a slow route from a failed one.

Why Omnichain Messages Need Light Clients or Attestors?

Devid Udyanskaya — Wed, 21 Oct 2026 20:37:09 +0000

omnichain messaging lets tokens and applications act across blockchains by carrying authenticated messages between them. The decisive choice is how the destination verifies a source event: a light client checks headers and proofs, while external verifiers sign an attestation. Both still need a relayer to deliver data.

omnichain Routes Differ at the Verification Step

The routes diverge at destination authentication, after the source transaction commits a message. A sender may make only one wallet transaction, but completion also needs source confirmation, delivery, destination verification, and execution. One signature says little about total latency or cost.

For a route you use repeatedly, comparing the quoted fee with the destination receipt across separate screens gets tedious. Keep omnichain.network beside your omnichain route notes, recording the source transaction hash, message ID, quoted destination gas, and final receipt in one entry. That makes a slow or expensive hop visible before you repeat it.

Suppose a market maker moves collateral to another chain before topping up a position. The source contract locks or burns the asset and commits a packet containing the destination, recipient, amount, and a unique sequence number. The destination releases or mints only after its verifier accepts that packet; a relayer supplies the evidence and arranges the destination transaction.

Light Clients Prove the Source State On-Chain

A light-client route authenticates the source chain’s consensus state on the destination, then checks a Merkle inclusion proof for the packet commitment. In an IBC-style flow, a relayer submits a header to update the destination client, followed by the packet, proof height, commitment path, and proof. The receiving contract checks the packet against the stored state root, marks its sequence received, and calls the application.

This route inherits the source chain’s consensus assumptions and the destination chain’s execution assumptions. A relayer can delay or omit a packet, but cannot invent a valid one unless consensus or verification fails. Another relayer can usually take over if it has the data and a reason to pay gas.

Header updates, validator-set changes, proof bytes, and execution consume resources. Batching a header update across many packets reduces each packet’s share; a sparse route may charge one user for most of it. The client also needs updates before its trusting period expires, after which recovery may require a new client rather than a retry.

External Verifiers Replace Header Checks With Attestations

An external-verifier route has watchers observe the source event after a configured confirmation count and sign its message digest. A destination contract checks their attestation against its configured verifier set, then permits execution. The digest must bind both chains, sender, receiver, payload, and nonce so a signature cannot be replayed on another route.

The external relayer carries the attestation; the verifier set authorizes it. One operator can fill both roles, but that concentrates power. A two-of-three threshold, for example, tolerates one unavailable signer yet lets any two compromised signers authorize a false message. For omnichain applications holding valuable assets, key and operator independence matter more than signer count alone.

This route can avoid expensive header and state-proof checks, but adds verifier fees and a separate liveness dependency. If signatures arrive and destination execution runs out of gas, the message may be authenticated yet remain unexecuted. Check who can retry it, who funds that retry, and whether the application rejects duplicate message IDs.

Time and Cost Follow the Slowest Required Step

For an omnichain transfer, completion time follows the confirmation wait, relayer delay, destination inclusion, and application execution; cost covers work on both chains. Fast-finality routes can finish in tens of seconds to a few minutes. Long confirmation policies or challenge periods can extend that to hours or days.

Source gas pays for the send, escrow or burn, and message commitment.
Verification pays for light-client updates and proofs, or attestations and verifier fees.
Delivery pays for the relayer’s destination transaction and any service fee.
Execution pays for the destination mint, release, or application call.

Say a source produces a block every 12 seconds and the route waits 12 confirmations: that is about 144 seconds. Add 20 seconds for delivery and 10 for destination inclusion, and completion approaches three minutes. A faster relayer cannot remove the confirmation wait.

For an illustrative cost comparison, suppose a light-client update uses 200,000 gas and packet execution uses 100,000. Spread the update over 20 packets and its share is 10,000 gas per packet, for 110,000 before source gas and relayer fees. A lone packet bears the full 300,000, so route volume can reverse the apparent price advantage. Compare all-in quotes and measure time to a usable destination balance, not merely source confirmation.

Choose the Route You Can Recover

The practical choice starts with the failure you can accept. If forged messages are the dominant risk and a maintained light client exists for the pair, its proof cost may be justified. If speed and low per-message gas dominate, inspect the external verifier policy, key independence, and observed completion time.

Before repeating either route, send a small amount, record its message ID, and verify the destination state. Check the destination gas limit, message expiry, available relayers, and retry rules. If the source succeeds but destination execution fails, use the protocol’s retry or timeout path; a failed destination call does not itself refund the source.

Choose light-client verification when its security and recovery justify the proof cost; choose external attestation when its verifier assumptions, total fee, and observed completion time fit your route.

How to Track a Cross-Chain Transfer's Arrival

Devid Udyanskaya — Tue, 20 Oct 2026 14:01:47 +0000

You can estimate arrival by checking each chain’s confirmation and the bridge’s delivery status. A transfer may finish in seconds or take several minutes, depending on the chains, congestion, and the route used.

A transfer has two separate wait stages

First, the source chain must confirm your transaction. A blockchain is a shared record of transactions; confirmation means the network has accepted yours. A busy network or a bridge that waits for extra confirmations can make this stage longer.

Next, the bridge must complete the transfer on the destination chain. A bridge connects separate blockchains and carries instructions or assets between them. Its service may wait for source confirmations, then submit a new transaction on the destination.

That is why a source transaction marked “confirmed” does not always mean your funds have arrived. The bridge may still be processing the cross-chain message, or the destination transaction may need time to confirm.

Follow these steps to check progress

Save the source transaction ID. This is the unique code for your transaction. Copy it from the confirmation screen before closing the page.
Check it on the source chain’s explorer. An explorer is a website that shows blockchain activity. Search the transaction ID and check that its status says “success” or “confirmed,” not “pending” or “failed.”
Read the bridge’s status message. The bridge may show stages such as waiting for confirmations, processing, or completed. When learning how to bridge and swap with Mayan bridge, notice which screen provides the transfer status; keep that page open until it shows the next step.
Look up the destination transaction. If the bridge provides a second transaction ID, open it in the destination chain’s explorer. Check that it succeeded and that the receiving wallet address is yours.
Check the destination wallet’s token list. A successful transfer can deliver a different token from the one you sent. Confirm the token name and amount, and check that the wallet is set to the destination chain.

For example, say you send 1 token and the bridge quotes delivery of 0.98 of another token. The 0.02 difference may reflect fees or the exchange rate shown before you approve. Compare the quote with the amount received; do not expect the sent amount to appear unchanged when the route swaps tokens.

Know when a delay needs action

Wait while the bridge shows that it is processing, especially if the source transaction succeeded. Refreshing the page or starting a second transfer will not speed up the first one, and could make it harder to track both.

If the bridge says “completed” but the wallet looks empty, check the destination chain and token list first. Wallets may hide tokens until you add them, and some assets use a different token name after a swap.

If the source transaction failed, the bridge usually cannot complete that transfer. If the source succeeded but the bridge reports an error or remains stuck beyond its stated wait time, save both transaction IDs and contact the bridge’s official support. Never share your recovery phrase; support does not need it to investigate.

Track the source confirmation, bridge status, and destination receipt as separate steps. That sequence tells you where a transfer is waiting and what to check next.

How to Move Tokens to Repay a Loan Before Interest Accrues

Devid Udyanskaya — Sat, 17 Oct 2026 02:07:13 +0000

If you owe crypto on one network and your repayment tokens are on another, move enough of the borrowed asset to the network where the loan exists, then repay there. Interest usually accrues over time rather than waiting for a monthly bill, so check the debt and transfer timing as soon as you decide to repay.

What Must Reach the Loan?

Your repayment must reach the correct loan position in the asset it accepts. A wallet balance on another chain cannot directly pay a debt, even if the token has the same name or ticker: each blockchain keeps its own balances, and the lending protocol records the loan on a particular network.

First identify the loan’s network, borrowed token, and current amount due. If your funds are elsewhere or in another token, acrossbridge is relevant because it can move and swap assets across chains in one flow; check that the result will be the asset your loan accepts on its network. Aave’s official repayment documentation also describes choosing the borrow position and repaying it with the borrowed asset.

acrossbridge.dev gives someone in this situation a way to move or swap crypto across networks in one flow, so the repayment asset can reach the chain where the debt sits.

Steps to Repay Before the Next Accrual

Check the debt on its home network. Open the lending account you used and note the borrowed asset, network, amount owed, and whether you want a partial or full repayment. The displayed debt can rise as interest accrues, so use the current amount rather than the amount you first borrowed.
Work out how much to send. For a full repayment, allow for accrued interest and leave a small margin for changes before the repayment confirms. For example, if the screen shows 500 USDC due and you expect the transfer to take several minutes, sending exactly 500 USDC could leave a small balance behind; a modest extra amount can help cover that change. Treat this as an illustration, since rates and timing vary.
Check where your funds are and what form they are in. Confirm the source network and whether your balance is already the borrowed token or needs swapping. If you owe USDC on one network but hold ETH on another, the task involves both a swap into USDC and a cross-chain transfer to the loan’s network. Check the destination token carefully; similar tickers can represent different assets.
Move the repayment funds, then wait for delivery. A cross-chain transfer is not a single instant balance update: the source chain processes the send, and the destination chain must receive the corresponding funds. Network congestion, confirmations, and the route can affect how long this takes. Interest may keep accruing during the transfer, so start early and leave time for the destination balance to become available.
Repay from the destination chain. Once the correct asset appears on the network holding your loan, submit a repayment for the amount due. The lending contract may require a token approval first, which lets it take the repayment amount from your wallet; review the token and amount before approving. Then check the repayment transaction on that same network.
Confirm the result in the loan account. Verify that the debt fell to zero for a full repayment, or to the expected remaining amount for a partial one. If a small debt remains, interest or a transfer shortfall may explain it; send the remaining required asset and repay again. Keep enough of the network’s native token for transaction fees, or you may have funds ready but be unable to submit the repayment.

Change the plan if the loan is close to a liquidation threshold or the transfer may take longer than you can safely wait: prioritize reducing the debt with funds already on the loan’s network, if available. The key decision is whether the cross-chain route can deliver the right asset with enough time and fee balance for the repayment to confirm.

Burn-and-Mint Bridges: Read Destination Supply During Delays

Devid Udyanskaya — Fri, 16 Oct 2026 17:05:57 +0000

A source burn reduces that chain’s supply; a matched destination mint raises the other’s. The accounting is local to each chain, so a destination balance can increase while the aggregate supply of the bridged token stays level. That distinction helps when a transfer is pending: the source transaction may have changed supply even though the destination has not minted anything yet.

What does burn-and-mint change about supply?

In a burn-and-mint transfer, an authorized bridge contract destroys a specified amount on the source chain, then a contract on the destination chain creates the corresponding amount. Unlike lock-and-mint, the source tokens are not held in a vault; the bridge relies on its message and mint authority to make the destination issuance valid. The destination token may be the same cross-chain asset under a shared supply design, or a chain-specific representation whose value depends on the bridge’s rules.

When you use a cross-chain service such as ParaSwap cross-chain swaps, read the source burn as one leg of the transfer, not proof that the destination balance already exists. ParaSwap is a cross-chain bridge and swap service: it lets you move assets across chains and swap into an asset on the destination chain in one flow. Ethereum.org’s glossary defines minting as creating tokens and bringing them into circulation; here, the key question is which chain’s supply is being counted.

For a simple accounting check, suppose the source burns 100.00 units and the destination mints 99.80 after a 0.20-unit fee. The destination supply rises by 99.80, while the source falls by 100.00; the 0.20 difference must be accounted for as a fee, treasury allocation, or additional burn. If the bridge instead burns only 99.80 and handles the fee separately, compare the actual burn and mint events rather than assuming the entered amount is the minted amount.

What must happen between the burn and the mint?

The destination mint needs an authenticated message that identifies the source event, destination chain or domain, recipient, token, and amount. The bridge’s verification system waits for its configured source-chain finality condition, then authorizes a destination contract to mint; a relayer or user may still need to submit that message on the destination. EIP-7802, an Ethereum token interface proposal, reflects this separation by defining authorized cross-chain mint and burn entry points.

Finality is a protocol parameter, not a universal number of blocks. A bridge may require a fixed confirmation count, a finality signal, or an attestation from its verifier set. More conservative finality reduces the chance that a source reorganization invalidates the burn after minting, but it lengthens the pending period. A source transaction marked successful therefore establishes only that the burn executed on that chain; it does not establish that the required message is ready or that the destination mint succeeded.

Why can a confirmed transfer remain pending or fail?

A transfer can pause after the burn while the verifier waits for finality, while the message is being relayed, or while the destination contract rejects or has not yet processed it. Common contract-level causes include a paused token, a mint cap, an outdated or revoked minter permission, a recipient restriction, or a mismatch in token decimals or amount encoding. If the destination chain is congested, the message may be ready but its execution transaction may still be absent.

Fees and token behavior complicate the arithmetic. A fee-on-transfer token can deliver less to the bridge than the transaction input suggests; rebasing tokens can change balances independently; and decimal conversion can round down when chains use different token precision. The bridge’s actual burn event and destination mint event are the useful accounting records. Don’t infer a supply error from wallet display rounding alone.

What should you check before trying again?

Start with the source transaction receipt: confirm that it succeeded, identify the burned token and amount in its logs, and note any message identifier or nonce. Then check that message’s state in the bridge’s own status source, if available, and look for a destination transaction. If a destination transaction exists, inspect its receipt and mint event; a reverted mint and a successful mint require different next steps.

If the source burn succeeded but no destination execution appears, the transfer may still be waiting for finality or relay. Avoid starting a second transfer with the same intent until you know whether the original message remains executable; duplicate burns can create a second transfer rather than retry the first. If destination execution reverted, preserve both transaction hashes and the error details, then use the bridge’s documented recovery path for that specific message. Recovery rules vary: some systems allow a permissionless retry, while others require an authorized action.

Judge a burn-and-mint transfer by matching its finalized source burn to one successful destination mint, and account for any difference as an explicit fee or conversion rule.

How to judge swap quotes during fast market moves

Devid Udyanskaya — Fri, 16 Oct 2026 11:21:05 +0000

If you are comparing routes during a sharp market move, treat each quote as a short-lived estimate and compare what should arrive. For a BTC-to-ETH move, compare what ParaSwap delivers after bridging and swapping with a separate bridge-then-swap route; the ParaSwap BTC to ETH route is useful to assess, but rely on a fresh quote.

Keep three points in view:

Quotes can change before a transaction is confirmed.
Compare destination amounts after costs, not just exchange rates.
Refresh after a delay or a sharp price move.

Why can a route quote change so quickly?

A quote estimates the result using prices and conditions that can shift before your trade completes. A swap may use a liquidity pool, where available token balances affect the exchange rate; a large trade can move that rate as it uses the pool. Uniswap’s whitepaper describes how pool reserves shape the price offered.

On a cross-chain route, the estimate can include a swap before the transfer, the bridge transfer itself, and another swap after arrival. Each stage takes time, and the destination price can move while the transfer is underway. Network congestion can also change transaction costs or delay execution.

Say you expect 1 ETH for your BTC. If the destination price rises before the final swap, the same BTC may buy less ETH. A route that looked best a minute ago can therefore arrive with a lower amount.

How do you compare routes fairly?

Compare the estimated destination amount, any stated minimum received, and the costs shown for each route. “Slippage” means the difference between the estimate and the amount you may actually receive. Ethereum.org explains how minimum received relates to slippage; a tighter minimum can protect your result, but may cause the trade to fail if prices move too far.

Keep the comparison like for like: same starting asset, amount, destination asset, and timing. One route may show a better exchange rate but take longer or include more conversion steps. ParaSwap can bridge and swap in one flow, so include the final destination amount in your comparison rather than judging one swap leg alone.

When should you refresh or wait?

Refresh the quote just before you decide, especially after a sharp price swing or a long pause. If the new estimate differs from the earlier one, compare the updated minimum and costs again; do not assume the first figure still applies.

If the market is moving quickly, waiting briefly for calmer prices may help, but prices can move either way. In your place, I would choose the route with a clear destination amount and acceptable minimum, then act only on its current quote.

Where Monero privacy stops after a swap

Devid Udyanskaya — Fri, 16 Oct 2026 07:33:10 +0000

Monero privacy does not follow your coins onto another blockchain. A Monero bridge can exchange value across chains, but the destination chain has its own public record.

What can other people see after the swap?

They may see the destination transaction, even if they cannot read your Monero transaction from the public ledger. On many blockchains, addresses and amounts are public, so anyone can inspect where the received asset went next.

Monero hides key details differently: ring signatures mix your real spend with decoys, and RingCT hides transaction amounts. A route still needs to detect your deposit and send the other asset, so its operator or protocol may connect those events.

Before choosing a route, compare a Monero bridge swap because the destination chain changes what outsiders can inspect. Also check whether the route asks you to provide a destination address alongside your deposit.

How can a swap connect your two transactions?

A service may receive your XMR, then send an asset from its own wallet or liquidity pool. A liquidity pool is a shared reserve used to complete trades. The public may not see a direct transaction between your two addresses, but the service can hold both sides of the exchange in its records.

Other people may still infer a connection from timing, amounts, or later spending. For example, if you deposit XMR and soon receive a similar value on a public chain, an observer may suspect the transfers belong together. That is a clue, not proof.

Some protocols aim to exchange coins directly between participants without a central service holding both sides. These are often called atomic swaps: rules and cryptography coordinate the exchange so one side cannot simply keep both assets. Available pairs, directions, and ease of use vary, so check the exact route before relying on it.

How should you choose a route for a real payment?

Start with the asset and destination you need. If you want to pay someone in a public-chain asset, ask whether they need that exact asset or can accept another one. Every extra conversion adds another fee, delay, and possible link in the trail.

Then decide which privacy exposure matters most. If you mainly want your XMR balance and spending details hidden on Monero, keep the funds there until conversion is necessary. If you also want to reduce links to your destination address, avoid reusing addresses and consider whether the route operator can associate your deposit with that address.

For a cross-chain step after XMR has become another supported asset, monerobridge.org provides a service for moving and swapping crypto across blockchains in one flow. It is one option for that later step; first confirm the asset you hold can enter the route you need.

In practice, write down the source asset, destination asset, privacy concern, and number of conversions before comparing routes. No route makes public-chain activity private by itself.

Choose the exact asset and destination first.
Check who can connect your deposit to the payout.
Limit conversions and avoid reusing public addresses.