Interactive Crypto Education Platform

CRYPTO
IS LEARNED
BY DOING

Master blockchain fundamentals, DeFi mechanics, ZK proofs, MEV, and advanced cryptographic concepts — through hands-on interactive games. No jargon lectures. Real intuition.

Explore Games Read the Concepts →
// 01 — Interactive Games
01

PLAY TO UNDERSTAND

Each game isolates one concept and forces you to engage with it mechanically — not just conceptually.

// GAME 01
🔗
Blockchain
CHAIN BUILDER
Link transaction blocks in the correct order using cryptographic hashes. Understand why tampering with any block invalidates the entire chain.
// GAME 02
🔑
Keys & Wallets
KEY MASTER
Navigate 10 rapid-fire questions on public/private keys, seed phrases, custodial vs non-custodial, hardware wallets, and derivation paths.
// GAME 03
📈
Trading & Markets
VOLATILE MARKET
Trade simulated BTC in real-time. Experience panic selling, FOMO, order books, and understand why most retail traders underperform.
// GAME 04
⛏️
Proof of Work
HASH MINER
Experience Proof-of-Work by iterating nonces until you find a valid hash. Feel exponentially how difficulty scales with each leading zero.
// GAME 05
💧
DeFi / AMM
LIQUIDITY POOL
Provision liquidity to an ETH/USDC AMM pool. Observe how the constant product formula (x×y=k) determines price and how impermanent loss works.
// GAME 06
🔮
Zero-Knowledge Proofs
ZK PROVER
Simulate a ZK proof: prove you know a secret number without revealing it. Walk through the commit → challenge → response protocol interactively.
// GAME 07
🎨
NFTs & Ownership
NFT MEMORY
Match NFT pairs while learning about on-chain metadata, royalty mechanics, IPFS storage, and what "ownership" actually means on a blockchain.
// GAME 08
MEV / Mempool
MEMPOOL SNIPER
You are a validator. Choose which pending transactions to include, front-run, or sandwich. Experience MEV extraction and why it's controversial.
// GAME 09
🗳️
Consensus
VALIDATOR VOTE
Participate in a simulated Proof-of-Stake consensus round. Vote on blocks, observe slashing conditions, and understand finality vs probabilistic safety.
// 02 — Concept Library
02

THE DEEP CONCEPTS

From genesis blocks to recursive ZK proofs — every concept explained with precision.

// Foundations

Blockchain Architecture

A blockchain is a Merkle-tree-backed append-only log replicated across a peer-to-peer network. Each block contains: a block header (with prev hash, Merkle root, timestamp, nonce), a list of transactions, and a cryptographic link to its parent.

The Merkle root is constructed by hashing transaction pairs recursively until one root hash represents the entire set. This allows SPV (Simplified Payment Verification) — you can prove a transaction was included without downloading the whole chain.

// Key Insight

Bitcoin's UTXO model tracks unspent outputs, not account balances. Every transaction consumes outputs and creates new ones. This enables parallel validation and improves privacy compared to Ethereum's account model.

The genesis block (block 0) is hardcoded — it has no parent. Satoshi embedded a newspaper headline in it: proof it wasn't pre-mined. This also anchors the chain's timeline to the real world.

Merkle TreeUTXOSPV Block HeaderGenesis Block
// Core Technology

Cryptographic Primitives

Bitcoin uses secp256k1 elliptic curve cryptography. A private key is a random 256-bit integer. The public key is derived by multiplying the private key by the generator point G on the curve. This operation is computationally irreversible — the "discrete logarithm problem."

ECDSA signatures work by: creating a random nonce k, computing point R = k×G, then using your private key + message hash to compute s. Anyone with your public key can verify (R, s) is valid without ever seeing your private key. Critically, if you reuse k, your private key is exposed.

// Critical Vulnerability

PlayStation 3 was hacked because Sony used a static k value in their ECDSA implementation. This same issue could compromise any crypto wallet that reuses nonces.

SHA-256 is used in Bitcoin's PoW and address derivation. It's a one-way function: given any input, you get a deterministic 256-bit output. Changing one bit of input completely changes the output — the "avalanche effect."

Ethereum uses Keccak-256 (not the NIST SHA-3 standard, despite being related). Addresses are the last 20 bytes of the Keccak-256 hash of the public key — not the public key itself.

secp256k1ECDSASHA-256 Keccak-256Discrete Log
// Network Agreement

Consensus Mechanisms

Proof of Work forces miners to expend real-world energy to propose blocks. The probability of mining the next block equals your share of total hashrate. The longest valid chain wins — this is Nakamoto Consensus. 51% attack requires controlling majority of global hashrate, which is economically prohibitive for large chains.

