Exam Practice Questions

The Byzantine Generals Problem in a permissionless digital setting: how to achieve consensus among untrusted parties without a central coordinator. Satoshi solved it using Proof-of-Work as a Sybil-resistance mechanism combined with longest-chain selection, making it economically irrational to attack the network.

DeFi provides:

• Complete transaction transparency (every trade visible)
• Real economic stakes (not simulated)
• Rapid iteration (experiments deploy in days vs. years in TradFi)
• Pseudonymous natural experiments

This enables unprecedented empirical testing of market microstructure theories, mechanism design, and behavioral economics in ways traditional finance cannot.

The avalanche effect means a single-bit change in input produces ~50% change in output bits. In blockchain:

• Prevents predicting hash outputs
• Makes mining truly random (cannot "aim" for target)
• Ensures tamper-evidence (any change completely alters hash)

Trust is redistributed, not eliminated:

• Mathematical assumptions: ECDLP hardness (unproven)
• Implementation correctness: Code bugs can break crypto
• Hardware integrity: Random number generators, secure enclaves
• Protocol design: Even correct primitives can be misused

Cryptography transforms trust from "trust this institution" to "trust these mathematical assumptions and implementations."

Byzantine Fault Tolerance (BFT) requires \(n \geq 3f+1\) because:

• With \(f\) faulty nodes, we need \(2f+1\) honest nodes to form a majority even when \(f\) are silent
• Total: \(f\) (faulty) + \(2f+1\) (honest) = \(3f+1\)
• This ensures that even if \(f\) nodes lie and \(f\) don't respond, honest majority remains

Problems PoS solved:

• Energy consumption (~99.9% reduction)
• Hardware arms race eliminated
• Faster finality possible

New problems created:

• "Nothing at stake" - validators can vote on multiple forks costlessly
• Long-range attacks on checkpoint integrity
• Wealth concentration concerns (rich get richer)
• Complexity in slashing conditions

Evolution driven by environmental criticism and scalability needs, but trade-offs in security model complexity.

UTXO (Bitcoin):

• Better privacy (new address per transaction)
• Parallel transaction processing
• Simpler to verify (stateless)
• No "balance" - only unspent outputs

Account (Ethereum):

• Easier smart contract programming
• More intuitive (like a bank account)
• Space-efficient for contracts
• Nonce prevents replay attacks

Predecessors' failures:

• DigiCash: Centralized (company went bankrupt)
• b-money/Bit Gold: Never implemented (theoretical only)

Bitcoin's innovations:

• Complete working implementation released
• Economic incentives aligned (mining rewards)
• Timing: 2008 financial crisis created demand
• Pseudonymous founder prevented single point of failure
• Open source community ownership

Bitcoin combined existing ideas (PoW, hash chains, digital signatures) with novel economic incentive design and launched with working code, not just a whitepaper.

Why gas is necessary:

• Prevents infinite loops (halting problem)
• Meters computational resources fairly
• Creates economic cost for spam/DoS attacks
• Compensates validators for execution

Out-of-gas behavior:

• Execution halts immediately
• All state changes revert (atomic failure)
• Gas is NOT refunded (already consumed)
• Transaction marked as failed on-chain

Resource costs differ dramatically:

• ADD: CPU cycle (~nanoseconds, ephemeral)
• SSTORE: Disk write that EVERY full node must store FOREVER

Economic reasoning:

• Storage has perpetual externality (state bloat)
• SSTORE costs 20,000 gas (new slot) vs. ADD costs 3 gas
• ~6,667x difference reflects: storage permanence + network replication + future read costs

Gas prices reflect true social cost of resources, not just immediate computation. Storage is "renting space on every node forever."

Analogy: A bank teller giving you cash before marking your withdrawal in the ledger. If you quickly return to another window, the ledger still shows your old balance, so you can withdraw again.

Checks-Effects-Interactions pattern:

1. Checks: Verify all conditions (require statements)
2. Effects: Update state variables (mark balance as withdrawn)
3. Interactions: External calls LAST (send ETH)

By updating state before external calls, reentering finds the state already changed, preventing double-spend.

Factors favoring reactive evolution:

