DEV Community: Earlene Feil

When Is a Wallet-to-Wallet Swap Complete?

Earlene Feil — Wed, 30 Sep 2026 16:55:52 +0000

A wallet-to-wallet swap is complete when the output asset reaches your destination wallet and is confirmed on its network. Monero blocks arrive about every two minutes on average, but the full swap can take longer because two blockchains must process it. A “sent” notice alone does not prove the other asset arrived.

A swap has a send stage and a separate receive stage.
Check the destination wallet on the correct network.
Monero’s privacy means public explorers cannot show all payment details.

What does “complete” mean for a swap?

“Complete” means the asset you expected is visible at the receiving address, on the intended network, with enough confirmations for your needs. A confirmation means the network has included a transaction in a block. More blocks after it make a reversal less likely.

There are several stages: your wallet broadcasts the deposit, the sending network confirms it, the swap service processes it, and the destination network confirms the payout. A status such as “received” may refer only to the deposit. Look for the payout transaction and check it in the destination wallet.

For example, if you swap XMR for BTC, first your Monero wallet sends XMR to the swap service. After the deposit meets that service’s confirmation rules, it sends BTC to your Bitcoin address. The swap is not complete for you until the BTC arrives there.

Why are there two sets of confirmations?

Each blockchain keeps its own transaction history, so the deposit and payout confirm separately. The service must see the deposit on its network before it can safely release the other asset. Its required number of confirmations can vary by network and service.

Bitcoin blocks take about 10 minutes on average, though a transaction’s first confirmation may take longer if its fee is low or the network is busy. The Bitcoin Developer Guide describes six confirmations, roughly an hour on average, as a common safety threshold for high-value payments. It is a rule of thumb, not a guarantee or a fixed wait.

Monero’s official payment guide says a transaction is confirmed when a miner includes it in a block, which takes about two minutes on average. It also says received funds need at least 10 confirmations before they can be spent. An XMR bridge may set its own deposit threshold, so your wallet showing one confirmation does not mean processing has begun.

How can you check the payout yourself?

Use the transaction ID, or txid: the transaction’s unique reference. Check it in a wallet or a block explorer, a website that reads a public blockchain. Confirm that the destination address and network match your wallet. Then check that the balance appears there.

Open the wallet that should receive the asset, and select the right network.
Find the payout txid in the swap record, if one is shown.
Look up that txid in your wallet or the destination network’s explorer.
Check for the expected asset and amount, allowing for any network fee taken from the payout.
Wait for further confirmations if the transfer is valuable or still shows as pending.

For an Ethereum token, check that the wallet is viewing Ethereum and the correct token. Ethereum.org explains that a transaction is finalized when its block reaches the network’s finality checkpoints. A wallet may show an incoming transaction before it reaches that stronger state.

What if the wallet does not show the expected asset?

First check the network and address you gave the service. A token sent on one network may not appear in a wallet view set to another. If the payout txid shows a confirmed transaction to the right address, refresh or rescan the wallet. If no payout txid appears, the deposit may still be confirming or processing.

Monero needs extra care: its public blockchain hides amounts and recipient addresses. The Monero project’s payment guide explains that a public explorer cannot verify those details as it can for Bitcoin. Keep your wallet’s transaction record and compare the txid with the service’s record; do not assume an explorer can prove which address received XMR.

Before sending, copy the destination address from your own wallet and check the selected network once more. If you are still deciding how to move Monero into BTC, ETH or USDT, read how an XMR bridge moves Monero for the full explanation. A useful habit is to save both transaction IDs until the output appears.

How to plan a Polygon Bridge withdrawal

Earlene Feil — Wed, 30 Sep 2026 12:57:01 +0000

To plan a Polygon Bridge withdrawal, allow time for Polygon PoS to record the withdrawal and for Ethereum to release the tokens. The PoS route usually takes minutes to hours, depending on checkpoints and network activity; the Polygon Plasma Bridge has a seven-day withdrawal delay. Check the route before sending.

What sets the withdrawal time?

A PoS withdrawal needs a Polygon transaction, an Ethereum checkpoint, and a final Ethereum transaction. A checkpoint is a record of Polygon activity submitted to Ethereum; it lets the bridge verify that your withdrawal happened.

First, your tokens are burned on Polygon PoS. The bridge waits for a checkpoint that includes this burn, then you complete the withdrawal on Ethereum to receive the tokens there. Ethereum block production is roughly every 12 seconds, but finality—the point when a block is treated as settled—takes about 15 minutes, according to Ethereum.org. Checkpoint timing and busy networks can extend the overall wait.