Proof of Stake replaces energy expenditure with capital at risk ("stake"). Validators are pseudorandomly selected weighted by stake. Slashing conditions punish equivocation (signing two conflicting blocks). Ethereum's implementation uses a "fork choice rule" (LMD-GHOST) combined with Casper FFG for finality.

// The Trilemma

Vitalik's Blockchain Trilemma: you can optimize for at most two of {Security, Scalability, Decentralization}. Bitcoin prioritizes security + decentralization. Many L2s trade some decentralization for scalability while inheriting L1 security.

BFT-style consensus (used by Cosmos chains, Solana's Tower BFT) achieves instant finality but requires knowing the validator set in advance. Byzantine Fault Tolerant systems can tolerate up to ⌊(n-1)/3⌋ malicious validators.

Nakamoto ConsensusLMD-GHOST Casper FFGSlashingBFT
// Decentralized Finance

DeFi Mechanics Deep Dive

AMMs and the x×y=k formula: Uniswap v2 maintains a constant product of token reserves. If pool has x ETH and y USDC, then x×y=k always. Buying ETH reduces x, forcing y to increase to maintain k. The price at any moment is y/x, but each trade moves along the curve — creating slippage.

Concentrated Liquidity (Uniswap v3) lets LPs specify a price range. Capital is only active when price is within range, earning more fees. But if price moves out of range, the LP holds only the underperforming asset — this is "impermanent loss" (more accurately: divergence loss).

// Impermanent Loss Formula

IL = 2√r/(1+r) - 1 where r is the price ratio change. A 2× price move causes ~5.7% IL. A 4× move causes ~20% IL. This loss is "impermanent" only if price returns to entry — otherwise it's permanent.

Flash loans allow borrowing unlimited assets within one transaction, requiring repayment before the transaction ends. If repayment fails, the whole transaction reverts. This enables arbitrage, collateral swaps, and self-liquidation — all atomically, without any capital.

x×y=kImpermanent LossFlash Loans Concentrated LiquiditySlippage
// Advanced Cryptography

Zero-Knowledge Proofs

A ZK proof lets you convince someone that you know a secret, or that a statement is true, without revealing any information beyond the truth of the statement itself. Three properties must hold: Completeness (honest provers always convince), Soundness (cheaters can't fake proofs), and Zero-Knowledge (the verifier learns nothing extra).

zk-SNARKs (Succinct Non-interactive ARguments of Knowledge) are the dominant form. "Succinct" means the proof is tiny (hundreds of bytes) and fast to verify, regardless of computation complexity. They require a "trusted setup" — a ceremony where toxic waste must be destroyed. Zcash's Powers of Tau involved thousands of participants so no single party could corrupt it.

// The Trusted Setup Problem

zk-STARKs (Scalable Transparent ARguments of Knowledge) eliminate the trusted setup using hash functions alone, at the cost of larger proof sizes. StarkWare uses STARKs; most zkEVMs (zkSync, Polygon) use SNARKs or hybrid approaches.

Recursive proofs allow a proof to verify another proof. This enables ZK rollups to batch thousands of transactions into one proof that settles on L1. Recursive composition is why zkEVMs can scale: prove a block's execution, then prove that proof's verification, compressing work exponentially.

zk-SNARKzk-STARKTrusted Setup Recursive ProofszkEVM
// Dark Forest

MEV & the Mempool

MEV (Maximal Extractable Value) is profit extractable by block producers by reordering, including, or censoring transactions within a block. The Ethereum mempool is public — every pending transaction is visible, creating a competitive arena called "the dark forest."

Front-running: a bot sees your large DEX buy in the mempool, submits the same trade with higher gas (priority fee), executes first, then you buy at a higher price. Sandwich attacks combine front-run + back-run: buy before you, sell after you, profiting from the price impact you cause.

// MEV Scale

Over $1.38B in MEV has been extracted from Ethereum since 2020 (via Flashbots data). Approximately 70%+ of Ethereum blocks are now built by MEV-Boost relays, meaning validators outsource block construction to specialized builders who maximize MEV.

PBS (Proposer-Builder Separation) formalizes this: block proposers (validators) and block builders are separate roles. Builders compete to construct the most profitable block; proposers simply choose the highest-bidding builder. MEV-Boost is the current implementation. Enshrined PBS is a future Ethereum roadmap item.

MEVFront-RunningSandwich Attack PBSFlashbotsDark Forest
// Scaling Solutions

Layer 2 Architecture

Optimistic Rollups (Optimism, Arbitrum) assume all transactions are valid by default. They post transaction data to L1 as calldata, but only run computation if someone submits a fraud proof. The 7-day challenge window is what lets withdrawals take a week — it's the time for fraud proofs to be submitted.

ZK Rollups (zkSync, Starknet, Polygon zkEVM) prove every state transition cryptographically. Withdrawals are instant (no challenge period). But generating ZK proofs is computationally expensive, and achieving full EVM equivalence in ZK circuits is extremely hard.

// Data Availability

EIP-4844 (Proto-Danksharding) introduced "blobs" — a new data type attached to blocks that's cheaper than calldata and auto-pruned after ~18 days. This reduced L2 fees by 10-100×. Full Danksharding will add 64 blobs/block with Data Availability Sampling (DAS).

Validiums use ZK proofs for computation but store data off-chain, achieving higher throughput at the cost of weaker data availability guarantees. Sovereign rollups (Celestia ecosystem) separate execution, settlement, and data availability into independent layers.

Optimistic RollupZK RollupEIP-4844 Fraud ProofValidiumData Availability
// Economic Design

Tokenomics & Mechanism Design

Token supply mechanics: Bitcoin is deflationary — hard cap of 21M, halvings every ~4 years. Ethereum switched to deflationary under EIP-1559, which burns a base fee on every transaction. When blocks are full, ETH can be net deflationary — "ultrasound money."

EIP-1559 replaced the first-price auction gas model. Now: base fee (burned) + priority fee (to validators). Base fee adjusts automatically: up when blocks are >50% full, down when <50%. This creates more predictable fees and reduces gas wars.

// Reflexivity

George Soros's concept applies powerfully to crypto: token price affects protocol usage (higher price = more liquidity = more users) which affects token fundamentals (fees, burn rate, yield) which affects price. This reflexive loop amplifies both bull and bear cycles.

Vote-escrow tokenomics (veCRV model): lock tokens for up to 4 years to receive veTokens. Longer locks = more governance power + fee share. This aligns long-term holders, reduces circulating supply, and launched the "Curve Wars" — protocols bribing veCRV holders to direct liquidity emissions.

EIP-1559DeflationaryveCRV Curve WarsReflexivityEmissions
// Cross-Chain

Bridges & Interoperability

Cross-chain bridges are among the most dangerous attack surfaces in crypto — over $2.5B was stolen from bridges in 2022 alone (Ronin: $625M, Wormhole: $320M, Nomad: $190M). Understanding why requires understanding trust models.

Lock-and-mint bridges: lock native token on chain A, mint wrapped version on chain B. The wrapped token's security is entirely dependent on the bridge contract — if it's exploited, the wrapped token becomes unbacked. This is what happened with Wormhole.

// Trust Spectrum

Bridges range from trusted (multisig custodians — least secure) → optimistic (fraud proofs, 7-day delay) → ZK-verified (cryptographic proofs, fastest finality, hardest to build). The canonical L1→L2 bridge for a rollup is the most secure, inheriting L1 security.

IBC (Inter-Blockchain Communication) is the gold standard in the Cosmos ecosystem — a light-client based protocol that verifies state proofs on the destination chain. No trusted intermediaries. LayerZero uses an oracle + relayer model with cryptoeconomic incentives rather than full state verification.

Lock-and-MintIBCLayerZero Light ClientTrust Model
// Real-World Data

Oracle Networks

Smart contracts are deterministic and isolated — they cannot read external data (prices, weather, sports results). Oracles are the bridge. But introducing external data introduces trust assumptions, breaking the trustless nature of on-chain execution.

Chainlink uses a decentralized network of node operators. For price feeds, multiple nodes fetch from multiple data sources, the median is taken, and the answer is committed on-chain. Node operators stake LINK as collateral — they're slashed for incorrect data. Aggregation is done via a "FluxAggregator" or "OffchainAggregation" (OCR2) contract.

// Oracle Manipulation

Protocols using on-chain DEX spot prices as oracles are vulnerable to flash loan manipulation. Attacker borrows $100M, moves a pool price, exploits a protocol reading that price, repays the loan — all in one transaction. Time-weighted average prices (TWAPs) mitigate this but add latency.

Pyth Network takes a different approach: publish-then-aggregate. Data providers (exchanges, market makers) push prices on-chain at high frequency. Consumers pull the latest price. Pyth uses a "confidence interval" alongside the price, communicating data uncertainty — a more nuanced model than a single point estimate.

ChainlinkTWAPPyth Oracle ManipulationOCR2