If a token swap is pending or failed, verify the token’s 20-byte contract address on the intended chain before trying again. A token’s name and ticker are display metadata; the chain and contract address identify which asset the transaction actually references.
Token identity is the chain and contract address
A token is identified by its contract address on a specific network, not by its symbol. Two Ethereum contracts can both report “cbBTC,” and the same address on another EVM chain can refer to unrelated code. A correct address on the wrong chain is still the wrong asset.
When checking a token for a Fermi swap, compare the address against the issuer’s official contract information for that network. The Fermi swap service is one way to exchange tokens from your wallet; confirming the asset before selecting it helps ensure the intended contract is part of the swap.
- Match the network as well as the address.
- Use an authoritative contract listing, not a ticker search alone.
- Check whether the transaction has already been broadcast.
- Read the receipt or simulation error before retrying.
Network first. Confirm the chain ID in your wallet and the network named by the issuer’s contract listing. Ethereum mainnet and Base, for example, have different chain IDs, and each chain has its own state and token contracts. A block explorer’s verified source and contract metadata can help inspect a candidate, but verification alone does not establish that the issuer is genuine.
Address second. Compare all 40 hexadecimal characters after 0x, preferably in EIP-55 checksum form. EIP-55’s mixed capitalization helps catch transcription errors; it does not authenticate a token. If the address came from a search result or message, independently locate the issuer’s official listing rather than treating the checksum as proof.
Transaction state third. If the wallet has not broadcast the transaction, correct the selected contract and obtain a fresh quote or simulation. If it is already pending, changing the selection does not alter the signed transaction: its calldata still contains the original token address. If it has reverted, the receipt identifies an on-chain failure; the sender generally still pays gas for execution, even though the swap did not complete.
A swap uses addresses throughout the call
The selected addresses flow from the quote into transaction calldata, where the swap call specifies the input and output assets and amounts. A contract then reads token balances and allowances and attempts the exchange; for an ERC-20 input, the wallet may first need to authorize a spender. A wrong contract can therefore produce a missing balance, failed allowance, an invalid quote, or a call that reverts.
Token decimals matter when interpreting amounts, but they do not change token identity. ERC-20’s decimals() value is commonly 18; cbBTC uses 8, while WETH uses 18. Contracts account in integer base units, so a displayed amount of 1 cbBTC corresponds to 100,000,000 units. If an interface reads the wrong contract’s decimals, its displayed quantity or quote can be misleading even when the raw transaction amount is valid.
Uniswap V3 illustrates another address-level detail: a pool is determined by the two token contracts and a fee tier, not by the symbols alone. Its documentation warns that deployments vary across networks. A token pair that exists under one contract address may have no corresponding pool under another, or may point toward thin liquidity and a materially worse execution price.
Pending and failed transactions need different recovery
A pending transaction is waiting for inclusion; it is not proof that token selection is still editable. Check the transaction hash, destination, calldata, nonce, and chain in a block explorer. Under Ethereum’s EIP-1559 fee market, inclusion depends partly on whether maxFeePerGas covers the current base fee and whether the priority fee is competitive. A nonce gap can also hold later transactions behind an earlier pending one.
If the pending transaction encodes the wrong asset, do not send another swap assuming it will replace the first. A replacement uses the same nonce and a higher fee, but only one same-nonce transaction can be included; wallet behavior varies, and increasing the fee does not edit calldata. If the original swap is still executable, replacement may not prevent it from landing.
For a failed transaction, inspect the receipt and revert reason where available, then check the exact input and output contract addresses, balance, allowance, and quoted minimum output. A stale quote or slippage bound can fail independently of address selection. Before resubmitting, establish which condition failed; repeated attempts can consume additional gas without changing the cause.
Correct the asset before signing again
For example, suppose a token search returns a lookalike cbBTC entry with a different address. Before signing, checking the issuer’s Ethereum listing reveals the mismatch; selecting the verified contract yields a quote for the intended asset. After signing, the fix is different: inspect the pending transaction’s calldata and nonce, because changing the token picker only affects a future transaction. When reviewing a Fermi swap attempt, the same distinction helps separate an asset-selection problem from a network-inclusion delay.
My practical rule is to copy the contract address from the issuer’s network-specific listing, compare it character by character with the selected asset, then confirm the chain once more before signing.