Docs revamp

.vscode/settings.json

@@ -0,0 +1,2 @@
+{
+}

docs/int/quickstart/advanced/_category_.json → docs/advanced/_category_.json

@@ -1,5 +1,5 @@
 {
     "label": "Advanced Guides",
-    "position": 10,
+    "position": 3,
     "collapsed": true
   }

docs/int/quickstart/advanced/quickstart-builder-api.md → docs/advanced/quickstart-builder-api.md

@@ -6,7 +6,7 @@ description: Run a distributed validator cluster with the builder API (MEV-Boost
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-# Run a cluster with MEV enabled
+# Enable MEV
 
 :::caution
 Charon is in a beta state and should be used with caution according to its [Terms of Use](https://obol.tech/terms.pdf).

docs/int/quickstart/advanced/quickstart-sdk.md → docs/advanced/quickstart-sdk.md

@@ -12,7 +12,7 @@ import TabItem from '@theme/TabItem';
 The Obol-SDK is in a beta state and should be used with caution on testnets only.
 :::
 
-This is a walkthrough of using the [Obol-SDK](https://www.npmjs.com/package/@obolnetwork/obol-sdk) to propose a four-node distributed validator cluster for creation using the [DV Launchpad](../../../dvl/intro.md).
+This is a walkthrough of using the [Obol-SDK](https://www.npmjs.com/package/@obolnetwork/obol-sdk) to propose a four-node distributed validator cluster for creation using the [DV Launchpad](../dvl_intro.md).
 
 ## Pre-requisites
 
@@ -85,9 +85,9 @@ console.log(
 
 ## Invite the Operators to complete the DKG
 
-Once the Obol-API returns a `configHash` string from the `createClusterDefinition` method, you can use this identifier to invite the operators to the [Launchpad](../../../dvl/intro.md) to complete the process
+Once the Obol-API returns a `configHash` string from the `createClusterDefinition` method, you can use this identifier to invite the operators to the [Launchpad](../dvl_intro.md) to complete the process
 
-1. Operators navigate to `https://<NETWORK_NAME_HERE>.launchpad.obol.tech/dv?configHash=<CONFIG_HASH_HERE>` and complete the [run a DV with others](../group/quickstart-group-operator.md) flow.
+1. Operators navigate to `https://<NETWORK_NAME_HERE>.launchpad.obol.tech/dv?configHash=<CONFIG_HASH_HERE>` and complete the [run a DV with others](../getting_started/quickstart_group.md) flow.
 1. Once the DKG is complete, and operators are using the `--publish` flag, the created cluster details will be posted to the Obol API
 1. The creator will be able to retrieve this data with `obol.getClusterLock(configHash)`, to use for activating the newly created validator.
 

docs/int/quickstart/advanced/quickstart-split.md → docs/advanced/quickstart-split.md

@@ -10,12 +10,12 @@ Charon is in a beta state and should be used with caution according to its [Term
 
 This process should only be used if you want to split an *existing validator private key* into multiple private key shares for use in a Distributed Validator Cluster. If your existing validator is not properly shut down before the Distributed Validator starts, your validator may be slashed.
 
-If you are starting a new validator, you should follow a [quickstart guide](../index.md) instead.
+If you are starting a new validator, you should follow a [quickstart guide](../getting_started/quickstart_overview.md) instead.
 
 If you use MEV-Boost, make sure you turned off your MEV-Boost service for the time of splitting the keys, otherwise you may hit [this issue](https://github.com/ObolNetwork/charon/issues/2770).
 :::
 
-Split an existing Ethereum validator key into multiple key shares for use in an [Obol Distributed Validator Cluster](../../key-concepts#distributed-validator-cluster).
+Split an existing Ethereum validator key into multiple key shares for use in an [Obol Distributed Validator Cluster](../intro/key-concepts.md#distributed-validator-cluster).
 
 
 ## Pre-requisites

docs/int/quickstart/advanced/self-relay.md → docs/advanced/self-relay.md

@@ -35,4 +35,4 @@ Configure **ALL** charon nodes in your cluster to use this relay:
 
 Note that a local `relay/.charon/charon-enr-private-key` file will be created next to `relay/docker-compose.yml` to ensure a persisted relay ENR across restarts.
 
-A list of publicly available relays that can be used is maintained [here](../../faq/risks.md#risk-obol-hosting-the-relay-infrastructure). 
+A list of publicly available relays that can be used is maintained [here](../faq/risks.md). 

docs/charon/_category_.json

@@ -1,5 +1,5 @@
 {
   "label": "Charon",
-  "position": 3,
-  "collapsed": false
+  "position": 5,
+  "collapsed": true
 }

docs/charon/charon-cli-reference.md

@@ -358,4 +358,4 @@ Flags:
       --p2p-relays strings                Comma-separated list of libp2p relay URLs or multiaddrs. (default [https://0.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.
 ```
-You can also consider adding [alternative public relays](../int/faq/risks.md#risk-obol-hosting-the-relay-infrastructure) to your cluster by specifying a list of `p2p-relays` in [`charon run`](#run-the-charon-middleware).
+You can also consider adding [alternative public relays](../faq/risks.md) to your cluster by specifying a list of `p2p-relays` in [`charon run`](#run-the-charon-middleware).

docs/charon/cluster-configuration.md

@@ -67,7 +67,7 @@ The schema of the `cluster-definition.json` is defined as:
 
 ### Using the DV Launchpad
 
-- A [`leader/creator`](docs/int/quickstart/group/index.md), that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster"
+- A `leader/creator`, that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster"
 - The `leader/creator` uses the user interface to configure all of the important details about the cluster including:
   - The `Withdrawal Address` for the created validators
   - The `Fee Recipient Address` for block proposals if it differs from the withdrawal address

docs/charon/dkg.md

@@ -7,11 +7,11 @@ sidebar_position: 2
 
 ## Overview
 
-A [**distributed validator key**](docs/int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus.
+A [**distributed validator key**](../intro/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus.
 
-To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](docs/int/key-concepts.md#distributed-validator-key-generation-ceremony).
+To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](../intro/key-concepts.md#distributed-validator-key-generation-ceremony).
 
-The charon client has the responsibility of securely completing a distributed key generation ceremony with its counterparty nodes. The ceremony configuration is outlined in a [cluster definition](../charon/cluster-configuration).
+The charon client has the responsibility of securely completing a distributed key generation ceremony with its counterparty nodes. The ceremony configuration is outlined in a [cluster definition](../charon/cluster-configuration.md).
 
 ## Actors Involved
 
@@ -70,4 +70,4 @@ There are a number of aspects to this trust surface that can be mitigated with a
 
 ### Sample Configuration and Lock Files
 
-Refer to the details [here](../charon/cluster-configuration).
+Refer to the details [here](../charon/cluster-configuration.md).

docs/charon/intro.md

@@ -5,7 +5,7 @@ sidebar_position: 1
 
 # Introduction
 
-This section introduces and outlines the Charon *[kharon]* middleware, Obol's implementation of DVT. Please see the [key concepts](/docs/int/key-concepts) section as background and context.
+This section introduces and outlines the Charon *[kharon]* middleware, Obol's implementation of DVT. Please see the [key concepts](../intro/key-concepts.md) section as background and context.
 
 ## What is Charon?
 
@@ -79,4 +79,4 @@ The following is an outline of the services that can be exposed by charon.
 
 ## Getting started
 
-For more information on running charon, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). 
+For more information on running charon, take a look at our [Quickstart Guides](../getting_started/quickstart_overview.md). 

docs/cg/_category_.json → docs/contribution&feedback/_category_.json

@@ -1,5 +1,5 @@
 {
   "label": "Contribution & Feedback",
-  "position": 10,
+  "position": 9,
   "collapsed": true
 }

docs/dvl/intro.md → docs/dvl_intro.md

@@ -1,21 +1,21 @@
 ---
 description: A dapp to securely create Distributed Validators alone or with a group.
-sidebar_position: 1
+sidebar_position: 6
 ---
 
-# Introduction
+# DV Launchpad
 
 ![DV Launchpad Promo Image](/img/DistributeYourValidators.svg)
 
 In order to activate an Ethereum validator, 32 ETH must be deposited into the official deposit contract. 
 
 The vast majority of users that created validators to date have used the **[~~Eth2~~ Staking Launchpad](https://launchpad.ethereum.org/)**, a public good open source website built by the Ethereum Foundation alongside participants that later went on to found Obol. This tool has been wildly successful in the safe and educational creation of a significant number of validators on the Ethereum mainnet.
 
-To facilitate the generation of distributed validator keys amongst remote users with high trust, the Obol Network developed and maintains a website that enables a group of users to come together and create these threshold keys: [**The DV Launchpad**](https://goerli.launchpad.obol.tech/).
+To facilitate the generation of distributed validator keys amongst remote users with high trust, the Obol Network developed and maintains a website that enables a group of users to come together and create these threshold keys: **The DV Launchpad**.
 
 ## Getting started
 
-For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). 
+For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](../docs/getting_started/quickstart_overview.md). 
 
 ## DV Launchpad Links
 

docs/int/faq/_category_.json → docs/faq/_category_.json

@@ -1,5 +1,5 @@
 {
   "label": "FAQ",
-  "position": 10,
+  "position": 4,
   "collapsed": true
 }

docs/int/faq/general.md → docs/faq/general.md

@@ -36,7 +36,7 @@ Recommended specifications:
 
 For more hardware considerations, check out the [ethereum.org guides](https://ethereum.org/en/developers/docs/nodes-and-clients/run-a-node/#environment-and-hardware) which explores various setups and trade-offs, such as running the node locally or in the cloud.
 
-For now, Geth, Teku & Lighthouse clients are packaged within the docker compose file provided in the [quickstart guides](../quickstart/group), so you don't have to install anything else to run a cluster. Just make sure you give them some time to sync once you start running your node.
+For now, Geth, Teku & Lighthouse clients are packaged within the docker compose file provided in the [quickstart guides](../getting_started/quickstart_overview.md), so you don't have to install anything else to run a cluster. Just make sure you give them some time to sync once you start running your node.
 
 ### What is the difference between a node, a validator and a cluster?
 A node is a single instance of Ethereum EL+CL clients that can communicate with other nodes to maintain the Ethereum blockchain.
@@ -55,7 +55,7 @@ It is possible to migrate your Charon node to another machine running the same c
 
 Currently, the minimum is 4 operators with a threshold of 3.
 
-The threshold (aka quorum) corresponds to the minimum numbers of operators that need to be active for the validator(s) to be able to perform its duties. It is defined by the following formula `n-(ceil(n/3)-1)`. We strongly recommend using this default threshold in your DKG as it maximises liveness while maintaining BFT safety. Setting a 4 out of 4 cluster for example, would make your validator more vulnerable to going offline instead of less vulnerable. You can check the recommended threshold values for a cluster [here](../key-concepts.md#distributed-validator-threshold).
+The threshold (aka quorum) corresponds to the minimum numbers of operators that need to be active for the validator(s) to be able to perform its duties. It is defined by the following formula `n-(ceil(n/3)-1)`. We strongly recommend using this default threshold in your DKG as it maximises liveness while maintaining BFT safety. Setting a 4 out of 4 cluster for example, would make your validator more vulnerable to going offline instead of less vulnerable. You can check the recommended threshold values for a cluster [here](../intro/key-concepts.md#distributed-validator-threshold).
 
 ## Obol Splits
 
@@ -73,15 +73,15 @@ Generally Obol Splits are deployed in an immutable fashion, meaning you cannot e
 
 ### How do Obol Splits work?
 
-You can read more about how Obol Splits work [here](../../sc/introducing-obol-splits.md). 
+You can read more about how Obol Splits work [here](../sc_obol-splits.md). 
 
 ### Are Obol Splits open source?
 
 Yes, Obol Splits are licensed under GPLv3 and the source code is available [here](https://github.com/ObolNetwork/obol-splits). 
 
 ### Are Obol Splits audited?
 
-The Obol Splits contracts have been audited, though further development has continued on the contracts since. Consult the audit results [here](../../sec/smart_contract_audit.md). 
+The Obol Splits contracts have been audited, though further development has continued on the contracts since. Consult the audit results [here](../security/smart_contract_audit.md). 
 
 ### Are the Obol Splits contracts verified on Etherscan?
 
@@ -95,7 +95,7 @@ No. Any address can trigger the contracts to move the funds, they do not need to
 
 The most important decision is to be aware of whether or not the Split contract you are using has been set up with editability. If a splitter is editable, you should understand what the address that can edit the split does. Is the editor an EOA? Who controls that address? How secure is their seed phrase? Is it a smart contract? What can that contract do? Can the controller contract be upgraded? etc. Generally, the safest thing in Obol's perspective is not to have an editable splitter, and if in future you are unhappy with the configuration, that you exit the validator and create a fresh cluster with new settings that fit your needs. 
 
-Another aspect to be aware of is how the splitting of principal from rewards works using the Optimistic Withdrawal Recipient contract. There are edge cases relating to not calling the contracts periodically or ahead of a withdrawal, activating more validators than the contract was configured for, and a worst case mass slashing on the network. Consult the documentation on the contract [here](../../sc/introducing-obol-splits.md#optimistic-withdrawal-recipient), its audit [here](../../sec/smart_contract_audit.md), and follow up with the core team if you have further questions. 
+Another aspect to be aware of is how the splitting of principal from rewards works using the Optimistic Withdrawal Recipient contract. There are edge cases relating to not calling the contracts periodically or ahead of a withdrawal, activating more validators than the contract was configured for, and a worst case mass slashing on the network. Consult the documentation on the contract [here](../sc_obol-splits.md#optimistic-withdrawal-recipient), its audit [here](../security/smart_contract_audit.md), and follow up with the core team if you have further questions. 
 
 ## Debugging Errors in Logs