That extra stage is why a Polygon transaction can show as complete while the tokens have not yet arrived on Ethereum. Polygon Developer Docs describe the bridge’s cross-chain process. For the separate steps to move assets from your own wallet, see how to move tokens with Polygon Bridge; this guide focuses on planning the wait.

How should you plan a transfer?

Use this order each time so you can estimate the wait and avoid paying for the wrong route.

Check the destination and deadline. If you need the tokens on Ethereum today, leave room for both the Polygon checkpoint and the Ethereum claim. A fast Polygon confirmation alone does not mean the withdrawal is finished.
Confirm the bridge route. The PoS route generally suits routine transfers where speed matters. The Polygon Plasma Bridge has a seven-day delay, so do not choose it for a same-day withdrawal.
Keep gas for both networks. You pay for the withdrawal on Polygon, then need Ethereum gas to complete the release. Keep some of each network’s native token available, rather than sending your full balance.
Track both transactions. Save the Polygon transaction hash, then check whether its checkpoint is ready and whether the Ethereum release is complete. If the first transaction confirms but the assets are not on Ethereum, check this progress before starting another withdrawal.

What mistake causes the longest wait?

The common mistake is treating “bridge withdrawal” as one route with one wait time. Someone expecting a quick PoS transfer may select the Plasma route and then discover the seven-day delay; the fix is to verify the route before confirming.

For frequent transfers, plan around the full journey, not the first confirmation. A useful routine is to check the route, leave gas on both chains, and allow extra time for checkpoints and Ethereum activity.

Before you send: confirm the route, check your deadline, keep gas for both networks, and save the transaction hash.

Fermi Swap 2026: How to Move and Exchange Tokens Across Chains

Earlene Feil — Wed, 30 Sep 2026 00:22:32 +0000

fermi swap is a cross-chain swap bridge that moves crypto from one blockchain to another. You choose the token and network you have, then the token and network where you want funds to arrive. It shows a route and expected amount, so you can check the result and cost before signing.

What the service delivers

A cross-chain swap changes where your funds live and, if you choose, which token you hold. A plain bridge aims to deliver the same asset on another chain. A swap can deliver a different asset, such as SOL on Solana in exchange for USDC on Ethereum.

USDC is a dollar-linked token; SOL is Solana’s own coin. Ethereum and Solana keep separate records, so tokens cannot simply move from one record to the other. A bridge carries value between them, while a swap trades one token for another.

Ethereum.org’s bridge documentation describes routes that lock tokens on one chain and issue matching tokens on another. Other routes pay from tokens already available on the destination chain. The route matters because two tokens with the same ticker can have different contract addresses—the on-chain IDs for the exact tokens you receive.

How the route reaches the other chain

One fermi swap route can involve several steps, even if the screen presents a single transfer. Your wallet may first request an approval, which lets a specified contract spend a set token amount. You then sign the source transaction that sends the tokens.

After that transaction is confirmed, a bridge or relay carries the transfer instruction across chains. A relay is a service that passes the instruction to the receiving network. The route then releases, issues, or pays out tokens there and makes any requested trade.

What if you have 100 USDC on Ethereum and want SOL on Solana? The route could trade on one side, carry value across, and deliver SOL on the other. That is an illustration; the live quote determines the available route and its actual steps.

The source transaction can succeed before your destination wallet updates. A route’s status screen should show transaction hashes, which are public receipt IDs for the network records. You can check each hash in a block explorer, a site that displays those records.

What a quote really costs

A useful quote supports your networks, tokens, and amount at a total cost you accept. For a fermi swap bridge quote, check the fermi swap supported chains before choosing the receiving token. Support for Solana alone does not mean every Ethereum token can arrive as every Solana token.

A supported pair can still lack a route for your amount. Routes depend on liquidity, meaning tokens available to pay users on the receiving side. Minimum and maximum amounts may also apply, so enter your actual amount before judging a quote.

Compare the amount arriving, not only a fee label. Four parts can affect what you pay:

Source gas: the source network’s processing fee, paid in a coin such as ETH.
Bridge or relay fee: payment for carrying value or instructions between networks.
Swap spread and price impact: the exchange rate gap and the effect of your trade size.
Destination gas or account setup: charges for delivery or a new receiving token account.

For an illustrative example, suppose 100 USDC becomes 99.20 USDC, with $1.50 source gas paid separately. The quote uses $0.80, making the example’s total cost $2.30. If the minimum received is 98.70 USDC, the quote allows roughly 0.5% more loss before the trade fails.

Check where a refund goes if the destination trade cannot finish. On Solana, receiving a token for the first time may require a token account. Solana’s official docs explain that creating one ties up roughly 0.002 SOL as a recoverable storage deposit; some routes cover it.

