Sending Crypto: Fees, Speed, and Getting It Right

Sending crypto is the moment theory turns into consequence. The previous parts of Zelcore Essentials set up the wallet, secured your seed phrase, and funded your first addresses. This part is about the action itself: picking the right fee, hitting send with confidence, and knowing what to do when a transaction sits in limbo.

Fees are the part most beginners get wrong. There is no universal dial. Bitcoin charges per byte of transaction size, Ethereum charges per unit of computation, Solana charges per signature plus an optional tip, and Tron sidesteps gas entirely with a resource model. If you treat them all the same, you will either overpay or get stranded in the mempool. The small-test-send rule and the speed-up/cancel moves reduce two specific risks: sending a large amount to a wrong or unusable address, and a send left waiting because its fee is too low.

Before you start

A send is a signed instruction broadcast to a public network. Once it is signed and confirmed, there is no undo you control: nobody — not Zelcore, not an exchange, not the recipient — can reverse it for you. Inclusion in one block is not the same as finality, though, so the recipient should still wait for the chain's usual confirmations or finality before treating the payment as settled (see Verifying the send below). While it is still pending, some chains let you replace it with a new version that pays a higher fee (covered below). On Bitcoin, a replacement can also change the outputs, meaning where the coins go, when the wallet supports it: Bitcoin Core's own fee-bump command, for example, accepts new outputs for the replacement transaction (Bitcoin Core fee-bump code). The original can still confirm first, though, so a replacement is not an undo you can count on. Treat every confirm button as a final decision.

Four things must be true before you sign:

• You have the correct network selected. USDT on Ethereum, USDT on Tron, and USDT on Solana are three different tokens that happen to share a ticker. If you paste an address that belongs to another chain, Zelcore says "This address belongs to [chain]. Send from [chain] instead." (Zelcore send and receive guide). On EVM networks that check has limits: the same 0x address is valid on every EVM chain, so no warning appears there. Confirm which network the recipient supports before you send. A wrong-network send that gets past that check may or may not be recoverable, depending on the address and who controls it on the other chain, so don't count on getting it back.
• Your sending address has enough balance to cover the amount plus the fee. The fee comes out of the same address, not a separate pot.
• The recipient address matches what the other party actually gave you. Compare the whole address against the source, middle characters included: address-poisoning scams plant lookalike addresses that share the first and last characters (MetaMask address poisoning guide), and a clipboard hijacker can swap the middle silently.
• You have the memo, destination tag or payment ID if the recipient needs one. Exchanges often ask for one on chains such as XRP or Stellar, and a deposit without it may not be credited to your account.

If any of those feel uncertain, stop and re-check. Sending is one of the few places in crypto where a 30-second pause is worth it.

How fees work on the big chains

Every chain answers the same question — how do I bid for block space? — in a different dialect. For a gentler overview of the concept itself, see our transaction fees at a higher level explainer.

Bitcoin. Fees equal transaction size in virtual bytes multiplied by a rate in sat/vByte. SegWit addresses produce smaller transactions than legacy ones and therefore cheaper fees. Taproot is not always smaller than native SegWit: P2TR transactions are slightly larger than equivalent P2WPKH transactions in a two-input, two-output comparison, so the saving depends on the transaction. Live rates are visible on explorers like mempool.space. Rates move with demand: they can be very low in quiet periods and climb to 50, 100, or 200+ sat/vB during congestion, so go by the live estimate rather than a remembered number. If you want the full picture of weight units, SegWit discounts, and RBF mechanics, see deeper Bitcoin fee mechanics, SegWit discount, and RBF/CPFP.

Ethereum (EIP-1559). Total gas cost equals gas used multiplied by (base fee + priority fee). The base fee is set by the protocol and burned, and the priority fee is your tip to the validator (ethereum.org gas guide). Your max fee per gas is the ceiling — if the base fee drops, you get change; if it spikes above your max, your transaction waits. Same model applies on EVM L2s like Arbitrum, Base, and Optimism, with far lower base fees plus a small L1 data component. Token sends have an extra catch covered in wallets, gas, and token approvals: ERC-20 transfers still burn ETH for gas, not the token you are sending.