• Adversarial pressure: Attackers have stronger incentives (direct profit) than researchers (reputation/grants)
• Complexity explosion: Composability creates emergent vulnerabilities impossible to anticipate
• Speed vs. security: "Move fast" culture prioritizes features over exhaustive testing
• Audit limitations: Audits are point-in-time; ecosystem evolves continuously

Pattern: DAO hack (2016) -> reentrancy guards. Flash loan attacks (2020) -> oracle improvements. Bridge exploits (2022) -> multi-sig reforms.

Each major exploit becomes a "teaching moment" that permanently changes best practices. Evolution is Lamarckian (learned traits inherited) rather than Darwinian in this context.

Fixed Supply (e.g., Bitcoin):

• Pro: Scarcity narrative, predictable
• Con: No ongoing miner/validator incentives after emissions end

Inflationary (e.g., Ethereum post-merge issuance):

• Pro: Perpetual security budget, rewards participation
• Con: Dilution of non-stakers

Deflationary (e.g., BNB burns):

• Pro: Decreasing supply can support price
• Con: Can create hoarding behavior, reduce velocity

Trust Lens: Trust was placed in an algorithm, not collateral. When confidence broke, there was nothing backing UST.

Incentives Lens: 20% Anchor yield was unsustainable, attracted hot money that fled at first sign of depeg. Reflexive mechanism: UST redemptions mint LUNA -> LUNA price drops -> more UST redemptions (death spiral).

Evolution Lens: Similar to earlier algorithmic stablecoin failures (Iron Finance, Basis Cash), but Terra scaled to $60B before collapse, magnifying damage.

Market Structure: Large concentrated holders could trigger cascades. Thin liquidity during stress amplified price moves.

Key lesson: Reflexive mechanisms where token A backs token B and vice versa are inherently fragile under stress.

Technical challenge:

• ERC-721 transfer function has no price parameter - the contract doesn't know if a transfer is a sale or gift
• Sales can happen "off-chain" with on-chain transfer appearing as simple transfer

Economic challenge:

• Wrapper contracts can hold NFTs and trade wrapper tokens instead
• OTC trades with separate ETH transfer bypass marketplace royalty enforcement
• Marketplaces competed on "zero royalty" to attract volume

Result: Royalties depend on marketplace cooperation, not protocol enforcement. EIP-2981 is informational only.

Valuation risks:

• No reliable price oracle for unique assets
• Floor price manipulation possible with thin markets
• Traits create discontinuous value functions

Liquidation risks:

• Illiquid markets mean liquidation may realize far below "fair value"
• Cascading liquidations can crash floor prices
• No partial liquidation possible (all-or-nothing)

Market structure risks:

• Wash trading inflates apparent values
• Concentrated ownership enables manipulation
• Royalty circumvention affects collection economics

Narrow range:

• Higher capital efficiency (more fees per $ deposited)
• Higher impermanent loss risk if price moves out of range
• Earns zero fees when out of range
• Requires active management

Wide range:

• Lower capital efficiency (diluted across range)
• More resilient to price movements
• Passive "set and forget" approach
• Always earning some fees

Optimal choice depends on expected volatility, management resources, and risk tolerance. Concentrated liquidity is essentially leverage on LP position.

Key findings:

• DEX traders appear less informed on average
• Prices on CEXs lead DEX prices (information flows CEX -> DEX)
• Arbitrageurs extract value by trading against stale DEX prices

Reasons for selection:

• CEXs offer lower latency (important for informed traders)
• DEXs have higher execution costs for large trades
• Self-custody preference correlates with less sophisticated trading

Implications:

• LPs face adverse selection primarily from arbitrageurs, not informed directional traders
• DEX price discovery is derivative, not primary
• Suggests different optimal market design for DEX vs. CEX

Legitimate uses:

1. Arbitrage: Borrow to exploit price differences across DEXs, repay from profit
2. Collateral swap: Replace collateral type without unwinding position
3. Self-liquidation: Repay debt and recover collateral in one transaction to avoid liquidation penalties

Malicious use:

• Oracle manipulation: Borrow large amount, manipulate spot price on DEX, trigger liquidations or exploit price-dependent logic, repay loan

Aave V3:

• Pool-based with cross-collateral
• E-mode for correlated assets (higher LTV)
• Trade-off: Systemic risk from shared pools vs. capital efficiency

Compound V3 (Comet):