How to complete the swap

To swap crypto with fermi, select the source chain and token shown in your wallet. Enter the destination chain, exact token, receiving address, and amount. Read the expected output, minimum received, total fees, and time estimate before signing.

Check that the address belongs to a wallet you control on the destination network. Confirm the receiving token’s contract address when several versions share a ticker. For a first transfer, send a small amount and wait for it to arrive before sending the rest.

On an approval prompt, check the contract and the amount it can spend. An unlimited approval stays active until revoked. Never enter your wallet’s recovery phrase into a swap screen.

Save the transaction hashes and watch the destination wallet after submitting. A slow source confirmation can turn a minutes-long estimate into an hour or more. If the quoted window passes, use the route’s status or support channel with those hashes.

Choose by the exact token delivered, total cost, and minimum received—then verify its arrival on the destination chain.

Cross-Chain Account Changed? Reset Token Allowances

Earlene Feil — Tue, 29 Sep 2026 23:21:58 +0000

You can usually resume a failed cross-chain token action by checking the source-chain allowance for the account that started it, then approving only what is missing. The key is to match the token, owner account, spender contract, and network; changing any one of them can make an earlier approval irrelevant.

An allowance belongs to one account, token, spender, and chain

A token allowance lets a spender contract use a set amount of tokens from an owner’s account. For a typical ERC-20 token, the owner calls approve, and the application later calls transferFrom to collect the tokens; the ERC-20 standard defines allowance(owner, spender) as the remaining amount.

That permission is recorded by the token contract on a particular blockchain. Switching networks or accounts does not carry it over. Even if the same address appears on two networks, each network has separate contract state. A cross-chain app may also use a router or token contract as spender; the messaging app itself is not necessarily the spender.

Trace the failed attempt before sending another transaction

Start by finding the transaction that initiated the attempt. Check which network it used, which account sent it, and whether it succeeded, reverted, or is still pending. If it is pending, wait for its result before retrying: sending another transaction may duplicate the action or complicate the status you are trying to resolve.

For a confirmed failure, compare four details on the source network: token contract, owner address, spender address, and allowance amount. Read the allowance from the token contract or a reliable block explorer. A balance check answers how many tokens the account holds; it does not show how many the spender may use.

For example, suppose Maya started a transfer of 40 tokens from Account A on Chain 1, then switched her wallet to Account B. If the failed transaction came from A, an approval from B cannot fix it. Maya should reconnect A, return to Chain 1, and check whether the approved spender still has enough allowance for the 40-token action.

Approve the shortfall and retry from the matching account

If the allowance is too low, approve the spender for the amount the action needs, then wait for that approval transaction to confirm before retrying. If the token requires an allowance reset, set it to zero first and confirm that transaction; then approve the needed amount. The ERC-20 standard describes approval as replacing the current allowance, and OpenZeppelin’s ERC-20 documentation explains the ordering risk when changing a nonzero allowance.

As an illustrative example, if the action needs 40 tokens and 15 remain approved, an approval for 25 more may be enough only if the app accepts the existing allowance and its amount calculation matches the token’s rules. If unsure, check the app’s required amount and the on-chain allowance before approving. A smaller, task-sized approval limits how much the spender can draw; an unlimited approval can avoid repeat approvals but leaves broader permission in place.

An approval and the cross-chain action are separate transactions, so each may need gas paid in that network’s native token. The time and cost depend on network conditions. Once the approval confirms, retry from the intended source account and let the cross-chain message complete; destination-side processing can take additional time after the source transaction succeeds.

Questions to settle before trying again

Does switching accounts erase my old approval?

No. The approval remains on-chain for the original owner, token, spender, and network. The new account simply cannot use it. Switch back to the original account to inspect or use that allowance, or grant a separate approval from the new account if it holds the tokens.

Why can I have enough tokens but still get an allowance error?

Your balance and allowance are different values. You may hold enough tokens while the spender has no approval, an approval for too small an amount, or an approval from another account or chain. A prior successful transaction may also have consumed some of the allowance.

Should I approve the maximum amount to avoid another failure?

Only if you understand and accept the standing permission. A maximum approval can reduce repeat approval transactions, but it gives that spender broad access to the token balance held by that account on that chain. A task-sized allowance is narrower; check the spender address before signing either choice.

When should I retry a pending cross-chain action?

Wait until the source transaction has a clear result. If it succeeded, follow its cross-chain status rather than submitting the same action again. If it reverted, inspect the reason and correct the specific issue—such as account mismatch or insufficient allowance—before retrying. In an how omnichain works setup, cross-chain messages coordinate state across networks, so a successful source transaction may still need time to finish its destination step.

