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. If you also understand the small-test-send rule and the speed-up/cancel moves, you will almost never lose money to a stuck or misdirected transaction.
Before you start
A send is a signed instruction broadcast to a public network. Once Zelcore signs it with the private key derived from your seed phrase and the network accepts it, nobody — not Zelcore, not an exchange, not the recipient — can reverse it. Treat every confirm button as a final decision.
Three 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. Send ETH-USDT to a Tron address and the funds are gone.
- 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. Check the first four and last four characters against the source — a clipboard hijacker can swap the middle silently.
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 always 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 and Taproot addresses produce smaller transactions and therefore cheaper fees. Live rates are visible on explorers like mempool.space. In calm conditions the floor sits near 1 sat/vB; during congestion it can climb to 50, 100, or 200+ sat/vB. 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. The priority fee is your tip to the validator. 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 (the maximum budget per transaction is 1.4 million compute units). 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 (600 points by default) that covers simple transfers. Smart-contract calls consume energy. 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.
Sending in Zelcore, step by step
- Pick the asset and network. Open the asset from the dashboard. Confirm the network — USDT-ERC20 and USDT-TRC20 are listed separately for a reason.
- Enter the recipient address. Paste it, then visually compare the first four and last four characters against the original source (email, invoice, the other wallet's receive screen). Never type long addresses by hand.
- Enter the amount. Zelcore shows the fiat equivalent beside it. Use Max only after confirming the displayed fee will be subtracted — otherwise your send will fail for insufficient balance.
- Choose the fee tier. Zelcore surfaces Slow, Normal, and Fast tiers based on live network conditions. Pick Normal for routine sends. Pick Fast only when time matters — an arbitrage, a dipping exchange deposit window, a time-locked trade.
- Review and confirm. Zelcore signs the transaction locally on your device, then broadcasts it. You get a transaction ID (txid or tx hash) immediately. Copy it before closing the screen.
One common tripwire on EVM chains: sending an ERC-20 token requires a balance of native ETH (or MATIC, BNB, AVAX on other EVMs) in the same address to pay gas. If you funded an address with USDC but no ETH, the send will not even broadcast.
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. Two to five dollars is enough. 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 loses five dollars, not five 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 Bitcoin, a test send also exposes whether the recipient uses a legacy address format that will cost you extra on the real transfer. On EVM, it reveals smart-contract rejection issues (some contracts refuse direct token receipts) before you commit the full amount. 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
Transactions progress from Pending (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. Ethereum wallets usually treat 12 to 32 block confirmations as settled. Solana uses its own status — 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 the mempool without confirming, it was likely dropped for paying too little fee. Bitcoin Core nodes expire low-fee transactions from the mempool after roughly two weeks by default. On EVM chains, the transaction stays stuck with its nonce reserved, blocking every later transaction from the same address until it resolves.
If your transaction is stuck
Bitcoin — Replace-By-Fee (RBF). If the original transaction opted into RBF under BIP-125 (Zelcore's BTC sends enable this by default), you can rebroadcast a replacement that spends at least one of the same inputs and pays a higher absolute fee than the original, plus enough extra to cover its own relay bandwidth. In practice, wallets bump the fee rate as well, which is how Bitcoin Core's standard mempool policy ends up enforcing replacement. The network drops the old version and miners include the new one.
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 a higher max priority fee. The network accepts whichever version confirms first; the slower copy drops. Most wallet UIs call this Speed Up.
EVM — Cancel. Submit a new transaction with the same nonce, zero value, sent to yourself, with a higher fee. The pending transaction is replaced by the cancel, freeing every later nonce.
Solana. Stuck transactions are rare by design — a transaction's recent blockhash is only valid for 150 slots (about a minute at roughly 400 ms per slot), after which it expires and is rejected. If your send dropped, simply retry with a higher priority fee.
One last rule: do not rebroadcast an identical transaction from another wallet or browser hoping it will go through. Every identical rebroadcast without a fee bump is ignored. The network sees it, deduplicates it, and moves on. The only way out of a stuck transaction is a replacement that pays more.
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.