• Single borrowable asset per market (e.g., USDC only)
• Multiple collateral types, but isolated risk
• Trade-off: Simplicity and safety vs. flexibility

Morpho:

• Peer-to-peer matching layer on top of Aave/Compound
• Better rates through direct matching
• Falls back to underlying pool for unmatched positions
• Trade-off: Complexity and matching risk vs. rate improvement

Mechanism:

• Go long spot asset (buy and hold)
• Go short perpetual future (same size)
• Net directional exposure: zero
• Collect funding payments when perp trades at premium

Why lower-risk:

• Delta-neutral: price movements don't affect P&L
• Profit comes from funding rate, not price prediction
• In bull markets, funding is persistently positive (longs pay shorts)

Risks remain:

• Funding can flip negative
• Exchange/counterparty risk
• Liquidation risk on perp leg if margin insufficient

How CFMMs provide oracle-like pricing:

• Marginal price derived from pool reserves (e.g., \(P = y/x\) for constant product)
• Manipulation requires actual capital locked in pool
• Time-weighted average price (TWAP) smooths manipulation attempts

Manipulation resistance:

• Arbitrageurs correct deviations from true price
• Cost to manipulate scales with pool liquidity
• TWAP requires sustained manipulation over time

Limitations:

• Low-liquidity pools easily manipulated
• Flash loan attacks can manipulate within single block (pre-TWAP)
• Multi-block manipulation still possible with sufficient capital
• Only prices assets traded on that specific CFMM

Fiat-backed (USDC, USDT):

• Trust the issuer holds actual reserves
• Trust auditors verify reserves accurately
• Trust banking system won't freeze accounts
• Centralized, can blacklist addresses

Crypto-backed (DAI):

• Trust smart contract code is correct
• Trust governance won't make harmful changes
• Trust oracles provide accurate prices
• Trust liquidation mechanism works under stress

Algorithmic (UST, FRAX):

• Trust algorithm maintains peg under all conditions
• Trust market will always provide arbitrage
• Trust reflexive mechanism doesn't death spiral
• Most trust assumptions; historically most failures

Mechanism design flaws:

• No exogenous collateral - system backed itself (circular)
• Reflexive death spiral: UST redemption -> LUNA mint -> LUNA price drop -> more redemption
• Anchor's 20% yield was subsidized, unsustainable, attracted hot money

Warning signs:

• Anchor reserves depleting rapidly
• Similar mechanisms had failed before (Iron Finance, ESD, Basis Cash)
• Large concentrated holdings could trigger cascade
• No circuit breakers or redemption limits

Academic critique:

• Violates basic monetary theory - currency needs independent backing
• Essentially an undercollateralized system pretending to be algorithmic
• Works only when everyone believes it works (pure confidence game)

Calculation:

LVR \(\propto \sigma^2/8\)

If \(\sigma\) doubles: \(\sigma_{new} = 2\sigma\)

New LVR \(\propto (2\sigma)^2/8 = 4\sigma^2/8 = 4 \times\) original LVR

Answer: LP losses quadruple when volatility doubles.

Implication: LPs are highly sensitive to volatility. During volatile periods, LVR can exceed fee income, making LP positions unprofitable. This is why concentrated liquidity (Uni V3) is especially risky - higher capital efficiency but also higher LVR exposure.

Improvements achieved:

