Treat every CDAA topic as a two-layer problem. Architecture tells you what the ledger guarantees; tokenomics, DeFi, custody, microstructure, and compliance all inherit those guarantees. Build analysis habits that state the layer explicitly, because a claim valid on one layer often fails silently on the other.
Why Ledger Architecture Constrains Every Other Analysis You Write
Architecture determines data availability, finality, and execution costs. Valuation, custody, and compliance conclusions are only as strong as the ledger properties underneath them, so study consensus, scaling, and fee models before any asset-level claim.
Compare consensus families by the guarantee they sell, not by marketing labels. Probabilistic finality under proof-of-work means a reorganization can reverse a recent settlement, so an analyst's assumption of settled balances needs a confirmation-depth caveat. Deterministic finality under BFT-style proof-of-stake settles a block irreversibly once quorum is reached, which changes how you reason about settlement risk and bridge design.
Trace one concrete example end to end: a user payment on a rollup that settles to a base layer. Note where execution happens, where data availability lives, what the gas unit measures on each layer, and what happens if the sequencer fails. When you later value the rollup's token or assess custody of assets on it, these traced details become the assumptions your model must state rather than invent.
- Finality type: probabilistic versus deterministic, and what each implies for settlement assumptions
- Execution layer: base layer, rollup, or app-chain, and who can reorder or censor transactions
- Fee market: what the gas unit pays for on each layer and how congestion propagates between layers
Valuing a Token Without Treating It Like an Equity Share
Tokens are not equity shares: supply schedules, lockups, burn mechanics, and velocity change the relationship between protocol activity and asset value. Use valuation lenses matched to token rights instead of importing one model wholesale.
Scenario 1: a paper exercise. A protocol generates fee revenue, burns part of every fee, and has 60 percent of supply locked in staking contracts. A first attempt applies a plain discounted cash flow to the full supply as if it were share count. The mistake: treating all protocol revenue as distributable cash flow and ignoring that locked supply removes float from circulation, so per-token demand pressure is modeled against the wrong denominator.
The better decision in this scenario is a two-step approach. First, value the protocol's activity using an equation-of-exchange style lens, where token value depends on transaction volume divided by circulating supply times velocity. Second, run a float scenario in which locked tokens unlock over your forecast horizon and velocity rises as the token circulates faster. Why it matters: the two steps produce opposite valuation directions, and stating both shows exactly which assumptions drive your conclusion.
| Valuation lens | What it measures | Key inputs | Blind spot to check |
|---|---|---|---|
| Equation-of-exchange / velocity model | Implied token value from transaction volume against effective float | On-chain volume, circulating supply, assumed velocity | Volume can be inflated by self-transfers; velocity is an assumption, not an observation |
| Fee-cash-flow lens | Value of rights to protocol revenue, where the token grants them | Fee revenue, share of fees accruing to token, burn rate | Requires the token to actually have revenue rights; many do not |
| Staking-yield lens | Return to securing the network, net of issuance | Issuance schedule, staked share, fee share, unlock schedule | High nominal yield can coincide with dilution that exceeds it |
| Relative network lens | Comparative value per active user or fees against peers | Active addresses, fees, comparable protocols | Comparables may differ in architecture, making ratios non-equivalent |
Reading AMM and Lending Mechanics Before You Compare Yields
DeFi yields come from different mechanisms with different risk shapes. Automated market makers expose position value to price ratios; lending exposes collateral to liquidation. Compare mechanisms, not headline annualized rates.
Scenario 2: a paper exercise. Two positions advertise similar yields: providing two tokens to a constant-product AMM pool, or supplying one volatile token as collateral to borrow a stablecoin. A first attempt ranks them by headline APY alone. The mistake: the APY figure ignores impermanent loss, the divergence between the pool's value and simply holding both tokens when their price ratio moves, and the lending figure ignores liquidation risk if collateral value falls toward the borrow threshold.
The better decision is to model one price scenario under each mechanism. For the pool, compute the pool value if one token doubles, and compare it against the hold portfolio to quantify impermanent loss, then ask whether fee income over your horizon plausibly covers it. For the loan, compute the collateralization ratio at entry and at the price drop, and identify the liquidation threshold. Why it matters: the same market move produces a slow, mechanical drag in one position and a discrete, threshold-triggered loss in the other, so they are not comparable as single numbers.
- AMM trade-off: fee income versus impermanent loss as a function of price-ratio divergence
- Lending trade-off: borrow capacity versus liquidation distance as a function of collateralization
- Oracle dependency: both mechanisms inherit the price feed's update rules, a second layer worth naming explicitly
Custody Models: What Multisig, MPC, and Smart-Contract Wallets Actually Promise
Custody is about who can authorize a transaction and what can go wrong with that authority. Map each model by signing mechanism, key share handling, and failure modes rather than by hot versus cold labels alone.
Compare the three common institutional patterns on paper. A threshold multisig uses separate full keys held by distinct parties, and the chain itself enforces the signature count; its failure modes include losing enough keys to fall below threshold and inflexible signer sets. A multi-party computation wallet splits a key into shares that never reassemble the full key, moving threshold logic off-chain; this eases operational flexibility but adds dependency on the MPC protocol and its implementation. A smart-contract wallet encodes authorization logic, including recovery and spending limits, in an on-chain contract, which adds the contract itself as an attack surface.
For each model, write the two questions an analyst must answer before assessing custody risk in a report: first, what set of parties must collude or fail for funds to move or become immovable; second, which layer enforces the policy, the chain, the cryptography, or the contract. Then connect custody back to the architecture layer: if the asset lives on a rollup, withdrawal and sequencer assumptions become part of the custody answer.
Microstructure Signals You Can Extract From Order Books and On-Chain Data
Microstructure analysis links market design to observed prices. Practice reading depth, spread, and slippage on paper, and treat on-chain metrics as supply and behavior data that must be cleaned before it supports a valuation input.
Work a slippage example by hand. Using a constant-product pool with reserves X and Y, a trader selling an amount of token X receives Y times the ratio change; compute the executed price and compare it to the pre-trade mid price, and note that slippage grows with trade size relative to pool depth. Then compare with a limit order book, where depth is visible but can be canceled instantly. The lesson is that depth in an AMM is committed liquidity while book depth is intent, and the two support different liquidity-risk conclusions.
For on-chain quantitative work, practice cleaning rather than collecting. Exchange-owned wallets, bridge contracts, and internal contract calls can distort raw counts of active addresses or volume. Build a habit of stating a cleaning rule, such as excluding known contract addresses from address counts, before computing any metric, and record how sensitive each metric is to that rule. This keeps microstructure findings honest inputs to the valuation lenses from the earlier section.
Classifying a Token for Compliance Purposes Without Overclaiming
Compliance analysis asks what rights a token confers and how it was offered, against the rules of a specific jurisdiction. Practice the reasoning pattern on paper; never import one jurisdiction's tests or thresholds into another.
Scenario 3: a paper exercise. A token grants holders a share of protocol fees, was sold in a fundraising round with marketing materials emphasizing expected returns, and now trades on secondary venues. The reasoning pattern to practice: enumerate the rights written into the token's code and documentation, separate them from expectations created in marketing, and identify which facts a given jurisdiction's analysis would weigh. The plausible mistake here is concluding classification from the technology alone, for example assuming a token used for gas payments can never carry investment-character facts.
The better decision in the scenario is a structured memo: list the economic rights, the distribution history, and the communication record, then state explicitly that the conclusion is jurisdiction-specific and that this exercise teaches the reasoning pattern, not a universal rule. Why it matters: compliance conclusions travel badly across borders, and an analyst who writes a conditional, fact-specific memo demonstrates far more skill than one who asserts a global category.
A Seven-Week Sequence With Readiness Checks You Can Score
Sequence the subject so architecture precedes everything and integration comes last. Each week ends with an observable output, and readiness is judged by whether your written artifacts meet the rubric below, not by any predicted score.
Suggested adaptable sequence: week one, architecture, producing the traced rollup payment example; week two, tokenomics, producing a float and unlock schedule for one real asset; week three, valuation lenses, producing the two-step model from Scenario 1; week four, DeFi mechanics, producing the impermanent loss and liquidation computations from Scenario 2; week five, custody and cryptography, producing the two-question map per custody model; week six, microstructure, producing one cleaned on-chain metric with a stated cleaning rule; week seven, integration, writing a one-page analysis of your chosen asset that crosses all layers and states compliance conclusions conditionally.
Practical exercise with a self-check rubric: pick one live token and, without any live trading, build a two-layer notebook. Layer one records consensus type, finality, fee model, and scaling path with sources; layer two records supply schedule, float, revenue rights, and one valuation-lens calculation. Score each layer from 0 to 3: 0 means claims asserted without stated assumptions; 1 means assumptions stated but unsupported; 2 means assumptions traced to identifiable on-chain or documentation facts; 3 means the artifact also states what observation would change the conclusion. A combined 4 or higher on a six-point scale is a reasonable learning milestone; treat it as a study signal, not a prediction of any exam outcome.
- Readiness check one: you can trace one transaction across execution and settlement layers without inventing guarantees
- Readiness check two: your valuation write-up names its lens, inputs, and the blind spot from the table above
- Readiness check three: your DeFi comparisons never rank mechanisms by a single headline rate
- Readiness check four: every custody and compliance claim is written as conditional on jurisdiction and architecture