These are my notes from JumpCrypto's reading list. So why even crypto? Jump frames crypto as infrastructure that is a trust-minimized ledger for value transfer, a shared state machine for computation, open platform of composable APIs, and a token-based incentive layer that scales the network.

Utilization of Tokens

The following excerpt is from "Crypto Tokens: A Breakthrough in Open Network Design" by Chris Dixon (2017). Chris Dixon argues that crypto tokens are a major breakthrough because they give the internet a practical way to build open networks that can compete with proprietary platforms. He contrasts the early web, which enabled small teams to build products through open protocols, with today’s iOS app stores and big tech ecosystems that impose fees and restrictions, limiting independent developers’ ability to scale. Tokenization changed the game by "unbundling" Bitcoin's deeper innovation. Beyond being a store of value, Bitcoin pioneered a method of coordinating and securing a decentralized network and tokens generalize that idea as a reusable pattern for different kind of networks. This idea of a reusable pattern spawned in many different derivatives. Dixon explains how a token can fund and operate an open service while keeping control decentralized. He emphasizes incentives where token ownership can align users, developers, investors, and service providers with a share goal. Growing the network helping overcome the bootstrap problem by sharing the collective gain via token ownership. He points that tokenizing network across different domains is the next chapter in open computing such as Linux or Wikipedia, making online infrastructure more accessible and fair.

Importance of Decentralization

Chris Dixon defines two eras:

Era 1 (1980s to early 2000s): Internet services were built on open, decentralized protocols like HTTP and SMTP. Anyone could build on them without permission allowing openness, helping companies grow and innovate.
Era 2 (mid-2000s to present): Large centralized platforms came to dominate this space. These companies (i.e. MAG7) controlled platforms and set rules for developers, eliminating third party innovation. During Era 2, I have a slight objection to what Dixon writes. Era 2 isn’t only centralized dominance; the open-source substrate stayed alive and materially enabled innovation. While distribution and user access became more centralized, the open-source "substrate" still enabled meaningful third-party innovation, especially in developer tooling and infrastructure.

In AI/ML, frameworks like PyTorch and TensorFlow were made open source. Majority of cloud infrastructure relies on Linux and Kubernetes allowed developers to build and deploy applications at scale without paying for licensing fees. Open sourcing by powerful "monopolistic" still allows us (the third party) to experiment. Though in the current landscape, many projects are bounded by training infrastructure like GPUs.

Dixon argues we're entering Era 3 of the internet, built on decentralized cryptonetworks (e.g. Bitcoin, Ethereum) that combine the best features of both earlier eras. Systems that use blockchain consensus and tokens to align incentives individuals without a centralized authority. The benefit of decentralization is not only about censorship resistance, but he also list benefits that were mentioned earlier. I find the concept of forking particularly intriguing, as it offers a way for individuals to move forward when they disagree on a project's direction

"True Power" of DeFi

The "true power" of DeFi comes from composability, the ability for open, permissionless protocols to interact and build on top of one another like "Legos". Because DeFi applications are open-source and expose their functionality on shared blockchains, developers can combine existing protocols without needing approval, avoiding the silos common in Web2 finance. This article mentions Yearn Finance optimizing yields across platforms, Achemix using those yields to create self-repaying loans, and Ribbon Finance layering option strategies on top of lending returns to demonstrate how composability allows capital to be reused efficiently across multiple different platforms.

While DeFi composability enables rapid innovation, it also introduces significant systemic risk tightly coupled protocol together in ways that amplify failure. Because many applications depend on shared liquidity, smart contracts, etc. A bug or exploit in a single foundational protocol can trigger widespread losses. TerraUSD/LUNA collapse in May 2022 is an example of systemic failure where breaking the fundamental protocol rippled through many interconnected protocols and markets. UT was integrated across different DeFi as a safe yield-bearing capital. Anchor was one of these platforms which offering unusually high yields. When UST lost its peg, large withdrawals and liquidity tress made it harder to defend the peg causing LUNA's price to collapse.

Bitcoin Protocol

The protocol has a set of rules:

