Base Documentation

repository·master·Indexed 43 days ago

https://github.com/base/docs

Public documentation site for Base, managed via the Mintlify framework. Includes guides for local development using the Mint CLI, MDX linting, documentation structure validation, and tools for generating AI-facing site indexes such as llms.txt and AGENTS.md.

Tokens
299.2K
Snippets
628
Records
1.2K
Agent score
56%

What's inside Base

  1. Overview of Flashblocks API

    master

    Flashblocks provide pre-confirmation-specific additions to Base public endpoints (mainnet.base.org / sepolia.base.org). These allow developers to read state, simulate transactions, and stream events against sequencer-ordered data approximately 1.8 seconds before a block is officially sealed.

    Note on Deprecation: Flashblocks are planned for deprecation in the upcoming Denim hardfork. Developers should prepare to migrate to canonical 200ms block behavior. For testing, you can use Vibenet.

  2. Overview of the B20 Native Token Standard

    master

    B20 is Base's native token standard, implemented as Rust precompiles rather than EVM smart contracts. This makes B20 tokens faster and cheaper than standard ERC-20 contracts.

    B20 is a superset of ERC-20: all standard methods (transfer, transferFrom, approve, balanceOf, allowance) and events work exactly as expected, allowing existing tooling to work without changes. However, B20 adds native support for:

    • Compliance Toolkit: Transfer policies (allowlists/blocklists), freeze-and-reissue controls, and supply caps.
    • Advanced Features: Memos (bytes32 payloads), granular pausing, and ERC-2612 permit support.
    • Variants:
      • Asset: Configurable decimals (6–18), rebase multiplier, onchain announcements, and batched issuance.
      • Stablecoin: Fixed 6 decimals and self-declared fiat currency codes.

    All tokens are deployed via the singleton B20Factory precompile.

  3. What is Base Verify?

    master

    Base Verify is a service that allows users to prove ownership of verified accounts on platforms like X, Coinbase, Instagram, and TikTok without sharing their credentials.

    Instead of raw account data, your application receives a deterministic token. This token acts as a Sybil-resistant identifier, allowing you to identify high-value users (e.g., those with Coinbase One subscriptions or specific social media follower counts) regardless of their onchain transaction history.

    Common Use Cases:

    • Token-gated airdrops or daily rewards.
    • Exclusive content access (e.g., creator coins).
    • Identity-based loyalty programs.
  4. Overview of the B20 Token Standard

    master

    B20 is Base's native ERC-20-compatible token standard implemented as Rust precompiles. It is a superset of ERC-20, maintaining full parity for standard methods like transfer, approve, balanceOf, and totalSupply.

    Key enhancements include:

    • Chain-native roles: Built-in RBAC (Role-Based Access Control).
    • Policy Scopes: Granular authorization via the PolicyRegistry.
    • Memos: Support for attaching metadata to transfers and mint/burn operations.
    • Supply Caps: Optional maximum supply limits.
    • Deterministic Factory: Creation via a singleton precompile with deterministic addresses.
    • Variants: Specialized surfaces for ASSET and STABLECOIN tokens.
  5. Overview of the Canyon upgrade

    master

    The Canyon upgrade brings Ethereum Shanghai EIPs to the Base execution layer. It includes the Shapella upgrade and several minor protocol fixes.

    Key features include:

    • Support for EIP-3651 (Warm COINBASE), EIP-3855 (PUSH0 instruction), and EIP-3860 (Limit and meter initcode).
    • Support for EIP-4895 (Beacon chain push withdrawals as operations).
    • Deprecation of SELFDESTRUCT via EIP-6049.
    • Modifications to the EIP-1559 Denominator.
    • Updates to the deposit receipt hash to include the deposit nonce and deposit nonce version.
    • Deployment of the create2Deployer to 0x13b0D85CcB8bf860b6b79AF3029fCA081AE9beF2.
  6. Overview of the Fjord hardfork

    master

    The Fjord hardfork introduced several key updates across the execution and consensus layers, including FastLZ-based L1 fee estimation, support for the secp256r1 curve via a new precompile, and Brotli channel compression.

    Activation Timestamps

    • mainnet: 1720627201 (2024-07-10 16:00:01 UTC)
    • sepolia: 1716998400 (2024-05-29 16:00:00 UTC)
  7. Understand the LLM interaction layer in sync-from-base-std

    master

    The llm/ directory manages how the synchronization script interacts with Large Language Models. It is decoupled from the main routing and file I/O logic. The core responsibility of this folder is defining what is sent to the model (prompts) and how it is transmitted (client).

    Key Components

    • prompts.mjs: Contains prompt builders for different dispatch kinds (code-change, release, manual-update) and a SHARED_RULES block. This is the primary file to edit if you want to change the model's instructions or behavior.
    • client.mjs: Manages communication with Coinbase's internal LLM Gateway. It handles authentication, retries, backoff, and benchmark logging. It follows a simple "pass a string, get a string back" contract.

    The Interaction Contract

    The main loop in ../index.mjs follows this pattern:

    1. Build: A pure function transforms context into a prompt string.
    2. Call: An asynchronous call sends the prompt to the Gateway and logs performance metrics.

    Note that benchmarking data is accumulated in BENCH_LOG and flushed to a JSONL file at the end of a run, which is then uploaded as a sync-bench-<run_id> artifact.

    import { buildClaudePrompt } from "./llm/prompts.mjs";
    import { callClaude, BENCH_LOG } from "./llm/client.mjs";
    
    const prompt = buildClaudePrompt(kind, ctx);   // pure: ctx → string
    const output = await callClaude(prompt, page); // side-effect: Gateway call + bench
  8. Choose a Base Verify integration

    master

    Base Verify provides two primary integration paths depending on where you want to enforce verification and what you are trying to achieve:

    1. Verify Social Accounts: Best for gated application experiences, rewards, and backend-controlled claims. You check verified account ownership and traits within your application backend.
    2. Verify Users Onchain: Best for contract-level claims, deposits, mints, votes, and other onchain actions. You enforce identity deduplication and eligibility policies directly within a smart contract.

    Both methods require the user to provide a wallet-signed SIWE (Sign-In With Ethereum) message to prove they control the wallet. Base Verify then evaluates the requested provider or policy and returns the necessary verification data.