Do not use emojis in any content. This applies to:
- Documentation (MDX, Markdown)
- Card titles and descriptions on the home page
- Scripts, README, and all project files
Use plain text only. Replace emoji emphasis with clear wording.
The berachain-docs directory is a git submodule containing the official Berachain documentation repository from https://github.com/berachain/docs. This submodule serves as the primary reference for creating new documentation.
The berachain-docs submodule contains:
apps/core/- Main Berachain documentation (docs.berachain.com)apps/bex/- BEX (Berachain Exchange) documentation (docs.bex.berachain.com)apps/bend/- Bend (lending protocol) documentation (docs.bend.berachain.com)packages/ui/- Shared Vue componentspackages/config/- Shared configuration constants
When creating new documentation, refer to the following files in berachain-docs/:
-
Style Guide:
berachain-docs/STYLE_GUIDE.md- Markdown formatting conventions
- Frontmatter structure
- Code block formatting
- Callout usage (tips, warnings, dangers)
- Heading hierarchy
- Link conventions
-
Contributing Guide:
berachain-docs/CONTRIBUTING.md- Development workflow
- Component creation guidelines
- Constants management
- Versioning practices
-
Example Documentation: Reference actual documentation files in:
berachain-docs/apps/core/content/- Core Berachain docsberachain-docs/apps/bex/content/- BEX docsberachain-docs/apps/bend/content/- Bend docs
- Use YAML frontmatter with meta tags for SEO
- Follow sentence case for headings
- Use proper heading hierarchy (H1 for page title, H2 for major sections, etc.)
- Include code examples with appropriate language tags
- Use callouts (:::tip, :::warning, :::danger) for important information
- Prefix shell commands with context:
# FROM: ./directory - Show expected output with comments:
# [Expected Output]: - Use proper language tags for code blocks
- Include placeholders for user-specific values (e.g.,
YOUR_VALIDATOR_ADDRESS)
- Structure endpoints with clear headings and HTML IDs for deep linking
- Include HTTP method, path, parameters, and responses
- Provide example requests and responses
- Document error cases
This project uses Mintlify for documentation (not VitePress like the submodule). Key differences:
- Navigation is defined in
docs.json(notsidebar.ts) - Files use
.mdxextension (not.md) - Mintlify has its own component system and conventions
- Reference the submodule: Check
berachain-docs/for similar content or examples - Follow style guide: Adhere to conventions in
berachain-docs/STYLE_GUIDE.md - Adapt to Mintlify: Convert VitePress-specific syntax to Mintlify equivalents
- Maintain consistency: Match the tone, structure, and formatting of existing docs
- Use examples: Reference actual documentation files in the submodule as templates
- Submodule root:
berachain-docs/ - Core docs content:
berachain-docs/apps/core/content/ - BEX docs content:
berachain-docs/apps/bex/content/ - Bend docs content:
berachain-docs/apps/bend/content/ - Style guide:
berachain-docs/STYLE_GUIDE.md - Contributing guide:
berachain-docs/CONTRIBUTING.md - Constants config:
berachain-docs/packages/config/constants.json
- Always check the submodule first for existing documentation on a topic
- Use the style guide as the authoritative source for formatting
- When adapting VitePress docs to Mintlify, preserve the content structure and adapt the syntax
- Maintain consistency with existing documentation in this repository
- Reference specific files in the submodule when asking for help or examples
- When a live documentation URL would otherwise begin returning
404, add a redirect indocs.json. - If a page is moved, redirect the old URL to the new canonical location.
- If a page is removed without a direct replacement, choose the closest substitute page and get maintainer approval before adding the redirect destination.
- Do not leave a previously live documentation URL to 404 without explicit maintainer agreement.
- After changing redirects, run
make check-redirectsagainst a running docs server when practical.
When editing this page (execution client versions and network genesis downloads):
If the intent is to bump the recommended Beacon Kit and/or Bera-Reth version numbers, you can read candidate tags from GitHub releases/latest (still choose the pairing you intend to document; it may lag latest on purpose):
# Candidate: latest Beacon Kit release tag
BEACON_KIT_TAG=$(curl -s https://api.github.com/repos/berachain/beacon-kit/releases/latest | jq -r .tag_name)
# Candidate: latest Bera-Reth release tag
BERA_RETH_TAG=$(curl -s https://api.github.com/repos/berachain/bera-reth/releases/latest | jq -r .tag_name)After any bump, apply rules 1–3 for the tags actually written on the page.
-
Raw genesis URLs must use the same Beacon Kit git tag as the release linked in the page copy (for example, page cites v1.3.9 →
https://raw.githubusercontent.com/berachain/beacon-kit/v1.3.9/testing/networks/<chainId>/eth-genesis.json). Do not userefs/heads/mainor a moving release branch for these downloads: operators need the exact tree that shipped with that Beacon Kit version. -
MD5 values in the table must match the exact bytes returned by the linked raw URL. After any URL or tag change, re-verify (for example
curl -fsSL '<url>' | md5). -
Coherence: Keep the Beacon Kit release tag link, the Bera-Reth version row, and the tag embedded in genesis URLs aligned. When bumping Beacon Kit, update the tag in all genesis URLs, update Bera-Reth if required, recompute MD5s, and adjust the “Updated” column when the artifact at that URL meaningfully changes for operators.