Curriculum

A blockchain transaction is a signed instruction: "move this amount, from this account, to that account," broadcast to a network of independent computers (nodes) that each check it against the same rules and the same shared history before adding it to the next block. No single company approves it. The network approves it by having enough independent participants agree it is valid — that a signature is genuine and the sending account actually has the balance it claims.

Once a transaction is a few blocks deep, reversing it would require rewriting those blocks and getting the network to accept the rewrite, which the design makes prohibitively expensive on any established chain. That is the entire meaning of "final" here: not that a court cannot compel a return of funds, but that no button exists to click.

A wallet is not a place money sits, the way a bank vault holds cash. The asset itself lives only as an entry in the blockchain's shared ledger. A wallet is software that holds the CRYPTOGRAPHIC KEYS that can produce a valid signature for that ledger entry. "My wallet has $400 in it" is shorthand for "the ledger has a $400 balance attached to an address, and my wallet holds the key that can move it."

This is why a wallet can be recreated from its seed phrase on a brand-new phone with the balance intact — nothing was ever stored ON the old phone except the key. It is also why losing the key with no backup destroys access permanently: the ledger entry still exists, but nothing can produce a signature for it anymore.

A wallet generates a private key: a large random number, kept secret. From it, mathematics derives a public key, and from that, an address — the string shared with others so they can send funds. The relationship is one-directional: it is computationally infeasible to work backward from a public key or address to the private key that produced it. That asymmetry is the entire basis of self-custody — sharing an address to receive funds reveals nothing that would let anyone move them out.

Signing a transaction means running it through a function that only the private key can produce a valid result for, and that anyone holding the public key can verify. That single mechanism — sign with the private half, verify with the public half — is what "your keys, your crypto" is describing: whoever holds the private key can produce valid signatures, full stop, regardless of who "should" own the funds.

Most wallets do not ask a person to back up one private key per asset. Instead they generate one seed phrase — typically 12 or 24 common English words, drawn from a standardized list (BIP-39) — and derive every private key the wallet will ever use from that single phrase in a deterministic sequence. Back up the phrase once, and every current and future key that wallet generates can be reconstructed from it on any compatible wallet software, on any device.

This makes the seed phrase strictly more sensitive than any individual private key: it is the key to all the keys. Anyone who obtains it can reconstruct the entire wallet, on their own device, without needing the original phone, app, or password. It is written down, never typed into a website, never photographed to a cloud-synced camera roll, and never entered anywhere except directly into trusted wallet software during setup or recovery.

Know Your Customer (KYC) verification — a government ID, sometimes a selfie match, sometimes a proof-of-address document — is a legal requirement on regulated exchanges operating in most jurisdictions, driven by anti-money-laundering law rather than by exchange preference. Expect it before any meaningful deposit or withdrawal limit unlocks, and expect it to take anywhere from minutes (automated document scan) to a few business days (manual review).

The identity data goes to the exchange, which is a real custodian of both funds and personal information — the same due-diligence instinct applied to a bank (is it licensed, insured where insurance exists, how long has it operated, has it had a public security incident) applies here too.

ACH bank transfer is typically the cheapest way to fund an account — often free or near-free — but settles over one to a few business days, and many exchanges hold newly-deposited-via-ACH funds for a matching period before allowing a crypto withdrawal, specifically to limit chargeback fraud.

A wire transfer settles same-day or next-day and typically carries a flat fee from the bank, the exchange, or both — worth checking on both ends before sending a large amount, since a wire fee is usually flat rather than a percentage and therefore matters far less on a large transfer than a small one.

A debit or credit card is the fastest rail — funds and the purchase clear in seconds — and by a wide margin the most expensive, carrying a card-processing fee that routinely runs several percent, layered on top of whatever spread the purchase itself carries. Card funding is a convenience premium, not a bargain.

Nearly every exchange offers two ways to acquire an asset on the same order book: a "simple" or "instant buy" flow that fills immediately at a price the exchange quotes, and an order-book flow — typically a limit order — where the buyer names a price and it fills only if the market reaches it.