• Reduced gas price wars and network congestion
• Democratized MEV access (validators don't need sophistication)
• Eliminated failed/reverted MEV transactions from chain
• Validators earn MEV without running specialized software

New problems created:

• Builder centralization: Top 2-3 builders process 80%+ of blocks
• Censorship vectors: Centralized builders can (and do) censor transactions
• Relay trust: Relays are trusted intermediaries in a "trustless" system
• MEV legitimization: Extraction is now institutionalized rather than eliminated

Conclusion: MEV-Boost improved symptoms (gas wars) but institutionalized MEV extraction and created new centralization risks. It's a second-best solution while protocol-level solutions (PBS enshrined) are developed.

Withdrawal times:

• Optimistic rollups: 7 days (challenge period)
• ZK rollups: Minutes to hours (proof verification time)

Why the difference:

• Optimistic: Assumes valid unless challenged; need time for fraud proofs
• ZK: Mathematical proof of validity; no need to wait for challenges

User implications:

• Optimistic users must use liquidity bridges for fast exits (pay fees)
• Capital is locked for 7 days (opportunity cost)
• ZK has better UX but higher computational costs
• Bridge solutions (Hop, Across) provide fast exits with fees

Factors driving cost variance:

1. Proof system choice: SNARK vs. STARK vs. PLONK have different proving costs and proof sizes
2. Data availability: Calldata vs. blobs vs. validium (off-chain) dramatically affects L1 costs
3. Batching efficiency: More transactions per batch = lower per-tx cost
4. Compression techniques: State diff compression quality varies
5. Amortization: Fixed proof costs spread over varying batch sizes

Implementation differences:

• zkSync Era, Starknet, Polygon zkEVM all use different proof systems
• Circuit design efficiency affects proving time and cost
• Some optimize for prover cost, others for verifier cost

Economic factors:

• Network utilization affects batch fill rate
• Sequencer profit margins vary
• Competitive dynamics (some subsidize costs for adoption)

How quadratic voting works:

• Cost of N votes = N^2 tokens
• 1 vote = 1 token, 2 votes = 4 tokens, 3 votes = 9 tokens
• Makes marginal vote increasingly expensive for whales
• Gives more voice to smaller holders with strong preferences

Limitations in practice:

• Sybil attacks: Whales split holdings across wallets to bypass quadratic cost
• Identity problem: Need reliable identity to prevent splitting
• Collusion: Vote buying still possible
• Complexity: Harder for average user to understand

Quadratic voting assumes one-person-one-identity, which blockchains can't enforce without identity solutions.

Evidence of centralization:

• Token concentration: Top 10 holders often control 50%+ of voting power
• Participation rates: Typically <5% of tokens vote
• Delegate power: Few delegates control most voting power
• Team influence: Founding teams often retain significant control

Evidence of decentralization:

• Anyone can propose (permissionless)
• On-chain execution (no single entity can stop)
• Transparent decision-making
• Exit rights (fork or sell tokens)

Balanced view:

DAOs are "decentralization spectrum" not binary. Most are decentralized in mechanism (code) but centralized in practice (participation). This may be rational - most token holders are passive investors, not governance participants. True decentralization requires active, informed participation that is costly to provide.

Layer 1 - Physical Asset:

• The actual asset (real estate, gold, receivables)
• Trust: Asset exists and has claimed value

Layer 2 - Legal Wrapper:

• SPV, trust, or legal entity that holds asset
• Trust: Legal structure enforceable in relevant jurisdiction

Layer 3 - Token Issuance:

• Smart contract representing ownership claims
• Trust: Token accurately represents legal claims

Layer 4 - Secondary Market:

• DEX/CEX trading of tokens
• Trust: Liquidity exists, oracle prices accurate

Key insight: Each layer adds trust assumptions. On-chain is only Layer 3-4; Layers 1-2 remain off-chain and require traditional trust.

Bullish factors:

• TradFi institutions entering (BlackRock, Franklin Templeton)
• Regulatory clarity emerging (MiCA, SEC guidance)
• Proven use case in stablecoins ($150B+ already)
• Infrastructure maturing (Chainlink CCIP, institutional custody)

Major barriers:

• Legal fragmentation: Every jurisdiction different (HARD)
• Oracle problem: Off-chain assets need trusted price feeds (MEDIUM)
• Liquidity fragmentation: Assets across many chains (SURMOUNTABLE)
• Regulatory uncertainty: Securities law unclear (MEDIUM)
• Smart contract risk: Institutional risk tolerance low (SURMOUNTABLE)

Assessment: $16T likely aggressive. More realistic: $1-3T by 2030, concentrated in:

• Tokenized treasuries (already $1B+)
• Private credit
• Real estate (fractional)

Legal/regulatory barriers are hardest - technology is ready, institutions are not.

Address clustering techniques:

Blockchain analytics firms group multiple Bitcoin addresses that likely belong to the same entity using several heuristics:

1. Common-input heuristic (co-spending):

• When a transaction spends from multiple input addresses, they likely belong to the same wallet/entity
• Rationale: Only someone controlling all inputs can create the transaction
• Exception: CoinJoin transactions deliberately violate this assumption

2. Change address detection:

• Identify which output is payment vs. change returning to sender
• Signals: Round payment amounts, address reuse patterns, UTXO age
• Links sender's input addresses to their change address

3. Timing analysis:

• Addresses active in similar time windows likely controlled together
• Transaction creation patterns reveal wallet software and behavior

4. External data fusion:

• Link clusters to real-world identities via KYC exchanges, IP addresses, forum posts
• Once one address in a cluster is identified, the whole cluster is tagged

Effectiveness: Studies show ~50% of Bitcoin transactions can be de-anonymized using these techniques. Privacy tools like CoinJoin, PayJoin, and careful UTXO management can defeat clustering heuristics.

Key DeFi lending protocol health metrics:

1. Utilization Rate:

• Formula: Total Borrowed / Total Supplied
• Healthy range: 70-85% (protocol-dependent)
• Too low (<50%): Capital inefficiency, low lender yields
• Too high (>95%): Liquidity crunch, withdrawal panic risk
• Why it matters: Indicates whether supply/demand is balanced and if withdrawals can be serviced

2. Liquidation Ratio / Health Factor Distribution:

• Metric: Percentage of positions near liquidation threshold
• Calculation: (Collateral Value × Liquidation Threshold) / Debt Value
• Warning signs: Large concentration of positions at 1.0-1.1 health factor
• Risk: Market volatility can trigger liquidation cascade
• Example: If 30% of positions have health factor <1.2, sharp price drop could cause mass liquidations and protocol insolvency

3. Bad Debt Accumulation:

• Definition: Debt positions where Collateral Value < Debt Value (underwater)
• Causes: Failed liquidations (oracle lag, gas wars, extreme volatility)
• Healthy: <0.1% of TVL
• Concerning: >1% of TVL
• Impact: Erodes lender value, may require governance intervention or insurance fund
• Case study: Aave V2 accumulated ~$1.6M bad debt during March 2020 crash

Bonus metrics:

• TVL (Total Value Locked): Overall protocol size and market confidence
• Collateral diversity: Concentration risk (e.g., 80% in one asset is risky)
• Whale concentration: Top 10 depositors' share of TVL
• Interest rate model stability: Excessive rate volatility indicates instability

Monitoring approach: Effective risk management requires real-time tracking of all three metrics plus stress-testing against historical volatility scenarios.

Expected loss without audit:

= 3% x 40% x $50M = 0.03 x 0.4 x $50M = $600,000

Expected loss with audit:

= 0.3% x 40% x $50M = 0.003 x 0.4 x $50M = $60,000

Risk reduction:

= $600,000 - $60,000 = $540,000

ROI:

= (Risk Reduction - Audit Cost) / Audit Cost

= ($540,000 - $100,000) / $100,000 = 440%

Conclusion: The audit has a 440% ROI, strongly justifying the investment.

Definition: Mathematical proof that code satisfies a specification.

Three main techniques:

1. Model checking: Exhaustively explore all possible states
2. Theorem proving: Mathematical proofs about code properties
3. Symbolic execution: Execute with symbolic (not concrete) values

Why not a silver bullet:

• Specification problem: Verifies code matches spec, but spec might be wrong
• Scope limitations: Can't verify external interactions, oracle behavior
• State explosion: Complex contracts have too many states
• Composability gap: Verified contracts may fail when composed
• Economic attacks: Can't verify economic incentive alignment
• Cost: Extremely expensive for full verification

Formal verification reduces but doesn't eliminate risk. It's one tool in a defense-in-depth approach.

The vulnerability:

Euler allowed users to "donate" collateral to reserves without proper accounting checks.

The exploit:

1. Attacker takes flash loan
2. Deposits to Euler, gets eTokens (receipt tokens)
3. Uses eTokens as collateral to borrow
4. "Donates" the eTokens to reserves (reduces own collateral)
5. Now technically underwater, but donation created bad debt
6. Liquidate self, extract value from bad debt
7. Repay flash loan, keep profit

Root cause: The donate function didn't check if it would make the account insolvent. The attacker could artificially create bad debt and extract value through liquidation mechanics.

Loss: ~$197M (later largely recovered through negotiations).

The antibody pattern:

1. Failure: Novel exploit discovered (pathogen enters)
2. Response: Post-mortem, community learning (immune response)
3. Hardening: New standards, tools, practices (antibodies formed)
4. Memory: Knowledge persists in auditor checklists, linters (immune memory)

Examples:

• DAO hack (2016): -> Reentrancy guards, CEI pattern, OpenZeppelin ReentrancyGuard
• Flash loan attacks (2020): -> TWAP oracles, Chainlink adoption, delayed price updates
• Bridge exploits (2022): -> Multi-sig reforms, proof verification, bridge security frameworks
• Access control failures: -> Role-based access patterns, initialization checks

Ecosystem-level effects:

• Audit firms specialize in specific attack vectors
• Formal verification tools target known vulnerability classes
• Insurance products price risk based on historical patterns

DeFi evolves through adversarial learning - each failure makes the ecosystem more robust to that specific attack class, but new attack vectors continue to emerge.

The relationship:

• FTX = exchange holding customer deposits
• Alameda = trading firm owned by same principals
• Supposed to be separate entities

What happened (fraud, not risk management):

1. Customer deposits were transferred to Alameda without consent
2. Used to make risky investments, venture bets, political donations
3. FTX code had hidden "allow negative balance" for Alameda
4. Financial statements falsified to hide the hole
5. When customers tried to withdraw, money wasn't there

Why fraud, not incompetence:

• Deliberate code changes to allow special treatment
• Active concealment from auditors and customers
• Misrepresentation of reserves
• Commingling of funds is textbook embezzlement

Incentive analysis:

• Access: Exchanges custody billions with few controls
• Information asymmetry: Users can't verify reserves in real-time
• Short-term gains: "Borrow" deposits for trading = potential profit
• Regulatory gaps: Offshore exchanges face little oversight
• Upside capture: Operator keeps trading profits
• Downside socialization: Losses fall on depositors in bankruptcy

Structural solutions:

1. Proof of Reserves: Cryptographic attestation of assets (partial - doesn't show liabilities)
2. Proof of Solvency: ZK proofs that assets >= liabilities
3. Segregated custody: Legal requirement for separate customer accounts
4. Insurance funds: Pre-funded protection (like FDIC)
5. Self-custody promotion: "Not your keys, not your coins"
6. DEX alternatives: Non-custodial trading eliminates counterparty risk

Fundamental tension: CeFi convenience requires trust; trust creates temptation. Only non-custodial solutions fully eliminate this risk.

The four prongs (ALL must be met):

1. Investment of money: Purchaser gives something of value
2. In a common enterprise: Fortunes tied to others or promoter
3. With expectation of profits: Bought for appreciation, not use
4. Derived from efforts of others: Success depends on promoter/team

Why it matters for crypto:

• Securities require registration, disclosure, investor protections
• Most ICO tokens likely meet Howey (promoted for profit, team-dependent)
• Sufficiently decentralized tokens may escape (no identifiable "others")
• SEC uses Howey to bring enforcement actions

Key debates:

• Is ETH a security? (SEC has not definitively ruled)
• When does decentralization remove prong 4?
• Do utility tokens avoid "expectation of profits"?

What is regulatory arbitrage:

Structuring operations to be subject to the least restrictive jurisdiction while serving global customers.

How crypto exchanges do it:

• Incorporate in permissive jurisdictions (Seychelles, Bahamas, Malta)
• Block US/EU IPs but users bypass with VPNs
• Serve global customers without local licenses
• Move headquarters when regulations tighten

Why it has been possible:

• Internet-native business, no physical presence needed
• Regulatory fragmentation across jurisdictions
• Speed of crypto innovation outpaced regulatory response
• Political will for enforcement was limited

Is it sustainable?

No, for several reasons:

• Major jurisdictions coordinating (FATF, FSB)
• Banking access requires compliance (fiat on/off ramps)
• Institutional investors require regulated venues
• Enforcement actions increasing (Binance settlement)

Trend is toward "comply everywhere or serve no one" - regulatory arbitrage window is closing.

Conceptual model:

ZK-SNARK = "I know a secret that satisfies these rules, and here's proof, but I won't reveal the secret."

Key components:

• Proving key: Used to generate proofs (prover has this)
• Verification key: Used to check proofs (public, anyone can verify)
• Proof: Short cryptographic object (~200 bytes) that convinces verifier

Trusted setup controversy:

• Generating keys requires random "toxic waste"
• If anyone saves this randomness, they can create fake proofs
• Must trust that ceremony participants destroyed their shares
• Multi-party ceremonies (1-of-N honest) reduce but don't eliminate trust

Alternatives: STARKs require no trusted setup but have larger proofs.

Legal perspective:

• OFAC sanctioned Tornado Cash smart contract addresses
• First sanction of autonomous code, not entity
• Legal question: Can you sanction software?
• Court challenge: Is immutable code "property" that can be sanctioned?

Technical perspective:

• Smart contracts are immutable - can't be "turned off"
• No entity to comply with sanctions
• Privacy tech is dual-use (legitimate privacy vs. money laundering)
• Front-end censorship doesn't stop direct contract interaction

Philosophical questions:

• Code as speech: Is publishing code protected expression?
• Tool neutrality: Should tool creators be liable for misuse?
• Privacy rights: Is financial privacy a right or privilege?
• Enforcement futility: Can you meaningfully sanction unstoppable code?

Ongoing implications:

• Developer arrest (Pertsev) chills privacy development
• Sets precedent for sanctioning DeFi protocols
• Tension between AML requirements and privacy technology

HTLC = Hash Time-Locked Contract:

• "I'll pay you X if you reveal the preimage of this hash within T time"

Multi-hop example (Alice -> Bob -> Carol):

1. Carol generates secret R, sends hash H(R) to Alice
2. Alice creates HTLC with Bob: "Pay Bob if he reveals preimage of H(R)"
3. Bob creates HTLC with Carol: "Pay Carol if she reveals preimage of H(R)"
4. Carol reveals R to Bob (claims payment)
5. Bob now knows R, reveals to Alice (claims payment)

Atomicity guarantee:

• Same hash H(R) used for all hops
• If Carol doesn't reveal R, all HTLCs expire (no one pays)
• If Carol reveals R, it propagates back (everyone can claim)
• Timelocks decrease along path (Carol's expires first, Alice's last)

Why banks are worried:

• Deposit flight: Risk-free CBDC competes with bank deposits
• Funding costs: Banks must raise rates to retain deposits
• Business model threat: Fractional reserve lending depends on stable deposits
• Relationship loss: Direct central bank accounts bypass banks entirely

Stress scenario: During crisis, depositors flee to "safe" CBDC, causing bank runs faster than ever before (instant digital transfer).

Design mitigations:

1. Holding limits: Cap individual CBDC balances (e.g., EUR 3,000)
2. Tiered remuneration: Zero or negative interest above threshold
3. No interest: Make CBDC unattractive as store of value
4. Intermediated model: Banks distribute/manage CBDC (preserve role)
5. Waterfall design: Excess CBDC auto-converts to bank deposits

Trade-off: Mitigations reduce disintermediation risk but also reduce CBDC utility. Central banks walking tightrope between innovation and stability.

ERC-4337 components:

• UserOperation: Pseudo-transaction from smart contract wallet (not EOA signature)
• Bundler: Collects UserOperations, submits as single transaction (like block builder)
• EntryPoint: Singleton contract that validates and executes UserOperations
• Paymaster: Optional contract that pays gas on behalf of users

Flow:

1. User creates UserOperation (intent to do something)
2. Bundler collects many UserOperations
3. Bundler submits bundle to EntryPoint
4. EntryPoint validates each UserOp (signature, funds)
5. If Paymaster specified, it pays gas instead of user
6. EntryPoint executes the operations

Benefits: Social recovery, multi-sig, gas sponsorship, session keys - all without protocol changes.

The accountability problem:

• AI agents can hold keys, execute trades, interact with protocols
• Decisions emerge from training, not explicit programming
• Actions may be unpredictable even to developers

Potential liable parties:

User:

• Delegated authority to AI
• Chose to use autonomous agent
• But: May not understand AI's decision process

Developer:

• Created the system
• Product liability precedents exist
• But: Can't foresee all emergent behaviors

AI itself:

• Made the decision
• But: No legal personhood, no assets to seize
• Philosophical: Can code be "negligent"?

Economic analysis:

• Liability should fall on party best able to prevent harm
• Insurance markets may emerge for AI agent risks
• Bonding requirements could internalize potential losses

Current gap: Legal frameworks assume human decision-makers. AI agents create principal-agent problems with no clear agent. Regulation will lag technology significantly.