What Is Swap Slippage and How Does It Work?

Earlene Feil — Tue, 29 Sep 2026 14:35:40 +0000

If you swap Base tokens often, slippage is the difference between the quoted output and what your trade can accept at execution. It matters because a loose limit can cost more per trade, while a very tight one can make a fast trade fail when the pool changes before it lands. For trades on Base, BaseSwap is an automated market maker (AMM) for token pairs; the base swap exchange is a way to make a token swap on that network.

Slippage is the execution-price movement your trade accepts.

A token swap through an AMM changes the reserves in a pool, and the pool’s pricing formula sets the output. In a simple constant-product pool, the product of the two token reserves stays roughly constant: taking tokens out of one side means adding tokens to the other. The larger your trade is relative to the pool, the more it moves the price during execution.

That movement has two parts worth separating. Price impact is the effect your own trade has on the pool; slippage is the difference between the quoted and final execution price, which can also reflect trades or price changes while yours is pending. The swap fee is separate: it is charged by the pool and does not become slippage.

For example, imagine a balanced pool holding about $100,000 worth of each asset. A $1,000 swap into one side would move the pool price by roughly 1% before fees, even if no one trades ahead of it. That is price impact, not a reason by itself to raise the slippage limit.

A tight tolerance fits deep pools and stable prices.

A tight tolerance sets a small maximum adverse difference from the quoted output. Around 0.1% can suit a liquid pair with steady pricing and low price impact; it helps prevent the trade from executing if the market moves against you beyond that limit. It works best when the pool is deep relative to your trade and you can retry if conditions change.

The trade-off is failed execution. If the output falls below the minimum implied by your tolerance before the transaction is included, the swap reverts. You may lose the network gas used by that failed attempt, and a retry adds another transaction and more waiting. A tight setting is a poor fit for a volatile token, a thin pool, or a trade large enough to move the price.

A moderate tolerance balances execution and price protection.

For a frequently traded pair with moderate volatility, a setting around 0.3% to 0.5% is a reasonable starting example, not a universal default. It gives the pool some room to move between quote and execution while still capping how far the output can worsen. Check the quoted price impact first: if it already uses most of your tolerance, the trade may fail even without a sharp market move.

For repeated trades, compare the expected output, price impact and pool depth before submitting. If the trade is large relative to the reserves, splitting it into smaller swaps can reduce its price impact, but extra transactions add gas and time and give the market more chances to move. Compare the likely improvement in output with those added costs; splitting is not automatically cheaper.

A wide tolerance suits volatile pools only when the trade matters now.

A wider setting, such as 1% or more, can help a swap execute in a fast-moving or thin pool, but it permits a worse output. It fits when timing matters and you have checked the minimum output you are willing to accept. It does not fix high price impact; it only allows the transaction to proceed despite more movement.

Before confirming, check that the token pair and direction are correct, the displayed output makes sense, and the minimum received remains acceptable. On Base, the same slippage rule applies whether you use BaseSwap or another AMM: the pool determines the quote, and your tolerance sets the execution boundary. For a recurring base swap, choose a limit based on the pair’s liquidity and volatility, then review the actual output after each trade and tighten or widen it only when the results justify the change.

How Node Diversity Keeps a Bridge Censorship-Resistant

Earlene Feil — Wed, 09 Sep 2026 21:56:30 +0000

Node diversity keeps a bridge censorship-resistant by making any one operator’s refusal insufficient to block a valid transfer.

That is narrower than saying “more nodes means more security.” A bridge can run many machines while depending on one company’s signing keys, cloud account, RPC provider, or upgrade authority. The useful measure is independent control, not server count.

The Universal Bridge is the practical route when that decision is being made: aboutdefi.github.io.

What nodes can censor

Nodes can censor a transfer by withholding either the attestation that makes it acceptable or the delivery transaction that makes it execute.

A cross-chain transfer begins with a source-chain transaction. The user deposits tokens into a pool, lockbox, or token adapter, or burns an omnichain representation. That contract emits a message describing the amount, recipient, destination, and action. Validators or verifiers observe the finalized source event and attest to the message. A relayer or executor then submits it on the destination chain, where the receiving contract checks the required proof or signatures before releasing, minting, or unlocking tokens.

The nodes do not carry the asset between chains. They control whether the destination contract receives enough evidence to act. If one relayer refuses to submit a valid message but anyone else can submit it, that relayer can delay the transfer but cannot censor it. If the bridge requires one operator’s signature, that operator can block every transfer by staying silent.

