This guide teaches the six Level 2 subject areas through a cross-layer tracing approach: pick one concrete system, follow it through consensus, contract, market, governance, and compliance layers, and force yourself to state the trade-off coupling at each boundary. Two worked scenarios show plausible mistakes and better decisions, a comparison table organizes consensus options, and a self-check rubric converts vague familiarity into measurable readiness milestones.
Why every scalability claim must be paired with a finality claim
Treat finality type, throughput mechanism, and trust assumptions as three separate axes. A design can gain throughput while changing when a transaction becomes irreversible, so never quote a scalability property without naming the finality property that accompanies it.
Start by fixing vocabulary. Probabilistic finality means a transaction becomes progressively harder to reverse as more blocks build on it, as in longest-chain proof-of-work designs; deterministic finality means a protocol step explicitly confirms the block, as in BFT-style proof-of-stake. Layer 2 rollups move execution off a base layer and post commitments back to it, inheriting the base layer's settlement guarantees while adding their own exit and fraud-proof or validity-proof window. Sharding splits state or work to parallelize, and DAG-style ledgers reorder what 'one ordering' even means. Each lever buys throughput by adding a waiting period, a proof obligation, or a coordination assumption. Practice naming which one for each design you study.
Worked scenario: a payments team accepts a large-value transfer after a single confirmation on a probabilistic-finality chain, reasoning that 'the block is mined, so it is done.' The plausible mistake is treating one confirmation as settlement. The better decision is to define a confirmation depth appropriate to the transferred value, or to route settlement through a deterministic-finality layer when irreversibility is a business requirement. Why it matters: reversal risk is not a code bug, it is a property of the consensus design, so it must be handled in process design, not patched after the fact.
Use the table below to organize your comparisons. For any chain or rollup you study, fill in all four columns from primary documentation. If you cannot fill a column, that gap, not memorized throughput numbers, is what to study next.
| Design family | Finality type | Scalability lever | Principal trade-off |
|---|---|---|---|
| Nakamoto-style proof-of-work | Probabilistic (depth-based) | Block size and interval tuning | Reorganization risk decreases with depth but never reaches zero |
| BFT-style proof-of-stake | Deterministic once finalized | Validator committee size and aggregation | Depends on honest-committee assumptions and key management |
| Rollups on a base layer | Inherits base layer after proof/exit window | Off-chain execution, compressed data posting | Withdrawal delay and proof-system assumptions |
| DAG / block-lattice ledgers | Per-transaction or asynchronous | Parallel transaction confirmation | Ordering and conflict-resolution rules replace a single global block |
Ranking audit findings by exploit path, not by fame of the pattern
Severity is a function of the exploit path, the impact, and the preconditions, not of how recognizable the vulnerability class is. A famous pattern behind a guard is less urgent than a dull-looking function that any authorized key can abuse.
Separate two families of findings. Code-level vulnerabilities, such as reentrancy, unchecked external calls, or precision and rounding errors, live in specific lines and have specific triggers. Design and economic flaws, such as oracle manipulation, governance capture, or liquidation cascades, can exist in code that is locally correct. Practice writing each finding as a sentence with four parts: the attacker's starting position, the sequence of calls or market actions, the resulting loss, and the preconditions. If you cannot state the starting position, you have found a pattern match, not a finding. This discipline also tells you when two findings are really one root cause.
Worked scenario: an audit report flags reentrancy in a token swap function, but you verify the function follows checks-effects-interactions and carries a reentrancy guard, so the exposure is a low-severity defense-in-depth note. Meanwhile, an unremarkable admin function lets a single upgrade key redirect the fee splitter to any address with no timelock. The plausible mistake is spending review effort on the famous pattern and noting the admin function as 'by design.' The better decision is to rank the admin path higher: fewer preconditions, larger impact, no mitigation between key compromise and loss. Why it matters: severity ranking determines what gets fixed first, and pattern fame is a poor proxy for path feasibility.
A useful paper drill: take any public audit summary and, before reading the severity labels, write your own ranking with justifications. Compare. Disagreements almost always reveal whether you are weighing preconditions and impact or merely matching names.
Decomposing an APY into fee yield, emissions, and leverage before trusting it
Decompose every quoted yield into its sources: trading fees, token emissions, and any recursive staking that multiplies exposure. Each source carries different sustainability and risk, and a single blended APY number hides exactly the distinctions this subject tests.
Work the mechanics with small numbers on paper. In a constant-product pool with reserves x and y and product k, a trade moves reserves along the curve, and the pool's post-trade value versus simply holding the two assets defines divergence loss, commonly called impermanent loss; it is a real accounting difference, not a fee. Fees offset it per unit of volume relative to pool size. Emissions-based rewards are a separate stream: they are paid in a token whose own supply schedule determines sell pressure. Recursive strategies, where rewards are restaked into the same position, raise effective yield and raise liquidation and depegging exposure at the same time. Practice rebuilding a quoted APY from these parts for one pool you can observe.
Worked scenario: a pool advertises roughly 200% APY, driven mostly by emissions at a rate you observed for one week. The plausible mistake is annualizing that weekly rate, compounding it, and treating the figure as a return expectation. The better decision is to trace the emission schedule, note whether it decays or is capped, estimate the reward token's sell pressure given the schedule, and restate expected return as fees plus a declining emissions stream, with an explicit exit plan for the reward token. Why it matters: the mistake converts a front-loaded, decaying incentive into a phantom steady-state return, and every downstream decision about position sizing inherits that error.
Extend the decomposition across layers: an emissions-heavy pool is simultaneously a DeFi question and a tokenomics question, because the emission schedule lives in the token's supply design. Noting that coupling is exactly the cross-layer habit this guide is building.
Choosing interoperability designs that match a permissioned network's trust model
Permissioned frameworks differ in membership control, data visibility mechanisms, and consensus style. Interoperability is not one technique: notary schemes, relay or IBC-style protocols, and hash-time-locked swaps each assume a different trust boundary, so the choice follows from who is trusted.
Anchor the enterprise layer in its own vocabulary. Permissioned networks typically gate membership through a certificate or identity service, restrict data visibility through channel or private-data-style constructs so only entitled parties see certain writes, and often use voting or authority-based consensus rather than open staking. Interoperability options then differ structurally: a shared notary or a committee of the participating organizations attests to cross-network events; a relay or light-client style protocol lets one chain verify another's state proofs with reduced trusted parties; hash-time-locked constructions enable atomic exchange without either side trusting the other, at the cost of lock-up windows and refund paths. For each option, write down the failure assumption: what entity, if malicious or offline, breaks the guarantee.
Worked scenario: two consortium members want to settle obligations and also access public-chain liquidity. The plausible mistake is bridging the consortium's transaction data to a public mainnet through a token bridge for convenience, exposing commercially sensitive visibility data to a trust boundary the consortium does not control, and mismatching the deterministic finality of the private network with the probabilistic finality of the public one. The better decision is to settle obligations inside the consortium through its existing notary or voting arrangement and, only where public liquidity is genuinely required, anchor commitments rather than raw data, handling finality mismatch with explicit confirmation rules. Why it matters: the interoperability choice silently rewrites the network's privacy and settlement guarantees, and those guarantees were the reason the consortium exists.
Tracing token supply schedules and distinguishing governance power from governance rights
Trace supply end to end: emissions, vesting, treasury releases, and burn sinks, then map who can actually execute decisions. High staking yield funded by emissions is dilution redistributed, not demand, and signaling rights are not execution rights.
Build the two ledgers separately. On the supply side, sketch the emission curve, unlock or vesting calendar for allocations, any fee burns, and the treasury's discretionary power; net inflation is what remains after sinks. On the governance side, distinguish on-chain binding proposals, off-chain signaling, delegate or vote-escrow weightings, multisig execution, and any veto or emergency powers held by a core team or council. Vote-escrow designs, which weight voting by lock duration, reward long-term alignment but can concentrate power with large, locked holders, so quorum and capture become design questions, not footnotes. For any project you study, you should be able to draw both ledgers on one page and point to where they interact, such as treasury-funded incentives approved by governance.
Worked scenario: a token advertises a staking APY well above comparable networks, and a reviewer concludes demand for the token is exceptional. The plausible mistake is reading the staking yield as evidence of fee-based demand without checking its funding source. The better decision is to trace the reward source: if staking rewards are minted as new supply, the yield to stakers is offset by dilution to non-stakers, and the sustainable comparison is fee revenue net of emissions. Why it matters: the same headline number describes opposite economics depending on funding, and position or governance decisions built on the wrong reading inherit the error.
Link this section backward to Section 3: an emission schedule simultaneously sets DeFi incentive levels and tokenomics dilution. When you trace one system, use the same emission numbers in both sections and check your conclusions are consistent across them.
Matching privacy technology to the compliance obligation it actually satisfies
Match the tool to the obligation with precision: zero-knowledge proofs prove statements without revealing underlying data, selective disclosure reveals chosen attributes, and encryption secures storage or transport but satisfies no disclosure rule by itself.
Separate three properties that are frequently merged in conversation. Confidentiality means unauthorized parties cannot read data. Auditability means an entitled party, such as an auditor or regulator, can verify transactions or view them under controlled conditions, which some designs implement through auditor view keys or scoped disclosure. Data protection obligations add a further layer: minimizing what is recorded, honoring rights over personal data, and controlling retention. A design can be confidential yet unauditable, auditable yet over-collecting, or encrypted at rest while still exposing more personal data on-chain than the purpose requires. Practice classifying any privacy feature you read about into which of these properties it changes, and which it leaves untouched.
Worked scenario: an enterprise wants to record customer-related events on a public chain and proposes hashing personal fields to make the record 'data-minimized.' The plausible mistake is assuming hashing removes the personal character of the data, when hashed values can still relate to identifiable individuals where re-identification is feasible, for example by hashing a known identifier and comparing. The better decision is to keep the chain as an integrity layer, storing only commitments or digests of records whose personal data lives off-chain in a system that supports deletion and access control, so the on-chain artifact verifies without carrying the data. Why it matters: this keeps the tamper-evidence benefit of the ledger while leaving data-protection rights operable on the underlying records, which a hash-everything design can compromise.
Hedge appropriately when you study this area: obligations differ by jurisdiction and by data type, and this guide does not replace legal advice. The transferable skill is the mapping discipline, not a memorized verdict about any specific regulation.
A ten-day tracing sequence and a rubric that scores readiness
Prepare by tracing one real system through all six topic layers across ten days, then run timed paper drills. Readiness means you can define and contrast, compute a worked example, and defend a trade-off decision in each layer, scored against the rubric below.
Adaptable sequence, adjust the pacing to your calendar. Days 1-2: pick one public network and one permissioned framework; fill in the consensus table from Section 1 for both from primary documentation. Days 3-4: read one audit summary for a contract in that system and write your own severity ranking before reading the labels. Day 5: trace one pool in that system, decomposing its APY into fees, emissions, and leverage as in Section 3. Day 6: draw the token's supply and governance ledgers from Section 5 and confirm your DeFi conclusions remain consistent. Day 7: map the interoperability options in Section 4 against the trust boundaries you identified. Day 8: classify the privacy and compliance properties in play using Section 6. Days 9-10: timed drills, then the rubric. Practice questions from /free-practice/level-2 slot into days 9 and 10 as retrieval checks, and the broader guides at /study-guides can supply alternate systems to trace.
Score each of the six topics from 0 to 3: 0, you recognize the term only; 1, you can define it and name one contrast; 2, you can complete a small worked example or trace, such as a divergence-loss calculation or a severity ranking with justification; 3, you can defend a trade-off decision across two layers, for example explaining how an emission schedule changes both a yield conclusion and a dilution conclusion. Reaching 2 everywhere before attempting 3s is a sensible milestone ordering. Treat these scores as learning milestones for your own tracking, not as a prediction of any exam result. If a layer stalls at 1, return to that section's drill rather than rereading summaries; the drills, not the reading, move the score.
- Readiness check 1: you can fill every column of the consensus table for two different designs without notes.
- Readiness check 2: you can write a four-part finding statement (starting position, sequence, impact, preconditions) for any vulnerability you name.
- Readiness check 3: you can decompose an observed pool's yield into fee, emission, and leverage components with stated assumptions.
- Readiness check 4: you can name the trusted entity that breaks each interoperability option you propose.
- Readiness check 5: your supply ledger and governance ledger for one token fit on one page and mark at least one interaction point.