fix: update 301 links with trailing slash in dao ops pages

docs/deployed-contracts/hoodi.md

@@ -2,7 +2,7 @@
 
 :::tip 📘 **Lido V3 Technical Paper**
 
-Learn about the next evolution of Lido staking with **stVaults** — user-defined validator setups with optional stETH liquidity. Read the complete [**Lido V3 Technical Paper**](/lido-v3-whitepaper) for architecture details, mechanisms, and implementation specifics.
+Learn about the next evolution of Lido staking with **stVaults** — user-defined validator setups with optional stETH liquidity. Read the complete [**Lido V3 Technical Paper**](/lido-v3-whitepaper/) for architecture details, mechanisms, and implementation specifics.
 
 :::
 

docs/deployed-contracts/index.md

@@ -6,7 +6,7 @@ pagination_next: deployed-contracts/hoodi
 
 :::tip 📘 **Lido V3 Technical Paper**
 
-Learn about the next evolution of Lido staking with **stVaults** — user-defined validator setups with optional stETH liquidity. Read the complete [**Lido V3 Technical Paper**](/lido-v3-whitepaper) for architecture details, mechanisms, and implementation specifics.
+Learn about the next evolution of Lido staking with **stVaults** — user-defined validator setups with optional stETH liquidity. Read the complete [**Lido V3 Technical Paper**](/lido-v3-whitepaper/) for architecture details, mechanisms, and implementation specifics.
 
 :::
 

docs/guides/address-ownership-guide.md

