fixed all broken links (hopefully)

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/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/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?
 

docs/dvl_intro.md

@@ -11,7 +11,7 @@ In order to activate an Ethereum validator, 32 ETH must be deposited into the of
 
 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
 

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 
 

docs/faq/risks.md

@@ -8,9 +8,9 @@ description: Centralization Risks and mitigation
 ## Risk: Obol hosting the relay infrastructure
 **Mitigation**: Self-host a relay
 
-One of the risks associated with Obol hosting the [LibP2P relays](docs/charon/networking.md) infrastructure allowing peer discovery is that if Obol-hosted relays go down, peers won't be able to discover each other and perform the DKG. To mitigate this risk, external organizations and node operators can consider self-hosting a relay. This way, if Obol's relays go down, the clusters can still operate through other relays in the network. Ensure that all nodes in the cluster use the same relays, or they will not be able to find each other if they are connected to different relays.
+One of the risks associated with Obol hosting the [LibP2P relays](../charon/networking.md) infrastructure allowing peer discovery is that if Obol-hosted relays go down, peers won't be able to discover each other and perform the DKG. To mitigate this risk, external organizations and node operators can consider self-hosting a relay. This way, if Obol's relays go down, the clusters can still operate through other relays in the network. Ensure that all nodes in the cluster use the same relays, or they will not be able to find each other if they are connected to different relays.
 
-The following non-Obol entities run relays that you can consider adding to your cluster (you can have more than one per cluster, see the `--p2p-relays` flag of [`charon run`](../../charon/charon-cli-reference.md#the-run-subcommand)):
+The following non-Obol entities run relays that you can consider adding to your cluster (you can have more than one per cluster, see the `--p2p-relays` flag of [`charon run`](../charon/charon-cli-reference.md#the-run-subcommand)):
 
 | Entity    | Relay URL                                   |
 |-----------|---------------------------------------|
@@ -25,9 +25,9 @@ The following non-Obol entities run relays that you can consider adding to your
 Another risk associated with Obol is having the ability to update the [Charon code](https://github.com/ObolNetwork/charon) running on the network which could introduce vulnerabilities or malicious code. To mitigate this risk, operators can consider pinning specific versions of the code that have been thoroughly tested and accepted by the network. This would ensure that any updates are carefully vetted and reviewed by the community.
 
 ## Risk: Obol hosting the DV Launchpad
-**Mitigation**: Use [`create cluster`](docs/charon/charon-cli-reference.md) or [`create dkg`](docs/charon/charon-cli-reference.md) locally and distribute the files manually
+**Mitigation**: Use [`create cluster`](../charon/charon-cli-reference.md) or [`create dkg`](../charon/charon-cli-reference.md) locally and distribute the files manually
 
-Hosting the first Charon frontend, the [DV Launchpad](docs/dvl/intro.md), on a centralized server could create a single point of failure, as users would have to rely on Obol's server to access the protocol. This could limit the decentralization of the protocol and could make it vulnerable to attacks or downtime. Obol hosting the launchpad on a decentralized network, such as IPFS is a first step but not enough. This is why the Charon code is open-source and contains a CLI interface to interact with the protocol locally.
+Hosting the first Charon frontend, the [DV Launchpad](../dvl_intro.md), on a centralized server could create a single point of failure, as users would have to rely on Obol's server to access the protocol. This could limit the decentralization of the protocol and could make it vulnerable to attacks or downtime. Obol hosting the launchpad on a decentralized network, such as IPFS is a first step but not enough. This is why the Charon code is open-source and contains a CLI interface to interact with the protocol locally.
 
 To mitigate the risk of launchpad failure, consider using the `create cluster` or `create dkg` commands locally and distributing the key shares files manually.
 
@@ -37,4 +37,4 @@ To mitigate the risk of launchpad failure, consider using the `create cluster` o
 
 The final centralization risk associated with Obol is the possibility of the company going bankrupt or acting maliciously, which would lead to a loss of control over the network and potentially cause damage to the ecosystem. To mitigate this risk, Obol has implemented a key recovery mechanism. This would allow the clusters to continue operating and to retrieve full private keys even if Obol is no longer able to provide support.
 
-A guide to recombine key shares into a single private key can be accessed [here](../quickstart/advanced/quickstart-combine.md).
+A guide to recombine key shares into a single private key can be accessed [here](../advanced/quickstart-combine.md).

docs/security/ev-assessment.md

@@ -64,9 +64,9 @@ Obol’s business model is to eventually capture a portion of the revenue genera
 
 Obol’s product consists of three main components, each run by its own team: a webapp, a client, and smart contracts.
 
-- [DV Launchpad](../dvl/intro.md): A webapp to create and manage distributed validators.
+- [DV Launchpad](../dvl_intro.md): A webapp to create and manage distributed validators.
 - [Charon](../charon/intro.md): A middleware client that enables operators to run distributed validators.
-- [Solidity](../sc/introducing-obol-splits.md): Withdrawal and fee recipient contracts for use with distributed validators.
+- [Solidity](../sc_obol-splits.md): Withdrawal and fee recipient contracts for use with distributed validators.
 
 ## Analysis - Cluster Setup and DKG