Lightning payments travel in onion packets: each hop peels one layer, learns only the next peer and its instructions, then forwards.
Complete Step 1 // Required reading in the study plan above, then continue here.
Step 2 — Core idea: peel one layer
Without onions, intermediate nodes would see the full route and payload. Privacy and security against some attackers depend on this layering — but Lightning is not anonymous cash by default.
Analogy: Nested envelopes. Each post office opens only its envelope, stamps the next address, and cannot read the inner letters.
Loading diagram…
Each peeled layer yields instructions: next node, amounts, outgoing CLTV, maybe custom records. Failures return encrypted error onions the payer can interpret for retries.
Builder habits: do not log decrypted onion internals; treat timing correlation as a leak vector; lengthen routes only within fee/latency budgets.
Done when: You can state what a middle hop must not learn about the final destination.
Step 3 — Visibility brief (lab)
Write the learns / does not learn list for a middle hop. Add one privacy caveat you would put in a README.
Done when: Lab evidence (visibility brief + caveat + source) is complete.
Next lesson
Transport & Noise — encrypted authenticated peer links under the BOLTs.