From ethereum-rnd
Use when working on Ethereum protocol development, consensus layer, execution layer, beacon chain, EIPs, networking, or any Ethereum R&D topic. Provides reference lookup across specs, APIs, research forums, and governance resources.
npx claudepluginhub chainsafe/lodestar-claude-plugins --plugin ethereum-rndThis skill uses the workspace's default tool permissions.
You have access to 17 Ethereum R&D resources for answering questions about Ethereum protocol development.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
Share bugs, ideas, or general feedback.
You have access to 17 Ethereum R&D resources for answering questions about Ethereum protocol development.
Clone repos locally for fast, reliable access. Run the setup script from the plugin repo:
bash scripts/clone-repos.sh [base-dir] # default: ~/ethereum-repos
Once cloned, use grep, find, and cat to search and read content directly:
# Search consensus specs for a function
grep -r "process_attestation" ~/ethereum-repos/consensus-specs/specs/ --include="*.md"
# Read a specific spec file
cat ~/ethereum-repos/consensus-specs/specs/electra/beacon-chain.md
# Find all EIPs mentioning a topic
grep -rl "blob" ~/ethereum-repos/EIPs/EIPS/ | head -20
# Search beacon API endpoints
grep -r "post_beacon_blocks" ~/ethereum-repos/beacon-APIs/apis/
# Find where a function is defined across client repos
grep -rn "processAttestation\|process_attestation" ~/ethereum-repos/lodestar/packages/ ~/ethereum-repos/lighthouse/consensus/ --include="*.ts" --include="*.rs"
Why local clones are better than WebFetch:
Keep repos updated: Re-run clone-repos.sh periodically (it does git pull on existing clones).
Fallback: If repos aren't cloned locally, use WebFetch with the raw GitHub URLs documented below for each resource.
| Question type | Go to |
|---|---|
| How does the beacon chain handle X? | consensus-specs |
| What beacon API endpoint does Y? | beacon-APIs |
| What JSON-RPC method does Z? | execution-apis |
| How does the EL implement X? | execution-specs (EELS) |
| How does MEV/builder API work? | builder-specs |
| How does peer discovery/networking work? | devp2p |
| What does EIP-NNNN specify? | EIPs |
| Why was X designed this way? | annotated-spec, eth2book |
| What did ACD decide about X? | pm, forkcast |
| What are researchers discussing about X? | ethresear.ch |
| What's the governance status of EIP-NNNN? | ethereum-magicians |
| What's happening with consensus redesign? | leanroadmap |
| What's the overall roadmap status? | strawmap |
| What did R&D Discord say about X? | eth-rnd-archive |
The canonical source for Ethereum's proof-of-stake protocol.
Structure: Specs are organized by fork in specs/{fork}/ with consistent filenames.
Forks (in order):
phase0 (epoch 0) — foundational beacon chainaltair (epoch 74240) — light client support, sync committeesbellatrix (epoch 144896) — the mergecapella (epoch 194048) — withdrawalsdeneb (epoch 269568) — blob transactions (EIP-4844)electra (epoch 364032) — validator consolidation, max EBfulu (epoch 411392) — data availability samplinggloas (in development) — builder integration, inclusion listsheze (in development) — next after gloasKey files per fork:
beacon-chain.md — state transition, data structures, epoch processingvalidator.md — validator duties, attestation, proposalfork-choice.md — fork choice rule (LMD-GHOST + Casper FFG)p2p-interface.md — gossipsub topics, req/resp protocolsfork.md — fork transition logiclight-client/ — light client sync protocol (altair+)How to fetch:
https://raw.githubusercontent.com/ethereum/consensus-specs/master/specs/{fork}/{file}.md
Example — fetch the Electra beacon chain spec:
WebFetch: https://raw.githubusercontent.com/ethereum/consensus-specs/master/specs/electra/beacon-chain.md
Additional content:
ssz/simple-serialize.md — SSZ serialization specconfigs/ — network configuration (mainnet, minimal)presets/ — parameter presetsOpenAPI 3.0 specification for the beacon node and validator client REST APIs.
Format: YAML OpenAPI spec. Main file: beacon-node-oapi.yaml
Key directories:
apis/ — individual endpoint definitionstypes/ — shared data type schemasparams/ — parameter definitionsAPI categories:
How to fetch:
https://raw.githubusercontent.com/ethereum/beacon-APIs/master/apis/{category}/{endpoint}.yaml
Rendered docs (human-readable):
https://ethereum.github.io/beacon-APIs/
OpenRPC specification for JSON-RPC and Engine API.
Format: YAML split across multiple files in src/, compiled to openrpc.json.
Two API surfaces:
eth_* namespace) — standard client API for users/appsengine_* namespace) — authenticated CL↔EL communicationKey directories:
src/eth/ — JSON-RPC method specssrc/engine/ — Engine API specs (organized by fork)src/schemas/ — shared type definitionsHow to fetch:
https://raw.githubusercontent.com/ethereum/execution-apis/main/src/engine/{fork}.md
https://raw.githubusercontent.com/ethereum/execution-apis/main/src/eth/{method}.yaml
Rendered docs:
https://ethereum.github.io/execution-apis/
Python implementation of the execution layer that serves as the formal specification.
Language: Python 3.11+. Prioritizes readability over performance.
Structure: Fork modules from Frontier (2015) through Prague/Osaka (2025+), each containing the full EL state transition logic.
Key paths:
src/ethereum/forks/{fork}/ — fork-specific implementationsrc/ethereum/forks/{fork}/vm/ — EVM implementation for that forktests/ — test suiteHow to fetch:
https://raw.githubusercontent.com/ethereum/execution-specs/forks/amsterdam/src/ethereum/forks/{fork}/{file}.py
OpenAPI specification for proposer-builder separation. Defines how consensus clients source blocks from external builders.
Format: YAML OpenAPI spec. Main file: builder-oapi.yaml
Key directories:
apis/builder/ — builder endpoint definitionsspecs/ — specs organized by forktypes/ — shared typesHow to fetch:
https://raw.githubusercontent.com/ethereum/builder-specs/main/specs/{fork}/builder.md
Rendered docs:
https://ethereum.github.io/builder-specs/
Peer-to-peer networking specs for node discovery and communication.
Key spec files:
| File | Protocol |
|---|---|
rlpx.md | RLPx transport protocol (encrypted TCP) |
discv4.md | Node Discovery v4 (Kademlia-based) |
discv5/discv5.md | Node Discovery v5 (current generation) |
enr.md | Ethereum Node Records (peer identity) |
dnsdisc.md | DNS-based node discovery |
caps/eth.md | Ethereum Wire Protocol (eth/68) |
caps/snap.md | Snapshot Sync Protocol (snap/1) |
caps/les.md | Light Ethereum Subprotocol (les/4) |
How to fetch:
https://raw.githubusercontent.com/ethereum/devp2p/master/{file}.md
https://raw.githubusercontent.com/ethereum/devp2p/master/caps/{protocol}.md
All EIPs as individual markdown files.
File pattern: EIPS/eip-{number}.md
Categories:
How to fetch a specific EIP:
https://raw.githubusercontent.com/ethereum/EIPs/master/EIPS/eip-{number}.md
Or the rendered version:
https://eips.ethereum.org/EIPS/eip-{number}
Note: ERCs (token/contract standards) are now in a separate repo ethereum/ERCs.
Annotated versions of the consensus spec focused on explaining why things were designed the way they are, not just what they do.
Coverage: phase0, altair, merge (not "bellatrix"), capella, deneb, phase1 (does not cover electra+)
Note: The Bellatrix fork is named merge in this repo's directory structure.
How to fetch:
https://raw.githubusercontent.com/ethereum/annotated-spec/master/{fork}/beacon-chain.md
When to use: When someone asks "why does the protocol do X?" rather than "what does the protocol do?"
Vitalik's research codebase. Python scripts and notebooks covering cryptography, data structures, economic analysis, and protocol experiments.
Topics include: zkSNARKs, zkSTARKs, Verkle tries, Casper, sharding, erasure coding, polynomial commitments, beacon chain simulations
Note: Explicitly unmaintained — code is offered as-is. Useful as reference for understanding research concepts, not as production code.
How to fetch:
https://raw.githubusercontent.com/ethereum/research/master/{topic}/{file}.py
Central coordination hub for Ethereum protocol development.
Key directories:
AllCoreDevs-EL-Meetings/ — Execution Layer calls (ACDE)AllCoreDevs-CL-Meetings/ — Consensus Layer calls (ACDC)Breakout-Room-Meetings/ — specialized topic discussionsNetwork-Upgrade-Archive/ — historical upgrade coordinationSchedule: Alternating weeks — one week CL focus, next week EL focus.
How to fetch meeting notes:
https://raw.githubusercontent.com/ethereum/pm/master/AllCoreDevs-CL-Meetings/call_{number}.md
https://raw.githubusercontent.com/ethereum/pm/master/AllCoreDevs-EL-Meetings/Meeting_{number}.md
Comprehensive tracker for all Ethereum protocol development calls. JS-rendered SPA — requires Playwright MCP for full access, but URL patterns are predictable.
Call series tracked:
Per-call detail includes:
Also tracks network events: Pectra/Fusaka devnet launches, testnet activations, mainnet upgrades, blob parameter changes (BPO1/BPO2).
URL patterns:
https://forkcast.org/calls — full call list + calendar
https://forkcast.org/calls/acdc/{number} — specific ACDC call
https://forkcast.org/calls/acde/{number} — specific ACDE call
https://forkcast.org/calls/acdt/{number} — specific ACDT call
https://forkcast.org/calls/{breakout}/{number} — specific breakout call (focil, epbs, bal, etc.)
How to use: Navigate with Playwright MCP to get transcripts and summaries. For the call list, the page loads without JS issues. Individual call pages need a brief wait for transcript data to load.
When to use: When someone asks what was discussed or decided in a specific ACD call, or wants to find the most recent call for a topic. Prefer forkcast over raw pm meeting notes — it has richer content (transcripts, summaries, YouTube links).
Machine-readable archive of all discussions in the Eth R&D Discord server. Updated weekly.
Format: JSON files per day per channel: {channel}/YYYY-MM-DD.json
Each message contains: author, category, content, timestamp, attachments.
115+ channels including:
consensus-dev, execution-dev — core client developmentevm, pos-consensus — specific protocol areascryptography, formal-methods, post-quantum — researchnetworking, el-networking — p2p layerpectra-upgrade, fusaka-upgrade — upgrade coordinationbeacon-network, portal-network — network protocolsaccount-abstraction, light-clients — featuresHow to search for a topic:
https://raw.githubusercontent.com/ethereum/eth-rnd-archive/master/{channel}/YYYY-MM-DD.json
Tip: Start with the most relevant channel. For broad protocol questions try consensus-dev or execution-dev. For specific features, use the dedicated channel.
Discourse forum for protocol research. Accessible via WebFetch.
Key categories:
How to search (use JSON API for reliable results):
WebFetch: https://ethresear.ch/search.json?q={query}
How to read a specific post:
WebFetch: https://ethresear.ch/t/{topic-slug}/{topic-id}.json
Discourse forum focused on EIP/ERC governance and protocol coordination.
Key categories:
How to search (use JSON API for reliable results):
WebFetch: https://ethereum-magicians.org/search.json?q={query}
When to use: For understanding the governance status, community sentiment, or discussion history around a specific EIP.
Comprehensive technical reference book on Ethereum's proof-of-stake transition.
Structure:
Coverage: Up to Capella (edition 0.3, work in progress). Does not cover Deneb+.
How to fetch:
WebFetch: https://eth2book.info/latest/part2/building_blocks/{topic}/
WebFetch: https://eth2book.info/latest/part3/transition/{topic}/
When to use: For thorough explanations of beacon chain fundamentals — validator lifecycle, consensus mechanics, incentive structures. Best for "explain how X works" questions about the core protocol.
Tracks Ethereum's consensus layer redesign — forward-looking research and engineering.
Key workstreams:
Topics: Gossipsub v2.0, attester-proposer separation, Poseidon hash cryptanalysis
Note: This is a JS-rendered SPA — WebFetch may not extract full content. Use WebSearch as fallback for specific lean consensus topics.
The official EF Protocol draft roadmap for Ethereum L1, maintained by the EF Architecture team (Ansgar, Barnabé, Francesco, Justin Drake). A living document updated at least quarterly.
Format: Google Drawings diagram embedded via iframe. Requires Google sign-in to view. Not machine-readable via WebFetch — use the sidebar FAQ and info below as reference.
URL:
https://strawmap.org/
Google Drawings source (requires auth):
https://docs.google.com/drawings/d/1GkcGfQv9kxgrYQMyu0BYGcZya0gIDG_wQ7GsFJEsdzY/edit?usp=sharing
Structure: The diagram is a timeline of forks progressing left to right, organized into three color-coded horizontal layers:
Dark boxes denote headliners, grey boxes indicate offchain upgrades, black boxes represent north stars. Arrows signal hard technical dependencies or natural fork progressions.
Fork naming: CL forks follow a star-based scheme with incrementing first letters: Altair, Bellatrix, Capella, Deneb, Electra, Fulu, Glamsterdam, Hegotá, I*, J* (I*/J* are placeholders, I* pronounced "I star").
Time horizon: ~7 forks through end of decade (~one fork every 6 months). Well beyond ACD's typical next-two-forks focus.
Five north stars (long-term goals):
Headliners: Each fork typically has one CL and one EL headliner (e.g. Glamsterdam: ePBS + BALs).
Contact: strawmap@ethereum.org or the maintainers on X (@adietrichs, @barnabemonnot, @fradamt, @drakefjustin).
When to use: When someone asks about the overall Ethereum roadmap, which features are planned for which forks, north star goals, or the multi-year direction of L1 development. Direct the user to strawmap.org since the diagram requires Google auth.
grep/cat on cloned repos (see "Local Clone Strategy" at the top). Fall back to raw GitHub URLs only if repos aren't cloned.grep -r "term" ~/ethereum-repos/consensus-specs/specs/ finds all references instantly, much faster than fetching individual files