[MegaRedHand]

Motivation

The project's self-descriptions still called ethlambda a Lean consensus client only, and CLAUDE.md said it was "not to be confused with" a Beacon Chain client. Since ethlambda beacon follows the Beacon Chain, those statements are wrong.

Changes

Every place that describes what ethlambda is now says "Beacon Chain and Lean Chain client":

File	What changed
README.md	Tagline; "Current status" now names both chains (beacon side points at the follower quickstart) and scopes the existing bullet list to the Lean Chain
book.toml, docs/introduction.md	Book description and intro. The intro also gains the Beacon Chain part that SUMMARY.md already lists ("four parts" was five)
CONTRIBUTING.md, Dockerfile (image label), .github/prompts/ai-review.md	One-line descriptions
CLAUDE.md	Replaces "not to be confused with Beacon Chain clients" with the two sub-commands
docs/infographics/*.html	Subtitle and footer only
docs/lmd_ghost.md	The comparison table and paragraphs credited "ethlambda" with having no proposer boost or equivocation discounting; that is only true of the Lean Chain, since the beacon fork choice implements both. Scoped to the Lean Chain

Pages that spoke of "ethlambda" or "the node" while meaning the Lean Chain alone now say so. The Lean content itself is unchanged:

File	What changed
docs/3sf_mini.md, docs/lmd_ghost.md, docs/slots_and_intervals.md	The "In ethlambda" notes become "In ethlambda's Lean Chain" (one said every validator has equal weight, which beacon does not do). The 3SF-mini and LMD-GHOST intros name ethlambda node, and LMD-GHOST points at the beacon fork choice
docs/architecture.md	A scope note: the page describes ethlambda node; ethlambda beacon runs the same two actors without keys, aggregation or duties
docs/benchmarking.md	synthetic is Lean Chain block building, import is Beacon Chain block import
docs/metrics.md	leanMetrics applies to the Lean Chain; points at where the beacon metrics are
docs/fork_choice_visualization.md	Served by ethlambda node only (/lean/v0 is a 404 on beacon)
docs/introduction.md	Spec deviations cover consensus-specs too
README.md	The node section no longer claims the rest of the README is about it

Left as is, since they already describe the Lean side specifically: docs/cli.md, docs/checkpoint_sync.md, docs/beacon_stf.md, the README's per-sub-command headers, .claude/skills/*, and code comments.

Open questions

• CONTRIBUTING.md still says "Lean Consensus is a clean slate. Don't add backward compatibility for deprecated features." The beacon side carries phase0 through gloas by necessity. Should that bullet be scoped to the Lean Chain?
• The architecture infographic's body is all Lean (3SF-mini badge, lean actors); only its subtitle changed here.
• The README roadmap still lists execution client integration as future work.

[github-actions]

🤖 Kimi Code Review

I'll review this PR diff focusing on the changes made. This appears to be primarily a documentation update to clarify that ethlambda supports both Beacon Chain and Lean Chain modes.

Overall Assessment

This is a documentation-only PR that updates project descriptions across multiple files to reflect that ethlambda is now a dual-mode client (Beacon Chain follower + Lean Chain consensus). No Rust code changes are present, so consensus-layer security and correctness concerns don't apply here.

Review Findings

1. Consistency Check — README.md line 316-321

The updated "Current status" section has a structural issue:

ethlambda is a Beacon Chain and Lean Chain client. On the Beacon Chain
(`ethlambda beacon`), it follows a network from a checkpoint-synced anchor and serves
the standard Beacon API; see the [Beacon Chain follower](#beacon-chain-follower)
quickstart. On the Lean Chain (`ethlambda node`), it implements the core features of a
Lean consensus client:

Issue: The [Beacon Chain follower](#beacon-chain-follower) anchor link may be broken. Looking at the diff, there's no corresponding anchor added in this PR. Verify that:

• Either this anchor already exists in README.md
• Or this link will 404 when rendered

Suggestion: Check if ### Beacon Chain follower or similar heading exists in README.md. If not, add it or change to a working anchor.

---

2. Grammar/Clarity — docs/introduction.md line 7-8

**ethlambda** is a minimalist, fast and modular implementation of a Beacon Chain and
Lean Chain client, written in Rust.

Minor: "a Beacon Chain and Lean Chain client" is slightly awkward. Consider: "of a dual-mode Beacon Chain and Lean Chain client" or "of both a Beacon Chain follower and Lean Chain client".

---

3. HTML Infographic Consistency — docs/infographics/3sf-mini-infographic.html line 735

The footer change is fine, but verify that this HTML file's title tag (if present) or meta description wasn't missed. The diff doesn't show <title> changes — check if line ~10 has a hardcoded "Lean Ethereum consensus client" string.

---

4. docs/introduction.md line 10 — Section count update

It is split into five parts:

Verification needed: The bulleted list below shows:

• Design
• Consensus
• Beacon Chain (new)
• Operations
• Appendix

That's 5 parts. ✅ Correct count.

---

5. docs/lmd_ghost.md lines 684-714 — Fork choice comparison table

The table update is accurate and the added clarifications about ethlambda beacon vs ethlambda node are helpful. However:

Potential confusion: Line 687-689 states:

"its Beacon Chain follower (ethlambda beacon) runs the Beacon Chain's own fork choice, proposer boost and equivocation discounting included"

This implies the Beacon Chain mode uses standard Lighthouse/Nimbus-style LMD-GHOST rather than ethlambda's simplified version. If true, this is an important architectural distinction that should be reflected in code documentation elsewhere. No issue in this PR, but flag for verification in implementation.

---

6. book.toml line 6 — Description length

description = "Minimalist, fast and modular implementation of a Beacon Chain and Lean Chain client written in Rust"

This is 114 characters. mdBook doesn't strictly limit this, but some social previews may truncate. Acceptable.

---

Missing Updates (Potential Oversights)

Check these files not in diff for stale descriptions:

File	Likely stale text	Action needed?
Cargo.toml	description field	Should match — verify separately
crates/*/Cargo.toml	Workspace member descriptions	Verify separately
docs/index.html or generated files	May be rebuilt from book.toml	Likely auto-generated
LICENSE or AUTHORS	Usually no project description	N/A