These are not the same price. The instant-buy flow embeds a spread — the gap between what a market maker will sell for and what it will buy back for — that is frequently far larger than the exchange's advertised trading fee, because the spread is a separate cost the headline fee page usually does not mention at all. A trading fee of 0% on the exchange's own fee schedule says nothing about the spread baked into its instant-buy price; the two are entirely different costs, charged in different places.

A limit order placed on the exchange's standard order book, by contrast, fills at the price named, with only the disclosed trading fee applied on top. The mechanical difference between the two flows — one price is quoted by the exchange and includes an undisclosed spread, the other is set by the trader and fills against other traders' orders — is routinely the largest single cost in an exchange purchase, larger than the fee difference between exchanges that people spend the most time comparing.

Many assets exist on more than one blockchain network simultaneously — USDC, for instance, is issued natively on Ethereum, Solana, Base, and others as separate tokens that share a symbol but live on entirely different ledgers. An exchange withdrawal form always asks which network to send over, and the receiving wallet or exchange must support that SAME network for the funds to arrive.

The network chosen also sets the transaction fee and speed: an Ethereum mainnet transfer can cost several to tens of dollars in gas depending on network congestion, while the same asset sent over Solana, Base, or another low-fee network can cost a small fraction of a cent — this is a mechanical fact about the network, unrelated to which one is "correct" for a given destination, which is decided purely by what the receiving side supports.

Sending a token built for one network to an address on a different, incompatible network typically does not bounce back or error out — the receiving chain simply has no record of that token, and there is no ledger for it to appear on. The transaction can succeed on the sending chain's own terms while the funds become permanently unreachable, because nothing at the destination knows how to associate them with any account.

Some networks share address formats without sharing ledgers (several EVM-compatible chains generate identical-looking addresses), which is precisely what makes this mistake easy to make and why the network selector is not a formality — it changes which ledger the funds land on, if any.

A handful of networks (XRP Ledger, Stellar, and some others) use a shared account model where an exchange holds ONE address for ALL of its users on that network, and relies on an additional memo or destination tag to route an incoming deposit to the correct individual account internally. Omitting a required memo, or entering the wrong one, sends the funds to the exchange's address with no way for that exchange to attribute them to any customer — recoverable only through the exchange's own support process, if at all, and never automatically.

Assets on account-based chains without this model — Ethereum, Solana, Bitcoin, and most others — use one address per recipient and need no memo at all; the field only matters on the specific networks that share addresses this way, and the withdrawal form indicates when one is required.

Before moving a meaningful balance, sending a small amount — enough to be worth confirming, small enough that a mistake costs little — and confirming it arrives and is spendable at the destination is standard practice for a reason: it catches a wrong network, a wrong memo, or a mistyped address while the cost of being wrong is trivial, rather than after the full balance is already gone.

A test send costs a second network fee, which is the entire price of the insurance it buys. Skipping it to save that fee is the single most common way a self-custody withdrawal goes wrong.

A hot wallet keeps its private keys on an internet-connected device — a phone or browser extension. It is the fastest to use: signing a transaction is a tap or a click, which is exactly what makes it the right tier for day-to-day interaction with apps, and exactly what makes it the wrong tier for a balance whose loss would be serious.

The threat it defends against is convenience-cost, not security: it exists to make frequent, small-value interaction practical. It does comparatively little against malware on the device it runs on, a malicious browser extension, or a phishing site that tricks a person into signing something they did not mean to.

A hardware wallet is a dedicated physical device whose one job is holding a private key and signing with it internally, so the key itself never touches an internet-connected computer or phone even while approving a transaction that computer initiated. The connected device sees only the finished, signed transaction, never the key that produced it.

This specifically defends against a compromised computer or phone — malware that can read every file and keystroke on the connected device still cannot extract a key that was never present on it. It defends much less well against a person approving a transaction on the device itself without reading what it says, which is why a hardware wallet's screen showing the actual destination and amount, and a habit of reading it before pressing confirm, is the control that actually matters.

A burner wallet is a hot wallet deliberately funded with only what a single risky interaction is worth — trying an unaudited new contract, connecting to an unfamiliar site, minting from an unverified source — kept permanently separate from any wallet holding a meaningful balance.

It defends against the specific failure mode where approving one bad transaction, or granting one over-broad token approval, drains everything reachable by that wallet's key. A burner wallet makes the reachable amount, by construction, the only thing at stake.

