BR Academy
Intro to Blockchain: How It Works and Why It Matters
0%
Exit course
Transactions and Fees·Lesson 13 of 25·12 min

Anatomy of a Transaction

The Concept

A blockchain transaction is, at its core, a structured and signed instruction: "move this amount from this address to that address," with a small fee attached to pay for its inclusion. Everything in Module 4 builds on understanding this structure, so this lesson breaks a transaction down field by field before the next lessons trace what happens to it after it's created.

A typical transaction carries these core fields:

  • Sender (from) — the address authorizing the transfer. This is implied by the signature rather than typed in separately: the signature itself proves which address is sending.
  • Recipient (to) — the address receiving the funds (or, for a smart contract interaction, the contract's address).
  • Amount (value) — how much is being transferred.
  • Nonce — a sequential counter, unique per sending address, that increases by exactly one with every transaction that address sends. Its job is to prevent replay attacks: without it, someone who intercepted a valid signed transaction could rebroadcast the exact same message repeatedly, and the network would have no way to tell a legitimate resend apart from a malicious copy. The nonce makes every transaction from a given address unique, even if the amount and recipient are identical to a previous one.
  • Fee (and on some chains, gas-related fields) — compensation for whoever does the work of including the transaction in a block, covered in depth two lessons from now.
  • Signature — the cryptographic proof, produced with the sender's private key (Module 3), that the sender authorized exactly this transaction and no other.

These fields get bundled together into one data structure, signed as a single unit (so changing any field invalidates the signature), and then broadcast to the network — the starting point for the lifecycle lesson that follows this one.

Some chains add a field beyond the basics above. On smart-contract platforms like Ethereum, a transaction can also carry data — a payload instructing a smart contract to run some function, rather than (or in addition to) simply moving value between accounts. In that case the "to" address is the contract's address, and the "data" field encodes exactly which function to call and with what arguments. This is how swapping tokens on a decentralized exchange, minting an NFT, or voting in an on-chain governance proposal all work under the hood: they're still ordinary signed transactions, just with a data payload that triggers contract code instead of (or alongside) a plain transfer.

It's worth being precise about what the signature actually covers: every field discussed above is hashed together into one value, and the signature is produced over that single hash. This is why the system is often described as tamper-evident rather than tamper-proof — nothing physically stops someone from altering a field in a transaction they've intercepted, but doing so changes the hash, which instantly invalidates the signature and causes every honest node to reject it.

It's also worth noticing what a transaction does not contain, since beginners often assume otherwise. It carries no usernames, no personal identifiers, and no description of "why" the transfer happened — only addresses, an amount, and the bookkeeping fields above. Any meaning beyond "value moved from A to B" is something humans attach afterward (a label in an exchange's internal records, a note in a spreadsheet, a memo field some wallets optionally support that isn't enforced by the protocol itself). This is part of why blockchains are better described as pseudonymous than anonymous: the transaction itself reveals no identity, but if an address is ever linked to a real person — through an exchange's KYC records, a public donation page, or simply reusing an address repeatedly — every transaction that address ever sent or received becomes traceable to that person, forever, since the ledger never forgets.

Transaction size also matters in ways that connect directly to the fee lesson ahead. A transaction with more inputs, a longer data payload, or a smart-contract call that touches more pieces of on-chain storage takes up more space in a block and more computational work to process — and block space is limited, so bigger or more complex transactions generally cost more to include. A simple transfer between two addresses is about as small and cheap as a transaction gets; a transaction that calls a smart contract function, by contrast, bundles in that data payload mentioned above and typically costs noticeably more.

Worked Example

Read a real transaction the way you'd see it on a block explorer, matching displayed fields back to the components just taught:

  • "From: 0x7a2f...91bc" — the sender address, derived from (and provable by) the signature.
  • "To: 0x3e88...04dd" — the recipient address.
  • "Value: 0.25 ETH" — the amount transferred.
  • "Nonce: 14" — this is the sending address's 15th transaction ever (nonces start at 0), making this exact transaction unambiguous even if an identical-looking one was sent before.
  • "Transaction Fee: 0.0008 ETH" — what was paid to get this transaction included.
  • "Signature / Hash: 0x4f0d..." — the unique cryptographic fingerprint and proof of authorization for this specific transaction.

Every one of these fields existed before the transaction was broadcast — the block explorer isn't adding information, it's just displaying what was already bundled and signed.

Exercise

On paper (not on-chain, no software needed), draft a mock transaction with all required fields filled in: a made-up sender address, a made-up recipient address, an amount, and a nonce value that would make sense if this were, say, the 6th transaction that sender had ever made. Then write one sentence explaining what would happen to your mock transaction's validity if you changed the amount after "signing" it — tying back to why signatures cover the entire bundled transaction, not just part of it.

Recap

  • Every transaction is a structured, signed instruction containing sender, recipient, amount, a nonce, a fee, and a signature — plus, on smart-contract chains, an optional data payload that calls contract code.
  • The nonce prevents replay attacks by making every transaction from a given address unique, even if the amount and recipient repeat.
  • Understanding this fixed structure is the prerequisite for the next two lessons: how a transaction travels from broadcast to confirmation, and how its fee is actually priced.

Resources

← Addresses and Derivation From Broadcast to Confirmation →