MetaMask ETH transfer checks before signing
Metamask lets you review an ETH transfer's recipient, amount and estimated network fee before authorizing the transaction. Compare the complete destination address with the recipient's receiving instructions and confirm the selected network. Check the sending account and the fee payment option alongside the ETH value. For a standard transfer funded entirely in ETH, your balance must cover the payment plus fees. Signing authorizes the request; submission alone does not prove the recipient received a payment.
The send request and its confirmation details
The send function prepares a payment, while the confirmation screen presents the details you will authorize with the selected account. The extension and mobile send flows include network and asset selection, with native ETH as the asset for a direct ETH payment. The destination and amount at confirmation should match the payment you intended. A connected application may also propose a contract interaction with an attached ETH value. Its destination and transaction data describe the action it asks your account to authorize. A familiar application name does not establish that these details match your intention.
The boundary between a draft and authorization
An unsigned draft can be rejected without paying a blockchain fee because no transaction has been submitted for execution.
Confirmation is the point to stop when the address, network or action differs from your intention. Your signature authorizes the transaction's contents; it does not certify the recipient's trustworthiness. Altering the destination changes the contents the signature must authorize. A message-signing request has a different payload from a transaction request. It does not establish that an ETH payment occurred, even when the message mentions a payment.
The network the recipient accepts
The network selected for the transfer must match a network the recipient supports for ETH deposits or payments. Ethereum Mainnet and other networks maintain separate transaction histories and balances. Some compatible networks use the same account address format. A matching address therefore does not establish that the recipient expects funds on the network currently selected.
An ordinary send remains on its selected network; it does not perform a bridge operation by itself. A service-managed deposit address also depends on the service's accepted networks. The ability to control an address on another network is separate from a service's willingness to credit that deposit, so compare the receiving instructions with the network attached to the transfer.
The complete destination address
Compare the entire destination address with receiving information obtained from the intended recipient, including characters hidden by an abbreviated display. Address poisoning plants lookalike addresses in transaction history through unsolicited transfers. Recognizing the beginning and ending of an address can miss differences in its middle. An entry in recent activity is therefore an unreliable substitute for the recipient's receiving instructions.
Saved contacts
An address-book label is a local name for a stored address. It helps you recognize a contact, but the full address remains the destination your transaction uses. For a service deposit, a familiar label does not establish that its receiving address or accepted network remains appropriate.
Pasted addresses
Clipboard malware can replace an address between copying it and pasting it into the wallet. Compare the pasted destination with the address the recipient supplied. Unexpected replacement calls for stopping the transfer and investigating the device. Manually correcting a pasted address does not resolve the underlying possibility of malware.
The ETH amount and the balance needed for fees
For an ordinary Ethereum transfer with the network fee paid in ETH, the sending account funds both the payment and gas. The payment amount goes to the recipient, while the network fee pays for processing. The network fee does not reduce the ETH value credited to the destination. A displayed total debit can therefore exceed the amount entered as payment.
An insufficient-funds error can arise even when the account holds the ETH amount you want to send. Funds in another wallet account do not automatically cover this account's fee. The selected account needs enough available balance for the transaction's funding requirement. A disabled confirmation button may reflect this problem. If the fee payment option changes, the relevant balance check changes with it.
The fee estimate and the signed limits
An estimated network fee predicts processing costs; the signed limits define the maximum resources and gas price you authorize. The estimate can change with network demand before confirmation.
Gas units and execution
The gas limit caps how much computational work the transaction may consume. Contract execution or transaction data can require more work than a simple payment. For an ordinary Ethereum transaction, the execution fee equals gas used multiplied by the effective gas price. Unused gas does not automatically become an extra fee simply because the limit permits it.
Price limits under EIP-1559
The maximum fee per gas caps the combined per-unit price. The maximum priority fee sets a separate ceiling for the validator's tip. These are ceilings; the full maximum is not automatically charged. Advanced values need their units to remain meaningful. A per-unit gas price is different from the ETH amount sent.
Base fee
Ethereum's base fee changes with block demand. An EIP-1559 transaction cannot be included while its maximum fee per gas falls below the required base fee. This restriction can keep a signed transaction waiting even when its address and payment amount are correct.
Priority fee
The priority fee rewards the validator for including the transaction. Its effective amount is limited by the space remaining under the maximum fee after the base fee. It affects inclusion incentives without setting a fixed confirmation deadline.
Transaction data and contract recipients
ETH sent to an address with executable code can trigger contract logic even without additional transaction data, and acceptance depends on the recipient's code and the conditions it checks. A contract can reject an ETH payment. If execution reverts after inclusion, the transfer does not succeed and consumed gas still incurs a fee.
For contract calls, the eventual recipient can differ from the transaction's top-level destination, so the ETH value alone does not explain where a contract will forward funds. Read any decoded operation alongside its destination and balance changes. Token approvals concern permissions over contract tokens; a plain native ETH payment does not require that allowance.
Contract previews and address warnings
Confirmation can include address warnings and, for supported contract interactions, previews of estimated balance changes. An unfamiliar-address alert identifies a new destination. It does not establish that the destination is malicious. A similarity warning points to a possible mismatch with an address previously used. Both notices require comparison with the intended recipient's receiving information.
Standard off-chain simulations predict contract behavior without enforcing the outcome on-chain. A contract can behave differently during actual execution. When Added protection is enabled for a supported smart-account interaction in the extension, execution must match the simulation conditions or revert, with consumed gas still payable. This verification also adds computational work, which can increase the network fee.
Simulation availability depends on wallet configuration. The Basic Functionality setting controls simulations and other connected features, using external services. Where the wallet setup permits disabling it, doing so removes those features. That privacy choice changes the information available during transaction review.
A direct ETH payment from review to execution
An ETH payment is ready to authorize when its destination and network match the recipient's receiving instructions and its amount matches the intended payment. This case assumes a recipient account without executable code and enough ETH to fund both the value and fee.
| Stage | Payment details | Observable state | Control over the transfer |
|---|---|---|---|
| Review | Selected sender, network, recipient, ETH value and fee settings | Unsigned request awaiting authorization | The signer can revise or reject the draft |
| Signing and submission | Authorized transaction carrying a signature | Submitted for processing; payment remains unconfirmed | The signer authorizes; network participants determine inclusion |
| Successful on-chain execution | ETH value credited to the recipient; gas charged separately | Successful execution recorded in an included block | Spending authority follows the destination account's key |
If the balance covers only the payment, this ETH-funded path cannot proceed unchanged. Eligible gas included transactions can offer another token for fees. The option requires a supported network with Smart Transactions and Estimate balance changes enabled. Review the selected fee token's available balance and the full quoted charge, including the wallet service fee. Paying fees in another token still leaves the ETH payment itself to fund.
Hardware signing and the device display
A connected hardware account uses the device to authorize the transfer, making its own transaction display part of the payment review. The private signing key remains on the hardware in its intended connected-account setup. Compare the destination and amount on that display with the intended payment. If the device and wallet disagree, stop before approving on the device. Readable information varies with the hardware and transaction type. An undecoded payload provides less context about contract actions than a plain payment display.
Device possession protects access to the signing key; it does not authenticate a proposed recipient. An incorrect payment can still carry a valid signature when the key holder authorizes it.
The on-chain record and the receiving service
An on-chain transaction record distinguishes a submitted request from a successfully executed ETH payment on the network you selected. The wallet's transaction details provide its transaction hash and access to the network's block explorer. Inspect execution status alongside the destination and ETH value. For a contract interaction, the top-level transaction alone may not describe every movement of funds.
A transaction hash identifies the request and can exist before block inclusion. With Smart Transactions, pending requests may not immediately appear on third-party explorers. The wallet's pending view and the confirmed blockchain record describe different states. An absent explorer result during that pending period does not establish a failed payment.
Block inclusion and finality are different network states. Finality provides stronger assurance that the included block will remain part of the chain.
Successful delivery to a service's deposit address does not establish that the service has credited your account. A receiving service may require additional confirmations or a minimum deposit before recording an ETH credit.
Metamask: common questions
Does sending ETH between my own accounts still incur gas?
An ordinary on-chain ETH transfer incurs a network fee even when you control both accounts, because moving funds between different addresses remains a blockchain transaction despite their local account names. The sending account must satisfy the funding requirement for the chosen fee payment method.
Is a small test payment proof that a later ETH transfer will be safe?
A successful test payment establishes only that particular transfer's outcome. The next transaction has its own address, network, amount and fee settings. Those details can change, so earlier success does not validate a later request. Receiving services may also impose minimum deposit amounts, making an extremely small test unsuitable for confirming account credit. Each later payment needs its own authorization.
When can an earlier pending transaction delay my ETH transfer?
For ordinary Ethereum transactions from the same account, a later nonce waits for earlier nonces to be processed. The nonce is the account's sequential transaction counter. Transaction details show this number, helping identify an ordering issue separately from a recipient-address error. This ordering applies within the same account on the same network. Activity in another account does not share that account's nonce sequence.
What information can the recipient see from a normal ETH transfer?
A standard Ethereum payment publicly reveals its sending address, receiving address and ETH value. A block explorer also makes transaction details and the addresses' on-chain balances accessible. Knowing a public address does not grant spending authority. However, linking that address with someone's identity can reveal more of their financial activity.
· last updated