Reviewing is how Lightning implementations stay safe. You will learn more from careful review than from rushing another feature PR.
Complete Step 1 // Required reading in the study plan above, then continue here.
Step 2 — Context: what maintainers expect
Use Pull’s Review Club picks, or browse open issues filtered for Lightning tracks.
What to check:
- Does it solve the claimed problem?
- Are there tests?
- Are edge cases handled?
- Is the diff minimal?
Loading diagram…
When reviewing channel, routing, or BOLT-adjacent changes, name the concept explicitly: inbound capacity, preimage flow, onion privacy, etc.
Done when: You can explain why silence is not an ACK.
Step 3 — Practice: review one PR (lab)
Read description, inspect diff, reason about tests. Draft conventional comments. State your verdict and the protocol concept involved.
Checklist
- Comments are actionable (what + why)
- You checked tests / verification claims
- You named a protocol concept from this roadmap
Done when: Lab evidence (PR URL + notes + verdict + concept) is complete.
Next lesson
Contribution Rubric — score your own attempt before opening a PR.