In June 2020 two Ethereum transactions, one moving 0.55 ETH and one moving 350 ETH, each paid a fee of exactly 10,668.73 ETH. Around $2.6M each. Both were mined by the same pool, which tried to find the sender.
Why it happened is still disputed. Vitalik Buterin called it a mistake. Other researchers argued the sender was being coerced and was burning funds under duress. No confirmed explanation was ever published, and we are not going to pretend otherwise.
What is not in dispute is the part that matters to you: the fee fields are an instruction, not an estimate, and the network charged exactly what they specified.
You are about to spend a course learning to read signature requests. That is impossible until you can read a transaction, because a hostile request is only recognisable against a correct model of a normal one.
A transaction is not an instruction to a company. There is no clearing department, no reversal window, and nobody to call. It is a signed message that a network executes literally.
The fields
Six things travel in an ordinary transaction. Each one fails differently.
to is the destination. If it is an address you did not verify, the funds are gone and the transaction succeeded. This is the field address poisoning attacks, covered in lesson 4.
value is how much native currency moves. Zero is normal and common: most interesting transactions move tokens or call contracts, and the token movement lives in the calldata, not here.
data (the calldata) is what you are actually asking a contract to do. On a plain transfer it is empty. On anything else it is the entire substance of the transaction, and it is the field wallets are worst at showing you. Lesson 3 is about that failure.
nonce is a per-account counter. It exists to stop the same signed message being replayed, and it forces your transactions to execute in order. Nonce 8 cannot execute until nonce 7 has.
Gas limit is the maximum work you authorise. Set it too low and the transaction runs out of gas, fails, and still charges you for the work performed. Set it high and you are not charged more, because you pay for gas used, not gas authorised.
The fee fields are where the money goes wrong. Under EIP-1559 there is a base fee the network sets and burns, a priority fee you offer to the validator, and a max fee you are willing to pay per unit.
The gas limit is how much I will pay.
The gas limit is a unit count, not a price. Your cost is units used, multiplied by price per unit. The two numbers are set separately, and a wallet that shows you one without the other is showing you half of the answer.
The multiplication nobody does
A standard ERC-20 transfer uses about 65,000 gas. Suppose your wallet proposes a gas limit of 65,000 and a max fee of 30 gwei.
A gwei is 0.000000001 ETH.
Maximum cost = 65,000 x 30 gwei = 1,950,000 gwei = 0.00195 ETH.
At an ETH price of $3,000 that is $5.85, and it is a ceiling rather than a bill. If the base fee at inclusion is 12 gwei and you offered 2 gwei priority, you pay 14 gwei per unit and the rest is never charged.
Actual cost = 65,000 x 14 gwei = 0.00091 ETH, about $2.73.
Do this multiplication once by hand and it takes forty seconds. Do it every time and it becomes a glance. The two numbers are always on the screen, and a fee that is wrong by three orders of magnitude does not look subtle once you are in the habit of reading them together.
The lab at the end of this course asks you to do it under time pressure. That is deliberate.
Pending, stuck, and replaced
There is no cancel button, and any interface that appears to offer one is doing something else.
Because the nonce forces ordering, a transaction sitting unmined at nonce 7 blocks nonce 8 behind it. To clear it you broadcast a replacement: same nonce, higher fee. Validators take the more profitable version. The standard cancellation is a replacement that sends zero value to yourself, which does nothing except consume the nonce.
The common and expensive mistake is submitting a second attempt at the next nonce, assuming the first one failed. Both are valid. If the first eventually confirms, you have paid twice and sent twice.
Confirm the original is genuinely pending rather than confirmed. Read the status on a block explorer, not in the wallet that is already confused about it.
If your account is a smart account
Everything above describes an externally owned account, which is a keypair signing a transaction directly. If you are using a smart account under ERC-4337, the model shifts and you should know which one you are in.
You do not submit a transaction. You submit a UserOperation, which a bundler wraps into a real transaction and pays for. Consequences worth holding onto:
- The address that pays gas may not be you. A paymaster can sponsor it, or you can pay in a token rather than the native currency.
- Nonces can be non-sequential, because the account contract defines its own replay protection.
- Several actions can be batched into one approval, which is genuinely better UX and also means one confirmation can authorise more than one thing. Read all of it.
- The account is a contract, so the contract is now part of your attack surface. That is new risk, not removed risk.
Under EIP-7702 an ordinary keypair account can temporarily behave like a smart account by pointing at contract code. That delegation persists until it is explicitly replaced, which is covered in F109.
A transaction is a literal instruction with six fields, and the network has no opinion about whether you meant it. Before you sign anything, you should be able to say out loud what the to address is, what the calldata does, and what the maximum fee multiplies out to. If you cannot answer all three, you are not ready to sign, and the next five lessons are about why that matters more than it sounds.