A practical setup most active users converge on independently: a burner for anything experimental or unaudited, a hot wallet for routine use at a balance the owner is comfortable losing to a phone compromise, and a hardware wallet for anything larger, moved rarely and deliberately. None of the three replaces the others — they defend against different failures, so running only one tier means accepting whichever failure that tier does not defend against.

A block explorer is a website that reads a blockchain's public data and presents it in a searchable, human-readable form: every transaction, every account balance, every contract's code and current state. Explorers exist for essentially every actively used chain, and pasting a contract address into one returns the ground truth about that contract as it exists on-chain right now, independent of whatever a website or a social post claims about it.

For a token specifically, the explorer's "holders" tab, transaction history, and contract-code tabs are the primary source; anything a third-party site says about the same token is, at best, a summary of what the explorer already shows.

A pair's LIQUIDITY is the actual value of assets sitting in its trading pool right now — the depth available to trade against. MARKET CAP is price multiplied by the CIRCULATING supply — tokens actually issued and out in the world. FULLY DILUTED VALUATION (FDV) is price multiplied by the MAXIMUM supply the token contract will ever allow to exist, including tokens not yet issued.

These three numbers answer different questions and none substitutes for another. A token can show a large market cap while its trading pool holds only a few thousand dollars of real liquidity — meaning that market cap is a mostly theoretical figure that a modest sell order would move sharply, since there is little on the other side of the pool to absorb it. A token can also show an FDV many multiples of its market cap when most of its supply has not been issued yet, which describes future dilution risk rather than anything about the current price.

None of these three numbers, alone or together, states whether a specific price is high or low — they measure supply, issuance, and available depth, not value.

Most token contracts retain one or more administrative "authorities" — permissions the deployer can exercise after launch. The two that matter most: a MINT authority, which can create new tokens (diluting every existing holder at will if still active), and, on some chains, an authority to freeze individual accounts' balances. An explorer's contract or token-info page for the relevant chain (Etherscan and its siblings for EVM chains, Solscan or Solana Explorer for Solana) shows whether each authority is still present ("active") or has been permanently renounced.

A renounced mint authority means the current supply is the maximum supply that will ever exist — a verifiable, on-chain fact, not a claim from the project. An active one means the deployer retains the technical ability to create more at any time, whatever they say their intentions are. This is exactly the kind of fact the safety surface (`/crypto/safety`) checks automatically, but it is also directly checkable by hand on the explorer in under a minute.

PRICE IMPACT is the price movement a trade itself CAUSES by consuming liquidity from a pool as it executes — a mechanical, predictable consequence of trade size against available depth, the same as the exchange spread from module 2 but now visible and calculable from the pool's own reserves rather than hidden inside a quoted price.

SLIPPAGE TOLERANCE is a setting the trader chooses: the maximum price movement, versus the quote shown when the trade was submitted, that is acceptable before the transaction should fail rather than execute. Between submission and confirmation on the network, other transactions can move the pool's price; a slippage tolerance set too tight causes routine failed transactions (which still cost the network fee even though nothing traded), while one set very loose removes the protection it exists to provide, allowing the trade to execute at a materially worse price than the trader saw when submitting it.

Rather than trading against one pool, most DEX interfaces route a swap through the SEQUENCE of pools, potentially spanning several protocols, that a solver determines will produce the best output for that specific size — including splitting one trade across multiple pools in parallel when that beats routing it through any single one. This is why the same nominal pair can quote a different effective price on different aggregator interfaces: they may be finding different routes through the same underlying liquidity.

On networks where transactions compete for limited block space, a PRIORITY FEE is an additional payment, on top of the base network fee, that a sender attaches to signal how urgently the transaction should be included. It functions as a bid: during network congestion, transactions offering a higher priority fee are typically included first, and a swap during a busy period may need one to land within the block the trader expected, rather than several blocks later at a materially different price.

Maximal Extractable Value (MEV) is profit an entity that controls what order transactions execute in — chiefly the party building the next block — can extract by choosing that order deliberately, rather than by trading on new information.