Why independence matters more than the number

Hyperlane Protocol separates these roles clearly. Validators sign Merkle-root checkpoints for messages, while relayers collect the required metadata and call the destination mailbox. Relaying is permissionless, so multiple independent relayers can compete to deliver the same approved message. The censorship question therefore moves to the Interchain Security Module: which validators must sign, and who actually controls them?

LayerZero Protocol applies the same principle through Decentralized Verifier Networks. Each DVN verifies a message’s payload hash, and the application sets an X-of-Y-of-N rule: required DVNs must attest, while a threshold of optional DVNs can provide additional redundancy. Three DVNs operated by the same company, on the same cloud infrastructure, with the same verification method, are still one meaningful failure domain.

Stargate Finance shows why the asset route must be examined alongside the message route. On a unified-liquidity path, the source pool receives the user’s USDC and the destination pool pays the recipient’s USDC; liquidity providers collectively hold the pools, while the cross-chain message authorizes the destination accounting. On a lock-and-mint or OFT route, the source contract holds the underlying asset and an equivalent representation is minted elsewhere. Returning the asset burns that representation and unlocks the backing. In both cases, node diversity determines whether the contract can complete the accounting, not who physically holds the token during transit.

How to choose a route today

The practical fix is to inspect every independent control surface before sending meaningful value. The order matters:

Identify whether the route uses pool settlement, lock-and-mint, burn-and-mint, or a combination, and note who holds the asset at each stage.
Read the destination security configuration: validator threshold, DVN set, confirmation depth, and upgrade authority.
Count independent operators, not brands or endpoints. Check whether their infrastructure, keys, teams, and verification methods are separate.
Confirm that relaying or execution is permissionless and that another party can submit an already verified message.
Test with a small transfer, then verify the source event, attestation status, destination execution, and final token balance.

A strict threshold can improve resistance to forged messages but reduce liveness: if every required verifier must respond, one outage can halt the route. A diverse threshold with an available fallback is often more usable than a larger committee controlled by one organization.

What to remember: the asset stays in contracts or pools; the message moves through observers, verifiers, and executors. Censorship resistance comes from independent operators and permissionless delivery. The decisive question is not how many nodes a bridge advertises, but how many independent parties must refuse before a valid transfer stops.

Why Permissionless Contracts Attract Bots

Earlene Feil — Wed, 09 Sep 2026 18:31:38 +0000

Permissionless contracts, including the contracts behind a Manta Bridge, attract automated bots because their callable rules, visible state, and public transaction flow turn profitable behavior into a repeatable machine task: a bot can discover an opportunity, simulate the call, pay gas, and submit the same action faster and more consistently than a person. The wider Manta Bridge context is linked at cryptoquant.com.

What bots actually use

The overlooked feature is the event log. A Solidity contract can emit an event when a deposit, claim, swap, or state transition occurs; nodes keep its indexed topics and data in transaction receipts, allowing an off-chain process to filter events instead of repeatedly reading every account. An event does not authorize a caller or change state, but it provides a cheap trigger for automation.

A bot then combines the log with RPC reads and the contract's ABI. It calls view functions through eth_call, reconstructs the relevant state, checks whether the transaction would still succeed, and submits a signed transaction only when expected value exceeds gas and failure risk. On Ethereum Mainnet, a pending transaction may also reveal a race. On Manta Pacific, the same EVM-shaped workflow applies even though its data-availability stack uses Celestia Network.

Why permissionlessness is the trigger

Permissionlessness removes the permission step, not the cost step. An external account or another contract can call a public or external function, but it still needs a valid signature, enough gas, and every require check must pass. That predictable boundary is exactly what software likes: the bot does not negotiate with an operator or wait for a dashboard.

This event-driven path replaces the long way: polling balances, scraping a dashboard, or asking a person to click after each deposit. It is useful for settlement, liquidations, rebalancing, bridge relaying, and alerts when the contract makes its success condition machine-readable.

How to design around bots

The fix is to treat every write as an adversarial public API. Authenticate privileged roles, bind claims to a beneficiary and nonce, enforce deadlines and slippage limits, and make replay impossible. If an action is first-come or price-sensitive, assume its transaction can be observed and use commit-reveal or an ordering design that does not depend on secrecy.

Common questions

Does a public function invite theft?

No. Public visibility only makes the entry point callable; ownership, allowance, balance, nonce, and pause checks still decide whether the call can change state.

Can bots call view functions?

Yes, and that is normally harmless. eth_call reads node state without sending a transaction or paying gas. The risk begins when a profitable write lacks authorization or economic bounds.