docs: add foundation delegation page and redirect for it#2336
docs: add foundation delegation page and redirect for it#2336jcstein merged 3 commits intodocs-glow-upfrom
Conversation
Summary of ChangesHello @jcstein, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request represents a substantial upgrade to the documentation infrastructure, transitioning from VitePress to Nextra to provide a more modern, interactive, and maintainable platform. The changes encompass a complete restructuring of content, the introduction of dynamic API documentation with an interactive playground, and the addition of new, critical information regarding private blockspace. This migration aims to improve the overall user experience and streamline future documentation efforts, ensuring that users can quickly find and interact with the information they need. Highlights
Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new documentation page for the Celestia Foundation Delegation Program, enhancing the project's documentation. It includes updates to the navigation metadata, adds a necessary redirect for the new page, and correctly resolves a hardcoded localhost URL in the main landing page, which is a significant improvement for production readiness. The new documentation page is comprehensive, but some minor clarifications and structural improvements could enhance readability and precision.
| </Link> | ||
|
|
||
| <Link href="http://localhost:4269/operate/getting-started/overview/" style={{ | ||
| <Link href="/operate/getting-started/overview/" style={{ |
There was a problem hiding this comment.
Excellent catch! Removing the hardcoded http://localhost:4269 URL is critical for ensuring the link functions correctly in production environments. Hardcoding local development URLs can lead to broken links and a poor user experience once deployed.
| @@ -1,19 +1,17 @@ | |||
| const meta = { | |||
| index: 'Home', | |||
| index: "Home", | |||
There was a problem hiding this comment.
While changing single quotes to double quotes is a stylistic preference, it's good to maintain consistency across the codebase. If there's a project-wide style guide for JavaScript, it's best to adhere to it. Otherwise, pick one and stick with it.
| title: "Operate", | ||
| type: "page", | ||
| }, | ||
| }; |
There was a problem hiding this comment.
Adding a semicolon here improves consistency with the rest of the file and common JavaScript practices. It's a good stylistic improvement.
| | Cohort | Cohort Size | Delegation Duration | Renewal By Cohort | | ||
| | -------- | ----------- | ------------------- | ----------------- | | ||
| | Cohort 5 | 15 | 12 months | Cohort 8 | | ||
| | Cohort 6 | 15 | 12 months | Cohort 9 | | ||
| | Cohort 7 | 20 | 12 months | Cohort 10 | |
There was a problem hiding this comment.
The table currently lists Cohort 5, 6, and 7. However, the 'Cohort information' section later in the document lists Cohort 1 through 6 with specific application dates. This might cause confusion regarding which cohorts are active or relevant. Consider either making this table more generic (e.g., 'Example Cohort Structure') or aligning it with the full list provided later, perhaps by showing the current or upcoming cohorts.
|
|
||
| The minimum requirements for participation in the program are as follows: | ||
|
|
||
| - Run an active Mainnet Beta validator **or** an active Mocha testnet validator for **at least 1 month before application deadline** |
There was a problem hiding this comment.
The phrasing "at least 1 month before application deadline" could be slightly clearer. Consider rephrasing to "at least one month prior to the application deadline" for improved precision.
- Run an active Mainnet Beta validator **or** an active Mocha testnet validator for **at least 1 month before application deadline"
+ Run an active Mainnet Beta validator **or** an active Mocha testnet validator for **at least one month prior to the application deadline"
| - Run an active Mainnet Beta validator **or** an active Mocha testnet validator for **at least 1 month before application deadline** | ||
| - Run an archival bridge node (on Mainnet Beta if you are already an active Mainnet Beta validator or on Mocha testnet if not) that is connected and reporting to the Celestia Labs [OTEL collector](/how-to-guides/celestia-node-metrics.md) (for new applicants - on testnet, so that we can evaluate performance) | ||
| - Not jailed more than once in the 6 months before application deadline | ||
| - If jailed more than once in the 6 months period before application deadline, then we require a public forum post with detailed post mortem and we consider case by case |
There was a problem hiding this comment.
This sentence is a bit long and could be rephrased for better clarity and formality. "we consider case by case" is somewhat informal for documentation. Consider something like: "If jailed more than once in the 6-month period prior to the application deadline, a public forum post with a detailed post-mortem is required, and applications will be reviewed on a case-by-case basis."
- If jailed more than once in the 6 months period before application deadline, then we require a public forum post with detailed post mortem and we consider case by case
+ If jailed more than once in the 6-month period prior to the application deadline, a public forum post with a detailed post-mortem is required, and applications will be reviewed on a case-by-case basis.
| - Not based within the US, within any country subject to economic sanctions, or within any other prohibited jurisdiction, and successfully complete a compliance screen | ||
| - Dedicated email address so that the Foundation can reach you in the event of emergency upgrades and fixes | ||
| - Maintain a fully archival (non-pruned) bridge node for both Mainnet Beta and Mocha if selected for the program | ||
| - Not running your infrastructure in Hetzner or OVH |
There was a problem hiding this comment.
The restriction "Not running your infrastructure in Hetzner or OVH" is very specific. It would be beneficial for transparency and user understanding to briefly explain the rationale behind this restriction, or link to a document that provides this explanation.
| - Getting slashed/tombstoned (cannot apply for 1 year afterwards) | ||
| - Getting jailed more than once during the cohort’s applicable delegation period | ||
| - Violating the [Celestia.org Community Code of Conduct](/community/coc.md) or engaging in harmful activities towards the network | ||
| - Failing to upgrade your node in a timely manner (24 hours or less) |
There was a problem hiding this comment.
The phrase "24 hours or less" can be more concisely and commonly expressed as "within 24 hours".
- Failing to upgrade your node in a timely manner (24 hours or less)
+ Failing to upgrade your node in a timely manner (within 24 hours)
| - Infrastructure | ||
| - Validator address and bridge node ID on Mainnet Beta | ||
| - If you don't run an active Mainnet Beta validator, please provide us with validator address, bridge node ID on Mocha-4 | ||
| - Have you been slashed or jailed in the last 6 months on Celestia or other chains you validated on. |
There was a problem hiding this comment.
This item is phrased as a question, "Have you been slashed or jailed...", but it's part of a list of information applicants should be ready to share. It would be more consistent to rephrase it as a data point to provide, for example: "History of slashing or jailing in the last 6 months on Celestia or other chains validated on."
- Have you been slashed or jailed in the last 6 months on Celestia or other chains you validated on.
+ History of slashing or jailing in the last 6 months on Celestia or other chains validated on.
| - [Cohort 5](https://docs.google.com/spreadsheets/d/1Fxu9uYJ4wxfHChEiSg5bmXAMU8IZSq7J3GYDCFgk1HA/edit?gid=1471991269#gid=1471991269): 15 Validator Seats (Applications open June 1, 2025) | ||
| - [Cohort 6](https://docs.google.com/spreadsheets/d/1Fxu9uYJ4wxfHChEiSg5bmXAMU8IZSq7J3GYDCFgk1HA/edit?gid=1010270944): 15 Validator Seats (Applications open October 1, 2025) | ||
|
|
||
| IMPORTANT: Each validator selected for the program has to maintain a fully archival (non pruned) bridge node for both Mainnet Beta and Mocha. |
There was a problem hiding this comment.
The requirement to "maintain a fully archival (non pruned) bridge node for both Mainnet Beta and Mocha" is also stated in the Eligibility criteria (line 60). While emphasizing important points is good, consider if this repetition is necessary or if it could be rephrased to reference the earlier section, to avoid redundancy.
2 participants
Overview