Solana. A small base fee of 5,000 lamports per signature, plus an optional priority fee quoted in micro-lamports per compute unit, with a maximum budget of 1.4 million compute units per transaction (Solana fee documentation). Priority fees became standard practice after the congestion cycles of recent years — during busy periods, skipping them means your transaction may simply drop.

Tron. No gas price. Every account has a free daily bandwidth allowance (currently 600 points) that covers simple transfers, while smart-contract calls consume energy, which has no free quota (TRON resource model). If you run out of either, the network burns TRX at a fixed rate to cover the shortfall, or you can stake ("freeze") TRX to earn resources over time.

In Zelcore: sending crypto step by step

1. Pick the asset and network. Open Portfolio, select the coin or token, then select Send; on mobile and in the extension, start from the coin's action row (Zelcore send and receive guide). Confirm the network — USDT-ERC20 and USDT-TRC20 are listed separately for a reason.
2. Enter the recipient address. Paste it, then compare the full address, character by character, against the original source (email, invoice, the other wallet's receive screen). Never type long addresses by hand.
3. Add the memo, tag or payment ID if the recipient asked for one. On chains that use one, the Zelcore send form shows the field for it (Zelcore send and receive guide).
4. Enter the amount. Zelcore shows the fiat equivalent beside it. Select Max to send the Total Spendable Amount (Zelcore send and receive guide). Either way, review the fee Zelcore displays before you confirm.
5. Choose the fee tier. Under Select Speed, Zelcore surfaces Economy, Normal, and Fast tiers based on live network conditions (on some chains the network calculates the fee automatically). Pick Normal for routine sends. Pick Fast only when time matters — an arbitrage, a dipping exchange deposit window, a time-locked trade.
6. Review and confirm. With a software wallet, Zelcore signs the transaction locally on your device, then broadcasts it. With a Ledger or Trezor account on Zelcore desktop, your keys stay on the device: Zelcore desktop builds each transaction, and you approve it on the device, and only some coins can be sent from a hardware wallet in Zelcore (Zelcore's Ledger and Trezor guide). You get a transaction ID (txid or tx hash) immediately. Copy it before closing the screen.

One common tripwire on EVM chains: sending a token requires a balance of the chain's native fee coin in the same address to pay gas, such as ETH on Ethereum, BNB on BNB Smart Chain and AVAX on Avalanche C-Chain. On Polygon PoS, POL is the native gas token (Polygon's POL migration update). If you funded an Ethereum address with USDC but no ETH, the send will not even broadcast. Other EVM networks work the same way with their own coin: BNB on BNB Smart Chain, POL on Polygon PoS, AVAX on Avalanche C-Chain.

The small-test-send rule

When you are about to pay a new recipient a meaningful amount — a first-time exchange deposit, a vendor invoice, a move to a hardware wallet — send a tiny test first. A few dollars is usually enough, but check the receiving service's minimum deposit and the network fee before you pick the amount: a test below an exchange's minimum may never be credited, and on some chains the fee alone is a few dollars. Wait until the recipient confirms it landed before sending the rest.

This catches three failure modes that no amount of address-checking can fully prevent:

• Wrong network selected. A test send to the wrong chain puts a few dollars at risk, not a few thousand.
• A clipboard hijacker or paste error silently swapping the destination address.
• A recipient address that is technically valid but unmonitored — an exchange deposit address for a delisted asset, or an old wallet nobody watches anymore.

On EVM chains, a successful test transfer doesn't prove a smart-contract recipient will credit the tokens: a standard token transfer can succeed even when the receiving contract doesn't handle it. If the recipient is a contract or a service, confirm it supports direct deposits of that token on that network before you send. Yes, you pay two fees instead of one. Two small Bitcoin fees are cheaper than the horror of a five-figure mistake.

Verifying the send

Paste the txid into the chain's block explorer:

• Bitcoin: mempool.space or blockstream.info
• Ethereum and EVM L2s: etherscan.io, arbiscan.io, basescan.org
• Solana: solscan.io or explorer.solana.com
• Tron: tronscan.org

The states differ by chain. On Bitcoin and EVM chains, a transaction progresses from Pending (waiting in the mempool) to Included in a block to Confirmed as more blocks stack on top. Bitcoin convention treats 3 to 6 confirmations as meaningful finality. On Ethereum, each new block adds confidence, but confirmations are not finality. It takes about 15 minutes for an Ethereum block to finalize (ethereum.org on finality). Solana uses its own statuses instead — processed, confirmed, finalized — with finalized being the safe endpoint.

Exchange deposits follow the exchange's confirmation policy, not the chain's. Your Bitcoin tx can be confirmed on-chain a few minutes after sending and still show as Pending on the exchange until it hits their internal threshold. Check the deposit page on the receiving side, not just the explorer. For the full life cycle of what happens after you hit send, see the Blockchain 101 walkthrough.

If the transaction disappears from one explorer's mempool without confirming, that does not prove it was dropped network-wide: the "mempool" message requests the TXIDs of transactions that the receiving node has verified as valid but which have not yet appeared in a block, so each mempool is one node's view. Check the txid in a second explorer and in your wallet history, and don't create a new payment until its status is clear, or both versions may end up paying. Bitcoin Core nodes expire low-fee transactions from the mempool after roughly two weeks by default. On EVM chains, a pending transaction stays pending until a proposer includes it, until another transaction with the same nonce replaces it, or until it is dropped. While it is pending, its lower nonce holds back every later transaction from the same address, so check its status and your account's current nonce in an explorer before you replace it.

If your transaction is stuck

Bitcoin — Replace-By-Fee (RBF). A replacement spends at least one of the same inputs and pays more than the original. The acceptance rules are node policy and have changed over time: in Bitcoin Core 31.0, transaction replacements are only accepted if the resulting mempool's feerate diagram is strictly better than before the replacement, and for a transaction in a cluster by itself it's sufficient for a replacement to have a higher fee and feerate than the original. Starting with v28.0, Bitcoin Core's -mempoolfullrbf option defaulted to on, and version 29.0 removed the option, making full replace-by-fee the standard behavior (Bitcoin Core 29.0 release notes). Whether you can replace a send still depends on your wallet offering it and on the relay policy of the nodes it reaches. Use your wallet's fee-bump flow rather than building a replacement by hand: Zelcore's BTC sends signal RBF, and an unconfirmed Bitcoin transaction in your Zelcore history shows a Replace by Fee option. A higher fee may still fail to confirm first: the higher-fee transaction might not be the one that confirms, but only one of the two versions can be confirmed (Bitcoin Core 0.15.0 release notes). Check in a block explorer which version confirmed before you treat the send as changed.

Bitcoin — Child-Pays-For-Parent (CPFP). If RBF is not available — or if you are the recipient waiting on a stuck incoming tx — spend the unconfirmed output in a new high-fee transaction. Miners that use ancestor- or package-aware fee evaluation can then include both the parent and child together based on their combined fee rate.

EVM — Speed up. Submit a new transaction with the same nonce and higher fees. Raise both the max fee and the max priority fee: Geth, a widely used Ethereum client, rejects a replacement unless both rise by at least its price-bump threshold (go-ethereum transaction pool code), which is 10% by default. Most wallet UIs call this Speed Up and set the fees for you. Only one transaction with that nonce can confirm; the other drops.

EVM — Cancel. Submit a new transaction with the same nonce, zero value, sent to yourself, with both fees raised the same way. A cancel is only an attempt: the original may still confirm first. Check in a block explorer which transaction with that nonce confirmed before you treat the payment as cancelled.

Solana. A Solana send can't stay pending for long: a given blockhash can only be used by transactions for about 60 to 90 seconds before it will be considered expired by the runtime (Solana transaction confirmation guide). If your send seems to have dropped, look up its signature in an explorer first. Before re-signing any transaction, make sure the original transaction's blockhash has expired (Solana retry guide). Only then, and only if the payment did not land, send it again, with a higher priority fee if the network is busy; a new payment signed too early can arrive as well and pay twice.

One last rule: rebroadcasting the identical signed transaction can help it reach more nodes while it is still valid, but it does not change the fee, so it will not rescue a send that is stuck because it pays too little. For that, use a replacement that pays more (RBF or an EVM speed-up) or, on Bitcoin, CPFP.

Next up

You can now move crypto between addresses cleanly and recover when a transaction stalls. In Part 5, we shift from sending to swapping — trading one asset for another directly inside Zelcore, without an exchange account, and what the quoted rate is actually hiding.