identities: User control keypairs (private key $\rightarrow$ public key). Identity is basically just someone who can produce a valid signature.
ownership: The protocol tracks UTXOs. You "own" coins if you can satisfy the spending condition on some UTXO
auth: Spending is done by producing data that satisfies the the UTXO's locking condition
linking: Hash Functions bind transaction into Merkle trees and blocks into a chain so that altering old data forces redoing alot of work. A Bitcoin transaction has inputs and outputs, where each input spends a previous output (an existing UTXO). An output contains two main things:
value: how many satoshis (BTC) are in this output
locking script (scriptPubKey): the spending condition, which is a program that say what must be provided later to spend it. This is mainly just showing that you own the private key for this address. A common address style is P2PKH. The output is basically saying "these coins can be spent by whoever can provide a signature matching this public-key-hash". A block is a container for:
a block header (fixed-format summary)
a list of transaction (starting with a special coinbase transaction) Block headers is serialized in a specific 80-byte format and then hashed for proof-of-work. This include many different fields like version, previous block hash, merkle root, time, bits, and nonce. The important field to know is the merkle root which is all transaction commited to this block. The block hash is computed from the header (Bitcoin uses double-SHA256). If you change nay transaction, the Merkle root changes, header changes, PoW hash change, and the header hash is referenced by the next block where you must redo PoW for that block and every descendant.

Merkle Trees#

Within a block:

Each transaction is hashed
Hashes are paired and hashed again repeatedly up a binary tree
The final root hash is the Merkle root stored in block header Changing any tx change its leaf hash will change every ancestor thus the Merkle root. Efficient inclusion proof: To prove "tx T is in block B," you only need:

