The six domains of this Level 1 syllabus are not six separate subjects; they are six views of one system. The most useful study method is to trace a single digital-asset transfer from the signature that authorizes it, through hashing and consensus, into a smart contract's state, and out to token classification and compliance questions. Build that trace on paper, then test every domain against it. This article shows how the trace works, where each domain's named concepts plug in, two worked decision scenarios, and a self-check rubric you can adapt to any schedule.
Why isolated domain review leaves gaps in DLT fundamentals
Treat the syllabus as layers of one transaction. Hashing secures records, consensus orders them, contracts mutate state, tokens define what moves, and security plus compliance govern the whole path between them.
The genuine difficulty of a distributed-ledger syllabus is integration, not vocabulary size. Each domain uses its own terms, so reviewing flashcards domain by domain produces recognition without connection. When a practice scenario says a validator signs and broadcasts a block proposal, you need to know which layer every verb belongs to: the wallet produces a signature, the transaction carries its payload, the network relays it, consensus orders and finalizes it, contract storage updates, and an explorer displays the resulting token event. Tracing one transfer end to end forces exactly these connections.
Set up a blank one-page diagram with six columns, one per domain. For each domain, write the named concept that acts at that moment — a hash pointer, a block proposal, a function call, a transfer event, an attack surface, a compliance check. Compare your map against your notes; every gap becomes a revision item. Then repeat the map for three different transaction types: a simple asset transfer, a contract deployment, and a collectible mint. The expected observation is that the first layers stay constant while later layers change, and that stability is precisely what the trace is designed to teach.
Cryptographic foundations: hash commitments versus signatures
Hashing produces a deterministic fixed-size fingerprint used for integrity and linkage; signatures prove authorship with a private key. Practice scenarios hinge on choosing the correct primitive, not reciting numeric parameters.
Learn the named properties as decision tools. Preimage resistance means a fingerprint cannot be reversed into its input; collision resistance means two different inputs should not share one output; determinism means the same input always yields the same output, which is what makes verification possible. Keep three primitives distinct in your notes: hashing (integrity, no key), symmetric encryption (confidentiality, shared key), and digital signatures (authorship and integrity, key pair). A signature is computed over a hash of the message, not over the message itself in most schemes, and encryption is not signing.
Worked scenario 1: an archive service wants to prove a document stored last year has not been altered, without revealing the document until a later dispute. A plausible mistake is to encrypt the document with the provider's key, reasoning that confidentiality implies integrity — but encryption hides content while still allowing whoever holds the key to swap ciphertexts. A second mistake is to have the provider sign the document, which proves nothing about timing since the provider could sign anything at any moment. The better decision is a hash commitment: store the digest, reveal the document later, and re-hash to verify. This matters because it demonstrates that hashing gives integrity without secrecy, and that where trust is placed determines which primitive fits.
Consensus mechanisms and ledger architectures: match the setting
Consensus answers who may propose blocks and how the network agrees; architecture answers who may participate. Compare mechanism families by trust assumptions and settings rather than memorizing one network's figures.
Define the recurring terms before comparing families. Finality describes when a transaction is considered irreversible, which is probabilistic in some designs and deterministic in others. Fork choice describes how the network picks among competing chains. Permissionless architectures let anyone join as a participant; permissioned architectures restrict participants to an identified set. In simplified terms, proof of work elects block producers through costly computation, proof of stake weights selection by locked collateral with penalties for misbehavior, and BFT-style voting reaches agreement among a small known validator set. Real protocols add considerable detail, so treat these as families, not complete descriptions.
Worked scenario 2: five banks build a shared settlement ledger and must choose an architecture. A plausible mistake is assuming a public proof-of-work network is required for security, which would expose transaction data publicly and tie settlement to an unrelated validator economy. The better decision is a permissioned architecture with a known validator set and BFT-style agreement, because the threat model here is misbehavior by identifiable members, not anonymous hashrate. Real deployments add operational and legal factors, but the transferable lesson is that architecture choice follows the trust model — and in scenario questions, identifying who the participants are usually identifies the right family. Use the table below to rehearse that matching.
| Mechanism family | Trust assumption | Typical setting | Study focus |
|---|---|---|---|
| Proof of work | Open participation; security from economic cost of computation | Permissionless public networks | Fork choice, probabilistic finality, energy trade-offs |
| Proof of stake | Security from locked collateral and penalties | Public and some consortium networks | Validator selection, slashing, finality gadgets |
| BFT-style voting | Small identified validator set with bounded faults | Permissioned consortium ledgers | Deterministic finality, membership governance |
| DAG and alternative structures | Varies by design; check the specific protocol | Specialized networks | Ordering rules, how finality is defined |
Smart contracts: deterministic state machines, not programs with free will
A smart contract is code whose execution every node replicates. Determinism, resource metering, immutable deployed code, and explicit access control define which designs are coherent and which are impossible.
Anchor four named concepts. Determinism means the execution environment forbids anything nodes could disagree about, such as wall-clock randomness or arbitrary network calls. State lives in the contract's storage and changes only through transactions. Deployed bytecode is immutable, so upgradeability comes from patterns like proxies or registries that redirect calls, not from editing code in place. Access control is explicit: owner, minter, or pauser roles decide who may call which function. Each of these four explains a family of scenario answers, so write one example sentence for each in your own words.
Paper exercise: a quiz item describes a contract that fetches the exact live market price from a website and refunds buyers automatically. The plausible mistake is accepting the premise — a replicated virtual machine cannot browse the web, so the described mechanism cannot exist as stated. The better decision is to recognize an oracle pattern: price data arrives via transactions from a feed contract, which moves trust to the oracle operator and its data sources. This matters because it links the execution-environment limits of this domain directly to the trust and security questions of later domains. As a second observation task, sketch a token sale contract and list its storage variables, its events, and its restricted functions; if you cannot separate the three, reread the state-versus-event distinction.
Tokenomics and asset classification: separate mechanics from rights
Classification starts with mechanical facts — fungibility, supply schedule, transfer rules — and only then asks what rights the token grants. Keep the mechanical layer distinct from the legal layer in your notes.
Build a two-axis vocabulary. The mechanical axis covers fungible versus non-fungible tokens, fixed caps versus inflationary or algorithmically adjusted supply, mint and burn functions, and the approval-and-transfer flow that fungible token interfaces use when a third party moves funds on an owner's behalf. The rights axis covers what the token does: payment, in-protocol utility such as fee discounts, governance votes, or representation of a unique collectible. Wrappers and pegged representations deserve their own note, since a wrapped asset's value claim depends on the wrapper's custody design, not on the underlying asset alone.
Decision scenario: a paper case describes a token with a fixed supply used both to vote on protocol parameters and to receive fee discounts. A plausible mistake is filing it as purely a payment token because one of its uses resembles payment. The better decision is to enumerate every function — governance right, utility discount, engineered scarcity — and mark the classification as potentially jurisdiction-dependent, since the same functional profile can be treated differently across borders. Record jurisdiction-dependent rather than asserting one country's legal test. This matters because classification is a multi-axis decision, and your compliance notes should point back to this ambiguity instead of papering over it.
Network security: name the layer each attack hits
Distinguish attacks on consensus power, attacks on network topology, attacks on keys, and attacks on contract code. Naming the layer prevents generic answers and points to the right mitigation family.
Sort the standard attacks into layers. A majority or 51 percent attack targets consensus power itself: an entity controlling most of the resource behind block production can attempt reorganizations, which is a double-spend risk especially where finality is probabilistic. A sybil attack floods an open network with fake identities, and its structural answer comes from the consensus design — weighting by computation or stake — not from encryption. An eclipse attack isolates one node from honest peers so it sees a false view. Separately, key compromise and contract bugs are failures of key management and code, not of the consensus protocol, and they need entirely different fixes.
Exercise: draw three columns — attack, layer hit, primary mitigation family — and fill them from memory for majority, sybil, eclipse, key theft, and reentrancy-style contract flaws, then check against your notes. Expected observations: sybil resistance originates in consensus weighting, a valid signature does nothing against a consensus-level attack, and a contract bug and a protocol bug can share symptoms while requiring fixes at different layers. If any attack lands in the wrong column, return to the consensus notes from the earlier section rather than restudying security in isolation — the columns are a direct test of your layer map.
Compliance vocabulary and your readiness rubric
Regulatory treatment of digital assets is jurisdiction-specific and evolving. Learn the shared vocabulary, label every rule with its jurisdiction, and use a rubric to decide when you are ready for timed practice.
Study the terms that recur across frameworks rather than one country's rulebook. Anti-money-laundering and know-your-customer obligations typically attach to service providers; information-sharing expectations between institutions appear in travel-rule-style provisions; licensing categories cover exchanges and custodians; sanctions screening applies to addresses and counterparties. The transferable principle is that identical technology can receive different treatment in different places. So when a scenario does not state a jurisdiction, note that the conclusion is conditional instead of importing your home country's thresholds or tests — matching each claim to its stated assumptions is itself an exam skill.
Readiness checks before moving to timed practice: rebuild the six-column layer map from memory; re-explain both worked scenarios in two sentences each; then score every domain from 1 to 3, where 1 means term recognition only, 2 means you can define a concept and give an example, and 3 means you can apply it to a new scenario. Reaching 2 or better across all six domains is a sensible learning milestone — it measures your study progress, not a predicted exam result. An adaptable sequence: week one, the layer map plus cryptography and consensus; week two, contracts and tokens; week three, security and compliance with all scenarios redone cold; then attempt practice questions under timing and route every miss back to the map.