# Base — full corpus # LLM Wiki An open-source template for building LLM-powered knowledge bases, following [Andrej Karpathy's "LLM Wiki" pattern](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f). You provide raw sources. The LLM reads them, writes structured wiki pages, cross-links everything, and maintains it over time. You never edit the wiki directly — you curate sources and ask questions. ## How It Works The system has three layers: ``` raw/ Sources you collect (articles, transcripts, notes, PDFs) wiki/ LLM-written & maintained pages (summaries, concepts, entities, syntheses) CLAUDE.md Schema that tells the LLM how to structure everything ``` Three operations drive the workflow: | Operation | Trigger | What happens | |-----------|---------|--------------| | **Ingest** | "ingest raw/my-source.txt" | LLM reads the source, creates a summary page, creates/updates concept and entity pages, adds cross-links, updates the index and log | | **Query** | Ask any question | LLM searches the wiki, synthesizes an answer with citations, optionally creates a synthesis page for novel insights | | **Lint** | "lint" or "health check" | LLM audits all pages for orphans, contradictions, missing links, incomplete sections, and low-confidence claims — fixes what it can, reports the rest | ## Quick Start 1. **Clone this repo** ```bash git clone https://github.com/YOUR_USERNAME/llm-wiki.git my-knowledge-base cd my-knowledge-base ``` 2. **Customize CLAUDE.md** for your domain - Update the Purpose section with your topic - Replace the placeholder tagging taxonomy with your own categories - Adjust confidence level descriptions if needed - Everything else (workflows, page formats, linking rules) works as-is 3. **Drop sources into `raw/`** - Text files, transcripts, articles, notes — any plain text - These are immutable once added; the LLM never modifies them 4. **Tell the LLM to ingest** ``` ingest raw/my-first-source.txt ``` The LLM will create summary pages, concept pages, entity pages, cross-links, and update the index. 5. **Ask questions** ``` What are the key differences between X and Y? ``` The LLM answers from the wiki, citing specific pages. 6. **Run health checks** ``` lint ``` The LLM audits the wiki and fixes issues. ## Directory Structure ``` . ├── CLAUDE.md # Schema — the LLM's instructions ├── raw/ # Your source documents (immutable) └── wiki/ ├── index.md # Master catalog of all pages ├── log.md # Append-only activity log ├── dashboard.md # Dataview dashboard (Obsidian) ├── analytics.md # Charts View analytics (Obsidian) ├── flashcards.md # Spaced repetition cards ├── summaries/ # One page per source document ├── concepts/ # Concept and framework pages ├── entities/ # People, tools, organizations, etc. ├── syntheses/ # Cross-cutting analyses and comparisons ├── journal/ # Research/session journal entries │ └── template.md # Journal entry template └── presentations/ # Marp slide decks ``` ## Enhancements This template includes several extras beyond the core wiki pattern: ### Dataview Dashboard (`wiki/dashboard.md`) Live queries that surface low-confidence pages, recent updates, concepts by tag, and pages with the most sources. Requires the [Dataview](https://github.com/blacksmithgu/obsidian-dataview) Obsidian plugin. ### Charts View Analytics (`wiki/analytics.md`) Visual analytics with pie charts, bar charts, and word clouds. Requires the [Charts View](https://github.com/caronchen/obsidian-chartsview-plugin) Obsidian plugin. ### Mermaid Diagrams Use Mermaid code blocks in any wiki page to create flowcharts, sequence diagrams, or concept maps. Native support in Obsidian and GitHub. ### Marp Slides (`wiki/presentations/`) Create slide decks from markdown using [Marp](https://marp.app/). Drop presentation files in this directory. ### Research Journal (`wiki/journal/`) Track your research sessions, experiments, or applied work with the included template. The LLM can reference journal entries when answering queries. ### Spaced Repetition (`wiki/flashcards.md`) Flashcards in the format used by the [Spaced Repetition](https://github.com/st3v3nmw/obsidian-spaced-repetition) Obsidian plugin. Ask the LLM to generate flashcards from any wiki page. ### MCP Server This repo works with Claude Code's MCP server capabilities. Point an MCP-compatible client at this repo and the LLM can read/write the wiki programmatically. ## Customizing for Your Domain The schema in `CLAUDE.md` is domain-agnostic. To adapt it: 1. **Purpose** — Describe your knowledge domain in one paragraph 2. **Tagging taxonomy** — Replace placeholder categories with your own (e.g., for a cooking KB: `cuisine`, `technique`, `ingredient`, `equipment`) 3. **Confidence levels** — Adjust the descriptions to match your domain's evidence standards 4. **Entity types** — Update the entity page description to match what entities mean in your domain (people, tools, companies, etc.) 5. **Journal template** — Customize `wiki/journal/template.md` for your workflow Everything else — page format, linking conventions, workflows, rules — is universal and works across domains. ## Example Domains This template works for any knowledge-intensive topic: - **Research notes** — papers, experiments, methodologies - **Book analysis** — themes, characters, author techniques - **Competitive analysis** — companies, products, market trends - **Course notes** — lectures, readings, key concepts - **Personal development** — frameworks, habits, book summaries - **Technical documentation** — APIs, architectures, design patterns - **Hobby deep-dives** — any subject you want to master ## License MIT --- title: "Knowledge Base Index" type: index updated: 2026-06-19 --- # Knowledge Base Index Master catalog of all wiki pages. Every page in the wiki must have an entry here. ## Concepts | Page | Tags | Confidence | Updated | |------|------|------------|---------| | [what-is-base](concepts/what-is-base.md) | base, l2, op-stack, overview | high | 2026-06-19 | | [network-and-rpc](concepts/network-and-rpc.md) | network, rpc, chain-id, fees | high | 2026-06-19 | | [chain-architecture](concepts/chain-architecture.md) | sequencer, batcher, derivation | high | 2026-06-19 | | [proof-system](concepts/proof-system.md) | proofs, zk, tee, withdrawals | high | 2026-06-19 | | [flashblocks](concepts/flashblocks.md) | flashblocks, latency, preconfirmations | high | 2026-06-19 | | [bridging](concepts/bridging.md) | bridge, deposits, withdrawals | high | 2026-06-19 | | [deploying-contracts](concepts/deploying-contracts.md) | deploy, solidity, foundry | high | 2026-06-19 | | [base-account](concepts/base-account.md) | base-account, smart-wallet, sub-accounts | high | 2026-06-19 | | [payments-and-spend-permissions](concepts/payments-and-spend-permissions.md) | base-pay, spend-permissions | high | 2026-06-19 | | [basenames](concepts/basenames.md) | basenames, ens, identity | high | 2026-06-19 | | [b20-tokens](concepts/b20-tokens.md) | b20, tokens, compliance | high | 2026-06-19 | | [running-a-node](concepts/running-a-node.md) | node, infrastructure, snapshots | high | 2026-06-19 | ## Entities | Page | Tags | Updated | |------|------|---------| | [predeploys-and-precompiles](entities/predeploys-and-precompiles.md) | predeploys, precompiles, system-contracts | 2026-06-19 | ## Summaries | Page | Source | Key Topics | Created | |------|--------|------------|---------| | [json-rpc-api-catalog](summaries/json-rpc-api-catalog.md) | docs.base.org API ref | eth_/debug_ methods, Flashblocks RPC | 2026-06-19 | | [docs-catalog](summaries/docs-catalog.md) | docs.base.org llms.txt | page map + hardfork timeline | 2026-06-19 | ## Syntheses | Page | Pages Compared | Created | |------|----------------|---------| | [app-safety-and-troubleshooting](syntheses/app-safety-and-troubleshooting.md) | tx + node + safety guides | 2026-06-19 | ## Statistics - **Total pages**: 16 - **Concepts**: 12 - **Entities**: 1 - **Summaries**: 2 - **Syntheses**: 1 - **Sources ingested**: 162 (1 llms.txt index, 160 docs.base.org pages, 1 node README) - **High confidence**: 15 - **Medium confidence**: 1 --- title: "B20 Native Token Standard" type: concept tags: [b20, tokens, erc20, compliance] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-b20-native-token-standard.md] --- # B20 Native Token Standard **B20** is the Base ecosystem's own version of **ERC-20**, introduced with the **Beryl** hardfork. It is a fungible-token standard with a **built-in compliance toolkit** baked into the interface rather than bolted on per-contract: - **Transfer policies** — programmable rules governing who can send/receive. - **Freeze-and-seize** — administrative control to freeze balances and seize funds (for regulated/asset-issuer use cases). - **Role-based access control** — granular permissions over token operations. - **Memos** — attach data to transfers. - **Supply caps** — enforce maximum supply. The full interface specs live in the **Base Standard Library** repository. Tokens are launched via the **B20 Factory precompile** (see "Launch a B20 Token" / "Launch a Token" in [docs-catalog](../summaries/docs-catalog.md)). ## When to use B20 vs ERC-20 Standard ERC-20 still works on Base (it's EVM-equivalent). Reach for **B20** when you need the compliance features natively — regulated assets, stablecoins, or anything requiring freeze/seize, transfer restrictions, or auditable memos. For a plain utility token, ERC-20 is simpler. B20 being a *native* standard means these controls are part of the protocol-blessed interface rather than custom code each issuer must audit. --- title: "Base Account & Sub Accounts" type: concept tags: [base-account, smart-wallet, sign-in, sub-accounts, auth] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-auth-sign-in-with-base.md, raw/llms_txt_doc-sub-accounts.md] --- # Base Account & Sub Accounts **Base Account** (formerly Coinbase Smart Wallet) is a smart-contract wallet with passkey sign-in and account-abstraction features — the foundation for the consumer UX Base targets. ## Sign In With Base (auth) A standard authentication flow where the user signs in with their Base Account. The docs show integration with **Privy**, which handles the initial auth flow, user sessions, and wallet connections; you can add a custom backend verification layer (verify the signed message server-side) for stronger guarantees. The result is a wallet-native login without seed-phrase friction. ## Sub Accounts **Sub Accounts** are app-specific wallet accounts embedded directly in your application, controlled by the user's main Base Account. They let an app provision a dedicated account per user so routine actions don't each require a popup signature — a smoother UX while the main account retains control. Pair them with [spend permissions](payments-and-spend-permissions.md) to enable automated/recurring on-chain actions within user-set limits. ## Related capabilities Base Account supports batched transactions, typed-data signing, and a capabilities API (what the wallet supports) — see [docs-catalog](../summaries/docs-catalog.md). Payments built on top: [payments-and-spend-permissions](payments-and-spend-permissions.md). --- title: "Basenames" type: concept tags: [basenames, ens, naming, identity] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-basenames.md] --- # Basenames **Basenames** are human-readable names for addresses on Base (e.g. `name.base.eth`) — Base's identity primitive. They are built **on top of the ENS protocol** and comply with **ENSIP-19** (the L2 reverse-resolution standard), so they interoperate with the broader ENS ecosystem rather than being a proprietary silo. ## What they're for - **Readable identity** — replace `0x…` addresses with a memorable name in wallets and apps. - **Reverse resolution** — map an address back to its primary Basename (the ENSIP-19 piece), so apps can display names without the user re-entering them. - **App integration** — resolve and display Basenames using ENS-compatible libraries pointed at Base. ## Lifecycle Names are registered through the Basenames **registrar**, can be transferred between accounts (there is a transfer guide), and have an FAQ covering renewals and resolution. The registrar contract and supporting flows are catalogued in [docs-catalog](../summaries/docs-catalog.md). Because Basenames are ENS-based, integrating them is largely standard ENS work with Base as the target chain — relevant when building user-facing apps with [Base Account](base-account.md). --- title: "Bridging: Standard Bridge, Deposits & Withdrawals" type: concept tags: [bridge, deposits, withdrawals, cross-domain-messenger] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-standard-bridges.md, raw/llms_txt_doc-contract-addresses.md] --- # Bridging: Standard Bridge, Deposits & Withdrawals The **standard bridges** move ETH and ERC-20 tokens between Ethereum L1 and Base L2. They are built on top of the **cross-domain messenger** contracts and present a standard deposit/withdraw interface for both L1-native and L2-native tokens (the legacy API is preserved so existing apps keep working). ## Deposits (L1 → L2) A deposit locks/burns tokens on L1 and mints/releases them on L2. Deposits are fast — they finalize on L2 once the deposit is included via the derivation pipeline ([chain-architecture](chain-architecture.md)). On-chain entry points: `L2StandardBridge` at `0x4200000000000000000000000000000000000010` (L2 side) and the L1 bridge/portal contracts. ## Withdrawals (L2 → L1) Withdrawals are **slower by design** because L1 must be sure the L2 state is valid: 1. Initiate the withdrawal on L2. 2. Wait for the securing checkpoint to be **proven** and pass the challenge window in the [proof-system](proof-system.md). 3. Finalize/claim on L1. This challenge delay is the price of trustless exit — even a misbehaving sequencer cannot steal bridged funds. ## Messaging Arbitrary L1↔L2 messages go through `L2CrossDomainMessenger` (`0x4200000000000000000000000000000000000007`); the standard bridges are themselves messenger clients. Note OP-Stack **address aliasing** applies to L1 contracts calling L2 ([what-is-base](what-is-base.md)). A separate **Base ↔ Solana** bridge exists for cross-ecosystem transfers (see [docs-catalog](../summaries/docs-catalog.md)). --- title: "Chain Architecture: Sequencing, Batching, Derivation" type: concept tags: [architecture, sequencer, batcher, derivation, op-stack] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-block-building.md, raw/llms_txt_doc-derivation.md, raw/llms_txt_doc-execution-engine.md, raw/llms_txt_doc-batcher.md] --- # Chain Architecture: Sequencing, Batching, Derivation Base is an OP-Stack rollup. Three roles move data from the L2 to Ethereum L1 and back. ## Block building (the sequencer) A single **sequencer** orders transactions and produces L2 blocks. Ordering is internally separate from UX — the sequencer can build [Flashblocks](flashblocks.md) every ~200ms without changing the externally observed block cadence. ## The batcher The **batcher** (batch submitter) posts L2 data to L1 so verifiers can reconstruct the chain. It watches the gap between the **unsafe head** (latest sequenced block) and the **safe head** (latest block confirmed on L1 via derivation), then encodes unconfirmed L2 blocks into **channels**, fragments them into **frames**, and posts frames as L1 transactions. Only data conforming to the derivation spec is accepted as valid. ## Derivation **Derivation** is the reverse: verifiers read the batcher's L1 frames, reassemble channels, decode batches, and reconstruct the original L2 blocks — giving every L1 observer a deterministic L2 chain. Span batches (a later hardfork) compress multiple L2 blocks per batcher transaction to cut L1 data cost. ## Execution engine The **execution engine** runs the EVM with OP-Stack changes. Example: EIP-7825 caps the per-transaction gas limit at 16,777,216 (2²⁴); transactions over the cap are rejected at validation. Execution-layer behavior is otherwise EVM-equivalent ([what-is-base](what-is-base.md)). ## Securing it Posting data to L1 makes the chain *available*; making L2 state *verifiable* from L1 is the job of the [proof-system](proof-system.md) (proposer, challenger, provers). Hardfork-by-hardfork changes to these components are mapped in [docs-catalog](../summaries/docs-catalog.md). --- title: "Deploying Smart Contracts on Base" type: concept tags: [deploy, solidity, foundry, hardhat, contracts] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-deploy-on-base.md, raw/llms_txt_doc-differences-between-ethereum-and-base.md] --- # Deploying Smart Contracts on Base Because Base is EVM-equivalent, deploying is the same workflow as Ethereum — point your tooling at a Base RPC and chain ID ([network-and-rpc](network-and-rpc.md)). ## The flow 1. **Set up tooling** — Foundry, Hardhat, or thirdweb; fund a deployer wallet with Base ETH (bridge from L1 or use a Sepolia faucet for testnet). 2. **Configure the network** — RPC `https://mainnet.base.org` / chain ID `8453` (or Sepolia `84532`). 3. **Deploy** — `forge create` / `hardhat deploy` exactly as on Ethereum; gas is paid in ETH with the two-part [fee](network-and-rpc.md) model. 4. **Verify** — publish source on the block explorer so the contract is readable and trusted (also a malicious-flag-avoidance best practice, see [app-safety-and-troubleshooting](../syntheses/app-safety-and-troubleshooting.md)). ## What to keep in mind vs Ethereum - **L1 data fee** dominates cost — minimize calldata; deploying large contracts costs more than the L2 gas alone suggests. - **Per-transaction gas cap** of 2²⁴ from the execution engine ([chain-architecture](chain-architecture.md)) — very large deploys may need splitting. - **Predeploys** at `0x42...` give you bridge/messenger/oracle contracts out of the box ([predeploys-and-precompiles](../entities/predeploys-and-precompiles.md)). Higher-level building blocks (account auth, payments, names) are in [base-account](base-account.md), [payments-and-spend-permissions](payments-and-spend-permissions.md), and [basenames](basenames.md). Managed deploy/RPC tooling (thirdweb, Coinbase Developer Platform) is catalogued in [docs-catalog](../summaries/docs-catalog.md). --- title: "Flashblocks" type: concept tags: [flashblocks, latency, preconfirmations, sequencer] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-flashblocks-overview.md, raw/llms_txt_doc-flashblocks-faq.md] --- # Flashblocks **Flashblocks** are **200ms incremental state updates** the Base sequencer streams between full blocks, sharply reducing perceived latency — users see their transaction reflected in ~200ms rather than waiting a full ~1s block. ## Key facts - **Always on.** Every Base block is built by the Flashblocks builder; Flashblocks are not optional and are always live. - **Preconfirmation, not finality.** A Flashblock is an early, partial view of the block being built. It gives fast UX feedback; full settlement still follows the normal block → L1 batch → proof path ([chain-architecture](chain-architecture.md), [proof-system](proof-system.md)). - **Two ways to consume** — a dedicated WebSocket stream of incremental Flashblock updates, and standard RPC methods that surface the latest "pending" Flashblock state (the `newflashblocks` / pending-logs surfaces in [docs-catalog](../summaries/docs-catalog.md)). ## Building against it Apps wanting the snappiest UX subscribe to the Flashblocks WebSocket and optimistically reflect the preconfirmed state, then reconcile against the confirmed block. Latency-sensitive reads can target the pending Flashblock. This 200ms cadence is one of the concrete [differences from Ethereum](what-is-base.md). --- title: "Networks, RPC & Fees" type: concept tags: [network, rpc, chain-id, fees, contract-addresses] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-connecting-to-base.md, raw/llms_txt_doc-contract-addresses.md, raw/llms_txt_doc-network-fees.md] --- # Networks, RPC & Fees ## Network parameters | Network | Chain ID | Public RPC | Explorer | |---|---|---|---| | Base Mainnet | **8453** | `https://mainnet.base.org` | base.blockscout.com | | Base Sepolia (testnet) | **84532** | `https://sepolia.base.org` | sepolia-explorer.base.org | The public RPCs are rate-limited; production apps use a node provider (Coinbase Developer Platform, Alchemy, QuickNode, etc. — see [docs-catalog](../summaries/docs-catalog.md)). ## Key predeploy addresses OP-Stack predeploys live at fixed `0x42...` addresses on every Base network (full list in `raw/`). The most-used: - `0x4200000000000000000000000000000000000006` — **WETH9** - `0x4200000000000000000000000000000000000007` — **L2CrossDomainMessenger** - `0x4200000000000000000000000000000000000010` — **L2StandardBridge** - `0x420000000000000000000000000000000000000F` — **GasPriceOracle** (used to estimate the L1 fee) See [predeploys-and-precompiles](../entities/predeploys-and-precompiles.md) for what these are. ## Fees Every Base transaction has **two costs**: 1. **L2 execution fee** — gas × L2 base fee, the cost to execute on Base. 2. **L1 security fee** — the estimated cost to publish the transaction's data on Ethereum L1, computed by the on-chain **GasPriceOracle**. This is usually the *larger* of the two and varies with Ethereum congestion. Because the L1 fee tracks Ethereum gas, flexible transactions can be cheaper when L1 is quiet. Base also enforces a **minimum base fee** (a difference from Ethereum). The architecture behind data posting (the batcher) is in [chain-architecture](chain-architecture.md). --- title: "Payments & Spend Permissions" type: concept tags: [base-pay, payments, spend-permissions, subscriptions] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-base-pay.md, raw/llms_txt_doc-spend-permissions.md] --- # Payments & Spend Permissions ## Base Pay **Base Pay** is a drop-in payment flow built on the Base Account SDK. It operates **independently of wallet connections** — it doesn't require special Wagmi (or other connector) integration; you call the Base Account SDK directly and follow the Accept Payments guide. This makes it easy to add "pay with Base" to any app regardless of the wallet stack. ## Spend Permissions **Spend Permissions** let a user grant a trusted **spender** a timed allowance to move assets from their Base Account **without a fresh signature each time**, within defined limits (amount, token, period). This is the primitive behind: - **Recurring payments / subscriptions** — charge on a schedule up to the allowance. - **Automated transactions** — agents or backends that act on the user's behalf within bounds. The user stays in control: permissions are scoped and revocable. Combined with [sub-accounts](base-account.md), spend permissions enable seamless, signature-free UX for trusted, bounded actions. ## When to use which Use **Base Pay** for one-off checkout; use **Spend Permissions** for anything recurring or automated. Both build on [Base Account](base-account.md). --- title: "Proof System & Withdrawal Security" type: concept tags: [proofs, fault-proofs, zk, tee, withdrawals, azul] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-proof-system.md, raw/llms_txt_doc-proposer.md, raw/llms_txt_doc-challenger.md] --- # Proof System & Withdrawal Security The **Azul** upgrade introduced a **multi-proof system** that secures the L2 checkpoints withdrawals depend on. A **checkpoint** is a fixed interval of L2 blocks summarized by an **output root**. ## The dispute game Each proposal about a checkpoint goes to **`AggregateVerifier`**, an L1 dispute game that can verify one or two proofs for the same proposal before withdrawals rely on it. Two prover paths feed it: - **TEE prover** — creates the initial proposal proof (common path). - **ZK prover** — a permissionless zero-knowledge path; anyone can produce/verify it. ## Offchain services - **Proposer** — turns canonical L2 checkpoint ranges into `AggregateVerifier` games on L1: selects the next checkpoint, obtains a TEE proof, validates it against canonical L2 state, and creates the dispute game via `DisputeGameFactory`. - **Challenger** — independently checks in-progress games against canonical L2 state and disputes invalid checkpoint roots. In the ZK path it is **permissionless** — any operator with canonical L1/L2 access can challenge. ## Why it matters Withdrawals from Base to Ethereum finalize only after the securing checkpoint is proven and past challenge — this is the source of the bridge's withdrawal delay ([bridging](bridging.md)). The proof system, plus a Security Council, is what lets users exit to L1 trustlessly even if the sequencer misbehaves. --- title: "Running a Base Node" type: concept tags: [node, infrastructure, op-stack, snapshots] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-run-a-node.md, raw/llms_txt_doc-node-troubleshooting.md] --- # Running a Base Node Anyone can run a Base node to get a private RPC endpoint and verify the chain independently. The supported path is the **official Base Node Docker setup**. ## What a Base node is Like any OP-Stack node, it pairs two processes: - An **execution client** (op-geth / Reth) running the EVM and serving JSON-RPC. - A **rollup node** (op-node) that drives [derivation](chain-architecture.md) — reconstructing L2 blocks from L1 data and following the sequencer's unsafe head. ## Setup essentials - Use the official Docker compose setup; point it at an L1 endpoint (you need access to an Ethereum node/provider for derivation). - **Snapshots** dramatically cut sync time — restore from a published snapshot rather than syncing from genesis. - Plan for **disk and bandwidth**: an archive node is large; most apps want a full (non-archive) node. ## Operational notes The docs cover node providers (if you'd rather not self-host), performance tuning, snapshots, and an upgrade guide for hardforks (your node must upgrade before each fork activates — see the upgrades in [docs-catalog](../summaries/docs-catalog.md)). Common failures — container won't start, falling behind the head, L1 connectivity — are collected in [app-safety-and-troubleshooting](../syntheses/app-safety-and-troubleshooting.md); the first diagnostic step is almost always checking container logs. --- title: "What is Base" type: concept tags: [base, l2, optimism, ethereum, overview] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-why-base.md, raw/llms_txt_doc-differences-between-ethereum-and-base.md] --- # What is Base Base is an Ethereum Layer 2 (L2) incubated by Coinbase, built on the **OP Stack** (the same rollup framework as Optimism, part of the Superchain). It offers **~1-second, sub-cent transactions** while inheriting Ethereum security: transaction data is posted to Ethereum L1 and L2 state is made verifiable from L1 through a proof system. ## Why Base - **Cheap and fast** — 1-second blocks, <1-cent typical transactions. - **EVM-equivalent** — built to be as compatible with Ethereum as possible; existing Solidity contracts and tooling work with minimal changes. - **Coinbase distribution** — apps can reach Coinbase's user base; grant programs fund builders. ## How Base differs from Ethereum Base is intentionally close to Ethereum, but a few differences matter when building: - **Flashblocks** — 200ms preconfirmation sub-blocks reduce perceived latency ([flashblocks](flashblocks.md)). - **Two-part fees** — every transaction pays an L2 execution fee *and* an L1 data (security) fee; the L1 portion usually dominates ([network-and-rpc](network-and-rpc.md)). - **Minimum base fee** — Base enforces a configurable floor on the base fee. - **Bridging** — moving assets to/from L1 goes through the standard bridge with a withdrawal challenge delay ([bridging](bridging.md)). - **Precompiles / predeploys / address aliasing** — OP-Stack-specific contracts and the L1→L2 address aliasing rule ([predeploys-and-precompiles](../entities/predeploys-and-precompiles.md)). ## Where to go next Network IDs and RPCs: [network-and-rpc](network-and-rpc.md). How the rollup actually produces and secures blocks: [chain-architecture](chain-architecture.md) and [proof-system](proof-system.md). Building apps: [deploying-contracts](deploying-contracts.md), [base-account](base-account.md). The full page map: [docs-catalog](../summaries/docs-catalog.md). --- title: "Predeploys & Precompiles" type: entity tags: [predeploys, precompiles, system-contracts, op-stack] updated: 2026-06-19 confidence: high sources: [raw/llms_txt_doc-predeploys.md, raw/llms_txt_doc-contract-addresses.md] --- # Predeploys & Precompiles OP-Stack chains ship a set of system contracts at fixed addresses from genesis. ## Predeploys **Predeployed contracts** exist on Base at predetermined addresses in the genesis state. They are like precompiles in that they're always present, but they run as **normal EVM bytecode** (upgradeable system contracts) rather than native node code. They live in the `0x42000000000000000000000000000000000000xx` range. Common ones: | Address | Contract | Role | |---|---|---| | `…0006` | WETH9 | wrapped ETH | | `…0007` | L2CrossDomainMessenger | L1↔L2 messaging ([bridging](../concepts/bridging.md)) | | `…0010` | L2StandardBridge | token bridge | | `…000F` | GasPriceOracle | L1-fee estimation ([network-and-rpc](../concepts/network-and-rpc.md)) | | `…0014` | L2ERC721Bridge | NFT bridge | (Full table in `raw/llms_txt_doc-contract-addresses.md`.) ## Precompiles & preinstalls - **Precompiles** are native node implementations callable as contracts (e.g. RIP-7212 secp256r1 added in Fjord, bn256 pairing restrictions in Granite — see hardforks in [docs-catalog](../summaries/docs-catalog.md)). - **Preinstalls** are commonly-needed contracts (e.g. multicall, Create2 deployer) present from genesis so apps can rely on them without deploying. ## Address aliasing When an L1 contract calls L2 through the messenger, its address is **aliased** (offset by a constant) to avoid spoofing — a behavior to account for when a contract's L2 logic checks `msg.sender` for an L1 origin. --- title: "Activity Log" type: log --- # Activity Log Append-only record of all wiki changes. ## Format Each entry follows this format: ``` ### YYYY-MM-DD HH:MM — [Action Type] - **Source/Trigger**: what initiated the action - **Pages created**: list of new pages - **Pages updated**: list of updated pages - **Notes**: any contradictions flagged, decisions made ``` --- ### 2026-04-08 00:00 — Setup - **Source/Trigger**: Repository initialized - **Pages created**: index.md, log.md, dashboard.md, analytics.md, flashcards.md - **Pages updated**: none - **Notes**: Empty knowledge base ready for first source ingestion ### 2026-06-19 00:00 — Initial curation (medium rung) - **Source/Trigger**: 162 raw sources (docs.base.org llms.txt + base/node README) - **Pages created**: 12 concepts, 1 entity (predeploys-and-precompiles), 2 summaries (json-rpc-api-catalog, docs-catalog), 1 synthesis (app-safety-and-troubleshooting) - **Pages updated**: index.md - **Notes**: Medium rung. JSON-RPC method pages + hardfork pages mapped in catalogs, not ingested per-page. app-safety-and-troubleshooting is confidence:medium. --- title: "Docs Catalog & Hardforks" type: summary tags: [catalog, map, hardforks, reference] updated: 2026-06-19 confidence: high sources: [raw/llms_txt-llms-txt-index.md] --- # Docs Catalog & Hardforks Map of the docs.base.org corpus (published via llms.txt; ~160 pages mirrored in `raw/` as `llms_txt_doc-.md`). Use this to find the right raw source; the wiki distills the high-traffic ones. | Area | Raw slugs (selection) | Wiki coverage | |---|---|---| | Get started | why-base, differences-between-ethereum-and-base, connecting-to-base, glossary, resources-for-ai-agents | [what-is-base](../concepts/what-is-base.md), [network-and-rpc](../concepts/network-and-rpc.md) | | Chain architecture | block-building, derivation, execution-engine, batcher, proposer, system-config, span-batches, p2p | [chain-architecture](../concepts/chain-architecture.md) | | Proofs/security | proof-system, proof-contracts, zk-prover, tee-prover, challenger, security-council-for-base | [proof-system](../concepts/proof-system.md) | | Flashblocks | flashblocks-overview, flashblocks-architecture, flashblocks-faq | [flashblocks](../concepts/flashblocks.md) | | Bridging | standard-bridges, cross-domain-messengers, deposits, withdrawals, base-solana-bridge, transaction-finality | [bridging](../concepts/bridging.md) | | Network/contracts | contract-addresses, network-fees, network-faucets, predeploys, precompiles, preinstalls | [network-and-rpc](../concepts/network-and-rpc.md), [predeploys-and-precompiles](../entities/predeploys-and-precompiles.md) | | Build apps | deploy-on-base, deploy-smart-contracts, thirdweb, coinbase-developer-platform, rainbowkit, reown | [deploying-contracts](../concepts/deploying-contracts.md) | | Base Account | auth-sign-in-with-base, authenticate-users, sign-in-with-base, sub-accounts, batch-transactions, capabilities-overview, sign-and-verify-typed-data | [base-account](../concepts/base-account.md) | | Payments | base-pay, accept-payments, accept-recurring-payments, spend-permissions | [payments-and-spend-permissions](../concepts/payments-and-spend-permissions.md) | | Basenames | basenames, basenames-faq, basename-transfer-guide, registrar | [basenames](../concepts/basenames.md) | | B20 / tokens | b20-native-token-standard, launch-a-b20-token, launch-a-token | [b20-tokens](../concepts/b20-tokens.md) | | Nodes | run-a-node, node-providers, node-performance, node-snapshots, node-upgrade-guide, node-troubleshooting | [running-a-node](../concepts/running-a-node.md) | | JSON-RPC | eth-*, debug-*, net-version, web3-clientversion, eth-simulatev1 | [json-rpc-api-catalog](json-rpc-api-catalog.md) | ## Hardforks (network upgrades) In order, each with an overview page in `raw/` (`llms_txt_doc-.md` / `-overview`): **Canyon** (Shanghai EIPs) → **Delta** (span batches) → **Ecotone** (Dencun, EIP-4844 blobs) → **Fjord** (FastLZ L1 fee, RIP-7212 secp256r1) → **Granite** (bn256 limits) → **Holocene** (dynamic EIP-1559 params) → **Isthmus** (Pectra EIPs, operator fee) → **Jovian** (configurable min base fee, DA footprint scalar) → **Beryl** (B20 standard, faster withdrawals, Reth V2) → **Azul** (Osaka EVM, multi-proof system). A node must upgrade before each fork activates ([running-a-node](../concepts/running-a-node.md)). --- title: "JSON-RPC & Node API Catalog" type: summary tags: [json-rpc, api, eth, debug, reference] updated: 2026-06-19 confidence: high sources: [raw/llms_txt-llms-txt-index.md, raw/llms_txt_doc-execution-engine.md] --- # JSON-RPC & Node API Catalog Base serves the standard Ethereum JSON-RPC surface (it's EVM-equivalent) plus OP-Stack and Flashblocks extensions. Each method has its own reference page mirrored in `raw/` as `llms_txt_doc-.md`; this page maps the space so agents fetch the exact one needed rather than ingesting all of them. ## Standard `eth_` methods (read) `eth_blockNumber`, `eth_call`, `eth_chainId`, `eth_estimateGas`, `eth_feeHistory`, `eth_gasPrice`, `eth_getBalance`, `eth_getBlockByHash`, `eth_getBlockByNumber`, `eth_getBlockReceipts`, `eth_getBlockTransactionCountByHash/ByNumber`, `eth_getCode`, `eth_getLogs`, `eth_getStorageAt`, `eth_getTransactionByHash` (and by-block-index variants), `eth_getTransactionCount`, `eth_getTransactionReceipt`, `eth_maxPriorityFeePerGas`, `eth_syncing`. ## Write / simulate `eth_sendRawTransaction`, `eth_simulateV1`, `eth_estimateGas`. ## Subscriptions & Flashblocks `eth_subscribe` / `eth_unsubscribe`; Flashblocks WebSocket surfaces (`newFlashblocks`, `newFlashblockTransactions`, pending-logs) for 200ms preconfirmation streams ([flashblocks](../concepts/flashblocks.md)). ## Debug / tracing `debug_traceTransaction`, `debug_traceBlockByHash`, `debug_traceBlockByNumber` (require a node/provider that enables the debug namespace). ## Misc `net_version`, `web3_clientVersion`. Note the execution-engine cap: transactions over **2²⁴ gas** are rejected ([chain-architecture](../concepts/chain-architecture.md)). For full request/response shapes, read the specific method page in `raw/`. --- title: "App Safety & Troubleshooting Casebook" type: synthesis tags: [troubleshooting, security, transactions, nodes, casebook] updated: 2026-06-19 confidence: medium sources: [raw/llms_txt_doc-troubleshooting-transactions.md, raw/llms_txt_doc-node-troubleshooting.md, raw/llms_txt_doc-how-to-avoid-getting-your-app-flagged-as-malicious.md] --- # App Safety & Troubleshooting Casebook Practical fixes distilled from the Base troubleshooting and safety guides. Confidence medium — symptoms/fixes paraphrased from the docs. ## Transactions stuck pending - **Max fee too low** — if `maxFeePerGas` is below the current base fee, the transaction sits until the base fee drops to your level. Fix: resubmit with a higher max fee (remember Base enforces a **minimum base fee**, and the [L1 data fee](../concepts/network-and-rpc.md) is separate). - **Nonce gaps / replacement** — a pending lower-nonce transaction blocks later ones; replace it (same nonce, higher fee) or wait. ## Node won't run / falls behind - **Always check container logs first** — the official Docker setup surfaces the cause there more often than not. - **Falling behind the head** — usually L1 connectivity (derivation needs a healthy Ethereum endpoint) or slow disk; use a **snapshot** to resync and provision faster storage ([running-a-node](../concepts/running-a-node.md)). - **Upgrade before hardforks** — a node on old software stalls at a fork boundary; follow the node upgrade guide ahead of each activation. ## Avoiding "malicious app" flags - **Verify your contracts** on block explorers — unverified source is a top trust red flag. - **Reduce contract risk** — audited, minimal-permission contracts; avoid patterns that resemble drainers (unbounded approvals, hidden transfers). - **Be transparent in wallet prompts** — clear typed-data and transaction descriptions; reputable wallets and scanners flag opaque or high-risk requests. ## Reporting Security issues go through Base's bug-bounty / vulnerability-reporting process (see [docs-catalog](../summaries/docs-catalog.md)) rather than public disclosure.