the tx hash
the sibling hashes along the path to the root ("merkle branch")
the blcok header that contains the merkle root This proof is logarithmic in numbers of transactions, not linear. Proof: Let a block contain transactions $T_0,T_1,...,T_{N-1}$ . Let $H:\{0,1\}^* \rightarrow \{0,1\}^n$ be a cryptographic hash. Define the leaf hash (transaction identifier) as: $L_{i}=H(ser(T_i))$ where $ser(T_i)$ is the byte serialization of the transaction. Define the parent hash operation as $Parent(a,b)=H(a\mid\mid b)$ Build the Merkle tree by repeatedly hashing pairs upward until one value remains. The final value is the Merkle root $MR\in\{0,1\}^n$ stored in the block header. The proof for leaf $L_i$ consists of:
transaction or its leaf hash
list of sibling hashes along the path from that leaf to root
left/right position at each step (order matters in $H(a\mid\mid b)$ $H (a ∣∣ b)$ . $\pi = ((s_0,b_0),(s_1,b_1),...,(s_{d-1},b_{d-1})$ $π = ((s_{0}, b_{0}), (s_{1}, b_{1}), ..., (s_{d - 1}, b_{d - 1})$
- $s_{k}\in \{0,1\}^n$ is the sibling hash at level $k$
- $b_k \in \{0,1\}$ is a direction bit:
- $d$ or the depth is approximately $\log_2 N$ Verification Algorithm:

Start from the leaf: $x_0=L_i$
For each level $k$ where $k\in \{0,1,...,d-1\}$ , combine the sibling $s_k$ in the correct order
Accept if the final computed value equal the Merkle root in the header If it matches, the transaction is included. More can be read at here. Additionally, a visual is provided here.

Mining and PoW#

Nielsen motivated PoW as a way to stop someone from creating a billion fake votes on a transaction validity. Instead, influence is proportional to computational work. Miners collect valid transaction from the mempool, build a candidate block (including coinbase tx paying themselves), compute the merkle root, and fill the header fields and try to find a header hash below the target. Targets adjust every 2016 block. The coinbase transaction creates the block subsidy (new BTC) plus collects transaction fees. Nodes verify coinbase amount does not exceed subsidy+fees.

Forking#

Forks happen when two miners find valid block at similar times. Bitcoin resolves this disagreement by selecting the chain with the most accumulated proof-of-work. Then, the nodes may reorg (roll back a few blocks and apply the winning branch by that node). The transaction from the losing branch return to the mempool. A full node verifies

every block header PoW
every transaction scripts/signatures
that inputs spend existing UTXOs
that money creation is within rules SPV clients doesn't validate all transaction. It downloads only block headers. Bitcoin developer documentation describes SPV as downloading headers and requesting transactions as needed. The bandwidth scales with chain height at 80 bytes/header.

Click here to view a bitcoin lifecycle

Ethereum Whitepaper

Instead of only tracking UTXOs like Bitcoin, Ethereum tracks a global state of accounts and code. It lets transactions trigger state transitions built in the VM (the EVM). The whitepaper's key claim is that "Bitcoin's big invention isn't money, it's a distributed consensus machine." Ethereum generalizes that where it provides a blockchain with a Turing-complete programming language so you can encode arbitrary state transition function ("smart contracts") directly on-chain. That means the "ledger" isn't just balances/UTXOs, it is a shared word state containing:

accounts with balances and storage
accounts that hold code (contracts)
rules for executing code deterministically on every node This whitepaper formalizes a cryptocurrency ledge as

APPLY(S, TX) -> S' OR ERROR

where:

S is current state
TX is a transaction
S' is the next state if valid else returns error It describes S as the set of unspent transaction outputs (UTXOs) and a transaction as consuming old UTXOs and producing new ones. The validation logic is described as the following:

Each input reference an existing UTXO and has a valid signature for it
sum(inputs) >= sum(outputs
Update the UTXO set Ethereum uses this framing because it want to define its APPLY function with a richer "state" then UTXOs. The whitepaper survey alternative blockchain apps and argues that building each one special purpose protocol could be redundant. Therefore, ETH aims for a single general platform where the blockchain is the computer and contracts are programs on it.

Decentralized Ordering#

If a trusted central server existed, you just need to run APPLY on that server. But in a decentralized network:

different nodes see transaction in different orders
attackers can try to double spend by racing transaction There must be a consensus mechanism that makes nodes converge on one canonical order of state transitions. This sets up the need for mining. Originally, ETH started as a PoW but transitions to PoS instead.

ETH's Design#

Ethereum replaces UTXOs with accounts. Externally Owned Account (EOAs) are controlled by private keys and Smart Contracts are controlled by code (EVM bytecode). Each account has a balance (ETH) and depending on type (nonce, code, and persistent storage). Ethereum states are centralized in to account objects. This makes it natural to store contract storage (key-value persistent memory) and program code (contract's logic).

Transactions vs Messages#

Transactions: Signed, originate from EOAs, pay fees and can create contracts or call contracts
Messages: Internal calls created by contract execution which is not signed but still part of the deterministic execution of a transaction. A singly externally-signed transaction can trigger a cascade of internal message calls (contract A calls contract B calls contract C and so on) and every node must reproduce that exact call tree and final state.

Transition Function `APPLY(S, TX)`

Validate the transaction (signature, nonce , balance $\ge$ gas, etc.)
Deduct fee ("gas")
Execute
- If it's a contract creation, initialize new account + run init code
- If it's a call, run callee code in EVM
Apply state change (balance, storage writes, logs)
Refund unused gas and pay miner/validator fee

Markle Particia Tries#

BTC block commit to transactions via Merkle root. ETH commits using Merkle Patricia Tries (a trie that support key-value mapping with cryptographic commitment). Visual depiction here

DeFi, Lending Protocols

To those who don't trust centralized figure, they are likely a believer in DeFi. Smart contracts are the backbone of DeFi as most project are built on top of Ethereum. Solidity, the Ethereum's programming language, allows for writing advanced smart contract that contain all logic that DeFi applications need. One of the early pioneers in DeFi application was MakerDAO (2015), allowing users to lock collateral to generate the DAI stable coin. Lending and borrowing is one of the pillars of this ecosystem. It also includes but not exclusive to:

Decentralized Exchanges: DEXes allow for exchanging crypto assets in a decentralized and permissionless way without giving up custody of the coin. There are 2 main types of dexes: the liquidity pool based and order book based ones. This includes Uniswap, Kyber, Bancor, etc.
Derivatives
Stable Coins: Algorithmic smart contract that is pegged to the US dollar without having to store dollars in the real world. This includes USDT, USDC, DAI, etc.
Margin Trading
Insurance

AMM#

An AMM is a type of decentralized exchange protocol that uses a formula to price assets instead of orderbook with buyers and sellers. The idea is to trade against a liquidity pool, a smart contract holding reserves of two (or more) tokens. The price you get is determined by a formula based on the ratio of tokens in the pool. A Stableswap AMM is designed for assets that should trade near the same price like: USDC/USDT or stETH/ETH. With a constant product curve, even swapping two stable coins that are both around a dollar produces slippage. The amplification parameter (A) controls the Stableswap formula:

$A$ is high: the curve behaves like constant sum ( $x+y=k$ ) where slippage is low
$A$ is low: it behaves like constant product ( $x\cdot y=k$ )

Uniswap#

Uniswap uses an AMM (Automated Market Maker). The foundation of Uniswap is simple: $x\cdot y=k$

$x$ is the reserve of Token $A$
$y$ is the reserve of Token $B$
$k$ is the constant Every trade must preserve this invariant and the product of the two reserves never changing. For example, a pool holds $100$ ETH and $300,000$ USDC, so $k=30,000,000$ . If you want to buy ETH by depositing $\Delta y$ USDC, the new reserves musts satisfy $(x-\Delta x)\cdot(y+\Delta y)=k$ Solving for $\Delta x$ is the amount of ETH you will receive. This means that the more you buy, the worse your price gets. This is price impact and it emerges naturally from the curve's shape. The marginal price at any point is just the ratio of reserves: $P=\frac{y}{x}$ . Uniswap V2 charges $0.3\%$ on each trade. The input amount is reduce before constant product check, so fees effectively increase $k$ overtime, benefiting liquidity providers. ![[Price Impact Graph.png]] Larger trade size (USDC deposited) raises the effective price due to price impact.

As you add liquidity to Uniswap, you deposit both tokens in proportion to the current reserves. You receive LP tokens representing your share of the pool. Your return comes from:

Accumulated Trading Fees
Change in the Underlying token price Impermanent loss is the main risk. If the price of one token moves significantly relative to when you deposited, the pool's rebalancing means you end up with fewer appreciating tokens and more of the depreciating one. For a price change of ratio $r$ , the impermanent loss compared to just holding is $IL=\frac{2\sqrt{r}}{1+r}-1$

Uniswap V3#

V3 introduced concentrated liquidity, letting LPs specify a range $[p_a,p_b]$ for their capital. Instead of spreading liquidity across the entire curve, your capital acts as if it were amplified within that range. The effective liquidity is $L=\Delta x \cdot \frac{\sqrt{p_a \cdot p_b}}{\sqrt{p_b} -\sqrt{p_a}}$ A narrow range gives you the same fee income with less capital, but you earn nothing when the price moves outside of the range. Thus, the IL is magnified.

Orderbook DEXes#

Orderbook DEXes work differently where they match explicit limit orders. There are bids and asks at specific prices just like a traditional exchange. The key differences from AMMs:

Price Discovery: In an orderbook, the price is set by where the best bid meets the best ask. There's no formula and determined by the market makers positing orders. In an AMM, price is an output of the reserve ratio.
Capital Efficiency: Professional market makers on order books can quote tight spreads with concentrated capital at specific price levels. Uniswap V2's liquidity is spread across all prices (very inefficient), though V3 closes this gap significantly.
Depth: On an order book, slippage depends on the depth of the book (how many orders are stacked at each price level). On an AMM, slippage is a function of trade size relative to total pool reserves (the $Δx$ formula above). Small pools have terrible slippage; deep order books can absorb large trades with minimal impact.
Latency and MEV: Order books need fast matching engines (dYdX runs on its own L1 chain for this). AMMs on Ethereum are vulnerable to MEV (front-running, sandwich attacks) because pending trades sit in a public mempool before execution.

to be continued...

L1

L2

Trading Mechanism

MEV/Arbitrage#

Smart Contract Programming

Byzantine Fault Tolerance & Proof-of-Stake algos

Exericses

Acknowledgements

These notes were developed primarly from Jump Crypto's published reading list which provides a structure way to understand the history of crypto. It explore core ideas including, but not limit to:

blockchain protocols
DeFi, AMMs, MEV/Arbitrage
decentralized systems

Jump's curated selection of whitepaper, technical resources, and exercise help me dive deeper into this topic. Any interpretations or extensions of these idea are my own.