SANDWICHING is the specific pattern most likely to touch an ordinary swap: an operator sees a pending trade in the public queue of not-yet-confirmed transactions (the "mempool"), inserts its own buy order immediately before it to push the price up, lets the victim's trade execute at that worse price, then immediately sells back down, capturing the difference. A slippage tolerance set no looser than necessary is the direct, mechanical defense: sandwiching only extracts value up to whatever tolerance the victim's trade allowed for.

An Automated Market Maker (AMM) pool holds a reserve of two assets and prices trades using a fixed formula against those reserves — the most common being the constant-product rule, `x * y = k`: multiplying the two reserve quantities together always yields the same constant. A trade that adds one asset to the pool must remove enough of the other to keep that product constant, which is what determines the trade's price and its price impact (module 6) purely mechanically, with no order book and no human market maker involved.

A liquidity provider (LP) deposits both assets in the pool's current ratio and receives LP tokens representing a proportional claim on the pool's reserves. Every trade against the pool pays a fee, split among LPs in proportion to their share — that fee income is the reward for supplying the depth other traders trade against.

As trades move the pool's internal price, the constant-product formula automatically sells whichever asset is rising and buys whichever asset is falling to keep the reserve product constant — mechanically, an LP is always accumulating more of the worse-performing asset and less of the better-performing one relative to what they deposited. IMPERMANENT LOSS is the value gap this produces, measured against simply holding the original two assets outside the pool without ever depositing them.

It is called "impermanent" because it exists only relative to holding, and only crystallizes into a real loss the moment of withdrawal — if the price ratio later returns to where it was at deposit, the gap closes to zero. But a price ratio that never returns makes the loss just as permanent as any other, which is why treating the name as a promise that it goes away is a mistake this module exists to head off.

The exact relationship, for a two-asset constant-product pool, given `r` as the ratio the price has moved to versus deposit: `impermanent loss = 2 * sqrt(r) / (1 + r) - 1`, always zero or negative, and identical in magnitude whether the price moved up by a factor of `r` or down by a factor of `1/r`.

A pool's displayed APY is very often two different things added together and shown as one number: FEE APY, which is a share of the real trading fees the pool actually collected — genuine revenue, funded by traders — and REWARD (or emission) APY, which is newly minted governance or protocol tokens paid to LPs to attract deposits, funded by dilution of that token's supply rather than by any trading activity.

A pool's headline APY that is almost entirely emissions is a materially different proposition from one that is almost entirely fees: the first depends on the reward token holding its value once received and eventually sold, and on the emission schedule continuing; the second is closer to being paid directly by the trading activity that generated it. Neither figure alone says whether the fee or reward income, together, outweighs any impermanent loss over the same period — that requires computing all three together for the specific pool and holding period in question.

Newer AMM designs let an LP concentrate their deposit within a chosen price RANGE rather than spreading it across the pool's entire theoretical price curve from zero to infinity. Capital within the active range earns a proportionally larger share of fees than the same capital would spread thinly across the whole curve — the mechanism behind why concentrated-liquidity positions can post materially higher fee APY than the equivalent full-range deposit.

The position stops earning fees entirely the moment price moves outside the chosen range, since the pool no longer needs that liquidity to price trades at the current level, and the impermanent-loss formula above changes shape for a bounded range — losses accumulate faster than the full-range case for a given price move, because the same capital was standing in for a much narrower slice of the price curve. A concentrated position, in other words, trades higher fee income within its range for a range it can exit entirely.

On-chain lending protocols pool deposited assets and lend them to borrowers who post collateral — usually a different asset, valued above the loan amount (over-collateralization), with the position automatically liquidated if the collateral's value falls too close to the loan's value. A lender's yield is the interest borrowers pay, set algorithmically by each pool's current utilization — how much of the deposited pool is currently borrowed out.

The yield genuinely originates from real borrower demand paying real interest. The risk is a smart-contract bug in the lending protocol itself, and — separately — the possibility that its liquidation mechanism fails to keep pace with a fast-moving market, leaving the pool with bad debt that deposited funds ultimately absorb.

