Before a transaction ever touches the network, it must be constructed. Think of this as filling out a cheque or a command packet. In the EVM architecture, this packet contains specific, non-negotiable fields.
An ordered counter (0, 1, 2...) specific to the sender. This prevents replay attacks. You cannot submit transaction #5 before transaction #4 is confirmed.
The fuel budget. Limit is the maximum computational work you allow; Price (or Priority Fee) is the bribe you pay per unit of work to be included.
The destination address and the amount of native currency (ETH/BNB/MATIC) to transfer. For contract interactions, 'Value' is often 0.
The instruction payload. If you are swapping tokens, this field contains the method ID for swap() and the encoded parameters.
Once the packet is constructed, it must be signed. This uses your Private Key to generate a cryptographic signature (v, r, s). This is the "Zero-Trust" element: the network doesn't need to know who you are, only that you hold the keys to this specific address.
Crucially, signing happens offline. Your private key never leaves your device.
After signing, your wallet broadcasts this raw hex string to a node (via RPC providers like Infura or Alchemy). This node acts as your gateway to the peer-to-peer network.
The "Memory Pool" is the waiting room for unconfirmed transactions. It is not a single central queue but a distributed buffer on every node.
The Auction Mechanism: Block space is finite. Validators (or builders) select transactions from the mempool based on profit. They will almost always pick the transactions paying the highest "Priority Fee."
Note: Sophisticated bots also monitor the mempool to "front-run" profitable trades, a phenomenon known as MEV (Maximal Extractable Value).
A validator selects your transaction, packages it into a block, and executes it. This is where the state change actually occurs.
The EVM subtracts the gas fee from your balance, increments your nonce, and runs the code in the "Data" field. If the code triggers internal transfers (e.g. sending tokens), those happen sequentially.
The outcome is recorded in a "Transaction Receipt." This confirms success (Status 1) or failure (Status 0). Importantly, even failed transactions pay gas because the network still did the computational work to determine it would fail.
Just because a transaction is in a block does not mean it is permanent immediately. In many chains (like Bitcoin), a block can be "orphaned" if two miners find blocks simultaneously.
Probabilistic Finality: The deeper the block gets buried (more confirmations), the safer it is. This is why exchanges wait for 6-12 confirmations.
Modern chains like Ethereum (post-Merge) uses "Gadget-based" finality. After roughly 12-15 minutes (2 epochs), a block is marked "Finalized." Reverting it would require burning at least 33% of the total staked ETH—an economic impossibility for most attackers.
Likely because your gas price is too low. Validators are ignoring your low bid in favor of more profitable transactions. You can 'unstuck' it by sending a replacement transaction with the same Nonce and higher gas.
In Ethereum (EIP-1559), the 'Base Fee' is burned (destroyed forever), reducing supply. The 'Priority Fee' (tip) goes directly to the validator as profit.
No. Once confirmed on-chain, the state change is immutable. There is no 'admin' to revert the database.