From 14bd8263e09ea9d7930f1845b69d20e31292aa14 Mon Sep 17 00:00:00 2001 From: ryzhak Date: Mon, 9 Jun 2025 22:00:54 +0300 Subject: [PATCH] docs: fix broken links --- for-developers/oracles.md | 6 +++--- for-developers/unstake.md | 2 +- for-operators/dvt/running-operator-with-dvt.md | 6 +++--- for-operators/dvt/ssv-setup.md | 10 +++++----- for-operators/kubernetes-staking-setup.md | 4 ++-- for-operators/migrate-from-v2/ethereum.md | 4 ++-- for-operators/operator-service/README.md | 10 +++++----- .../operator-service/running-with-hashi-vault.md | 4 ++-- .../operator-service/running-with-remote-signer.md | 4 ++-- governance/dao-treasury.md | 2 +- guides/ostoken.md | 4 ++-- protocol-overview-in-depth/ostoken.md | 4 +++- 12 files changed, 31 insertions(+), 29 deletions(-) diff --git a/for-developers/oracles.md b/for-developers/oracles.md index db19fce..3adc8a0 100644 --- a/for-developers/oracles.md +++ b/for-developers/oracles.md @@ -23,7 +23,7 @@ layout:

Oracles updating rewards

-Currently, there is no way to fetch the Beacon Chain state in the EVM. It is planned to make it available in [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788). Until then, StakeWise uses Oracles to fetch rewards from the Beacon Chain and submit the updates to the contracts. The Oracles are listed [here](../protocol-overview-in-depth/oracles.md). The Oracles are selected and [approved](https://vote.stakewise.io/#/proposal/0x54ceedefd1060fbad17ab6181be5a90da4c686dc071d1f6121d24c0398700be6) by the StakeWise DAO. The Oracles run the [v3-oracle](https://github.com/stakewise/v3-oracle) nodes and have the following responsibilities: +Currently, there is no way to fetch the Beacon Chain state in the EVM. It is planned to make it available in [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788). Until then, StakeWise uses Oracles to fetch rewards from the Beacon Chain and submit the updates to the contracts. The Oracles are listed [here](../protocol-overview-in-depth/oracles.md). The Oracles are selected and [approved](https://vote.stakewise.io/#/proposal/0x54ceedefd1060fbad17ab6181be5a90da4c686dc071d1f6121d24c0398700be6) by the StakeWise DAO. The Oracles run the [oracle](https://github.com/stakewise/oracle) nodes and have the following responsibilities: ### Rewards update @@ -37,7 +37,7 @@ The voting process consists of the following steps: 4. Calculate the [Merkle tree](https://en.wikipedia.org/wiki/Merkle_tree) based on consensus/execution rewards from the previous steps and upload it to IPFS. For example, [bafkreibqhdr6p5uh67ickt4dpppb525bwuofjocnpsx4dbl57llogfph2e](https://stakewise.infura-ipfs.io/ipfs/bafkreibqhdr6p5uh67ickt4dpppb525bwuofjocnpsx4dbl57llogfph2e). 5. Save the vote to the database and make it available through public API. -Anyone who runs [v3-keeper](https://github.com/stakewise/v3-keeper/) will fetch votes from Oracles endpoints, concatenate them and send them to the [Keeper contract](https://v3-docs.stakewise.io/deployments). Currently, 6 out of 11 votes are required to submit an update. Once the update has submitted, Vaults can pull the updates through the `updateState` call. +Anyone who runs [v3-keeper](https://github.com/stakewise/v3-keeper/) will fetch votes from Oracles endpoints, concatenate them and send them to the [Keeper contract](https://docs.stakewise.io/for-developers/networks). Currently, 6 out of 11 votes are required to submit an update. Once the update has submitted, Vaults can pull the updates through the `updateState` call. ### Validator(s) registration @@ -74,7 +74,7 @@ if (await keeperContract.canHarvest(vaultContract.address)) { ``` {% hint style="info" %} -The **harvestParams** can be fetched from the [StakeWise subgraph](https://graphs.stakewise.io/mainnet/subgraphs/name/stakewise/prod/graphql?query=%7B%0A++vaults%28where%3A+%7Bid%3A+%220xac0f906e433d58fa868f936e8a43230473652885%22%7D%29+%7B%0A++++rewardsRoot%0A++++proofReward%0A++++proofUnlockedMevReward%0A++++proof%0A++%7D%0A%7D) or by fetching the last [RewardsUpdated](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IKeeperRewards.sol#L22) event from the [Keeper contract](https://v3-docs.stakewise.io/deployments), extracting the `rewardsIpfsHash`, fetching the file, and getting the parameters for your Vault from it. +The **harvestParams** can be fetched from the [StakeWise subgraph](https://graphs.stakewise.io/mainnet/subgraphs/name/stakewise/prod/graphql?query=%7B%0A++vaults%28where%3A+%7Bid%3A+%220xac0f906e433d58fa868f936e8a43230473652885%22%7D%29+%7B%0A++++rewardsRoot%0A++++proofReward%0A++++proofUnlockedMevReward%0A++++proof%0A++%7D%0A%7D) or by fetching the last [RewardsUpdated](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IKeeperRewards.sol#L22) event from the [Keeper contract](https://docs.stakewise.io/for-developers/networks), extracting the `rewardsIpfsHash`, fetching the file, and getting the parameters for your Vault from it. {% endhint %} 2. By the Vault operator by passing `--harvest-vault` to the `start` command in [v3-operator](https://github.com/stakewise/v3-operator). diff --git a/for-developers/unstake.md b/for-developers/unstake.md index 6a5bfe8..343f7f3 100644 --- a/for-developers/unstake.md +++ b/for-developers/unstake.md @@ -65,7 +65,7 @@ Claims assets that were withdrawn by the Vault. It can be called only after the * [Interface](https://github.com/stakewise/v3-core/blob/b93337b7f48f3d94bd76e6facadd0635326237de/contracts/interfaces/IVaultEnterExit.sol) * [Implementation](https://github.com/stakewise/v3-core/blob/b93337b7f48f3d94bd76e6facadd0635326237de/contracts/vaults/modules/VaultEnterExit.sol) -* [Exit queue internal library](https://github.com/stakewise/v3-core/blob/b93337b7f48f3d94bd76e6facadd0635326237de/contracts/vaults/modules/VaultEnterExit.sol) +* [Exit queue internal library](https://github.com/stakewise/v3-core/blob/b93337b7f48f3d94bd76e6facadd0635326237de/contracts/libraries/ExitQueue.sol) ## Vaults exit requests diff --git a/for-operators/dvt/running-operator-with-dvt.md b/for-operators/dvt/running-operator-with-dvt.md index 90f3675..6990afe 100644 --- a/for-operators/dvt/running-operator-with-dvt.md +++ b/for-operators/dvt/running-operator-with-dvt.md @@ -29,7 +29,7 @@ Generate validator keys with a group using DKG ceremony. See [Obol DKG guide](ht {% endtab %} {% tab title="SSV" %} -Generate validator keys with a group using DKG ceremony. See [SSV DKG guide](https://docs.ssv.network/validator-user-guides/validator-management/distributing-a-validator-1). +Generate validator keys with a group using DKG ceremony. See [SSV DKG guide](https://docs.ssv.network/stakers/validator-management/distributing-a-validator/). {% endtab %} {% endtabs %} @@ -46,7 +46,7 @@ Each DVT operator should run Charon instance. Charon is HTTP middleware built by {% endtab %} {% tab title="SSV" %} -SSV node works as DVT replacement for validator client. Each SSV operator participating in a cluster should run his own node. See [the guide for SSV operators](https://docs.ssv.network/operator-user-guides/operator-node). +SSV node works as DVT replacement for validator client. Each SSV operator participating in a cluster should run his own node. See [the guide for SSV operators](https://docs.ssv.network/operators/operator-node/). {% endtab %} {% endtabs %} @@ -208,7 +208,7 @@ DKG ceremony produces deposit data file in addition to keystores. See [instructi #### Step 4.4 Run Stakewise Operator -See [instructions](https://docs.stakewise.io/for-operators/operator-service#upload-deposit-data-file-to-vault). +See [instructions](https://docs.stakewise.io/for-operators/operator-service#run-operator-service). There are some changes for DVT case: diff --git a/for-operators/dvt/ssv-setup.md b/for-operators/dvt/ssv-setup.md index 590df6e..a216261 100644 --- a/for-operators/dvt/ssv-setup.md +++ b/for-operators/dvt/ssv-setup.md @@ -96,7 +96,7 @@ Pay close attention to the publicKey field, as the name says, it contains the pu #### Step 3.1. Run SSV Node -{% embed url="https://docs.ssv.network/operator-user-guides/operator-node" %} +{% embed url="https://docs.ssv.network/operators/operator-node/" %} **Create Configuration File** @@ -210,12 +210,12 @@ p2p: **Offline Key Splitting** -Offline key splitting is the most secure option, although less convenient, as it requires running a command line tool. For more information, refer to the specific [User Guide on how to use the ssv-keys CLI tool](https://docs.ssv.network/validator-user-guides/tools/ssv-keys-cli). +Offline key splitting is the most secure option, although less convenient, as it requires running a command line tool. For more information, refer to the specific [User Guide on how to use the ssv-keys CLI tool](https://docs.ssv.network/stakers/tools/ssv-keys-cli). _**Before continue download**_ [_**ssv-keys**_](https://github.com/bloxapp/ssv-keys/releases) {% hint style="info" %} -The latest SSV Smart Contract updates added support for [_bulk operations_](https://docs.ssv.network/developers/smart-contracts/ssvnetwork#bulkregistervalidator-publickey-operatorids-shares-amount-cluster), and the latest release of`ssv-keys` has been made compatible with bulk operations. With version 1.1.0 (and above), it is possible to generate keyshares for multiple keystores in a single operation. +The latest SSV Smart Contract updates added support for [_bulk operations_](https://docs.ssv.network/developers/smart-contracts/ssvnetwork/#bulkregistervalidatorpublickey-operatorids-shares-amount-cluster), and the latest release of`ssv-keys` has been made compatible with bulk operations. With version 1.1.0 (and above), it is possible to generate keyshares for multiple keystores in a single operation. {% endhint %}

Select your validator cluster and press Add validator button

@@ -259,7 +259,7 @@ You can select the operational runway period of your validator, in accordance wi
-**Please read carefully and understand how fees are managed and the risks of account** [**liquidation**](https://ssv.network/glossary/#liquidation) **if your account balance falls below the** [**Threshold Balance**](https://ssv.network/glossary/##threshold-balance)**.** +**Please read carefully and understand how fees are managed and the risks of account** [**liquidation**](https://ssv.network/glossary/#liquidation) **if your account balance falls below the** [**Threshold Balance**](https://docs.ssv.network/learn/glossary/#liquidation-collateral)**.** The following screen alerts you of the potential dangers of registering a validator on the SSV network, if the same set of validator keys is also being used by other consensus and validator clients. @@ -281,6 +281,6 @@ By clicking on Register validator(s), you'll be proposed to sign transactions to For more info check SSV docs: -{% embed url="https://docs.ssv.network/validator-user-guides/validator-management/distributing-a-validator" %} +{% embed url="https://docs.ssv.network/stakers/validator-management/distributing-a-validator/" %} ### Step 3. Deposit to Vault ;) diff --git a/for-operators/kubernetes-staking-setup.md b/for-operators/kubernetes-staking-setup.md index 74a0aad..222c052 100644 --- a/for-operators/kubernetes-staking-setup.md +++ b/for-operators/kubernetes-staking-setup.md @@ -310,8 +310,8 @@ After the database is deployed, two databases and two users must be created: Complete the following steps before proceeding: 1. [Install Operator Service](https://docs.stakewise.io/for-operators/operator-service#install-operator-service) -2. [Prepare Operator Service](https://docs.stakewise.io/for-operators/operator-service#install-operator-service) -3. [Update deposit data file to the Vault](https://docs.stakewise.io/for-operators/operator-service#install-operator-service) +2. [Prepare Operator Service](https://docs.stakewise.io/for-operators/operator-service#prepare-operator-service) +3. [Upload deposit data file to the Vault](https://docs.stakewise.io/for-operators/operator-service#upload-deposit-data-file-to-vault) #### Setup database diff --git a/for-operators/migrate-from-v2/ethereum.md b/for-operators/migrate-from-v2/ethereum.md index 9e53838..bd8c533 100644 --- a/for-operators/migrate-from-v2/ethereum.md +++ b/for-operators/migrate-from-v2/ethereum.md @@ -6,7 +6,7 @@ Download the latest operator binary from [here](https://github.com/stakewise/v3- ### Step 1. Validator keys recovery -Follow the steps to recover the keystores using your validator keys mnemonic [here](https://github.com/stakewise/v3-operator#recover-vault-data-directory-and-keystores). +Follow the steps to recover the keystores using your validator keys mnemonic [here](https://github.com/stakewise/v3-operator?tab=readme-ov-file#recover-validator-keystores). After recovery add fake `deposit_data.json` file to your operator's vault directory, with content: @@ -66,7 +66,7 @@ helm upgrade --install web3signer stakewise/web3signer \ ### Step 4. Create wallet and Kubernetes secret -Сreate operator hot wallet by following the instructions [here](https://github.com/stakewise/v3-operator#3-create-wallet). +Сreate operator hot wallet by following the instructions [here](https://github.com/stakewise/v3-operator?tab=readme-ov-file#step-3-create-hot-wallet). Before deploying v3-operator service create kubernetes secret with operator wallet: diff --git a/for-operators/operator-service/README.md b/for-operators/operator-service/README.md index 8f37e5f..6a85593 100644 --- a/for-operators/operator-service/README.md +++ b/for-operators/operator-service/README.md @@ -28,7 +28,7 @@ All node operators of StakeWise V3 must run Operator Service in order to success #### Execution client -Ensure your execution node is fully synced and running. Any execution client that supports [ETH Execution API specification](https://ethereum.github.io/execution-apis/api-documentation/) can be used: +Ensure your execution node is fully synced and running. Any execution client that supports [ETH Execution API specification](https://ethereum.github.io/execution-apis/category/reference/) can be used: * [Nethermind](https://launchpad.ethereum.org/en/nethermind) (Ethereum, Gnosis) * [Besu](https://launchpad.ethereum.org/en/besu) (Ethereum) @@ -229,7 +229,7 @@ Successfully initialized configuration for vault 0x3320a...68 -**Step 2. Create validator keys** +#### **Step 2. Create validator keys** Next, run the `create-keys` command to kickstart the deposit data and validator keystores creation process, making sure you have your newly created mnemonic to hand: @@ -256,7 +256,7 @@ Deposit data saved to /home/user/.stakewise/0x3320a...68/keystores/deposit_data. -You may not want the operator service to have direct access to the validator keys. Validator keystores do not need to be present directly in the operator. You can check the [remote signer](https://docs.stakewise.io/for-operators/v3-operator-with-remote-signer) or [Hashicorp Vault](https://docs.stakewise.io/for-operators/v3-operator-with-hashi-vault) guides on how to run Operator Service with them. +You may not want the operator service to have direct access to the validator keys. Validator keystores do not need to be present directly in the operator. You can check the [remote signer](https://docs.stakewise.io/for-operators/operator-service/running-with-remote-signer) or [Hashicorp Vault](https://docs.stakewise.io/for-operators/operator-service/running-with-hashi-vault) guides on how to run Operator Service with them. {% hint style="info" %} Remember to upload the newly generated validator keys to the validator(s). For that, please follow a guide for your consensus client. The password for your keystores is located in the `password.txt` file in the keystores folder. @@ -288,7 +288,7 @@ Note, you must send some ETH (or xDAI for Gnosis) to the wallet for gas expenses ### Upload deposit data file to Vault -Once you have created your validator keys, deposit data file, and hot wallet, you need to upload the deposit data file to the Vault. This process connects your node to the Vault. Note, if there is more than one node operator in a Vault, you first need to merge all operator deposit data files into a single file (use the merge-deposit-data command). Uploading the deposit data file can be achieved either through the StakeWise UI or via Operator Service and can only be done by the [Vault Admin or Keys Manager](https://docs-v3.stakewise.io/protocol-overview-in-depth/vaults#governance-and-management). +Once you have created your validator keys, deposit data file, and hot wallet, you need to upload the deposit data file to the Vault. This process connects your node to the Vault. Note, if there is more than one node operator in a Vault, you first need to merge all operator deposit data files into a single file (use the merge-deposit-data command). Uploading the deposit data file can be achieved either through the StakeWise UI or via Operator Service and can only be done by the [Vault Admin or Keys Manager](https://docs.stakewise.io/protocol-overview-in-depth/vaults#governance-and-management). {% tabs %} {% tab title="StakeWise UI" %} @@ -393,7 +393,7 @@ Operator Service has many different commands that are not mandatory but might co #### Add validator keys to Vault -You can always add more validator keys to your Vault. For that, you need to generate new validator keys and deposit data as described in [Step 2. Create validator keys](broken-reference/) and upload the deposit data file to your Vault as described in [Step 3. Upload deposit data file to Vault](broken-reference/). Note, uploading a new deposit data file will overwrite the existing file and consequently overwrite previously un-used validator keys. It can be done at any point, but only by the Vault Admin or Keys Manager. +You can always add more validator keys to your Vault. For that, you need to generate new validator keys and deposit data as described in [Step 2. Create validator keys](https://docs.stakewise.io/for-operators/operator-service#step-2.-create-validator-keys) and upload the deposit data file to your Vault as described in [Step 3. Upload deposit data file to Vault](https://docs.stakewise.io/for-operators/operator-service#upload-deposit-data-file-to-vault). Note, uploading a new deposit data file will overwrite the existing file and consequently overwrite previously un-used validator keys. It can be done at any point, but only by the Vault Admin or Keys Manager. #### Validators voluntary exit diff --git a/for-operators/operator-service/running-with-hashi-vault.md b/for-operators/operator-service/running-with-hashi-vault.md index df70417..a5bd760 100644 --- a/for-operators/operator-service/running-with-hashi-vault.md +++ b/for-operators/operator-service/running-with-hashi-vault.md @@ -7,8 +7,8 @@ Operator supports loading signing keys from remote [Hashi Vault](https://github. Complete the following steps before proceeding: 1. [Install Operator Service](https://docs.stakewise.io/for-operators/operator-service#install-operator-service) -2. [Prepare Operator Service](https://docs.stakewise.io/for-operators/operator-service#install-operator-service) -3. [Update deposit data file to the Vault](https://docs.stakewise.io/for-operators/operator-service#install-operator-service) +2. [Prepare Operator Service](https://docs.stakewise.io/for-operators/operator-service#prepare-operator-service) +3. [Upload deposit data file to the Vault](https://docs.stakewise.io/for-operators/operator-service#upload-deposit-data-file-to-vault) Currently there are two commands that support loading signing keys: `start` and `validators-exit`, user must provide hashi vault instance URL, authentication token, and secret path in K/V engine. Internal structure of the secret must resemble following json: diff --git a/for-operators/operator-service/running-with-remote-signer.md b/for-operators/operator-service/running-with-remote-signer.md index e942a83..7fa4f75 100644 --- a/for-operators/operator-service/running-with-remote-signer.md +++ b/for-operators/operator-service/running-with-remote-signer.md @@ -7,8 +7,8 @@ You may not want the operator service to have direct access to the validator key Complete the following steps before proceeding: 1. [Install Operator Service](https://docs.stakewise.io/for-operators/operator-service#install-operator-service) -2. [Prepare Operator Service](https://docs.stakewise.io/for-operators/operator-service#install-operator-service) -3. [Update deposit data file to the Vault](https://docs.stakewise.io/for-operators/operator-service#install-operator-service) +2. [Prepare Operator Service](https://docs.stakewise.io/for-operators/operator-service#prepare-operator-service) +3. [Upload deposit data file to the Vault](https://docs.stakewise.io/for-operators/operator-service#upload-deposit-data-file-to-vault) ### Remote signer setup (optional) diff --git a/governance/dao-treasury.md b/governance/dao-treasury.md index 85853af..56d0629 100644 --- a/governance/dao-treasury.md +++ b/governance/dao-treasury.md @@ -6,7 +6,7 @@ coverY: 0 # DAO Treasury -DAO Treasury ([**0x144a98cb1CdBb23610501fE6108858D9B7D24934**](https://gnosis-safe.io/app/#/safes/0x144a98cb1CdBb23610501fE6108858D9B7D24934) **on Ethereum,** [**0x8737f638E9af54e89ed9E1234dbC68B115CD169e**](https://gnosisscan.io/address/0x8737f638E9af54e89ed9E1234dbC68B115CD169e) **on Gnosis**) is a [Gnosis Safe](https://gnosis-safe.io/) with a committee of 7 persons and a [SafeSnap Module](https://docs.snapshot.org/user-guides/plugins/safesnap-reality) that allows the submission of transactions on behalf of the governance token holders. +DAO Treasury ([**0x144a98cb1CdBb23610501fE6108858D9B7D24934**](https://etherscan.io/address/0x144a98cb1CdBb23610501fE6108858D9B7D24934) **on Ethereum,** [**0x8737f638E9af54e89ed9E1234dbC68B115CD169e**](https://gnosisscan.io/address/0x8737f638E9af54e89ed9E1234dbC68B115CD169e) **on Gnosis**) is a [Gnosis Safe](https://gnosis-safe.io/) with a committee of 7 persons and a [SafeSnap Module](https://docs.snapshot.org/user-guides/plugins/safesnap-reality) that allows the submission of transactions on behalf of the governance token holders. The goal of the DAO committee is to monitor and reject the transactions that are not supposed to be executed on behalf of the DAO Treasury, since such malicious transactions can be submitted by an arbitrary account. In order to reject the transaction, a threshold of **4 out of 7** committee members must sign the rejection. diff --git a/guides/ostoken.md b/guides/ostoken.md index aac2d03..be778af 100644 --- a/guides/ostoken.md +++ b/guides/ostoken.md @@ -178,7 +178,7 @@ Note that osGNO not acquired by minting from a Vault does not require any mainte {% tab title="osETH" %} All your minted osETH must be burned before you can fully unstake ETH from a Vault. -[Learn more about burning osETH ->](../protocol-overview-in-depth/ostoken.md#burning-oseth) +[Learn more about burning osETH ->](../protocol-overview-in-depth/ostoken.md#burning) The StakeWise DAO staking fee is included in the balance of osETH that must be burned before you can unstake. @@ -196,7 +196,7 @@ The StakeWise DAO staking fee is included in the balance of osETH that must be b {% tab title="osGNO" %} All your minted osGNO must be burned before you can fully unstake GNO from a Vault. -[Learn more about burning osGNO ->](../protocol-overview-in-depth/ostoken.md#burning-oseth) +[Learn more about burning osGNO ->](../protocol-overview-in-depth/ostoken.md#burning) The StakeWise DAO staking fee is included in the balance of osGNO that must be burned before you can unstake. diff --git a/protocol-overview-in-depth/ostoken.md b/protocol-overview-in-depth/ostoken.md index 9b710ca..f3d8fc3 100644 --- a/protocol-overview-in-depth/ostoken.md +++ b/protocol-overview-in-depth/ostoken.md @@ -92,7 +92,7 @@ Stakers in Vaults benefit from these slashing protection mechanisms because when Stakers who buy osETH on DEXs don't have exposure to any particular Vault and hence are fully insulated against any slashing losses and poor performance that may occur. -[Read more about the excess backing of osETH ->](ostoken.md#overcollateralization) +[Read more about the excess backing of osETH ->](ostoken.md#backing) {% endtab %} {% tab title="osGNO" %} @@ -113,6 +113,8 @@ Stakers in Vaults benefit from these slashing protection mechanisms because when **Buying osGNO on DEXs** Stakers who buy osGNO on DEXs don't have exposure to any particular Vault and hence are fully insulated against any slashing losses and poor performance that may occur. + +[Read more about the excess backing of osGNO ->](ostoken.md#backing) {% endtab %} {% endtabs %}