On a proof-of-stake network, STAKING means locking a network's native asset with a validator, who uses it as collateral backing their participation in producing and confirming blocks. Reward yield comes from two places: the network's own issuance (new tokens created specifically to pay stakers, functioning as network security spending funded by dilution of everyone's share) and a cut of transaction fees the validator collects.

The specific risk staking adds is SLASHING: a validator that behaves incorrectly — going offline for too long, or, more seriously, signing conflicting blocks — can have a portion of its staked collateral destroyed by the network's own rules. Delegating to a validator therefore delegates exposure to that validator's uptime and correct behavior, not just to the network's general health.

A liquid staking protocol stakes on a depositor's behalf and issues a liquid staking token (LST) in return — a receipt representing the staked position plus its accruing rewards, tradable and usable elsewhere on-chain while the underlying stays locked with validators. This solves staking's core liquidity problem (funds otherwise sit locked and unusable, often for a mandatory unbonding period) but adds a new one: the LST's market price can, and periodically does, temporarily de-peg from the value of the underlying staked asset it represents, particularly during periods when many holders want to exit at once and the venues to sell the LST directly have thinner liquidity than the redemption queue.

Restaking protocols take an already-staked or already-liquid-staked position and pledge that SAME collateral again to secure additional, separate protocols or networks (often called "actively validated services") beyond the base chain, in exchange for additional yield paid by whichever service is being secured.

The yield stacks because the same capital is now backing multiple commitments at once — and so, mechanically, does the risk: a fault by any one of the additional services being secured, or a bug in the restaking protocol's own accounting of who is backing what, can result in slashing that traces back to the base staked position, a risk that does not exist for a position staked once and left there.

A new project typically allocates a large share of its total token supply to its team, early investors, and a treasury, alongside whatever portion is sold or distributed publicly at launch. Releasing all of it immediately would let insiders exit into the earliest, thinnest liquidity available — vesting exists specifically to delay and spread out when that allocation becomes transferable, so it enters the market gradually rather than all at once.

A CLIFF is a period during which zero of an allocation is transferable, followed by a single point at which a chunk (sometimes the entire allocation, sometimes a fixed percentage) becomes transferable all at once — a one-year cliff, for instance, means nothing from that allocation can move for twelve months, then some or all of it can.

LINEAR VESTING releases a fixed amount continuously (sometimes modeled as per-block, in practice usually indistinguishable from continuous) over a defined window rather than in one lump — a token vesting linearly over two years with no cliff becomes transferable in small increments every day for those two years, rather than in one event.

The two combine constantly: a common structure is a cliff of some months where nothing releases, followed by linear release of the remainder over a longer subsequent window — meaning both the CLIFF DATE and the SLOPE of the linear portion afterward are mechanically relevant, not just one or the other.

A cliff unlock concentrates a large amount of newly-transferable supply at a single moment, which — mechanically, independent of any judgment about the token itself — is the point at which recipients who intend to sell some or all of it are first able to. A linear schedule instead spreads that same eventual supply increase across many smaller moments, which the market can absorb more gradually.

None of this states what any specific holder will do with newly-unlocked tokens, or what a specific unlock will do to a specific price — those depend on facts (how much of the unlock recipients intend to sell, what the market's existing depth is, what else is happening concurrently) this module has no data on. What it teaches is the shape of the mechanism: WHEN supply becomes available to move, and in what pattern, which is the fact a project's own tokenomics documentation states directly and precisely, for that specific token, on that specific chain.

The United States Internal Revenue Service treats convertible virtual currency as PROPERTY for federal tax purposes, not as currency — a position it has stated in published guidance (IRS Notice 2014-21) and a standing FAQ maintained on its own site. Property tax treatment means the general rules for property disposals apply: a taxable event occurs on a DISPOSAL, and gain or loss is measured against the asset's cost basis — what was originally paid for it, including fees.

Selling a digital asset for a fiat currency is a disposal. So is trading one digital asset directly for a different one — the property-not-currency treatment means a crypto-to-crypto trade is treated the same as selling the first asset for cash and immediately buying the second, a taxable event even though no fiat currency ever appeared in the transaction. Spending a digital asset directly on goods or services is also a disposal of that asset, at whatever it was worth at the moment of the purchase.

Simply buying and holding is not a disposal — no taxable event occurs from a price moving while an asset is held, only from something that counts as disposing of it. What counts as a disposal in more specialized situations (a liquid-staking deposit, an LP deposit, a token received from an airdrop or a staking reward) is exactly the kind of individual-facts question this module cannot answer generally — it is a preparer question, informed by primary IRS guidance, not a generic rule.

For every acquisition: the date, the amount, and its cost basis in the account's home fiat currency at that moment. For every disposal: the date, the amount, and its value at that moment. For a self-custody wallet especially, a transaction history reconstructed a year later from an explorer, with no record of what was paid for anything, is materially harder to work from than records kept as transactions happen.

An exchange typically supplies transaction and, in some cases, tax-summary exports covering activity ON that exchange — but nothing an exchange exports can see a transfer to a self-custody wallet followed by activity that happened entirely outside any exchange's visibility. Keeping a running personal record, rather than relying entirely on reconstructing one later from whichever venues happen to have exports available, is the single highest-leverage habit this module can suggest.

The IRS publishes its own guidance and a maintained FAQ on digital asset transactions directly on its website, and that primary source — plus a preparer who has actually reviewed the specific transaction history in question — is the correct next step for anything beyond the general mechanics covered here. This module is deliberately silent on specific numbers, forms, or filing thresholds for exactly that reason: those are precisely the details that change from filer to filer and year to year, and that a general explainer stating them with confidence would be the least trustworthy source for.

A position's size can be derived from three inputs decided independently of each other: the account's total size, a RISK FRACTION — what percentage of that account a single trade is allowed to lose before it is closed — and a STOP distance, the price at which that trade will in fact be closed if it moves against its entry. The formula: dollar risk = account size x risk fraction; position size (in units of the asset) = dollar risk / (entry price - stop price).

As one illustrative example only — an account of $10,000, a risk fraction of 1%, an entry at $100 and a stop at $95 — the dollar risk is $100 and the position size is 20 units, because a move from $100 to $95 on 20 units loses exactly the $100 the risk fraction allowed. Changing the risk fraction, the entry, or the stop changes the position size proportionally; the formula has no opinion on what the risk fraction should be, only on what follows arithmetically once it is chosen.

Expectancy answers a different question than any single trade's outcome: given a WIN RATE and the average size of a win versus the average size of a loss (both as a percent of what was risked), what does the arithmetic say a large number of trades following the same process should average out to? The formula: expectancy = (win rate x average win) - (loss rate x average loss), where loss rate is `1 - win rate`.

As one illustrative example only — a 40% win rate, an average win of 3% and an average loss of 1% — expectancy is `(0.40 x 3) - (0.60 x 1) = 1.2 - 0.6 = 0.6`, positive despite losing on the majority of trades, because the wins were large enough relative to the losses to more than compensate. The same arithmetic runs the other way just as easily: a 70% win rate with losses several times the size of wins can produce a NEGATIVE expectancy despite winning most of the time. Win rate alone, without the size of wins and losses, says nothing about whether a process is working.

Risk of ruin describes the probability that a sequence of losses, even under a genuinely positive-expectancy process, is severe enough to exhaust an account (or reduce it) before the process's long-run average has a chance to play out. It exists as a real, calculable concept in the trading and gambling literature precisely because expectancy is a LONG-RUN average, and a long-run average with a high enough per-trade risk fraction can still be preceded by a losing streak, or a single position, large enough to end the account well before that average is reached.

The load-bearing relationship is qualitative and directly related to the sizing arithmetic above: a smaller risk fraction per trade lowers risk of ruin for a given expectancy, and a larger one raises it, holding everything else constant — the exact same risk-fraction input from the position-sizing formula, not a separate lever.

Expectancy and risk of ruin are both computed FROM a record of what actually happened — a win rate and average win/loss sizes are statistics over a set of real, logged trades, not numbers pulled from memory or intuition after the fact. A trading journal recording, at minimum, the entry, the stop, the exit, and the result of every position is the raw data both formulas in this module actually run on.

Without a journal, "my win rate feels like it's around 60%" is an impression, not a number an expectancy calculation can use — and memory for trading outcomes is reliably worse at this than a plain log, because losses and wins are not recalled with equal ease. The journal is not a record-keeping nicety layered on top of the framework; it is the framework's only actual data source.