Chapter 6 · What Happens in an On-chain Transaction?

A Real-World Problem

You press confirm.

The interface spins for three seconds, then ten. It changes to “submitted,” with small text beneath: awaiting confirmation 1/12.

You send the transaction identifier to the recipient. They say it has not arrived.

Later it shows 3/12. The recipient sees it, but their platform says they must still wait.

Has the money arrived or not?

The question is more complicated than it looks. Even on one chain, rules differ:

• One platform requires one confirmation; another requires thirty.
• The same platform may require different counts for 100 yuan and a large deposit.
• Some chains display only “completed,” with no count.
• Sometimes the interface says “successful” but the money never arrives, and the fee is still charged.

That last point confuses beginners most: why pay for a failed transaction?

Chapter 1 distinguished receipt displays from settlement. This chapter unpacks the entire gap: every step between confirmation and irreversible receipt, how each can fail, and where confidence is justified.

It also brings the first five chapters together: ledgers (chapter 2), consensus (3), ordering and work (4), and signatures and keys (5).

Thought Experiment

Return to chapter 5's wall and add chapter 4's sequence of appended pages.

You want to pay five shells to the shop. Here is the complete process:

Step one: write a note. It says, “Transfer five from my row to the shop's.” Besides amount and recipient, it needs two things:

• A sequence number, saying this is your eighth note. Without it, someone could submit the same note again and charge you twice.
• A delivery fee for whoever copies it onto the wall.

Step two: stamp it. Everyone can verify your private seal produced the imprint. Changing any character invalidates it.

Step three: put it in the basket. A large basket in the village center holds all pending notes.

Crucially, the basket is public. Anyone can inspect every note, including yours. They know what you intend before it takes effect.

Step four: wait for a page writer. Periodically, someone selects a batch and copies a new page.

Why select yours? The delivery fee. Higher bids go first; lower bids may wait a long time. A full basket drives fees high, while a nearly empty one allows a small fee to work quickly.

Step five: your note appears on page 100. Does it count now?

Step six: the next morning, someone brings a longer book.

It diverges from page 99 onward and exceeds the current sequence. Under chapter 4's rules, the village accepts it instead.

Your note is absent. If lucky, it returns to the basket. If unlucky, the replacement history contains a payment from you to the attacker, with your genuine imprint. Can the attacker construct that conflict merely by seeing your note? No: they lack your private seal. But the payer can create it themselves.

Step seven: the village adopts a habit. Every additional page after yours raises the work required to overturn it. After six or seven, the cost becomes too high to bother.

But the cost is never infinite. It is merely uneconomical.

Step eight: a neighboring village changes the rule. Instead of choosing the longest sequence, a group of staked bookkeepers periodically signs together: “Locked through page 100. Changing it forfeits the stake.”

After signing, page 100 cannot change unless enough members are willing to lose their entire deposits together.

Pause: does “counts” mean the same thing in steps seven and eight?

One means reversal is too expensive to attempt. The other means reversal violates the rules and incurs penalties.

These are different assurances, though both interfaces display “completed.”

Your Decision

You run the shop. Someone pays with a note.

When do you hand over the goods?

What Happens

The choices are four settings of one question:

How much protection against reversal do you want to buy?

You pay through waiting. Longer waits lower reversal probability and raise its cost.

Three increasingly important conclusions follow.

First, finality is a curve, not a switch.

No chain is perfectly certain at second zero. Some curves become almost vertical at explicit final confirmation; others approach certainty without reaching it. Every curve begins the same way: a newly submitted transaction has no assurance.

Second, “successful” appears at three stages with different meanings.

The same green checkmark often represents three separate things:

Third, a failed transaction still pays fees.

Chapter 4 explains why. Fees buy processing work, not success. The writer reads your note, executes it, finds insufficient balance or unmet conditions, and records failure. The work actually happened.

You pay for computation, not the outcome. Chapter 7 develops this distinction.

Build a Model

Seven boxes separate intent from irreversibility. This is stage 1's most useful diagram to memorize.

Unpack each box:

Three boxes deserve special attention because losses concentrate there.

Signing. It is the only point where you can still refuse. Afterward, the chain follows the signature, not your changing wishes. A signature may authorize future movement of a whole asset class, not just one transfer. Reject anything you cannot understand: this is the cheapest protection.

The mempool. Many people overlook that it is public. Before execution, the world can see amounts, recipients, swaps, and acceptable slippage.

Specialists watch it. Before a large price-moving order, they buy first, let your purchase raise the price, and sell afterward. Your worse price is their profit, earned entirely within the rules. Chapters 18 and 24 unpack this.

Inclusion. Included and successful differ. Failed and successful transactions sit side by side in the same block with different status labels. Common failure causes include insufficient resource budgets, contract rejection conditions, and prices moving beyond your tolerance.

Use this practical scale for future transfers:

The larger the amount, the less familiar the counterparty, and the less recourse available, the farther right you should wait.

Conversely, do not wait for full finality on every tiny payment. That spends protection costs in the wrong place.

What It Is Called

Now name the steps.

Bring it together:

Finality is progressively strengthening assurance rather than simply an instant.

Ask how settled the payment is, and whether that assurance matches its amount, not just whether it arrived.

Hands-on

AI Lab

These transaction details come from a testnet. Explain each field:

(Paste the fields you recorded here.)

For each, state:
1. What it records
2. Who determines it: sender, network, or block producer
3. What symptoms an incorrect value would produce

Finally, state the transaction’s current status and whether it can still be overturned.

Based on this transaction:

1. Are inclusion and successful execution the same? If included execution fails,
is a fee still charged, and why?

2. Can I reverse it now? What if it remains in the mempool?
What if it has already been included?

3. How many confirmations should I wait for a large incoming transfer?
Do not give a number first. Explain which variables determine it.

4. Is this chain’s finality probabilistic or deterministic, and what supports that answer?

Real-World Case

Change One Variable

Takeaway Questions

Choose three of the Eighteen Questions for this chapter.

Chapter Check