@@ -22,7 +22,7 @@ Using EOA across Lido DAO operational multisigs or protocol contracts requires p
 
 2. Publish the message along with the Etherescan link (or signature hash in case of MyEtherWallet) on X.com (formerly Twitter) or other easily accessible social media.
 3. Share the link to the post as a comment at the relevant [Lido DAO forum](https://research.lido.fi) post.
-4. Make sure to follow the [general rules of thumb](/guides/multisig-signer-manual) for being a signer in Lido DAO operational multisigs.
+4. Make sure to follow the [general rules of thumb](/guides/multisig-signer-manual/) for being a signer in Lido DAO operational multisigs.
 
 ### In case of using Safe multisig
 

docs/guides/curated-module/el-rewards-configuration.md

@@ -1,12 +1,12 @@
 # Execution Layer Rewards Configuration
 
-Node Operators who run validators for Lido are required to set the fee recipient for the relevant validators to the protocol-managed [`LidoExecutionLayerRewardsVault`](/contracts/lido-execution-layer-rewards-vault) which manages [Execution Layer Rewards](/contracts/lido#gettotalelrewardscollected). This address differs depending on the network (Mainnet, testnet, etc.) and is _not_ the same as the [Withdrawal Credentials](/contracts/staking-router#getwithdrawalcredentials) address.
+Node Operators who run validators for Lido are required to set the fee recipient for the relevant validators to the protocol-managed [`LidoExecutionLayerRewardsVault`](/contracts/lido-execution-layer-rewards-vault/) which manages [Execution Layer Rewards](/contracts/lido/#gettotalelrewardscollected). This address differs depending on the network (Mainnet, testnet, etc.) and is _not_ the same as the [Withdrawal Credentials](/contracts/staking-router/#getwithdrawalcredentials) address.
 
-This smart contract address can also be retrieved by [querying the `elRewardsVault()`](/contracts/lido-locator#elrewardsvault) method in the `LidoLocator` contract.
+This smart contract address can also be retrieved by [querying the `elRewardsVault()`](/contracts/lido-locator/#elrewardsvault) method in the `LidoLocator` contract.
 
 The address is also available in the [Deployed Contracts] docs page, labeled as `Execution Layer Rewards Vault`.
 
-[deployed contracts]: /deployed-contracts
+[deployed contracts]: /deployed-contracts/
 
 ## Fee recipient options for various Beacon Chain clients
 
@@ -40,12 +40,12 @@ For some clients the fee recipient option should be applied with other options,
 [teku mev integration]: https://docs.teku.consensys.net/en/latest/Reference/CLI/CLI-Syntax/#builder-endpoint
 [nimbus mev integration]: https://nimbus.guide/external-block-builder.html
 [lighthouse mev integration]: https://lighthouse-book.sigmaprime.io/builders.html
-[lodestar mev integration]: https://chainsafe.github.io/lodestar/run/beacon-management/mev-and-builder-integration
+[lodestar mev integration]: https://chainsafe.github.io/lodestar/run/beacon-management/mev-and-builder-integration/
 [prysm mev integration]: https://docs.prylabs.network/docs/prysm-usage/parameters
 
 ## Relays and MEV-Boost options
 
-List of possible relays that have been approved by DAO can be fetched by [querying the `get_relays()`](/contracts/mev-boost-relays-allowed-list#get_relays) method in `MevBoostRelayAllowedList` contract.
+List of possible relays that have been approved by DAO can be fetched by [querying the `get_relays()`](/contracts/mev-boost-relays-allowed-list/#get_relays) method in `MevBoostRelayAllowedList` contract.
 
 ### Mainnet
 

docs/guides/curated-module/validator-keys.md

@@ -229,4 +229,4 @@ It is urgent to notify Lido team and other Node Operators as soon as possible. F
 
 Once new keys are present and valid, a motion can be proposed to increase the staking limit for the Node Operator.
 
-[Node Operators Guide to Easy Track](https://docs.lido.fi/guides/easy-track-guide#node-operators-guide-to-easy-track)
+[Node Operators Guide to Easy Track](https://docs.lido.fi/guides/easy-track-guide/#node-operators-guide-to-easy-track)

docs/guides/deposit-security-manual.md

@@ -44,7 +44,7 @@ It might be any EOA account under the member's control. Send the address of its
 
 ### Onchain Data Bus Communication
 
-For inter-service communication, an onchain data bus is utilized, based on EVM-based network and a simple smart contract. This smart contract allows for sending messages essential for the operation of the service. The current specification of these messages is outlined in [this file](https://github.com/lidofinance/lido-council-daemon/blob/main/src/abi/data-bus.abi.json). For more details on the smart contract, please refer to [the document](/contracts/data-bus).
+For inter-service communication, an onchain data bus is utilized, based on EVM-based network and a simple smart contract. This smart contract allows for sending messages essential for the operation of the service. The current specification of these messages is outlined in [this file](https://github.com/lidofinance/lido-council-daemon/blob/main/src/abi/data-bus.abi.json). For more details on the smart contract, please refer to [the document](/contracts/data-bus/).
 
 ### Run lido-council-daemon
 

docs/guides/depositor-bot.md

@@ -2,13 +2,13 @@
 
 ## Introduction
 
-Depositor bot is a part of [Deposit Security Module](/contracts/deposit-security-module).
+Depositor bot is a part of [Deposit Security Module](/contracts/deposit-security-module/).
 
 The Depositor Bot obtains signed deposit messages from Council Daemons. Once a sufficient number of messages is
 collected to constitute a quorum, the bot proceeds to initiate a deposit into the designated staking module. This
 deposit is executed using
-the [depositBufferedEther](https://docs.lido.fi/contracts/deposit-security-module#depositbufferedether) function within
-the [DepositSecurityModule](https://docs.lido.fi/contracts/deposit-security-module) smart contract.
+the [depositBufferedEther](https://docs.lido.fi/contracts/deposit-security-module/#depositbufferedether) function within
+the [DepositSecurityModule](https://docs.lido.fi/contracts/deposit-security-module/) smart contract.
 
 ## Requirements
 
@@ -97,7 +97,7 @@ line `"msg": "Bot env variables"`
 
 ### Docker
 
-Docker image can be found [here](https://docs.lido.fi/guides/tooling#depositor-bot).
+Docker image can be found [here](https://docs.lido.fi/guides/tooling/#depositor-bot).
 
 ## Monitoring
 

docs/guides/multisig-signer-manual.md

@@ -3,7 +3,7 @@
 Lido DAO uses multisig wallet for different ops for flexibility and fast reaction times. Here's a list of general tips & rules around being the signer:
 
 1. Use hardware wallet & back up the seed phrase.
-2. Upon joining to any multisig make sure to verify the address according [to the guide](/guides/address-ownership-guide).
+2. Upon joining to any multisig make sure to verify the address according [to the guide](/guides/address-ownership-guide/).
 3. Check transactions you see on the multisig. If it's unclear to what the transaction should do and why — don't sign it and ask for explanation.
 4. Every transaction should have "how to check" guide.
    1. Addresses & sums in question should be verifiable through third party sources (message from your fellow multisig co-signer doesn't cut it).

docs/guides/oracle-operator-manual.md

@@ -20,7 +20,7 @@ The Lido Oracle mechanism comprises three main components. The first component i
 
 Based on the update reports received from the oracles, the Lido smart contract performs state transitions such as updating user balances, processing withdrawal requests, and distributing rewards to node operators. Thus, the Lido Oracle mechanism acts as a synchronization device that bridges the protocol across the execution and consensus layers. It ensures that the protocol is updated in a timely and accurate manner and allows for smooth and efficient operation of the entire Lido system.
 
-The two core contracts in the Lido Oracle suite are called [AccountingOracle](/contracts/accounting-oracle) and [ValidatorsExitBus](/contracts/validators-exit-bus-oracle). Together, these contracts collect information submitted by oracles about the state of validators and their balances, the amount of funds accumulated on protocol vaults, the number of withdrawal requests the protocol is able to process, and the validators are expected to be voluntary exited to finalize more withdrawal requests. This information is then used for these crucial processes:
+The two core contracts in the Lido Oracle suite are called [AccountingOracle](/contracts/accounting-oracle/) and [ValidatorsExitBus](/contracts/validators-exit-bus-oracle/). Together, these contracts collect information submitted by oracles about the state of validators and their balances, the amount of funds accumulated on protocol vaults, the number of withdrawal requests the protocol is able to process, and the validators are expected to be voluntary exited to finalize more withdrawal requests. This information is then used for these crucial processes:
 
 - rebasing user balances,
 - distributing node operator rewards,
@@ -46,7 +46,7 @@ The diagram below shows:
 `ReportProcessor` - `AccountingOracle` or `ValidatorsExitBusOracle` contract.
 `HashConsensus` -  a contract which manages oracle members committee and allows the members to reach consensus on the particular data hash for each reporting frame.
 
-You can read more about HashConsensus [here](/contracts/hash-consensus).
+You can read more about HashConsensus [here](/contracts/hash-consensus/).
 
 ```mermaid
 graph LR;

docs/guides/oracle-spec/accounting-oracle.md

@@ -1,7 +1,7 @@
 # Accounting oracle
 
 :::info
-It's advised to read [What is Lido Oracle mechanism](/guides/oracle-operator-manual#intro) before
+It's advised to read [What is Lido Oracle mechanism](/guides/oracle-operator-manual/#intro) before
 :::
 
 ## Withdrawal stage

docs/guides/oracle-spec/validator-exit-bus.md

@@ -1,10 +1,10 @@
 # Validators Exit Bus
 
 :::info
-It's advised to read [What is Lido Oracle mechanism](/guides/oracle-operator-manual#intro) before
+It's advised to read [What is Lido Oracle mechanism](/guides/oracle-operator-manual/#intro) before
 :::
 
-[Validators Exit Bus](/contracts/validators-exit-bus-oracle) is an oracle that ejects Lido validators when the protocol requires additional funds to process user withdrawals.
+[Validators Exit Bus](/contracts/validators-exit-bus-oracle/) is an oracle that ejects Lido validators when the protocol requires additional funds to process user withdrawals.
 
 There are two stages of selecting validators for exit: Covering Demand in WQ and Boosted Exits
 
@@ -118,16 +118,16 @@ ValidatorsExitBusOracle.getLastRequestedValidatorIndices(
 
 To find the next validators to exit, Validators Exit Bus Oracle collects the following state from both Ethereum Consensus and Execution layers.
 
-- From [OracleDaemonConfig](/contracts/oracle-daemon-config) contract:
+- From [OracleDaemonConfig](/contracts/oracle-daemon-config/) contract:
   - PREDICTION_DURATION_IN_SLOTS
   - VALIDATOR_DELAYED_TIMEOUT_IN_SLOTS
-- From [Withdrawal Queue](/contracts/withdrawal-queue-erc721):
+- From [Withdrawal Queue](/contracts/withdrawal-queue-erc721/):
   - Get total unfinalized withdrawal request amount
-- From [Lido](/contracts/lido) contract:
+- From [Lido](/contracts/lido/) contract:
   - Recent postCLBalance/preCLBalance and withdrawals from Execution Layer Rewards and Withdrawal vaults via events
 - From Consensus Layer node:
   - All validators and their states on the reference slot
-- From [Staking Router](/contracts/staking-router):
+- From [Staking Router](/contracts/staking-router/):
   - Public keys of all Lido validators
   - Indices of the last requested validator to exit for each Node Operator
   - Validator keys statistics for each Node Operator
@@ -143,13 +143,13 @@ Collects the amount of stETH in the queue yet to be finalized from `WithdrawalQu
 
 #### Calculate average rewards speed per epoch
 
-Fetches `ETHDistributed` and `TokenRebased` events from the [`Lido`](/contracts/lido) contract and calculate average rewards amount per epoch. The rewards prediction period config fetches from the [OracleDaemonConfig](/contracts/oracle-daemon-config) contract.
+Fetches `ETHDistributed` and `TokenRebased` events from the [`Lido`](/contracts/lido/) contract and calculate average rewards amount per epoch. The rewards prediction period config fetches from the [OracleDaemonConfig](/contracts/oracle-daemon-config/) contract.
 
 To get events in past, addressing the cases where there can be slots with missed block, the next scheme is introduced:
 
 ![VEBO 6](../../../static/img/oracle-spec/vebo-6.png)
 
-- Get from [OracleDaemonConfig](/contracts/oracle-daemon-config) contract `PREDICTION_DURATION_IN_SLOTS` value
+- Get from [OracleDaemonConfig](/contracts/oracle-daemon-config/) contract `PREDICTION_DURATION_IN_SLOTS` value
 - Get `TokenRebased` events from Lido
 - Get `ETHDistributed` events from Lido
 - Group that events by transaction hash
@@ -207,7 +207,7 @@ epochs_required_to_exit_validators = (validators_to_eject_count - remain_exits_c
 withdrawal_epoch=max_exit_epoch_number + epochs_required_to_exit_validators + MIN_VALIDATOR_WITHDRAWABILITY_DELAY)
 ```
 
-MIN_VALIDATOR_WITHDRAWABILITY_DELAY [here](https://eth2book.info/altair/part3/config/configuration#min_validator_withdrawability_delay)
+MIN_VALIDATOR_WITHDRAWABILITY_DELAY [here](https://eth2book.info/altair/part3/config/configuration/#min_validator_withdrawability_delay)
 
 So now we can calculate what amount (and validators count) is needed to fully cover amount of non-finalized WithdrawQueue requests.