| Phase | Dates | Notes |
| Applications Open | May 14 – Mai 28 | Anyone can apply during this period |
| Review & Approval | Mai 29 - June 11 | Committee reviews proposals and approves based on milestone scope. Publish recap of selected proposals and next steps |
| Pause & Monitoring | June 12 - July 9 | Publish recap of selected proposals and next steps |
All of Mellow DVV TVL
+ Lido SDVT Module validators added post Jan 13th Airdrop
+ Lido CSM TVL ran by Obol DVs
- Mellow Depositors: 80% for CSM TVL, 90% for SDVT TVL
- Rest to Node Operators
| Phase | Dates | Notes |
| Applications Open | May 14 – June 11 | Anyone can apply during this period |
| Review & Approval | June 12 - June 25 | Committee reviews proposals and approves based on milestone scope. Publish recap of selected proposals and next steps |
| Pause & Monitoring | June 26 - July 23 | Publish recap of selected proposals and next steps |
+
+
+
+Governor Contract
+ +* **Address:** [`0xcB1622185A0c62A80494bEde05Ba95ef29Fbf85c`](https://etherscan.io/address/0xcB1622185A0c62A80494bEde05Ba95ef29Fbf85c) + +- **Purpose:** Manages onchain proposal lifecycle and voting logic for Token House governance. + +* **What you can find onchain:** + * Voting thresholds + * Quorum settings, + * Delay/period configs, + * Proposal and vote history. + +
+
+
+
+Obol Staker
+ +* **Address:** [`0x30641013934ec7625c9e73a4D63aab4201004259`](https://etherscan.io/address/0x30641013934ec7625c9e73a4D63aab4201004259) + +- **Purpose:** This is the base layer of the Obol staking system. It facilitates the basic mechanics of staking, such as managing deposits, forwarding governance delegation, and streaming rewards based on earning power. + +* **What you can find onchain:** + * Total OBOL staked in the contract + * Stake, earning power, rewards and balances on a granular, per-deposit basis + * Current reward rate and configuration + * Contract events (e.g. `Staked`, `Withdrawn`) + * Interactions for staking/unstaking + +
+
+
+
+stOBOL (ERC-20 Token Contract)
+ +* **Address:** [`0x6590cBBCCbE6B83eF3774Ef1904D86A7B02c2fCC`](https://etherscan.io/address/0x6590cBBCCbE6B83eF3774Ef1904D86A7B02c2fCC) + +- **Purpose:** A liquid ERC-20 representation of staked OBOL built on top of the Obol Staker. It adds features like transferability, reward auto compounding, and the ability to use a staked OBOL position in other protocols. Holders retain the ability to delegate their staked tokens to the governance delagate of their choice. + +* **What you can find onchain:** + * ERC-20 metadata (name, symbol, decimals) + * Total supply and balances + * Transfer history + * Allowances / approvals + * Voting power interface (via `getVotes` and `delegates`) + * Event logs for delegation changes + +
+
+
+
+Reward Notifier
+ +* **Address:** [`0x384dd81047F88eE35DE75DA1149943B8e62d8802`](https://etherscan.io/address/0x384dd81047F88eE35DE75DA1149943B8e62d8802) + +- **Purpose:** Manages the distribution of tokens to the staking contract so they can be streamed as rewards to stakers. + +* **What you can find onchain:** + * Current and past reward rate values + * Administrative role settings (who can push updates) + * Timing/config changes made through proposals + * Events like `RewardRateUpdated` + +
+
+
+
+## Learn more about...
+
+[token-utility.md](token-utility.md)
+[staking-and-stobol.md](staking-and-stobol.md)
+[token-distribution-and-liquidity.md](token-distribution-and-liquidity.md)
+[token-holders-faq.md](token-holders-faq.md)
+[tge-faq.md](tge-faq.md)
diff --git a/versioned_docs/version-v1.4/community-and-governance/obol-token/staking-and-stobol.md b/versioned_docs/version-v1.4/community-and-governance/obol-token/staking-and-stobol.md
new file mode 100644
index 0000000000..583b15ff6f
--- /dev/null
+++ b/versioned_docs/version-v1.4/community-and-governance/obol-token/staking-and-stobol.md
@@ -0,0 +1,81 @@
+---
+description: "This page explains how OBOL staking works, the role of stOBOL, and what happens when tokens are delegated, transferred, or used in DeFi protocols. You can stake and unstake OBOL via stake.obol.org."
+sidebar_label: "Staking & stOBOL"
+slug: /community-and-governance/obol-token/staking-and-stobol
+---
+
+# Staking & stOBOL
+
+## Overview
+
+Staking allows OBOL token holders to participate in governance while earning rewards. When you stake OBOL, you receive a liquid staking token called stOBOL. This token is transferable, composable in DeFi, and earns staking rewards while maintaining governance power, as long as it remains in the same address that originally staked the OBOL Tokens. It represents a flexible and powerful tool to both support the network and engage in the broader ecosystem.
+
+stOBOL unlocks new opportunities for participation. It is yield-bearing, enables seamless governance engagement, and is expected to be increasingly integrated across DeFi platforms. If it is transferred elsewhere, direct delegation is removed and governance power is reassigned using a protective fallback strategy, preventing governance attacks.
+
+### To Recap
+
+* stOBOL is a liquid staking token received when you stake OBOL.
+* It allows users to earn staking rewards which auto-compound while retaining governance power.
+* stOBOL is fully transferable (ERC-20) and can be used in DeFi (e.g., as collateral).
+
+## Key Concepts
+
+| **Feature** | **OBOL** | **stOBOL** |
+| ------------------------- | ------------------------------------- | -------------------------------------------------------------------------------------------------------- |
+| **Governance voting** | ✅ (direct or delegated) | ✅ (only if kept on original staking address, otherwise governance power reallocated to default strategy) |
+| **Transferable** | ✅ | ✅ |
+| **Used in DeFi** | ✅ (less efficient, not yield-bearing) | ✅ (yield-bearing) |
+| **Earns staking rewards** | ❌ | ✅ |
+
+## Delegation & Governance
+
+Governance power is fundamentally tied to the OBOL Token. When OBOL is staked, the governance power does not transfer to stOBOL itself but remains associated with the underlying staked OBOL. stOBOL serves as a representation of that staked position, surfacing its governance power **only while being held in the same address** that originally staked the OBOL.
+
+If stOBOL is transferred to another address or smart contract, governance power is not automatically preserved. Instead:
+
+* By default, the governance power is reassigned to the **Overwhelming Support** auto-delegate strategy.
+* However, the receiving address or smart contract **can explicitly delegate** the voting power of its stOBOL to a delegate of choice, if such functionality is supported.
+
+This design ensures that governance power follows clear, transparent rules:
+
+* **No double-counting**: the OBOL held in the staking contract is not counted separately from the stOBOL in circulation.
+* **No governance arbitrage**: someone cannot gain voting rights simply by borrowing or acquiring stOBOL without also controlling the original staking delegation.
+
+If stOBOL is used in DeFi protocols (e.g., as collateral on Morpho), governance power defaults to the Overwhelming Support strategy unless the protocol itself implements explicit delegation support for pooled stOBOL assets.
+
+## How the Overwhelming Support Strategy Works
+
+When a liquid staking token (like stOBOL) is transferred, any previous delegation is removed. To prevent this from harming quorum or enabling governance attacks, the system can route that voting power through an automatic fallback strategy. The first strategy implemented is called the "Overwhelming Support" strategy. This fallback strategy only casts votes using its accrued governance power **in favor** of a proposal when all the following conditions are met:
+
+* **Sub-quorum reached:** At least 66% of the quorum is already met by FOR votes (`subQuorumBips = 66%`).
+* **High support threshold:** At least 90% of votes cast so far are FOR votes (`supportThreshold = 90%`).
+* **Within final voting window:** The proposal is within \~2.5 days of its deadline (`votingWindow = 14400` blocks).
+
+If all three criteria are met, the strategy casts its voting power FOR the proposal. If not, it abstains.
+
+This ensures that fallback voting power (from transferred stOBOL) is only used to support proposals that already have overwhelming community backing. It avoids influencing contentious or split decisions, protecting governance neutrality and reducing capture risk.
+
+This model preserves network governance while allowing for stOBOL to flow through DeFi protocols.
+
+Other strategies can be proposed via governance.
+
+## Summary Flow
+
+1. OBOL is staked and stOBOL is minted to the staker’s address.
+2. While stOBOL remains with the same address, governance power is retained and delegated as usual.
+3. If stOBOL is transferred, governance power is removed and reassigned via the "Overwhelming Support" strategy. Other strategies can be proposed via governance.
+
+
+
+## Additional Notes
+
+* You can stake and unstake OBOL via [stake.obol.org](https://vote.obol.org/stake).
+* Voting and delegation are managed at [vote.obol.org](https://vote.obol.org/).
+
+As the protocol evolves, new strategies or staking configurations may be introduced through DAO governance. Feedback from the community helps inform these decisions.
+
+Have questions? Join our [Discord](https://discord.gg/n6ebKsX46w) or visit the [Governance Forum](https://community.obol.org).
+
+***
+
+_This page will evolve as more staking strategies and integrations are launched._
diff --git a/versioned_docs/version-v1.4/community-and-governance/obol-token/tge-faq.md b/versioned_docs/version-v1.4/community-and-governance/obol-token/tge-faq.md
new file mode 100644
index 0000000000..dcb25eb8f8
--- /dev/null
+++ b/versioned_docs/version-v1.4/community-and-governance/obol-token/tge-faq.md
@@ -0,0 +1,137 @@
+---
+sidebar_label: "TGE FAQ"
+slug: /community-and-governance/obol-token/tge-faq
+---
+
+# TGE FAQ
+
+## Unlock and Listing
+
+Auto Delegate (Overwhelming Support Strategy)
+ +* **Address:** [`0xCa28852B6Fc15EbD95b17c875D5Eb14b08579158`](https://etherscan.io/address/0xCa28852B6Fc15EbD95b17c875D5Eb14b08579158) + +- **Purpose:** Implements the “Overwhelming Support” auto-delegation strategy. This contract casts votes on behalf of un-delegated or transferred stOBOL when proposals receive strong community support. This mechanism uses tokens that would otherwise not be available in governance to ensure uncontroversial proposals will meet quorum. + +* **What you can find onchain:** + * Parameters like `supportThreshold`, `subQuorumBips`, and `votingWindow` + * Proposals voted on by the strategy + * Vote power amounts cast + * Event logs showing execution activity + * Wallets or protocols interacting with auto-delegation logic + +
+
+
+
+How do I unlock my OBOL Tokens received in the Airdrop?
+ +Starting May 7th at 11:00 AM UTC, visit [**claim.obol.org**](https://claim.obol.org), click **“Unlock”**, and follow the steps. + +
+
+
+
+When is the official TGE date and time?
+ +The OBOL Token will be listed on exchanges for deposit, trading and withdrawals on May 7th, 2025 at 11:00 AM UTC + +
+
+
+
+Where will the OBOL Token be listed for trading?
+ +* **Binance**, **Bybit**, **Bitget**, **Gate.io**, **MEXC**, and others. + +- Check [CoinGecko](https://coingecko.com) or [CoinMarketCap](https://coinmarketcap.com/currencies/obol/) for the most up-to-date list. + +
+
+
+
+What are the exact listing times on exchanges?
+ +* **Binance Alpha** – _May 7 at 10:00 AM UTC_ + +- **Binance Futures** – _May 7 at 10:30 AM UTC_ + +* **Bybit, Gate.io, Bitget, MEXC** – _May 7 at 11:00 AM UTC_ + +
+
+
+
+Where can I track the price of the OBOL Token?
+ +[CoinGecko](https://coingecko.com) and [CoinMarketCap](https://coinmarketcap.com/currencies/obol/) + +
+
+
+
+Where can I buy the OBOL Token onchain?
+ +* A **Uniswap v3 pool** will be seeded with initial liquidity. + +- The contract address is [here](https://etherscan.io/address/0x57F52C9faa6D40c5163D76b8D7dD81ddB7c95434). + +* Anyone can start a pool. Check live prices via **CoinGecko**, or **CoinMarketCap**. + +
+
+
+
+## **Token Supply & Distribution**
+
+Are there any country restrictions for claiming or trading the OBOL Token?
+ +* Yes. Each venue has its own restrictions. + +- Unlocking OBOL Tokens received through the Airdrop is subject to the same geo restrictions as claiming. + +
+
+
+
+What is the circulating supply at TGE?
+ +Approximately 19**%**. Full breakdown is on [CoinMarketCap](https://coinmarketcap.com/currencies/obol/). + +
+
+
+
+Why does Etherscan show 374M tokens instead of 500M?
+ +For legal and tax reasons, not all tokens are minted yet. + +
+
+
+
+How many tokens were allocated to CoinList, and how many unlock at TGE?
+ +Details available on the [**Coinlist Sale Page**](https://coinlist.co/obol). + +
+
+
+
+## **Unlocks & Vesting**
+
+When were unclaimed airdrop tokens returned to the treasury?
+ +As approved by [**OIP-2**](https://community.obol.org/t/oip-2-unlock-obol-token/317), they were [returned](https://etherscan.io/tx/0x738b4c252bb4613b9945e3b6426ec4ee510c6cdb86027fe20d533c4799a3a331) on **May 2, 2025**. + +
+
+
+
+Can CoinList participants claim at TGE?
+ +Yes, a portion of their tokens will unlock on May 7th at 11AM UTC per the [**Coinlist terms**](https://coinlist.co/obol). + +
+
+
+
+Will RAF1 tokens be available at TGE?
+ +RAF1 tokens will be distributed **shortly after TGE**. + +
+
+
+
diff --git a/versioned_docs/version-v1.4/community-and-governance/obol-token/token-distribution-and-liquidity.md b/versioned_docs/version-v1.4/community-and-governance/obol-token/token-distribution-and-liquidity.md
new file mode 100644
index 0000000000..649045f286
--- /dev/null
+++ b/versioned_docs/version-v1.4/community-and-governance/obol-token/token-distribution-and-liquidity.md
@@ -0,0 +1,42 @@
+---
+sidebar_label: "Token Distribution & Liquidity"
+slug: /community-and-governance/obol-token/token-distribution-and-liquidity
+---
+
+# Token Distribution & Liquidity
+
+## Token Distribution
+
+The total supply is capped at 500 million tokens. The full supply is not immediately circulating and tokens will unlock over the coming months and years.
+
+
+
+### **Ecosystem Treasury & Retroactive Funding (RAF) | 38.8%**
+
+A significant portion of OBOL Tokens are allocated to the ecosystem treasury to drive innovation and decentralization. These funds support different initiatives, for example, [**SQUAD Goals**](https://community.obol.org/t/oip-3-obol-collective-2025-goals-proposal/)**, Grants & Incentives Funding** contributors who help to the growth of the protocol and the broader Collective and [**Retroactive Funding (RAF)**](https://docs.obol.org/community-and-governance/governance/raf)**,** rewarding contributions that have positively impacted the Obol Collective. Over time, the Obol Association plans to give additional control over these tokens to the community.
+
+### **Investors | 23.7%**
+
+Early investors played a key role in bringing the Obol Collective to life. This allocation ensures that individuals and entities that provided early financial support are fairly rewarded while adhering to best practices in responsible token vesting.
+
+### **Team | 19%**
+
+To attract and retain top-tier talent, a portion of tokens is reserved for core contributors, founders, and developers. This allocation aligns with the long-term vision of the project and is subject to a lock-up period similar to the one of investors.
+
+### **Community Incentives | 7.5%**
+
+To promote awareness and adoption, OBOL tokens will be used for user-focused initiatives that drive adoption of Obol DVs. The first of these initiative is the [Obol Incentives Program.](https://obol.org/incentives)
+
+### **Airdrop | 7.5%**
+
+As a community-first initiative, Obol has rewarded early contributors and supporters through a retroactive airdrop. This ensures ongoing participation in the Collective and strengthens the decentralized operator ecosystem. For more information about the Airdrop distribution, please [see this blog article](https://blog.obol.org/airdrop/).
+
+### **Public Sale via Coinlist | 3.6%**
+
+To ensure broad and fair token distribution, a portion of OBOL Tokens have been made available through a [Coinlist public sale](https://coinlist.co/obol) at better terms than investors. 50% of tokens purchased in the token sale will be fully unlocked and transferable at TGE, followed by a 12 month linear unlock for the remainder of the tokens.
+
+## Token Liquidity
+
+Once the token becomes transferable, the community will be able to track the distribution schedule and observe how the circulating supply increases over time according to the structured unlock plan.
+
+
diff --git a/versioned_docs/version-v1.4/community-and-governance/obol-token/token-holders-faq.md b/versioned_docs/version-v1.4/community-and-governance/obol-token/token-holders-faq.md
new file mode 100644
index 0000000000..430515da8c
--- /dev/null
+++ b/versioned_docs/version-v1.4/community-and-governance/obol-token/token-holders-faq.md
@@ -0,0 +1,135 @@
+---
+description: "This page is designed to answer the most common questions from OBOL token holders, particularly those holding liquid OBOL or stOBOL."
+sidebar_label: "Token Holders FAQ"
+slug: /community-and-governance/obol-token/token-holders-faq
+---
+
+# Token Holders FAQ
+
+## General
+
+When will OBOL Token incentives be claimable?
+ +Starting May 12, 2025, incentives will be distributed weekly + +
+
+
+
+What is the OBOL token used for?
+ +OBOL is the governance token of the Obol Collective. It enables holders to participate in on-chain governance by voting directly or delegating their voting power to delegates. + +OBOL is also used in the [RAF](../governance/raf/), where token holders delegate to vote on which contributors should receive retroactive funding for valuable work. + +In addition, OBOL can be staked to receive stOBOL, a liquid token that accrues staking rewards and retains governance power as long as it remains in the staker’s wallet. This staking mechanism supports long-term alignment and decentralized ownership. + +Finally, both OBOL and stOBOL are being integrated into DeFi protocols, such as liquidity pools, lending platforms (e.g. Morpho), and restaking services (e.g. Eigenlayer, Symbiotic), with more utility expected over time as shaped by community governance. + +
+
+
+
+What is stOBOL?
+ +stOBOL is the liquid staking token received when you stake OBOL. It earns staking rewards and can be used in DeFi. Holding stOBOL in your wallet preserves your governance power. More info in [#staking-and-stobol](staking-and-stobol.md "mention") + +
+
+
+
+## Delegation & Governance
+
+Where can I see OBOL price, supply, and markets?
+ +You can track OBOL on [CoinMarketCap](https://www.coingecko.com/en/coins/obol-2) or [Coingecko](https://coingecko.com). These pages include market data, supply information, and live price charts. + +
+
+
+
+How do I delegate my OBOL tokens?
+ +You can delegate via [vote.obol.org](https://vote.obol.org/dao/delegates). Connect your wallet, choose a delegate, and confirm the delegation transaction. + +
+
+
+
+What happens if I stake OBOL?
+ +You receive stOBOL, which maintains your delegation as long as it stays in your wallet. Once transferred (e.g., to a DeFi protocol), you lose the individual delegation. Voting power is then routed via an [auto-delegation strategy](staking-and-stobol.md). + +
+
+
+
+Can I change my delegate?
+ +Yes, you can re-delegate at any time through the Collective Portal at [vote.obol.org](https://vote.obol.org) + +
+
+
+
+## Staking & stOBOL
+
+Does holding OBOL give me passive income?
+ +Not directly. Only staking OBOL (to receive auto-compounding stOBOL) allows you to earn rewards. + +
+
+
+
+How do I stake OBOL?
+ +Use [stake.obol.org](https://stake.obol.org) to stake. You’ll receive auto-compounding stOBOL in return. + +
+
+
+
+Can I transfer stOBOL?
+ +Yes, stOBOL is a fully transferable ERC-20 token. However, if you transfer it, your direct delegation is lost, and your governance power enters the auto-delegation pool. + +
+
+
+
+Where can I use stOBOL?
+ +stOBOL can be used in DeFi protocols (e.g., as collateral, in LPs, etc.). Integrations are ongoing and will be announced via Discord and Twitter. + +
+
+
+
+## Token Value & Utility
+
+Can I unstake OBOL?
+ +Yes. You can return stOBOL to the staking contract at anytime without lockup to reclaim your OBOL. Unstaking and restaking interfaces are provided at [stake.obol.org](https://stake.obol.org). + +
+
+
+
+What gives the OBOL token value?
+ +OBOL gains utility through governance rights, staking yield, and its use in DeFi. Long term, its value could be tied to the growth of the Obol Network, including fees, protocol usage, and TVL. + +
+
+
+
+Does OBOL accrue fees?
+ +Currently, OBOL does not accrue protocol revenue. However, the DAO may vote in the future to direct protocol revenue toward token holders or stakers. + +
+
+
+
+_This page is updated regularly. If your question isn’t listed, reach out via Discord or the Governance Forum._
diff --git a/versioned_docs/version-v1.4/community-and-governance/obol-token/token-utility.md b/versioned_docs/version-v1.4/community-and-governance/obol-token/token-utility.md
new file mode 100644
index 0000000000..60dd9ce505
--- /dev/null
+++ b/versioned_docs/version-v1.4/community-and-governance/obol-token/token-utility.md
@@ -0,0 +1,32 @@
+---
+sidebar_label: "Token Utility"
+slug: /community-and-governance/obol-token/token-utility
+---
+
+# Token Utility
+
+## **Governance**
+
+OBOL Token holders delegate their voting power to delegates who participate in the Token House decision-making processes. This includes voting on proposals affecting the Obol Collective’s direction, upgrades, and funding allocations. Read more about the Token House [here](../governance/token-house.md).
+
+## **Obol Retroactive Funding (RAF)**
+
+Token holders delegate their voting power to Delegates, who vote on the projects eligible for retroactive funding. Read more about the Obol RAF [here](../governance/raf/).
+
+## **OBOL Token Staking**
+
+As per[ OIP-1](https://community.obol.org/t/oip-1-building-and-enabling-staking-for-the-obol-token/312), OBOL token holders will have the opportunity to stake their tokens, contributing to the security and stability of the Collective by preserving governance while earning rewards and being able to engage in DeFi. Staking involves depositing OBOL tokens in a vault (without lockup) that automatically delegates the Tokens if not done already. In return, stakers receive stOBOL, which automatically accrues OBOL Tokens as rewards as it's price vs OBOL increases.
+
+This staking program will be implemented in phases, allowing the community to gradually engage in and benefit from the system while reinforcing the decentralization of the Obol Collective. For the first six months, the total rewards will be 0.33% of the total supply, providing early participants with attractive rewards. After this period, the staking rewards may be adjusted based on governance proposals and market conditions. This structured rollout ensures a sustainable and rewarding staking experience while reinforcing the decentralization of the Obol Collective.
+
+To get started, simply visit [https://stake.obol.org](https://stake.obol.org) and follow the staking flow — no technical setup required. The interface will guide you through selecting your wallet, choosing the amount to stake, and submitting the transaction.
+
+**You will find more info about the OBOL token staking in the dedicated** [staking-and-stobol.md](staking-and-stobol.md "mention") **section.**
+
+## **DeFi**
+
+Plans are in place to launch several DeFi avenues for the OBOL Token post-TGE, such as liquidity pools, lending protocols (e.g. Morpho) and restaking (e.g. Eigenlayer, Symbiotic).
+
+## **More Utility Coming Soon**
+
+Via Token House governance proposals in the [Governance Forum](https://community.obol.org/), the Obol community can add more functionality and utility to the OBOL Token.
diff --git a/versioned_docs/version-v1.4/learn/charon/README.md b/versioned_docs/version-v1.4/learn/charon/README.md
new file mode 100644
index 0000000000..4afbb167ab
--- /dev/null
+++ b/versioned_docs/version-v1.4/learn/charon/README.md
@@ -0,0 +1,7 @@
+---
+sidebar_label: "Charon"
+slug: /learn/charon
+---
+
+# Charon
+
diff --git a/versioned_docs/version-v1.4/learn/charon/charon-cli-reference.md b/versioned_docs/version-v1.4/learn/charon/charon-cli-reference.md
new file mode 100644
index 0000000000..c9116a4ceb
--- /dev/null
+++ b/versioned_docs/version-v1.4/learn/charon/charon-cli-reference.md
@@ -0,0 +1,748 @@
+---
+description: "A go-based middleware client for taking part in Distributed Validator clusters."
+sidebar_label: "CLI Reference"
+slug: /learn/charon/charon-cli-reference
+---
+
+# CLI Reference
+
+The following is a reference for Charon version [`v1.4.3`](https://github.com/ObolNetwork/charon/releases/tag/v1.4.3). Find the latest release on [our Github](https://github.com/ObolNetwork/charon/releases).
+
+The following are the top-level commands available to use.
+
+```markdown
+charon --help
+Charon enables the operation of Ethereum validators in a fault tolerant manner by splitting the validating keys across a group of trusted parties using threshold cryptography.
+
+Usage:
+ charon [command]
+
+Available Commands:
+ alpha Alpha subcommands provide early access to in-development features
+ combine Combine the private key shares of a distributed validator cluster into a set of standard validator private keys
+ completion Generate the autocompletion script for the specified shell
+ create Create artifacts for a distributed validator cluster
+ dkg Participate in a Distributed Key Generation ceremony
+ enr Print the ENR that identifies this client
+ exit Exit a distributed validator.
+ help Help about any command
+ relay Start a libp2p relay server
+ run Run the charon middleware client
+ version Print version and exit
+
+Flags:
+ -h, --help Help for charon
+
+Use "charon [command] --help" for more information about a command.
+```
+
+## The `create` command
+
+The `create` command handles the creation of artifacts needed by Charon to operate.
+
+```markdown
+charon create --help
+Create artifacts for a distributed validator cluster. These commands can be used to facilitate the creation of a distributed validator cluster between a group of operators by performing a distributed key generation ceremony, or they can be used to create a local cluster for single operator use cases.
+
+Usage:
+ charon create [command]
+
+Available Commands:
+ cluster Create private keys and configuration files needed to run a distributed validator cluster locally
+ dkg Create the configuration for a new Distributed Key Generation ceremony using charon dkg
+ enr Create an Ethereum Node Record (ENR) private key to identify this charon client
+
+Flags:
+ -h, --help Help for create
+
+Use "charon create [command] --help" for more information about a command.
+```
+
+### Creating an ENR for Charon
+
+An `enr` is an Ethereum Node Record. It is used to identify this Charon client to its other counterparty Charon clients across the internet.
+
+```markdown
+charon create enr --help
+Create an Ethereum Node Record (ENR) private key to identify this charon client
+
+Usage:
+ charon create enr [flags]
+
+Flags:
+ --data-dir string The directory where charon will store all its internal data. (default ".charon")
+ -h, --help Help for enr
+```
+
+### Create a full cluster locally
+
+The `charon create cluster` command creates a set of distributed validators locally; including the private keys, a `cluster-lock.json` file, and deposit data. This command should only be used for solo-operation of distributed validators. To run a distributed validator cluster with a group of operators, it is preferable to create these artifacts using the [DV Launchpad](../intro/launchpad.md) and the `charon dkg` command. That way, no single operator custodies all of the private keys to a distributed validator.
+
+:::warning
+This command produces new distributed validator private keys or handles and splits pre-existing traditional validator private keys, please use caution and keep these private keys securely backed up and secret.
+:::
+
+```markdown
+charon create cluster --help
+Creates a local charon cluster configuration including validator keys, charon p2p keys, cluster-lock.json and deposit-data.json file(s). See flags for supported features.
+
+Usage:
+ charon create cluster [flags]
+
+Flags:
+ --cluster-dir string The target folder to create the cluster in. (default "./")
+ --compounding Enable compounding rewards for validators by using 0x02 withdrawal credentials.
+ --consensus-protocol string Preferred consensus protocol name for the cluster. Selected automatically when not specified.
+ --definition-file string Optional path to a cluster definition file or an HTTP URL. This overrides all other configuration flags.
+ --deposit-amounts ints List of partial deposit amounts (integers) in ETH. Values must sum up to at least 32ETH.
+ --execution-client-rpc-endpoint string The address of the execution engine JSON-RPC API.
+ --fee-recipient-addresses strings Comma separated list of Ethereum addresses of the fee recipient for each validator. Either provide a single fee recipient address or fee recipient addresses for each validator.
+ -h, --help Help for cluster
+ --insecure-keys Generates insecure keystore files. This should never be used. It is not supported on mainnet.
+ --keymanager-addresses strings Comma separated list of keymanager URLs to import validator key shares to. Note that multiple addresses are required, one for each node in the cluster, with node0's keyshares being imported to the first address, node1's keyshares to the second, and so on.
+ --keymanager-auth-tokens strings Authentication bearer tokens to interact with the keymanager URLs. Don't include the "Bearer" symbol, only include the api-token.
+ --name string The cluster name
+ --network string Ethereum network to create validators for. Options: mainnet, goerli, sepolia, hoodi, holesky, gnosis, chiado.
+ --nodes int The number of charon nodes in the cluster. Minimum is 3.
+ --num-validators int The number of distributed validators needed in the cluster.
+ --publish Publish lock file to obol-api.
+ --publish-address string The URL to publish the lock file to. (default "https://api.obol.tech/v1")
+ --split-existing-keys Split an existing validator's private key into a set of distributed validator private key shares. Does not re-create deposit data for this key.
+ --split-keys-dir string Directory containing keys to split. Expects keys in keystore-*.json and passwords in keystore-*.txt. Requires --split-existing-keys.
+ --target-gas-limit uint Preferred target gas limit for transactions. (default 36000000)
+ --testnet-chain-id uint Chain ID of the custom test network.
+ --testnet-fork-version string Genesis fork version of the custom test network (in hex).
+ --testnet-genesis-timestamp int Genesis timestamp of the custom test network.
+ --testnet-name string Name of the custom test network.
+ --threshold int Optional override of threshold required for signature reconstruction. Defaults to ceil(n*2/3) if zero. Warning, non-default values decrease security.
+ --withdrawal-addresses strings Comma separated list of Ethereum addresses to receive the returned stake and accrued rewards for each validator. Either provide a single withdrawal address or withdrawal addresses for each validator.
+```
+
+### Creating the configuration for a DKG Ceremony
+
+This `charon create dkg` command creates a `cluster_definition.json` file used for the `charon dkg` command.
+
+```markdown
+charon create dkg --help
+Create a cluster definition file that will be used by all participants of a DKG.
+
+Usage:
+ charon create dkg [flags]
+
+Flags:
+ --compounding Enable compounding rewards for validators by using 0x02 withdrawal credentials.
+ --consensus-protocol string Preferred consensus protocol name for the cluster. Selected automatically when not specified.
+ --deposit-amounts ints List of partial deposit amounts (integers) in ETH. Values must sum up to at least 32ETH.
+ --dkg-algorithm string DKG algorithm to use; default, frost (default "default")
+ --execution-client-rpc-endpoint string The address of the execution engine JSON-RPC API.
+ --fee-recipient-addresses strings Comma separated list of Ethereum addresses of the fee recipient for each validator. Either provide a single fee recipient address or fee recipient addresses for each validator.
+ -h, --help Help for dkg
+ --name string Optional cosmetic cluster name
+ --network string Ethereum network to create validators for. Options: mainnet, goerli, sepolia, hoodi, holesky, gnosis, chiado. (default "mainnet")
+ --num-validators int The number of distributed validators the cluster will manage (32ETH+ staked for each). (default 1)
+ --operator-addresses strings Comma-separated list of each operator's Ethereum address.
+ --operator-enrs strings Comma-separated list of each operator's Charon ENR address.
+ --output-dir string The folder to write the output cluster-definition.json file to. (default ".charon")
+ --publish Creates an invitation to the DKG ceremony on the DV Launchpad. Terms and conditions apply.
+ --publish-address string The URL to publish the cluster to. (default "https://api.obol.tech/v1")
+ --target-gas-limit uint Preferred target gas limit for transactions. (default 36000000)
+ -t, --threshold int Optional override of threshold required for signature reconstruction. Defaults to ceil(n*2/3) if zero. Warning, non-default values decrease security.
+ --withdrawal-addresses strings Comma separated list of Ethereum addresses to receive the returned stake and accrued rewards for each validator. Either provide a single withdrawal address or withdrawal addresses for each validator.
+```
+
+## The `dkg` command
+
+### Performing a DKG Ceremony
+
+The `charon dkg` command takes a `cluster_definition.json` file that instructs Charon on the terms of a new distributed validator cluster to be created. Charon establishes communication with the other nodes identified in the file, performs a distributed key generation ceremony to create the required threshold private keys, and signs deposit data for each new distributed validator. The command outputs the `cluster-lock.json` file and key shares for each Distributed Validator created.
+
+```markdown
+charon dkg --help
+Participate in a distributed key generation ceremony for a specific cluster definition that creates
+distributed validator key shares and a final cluster lock configuration. Note that all other cluster operators should run
+this command at the same time.
+
+Usage:
+ charon dkg [flags]
+
+Flags:
+ --data-dir string The directory where charon will store all its internal data. (default ".charon")
+ --definition-file string The path to the cluster definition file or an HTTP URL. (default ".charon/cluster-definition.json")
+ --execution-client-rpc-endpoint string The address of the execution engine JSON-RPC API.
+ -h, --help Help for dkg
+ --keymanager-address string The keymanager URL to import validator keyshares.
+ --keymanager-auth-token string Authentication bearer token to interact with keymanager API. Don't include the "Bearer" symbol, only include the api-token.
+ --log-color string Log color; auto, force, disable. (default "auto")
+ --log-format string Log format; console, logfmt or json (default "console")
+ --log-level string Log level; debug, info, warn or error (default "info")
+ --log-output-path string Path in which to write on-disk logs.
+ --no-verify Disables cluster definition and lock file verification.
+ --p2p-disable-reuseport Disables TCP port reuse for outgoing libp2p connections.
+ --p2p-external-hostname string The DNS hostname advertised by libp2p. This may be used to advertise an external DNS.
+ --p2p-external-ip string The IP address advertised by libp2p. This may be used to advertise an external IP.
+ --p2p-relays strings Comma-separated list of libp2p relay URLs or multiaddrs. (default [https://0.relay.obol.tech,https://2.relay.obol.dev,https://1.relay.obol.tech])
+ --p2p-tcp-address strings Comma-separated list of listening TCP addresses (ip and port) for libP2P traffic. Empty default doesn't bind to local port therefore only supports outgoing connections.
+ --publish Publish the created cluster to a remote API.
+ --publish-address string The URL to publish the cluster to. (default "https://api.obol.tech/v1")
+ --publish-timeout duration Timeout for publishing a cluster, consider increasing if the cluster contains more than 200 validators. (default 30s)
+ --shutdown-delay duration Graceful shutdown delay. (default 1s)
+ --timeout duration Timeout for the DKG process, should be increased if DKG times out. (default 1m0s)
+```
+
+## The `run` command
+
+### Run the Charon middleware
+
+This `run` command accepts a `cluster-lock.json` file that was created either via a `charon create cluster` command or `charon dkg`. This lock file outlines the nodes in the cluster and the distributed validators they operate on behalf of.
+
+```markdown
+charon run --help
+Starts the long-running Charon middleware process to perform distributed validator duties.
+
+Usage:
+ charon run [flags]
+
+Flags:
+ --beacon-node-endpoints strings Comma separated list of one or more beacon node endpoint URLs.
+ --beacon-node-headers strings Comma separated list of headers formatted as header=value
+ --beacon-node-submit-timeout duration Timeout for the submission-related HTTP requests Charon makes to the configured beacon nodes. (default 2s)
+ --beacon-node-timeout duration Timeout for the HTTP requests Charon makes to the configured beacon nodes. (default 2s)
+ --builder-api Enables the builder api. Will only produce builder blocks. Builder API must also be enabled on the validator client. Beacon node must be connected to a builder-relay to access the builder network.
+ --consensus-protocol string Preferred consensus protocol name for the node. Selected automatically when not specified.
+ --debug-address string Listening address (ip and port) for the pprof and QBFT debug API. It is not enabled by default.
+ --execution-client-rpc-endpoint string The address of the execution engine JSON-RPC API.
+ --fallback-beacon-node-endpoints strings A list of beacon nodes to use if the primary list are offline or unhealthy.
+ --feature-set string Minimum feature set to enable by default: alpha, beta, or stable. Warning: modify at own risk. (default "stable")
+ --feature-set-disable strings Comma-separated list of features to disable, overriding the default minimum feature set.
+ --feature-set-enable strings Comma-separated list of features to enable, overriding the default minimum feature set.
+ --graffiti strings Comma-separated list or single graffiti string to include in block proposals. List maps to validator's public key in cluster lock. Appends "OBHow can I stay up to date on OBOL news?
+ +Join our [Discord](https://discord.gg/obol), follow [@ObolNetwork](https://x.com/Obol_Collective), and check our [Forum](https://community.obol.org) for governance and integration updates. + +All of Mellow DVV TVL
+ Lido SDVT Module validators added post Jan 13th Airdrop
+ Lido CSM TVL ran by Obol DVs
- Mellow Depositors: 80% for CSM TVL, 90% for SDVT TVL
- Rest to Node Operators
| Phase | Dates | Notes |
| Applications Open | May 14 – June 11 | Anyone can apply during this period |
| Review & Approval | June 12 - June 25 | Committee reviews proposals and approves based on milestone scope. Publish recap of selected proposals and next steps |
| Pause & Monitoring | June 26 - July 23 | Publish recap of selected proposals and next steps |
+
+
+
+Governor Contract
+ +* **Address:** [`0xcB1622185A0c62A80494bEde05Ba95ef29Fbf85c`](https://etherscan.io/address/0xcB1622185A0c62A80494bEde05Ba95ef29Fbf85c) + +- **Purpose:** Manages onchain proposal lifecycle and voting logic for Token House governance. +- **What you can find onchain:** + * Voting thresholds + * Quorum settings, + * Delay/period configs, + * Proposal and vote history. + +
+
+
+
+Obol Staker
+ +* **Address:** [`0x30641013934ec7625c9e73a4D63aab4201004259`](https://etherscan.io/address/0x30641013934ec7625c9e73a4D63aab4201004259) + +- **Purpose:** This is the base layer of the Obol staking system. It facilitates the basic mechanics of staking, such as managing deposits, forwarding governance delegation, and streaming rewards based on earning power. +- **What you can find onchain:** + * Total OBOL staked in the contract + * Stake, earning power, rewards and balances on a granular, per-deposit basis + * Current reward rate and configuration + * Contract events (e.g. `Staked`, `Withdrawn`) + * Interactions for staking/unstaking + +
+
+
+
+stOBOL (ERC-20 Token Contract)
+ +* **Address:** [`0x6590cBBCCbE6B83eF3774Ef1904D86A7B02c2fCC`](https://etherscan.io/address/0x6590cBBCCbE6B83eF3774Ef1904D86A7B02c2fCC) +* **Purpose:** A liquid ERC-20 representation of staked OBOL built on top of the Obol Staker. It adds features like transferability, reward auto compounding, and the ability to use a staked OBOL position in other protocols. Holders retain the ability to delegate their staked tokens to the governance delagate of their choice. +* **What you can find onchain:** + * ERC-20 metadata (name, symbol, decimals) + * Total supply and balances + * Transfer history + * Allowances / approvals + * Voting power interface (via `getVotes` and `delegates`) + * Event logs for delegation changes + +
+
+
+
+Reward Notifier
+ +* **Address:** [`0x384dd81047F88eE35DE75DA1149943B8e62d8802`](https://etherscan.io/address/0x384dd81047F88eE35DE75DA1149943B8e62d8802) +* **Purpose:** Manages the distribution of tokens to the staking contract so they can be streamed as rewards to stakers. +* **What you can find onchain:** + * Current and past reward rate values + * Administrative role settings (who can push updates) + * Timing/config changes made through proposals + * Events like `RewardRateUpdated` + +
+
+
+
+## Learn more about...
+
+[token-utility.md](token-utility.md)
+[staking-and-stobol.md](staking-and-stobol.md)
+[token-distribution-and-liquidity.md](token-distribution-and-liquidity.md)
+[token-holders-faq.md](token-holders-faq.md)
+[tge-faq.md](tge-faq.md)
diff --git a/versioned_docs/version-v1.5/community-and-governance/obol-token/staking-and-stobol.md b/versioned_docs/version-v1.5/community-and-governance/obol-token/staking-and-stobol.md
new file mode 100644
index 0000000000..6fad699077
--- /dev/null
+++ b/versioned_docs/version-v1.5/community-and-governance/obol-token/staking-and-stobol.md
@@ -0,0 +1,78 @@
+---
+description: "This page explains how OBOL staking works, the role of stOBOL, and what happens when tokens are delegated, transferred, or used in DeFi protocols. You can stake and unstake OBOL via stake.obol.org."
+sidebar_label: "Staking & stOBOL"
+slug: /community-and-governance/obol-token/staking-and-stobol
+---
+
+# Staking & stOBOL
+
+## Overview
+
+Staking allows OBOL token holders to participate in governance while earning rewards. When you stake OBOL, you receive a liquid staking token called stOBOL. This token is transferable, composable in DeFi, and earns staking rewards while maintaining governance power, as long as it remains in the same address that originally staked the OBOL Tokens. It represents a flexible and powerful tool to both support the network and engage in the broader ecosystem.
+
+stOBOL unlocks new opportunities for participation. It is yield-bearing, enables seamless governance engagement, and is expected to be increasingly integrated across DeFi platforms. If it is transferred elsewhere, direct delegation is removed and governance power is reassigned an Auto-Delegate, preventing governance attacks. The voting behaviour of the Auto-Delegate is determined by the active strategy.
+
+### To Recap
+
+* stOBOL is a liquid staking token received when you stake OBOL.
+* It allows users to earn staking rewards which auto-compound while retaining governance power.
+* stOBOL is fully transferable (ERC-20) and can be used in DeFi (e.g., as collateral).
+
+## Key Concepts
+
+Auto Delegate Strategy
+ +* **Address:** [`0xCa28852B6Fc15EbD95b17c875D5Eb14b08579158`](https://etherscan.io/address/0xCa28852B6Fc15EbD95b17c875D5Eb14b08579158) +* **Purpose:** Implements the “Overwhelming Support” auto-delegation strategy. This contract casts votes on behalf of un-delegated or transferred stOBOL when proposals receive strong community support. This mechanism uses tokens that would otherwise not be available in governance to ensure uncontroversial proposals will meet quorum. +* **What you can find onchain:** + * Parameters like `supportThreshold`, `subQuorumBips`, and `votingWindow` + * Proposals voted on by the strategy + * Vote power amounts cast + * Event logs showing execution activity + * Wallets or protocols interacting with auto-delegation logic + +| Feature | OBOL | stOBOL |
| Governance voting | ✅ (direct or delegated) | ✅ (only if kept on original staking address, otherwise governance power reallocated to the Auto-Delegate) |
| Transferable | ✅ | ✅ |
| Used in DeFi | ✅ (less efficient, not yield-bearing) | ✅ (yield-bearing) |
| Earns staking rewards | ❌ | ✅ |
+
+
+
+How do I unlock my OBOL Tokens received in the Airdrop?
+ +Starting May 7th at 11:00 AM UTC, visit [**claim.obol.org**](https://claim.obol.org), click **“Unlock”**, and follow the steps. + +
+
+
+
+When is the official TGE date and time?
+ +The OBOL Token will be listed on exchanges for deposit, trading and withdrawals on May 7th, 2025 at 11:00 AM UTC + +
+
+
+
+Where will the OBOL Token be listed for trading?
+ +* **Binance**, **Bybit**, **Bitget**, **Gate.io**, **MEXC**, and others. + +- Check [CoinGecko](https://coingecko.com) or [CoinMarketCap](https://coinmarketcap.com/currencies/obol/) for the most up-to-date list. + +
+
+
+
+What are the exact listing times on exchanges?
+ +* **Binance Alpha** – _May 7 at 10:00 AM UTC_ + +- **Binance Futures** – _May 7 at 10:30 AM UTC_ + +* **Bybit, Gate.io, Bitget, MEXC** – _May 7 at 11:00 AM UTC_ + +
+
+
+
+Where can I track the price of the OBOL Token?
+ +[CoinGecko](https://coingecko.com) and [CoinMarketCap](https://coinmarketcap.com/currencies/obol/) + +
+
+
+
+Where can I buy the OBOL Token onchain?
+ +* A **Uniswap v3 pool** will be seeded with initial liquidity. + +- The contract address is [here](https://etherscan.io/address/0x57F52C9faa6D40c5163D76b8D7dD81ddB7c95434). + +* Anyone can start a pool. Check live prices via **CoinGecko**, or **CoinMarketCap**. + +
+
+
+
+## **Token Supply & Distribution**
+
+Are there any country restrictions for claiming or trading the OBOL Token?
+ +* Yes. Each venue has its own restrictions. + +- Unlocking OBOL Tokens received through the Airdrop is subject to the same geo restrictions as claiming. + +
+
+
+
+What is the circulating supply at TGE?
+ +Approximately 19**%**. Full breakdown is on [CoinMarketCap](https://coinmarketcap.com/currencies/obol/). + +
+
+
+
+Why does Etherscan show 374M tokens instead of 500M?
+ +For legal and tax reasons, not all tokens are minted yet. + +
+
+
+
+How many tokens were allocated to CoinList, and how many unlock at TGE?
+ +Details available on the [**Coinlist Sale Page**](https://coinlist.co/obol). + +
+
+
+
+## **Unlocks & Vesting**
+
+When were unclaimed airdrop tokens returned to the treasury?
+ +As approved by [**OIP-2**](https://community.obol.org/t/oip-2-unlock-obol-token/317), they were [returned](https://etherscan.io/tx/0x738b4c252bb4613b9945e3b6426ec4ee510c6cdb86027fe20d533c4799a3a331) on **May 2, 2025**. + +
+
+
+
+Can CoinList participants claim at TGE?
+ +Yes, a portion of their tokens will unlock on May 7th at 11AM UTC per the [**Coinlist terms**](https://coinlist.co/obol). + +
+
+
+
+Will RAF1 tokens be available at TGE?
+ +RAF1 tokens will be distributed **shortly after TGE**. + +
+
+
+
+## **Token Utility**
+
+When will OBOL Token incentives be claimable?
+ +Starting May 12, 2025 + +
+
+
+
+What is the utility of the OBOL Token?
+ +See the top of the page + +
+
+
+
+What is stOBOL?
+ +A staked version of the OBOL Token that can be used in DeFi or with restaking platforms. + +
+
+
+
+Can the OBOL or stOBOL Tokens be used in DeFi?
+ +Yes. More info will follow **post-TGE**. + +
+
+
diff --git a/versioned_docs/version-v1.5/community-and-governance/obol-token/token-distribution-and-liquidity.md b/versioned_docs/version-v1.5/community-and-governance/obol-token/token-distribution-and-liquidity.md
new file mode 100644
index 0000000000..649045f286
--- /dev/null
+++ b/versioned_docs/version-v1.5/community-and-governance/obol-token/token-distribution-and-liquidity.md
@@ -0,0 +1,42 @@
+---
+sidebar_label: "Token Distribution & Liquidity"
+slug: /community-and-governance/obol-token/token-distribution-and-liquidity
+---
+
+# Token Distribution & Liquidity
+
+## Token Distribution
+
+The total supply is capped at 500 million tokens. The full supply is not immediately circulating and tokens will unlock over the coming months and years.
+
+
+
+### **Ecosystem Treasury & Retroactive Funding (RAF) | 38.8%**
+
+A significant portion of OBOL Tokens are allocated to the ecosystem treasury to drive innovation and decentralization. These funds support different initiatives, for example, [**SQUAD Goals**](https://community.obol.org/t/oip-3-obol-collective-2025-goals-proposal/)**, Grants & Incentives Funding** contributors who help to the growth of the protocol and the broader Collective and [**Retroactive Funding (RAF)**](https://docs.obol.org/community-and-governance/governance/raf)**,** rewarding contributions that have positively impacted the Obol Collective. Over time, the Obol Association plans to give additional control over these tokens to the community.
+
+### **Investors | 23.7%**
+
+Early investors played a key role in bringing the Obol Collective to life. This allocation ensures that individuals and entities that provided early financial support are fairly rewarded while adhering to best practices in responsible token vesting.
+
+### **Team | 19%**
+
+To attract and retain top-tier talent, a portion of tokens is reserved for core contributors, founders, and developers. This allocation aligns with the long-term vision of the project and is subject to a lock-up period similar to the one of investors.
+
+### **Community Incentives | 7.5%**
+
+To promote awareness and adoption, OBOL tokens will be used for user-focused initiatives that drive adoption of Obol DVs. The first of these initiative is the [Obol Incentives Program.](https://obol.org/incentives)
+
+### **Airdrop | 7.5%**
+
+As a community-first initiative, Obol has rewarded early contributors and supporters through a retroactive airdrop. This ensures ongoing participation in the Collective and strengthens the decentralized operator ecosystem. For more information about the Airdrop distribution, please [see this blog article](https://blog.obol.org/airdrop/).
+
+### **Public Sale via Coinlist | 3.6%**
+
+To ensure broad and fair token distribution, a portion of OBOL Tokens have been made available through a [Coinlist public sale](https://coinlist.co/obol) at better terms than investors. 50% of tokens purchased in the token sale will be fully unlocked and transferable at TGE, followed by a 12 month linear unlock for the remainder of the tokens.
+
+## Token Liquidity
+
+Once the token becomes transferable, the community will be able to track the distribution schedule and observe how the circulating supply increases over time according to the structured unlock plan.
+
+
diff --git a/versioned_docs/version-v1.5/community-and-governance/obol-token/token-holders-faq.md b/versioned_docs/version-v1.5/community-and-governance/obol-token/token-holders-faq.md
new file mode 100644
index 0000000000..b4774dd49c
--- /dev/null
+++ b/versioned_docs/version-v1.5/community-and-governance/obol-token/token-holders-faq.md
@@ -0,0 +1,135 @@
+---
+description: "This page is designed to answer the most common questions from OBOL token holders, particularly those holding liquid OBOL or stOBOL."
+sidebar_label: "Token Holders FAQ"
+slug: /community-and-governance/obol-token/token-holders-faq
+---
+
+# Token Holders FAQ
+
+## General
+
+Are there incentives for providing DeFi liquidity with OBOL or stOBOL?
+ +**Not at TGE**, but proposals for incentives can be submitted via governance. + +
+
+
+
+What is the OBOL token used for?
+ +OBOL is the governance token of the Obol Collective. It enables holders to participate in on-chain governance by voting directly or delegating their voting power to delegates. + +OBOL is also used in the [RAF](../governance/raf/), where token holders delegate to vote on which contributors should receive retroactive funding for valuable work. + +In addition, OBOL can be staked to receive stOBOL, a liquid token that accrues staking rewards and retains governance power as long as it remains in the staker’s wallet. This staking mechanism supports long-term alignment and decentralized ownership. + +Finally, both OBOL and stOBOL are being integrated into DeFi protocols, such as liquidity pools, lending platforms (e.g. Morpho), and restaking services (e.g. Eigenlayer, Symbiotic), with more utility expected over time as shaped by community governance. + +
+
+
+
+What is stOBOL?
+ +stOBOL is the liquid staking token received when you stake OBOL. It earns staking rewards and can be used in DeFi. Holding stOBOL in your wallet preserves your governance power. More info in [staking-and-stobol.md](staking-and-stobol.md "mention") + +
+
+
+
+## Delegation & Governance
+
+Where can I see OBOL price, supply, and markets?
+ +You can track OBOL on [CoinMarketCap](https://www.coingecko.com/en/coins/obol-2) or [Coingecko](https://coingecko.com). These pages include market data, supply information, and live price charts. + +
+
+
+
+How do I delegate my OBOL tokens?
+ +You can delegate via [vote.obol.org](https://vote.obol.org/dao/delegates). Connect your wallet, choose a delegate, and confirm the delegation transaction. + +
+
+
+
+What happens if I stake OBOL?
+ +You receive stOBOL, which maintains your delegation as long as it stays in your wallet. Once transferred (e.g., to a DeFi protocol), you lose the individual delegation. Voting power is then routed via an [auto-delegation strategy](staking-and-stobol.md#how-the-auto-delegate-strategy-works-current-overwhelming-support). + +
+
+
+
+Can I change my delegate?
+ +Yes, you can re-delegate at any time through the Collective Portal at [vote.obol.org](https://vote.obol.org) + +
+
+
+
+## Staking & stOBOL
+
+Does holding OBOL give me passive income?
+ +Not directly. Only staking OBOL (to receive auto-compounding stOBOL) allows you to earn rewards. + +
+
+
+
+How do I stake OBOL?
+ +Use [stake.obol.org](https://stake.obol.org) to stake. You’ll receive auto-compounding stOBOL in return. + +
+
+
+
+Can I transfer stOBOL?
+ +Yes, stOBOL is a fully transferable ERC-20 token. However, if you transfer it, your direct delegation is lost, and your governance power enters the auto-delegation pool. + +
+
+
+
+Where can I use stOBOL?
+ +stOBOL can be used in DeFi protocols (e.g., as collateral, in LPs, etc.). Integrations are ongoing and will be announced via Discord and Twitter. + +
+
+
+
+## Token Value & Utility
+
+Can I unstake OBOL?
+ +Yes. You can return stOBOL to the staking contract at anytime without lockup to reclaim your OBOL. Unstaking and restaking interfaces are provided at [stake.obol.org](https://stake.obol.org). + +
+
+
+
+What gives the OBOL token value?
+ +OBOL gains utility through governance rights, staking yield, and its use in DeFi. Long term, its value could be tied to the growth of the Obol Network, including fees, protocol usage, and TVL. + +
+
+
+
+Does OBOL accrue fees?
+ +Currently, OBOL does not accrue protocol revenue. However, the DAO may vote in the future to direct protocol revenue toward token holders or stakers. + +
+
+
+
+_This page is updated regularly. If your question isn’t listed, reach out via Discord or the Governance Forum._
diff --git a/versioned_docs/version-v1.5/community-and-governance/obol-token/token-utility.md b/versioned_docs/version-v1.5/community-and-governance/obol-token/token-utility.md
new file mode 100644
index 0000000000..6adaca1495
--- /dev/null
+++ b/versioned_docs/version-v1.5/community-and-governance/obol-token/token-utility.md
@@ -0,0 +1,44 @@
+---
+sidebar_label: "Token Utility"
+slug: /community-and-governance/obol-token/token-utility
+---
+
+# Token Utility
+
+## **Governance**
+
+OBOL Token holders delegate their voting power to delegates who participate in the Token House decision-making processes. This includes voting on proposals affecting the Obol Collective’s direction, upgrades, and funding allocations. Read more about the Token House [here](../governance/token-house.md).
+
+## **Obol Retroactive Funding (RAF)**
+
+Token holders delegate their voting power to Delegates, who vote on the projects eligible for retroactive funding. Read more about the Obol RAF [here](../governance/raf/).
+
+## **OBOL Token Staking**
+
+As per[ OIP-1](https://community.obol.org/t/oip-1-building-and-enabling-staking-for-the-obol-token/312), OBOL token holders will have the opportunity to stake their tokens, contributing to the security and stability of the Collective by preserving governance while earning rewards and being able to engage in DeFi. Staking involves depositing OBOL tokens in a vault (without lockup) that automatically delegates the Tokens if not done already. In return, stakers receive stOBOL, which automatically accrues OBOL Tokens as rewards as it's price vs OBOL increases.
+
+This staking program will be implemented in phases, allowing the community to gradually engage in and benefit from the system while reinforcing the decentralization of the Obol Collective. For the first six months, the total rewards will be 0.33% of the total supply, providing early participants with attractive rewards. After this period, the staking rewards may be adjusted based on governance proposals and market conditions. This structured rollout ensures a sustainable and rewarding staking experience while reinforcing the decentralization of the Obol Collective.
+
+To get started, simply visit [https://stake.obol.org](https://stake.obol.org) and follow the staking flow — no technical setup required. The interface will guide you through selecting your wallet, choosing the amount to stake, and submitting the transaction.
+
+**You will find more info about the OBOL token staking in the dedicated** [staking-and-stobol.md](staking-and-stobol.md "mention") **section.**
+
+## **DeFi**
+
+Plans are in place to launch several DeFi avenues for the OBOL Token post-TGE, such as liquidity pools, lending protocols (e.g. Morpho) and restaking (e.g. Eigenlayer, Symbiotic).
+
+### Pendle Integration for stOBOL
+
+_Note: The Pendle integration is not yet live. It is expected to go live in the first half of August 2025. This information is provided in advance for community awareness._
+
+stOBOL is supported on [Pendle Finance](https://app.pendle.finance), enabling users to access advanced yield strategies with their staked OBOL.
+
+Through Pendle, users can isolate and trade the future yield of stOBOL by buying or selling its **Principal Tokens (PT)** and **Yield Tokens (YT)**.
+
+This opens up new opportunities: holders can lock in fixed yield by purchasing PTs, speculate on rising yield by acquiring YTs, or passively earn through **liquidity provision**, which offers exposure to swap fees and additional PENDLE incentives. Importantly, Pendle pools are **permissionless**, and while the Obol Association has provided initial liquidity to bootstrap the market, anyone can contribute. \
+\
+For more details, refer to the [Pendle Academy](https://pendle.gitbook.io/pendle-academy) and [stOBOL pool on Pendle](https://app.pendle.finance/trade).
+
+## **More Utility Coming Soon**
+
+Via Token House governance proposals in the [Governance Forum](https://community.obol.org/), the Obol community can add more functionality and utility to the OBOL Token.
diff --git a/versioned_docs/version-v1.5/learn/charon/README.md b/versioned_docs/version-v1.5/learn/charon/README.md
new file mode 100644
index 0000000000..4afbb167ab
--- /dev/null
+++ b/versioned_docs/version-v1.5/learn/charon/README.md
@@ -0,0 +1,7 @@
+---
+sidebar_label: "Charon"
+slug: /learn/charon
+---
+
+# Charon
+
diff --git a/versioned_docs/version-v1.5/learn/charon/charon-cli-reference.md b/versioned_docs/version-v1.5/learn/charon/charon-cli-reference.md
new file mode 100644
index 0000000000..39b50bb526
--- /dev/null
+++ b/versioned_docs/version-v1.5/learn/charon/charon-cli-reference.md
@@ -0,0 +1,751 @@
+---
+description: "A go-based middleware client for taking part in Distributed Validator clusters."
+sidebar_label: "CLI Reference"
+slug: /learn/charon/charon-cli-reference
+---
+
+# CLI Reference
+
+The following is a reference for Charon version [`v1.5.2`](https://github.com/ObolNetwork/charon/releases/tag/v1.5.2). Find the latest release on [our Github](https://github.com/ObolNetwork/charon/releases).
+
+The following are the top-level commands available to use.
+
+```markdown
+charon --help
+Charon enables the operation of Ethereum validators in a fault tolerant manner by splitting the validating keys across a group of trusted parties using threshold cryptography.
+
+Usage:
+ charon [command]
+
+Available Commands:
+ alpha Alpha subcommands provide early access to in-development features
+ combine Combine the private key shares of a distributed validator cluster into a set of standard validator private keys
+ completion Generate the autocompletion script for the specified shell
+ create Create artifacts for a distributed validator cluster
+ dkg Participate in a Distributed Key Generation ceremony
+ enr Print the ENR that identifies this client
+ exit Exit a distributed validator.
+ help Help about any command
+ relay Start a libp2p relay server
+ run Run the charon middleware client
+ version Print version and exit
+
+Flags:
+ -h, --help Help for charon
+
+Use "charon [command] --help" for more information about a command.
+```
+
+## The `create` command
+
+The `create` command handles the creation of artifacts needed by Charon to operate.
+
+```markdown
+charon create --help
+Create artifacts for a distributed validator cluster. These commands can be used to facilitate the creation of a distributed validator cluster between a group of operators by performing a distributed key generation ceremony, or they can be used to create a local cluster for single operator use cases.
+
+Usage:
+ charon create [command]
+
+Available Commands:
+ cluster Create private keys and configuration files needed to run a distributed validator cluster locally
+ dkg Create the configuration for a new Distributed Key Generation ceremony using charon dkg
+ enr Create an Ethereum Node Record (ENR) private key to identify this charon client
+
+Flags:
+ -h, --help Help for create
+
+Use "charon create [command] --help" for more information about a command.
+```
+
+### Creating an ENR for Charon
+
+An `enr` is an Ethereum Node Record. It is used to identify this Charon client to its other counterparty Charon clients across the internet.
+
+```markdown
+charon create enr --help
+Create an Ethereum Node Record (ENR) private key to identify this charon client
+
+Usage:
+ charon create enr [flags]
+
+Flags:
+ --data-dir string The directory where charon will store all its internal data. (default ".charon")
+ -h, --help Help for enr
+```
+
+### Create a full cluster locally
+
+The `charon create cluster` command creates a set of distributed validators locally; including the private keys, a `cluster-lock.json` file, and deposit data. This command should only be used for solo-operation of distributed validators. To run a distributed validator cluster with a group of operators, it is preferable to create these artifacts using the [DV Launchpad](../intro/launchpad.md) and the `charon dkg` command. That way, no single operator custodies all of the private keys to a distributed validator.
+
+:::warning
+This command produces new distributed validator private keys or handles and splits pre-existing traditional validator private keys, please use caution and keep these private keys securely backed up and secret.
+:::
+
+```markdown
+charon create cluster --help
+Creates a local charon cluster configuration including validator keys, charon p2p keys, cluster-lock.json and deposit-data.json file(s). See flags for supported features.
+
+Usage:
+ charon create cluster [flags]
+
+Flags:
+ --cluster-dir string The target folder to create the cluster in. (default "./")
+ --compounding Enable compounding rewards for validators by using 0x02 withdrawal credentials.
+ --consensus-protocol string Preferred consensus protocol name for the cluster. Selected automatically when not specified.
+ --definition-file string Optional path to a cluster definition file or an HTTP URL. This overrides all other configuration flags.
+ --deposit-amounts ints List of partial deposit amounts (integers) in ETH. Values must sum up to at least 32ETH.
+ --execution-client-rpc-endpoint string The address of the execution engine JSON-RPC API.
+ --fee-recipient-addresses strings Comma separated list of Ethereum addresses of the fee recipient for each validator. Either provide a single fee recipient address or fee recipient addresses for each validator.
+ -h, --help Help for cluster
+ --insecure-keys Generates insecure keystore files. This should never be used. It is not supported on mainnet.
+ --keymanager-addresses strings Comma separated list of keymanager URLs to import validator key shares to. Note that multiple addresses are required, one for each node in the cluster, with node0's keyshares being imported to the first address, node1's keyshares to the second, and so on.
+ --keymanager-auth-tokens strings Authentication bearer tokens to interact with the keymanager URLs. Don't include the "Bearer" symbol, only include the api-token.
+ --name string The cluster name
+ --network string Ethereum network to create validators for. Options: mainnet, goerli, sepolia, hoodi, holesky, gnosis, chiado.
+ --nodes int The number of charon nodes in the cluster. Minimum is 3.
+ --num-validators int The number of distributed validators needed in the cluster.
+ --publish Publish lock file to obol-api.
+ --publish-address string The URL to publish the lock file to. (default "https://api.obol.tech/v1")
+ --split-existing-keys Split an existing validator's private key into a set of distributed validator private key shares. Does not re-create deposit data for this key.
+ --split-keys-dir string Directory containing keys to split. Expects keys in keystore-*.json and passwords in keystore-*.txt. Requires --split-existing-keys.
+ --target-gas-limit uint Preferred target gas limit for transactions. (default 60000000)
+ --testnet-chain-id uint Chain ID of the custom test network.
+ --testnet-fork-version string Genesis fork version of the custom test network (in hex).
+ --testnet-genesis-timestamp int Genesis timestamp of the custom test network.
+ --testnet-name string Name of the custom test network.
+ --threshold int Optional override of threshold required for signature reconstruction. Defaults to ceil(n*2/3) if zero. Warning, non-default values decrease security.
+ --withdrawal-addresses strings Comma separated list of Ethereum addresses to receive the returned stake and accrued rewards for each validator. Either provide a single withdrawal address or withdrawal addresses for each validator.
+ --zipped Create a tar archive compressed with gzip of the cluster directory after creation.
+```
+
+### Creating the configuration for a DKG Ceremony
+
+This `charon create dkg` command creates a `cluster_definition.json` file used for the `charon dkg` command.
+
+```markdown
+charon create dkg --help
+Create a cluster definition file that will be used by all participants of a DKG.
+
+Usage:
+ charon create dkg [flags]
+
+Flags:
+ --compounding Enable compounding rewards for validators by using 0x02 withdrawal credentials.
+ --consensus-protocol string Preferred consensus protocol name for the cluster. Selected automatically when not specified.
+ --deposit-amounts ints List of partial deposit amounts (integers) in ETH. Values must sum up to at least 32ETH.
+ --dkg-algorithm string DKG algorithm to use; default, frost (default "default")
+ --execution-client-rpc-endpoint string The address of the execution engine JSON-RPC API.
+ --fee-recipient-addresses strings Comma separated list of Ethereum addresses of the fee recipient for each validator. Either provide a single fee recipient address or fee recipient addresses for each validator.
+ -h, --help Help for dkg
+ --name string Optional cosmetic cluster name
+ --network string Ethereum network to create validators for. Options: mainnet, goerli, sepolia, hoodi, holesky, gnosis, chiado. (default "mainnet")
+ --num-validators int The number of distributed validators the cluster will manage (32ETH+ staked for each). (default 1)
+ --operator-addresses strings Comma-separated list of each operator's Ethereum address.
+ --operator-enrs strings Comma-separated list of each operator's Charon ENR address.
+ --output-dir string The folder to write the output cluster-definition.json file to. (default ".charon")
+ --publish Creates an invitation to the DKG ceremony on the DV Launchpad. Terms and conditions apply.
+ --publish-address string The URL to publish the cluster to. (default "https://api.obol.tech/v1")
+ --target-gas-limit uint Preferred target gas limit for transactions. (default 60000000)
+ -t, --threshold int Optional override of threshold required for signature reconstruction. Defaults to ceil(n*2/3) if zero. Warning, non-default values decrease security.
+ --withdrawal-addresses strings Comma separated list of Ethereum addresses to receive the returned stake and accrued rewards for each validator. Either provide a single withdrawal address or withdrawal addresses for each validator.
+```
+
+## The `dkg` command
+
+### Performing a DKG Ceremony
+
+The `charon dkg` command takes a `cluster_definition.json` file that instructs Charon on the terms of a new distributed validator cluster to be created. Charon establishes communication with the other nodes identified in the file, performs a distributed key generation ceremony to create the required threshold private keys, and signs deposit data for each new distributed validator. The command outputs the `cluster-lock.json` file and key shares for each Distributed Validator created.
+
+```markdown
+charon dkg --help
+Participate in a distributed key generation ceremony for a specific cluster definition that creates
+distributed validator key shares and a final cluster lock configuration. Note that all other cluster operators should run
+this command at the same time.
+
+Usage:
+ charon dkg [flags]
+
+Flags:
+ --data-dir string The directory where charon will store all its internal data. (default ".charon")
+ --definition-file string The path to the cluster definition file or an HTTP URL. (default ".charon/cluster-definition.json")
+ --execution-client-rpc-endpoint string The address of the execution engine JSON-RPC API.
+ -h, --help Help for dkg
+ --keymanager-address string The keymanager URL to import validator keyshares.
+ --keymanager-auth-token string Authentication bearer token to interact with keymanager API. Don't include the "Bearer" symbol, only include the api-token.
+ --log-color string Log color; auto, force, disable. (default "auto")
+ --log-format string Log format; console, logfmt or json (default "console")
+ --log-level string Log level; debug, info, warn or error (default "info")
+ --log-output-path string Path in which to write on-disk logs.
+ --no-verify Disables cluster definition and lock file verification.
+ --p2p-disable-reuseport Disables TCP port reuse for outgoing libp2p connections.
+ --p2p-external-hostname string The DNS hostname advertised by libp2p. This may be used to advertise an external DNS.
+ --p2p-external-ip string The IP address advertised by libp2p. This may be used to advertise an external IP.
+ --p2p-relays strings Comma-separated list of libp2p relay URLs or multiaddrs. (default [https://0.relay.obol.tech,https://2.relay.obol.dev,https://1.relay.obol.tech])
+ --p2p-tcp-address strings Comma-separated list of listening TCP addresses (ip and port) for libP2P traffic. Empty default doesn't bind to local port therefore only supports outgoing connections.
+ --publish Publish the created cluster to a remote API.
+ --publish-address string The URL to publish the cluster to. (default "https://api.obol.tech/v1")
+ --publish-timeout duration Timeout for publishing a cluster, consider increasing if the cluster contains more than 200 validators. (default 30s)
+ --shutdown-delay duration Graceful shutdown delay. (default 1s)
+ --timeout duration Timeout for the DKG process, should be increased if DKG times out. (default 1m0s)
+```
+
+## The `run` command
+
+### Run the Charon middleware
+
+This `run` command accepts a `cluster-lock.json` file that was created either via a `charon create cluster` command or `charon dkg`. This lock file outlines the nodes in the cluster and the distributed validators they operate on behalf of.
+
+```markdown
+charon run --help
+Starts the long-running Charon middleware process to perform distributed validator duties.
+
+Usage:
+ charon run [flags]
+
+Flags:
+ --beacon-node-endpoints strings Comma separated list of one or more beacon node endpoint URLs.
+ --beacon-node-headers strings Comma separated list of headers formatted as header=value
+ --beacon-node-submit-timeout duration Timeout for the submission-related HTTP requests Charon makes to the configured beacon nodes. (default 2s)
+ --beacon-node-timeout duration Timeout for the HTTP requests Charon makes to the configured beacon nodes. (default 2s)
+ --builder-api Enables the builder api. Will only produce builder blocks. Builder API must also be enabled on the validator client. Beacon node must be connected to a builder-relay to access the builder network.
+ --consensus-protocol string Preferred consensus protocol name for the node. Selected automatically when not specified.
+ --debug-address string Listening address (ip and port) for the pprof and QBFT debug API. It is not enabled by default.
+ --execution-client-rpc-endpoint string The address of the execution engine JSON-RPC API.
+ --fallback-beacon-node-endpoints strings A list of beacon nodes to use if the primary list are offline or unhealthy.
+ --feature-set string Minimum feature set to enable by default: alpha, beta, or stable. Warning: modify at own risk. (default "stable")
+ --feature-set-disable strings Comma-separated list of features to disable, overriding the default minimum feature set.
+ --feature-set-enable strings Comma-separated list of features to enable, overriding the default minimum feature set.
+ --graffiti strings Comma-separated list or single graffiti string to include in block proposals. List maps to validator's public key in cluster lock. Appends "OBHow can I stay up to date on OBOL news?
+ +Join our [Discord](https://discord.gg/obol), follow [@ObolNetwork](https://x.com/Obol_Collective), and check our [Forum](https://community.obol.org) for governance and integration updates. + +All of Mellow DVV TVL
+ Lido SDVT Module validators added post Jan 13th Airdrop
+ Lido CSM TVL ran by Obol DVs
- Mellow Depositors: 80% for CSM TVL, 90% for SDVT TVL
- Rest to Node Operators
Obol SDK
+ +This repo contains the Obol Software Development Kit, for creating Distributed Validators with the help of the [Obol API](https://docs.obol.org/api). + +## Getting Started + +Checkout our [docs](https://docs.obol.org/advanced/quickstart-sdk), [examples](https://github.com/ObolNetwork/obol-sdk-examples/), and SDK [reference](https://obolnetwork.github.io/obol-sdk). Further guides and walkthroughs coming soon. + +## Terms and Conditions +To use obol-sdk and in order to be able to create a cluster definition or accept an invite to join a cluster, you must accept the [latest Obol terms and conditions](https://obol.org/terms.pdf) by calling acceptObolLatestTermsAndConditions. + +## ⚠️ Important Security Notice: +If you're integrating this SDK with a **backend** (e.g., in Node.js), and you store a private key for executing splitter transactions, handle it with extreme caution. Ensure that: + +- The private key is securely stored (e.g., in an `.env` file). +- Never commit or push your `.env` file containing the private key to version control. + +## Contributing + +Please review the following guidelines: + +- [How to Report Bugs](#how-to-report-bugs) +- [How to Propose Changes](#how-to-propose-changes) +- [Code Review Process](#code-review-process) + +### How to Report Bugs + +If you encounter a bug or unexpected behavior, please follow these steps to report it: + +1. Go to the "Issues" tab of this repository. +2. Click on the "Get started" button in the Bug report section. +3. Provide a clear title and description of the issue following the format provided. + +### How to Propose Changes + +If you'd like to propose improvements or new features, please follow these steps: + +1. Fork this repository. +2. Create a new branch for your changes. +3. Make your changes and commit them with clear messages. +4. Open a pull request with a detailed description of the changes. + +### Code Review Process + +All contributions are reviewed before they are merged into the main branch. Please address any feedback provided during the review process. + +Thank you for contributing to Obol-SDK! + +## Enumerations + +- [FORK\_MAPPING](enumerations/FORK_MAPPING.md) + +## Classes + +- [Client](classes/Client.md) + +## Interfaces + +- [ClusterDefinition](interfaces/ClusterDefinition.md) +- [RewardsSplitPayload](interfaces/RewardsSplitPayload.md) + +## Type Aliases + +- [ClusterOperator](type-aliases/ClusterOperator.md) +- [OperatorPayload](type-aliases/OperatorPayload.md) +- [ClusterCreator](type-aliases/ClusterCreator.md) +- [ClusterValidator](type-aliases/ClusterValidator.md) +- [ClusterPayload](type-aliases/ClusterPayload.md) +- [SplitRecipient](type-aliases/SplitRecipient.md) +- [TotalSplitPayload](type-aliases/TotalSplitPayload.md) +- [BuilderRegistrationMessage](type-aliases/BuilderRegistrationMessage.md) +- [BuilderRegistration](type-aliases/BuilderRegistration.md) +- [DepositData](type-aliases/DepositData.md) +- [DistributedValidator](type-aliases/DistributedValidator.md) +- [ClusterLock](type-aliases/ClusterLock.md) +- [ETH\_ADDRESS](type-aliases/ETH_ADDRESS.md) + +## Functions + +- [validateClusterLock](functions/validateClusterLock.md) diff --git a/versioned_docs/version-v1.5/sdk/interfaces/ClusterDefinition.md b/versioned_docs/version-v1.5/sdk/interfaces/ClusterDefinition.md new file mode 100644 index 0000000000..b57096a0bf --- /dev/null +++ b/versioned_docs/version-v1.5/sdk/interfaces/ClusterDefinition.md @@ -0,0 +1,29 @@ +--- +sidebar_label: "ClusterDefinition" +slug: /sdk/interfaces/clusterdefinition +--- + +Cluster definition data needed for dkg + +## Extends + +- [`ClusterPayload`](../type-aliases/ClusterPayload.md) + +## Properties + +| Property | Type | Description | Inherited from | Defined in | +| ------ | ------ | ------ | ------ | ------ | +| `name` | `string` | The cluster name. | `ClusterPayload.name` | types.ts:73 | +| `operators` | [`ClusterOperator`](../type-aliases/ClusterOperator.md)[] | The cluster nodes operators addresses. | `ClusterPayload.operators` | types.ts:76 | +| `validators` | [`ClusterValidator`](../type-aliases/ClusterValidator.md)[] | The cluster validators information. | `ClusterPayload.validators` | types.ts:79 | +| `deposit_amounts?` | `null` \| `string`[] | The cluster partial deposits in gwei or 32000000000. | `ClusterPayload.deposit_amounts` | types.ts:82 | +| `creator` | [`ClusterCreator`](../type-aliases/ClusterCreator.md) | The creator of the cluster. | - | types.ts:90 | +| `version` | `string` | The cluster configuration version. | - | types.ts:93 | +| `dkg_algorithm` | `string` | The cluster dkg algorithm. | - | types.ts:96 | +| `fork_version` | `string` | The cluster fork version. | - | types.ts:99 | +| `uuid` | `string` | The cluster uuid. | - | types.ts:102 | +| `timestamp` | `string` | The cluster creation timestamp. | - | types.ts:105 | +| `config_hash` | `string` | The cluster configuration hash. | - | types.ts:108 | +| `threshold` | `number` | The distributed validator threshold. | - | types.ts:111 | +| `num_validators` | `number` | The number of distributed validators in the cluster. | - | types.ts:114 | +| `definition_hash?` | `string` | The hash of the cluster definition. | - | types.ts:117 | diff --git a/versioned_docs/version-v1.5/sdk/interfaces/README.md b/versioned_docs/version-v1.5/sdk/interfaces/README.md new file mode 100644 index 0000000000..b635dbc6dc --- /dev/null +++ b/versioned_docs/version-v1.5/sdk/interfaces/README.md @@ -0,0 +1,7 @@ +--- +sidebar_label: "Interfaces" +slug: /sdk/interfaces +--- + +# interfaces + diff --git a/versioned_docs/version-v1.5/sdk/interfaces/RewardsSplitPayload.md b/versioned_docs/version-v1.5/sdk/interfaces/RewardsSplitPayload.md new file mode 100644 index 0000000000..4ee32df936 --- /dev/null +++ b/versioned_docs/version-v1.5/sdk/interfaces/RewardsSplitPayload.md @@ -0,0 +1,24 @@ +--- +sidebar_label: "RewardsSplitPayload" +slug: /sdk/interfaces/rewardssplitpayload +--- + +# RewardsSplitPayload + +OWR and Split Proxy Params + +### Extends + +* [`TotalSplitPayload`](../type-aliases/TotalSplitPayload.md) + +### Properties + +| Property | Type | Description | Inherited from | Defined in | +| -------------------- | -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- | ------------ | +| `splitRecipients` | [`SplitRecipient`](../type-aliases/SplitRecipient.md)\[] | The split recipients addresses and splits. | `TotalSplitPayload.splitRecipients` | types.ts:136 | +| `ObolRAFSplit?` | `number` | Split percentageNumber allocated for Obol protocol development fee, minimum is 1%. | `TotalSplitPayload.ObolRAFSplit` | types.ts:139 | +| `distributorFee?` | `number` | The percentageNumber of accrued rewards that is paid to the caller of the distribution function to compensate them for the gas costs of doing so. Cannot be greater than 10%. For example, 5 represents 5%. | `TotalSplitPayload.distributorFee` | types.ts:142 | +| `controllerAddress?` | `string` | Address that can mutate the split, should be ZeroAddress for immutable split. | `TotalSplitPayload.controllerAddress` | types.ts:145 | +| `principalRecipient` | `string` | Address that will reclaim validator principal after exit. | - | types.ts:153 | +| `etherAmount` | `number` | Amount needed to deploy all validators expected for the OWR/Splitter configuration. | - | types.ts:156 | +| `recoveryAddress?` | `string` | Address that can control where the owr erc-20 tokens can be pushed, if set to zero it goes to splitter or principal address. | - | types.ts:159 | diff --git a/versioned_docs/version-v1.5/sdk/type-aliases/BuilderRegistration.md b/versioned_docs/version-v1.5/sdk/type-aliases/BuilderRegistration.md new file mode 100644 index 0000000000..281cd48a13 --- /dev/null +++ b/versioned_docs/version-v1.5/sdk/type-aliases/BuilderRegistration.md @@ -0,0 +1,19 @@ +--- +sidebar_label: "BuilderRegistration" +slug: /sdk/type-aliases/builderregistration +--- + +> **BuilderRegistration**: `object` + +Pre-generated Signed Validator Builder Registration + +## Type declaration + +| Name | Type | Description | Defined in | +| ------ | ------ | ------ | ------ | +| `message` | [`BuilderRegistrationMessage`](BuilderRegistrationMessage.md) | Builder registration message. | types.ts:184 | +| `signature` | `string` | BLS signature of the builder registration message. | types.ts:187 | + +## Defined in + +types.ts:182 diff --git a/versioned_docs/version-v1.5/sdk/type-aliases/BuilderRegistrationMessage.md b/versioned_docs/version-v1.5/sdk/type-aliases/BuilderRegistrationMessage.md new file mode 100644 index 0000000000..f7467b4436 --- /dev/null +++ b/versioned_docs/version-v1.5/sdk/type-aliases/BuilderRegistrationMessage.md @@ -0,0 +1,21 @@ +--- +sidebar_label: "BuilderRegistrationMessage" +slug: /sdk/type-aliases/builderregistrationmessage +--- + +> **BuilderRegistrationMessage**: `object` + +Unsigned DV Builder Registration Message + +## Type declaration + +| Name | Type | Description | Defined in | +| ------ | ------ | ------ | ------ | +| `fee_recipient` | `string` | The DV fee recipient. | types.ts:167 | +| `gas_limit` | `number` | Default is 30000000. | types.ts:170 | +| `timestamp` | `number` | Timestamp when generating cluster lock file. | types.ts:173 | +| `pubkey` | `string` | The public key of the DV. | types.ts:176 | + +## Defined in + +types.ts:165 diff --git a/versioned_docs/version-v1.5/sdk/type-aliases/ClusterCreator.md b/versioned_docs/version-v1.5/sdk/type-aliases/ClusterCreator.md new file mode 100644 index 0000000000..643f98978e --- /dev/null +++ b/versioned_docs/version-v1.5/sdk/type-aliases/ClusterCreator.md @@ -0,0 +1,19 @@ +--- +sidebar_label: "ClusterCreator" +slug: /sdk/type-aliases/clustercreator +--- + +> **ClusterCreator**: `object` + +Cluster creator data + +## Type declaration + +| Name | Type | Description | Defined in | +| ------ | ------ | ------ | ------ | +| `address` | `string` | The creator address. | types.ts:52 | +| `config_signature`? | `string` | The cluster configuration signature. | types.ts:54 | + +## Defined in + +types.ts:50 diff --git a/versioned_docs/version-v1.5/sdk/type-aliases/ClusterLock.md b/versioned_docs/version-v1.5/sdk/type-aliases/ClusterLock.md new file mode 100644 index 0000000000..e386f0060e --- /dev/null +++ b/versioned_docs/version-v1.5/sdk/type-aliases/ClusterLock.md @@ -0,0 +1,22 @@ +--- +sidebar_label: "ClusterLock" +slug: /sdk/type-aliases/clusterlock +--- + +> **ClusterLock**: `object` + +Cluster Details after DKG is complete + +## Type declaration + +| Name | Type | Description | Defined in | +| ------ | ------ | ------ | ------ | +| `cluster_definition` | [`ClusterDefinition`](../interfaces/ClusterDefinition.md) | The cluster definition. | types.ts:235 | +| `distributed_validators` | [`DistributedValidator`](DistributedValidator.md)[] | The cluster distributed validators. | types.ts:238 | +| `signature_aggregate` | `string` | The cluster bls signature aggregate. | types.ts:241 | +| `lock_hash` | `string` | The hash of the cluster lock. | types.ts:244 | +| `node_signatures`? | `string`[] | Node Signature for the lock hash by the node secp256k1 key. | types.ts:247 | + +## Defined in + +types.ts:233 diff --git a/versioned_docs/version-v1.5/sdk/type-aliases/ClusterOperator.md b/versioned_docs/version-v1.5/sdk/type-aliases/ClusterOperator.md new file mode 100644 index 0000000000..c12e7caa48 --- /dev/null +++ b/versioned_docs/version-v1.5/sdk/type-aliases/ClusterOperator.md @@ -0,0 +1,23 @@ +--- +sidebar_label: "ClusterOperator" +slug: /sdk/type-aliases/clusteroperator +--- + +> **ClusterOperator**: `object` + +Node operator data + +## Type declaration + +| Name | Type | Description | Defined in | +| ------ | ------ | ------ | ------ | +| `address` | `string` | The operator address. | types.ts:23 | +| `enr`? | `string` | The operator ethereum node record. | types.ts:26 | +| `fork_version`? | `string` | The cluster fork_version. | types.ts:29 | +| `version`? | `string` | The cluster version. | types.ts:32 | +| `enr_signature`? | `string` | The operator enr signature. | types.ts:35 | +| `config_signature`? | `string` | The operator configuration signature. | types.ts:38 | + +## Defined in + +types.ts:21 diff --git a/versioned_docs/version-v1.5/sdk/type-aliases/ClusterPayload.md b/versioned_docs/version-v1.5/sdk/type-aliases/ClusterPayload.md new file mode 100644 index 0000000000..ab4d99aff2 --- /dev/null +++ b/versioned_docs/version-v1.5/sdk/type-aliases/ClusterPayload.md @@ -0,0 +1,21 @@ +--- +sidebar_label: "ClusterPayload" +slug: /sdk/type-aliases/clusterpayload +--- + +> **ClusterPayload**: `object` + +Cluster configuration + +## Type declaration + +| Name | Type | Description | Defined in | +| ------ | ------ | ------ | ------ | +| `name` | `string` | The cluster name. | types.ts:73 | +| `operators` | [`ClusterOperator`](ClusterOperator.md)[] | The cluster nodes operators addresses. | types.ts:76 | +| `validators` | [`ClusterValidator`](ClusterValidator.md)[] | The cluster validators information. | types.ts:79 | +| `deposit_amounts`? | `string`[] \| `null` | The cluster partial deposits in gwei or 32000000000. | types.ts:82 | + +## Defined in + +types.ts:71 diff --git a/versioned_docs/version-v1.5/sdk/type-aliases/ClusterValidator.md b/versioned_docs/version-v1.5/sdk/type-aliases/ClusterValidator.md new file mode 100644 index 0000000000..266d48a113 --- /dev/null +++ b/versioned_docs/version-v1.5/sdk/type-aliases/ClusterValidator.md @@ -0,0 +1,19 @@ +--- +sidebar_label: "ClusterValidator" +slug: /sdk/type-aliases/clustervalidator +--- + +> **ClusterValidator**: `object` + +Validator withdrawal configuration + +## Type declaration + +| Name | Type | Description | Defined in | +| ------ | ------ | ------ | ------ | +| `fee_recipient_address` | `string` | Address to receive MEV rewards (if enabled), block proposal and priority fees. | types.ts:62 | +| `withdrawal_address` | `string` | Address to receive skimming rewards and validator principal at exit. | types.ts:65 | + +## Defined in + +types.ts:60 diff --git a/versioned_docs/version-v1.5/sdk/type-aliases/DepositData.md b/versioned_docs/version-v1.5/sdk/type-aliases/DepositData.md new file mode 100644 index 0000000000..592d2f643b --- /dev/null +++ b/versioned_docs/version-v1.5/sdk/type-aliases/DepositData.md @@ -0,0 +1,22 @@ +--- +sidebar_label: "DepositData" +slug: /sdk/type-aliases/depositdata +--- + +> **DepositData**: `object` + +Required deposit data for validator activation + +## Type declaration + +| Name | Type | Description | Defined in | +| ------ | ------ | ------ | ------ | +| `pubkey` | `string` | The public key of the distributed validator. | types.ts:195 | +| `withdrawal_credentials` | `string` | The 0x01 withdrawal address of the DV. | types.ts:198 | +| `amount` | `string` | 32 ethers. | types.ts:201 | +| `deposit_data_root` | `string` | A checksum for DepositData fields . | types.ts:204 | +| `signature` | `string` | BLS signature of the deposit message. | types.ts:207 | + +## Defined in + +types.ts:193 diff --git a/versioned_docs/version-v1.5/sdk/type-aliases/DistributedValidator.md b/versioned_docs/version-v1.5/sdk/type-aliases/DistributedValidator.md new file mode 100644 index 0000000000..5ec5dcc09d --- /dev/null +++ b/versioned_docs/version-v1.5/sdk/type-aliases/DistributedValidator.md @@ -0,0 +1,22 @@ +--- +sidebar_label: "DistributedValidator" +slug: /sdk/type-aliases/distributedvalidator +--- + +> **DistributedValidator**: `object` + +Required deposit data for validator activation + +## Type declaration + +| Name | Type | Description | Defined in | +| ------ | ------ | ------ | ------ | +| `distributed_public_key` | `string` | The public key of the distributed validator. | types.ts:215 | +| `public_shares` | `string`[] | The public key of the node distributed validator share. | types.ts:218 | +| `deposit_data`? | `Partial`\<[`DepositData`](DepositData.md)\> | The deposit data for activating the DV. | types.ts:221 | +| `partial_deposit_data`? | `Partial`\<[`DepositData`](DepositData.md)\>[] | The deposit data with partial amounts or full amount for activating the DV. | types.ts:224 | +| `builder_registration`? | [`BuilderRegistration`](BuilderRegistration.md) | pre-generated signed validator builder registration to be sent to builder network. | types.ts:227 | + +## Defined in + +types.ts:213 diff --git a/versioned_docs/version-v1.5/sdk/type-aliases/ETH_ADDRESS.md b/versioned_docs/version-v1.5/sdk/type-aliases/ETH_ADDRESS.md new file mode 100644 index 0000000000..c08cb82c83 --- /dev/null +++ b/versioned_docs/version-v1.5/sdk/type-aliases/ETH_ADDRESS.md @@ -0,0 +1,12 @@ +--- +sidebar_label: "ETH_ADDRESS" +slug: /sdk/type-aliases/eth_address +--- + +> **ETH\_ADDRESS**: `string` + +String expected to be Ethereum Address + +## Defined in + +types.ts:253 diff --git a/versioned_docs/version-v1.5/sdk/type-aliases/OperatorPayload.md b/versioned_docs/version-v1.5/sdk/type-aliases/OperatorPayload.md new file mode 100644 index 0000000000..ee7810452c --- /dev/null +++ b/versioned_docs/version-v1.5/sdk/type-aliases/OperatorPayload.md @@ -0,0 +1,12 @@ +--- +sidebar_label: "OperatorPayload" +slug: /sdk/type-aliases/operatorpayload +--- + +> **OperatorPayload**: `Partial`\<[`ClusterOperator`](ClusterOperator.md)\> & `Required`\<`Pick`\<[`ClusterOperator`](ClusterOperator.md), `"enr"` \| `"version"`\>\> + +A partial view of `ClusterOperator` with `enr` and `version` as required properties. + +## Defined in + +types.ts:44 diff --git a/versioned_docs/version-v1.5/sdk/type-aliases/README.md b/versioned_docs/version-v1.5/sdk/type-aliases/README.md new file mode 100644 index 0000000000..9e1ac60271 --- /dev/null +++ b/versioned_docs/version-v1.5/sdk/type-aliases/README.md @@ -0,0 +1,7 @@ +--- +sidebar_label: "Type-Aliases" +slug: /sdk/type-aliases +--- + +# type-aliases + diff --git a/versioned_docs/version-v1.5/sdk/type-aliases/SplitRecipient.md b/versioned_docs/version-v1.5/sdk/type-aliases/SplitRecipient.md new file mode 100644 index 0000000000..e40db01a6c --- /dev/null +++ b/versioned_docs/version-v1.5/sdk/type-aliases/SplitRecipient.md @@ -0,0 +1,19 @@ +--- +sidebar_label: "SplitRecipient" +slug: /sdk/type-aliases/splitrecipient +--- + +> **SplitRecipient**: `object` + +Split Recipient Keys + +## Type declaration + +| Name | Type | Description | Defined in | +| ------ | ------ | ------ | ------ | +| `account` | `string` | The split recipient address. | types.ts:125 | +| `percentAllocation` | `number` | The recipient split. | types.ts:128 | + +## Defined in + +types.ts:123 diff --git a/versioned_docs/version-v1.5/sdk/type-aliases/TotalSplitPayload.md b/versioned_docs/version-v1.5/sdk/type-aliases/TotalSplitPayload.md new file mode 100644 index 0000000000..3e24994833 --- /dev/null +++ b/versioned_docs/version-v1.5/sdk/type-aliases/TotalSplitPayload.md @@ -0,0 +1,23 @@ +--- +sidebar_label: "TotalSplitPayload" +slug: /sdk/type-aliases/totalsplitpayload +--- + +# TotalSplitPayload + +> **TotalSplitPayload**: `object` + +Split Proxy Params + +### Type declaration + +| Name | Type | Description | Defined in | +| -------------------- | ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | +| `splitRecipients` | [`SplitRecipient`](SplitRecipient.md)\[] | The split recipients addresses and splits. | types.ts:136 | +| `ObolRAFSplit`? | `number` | Split percentageNumber allocated for Obol protocol development fee, minimum is 1%. | types.ts:139 | +| `distributorFee`? | `number` | The percentageNumber of accrued rewards that is paid to the caller of the distribution function to compensate them for the gas costs of doing so. Cannot be greater than 10%. For example, 5 represents 5%. | types.ts:142 | +| `controllerAddress`? | `string` | Address that can mutate the split, should be ZeroAddress for immutable split. | types.ts:145 | + +### Defined in + +types.ts:134 diff --git a/versioned_docs/version-v1.5/walkthrough-guides/walkthroughs/README.md b/versioned_docs/version-v1.5/walkthrough-guides/walkthroughs/README.md new file mode 100644 index 0000000000..5368c6e179 --- /dev/null +++ b/versioned_docs/version-v1.5/walkthrough-guides/walkthroughs/README.md @@ -0,0 +1,7 @@ +--- +sidebar_label: "Walkthroughs" +slug: /walkthrough-guides/walkthroughs +--- + +# walkthroughs + diff --git a/versioned_docs/version-v1.5/walkthrough-guides/walkthroughs/walkthrough-guides.md b/versioned_docs/version-v1.5/walkthrough-guides/walkthroughs/walkthrough-guides.md new file mode 100644 index 0000000000..461dff576f --- /dev/null +++ b/versioned_docs/version-v1.5/walkthrough-guides/walkthroughs/walkthrough-guides.md @@ -0,0 +1,35 @@ +--- +description: "Walkthrough guides" +sidebar_label: "Walkthrough Guides" +slug: /walkthrough-guides/walkthroughs/walkthrough-guides +--- + +# Walkthrough Guides + +This section contains walkthrough guides for beginner users. Some of these guides are specific to particular hardware or operating systems, and may not replace more general documentation. These guides contain more detailed step-by-step information which may be useful for beginner users with limited experience with Linux, validators, and other topics which the primary guides assume some prior familiarity of. + +Some of these guides are community-created, and may contain issues or omissions. + +## Running Charon with Native Execution/Consensus Clients - by Atomic Whale + +See the guide [here](https://github.com/atomicwhale/obol-guides/blob/main/charon_local-native.md). + +This guide covers running Charon with local EC/BN running as system service (systemd). For example, if you have followed one of these guides (Somer Esat Guides / CoinCashew Guides / EthPilar) to set up your node. + +## Running Charon with Docker Execution/Consensus Clients - by Atomic Whale + +See the guide [here](https://github.com/atomicwhale/obol-guides/blob/main/charon_local-docker.md). + +This guide covers running Charon with local EC/BN managed by a docker-based stack (ETH-Docker/Rocket Pool Smart Node). + +## Running Charon with remote EC/BN - by Atomic Whale + +See the guide [here](https://github.com/atomicwhale/obol-guides/blob/main/charon_remote.md). + +This guide covers running Charon with remote EC/BN. For people who already have EC/BN running on a remote/differnt machine, and want to run Charon separately (for example a small VPS). + +## Running Multiple Charon instances on one machine - by Atomic Whale + +See the guide [here](https://github.com/atomicwhale/obol-guides/blob/main/charon_multiple.md). + +This guide covers steps to run multiple Charon instaces on one machine. diff --git a/versioned_docs/version-v1.6/README.md b/versioned_docs/version-v1.6/README.md new file mode 100644 index 0000000000..1cf9800b4e --- /dev/null +++ b/versioned_docs/version-v1.6/README.md @@ -0,0 +1,8 @@ +--- +title: "Introduction" +description: "Overview of the Obol Collective and Distributed Validator concepts" +sidebar_label: "Introduction" +slug: /learn/readme +--- + +Welcome to the Introduction section. Here you’ll find an overview of Obol, staking incentives, key DV concepts, and more. diff --git a/versioned_docs/version-v1.6/advanced-and-troubleshooting/advanced/README.md b/versioned_docs/version-v1.6/advanced-and-troubleshooting/advanced/README.md new file mode 100644 index 0000000000..27650c3586 --- /dev/null +++ b/versioned_docs/version-v1.6/advanced-and-troubleshooting/advanced/README.md @@ -0,0 +1,7 @@ +--- +sidebar_label: "Advanced Guides" +slug: /advanced-and-troubleshooting/advanced +--- + +# advanced + diff --git a/versioned_docs/version-v1.6/advanced-and-troubleshooting/advanced/add-validators.md b/versioned_docs/version-v1.6/advanced-and-troubleshooting/advanced/add-validators.md new file mode 100644 index 0000000000..ff55743164 --- /dev/null +++ b/versioned_docs/version-v1.6/advanced-and-troubleshooting/advanced/add-validators.md @@ -0,0 +1,69 @@ +--- +description: "Add validators to your existing distributed validator cluster using the charon alpha add-validators command." +sidebar_label: "Adding Validators" +slug: /advanced-and-troubleshooting/advanced/add-validators +--- + +# Adding Validators + +:::warning +This is an experimental feature available starting with Charon v1.6 and should not be used in production (Mainnet) yet. +::: + +You can add validators to your cluster using the `charon alpha add-validators` command. The example below is designed for the default configuration provided by this repository and assumes that the stack uses the Lodestar validator client. + +## Prerequisites + +1. Review the `add-validators` command [CLI reference](https://docs.obol.org/docs/learn/charon/charon-cli-reference). +2. Ensure this folder contains a valid `.charon` directory currently used by the running node. Keep the DV node running during the process. + +## Adding Validators Process + +The examples below are for adding 10 validators. You can use them with any number of validators you would like to add. Run the following command to collectively generate and add 10 new validators with other node operators (similar to DKG): + +```bash +# If you prefer running a pre-built charon binary +charon alpha add-validators --num-validators 10 --withdrawal-addresses=0x
+
+
+
+Governor Contract
+ +* **Address:** [`0xcB1622185A0c62A80494bEde05Ba95ef29Fbf85c`](https://etherscan.io/address/0xcB1622185A0c62A80494bEde05Ba95ef29Fbf85c) + +- **Purpose:** Manages onchain proposal lifecycle and voting logic for Token House governance. +- **What you can find onchain:** + * Voting thresholds + * Quorum settings, + * Delay/period configs, + * Proposal and vote history. + +
+
+
+
+Obol Staker
+ +* **Address:** [`0x30641013934ec7625c9e73a4D63aab4201004259`](https://etherscan.io/address/0x30641013934ec7625c9e73a4D63aab4201004259) + +- **Purpose:** This is the base layer of the Obol staking system. It facilitates the basic mechanics of staking, such as managing deposits, forwarding governance delegation, and streaming rewards based on earning power. +- **What you can find onchain:** + * Total OBOL staked in the contract + * Stake, earning power, rewards and balances on a granular, per-deposit basis + * Current reward rate and configuration + * Contract events (e.g. `Staked`, `Withdrawn`) + * Interactions for staking/unstaking + +
+
+
+
+stOBOL (ERC-20 Token Contract)
+ +* **Address:** [`0x6590cBBCCbE6B83eF3774Ef1904D86A7B02c2fCC`](https://etherscan.io/address/0x6590cBBCCbE6B83eF3774Ef1904D86A7B02c2fCC) +* **Purpose:** A liquid ERC-20 representation of staked OBOL built on top of the Obol Staker. It adds features like transferability, reward auto compounding, and the ability to use a staked OBOL position in other protocols. Holders retain the ability to delegate their staked tokens to the governance delagate of their choice. +* **What you can find onchain:** + * ERC-20 metadata (name, symbol, decimals) + * Total supply and balances + * Transfer history + * Allowances / approvals + * Voting power interface (via `getVotes` and `delegates`) + * Event logs for delegation changes + +
+
+
+
+Reward Notifier
+ +* **Address:** [`0x384dd81047F88eE35DE75DA1149943B8e62d8802`](https://etherscan.io/address/0x384dd81047F88eE35DE75DA1149943B8e62d8802) +* **Purpose:** Manages the distribution of tokens to the staking contract so they can be streamed as rewards to stakers. +* **What you can find onchain:** + * Current and past reward rate values + * Administrative role settings (who can push updates) + * Timing/config changes made through proposals + * Events like `RewardRateUpdated` + +
+
+
+
+## Learn more about...
+
+[token-utility.md](token-utility.md)
+[staking-and-stobol.md](staking-and-stobol.md)
+[token-distribution-and-liquidity.md](token-distribution-and-liquidity.md)
+[token-holders-faq.md](token-holders-faq.md)
+[tge-faq.md](tge-faq.md)
diff --git a/versioned_docs/version-v1.6/community-and-governance/obol-token/staking-and-stobol.md b/versioned_docs/version-v1.6/community-and-governance/obol-token/staking-and-stobol.md
new file mode 100644
index 0000000000..f2c58623fa
--- /dev/null
+++ b/versioned_docs/version-v1.6/community-and-governance/obol-token/staking-and-stobol.md
@@ -0,0 +1,78 @@
+---
+description: "This page explains how OBOL staking works, the role of stOBOL, and what happens when tokens are delegated, transferred, or used in DeFi protocols. You can stake and unstake OBOL via stake.obol.org."
+sidebar_label: "Staking & stOBOL"
+slug: /community-and-governance/obol-token/staking-and-stobol
+---
+
+# Staking & stOBOL
+
+## Overview
+
+Staking allows OBOL token holders to participate in governance while earning rewards. When you stake OBOL, you receive a liquid staking token called stOBOL. This token is transferable, composable in DeFi, and earns staking rewards while maintaining governance power, as long as it remains in the same address that originally staked the OBOL Tokens. It represents a flexible and powerful tool to both support the network and engage in the broader ecosystem.
+
+stOBOL unlocks new opportunities for participation. It is yield-bearing, enables seamless governance engagement, and is expected to be increasingly integrated across DeFi platforms. If it is transferred elsewhere, direct delegation is removed and governance power is reassigned an Auto-Delegate, preventing governance attacks. The voting behaviour of the Auto-Delegate is determined by the active strategy.
+
+### To Recap
+
+* stOBOL is a liquid staking token received when you stake OBOL.
+* It allows users to earn staking rewards which auto-compound while retaining governance power.
+* stOBOL is fully transferable (ERC-20) and can be used in DeFi (e.g., as collateral).
+
+## Key Concepts
+
+Auto Delegate (Overwhelming Support Strategy)
+ +* **Address:** [`0xCa28852B6Fc15EbD95b17c875D5Eb14b08579158`](https://etherscan.io/address/0xCa28852B6Fc15EbD95b17c875D5Eb14b08579158) +* **Purpose:** Implements the “Overwhelming Support” auto-delegation strategy. This contract casts votes on behalf of un-delegated or transferred stOBOL when proposals receive strong community support. This mechanism uses tokens that would otherwise not be available in governance to ensure uncontroversial proposals will meet quorum. +* **What you can find onchain:** + * Parameters like `supportThreshold`, `subQuorumBips`, and `votingWindow` + * Proposals voted on by the strategy + * Vote power amounts cast + * Event logs showing execution activity + * Wallets or protocols interacting with auto-delegation logic + +| Feature | OBOL | stOBOL |
| Governance voting | ✅ (direct or delegated) | ✅ (only if kept on original staking address, otherwise governance power reallocated to the Auto-Delegate) |
| Transferable | ✅ | ✅ |
| Used in DeFi | ✅ (less efficient, not yield-bearing) | ✅ (yield-bearing) |
| Earns staking rewards | ❌ | ✅ |
+
+
+
+How do I unlock my OBOL Tokens received in the Airdrop?
+ +Starting May 7th at 11:00 AM UTC, visit [**claim.obol.org**](https://claim.obol.org), click **“Unlock”**, and follow the steps. + +
+
+
+
+When is the official TGE date and time?
+ +The OBOL Token will be listed on exchanges for deposit, trading and withdrawals on May 7th, 2025 at 11:00 AM UTC + +
+
+
+
+Where will the OBOL Token be listed for trading?
+ +* **Binance**, **Bybit**, **Bitget**, **Gate.io**, **MEXC**, and others. + +- Check [CoinGecko](https://coingecko.com) or [CoinMarketCap](https://coinmarketcap.com/currencies/obol/) for the most up-to-date list. + +
+
+
+
+What are the exact listing times on exchanges?
+ +* **Binance Alpha** – _May 7 at 10:00 AM UTC_ + +- **Binance Futures** – _May 7 at 10:30 AM UTC_ + +* **Bybit, Gate.io, Bitget, MEXC** – _May 7 at 11:00 AM UTC_ + +
+
+
+
+Where can I track the price of the OBOL Token?
+ +[CoinGecko](https://coingecko.com) and [CoinMarketCap](https://coinmarketcap.com/currencies/obol/) + +
+
+
+
+Where can I buy the OBOL Token onchain?
+ +* A **Uniswap v3 pool** will be seeded with initial liquidity. + +- The contract address is [here](https://etherscan.io/address/0x57F52C9faa6D40c5163D76b8D7dD81ddB7c95434). + +* Anyone can start a pool. Check live prices via **CoinGecko**, or **CoinMarketCap**. + +
+
+
+
+## **Token Supply & Distribution**
+
+Are there any country restrictions for claiming or trading the OBOL Token?
+ +* Yes. Each venue has its own restrictions. + +- Unlocking OBOL Tokens received through the Airdrop is subject to the same geo restrictions as claiming. + +
+
+
+
+What is the circulating supply at TGE?
+ +Approximately 19**%**. Full breakdown is on [CoinMarketCap](https://coinmarketcap.com/currencies/obol/). + +
+
+
+
+Why does Etherscan show 374M tokens instead of 500M?
+ +For legal and tax reasons, not all tokens are minted yet. + +
+
+
+
+How many tokens were allocated to CoinList, and how many unlock at TGE?
+ +Details available on the [**Coinlist Sale Page**](https://coinlist.co/obol). + +
+
+
+
+## **Unlocks & Vesting**
+
+When were unclaimed airdrop tokens returned to the treasury?
+ +As approved by [**OIP-2**](https://community.obol.org/t/oip-2-unlock-obol-token/317), they were [returned](https://etherscan.io/tx/0x738b4c252bb4613b9945e3b6426ec4ee510c6cdb86027fe20d533c4799a3a331) on **May 2, 2025**. + +
+
+
+
+Can CoinList participants claim at TGE?
+ +Yes, a portion of their tokens will unlock on May 7th at 11AM UTC per the [**Coinlist terms**](https://coinlist.co/obol). + +
+
+
+
+Will RAF1 tokens be available at TGE?
+ +RAF1 tokens will be distributed **shortly after TGE**. + +
+
+
+
+## **Token Utility**
+
+When will OBOL Token incentives be claimable?
+ +Starting May 12, 2025 + +
+
+
+
+What is the utility of the OBOL Token?
+ +See the top of the page + +
+
+
+
+What is stOBOL?
+ +A staked version of the OBOL Token that can be used in DeFi or with restaking platforms. + +
+
+
+
+Can the OBOL or stOBOL Tokens be used in DeFi?
+ +Yes. More info will follow **post-TGE**. + +
+
+
diff --git a/versioned_docs/version-v1.6/community-and-governance/obol-token/token-distribution-and-liquidity.md b/versioned_docs/version-v1.6/community-and-governance/obol-token/token-distribution-and-liquidity.md
new file mode 100644
index 0000000000..649045f286
--- /dev/null
+++ b/versioned_docs/version-v1.6/community-and-governance/obol-token/token-distribution-and-liquidity.md
@@ -0,0 +1,42 @@
+---
+sidebar_label: "Token Distribution & Liquidity"
+slug: /community-and-governance/obol-token/token-distribution-and-liquidity
+---
+
+# Token Distribution & Liquidity
+
+## Token Distribution
+
+The total supply is capped at 500 million tokens. The full supply is not immediately circulating and tokens will unlock over the coming months and years.
+
+
+
+### **Ecosystem Treasury & Retroactive Funding (RAF) | 38.8%**
+
+A significant portion of OBOL Tokens are allocated to the ecosystem treasury to drive innovation and decentralization. These funds support different initiatives, for example, [**SQUAD Goals**](https://community.obol.org/t/oip-3-obol-collective-2025-goals-proposal/)**, Grants & Incentives Funding** contributors who help to the growth of the protocol and the broader Collective and [**Retroactive Funding (RAF)**](https://docs.obol.org/community-and-governance/governance/raf)**,** rewarding contributions that have positively impacted the Obol Collective. Over time, the Obol Association plans to give additional control over these tokens to the community.
+
+### **Investors | 23.7%**
+
+Early investors played a key role in bringing the Obol Collective to life. This allocation ensures that individuals and entities that provided early financial support are fairly rewarded while adhering to best practices in responsible token vesting.
+
+### **Team | 19%**
+
+To attract and retain top-tier talent, a portion of tokens is reserved for core contributors, founders, and developers. This allocation aligns with the long-term vision of the project and is subject to a lock-up period similar to the one of investors.
+
+### **Community Incentives | 7.5%**
+
+To promote awareness and adoption, OBOL tokens will be used for user-focused initiatives that drive adoption of Obol DVs. The first of these initiative is the [Obol Incentives Program.](https://obol.org/incentives)
+
+### **Airdrop | 7.5%**
+
+As a community-first initiative, Obol has rewarded early contributors and supporters through a retroactive airdrop. This ensures ongoing participation in the Collective and strengthens the decentralized operator ecosystem. For more information about the Airdrop distribution, please [see this blog article](https://blog.obol.org/airdrop/).
+
+### **Public Sale via Coinlist | 3.6%**
+
+To ensure broad and fair token distribution, a portion of OBOL Tokens have been made available through a [Coinlist public sale](https://coinlist.co/obol) at better terms than investors. 50% of tokens purchased in the token sale will be fully unlocked and transferable at TGE, followed by a 12 month linear unlock for the remainder of the tokens.
+
+## Token Liquidity
+
+Once the token becomes transferable, the community will be able to track the distribution schedule and observe how the circulating supply increases over time according to the structured unlock plan.
+
+
diff --git a/versioned_docs/version-v1.6/community-and-governance/obol-token/token-holders-faq.md b/versioned_docs/version-v1.6/community-and-governance/obol-token/token-holders-faq.md
new file mode 100644
index 0000000000..7d8565ad63
--- /dev/null
+++ b/versioned_docs/version-v1.6/community-and-governance/obol-token/token-holders-faq.md
@@ -0,0 +1,135 @@
+---
+description: "This page is designed to answer the most common questions from OBOL token holders, particularly those holding liquid OBOL or stOBOL."
+sidebar_label: "Token Holders FAQ"
+slug: /community-and-governance/obol-token/token-holders-faq
+---
+
+# Token Holders FAQ
+
+## General
+
+Are there incentives for providing DeFi liquidity with OBOL or stOBOL?
+ +**Not at TGE**, but proposals for incentives can be submitted via governance. + +
+
+
+
+What is the OBOL token used for?
+ +OBOL is the governance token of the Obol Collective. It enables holders to participate in on-chain governance by voting directly or delegating their voting power to delegates. + +OBOL is also used in the [RAF](../governance/raf/), where token holders delegate to vote on which contributors should receive retroactive funding for valuable work. + +In addition, OBOL can be staked to receive stOBOL, a liquid token that accrues staking rewards and retains governance power as long as it remains in the staker’s wallet. This staking mechanism supports long-term alignment and decentralized ownership. + +Finally, both OBOL and stOBOL are being integrated into DeFi protocols, such as liquidity pools, lending platforms (e.g. Morpho), and restaking services (e.g. Eigenlayer, Symbiotic), with more utility expected over time as shaped by community governance. + +
+
+
+
+What is stOBOL?
+ +stOBOL is the liquid staking token received when you stake OBOL. It earns staking rewards and can be used in DeFi. Holding stOBOL in your wallet preserves your governance power. More info in [staking-and-stobol.md](staking-and-stobol.md "mention") + +
+
+
+
+## Delegation & Governance
+
+Where can I see OBOL price, supply, and markets?
+ +You can track OBOL on [CoinMarketCap](https://www.coingecko.com/en/coins/obol-2) or [Coingecko](https://coingecko.com). These pages include market data, supply information, and live price charts. + +
+
+
+
+How do I delegate my OBOL tokens?
+ +You can delegate via [vote.obol.org](https://vote.obol.org/dao/delegates). Connect your wallet, choose a delegate, and confirm the delegation transaction. + +
+
+
+
+What happens if I stake OBOL?
+ +You receive stOBOL, which maintains your delegation as long as it stays in your wallet. Once transferred (e.g., to a DeFi protocol), you lose the individual delegation. Voting power is then routed via an [auto-delegation strategy](staking-and-stobol.md#how-the-auto-delegate-strategy-works-current-overwhelming-support). + +
+
+
+
+Can I change my delegate?
+ +Yes, you can re-delegate at any time through the Collective Portal at [vote.obol.org](https://vote.obol.org) + +
+
+
+
+## Staking & stOBOL
+
+Does holding OBOL give me passive income?
+ +Not directly. Only staking OBOL (to receive auto-compounding stOBOL) allows you to earn rewards. + +
+
+
+
+How do I stake OBOL?
+ +Use [stake.obol.org](https://stake.obol.org) to stake. You’ll receive auto-compounding stOBOL in return. + +
+
+
+
+Can I transfer stOBOL?
+ +Yes, stOBOL is a fully transferable ERC-20 token. However, if you transfer it, your direct delegation is lost, and your governance power enters the auto-delegation pool. + +
+
+
+
+Where can I use stOBOL?
+ +stOBOL can be used in DeFi protocols (e.g., as collateral, in LPs, etc.). Integrations are ongoing and will be announced via Discord and Twitter. Integrations are also documented [here](staking-and-stobol.md). + +
+
+
+
+## Token Value & Utility
+
+Can I unstake OBOL?
+ +Yes. You can return stOBOL to the staking contract at anytime without lockup to reclaim your OBOL. Unstaking and restaking interfaces are provided at [stake.obol.org](https://stake.obol.org). + +
+
+
+
+What gives the OBOL token value?
+ +OBOL gains utility through governance rights, staking yield, and its use in DeFi. Long term, its value could be tied to the growth of the Obol Network, including fees, protocol usage, and TVL. + +
+
+
+
+Does OBOL accrue fees?
+ +Currently, OBOL does not accrue protocol revenue. However, the DAO may vote in the future to direct protocol revenue toward token holders or stakers. + +
+
+
+
+_This page is updated regularly. If your question isn’t listed, reach out via Discord or the Governance Forum._
diff --git a/versioned_docs/version-v1.6/community-and-governance/obol-token/token-utility.md b/versioned_docs/version-v1.6/community-and-governance/obol-token/token-utility.md
new file mode 100644
index 0000000000..e4536f6769
--- /dev/null
+++ b/versioned_docs/version-v1.6/community-and-governance/obol-token/token-utility.md
@@ -0,0 +1,46 @@
+---
+sidebar_label: "Token Utility"
+slug: /community-and-governance/obol-token/token-utility
+---
+
+# Token Utility
+
+## **Governance**
+
+OBOL Token holders delegate their voting power to delegates who participate in the Token House decision-making processes. This includes voting on proposals affecting the Obol Collective’s direction, upgrades, and funding allocations. Read more about the Token House [here](../governance/token-house.md).
+
+## **Obol Retroactive Funding (RAF)**
+
+Token holders delegate their voting power to Delegates, who vote on the projects eligible for retroactive funding. Read more about the Obol RAF [here](../governance/raf/).
+
+## **OBOL Token Staking**
+
+As per[ OIP-1](https://community.obol.org/t/oip-1-building-and-enabling-staking-for-the-obol-token/312), OBOL token holders will have the opportunity to stake their tokens, contributing to the security and stability of the Collective by preserving governance while earning rewards and being able to engage in DeFi. Staking involves depositing OBOL tokens in a vault (without lockup) that automatically delegates the Tokens if not done already. In return, stakers receive stOBOL, which automatically accrues OBOL Tokens as rewards as it's price vs OBOL increases.
+
+This staking program will be implemented in phases, allowing the community to gradually engage in and benefit from the system while reinforcing the decentralization of the Obol Collective. For the first six months, the total rewards will be 0.33% of the total supply, providing early participants with attractive rewards. After this period, the staking rewards may be adjusted based on governance proposals and market conditions. This structured rollout ensures a sustainable and rewarding staking experience while reinforcing the decentralization of the Obol Collective.
+
+To get started, simply visit [https://stake.obol.org](https://stake.obol.org) and follow the staking flow — no technical setup required. The interface will guide you through selecting your wallet, choosing the amount to stake, and submitting the transaction.
+
+**You will find more info about the OBOL token staking in the dedicated** [staking-and-stobol.md](staking-and-stobol.md "mention") **section.**
+
+## **DeFi**
+
+Plans are in place to launch several DeFi avenues for the OBOL Token post-TGE, such as liquidity pools, lending protocols (e.g. Morpho) and restaking (e.g. Eigenlayer, Symbiotic).
+
+### Pendle Integration for wstOBOL
+
+_Note: The Pendle integration is not yet live. It is expected to go live in the first half of October 2025. This information is provided in advance for community awareness._
+
+wstOBOL is supported on [Pendle Finance](https://app.pendle.finance), enabling users to access advanced yield strategies with their staked OBOL. wstOBOL is the wrapped version of stOBOL.
+
+For more info on wstOBOL, refer to our [dedicated page](wstobol.md).
+
+Through Pendle, users can isolate and trade the future yield of wstOBOL by buying or selling its **Principal Tokens (PT)** and **Yield Tokens (YT)**.
+
+This opens up new opportunities: holders can lock in fixed yield by purchasing PTs, speculate on rising yield by acquiring YTs, or passively earn through **liquidity provision**, which offers exposure to swap fees and additional PENDLE incentives. Importantly, Pendle pools are **permissionless**, and while the Obol Association has provided initial liquidity to bootstrap the market, anyone can contribute.\
+\
+For more details, refer to the [Pendle Academy](https://pendle.gitbook.io/pendle-academy) and [wstOBOL pool on Pendle](https://app.pendle.finance/trade).
+
+## **More Utility Coming Soon**
+
+Via Token House governance proposals in the [Governance Forum](https://community.obol.org/), the Obol community can add more functionality and utility to the OBOL Token.
diff --git a/versioned_docs/version-v1.6/community-and-governance/obol-token/wstobol.md b/versioned_docs/version-v1.6/community-and-governance/obol-token/wstobol.md
new file mode 100644
index 0000000000..841af39cea
--- /dev/null
+++ b/versioned_docs/version-v1.6/community-and-governance/obol-token/wstobol.md
@@ -0,0 +1,59 @@
+---
+description: "Coming Soon..."
+sidebar_label: "wstOBOL"
+slug: /community-and-governance/obol-token/wstobol
+---
+
+# wstOBOL
+
+## What is wstOBOL?
+
+When you stake OBOL, you receive stOBOL, a non-rebasing, auto-compounding token.
+
+* Your stOBOL balance stays constant in your wallet.
+* The value of each stOBOL relative to OBOL increases over time as staking rewards accrue.
+
+Unlike “plain” LSTs like stETH, stOBOL is designed to preserve governance: each staked token maintains its delegation, ensuring governance always reflects the real economic stake.
+
+**wstOBOL (wrapped stOBOL)** is simply a wrapped version of stOBOL. It **carries the same yield and economics**, with rewards accruing via the same exchange-rate mechanism. The difference lies in integration:
+
+* stOBOL can introduce a minor 1-wei transfer variance due to its governance-preserving accounting.
+* wstOBOL eliminates this by providing a perfectly static balance, making it fully compatible with DeFi protocols that require strict 1:1 transfers.
+
+Think of wstOBOL as the “DeFi-strict” form of stOBOL. It does not change how rewards work, only how the token behaves when integrated into external systems.
+
+### Why does wstOBOL exist?
+
+Some DeFi protocols cannot easily integrate stOBOL’s governance logic. wstOBOL simplifies adoption. stOBOL continues to safeguard governance rights, while wstOBOL ensures smooth DeFi use.
+
+**Not all integrations require wstOBOL.** Some can use stOBOL directly. We will keep this page updated so users know which path to take for each integration. For example, Pendle requires wstOBOL.
+
+## How does wrapping work?
+
+* **Wrapping**: you deposit stOBOL and receive the same amount of wstOBOL.
+* **Unwrapping**: you return wstOBOL and receive the same amount of stOBOL.
+
+The number of tokens is 1:1. The economic value grows over time because **stOBOL’s exchange rate to OBOL increases**, and wstOBOL simply represents the same claim on that growing value.
+
+## User Flows
+
+You can manage wrapping and unwrapping directly on our [staking platform](https://vote.obol.org/dao/token/wrap). The process is fully integrated and intuitive: just head to the staking portal and you’ll see the following options:
+
+* **Stake (OBOL → stOBOL)**: Stake OBOL and receive stOBOL, which auto-compounds and preserves delegation.
+* **Unstake (stOBOL → OBOL)**: Exit staking and redeem more OBOL back from stOBOL.
+* **Wrap (stOBOL → wstOBOL)**: Convert stOBOL into wstOBOL for use in integrations that require strict accounting.
+* **Unwrap (wstOBOL → stOBOL)**: Redeem wstOBOL back into stOBOL 1:1.
+
+## Where can I use wstOBOL?
+
+* **Pendle Finance** (yield trading, fixed/floating yield markets).
+* Future integrations in lending, borrowing, and liquidity protocols.
+
+## Risks & Considerations
+
+* Wrapping/unwrapping requires **gas fees**.
+* UX involves an extra step for users who hold stOBOL and want to access these DeFi apps.
+
+## Learn More
+
+* [Pendle Documentation](https://pendle.gitbook.io/)
diff --git a/versioned_docs/version-v1.6/learn/charon/README.md b/versioned_docs/version-v1.6/learn/charon/README.md
new file mode 100644
index 0000000000..4afbb167ab
--- /dev/null
+++ b/versioned_docs/version-v1.6/learn/charon/README.md
@@ -0,0 +1,7 @@
+---
+sidebar_label: "Charon"
+slug: /learn/charon
+---
+
+# Charon
+
diff --git a/versioned_docs/version-v1.6/learn/charon/charon-cli-reference.md b/versioned_docs/version-v1.6/learn/charon/charon-cli-reference.md
new file mode 100644
index 0000000000..c2531dd1b3
--- /dev/null
+++ b/versioned_docs/version-v1.6/learn/charon/charon-cli-reference.md
@@ -0,0 +1,828 @@
+---
+description: "A go-based middleware client for taking part in Distributed Validator clusters."
+sidebar_label: "CLI Reference"
+slug: /learn/charon/charon-cli-reference
+---
+
+# CLI Reference
+
+The following is a reference for Charon version [`v1.6.1`](https://github.com/ObolNetwork/charon/releases/tag/v1.6.1). Find the latest release on [our Github](https://github.com/ObolNetwork/charon/releases).
+
+The following are the top-level commands available to use.
+
+```markdown
+charon --help
+Charon enables the operation of Ethereum validators in a fault tolerant manner by splitting the validating keys across a group of trusted parties using threshold cryptography.
+
+Usage:
+ charon [command]
+
+Available Commands:
+ alpha Alpha subcommands provide early access to in-development features
+ combine Combine the private key shares of a distributed validator cluster into a set of standard validator private keys
+ completion Generate the autocompletion script for the specified shell
+ create Create artifacts for a distributed validator cluster
+ dkg Participate in a Distributed Key Generation ceremony
+ enr Print the ENR that identifies this client
+ exit Exit a distributed validator.
+ help Help about any command
+ relay Start a libp2p relay server
+ run Run the charon middleware client
+ version Print version and exit
+
+Flags:
+ -h, --help Help for charon
+
+Use "charon [command] --help" for more information about a command.
+```
+
+## The `create` command
+
+The `create` command handles the creation of artifacts needed by Charon to operate.
+
+```markdown
+charon create --help
+Create artifacts for a distributed validator cluster. These commands can be used to facilitate the creation of a distributed validator cluster between a group of operators by performing a distributed key generation ceremony, or they can be used to create a local cluster for single operator use cases.
+
+Usage:
+ charon create [command]
+
+Available Commands:
+ cluster Create private keys and configuration files needed to run a distributed validator cluster locally
+ dkg Create the configuration for a new Distributed Key Generation ceremony using charon dkg
+ enr Create an Ethereum Node Record (ENR) private key to identify this charon client
+
+Flags:
+ -h, --help Help for create
+
+Use "charon create [command] --help" for more information about a command.
+```
+
+### Creating an ENR for Charon
+
+An `enr` is an Ethereum Node Record. It is used to identify this Charon client to its other counterparty Charon clients across the internet.
+
+```markdown
+charon create enr --help
+Create an Ethereum Node Record (ENR) private key to identify this charon client
+
+Usage:
+ charon create enr [flags]
+
+Flags:
+ --data-dir string The directory where charon will store all its internal data. (default ".charon")
+ -h, --help Help for enr
+```
+
+### Create a full cluster locally
+
+The `charon create cluster` command creates a set of distributed validators locally; including the private keys, a `cluster-lock.json` file, and deposit data. This command should only be used for solo-operation of distributed validators. To run a distributed validator cluster with a group of operators, it is preferable to create these artifacts using the [DV Launchpad](../intro/launchpad.md) and the `charon dkg` command. That way, no single operator custodies all of the private keys to a distributed validator.
+
+:::warning
+This command produces new distributed validator private keys or handles and splits pre-existing traditional validator private keys, please use caution and keep these private keys securely backed up and secret.
+:::
+
+```markdown
+charon create cluster --help
+Creates a local charon cluster configuration including validator keys, charon p2p keys, cluster-lock.json and deposit-data.json file(s). See flags for supported features.
+
+Usage:
+ charon create cluster [flags]
+
+Flags:
+ --cluster-dir string The target folder to create the cluster in. (default "./")
+ --compounding Enable compounding rewards for validators by using 0x02 withdrawal credentials.
+ --consensus-protocol string Preferred consensus protocol name for the cluster. Selected automatically when not specified.
+ --definition-file string Optional path to a cluster definition file or an HTTP URL. This overrides all other configuration flags.
+ --deposit-amounts ints List of partial deposit amounts (integers) in ETH. Values must sum up to at least 32ETH.
+ --execution-client-rpc-endpoint string The address of the execution engine JSON-RPC API.
+ --fee-recipient-addresses strings Comma separated list of Ethereum addresses of the fee recipient for each validator. Either provide a single fee recipient address or fee recipient addresses for each validator.
+ -h, --help Help for cluster
+ --insecure-keys Generates insecure keystore files. This should never be used. It is not supported on mainnet.
+ --keymanager-addresses strings Comma separated list of keymanager URLs to import validator key shares to. Note that multiple addresses are required, one for each node in the cluster, with node0's keyshares being imported to the first address, node1's keyshares to the second, and so on.
+ --keymanager-auth-tokens strings Authentication bearer tokens to interact with the keymanager URLs. Don't include the "Bearer" symbol, only include the api-token.
+ --name string The cluster name
+ --network string Ethereum network to create validators for. Options: mainnet, goerli, sepolia, hoodi, holesky, gnosis, chiado.
+ --nodes int The number of charon nodes in the cluster. Minimum is 3.
+ --num-validators int The number of distributed validators needed in the cluster.
+ --publish Publish lock file to obol-api.
+ --publish-address string The URL to publish the lock file to. (default "https://api.obol.tech/v1")
+ --split-existing-keys Split an existing validator's private key into a set of distributed validator private key shares. Does not re-create deposit data for this key.
+ --split-keys-dir string Directory containing keys to split. Expects keys in keystore-*.json and passwords in keystore-*.txt. Requires --split-existing-keys.
+ --target-gas-limit uint Preferred target gas limit for transactions. (default 60000000)
+ --testnet-chain-id uint Chain ID of the custom test network.
+ --testnet-fork-version string Genesis fork version of the custom test network (in hex).
+ --testnet-genesis-timestamp int Genesis timestamp of the custom test network.
+ --testnet-name string Name of the custom test network.
+ --threshold int Optional override of threshold required for signature reconstruction. Defaults to ceil(n*2/3) if zero. Warning, non-default values decrease security.
+ --withdrawal-addresses strings Comma separated list of Ethereum addresses to receive the returned stake and accrued rewards for each validator. Either provide a single withdrawal address or withdrawal addresses for each validator.
+ --zipped Create a tar archive compressed with gzip of the cluster directory after creation.
+```
+
+### Creating the configuration for a DKG Ceremony
+
+This `charon create dkg` command creates a `cluster_definition.json` file used for the `charon dkg` command.
+
+```markdown
+charon create dkg --help
+Create a cluster definition file that will be used by all participants of a DKG.
+
+Usage:
+ charon create dkg [flags]
+
+Flags:
+ --compounding Enable compounding rewards for validators by using 0x02 withdrawal credentials.
+ --consensus-protocol string Preferred consensus protocol name for the cluster. Selected automatically when not specified.
+ --deposit-amounts ints List of partial deposit amounts (integers) in ETH. Values must sum up to at least 32ETH.
+ --dkg-algorithm string DKG algorithm to use; default, frost (default "default")
+ --execution-client-rpc-endpoint string The address of the execution engine JSON-RPC API.
+ --fee-recipient-addresses strings Comma separated list of Ethereum addresses of the fee recipient for each validator. Either provide a single fee recipient address or fee recipient addresses for each validator.
+ -h, --help Help for dkg
+ --name string Optional cosmetic cluster name
+ --network string Ethereum network to create validators for. Options: mainnet, goerli, sepolia, hoodi, holesky, gnosis, chiado. (default "mainnet")
+ --num-validators int The number of distributed validators the cluster will manage (32ETH+ staked for each). (default 1)
+ --operator-addresses strings Comma-separated list of each operator's Ethereum address.
+ --operator-enrs strings Comma-separated list of each operator's Charon ENR address.
+ --output-dir string The folder to write the output cluster-definition.json file to. (default ".charon")
+ --publish Creates an invitation to the DKG ceremony on the DV Launchpad. Terms and conditions apply.
+ --publish-address string The URL to publish the cluster to. (default "https://api.obol.tech/v1")
+ --target-gas-limit uint Preferred target gas limit for transactions. (default 60000000)
+ -t, --threshold int Optional override of threshold required for signature reconstruction. Defaults to ceil(n*2/3) if zero. Warning, non-default values decrease security.
+ --withdrawal-addresses strings Comma separated list of Ethereum addresses to receive the returned stake and accrued rewards for each validator. Either provide a single withdrawal address or withdrawal addresses for each validator.
+```
+
+## The `dkg` command
+
+### Performing a DKG Ceremony
+
+The `charon dkg` command takes a `cluster_definition.json` file that instructs Charon on the terms of a new distributed validator cluster to be created. Charon establishes communication with the other nodes identified in the file, performs a distributed key generation ceremony to create the required threshold private keys, and signs deposit data for each new distributed validator. The command outputs the `cluster-lock.json` file and key shares for each Distributed Validator created.
+
+```markdown
+charon dkg --help
+Participate in a distributed key generation ceremony for a specific cluster definition that creates
+distributed validator key shares and a final cluster lock configuration. Note that all other cluster operators should run
+this command at the same time.
+
+Usage:
+ charon dkg [flags]
+
+Flags:
+ --data-dir string The directory where charon will store all its internal data. (default ".charon")
+ --definition-file string The path to the cluster definition file or an HTTP URL. (default ".charon/cluster-definition.json")
+ --execution-client-rpc-endpoint string The address of the execution engine JSON-RPC API.
+ -h, --help Help for dkg
+ --keymanager-address string The keymanager URL to import validator keyshares.
+ --keymanager-auth-token string Authentication bearer token to interact with keymanager API. Don't include the "Bearer" symbol, only include the api-token.
+ --log-color string Log color; auto, force, disable. (default "auto")
+ --log-format string Log format; console, logfmt or json (default "console")
+ --log-level string Log level; debug, info, warn or error (default "info")
+ --log-output-path string Path in which to write on-disk logs.
+ --no-verify Disables cluster definition and lock file verification.
+ --p2p-disable-reuseport Disables TCP port reuse for outgoing libp2p connections.
+ --p2p-external-hostname string The DNS hostname advertised by libp2p. This may be used to advertise an external DNS.
+ --p2p-external-ip string The IP address advertised by libp2p. This may be used to advertise an external IP.
+ --p2p-relays strings Comma-separated list of libp2p relay URLs or multiaddrs. (default [https://0.relay.obol.tech,https://2.relay.obol.dev,https://1.relay.obol.tech])
+ --p2p-tcp-address strings Comma-separated list of listening TCP addresses (ip and port) for libP2P traffic. Empty default doesn't bind to local port therefore only supports outgoing connections.
+ --p2p-udp-address strings Comma-separated list of listening UDP addresses (ip and port) for libP2P traffic. Empty default doesn't bind to local port therefore only supports outgoing connections.
+ --publish Publish the created cluster to a remote API.
+ --publish-address string The URL to publish the cluster to. (default "https://api.obol.tech/v1")
+ --publish-timeout duration Timeout for publishing a cluster, consider increasing if the cluster contains more than 200 validators. (default 30s)
+ --shutdown-delay duration Graceful shutdown delay. (default 1s)
+ --timeout duration Timeout for the DKG process, should be increased if DKG times out. (default 1m0s)
+ --zipped Create a tar archive compressed with gzip of the target directory after creation.
+```
+
+## The `run` command
+
+### Run the Charon middleware
+
+This `run` command accepts a `cluster-lock.json` file that was created either via a `charon create cluster` command or `charon dkg`. This lock file outlines the nodes in the cluster and the distributed validators they operate on behalf of.
+
+```markdown
+charon run --help
+Starts the long-running Charon middleware process to perform distributed validator duties.
+
+Usage:
+ charon run [flags]
+
+Flags:
+ --beacon-node-endpoints strings Comma separated list of one or more beacon node endpoint URLs.
+ --beacon-node-headers strings Comma separated list of headers formatted as header=value
+ --beacon-node-submit-timeout duration Timeout for the submission-related HTTP requests Charon makes to the configured beacon nodes. (default 2s)
+ --beacon-node-timeout duration Timeout for the HTTP requests Charon makes to the configured beacon nodes. (default 2s)
+ --builder-api Enables the builder api. Will only produce builder blocks. Builder API must also be enabled on the validator client. Beacon node must be connected to a builder-relay to access the builder network.
+ --consensus-protocol string Preferred consensus protocol name for the node. Selected automatically when not specified.
+ --debug-address string Listening address (ip and port) for the pprof and QBFT debug API. It is not enabled by default.
+ --execution-client-rpc-endpoint string The address of the execution engine JSON-RPC API.
+ --fallback-beacon-node-endpoints strings A list of beacon nodes to use if the primary list are offline or unhealthy.
+ --feature-set string Minimum feature set to enable by default: alpha, beta, or stable. Warning: modify at own risk. (default "stable")
+ --feature-set-disable strings Comma-separated list of features to disable, overriding the default minimum feature set.
+ --feature-set-enable strings Comma-separated list of features to enable, overriding the default minimum feature set.
+ --graffiti strings Comma-separated list or single graffiti string to include in block proposals. List maps to validator's public key in cluster lock. Appends "OBHow can I stay up to date on OBOL news?
+ +Join our [Discord](https://discord.obol.org), follow [@ObolNetwork](https://x.com/Obol_Collective), and check our [Forum](https://community.obol.org) for governance and integration updates. + +All of Mellow DVV TVL
+ Lido SDVT Module validators added post Jan 13th Airdrop
+ Lido CSM TVL ran by Obol DVs
- Mellow Depositors: 80% for CSM TVL, 90% for SDVT TVL
- Rest to Node Operators
+
+
+
+Governor Contract
+ +* **Address:** [`0xcB1622185A0c62A80494bEde05Ba95ef29Fbf85c`](https://etherscan.io/address/0xcB1622185A0c62A80494bEde05Ba95ef29Fbf85c) + +- **Purpose:** Manages onchain proposal lifecycle and voting logic for Token House governance. +- **What you can find onchain:** + * Voting thresholds + * Quorum settings, + * Delay/period configs, + * Proposal and vote history. + +
+
+
+
+Obol Staker
+ +* **Address:** [`0x30641013934ec7625c9e73a4D63aab4201004259`](https://etherscan.io/address/0x30641013934ec7625c9e73a4D63aab4201004259) + +- **Purpose:** This is the base layer of the Obol staking system. It facilitates the basic mechanics of staking, such as managing deposits, forwarding governance delegation, and streaming rewards based on earning power. +- **What you can find onchain:** + * Total OBOL staked in the contract + * Stake, earning power, rewards and balances on a granular, per-deposit basis + * Current reward rate and configuration + * Contract events (e.g. `Staked`, `Withdrawn`) + * Interactions for staking/unstaking + +
+
+
+
+stOBOL (ERC-20 Token Contract)
+ +* **Address:** [`0x6590cBBCCbE6B83eF3774Ef1904D86A7B02c2fCC`](https://etherscan.io/address/0x6590cBBCCbE6B83eF3774Ef1904D86A7B02c2fCC) +* **Purpose:** A liquid ERC-20 representation of staked OBOL built on top of the Obol Staker. It adds features like transferability, reward auto compounding, and the ability to use a staked OBOL position in other protocols. Holders retain the ability to delegate their staked tokens to the governance delagate of their choice. +* **What you can find onchain:** + * ERC-20 metadata (name, symbol, decimals) + * Total supply and balances + * Transfer history + * Allowances / approvals + * Voting power interface (via `getVotes` and `delegates`) + * Event logs for delegation changes + +
+
+
+
+Reward Notifier
+ +* **Address:** [`0x384dd81047F88eE35DE75DA1149943B8e62d8802`](https://etherscan.io/address/0x384dd81047F88eE35DE75DA1149943B8e62d8802) +* **Purpose:** Manages the distribution of tokens to the staking contract so they can be streamed as rewards to stakers. +* **What you can find onchain:** + * Current and past reward rate values + * Administrative role settings (who can push updates) + * Timing/config changes made through proposals + * Events like `RewardRateUpdated` + +
+
+
+
+## Learn more about...
+
+[token-utility.md](token-utility.md)
+[staking-and-stobol.md](staking-and-stobol.md)
+[token-distribution-and-liquidity.md](token-distribution-and-liquidity.md)
+[token-holders-faq.md](token-holders-faq.md)
+[tge-faq.md](tge-faq.md)
diff --git a/versioned_docs/version-v1.7/community-and-governance/obol-token/staking-and-stobol.md b/versioned_docs/version-v1.7/community-and-governance/obol-token/staking-and-stobol.md
new file mode 100644
index 0000000000..f2c58623fa
--- /dev/null
+++ b/versioned_docs/version-v1.7/community-and-governance/obol-token/staking-and-stobol.md
@@ -0,0 +1,78 @@
+---
+description: "This page explains how OBOL staking works, the role of stOBOL, and what happens when tokens are delegated, transferred, or used in DeFi protocols. You can stake and unstake OBOL via stake.obol.org."
+sidebar_label: "Staking & stOBOL"
+slug: /community-and-governance/obol-token/staking-and-stobol
+---
+
+# Staking & stOBOL
+
+## Overview
+
+Staking allows OBOL token holders to participate in governance while earning rewards. When you stake OBOL, you receive a liquid staking token called stOBOL. This token is transferable, composable in DeFi, and earns staking rewards while maintaining governance power, as long as it remains in the same address that originally staked the OBOL Tokens. It represents a flexible and powerful tool to both support the network and engage in the broader ecosystem.
+
+stOBOL unlocks new opportunities for participation. It is yield-bearing, enables seamless governance engagement, and is expected to be increasingly integrated across DeFi platforms. If it is transferred elsewhere, direct delegation is removed and governance power is reassigned an Auto-Delegate, preventing governance attacks. The voting behaviour of the Auto-Delegate is determined by the active strategy.
+
+### To Recap
+
+* stOBOL is a liquid staking token received when you stake OBOL.
+* It allows users to earn staking rewards which auto-compound while retaining governance power.
+* stOBOL is fully transferable (ERC-20) and can be used in DeFi (e.g., as collateral).
+
+## Key Concepts
+
+Auto Delegate (Overwhelming Support Strategy)
+ +* **Address:** [`0xCa28852B6Fc15EbD95b17c875D5Eb14b08579158`](https://etherscan.io/address/0xCa28852B6Fc15EbD95b17c875D5Eb14b08579158) +* **Purpose:** Implements the “Overwhelming Support” auto-delegation strategy. This contract casts votes on behalf of un-delegated or transferred stOBOL when proposals receive strong community support. This mechanism uses tokens that would otherwise not be available in governance to ensure uncontroversial proposals will meet quorum. +* **What you can find onchain:** + * Parameters like `supportThreshold`, `subQuorumBips`, and `votingWindow` + * Proposals voted on by the strategy + * Vote power amounts cast + * Event logs showing execution activity + * Wallets or protocols interacting with auto-delegation logic + +| Feature | OBOL | stOBOL |
| Governance voting | ✅ (direct or delegated) | ✅ (only if kept on original staking address, otherwise governance power reallocated to the Auto-Delegate) |
| Transferable | ✅ | ✅ |
| Used in DeFi | ✅ (less efficient, not yield-bearing) | ✅ (yield-bearing) |
| Earns staking rewards | ❌ | ✅ |
+
+
+
+How do I unlock my OBOL Tokens received in the Airdrop?
+ +Starting May 7th at 11:00 AM UTC, visit [**claim.obol.org**](https://claim.obol.org), click **“Unlock”**, and follow the steps. + +
+
+
+
+When is the official TGE date and time?
+ +The OBOL Token will be listed on exchanges for deposit, trading and withdrawals on May 7th, 2025 at 11:00 AM UTC + +
+
+
+
+Where will the OBOL Token be listed for trading?
+ +* **Binance**, **Bybit**, **Bitget**, **Gate.io**, **MEXC**, and others. + +- Check [CoinGecko](https://coingecko.com) or [CoinMarketCap](https://coinmarketcap.com/currencies/obol/) for the most up-to-date list. + +
+
+
+
+What are the exact listing times on exchanges?
+ +* **Binance Alpha** – _May 7 at 10:00 AM UTC_ + +- **Binance Futures** – _May 7 at 10:30 AM UTC_ + +* **Bybit, Gate.io, Bitget, MEXC** – _May 7 at 11:00 AM UTC_ + +
+
+
+
+Where can I track the price of the OBOL Token?
+ +[CoinGecko](https://coingecko.com) and [CoinMarketCap](https://coinmarketcap.com/currencies/obol/) + +
+
+
+
+Where can I buy the OBOL Token onchain?
+ +* A **Uniswap v3 pool** will be seeded with initial liquidity. + +- The contract address is [here](https://etherscan.io/address/0x57F52C9faa6D40c5163D76b8D7dD81ddB7c95434). + +* Anyone can start a pool. Check live prices via **CoinGecko**, or **CoinMarketCap**. + +
+
+
+
+## **Token Supply & Distribution**
+
+Are there any country restrictions for claiming or trading the OBOL Token?
+ +* Yes. Each venue has its own restrictions. + +- Unlocking OBOL Tokens received through the Airdrop is subject to the same geo restrictions as claiming. + +
+
+
+
+What is the circulating supply at TGE?
+ +Approximately 19**%**. Full breakdown is on [CoinMarketCap](https://coinmarketcap.com/currencies/obol/). + +
+
+
+
+Why does Etherscan show 374M tokens instead of 500M?
+ +For legal and tax reasons, not all tokens are minted yet. + +
+
+
+
+How many tokens were allocated to CoinList, and how many unlock at TGE?
+ +Details available on the [**Coinlist Sale Page**](https://coinlist.co/obol). + +
+
+
+
+## **Unlocks & Vesting**
+
+When were unclaimed airdrop tokens returned to the treasury?
+ +As approved by [**OIP-2**](https://community.obol.org/t/oip-2-unlock-obol-token/317), they were [returned](https://etherscan.io/tx/0x738b4c252bb4613b9945e3b6426ec4ee510c6cdb86027fe20d533c4799a3a331) on **May 2, 2025**. + +
+
+
+
+Can CoinList participants claim at TGE?
+ +Yes, a portion of their tokens will unlock on May 7th at 11AM UTC per the [**Coinlist terms**](https://coinlist.co/obol). + +
+
+
+
+Will RAF1 tokens be available at TGE?
+ +RAF1 tokens will be distributed **shortly after TGE**. + +
+
+
+
+## **Token Utility**
+
+When will OBOL Token incentives be claimable?
+ +Starting May 12, 2025 + +
+
+
+
+What is the utility of the OBOL Token?
+ +See the top of the page + +
+
+
+
+What is stOBOL?
+ +A staked version of the OBOL Token that can be used in DeFi or with restaking platforms. + +
+
+
+
+Can the OBOL or stOBOL Tokens be used in DeFi?
+ +Yes. More info will follow **post-TGE**. + +
+
+
diff --git a/versioned_docs/version-v1.7/community-and-governance/obol-token/token-distribution-and-liquidity.md b/versioned_docs/version-v1.7/community-and-governance/obol-token/token-distribution-and-liquidity.md
new file mode 100644
index 0000000000..649045f286
--- /dev/null
+++ b/versioned_docs/version-v1.7/community-and-governance/obol-token/token-distribution-and-liquidity.md
@@ -0,0 +1,42 @@
+---
+sidebar_label: "Token Distribution & Liquidity"
+slug: /community-and-governance/obol-token/token-distribution-and-liquidity
+---
+
+# Token Distribution & Liquidity
+
+## Token Distribution
+
+The total supply is capped at 500 million tokens. The full supply is not immediately circulating and tokens will unlock over the coming months and years.
+
+
+
+### **Ecosystem Treasury & Retroactive Funding (RAF) | 38.8%**
+
+A significant portion of OBOL Tokens are allocated to the ecosystem treasury to drive innovation and decentralization. These funds support different initiatives, for example, [**SQUAD Goals**](https://community.obol.org/t/oip-3-obol-collective-2025-goals-proposal/)**, Grants & Incentives Funding** contributors who help to the growth of the protocol and the broader Collective and [**Retroactive Funding (RAF)**](https://docs.obol.org/community-and-governance/governance/raf)**,** rewarding contributions that have positively impacted the Obol Collective. Over time, the Obol Association plans to give additional control over these tokens to the community.
+
+### **Investors | 23.7%**
+
+Early investors played a key role in bringing the Obol Collective to life. This allocation ensures that individuals and entities that provided early financial support are fairly rewarded while adhering to best practices in responsible token vesting.
+
+### **Team | 19%**
+
+To attract and retain top-tier talent, a portion of tokens is reserved for core contributors, founders, and developers. This allocation aligns with the long-term vision of the project and is subject to a lock-up period similar to the one of investors.
+
+### **Community Incentives | 7.5%**
+
+To promote awareness and adoption, OBOL tokens will be used for user-focused initiatives that drive adoption of Obol DVs. The first of these initiative is the [Obol Incentives Program.](https://obol.org/incentives)
+
+### **Airdrop | 7.5%**
+
+As a community-first initiative, Obol has rewarded early contributors and supporters through a retroactive airdrop. This ensures ongoing participation in the Collective and strengthens the decentralized operator ecosystem. For more information about the Airdrop distribution, please [see this blog article](https://blog.obol.org/airdrop/).
+
+### **Public Sale via Coinlist | 3.6%**
+
+To ensure broad and fair token distribution, a portion of OBOL Tokens have been made available through a [Coinlist public sale](https://coinlist.co/obol) at better terms than investors. 50% of tokens purchased in the token sale will be fully unlocked and transferable at TGE, followed by a 12 month linear unlock for the remainder of the tokens.
+
+## Token Liquidity
+
+Once the token becomes transferable, the community will be able to track the distribution schedule and observe how the circulating supply increases over time according to the structured unlock plan.
+
+
diff --git a/versioned_docs/version-v1.7/community-and-governance/obol-token/token-holders-faq.md b/versioned_docs/version-v1.7/community-and-governance/obol-token/token-holders-faq.md
new file mode 100644
index 0000000000..4876719cca
--- /dev/null
+++ b/versioned_docs/version-v1.7/community-and-governance/obol-token/token-holders-faq.md
@@ -0,0 +1,135 @@
+---
+description: "This page is designed to answer the most common questions from OBOL token holders, particularly those holding liquid OBOL or stOBOL."
+sidebar_label: "Token Holders FAQ"
+slug: /community-and-governance/obol-token/token-holders-faq
+---
+
+# Token Holders FAQ
+
+## General
+
+Are there incentives for providing DeFi liquidity with OBOL or stOBOL?
+ +**Not at TGE**, but proposals for incentives can be submitted via governance. + +
+
+
+
+What is the OBOL token used for?
+ +OBOL is the governance token of the Obol Collective. It enables holders to participate in on-chain governance by voting directly or delegating their voting power to delegates. + +OBOL is also used in the [RAF](../governance/raf/), where token holders delegate to vote on which contributors should receive retroactive funding for valuable work. + +In addition, OBOL can be staked to receive stOBOL, a liquid token that accrues staking rewards and retains governance power as long as it remains in the staker’s wallet. This staking mechanism supports long-term alignment and decentralized ownership. + +Finally, both OBOL and stOBOL are being integrated into DeFi protocols, such as liquidity pools, lending platforms (e.g. Morpho), and restaking services (e.g. Eigenlayer, Symbiotic), with more utility expected over time as shaped by community governance. + +
+
+
+
+What is stOBOL?
+ +stOBOL is the liquid staking token received when you stake OBOL. It earns staking rewards and can be used in DeFi. Holding stOBOL in your wallet preserves your governance power. More info in [staking-and-stobol.md](staking-and-stobol.md "mention") + +
+
+
+
+## Delegation & Governance
+
+Where can I see OBOL price, supply, and markets?
+ +You can track OBOL on [CoinMarketCap](https://www.coingecko.com/en/coins/obol-2) or [Coingecko](https://coingecko.com). These pages include market data, supply information, and live price charts. + +
+
+
+
+How do I delegate my OBOL tokens?
+ +You can delegate via [vote.obol.org](https://vote.obol.org/dao/delegates). Connect your wallet, choose a delegate, and confirm the delegation transaction. + +
+
+
+
+What happens if I stake OBOL?
+ +You receive stOBOL, which maintains your delegation as long as it stays in your wallet. Once transferred (e.g., to a DeFi protocol), you lose the individual delegation. Voting power is then routed via an [auto-delegation strategy](staking-and-stobol.md#how-the-auto-delegate-strategy-works-current-overwhelming-support). + +
+
+
+
+Can I change my delegate?
+ +Yes, you can re-delegate at any time through the Collective Portal at [vote.obol.org](https://vote.obol.org) + +
+
+
+
+## Staking & stOBOL
+
+Does holding OBOL give me passive income?
+ +Not directly. Only staking OBOL (to receive auto-compounding stOBOL) allows you to earn rewards. + +
+
+
+
+How do I stake OBOL?
+ +Use [stake.obol.org](https://stake.obol.org) to stake. You’ll receive auto-compounding stOBOL in return. + +
+
+
+
+Can I transfer stOBOL?
+ +Yes, stOBOL is a fully transferable ERC-20 token. However, if you transfer it, your direct delegation is lost, and your governance power enters the auto-delegation pool. + +
+
+
+
+Where can I use stOBOL?
+ +stOBOL can be used in DeFi protocols (e.g., as collateral, in LPs, etc.). Integrations are ongoing and will be announced via Discord and Twitter. Integrations are also documented [here](token-utility.md). + +
+
+
+
+## Token Value & Utility
+
+Can I unstake OBOL?
+ +Yes. You can return stOBOL to the staking contract at anytime without lockup to reclaim your OBOL. Unstaking and restaking interfaces are provided at [stake.obol.org](https://stake.obol.org). + +
+
+
+
+What gives the OBOL token value?
+ +OBOL gains utility through governance rights, staking yield, and its use in DeFi. Long term, its value could be tied to the growth of the Obol Network, including fees, protocol usage, and TVL. + +
+
+
+
+Does OBOL accrue fees?
+ +Currently, OBOL does not accrue protocol revenue. However, the DAO may vote in the future to direct protocol revenue toward token holders or stakers. + +
+
+
+
+_This page is updated regularly. If your question isn’t listed, reach out via Discord or the Governance Forum._
diff --git a/versioned_docs/version-v1.7/community-and-governance/obol-token/token-utility.md b/versioned_docs/version-v1.7/community-and-governance/obol-token/token-utility.md
new file mode 100644
index 0000000000..4a4e0f112c
--- /dev/null
+++ b/versioned_docs/version-v1.7/community-and-governance/obol-token/token-utility.md
@@ -0,0 +1,42 @@
+---
+sidebar_label: "Token Utility"
+slug: /community-and-governance/obol-token/token-utility
+---
+
+# Token Utility
+
+## **Governance**
+
+OBOL Token holders delegate their voting power to delegates who participate in the Token House decision-making processes. This includes voting on proposals affecting the Obol Collective’s direction, upgrades, and funding allocations. Read more about the Token House [here](../governance/token-house.md).
+
+## **Obol Retroactive Funding (RAF)**
+
+Token holders delegate their voting power to Delegates, who vote on the projects eligible for retroactive funding. Read more about the Obol RAF [here](../governance/raf/).
+
+## **OBOL Token Staking**
+
+As per[ OIP-1](https://community.obol.org/t/oip-1-building-and-enabling-staking-for-the-obol-token/312), OBOL token holders will have the opportunity to stake their tokens, contributing to the security and stability of the Collective by preserving governance while earning rewards and being able to engage in DeFi. Staking involves depositing OBOL tokens in a vault (without lockup) that automatically delegates the Tokens if not done already. In return, stakers receive stOBOL, which automatically accrues OBOL Tokens as rewards as it's price vs OBOL increases.
+
+This staking program will be implemented in phases, allowing the community to gradually engage in and benefit from the system while reinforcing the decentralization of the Obol Collective. For the first six months, the total rewards will be 0.33% of the total supply, providing early participants with attractive rewards. After this period, the staking rewards may be adjusted based on governance proposals and market conditions. This structured rollout ensures a sustainable and rewarding staking experience while reinforcing the decentralization of the Obol Collective.
+
+To get started, simply visit [https://stake.obol.org](https://stake.obol.org) and follow the staking flow — no technical setup required. The interface will guide you through selecting your wallet, choosing the amount to stake, and submitting the transaction.
+
+**You will find more info about the OBOL token staking in the dedicated** [staking-and-stobol.md](staking-and-stobol.md "mention") **section.**
+
+## **DeFi**
+
+Plans are in place to launch several DeFi avenues for the OBOL Token post-TGE, such as liquidity pools, lending protocols (e.g. Morpho) and restaking (e.g. Eigenlayer, Symbiotic).
+
+### Pendle Integration for stOBOL
+
+wstOBOL is supported on [Pendle Finance](https://app.pendle.finance/trade/pools/0x78954a6a2c2a08455f92e47c4e587feb7467bf37/zap/in?chain=ethereum), enabling users to access advanced yield strategies with their staked OBOL. wstOBOL is the wrapped version of stOBOL.
+
+For more info on wstOBOL, refer to our [dedicated page](wstobol.md).
+
+Through Pendle, users can isolate and trade the future yield of wstOBOL by buying or selling its **Principal Tokens (PT)** and **Yield Tokens (YT)**.
+
+This opens up new opportunities: holders can lock in fixed yield by purchasing PTs, speculate on rising yield by acquiring YTs, or passively earn through **liquidity provision**, which offers exposure to swap fees and additional PENDLE incentives. Importantly, Pendle pools are **permissionless**, and while the Obol Association has provided initial liquidity to bootstrap the market, anyone can contribute. For more details, refer to the [Pendle Academy](https://pendle.gitbook.io/pendle-academy) and [wstOBOL pool on Pendle](https://app.pendle.finance/trade).
+
+## **More Utility Coming Soon**
+
+Via Token House governance proposals in the [Governance Forum](https://community.obol.org/), the Obol community can add more functionality and utility to the OBOL Token.
diff --git a/versioned_docs/version-v1.7/community-and-governance/obol-token/wstobol.md b/versioned_docs/version-v1.7/community-and-governance/obol-token/wstobol.md
new file mode 100644
index 0000000000..cb6a5ccef2
--- /dev/null
+++ b/versioned_docs/version-v1.7/community-and-governance/obol-token/wstobol.md
@@ -0,0 +1,51 @@
+---
+sidebar_label: "wstOBOL"
+slug: /community-and-governance/obol-token/wstobol
+---
+
+# wstOBOL
+
+### What is wstOBOL? {#what-is-wstobol}
+When you stake OBOL, you receive stOBOL, a non-rebasing, auto-compounding token.
+
+* Your stOBOL balance stays constant in your wallet.
+* The value of each stOBOL relative to OBOL increases over time as staking rewards accrue.
+
+Unlike “plain” LSTs like stETH, stOBOL is designed to preserve governance: each staked token maintains its delegation, ensuring governance always reflects the real economic stake.
+
+**wstOBOL (wrapped stOBOL)** is simply a wrapped version of stOBOL. It **carries the same yield and economics**, with rewards accruing via the same exchange-rate mechanism. The difference lies in integration:
+
+* stOBOL can introduce a minor 1-wei transfer variance due to its governance-preserving accounting.
+* wstOBOL eliminates this by providing a perfectly static balance, making it fully compatible with DeFi protocols that require strict 1:1 transfers.
+
+Think of wstOBOL as the “DeFi-strict” form of stOBOL. It does not change how rewards work, only how the token behaves when integrated into external systems.
+
+#### Why does wstOBOL exist? {#why-does-wstobol-exist}
+Some DeFi protocols cannot easily integrate stOBOL’s governance logic. wstOBOL simplifies adoption. stOBOL continues to safeguard governance rights, while wstOBOL ensures smooth DeFi use.
+
+**Not all integrations require wstOBOL.** Some can use stOBOL directly. We will keep this page updated so users know which path to take for each integration. For example, Pendle requires wstOBOL.
+
+### How does wrapping work? {#how-does-wrapping-work}
+* **Wrapping**: you deposit stOBOL and receive the same amount of wstOBOL.
+* **Unwrapping**: you return wstOBOL and receive the same amount of stOBOL.
+
+The number of tokens is 1:1. The economic value grows over time because **stOBOL’s exchange rate to OBOL increases**, and wstOBOL simply represents the same claim on that growing value.
+
+### User Flows {#user-flows}
+You can manage wrapping and unwrapping directly on our [staking platform](https://vote.obol.org/dao/token/wrap). The process is fully integrated and intuitive: just head to the staking portal and you’ll see the following options:
+
+* **Stake (OBOL → stOBOL)**: Stake OBOL and receive stOBOL, which auto-compounds and preserves delegation.
+* **Unstake (stOBOL → OBOL)**: Exit staking and redeem more OBOL back from stOBOL.
+* **Wrap (stOBOL → wstOBOL)**: Convert stOBOL into wstOBOL for use in integrations that require strict accounting.
+* **Unwrap (wstOBOL → stOBOL)**: Redeem wstOBOL back into stOBOL 1:1.
+
+### Where can I use wstOBOL? {#where-can-i-use-wstobol}
+* [**Pendle Finance**](https://app.pendle.finance/trade/pools/0x78954a6a2c2a08455f92e47c4e587feb7467bf37/zap/in?chain=ethereum) (yield trading, fixed/floating yield markets).
+* Future integrations in lending, borrowing, and liquidity protocols.
+
+### Risks & Considerations {#risks-and-considerations}
+* Wrapping/unwrapping requires **gas fees**.
+* UX involves an extra step for users who hold stOBOL and want to access these DeFi apps.
+
+### Learn More {#learn-more}
+* [Pendle Documentation](https://pendle.gitbook.io/)
diff --git a/versioned_docs/version-v1.7/learn/charon/README.md b/versioned_docs/version-v1.7/learn/charon/README.md
new file mode 100644
index 0000000000..4afbb167ab
--- /dev/null
+++ b/versioned_docs/version-v1.7/learn/charon/README.md
@@ -0,0 +1,7 @@
+---
+sidebar_label: "Charon"
+slug: /learn/charon
+---
+
+# Charon
+
diff --git a/versioned_docs/version-v1.7/learn/charon/charon-cli-reference.md b/versioned_docs/version-v1.7/learn/charon/charon-cli-reference.md
new file mode 100644
index 0000000000..3612f45445
--- /dev/null
+++ b/versioned_docs/version-v1.7/learn/charon/charon-cli-reference.md
@@ -0,0 +1,831 @@
+---
+description: "A go-based middleware client for taking part in Distributed Validator clusters."
+sidebar_label: "CLI Reference"
+slug: /learn/charon/charon-cli-reference
+---
+
+# CLI Reference
+
+The following is a reference for Charon version [`v1.7.0`](https://github.com/ObolNetwork/charon/releases/tag/v1.7.0). Find the latest release on [our Github](https://github.com/ObolNetwork/charon/releases).
+
+The following are the top-level commands available to use.
+
+```markdown
+charon --help
+Charon enables the operation of Ethereum validators in a fault tolerant manner by splitting the validating keys across a group of trusted parties using threshold cryptography.
+
+Usage:
+ charon [command]
+
+Available Commands:
+ alpha Alpha subcommands provide early access to in-development features
+ combine Combine the private key shares of a distributed validator cluster into a set of standard validator private keys
+ completion Generate the autocompletion script for the specified shell
+ create Create artifacts for a distributed validator cluster
+ dkg Participate in a Distributed Key Generation ceremony
+ enr Print the ENR that identifies this client
+ exit Exit a distributed validator.
+ help Help about any command
+ relay Start a libp2p relay server
+ run Run the charon middleware client
+ version Print version and exit
+
+Flags:
+ -h, --help Help for charon
+
+Use "charon [command] --help" for more information about a command.
+```
+
+## The `create` command
+
+The `create` command handles the creation of artifacts needed by Charon to operate.
+
+```markdown
+charon create --help
+Create artifacts for a distributed validator cluster. These commands can be used to facilitate the creation of a distributed validator cluster between a group of operators by performing a distributed key generation ceremony, or they can be used to create a local cluster for single operator use cases.
+
+Usage:
+ charon create [command]
+
+Available Commands:
+ cluster Create private keys and configuration files needed to run a distributed validator cluster locally
+ dkg Create the configuration for a new Distributed Key Generation ceremony using charon dkg
+ enr Create an Ethereum Node Record (ENR) private key to identify this charon client
+
+Flags:
+ -h, --help Help for create
+
+Use "charon create [command] --help" for more information about a command.
+```
+
+### Creating an ENR for Charon
+
+An `enr` is an Ethereum Node Record. It is used to identify this Charon client to its other counterparty Charon clients across the internet.
+
+```markdown
+charon create enr --help
+Create an Ethereum Node Record (ENR) private key to identify this charon client
+
+Usage:
+ charon create enr [flags]
+
+Flags:
+ --data-dir string The directory where charon will store all its internal data. (default ".charon")
+ -h, --help Help for enr
+```
+
+### Create a full cluster locally
+
+The `charon create cluster` command creates a set of distributed validators locally; including the private keys, a `cluster-lock.json` file, and deposit data. This command should only be used for solo-operation of distributed validators. To run a distributed validator cluster with a group of operators, it is preferable to create these artifacts using the [DV Launchpad](../intro/launchpad.md) and the `charon dkg` command. That way, no single operator custodies all of the private keys to a distributed validator.
+
+:::warning
+This command produces new distributed validator private keys or handles and splits pre-existing traditional validator private keys, please use caution and keep these private keys securely backed up and secret.
+:::
+
+```markdown
+charon create cluster --help
+Creates a local charon cluster configuration including validator keys, charon p2p keys, cluster-lock.json and deposit-data.json file(s). See flags for supported features.
+
+Usage:
+ charon create cluster [flags]
+
+Flags:
+ --cluster-dir string The target folder to create the cluster in. (default "./")
+ --compounding Enable compounding rewards for validators by using 0x02 withdrawal credentials.
+ --consensus-protocol string Preferred consensus protocol name for the cluster. Selected automatically when not specified.
+ --definition-file string Optional path to a cluster definition file or an HTTP URL. This overrides all other configuration flags.
+ --deposit-amounts ints List of partial deposit amounts (integers) in ETH. Values must sum up to at least 32ETH.
+ --execution-client-rpc-endpoint string The address of the execution engine JSON-RPC API.
+ --fee-recipient-addresses strings Comma separated list of Ethereum addresses of the fee recipient for each validator. Either provide a single fee recipient address or fee recipient addresses for each validator.
+ -h, --help Help for cluster
+ --insecure-keys Generates insecure keystore files. This should never be used. It is not supported on mainnet.
+ --keymanager-addresses strings Comma separated list of keymanager URLs to import validator key shares to. Note that multiple addresses are required, one for each node in the cluster, with node0's keyshares being imported to the first address, node1's keyshares to the second, and so on.
+ --keymanager-auth-tokens strings Authentication bearer tokens to interact with the keymanager URLs. Don't include the "Bearer" symbol, only include the api-token.
+ --name string The cluster name
+ --network string Ethereum network to create validators for. Options: mainnet, goerli, sepolia, hoodi, holesky, gnosis, chiado.
+ --nodes int The number of charon nodes in the cluster. Minimum is 3.
+ --num-validators int The number of distributed validators needed in the cluster.
+ --publish Publish lock file to obol-api.
+ --publish-address string The URL to publish the lock file to. (default "https://api.obol.tech/v1")
+ --split-existing-keys Split an existing validator's private key into a set of distributed validator private key shares. Does not re-create deposit data for this key.
+ --split-keys-dir string Directory containing keys to split. Expects keys in keystore-*.json and passwords in keystore-*.txt. Requires --split-existing-keys.
+ --target-gas-limit uint Preferred target gas limit for transactions. (default 60000000)
+ --testnet-chain-id uint Chain ID of the custom test network.
+ --testnet-fork-version string Genesis fork version of the custom test network (in hex).
+ --testnet-genesis-timestamp int Genesis timestamp of the custom test network.
+ --testnet-name string Name of the custom test network.
+ --threshold int Optional override of threshold required for signature reconstruction. Defaults to ceil(n*2/3) if zero. Warning, non-default values decrease security.
+ --withdrawal-addresses strings Comma separated list of Ethereum addresses to receive the returned stake and accrued rewards for each validator. Either provide a single withdrawal address or withdrawal addresses for each validator.
+ --zipped Create a tar archive compressed with gzip of the cluster directory after creation.
+```
+
+### Creating the configuration for a DKG Ceremony
+
+This `charon create dkg` command creates a `cluster_definition.json` file used for the `charon dkg` command.
+
+```markdown
+charon create dkg --help
+Create a cluster definition file that will be used by all participants of a DKG.
+
+Usage:
+ charon create dkg [flags]
+
+Flags:
+ --compounding Enable compounding rewards for validators by using 0x02 withdrawal credentials.
+ --consensus-protocol string Preferred consensus protocol name for the cluster. Selected automatically when not specified.
+ --deposit-amounts ints List of partial deposit amounts (integers) in ETH. Values must sum up to at least 32ETH.
+ --dkg-algorithm string DKG algorithm to use; default, frost (default "default")
+ --execution-client-rpc-endpoint string The address of the execution engine JSON-RPC API.
+ --fee-recipient-addresses strings Comma separated list of Ethereum addresses of the fee recipient for each validator. Either provide a single fee recipient address or fee recipient addresses for each validator.
+ -h, --help Help for dkg
+ --name string Optional cosmetic cluster name
+ --network string Ethereum network to create validators for. Options: mainnet, goerli, sepolia, hoodi, holesky, gnosis, chiado. (default "mainnet")
+ --num-validators int The number of distributed validators the cluster will manage (32ETH+ staked for each). (default 1)
+ --operator-addresses strings Comma-separated list of each operator's Ethereum address.
+ --operator-enrs strings Comma-separated list of each operator's Charon ENR address.
+ --output-dir string The folder to write the output cluster-definition.json file to. (default ".charon")
+ --publish Creates an invitation to the DKG ceremony on the DV Launchpad. Terms and conditions apply.
+ --publish-address string The URL to publish the cluster to. (default "https://api.obol.tech/v1")
+ --target-gas-limit uint Preferred target gas limit for transactions. (default 60000000)
+ -t, --threshold int Optional override of threshold required for signature reconstruction. Defaults to ceil(n*2/3) if zero. Warning, non-default values decrease security.
+ --withdrawal-addresses strings Comma separated list of Ethereum addresses to receive the returned stake and accrued rewards for each validator. Either provide a single withdrawal address or withdrawal addresses for each validator.
+```
+
+## The `dkg` command
+
+### Performing a DKG Ceremony
+
+The `charon dkg` command takes a `cluster_definition.json` file that instructs Charon on the terms of a new distributed validator cluster to be created. Charon establishes communication with the other nodes identified in the file, performs a distributed key generation ceremony to create the required threshold private keys, and signs deposit data for each new distributed validator. The command outputs the `cluster-lock.json` file and key shares for each Distributed Validator created.
+
+```markdown
+charon dkg --help
+Participate in a distributed key generation ceremony for a specific cluster definition that creates
+distributed validator key shares and a final cluster lock configuration. Note that all other cluster operators should run
+this command at the same time.
+
+Usage:
+ charon dkg [flags]
+
+Flags:
+ --data-dir string The directory where charon will store all its internal data. (default ".charon")
+ --definition-file string The path to the cluster definition file or an HTTP URL. (default ".charon/cluster-definition.json")
+ --execution-client-rpc-endpoint string The address of the execution engine JSON-RPC API.
+ -h, --help Help for dkg
+ --keymanager-address string The keymanager URL to import validator keyshares.
+ --keymanager-auth-token string Authentication bearer token to interact with keymanager API. Don't include the "Bearer" symbol, only include the api-token.
+ --log-color string Log color; auto, force, disable. (default "auto")
+ --log-format string Log format; console, logfmt or json (default "console")
+ --log-level string Log level; debug, info, warn or error (default "info")
+ --log-output-path string Path in which to write on-disk logs.
+ --no-verify Disables cluster definition and lock file verification.
+ --p2p-disable-reuseport Disables TCP port reuse for outgoing libp2p connections.
+ --p2p-external-hostname string The DNS hostname advertised by libp2p. This may be used to advertise an external DNS.
+ --p2p-external-ip string The IP address advertised by libp2p. This may be used to advertise an external IP.
+ --p2p-relays strings Comma-separated list of libp2p relay URLs or multiaddrs. (default [https://0.relay.obol.tech,https://2.relay.obol.dev,https://1.relay.obol.tech])
+ --p2p-tcp-address strings Comma-separated list of listening TCP addresses (ip and port) for libP2P traffic. Empty default doesn't bind to local port therefore only supports outgoing connections.
+ --p2p-udp-address strings Comma-separated list of listening UDP addresses (ip and port) for libP2P traffic. Empty default doesn't bind to local port therefore only supports outgoing connections.
+ --publish Publish the created cluster to a remote API.
+ --publish-address string The URL to publish the cluster to. (default "https://api.obol.tech/v1")
+ --publish-timeout duration Timeout for publishing a cluster, consider increasing if the cluster contains more than 200 validators. (default 30s)
+ --shutdown-delay duration Graceful shutdown delay. (default 1s)
+ --timeout duration Timeout for the DKG process, should be increased if DKG times out. (default 1m0s)
+ --zipped Create a tar archive compressed with gzip of the target directory after creation.
+```
+
+## The `run` command
+
+### Run the Charon middleware
+
+This `run` command accepts a `cluster-lock.json` file that was created either via a `charon create cluster` command or `charon dkg`. This lock file outlines the nodes in the cluster and the distributed validators they operate on behalf of.
+
+```markdown
+charon run --help
+Starts the long-running Charon middleware process to perform distributed validator duties.
+
+Usage:
+ charon run [flags]
+
+Flags:
+ --beacon-node-endpoints strings Comma separated list of one or more beacon node endpoint URLs.
+ --beacon-node-headers strings Comma separated list of headers formatted as header=value
+ --beacon-node-submit-timeout duration Timeout for the submission-related HTTP requests Charon makes to the configured beacon nodes. (default 2s)
+ --beacon-node-timeout duration Timeout for the HTTP requests Charon makes to the configured beacon nodes. (default 2s)
+ --builder-api Enables the builder api. Will only produce builder blocks. Builder API must also be enabled on the validator client. Beacon node must be connected to a builder-relay to access the builder network.
+ --consensus-protocol string Preferred consensus protocol name for the node. Selected automatically when not specified.
+ --debug-address string Listening address (ip and port) for the pprof and QBFT debug API. It is not enabled by default.
+ --execution-client-rpc-endpoint string The address of the execution engine JSON-RPC API.
+ --fallback-beacon-node-endpoints strings A list of beacon nodes to use if the primary list are offline or unhealthy.
+ --feature-set string Minimum feature set to enable by default: alpha, beta, or stable. Warning: modify at own risk. (default "stable")
+ --feature-set-disable strings Comma-separated list of features to disable, overriding the default minimum feature set.
+ --feature-set-enable strings Comma-separated list of features to enable, overriding the default minimum feature set.
+ --graffiti strings Comma-separated list or single graffiti string to include in block proposals. List maps to validator's public key in cluster lock. Appends "OBHow can I stay up to date on OBOL news?
+ +Join our [Discord](https://discord.obol.org), follow [@ObolNetwork](https://x.com/Obol_Collective), and check our [Forum](https://community.obol.org) for governance and integration updates. + +All of Mellow DVV TVL
+ Lido SDVT Module validators added post Jan 13th Airdrop
+ Lido CSM TVL ran by Obol DVs
- Mellow Depositors: 80% for CSM TVL, 90% for SDVT TVL
- Rest to Node Operators
+
+
+
+Governor Contract
+ +* **Address:** [`0xcB1622185A0c62A80494bEde05Ba95ef29Fbf85c`](https://etherscan.io/address/0xcB1622185A0c62A80494bEde05Ba95ef29Fbf85c) +* **Purpose:** Manages onchain proposal lifecycle and voting logic for Token House governance. +* **What you can find onchain:** + * Voting thresholds + * Quorum settings, + * Delay/period configs, + * Proposal and vote history. + +
+
+
+
+Auto Delegate (Overwhelming Support Strategy)
+ +* **Address:** [`0xCa28852B6Fc15EbD95b17c875D5Eb14b08579158`](https://etherscan.io/address/0xCa28852B6Fc15EbD95b17c875D5Eb14b08579158) +* **Purpose:** Implements the “Overwhelming Support” auto-delegation strategy. This contract casts votes on behalf of un-delegated or transferred stOBOL when proposals receive strong community support. This mechanism uses tokens that would otherwise not be available in governance to ensure uncontroversial proposals will meet quorum. +* **What you can find onchain:** + * Parameters like `supportThreshold`, `subQuorumBips`, and `votingWindow` + * Proposals voted on by the strategy + * Vote power amounts cast + * Event logs showing execution activity + * Wallets or protocols interacting with auto-delegation logic + +
+
+
+
+## Learn more about...
+
+[token-distribution-and-liquidity.md](token-distribution-and-liquidity.md)
+[token-holders-faq.md](token-holders-faq.md)
+[tge-faq.md](tge-faq.md)
diff --git a/versioned_docs/version-v1.8/community-and-governance/obol-token/tge-faq.md b/versioned_docs/version-v1.8/community-and-governance/obol-token/tge-faq.md
new file mode 100644
index 0000000000..d8501c1ef2
--- /dev/null
+++ b/versioned_docs/version-v1.8/community-and-governance/obol-token/tge-faq.md
@@ -0,0 +1,140 @@
+---
+sidebar_label: "TGE FAQ"
+slug: /community-and-governance/obol-token/tge-faq
+---
+
+# TGE FAQ
+
+## Unlock and Listing
+
+Lockup / Unlock Contract (Airdrop Claim NFTs
+ +* **Contract name:** ObolLockups +* **Address:** [0x3b9122704a20946e9cb49b2a8616ccc0f0d61adb](https://etherscan.io/address/0x3b9122704a20946e9cb49b2a8616ccc0f0d61adb) +* **Network:** Ethereum mainnet +* **Purpose:** This contract was used during the OBOL airdrop to manage token lockups. Airdrop allocations were issued as **NFT-based lockups**, allowing recipients to claim their tokens and unlock them over time **without a fixed deadline**. The original claiming interface ([claim.obol.org](http://claim.obol.org)) is no longer live. However, the lockups remain fully accessible **onchain**, and users can still unlock their tokens directly via the contract. +* **How the mechanism works:** + * Each airdrop recipient received an NFT representing a locked OBOL allocation. + * The NFT encodes the lockup parameters. + * Tokens can be unlocked by calling the unlock function on the contract once the conditions are met. +* **What you can find onchain:** + * NFT ownership (ownerOf) + * Lockup parameters + * Locked and unlocked token balances + * The unlock function used to release available tokens + * Administrative parameters related to transferability and global lockups +* **Important note for users:** If you believe you still have locked OBOL tokens from the airdrop, you can: + * Verify that you hold an **ObolLockups NFT** at the address above. + * Interact **directly with this contract on Etherscan** to call the unlock function. + +For security reasons, users should **only** interact with the contract address listed here and not rely on token or NFT names alone. + +
+
+
+
+How do I unlock my OBOL Tokens received in the Airdrop?
+ +Starting May 7th at 11:00 AM UTC, visit [**claim.obol.org**](https://claim.obol.org), click **“Unlock”**, and follow the steps. + +
+
+
+
+When is the official TGE date and time?
+ +The OBOL Token will be listed on exchanges for deposit, trading and withdrawals on May 7th, 2025 at 11:00 AM UTC + +
+
+
+
+Where will the OBOL Token be listed for trading?
+ +* **Binance**, **Bybit**, **Bitget**, **Gate.io**, **MEXC**, and others. +* Check [CoinGecko](https://coingecko.com) or [CoinMarketCap](https://coinmarketcap.com/currencies/obol/) for the most up-to-date list. + +
+
+
+
+What are the exact listing times on exchanges?
+ +* **Binance Alpha** – _May 7 at 10:00 AM UTC_ +* **Binance Futures** – _May 7 at 10:30 AM UTC_ +* **Bybit, Gate.io, Bitget, MEXC** – _May 7 at 11:00 AM UTC_ + +
+
+
+
+Where can I track the price of the OBOL Token?
+ +[CoinGecko](https://coingecko.com) and [CoinMarketCap](https://coinmarketcap.com/currencies/obol/) + +
+
+
+
+Where can I buy the OBOL Token onchain?
+ +* A **Uniswap v3 pool** will be seeded with initial liquidity. +* The contract address is [here](https://etherscan.io/address/0x57F52C9faa6D40c5163D76b8D7dD81ddB7c95434). +* Anyone can start a pool. Check live prices via **CoinGecko**, or **CoinMarketCap**. + +
+
+
+
+## **Token Supply & Distribution**
+
+Are there any country restrictions for claiming or trading the OBOL Token?
+ +* Yes. Each venue has its own restrictions. +* Unlocking OBOL Tokens received through the Airdrop is subject to the same geo restrictions as claiming. + +
+
+
+
+What is the circulating supply at TGE?
+ +Approximately 19**%**. Full breakdown is on [CoinMarketCap](https://coinmarketcap.com/currencies/obol/). + +
+
+
+
+Why does Etherscan show 374M tokens instead of 500M?
+ +For legal and tax reasons, not all tokens are minted yet. + +
+
+
+
+How many tokens were allocated to CoinList, and how many unlock at TGE?
+ +Details available on the [**Coinlist Sale Page**](https://coinlist.co/obol). + +
+
+
+
+## **Unlocks & Vesting**
+
+When were unclaimed airdrop tokens returned to the treasury?
+ +As approved by [**OIP-2**](https://community.obol.org/t/oip-2-unlock-obol-token/317), they were [returned](https://etherscan.io/tx/0x738b4c252bb4613b9945e3b6426ec4ee510c6cdb86027fe20d533c4799a3a331) on **May 2, 2025**. + +
+
+
+
+Can CoinList participants claim at TGE?
+ +Yes, a portion of their tokens will unlock on May 7th at 11AM UTC per the [**Coinlist terms**](https://coinlist.co/obol). + +
+
+
+
+Will RAF1 tokens be available at TGE?
+ +RAF1 tokens will be distributed **shortly after TGE**. + +
+
+
+
+## **Token Utility**
+
+When will OBOL Token incentives be claimable?
+ +Starting May 12, 2025 + +
+
+
diff --git a/versioned_docs/version-v1.8/community-and-governance/obol-token/token-distribution-and-liquidity.md b/versioned_docs/version-v1.8/community-and-governance/obol-token/token-distribution-and-liquidity.md
new file mode 100644
index 0000000000..fad713567f
--- /dev/null
+++ b/versioned_docs/version-v1.8/community-and-governance/obol-token/token-distribution-and-liquidity.md
@@ -0,0 +1,42 @@
+---
+sidebar_label: "Token Distribution & Liquidity"
+slug: /community-and-governance/obol-token/token-distribution-and-liquidity
+---
+
+# Token Distribution & Liquidity
+
+## Token Distribution
+
+The total supply is capped at 500 million tokens. The full supply is not immediately circulating and tokens will unlock over the coming months and years.
+
+
+
+### **Ecosystem Treasury & Retroactive Funding (RAF) | 38.8%**
+
+A significant portion of OBOL Tokens are allocated to the ecosystem treasury to drive innovation and decentralization. These funds support different initiatives, for example, [**SQUAD Goals**](https://community.obol.org/t/oip-3-obol-collective-2025-goals-proposal/)**, Grants & Incentives Funding** contributors who help to the growth of the protocol and the broader Collective and [**Retroactive Funding (RAF)**](../governance/raf/README.md)**,** rewarding contributions that have positively impacted the Obol Collective. Over time, the Obol Association plans to give additional control over these tokens to the community.
+
+### **Investors | 23.7%**
+
+Early investors played a key role in bringing the Obol Collective to life. This allocation ensures that individuals and entities that provided early financial support are fairly rewarded while adhering to best practices in responsible token vesting.
+
+### **Team | 19%**
+
+To attract and retain top-tier talent, a portion of tokens is reserved for core contributors, founders, and developers. This allocation aligns with the long-term vision of the project and is subject to a lock-up period similar to the one of investors.
+
+### **Community Incentives | 7.5%**
+
+To promote awareness and adoption, OBOL tokens will be used for user-focused initiatives that drive adoption of Obol DVs. The first of these initiative is the [Obol Incentives Program.](https://obol.org/incentives)
+
+### **Airdrop | 7.5%**
+
+As a community-first initiative, Obol has rewarded early contributors and supporters through a retroactive airdrop. This ensures ongoing participation in the Collective and strengthens the decentralized operator ecosystem. For more information about the Airdrop distribution, please [see this blog article](https://blog.obol.org/airdrop/).
+
+### **Public Sale via Coinlist | 3.6%**
+
+To ensure broad and fair token distribution, a portion of OBOL Tokens have been made available through a [Coinlist public sale](https://coinlist.co/obol) at better terms than investors. 50% of tokens purchased in the token sale will be fully unlocked and transferable at TGE, followed by a 12 month linear unlock for the remainder of the tokens.
+
+## Token Liquidity
+
+Once the token becomes transferable, the community will be able to track the distribution schedule and observe how the circulating supply increases over time according to the structured unlock plan.
+
+
diff --git a/versioned_docs/version-v1.8/community-and-governance/obol-token/token-holders-faq.md b/versioned_docs/version-v1.8/community-and-governance/obol-token/token-holders-faq.md
new file mode 100644
index 0000000000..0888f499f9
--- /dev/null
+++ b/versioned_docs/version-v1.8/community-and-governance/obol-token/token-holders-faq.md
@@ -0,0 +1,77 @@
+---
+description: "This page is designed to answer the most common questions from OBOL token holders, particularly those holding liquid OBOL or stOBOL."
+sidebar_label: "Token Holders FAQ"
+slug: /community-and-governance/obol-token/token-holders-faq
+---
+
+# Token Holders FAQ
+
+## General
+
+What is the utility of the OBOL Token?
+ +See the top of the page + +
+
+
+
+What is the OBOL token used for?
+ +OBOL is the governance token of the Obol Collective. It enables holders to participate in on-chain governance by voting directly or delegating their voting power to delegates. + +OBOL is also used in the [RAF](../governance/raf/), where token holders delegate to vote on which contributors should receive retroactive funding for valuable work. + +In addition, OBOL can be staked to receive stOBOL, a liquid token that accrues staking rewards and retains governance power as long as it remains in the staker’s wallet. This staking mechanism supports long-term alignment and decentralized ownership. + +Finally, both OBOL and stOBOL are being integrated into DeFi protocols, such as liquidity pools, lending platforms (e.g. Morpho), and restaking services (e.g. Eigenlayer, Symbiotic), with more utility expected over time as shaped by community governance. + +
+
+
+
+## Delegation & Governance
+
+Where can I see OBOL price, supply, and markets?
+ +You can track OBOL on [CoinMarketCap](https://www.coingecko.com/en/coins/obol-2) or [Coingecko](https://coingecko.com). These pages include market data, supply information, and live price charts. + +
+
+
+
+How do I delegate my OBOL tokens?
+ +You can delegate via [vote.obol.org](https://vote.obol.org/dao/delegates). Connect your wallet, choose a delegate, and confirm the delegation transaction. + +
+
+
+
+Can I change my delegate?
+ +Yes, you can re-delegate at any time through the Collective Portal at [vote.obol.org](https://vote.obol.org) + +
+
+
+
+## Token Value & Utility
+
+Does holding OBOL give me passive income?
+ +Not directly. Only staking OBOL (to receive auto-compounding stOBOL) allows you to earn rewards. + +
+
+
+
+Does OBOL accrue fees?
+ +Currently, OBOL does not accrue protocol revenue. However, the DAO may vote in the future to direct protocol revenue toward token holders or stakers. + +
+
+
+
+_This page is updated regularly. If your question isn’t listed, reach out via Discord or the Governance Forum._
diff --git a/versioned_docs/version-v1.8/learn/charon/README.md b/versioned_docs/version-v1.8/learn/charon/README.md
new file mode 100644
index 0000000000..4afbb167ab
--- /dev/null
+++ b/versioned_docs/version-v1.8/learn/charon/README.md
@@ -0,0 +1,7 @@
+---
+sidebar_label: "Charon"
+slug: /learn/charon
+---
+
+# Charon
+
diff --git a/versioned_docs/version-v1.8/learn/charon/charon-cli-reference.md b/versioned_docs/version-v1.8/learn/charon/charon-cli-reference.md
new file mode 100644
index 0000000000..f3a277d2ec
--- /dev/null
+++ b/versioned_docs/version-v1.8/learn/charon/charon-cli-reference.md
@@ -0,0 +1,1089 @@
+---
+description: "A go-based middleware client for taking part in Distributed Validator clusters."
+sidebar_label: "CLI Reference"
+slug: /learn/charon/charon-cli-reference
+---
+
+# CLI Reference
+
+The following is a reference for Charon version [`v1.8.0`](https://github.com/ObolNetwork/charon/releases/tag/v1.8.0). Find the latest release on [our Github](https://github.com/ObolNetwork/charon/releases).
+
+The following are the top-level commands available to use.
+
+```markdown
+charon --help
+Charon enables the operation of Ethereum validators in a fault tolerant manner by splitting the validating keys across a group of trusted parties using threshold cryptography.
+
+Usage:
+ charon [command]
+
+Available Commands:
+ alpha Alpha subcommands provide early access to in-development features
+ combine Combine the private key shares of a distributed validator cluster into a set of standard validator private keys
+ completion Generate the autocompletion script for the specified shell
+ create Create artifacts for a distributed validator cluster
+ deposit Sign and fetch a new partial deposit.
+ dkg Participate in a Distributed Key Generation ceremony
+ enr Print the ENR that identifies this client
+ exit Exit a distributed validator.
+ help Help about any command
+ relay Start a libp2p relay server
+ run Run the charon middleware client
+ version Print version and exit
+
+Flags:
+ -h, --help Help for charon
+
+Use "charon [command] --help" for more information about a command.
+```
+
+## The `create` command
+
+The `create` command handles the creation of artifacts needed by Charon to operate.
+
+```markdown
+charon create --help
+Create artifacts for a distributed validator cluster. These commands can be used to facilitate the creation of a distributed validator cluster between a group of operators by performing a distributed key generation ceremony, or they can be used to create a local cluster for single operator use cases.
+
+Usage:
+ charon create [command]
+
+Available Commands:
+ cluster Create private keys and configuration files needed to run a distributed validator cluster locally
+ dkg Create the configuration for a new Distributed Key Generation ceremony using charon dkg
+ enr Create an Ethereum Node Record (ENR) private key to identify this charon client
+
+Flags:
+ -h, --help Help for create
+
+Use "charon create [command] --help" for more information about a command.
+```
+
+### Creating an ENR for Charon
+
+An `enr` is an Ethereum Node Record. It is used to identify this Charon client to its other counterparty Charon clients across the internet.
+
+```markdown
+charon create enr --help
+Create an Ethereum Node Record (ENR) private key to identify this charon client
+
+Usage:
+ charon create enr [flags]
+
+Flags:
+ --data-dir string The directory where charon will store all its internal data. (default ".charon")
+ -h, --help Help for enr
+```
+
+### Create a full cluster locally
+
+The `charon create cluster` command creates a set of distributed validators locally; including the private keys, a `cluster-lock.json` file, and deposit data. This command should only be used for solo-operation of distributed validators. To run a distributed validator cluster with a group of operators, it is preferable to create these artifacts using the [DV Launchpad](../intro/launchpad.md) and the `charon dkg` command. That way, no single operator custodies all of the private keys to a distributed validator.
+
+:::warning
+This command produces new distributed validator private keys or handles and splits pre-existing traditional validator private keys, please use caution and keep these private keys securely backed up and secret.
+:::
+
+```markdown
+charon create cluster --help
+Creates a local charon cluster configuration including validator keys, charon p2p keys, cluster-lock.json and deposit-data.json file(s). See flags for supported features.
+
+Usage:
+ charon create cluster [flags]
+
+Flags:
+ --cluster-dir string The target folder to create the cluster in. (default "./")
+ --compounding Enable compounding rewards for validators by using 0x02 withdrawal credentials.
+ --consensus-protocol string Preferred consensus protocol name for the cluster. Selected automatically when not specified.
+ --definition-file string Optional path to a cluster definition file or an HTTP URL. This overrides all other configuration flags.
+ --deposit-amounts ints List of partial deposit amounts (integers) in ETH. Values must sum up to at least 32ETH.
+ --execution-client-rpc-endpoint string The address of the execution engine JSON-RPC API.
+ --fee-recipient-addresses strings Comma separated list of Ethereum addresses of the fee recipient for each validator. Either provide a single fee recipient address or fee recipient addresses for each validator.
+ -h, --help Help for cluster
+ --insecure-keys Generates insecure keystore files. This should never be used. It is not supported on mainnet.
+ --keymanager-addresses strings Comma separated list of keymanager URLs to import validator key shares to. Note that multiple addresses are required, one for each node in the cluster, with node0's keyshares being imported to the first address, node1's keyshares to the second, and so on.
+ --keymanager-auth-tokens strings Authentication bearer tokens to interact with the keymanager URLs. Don't include the "Bearer" symbol, only include the api-token.
+ --name string The cluster name
+ --network string Ethereum network to create validators for. Options: mainnet, goerli, sepolia, hoodi, holesky, gnosis, chiado.
+ --nodes int The number of charon nodes in the cluster. Minimum is 3.
+ --num-validators int The number of distributed validators needed in the cluster.
+ --publish Publish lock file to obol-api.
+ --publish-address string The URL to publish the lock file to. (default "https://api.obol.tech/v1")
+ --split-existing-keys Split an existing validator's private key into a set of distributed validator private key shares. Does not re-create deposit data for this key.
+ --split-keys-dir string Directory containing keys to split. Expects keys in keystore-*.json and passwords in keystore-*.txt. Requires --split-existing-keys.
+ --target-gas-limit uint Preferred target gas limit for transactions. (default 60000000)
+ --testnet-chain-id uint Chain ID of the custom test network.
+ --testnet-fork-version string Genesis fork version of the custom test network (in hex).
+ --testnet-genesis-timestamp int Genesis timestamp of the custom test network.
+ --testnet-name string Name of the custom test network.
+ --threshold int Optional override of threshold required for signature reconstruction. Defaults to ceil(n*2/3) if zero. Warning, non-default values decrease security.
+ --withdrawal-addresses strings Comma separated list of Ethereum addresses to receive the returned stake and accrued rewards for each validator. Either provide a single withdrawal address or withdrawal addresses for each validator.
+ --zipped Create a tar archive compressed with gzip of the cluster directory after creation.
+```
+
+### Creating the configuration for a DKG Ceremony
+
+This `charon create dkg` command creates a `cluster_definition.json` file used for the `charon dkg` command.
+
+```markdown
+charon create dkg --help
+Create a cluster definition file that will be used by all participants of a DKG.
+
+Usage:
+ charon create dkg [flags]
+
+Flags:
+ --compounding Enable compounding rewards for validators by using 0x02 withdrawal credentials.
+ --consensus-protocol string Preferred consensus protocol name for the cluster. Selected automatically when not specified.
+ --deposit-amounts ints List of partial deposit amounts (integers) in ETH. Values must sum up to at least 32ETH.
+ --dkg-algorithm string DKG algorithm to use; default, frost or pedersen. (default "default")
+ --execution-client-rpc-endpoint string The address of the execution engine JSON-RPC API.
+ --fee-recipient-addresses strings Comma separated list of Ethereum addresses of the fee recipient for each validator. Either provide a single fee recipient address or fee recipient addresses for each validator.
+ -h, --help Help for dkg
+ --name string Optional cosmetic cluster name
+ --network string Ethereum network to create validators for. Options: mainnet, goerli, sepolia, hoodi, holesky, gnosis, chiado. (default "mainnet")
+ --num-validators int The number of distributed validators the cluster will manage (32ETH+ staked for each). (default 1)
+ --operator-addresses strings Comma-separated list of each operator's Ethereum address.
+ --operator-enrs strings Comma-separated list of each operator's Charon ENR address.
+ --output-dir string The folder to write the output cluster-definition.json file to. (default ".charon")
+ --publish Creates an invitation to the DKG ceremony on the DV Launchpad. Terms and conditions apply.
+ --publish-address string The URL to publish the cluster to. (default "https://api.obol.tech/v1")
+ --target-gas-limit uint Preferred target gas limit for transactions. (default 60000000)
+ -t, --threshold int Optional override of threshold required for signature reconstruction. Defaults to ceil(n*2/3) if zero. Warning, non-default values decrease security.
+ --withdrawal-addresses strings Comma separated list of Ethereum addresses to receive the returned stake and accrued rewards for each validator. Either provide a single withdrawal address or withdrawal addresses for each validator.
+```
+
+## The `dkg` command
+
+### Performing a DKG Ceremony
+
+The `charon dkg` command takes a `cluster_definition.json` file that instructs Charon on the terms of a new distributed validator cluster to be created. Charon establishes communication with the other nodes identified in the file, performs a distributed key generation ceremony to create the required threshold private keys, and signs deposit data for each new distributed validator. The command outputs the `cluster-lock.json` file and key shares for each Distributed Validator created.
+
+```markdown
+charon dkg --help
+Participate in a distributed key generation ceremony for a specific cluster definition that creates
+distributed validator key shares and a final cluster lock configuration. Note that all other cluster operators should run
+this command at the same time.
+
+Usage:
+ charon dkg [flags]
+
+Flags:
+ --data-dir string The directory where charon will store all its internal data. (default ".charon")
+ --definition-file string The path to the cluster definition file or an HTTP URL. (default ".charon/cluster-definition.json")
+ --execution-client-rpc-endpoint string Optional address of an execution engine JSON-RPC API. Used to validate smart contract signatures for Node Operators in the cluster.
+ -h, --help Help for dkg
+ --keymanager-address string The keymanager URL to import validator keyshares.
+ --keymanager-auth-token string Authentication bearer token to interact with keymanager API. Don't include the "Bearer" symbol, only include the api-token.
+ --log-color string Log color; auto, force, disable. (default "auto")
+ --log-format string Log format; console, logfmt or json (default "console")
+ --log-level string Log level; debug, info, warn or error (default "info")
+ --log-output-path string Path in which to write on-disk logs.
+ --no-verify Disables cluster definition and lock file verification.
+ --p2p-disable-reuseport Disables TCP port reuse for outgoing libp2p connections.
+ --p2p-external-hostname string The DNS hostname advertised by libp2p. This may be used to advertise an external DNS.
+ --p2p-external-ip string The IP address advertised by libp2p. This may be used to advertise an external IP.
+ --p2p-relays strings Comma-separated list of libp2p relay URLs or multiaddrs. (default [https://0.relay.obol.tech,https://1.relay.obol.tech,https://2.relay.obol.dev])
+ --p2p-tcp-address strings Comma-separated list of listening TCP addresses (ip and port) for libP2P traffic. Empty default doesn't bind to local port therefore only supports outgoing connections.
+ --p2p-udp-address strings Comma-separated list of listening UDP addresses (ip and port) for libP2P traffic. Empty default doesn't bind to local port therefore only supports outgoing connections.
+ --publish Publish the created cluster to a remote API.
+ --publish-address string The URL to publish the cluster to. (default "https://api.obol.tech/v1")
+ --publish-timeout duration Timeout for publishing a cluster, consider increasing if the cluster contains more than 200 validators. (default 30s)
+ --shutdown-delay duration Graceful shutdown delay. (default 1s)
+ --timeout duration Timeout for the DKG process, should be increased if DKG times out. (default 1m0s)
+ --zipped Create a tar archive compressed with gzip of the target directory after creation.
+```
+
+## The `run` command
+
+### Run the Charon middleware
+
+This `run` command accepts a `cluster-lock.json` file that was created either via a `charon create cluster` command or `charon dkg`. This lock file outlines the nodes in the cluster and the distributed validators they operate on behalf of.
+
+```markdown
+charon run --help
+Starts the long-running Charon middleware process to perform distributed validator duties.
+
+Usage:
+ charon run [flags]
+
+Flags:
+ --beacon-node-endpoints strings Comma separated list of one or more beacon node endpoint URLs.
+ --beacon-node-headers strings Comma separated list of headers formatted as header=value
+ --beacon-node-submit-timeout duration Timeout for the submission-related HTTP requests Charon makes to the configured beacon nodes. (default 2s)
+ --beacon-node-timeout duration Timeout for the HTTP requests Charon makes to the configured beacon nodes. (default 2s)
+ --builder-api Enables the builder api. Will only produce builder blocks. Builder API must also be enabled on the validator client. Beacon node must be connected to a builder-relay to access the builder network.
+ --consensus-protocol string Preferred consensus protocol name for the node. Selected automatically when not specified.
+ --debug-address string Listening address (ip and port) for the pprof and QBFT debug API. It is not enabled by default.
+ --execution-client-rpc-endpoint string The address of the execution engine JSON-RPC API.
+ --fallback-beacon-node-endpoints strings A list of beacon nodes to use if the primary list are offline or unhealthy.
+ --feature-set string Minimum feature set to enable by default: alpha, beta, or stable. Warning: modify at own risk. (default "stable")
+ --feature-set-disable strings Comma-separated list of features to disable, overriding the default minimum feature set.
+ --feature-set-enable strings Comma-separated list of features to enable, overriding the default minimum feature set.
+ --graffiti strings Comma-separated list or single graffiti string to include in block proposals. List maps to validator's public key in cluster lock. Appends "OBHow can I stay up to date on OBOL news?
+ +Join our [Discord](https://discord.obol.org), follow [@ObolNetwork](https://x.com/Obol_Collective), and check our [Forum](https://community.obol.org) for governance and integration updates. + +All of Mellow DVV TVL
+ Lido SDVT Module validators added post Jan 13th Airdrop
+ Lido CSM TVL ran by Obol DVs
- Mellow Depositors: 80% for CSM TVL, 90% for SDVT TVL
- Rest to Node Operators
+::: +### Who This Kit Is For + +**Node operators** who are: + +* Being asked to **deploy, and operate** an stVault for a fund, DAO, protocol, or other allocator +* Building that vault on top of a **multi-operator Obol DV** rather than a single operator / single client setup + +**Capital allocators** who: + +* Need to understand **why** a DV-backed stVault can support more favorable risk assessments and reserve ratios +* Want a clear checklist for vetting operators and understanding what strong DV cluster operations look like + +### Why Obol DVs Are the Best Way to Deploy an stVault + +Lido V3's stVault design unlocks new levels of **capital efficiency** for node operators and institutional stakers. Obol Distributed Validators are **the most capital-efficient way to run a vault on Lido V3**. + +One of Lido V3's key innovations is the **Reserve Ratio (RR)**, which determines how much ETH must be kept as a reserve buffer relative to minted stETH. Lido is proposing a **2% Reserve Ratio tier for verified multi-operator DV vaults**, allowing up to **98% stETH minting capacity**. This is the most favorable tier. By comparison, the next-highest default tier for identified operators proposes a 5% RR with only 95% minting capacity. + +**Obol Distributed Validators unlock the highest minting capacity available on Lido V3.** + +#### Key Benefits + +* **Unlock the highest capital efficiency**\ + Multi-operator DV vaults qualify for the 2% Reserve Ratio tier, offering 98% stETH minting capacity, the most capital-efficient configuration on Lido V3. +* **Distribute responsibility across multiple operators**\ + Reduce reliance on any single infrastructure provider, company, or jurisdiction. Multi-operator setups distribute private key shares across many entities. +* **Maximize client and implementation diversity**\ + Run multiple consensus and execution client combinations inside the same vault, strengthening the vault's resilience and reducing correlation risks. +* **Superior liveness and fault tolerance**\ + Obol's fault-tolerant infrastructure means your validators keep performing even if individual operators experience downtime or failures. +* **Enterprise-grade security**\ + Leverage best-in-class security that institutional stakers and asset managers require for managing significant stake. + +### 📚 How This Integration Kit Is Organized + +#### For Node Operators – Implementation Guide + +A practical guide to designing, deploying, and operating an stVault using Obol DVs, including: + +* What to collect from the vault owner +* How to design your DV cluster (operators, clients, geos) +* How to rehearse on testnet and prepare for mainnet launch +* How this integrates into the Lido V3 stVault flow + +👉 [**Read the Node Operator Guide →**](lido-v3-stvault-for-node-operator.md) +#### For Capital Allocators – Design & Risk Overview + +A higher-level walkthrough of: + +* What you are optimizing for (safety, yield, minting capacity, counterparty risk) +* Why multi-operator DVs are different from "just another node operator" +* How Obol's [**Cluster-as-a-Service**](https://hubs.ly/Q03Y2Srl0) offering can help guide your decisions +* What to ask from your operators or from Obol directly + +👉 [**Read the Capital Allocator Guide →**](lido-v3-stvault-for-capital-allocators.md) +#### Support & Services for stVault Builders + +How to: + +* [Get in touch with the Obol team](mailto:lido@obol.tech) for guidance and design help +* Leverage Obol's [**Cluster-as-a-Service**](https://hubs.ly/Q03Y2Srl0) offering to get set up +### 🔗 Quick Links + +* [**Default risk assessment framework**](https://research.lido.fi/t/default-risk-assessment-framework-and-fees-parameters-for-lido-v3-stvaults/10504) — Explore how Tiers within Identified Node Operators effect the reserve ratio of the vault +* [**DV Cluster identification and assessment**](https://docs.lido.fi/run-on-lido/stvaults/node-operators-identification/#dvt-cluster-identification-and-assessment) — See the identification requirements for each node operator in a cluster in order to qualify for improved Tiering +* [**stVaults Doc Center**](https://docs.lido.fi/run-on-lido/stvaults/) — View Lido's comprehensive guides which detail how to create any product powered by stVaults + +#### Future Extensions + +As Lido's [**DeFi wrapper**](https://hackmd.io/@lido/lido-v3-wrapper-design) and more advanced strategies roll out, we will extend this kit with: + +* End-to-end reference architectures that combine stVaults, wrappers, and multi-operator DV clusters +* Config and deployment examples taken from real-world vaults +* Case studies, including the "Ethereum client team vault", once it is live + +**For now, this page gives you the map. The linked sections show you how to actually build and run the vaults behind it.** diff --git a/versioned_docs/version-v1.8/run-a-dv/prepare/README.md b/versioned_docs/version-v1.8/run-a-dv/prepare/README.md new file mode 100644 index 0000000000..6d77f77e82 --- /dev/null +++ b/versioned_docs/version-v1.8/run-a-dv/prepare/README.md @@ -0,0 +1,7 @@ +--- +sidebar_label: "Prepare to Run a DV" +slug: /run-a-dv/prepare +--- + +# prepare + diff --git a/versioned_docs/version-v1.8/run-a-dv/prepare/deployment-best-practices.md b/versioned_docs/version-v1.8/run-a-dv/prepare/deployment-best-practices.md new file mode 100644 index 0000000000..da8f61b1da --- /dev/null +++ b/versioned_docs/version-v1.8/run-a-dv/prepare/deployment-best-practices.md @@ -0,0 +1,99 @@ +--- +description: "DV Deployment best practices, for running an optimal Distributed Validator setup at scale." +sidebar_label: "Deployment Best Practices" +slug: /run-a-dv/prepare/deployment-best-practices +--- + +# Deployment Best Practices + +The following are a selection of best practices for deploying Distributed Validator Clusters at scale on mainnet. + +## Hardware Specifications + +The following specifications are recommended for bare metal machines for clusters intending to run a significant number of mainnet validators: + +### Minimum Specs + +* A CPU with 4+ cores, favouring high clock speed over more cores. ( >3.0GHz and higher or a cpubenchmark [single thread](https://www.cpubenchmark.net/singleThread.html) score of >2,500) +* 16GB of RAM +* 2TB+ free SSD disk space (for mainnet) +* 1000 read/write SSD IOPS +* 500MB/s read/write SSD speed +* 10mb/s internet bandwidth + +### Recommended Specs for extremely large clusters + +* A CPU with 8+ physical cores, with clock speeds >3.5Ghz +* 32GB+ RAM (depending on the EL+CL clients) +* 4TB+ NVMe storage +* 2000 read/write SSD IOPS +* 1000MB/s read/write SSD speed +* 25mb/s internet bandwidth + +An NVMe storage device is **highly recommended for optimal performance**, offering nearly 10x more random read/writes per second than a standard SSD. + +Inadequate hardware (low-performance virtualized servers and/or slow HDD storage) has been observed to hinder performance, indicating the necessity of provisioning adequate resources. **CPU clock speed and Disk throughput+latency are the most important factors for running a performant validator.** + +Note that the Charon client itself takes less than 1GB of RAM and minimal CPU load. In order to optimise both performance and cost-effectiveness, it is recommended to prioritise physical over virtualised setups. Such configurations typically offer greater performance and minimise overhead associated with virtualisation, contributing to improved efficiency and reliability. + +When constructing a DV cluster, it is important to be conscious of whether a cluster runs across cloud providers or stays within a single provider's private networking. This likely can impact the bandwidth and latency of the connections between nodes, as well as the egress costs of the cluster (Charon has a relatively low communication with its peers, averaging 10s of kb/s in large mainnet clusters). Ideally, bare metal machines in different locations within the same continent and with at least two providers, balances redundancy and performance. + +## Intra-cluster Latency + +It is recommended to **keep peer ping latency below 235 milliseconds for all peers in a cluster**. Charon should report a consensus duration averaging under 1 second through its prometheus metric `core_consensus_duration_seconds_bucket` and associated grafana panel titled "Consensus Duration". + +In cases where latencies exceed these thresholds, efforts should be made to reduce the physical distance between nodes or optimise Internet Service Provider (ISP) settings accordingly. Ensure all nodes are connecting to one another directly rather than through a relay. + +For high-scale, performance deployments; inter-peer latency of < 25ms is optimal, along with an average consensus duration under 100ms. + +## Node Locations + +For optimal performance and high availability, it is recommended to provision machines or virtual machines (VMs) within the same continent. This practice helps minimize potential latency issues ensuring efficient communication and responsiveness. Consider maps of [undersea internet cables](https://www.submarinecablemap.com/) when selecting locations across oceans with low latency. + +## Peer Connections + +Charon clients can establish connections with one another in two ways: either through a third publicly accessible server known as [a relay](../../learn/charon/charon-cli-reference.md#host-a-relay) or directly with one another if they can establish a connection. The former is known as a relay connection and the latter is known as a direct connection. + +It is important that all nodes in a cluster be directly connected to one another - this can halve the latency between them and reduces bandwidth constraints significantly. Opening Charon’s p2p port (the default is `3610`) to the Internet, or configuring your routers NAT gateway to permit connections to your Charon client, are what are required to facilitate a direct connection between clients. + +## Instance Independence + +Each node in the cluster should have its own independent beacon node (EL+CL) and validator client as well as Charon client. Sharing beacon nodes between the different nodes would potentially impact the fault tolerance of the cluster and as a result should be avoided. + +## Placement of Charon clients + +If you wish to divide a Distributed Validator node across multiple physical or virtual machines; locate the Charon client on the EL/CL machine instead of the VC machine. This setup reduces latency from Charon to the consensus layer, as well as keeping the public-internet connected clients separate from the clients that hold the validator private keys. Be sure to use encrypted communication between your VC and the Charon client, potentially through a cloud-provided network, a self-managed network tunnel, a VPN, a Kubernetes [CNI](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/), or other manner. + +## Node Configuration + +Cluster sizes that allow for Byzantine Fault Tolerance are recommended as they are safer than clusters with simply Crash Fault Tolerance (See this guide for reference - [Cluster Size and Resilience](../../learn/charon/cluster-configuration/#cluster-size-and-resilience)). + +## MEV-Boost Relays + +MEV relays are configured at the Consensus Layer or MEV-boost client level. Refer to our [guide](../../advanced-and-troubleshooting/advanced/enable-mev.mdx) to ensure all necessary configuration has been applied to your clients. As with all validators, low latency during proposal opportunities is extremely important. By default, MEV-Boost waits for all configured relays to return a bid, or will timeout if any have not returned a bid within 950ms. This default timeout is generally too slow for a distributed cluster (think of this time as additive to the time it takes the cluster to come to consensus, both of which need to happen within a 2 second window for optimal proposal broadcasting). It is likely better to only list relays that are located geographically near your node, so that once all relays respond (e.g. in < 50ms) your cluster will move forward with the proposal. + +Use Charon's [`test mev` command](./test-a-cluster.mdx#test-mev-relay) to test a number of your preferred relays, and select the two or three relays with the lowest latency to your node(s), you do not need to have the same relays on each node in a cluster. + +## Client Diversity + +The clusters should consist of a combination of your preferred consensus, execution, and validator clients. It is recommended to include a combination of multiple clients in order to have a healthy client diversity within the cluster, ideally, if any single client type fails, it should be less than the fault tolerance of the cluster, and the validators should stay online/not do anything slashable. + +Remote signers can be included as well, such as Web3signer or Dirk. A diversity of private key infrastructure setups further reduces the risk of total key compromise. + +Tested client combinations can be found in the [release notes](https://github.com/ObolNetwork/charon/releases) for each Charon version. + +## Metrics Monitoring + +As requested by Obol Labs, node operators can push [standard monitoring](../start/obol-monitoring.mdx) (Prometheus) and logging (Loki) data to Obol Labs' core team's cloud infrastructure for in-depth analysis of performance data and to assist during potential issues that may arise. Our recommendation for operators is to independently store information on their node health over the course of the validator lifecycle as well as any information on validator performance that they collect during the normal life cycle of a validator. + +## Obol Splits + +Leveraging [Obol Splits](../../learn/intro/obol-splits.md) smart contracts allows for non-custodial fund handling and allows for net customer payouts in an ongoing manner. Obol Splits ensure no commingling of funds across customers, and maintain full non-custodial integrity. Read more about Obol Splits [here](../../learn/intro/frequently-asked-questions.mdx#obol-splits). + +## Deposit Process + +Deposit processes can be done via an automated script. This can be used for DV clusters until they reach the desired number of validators. + +It is important to allow time for the validators to be activated (usually < 24 hours). + +Consider using batching smart contracts to reduce the gas cost of a script, but take caution in their integration not to make an invalid deposit. diff --git a/versioned_docs/version-v1.8/run-a-dv/prepare/how_where_dvs.md b/versioned_docs/version-v1.8/run-a-dv/prepare/how_where_dvs.md new file mode 100644 index 0000000000..1c94049a40 --- /dev/null +++ b/versioned_docs/version-v1.8/run-a-dv/prepare/how_where_dvs.md @@ -0,0 +1,43 @@ +--- +description: "How and where to run DVs" +sidebar_label: "How and Where To Run DVs" +slug: /run-a-dv/prepare/how_where_dvs +--- + +# How and Where To Run DVs + +## Launchers and Deployment Tooling + +* [Obol CDVN](https://github.com/ObolNetwork/charon-distributed-validator-node) +* [Obol K8s](https://github.com/ObolNetwork/charon-k8s-distributed-validator-node) +* [Obol Helm Charts](https://github.com/ObolNetwork/helm-charts) +* [Obol Ansible Playbooks](https://github.com/ObolNetwork/obol-ansible) +* [Dappnode](https://docs.dappnode.io/docs/user/staking/ethereum/dvt-technologies/obol-network/) +* [Stereum](https://stereum.net/) +* [Sedge](https://github.com/ObolNetwork/sedge/blob/develop/docs/docs/quickstart/charon.mdx) +* [Terraform Charon Relay](https://github.com/ObolNetwork/terraform-charon-relay) +* [Terraform Grafana Charon dashboards](https://github.com/ObolNetwork/terraform-grafana-dashboards) + +## Quickstart Guides + +* [Run a DV alone](../start/create-a-dv-alone.mdx) +* [Run a DV as a group](../start/create-a-dv-with-a-group.mdx) + +## CL+VC Combinations: + +**Legend** + +* ✅: All duties succeed in testing +* 🟡: All duties succeed in testing, except non-penalised aggregation duties +* 🟠: Duties may fail for this combination +* 🔴: One or more duties fails consistently + +| Validator 👉 Consensus 👇 | Teku v24.10.3 | Lighthouse v5.3.0 | Lodestar v1.23.0 | Nimbus v24.10.0 | Prysm v5.1.2 | Remarks | +| ------------------------- | ------------- | ----------------- | ---------------- | --------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Teku v24.10.3 | ✅ | 🟡 | ✅ | ✅ | 🟠 | Teku `beacon node` needs the `--validators-graffiti-client-append-format=DISABLED` flag in order to produce blocks properly. Teku `validator client` is only failing aggregation duties 50% of the time, which are not directly penalised but impact network density at high scale. | +| Lighthouse v5.3.0 | ✅ | 🟡 | ✅ | ✅ | ✅ | Lighthouse `validator client` is only failing aggregation duties, which are not directly penalised but impact network density at high scale. | +| Lodestar v1.23.0 | ✅ | 🟡 | ✅ | ✅ | 🟠 | | +| Nimbus v24.10.0 | ✅ | 🟡 | ✅ | ✅ | 🟠 | | +| Prysm v5.1.2 | ✅ | 🟡 | ✅ | ✅ | ✅ | Prysm `validator client` is failing aggregation duties 50% of the time, which are not directly penalised but impact network density at high scale. In some combinations rare failures of attestation and proposal duties were observed (0-2% per epoch). | + +Note: for the most recent compatibility information, please see the [release notes](https://github.com/ObolNetwork/charon/releases/) from the most recent release of Charon. diff --git a/versioned_docs/version-v1.8/run-a-dv/prepare/test-a-cluster.mdx b/versioned_docs/version-v1.8/run-a-dv/prepare/test-a-cluster.mdx new file mode 100644 index 0000000000..c223364b08 --- /dev/null +++ b/versioned_docs/version-v1.8/run-a-dv/prepare/test-a-cluster.mdx @@ -0,0 +1,654 @@ +--- +sidebar_label: "Test a Cluster" +slug: /run-a-dv/prepare/test-a-cluster +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +# Test a Cluster + +Charon test commands are designed to help you evaluate the performance and readiness of your candidate cluster. It allows you to test your connection to other Charon peers, the performance of your beacon node(s), the readiness of your validator client, the performance of the MEV relays you will be using and the infrastructure on which you will run the cluster. It prints a performance report to the standard output (which can be omitted with the `--quiet` flag) and a machine-readable JSON format of the report if the `--output-json` flag is set. + + +:::tip + +Adding the `--publish` flag to the below commands, and running the command from the directory containing your `.charon` folder, will submit the test results to the [Obol API](../../api/what-is-this-api.md). Publishing your performance reports grows the staking node dataset, and allows Obol and Ethereum development teams to make data-driven choices regarding the required specs for validating Ethereum. We hope you will consider opting in. + +::: + +
+
+
+Stake ETH on Obol DVs
Stake on existing DVT products and explore available options.
+Learn About Obol
Start here to understand DVT, how Charon (our middleware) works, and why distributed validators are fundamental to Ethereums future.
+
+
diff --git a/versioned_docs/version-v1.9/advanced-and-troubleshooting/advanced/README.md b/versioned_docs/version-v1.9/advanced-and-troubleshooting/advanced/README.md
new file mode 100644
index 0000000000..991baa0e5d
--- /dev/null
+++ b/versioned_docs/version-v1.9/advanced-and-troubleshooting/advanced/README.md
@@ -0,0 +1,7 @@
+---
+sidebar_label: "Advanced Guides"
+slug: /advanced-and-troubleshooting/advanced
+---
+
+# Advanced Guides
+
diff --git a/versioned_docs/version-v1.9/advanced-and-troubleshooting/advanced/adv-docker-configs.md b/versioned_docs/version-v1.9/advanced-and-troubleshooting/advanced/adv-docker-configs.md
new file mode 100644
index 0000000000..91890c82c5
--- /dev/null
+++ b/versioned_docs/version-v1.9/advanced-and-troubleshooting/advanced/adv-docker-configs.md
@@ -0,0 +1,37 @@
+---
+description: "Use advanced docker-compose features to have more flexibility and power to change the default configuration."
+sidebar_label: "Advanced Docker Configs"
+slug: /advanced-and-troubleshooting/advanced/adv-docker-configs
+---
+
+# Advanced Docker Configs
+
+:::info
+This section is intended for _docker power users_, i.e.: for those who are familiar with working with `docker compose` and want to have more flexibility and power to change the default configuration.
+:::
+
+We use the "Multiple Compose File" feature which provides a very powerful way to override any configuration in `docker-compose.yml` without needing to modify version-controlled files since that results in conflicts when upgrading this repo. See [this](https://docs.docker.com/compose/extends/#multiple-compose-files) for more details.
+
+There are some additional compose files in [this repository](https://github.com/ObolNetwork/charon-distributed-validator-node/), `compose-debug.yml` and `docker-compose.override.yml.sample`, along with the default `docker-compose.yml` file that you can use for this purpose.
+
+* `compose-debug.yml` contains some additional containers that developers can use for debugging, like `tempo`. To achieve this, you can run:
+
+```shell
+docker compose -f docker-compose.yml -f compose-debug.yml up
+```
+
+* `docker-compose.override.yml.sample` is intended to override the default configuration provided in `docker-compose.yml`. This is useful when, for example, you wish to add port mappings or want to disable a container.
+* To use it, just copy the sample file to `docker-compose.override.yml` and customise it to your liking. Please create this file ONLY when you want to tweak something. This is because the default override file is empty and docker errors if you provide an empty compose file.
+
+```shell
+cp docker-compose.override.yml.sample docker-compose.override.yml
+
+# Tweak docker-compose.override.yml and then run docker compose up
+docker compose up
+```
+
+* You can also run all these compose files together. This is desirable when you want to use both the features. For example, you may want to have some debugging containers AND also want to override some defaults. To achieve this, you can run:
+
+```shell
+docker compose -f docker-compose.yml -f docker-compose.override.yml -f compose-debug.yml up
+```
diff --git a/versioned_docs/version-v1.9/advanced-and-troubleshooting/advanced/alter-withdrawal-addresses.md b/versioned_docs/version-v1.9/advanced-and-troubleshooting/advanced/alter-withdrawal-addresses.md
new file mode 100644
index 0000000000..d4f8808d8c
--- /dev/null
+++ b/versioned_docs/version-v1.9/advanced-and-troubleshooting/advanced/alter-withdrawal-addresses.md
@@ -0,0 +1,80 @@
+---
+description: "Prepare an alternative deposit for an unused validator"
+sidebar_label: "Alter Withdrawal Addresses"
+slug: /advanced-and-troubleshooting/advanced/alter-withdrawal-addresses
+---
+
+# Alter Withdrawal Addresses
+
+:::warning
+Please take care when changing a withdrawal address for an inactivated validator. Activating a validator that exits to a withdrawal address you don't control likely means your funds are lost.
+
+Also be careful as to the trustworthiness of the original withdrawal address. They [could attempt to front-run](https://medium.com/immunefi/rocketpool-lido-frontrunning-bug-fix-postmortem-e701f26d7971) the alternative deposit, and end up receiving the new depositor's funds to their withdrawal address.
+:::
+
+On occasion it can be useful to be able to change the withdrawal address specified for an already created but unused distributed validator. For example if they are unneeded extra capacity, or if the withdrawal address to be used was not known at cluster creation time and a trusted placeholder address was used instead. The `charon deposit` commands allow you to sign alternative deposit messages for **inactive validators** with the help of the Obol [API](../../api/what-is-this-api.md).
+
+:::info
+If you want to change the withdrawal address of a running validator, consider a validator [consolidation](operator-rotation.md) instead.
+:::
+
+## Sign an alternative deposit message
+
+A threshold of operators must decide which public keys they are changing the withdrawal address for, and what the new withdrawal address will be. Then each run the `charon deposit sign` command with their partial private keys and the appropriate (identical) flags.
+
+**Single public key**
+
+```sh
+docker run -u $(id -u):$(id -g) --rm -v "$(pwd)/:/opt/charon" obolnetwork/charon:v1.9.0 deposit sign \
+ --validator-public-keys="0xb9171b84a09da7ff983a36e1c6e873e1537e97ad31aa868185d62c68e255baad8c1cfb83f508460ed96572d2a8e9e9da" \
+ --withdrawal-addresses="0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"
+```
+
+:::info
+`validator-public-keys` are the distributed validator public keys for which the alternative deposit data should be signed (find them in your cluster\_lock.json file in the `distributed_validator_public_keys` mapping or on the DV Launchpad). `withdrawal-addresses` are the new withdrawal address(es) for which the new deposit data should be signed. There should either be the same amount as `validator-public-keys` specified, or a single address that will be used for all public keys specified.
+
+Optionally, users can also specify multiple different `deposit-amounts` (defaults to only `32`) to be prepared.
+:::
+
+**Multiple public keys, multiple withdrawal addresses**
+
+```sh
+docker run -u $(id -u):$(id -g) --rm -v "$(pwd)/:/opt/charon" obolnetwork/charon:v1.9.0 deposit sign \
+ --validator-public-keys="0xb9171b84a09da7ff983a36e1c6e873e1537e97ad31aa868185d62c68e255baad8c1cfb83f508460ed96572d2a8e9e9da,0xc9171b84a09da7ff983a36e1c6e873e1537e97ad31aa868185d62c68e255baad8c1cfb83f508460ed96572d2a8e9e9da" \
+ --withdrawal-addresses="0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045,0x1db3439a222c519ab44bb1144fc28167b4fa6ee6"
+```
+
+**Multiple public keys, single withdrawal address**
+
+```sh
+docker run -u $(id -u):$(id -g) --rm -v "$(pwd)/:/opt/charon" obolnetwork/charon:v1.9.0 deposit sign \
+ --validator-public-keys="0xb9171b84a09da7ff983a36e1c6e873e1537e97ad31aa868185d62c68e255baad8c1cfb83f508460ed96572d2a8e9e9da,0xc9171b84a09da7ff983a36e1c6e873e1537e97ad31aa868185d62c68e255baad8c1cfb83f508460ed96572d2a8e9e9da" \
+ --withdrawal-addresses="0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"
+```
+
+## Fetch full deposit data
+
+After a threshold of operators have submitted partial alternative deposits, a full aggregated deposit message can be fetched from Obol API.
+
+```sh
+docker run -u $(id -u):$(id -g) --rm -v "$(pwd)/:/opt/charon" obolnetwork/charon:v1.9.0 deposit fetch \
+ --validator-public-keys="0xb9171b84a09da7ff983a36e1c6e873e1537e97ad31aa868185d62c68e255baad8c1cfb83f508460ed96572d2a8e9e9da" \
+```
+
+:::info
+`validator-public-keys` are the validator public keys for which the new deposit data should be fetched.
+:::
+
+After a successful fetch the new deposit data files are saved in `.charon/deposit-data-Integrate Obol DVs
Deploy DVs on mainnet or testnet and follow the quickstart path for operators and allocators.
+Get In Touch
Partnerships, integration support, allocator onboarding, or general questions.
+
+
+
+Stake ETH on Obol DVs
Stake on existing DVT products and explore available options.
+Learn About Obol
Start here to understand DVT, how Charon (our middleware) works, and why distributed validators are fundamental to Ethereums future.
+
+
diff --git a/versioned_docs/version-v1.9/learn/intro/frequently-asked-questions.mdx b/versioned_docs/version-v1.9/learn/intro/frequently-asked-questions.mdx
new file mode 100644
index 0000000000..c4be43f9c6
--- /dev/null
+++ b/versioned_docs/version-v1.9/learn/intro/frequently-asked-questions.mdx
@@ -0,0 +1,110 @@
+---
+sidebar_label: "Frequently Asked Questions"
+slug: /learn/readme/frequently-asked-questions
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Frequently Asked Questions
+
+## Frequently Asked Questions
+
+### General[](frequently-asked-questions.mdx#general) {#general}
+#### Does Obol have a token?[](frequently-asked-questions.mdx#does-obol-have-a-token) {#does-obol-have-a-token}
+Yes, please see the [token page](../../community-and-governance/obol-token/) for details about the OBOL Token and our [announcement](https://blog.obol.org/airdrop/) for details about the community airdrop that took place in January 2025. The official token contract address is [0x0B010000b7624eb9B3DfBC279673C76E9D29D5F7](https://etherscan.io/token/0x0B010000b7624eb9B3DfBC279673C76E9D29D5F7).
+
+#### Where can I learn more about Distributed Validators?[](frequently-asked-questions.mdx#where-can-i-learn-more-about-distributed-validators) {#where-can-i-learn-more-about-distributed-validators}
+Have you checked out our [blog site](https://blog.obol.tech/) and [twitter](https://twitter.com/ObolNetwork) yet? Maybe join our [discord](https://discord.gg/n6ebKsX46w) too.
+
+#### Where does the name Charon come from?[](frequently-asked-questions.mdx#where-does-the-name-charon-come-from) {#where-does-the-name-charon-come-from}
+[Charon](https://www.theoi.com/Khthonios/Kharon.html) \[kharon] is the Ancient Greek Ferryman of the Dead. He was tasked with bringing people across the Acheron river to the underworld. His fee was one Obol coin, placed in the mouth of the deceased. This tradition of placing a coin or Obol in the mouth of the deceased continues to this day across the Greek world.
+
+#### What are the hardware requirements for running a Charon node?[](frequently-asked-questions.mdx#what-are-the-hardware-requirements-for-running-a-charon-node) {#what-are-the-hardware-requirements-for-running-a-charon-node}
+Charon alone uses negligible disk space of not more than a few MBs. However, if you are running your consensus client and execution client on the same server as Charon, then you will typically need the same hardware as running a full Ethereum node:
+
+Integrate Obol DVs
Deploy DVs on mainnet or testnet and follow the quickstart path for operators and allocators.
+Get In Touch
Partnerships, integration support, allocator onboarding, or general questions.
+All of Mellow DVV TVL
+ Lido SDVT Module validators added post Jan 13th Airdrop
+ Lido CSM TVL ran by Obol DVs
- Mellow Depositors: 80% for CSM TVL, 90% for SDVT TVL
- Rest to Node Operators
+
diff --git a/versioned_docs/version-v1.9/obol-stack/README.md b/versioned_docs/version-v1.9/obol-stack/README.md
new file mode 100644
index 0000000000..0734aad742
--- /dev/null
+++ b/versioned_docs/version-v1.9/obol-stack/README.md
@@ -0,0 +1,112 @@
+---
+description: "A framework for AI agents to run decentralised infrastructure locally"
+sidebar_label: "Introduction"
+slug: /obol-stack/obol-stack
+---
+
+# Introduction
+
+The Obol Stack is a local development environment for running AI agents alongside blockchain infrastructure. It provides a simplified CLI for managing a Kubernetes cluster with an AI agent ([OpenClaw](https://openclaw.ai)), dynamically deployable blockchain networks, and public access via Cloudflare tunnels.
+
+:::info
+The Obol Stack is alpha software. For production deployments, refer to the respective network documentation and use appropriate infrastructure.
+:::
+
+## What is the Obol Stack?
+
+Obol Stack is a two-part system:
+
+1. **obolup.sh** - A bootstrap installer that sets up your environment
+2. **obol CLI** - A Go-based binary for stack, agent, and network management
+
+The stack runs entirely on your local machine using [k3d](https://k3d.io/) (Kubernetes in Docker), providing a lightweight yet fully-featured Kubernetes environment.
+
+## Key features
+
+* **Agent-first** - Deploy an AI agent (OpenClaw) that can interact with blockchain networks and expose services.
+* **Multiple network support** - Deploy Ethereum nodes, Aztec sequencers, and more.
+* **Unique deployments** - Each installation creates a uniquely-namespaced deployment, allowing multiple instances to run simultaneously.
+* **Public access** - Expose services to the internet via Cloudflare tunnels and x402 payment gateways.
+* **Simplified tooling** - Wraps kubectl, helm, and other Kubernetes tools with automatic configuration.
+
+## CLI overview
+
+| Command | Description |
+| --------------------------------------------- | ------------------------------ |
+| `obol stack init / up / down / purge` | Cluster lifecycle management |
+| `obol agent init` | Set up the AI agent (OpenClaw) |
+| `obol openclaw dashboard / setup / ...` | Manage OpenClaw instances |
+| `obol model setup / status` | Configure LLM providers |
+| `obol network list / install / sync / delete` | Manage blockchain networks |
+| `obol app install / sync / list / delete` | Install arbitrary Helm charts |
+| `obol tunnel status / login / provision` | Manage Cloudflare tunnels |
+| `obol kubectl / helm / k9s` | Kubernetes tool passthroughs |
+
+## Default infrastructure
+
+When you start the stack, the following services are deployed automatically:
+
+| Service | Namespace | Description |
+| ----------------- | --------------- | ------------------------------------------------ |
+| **Traefik** | `traefik` | Gateway API ingress controller |
+| **Cloudflared** | `traefik` | Cloudflare tunnel connector |
+| **ERPC** | `erpc` | Unified RPC load balancer for Ethereum endpoints |
+| **Obol Frontend** | `obol-frontend` | Web management dashboard |
+| **Monitoring** | `monitoring` | Prometheus + kube-prometheus-stack |
+| **llmspy** | `llm` | LLM proxy/router for AI agent traffic |
+
+## System requirements
+
+### Prerequisites
+
+* **Docker** 20.10.0 or later (daemon must be running)
+* **macOS** (Darwin) or **Linux**
+* **amd64** or **arm64** architecture
+
+### Resource recommendations
+
+| Component | Minimum | Recommended |
+| ----------- | ------- | --------------------------- |
+| **CPU** | 4 cores | 8 cores |
+| **RAM** | 8 GB | 16 GB |
+| **Storage** | 50 GB | 500+ GB (varies by network) |
+
+:::warning
+Running full Ethereum nodes requires significant disk space. Mainnet execution clients can require 1+ TB of storage.
+:::
+
+## Architecture overview
+
+```
++---------------------------------------------------------+
+| Obol Stack |
++---------------------------------------------------------+
+| obol CLI |
+| +-- stack (init, up, down, purge) |
+| +-- agent (init) |
+| +-- openclaw (dashboard, setup, sync, skills, ...) |
+| +-- model (configure, status) |
+| +-- network (list, install, sync, delete) |
+| +-- app (install, sync, list, delete) |
+| +-- tunnel (status, login, provision) |
+| +-- kubectl / helm / helmfile / k9s |
++---------------------------------------------------------+
+| k3d Cluster |
+| +-- Traefik Gateway (ports 80, 8080, 443, 8443) |
+| +-- Cloudflared (public tunnel) |
+| +-- llmspy (LLM gateway) |
+| +-- ERPC (RPC load balancer) |
+| +-- Obol Frontend (web dashboard) |
+| +-- Monitoring (Prometheus) |
++---------------------------------------------------------+
+| Deployments |
+| +-- openclaw-Staking Fundamentals
Definitions for distributed validators, clusters, key shares, and all other lingo.
+How Charon Works
Dig into Charon, our middleware that enables DVT.
+The Obol Launchpad
A one-stop shop to deploy validators, explore operators, or claim rewards.
+The Obol Token
Details on the OBOL token utility and mechanics.
+How Obol Is Unique
Comparison of Obol's middleware design with other DV implementations.
+FAQs
Answers to common questions that have been raised in our community.
++::: +### Who This Kit Is For + +**Node operators** who are: + +* Being asked to **deploy, and operate** an stVault for a fund, DAO, protocol, or other allocator +* Building that vault on top of a **multi-operator Obol DV** rather than a single operator / single client setup + +**Capital allocators** who: + +* Need to understand **why** a DV-backed stVault can support more favorable risk assessments and reserve ratios +* Want a clear checklist for vetting operators and understanding what strong DV cluster operations look like + +### Why Obol DVs Are the Best Way to Deploy an stVault + +Lido V3's stVault design unlocks new levels of **capital efficiency** for node operators and institutional stakers. Obol Distributed Validators are **the most capital-efficient way to run a vault on Lido V3**. + +One of Lido V3's key innovations is the **Reserve Ratio (RR)**, which determines how much ETH must be kept as a reserve buffer relative to minted stETH. Lido is proposing a **2% Reserve Ratio tier for verified multi-operator DV vaults**, allowing up to **98% stETH minting capacity**. This is the most favorable tier. By comparison, the next-highest default tier for identified operators proposes a 5% RR with only 95% minting capacity. + +**Obol Distributed Validators unlock the highest minting capacity available on Lido V3.** + +#### Key Benefits + +* **Unlock the highest capital efficiency**\ + Multi-operator DV vaults qualify for the 2% Reserve Ratio tier, offering 98% stETH minting capacity, the most capital-efficient configuration on Lido V3. +* **Distribute responsibility across multiple operators**\ + Reduce reliance on any single infrastructure provider, company, or jurisdiction. Multi-operator setups distribute private key shares across many entities. +* **Maximize client and implementation diversity**\ + Run multiple consensus and execution client combinations inside the same vault, strengthening the vault's resilience and reducing correlation risks. +* **Superior liveness and fault tolerance**\ + Obol's fault-tolerant infrastructure means your validators keep performing even if individual operators experience downtime or failures. +* **Enterprise-grade security**\ + Leverage best-in-class security that institutional stakers and asset managers require for managing significant stake. + +### 📚 How This Integration Kit Is Organized + +**For Node Operators – Implementation Guide** + +A practical guide to designing, deploying, and operating an stVault using Obol DVs, including: + +* What to collect from the vault owner +* How to design your DV cluster (operators, clients, geos) +* How to rehearse on testnet and prepare for mainnet launch +* How this integrates into the Lido V3 stVault flow + +👉 [**Read the Node Operator Guide →**](lido-v3-stvault-for-node-operator.md) +**For Capital Allocators – Design & Risk Overview** + +A higher-level walkthrough of: + +* What you are optimizing for (safety, yield, minting capacity, counterparty risk) +* Why multi-operator DVs are different from "just another node operator" +* How Obol's [**Cluster-as-a-Service**](https://hubs.ly/Q03Y2Srl0) offering can help guide your decisions +* What to ask from your operators or from Obol directly + +👉 [**Read the Capital Allocator Guide →**](lido-v3-stvault-for-capital-allocators.md) +**Support & Services for stVault Builders** + +How to: + +* [Get in touch with the Obol team](mailto:lido@obol.tech) for guidance and design help +* Leverage Obol's [**Cluster-as-a-Service**](https://hubs.ly/Q03Y2Srl0) offering to get set up +### 🔗 Quick Links + +* [**Default risk assessment framework**](https://research.lido.fi/t/default-risk-assessment-framework-and-fees-parameters-for-lido-v3-stvaults/10504) — Explore how Tiers within Identified Node Operators effect the reserve ratio of the vault +* [**DV Cluster identification and assessment**](https://docs.lido.fi/run-on-lido/stvaults/node-operators-identification/#dvt-cluster-identification-and-assessment) — See the identification requirements for each node operator in a cluster in order to qualify for improved Tiering +* [**stVaults Doc Center**](https://docs.lido.fi/run-on-lido/stvaults/) — View Lido's comprehensive guides which detail how to create any product powered by stVaults + +#### Future Extensions + +As Lido's [**DeFi wrapper**](https://hackmd.io/@lido/lido-v3-wrapper-design) and more advanced strategies roll out, we will extend this kit with: + +* End-to-end reference architectures that combine stVaults, wrappers, and multi-operator DV clusters +* Config and deployment examples taken from real-world vaults +* Case studies, including the "Ethereum client team vault", once it is live + +**For now, this page gives you the map. The linked sections show you how to actually build and run the vaults behind it.** diff --git a/versioned_docs/version-v1.9/run-a-dv/prepare/README.md b/versioned_docs/version-v1.9/run-a-dv/prepare/README.md new file mode 100644 index 0000000000..a4d3971909 --- /dev/null +++ b/versioned_docs/version-v1.9/run-a-dv/prepare/README.md @@ -0,0 +1,7 @@ +--- +sidebar_label: "Prepare to Run a DV" +slug: /run-a-dv/prepare +--- + +# Prepare to Run a DV + diff --git a/versioned_docs/version-v1.9/run-a-dv/prepare/deployment-best-practices.md b/versioned_docs/version-v1.9/run-a-dv/prepare/deployment-best-practices.md new file mode 100644 index 0000000000..7168c7d6e1 --- /dev/null +++ b/versioned_docs/version-v1.9/run-a-dv/prepare/deployment-best-practices.md @@ -0,0 +1,117 @@ +--- +description: "DV Deployment best practices, for running an optimal Distributed Validator setup at scale." +sidebar_label: "Deployment Best Practices" +slug: /run-a-dv/prepare/deployment-best-practices +--- + +# Deployment Best Practices + +The following are a selection of best practices for deploying Distributed Validator Clusters at scale on mainnet. + +## Hardware Specifications + +The following specifications are recommended for bare metal machines for clusters intending to run a significant number of mainnet validators: + +### Minimum Specs + +* A CPU with 4+ cores, favouring high clock speed over more cores. ( >3.0GHz and higher or a cpubenchmark [single thread](https://www.cpubenchmark.net/singleThread.html) score of >2,500) +* 16GB of RAM +* 2TB+ free SSD disk space (for mainnet) +* 1000 read/write SSD IOPS +* 500MB/s read/write SSD speed +* 10Mbps internet bandwidth + +### Recommended Specs for extremely large clusters + +* A CPU with 8+ physical cores, with clock speeds >3.5Ghz +* 32GB+ RAM (depending on the EL+CL clients) +* 4TB+ NVMe storage +* 2000 read/write SSD IOPS +* 1000MB/s read/write SSD speed +* 25Mbps internet bandwidth + +An NVMe storage device is **highly recommended for optimal performance**, offering nearly 10x more random read/writes per second than a standard SSD. + +Inadequate hardware (low-performance virtualized servers and/or slow HDD storage) has been observed to hinder performance, indicating the necessity of provisioning adequate resources. **CPU clock speed and Disk throughput+latency are the most important factors for running a performant validator.** + +Note that the Charon client itself takes less than 1GB of RAM and minimal CPU load. In order to optimise both performance and cost-effectiveness, it is recommended to prioritise physical over virtualised setups. Such configurations typically offer greater performance and minimise overhead associated with virtualisation, contributing to improved efficiency and reliability. + +When constructing a DV cluster, it is important to be conscious of whether a cluster runs across cloud providers or stays within a single provider's private networking. This likely can impact the bandwidth and latency of the connections between nodes, as well as the egress costs of the cluster (Charon has a relatively low communication with its peers, averaging 10s of kb/s in large mainnet clusters). Ideally, bare metal machines in different locations within the same continent and with at least two providers, balances redundancy and performance. + +## Intra-cluster Latency + +It is recommended to **keep peer ping latency below 235 milliseconds for all peers in a cluster**. Charon should report a consensus duration averaging under 1 second through its prometheus metric `core_consensus_duration_seconds_bucket` and associated grafana panel titled "Consensus Duration". + +In cases where latencies exceed these thresholds, efforts should be made to reduce the physical distance between nodes or optimise Internet Service Provider (ISP) settings accordingly. Ensure all nodes are connecting to one another directly rather than through a relay. + +For high-scale, performance deployments; inter-peer latency of < 25ms is optimal, along with an average consensus duration under 100ms. + +## Peer Connections + +Charon clients can establish connections with one another in two ways: either through a third publicly accessible server known as [a relay](../../learn/charon/charon-cli-reference.md#host-a-relay) or directly with one another if they can establish a connection. The former is known as a relay connection and the latter is known as a direct connection. + +It is important that all nodes in a cluster be directly connected to one another - this can halve the latency between them and reduces bandwidth constraints significantly. Opening Charon’s p2p port (the default is `3610`) to the Internet, or configuring your routers NAT gateway to permit connections to your Charon client, are what are required to facilitate a direct connection between clients. Confirm direct peer reachability with `charon alpha test peers`. + +## Node Locations + +For optimal performance and high availability, it is recommended to provision machines or virtual machines (VMs) within the same continent. This practice helps minimise potential latency issues ensuring efficient communication and responsiveness. Consider maps of [undersea internet cables](https://www.submarinecablemap.com/) when selecting locations across oceans with low latency. + +When operating multiple nodes within a cloud environment, care must be taken to distribute nodes across availability zones to avoid AZ outages becoming cluster outages. + +## Instance Independence + +Each node in the cluster should have its own independent beacon node (EL+CL) and validator client as well as Charon client. Sharing beacon nodes between the different nodes significantly hinders the benefits of running a Charon cluster by reintroducing a single point of failure to the distributed architecture. + +## Beacon Node Redundancy + +In cases where multiple beacon nodes are available to a node, Charon should be configured to use both in parallel by adding them to `--beacon-node-endpoints`. This will query each beacon node and use the fastest response, improving both performance and availability. Only in situations where this is not economically feasible should `--fallback-beacon-node-endpoints` be used instead, which will query beacon nodes sequentially. Sequential querying will decrease performance due to timeouts being required before failover. + +## Placement of Charon clients + +If you wish to divide a Distributed Validator node across multiple physical or virtual machines; locate the Charon client on the EL/CL machine instead of the VC machine. This setup reduces latency from Charon to the consensus layer, as well as keeping the public-internet connected clients separate from the clients that hold the validator private keys. If Charon and the VC connect over an untrusted network, the connection should be encrypted (VPN, Kubernetes [CNI](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) etc). + +## Node Configuration + +Cluster sizes that allow for Byzantine Fault Tolerance are recommended as they are safer than clusters with simply Crash Fault Tolerance (See this guide for reference - [Cluster Size and Resilience](../../learn/charon/cluster-configuration.md#cluster-size-and-resilience)). A minimum of four Charon nodes is strongly recommended for this reason. + +## MEV-Boost Relays + +MEV relays are configured at the Consensus Layer or MEV-boost client level. Refer to our [guide](../../advanced-and-troubleshooting/advanced/enable-mev.mdx) to ensure all necessary configuration has been applied to your clients. As with all validators, low latency during proposal opportunities is extremely important. By default, MEV-Boost waits for all configured relays to return a bid, or will timeout if any have not returned a bid within 950ms. This default timeout is generally too slow for a distributed cluster (think of this time as additive to the time it takes the cluster to come to consensus, both of which need to happen within a 2 second window for optimal proposal broadcasting). It is likely better to only list relays that are located geographically near your node, so that once all relays respond (e.g. in < 50ms) your cluster will move forward with the proposal. + +Use Charon's [`test mev` command](test-a-cluster.mdx#test-mev-relay) to test a number of your preferred relays, and select the two or three relays with the lowest latency to your node(s), you do not need to have the same relays on each node in a cluster. + +## Client Diversity + +Obol clusters should consist of a mix of different consensus, execution, and validator clients. Charon can't [detect client failures](../../learn/further-reading/ethereum_and_dvt.md#deep-dive-into-dvt-and-charons-architecture) if all nodes are using the same client. At a minimum, no single client should comprise the [threshold](../../learn/charon/cluster-configuration.md#cluster-size-and-resilience) of nodes in the cluster. For example: + +A 7 node cluster with 4 Teku, 2 Lodestar and 1 Nimbus for validator clients **does not** have client error safety since the threshold (4) of votes can be met with just the Teku client. + +A 7 node cluster with 3 Teku, 3 Lodestar and 1 Nimbus for validator clients **is safe against a single client bug** as the threshold is not met by any one client. + +Keep in mind that client diversity includes EL, CL and VC clients and each layer needs an appropriate mix for optimal security. + +Remote signers can be included as well, such as Web3signer or Dirk. A diversity of private key infrastructure setups further reduces the risk of total key compromise. + +Tested client combinations can be found in the [release notes](https://github.com/ObolNetwork/charon/releases) for each Charon version. + +## Execution Layer Configuration + +When available on the EL client (e.g Nethermind), blob inclusion for locally-built blocks should be set to 0. Setting blob count to 0 for locally-built blocks avoids the additional latency of gathering blob transactions, which matters when falling back from MEV relay blocks under time pressure. + +## Metrics Monitoring + +Node operators should push [standard monitoring](../start/obol-monitoring.mdx) (Prometheus) and logging (Loki) data to Obol Labs' core team's cloud infrastructure for in-depth analysis of performance data and to assist during potential issues that may arise. The logging and metrics configuration values will be provided by the Obol team during onboarding. + +It is recommended that operators independently store information on their node health over the course of the validator lifecycle as well as any information on validator performance that they collect during the normal life cycle of a validator. + +## Obol Splits + +Leveraging [Obol Splits](../../learn/intro/obol-splits.md) smart contracts allows for non-custodial fund handling and allows for net customer payouts in an ongoing manner. Obol Splits ensure no commingling of funds across customers, and maintain full non-custodial integrity. Read more about Obol Splits [here](../../learn/intro/frequently-asked-questions.mdx#obol-splits). + +## Deposit Process + +Deposit processes can be done via an automated script. This can be used for DV clusters until they reach the desired number of validators. + +It is important to allow time for the validators to be activated (see current [queue](https://beaconcha.in/validators/queues)). + +Consider using batching smart contracts to reduce the gas cost of a script, but take caution in their integration not to make an invalid deposit. diff --git a/versioned_docs/version-v1.9/run-a-dv/prepare/how_where_dvs.md b/versioned_docs/version-v1.9/run-a-dv/prepare/how_where_dvs.md new file mode 100644 index 0000000000..1c94049a40 --- /dev/null +++ b/versioned_docs/version-v1.9/run-a-dv/prepare/how_where_dvs.md @@ -0,0 +1,43 @@ +--- +description: "How and where to run DVs" +sidebar_label: "How and Where To Run DVs" +slug: /run-a-dv/prepare/how_where_dvs +--- + +# How and Where To Run DVs + +## Launchers and Deployment Tooling + +* [Obol CDVN](https://github.com/ObolNetwork/charon-distributed-validator-node) +* [Obol K8s](https://github.com/ObolNetwork/charon-k8s-distributed-validator-node) +* [Obol Helm Charts](https://github.com/ObolNetwork/helm-charts) +* [Obol Ansible Playbooks](https://github.com/ObolNetwork/obol-ansible) +* [Dappnode](https://docs.dappnode.io/docs/user/staking/ethereum/dvt-technologies/obol-network/) +* [Stereum](https://stereum.net/) +* [Sedge](https://github.com/ObolNetwork/sedge/blob/develop/docs/docs/quickstart/charon.mdx) +* [Terraform Charon Relay](https://github.com/ObolNetwork/terraform-charon-relay) +* [Terraform Grafana Charon dashboards](https://github.com/ObolNetwork/terraform-grafana-dashboards) + +## Quickstart Guides + +* [Run a DV alone](../start/create-a-dv-alone.mdx) +* [Run a DV as a group](../start/create-a-dv-with-a-group.mdx) + +## CL+VC Combinations: + +**Legend** + +* ✅: All duties succeed in testing +* 🟡: All duties succeed in testing, except non-penalised aggregation duties +* 🟠: Duties may fail for this combination +* 🔴: One or more duties fails consistently + +| Validator 👉 Consensus 👇 | Teku v24.10.3 | Lighthouse v5.3.0 | Lodestar v1.23.0 | Nimbus v24.10.0 | Prysm v5.1.2 | Remarks | +| ------------------------- | ------------- | ----------------- | ---------------- | --------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Teku v24.10.3 | ✅ | 🟡 | ✅ | ✅ | 🟠 | Teku `beacon node` needs the `--validators-graffiti-client-append-format=DISABLED` flag in order to produce blocks properly. Teku `validator client` is only failing aggregation duties 50% of the time, which are not directly penalised but impact network density at high scale. | +| Lighthouse v5.3.0 | ✅ | 🟡 | ✅ | ✅ | ✅ | Lighthouse `validator client` is only failing aggregation duties, which are not directly penalised but impact network density at high scale. | +| Lodestar v1.23.0 | ✅ | 🟡 | ✅ | ✅ | 🟠 | | +| Nimbus v24.10.0 | ✅ | 🟡 | ✅ | ✅ | 🟠 | | +| Prysm v5.1.2 | ✅ | 🟡 | ✅ | ✅ | ✅ | Prysm `validator client` is failing aggregation duties 50% of the time, which are not directly penalised but impact network density at high scale. In some combinations rare failures of attestation and proposal duties were observed (0-2% per epoch). | + +Note: for the most recent compatibility information, please see the [release notes](https://github.com/ObolNetwork/charon/releases/) from the most recent release of Charon. diff --git a/versioned_docs/version-v1.9/run-a-dv/prepare/test-a-cluster.mdx b/versioned_docs/version-v1.9/run-a-dv/prepare/test-a-cluster.mdx new file mode 100644 index 0000000000..2517f2bea9 --- /dev/null +++ b/versioned_docs/version-v1.9/run-a-dv/prepare/test-a-cluster.mdx @@ -0,0 +1,641 @@ +--- +sidebar_label: "Test a Cluster" +slug: /run-a-dv/prepare/test-a-cluster +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +# Test a Cluster + +Charon test commands are designed to help you evaluate the performance and readiness of your candidate cluster. It allows you to test your connection to other Charon peers, the performance of your beacon node(s), the readiness of your validator client, the performance of the MEV relays you will be using and the infrastructure on which you will run the cluster. It prints a performance report to the standard output (which can be omitted with the `--quiet` flag) and a machine-readable JSON format of the report if the `--output-json` flag is set. + +:::tip +Adding the `--publish` flag to the below commands, and running the command from the directory containing your `.charon` folder, will submit the test results to the [Obol API](../../api/what-is-this-api.md). Publishing your performance reports grows the staking node dataset, and allows Obol and Ethereum development teams to make data-driven choices regarding the required specs for validating Ethereum. We hope you will consider opting in. +::: + +
All OB → Principal Recipient
New Principal = CP - OB
CP → Principal RecipientOB - CP → Reward Recipient
New Principal = 0
Important: Review these details carefully before proceeding. Once you accept the cluster configuration, you'll be committed to the withdrawal and fee recipient addresses set by the creator.
+
+
+
+What happens if I lose my ENR private key?
+ +If you lose your ENR private key (`.charon/charon-enr-private-key`), you won't be able to participate in the DKG ceremony or start the DV cluster successfully. It's critical to back up this file securely before proceeding with the cluster creation process. + +
+
+
+
+Can I change the cluster configuration after it's been created?
+ +Once a cluster configuration has been created and signed by all operators, it cannot be changed. If you need to modify the cluster settings, you'll need to create a new cluster configuration and have all operators sign the new configuration. + +
+
+
+
+What if one operator doesn't show up for the DKG ceremony?
+ +All operators must participate simultaneously in the DKG ceremony for it to complete successfully. If an operator is unable to participate, you'll need to wait for them or create a new cluster configuration without that operator. It's recommended to schedule the DKG ceremony at a time when all operators can participate. + +
+
+
+
+How do I know if my node is properly connected to the cluster?
+ +You can verify your node's connection status by checking the Grafana dashboard (if using CDVN) or monitoring the Charon logs. Your Charon client should be able to connect to all peers directly, and you should see successful handshakes in the logs. The dashboard will show connection status for each peer in the cluster. + +
+
+
+
+What should I do if the DKG ceremony fails?
+ +If the DKG ceremony fails, check the logs for error messages. Common issues include network connectivity problems, mismatched cluster definitions, or operators not running the command simultaneously. Ensure all operators have the correct `cluster-definition.json` file and are running the DKG command at the same time. You may need to restart the DKG process after resolving any issues. + +
+
+
+
+Can I use different client combinations for different operators in the cluster?
+ +Yes, each operator can use different execution and consensus clients. The Charon client handles the coordination between different client implementations, so operators can choose the clients that work best for their infrastructure while still participating in the same distributed validator cluster. + +
+
+
+
+What happens if I need to replace an operator in the cluster?
+ +Replacing an operator requires creating a new cluster configuration with the new operator's details and having all remaining operators plus the new operator sign the new configuration. This will require running a new DKG ceremony. For more information, see the [operator rotation guide](../../advanced-and-troubleshooting/advanced/operator-rotation.md). + +
+
+
diff --git a/versioned_docs/version-v1.9/run-a-dv/start/obol-monitoring.mdx b/versioned_docs/version-v1.9/run-a-dv/start/obol-monitoring.mdx
new file mode 100644
index 0000000000..bb55abba87
--- /dev/null
+++ b/versioned_docs/version-v1.9/run-a-dv/start/obol-monitoring.mdx
@@ -0,0 +1,119 @@
+---
+description: "Add credentials to help the Obol Team monitor the health of your cluster"
+sidebar_label: "Push Metrics and Logs to Obol"
+slug: /run-a-dv/start/obol-monitoring
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Push Metrics and Logs to Obol
+
+:::info
+This is **optional but encouraged**, and does not confer any special privileges within Obol.
+:::
+
+## Metrics
+
+Metrics are statistics that are gathered on a periodic basis and used to visualise the health and performance of your Charon node and DV cluster. These metrics power your local Grafana dashboard, as well as the hosted dashboards. Submitting metrics to the Obol Core team will allow you to see advanced performance analytics on Obol's hosted platform, as well as to opt into automated alerting whenever something goes wrong with your node.
+
+