The best way to learn blockchain technology is to understand one shared-record problem, follow how an authorised change becomes accepted, and then test what the system can and cannot prove. Start with records, state, hashes and signatures before consensus, smart contracts or platform tools. You do not need to buy cryptocurrency to begin.
This guide turns the published eduKateSG blockchain library into a practical learning route. The numbered technical collection contains 100 topics with separate English and Simplified Chinese versions. The plain-language How Blockchain Works companions provide an easier entrance, while the extension workshops offer deeper practice. The complete reading map below connects these layers without asking you to read everything at once.
Did you know that choosing an ordinary database can be an excellent final answer in a blockchain assignment? Understanding the technology means knowing when its particular properties are useful, not recommending it for every problem. Your aim is to produce a clear explanation, a checkable trace and a defensible decision. Those are more meaningful signs of learning than recognising a large collection of technical words.
Find your next learning step
How to Learn Blockchain Technology · Learning guide 01
Choose your starting point · Learn the sequence · Plan study cycles · Check and repair · Complete reading map
Contents
Chapters 1–6
1. Choose an outcome before choosing a reading list
2. Diagnose the first missing connection
3. Use the library as three connected layers
4. Make one example travel with you
5. Foundations: learn what the system is trying to coordinate
Chapters 7–12
7. Consensus: keep validity, selection and finality separate
8. Transactions and execution: follow the changing state
9. Architecture and scaling: map responsibilities before performance
10. Infrastructure: inspect how an answer was obtained
11. Security: connect each power to a failure and a recovery path
12. Digital value: separate a record from the right it describes
Chapters 13–18
13. Governance and China context: learn to read authority accurately
14. Applications: finish with a defensible decision
15. Choose a route that matches your responsibility
16. Study in English and Chinese without losing meaning
17. Plan study in cycles, not a race through pages
18. Keep five pieces of evidence that learning is becoming usable
Chapters 19–23
19. Avoid four common study shortcuts
20. Make safe practice the default
21. Use current documentation after you know what to ask
CHAPTER 1 OF 23 · Learn and apply
1. Choose an outcome before choosing a reading list
Decide what you want to be able to do
An interested adult may want to understand a news report. A student may need to explain a transaction. A developer may want to test a contract. A project manager may need to evaluate a supplier's proposal. These goals overlap, but they do not require identical starting points or equal depth in every topic.
Write one sentence: “After this stage, I want to be able to explain or check…” Finish it with an observable task. For example, explain why a signed message is not proof of a physical delivery; trace the effect of a rejected request; or compare two record systems against the same requirement.
Keep the goal small enough to inspect
“Master blockchain” is a direction, not a first assignment. “Trace a booking request and identify the point where it becomes accepted” gives you something to attempt and correct. Keep a larger ambition, but let the next piece of work be concrete. You can increase complexity after you can explain the first example without borrowing the article's wording.
Try five questions without looking up definitions
What is the difference between a present state and the history that produced it? Why might two copied records disagree? What does a valid digital signature establish? Why does ordering matter when two requests compete? Which part of a delivery claim cannot be established from a ledger alone?
These are starting questions, not an entrance examination. Mark each answer as clear, partial or unclear. If you can repeat a definition but cannot apply it to a small example, choose partial. That honest distinction makes the reading route much more useful.
Repair the cause rather than collecting more terminology
If you confuse a message with an accepted update, return to blocks, transactions and state. If you confuse a fingerprint with secrecy, return to hashing and encryption. If you know both definitions but cannot explain their relationship, practise a comparison. More advanced reading will not automatically repair an earlier distinction. The first unstable connection is often the most productive place to work.
Begin with a plain-language explanation when needed
The How Blockchain Works articles make one mechanism visible at a time: shared copies, fingerprints, signatures, agreement, finality, or outside-world information. Use them when the specialist vocabulary obscures the question. They are an entrance into the technical lessons, not an inferior route.
Move to the numbered technical workshop
The BC001–BC100 collection develops precise tasks, examples and limits. A technical article may ask you to classify a claim, replay state, reconcile evidence or make a decision. Read the opening carefully: it usually tells you what the workshop is designed to teach and what its model excludes.
Choose an extension for a specific purpose
The extension articles address deeper tasks such as nested calls, event decoding, storage migration and authority processing. Approach one when its prerequisite is clear and its task fits your goal. A difficult extension is not automatically a better next lesson. The right next lesson is the one you can connect to what you already understand.
A shared field camera
Imagine two school clubs and a community centre sharing camera C7. The centre stores the equipment; the clubs book time; an authorised employee records handovers. This is a fictional learning scenario, not a description of an existing service. Initially, C7 is available, held by the centre and not reserved.
Use that same example while studying different mechanisms. A reservation proposes a state change. A signature supports an authority check. A shared network must coordinate competing updates. An application shows the result. A handover acknowledgement is an external claim, and the physical camera may still be missing.
Change one condition at a time
First trace one valid reservation. Then try an unauthorised caller. Then repeat the same request. Then introduce conflicting reservations or a delayed screen update. By changing one condition, you can see which concept explains the changed outcome. When several conditions change together, it becomes much harder to identify why your prediction was wrong.
CHAPTER 5 OF 23 · Learn and apply
5. Foundations: learn what the system is trying to coordinate
Read BC001–BC010 for a common mental model
Begin with the nature of a shared record, compare databases and distributed systems, and identify the participants and their decision rights. The wider technology stack matters: the interface, storage and access service do not disappear because a ledger is present. The history lesson gives context rather than a product recommendation.
Produce a responsibility map
For C7, list who may request a booking, who may approve it, who can verify the result and who handles a disputed handover. Then compare a central database, signed records and a shared ledger. Name one requirement each arrangement can satisfy and one additional responsibility it creates.
Move on when you can explain the coordination problem without using blockchain as the explanation. If your answer is “we need trust,” specify what each party must trust another party to do. When a Blockchain Is Useful and When It Is Not is a useful checkpoint because it asks whether the proposed benefit survives a practical comparison.
Read BC011–BC020 by question, not by glamour
Hashes, signatures, inclusion proofs, identity-related keys, zero-knowledge proofs and shared control answer different questions. Resist the temptation to combine them into a single statement that something is secure. State the input, the check and the conclusion supported by that check.
Produce three evidence cards
For the camera's inspection report, write one card for detecting changed bytes, one for keeping content confidential and one for checking a signing key's relationship to the message. For each card, add a limitation. A matching digest does not establish honest inspection; a valid signature does not establish that the key was safely controlled.
Use Choosing Encryption, Hashing and Signing for a Blockchain Document Workflow to work through choosing operations for a document workflow. Progress does not require inventing a cryptographic algorithm. It requires choosing the right question and understanding the evidence a maintained implementation should supply. Leave key generation and production cryptography to appropriate, reviewed tools and procedures.
CHAPTER 7 OF 23 · Learn and apply
7. Consensus: keep validity, selection and finality separate
Read BC021–BC030 with an assumption sheet
Write four headings: valid candidates, participant weight, selected history and finality. Add timing and fault assumptions beneath them. A network label such as proof of stake does not fill every box. A large vote or work total does not make an otherwise invalid action valid.
Produce a bounded conclusion
Suppose two clubs submit conflicting requests. Explain how the application decides whether a request is allowed, then separately explain how the network coordinates accepted history. If the supplied description omits a finality condition, mark it unspecified rather than creating one.
Reading Blockchain Consensus Claims: Validity, Fork Choice and Finality provides fictional consensus descriptions for this kind of reading. Follow it with the partition, progress and finality lessons. You are ready to continue when you can explain why a node's current view, a valid block and a settled outcome are related but not identical statements. That distinction will return throughout the later modules.
CHAPTER 8 OF 23 · Learn and apply
8. Transactions and execution: follow the changing state
Read BC031–BC040 with a trace table
These lessons connect intent, transaction construction, account or UTXO models, ordering, resource budgets, execution, contract state and external inputs. Keep a column for the state before an operation and another for the state afterwards. Explain every change rather than jumping directly to a final balance or status.
Produce a success-and-failure comparison
For C7, compare a permitted reservation with a rejected duplicate. Then consider an included transaction whose execution fails in a specified platform model. Do not assume that all systems expose the same receipt fields, fees or rollback behaviour. The lesson's scope determines which effects you may infer.
Diagnosing Failed Blockchain Transactions: Rejection, Revert and Call Boundaries is especially useful for learning why failed is not a complete diagnosis. Its distinctions include rejection before inclusion, included execution failure and an inner failure handled by an outer program. A correct answer names the stage and the evidence, not merely the colour of the interface's status label.
CHAPTER 9 OF 23 · Learn and apply
9. Architecture and scaling: map responsibilities before performance
Read BC041–BC050 as architecture comparisons
Bitcoin, Ethereum, Solana and Fabric distribute tasks differently. Modular systems, rollups, data availability and payment channels introduce further responsibility boundaries. Do not learn them as a league table of faster and slower names. Ask who executes, orders, verifies, publishes and preserves the relevant information.
Produce a dependency diagram in words
Choose one architecture described by an article. Write a compact account of where the user's request goes and which result another participant can check. Name the assumptions introduced by a special component, such as a sequencer or external operator, if the particular design includes it.
For a scaling proposal, ask whether the headline speed concerns submission, execution or an outcome on which a recipient can rely. Treat a narrower measurement as useful for its own question, not as proof of the whole service. This habit makes the infrastructure and benchmark modules easier to understand later.
CHAPTER 10 OF 23 · Learn and apply
10. Infrastructure: inspect how an answer was obtained
Read BC051–BC060 as evidence-handling lessons
An RPC endpoint, a block explorer, a historical index and a full node are not interchangeable sources. A screen may combine chain-derived fields, decoded data and service-added labels. Network and block context matter when comparing answers. Index coverage matters when asking a historical question.
Produce a provenance sheet
Take the fictional explorer packet in Reading a Block Explorer: Separate Chain Evidence, Decoding and Labels. Mark which fields came from chain evidence, which were decoded and which were added by the service. Rewrite a broad claim as a narrower one supported by the supplied field. This is more instructive than browsing a live address and guessing what its activity means.
Then ask whether an apparently delayed update comes from the base network, the access endpoint or the indexer. Do not diagnose all visible delays as consensus failure. Learning to locate the layer is a transferable systems skill, useful beyond blockchain and important before you begin evaluating operational dashboards.
CHAPTER 11 OF 23 · Learn and apply
11. Security: connect each power to a failure and a recovery path
Read BC061–BC070 before live experimentation
The security module examines threat models, custody, recovery, programmable accounts, approvals, confirmation interfaces, defensive tests, audits, privacy and incident handling. Keep a list of who can act, block an action, change permissions and recover control. Those powers may belong to different parties.
Produce a control-and-recovery map
For the camera register, describe what happens if a routine signing key is lost and what happens if it is stolen. They are different situations. Name the evidence a replacement authority would need and which already accepted records remain. Avoid promising that a backup or emergency button restores everything.
Smart-Contract Defensive Testing: Build a Matrix That Can Catch the Wrong Result helps distinguish a useful test from a reassuring green result. Reading a Blockchain Audit Packet: Code Versions, Proof Scope and Upgrade Authority then adds the scope of an audit packet. Passing a bounded classroom exercise is a learning milestone, not evidence that you are ready to manage real assets or certify production security.
CHAPTER 12 OF 23 · Learn and apply
12. Digital value: separate a record from the right it describes
Read BC071–BC080 without turning study into trading
The module explores asset properties, token interfaces, metadata, claims, reserves, liabilities, pool arithmetic, lending, composability and operating budgets. Use the supplied synthetic data. Learning the mechanisms does not require opening an account, purchasing a token or executing a financial transaction.
Produce a claims-and-obligations explanation
If a digital record represents a right to use C7, explain who recognises that right and how it relates to the real equipment. For financial examples, identify the issuer, liability, reserve or redemption condition specified in the lesson. Do not infer these facts from a token name or balance alone.
Arithmetic can be a prerequisite here. If ratios, denominators, units or threshold comparisons are unclear, repair them before adding financial terminology. A carefully explained small calculation is more useful than a confident paragraph that confuses a technical balance with an enforceable or immediately redeemable claim.
CHAPTER 13 OF 23 · Learn and apply
13. Governance and China context: learn to read authority accurately
Read BC081–BC090 as decision-and-document tasks
Follow a rule change from proposal to effect, inspect voting assumptions, separate control from permission, and identify the specific activity described by a policy document. Mainland China, Hong Kong and Singapore require separate evidence cards rather than one blended account of digital-asset rules.
Produce a dated source card
Record the document's issuer, date, scope and the exact question it helps answer. Mark whether the passage describes a requirement, an objective, a proposal or a reported outcome. A dated goal is not proof of achievement, and a technology-development policy is not blanket permission for every commercial activity.
For readers in China, the Chinese siblings provide a complete technical route. Use Reading Mainland Blockchain Policy: Build a Document and Claim Evidence Ledger for the document-reading method and Mainland China, Hong Kong and Singapore: Build Separate Digital-Asset Evidence Cards for separating jurisdictions. Before a real decision, verify current official sources. The learning exercise develops source discipline; it is not a substitute for legal advice on a particular deployment.
CHAPTER 14 OF 23 · Learn and apply
14. Applications: finish with a defensible decision
Read BC091–BC100 with the user outcome in view
The final module asks about improvement claims, shipments, credentials, credential status, AI actions, sensor evidence, environmental boundaries, pilots, procurement and a capstone. These topics connect technical records with the wider service. Ask what changed for the user and how the claim would be checked.
Produce a decision memo
State the problem, compare plausible options, replay the supplied events, identify evidence gaps and recommend a bounded next step. Include what would make you change your recommendation. This is stronger than a one-sided list of blockchain benefits.
Blockchain Capstone: Decide a Shared Booking System from a Fixed Evidence Dossier gives a fixed dossier and a worked answer for a shared booking system. Attempt the assignment before reading its answer. Then revisit your decision when the governance fact changes. Choosing a non-blockchain option can demonstrate clear understanding when the evidence supports it. The technology is the subject you are learning, not the answer you are obliged to select.
CHAPTER 15 OF 23 · Learn and apply
15. Choose a route that matches your responsibility
For a general reader or teacher
Use the plain-language companions, the foundations and selected applications. Produce explanations and paper traces. For a child, select an age-appropriate task with an adult rather than assigning the whole technical catalogue. The existing child-learning guide remains the specialist entrance for that purpose.
For a developer or technical analyst
Add execution, platform architecture, infrastructure and defensive testing. Read official implementation documentation after the conceptual task is clear. A tutorial for one version or platform is not a universal blockchain specification. Record what you used and what you did not test.
For a project evaluator or policy reader
Prioritise trust models, evidence provenance, security, governance, policy and pilot decisions. You do not need to implement every algorithm to ask good questions, but you must not disguise an implementation gap as certainty. Use the full catalogue as a reference map; choose deeper technical lessons when a decision depends on their distinctions.
CHAPTER 16 OF 23 · Learn and apply
16. Study in English and Chinese without losing meaning
Use language switching to repair a specific gap
If an English term obscures an otherwise understandable concept, open its Chinese sibling. If the Chinese explanation is clear but you need to recognise an API or specification term, record the English label beside it. Work with the same example in both languages.
Keep a distinction notebook
Useful pairs include validity and finality, custody and ownership, execution and acceptance, hashing and encryption. Write a short contrast rather than a translation alone. For example, custody asks who controls an object or key in a stated arrangement; ownership raises a different set of rights and recognition questions.
The two language pages are two routes to the same learning task, not two different achievements you must accumulate. Explain the concept naturally in the language you understand best, then check that translating it has not removed a condition or widened a claim. Precise meaning matters more than sounding technical.
CHAPTER 17 OF 23 · Learn and apply
17. Plan study in cycles, not a race through pages
Use a repeatable cycle
Choose one question, read a relevant section, close it, explain the answer, attempt a small case and check your reasoning. Keep a note of the gap exposed by the attempt. In the next session, begin with that gap before adding a new topic.
A suggested six-cycle opening
Cycle one covers shared state and the problem. Cycle two distinguishes hashes, signatures and secrecy. Cycle three separates validity from agreement. Cycle four traces execution and a failure. Cycle five checks an evidence screen and an outside-world claim. Cycle six compares architectures and writes a short decision.
These are suggested study units, not six days or a guarantee of mastery. A unit may take several sessions. Use your available time, reading language and prior knowledge to set the pace. Returning to an earlier lesson after an unsuccessful explanation is part of the route, not evidence that the route has failed.
CHAPTER 18 OF 23 · Learn and apply
18. Keep five pieces of evidence that learning is becoming usable
Explanation, trace and comparison
Keep a one-minute explanation in ordinary language, a state trace with reasons for each accepted or rejected operation, and a comparison of two mechanisms. These show different abilities. A polished definition alone does not establish that you can follow an unfamiliar sequence.
Boundary and transfer
Add one unsupported claim rewritten into a defensible statement, and one new situation that changes a condition in the original example. For instance, change a current-state question into a historical-state question and identify the extra context needed. Or replace a known participant with an unknown one and reconsider the admission assumptions.
Review these pieces later without the article open. If you cannot reconstruct an argument, locate the missing step and repair it. Do not turn the portfolio into a performance display. Its purpose is to show you and a teacher where understanding holds and where the next explanation or practice should begin.
| Learning evidence | What to produce |
|---|---|
| Explanation | Explain the problem and mechanism without slogans |
| Trace | Show the state after every accepted or rejected action |
| Comparison | Choose the mechanism and explain an alternative’s limit |
| Boundary | Rewrite a claim to match the supplied evidence |
| Transfer | Change one condition and justify the new result |
Definitions without decisions
Recognising terms can create a comfortable sense of familiarity. Test it by asking which evidence would settle a specific question. If you cannot choose between a hash, signature, receipt or external observation, the definitions are not yet connected.
Coding before understanding the state
A running example can conceal uncertainty about what it should do. Specify the expected state change and a rejected case before following a tutorial. You do not need to build a production system to practise this discipline.
Reading answers before attempting the task
A worked answer is valuable for checking, but it can feel obvious after you have seen it. Write your first prediction before opening it. Keep the incorrect prediction so that the correction has a visible cause.
Treating every diagram as a complete explanation
Ask what each arrow carries, who controls the component and what happens if it fails. A picture that omits those details may orient you, but it cannot carry a full architecture judgment. Use diagrams to expose responsibilities rather than to decorate terminology.
Start with supplied, fictional data
Use paper records, symbolic identifiers and the article's synthetic packets. Do not paste personal information, seed phrases, secret keys or confidential organisational records into public tools. A learning task should not require a real financial commitment.
Understand the boundary of a development environment
A local development chain and a public testnet have different connectivity and visibility. A reset does not necessarily erase every copy of data or activity in connected services. The safe-practice extension explains these distinctions. Read it before moving from paper exercises to networked tools.
If you later practise with software, use current official instructions appropriate to that environment and keep a clear separation from production credentials and valuable assets. The exercises in this guide are deliberately executable on paper. Their purpose is to develop reasoning without making security, privacy or financial exposure the price of entry.
CHAPTER 21 OF 23 · Learn and apply
21. Use current documentation after you know what to ask
A concept and its implementation have different life cycles
The distinction between a signature and encryption is comparatively stable. A platform's supported transaction type, interface or upgrade status can change. Record the date and version of implementation material rather than mixing screenshots and examples from different periods.
Read with a question sheet
Before opening official documentation, write the question, the relevant component, the expected evidence and the assumption you need to confirm. Then identify whether the document is a current specification, an explanatory page, a proposal or a historical account. They are useful in different ways.
The NIST blockchain overview provides a dated foundation. Ethereum's developer documentation describes that ecosystem. Neither replaces the need to check the particular system and version in a real project. Documentation reading becomes much easier when you are looking for a defined answer rather than trying to memorise every page.
CHAPTER 22 OF 23 · Learn and apply
22. Understand what this learning route does not certify
Educational progress is not professional authorisation
Completing articles and exercises does not automatically qualify someone to audit contracts, advise on regulation, manage custody or deploy critical infrastructure. Those responsibilities require further knowledge, review and appropriate organisational arrangements.
Keep claims proportionate to the work completed
You can accurately say that you traced a specified example, completed a bounded test matrix or compared architectures against a given dossier. Do not widen that into a claim that all blockchain systems are safe, unsafe or interchangeable. Clear scope is itself an important result of the course of study.
This route is a connected reading and practice guide, not a credentialed programme or a promise about employment. Its value is the growing ability to ask better questions and support an answer. That ability can guide further study and help you recognise when a specialist review is needed.
Choose the next question you cannot yet answer
If your explanation is vague, use a plain-language companion. If the mechanism is clear but the evidence is not, open the matching numbered workshop. If the workshop is comfortable and a deeper execution detail matters, choose an extension. Keep the learning layers connected.
Turn the library into work you can check
The next article in this learning series explains a complete reading-and-practice session, including a new paper case, checking questions and an error-repair routine. It teaches how to study an existing lesson rather than replacing that lesson. Use it whenever reading seems clear in the moment but difficult to reproduce afterwards.
Below are all 100 numbered topics in their existing module order, the published plain-language companions and the extension workshops identified in the library at this review. The links lead to the original articles. There is no need to finish every branch before moving forward; use the map to find the concept, task or evidence question that your next piece of work requires.
Complete reading map
The existing numbered curriculum is shown in full below. Each row leads to the published lesson and its language sibling. The study outputs are suggested tasks for this learning guide, not certificates or claims that reading alone establishes competence.
01. Foundations · BC001–BC010
Suggested output: A problem and responsibility map
02. Cryptography · BC011–BC020
Suggested output: Three evidence cards with limitations
03. Distributed systems and consensus · BC021–BC030
Suggested output: A consensus assumption sheet
04. Transactions and execution · BC031–BC040
Suggested output: A state trace including failures
05. Architecture and scaling · BC041–BC050
Suggested output: A responsibility and dependency map
06. Interoperability and infrastructure · BC051–BC060
Suggested output: A field-by-field provenance review
07. Wallets, security and privacy · BC061–BC070
Suggested output: An authority and recovery map
08. Tokens and digital value · BC071–BC080
Suggested output: A claim and obligation explanation
09. Governance and China context · BC081–BC090
Suggested output: A dated document and decision card
10. Applications and practical judgment · BC091–BC100
Suggested output: A bounded recommendation from a fixed dossier
Plain-language companions · 35 published guides
These existing plain-language companions are English articles. Chinese readers can use the complete Chinese technical route above; a translated title is not being presented as a Chinese page.
How Blockchain Works | Simplest Explanation
How Blockchain Works | The Complete System
How Blockchain Works | The History
How Blockchain Works | What Can We Do with It
How Blockchain Works | Why We Need Blockchain
How Blockchain Works | Who Runs a Blockchain?
How Blockchain Works | An Idea into A Decentralized Ledger
How Blockchain Works | Why Time Is Key
How Blockchain Works | Closed Loop System
How Blockchain Works | A Record’s Journey
How Blockchain Works | Digital Fingerprints
How Blockchain Works | Keys and Digital Signatures
How Blockchain Works | Nodes and Shared Copies
How Blockchain Works | Consensus and Agreement
How Blockchain Works | Smart Contracts and Rules
How Blockchain Works | Oracles and the Outside World
How Blockchain Works | Public, Private and Consortium Networks
How Blockchain Works | Confirmations and Finality
How Blockchain Works | Wallets and Custody
How Blockchain Works | Tokens and What They Represent
How Blockchain Works | Supply Chains and Handovers
How Blockchain Works | Certificates and Credentials
How Blockchain Works | Databases and When Blockchain Helps
How Blockchain Works | Scaling and Layers
How Blockchain Works | Bridges Between Networks
How Blockchain Works | Fees and Computing Resources
How Blockchain Works | Governance and Upgrades
How Blockchain Works | Privacy and What Records Reveal
How Blockchain Works | Zero-Knowledge Proofs
How Blockchain Works | Block Explorers and Reading a Record
How Blockchain Works | Testing Rules and Finding Mistakes
How Blockchain Works | Merkle Trees and Small Proofs
How Blockchain Works | Data Availability and Missing Pieces
How Blockchain Works | Forks and Changing Histories
How Blockchain Works | Digital Identity and Proving Who You Are
Technical extensions · 19 topic pairs
Choose an extension only after its prerequisite task is clear. These workshops deepen the existing technical library rather than replace its foundational sequence.
Related introductions and family guides
Use these related introductions when their specific reader question matches yours. They remain separate articles; this learning series does not replace them.
Blockchain Versus Crypto for Parents and Children
Problems a Blockchain Might Experience | What Can Go Wrong and Why
Can You Correct a Mistake on a Blockchain? | A Simple Guide for Children and Adults
How to Explain Blockchain to a Child? (Or an Adult)
What Is Blockchain? How Children Should Learn About It the Right Way
Continue learning
Sources and scope
The learning routes and paper model are original educational suggestions, not a guaranteed mastery timetable. The linked eduKateSG articles retain their own examples, references and model boundaries. Library links were checked against the published WordPress directory on 14 October 2026.
NIST IR 8202 — Blockchain Technology Overview, 2018 · Ethereum developer documentation