---

Positive Acknowledgments

1. Clear mode distinction: The ethlambda beacon vs ethlambda node naming convention is consistently applied.
2. Accurate technical distinctions: The lmd_ghost.md table correctly preserves that Lean Chain lacks proposer boost, balance weighting, and equivocation discounting.
3. No code drift: This is purely documentation — no risk of consensus bugs from description changes.

---

Summary

Severity	Count	Items
🔴 Critical	0	—
🟡 Moderate	1	Verify README.md anchor link #beacon-chain-follower exists
🟢 Minor	1	Consider grammar polish in introduction.md
ℹ️ Info	1	Check Cargo.toml description consistency outside this PR

Recommendation: Approve after verifying the README.md internal anchor link resolves correctly.

---

Automated review by Kimi (Moonshot AI) · kimi-k2.6 · custom prompt

[github-actions]

🤖 Claude Code Review

Review of PR 715: describe ethlambda as a Beacon Chain and Lean Chain client

This is a docs-only change and I found no correctness or security issues. I read the diff only and did not build the book or check links.

Points worth a look:

1. docs/introduction.md: the new Beacon Chain bullet is a good fix, since SUMMARY.md already lists that part. Please check the three link targets exist and match SUMMARY.md: beacon_stf.md, beacon_wire.md and beacon_engine.md.
2. README.md: the new "Current status" text links to #beacon-chain-follower. Please confirm that heading exists exactly, because GitHub anchors are generated from the heading text.
3. docs/lmd_ghost.md: scoping the comparison to the Lean Chain is accurate and the column header change is right. Two small leftovers:
   • The table separator row (|--------|-----------|---...) is now misaligned with the shorter "Lean Chain" header. Markdown renders it fine, but it is untidy.
   • The "Key Files" section and the rest of the doc may still say "ethlambda" for lean-only behaviour. A quick grep would settle this.
4. CONTRIBUTING.md: the PR description raises the "Lean Consensus is a clean slate. Don't add backward compatibility for deprecated features" bullet. I'd scope it to the Lean Chain in this PR. The beacon side carries phase0 through gloas, so the bullet now contradicts the new tagline and could mislead contributors and the AI reviewer.
5. .github/prompts/ai-review.md: the prompt still lists only lean consensus considerations (3SF-mini, XMSS). Beacon-side reviews would benefit from adding beacon items, such as spec-fixture conformance and the SSZ progressive containers. This is optional and can be a follow-up.
6. docs/infographics/ethlambda_architecture.html: the subtitle now claims both chains but the body is all Lean. That is fine as an interim step, but a follow-up issue would stop the infographic from overpromising.

Overall the wording is consistent across files and the lean/beacon distinctions are accurate. Items 1 and 2 are the only ones that could cause a visible break, so I'd verify those before merging.

---

Automated review by Claude (Anthropic) · sonnet · custom prompt

[github-actions]

🤖 Codex Code Review

Looks good overall — this PR appears to be documentation/branding only, with no Rust or consensus logic changes in the diff, so I don’t see any direct correctness, security, performance, or memory-safety risk from the code itself.

Findings

• No code changes detected in the PR diff; all touched files are docs/metadata (README.md, docs/*, Dockerfile, contributor docs). That means no impact to fork choice, attestation processing, state transition, XMSS, or SSZ behavior in this PR.
• README.md:319 clearly distinguishes ethlambda beacon from ethlambda node, which is a helpful clarification and reduces operator confusion.
• docs/introduction.md:11 updates the docs structure from four to five parts, and the bullets below do match five sections. No inconsistency there.
• docs/lmd_ghost.md:687 is a meaningful clarification: it explicitly scopes the described simplifications to the Lean Chain and states that ethlambda beacon uses Beacon Chain fork choice features like proposer boost and equivocation discounting. That improves correctness of the documentation.

Minor suggestion

• README.md:7 says “implementation of a Beacon Chain and Lean Chain client”. Since the project is one binary with two modes, wording like “implementation of Beacon Chain and Lean Chain clients” or “a client for the Beacon Chain and Lean Chain” may read a bit more naturally. This is stylistic only.

No blocking issues from a code review perspective.

---

Automated review by OpenAI Codex · gpt-5.4 · custom prompt