diff --git a/docs/build/getting-started/welcome.md b/docs/build/getting-started/welcome.md
index f5299b30be2..87442e4f2d9 100644
--- a/docs/build/getting-started/welcome.md
+++ b/docs/build/getting-started/welcome.md
@@ -17,7 +17,7 @@ keywords:
 Welcome to the "Build" section of the IOTA Wiki. This section is for developers interested in using the IOTA and Shimmer
 networks for decentralized applications, integrating their exchange, minting NFTs, and much more. Here, you can find all
 the available [Networks and Endpoints](networks-endpoints.md), links for all the available
-[Tools](/build/tools), [APIS](/apis/welcome/), and all the documentation to communicate with the Layer 1 networks,
+[Tools](/build/tools), [APIS](/apis/welcome), and all the documentation to communicate with the Layer 1 networks,
 build
 decentralized applications and interact with Layer 2 [smart contracts](#smart-contracts).
 
diff --git a/docs/build/identity.rs/0.7-alpha/docs/concepts/decentralized_identifiers/alias.mdx b/docs/build/identity.rs/0.7-alpha/docs/concepts/decentralized_identifiers/alias.mdx
index ebeb2328744..4c315bc5b04 100644
--- a/docs/build/identity.rs/0.7-alpha/docs/concepts/decentralized_identifiers/alias.mdx
+++ b/docs/build/identity.rs/0.7-alpha/docs/concepts/decentralized_identifiers/alias.mdx
@@ -14,7 +14,7 @@ keywords:
 
 # Alias Output
 
-The IOTA method uses the IOTA ledger which uses the [unspent transaction output (UTXO) model](https://wiki.iota.org/goshimmer/protocol_specification/components/ledgerstate). Also, the features of the [Stardust](https://wiki.iota.org/introduction/develop/explanations/what_is_stardust) upgrade are fundamental to the IOTA DID method.
+The IOTA method uses the IOTA ledger which uses the [unspent transaction output (UTXO) model](/goshimmer/protocol_specification/components/ledgerstate). Also, the features of the [Stardust](/introduction/stardust/explanations/what_is_stardust) upgrade are fundamental to the IOTA DID method.
 
 The Alias Output is used for storing the DID Document on the ledger. It is a specific implementation of the UTXO state machine that can hold arbitrary data in its `State Metadata`. The Alias Output has two kinds of controllers, a state controller and a governor. A state controller can execute a state transition which allows updating the data in the `State Metadata`. The governor, on the contrary, can't update the `State Metadata` but can change both controllers and destroy the Alias Output.
 A controller can be either Ed25519 Address, Alias Address or an NFT Address and at most one of each can be set for an Alias Output.
diff --git a/docs/build/identity.rs/0.7-alpha/docs/concepts/decentralized_identifiers/create.mdx b/docs/build/identity.rs/0.7-alpha/docs/concepts/decentralized_identifiers/create.mdx
index 84f54252455..fb8bbd20a33 100644
--- a/docs/build/identity.rs/0.7-alpha/docs/concepts/decentralized_identifiers/create.mdx
+++ b/docs/build/identity.rs/0.7-alpha/docs/concepts/decentralized_identifiers/create.mdx
@@ -55,6 +55,6 @@ Once the transaction is confirmed, the `Alias ID` would be assigned and the DID
 
 ## Running a private network
 
-In order to run the examples, a private network (sometimes also called a private Tangle) needs to run locally. You can refer to [Hornet wiki](https://wiki.iota.org/hornet/develop/how_tos/private_tangle) for instructions on how to run a private network.
+In order to run the examples, a private network (sometimes also called a private Tangle) needs to run locally. You can refer to [Hornet wiki](/hornet/2.0.0-rc.6/how_tos/private_tangle) for instructions on how to run a private network.
 
 If your local private network uses different ports than Hornet, modify the API and faucet endpoints in the examples to match your local setup.
diff --git a/docs/build/identity.rs/0.7-alpha/docs/concepts/decentralized_identifiers/overview.mdx b/docs/build/identity.rs/0.7-alpha/docs/concepts/decentralized_identifiers/overview.mdx
index d6fa95c0052..ce240db6540 100644
--- a/docs/build/identity.rs/0.7-alpha/docs/concepts/decentralized_identifiers/overview.mdx
+++ b/docs/build/identity.rs/0.7-alpha/docs/concepts/decentralized_identifiers/overview.mdx
@@ -79,4 +79,4 @@ Iota Identity helps with abstracting the details of the DID standard by providin
 
 ### Storage solution
 
-IOTA Identity provides a [Stronghold](https://wiki.iota.org/stronghold.rs/welcome/ 'Stronghold is an open-source software library that was originally built to protect IOTA Seeds, but can be used to protect any digital secret.') solution for managing secrets securely, without requiring developers to reinvent the security wheel.
+IOTA Identity provides a [Stronghold](/stronghold.rs/welcome/ 'Stronghold is an open-source software library that was originally built to protect IOTA Seeds, but can be used to protect any digital secret.') solution for managing secrets securely, without requiring developers to reinvent the security wheel.
diff --git a/docs/build/identity.rs/0.7-alpha/docs/contribute.mdx b/docs/build/identity.rs/0.7-alpha/docs/contribute.mdx
index 09b3a39a406..810107b0070 100644
--- a/docs/build/identity.rs/0.7-alpha/docs/contribute.mdx
+++ b/docs/build/identity.rs/0.7-alpha/docs/contribute.mdx
@@ -30,7 +30,7 @@ All of the code is open source and hosted on [GitHub](https://github.com/iotaled
 
 - [Report a bug](https://github.com/iotaledger/identity.rs/issues/new/choose).
 - [Suggest a new feature](https://github.com/iotaledger/documentation/blob/develop/.github/CONTRIBUTING.md).
-- [Contribute to the documentation](https://wiki.iota.org/identity.rs/contribute#contribute-to-the-documentation).
+- [Contribute to the documentation](/identity.rs/contribute#contribute-to-the-documentation).
 
 ## Contribute to the Documentation
 
diff --git a/docs/build/identity.rs/0.7-alpha/docs/decentralized_identity.mdx b/docs/build/identity.rs/0.7-alpha/docs/decentralized_identity.mdx
index c03b33edb1b..9991e477da4 100644
--- a/docs/build/identity.rs/0.7-alpha/docs/decentralized_identity.mdx
+++ b/docs/build/identity.rs/0.7-alpha/docs/decentralized_identity.mdx
@@ -95,7 +95,7 @@ IOTA is a neutral and free-to-use public infrastructure acting as a trustworthy
 
 :::
 
-IOTA is a scalable and feeless Distributed Ledger Technology (DLT). Similar to Blockchain technology, IOTA provides an immutable and decentralized ledger that can transact value through the IOTA token. Unlike Blockchain, IOTA uses a non-linear data structure called the [Tangle](https://wiki.iota.org/learn/about-iota/an-introduction-to-iota#the-tangle-data-structure) which makes it feeless and vastly more scalable. The Tangle also facilitates feeless transactions of data, such as DID registrations and credential revocations. As a single source of truth and trust in data, the Tangle can provide the trust infrastructure in a highly networked world.
+IOTA is a scalable and feeless Distributed Ledger Technology (DLT). Similar to Blockchain technology, IOTA provides an immutable and decentralized ledger that can transact value through the IOTA token. Unlike Blockchain, IOTA uses a non-linear data structure called the [Tangle](/learn/about-iota/an-introduction-to-iota#the-tangle-data-structure) which makes it feeless and vastly more scalable. The Tangle also facilitates feeless transactions of data, such as DID registrations and credential revocations. As a single source of truth and trust in data, the Tangle can provide the trust infrastructure in a highly networked world.
 
 IOTA is uniquely suited for a single unifying identity implementation. The network is designed for both humans and devices, providing a platform for trusted communication between individuals, organizations, and things. The IOTA Foundation’s principles of full transparency, openness, and permissionless innovation provide an open and neutral environment:
 
@@ -103,7 +103,7 @@ IOTA is uniquely suited for a single unifying identity implementation. The netwo
 2. **Public**: Everyone can observe (unless using optional encryption) the transactions in the network. The network is inherently transparent.
 3. **Feeless**: All data and value transactions on the network are free. Unlike other DLTs such as Bitcoin or Ethereum, registration and communication of identities can be written to the network without a requirement to purchase a cryptocurrency token.
 4. **Open Source**: Everyone can view and contribute to the code.
-5. **Easy to use**: IOTA Identity is inherently easier to use due to the lack of fees or requirements to set up an entire private network. In addition, the framework is designed to have an easy to use high-level API, with accessibility to the low-level, more complex and more flexible API. Through integration with the [Stronghold](https://wiki.iota.org/stronghold.rs/welcome 'Stronghold is an open-source software library that was originally built to protect IOTA Seeds, but can be used to protect any digital secret.') project, we also provide out-of-the-box security for secrets.
+5. **Easy to use**: IOTA Identity is inherently easier to use due to the lack of fees or requirements to set up an entire private network. In addition, the framework is designed to have an easy to use high-level API, with accessibility to the low-level, more complex and more flexible API. Through integration with the [Stronghold](/stronghold.rs/welcome 'Stronghold is an open-source software library that was originally built to protect IOTA Seeds, but can be used to protect any digital secret.') project, we also provide out-of-the-box security for secrets.
 
 Data must be immutably stored on a distributed ledger to ensure the decentralized nature of the digital identity protocol. With the network’s continual uptime, credentials are always verifiable without a dependency on the servers of credential issuers. This system also increases individual privacy, because contact with the Issuer is removed from the interaction between Holder and Verifier. Issuers will not be able to track when and how often the Holder uses their credentials. The flexibility afforded from the Tangle means that the digital identity framework remains extendable in the future.
 
diff --git a/docs/build/identity.rs/0.7-alpha/docs/libraries/wasm/getting_started.mdx b/docs/build/identity.rs/0.7-alpha/docs/libraries/wasm/getting_started.mdx
index 06d60816179..4420b4a1823 100644
--- a/docs/build/identity.rs/0.7-alpha/docs/libraries/wasm/getting_started.mdx
+++ b/docs/build/identity.rs/0.7-alpha/docs/libraries/wasm/getting_started.mdx
@@ -17,7 +17,7 @@ keywords:
 
 > This is the beta version of the official WASM bindings for [IOTA Identity](https://github.com/iotaledger/identity.rs).
 
-## [API Reference](https://wiki.iota.org/identity.rs/libraries/wasm/api_reference)
+## [API Reference](/identity.rs/libraries/wasm/api_reference)
 
 ## [Examples](https://github.com/iotaledger/identity.rs/blob/main/bindings/wasm/examples/README.md)
 
@@ -64,7 +64,7 @@ The minimum supported version for node is: `v16`
 ## NodeJS Usage
 
 The following code creates a new IOTA DID Document suitable for publishing to a locally running private network.
-See the [instructions](https://wiki.iota.org/hornet/develop/how_tos/private_tangle) on running your own private network.
+See the [instructions](/hornet/2.0.0-rc.6/how_tos/private_tangle) on running your own private network.
 
 <!--
 Test this example using https://github.com/anko/txm: `txm README.md`
diff --git a/docs/build/identity.rs/0.7-alpha/docs/specs/did/iota_did_method_spec.mdx b/docs/build/identity.rs/0.7-alpha/docs/specs/did/iota_did_method_spec.mdx
index 6379dd1fe4e..bb1f3344e47 100644
--- a/docs/build/identity.rs/0.7-alpha/docs/specs/did/iota_did_method_spec.mdx
+++ b/docs/build/identity.rs/0.7-alpha/docs/specs/did/iota_did_method_spec.mdx
@@ -18,7 +18,7 @@ keywords:
 
 ## Abstract
 
-The IOTA DID Method Specification describes a method of implementing the [Decentralized Identifiers](https://www.w3.org/TR/did-core/) (DID) standard on [IOTA](https://iota.org), a Distributed Ledger Technology (DLT). It conforms to the [DID specification v1.0](https://www.w3.org/TR/did-core/) and describes how to perform Create, Read, Update and Delete (CRUD) operations for IOTA DID Documents using unspent transaction outputs ([UTXO](https://wiki.iota.org/IOTA-2.0-Research-Specifications/5.1UTXO)) on the IOTA and [Shimmer](https://shimmer.network/) networks, introduced with the [Stardust upgrade](https://blog.shimmer.network/stardust-upgrade-in-a-nutshell/).
+The IOTA DID Method Specification describes a method of implementing the [Decentralized Identifiers](https://www.w3.org/TR/did-core/) (DID) standard on [IOTA](https://iota.org), a Distributed Ledger Technology (DLT). It conforms to the [DID specification v1.0](https://www.w3.org/TR/did-core/) and describes how to perform Create, Read, Update and Delete (CRUD) operations for IOTA DID Documents using unspent transaction outputs ([UTXO](/introduction/reference/details#unspent-transaction-output-utxo)) on the IOTA and [Shimmer](https://shimmer.network/) networks, introduced with the [Stardust upgrade](https://blog.shimmer.network/stardust-upgrade-in-a-nutshell/).
 
 ## Data Types & Subschema Notation
 
@@ -28,7 +28,7 @@ Data types and subschemas used throughout this TIP are defined in [TIP-21](https
 
 ### UTXO Ledger
 
-The unspent transaction output ([UTXO](https://wiki.iota.org/IOTA-2.0-Research-Specifications/5.1UTXO)) model defines a ledger state which is comprised of unspent outputs. Outputs are created by a transaction consuming outputs of previous transactions as inputs. The Stardust version of the protocol defines several output types, the relevant ones for the IOTA DID Method are: Basic Outputs for value transactions, and Alias Outputs for storage of DID Documents.
+The unspent transaction output ([UTXO](/introduction/reference/details#unspent-transaction-output-utxo)) model defines a ledger state which is comprised of unspent outputs. Outputs are created by a transaction consuming outputs of previous transactions as inputs. The Stardust version of the protocol defines several output types, the relevant ones for the IOTA DID Method are: Basic Outputs for value transactions, and Alias Outputs for storage of DID Documents.
 
 All outputs must hold a minimum amount of tokens to be stored on the ledger. For output types that can hold arbitrary data, for instance the Alias Output, the amount of tokens held by the output must cover the byte cost of the data stored. This prevents the ledger size from growing uncontrollably while guaranteeing that the data is not pruned from the nodes, which is important for resolving DID Documents. This deposit is fully refundable and can be reclaimed when the output is destroyed.
 
diff --git a/docs/build/identity.rs/0.7-alpha/docs/tutorials/validate_university_degree.mdx b/docs/build/identity.rs/0.7-alpha/docs/tutorials/validate_university_degree.mdx
index 4efdc8a7c2f..994770c780b 100644
--- a/docs/build/identity.rs/0.7-alpha/docs/tutorials/validate_university_degree.mdx
+++ b/docs/build/identity.rs/0.7-alpha/docs/tutorials/validate_university_degree.mdx
@@ -82,7 +82,7 @@ npm run start create-did alice alice-password
 This will create a minimal DID document for alice, and publish it to the Tangle. A Stronghold file `alice.hodl` will be created under `/stronghold-files` which contains the Account's state and the private key of the main verification method of the DID.
 `alice-password` will be used as a password for the stronghold storage. Obviously this password must be more secure in production applications.
 
-See [Creating a Decentralized Identity](https://wiki.iota.org/identity.rs/concepts/decentralized_identifiers/create) for more information about generating DIDs.
+See [Creating a Decentralized Identity](/identity.rs/concepts/decentralized_identifiers/create) for more information about generating DIDs.
 
 ### 2. **Issuer**: Create a DID
 
@@ -97,7 +97,7 @@ with that `uni-of-oslo.hodl` will be created under `/stronhold-files`.
 ### 3. **Issuer**: Add a Verification Method
 
 Since the university will need to issue a signed verifiable credential for Alice, a verification method should be added to the university's DID document.
-Read more about adding verification methods in [update DID Documents](https://wiki.iota.org/identity.rs/concepts/decentralized_identifiers/update).
+Read more about adding verification methods in [update DID Documents](/identity.rs/concepts/decentralized_identifiers/update).
 
 To add a Verification Method the following command can be used:
 
@@ -126,7 +126,7 @@ npm run start create-vm alice alice-password key-1
 
 ### 5: **Issuer**: Create Revocation list
 
-In order for the issuer to be able to revoke credentials in the future, a revocation list is needed. See [Verifiable Credential Revocation](https://wiki.iota.org/identity.rs/concepts/verifiable_credentials/revocation) for further details.
+In order for the issuer to be able to revoke credentials in the future, a revocation list is needed. See [Verifiable Credential Revocation](/identity.rs/concepts/verifiable_credentials/revocation) for further details.
 The following command can be used to create a revocation list:
 
 ```bash
diff --git a/docs/build/identity.rs/next/docs/concepts/decentralized_identifiers/alias.mdx b/docs/build/identity.rs/next/docs/concepts/decentralized_identifiers/alias.mdx
index ebeb2328744..4c315bc5b04 100644
--- a/docs/build/identity.rs/next/docs/concepts/decentralized_identifiers/alias.mdx
+++ b/docs/build/identity.rs/next/docs/concepts/decentralized_identifiers/alias.mdx
@@ -14,7 +14,7 @@ keywords:
 
 # Alias Output
 
-The IOTA method uses the IOTA ledger which uses the [unspent transaction output (UTXO) model](https://wiki.iota.org/goshimmer/protocol_specification/components/ledgerstate). Also, the features of the [Stardust](https://wiki.iota.org/introduction/develop/explanations/what_is_stardust) upgrade are fundamental to the IOTA DID method.
+The IOTA method uses the IOTA ledger which uses the [unspent transaction output (UTXO) model](/goshimmer/protocol_specification/components/ledgerstate). Also, the features of the [Stardust](/introduction/stardust/explanations/what_is_stardust) upgrade are fundamental to the IOTA DID method.
 
 The Alias Output is used for storing the DID Document on the ledger. It is a specific implementation of the UTXO state machine that can hold arbitrary data in its `State Metadata`. The Alias Output has two kinds of controllers, a state controller and a governor. A state controller can execute a state transition which allows updating the data in the `State Metadata`. The governor, on the contrary, can't update the `State Metadata` but can change both controllers and destroy the Alias Output.
 A controller can be either Ed25519 Address, Alias Address or an NFT Address and at most one of each can be set for an Alias Output.
diff --git a/docs/build/identity.rs/next/docs/concepts/decentralized_identifiers/create.mdx b/docs/build/identity.rs/next/docs/concepts/decentralized_identifiers/create.mdx
index 84f54252455..fb8bbd20a33 100644
--- a/docs/build/identity.rs/next/docs/concepts/decentralized_identifiers/create.mdx
+++ b/docs/build/identity.rs/next/docs/concepts/decentralized_identifiers/create.mdx
@@ -55,6 +55,6 @@ Once the transaction is confirmed, the `Alias ID` would be assigned and the DID
 
 ## Running a private network
 
-In order to run the examples, a private network (sometimes also called a private Tangle) needs to run locally. You can refer to [Hornet wiki](https://wiki.iota.org/hornet/develop/how_tos/private_tangle) for instructions on how to run a private network.
+In order to run the examples, a private network (sometimes also called a private Tangle) needs to run locally. You can refer to [Hornet wiki](/hornet/2.0.0-rc.6/how_tos/private_tangle) for instructions on how to run a private network.
 
 If your local private network uses different ports than Hornet, modify the API and faucet endpoints in the examples to match your local setup.
diff --git a/docs/build/identity.rs/next/docs/concepts/decentralized_identifiers/overview.mdx b/docs/build/identity.rs/next/docs/concepts/decentralized_identifiers/overview.mdx
index d6fa95c0052..ce240db6540 100644
--- a/docs/build/identity.rs/next/docs/concepts/decentralized_identifiers/overview.mdx
+++ b/docs/build/identity.rs/next/docs/concepts/decentralized_identifiers/overview.mdx
@@ -79,4 +79,4 @@ Iota Identity helps with abstracting the details of the DID standard by providin
 
 ### Storage solution
 
-IOTA Identity provides a [Stronghold](https://wiki.iota.org/stronghold.rs/welcome/ 'Stronghold is an open-source software library that was originally built to protect IOTA Seeds, but can be used to protect any digital secret.') solution for managing secrets securely, without requiring developers to reinvent the security wheel.
+IOTA Identity provides a [Stronghold](/stronghold.rs/welcome/ 'Stronghold is an open-source software library that was originally built to protect IOTA Seeds, but can be used to protect any digital secret.') solution for managing secrets securely, without requiring developers to reinvent the security wheel.
diff --git a/docs/build/identity.rs/next/docs/contribute.mdx b/docs/build/identity.rs/next/docs/contribute.mdx
index 09b3a39a406..810107b0070 100644
--- a/docs/build/identity.rs/next/docs/contribute.mdx
+++ b/docs/build/identity.rs/next/docs/contribute.mdx
@@ -30,7 +30,7 @@ All of the code is open source and hosted on [GitHub](https://github.com/iotaled
 
 - [Report a bug](https://github.com/iotaledger/identity.rs/issues/new/choose).
 - [Suggest a new feature](https://github.com/iotaledger/documentation/blob/develop/.github/CONTRIBUTING.md).
-- [Contribute to the documentation](https://wiki.iota.org/identity.rs/contribute#contribute-to-the-documentation).
+- [Contribute to the documentation](/identity.rs/contribute#contribute-to-the-documentation).
 
 ## Contribute to the Documentation
 
diff --git a/docs/build/identity.rs/next/docs/decentralized_identity.mdx b/docs/build/identity.rs/next/docs/decentralized_identity.mdx
index c03b33edb1b..9991e477da4 100644
--- a/docs/build/identity.rs/next/docs/decentralized_identity.mdx
+++ b/docs/build/identity.rs/next/docs/decentralized_identity.mdx
@@ -95,7 +95,7 @@ IOTA is a neutral and free-to-use public infrastructure acting as a trustworthy
 
 :::
 
-IOTA is a scalable and feeless Distributed Ledger Technology (DLT). Similar to Blockchain technology, IOTA provides an immutable and decentralized ledger that can transact value through the IOTA token. Unlike Blockchain, IOTA uses a non-linear data structure called the [Tangle](https://wiki.iota.org/learn/about-iota/an-introduction-to-iota#the-tangle-data-structure) which makes it feeless and vastly more scalable. The Tangle also facilitates feeless transactions of data, such as DID registrations and credential revocations. As a single source of truth and trust in data, the Tangle can provide the trust infrastructure in a highly networked world.
+IOTA is a scalable and feeless Distributed Ledger Technology (DLT). Similar to Blockchain technology, IOTA provides an immutable and decentralized ledger that can transact value through the IOTA token. Unlike Blockchain, IOTA uses a non-linear data structure called the [Tangle](/learn/about-iota/an-introduction-to-iota#the-tangle-data-structure) which makes it feeless and vastly more scalable. The Tangle also facilitates feeless transactions of data, such as DID registrations and credential revocations. As a single source of truth and trust in data, the Tangle can provide the trust infrastructure in a highly networked world.
 
 IOTA is uniquely suited for a single unifying identity implementation. The network is designed for both humans and devices, providing a platform for trusted communication between individuals, organizations, and things. The IOTA Foundation’s principles of full transparency, openness, and permissionless innovation provide an open and neutral environment:
 
@@ -103,7 +103,7 @@ IOTA is uniquely suited for a single unifying identity implementation. The netwo
 2. **Public**: Everyone can observe (unless using optional encryption) the transactions in the network. The network is inherently transparent.
 3. **Feeless**: All data and value transactions on the network are free. Unlike other DLTs such as Bitcoin or Ethereum, registration and communication of identities can be written to the network without a requirement to purchase a cryptocurrency token.
 4. **Open Source**: Everyone can view and contribute to the code.
-5. **Easy to use**: IOTA Identity is inherently easier to use due to the lack of fees or requirements to set up an entire private network. In addition, the framework is designed to have an easy to use high-level API, with accessibility to the low-level, more complex and more flexible API. Through integration with the [Stronghold](https://wiki.iota.org/stronghold.rs/welcome 'Stronghold is an open-source software library that was originally built to protect IOTA Seeds, but can be used to protect any digital secret.') project, we also provide out-of-the-box security for secrets.
+5. **Easy to use**: IOTA Identity is inherently easier to use due to the lack of fees or requirements to set up an entire private network. In addition, the framework is designed to have an easy to use high-level API, with accessibility to the low-level, more complex and more flexible API. Through integration with the [Stronghold](/stronghold.rs/welcome 'Stronghold is an open-source software library that was originally built to protect IOTA Seeds, but can be used to protect any digital secret.') project, we also provide out-of-the-box security for secrets.
 
 Data must be immutably stored on a distributed ledger to ensure the decentralized nature of the digital identity protocol. With the network’s continual uptime, credentials are always verifiable without a dependency on the servers of credential issuers. This system also increases individual privacy, because contact with the Issuer is removed from the interaction between Holder and Verifier. Issuers will not be able to track when and how often the Holder uses their credentials. The flexibility afforded from the Tangle means that the digital identity framework remains extendable in the future.
 
diff --git a/docs/build/identity.rs/next/docs/libraries/wasm/getting_started.mdx b/docs/build/identity.rs/next/docs/libraries/wasm/getting_started.mdx
index a3375c72162..3a6fa3ce055 100644
--- a/docs/build/identity.rs/next/docs/libraries/wasm/getting_started.mdx
+++ b/docs/build/identity.rs/next/docs/libraries/wasm/getting_started.mdx
@@ -17,7 +17,7 @@ keywords:
 
 > This is the beta version of the official WASM bindings for [IOTA Identity](https://github.com/iotaledger/identity.rs).
 
-## [API Reference](https://wiki.iota.org/identity.rs/libraries/wasm/api_reference)
+## [API Reference](/identity.rs/libraries/wasm/api_reference)
 
 ## [Examples](https://github.com/iotaledger/identity.rs/blob/main/bindings/wasm/examples/README.md)
 
@@ -64,7 +64,7 @@ The minimum supported version for node is: `v16`
 ## NodeJS Usage
 
 The following code creates a new IOTA DID Document suitable for publishing to a locally running private network.
-See the [instructions](https://wiki.iota.org/hornet/develop/how_tos/private_tangle) on running your own private network.
+See the [instructions](/hornet/2.0.0-rc.6/how_tos/private_tangle) on running your own private network.
 
 <!--
 Test this example using https://github.com/anko/txm: `txm README.md`
diff --git a/docs/build/identity.rs/next/docs/specs/did/iota_did_method_spec.mdx b/docs/build/identity.rs/next/docs/specs/did/iota_did_method_spec.mdx
index 6379dd1fe4e..bb1f3344e47 100644
--- a/docs/build/identity.rs/next/docs/specs/did/iota_did_method_spec.mdx
+++ b/docs/build/identity.rs/next/docs/specs/did/iota_did_method_spec.mdx
@@ -18,7 +18,7 @@ keywords:
 
 ## Abstract
 
-The IOTA DID Method Specification describes a method of implementing the [Decentralized Identifiers](https://www.w3.org/TR/did-core/) (DID) standard on [IOTA](https://iota.org), a Distributed Ledger Technology (DLT). It conforms to the [DID specification v1.0](https://www.w3.org/TR/did-core/) and describes how to perform Create, Read, Update and Delete (CRUD) operations for IOTA DID Documents using unspent transaction outputs ([UTXO](https://wiki.iota.org/IOTA-2.0-Research-Specifications/5.1UTXO)) on the IOTA and [Shimmer](https://shimmer.network/) networks, introduced with the [Stardust upgrade](https://blog.shimmer.network/stardust-upgrade-in-a-nutshell/).
+The IOTA DID Method Specification describes a method of implementing the [Decentralized Identifiers](https://www.w3.org/TR/did-core/) (DID) standard on [IOTA](https://iota.org), a Distributed Ledger Technology (DLT). It conforms to the [DID specification v1.0](https://www.w3.org/TR/did-core/) and describes how to perform Create, Read, Update and Delete (CRUD) operations for IOTA DID Documents using unspent transaction outputs ([UTXO](/introduction/reference/details#unspent-transaction-output-utxo)) on the IOTA and [Shimmer](https://shimmer.network/) networks, introduced with the [Stardust upgrade](https://blog.shimmer.network/stardust-upgrade-in-a-nutshell/).
 
 ## Data Types & Subschema Notation
 
@@ -28,7 +28,7 @@ Data types and subschemas used throughout this TIP are defined in [TIP-21](https
 
 ### UTXO Ledger
 
-The unspent transaction output ([UTXO](https://wiki.iota.org/IOTA-2.0-Research-Specifications/5.1UTXO)) model defines a ledger state which is comprised of unspent outputs. Outputs are created by a transaction consuming outputs of previous transactions as inputs. The Stardust version of the protocol defines several output types, the relevant ones for the IOTA DID Method are: Basic Outputs for value transactions, and Alias Outputs for storage of DID Documents.
+The unspent transaction output ([UTXO](/introduction/reference/details#unspent-transaction-output-utxo)) model defines a ledger state which is comprised of unspent outputs. Outputs are created by a transaction consuming outputs of previous transactions as inputs. The Stardust version of the protocol defines several output types, the relevant ones for the IOTA DID Method are: Basic Outputs for value transactions, and Alias Outputs for storage of DID Documents.
 
 All outputs must hold a minimum amount of tokens to be stored on the ledger. For output types that can hold arbitrary data, for instance the Alias Output, the amount of tokens held by the output must cover the byte cost of the data stored. This prevents the ledger size from growing uncontrollably while guaranteeing that the data is not pruned from the nodes, which is important for resolving DID Documents. This deposit is fully refundable and can be reclaimed when the output is destroyed.
 
diff --git a/docs/build/identity.rs/next/docs/tutorials/validate_university_degree.mdx b/docs/build/identity.rs/next/docs/tutorials/validate_university_degree.mdx
index 4efdc8a7c2f..994770c780b 100644
--- a/docs/build/identity.rs/next/docs/tutorials/validate_university_degree.mdx
+++ b/docs/build/identity.rs/next/docs/tutorials/validate_university_degree.mdx
@@ -82,7 +82,7 @@ npm run start create-did alice alice-password
 This will create a minimal DID document for alice, and publish it to the Tangle. A Stronghold file `alice.hodl` will be created under `/stronghold-files` which contains the Account's state and the private key of the main verification method of the DID.
 `alice-password` will be used as a password for the stronghold storage. Obviously this password must be more secure in production applications.
 
-See [Creating a Decentralized Identity](https://wiki.iota.org/identity.rs/concepts/decentralized_identifiers/create) for more information about generating DIDs.
+See [Creating a Decentralized Identity](/identity.rs/concepts/decentralized_identifiers/create) for more information about generating DIDs.
 
 ### 2. **Issuer**: Create a DID
 
@@ -97,7 +97,7 @@ with that `uni-of-oslo.hodl` will be created under `/stronhold-files`.
 ### 3. **Issuer**: Add a Verification Method
 
 Since the university will need to issue a signed verifiable credential for Alice, a verification method should be added to the university's DID document.
-Read more about adding verification methods in [update DID Documents](https://wiki.iota.org/identity.rs/concepts/decentralized_identifiers/update).
+Read more about adding verification methods in [update DID Documents](/identity.rs/concepts/decentralized_identifiers/update).
 
 To add a Verification Method the following command can be used:
 
@@ -126,7 +126,7 @@ npm run start create-vm alice alice-password key-1
 
 ### 5: **Issuer**: Create Revocation list
 
-In order for the issuer to be able to revoke credentials in the future, a revocation list is needed. See [Verifiable Credential Revocation](https://wiki.iota.org/identity.rs/concepts/verifiable_credentials/revocation) for further details.
+In order for the issuer to be able to revoke credentials in the future, a revocation list is needed. See [Verifiable Credential Revocation](/identity.rs/concepts/verifiable_credentials/revocation) for further details.
 The following command can be used to create a revocation list:
 
 ```bash
diff --git a/docs/build/identity.rs/v0.5.0/docs/concepts/decentralized_identifiers/overview.mdx b/docs/build/identity.rs/v0.5.0/docs/concepts/decentralized_identifiers/overview.mdx
index d43be3252da..994ed62ca5e 100644
--- a/docs/build/identity.rs/v0.5.0/docs/concepts/decentralized_identifiers/overview.mdx
+++ b/docs/build/identity.rs/v0.5.0/docs/concepts/decentralized_identifiers/overview.mdx
@@ -70,7 +70,7 @@ IOTA is a feeless Distributed Ledger Technology, which means that messages can i
 
 ### Ease-of-use
 
-Without the need for a token, IOTA Identity can directly be used on the main network without having to purchase and manage a cryptocurrency token. In addition, the framework provides easy-to-use APIs that allow both standardized behavior or flexible, yet more complex access. Lastly, IOTA Identity provides a [Stronghold](https://wiki.iota.org/stronghold.rs/welcome/ 'Stronghold is an open-source software library that was originally built to protect IOTA Seeds, but can be used to protect any digital secret.') solution for managing secrets securely, without requiring developers to reinvent the security wheel.
+Without the need for a token, IOTA Identity can directly be used on the main network without having to purchase and manage a cryptocurrency token. In addition, the framework provides easy-to-use APIs that allow both standardized behavior or flexible, yet more complex access. Lastly, IOTA Identity provides a [Stronghold](/stronghold.rs/welcome/ 'Stronghold is an open-source software library that was originally built to protect IOTA Seeds, but can be used to protect any digital secret.') solution for managing secrets securely, without requiring developers to reinvent the security wheel.
 
 ### General Purpose DLT
 
diff --git a/docs/build/identity.rs/v0.5.0/docs/concepts/decentralized_identifiers/private_tangle.mdx b/docs/build/identity.rs/v0.5.0/docs/concepts/decentralized_identifiers/private_tangle.mdx
index 8cc15371ac5..57b1cf1f4eb 100644
--- a/docs/build/identity.rs/v0.5.0/docs/concepts/decentralized_identifiers/private_tangle.mdx
+++ b/docs/build/identity.rs/v0.5.0/docs/concepts/decentralized_identifiers/private_tangle.mdx
@@ -13,7 +13,7 @@ import TabItem from '@theme/TabItem';
 
 ## Example
 
-This example shows how you can create a DID on a private tangle. You can run it together with a local [Hornet node](https://wiki.iota.org/hornet/welcome).
+This example shows how you can create a DID on a private tangle. You can run it together with a local [Hornet node](/hornet/welcome).
 
 ### Account Module (Recommended)
 
diff --git a/docs/build/identity.rs/v0.5.0/docs/contribute.mdx b/docs/build/identity.rs/v0.5.0/docs/contribute.mdx
index 09b3a39a406..810107b0070 100644
--- a/docs/build/identity.rs/v0.5.0/docs/contribute.mdx
+++ b/docs/build/identity.rs/v0.5.0/docs/contribute.mdx
@@ -30,7 +30,7 @@ All of the code is open source and hosted on [GitHub](https://github.com/iotaled
 
 - [Report a bug](https://github.com/iotaledger/identity.rs/issues/new/choose).
 - [Suggest a new feature](https://github.com/iotaledger/documentation/blob/develop/.github/CONTRIBUTING.md).
-- [Contribute to the documentation](https://wiki.iota.org/identity.rs/contribute#contribute-to-the-documentation).
+- [Contribute to the documentation](/identity.rs/contribute#contribute-to-the-documentation).
 
 ## Contribute to the Documentation
 
diff --git a/docs/build/identity.rs/v0.5.0/docs/decentralized_identity.mdx b/docs/build/identity.rs/v0.5.0/docs/decentralized_identity.mdx
index c03b33edb1b..9991e477da4 100644
--- a/docs/build/identity.rs/v0.5.0/docs/decentralized_identity.mdx
+++ b/docs/build/identity.rs/v0.5.0/docs/decentralized_identity.mdx
@@ -95,7 +95,7 @@ IOTA is a neutral and free-to-use public infrastructure acting as a trustworthy
 
 :::
 
-IOTA is a scalable and feeless Distributed Ledger Technology (DLT). Similar to Blockchain technology, IOTA provides an immutable and decentralized ledger that can transact value through the IOTA token. Unlike Blockchain, IOTA uses a non-linear data structure called the [Tangle](https://wiki.iota.org/learn/about-iota/an-introduction-to-iota#the-tangle-data-structure) which makes it feeless and vastly more scalable. The Tangle also facilitates feeless transactions of data, such as DID registrations and credential revocations. As a single source of truth and trust in data, the Tangle can provide the trust infrastructure in a highly networked world.
+IOTA is a scalable and feeless Distributed Ledger Technology (DLT). Similar to Blockchain technology, IOTA provides an immutable and decentralized ledger that can transact value through the IOTA token. Unlike Blockchain, IOTA uses a non-linear data structure called the [Tangle](/learn/about-iota/an-introduction-to-iota#the-tangle-data-structure) which makes it feeless and vastly more scalable. The Tangle also facilitates feeless transactions of data, such as DID registrations and credential revocations. As a single source of truth and trust in data, the Tangle can provide the trust infrastructure in a highly networked world.
 
 IOTA is uniquely suited for a single unifying identity implementation. The network is designed for both humans and devices, providing a platform for trusted communication between individuals, organizations, and things. The IOTA Foundation’s principles of full transparency, openness, and permissionless innovation provide an open and neutral environment:
 
@@ -103,7 +103,7 @@ IOTA is uniquely suited for a single unifying identity implementation. The netwo
 2. **Public**: Everyone can observe (unless using optional encryption) the transactions in the network. The network is inherently transparent.
 3. **Feeless**: All data and value transactions on the network are free. Unlike other DLTs such as Bitcoin or Ethereum, registration and communication of identities can be written to the network without a requirement to purchase a cryptocurrency token.
 4. **Open Source**: Everyone can view and contribute to the code.
-5. **Easy to use**: IOTA Identity is inherently easier to use due to the lack of fees or requirements to set up an entire private network. In addition, the framework is designed to have an easy to use high-level API, with accessibility to the low-level, more complex and more flexible API. Through integration with the [Stronghold](https://wiki.iota.org/stronghold.rs/welcome 'Stronghold is an open-source software library that was originally built to protect IOTA Seeds, but can be used to protect any digital secret.') project, we also provide out-of-the-box security for secrets.
+5. **Easy to use**: IOTA Identity is inherently easier to use due to the lack of fees or requirements to set up an entire private network. In addition, the framework is designed to have an easy to use high-level API, with accessibility to the low-level, more complex and more flexible API. Through integration with the [Stronghold](/stronghold.rs/welcome 'Stronghold is an open-source software library that was originally built to protect IOTA Seeds, but can be used to protect any digital secret.') project, we also provide out-of-the-box security for secrets.
 
 Data must be immutably stored on a distributed ledger to ensure the decentralized nature of the digital identity protocol. With the network’s continual uptime, credentials are always verifiable without a dependency on the servers of credential issuers. This system also increases individual privacy, because contact with the Issuer is removed from the interaction between Holder and Verifier. Issuers will not be able to track when and how often the Holder uses their credentials. The flexibility afforded from the Tangle means that the digital identity framework remains extendable in the future.
 
diff --git a/docs/build/identity.rs/v0.5.0/docs/libraries/wasm/getting_started.mdx b/docs/build/identity.rs/v0.5.0/docs/libraries/wasm/getting_started.mdx
index 40279e2028a..39b7f36f4c2 100644
--- a/docs/build/identity.rs/v0.5.0/docs/libraries/wasm/getting_started.mdx
+++ b/docs/build/identity.rs/v0.5.0/docs/libraries/wasm/getting_started.mdx
@@ -17,7 +17,7 @@ keywords:
 
 > This is the beta version of the official WASM bindings for [IOTA Identity](https://github.com/iotaledger/identity.rs).
 
-## [API Reference](https://wiki.iota.org/identity.rs/libraries/wasm/api_reference)
+## [API Reference](/identity.rs/libraries/wasm/api_reference)
 
 ## [Account Examples](https://github.com/iotaledger/identity.rs/blob/main/bindings/wasm/examples-account/README.md)
 
diff --git a/docs/build/identity.rs/v0.6.0/docs/concepts/decentralized_identifiers/overview.mdx b/docs/build/identity.rs/v0.6.0/docs/concepts/decentralized_identifiers/overview.mdx
index d43be3252da..994ed62ca5e 100644
--- a/docs/build/identity.rs/v0.6.0/docs/concepts/decentralized_identifiers/overview.mdx
+++ b/docs/build/identity.rs/v0.6.0/docs/concepts/decentralized_identifiers/overview.mdx
@@ -70,7 +70,7 @@ IOTA is a feeless Distributed Ledger Technology, which means that messages can i
 
 ### Ease-of-use
 
-Without the need for a token, IOTA Identity can directly be used on the main network without having to purchase and manage a cryptocurrency token. In addition, the framework provides easy-to-use APIs that allow both standardized behavior or flexible, yet more complex access. Lastly, IOTA Identity provides a [Stronghold](https://wiki.iota.org/stronghold.rs/welcome/ 'Stronghold is an open-source software library that was originally built to protect IOTA Seeds, but can be used to protect any digital secret.') solution for managing secrets securely, without requiring developers to reinvent the security wheel.
+Without the need for a token, IOTA Identity can directly be used on the main network without having to purchase and manage a cryptocurrency token. In addition, the framework provides easy-to-use APIs that allow both standardized behavior or flexible, yet more complex access. Lastly, IOTA Identity provides a [Stronghold](/stronghold.rs/welcome/ 'Stronghold is an open-source software library that was originally built to protect IOTA Seeds, but can be used to protect any digital secret.') solution for managing secrets securely, without requiring developers to reinvent the security wheel.
 
 ### General Purpose DLT
 
diff --git a/docs/build/identity.rs/v0.6.0/docs/concepts/decentralized_identifiers/private_tangle.mdx b/docs/build/identity.rs/v0.6.0/docs/concepts/decentralized_identifiers/private_tangle.mdx
index 0b023ff5585..d9ada7ec006 100644
--- a/docs/build/identity.rs/v0.6.0/docs/concepts/decentralized_identifiers/private_tangle.mdx
+++ b/docs/build/identity.rs/v0.6.0/docs/concepts/decentralized_identifiers/private_tangle.mdx
@@ -13,7 +13,7 @@ import TabItem from '@theme/TabItem';
 
 ## Example
 
-This example shows how you can create a DID on a private tangle. You can run it together with a local [Hornet node](https://wiki.iota.org/hornet/welcome).
+This example shows how you can create a DID on a private tangle. You can run it together with a local [Hornet node](/hornet/welcome).
 
 ### Account Module (Recommended)
 
diff --git a/docs/build/identity.rs/v0.6.0/docs/contribute.mdx b/docs/build/identity.rs/v0.6.0/docs/contribute.mdx
index 09b3a39a406..810107b0070 100644
--- a/docs/build/identity.rs/v0.6.0/docs/contribute.mdx
+++ b/docs/build/identity.rs/v0.6.0/docs/contribute.mdx
@@ -30,7 +30,7 @@ All of the code is open source and hosted on [GitHub](https://github.com/iotaled
 
 - [Report a bug](https://github.com/iotaledger/identity.rs/issues/new/choose).
 - [Suggest a new feature](https://github.com/iotaledger/documentation/blob/develop/.github/CONTRIBUTING.md).
-- [Contribute to the documentation](https://wiki.iota.org/identity.rs/contribute#contribute-to-the-documentation).
+- [Contribute to the documentation](/identity.rs/contribute#contribute-to-the-documentation).
 
 ## Contribute to the Documentation
 
diff --git a/docs/build/identity.rs/v0.6.0/docs/decentralized_identity.mdx b/docs/build/identity.rs/v0.6.0/docs/decentralized_identity.mdx
index c03b33edb1b..9991e477da4 100644
--- a/docs/build/identity.rs/v0.6.0/docs/decentralized_identity.mdx
+++ b/docs/build/identity.rs/v0.6.0/docs/decentralized_identity.mdx
@@ -95,7 +95,7 @@ IOTA is a neutral and free-to-use public infrastructure acting as a trustworthy
 
 :::
 
-IOTA is a scalable and feeless Distributed Ledger Technology (DLT). Similar to Blockchain technology, IOTA provides an immutable and decentralized ledger that can transact value through the IOTA token. Unlike Blockchain, IOTA uses a non-linear data structure called the [Tangle](https://wiki.iota.org/learn/about-iota/an-introduction-to-iota#the-tangle-data-structure) which makes it feeless and vastly more scalable. The Tangle also facilitates feeless transactions of data, such as DID registrations and credential revocations. As a single source of truth and trust in data, the Tangle can provide the trust infrastructure in a highly networked world.
+IOTA is a scalable and feeless Distributed Ledger Technology (DLT). Similar to Blockchain technology, IOTA provides an immutable and decentralized ledger that can transact value through the IOTA token. Unlike Blockchain, IOTA uses a non-linear data structure called the [Tangle](/learn/about-iota/an-introduction-to-iota#the-tangle-data-structure) which makes it feeless and vastly more scalable. The Tangle also facilitates feeless transactions of data, such as DID registrations and credential revocations. As a single source of truth and trust in data, the Tangle can provide the trust infrastructure in a highly networked world.
 
 IOTA is uniquely suited for a single unifying identity implementation. The network is designed for both humans and devices, providing a platform for trusted communication between individuals, organizations, and things. The IOTA Foundation’s principles of full transparency, openness, and permissionless innovation provide an open and neutral environment:
 
@@ -103,7 +103,7 @@ IOTA is uniquely suited for a single unifying identity implementation. The netwo
 2. **Public**: Everyone can observe (unless using optional encryption) the transactions in the network. The network is inherently transparent.
 3. **Feeless**: All data and value transactions on the network are free. Unlike other DLTs such as Bitcoin or Ethereum, registration and communication of identities can be written to the network without a requirement to purchase a cryptocurrency token.
 4. **Open Source**: Everyone can view and contribute to the code.
-5. **Easy to use**: IOTA Identity is inherently easier to use due to the lack of fees or requirements to set up an entire private network. In addition, the framework is designed to have an easy to use high-level API, with accessibility to the low-level, more complex and more flexible API. Through integration with the [Stronghold](https://wiki.iota.org/stronghold.rs/welcome 'Stronghold is an open-source software library that was originally built to protect IOTA Seeds, but can be used to protect any digital secret.') project, we also provide out-of-the-box security for secrets.
+5. **Easy to use**: IOTA Identity is inherently easier to use due to the lack of fees or requirements to set up an entire private network. In addition, the framework is designed to have an easy to use high-level API, with accessibility to the low-level, more complex and more flexible API. Through integration with the [Stronghold](/stronghold.rs/welcome 'Stronghold is an open-source software library that was originally built to protect IOTA Seeds, but can be used to protect any digital secret.') project, we also provide out-of-the-box security for secrets.
 
 Data must be immutably stored on a distributed ledger to ensure the decentralized nature of the digital identity protocol. With the network’s continual uptime, credentials are always verifiable without a dependency on the servers of credential issuers. This system also increases individual privacy, because contact with the Issuer is removed from the interaction between Holder and Verifier. Issuers will not be able to track when and how often the Holder uses their credentials. The flexibility afforded from the Tangle means that the digital identity framework remains extendable in the future.
 
diff --git a/docs/build/identity.rs/v0.6.0/docs/libraries/wasm/getting_started.mdx b/docs/build/identity.rs/v0.6.0/docs/libraries/wasm/getting_started.mdx
index 166cbf17c25..d244184d421 100644
--- a/docs/build/identity.rs/v0.6.0/docs/libraries/wasm/getting_started.mdx
+++ b/docs/build/identity.rs/v0.6.0/docs/libraries/wasm/getting_started.mdx
@@ -17,7 +17,7 @@ keywords:
 
 > This is the beta version of the official WASM bindings for [IOTA Identity](https://github.com/iotaledger/identity.rs).
 
-## [API Reference](https://wiki.iota.org/identity.rs/libraries/wasm/api_reference)
+## [API Reference](/identity.rs/libraries/wasm/api_reference)
 
 ## [Account Examples](https://github.com/iotaledger/identity.rs/blob/support/v0.6/bindings/wasm/examples-account/README.md)
 
diff --git a/docs/build/identity.rs/v0.6.0/docs/tutorials/validate_university_degree.mdx b/docs/build/identity.rs/v0.6.0/docs/tutorials/validate_university_degree.mdx
index 4f60ebcc512..e7b65d81461 100644
--- a/docs/build/identity.rs/v0.6.0/docs/tutorials/validate_university_degree.mdx
+++ b/docs/build/identity.rs/v0.6.0/docs/tutorials/validate_university_degree.mdx
@@ -79,7 +79,7 @@ npm run start create-did alice alice-password
 This will create a minimal DID document for alice, and publish it to the Tangle. A Stronghold file `alice.hodl` will be created under `/stronghold-files` which contains the Account's state and the private key of the main verification method of the DID.
 `alice-password` will be used as a password for the stronghold storage. Obviously this password must be more secure in production applications.
 
-See [Creating a Decentralized Identity](https://wiki.iota.org/identity.rs/concepts/decentralized_identifiers/create) for more information about generating DIDs.
+See [Creating a Decentralized Identity](/identity.rs/concepts/decentralized_identifiers/create) for more information about generating DIDs.
 
 ### 2. **Issuer**: Create a DID
 
@@ -94,7 +94,7 @@ with that `uni-of-oslo.hodl` will be created under `/stronhold-files`.
 ### 3. **Issuer**: Add a Verification Method
 
 Since the university will need to issue a signed verifiable credential for Alice, a verification method should be added to the university's DID document.
-Read more about adding verification methods in [update DID Documents](https://wiki.iota.org/identity.rs/concepts/decentralized_identifiers/update).
+Read more about adding verification methods in [update DID Documents](/identity.rs/concepts/decentralized_identifiers/update).
 
 To add a Verification Method the following command can be used:
 
@@ -123,7 +123,7 @@ npm run start create-vm alice alice-password key-1
 
 ### 5: **Issuer**: Create Revocation list
 
-In order for the issuer to be able to revoke credentials in the future, a revocation list is needed. See [Verifiable Credential Revocation](https://wiki.iota.org/identity.rs/concepts/verifiable_credentials/revocation) for further details.
+In order for the issuer to be able to revoke credentials in the future, a revocation list is needed. See [Verifiable Credential Revocation](/identity.rs/concepts/verifiable_credentials/revocation) for further details.
 The following command can be used to create a revocation list:
 
 ```bash
diff --git a/docs/build/introduction-docs/chrysalis/docs/explanations/libraries.md b/docs/build/introduction-docs/chrysalis/docs/explanations/libraries.md
index 198a8e90497..bc182df9112 100644
--- a/docs/build/introduction-docs/chrysalis/docs/explanations/libraries.md
+++ b/docs/build/introduction-docs/chrysalis/docs/explanations/libraries.md
@@ -18,8 +18,8 @@ With the IOTA client libraries you can easily integrate IOTA into your own appli
 
 The official IOTA libraries serve as `one-source-code-of-truth` to IOTA users and provide binding to other programming languages. Below is a list of the IOTA libraries. You can also check out the [IOTA client libraries blog post](https://blog.iota.org/the-new-iota-client-libraries-harder-better-faster-stronger/), to learn about the libraries' core principles.
 
-- [client-lib](https://wiki.iota.org/iota.rs/welcome): a general purpose IOTA client library for interacting with the IOTA network (Tangle).
-- [wallet-lib](https://wiki.iota.org/wallet.rs/welcome): a stateful library specifically designed to be used for IOTA value-based transfers .
+- [client-lib](/iota.rs/welcome): a general purpose IOTA client library for interacting with the IOTA network (Tangle).
+- [wallet-lib](/wallet.rs/welcome): a stateful library specifically designed to be used for IOTA value-based transfers .
 - [iota.c](https://github.com/iotaledger/iota.c): a special-purpose library in C for embedded devices (with microcontrollers) covering a basic features of `client-lib` or `wallet-lib.`
 - [iota.js](https://github.com/iotaledger/iota.js/tree/chrysalis): an initial IOTA client library in Typescript that can be used in a web browser.
 - [iota.go](https://github.com/iotaledger/iota.go/tree/chrysalis/phase2): an initial IOTA client library in Golang.
diff --git a/docs/build/introduction-docs/chrysalis/docs/explanations/node_software.md b/docs/build/introduction-docs/chrysalis/docs/explanations/node_software.md
index 89614c76464..a697d7f23f3 100644
--- a/docs/build/introduction-docs/chrysalis/docs/explanations/node_software.md
+++ b/docs/build/introduction-docs/chrysalis/docs/explanations/node_software.md
@@ -22,7 +22,7 @@ Hornet is an EDF-supported community node written in Go and has already proven i
 ## Hornet
 
 - [Official GitHub Repository](https://github.com/gohornet/hornet).
-- [Documentation](https://wiki.iota.org/hornet/welcome).
+- [Documentation](/hornet/welcome).
 
 ## Node API Specification
 
diff --git a/docs/build/introduction-docs/chrysalis/docs/explanations/update/chrysalis_improvements.md b/docs/build/introduction-docs/chrysalis/docs/explanations/update/chrysalis_improvements.md
index 52675dae992..ac2dd08f0a0 100644
--- a/docs/build/introduction-docs/chrysalis/docs/explanations/update/chrysalis_improvements.md
+++ b/docs/build/introduction-docs/chrysalis/docs/explanations/update/chrysalis_improvements.md
@@ -49,7 +49,7 @@ A new [Uniform Random Tip Selection](https://github.com/iotaledger/protocol-rfcs
 
 With Chrysalis, we wanted to offer a more standard API on both the node and client library level. Node implementations provide a completely redesigned [RESTful](https://editor.swagger.io/?url=https://raw.githubusercontent.com/rufsam/protocol-rfcs/master/text/0026-rest-api/rest-api.yaml) and [eventful](https://playground.asyncapi.io/?load=https://raw.githubusercontent.com/luca-moser/protocol-rfcs/rfc/node-event-api/text/0033-node-event-api/0033-node-event-api.yml) API implementations.
 
-Our [client libraries](https://wiki.iota.org/build/networks/iota-1.5#libraries) provide high-level abstractions that allow developers to build solutions that are easier to develop and cheaper to maintain.
+Our [client libraries](/build/welcome) provide high-level abstractions that allow developers to build solutions that are easier to develop and cheaper to maintain.
 
 ## Full Changelog
 
diff --git a/docs/build/introduction-docs/chrysalis/docs/explanations/update/migration_mechanism.md b/docs/build/introduction-docs/chrysalis/docs/explanations/update/migration_mechanism.md
index 326662dfaa4..9246ab77c84 100644
--- a/docs/build/introduction-docs/chrysalis/docs/explanations/update/migration_mechanism.md
+++ b/docs/build/introduction-docs/chrysalis/docs/explanations/update/migration_mechanism.md
@@ -105,4 +105,4 @@ A verifier node is a Chrysalis Phase 2 node which upon seeing receipts:
 2. Then performs WOTS signature verification of the legacy milestone bundle and all confirmed bundles.
 3. Additionally, it also checks that all confirmed funds on the legacy network for the given legacy milestone, are indeed minted with a given batch of receipts (i.e. nothing is left out).
 
-For further reference, you can read the [Hornet as a verifier node](https://wiki.iota.org/hornet/post_installation/run_as_a_verifier) page.
+For further reference, you can read the [Hornet as a verifier node](/hornet/how_tos/run_as_a_verifier) page.
diff --git a/docs/build/introduction-docs/chrysalis/docs/explanations/update/path_to_chrysalis.md b/docs/build/introduction-docs/chrysalis/docs/explanations/update/path_to_chrysalis.md
index 426184ad42e..be6a4f141aa 100644
--- a/docs/build/introduction-docs/chrysalis/docs/explanations/update/path_to_chrysalis.md
+++ b/docs/build/introduction-docs/chrysalis/docs/explanations/update/path_to_chrysalis.md
@@ -86,7 +86,7 @@ The Chrysalis changes were specified in the form of RFCs. You can find all the R
 
 ### Wallet Support
 
-The Trinity wallet was a popular IOTA wallet. With Chrysalis, we released a new wallet implementation, [Firefly](https://blog.iota.org/firefly-iota-next-generation-wallet-26bdd4d01510/). The team worked on a complete reevaluation of the wallet architecture, with a completely redesigned experience for you. At its core is a [new wallet library](https://wiki.iota.org/wallet.rs/welcome) written in Rust. The wallet library is designed to allow other developers to easily implement IOTA wallets within their applications. Another new Rust library utilized by Firefly is Stronghold; Stronghold enables ultra-secure secret handling and storage.
+The Trinity wallet was a popular IOTA wallet. With Chrysalis, we released a new wallet implementation, [Firefly](https://blog.iota.org/firefly-iota-next-generation-wallet-26bdd4d01510/). The team worked on a complete reevaluation of the wallet architecture, with a completely redesigned experience for you. At its core is a [new wallet library](/wallet.rs/welcome) written in Rust. The wallet library is designed to allow other developers to easily implement IOTA wallets within their applications. Another new Rust library utilized by Firefly is Stronghold; Stronghold enables ultra-secure secret handling and storage.
 
 ### Infrastructure
 
diff --git a/docs/build/introduction-docs/chrysalis/docs/how_tos/exchange.md b/docs/build/introduction-docs/chrysalis/docs/how_tos/exchange.md
index 30a0fc5e72c..37eedf23a8a 100644
--- a/docs/build/introduction-docs/chrysalis/docs/how_tos/exchange.md
+++ b/docs/build/introduction-docs/chrysalis/docs/how_tos/exchange.md
@@ -30,7 +30,7 @@ Within the Chrysalis update (also known as IOTA 1.5), some building blocks were
 
 ## How Do I Implement It to My Exchange?
 
-In [wallet.rs](https://wiki.iota.org/wallet.rs/welcome), we use an account model so you can create an account for each of your users. Another approach would be to use one account and generate multiple addresses, which you can then link to the users in your database. The wallet library is designed to be as flexible as possible to back up any of your use cases.
+In [wallet.rs](/wallet.rs/welcome), we use an account model so you can create an account for each of your users. Another approach would be to use one account and generate multiple addresses, which you can then link to the users in your database. The wallet library is designed to be as flexible as possible to back up any of your use cases.
 
 Since IOTA addresses in the Chrysalis network are perfectly reusable, they can be mapped to your users in a clear and concise way:
 
@@ -69,7 +69,7 @@ Features of the Wallet Library:
 
 The Wallet Library is a stateful package with a standardized interface for developers to build applications involving IOTA value transactions. It offers abstractions to handle IOTA payments and can optionally interact with the IOTA Stronghold for seed handling, seed storage, and state backup. You can also use an SQLite database instead of Stronghold but it is not as secure.
 
-For further reference, you can read our [wallet documentation here](https://wiki.iota.org/wallet.rs/welcome).
+For further reference, you can read our [wallet documentation here](/wallet.rs/welcome).
 
 The following examples cover the _multi-account approach_ using the `NodeJS` binding:
 
@@ -153,7 +153,7 @@ let account = await manager.createAccount({
 
 Each account is related to a specific IOTA network (mainnet/devnet) which is referenced by a node property, such as node url (in this example, the Chrysalis devnet balancer).
 
-For more information about `clientOptions`, please refer to the [Wallet NodeJs API Reference](https://wiki.iota.org/wallet.rs/libraries/nodejs/api_reference).
+For more information about `clientOptions`, please refer to the [Wallet NodeJs API Reference](/wallet.rs/reference/nodejs).
 
 The `Alias` can be whatever fits to the given use case and should be unique. The `Alias` is typically used to identify the given account later on. Each account is also represented by an `index` which is incremented (by 1) every time a new account is created. Any account can then be referred to via `index`, `alias`, or one of its generated `addresses`.
 
@@ -252,7 +252,7 @@ data: {
 
 `accountId` can then be used to identify the given account via `AccountManager.getAccount(accountId)`.
 
-For further reference, you can read more about events in the [API reference](https://wiki.iota.org/wallet.rs/libraries/nodejs/api_reference#addeventlistenerevent-cb).
+For further reference, you can read more about events in the [API reference](/wallet.rs/reference/nodejs).
 
 ### 5. Check the Account Balance
 
diff --git a/docs/build/introduction-docs/chrysalis/docs/how_tos/mainnet_hornet_node_k8s.md b/docs/build/introduction-docs/chrysalis/docs/how_tos/mainnet_hornet_node_k8s.md
index 70d1015a45f..eace4568669 100644
--- a/docs/build/introduction-docs/chrysalis/docs/how_tos/mainnet_hornet_node_k8s.md
+++ b/docs/build/introduction-docs/chrysalis/docs/how_tos/mainnet_hornet_node_k8s.md
@@ -9,7 +9,7 @@ keywords:
 
 # How to Run Hornet On Kubernetes
 
-This page explains how to run [IOTA mainnet](../reference/networks/mainnet.md) [Hornet](https://wiki.iota.org/hornet/welcome) nodes in a Kubernetes (K8s) environment. [Kubernetes](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/) is a portable, extensible, open-source platform for managing containerized workloads and services that facilitates both **declarative configuration** and automation. It has a large, rapidly growing ecosystem. K8s services, support, and tools are widely available on multiple cloud providers.
+This page explains how to run [IOTA mainnet](../reference/networks/mainnet.md) [Hornet](/hornet/welcome) nodes in a Kubernetes (K8s) environment. [Kubernetes](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/) is a portable, extensible, open-source platform for managing containerized workloads and services that facilitates both **declarative configuration** and automation. It has a large, rapidly growing ecosystem. K8s services, support, and tools are widely available on multiple cloud providers.
 
 If you are not familiar with K8s we recommend you to start by [learning the K8s technology](https://kubernetes.io/docs/tutorials/kubernetes-basics/).
 
@@ -27,7 +27,7 @@ You will also need to [properly configure](https://kubernetes.io/docs/reference/
 You can pass the following parameters as variables on the command line to the one-click script:
 
 - `NAMESPACE`: The namespace where the one-click script will create the K8s objects. `tangle` by default.
-- `PEER`: A [multipeer address](https://wiki.iota.org/hornet/post_installation/peering#addressing-peer-neighbors) that will be used to peer your nodes with. If you do not provide an address, auto-peering will be configured for the set's first Hornet Node (`hornet-0`).
+- `PEER`: A [multipeer address](/hornet/references/peering) that will be used to peer your nodes with. If you do not provide an address, auto-peering will be configured for the set's first Hornet Node (`hornet-0`).
 - `INSTANCES`: The number of Hornet instances to be deployed. `1` by default.
 - `INGRESS_CLASS`: The class associated with the [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) object that will be used to externally expose the Node API endpoint so that it can be load balanced. It can depend on the target K8s environment. `nginx` by default.
 
diff --git a/docs/build/introduction-docs/chrysalis/docs/how_tos/migration/hub_migration.md b/docs/build/introduction-docs/chrysalis/docs/how_tos/migration/hub_migration.md
index 030bbf971a5..e99a9be48e7 100644
--- a/docs/build/introduction-docs/chrysalis/docs/how_tos/migration/hub_migration.md
+++ b/docs/build/introduction-docs/chrysalis/docs/how_tos/migration/hub_migration.md
@@ -13,7 +13,7 @@ keywords:
 
 :::info
 
-This guide outlines how to switch from using IOTA Hub to [Wallet.rs](https://wiki.iota.org/wallet.rs/welcome) or its [bindings](https://wiki.iota.org/wallet.rs/libraries/overview) instead.
+This guide outlines how to switch from using IOTA Hub to [Wallet.rs](/wallet.rs/welcome) or its bindings instead.
 
 :::
 
@@ -31,11 +31,11 @@ Dave de Fijter
 
 Because of the unique features of IOTA 1.0, it was difficult to manage IOTA transactions with just a library. With the Chrysalis update, we have updated to be more accommodating to industry-wide standards and developers.
 
-IOTA Hub was deprecated with the Chrysalis upgrade and will not work with the new protocol changes. If you somehow still use Hub, we recommend that you to switch our new wallet library [Iota.rs](https://wiki.iota.org/iota.rs/welcome), or its [bindings](https://wiki.iota.org/iota.rs/libraries/overview), where you can easily manage IOTA addresses, deposits, and withdrawals for user accounts.
+IOTA Hub was deprecated with the Chrysalis upgrade and will not work with the new protocol changes. If you somehow still use Hub, we recommend that you to switch our new wallet library [Iota.rs](/iota.rs/welcome), or its bindings, where you can easily manage IOTA addresses, deposits, and withdrawals for user accounts.
 
 To upgrade from Hub to a Chrysalis implementation you will need to:
 
-- Integrate the Chrysalis network using [Wallet.rs](https://wiki.iota.org/wallet.rs/welcome) as mentioned in the [Exchange section](../exchange.md).
+- Integrate the Chrysalis network using [Wallet.rs](/wallet.rs/welcome) as mentioned in the [Exchange section](../exchange.md).
 - Pause withdrawals/deposits.
 - Make sure all balances have been swept and all deposits have been processed.
 - [Transfer all IOTA to a generated migration address](token_migration.md).
diff --git a/docs/build/introduction-docs/chrysalis/docs/how_tos/one_click_private_tangle.md b/docs/build/introduction-docs/chrysalis/docs/how_tos/one_click_private_tangle.md
index be4241870ec..26dbe0ade89 100644
--- a/docs/build/introduction-docs/chrysalis/docs/how_tos/one_click_private_tangle.md
+++ b/docs/build/introduction-docs/chrysalis/docs/how_tos/one_click_private_tangle.md
@@ -33,7 +33,7 @@ There are three main nodes identified:
 
 These three nodes are peered amongst each other as our architecture is based on Docker, so that each node runs within a Docker Container and all containers are attached to the same network named `private-tangle`.
 
-To facilitate adding extra nodes to your Tangle, an [autopeering](https://wiki.iota.org/hornet/post_installation/peering#autopeering) entry node is automatically created. Furthermore, the `Spammer` and the `node1` enable by default autopeering so that they can be peered with any extra node later added. The autopeering entry node listens on the _UDP_ port `14626`.
+To facilitate adding extra nodes to your Tangle, an [autopeering](/hornet/references/peering#autopeering) entry node is automatically created. Furthermore, the `Spammer` and the `node1` enable by default autopeering so that they can be peered with any extra node later added. The autopeering entry node listens on the _UDP_ port `14626`.
 
 In addition, to make your Tangle easier to use, a Tangle Explorer can be deployed, conveniently, similar to the one at [https://explorer.iota.org](https://explorer.iota.org). As a result, all the participants in the network are able to browse and visualize messages or IOTA Streams channels. The Tangle Explorer deployment involves two containers, one with the REST API listening at port `4000` and one with the Web Application exposed to the host at port `8082`. The Tangle Explorer also uses MQTT to watch what is happening on your Tangle. This is the rationale for having a connection between the Explorer's REST API Container and the Hornet Node through port `1881`.
 
@@ -90,7 +90,7 @@ The summary of services exposed to the outside world (through the host) is as fo
 
 The deployment architecture described above can be easily transitioned to production-ready by incorporating a reverse proxy leveraging [NGINX](https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/#). As a result, the amount of ports exposed to the outside world can be reduced or load balancing between the nodes of your Tangle can be achieved. IOTA intends to provide automatic, "one-click" deployment of this kind of enhanced architectures in a future version of this software.
 
-To support the deployment of an IOTA Tangle, the IOTA Community has developed a set of shell scripts and configuration templates to make it easier to deploy a (Docker based) Tangle with the architecture described above. You can also customize the [default configuration files](https://github.com/iotaledger/one-click-tangle/blob/chrysalis/hornet-private-net/config) if, for instance, you want to enable extra [Hornet plugins](https://wiki.iota.org/hornet/post_installation#configuration-files).
+To support the deployment of an IOTA Tangle, the IOTA Community has developed a set of shell scripts and configuration templates to make it easier to deploy a (Docker based) Tangle with the architecture described above. You can also customize the [default configuration files](https://github.com/iotaledger/one-click-tangle/blob/chrysalis/hornet-private-net/config) if, for instance, you want to enable extra [Hornet plugins](/hornet/how_tos/post_installation/#configuration-files).
 
 But now let us see how we can launch our Tangle via a "single-click". We have two options: through the [AWS Marketplace](https://aws.amazon.com/marketplace/pp/B095WQQTNG/) or through any [Docker-enabled machine](#one-click-private-tangle-on-any-docker-enabled-vm).
 
@@ -98,7 +98,7 @@ But now let us see how we can launch our Tangle via a "single-click". We have tw
 
 To materialize on AWS using the deployment architecture described above, go to the AWS Marketplace and install this [product](https://aws.amazon.com/marketplace/pp/B095WQQTNG/) and follow the [instructions](https://github.com/iotaledger/one-click-tangle/blob/chrysalis/hornet-private-net/README_AWS.md). That's it!
 
-Behind the scenes, the process will launch all the Docker containers (through docker-compose), create a key pair for the Coordinator, configure the Coordinator public key for the initial node, generate an initial IOTA Address holding all IOTAs, the identity for our Nodes, etc., meaning our [deployment architecture](#mvp-deployment-architecture-of-a-private-tangle) and all the steps described [here](https://wiki.iota.org/hornet/getting_started/private_tangle), but **fully automated**, with "one-click"!.
+Behind the scenes, the process will launch all the Docker containers (through docker-compose), create a key pair for the Coordinator, configure the Coordinator public key for the initial node, generate an initial IOTA Address holding all IOTAs, the identity for our Nodes, etc., meaning our [deployment architecture](#mvp-deployment-architecture-of-a-private-tangle) and all the steps described [here](https://github.com/iotaledger/hornet/tree/production/private_tangle), but **fully automated**, with "one-click"!.
 
 Below are the parameters of this "one-click" installation (further details can be found at [here](https://github.com/iotaledger/one-click-tangle/tree/chrysalis/hornet-private-net/config)):
 
@@ -150,7 +150,7 @@ To start your Tangle through the command line:
 
 You can optionally pass the amount of time (in seconds) to wait for the Coordinator bootstrap step. This step enables the Coordinator to bootstrap by emitting its first milestone.
 
-Behind the scenes, our process will create the identity for the Coordinator, the keys that will be used for signing milestones, an initial IOTA Address holding all IOTAs, the identity of our Nodes, etc meaning all the steps described [here](https://wiki.iota.org/hornet/getting_started/private_tangle), but fully automated.
+Behind the scenes, our process will create the identity for the Coordinator, the keys that will be used for signing milestones, an initial IOTA Address holding all IOTAs, the identity of our Nodes, etc meaning all the steps described [here](https://github.com/iotaledger/hornet/tree/production/private_tangle), but fully automated.
 
 After the process finishes, you should see the following docker containers up and running:
 
@@ -247,7 +247,7 @@ After executing the commands described above, a new Docker container (named `my-
 
 :::note
 
-In case you want to spin a node from a different machine (or base folder), you would need to manually pass those parameters, including a [multiaddr](https://wiki.iota.org/hornet/post_installation/peering#addressing-peer-neighbors) peer address of a node to peer with (for instance `node1`) you want to peer with, as explained [here](https://github.com/iotaledger/one-click-tangle/tree/chrysalis/hornet-private-net/extra-nodes).
+In case you want to spin a node from a different machine (or base folder), you would need to manually pass those parameters, including a [multiaddr](/hornet/references/peering) peer address of a node to peer with (for instance `node1`) you want to peer with, as explained [here](https://github.com/iotaledger/one-click-tangle/tree/chrysalis/hornet-private-net/extra-nodes).
 
 :::
 
diff --git a/docs/build/introduction-docs/chrysalis/docs/reference/details.md b/docs/build/introduction-docs/chrysalis/docs/reference/details.md
index 7b6f93e9033..c2cfbac3f42 100644
--- a/docs/build/introduction-docs/chrysalis/docs/reference/details.md
+++ b/docs/build/introduction-docs/chrysalis/docs/reference/details.md
@@ -55,9 +55,9 @@ For further reference, please see our [Protocol-rfc#0020 - Bech32 Address Format
 
 ### Seed
 
-With the updated [wallet library](https://wiki.iota.org/wallet.rs/welcome), developers do not need to use a self-generated seed. By default, the seed is created and stored in Stronghold, our in-house built security enclave. It is not possible to extract the seed from Stronghold for security purposes. Stronghold uses encrypted snapshots that can easily be backed up and securely shared between devices. These snapshots are then further secured with a password.
+With the updated [wallet library](/wallet.rs/welcome), developers do not need to use a self-generated seed. By default, the seed is created and stored in Stronghold, our in-house built security enclave. It is not possible to extract the seed from Stronghold for security purposes. Stronghold uses encrypted snapshots that can easily be backed up and securely shared between devices. These snapshots are then further secured with a password.
 
-More information about IOTA Wallet Library is available on the [Wallet docs page](https://wiki.iota.org/wallet.rs/welcome) or in the [Exchange guide](../how_tos/exchange.md), which is mainly focuses on value transactions.
+More information about IOTA Wallet Library is available on the [Wallet docs page](/wallet.rs/welcome) or in the [Exchange guide](../how_tos/exchange.md), which is mainly focuses on value transactions.
 
 :::note
 
@@ -67,7 +67,7 @@ It is highly recommended you do NOT use online seed generators at all. The seed
 
 A root of the `Ed25519` signature scheme is a `32-byte (256-bit)` uniformly randomly generated seed based on which all private keys and corresponding addresses are generated. A seed may be represented by a string of 64 characters using `[0-9a-f]` alphabet (32 bytes encoded in hexadecimal).
 
-The seed can be, for example, generated using the SHA256 algorithm on some random input generated by cryptographically secure pseudo-random generator, such as [os.urandom()](https://wiki.iota.org/iota.rs/libraries/python/examples#generating-seed-and-addresses).
+The seed can be, for example, generated using the SHA256 algorithm on some random input generated by cryptographically secure pseudo-random generator, such as [os.urandom()](/iota.rs/examples/generate_seed/?language=python).
 
 Seed examples (a single seed per line):
 
@@ -78,7 +78,7 @@ e94346bce41402155ef120e2525fad2d0bf30b10a89e4b93fd8471df1e6a0981
 ...
 ```
 
-> In modern wallet implementations, such as our [wallet.rs library](https://wiki.iota.org/wallet.rs/welcome) and [firefly wallet](https://github.com/iotaledger/firefly), the seed is usually generated from a `seed mnemonic` (`seed phrase`), using the [BIP39 standard](https://en.bitcoin.it/wiki/BIP_0039), for better memorization or to be stored by humans. It is based on a randomly generated list of english words and is later used to generate the seed. Either way, the seed is a root for all generated private keys and addresses.
+> In modern wallet implementations, such as our [wallet.rs library](/wallet.rs/welcome) and [firefly wallet](https://github.com/iotaledger/firefly), the seed is usually generated from a `seed mnemonic` (`seed phrase`), using the [BIP39 standard](https://en.bitcoin.it/wiki/BIP_0039), for better memorization or to be stored by humans. It is based on a randomly generated list of english words and is later used to generate the seed. Either way, the seed is a root for all generated private keys and addresses.
 
 For further reference, please see the [Protocol-rfc#0010 - Mnemonic Seed](https://github.com/iotaledger/tips/blob/main/tips/TIP-0010/tip-0010.md) page.
 
@@ -112,7 +112,7 @@ And there are a few additional things to note:
 
 :::note
 
-Having many different accounts may have a negative impact on performance while in the [account discovery](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#account-discovery) phase. So, if you are after using multiple, different accounts then you may be interested in our stateful library [wallet.rs](https://wiki.iota.org/wallet.rs/welcome) that incorporates all business logic needed to efficiently manage independent accounts. Additionally, our [exchange guide](../how_tos/exchange.md) provides some useful tips on how different accounts may be leveraged.
+Having many different accounts may have a negative impact on performance while in the [account discovery](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#account-discovery) phase. So, if you are after using multiple, different accounts then you may be interested in our stateful library [wallet.rs](/wallet.rs/welcome) that incorporates all business logic needed to efficiently manage independent accounts. Additionally, our [exchange guide](../how_tos/exchange.md) provides some useful tips on how different accounts may be leveraged.
 
 :::
 
diff --git a/docs/build/introduction-docs/stardust/docs/explanations/libraries/client.md b/docs/build/introduction-docs/stardust/docs/explanations/libraries/client.md
index 9f395e40b5a..e6f97f683a3 100644
--- a/docs/build/introduction-docs/stardust/docs/explanations/libraries/client.md
+++ b/docs/build/introduction-docs/stardust/docs/explanations/libraries/client.md
@@ -17,7 +17,7 @@ keywords:
 
 :::warning Deprecated
 
-The IOTA client libraries have been deprecated and replaced by the [IOTA SDK](https://wiki.iota.org/shimmer/iota-sdk/welcome).
+The IOTA client libraries have been deprecated and replaced by the [IOTA SDK](/iota-sdk/welcome).
 
 :::
 
@@ -32,38 +32,31 @@ However, if you want to process value transfers, you should use our stateful [wa
 
 ## Rust
 
-- [Getting Started](https://wiki.iota.org/iota.rs/develop/libraries/rust/getting_started) - Getting Started with Rust and the IOTA Client Library.
-- [Examples](https://wiki.iota.org/iota.rs/develop/libraries/rust/examples) - Find starting points or inspiration in the examples.
+- [Getting Started](/iota.rs/2.0.1-rc.7/getting_started/rust) - Getting Started with Rust and the IOTA Client Library.
+- [Examples](/iota.rs/2.0.1-rc.7/how_tos/run_how_tos?language=rust) - Find starting points or inspiration in the examples.
 - [Repository](https://github.com/iotaledger/iota.rs/tree/develop) - Browse through the code and learn what's happening behind the scenes. Pull requests are very welcome!
-- [API Documentation](https://wiki.iota.org/iota.rs/develop/libraries/rust/api_reference) - The IOTA Client Library Rust API Documentation.
+- [API Documentation](/iota.rs/2.0.1-rc.7/libraries/rust/api_reference) - The IOTA Client Library Rust API Documentation.
 
 ## Node.js
 
-- [Getting Started](https://wiki.iota.org/iota.rs/develop/libraries/nodejs/getting_started) - Getting Started with Node.js and the IOTA Client Library.
-- [Examples](https://wiki.iota.org/iota.rs/develop/libraries/nodejs/examples) - Find starting points or inspiration in the examples.
+- [Getting Started](/iota.rs/2.0.1-rc.7/getting_started/nodejs) - Getting Started with Node.js and the IOTA Client Library.
+- [Examples](/iota.rs/2.0.1-rc.7/how_tos/run_how_tos?language=typescript-node) - Find starting points or inspiration in the examples.
 - [Repository](https://github.com/iotaledger/iota.rs/tree/develop) - Browse through the code and learn what's happening behind the scenes. Pull requests are very welcome!
-- [API Documentation](https://wiki.iota.org/iota.rs/develop/libraries/nodejs/api_reference) - The IOTA Client Library Node.js API Documentation.
+- [API Documentation](/iota.rs/2.0.1-rc.7/libraries/nodejs/references/api_ref) - The IOTA Client Library Node.js API Documentation.
 
 ## Python
 
-- [Getting Started](https://wiki.iota.org/iota.rs/develop/libraries/python/getting_started) - Getting Started with Python and the IOTA Client Library.
-- [Examples](https://wiki.iota.org/iota.rs/develop/libraries/python/examples) - Find starting points or inspiration in the examples.
+- [Getting Started](/iota.rs/2.0.1-rc.7/getting_started/python) - Getting Started with Python and the IOTA Client Library.
+- [Examples](/iota.rs/2.0.1-rc.7/how_tos/run_how_tos?language=python) - Find starting points or inspiration in the examples.
 - [Repository](https://github.com/iotaledger/iota.rs/tree/develop/bindings/python) - Browse through the code and learn what's happening behind the scenes. Pull requests are very welcome!
-- [API Documentation](https://wiki.iota.org/iota.rs/develop/libraries/python/api_reference) - The IOTA Client Library Python API Documentation.
+- [API Documentation](/iota.rs/2.0.1-rc.7/libraries/python/references/iota_client/client) - The IOTA Client Library Python API Documentation.
 
 ## Java
 
-- [Getting Started](https://wiki.iota.org/iota.rs/develop/libraries/java/getting_started) - Getting Started with Java and the IOTA Client Library.
-- [Examples](https://wiki.iota.org/iota.rs/develop/libraries/java/examples) - Find starting points or inspiration in the examples.
+- [Getting Started](/iota.rs/2.0.1-rc.7/getting_started/java) - Getting Started with Java and the IOTA Client Library.
+- [Examples](/iota.rs/2.0.1-rc.7/how_tos/run_how_tos?language=java) - Find starting points or inspiration in the examples.
 - [Repository](https://github.com/iotaledger/iota.rs/tree/develop/bindings/java) - Browse through the code and learn what's happening behind the scenes. Pull requests are very welcome!
-- [API Documentation](https://wiki.iota.org/iota.rs/develop/libraries/java/api_reference) - The IOTA Client Library Java API Documentation.
-
-## Wasm
-
-- [Getting Started](https://wiki.iota.org/iota.rs/develop/libraries/wasm/getting_started) - Getting Started with Wasm and the IOTA Client Library.
-- [Examples](https://wiki.iota.org/iota.rs/develop/libraries/wasm/examples) - Find starting points or inspiration in the examples.
-- [Repository](https://github.com/iotaledger/iota.rs/tree/develop/bindings/wasm) - Browse through the code and learn what's happening behind the scenes. Pull requests are very welcome!
-- [API Documentation](https://wiki.iota.org/iota.rs/develop/libraries/wasm/api_reference) - The IOTA Client Library Wasm API Documentation.
+- [API Documentation](/iota.rs/2.0.1-rc.7/libraries/java/api_reference) - The IOTA Client Library Java API Documentation.
 
 ## C
 
diff --git a/docs/build/introduction-docs/stardust/docs/explanations/libraries/overview.md b/docs/build/introduction-docs/stardust/docs/explanations/libraries/overview.md
index a6fceb0e8ef..4151538f7f7 100644
--- a/docs/build/introduction-docs/stardust/docs/explanations/libraries/overview.md
+++ b/docs/build/introduction-docs/stardust/docs/explanations/libraries/overview.md
@@ -16,7 +16,7 @@ keywords:
 
 :::warning Deprecated
 
-The IOTA client libraries have been deprecated and replaced by the [IOTA SDK](https://wiki.iota.org/shimmer/iota-sdk/welcome).
+The IOTA client libraries have been deprecated and replaced by the [IOTA SDK](/iota-sdk/welcome).
 
 :::
 
@@ -24,10 +24,10 @@ The IOTA client libraries have been deprecated and replaced by the [IOTA SDK](ht
 
 The official IOTA libraries serve as `one-source-code-of-truth` to IOTA users and provide binding to other programming languages. Below is a list of the IOTA libraries. You can also check out the [IOTA client libraries blog post](https://blog.iota.org/the-new-iota-client-libraries-harder-better-faster-stronger/), to learn about the libraries' core principles.
 
-- [IOTA SDK](https://wiki.iota.org/shimmer/iota-sdk/welcome/): The IOTA SDK replaces `iota.rs`, `iota.js` and `wallet.rs` with a convenient development kit, written
-  in [Rust](https://wiki.iota.org/shimmer/iota-sdk/getting-started/rust/), with bindings for
-  [Node.js](https://wiki.iota.org/shimmer/iota-sdk/getting-started/nodejs/),
-  [Python](https://wiki.iota.org/shimmer/iota-sdk/getting-started/python/), and [Wasm](https://wiki.iota.org/shimmer/iota-sdk/getting-started/wasm/).
+- [IOTA SDK](/iota-sdk/welcome): The IOTA SDK replaces `iota.rs`, `iota.js` and `wallet.rs` with a convenient development kit, written
+  in [Rust](/iota-sdk/getting-started/rust), with bindings for
+  [Node.js](/iota-sdk/getting-started/nodejs),
+  [Python](/iota-sdk/getting-started/python), and [Wasm](/iota-sdk/getting-started/wasm).
 - [iota.go](https://github.com/iotaledger/iota.go/tree/v3): an IOTA client library in Golang.
 - [iota.c](https://github.com/iotaledger/iota.c/tree/develop): a special-purpose library in C for embedded devices (with microcontrollers) covering a basic features of `client-lib` or `wallet-lib.`
 
diff --git a/docs/build/introduction-docs/stardust/docs/explanations/libraries/wallet.md b/docs/build/introduction-docs/stardust/docs/explanations/libraries/wallet.md
index c49c6e7ca4f..1f4a4407c8d 100644
--- a/docs/build/introduction-docs/stardust/docs/explanations/libraries/wallet.md
+++ b/docs/build/introduction-docs/stardust/docs/explanations/libraries/wallet.md
@@ -15,37 +15,37 @@ keywords:
 
 :::warning Deprecated
 
-The IOTA client libraries have been deprecated and replaced by the [IOTA SDK](https://wiki.iota.org/shimmer/iota-sdk/welcome).
+The IOTA client libraries have been deprecated and replaced by the [IOTA SDK](/iota-sdk/welcome).
 
 :::
 
 The wallet library is a stateful library for developers; essentially, it's a programmable wallet. However, if you use IOTA or Shimmer to transfer tokens, you should use this library as its stateful design supports the handling and monitoring of multiple accounts and addresses.
 
-It also supports the [Stronghold.rs](https://github.com/iotaledger/stronghold.rs) enclave, incorporating the best security practices in one package. You can read more about the [IOTA Wallet Library documentation in our wiki](https://wiki.iota.org/develop/wallet.rs/welcome).
+It also supports the [Stronghold.rs](https://github.com/iotaledger/stronghold.rs) enclave, incorporating the best security practices in one package. You can read more about the [IOTA Wallet Library documentation in our wiki](/wallet.rs/1.0.0-rc.6/welcome).
 
 ## Rust
 
 ---
 
-- [Getting Started](https://wiki.iota.org/wallet.rs/develop/libraries/rust/getting_started) - Getting Started with Rust and the IOTA Wallet Library.
-- [Examples](https://wiki.iota.org/wallet.rs/develop/libraries/rust/examples) - Find starting points or inspiration in the examples.
+- [Getting Started](/wallet.rs/1.0.0-rc.6/getting_started/rust) - Getting Started with Rust and the IOTA Wallet Library.
+- [Examples](/wallet.rs/1.0.0-rc.6/how_tos/run_how_tos?language=rust) - Find starting points or inspiration in the examples.
 - [Repository](https://github.com/iotaledger/wallet.rs/tree/develop) - Browse through the code and learn what's happening behind the scenes. Pull requests are very welcome!
-- [API Documentation](https://wiki.iota.org/wallet.rs/develop/libraries/rust/api_reference) - The IOTA Wallet Library Rust API Documentation.
+- [API Documentation](/wallet.rs/1.0.0-rc.6/references/rust_api_reference) - The IOTA Wallet Library Rust API Documentation.
 
 ## Node.js
 
 ---
 
-- [Getting Started](https://wiki.iota.org/wallet.rs/develop/libraries/nodejs/getting_started) - Getting Started with Node.js and the IOTA Wallet Library.
-- [Examples](https://wiki.iota.org/wallet.rs/develop/libraries/nodejs/examples) - Find starting points or inspiration in the examples.
+- [Getting Started](/wallet.rs/1.0.0-rc.6/getting_started/nodejs) - Getting Started with Node.js and the IOTA Wallet Library.
+- [Examples](/wallet.rs/1.0.0-rc.6/how_tos/run_how_tos?language=typescript-node) - Find starting points or inspiration in the examples.
 - [Repository](https://github.com/iotaledger/wallet.rs/tree/develop/bindings/nodejs) - Browse through the code and learn what's happening behind the scenes. Pull requests are very welcome!
-- [API Documentation](https://wiki.iota.org/wallet.rs/develop/libraries/nodejs/api_reference) - The IOTA Wallet Library Node.js API Documentation.
+- [API Documentation](/wallet.rs/1.0.0-rc.6/references/nodejs/api_ref) - The IOTA Wallet Library Node.js API Documentation.
 
 ## Python
 
 ---
 
-- [Getting Started](https://wiki.iota.org/wallet.rs/develop/libraries/python/getting_started) - Getting Started with Python and the IOTA Wallet Library.
-- [Examples](https://wiki.iota.org/wallet.rs/develop/libraries/python/examples) - Find starting points or inspiration in the examples.
+- [Getting Started](/wallet.rs/1.0.0-rc.6/getting_started/python) - Getting Started with Python and the IOTA Wallet Library.
+- [Examples](/wallet.rs/1.0.0-rc.6/how_tos/run_how_tos?language=python) - Find starting points or inspiration in the examples.
 - [Repository](https://github.com/iotaledger/wallet.rs/tree/develop/bindings/python) - Browse through the code and learn what's happening behind the scenes. Pull requests are very welcome!
-- [API Documentation](https://wiki.iota.org/wallet.rs/develop/libraries/python/api_reference) - The IOTA Wallet Library Python API Documentation.
+- [API Documentation](/wallet.rs/1.0.0-rc.6/references/python/iota_wallet/account) - The IOTA Wallet Library Python API Documentation.
diff --git a/docs/build/introduction-docs/stardust/docs/explanations/node_software.md b/docs/build/introduction-docs/stardust/docs/explanations/node_software.md
index 6b472e0f607..0eba97a4802 100644
--- a/docs/build/introduction-docs/stardust/docs/explanations/node_software.md
+++ b/docs/build/introduction-docs/stardust/docs/explanations/node_software.md
@@ -20,7 +20,7 @@ performant implementation, furthermore its [IOTA Node Extension (INX)](https://T
 for Stardust eases the development of application specific node extensions.
 
 - [Official GitHub Repository](https://github.com/iotaledger/hornet)
-- [Documentation](https://wiki.iota.org/hornet/develop/welcome)
+- [Documentation](/hornet/2.0.0-rc.6/welcome)
 
 ## Node API Specification
 
diff --git a/docs/build/introduction-docs/stardust/docs/explanations/what_is_stardust/what_is_stardust.md b/docs/build/introduction-docs/stardust/docs/explanations/what_is_stardust/what_is_stardust.md
index 3941353bbee..dfe3d56f5bd 100644
--- a/docs/build/introduction-docs/stardust/docs/explanations/what_is_stardust/what_is_stardust.md
+++ b/docs/build/introduction-docs/stardust/docs/explanations/what_is_stardust/what_is_stardust.md
@@ -15,7 +15,7 @@ image: /img/logo/preview.png
 The previous IOTA protocol, Chrysalis, was optimized for a single application: sending digital money from A to B.
 The upcoming Stardust upgrade introduces computation and utility to the ledger:
 
-- Making IOTA an **infrastructure and settlement layer** for [second-layer smart contract chains](https://wiki.iota.org/smart-contracts/overview) using [IOTA Smart Contracts (ISC)](#isc).
+- Making IOTA an **infrastructure and settlement layer** for [second-layer smart contract chains](/smart-contracts/overview) using [IOTA Smart Contracts (ISC)](#isc).
 - Transforming IOTA into a **multi-asset ledger** with custom, user-defined tokens using the new [tokenization framework](#tokenization-framework).
 
 ## Tokenization Framework
@@ -54,11 +54,11 @@ ISC can be deployed as multiple Layer 2 (L2) chains, unlike many other projects
 
 ### Advantages
 
-- [L1 is not congested with smart contracts](https://wiki.iota.org/shimmer/smart-contracts/guide/core_concepts/smart-contracts/#scalable-smart-contracts).
+- [L1 is not congested with smart contracts](/learn/smart-contracts/core_concepts/smart-contracts#scalable-smart-contracts).
 - Since L1 is not limited by the speed of the smart contract VM, transactions per second (TPS) increase significantly.
 - No maximal extractable value (MEV). No front-running or sandwich attacks, resulting in a “fairer” DeFi environment. A set fee and randomization of transactions are included in blocks, making MEV impossible.
 - Native randomness beacon (random number generator, or RNG). This is freely available to all dApps, removing the need for expensive, trusted third-party RNGs.
-- L1 smart contracts are complex on a [DAG](https://wiki.iota.org/shimmer/learn/tangle/) as the order of events is less apparent than on a regular blockchain (where there is no parallel execution).
+- L1 smart contracts are complex on a [DAG](/get-started/introduction/iota/introduction#the-tangle) as the order of events is less apparent than on a regular blockchain (where there is no parallel execution).
 - We have designed a system where L2 chains can interact using the IOTA L1. Assets can be transferred cross-chain via Layer 1 without collateralized bridges. This is a significant advantage of ISC compared to other L2 solutions and is comparable to the IBC system on Cosmos.
 - ISC is horizontally scalable. When one SC chain becomes saturated, you can easily spin up a second chain to handle the additional throughput.
 - Every L2 chain can behave as a sovereign ecosystem and be fully customized, which is very appealing to many projects. Recent examples include DyDx and Dogechain, both building sovereign chains on Cosmos.
diff --git a/docs/build/introduction-docs/stardust/docs/welcome.md b/docs/build/introduction-docs/stardust/docs/welcome.md
index c023555f0e2..9a209225fbd 100644
--- a/docs/build/introduction-docs/stardust/docs/welcome.md
+++ b/docs/build/introduction-docs/stardust/docs/welcome.md
@@ -9,7 +9,7 @@ image: /img/logo/preview.png
 
 # Welcome
 
-Stardust protocol is the successor to IOTA 1.5, also known as [Chrysalis](https://wiki.iota.org/chrysalis-docs/welcome), that transforms IOTA into a multi-asset ledger and enables the operation of [IOTA Smart Contracts](https://wiki.iota.org/smart-contracts/overview). This page outlines the new concepts
+Stardust protocol is the successor to IOTA 1.5, also known as [Chrysalis](/introduction/welcome), that transforms IOTA into a multi-asset ledger and enables the operation of [IOTA Smart Contracts](/smart-contracts/overview). This page outlines the new concepts
 and differences compared to Chrysalis, furthermore gives an overview of different components of the IOTA technology stack.
 
 Stardust debuts on [Shimmer](https://shimmer.network/), the new staging network for IOTA, before being fully supported on the IOTA Mainnet.
diff --git a/docs/build/iota-sdk/1.0.0/docs/_admonitions/_warning-password-storage.md b/docs/build/iota-sdk/1.0.0/docs/_admonitions/_warning-password-storage.md
index 7a168cf98b4..bd0a57dcebe 100644
--- a/docs/build/iota-sdk/1.0.0/docs/_admonitions/_warning-password-storage.md
+++ b/docs/build/iota-sdk/1.0.0/docs/_admonitions/_warning-password-storage.md
@@ -1,7 +1,7 @@
 :::warning Safe Password Storage
 
 In a production setup, do not store passwords in the host's environment variables or in the source code. See
-our [backup and security recommendations](https://wiki.iota.org/shimmer/introduction/how_tos/backup_security/) for
+our [backup and security recommendations](/introduction/how_tos/backup_security) for
 production setups.
 
 :::
diff --git a/docs/build/iota-sdk/1.0.0/docs/_admonitions/_warning-unlock-conditions.md b/docs/build/iota-sdk/1.0.0/docs/_admonitions/_warning-unlock-conditions.md
index 98b6c8acde7..ebb8cbd6df6 100644
--- a/docs/build/iota-sdk/1.0.0/docs/_admonitions/_warning-unlock-conditions.md
+++ b/docs/build/iota-sdk/1.0.0/docs/_admonitions/_warning-unlock-conditions.md
@@ -1,7 +1,8 @@
 :::warning Unlock Conditions
 
-Outputs may have multiple [UnlockConditions](https://wiki.iota.org/shimmer/tips/tips/TIP-0018/#unlock-conditions), which may require [returning some or all of the transferred amount](https://wiki.iota.org/shimmer/tips/tips/TIP-0018/#storage-deposit-return-unlock-condition). The outputs could also [expire if not claimed in time](https://wiki.iota.org/shimmer/tips/tips/TIP-0018/#expiration-unlock-condition) or may not be [unlockable for a predefined period](https://wiki.iota.org/shimmer/tips/tips/TIP-0018/#timelock-unlock-condition).
-To get outputs with only the [`AddressUnlockCondition`](https://wiki.iota.org/shimmer/tips/tips/TIP-0018/#address-unlock-condition), you should synchronize with the option `syncOnlyMostBasicOutputs: true`.
+Outputs may have multiple [UnlockConditions](/tips/tips/TIP-0018#unlock-conditions), which may require [returning some or all of the transferred amount](/tips/tips/TIP-0018#storage-deposit-return-unlock-condition). The outputs could also [expire if not claimed in time](/tips/tips/TIP-0018#expiration-unlock-condition), or may not be [unlockable for a predefined period](/tips/tips/TIP-0018#timelock-unlock-condition).
+
+To get outputs with only the [`AddressUnlockCondition`](/tips/tips/TIP-0018#address-unlock-condition), you should synchronize with the option `syncOnlyMostBasicOutputs: true`.
 
 If you are synchronizing outputs with other unlock conditions, you should check the unlock conditions carefully before crediting users any balance.
 
diff --git a/docs/build/iota-sdk/1.0.0/docs/how-tos/accounts-and-addresses/consolidate-outputs.mdx b/docs/build/iota-sdk/1.0.0/docs/how-tos/accounts-and-addresses/consolidate-outputs.mdx
index d0b05b68f76..a8b30ff96ab 100644
--- a/docs/build/iota-sdk/1.0.0/docs/how-tos/accounts-and-addresses/consolidate-outputs.mdx
+++ b/docs/build/iota-sdk/1.0.0/docs/how-tos/accounts-and-addresses/consolidate-outputs.mdx
@@ -13,7 +13,7 @@ keywords:
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-[UTXOs](https://wiki.iota.org/shimmer/tips/tips/TIP-0020.md#utxo) can accumulate over time as users perform transactions,
+[UTXOs](/tips/tips/TIP-0020#utxo) can accumulate over time as users perform transactions,
 resulting in a fragmented UTXO set with many small outputs. Consolidating these outputs allows you to reduce the overall
 number of UTXOs, which can improve transaction efficiency and reduce storage deposit fees.
 
diff --git a/docs/build/iota-sdk/1.0.0/docs/how-tos/accounts-and-addresses/create-account.mdx b/docs/build/iota-sdk/1.0.0/docs/how-tos/accounts-and-addresses/create-account.mdx
index 33c2e9da1d3..7dd28846608 100644
--- a/docs/build/iota-sdk/1.0.0/docs/how-tos/accounts-and-addresses/create-account.mdx
+++ b/docs/build/iota-sdk/1.0.0/docs/how-tos/accounts-and-addresses/create-account.mdx
@@ -30,7 +30,7 @@ assets, enabling users to send and receive transactions, and engage in various a
 <TabItem value="rust" label="Rust">
 
 1. Instantiate a [`Wallet`](https://docs.rs/iota-sdk/latest/iota_sdk/wallet/core/struct.Wallet.html) and use it to store
-   the [Stronghold](https://wiki.iota.org/stronghold.rs/welcome) mnemonic.
+   the [Stronghold](/stronghold.rs/welcome) mnemonic.
 
 <div className={'hide-code-block-extras'}>
 
@@ -56,7 +56,7 @@ https://github.com/iotaledger/iota-sdk/blob/develop/sdk/examples/how_tos/account
 <TabItem value="typescript-node" label="Typescript (Node.js)">
 
 1. Instantiate a [`Wallet`](../../references/nodejs/classes/Wallet.md) and use it to store the
-   [Stronghold](https://wiki.iota.org/stronghold.rs/welcome) mnemonic.
+   [Stronghold](/stronghold.rs/welcome) mnemonic.
 
 <div className={'hide-code-block-extras'}>
 
@@ -82,7 +82,7 @@ https://github.com/iotaledger/iota-sdk/blob/develop/bindings/nodejs/examples/how
 <TabItem value="python" label="Python">
 
 1. Instantiate a [`Wallet`](../../references/python/iota_sdk/wallet/wallet.md) and use it to store the
-   [Stronghold](https://wiki.iota.org/stronghold.rs/welcome) mnemonic.
+   [Stronghold](/stronghold.rs/welcome) mnemonic.
 
 <div className={'hide-code-block-extras'}>
 
diff --git a/docs/build/iota-sdk/1.0.0/docs/how-tos/advanced-transactions/advanced-transaction.mdx b/docs/build/iota-sdk/1.0.0/docs/how-tos/advanced-transactions/advanced-transaction.mdx
index f3ccff389ab..c7fc5897f07 100644
--- a/docs/build/iota-sdk/1.0.0/docs/how-tos/advanced-transactions/advanced-transaction.mdx
+++ b/docs/build/iota-sdk/1.0.0/docs/how-tos/advanced-transactions/advanced-transaction.mdx
@@ -31,7 +31,7 @@ The following example will:
 1. Instantiate a [`Wallet`](https://docs.rs/iota-sdk/latest/iota_sdk/wallet/core/struct.Wallet.html), get Alice's `Account` which was
    [created in the first guide](../accounts-and-addresses/create-account.mdx) and [sync it](../accounts-and-addresses/check-balance.mdx).
 2. Create a [`BasicOutput`](https://docs.rs/iota-sdk/latest/iota_sdk/types/block/output/basic/struct.BasicOutput.html)
-   that is [time-locked](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/unlock-conditions.md#timelock) for one
+   that is [time-locked](/learn/protocols/stardust/core-concepts/output-unlock-conditions#timelock) for one
    hour by calling the [`BasicOutputBuilder()`](https://docs.rs/iota-sdk/latest/iota_sdk/types/block/output/basic/struct.BasicOutputBuilder.html)
    function and passing the [`AddressUnlockCondition`](https://docs.rs/iota-sdk/latest/iota_sdk/types/block/output/unlock_condition/struct.AddressUnlockCondition.html) and
    the [`TimelockUnlockCondition`](https://docs.rs/iota-sdk/latest/iota_sdk/types/block/output/unlock_condition/struct.TimelockUnlockCondition.html) in as
@@ -77,7 +77,7 @@ The following example will:
 1. Instantiate a [`Wallet`](https://docs.rs/iota-sdk/latest/iota_sdk/wallet/core/struct.Wallet.html), get Alice's `Account` which was
    [created in the first guide](../accounts-and-addresses/create-account.mdx) and [sync it](../accounts-and-addresses/check-balance.mdx).
 2. Create a [`BasicOutput`](../../references/nodejs/classes/BasicOutput.md) that is
-   [time-locked](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/unlock-conditions.md#timelock) for one
+   [time-locked](/learn/protocols/stardust/core-concepts/output-unlock-conditions#timelock) for one
    hour by calling the [`Client.buildBasicOutput()`](../../references/nodejs/classes/Client.md#buildbasicoutput)
    function and passing the [`AddressUnlockCondition`](../../references/nodejs/classes/AddressUnlockCondition.md) and
    the [`TimelockUnlockCondition`](../../references/nodejs/classes/TimelockUnlockCondition.md) in as
@@ -120,7 +120,7 @@ https://github.com/iotaledger/iota-sdk/blob/develop/bindings/nodejs/examples/how
 1. Instantiate a [`Wallet`](https://docs.rs/iota-sdk/latest/iota_sdk/wallet/core/struct.Wallet.html), get Alice's `Account` which was
    [created in the first guide](../accounts-and-addresses/create-account.mdx) and [sync it](../accounts-and-addresses/check-balance.mdx).
 2. Create a `BasicOutput` that is
-   [time-locked](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/unlock-conditions.md#timelock) for one
+   [time-locked](/learn/protocols/stardust/core-concepts/output-unlock-conditions#timelock) for one
    hour by calling the [`Client.build_basic_output()`](../../references/python/iota_sdk/client/client.md#build_basic_output)
    function and passing the [`AddressUnlockCondition`](../../references/python/iota_sdk/types/unlock_condition.md#addressunlockcondition-objects) and
    the [`TimelockUnlockCondition`](../../references/python/iota_sdk/types/unlock_condition.md#timelockunlockcondition-objects) in as
diff --git a/docs/build/iota-sdk/1.0.0/docs/how-tos/advanced-transactions/send-micro-transaction.mdx b/docs/build/iota-sdk/1.0.0/docs/how-tos/advanced-transactions/send-micro-transaction.mdx
index fb5bca03829..fd85300694c 100644
--- a/docs/build/iota-sdk/1.0.0/docs/how-tos/advanced-transactions/send-micro-transaction.mdx
+++ b/docs/build/iota-sdk/1.0.0/docs/how-tos/advanced-transactions/send-micro-transaction.mdx
@@ -18,7 +18,7 @@ import TabItem from '@theme/TabItem';
 import TipFaucet from '../../_admonitions/_tip-faucet.md';
 
 Any transaction with an amount that is below the minimum
-[storage deposit](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/storage-deposit.md) is considered a
+[storage deposit](/learn/protocols/stardust/core-concepts/storage-deposit) is considered a
 microtransaction.
 
 The IOTA SDK has a convenient
diff --git a/docs/build/iota-sdk/1.0.0/docs/how-tos/client/get-outputs.md b/docs/build/iota-sdk/1.0.0/docs/how-tos/client/get-outputs.md
index abff86acfb9..e77fba99a1d 100644
--- a/docs/build/iota-sdk/1.0.0/docs/how-tos/client/get-outputs.md
+++ b/docs/build/iota-sdk/1.0.0/docs/how-tos/client/get-outputs.md
@@ -16,7 +16,7 @@ import TabItem from "@theme/TabItem";
 import AccountClient from '../../\_admonitions/\_account-client.md'
 
 Querying outputs allows you to retrieve specific information about transactions or assets on
-the [Tangle](https://wiki.iota.org/shimmer/learn/tangle.md). You can verify the status of transactions, track the movement
+the [Tangle](/get-started/introduction/iota/introduction#the-tangle). You can verify the status of transactions, track the movement
 of assets, and gather relevant details such as transaction history, ownership, or other metadata. You can query for any
 output type using the following functions:
 
diff --git a/docs/build/iota-sdk/1.0.0/docs/how-tos/exchange-guide.mdx b/docs/build/iota-sdk/1.0.0/docs/how-tos/exchange-guide.mdx
index d078f98d83a..84180c252ca 100644
--- a/docs/build/iota-sdk/1.0.0/docs/how-tos/exchange-guide.mdx
+++ b/docs/build/iota-sdk/1.0.0/docs/how-tos/exchange-guide.mdx
@@ -31,7 +31,7 @@ Features of the IOTA SDK:
 :::note Stardust Update
 
 The Stardust update is a set of protocol changes that were first deployed to the Shimmer network.
-See [What is Stardust?](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust.md)
+See [What is Stardust?](/learn/protocols/stardust/introduction)
 for an overview of its features or [TIPs](https://github.com/iotaledger/tips)
 flagged `Stardust` for a deeper understanding of the protocol changes.
 
@@ -41,7 +41,7 @@ flagged `Stardust` for a deeper understanding of the protocol changes.
 
 The IOTA SDK is a stateful library which provides an API for developers to build value transaction applications.
 It offers abstractions to handle payments,
-and can optionally interact with [Stronghold](https://wiki.iota.org/stronghold.rs/getting_started) for seed handling,
+and can optionally interact with [Stronghold](/stronghold.rs/getting_started) for seed handling,
 seed storage, and state backup.
 
 You can use the following examples as a guide to implement the
@@ -78,16 +78,16 @@ Most of the APIs are the same and the changes are fairly minimal, here are some
 
 - The npm package changes from [`@iota/wallet`](https://www.npmjs.com/package/@iota/wallet) to
   [`@iota/sdk`](https://www.npmjs.com/package/@iota/sdk).
-- [`AccountManager`](https://wiki.iota.org/shimmer/wallet.rs/references/nodejs/classes/AccountManager.md)
+- [`AccountManager`](/wallet.rs/1.0.0-rc.6/references/nodejs/classes/AccountManager)
   becomes
   [`Wallet`](../references/nodejs/classes/Wallet.md).
-- [`manager.generateMnemonic()`](https://wiki.iota.org/shimmer/wallet.rs/references/nodejs/classes/AccountManager.md#generatemnemonic)
+- [`manager.generateMnemonic()`](/wallet.rs/1.0.0-rc.6/references/nodejs/classes/AccountManager#generatemnemonic)
   becomes
   [`Utils.generateMnemonic()`](../references/nodejs/classes/Utils.md#generatemnemonic).
-- [`AccountManager.generateAddress`](https://wiki.iota.org/shimmer/wallet.rs/references/nodejs/classes/AccountManager.md#generateaddress)
+- [`AccountManager.generateAddress`](/wallet.rs/1.0.0-rc.6/references/nodejs/classes/AccountManager#generateaddress)
   becomes
   [`Wallet.generateEd25519Addresses`](../references/nodejs/classes/Wallet.md#generateed25519address).
-- [`Account.sendAmount`](https://wiki.iota.org/shimmer/wallet.rs/references/nodejs/classes/Account.md) becomes
+- [`Account.sendAmount`](/wallet.rs/1.0.0-rc.6/references/nodejs/classes/Account) becomes
   [`send`](../references/nodejs/classes/Account.md#send).
 - The callbacks to `listen` now provide a properly typed
   [`Event`](../references/nodejs/classes/Event.md).
@@ -96,13 +96,13 @@ Most of the APIs are the same and the changes are fairly minimal, here are some
 <TabItem value="python" label="Python">
 
 - The pip package changes from `iota-wallet` to [`iota-sdk`](https://pypi.org/project/iota-sdk.md).
-- [`wallet.generate_mnemonic()`](https://wiki.iota.org/shimmer/wallet.rs/references/python/iota_wallet/wallet.md#generate_mnemonic)
+- [`wallet.generate_mnemonic()`](/wallet.rs/1.0.0-rc.6/references/python/iota_wallet/wallet#generate_mnemonic)
   becomes
   [`utils.generate_mnemonic()`](../references/python/iota_sdk/utils.md#generate_mnemonic).
-- [`wallet.generate_address()`](https://wiki.iota.org/shimmer/wallet.rs/references/python/iota_wallet/wallet.md#generate_address)
+- [`wallet.generate_address()`](/wallet.rs/1.0.0-rc.6/references/python/iota_wallet/wallet#generate_address)
   becomes
   [`wallet.generate_ed25519_addresses()`](../references/python/iota_sdk/wallet/wallet.md#generate_ed25519_address).
-- [`account.send_amount`](https://wiki.iota.org/shimmer/wallet.rs/references/python/iota_wallet/account.md#send_amount)
+- [`account.send_amount`](/wallet.rs/1.0.0-rc.6/references/python/iota_wallet/account#send_amount)
   becomes
   [`account.send`](../references/python/iota_sdk/wallet/account.md#send).
 - The callbacks to `listen` now provide a properly typed
@@ -120,7 +120,7 @@ Most of the APIs are the same and the changes are fairly minimal, here are some
 First, you should install the components needed to use the IOTA SDK and the binding of your choice; it may vary a bit
 from language to language.
 
-You can read more about [backup and security in this guide](https://wiki.iota.org/shimmer/introduction/how_tos/backup_security).
+You can read more about [backup and security in this guide](/introduction/how_tos/backup_security).
 
 <Tabs groupId="language" queryString>
 
@@ -204,7 +204,7 @@ EXPLORER_URL="https://explorer.shimmer.network/testnet"
 ### 2. Generate a Mnemonic
 
 After you have created the `.env` file, you can initialize the `Wallet` instance with a secret manager
-([`Stronghold`](https://wiki.iota.org/stronghold.rs/welcome) by default) and client options.
+([`Stronghold`](/stronghold.rs/welcome) by default) and client options.
 
 By default, the Stronghold file will be called `wallet.stronghold`.
 It will store the seed (derived from the mnemonic) that serves as a cryptographic key from which all accounts and
@@ -219,9 +219,7 @@ complexities and makes transacting in a network very easy and convenient.
 
 :::warning Back up and Security
 
-Keep the `stronghold` password and the `stronghold` database on separate devices.
-See the [backup and security guide](https://wiki.iota.org/shimmer/introduction/how_tos/backup_security.md) for more
-information.
+It is best practice to keep the `stronghold` password and the `stronghold` database on separate devices.
 
 :::
 
@@ -537,7 +535,7 @@ You can use the following example to send tokens to an address.
 :::note Dust Protection
 
 When sending tokens,
-you should consider a [dust protection](https://wiki.iota.org/shimmer/tips/tips/TIP-0019) mechanism.
+you should consider a [dust protection](/tips/tips/TIP-0019) mechanism.
 
 :::
 
diff --git a/docs/build/iota-sdk/1.0.0/docs/how-tos/native-tokens/create.mdx b/docs/build/iota-sdk/1.0.0/docs/how-tos/native-tokens/create.mdx
index f1dd1d3880e..21ac9e2a479 100644
--- a/docs/build/iota-sdk/1.0.0/docs/how-tos/native-tokens/create.mdx
+++ b/docs/build/iota-sdk/1.0.0/docs/how-tos/native-tokens/create.mdx
@@ -16,10 +16,10 @@ import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 import TipFaucet from '../../_admonitions/_tip-faucet.md';
 
-The stardust update allows you to create your own [native tokens](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/tokenization#native-tokens)
+The stardust update allows you to create your own [native tokens](/introduction/stardust/explanations/what_is_stardust/tokenization#native-tokens)
 Native tokens are minted by a so-called Foundry. The Foundry allows you to specify a max supply once and change the circulating supply.
 
-You can also specify some custom metadata in the foundry output or follow a standard like [IRC30](https://wiki.iota.org/tips/tips/TIP-0030.md).
+You can also specify some custom metadata in the foundry output or follow a standard like [IRC30](/tips/tips/TIP-0030).
 To create a Foundry you need an Alias Output which owns it. This Alias Output only needs to be generated once and can own multiple foundries.
 
 <TipFaucet />
@@ -31,8 +31,8 @@ To create a Foundry you need an Alias Output which owns it. This Alias Output on
 
 1. Instantiate a [`Wallet`](https://docs.rs/iota-sdk/latest/iota_sdk/wallet/core/struct.Wallet.html), get Alice's `Account` which was
    [created in the first guide](../accounts-and-addresses/create-account.mdx) and [sync it](../accounts-and-addresses/check-balance.mdx).
-2. Check the account's balance for an [`Alias Output`](https://wiki.iota.org/shimmer/tips/tips/TIP-0018.md#alias-output)
-   it can use to create the [native tokens](https://wiki.iota.org/shimmer/tips/tips/TIP-0018.md#native-tokens-in-outputs).
+2. Check the account's balance for an [`Alias Output`](/tips/tips/TIP-0018#alias-output)
+   it can use to create the [native tokens](/tips/tips/TIP-0018#native-tokens-in-outputs).
    If the account doesn't have any, it will create one.
 
 <div className={'hide-code-block-extras'}>
@@ -69,8 +69,8 @@ https://github.com/iotaledger/iota-sdk/blob/develop/sdk/examples/how_tos/native_
 
 1. Instantiate a [`Wallet`](https://docs.rs/iota-sdk/latest/iota_sdk/wallet/core/struct.Wallet.html), get Alice's `Account` which was
    [created in the first guide](../accounts-and-addresses/create-account.mdx) and [sync it](../accounts-and-addresses/check-balance.mdx).
-2. Check the account's balance for an [`Alias Output`](https://wiki.iota.org/shimmer/tips/tips/TIP-0018.md#alias-output)
-   it can use to create the [native tokens](https://wiki.iota.org/shimmer/tips/tips/TIP-0018.md#native-tokens-in-outputs).
+2. Check the account's balance for an [`Alias Output`](/tips/tips/TIP-0018#alias-output)
+   it can use to create the [native tokens](/tips/tips/TIP-0018#native-tokens-in-outputs).
    If the account doesn't have any, it will create one.
 
 <div className={'hide-code-block-extras'}>
@@ -109,8 +109,8 @@ https://github.com/iotaledger/iota-sdk/blob/develop/bindings/nodejs/examples/how
 
 1. Instantiate a [`Wallet`](https://docs.rs/iota-sdk/latest/iota_sdk/wallet/core/struct.Wallet.html), get Alice's `Account` which was
    [created in the first guide](../accounts-and-addresses/create-account.mdx) and [sync it](../accounts-and-addresses/check-balance.mdx).
-2. Check the account's balance for an [`Alias Output`](https://wiki.iota.org/shimmer/tips/tips/TIP-0018.md#alias-output)
-   it can use to create the [native tokens](https://wiki.iota.org/shimmer/tips/tips/TIP-0018.md#native-tokens-in-outputs).
+2. Check the account's balance for an [`Alias Output`](/tips/tips/TIP-0018#alias-output)
+   it can use to create the [native tokens](/tips/tips/TIP-0018#native-tokens-in-outputs).
    If the account doesn't have any, it will create one.
 
 <div className={'hide-code-block-extras'}>
diff --git a/docs/build/iota-sdk/1.0.0/docs/how-tos/native-tokens/destroy-foundry.mdx b/docs/build/iota-sdk/1.0.0/docs/how-tos/native-tokens/destroy-foundry.mdx
index 6f8b205baf8..5f2d36bf494 100644
--- a/docs/build/iota-sdk/1.0.0/docs/how-tos/native-tokens/destroy-foundry.mdx
+++ b/docs/build/iota-sdk/1.0.0/docs/how-tos/native-tokens/destroy-foundry.mdx
@@ -18,7 +18,7 @@ import TabItem from '@theme/TabItem';
 import DestroyFoundry from '../../_admonitions/_destroy_foundry.md';
 
 If at any point you want to disable the production of your
-[native token](https://wiki.iota.org/shimmer/introduction/explanations/ledger/foundry), you should destroy the foundry.
+[native token](/introduction/stardust/explanations/ledger/foundry), you should destroy the foundry.
 However, you can only destroy a foundry output as long as its circulating native token supply is zero.
 
 <DestroyFoundry />
diff --git a/docs/build/iota-sdk/1.0.0/docs/how-tos/native-tokens/mint.mdx b/docs/build/iota-sdk/1.0.0/docs/how-tos/native-tokens/mint.mdx
index cba44ab298d..fccf506a77a 100644
--- a/docs/build/iota-sdk/1.0.0/docs/how-tos/native-tokens/mint.mdx
+++ b/docs/build/iota-sdk/1.0.0/docs/how-tos/native-tokens/mint.mdx
@@ -17,7 +17,7 @@ import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
 After you have [created](create.mdx) a
-[native token](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/tokenization#native-tokens),
+[native token](/introduction/stardust/explanations/what_is_stardust/tokenization#native-tokens),
 you may want to increase the circulating native token supply by minting more tokens.
 
 ## Example Code
diff --git a/docs/build/iota-sdk/1.0.0/docs/how-tos/native-tokens/send.mdx b/docs/build/iota-sdk/1.0.0/docs/how-tos/native-tokens/send.mdx
index c4114c09007..c9d1171b024 100644
--- a/docs/build/iota-sdk/1.0.0/docs/how-tos/native-tokens/send.mdx
+++ b/docs/build/iota-sdk/1.0.0/docs/how-tos/native-tokens/send.mdx
@@ -17,10 +17,10 @@ import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
 After you have [created](create.mdx) a
-[native token](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/tokenization#native-tokens),
+[native token](/introduction/stardust/explanations/what_is_stardust/tokenization#native-tokens),
 you can easily send it by calling the `Account.send_native_tokens(params, options)` function.
 
-As with any output, you can set [output unlock conditions](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/unlock_conditions).
+As with any output, you can set [output unlock conditions](/introduction/stardust/explanations/what_is_stardust/unlock_conditions).
 Keep in mind that if you set unlock conditions, whoever you send the native tokens to may need to
 claim them.
 
diff --git a/docs/build/iota-sdk/1.0.0/docs/how-tos/nfts/burn-nft.mdx b/docs/build/iota-sdk/1.0.0/docs/how-tos/nfts/burn-nft.mdx
index f42fd8543b5..e7ad9ba2483 100644
--- a/docs/build/iota-sdk/1.0.0/docs/how-tos/nfts/burn-nft.mdx
+++ b/docs/build/iota-sdk/1.0.0/docs/how-tos/nfts/burn-nft.mdx
@@ -14,8 +14,8 @@ keywords:
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-When you burn an [NFT](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/tokenization.md#non-fungible-tokens-nfts),
-you permanently remove it from the ledger state, rendering it unusable and nontransferable. The associated [storage deposit](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/storage-deposit.md) will automatically be returned to its original account.
+When you burn an [NFT](/learn/protocols/stardust/core-concepts/multi-asset-ledger#non-fungible-tokens-nfts),
+you permanently remove it from the ledger state, rendering it unusable and nontransferable. The associated [storage deposit](/learn/protocols/stardust/core-concepts/storage-deposit) will automatically be returned to its original account.
 
 :::warning irreversible
 
diff --git a/docs/build/iota-sdk/1.0.0/docs/how-tos/nfts/mint-nft.mdx b/docs/build/iota-sdk/1.0.0/docs/how-tos/nfts/mint-nft.mdx
index bf5bd04afa5..16100626354 100644
--- a/docs/build/iota-sdk/1.0.0/docs/how-tos/nfts/mint-nft.mdx
+++ b/docs/build/iota-sdk/1.0.0/docs/how-tos/nfts/mint-nft.mdx
@@ -14,13 +14,13 @@ keywords:
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-Minting an [NFT](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/tokenization.md#non-fungible-tokens-nfts)
-refers to creating a unique and indivisible digital asset on [the Tangle](https://wiki.iota.org/shimmer/learn/tangle.md).
+Minting an [NFT](/learn/protocols/stardust/core-concepts/multi-asset-ledger#non-fungible-tokens-nfts)
+refers to creating a unique and indivisible digital asset on [the Tangle](/get-started/introduction/iota/introduction#the-tangle).
 When you mint an NFT, you usually associate a digital file, such as artwork, music, or video, with a specific token on
 the Tangle, establishing its authenticity, ownership, and uniqueness. This is done by assigning
-[metadata](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/output-features.md#metadata)
+[metadata](/learn/protocols/stardust/core-concepts/output-features#metadata)
 to the NFT, including details about the creator
-(or [issuer](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/output-features.md#issuer)), the asset's
+(or [issuer](/learn/protocols/stardust/core-concepts/output-features#issuer)), the asset's
 description, and any additional information relevant to its value or characteristics.
 
 ## Example Code
@@ -42,8 +42,8 @@ https://github.com/iotaledger/iota-sdk/blob/develop/sdk/examples/how_tos/nfts/mi
 </div>
 
 3. Create a new [`MintNftParams`](https://docs.rs/iota-sdk/latest/iota_sdk/wallet/struct.MintNftParams.html) and set its
-   values. Note that these include setting the [sender](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/output-features.md#sender)
-   and the [issuer](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/output-features.md#issuer).
+   values. Note that these include setting the [sender](/learn/protocols/stardust/core-concepts/output-features#sender)
+   and the [issuer](/learn/protocols/stardust/core-concepts/output-features#issuer).
 
 <div className={'hide-code-block-extras'}>
 
@@ -102,8 +102,8 @@ https://github.com/iotaledger/iota-sdk/blob/develop/bindings/nodejs/examples/how
 </div>
 
 3. Create a new [`MintNftParams`](../../references/nodejs/interfaces/MintNftParams.md) and set its
-   values. Note that these include setting the [sender](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/output-features.md#sender)
-   and the [issuer](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/output-features.md#issuer).
+   values. Note that these include setting the [sender](/learn/protocols/stardust/core-concepts/output-features#sender)
+   and the [issuer](/learn/protocols/stardust/core-concepts/output-features#issuer).
 
 <div className={'hide-code-block-extras'}>
 
diff --git a/docs/build/iota-sdk/1.0.0/docs/how-tos/nfts/send-nft.mdx b/docs/build/iota-sdk/1.0.0/docs/how-tos/nfts/send-nft.mdx
index 2dbd7c29bec..4baded8031a 100644
--- a/docs/build/iota-sdk/1.0.0/docs/how-tos/nfts/send-nft.mdx
+++ b/docs/build/iota-sdk/1.0.0/docs/how-tos/nfts/send-nft.mdx
@@ -14,7 +14,7 @@ keywords:
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-Sending an [NFT](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/tokenization.md#non-fungible-tokens-nfts)
+Sending an [NFT](/learn/protocols/stardust/core-concepts/multi-asset-ledger#non-fungible-tokens-nfts)
 allows you to transfer ownership of the unique digital asset to another user. By sending an NFT you grant the new owner full control and possession of the token, including its
 associated collectible or token value and any other attributes it defines.
 
diff --git a/docs/build/iota-sdk/1.0.0/docs/how-tos/outputs/features.mdx b/docs/build/iota-sdk/1.0.0/docs/how-tos/outputs/features.mdx
index 7c18242940f..37cd91a56b6 100644
--- a/docs/build/iota-sdk/1.0.0/docs/how-tos/outputs/features.mdx
+++ b/docs/build/iota-sdk/1.0.0/docs/how-tos/outputs/features.mdx
@@ -16,11 +16,11 @@ import TabItem from '@theme/TabItem';
 import AccountClient from '../../_admonitions/_account-client.md';
 
 The Stardust protocol introduced
-[multiple new output features](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/output-features.md)
-that allow you to add [metadata](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/output-features.md#metadata),
-a [sender](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/output-features.md#sender)
-(or [issuer](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/output-features.md#issuer) in the case of
-[NFTs](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/tokenization.md#non-fungible-tokens-nfts)) or [tag](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust/output-features.md#tag) them by adding
+[multiple new output features](/learn/protocols/stardust/core-concepts/output-features)
+that allow you to add [metadata](/learn/protocols/stardust/core-concepts/output-features#metadata),
+a [sender](/learn/protocols/stardust/core-concepts/output-features#sender)
+(or [issuer](/learn/protocols/stardust/core-concepts/output-features#issuer) in the case of
+[NFTs](/learn/protocols/stardust/core-concepts/multi-asset-ledger#non-fungible-tokens-nfts)) or [tag](/learn/protocols/stardust/core-concepts/output-features#tag) them by adding
 some small indexation data to the output.
 
 <AccountClient />
@@ -28,7 +28,7 @@ some small indexation data to the output.
 :::info Output Features
 
 Different outputs can have different features. This table shows you which output has which features. You can find the
-output specs in [TIP-018](https://wiki.iota.org/tips/tips/TIP-0018)
+output specs in [TIP-018](/tips/tips/TIP-0018)
 
 | Output  | Sender | Metadata | Immutable Metadata | Tag | Immutable Issuer |
 | ------- | :----: | :------: | :----------------: | :-: | :--------------: |
diff --git a/docs/build/iota-sdk/1.0.0/docs/how-tos/outputs/unlock-conditions.mdx b/docs/build/iota-sdk/1.0.0/docs/how-tos/outputs/unlock-conditions.mdx
index cc419f66732..6c5f365dcd8 100644
--- a/docs/build/iota-sdk/1.0.0/docs/how-tos/outputs/unlock-conditions.mdx
+++ b/docs/build/iota-sdk/1.0.0/docs/how-tos/outputs/unlock-conditions.mdx
@@ -21,7 +21,7 @@ Outputs can have different unlock conditions. This guide explains how to add the
 
 :::info Output Unlock Conditions
 
-Different outputs can have different unlock conditions. This table shows you which output is compatible with which unlock condition. You can find the output specs in [TIP-018](https://wiki.iota.org/tips/tips/TIP-0018)
+Different outputs can have different unlock conditions. This table shows you which output is compatible with which unlock condition. You can find the output specs in [TIP-018](/tips/tips/TIP-0018)
 
 | Output  | Address | Storage Deposit Return | Timelock | Expiration | State Controller Address | Governor Address | Immutable Alias Address |
 | ------- | :-----: | :--------------------: | :------: | :--------: | :----------------------: | :--------------: | :---------------------: |
@@ -158,7 +158,7 @@ The following example will add the following [`unlockConditions`](../../referenc
 by passing them as [output parameters](../../references/nodejs/interfaces/BasicOutputBuilderParams.md#unlockconditions)
 when building the outputs:
 
-1. [`StorageDepositReturnUnlockCondition`](https://wiki.iota.org/next/iota-sdk/references/python/iota_sdk/types/unlock_condition.md#storagedepositreturnunlockcondition-objects).
+1. [`StorageDepositReturnUnlockCondition`](../../references/python/iota_sdk/types/unlock_condition.md#storagedepositreturnunlockcondition-objects).
 
 <div className={'hide-code-block-extras'}>
 
@@ -168,7 +168,7 @@ https://github.com/iotaledger/iota-sdk/blob/develop/bindings/python/examples/how
 
 </div>
 
-2. [`TimelockUnlockCondition`](https://wiki.iota.org/next/iota-sdk/references/python/iota_sdk/types/unlock_condition.md#timelockunlockcondition-objects).
+2. [`TimelockUnlockCondition`](../../references/python/iota_sdk/types/unlock_condition.md#timelockunlockcondition-objects).
 
 <div className={'hide-code-block-extras'}>
 
@@ -178,7 +178,7 @@ https://github.com/iotaledger/iota-sdk/blob/develop/bindings/python/examples/how
 
 </div>
 
-3. [`ExpirationUnlockCondition`](https://wiki.iota.org/next/iota-sdk/references/python/iota_sdk/types/unlock_condition.md#expirationunlockcondition-objects).
+3. [`ExpirationUnlockCondition`](../../references/python/iota_sdk/types/unlock_condition.md#expirationunlockcondition-objects).
 
 <div className={'hide-code-block-extras'}>
 
@@ -188,7 +188,7 @@ https://github.com/iotaledger/iota-sdk/blob/develop/bindings/python/examples/how
 
 </div>
 
-4. [`GovernorAddressUnlockCondition`](https://wiki.iota.org/next/iota-sdk/references/python/iota_sdk/types/unlock_condition.md#statecontrolleraddressunlockcondition-objects) and [`StateControllerAddressUnlockCondition`](https://wiki.iota.org/next/iota-sdk/references/python/iota_sdk/types/unlock_condition.md#governoraddressunlockcondition-objects).
+4. [`GovernorAddressUnlockCondition`](../../references/python/iota_sdk/types/unlock_condition.md#statecontrolleraddressunlockcondition-objects) and [`StateControllerAddressUnlockCondition`](../../references/python/iota_sdk/types/unlock_condition.md#governoraddressunlockcondition-objects).
 
 <div className={'hide-code-block-extras'}>
 
@@ -198,7 +198,7 @@ https://github.com/iotaledger/iota-sdk/blob/develop/bindings/python/examples/how
 
 </div>
 
-6. [`ImmutableAliasAddressUnlockCondition`](https://wiki.iota.org/next/iota-sdk/references/python/iota_sdk/types/unlock_condition.md#immutablealiasaddressunlockcondition-objects).
+6. [`ImmutableAliasAddressUnlockCondition`](../../references/python/iota_sdk/types/unlock_condition.md#immutablealiasaddressunlockcondition-objects).
 
 <div className={'hide-code-block-extras'}>
 
diff --git a/docs/build/iota-sdk/1.0.0/docs/welcome.md b/docs/build/iota-sdk/1.0.0/docs/welcome.md
index 49023aafc16..c48803580e1 100644
--- a/docs/build/iota-sdk/1.0.0/docs/welcome.md
+++ b/docs/build/iota-sdk/1.0.0/docs/welcome.md
@@ -21,7 +21,7 @@ keywords:
 ![IOTA SDK Overview](/img/banner/client_lib_overview.png)
 
 The IOTA SDK provides a convenient and efficient way to interact with nodes in the Shimmer
-and IOTA networks running the [Stardust protocol](https://wiki.iota.org/shimmer/develop/explanations/what-is-stardust).
+and IOTA networks running the [Stardust protocol](/learn/protocols/stardust/introduction).
 It consists of two main modules: `client` and `wallet`.
 
 The `wallet` module uses high-level functions that simplify everyday operations with a standardized interface for
@@ -51,15 +51,15 @@ programming pattern, so the Python binding uses named constructor arguments.
 Your application communicates directly with the IOTA SDK in Rust or through one of the language bindings. The IOTA SDK
 turns your requests into REST API calls and sends them to a node. The node, in turn, interacts with the rest of an
 IOTA network, which could be the
-[main operational network (mainnet)](https://wiki.iota.org/shimmer/develop/explanations/what-is-shimmer/networks/#shimmer-mainnet)
+[main operational network (mainnet)](/build/networks-endpoints#shimmer)
 or
-a [network for testing purposes (testnet)](https://wiki.iota.org/shimmer/develop/explanations/what-is-shimmer/networks/#public-testnet).
+a [network for testing purposes (testnet)](/build/networks-endpoints#public-testnet).
 
 !["An overview of the IOTA SDK layers."](/img/layered_overview.png 'An overview of the IOTA SDK layers.')
 
 ## Secure Secret Management
 
-You can use [Stronghold](https://wiki.iota.org/shimmer/stronghold.rs/welcome) for secure secret management. Stronghold
+You can use [Stronghold](/stronghold.rs/welcome) for secure secret management. Stronghold
 can store the encrypted seed at rest. It is not possible to extract the seed from Stronghold for security purposes.
 Stronghold uses encrypted snapshots that can easily be backed up and securely shared between devices. These snapshots
 are further secured with a password.
diff --git a/docs/build/iota.js/2.0.0-rc.1/admonitions/_enable_pow.md b/docs/build/iota.js/2.0.0-rc.1/admonitions/_enable_pow.md
index fa7645cf46c..d983624be29 100644
--- a/docs/build/iota.js/2.0.0-rc.1/admonitions/_enable_pow.md
+++ b/docs/build/iota.js/2.0.0-rc.1/admonitions/_enable_pow.md
@@ -2,6 +2,6 @@
 
 This example requires an API endpoint that has "Proof of Work" enabled.
 The [public Alphanet API](https://api.alphanet.iotaledger.net/) does not have this feature. To run the example, please
-choose an API which does, or [run your own Hornet node](https://wiki.iota.org/hornet/getting_started).
+choose an API which does, or [run your own Hornet node](/hornet/getting_started).
 
 :::
diff --git a/docs/build/iota.js/2.0.0-rc.1/docs/how_tos/transaction.mdx b/docs/build/iota.js/2.0.0-rc.1/docs/how_tos/transaction.mdx
index 24f03b75c55..1df64e4deff 100644
--- a/docs/build/iota.js/2.0.0-rc.1/docs/how_tos/transaction.mdx
+++ b/docs/build/iota.js/2.0.0-rc.1/docs/how_tos/transaction.mdx
@@ -41,7 +41,7 @@ Once you have [generated a seed](#generate-a-seed), you can create a wallet usin
 ### Request Funds
 
 Before you can send the transaction, you will need to request funds. If you are on the alphanet, you can request test
-funds from the [faucet](https://faucet.alphanet.iotaledger.net/api/enqueue). If you are running a [private tangle](https://wiki.iota.org/hornet/how_tos/private_tangle),
+funds from the [faucet](https://faucet.alphanet.iotaledger.net/api/enqueue). If you are running a [private tangle](/hornet/2.0.0-rc.6/how_tos/private_tangle),
 you can use the '/enqueue' endpoint.
 
 ## Send the Transaction
diff --git a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/alias-transactions/01-introduction.md b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/alias-transactions/01-introduction.md
index 3f89a0653f5..35263618a8c 100644
--- a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/alias-transactions/01-introduction.md
+++ b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/alias-transactions/01-introduction.md
@@ -16,24 +16,24 @@ keywords:
 
 # Stardust for iota.js: Alias Transactions
 
-This tutorial will get you acquainted with the structure and functionality of [Alias Transactions](https://wiki.iota.org/shimmer/introduction/explanations/ledger/alias) in
-IOTA's [Stardust protocol](https://wiki.iota.org/shimmer/introduction/welcome) in
+This tutorial will get you acquainted with the structure and functionality of [Alias Transactions](/introduction/stardust/explanations/ledger/alias) in
+IOTA's [Stardust protocol](/introduction/stardust/welcome) in
 the [Shimmer network](https://shimmer.network) using [iota.js](https://github.com/iotaledger/iota.js) primitives to
 issue transactions that involve Alias Output.
 
 ## Introduction
 
-Starting from [Chrysalis](https://wiki.iota.org/introduction/welcome), IOTA is
-a [UTXO-based (Unspent Transaction Output)](https://wiki.iota.org/introduction/reference/details#unspent-transaction-output-utxo)
+Starting from [Chrysalis](/learn/protocols/chrysalis/introduction), IOTA is
+a [UTXO-based (Unspent Transaction Output)](/learn/protocols/chrysalis/core-concepts/switch-to-UTXO)
 Ledger. Each UTXO, also known as **output**, has an associated number of tokens that determines its value.
 Thus, the permanent data on the ledger is composed of a set of records (_outputs_) that can be unlocked by the owner of
 its associated address, i.e., the one who knows the address' private key.
 
-There are different [output types](https://wiki.iota.org/shimmer/learn/outputs). This tutorial series will only focus on
+There are different [output types](/tips/tips/TIP-0018#output-design). This tutorial series will only focus on
 **Alias Outputs** known as [`IAliasOutput`](./../../references/client/interfaces/IAliasOutput.md). Alias Outputs are
 generated by transactions that unlock and consume already existing outputs. When a transaction consumes them, these
 outputs turn into inputs and generate new outputs, typically another Alias Output with the same Alias ID but in a different state. At pruning time, _consumed outputs_ will be removed by Nodes.
 
 ## Storage Costs and Deposits
 
-You need to take into account that Alias Output as any other UTXOs need to be stored by [Hornet Nodes](https://wiki.iota.org/shimmer/hornet/welcome), so there is a [storage cost](https://wiki.iota.org/shimmer/iota.js/tutorials/value-transactions/introduction/#storage-costs-and-deposits).
+You need to take into account that Alias Output as any other UTXOs need to be stored by [Hornet Nodes](/hornet/welcome), so there is a [storage cost](/iota.js/tutorials/value-transactions/introduction#storage-costs-and-deposits).
diff --git a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/alias-transactions/03-mint-new-alias.md b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/alias-transactions/03-mint-new-alias.md
index e938b240715..71d91385af1 100644
--- a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/alias-transactions/03-mint-new-alias.md
+++ b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/alias-transactions/03-mint-new-alias.md
@@ -11,7 +11,7 @@ keywords:
 
 # Mint a New Alias Address
 
-You can use an [Alias Output](https://wiki.iota.org/shimmer/introduction/explanations/ledger/alias/) to store proof of the world state included in the ledger and never pruned. An Alias Output is associated with an Alias ID (also known as an [Alias Address](#calculate-the-alias-id)). An Alias ID remains immutable during its lifetime.
+You can use an [Alias Output](/introduction/stardust/explanations/ledger/alias) to store proof of the world state included in the ledger and never pruned. An Alias Output is associated with an Alias ID (also known as an [Alias Address](#calculate-the-alias-id)). An Alias ID remains immutable during its lifetime.
 
 For instance, an Alias Output can contain a hash or digital signature as a commitment to the state of a particular dynamic data set, as it happens with Smart Contracts. A data validator can use such proof to ensure that the concerned data has not been tampered with. When there is a change in the data, a transition to a new state is recorded on the ledger by a new transaction that generates a new Alias Output with the original Alias ID. The Alias ID remains constant, whereas a new Alias Output is generated to hold the new state.
 
diff --git a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/alias-transactions/04-alias-transaction.md b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/alias-transactions/04-alias-transaction.md
index 1127d217592..fc08a9eb789 100644
--- a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/alias-transactions/04-alias-transaction.md
+++ b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/alias-transactions/04-alias-transaction.md
@@ -34,7 +34,7 @@ const stateControllerPrivateKey = '0xa060ff...';
 
 ## Query Alias Output
 
-You will first need to find the Alias Output of your Alias. The easiest way to do so is through a query to the [indexation plugin](https://wiki.iota.org/shimmer/inx-indexer/welcome/) by Alias ID. Observe that you need to obtain the full output details as we need to use them as input for the transaction.
+You will first need to find the Alias Output of your Alias. The easiest way to do so is through a query to the [indexation plugin](/hornet/2.0.0-rc.6/inx-plugins/indexer/api_reference) by Alias ID. Observe that you need to obtain the full output details as we need to use them as input for the transaction.
 
 ```typescript
 const indexerPlugin = new IndexerPluginClient(client);
diff --git a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/native-token-transactions/01-introduction.md b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/native-token-transactions/01-introduction.md
index adc6dae0318..35e88ef6f30 100644
--- a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/native-token-transactions/01-introduction.md
+++ b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/native-token-transactions/01-introduction.md
@@ -23,20 +23,20 @@ This tutorial will show you how to user-defined native tokens, also known as **D
 
 ## Introduction
 
-Starting from [Chrysalis](https://wiki.iota.org/introduction/welcome), IOTA is
-a [UTXO-based (Unspent Transaction Output)](https://wiki.iota.org/introduction/reference/details#unspent-transaction-output-utxo)
+Starting from [Chrysalis](/learn/protocols/chrysalis/introduction), IOTA is
+a [UTXO-based (Unspent Transaction Output)](/learn/protocols/chrysalis/core-concepts/switch-to-UTXO)
 Ledger. Each UTXO, also known as **output**, has an associated number of tokens, protocol-defined Tokens (SMR) and, optionally, user-defined native tokens) that determines its value.
 Thus, the permanent data on the ledger is composed of a set of records (_Outputs_) that can be unlocked by the owner of
 its associated address, i.e., the one who knows the address' private key.
 
-There are different [Output types](https://wiki.iota.org/shimmer/learn/outputs) in the [Stardust Protocol](https://wiki.iota.org/shimmer/introduction/welcome). This tutorial will focus on
-outputs that involve user-defined [native tokens](https://wiki.iota.org/shimmer/introduction/explanations/ledger/foundry/), a.k.a digital assets. The tutorial will also use [Alias](https://wiki.iota.org/shimmer/introduction/explanations/ledger/alias/) and [Foundry](https://wiki.iota.org/shimmer/learn/outputs/#foundry-output) Outputs.
+There are different [Output types](/tips/tips/TIP-0018#output-design) in the [Stardust Protocol](/introduction/stardust/welcome). This tutorial will focus on
+outputs that involve user-defined [native tokens](/introduction/stardust/explanations/ledger/foundry), a.k.a digital assets. The tutorial will also use [Alias](/introduction/stardust/explanations/ledger/alias) and [Foundry](/tips/tips/TIP-0018#output-design#foundry-output) Outputs.
 
 :::info Foundries
 A _Foundry Output_ is an Output that controls the supply of user-defined, custom tokens, also known as _native tokens_.
 :::
 
-Last but not least, you will learn how to define [UTXOs](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/rethink_utxo/) to transfer native tokens among addresses.
+Last but not least, you will learn how to define [UTXOs](/introduction/stardust/explanations/what_is_stardust/rethink_utxo) to transfer native tokens among addresses.
 
 :::tip NFTs
 If you want to mint Non-Fungible Tokens (NFTs), you can check out this [how-to guide](../../how_tos/mint_nft.mdx).
@@ -44,4 +44,4 @@ If you want to mint Non-Fungible Tokens (NFTs), you can check out this [how-to g
 
 ## Storage Costs and Deposits
 
-You need to take into account that both Alias and Foundry outputs need to be stored by [Hornet Nodes](https://wiki.iota.org/shimmer/hornet/welcome), so there is a [storage cost](https://wiki.iota.org/shimmer/iotajs/tutorials/value-transactions/introduction/#storage-costs-and-deposits) as with any UTXO.
+You need to take into account that both Alias and Foundry outputs need to be stored by [Hornet Nodes](/hornet/welcome), so there is a [storage cost](/learn/protocols/stardust/core-concepts/storage-deposit) as with any UTXO.
diff --git a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/native-token-transactions/03-mint-native-tokens.md b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/native-token-transactions/03-mint-native-tokens.md
index 2ec281f11fb..e6502464adc 100644
--- a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/native-token-transactions/03-mint-native-tokens.md
+++ b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/native-token-transactions/03-mint-native-tokens.md
@@ -18,19 +18,19 @@ keywords:
 
 To mint a new native token you will need the following:
 
-- An initial _unspent Output_ with enough funds to cover the [storage costs](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/storage_deposit/) of the different Outputs involved. In the Testnet, you can [request funds through the Faucet](../value-transactions/06-request-funds-from-the-faucet.md).
+- An initial _unspent Output_ with enough funds to cover the [storage costs](/introduction/stardust/explanations/what_is_stardust/storage_deposit) of the different Outputs involved. In the Testnet, you can [request funds through the Faucet](../value-transactions/06-request-funds-from-the-faucet.md).
 
 :::info Storage Deposits
 
-[Storage deposits](https://wiki.iota.org/shimmer/learn/role-of-token/#storage-deposits) can only be covered by **protocol-defined tokens** (`SMR`).
+[Storage deposits](/learn/protocols/stardust/core-concepts/storage-deposit) can only be covered by **protocol-defined tokens** (`SMR`).
 
 :::
 
-- An _Alias Address_ that you will use to control the Foundry Output associated with your new native tokens. Any change made to the Foundry state will require the keys of the [State Controller](https://wiki.iota.org/shimmer/tips/tips/TIP-0018/#state-controller-address-unlock-condition) of this Alias Address and the corresponding state transition that will generate an unspent Alias Output.
+- An _Alias Address_ that you will use to control the Foundry Output associated with your new native tokens. Any change made to the Foundry state will require the keys of the [State Controller](/tips/tips/TIP-0018#state-controller-address-unlock-condition) of this Alias Address and the corresponding state transition that will generate an unspent Alias Output.
 
 - A _Token Scheme_ that defines a class of tokens with _initial supply_ (how many native tokens of that class you will mint initially) and _maximum supply_.
 
-- A _Foundry Output_ that captures all the parameters and the state related to your new native tokens, including the [Token Scheme](https://wiki.iota.org/shimmer/tips/tips/TIP-0018/#simple-token-scheme-validation-rules).
+- A _Foundry Output_ that captures all the parameters and the state related to your new native tokens, including the [Token Scheme](/tips/tips/TIP-0018#simple-token-scheme-validation-rules).
 
 - An _Address_ to which you will transfer the initial supply of native tokens through a Basic Output. You can find a guide to generating your [seed](../value-transactions/03-generate-a-seed.md) and [address](../value-transactions/04-generate-addresses.md) in the [send value transactions tutorial](../value-transactions/01-introduction.md).
 
@@ -58,7 +58,7 @@ This tutorial assumes that the newly minted Alias ID holds enough funds (protoco
 
 ### Obtain the Current Alias Output
 
-Once you have your Alias ID, you will need to get its current unspent Alias Output through the [Indexer Plugin](https://wiki.iota.org/shimmer/inx-indexer/welcome/). The Alias Output will participate in a transaction that will create a new Foundry Output and mint native tokens.
+Once you have your Alias ID, you will need to get its current unspent Alias Output through the [Indexer Plugin](/hornet/2.0.0-rc.6/inx-plugins/indexer/api_reference). The Alias Output will participate in a transaction that will create a new Foundry Output and mint native tokens.
 
 ```typescript
 const aliasId = '0x8c81...';
@@ -110,7 +110,7 @@ You can observe that you need to define the total amount and the maximum supply
 
 ## Define the Foundry Output
 
-Your next step is to define the Foundry Output (`IFoundryOutput`) that will control your new Token Scheme. You will need to set the serial number of the Foundry (`1` in this case), the formerly defined token scheme and the [unlock conditions](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/unlock_conditions/). The Foundry Output can only be unlocked by the state controller of the Alias Address that controls it.
+Your next step is to define the Foundry Output (`IFoundryOutput`) that will control your new Token Scheme. You will need to set the serial number of the Foundry (`1` in this case), the formerly defined token scheme and the [unlock conditions](/introduction/stardust/explanations/what_is_stardust/unlock_conditions). The Foundry Output can only be unlocked by the state controller of the Alias Address that controls it.
 
 As with the Alias Output, you need to deliberately set the amount to `0`, as at this point in time you don't know the amount of protocol-defined tokens you will need to cover the storage deposit for this Output.
 
@@ -154,7 +154,7 @@ That token class ID is simply the Foundry ID that will remain immutable regardle
 
 ## Define the Basic Output That Will Hold the Initial Batch of Minted Tokens
 
-As the Foundry has an initial set of minted tokens, you will need a [Basic Output](https://wiki.iota.org/shimmer/introduction/explanations/ledger/simple_transfers/) to hold those native tokens. This new Basic Output will hold the initial amount of minted native tokens identified through their token class ID. As with other Outputs, you need to set the amount of protocol-defined tokens to `0` as you don't know yet the storage deposit cost.
+As the Foundry has an initial set of minted tokens, you will need a [Basic Output](/introduction/stardust/explanations/ledger/simple_transfers) to hold those native tokens. This new Basic Output will hold the initial amount of minted native tokens identified through their token class ID. As with other Outputs, you need to set the amount of protocol-defined tokens to `0` as you don't know yet the storage deposit cost.
 
 ```typescript
 const nativeTokenOwnerAddress = '0x647f....';
diff --git a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/native-token-transactions/04-native-tokens-transaction.md b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/native-token-transactions/04-native-tokens-transaction.md
index e78c3c3ff7d..14776a193c3 100644
--- a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/native-token-transactions/04-native-tokens-transaction.md
+++ b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/native-token-transactions/04-native-tokens-transaction.md
@@ -53,7 +53,7 @@ const destAddress = '0xc8413...';
 
 ## Query Native Tokens Output to be Spent
 
-The first thing you need to do is to find the Basic Output that holds the native tokens. The easiest way to do it is through a query to the [indexation plugin](https://wiki.iota.org/shimmer/inx-indexer/welcome/), as shown below. You will need to obtain the full Output details, as you will need to use it as Input for your following transaction.
+The first thing you need to do is to find the Basic Output that holds the native tokens. The easiest way to do it is through a query to the [indexation plugin](/hornet/2.0.0-rc.6/inx-plugins/indexer/api_reference), as shown below. You will need to obtain the full Output details, as you will need to use it as Input for your following transaction.
 
 ```typescript
 const indexerPlugin = new IndexerPluginClient(client);
diff --git a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/native-token-transactions/05-melt-native-tokens.md b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/native-token-transactions/05-melt-native-tokens.md
index 46075034a98..1ad30508013 100644
--- a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/native-token-transactions/05-melt-native-tokens.md
+++ b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/native-token-transactions/05-melt-native-tokens.md
@@ -69,7 +69,7 @@ In this step, you need to transition the Alias Address to a new state, as one of
 
 ### Query for the Alias Output
 
-First, you need to find the unspent Alias Output of your Alias Address through a query to the [indexing plugin](https://wiki.iota.org/shimmer/inx-indexer/welcome/) using the Alias ID. You need to obtain the full Output details, as you will need to use it as Input for your transaction.
+First, you need to find the unspent Alias Output of your Alias Address through a query to the [indexing plugin](/hornet/2.0.0-rc.6/inx-plugins/indexer/api_reference) using the Alias ID. You need to obtain the full Output details, as you will need to use it as Input for your transaction.
 
 ```typescript
 const indexerPlugin = new IndexerPluginClient(client);
@@ -123,7 +123,7 @@ const initialFoundryOutput: IFoundryOutput =
   initialFoundryOutputDetails.output as IFoundryOutput;
 ```
 
-Keep in mind that you will need to use the `Bech32Helper.toBech32(bech32Text, humanReadablePart)`(references/client/classes/Bech32Helper/#frombech32) function to convert your Alias ID to a Bech32 address to match the format of the parameter expected by the indexing plugin.
+Keep in mind that you will need to use the `Bech32Helper.toBech32(bech32Text, humanReadablePart)`(references/client/classes/Bech32Helper#frombech32) function to convert your Alias ID to a Bech32 address to match the format of the parameter expected by the indexing plugin.
 
 At the end of this step, you know **Input #2**.
 
diff --git a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/nft-transactions/01-introduction.md b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/nft-transactions/01-introduction.md
index a67751838f3..6b6b59cc2bb 100644
--- a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/nft-transactions/01-introduction.md
+++ b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/nft-transactions/01-introduction.md
@@ -19,24 +19,24 @@ keywords:
 
 # Stardust for iota.js: NFT Transactions
 
-This tutorial will get you acquainted with the structure and functionality of [NFT Transactions](https://wiki.iota.org/shimmer/introduction/explanations/ledger/nft) in
-IOTA's [Stardust protocol](https://wiki.iota.org/shimmer/introduction/welcome) in
+This tutorial will get you acquainted with the structure and functionality of [NFT Transactions](/learn/protocols/stardust/core-concepts/multi-asset-ledger#non-fungible-tokens-nfts) in
+IOTA's [Stardust protocol](/introduction/welcome) in
 the [Shimmer network](https://shimmer.network) using [iota.js](https://github.com/iotaledger/iota.js) primitives to
 issue transactions that involve NFT Output.
 
 ## Introduction
 
-Starting from [Chrysalis](https://wiki.iota.org/introduction/welcome), IOTA is
-a [UTXO-based (Unspent Transaction Output)](https://wiki.iota.org/introduction/reference/details#unspent-transaction-output-utxo)
+Starting from [Chrysalis](/introduction/welcome), IOTA is
+a [UTXO-based (Unspent Transaction Output)](/introduction/reference/details#unspent-transaction-output-utxo)
 Ledger. Each UTXO, also known as **Output**, has an associated number of tokens that determines its value.
 Thus, the permanent data on the ledger is composed of a set of records (_Outputs_) that can be unlocked by the owner of
 its associated address, i.e., the one who knows the address' private key.
 
-There are different [output types](https://wiki.iota.org/shimmer/learn/outputs). This tutorial series will only focus on
+There are different [output types](/tips/tips/TIP-0018#output-design). This tutorial series will only focus on
 **NFT Outputs** known as [`INftOutput`](./../../references/client/interfaces/INftOutput.md). NFT Outputs are
 generated by transactions that unlock and consume already existing Outputs. When a transaction consumes them, these
 Outputs turn into Inputs and generate new Outputs, typically another NFT Output with the same NFT ID but in a different state. At pruning time, _consumed Outputs_ will be removed by Nodes.
 
 ## Storage Costs and Deposits
 
-You need to take into account that NFT Output, as any other UTXOs, need to be stored by [Hornet Nodes](https://wiki.iota.org/shimmer/hornet/welcome), so there is a [storage cost](https://wiki.iota.org/shimmer/iota.js/tutorials/value-transactions/introduction/#storage-costs-and-deposits).
+You need to take into account that NFT Output, as any other UTXOs, need to be stored by [Hornet Nodes](/hornet/welcome), so there is a [storage cost](/iota.js/tutorials/value-transactions/introduction#storage-costs-and-deposits).
diff --git a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/nft-transactions/03-mint-new-nft.md b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/nft-transactions/03-mint-new-nft.md
index d78645e56a3..a1289dda8f5 100644
--- a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/nft-transactions/03-mint-new-nft.md
+++ b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/nft-transactions/03-mint-new-nft.md
@@ -15,9 +15,9 @@ keywords:
 
 # Mint a New NFT
 
-An [NFT](https://wiki.iota.org/shimmer/introduction/explanations/ledger/nft/) is a unique token on the ledger. Its owner
+An [NFT](/learn/protocols/stardust/core-concepts/multi-asset-ledger#non-fungible-tokens-nfts) is a unique token on the ledger. Its owner
 controls it through the private key of
-an [address](https://wiki.iota.org/iota.rs/explanations/address_key_space/). An NFT has a unique ID assigned by the
+an [address](/iota.rs/explanations/address_key_space/). An NFT has a unique ID assigned by the
 Ledger, bound to an Output in the Ledger. An NFT has some immutable
 features that cannot be changed through the lifetime of the NFT, namely the issuer of the NFT. Additionally, immutable
 metadata links the NFT with a Digital Asset (image, video, etc.). The owner of the NFT can only change non-immutable
@@ -25,15 +25,15 @@ aspects of
 the NFT by unlocking its unspent Output in a transaction and generating a
 new Output (conserving the NFT ID). The owner can also use a transaction to transfer the NFT to another owner. As with
 other types of Outputs, NFT Outputs must also cover
-their [storage costs](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/storage_deposit/) with
+their [storage costs](/learn/protocols/stardust/core-concepts/storage-deposit) with
 protocol-defined tokens (`SMR`).
 
 To mint an NFT, you will need the following:
 
-- A unspent [Basic Output](https://wiki.iota.org/shimmer/tips/tips/TIP-0018/#basic-output) that holds enough funds for
+- A unspent [Basic Output](/tips/tips/TIP-0018#basic-output) that holds enough funds for
   the minimal storage deposit needed for the NFT Output. In
-  the [Testnet](https://wiki.iota.org/shimmer/introduction/reference/networks/betanet/), you
-  can [request funds from the Faucet](https://wiki.iota.org/shimmer/iota.js/tutorials/value-transactions/request-funds-from-the-faucet/).
+  the [Testnet](/build/networks-endpoints#public-testnet), you
+  can [request funds from the Faucet](/iota.js/tutorials/value-transactions/request-funds-from-the-faucet).
 
 - The key pair that corresponds to the Shimmer address that owns the former Output, as you need to unlock a certain
   amount of funds to cover the storage deposit of the Output corresponding to the newly minted NFT.
@@ -112,7 +112,7 @@ The `nftId` is initialized as a hexadecimal string that represents `32` bytes se
 request to mint a **new** NFT. The Output also includes two immutable features:
 The `Issuer`. It must be equal to the owner of the Input of the transaction that will create the NFT
 The `metadata`. This allows knowing information about the asset bound to the NFT. In this case,
-the [IRC27 standard](https://wiki.iota.org/shimmer/tips/tips/TIP-0027/) is used to assert that the asset is an image
+the [IRC27 standard](/tips/tips/TIP-0027) is used to assert that the asset is an image
 hosted at a particular URI.
 
 ### Unlock Conditions
diff --git a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/nft-transactions/04-nft-transaction.md b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/nft-transactions/04-nft-transaction.md
index d40402b618c..79153b870e8 100644
--- a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/nft-transactions/04-nft-transaction.md
+++ b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/nft-transactions/04-nft-transaction.md
@@ -17,9 +17,9 @@ from the ledger.
 
 This section will show you how to issue a transaction that will transfer the ownership of your NFT to a different
 address. Since you probably want to recover the tokens you used to cover
-the [storage deposits](https://wiki.iota.org/shimmer/iota.js/tutorials/value-transactions/introduction/#storage-costs-and-deposits),
+the [storage deposits](/iota.js/tutorials/value-transactions/introduction#storage-costs-and-deposits),
 this code example includes an
-additional [storage deposit return](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/unlock_conditions/#storage-deposit-return) [unlock condition](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/unlock_conditions/)
+additional [storage deposit return](/learn/protocols/stardust/core-concepts/output-unlock-conditions#storage-deposit-return) [unlock condition](/learn/protocols/stardust/core-concepts/output-unlock-conditions)
 to the NFT Output.
 
 ## Preparation
@@ -48,7 +48,7 @@ const nftBuyerAddr = '0x57d3...';
 ## Query For the NFT Output
 
 You will first need to query for the NFT Output of your NFT. The easiest way to do so is through a query to
-the [indexation plugin](https://wiki.iota.org/shimmer/inx-indexer/welcome/) by NFT ID. You need to obtain the full
+the [indexation plugin](/hornet/2.0.0-rc.6/inx-plugins/indexer/api_reference) by NFT ID. You need to obtain the full
 Output details as you need to use them as input for the transaction.
 
 ```typescript
@@ -70,9 +70,9 @@ const initialNftOutput: INftOutput =
 Once you have [queried for the NFT output](#query-for-the-nft-output), you should create the new NFT Output by cloning
 it, and then set the two new unlock conditions:
 
-1. The [address](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/unlock_conditions/#address)
+1. The [address](/learn/protocols/stardust/core-concepts/output-unlock-conditions#address)
    corresponding to the new owner of the NFT (for instance, the buyer of the NFT).
-2. A [storage deposit unlock condition](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/unlock_conditions/#storage-deposit-return)
+2. A [storage deposit unlock condition](/learn/protocols/stardust/core-concepts/output-unlock-conditions#storage-deposit-return)
    that will allow you to get a refund of the storage costs of the NFT Output. That way, the `SMR` tokens you used to cover
    the storage costs will be refunded whenever the new owner of the NFT decides to unlock it.
 
diff --git a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/nft-transactions/05-claim-nft.md b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/nft-transactions/05-claim-nft.md
index 480f20058b3..a8f6ad586f2 100644
--- a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/nft-transactions/05-claim-nft.md
+++ b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/nft-transactions/05-claim-nft.md
@@ -17,7 +17,7 @@ keywords:
 
 In the previous section of this tutorial, you [transferred and NFT](./04-nft-transaction.md) to a new owner. However,
 since you added
-a [storage deposit return unlock condition](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/unlock_conditions/#storage-deposit-return)
+a [storage deposit return unlock condition](/learn/protocols/stardust/core-concepts/output-unlock-conditions#storage-deposit-return)
 to the transfer, the new owner will need to create a new Output to return the deposit.
 
 This section will show you how to refund the issuer of the NFT and gain complete control over the NFT. To do so, you
@@ -25,7 +25,7 @@ will need to do the following:
 
 Issue a [new NFT transaction](./04-nft-transaction.md) that changes the unlock conditions so that the only remaining
 condition is
-the [address](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/unlock_conditions/#address).
+the [address](/learn/protocols/stardust/core-concepts/output-unlock-conditions#address).
 
 Create an additional Input with enough funds to cover the storage deposit for the new NFT Output,
 Generate an Output to refund the issuer.
@@ -70,7 +70,7 @@ const nftOwnerPrivateKey = '0xc2be...';
 ## Query For the NFT Output
 
 You will first need to retrieve the NFT Output of your NFT from the network. The easiest way to do so is through a query
-to the [indexation plugin](https://wiki.iota.org/shimmer/inx-indexer/welcome/) by NFT ID. You need to obtain the full
+to the [indexation plugin](/hornet/2.0.0-rc.6/inx-plugins/indexer/api_reference) by NFT ID. You need to obtain the full
 Output details as you need to use them as Input for the transaction.
 
 ```typescript
@@ -93,9 +93,9 @@ At the end of this step you have obtained **Input #1** of your transaction.
 ## Set the New Unlock Conditions
 
 You can create the new NFT Output by cloning the [one received from the node](#query-nft-output), removing
-the [storage deposit return unlock condition](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/unlock_conditions/#storage-deposit-return),
+the [storage deposit return unlock condition](/learn/protocols/stardust/core-concepts/output-unlock-conditions#storage-deposit-return),
 and only keep
-the [address unlock condition](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/unlock_conditions/#address).
+the [address unlock condition](/learn/protocols/stardust/core-concepts/output-unlock-conditions#address).
 That way, you will have full control of the NFT through your address keys.
 
 The `amount` field is set to `0`, so you can later calculate the minimum storage deposit needed for your new NFT Output.
@@ -204,7 +204,7 @@ At the end of this sub-step you know the total cost that should be covered by yo
 ### Find an Output With Enough Funds
 
 You can find the right Basic Output by querying
-the [indexation plugin](https://wiki.iota.org/shimmer/inx-indexer/welcome/). You should check that the Output has not
+the [indexation plugin](/hornet/2.0.0-rc.6/inx-plugins/indexer/api_reference). You should check that the Output has not
 been spent yet.
 
 ```typescript
diff --git a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/value-transactions/01-introduction.md b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/value-transactions/01-introduction.md
index 357e6bab531..667ac5f6864 100644
--- a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/value-transactions/01-introduction.md
+++ b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/value-transactions/01-introduction.md
@@ -17,30 +17,30 @@ keywords:
 # Stardust for iota.js: Value Transactions
 
 This tutorial will get you acquainted with the structure and functionality of transactions in
-IOTA's [Stardust protocol](https://wiki.iota.org/shimmer/introduction/welcome) in
+IOTA's [Stardust protocol](/introduction/welcome) in
 the [Shimmer network](https://shimmer.network) using [iota.js](https://github.com/iotaledger/iota.js) primitives to
 issue value transactions.
 
 ## Introduction
 
-Starting from [Chrysalis](https://wiki.iota.org/introduction/welcome), IOTA is
-a [UTXO-based (Unspent Transaction Output)](https://wiki.iota.org/introduction/reference/details#unspent-transaction-output-utxo)
+Starting from [Chrysalis](/introduction/welcome), IOTA is
+a [UTXO-based (Unspent Transaction Output)](/introduction/reference/details#unspent-transaction-output-utxo)
 Ledger. Each UTXO, also known as **output**, has an associated number of tokens that determines its value.
 Thus, the permanent data on the ledger is composed of a set of records (_outputs_) that can be unlocked by the owner of
 its associated address, i.e., the one who knows the address' private key.
 
-There are different [output types](https://wiki.iota.org/shimmer/learn/outputs). This tutorial series will only focus on
+There are different [output types](/tips/tips/TIP-0018#output-design). This tutorial series will only focus on
 value outputs known as [`IBasicOutput`](./../../references/client/interfaces/IBasicOutput.md). Outputs are
 generated by transactions that unlock and consume already existing outputs. When a transaction consumes them, these
 outputs turn into inputs and generate new outputs. At pruning time, _consumed outputs_ will be removed by Nodes.
 However, they might be stored permanently by Nodes that have enabled
-the [INX Chronicle](https://wiki.iota.org/shimmer/chronicle/welcome) plugin.
+the [INX Chronicle](/chronicle/welcome) plugin.
 Each output in the Ledger has a unique identifier as it has each transaction that mutates the Ledger state by
 manipulating other outputs.
 
 ## Storage Costs and Deposits
 
-UTXOs need to be stored by [Hornet Nodes](https://wiki.iota.org/shimmer/hornet/welcome), so there is a storage cost.
+UTXOs need to be stored by [Hornet Nodes](/hornet/welcome), so there is a storage cost.
 The Stardust protocol defines a parameter, named ["vByte cost"](../../references/client/interfaces/IRent.md#vbytecost),
 that establishes the cost of storage of each "virtual byte" in _Glow_ (one Glow corresponds to 0.000001 Shimmer).
 As each output consumes a number of vBytes in the Ledger, it is a necessary condition for an output
diff --git a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/value-transactions/07-query-output-details.md b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/value-transactions/07-query-output-details.md
index 887728e54ff..2483c56ec1f 100644
--- a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/value-transactions/07-query-output-details.md
+++ b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/value-transactions/07-query-output-details.md
@@ -93,7 +93,7 @@ The output details contain two different groups of information:
   the [Ed22519 public key hash](../../references/client/interfaces/IEd25519Address.md#pubkeyhash) of your initial
   address. That means that only the one who controls the private key corresponding to that public key hash can
   unlock this output and use the corresponding funds. The protocol defines other
-  possible [unlock conditions](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/unlock_conditions)
+  possible [unlock conditions](/learn/protocols/stardust/core-concepts/output-unlock-conditions)
   that will be when you [prepare the transaction](08-transfer-funds.md#Preparing-outputs).
 
 ## Putting It All Together
diff --git a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/value-transactions/09-understanding-deposits.md b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/value-transactions/09-understanding-deposits.md
index 24f054f0a00..02d0cb0129b 100644
--- a/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/value-transactions/09-understanding-deposits.md
+++ b/docs/build/iota.js/2.0.0-rc.1/docs/tutorials/value-transactions/09-understanding-deposits.md
@@ -14,7 +14,7 @@ keywords:
 
 You can try executing all the steps described in this tutorial again but using a new output ID corresponding to the
 value `999.95 SMR` in the origin address. This time, instead of hard-coding the output ID, you can obtain the output
-ID through the [indexation plugin](https://wiki.iota.org/shimmer/inx-indexer/welcome). The indexation plugin keeps the
+ID through the [indexation plugin](/hornet/2.0.0-rc.6/inx-plugins/indexer/api_reference). The indexation plugin keeps the
 correspondence between addresses and their associated outputs, so it is easy to obtain the balance of an address.
 
 ```typescript
diff --git a/docs/build/iota.rs/1.4.0/docs/_admonitions/_dust_protection.md b/docs/build/iota.rs/1.4.0/docs/_admonitions/_dust_protection.md
index f2e05a19f01..7886b76c94a 100644
--- a/docs/build/iota.rs/1.4.0/docs/_admonitions/_dust_protection.md
+++ b/docs/build/iota.rs/1.4.0/docs/_admonitions/_dust_protection.md
@@ -1,6 +1,6 @@
 :::note Dust Protection
 
-Due to the [dust protection](https://wiki.iota.org/introduction/explanations/faq/#what-is-dust-protection-and-how-does-it-work)
+Due to the [dust protection](/introduction/explanations/faq#what-is-dust-protection-and-how-does-it-work)
 mechanism implemented in the network protocol, microtransactions below 1Mi of IOTA tokens can only be sent to another
 address if there is already at least 1Mi on that address
 
diff --git a/docs/build/iota.rs/1.4.0/docs/_admonitions/_enable_mqtt b/docs/build/iota.rs/1.4.0/docs/_admonitions/_enable_mqtt
index 59f3c8e72f4..c6139f58e32 100644
--- a/docs/build/iota.rs/1.4.0/docs/_admonitions/_enable_mqtt
+++ b/docs/build/iota.rs/1.4.0/docs/_admonitions/_enable_mqtt
@@ -1,7 +1,7 @@
 :::info Enable MQTT
 
 The IOTA node needs to have the MQTT layer enabled. There is a set of test nodes available that have MQTT enabled.
-You can find more information in the [devnet section](https://wiki.iota.org/chrysalis-docs/devnet/) of the Chrysalis
+You can find more information in the [devnet section](/introduction/devnet/) of the Chrysalis
 documentation.
 
 :::
diff --git a/docs/build/iota.rs/1.4.0/docs/_admonitions/_faucet_service.md b/docs/build/iota.rs/1.4.0/docs/_admonitions/_faucet_service.md
index 4cd72a27106..44944df9a37 100644
--- a/docs/build/iota.rs/1.4.0/docs/_admonitions/_faucet_service.md
+++ b/docs/build/iota.rs/1.4.0/docs/_admonitions/_faucet_service.md
@@ -1,6 +1,6 @@
 :::note Faucet Service
 
 You can use the [faucet service](https://faucet.chrysalis-devnet.iota.cafe/) to send test tokens to any Chrysalis
-[devnet](https://wiki.iota.org/introduction/reference/networks/devnet) address.
+[devnet](/introduction/reference/networks/devnet) address.
 
 :::
diff --git a/docs/build/iota.rs/1.4.0/docs/_admonitions/_password_storage.md b/docs/build/iota.rs/1.4.0/docs/_admonitions/_password_storage.md
index 00f7e4c8ac2..e7abca479c9 100644
--- a/docs/build/iota.rs/1.4.0/docs/_admonitions/_password_storage.md
+++ b/docs/build/iota.rs/1.4.0/docs/_admonitions/_password_storage.md
@@ -1,7 +1,7 @@
 :::warning Password Storage
 
 It is not recommended to store passwords or seeds on a host's environment variables or in the source code in a production
-setup. Please follow our [backup and security](https://wiki.iota.org/introduction/how_tos/backup_security/)
+setup. Please follow our [backup and security](/introduction/how_tos/backup_security/)
 recommendations for production use.
 
 :::
diff --git a/docs/build/iota.rs/1.4.0/docs/_admonitions/_seed_mnemonics.md b/docs/build/iota.rs/1.4.0/docs/_admonitions/_seed_mnemonics.md
index c399f907910..2424a884eb1 100644
--- a/docs/build/iota.rs/1.4.0/docs/_admonitions/_seed_mnemonics.md
+++ b/docs/build/iota.rs/1.4.0/docs/_admonitions/_seed_mnemonics.md
@@ -1,6 +1,6 @@
 :::info Seed Mnemonics/Phrases
 
-In modern wallet implementations such as the [wallet.rs library](https://wiki.iota.org/wallet.rs/welcome) and the
+In modern wallet implementations such as the [wallet.rs library](/wallet.rs/welcome) and the
 [firefly wallet](https://blog.iota.org/firefly-beta-release/), the seed is usually generated from a `seed mnemonic`
 (`seed phrase`), using [BIP39 standard](https://en.bitcoin.it/wiki/BIP_0039), to be better memorized/stored by humans.
 It is based on a randomly generated list of english words and later used to generate the seed. The seed is a root for
diff --git a/docs/build/iota.rs/1.4.0/docs/_admonitions/_wallet_transaction_recommendation.md b/docs/build/iota.rs/1.4.0/docs/_admonitions/_wallet_transaction_recommendation.md
index 66e57dc5801..1de84752302 100644
--- a/docs/build/iota.rs/1.4.0/docs/_admonitions/_wallet_transaction_recommendation.md
+++ b/docs/build/iota.rs/1.4.0/docs/_admonitions/_wallet_transaction_recommendation.md
@@ -1,8 +1,8 @@
 :::info
 
 Though it is possible to send transactions with iota.rs, we strongly recommend that you use the official
-[`wallet.rs`](https://wiki.iota.org/wallet.rs/welcome) library together with the
-[`stronghold.rs`](https://wiki.iota.org/stronghold.rs/welcome) enclave for value-based transfers. This combination
+[`wallet.rs`](/wallet.rs/welcome) library together with the
+[`stronghold.rs`](/stronghold.rs/welcome) enclave for value-based transfers. This combination
 incorporates the best security practices while dealing with seeds, related addresses, and `UTXO`.
 
 :::
diff --git a/docs/build/iota.rs/1.4.0/docs/_partials/examples/01_get_info/outputs/camelCase.md b/docs/build/iota.rs/1.4.0/docs/_partials/examples/01_get_info/outputs/camelCase.md
index a16546876dd..08b663d5fda 100644
--- a/docs/build/iota.rs/1.4.0/docs/_partials/examples/01_get_info/outputs/camelCase.md
+++ b/docs/build/iota.rs/1.4.0/docs/_partials/examples/01_get_info/outputs/camelCase.md
@@ -26,7 +26,7 @@ The most important properties are:
   up and running, it may not be fully prepared to process your API calls properly. The node should be "synced", meaning
   that it should be aware of all transactions in the Tangle. It is better to avoid interacting with nodes which are not
   fully synced.
-- `bech32HRP`: Indicates whether the given node is a part of [devnet](https://wiki.iota.org/introduction/reference/networks/devnet)
-  (`atoi`) or [mainnet](https://wiki.iota.org/introduction/reference/networks/mainnet) (`iota`). You can find more info regarding the
-  [IOTA address format](https://wiki.iota.org/introduction/reference/details/#iota-15-address-anatomy) in the official
-  [Chrysalis documentation](https://wiki.iota.org/introduction/welcome).
+- `bech32HRP`: Indicates whether the given node is a part of [devnet](/introduction/reference/networks/devnet)
+  (`atoi`) or [mainnet](/introduction/reference/networks/mainnet) (`iota`). You can find more info regarding the
+  [IOTA address format](/introduction/reference/details#iota-15-address-anatomy) in the official
+  [Chrysalis documentation](/introduction/welcome).
diff --git a/docs/build/iota.rs/1.4.0/docs/_partials/examples/01_get_info/outputs/snake_case.md b/docs/build/iota.rs/1.4.0/docs/_partials/examples/01_get_info/outputs/snake_case.md
index b156efc682c..c8f4ff22629 100644
--- a/docs/build/iota.rs/1.4.0/docs/_partials/examples/01_get_info/outputs/snake_case.md
+++ b/docs/build/iota.rs/1.4.0/docs/_partials/examples/01_get_info/outputs/snake_case.md
@@ -26,7 +26,7 @@ The most important properties are:
   up and running, it may not be fully prepared to process your API calls properly. The node should be "synced", meaning
   that it should be aware of all transactions in the Tangle. It is better to avoid interacting with nodes which are not
   fully synced.
-- `bech32_hrp`: Indicates whether the given node is a part of [devnet](https://wiki.iota.org/introduction/reference/networks/devnet)
-  (`atoi`) or [mainnet](https://wiki.iota.org/introduction/reference/networks/mainnet) (`iota`). You can find more info regarding the
-  [IOTA address format](https://wiki.iota.org/chrysalis-docs/guides/developer/#iota-15-address-anatom) in the official
-  [Chrysalis documentation](https://wiki.iota.org/chrysalis-docs/welcome).
+- `bech32_hrp`: Indicates whether the given node is a part of [devnet](/introduction/reference/networks/devnet)
+  (`atoi`) or [mainnet](/introduction/reference/networks/mainnet) (`iota`). You can find more info regarding the
+  [IOTA address format](/introduction/reference/details#iota-15-address-anatomym) in the official
+  [Chrysalis documentation](/introduction/welcome).
diff --git a/docs/build/iota.rs/1.4.0/docs/examples/get_info.mdx b/docs/build/iota.rs/1.4.0/docs/examples/get_info.mdx
index 548f465dd71..2e569673878 100644
--- a/docs/build/iota.rs/1.4.0/docs/examples/get_info.mdx
+++ b/docs/build/iota.rs/1.4.0/docs/examples/get_info.mdx
@@ -29,11 +29,11 @@ import WasmGetInfo from '../libraries/wasm/examples/_01_get_info.mdx';
 You can access all the features of the `iota.rs` library using an instance of the `Client` class. The `Client` class
 provides high-level abstraction to all interactions over IOTA network (Tangle). You have to instantiate this class
 before you start any interactions with the library, or more precisely with the
-[IOTA nodes](https://wiki.iota.org/introduction/explanations/node_software) that power IOTA network.
+[IOTA nodes](/introduction/explanations/node_software) that power IOTA network.
 
 The library is designed to automatically choose a starting IOTA node based on the network type you would like to
-participate in: [`devnet`](https://wiki.iota.org/introduction/reference/networks/devnet) or
-[`mainnet`](https://wiki.iota.org/introduction/reference/networks/mainnet).
+participate in: [`devnet`](/introduction/reference/networks/devnet) or
+[`mainnet`](/introduction/reference/networks/mainnet).
 
 <WarningPasswordStorage />
 
diff --git a/docs/build/iota.rs/1.4.0/docs/explanations/address_key_space.md b/docs/build/iota.rs/1.4.0/docs/explanations/address_key_space.md
index 2db866b2ede..d89cf2d7369 100644
--- a/docs/build/iota.rs/1.4.0/docs/explanations/address_key_space.md
+++ b/docs/build/iota.rs/1.4.0/docs/explanations/address_key_space.md
@@ -55,9 +55,9 @@ And there are few additional interesting notes:
   developers to implement. \_Using different `accounts` may have a negative impact on a performance while you are on the
   [account discovery](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#account-discovery) phase. If you are
   planning on using many multiple accounts then you may be interested in our stateful library
-  [wallet.rs](https://wiki.iota.org/wallet.rs/welcome) that incorporates all business logic needed to efficiently manage
+  [wallet.rs](/wallet.rs/welcome) that incorporates all business logic needed to efficiently manage
   independent accounts.
-  Our [exchange guide](https://wiki.iota.org/introduction/how_tos/exchange)
+  Our [exchange guide](/introduction/how_tos/exchange)
   provides some useful tips on how different accounts may be leveraged.
 
 ![address_generation](/img/libraries/address_generation.svg)
diff --git a/docs/build/iota.rs/1.4.0/docs/libraries/java/examples/_03_generate_addresses.mdx b/docs/build/iota.rs/1.4.0/docs/libraries/java/examples/_03_generate_addresses.mdx
index 1c70fdb4e88..eb3569e229a 100644
--- a/docs/build/iota.rs/1.4.0/docs/libraries/java/examples/_03_generate_addresses.mdx
+++ b/docs/build/iota.rs/1.4.0/docs/libraries/java/examples/_03_generate_addresses.mdx
@@ -22,7 +22,7 @@ https://github.com/iotaledger/iota.rs/blob/production/bindings/java/examples/jav
 ```
 
 IOTA addresses are represented by a checksumed base-32 string (Bech32). You can find a detailed explanation in the
-[Chrysalis documentations](https://wiki.iota.org/chrysalis-docs/guides/developer/#iota-15-address-anatom), but here are
+[Chrysalis documentations](/introduction/reference/details#iota-15-address-anatomym), but here are
 parts relevant to this example:
 
 - If an address starts with `atoi` then it means it is related to `devnet`. `iota` stands for `mainnet`.
diff --git a/docs/build/iota.rs/1.4.0/docs/libraries/java/examples/_04_get_balance.mdx b/docs/build/iota.rs/1.4.0/docs/libraries/java/examples/_04_get_balance.mdx
index 48179399bc1..fd743a002dd 100644
--- a/docs/build/iota.rs/1.4.0/docs/libraries/java/examples/_04_get_balance.mdx
+++ b/docs/build/iota.rs/1.4.0/docs/libraries/java/examples/_04_get_balance.mdx
@@ -42,4 +42,4 @@ The outputs of address "atoi1qzt0nhsf38nh6rs4p6zs5knqp6psgha9wsv74uajqgjmwc75ugu
 
 - `dustAllowed` indicates whether the given address is allowed to accept a dust. You can learn more about dust
   protection in the
-  [Chrysalis documentation](https://wiki.iota.org/chrysalis-docs/faq#what-is-dust-protection-and-how-does-it-work).
+  [Chrysalis documentation](/introduction/explanations/faq#what-is-dust-protection-and-how-does-it-work).
diff --git a/docs/build/iota.rs/1.4.0/docs/libraries/nodejs/examples/_03_generate_addresses.mdx b/docs/build/iota.rs/1.4.0/docs/libraries/nodejs/examples/_03_generate_addresses.mdx
index 2fbc931b79a..baba23b50c7 100644
--- a/docs/build/iota.rs/1.4.0/docs/libraries/nodejs/examples/_03_generate_addresses.mdx
+++ b/docs/build/iota.rs/1.4.0/docs/libraries/nodejs/examples/_03_generate_addresses.mdx
@@ -22,7 +22,7 @@ https://github.com/iotaledger/iota.rs/tree/production/bindings/nodejs/examples/0
 ```
 
 IOTA addresses are represented by a checksumed base-32 string (Bech32). You can find a detailed explanation in the
-[Chrysalis documentations](https://wiki.iota.org/chrysalis-docs/guides/developer/#iota-15-address-anatom), but here are
+[Chrysalis documentations](/introduction/reference/details#iota-15-address-anatomym), but here are
 parts relevant to this example:
 
 - If an address starts with `atoi` then it means it is related to `devnet`. `iota` stands for `mainnet`.
diff --git a/docs/build/iota.rs/1.4.0/docs/libraries/nodejs/examples/_04_get_balance.mdx b/docs/build/iota.rs/1.4.0/docs/libraries/nodejs/examples/_04_get_balance.mdx
index 3f9d5bd8d27..1c8b74f3bd2 100644
--- a/docs/build/iota.rs/1.4.0/docs/libraries/nodejs/examples/_04_get_balance.mdx
+++ b/docs/build/iota.rs/1.4.0/docs/libraries/nodejs/examples/_04_get_balance.mdx
@@ -41,4 +41,4 @@ Account balance: 0
 
 - `dustAllowed` indicates whether the given address is allowed to accept a dust. You can learn more about dust
   protection in the
-  [Chrysalis documentation](https://wiki.iota.org/chrysalis-docs/faq#what-is-dust-protection-and-how-does-it-work).
+  [Chrysalis documentation](/introduction/explanations/faq#what-is-dust-protection-and-how-does-it-work).
diff --git a/docs/build/iota.rs/1.4.0/docs/libraries/python/examples/_03_generate_addresses.mdx b/docs/build/iota.rs/1.4.0/docs/libraries/python/examples/_03_generate_addresses.mdx
index 9cf4b958a2a..c4ccd235484 100644
--- a/docs/build/iota.rs/1.4.0/docs/libraries/python/examples/_03_generate_addresses.mdx
+++ b/docs/build/iota.rs/1.4.0/docs/libraries/python/examples/_03_generate_addresses.mdx
@@ -39,7 +39,7 @@ https://github.com/iotaledger/iota.rs/tree/production/bindings/python/examples/0
 - This behavior is controlled by the `get_all` argument. `get_all=False` (default) generates only public addresses.
 
 IOTA addresses are represented by a checksumed base-32 string (Bech32). You can find a detailed explanation in the
-[Chrysalis documentations](https://wiki.iota.org/chrysalis-docs/guides/developer/#iota-15-address-anatom), but here are
+[Chrysalis documentations](/introduction/reference/details#iota-15-address-anatomym), but here are
 parts relevant to this example:
 
 - If an address starts with `atoi` then it means it is related to `devnet`. `iota` stands for `mainnet`.
diff --git a/docs/build/iota.rs/1.4.0/docs/libraries/python/examples/_04_get_balance.mdx b/docs/build/iota.rs/1.4.0/docs/libraries/python/examples/_04_get_balance.mdx
index 479298051ae..43c399930e4 100644
--- a/docs/build/iota.rs/1.4.0/docs/libraries/python/examples/_04_get_balance.mdx
+++ b/docs/build/iota.rs/1.4.0/docs/libraries/python/examples/_04_get_balance.mdx
@@ -34,4 +34,4 @@ Account balance: 0
 ```
 
 - `dustAllowed` indicates whether the given address is allowed to accept a dust due to
-  [dust protection mechanism](https://wiki.iota.org/chrysalis-docs/faq#what-is-dust-protection-and-how-does-it-work).
+  [dust protection mechanism](/introduction/explanations/faq#what-is-dust-protection-and-how-does-it-work).
diff --git a/docs/build/iota.rs/1.4.0/docs/libraries/rust/examples/_03_generate_addresses.mdx b/docs/build/iota.rs/1.4.0/docs/libraries/rust/examples/_03_generate_addresses.mdx
index 9b37401022e..19ae965df79 100644
--- a/docs/build/iota.rs/1.4.0/docs/libraries/rust/examples/_03_generate_addresses.mdx
+++ b/docs/build/iota.rs/1.4.0/docs/libraries/rust/examples/_03_generate_addresses.mdx
@@ -43,7 +43,7 @@ List of offline generated public addresses:
 ```
 
 IOTA addresses are represented by a checksumed base-32 string (Bech32). You can find a detailed explanation in the
-[Chrysalis documentations](https://wiki.iota.org/chrysalis-docs/guides/developer/#iota-15-address-anatom), but here are
+[Chrysalis documentations](/introduction/reference/details#iota-15-address-anatomym), but here are
 parts relevant to this example:
 
 - If an address starts with `atoi` then it means it is related to `devnet`. `iota` stands for `mainnet`.
diff --git a/docs/build/iota.rs/1.4.0/docs/libraries/rust/examples/_04_get_balance.mdx b/docs/build/iota.rs/1.4.0/docs/libraries/rust/examples/_04_get_balance.mdx
index c7d9ca992e3..ad7d615049f 100644
--- a/docs/build/iota.rs/1.4.0/docs/libraries/rust/examples/_04_get_balance.mdx
+++ b/docs/build/iota.rs/1.4.0/docs/libraries/rust/examples/_04_get_balance.mdx
@@ -55,4 +55,4 @@ The outputs of address "atoi1qzt0nhsf38nh6rs4p6zs5knqp6psgha9wsv74uajqgjmwc75ugu
 ```
 
 - `dustAllowed` indicates whether the given address is allowed to accept a dust due to
-  [dust protection mechanism](https://wiki.iota.org/chrysalis-docs/faq#what-is-dust-protection-and-how-does-it-work).
+  [dust protection mechanism](/introduction/explanations/faq#what-is-dust-protection-and-how-does-it-work).
diff --git a/docs/build/iota.rs/1.4.0/docs/libraries/wasm/examples/_03_generate_addresses.mdx b/docs/build/iota.rs/1.4.0/docs/libraries/wasm/examples/_03_generate_addresses.mdx
index d4112445cb0..f0a0dcdb41a 100644
--- a/docs/build/iota.rs/1.4.0/docs/libraries/wasm/examples/_03_generate_addresses.mdx
+++ b/docs/build/iota.rs/1.4.0/docs/libraries/wasm/examples/_03_generate_addresses.mdx
@@ -22,7 +22,7 @@ https://github.com/iotaledger/iota.rs/tree/production/bindings/wasm/examples/03_
 ```
 
 IOTA addresses are represented by a checksumed base-32 string (Bech32). You can find a detailed explanation in the
-[Chrysalis documentations](https://wiki.iota.org/chrysalis-docs/guides/developer/#iota-15-address-anatom), but here are
+[Chrysalis documentations](/introduction/reference/details#iota-15-address-anatomym), but here are
 parts relevant to this example:
 
 - If an address starts with `atoi` then it means it is related to `devnet`. `iota` stands for `mainnet`.
diff --git a/docs/build/iota.rs/1.4.0/docs/libraries/wasm/examples/_04_get_balance.mdx b/docs/build/iota.rs/1.4.0/docs/libraries/wasm/examples/_04_get_balance.mdx
index b4009d7e83c..e4c82e541fc 100644
--- a/docs/build/iota.rs/1.4.0/docs/libraries/wasm/examples/_04_get_balance.mdx
+++ b/docs/build/iota.rs/1.4.0/docs/libraries/wasm/examples/_04_get_balance.mdx
@@ -42,4 +42,4 @@ Account balance: 0
 
 - `dustAllowed` indicates whether the given address is allowed to accept a dust. You can learn more about dust
   protection in the
-  [Chrysalis documentation](https://wiki.iota.org/chrysalis-docs/faq#what-is-dust-protection-and-how-does-it-work).
+  [Chrysalis documentation](/introduction/explanations/faq#what-is-dust-protection-and-how-does-it-work).
diff --git a/docs/build/iota.rs/1.4.0/docs/overview.md b/docs/build/iota.rs/1.4.0/docs/overview.md
index 3bb3b6412e0..ce90fe5aaff 100644
--- a/docs/build/iota.rs/1.4.0/docs/overview.md
+++ b/docs/build/iota.rs/1.4.0/docs/overview.md
@@ -15,7 +15,7 @@ keywords:
 ![IOTA Client Library Overview](/img/Banner/banner_client_lib_overview.png)
 
 The iota.rs library is designed to simplify how you connect and interact
-with [nodes](https://wiki.iota.org/chrysalis-docs/node_software) in the IOTA network. You can use it to generate
+with [nodes](/introduction/explanations/node_software) in the IOTA network. You can use it to generate
 addresses, send messages, sign and send transactions, and more.
 
 Beyond establishing the initial connection to a node, iota.rs has no state. Operations use only the data you pass during
@@ -25,9 +25,9 @@ your application.
 This stateless approach makes iota.rs easy to use and understand. But since you are in full control of data management,
 you are also fully responsible for it, which could feel overwhelming if you handle complex or sensitive data. If you
 plan on managing funds in your application, take a look at
-our [wallet.rs library](https://wiki.iota.org/wallet.rs/welcome) instead. It allows you to manage your user's funds
+our [wallet.rs library](/wallet.rs/welcome) instead. It allows you to manage your user's funds
 safely, and it already includes our best security practices. It
-uses [stronghold.rs](https://wiki.iota.org/stronghold.rs/welcome) to store sensitive data and iota.rs to communicate
+uses [stronghold.rs](/stronghold.rs/welcome) to store sensitive data and iota.rs to communicate
 with the IOTA network and, unlike iota.rs, it has a state.
 
 ## Supported Languages
@@ -44,12 +44,8 @@ powerful no matter which language you choose.
 Your application communicates with iota.rs either directly in Rust or through one of the language bindings. The iota.rs
 library turns your requests into REST API calls and sends them to a node through the Internet. The node, in turn,
 interacts with the rest of an IOTA network, which could be
-the [main operational network (mainnet)](https://wiki.iota.org/introduction/reference/networks/mainnet) or
-a [network for testing purposes (devnet)](https://wiki.iota.org/introduction/reference/networks/devnet).
-
-Different nodes can run on different software, but they always expose the same interface to clients. For example, one
-node could be a [Hornet](https://wiki.iota.org/hornet/welcome) node, and the other could be
-a [Bee](https://wiki.iota.org/bee/welcome) node, and they both would appear the same for any client.
+the [main operational network (mainnet)](/introduction/reference/networks/mainnet) or
+a [network for testing purposes (devnet)](/introduction/reference/networks/devnet).
 
 ![A diagram that illustrates the text above. It has three layers: the application layer that includes iota.rs and its bindings, communication layer (the Internet network), and IOTA network layer with nodes that operate on one of the IOTA networks.](/img/overview/layered_overview.svg 'An overview of IOTA layers.')
 
diff --git a/docs/build/iota.rs/1.4.0/docs/specs.mdx b/docs/build/iota.rs/1.4.0/docs/specs.mdx
index 79eff65965f..ace6cf2803f 100644
--- a/docs/build/iota.rs/1.4.0/docs/specs.mdx
+++ b/docs/build/iota.rs/1.4.0/docs/specs.mdx
@@ -701,7 +701,7 @@ A tuple with the newly promoted `(MessageId, Message)`.
 
 ## Full Node API
 
-The full node APIs of [Bee](https://wiki.iota.org/bee/welcome) and [Hornet](https://wiki.iota.org/hornet/welcome) will
+The full node APIs of [Hornet](/hornet/welcome) will
 still be public. Users who are familiar with these relative low level Restful APIs can still call them directly if they
 are confident in their usage.
 
diff --git a/docs/build/iota.rs/2.0.1-rc.7/docs/_admonitions/_password_storage.md b/docs/build/iota.rs/2.0.1-rc.7/docs/_admonitions/_password_storage.md
index 62b0cf8d4f4..1b60dd89dd6 100644
--- a/docs/build/iota.rs/2.0.1-rc.7/docs/_admonitions/_password_storage.md
+++ b/docs/build/iota.rs/2.0.1-rc.7/docs/_admonitions/_password_storage.md
@@ -1,7 +1,7 @@
 :::warning Password Storage
 
 Never store passwords or seeds on a host's environment variables or in the source code in a production
-setup. Please follow our [backup and security](https://wiki.iota.org/shimmer/introduction/how_tos/backup_security)
+setup. Please follow our [backup and security](/introduction/how_tos/backup_security)
 recommendations for production use.
 
 :::
diff --git a/docs/build/iota.rs/2.0.1-rc.7/docs/_admonitions/_wallet_transaction_recommendation.md b/docs/build/iota.rs/2.0.1-rc.7/docs/_admonitions/_wallet_transaction_recommendation.md
index 9e07f89c6f1..63abab9349e 100644
--- a/docs/build/iota.rs/2.0.1-rc.7/docs/_admonitions/_wallet_transaction_recommendation.md
+++ b/docs/build/iota.rs/2.0.1-rc.7/docs/_admonitions/_wallet_transaction_recommendation.md
@@ -1,8 +1,8 @@
 :::info Wallet.rs
 
 Though it is possible to send transactions with `iota.rs`, we strongly recommend that you use the official
-[`wallet.rs`](https://wiki.iota.org/shimmer/wallet.rs/welcome) library together with the
-[`stronghold.rs`](https://wiki.iota.org/stronghold.rs/welcome) enclave for value-based transfers. This combination
+[`wallet.rs`](/wallet.rs/welcome) library together with the
+[`stronghold.rs`](/stronghold.rs/welcome) enclave for value-based transfers. This combination
 incorporates the best security practices while dealing with seeds, related addresses, and UTXO.
 
 :::
diff --git a/docs/build/iota.rs/2.0.1-rc.7/docs/getting_started/java.mdx b/docs/build/iota.rs/2.0.1-rc.7/docs/getting_started/java.mdx
index 52ca0b685d2..4e03ca2856f 100644
--- a/docs/build/iota.rs/2.0.1-rc.7/docs/getting_started/java.mdx
+++ b/docs/build/iota.rs/2.0.1-rc.7/docs/getting_started/java.mdx
@@ -102,7 +102,7 @@ public class HelloWorld {
 ## What's Next?
 
 Now that you are up and running, you can get acquainted with the library using
-its [how-to guides](https://wiki.iota.org/shimmer/iota.rs/how_tos/run_how_tos/) and the
+its [how-to guides](../how_tos/00_run_how_tos.mdx) and the
 repository's [code examples](https://github.com/iotaledger/iota.rs/tree/develop/client/bindings/java/examples/src).
 
 ## Instead, build everything from scratch yourself:
@@ -305,7 +305,7 @@ public class HelloWorld {
 ## What's Next?
 
 Now that you are up and running, you can get acquainted with the library using
-its [how-to guides](https://wiki.iota.org/shimmer/iota.rs/how_tos/run_how_tos/) and the
+its [how-to guides](../how_tos/00_run_how_tos.mdx) and the
 repository's [code examples](https://github.com/iotaledger/iota.rs/tree/develop/client/bindings/java/examples/src).
 
 ## Instead, build everything from scratch yourself:
diff --git a/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/01_get_node_info.mdx b/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/01_get_node_info.mdx
index 58629046a1c..41d9247bead 100644
--- a/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/01_get_node_info.mdx
+++ b/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/01_get_node_info.mdx
@@ -29,7 +29,7 @@ import IotaJs from '../_admonitions/_iotajs_example.mdx';
 You can access all the features of the `iota.rs` library using an instance of the `Client` class. The `Client` class
 provides high-level abstraction to all interactions over IOTA network (Tangle). You have to instantiate this class
 before you start any interactions with the library, or more precisely with the
-[IOTA nodes](https://wiki.iota.org/chrysalis-docs/node_software) that power IOTA network.
+[IOTA nodes](/introduction/stardust/explanations/node_software) that power IOTA network.
 
 The following code example will:
 
@@ -37,7 +37,7 @@ The following code example will:
 2. Use the created client to get information about the node.
 3. Print the information to the console.
 
-<IotaJs exampleURL='https://wiki.iota.org/iota.js/how_tos/simple' />
+<IotaJs exampleURL='/iota.js/how_tos/simple' />
 
 ## Code Example
 
diff --git a/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/03_generate_addresses.mdx b/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/03_generate_addresses.mdx
index 9e3afa2ede2..2346b463760 100644
--- a/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/03_generate_addresses.mdx
+++ b/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/03_generate_addresses.mdx
@@ -38,7 +38,7 @@ The following code example will:
 4. Generate an internal address.
 5. Generate an offline address.
 
-<IotaJs exampleURL='https://wiki.iota.org/iota.js/how_tos/address' />
+<IotaJs exampleURL='/iota.js/how_tos/address' />
 
 ## Code Example
 
diff --git a/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/08_post_block.mdx b/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/08_post_block.mdx
index 2b4b5b3d9bc..fc5eb7125e7 100644
--- a/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/08_post_block.mdx
+++ b/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/08_post_block.mdx
@@ -44,7 +44,7 @@ The following code example will:
 4. [Create and post](07_create_block.mdx) the block with the data from step 2.
 5. [Generate a public address](03_generate_addresses.mdx).
 
-<IotaJs exampleURL='https://wiki.iota.org/iota.js/how_tos/data' />
+<IotaJs exampleURL='/iota.js/how_tos/data' />
 
 ## Post a Block
 
diff --git a/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/09_get_block.mdx b/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/09_get_block.mdx
index 06a81433b39..74862788a42 100644
--- a/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/09_get_block.mdx
+++ b/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/09_get_block.mdx
@@ -38,7 +38,7 @@ The following code example will:
 4. Retrieve and log the block's data.
 5. Get the block by its block ID.
 
-<IotaJs exampleURL='https://wiki.iota.org/iota.js/how_tos/data' />
+<IotaJs exampleURL='/iota.js/how_tos/data' />
 
 ## Code Example
 
diff --git a/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/10_prepare_sign_transaction.mdx b/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/10_prepare_sign_transaction.mdx
index a66eeaa5d6a..dd16e6610ac 100644
--- a/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/10_prepare_sign_transaction.mdx
+++ b/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/10_prepare_sign_transaction.mdx
@@ -33,7 +33,7 @@ The following code example will:
 4. [Build](07_create_block.mdx) and [post a block](08_post_block.mdx) with an output address and amount to send.
 5. Log the transaction.
 
-<IotaJs exampleURL='https://wiki.iota.org/iota.js/how_tos/transaction' />
+<IotaJs exampleURL='/iota.js/how_tos/transaction' />
 
 ## Code Example
 
diff --git a/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/11_build_nft_output.mdx b/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/11_build_nft_output.mdx
index a35d1df9b7e..fdd96a3c807 100644
--- a/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/11_build_nft_output.mdx
+++ b/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/11_build_nft_output.mdx
@@ -32,7 +32,7 @@ The following code example will:
 3. Build an NFT output.
 4. [Build](07_create_block.mdx) and [post](08_post_block.mdx) a block with the NFT output created in step 3.
 
-<IotaJs exampleURL='https://wiki.iota.org/iota.js/how_tos/mint_nft' />
+<IotaJs exampleURL='/iota.js/how_tos/mint_nft' />
 
 ## Code Example
 
diff --git a/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/16_use-python-with-iota.mdx b/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/16_use-python-with-iota.mdx
index 64f77ac0521..de51f8fc62b 100644
--- a/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/16_use-python-with-iota.mdx
+++ b/docs/build/iota.rs/2.0.1-rc.7/docs/how_tos/16_use-python-with-iota.mdx
@@ -22,7 +22,7 @@ First install the Shimmer version following the [installation guide](/getting_st
 
 ### Install IOTA Version
 
-To install the IOTA version you need to follow the [Install from source](https://wiki.iota.org/iota.rs/getting_started/python#install-from-source) guide.
+To install the IOTA version you need to follow the [Install from source](/iota.rs/getting_started/python#install-from-source) guide.
 Before you continue with the steps after having cloned the repo, we need to apply some changes to the repo first.
 
 :::info
@@ -41,7 +41,7 @@ In `bindings/python/native/Cargo.toml` change both names:
   authors = ["IOTA Stiftung"]
   edition = "2021"
   description = "Python bindings for the IOTA client library"
-  documentation = "https://wiki.iota.org/iota.rs/welcome"
+  documentation = "/iota.rs/welcome"
   homepage = "https://www.iota.org/"
   repository = "https://github.com/iotaledger/iota.rs"
   license = "Apache-2.0"
@@ -95,7 +95,7 @@ And in `bindings/python/native/src/lib.rs`:
   }
 ```
 
-Now you can continue the installation from [here](https://wiki.iota.org/iota.rs/getting_started/python#change-to-the-python-binding-directory).
+Now you can continue the installation from [here](/iota.rs/getting_started/python#change-to-the-python-binding-directory).
 
 ### Usage
 
diff --git a/docs/build/iota.rs/2.0.1-rc.7/docs/libraries/overview.md b/docs/build/iota.rs/2.0.1-rc.7/docs/libraries/overview.md
index 5c618a9dc61..7242827ccf6 100644
--- a/docs/build/iota.rs/2.0.1-rc.7/docs/libraries/overview.md
+++ b/docs/build/iota.rs/2.0.1-rc.7/docs/libraries/overview.md
@@ -35,6 +35,6 @@ You can use the [Shimmer Tangle Explorer](https://explorer.shimmer.network/testn
 ## Get Test Tokens
 
 If you plan on managing funds in your application, take a look at
-our [wallet.rs library](https://wiki.iota.org/wallet.rs/welcome) instead.
+our [wallet.rs library](/wallet.rs/welcome) instead.
 
 In any case, to properly test value-based transactions on testnet network, you are going to need some tokens. You can get some testnet tokens through the [Shimmer Faucet](https://faucet.testnet.shimmer.network).
diff --git a/docs/build/iota.rs/2.0.1-rc.7/docs/overview.md b/docs/build/iota.rs/2.0.1-rc.7/docs/overview.md
index b4c250288e1..0eb84c9616c 100644
--- a/docs/build/iota.rs/2.0.1-rc.7/docs/overview.md
+++ b/docs/build/iota.rs/2.0.1-rc.7/docs/overview.md
@@ -1,6 +1,6 @@
 ---
 description: 'The iota.rs library is designed to simplify how you connect and interact
-with [nodes](https://wiki.iota.org/chrysalis-docs/node_software) in the IOTA network. '
+with [nodes](/introduction/node_software) in the IOTA network. '
 image: /img/overview/layered_overview.svg
 keywords:
 
@@ -18,7 +18,7 @@ keywords:
 ![IOTA Client Library Overview](/img/Banner/banner_client_lib_overview.png)
 
 The iota.rs library is designed to simplify how you connect and interact
-with [nodes](https://wiki.iota.org/shimmer/introduction/explanations/node_software) in the IOTA network. You can use it to generate
+with [nodes](/introduction/explanations/node_software) in the IOTA network. You can use it to generate
 addresses, send messages, sign and send transactions, and more.
 
 Beyond establishing the initial connection to a node, iota.rs has no state. Operations use only the data you pass during
@@ -28,7 +28,7 @@ your application.
 This stateless approach makes iota.rs easy to use and understand. But since you are in full control of data management,
 you are also fully responsible for it, which could feel overwhelming if you handle complex or sensitive data. If you
 plan on managing funds in your application, take a look at
-our [wallet.rs library](https://wiki.iota.org/wallet.rs/welcome) instead.
+our [wallet.rs library](/wallet.rs/welcome) instead.
 
 ## Supported Languages
 
@@ -44,13 +44,13 @@ powerful no matter which language you choose.
 Your application communicates with iota.rs either directly in Rust or through one of the language bindings. The iota.rs
 library turns your requests into REST API calls and sends them to a node through the Internet. The node, in turn,
 interacts with the rest of an IOTA network, which could be
-the [main operational network (mainnet)](https://wiki.iota.org/introduction/reference/networks/mainnet) or
-a [network for testing purposes (devnet)](https://wiki.iota.org/introduction/reference/networks/devnet).
+the [main operational network (mainnet)](/introduction/reference/networks/mainnet) or
+a [network for testing purposes (devnet)](/introduction/reference/networks/devnet).
 
 Different nodes can run on different software, but they always expose the same interface to clients. For example, one
-node could be a [Hornet](https://wiki.iota.org/shimmer/hornet/welcome) node, and the other could be
+node could be a [Hornet](/hornet/welcome) node, and the other could be
 a different implementation of the
-[core REST API](https://wiki.iota.org/shimmer/develop/nodes/core-rest-api/iota-core-rest-api/), and they both would
+[core REST API](/apis/core/v2/iota-core-rest-api), and they both would
 appear the same for any client.
 
 ![A diagram that illustrates the text above. It has three layers: the application layer that includes iota.rs and its bindings, communication layer (the Internet network), and IOTA network layer with nodes that operate on one of the IOTA networks.](/img/overview/layered_overview.svg 'An overview of IOTA layers.')
diff --git a/docs/build/streams/0.2.0/docs/welcome.md b/docs/build/streams/0.2.0/docs/welcome.md
index ac20b0494a8..6c4bfc9c5f6 100644
--- a/docs/build/streams/0.2.0/docs/welcome.md
+++ b/docs/build/streams/0.2.0/docs/welcome.md
@@ -21,7 +21,7 @@ This is the documentation for the official IOTA Streams software. You can read m
 
 Streams is an organizational tool for structuring and navigating secure data through the Tangle. Streams organizes data by ordering it in a uniform and interoperable structure. Needless to say, it is also based on our official _one source code of truth_ [IOTA Rust library](https://github.com/iotaledger/iota.rs).
 
-More information about Chrysalis components is available at [documentation portal](https://wiki.iota.org/chrysalis-docs/welcome).
+More information about Chrysalis components is available at [documentation portal](/introduction/welcome).
 
 ## Joining the discussion
 
diff --git a/docs/build/wallet.rs/0.1.0/docs/examples/nodejs.mdx b/docs/build/wallet.rs/0.1.0/docs/examples/nodejs.mdx
index d4140de2000..da91753902e 100644
--- a/docs/build/wallet.rs/0.1.0/docs/examples/nodejs.mdx
+++ b/docs/build/wallet.rs/0.1.0/docs/examples/nodejs.mdx
@@ -56,11 +56,11 @@ One of the key principles behind `Stronghold` based storage is that no one can e
 
 If you also want to store a seed somewhere else, you can use the `AccountManager.generateMnemonic()` method. Using this method generates a random seed. You can also use it before the actual account initialization.
 
-You can find detailed information about seed generation in the [Developer Guide to Chrysalis](https://wiki.iota.org/introduction/welcome/).
+You can find detailed information about seed generation in the [Developer Guide to Chrysalis](/introduction/welcome/).
 
 ### Accounts
 
-The `wallet.rs` library uses a model of individual accounts to separate individual users or clients from each other. You can generate multiple addresses for each account deterministically. You can find more information about account management in the [Developer Guide to Chrysalis](https://wiki.iota.org/introduction/how_tos/exchange/).
+The `wallet.rs` library uses a model of individual accounts to separate individual users or clients from each other. You can generate multiple addresses for each account deterministically. You can find more information about account management in the [Developer Guide to Chrysalis](/introduction/how_tos/exchange/).
 
 Once you have created the backend storage, you can create individual accounts for individual users can be created by running the `manager.createAccount()` method:
 
@@ -143,7 +143,7 @@ You can use the following example to generate a new database and account:
 https://github.com/iotaledger/wallet.rs/tree/production/bindings/nodejs/examples/binding_examples/3-check-balance.js
 ```
 
-IOTA is based on _Unspent Transaction Output_ model. You can find a detailed explanation in the [Developer Guide to Chrysalis](https://wiki.iota.org/learn/about-iota/messages#utxo).
+IOTA is based on _Unspent Transaction Output_ model. You can find a detailed explanation in the [Developer Guide to Chrysalis](/learn/about-iota/messages#utxo).
 
 ## Sending Tokens
 
@@ -163,7 +163,7 @@ The `Account.send()` function returns a _wallet message_ that fully describes th
 
 ### Dust Protection
 
-The network uses a [dust protection](https://wiki.iota.org/introduction/explanations/faq/#what-is-dust-protection-and-how-does-it-work) protocol to prevent malicious actors from spamming the network while also keeping track of the unspent amount ( _UTXO_ ).
+The network uses a [dust protection](/introduction/explanations/faq#what-is-dust-protection-and-how-does-it-work) protocol to prevent malicious actors from spamming the network while also keeping track of the unspent amount ( _UTXO_ ).
 
 :::info
 
diff --git a/docs/build/wallet.rs/0.1.0/docs/getting_started/nodejs.mdx b/docs/build/wallet.rs/0.1.0/docs/getting_started/nodejs.mdx
index 6a361889641..75ef7e07f3f 100644
--- a/docs/build/wallet.rs/0.1.0/docs/getting_started/nodejs.mdx
+++ b/docs/build/wallet.rs/0.1.0/docs/getting_started/nodejs.mdx
@@ -18,7 +18,7 @@ import TabItem from '@theme/TabItem';
 
 :::note
 
-You can find a guide for exchanges and the most common use cases in the [Chrysalis documentation](https://wiki.iota.org/introduction/how_tos/exchange/), which is based on `wallet.rs` and `Node.js`.
+You can find a guide for exchanges and the most common use cases in the [Chrysalis documentation](/introduction/how_tos/exchange/), which is based on `wallet.rs` and `Node.js`.
 
 :::
 
@@ -37,10 +37,10 @@ You can use the following links to install any of the requirements.
 
 ## Install the Library
 
-Since wallet.rs is also used to communicate with nodes in the [Shimmer network](https://wiki.iota.org/shimmer/learn/welcome/)
-that runs the [Stardust protocol](https://wiki.iota.org/shimmer/introduction/welcome/), if you plan to use the library
-in the [IOTA network](https://wiki.iota.org/learn/about-iota/an-introduction-to-iota/) with the
-[Chrysalis protocol](https://wiki.iota.org/introduction/welcome/), you will need to install the latest `1.x.x` version.
+Since wallet.rs is also used to communicate with nodes in the [Shimmer network](/get-started/introduction/shimmer/introduction)
+that runs the [Stardust protocol](/introduction/welcome), if you plan to use the library
+in the [IOTA network](/learn/about-iota/an-introduction-to-iota/) with the
+[Chrysalis protocol](/introduction/welcome/), you will need to install the latest `1.x.x` version.
 
 <Tabs groupId="nodePackageManager" queryString>
 <TabItem value="npm" label="npm">
@@ -141,7 +141,7 @@ yarn install
 
 :::warning Safe password Storage
 
-In a production setup, do not store passwords in the host's environment variables or in the source code. For reference, see our [backup and security recommendations](https://wiki.iota.org/introduction/how_tos/backup_security/) for production setups.
+In a production setup, do not store passwords in the host's environment variables or in the source code. For reference, see our [backup and security recommendations](/introduction/how_tos/backup_security/) for production setups.
 
 :::
 
diff --git a/docs/build/wallet.rs/0.1.0/docs/getting_started/python.md b/docs/build/wallet.rs/0.1.0/docs/getting_started/python.md
index 46f6d4848a5..01bf6881591 100644
--- a/docs/build/wallet.rs/0.1.0/docs/getting_started/python.md
+++ b/docs/build/wallet.rs/0.1.0/docs/getting_started/python.md
@@ -15,7 +15,7 @@ keywords:
 
 :::note
 
-In a production setup, do not store passwords in the host's environment variables or in the source code. For reference, review our [backup and security recommendations](https://wiki.iota.org/introduction/how_tos/backup_security/) for production setups.
+In a production setup, do not store passwords in the host's environment variables or in the source code. For reference, review our [backup and security recommendations](/introduction/how_tos/backup_security/) for production setups.
 :::
 
 ## Requirements
diff --git a/docs/build/wallet.rs/0.1.0/docs/reference/specifications.md b/docs/build/wallet.rs/0.1.0/docs/reference/specifications.md
index 1c1bf574a1f..f793aeec057 100644
--- a/docs/build/wallet.rs/0.1.0/docs/reference/specifications.md
+++ b/docs/build/wallet.rs/0.1.0/docs/reference/specifications.md
@@ -17,9 +17,9 @@ keywords:
 
 The `wallet.rs` library is a stateful package with a standardized interface to build applications with IOTA value transactions. The package is compatible with different platforms such as web, desktop, and mobile.
 
-The package introduces the concept of an _account_ . An _account_ is a reference to, or a label for, a [seed](https://wiki.iota.org/introduction/reference/details/#seed). It has certain properties such as [addresses](https://github.com/Wollac/protocol-rfcs/blob/bech32-address-format/text/0020-bech32-address-format/0020-bech32-address-format.md) and [messages](https://github.com/GalRogozinski/protocol-rfcs/blob/message/text/0017-message/0017-message.md). An account also maintains various behaviours, including moving funds, looking for new messages, and making copies of message histories. Additionally, it provides a degree of financial privacy and thus does not incur any overhead.
+The package introduces the concept of an _account_ . An _account_ is a reference to, or a label for, a [seed](/introduction/reference/details#seed). It has certain properties such as [addresses](https://github.com/Wollac/protocol-rfcs/blob/bech32-address-format/text/0020-bech32-address-format/0020-bech32-address-format.md) and [messages](https://github.com/GalRogozinski/protocol-rfcs/blob/message/text/0017-message/0017-message.md). An account also maintains various behaviours, including moving funds, looking for new messages, and making copies of message histories. Additionally, it provides a degree of financial privacy and thus does not incur any overhead.
 
-[A similar account package was used before](https://wiki.iota.org/introduction/explanations/update/chrysalis_improvements/#ed25519-signature-scheme) but it became obsolete with the introduction of Ed25519 signatures. The previous account package was also limited to a single account, whereas the new package manages multiple accounts.
+[A similar account package was used before](/introduction/explanations/update/chrysalis_improvements#ed25519-signature-scheme) but it became obsolete with the introduction of Ed25519 signatures. The previous account package was also limited to a single account, whereas the new package manages multiple accounts.
 
 For IOTA, the motivation to use this package was to offer a simplified (stateful) approach to handle IOTA payments.
 
diff --git a/docs/build/wallet.rs/0.1.0/docs/welcome.md b/docs/build/wallet.rs/0.1.0/docs/welcome.md
index c9384b277ce..5339329f596 100644
--- a/docs/build/wallet.rs/0.1.0/docs/welcome.md
+++ b/docs/build/wallet.rs/0.1.0/docs/welcome.md
@@ -42,10 +42,10 @@ With the `wallet.rs` library, developers no longer need to use a self-generated
 
 ## IOTA 1.5 (Chrysalis) in a Nutshell
 
-For some background, you can checkout our [Developer Guide to Chrysalis](https://wiki.iota.org/introduction/explanations/update/what_is_chrysalis/) which explains all of the main concepts behind the IOTA Chrysalis in detail.
+For some background, you can checkout our [Developer Guide to Chrysalis](/introduction/explanations/update/what_is_chrysalis/) which explains all of the main concepts behind the IOTA Chrysalis in detail.
 
-You can also read our [Chrysalis documentation](https://wiki.iota.org/introduction/welcome/) to learn the history of versions between IOTA 1.0 and Chrysalis.
+You can also read our [Chrysalis documentation](/introduction/welcome/) to learn the history of versions between IOTA 1.0 and Chrysalis.
 
 ## Testnet
 
-To join the Chrysalis public devnet, check out our [blog post](https://blog.iota.org/chrysalis-phase-2-testnet-out-now/). You can also learn more about the different Chrysalis components in our [Chrysalis documentation portal](https://wiki.iota.org/introduction/welcome/).
+To join the Chrysalis public devnet, check out our [blog post](https://blog.iota.org/chrysalis-phase-2-testnet-out-now/). You can also learn more about the different Chrysalis components in our [Chrysalis documentation portal](/introduction/welcome/).
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/_admonitions/_password_storage.md b/docs/build/wallet.rs/1.0.0-rc.6/docs/_admonitions/_password_storage.md
index 00f7e4c8ac2..e7abca479c9 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/_admonitions/_password_storage.md
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/_admonitions/_password_storage.md
@@ -1,7 +1,7 @@
 :::warning Password Storage
 
 It is not recommended to store passwords or seeds on a host's environment variables or in the source code in a production
-setup. Please follow our [backup and security](https://wiki.iota.org/introduction/how_tos/backup_security/)
+setup. Please follow our [backup and security](/introduction/how_tos/backup_security/)
 recommendations for production use.
 
 :::
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/_admonitions/_warning_safe_password_storage.md b/docs/build/wallet.rs/1.0.0-rc.6/docs/_admonitions/_warning_safe_password_storage.md
index ab679554af2..94e53d498a5 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/_admonitions/_warning_safe_password_storage.md
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/_admonitions/_warning_safe_password_storage.md
@@ -1,5 +1,5 @@
 :::warning Safe Password Storage
 
-In a production setup, do not store passwords in the host's environment variables or in the source code. See our [backup and security recommendations](https://wiki.iota.org/shimmer/introduction/how_tos/backup_security) for production setups.
+In a production setup, do not store passwords in the host's environment variables or in the source code. See our [backup and security recommendations](/introduction/how_tos/backup_security) for production setups.
 
 :::
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/_admonitions/_warning_unlock_conditions.md b/docs/build/wallet.rs/1.0.0-rc.6/docs/_admonitions/_warning_unlock_conditions.md
index 09b3817a572..bba2618177b 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/_admonitions/_warning_unlock_conditions.md
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/_admonitions/_warning_unlock_conditions.md
@@ -1,8 +1,8 @@
 :::warning Unlock Conditions
 
-Outputs may have multiple [UnlockConditions](https://wiki.iota.org/shimmer/tips/tips/TIP-0018/#unlock-conditions), which may require [returning some or all of the transferred amount](https://wiki.iota.org/shimmer/tips/tips/TIP-0018/#storage-deposit-return-unlock-condition). The outputs could also [expire if not claimed in time](https://wiki.iota.org/shimmer/tips/tips/TIP-0018/#expiration-unlock-condition), or may not be [unlockable for a predefined period](https://wiki.iota.org/shimmer/tips/tips/TIP-0018/#timelock-unlock-condition).
+Outputs may have multiple [UnlockConditions](/tips/tips/TIP-0018#unlock-conditions), which may require [returning some or all of the transferred amount](/tips/tips/TIP-0018#storage-deposit-return-unlock-condition). The outputs could also [expire if not claimed in time](/tips/tips/TIP-0018#expiration-unlock-condition), or may not be [unlockable for a predefined period](/tips/tips/TIP-0018#timelock-unlock-condition).
 
-To get outputs with only the [`AddressUnlockCondition`](https://wiki.iota.org/shimmer/tips/tips/TIP-0018/#address-unlock-condition), you should synchronize with the option `syncOnlyMostBasicOutputs: true`.
+To get outputs with only the [`AddressUnlockCondition`](/tips/tips/TIP-0018#address-unlock-condition), you should synchronize with the option `syncOnlyMostBasicOutputs: true`.
 
 If you are synchronizing outputs with other unlock conditions, you should check the unlock conditions carefully before crediting users any balance.
 
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/explanations/library_overview.md b/docs/build/wallet.rs/1.0.0-rc.6/docs/explanations/library_overview.md
index 854e4ba90a7..beaf195e3f0 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/explanations/library_overview.md
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/explanations/library_overview.md
@@ -33,7 +33,7 @@ multiple accounts or multiple addresses. It is up to a developer whether he choo
 multi-account approach.
 
 The library is based on
-a [derivation for multiple accounts from a single seed](https://wiki.iota.org/introduction/reference/details/#addresskey-space).
+a [derivation for multiple accounts from a single seed](/introduction/reference/details#addresskey-space).
 An account is simply a deterministic identifier from which multiple addresses can be further derived.
 
 The following image illustrates the relationships between seed, accounts and addresses. A single seed can contain
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/getting_started/java.mdx b/docs/build/wallet.rs/1.0.0-rc.6/docs/getting_started/java.mdx
index cf1e1efbbe7..4b8e3373e26 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/getting_started/java.mdx
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/getting_started/java.mdx
@@ -124,7 +124,7 @@ public class CreateAccount {
 ## What's Next?
 
 Now that you are up and running, you can get acquainted with the library using
-its [how-to guides](https://wiki.iota.org/shimmer/wallet.rs/how_tos/run_how_tos/) and the
+its [how-to guides](../how_tos/run_how_tos.mdx) and the
 repository's [code examples](https://github.com/iotaledger/wallet.rs/tree/develop/wallet/bindings/java/examples/src).
 
 ## Instead, build everything from scratch yourself:
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/NFT/01_mint_nft.mdx b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/NFT/01_mint_nft.mdx
index 4b48ee97fc5..37ebd0cea15 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/NFT/01_mint_nft.mdx
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/NFT/01_mint_nft.mdx
@@ -27,11 +27,11 @@ import IOTAJsExample from '../../_admonitions/_info_iotajs.mdx';
 <TipFaucet />
 
 You can use a node running the stardust update to mint
-[non-fungible tokens (NFTs)](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/tokenization#non-fungible-tokens-nfts).
+[non-fungible tokens (NFTs)](/introduction/stardust/explanations/what_is_stardust/tokenization#non-fungible-tokens-nfts).
 To do so, you will only need to [add some funds to your account](../accounts_and_addresses/03_request_funds.mdx), define
 the native token's options and call the `Account.mint_nfts(nft_options, options)` function.
 
-<IOTAJsExample exampleURL={'https://wiki.iota.org/iota.js/how_tos/mint_nft'} />
+<IOTAJsExample exampleURL={'/iota.js/how_tos/mint_nft'} />
 
 ## Code Example
 
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/NFT/02_send_nft.mdx b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/NFT/02_send_nft.mdx
index 213dc8c55d6..846932a414e 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/NFT/02_send_nft.mdx
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/NFT/02_send_nft.mdx
@@ -27,12 +27,12 @@ import RustOutput from '../../libraries/rust/how_to/NFT/_02_send_nft/_expected_o
 import ReplaceNFTId from '../../_admonitions/_note_replace_native_token_id.md';
 
 After you have [minted](01_mint_nft.mdx) an
-[NFT](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/tokenization#non-fungible-tokens-nfts),
+[NFT](/introduction/stardust/explanations/what_is_stardust/tokenization#non-fungible-tokens-nfts),
 you can easily send it by calling the `Account.send_nft(addresses_nft_ids, options)` function.
 
 As with any output, you can set a
-[storage deposit](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/storage_deposit) and
-[output unlock conditions](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/unlock_conditions).
+[storage deposit](/introduction/stardust/explanations/what_is_stardust/storage_deposit) and
+[output unlock conditions](/introduction/stardust/explanations/what_is_stardust/unlock_conditions).
 Keep in mind that if you set unlock conditions, whoever you send the native tokens to may need to
 [claim them](../outputs_and_transactions/04_claim_outputs.mdx).
 
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/accounts_and_addresses/01_create_a_wallet_account.mdx b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/accounts_and_addresses/01_create_a_wallet_account.mdx
index 956da260e13..0b5ee3ace2f 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/accounts_and_addresses/01_create_a_wallet_account.mdx
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/accounts_and_addresses/01_create_a_wallet_account.mdx
@@ -36,7 +36,7 @@ The first thing you will need to do when you are getting started with the wallet
 The following example will:
 
 1. Create an account manager.
-2. Use it to store the [Stronghold](https://wiki.iota.org/stronghold.rs/welcome) mnemonic.
+2. Use it to store the [Stronghold](/stronghold.rs/welcome) mnemonic.
 3. Create a wallet with the alias "Alice".
 
 <Tabs groupId='language' queryString>
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/accounts_and_addresses/02_generate_address.mdx b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/accounts_and_addresses/02_generate_address.mdx
index 20cbd9913bf..3c8dfc108e2 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/accounts_and_addresses/02_generate_address.mdx
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/accounts_and_addresses/02_generate_address.mdx
@@ -32,7 +32,7 @@ After you have [created an account](01_create_a_wallet_account.mdx), you have a
 
 <TipAccountApproaches />
 
-<IOTAJsExample exampleURL={'https://wiki.iota.org/iota.js/how_tos/address'} />
+<IOTAJsExample exampleURL={'/iota.js/how_tos/address'} />
 
 ## Code Example
 
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/exchange_guide.mdx b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/exchange_guide.mdx
index 2fea445a29a..1e6dae3d587 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/exchange_guide.mdx
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/exchange_guide.mdx
@@ -43,7 +43,7 @@ Features of the Wallet Library:
 
 ### How Does it Work?
 
-The Wallet Library is a stateful package with a standardized interface for developers to build applications involving value transactions. It offers abstractions to handle payments and can optionally interact with [Stronghold](https://wiki.iota.org/stronghold.rs/getting_started) for seed handling, seed storage, and state backup.
+The Wallet Library is a stateful package with a standardized interface for developers to build applications involving value transactions. It offers abstractions to handle payments and can optionally interact with [Stronghold](/stronghold.rs/getting_started) for seed handling, seed storage, and state backup.
 
 :::note
 
@@ -72,7 +72,7 @@ Since all `wallet.rs` bindings are based on core principles provided by the `wal
 
 First, you should install the components that are needed to use `wallet.rs` and the binding of your choice; it may vary a bit from language to language. In the case of the [NodeJs binding](./../getting_started/nodejs.mdx), it is straightforward since it is distributed via the `npm` package manager.
 
-You can read more about [backup and security in this guide](https://wiki.iota.org/shimmer/introduction/how_tos/backup_security).
+You can read more about [backup and security in this guide](/introduction/how_tos/backup_security).
 
 ```bash
 npm install @iota/wallet dotenv
@@ -97,7 +97,7 @@ SH_PASSWORD="here is your super secure password"
 MNEMONIC="here is your super secure 24 word mnemonic, it's only needed here the first time"
 ```
 
-After you have updated the `.env` file, you can initialize the `AccountManager` instance with a secret manager([`Stronghold`](https://wiki.iota.org/stronghold.rs/welcome) by default) and client options.
+After you have updated the `.env` file, you can initialize the `AccountManager` instance with a secret manager([`Stronghold`](/stronghold.rs/welcome) by default) and client options.
 
 :::note
 
@@ -111,7 +111,7 @@ One of the key principles behind the `stronghold` is that no one can get a seed
 
 :::note
 
-Keep the `stronghold` password and the `stronghold` database on separate devices. See the [backup and security guide](https://wiki.iota.org/introduction/how_tos/backup_security/) for more information.
+Keep the `stronghold` password and the `stronghold` database on separate devices. See the [backup and security guide](/introduction/how_tos/backup_security/) for more information.
 
 :::
 
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/native_tokens/01_mint_native_token.mdx b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/native_tokens/01_mint_native_token.mdx
index 6b421f52264..9bad03382f4 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/native_tokens/01_mint_native_token.mdx
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/native_tokens/01_mint_native_token.mdx
@@ -26,7 +26,7 @@ import RustOutput from '../../libraries/rust/how_to/native_tokens/_01_mint_nativ
 import TipFaucet from '../../_admonitions/_tip_faucet.md';
 
 You can use a node running the stardust update to mint
-[native tokens](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/tokenization#native-tokens).
+[native tokens](/introduction/stardust/explanations/what_is_stardust/tokenization#native-tokens).
 To do so, you will only need to [add some funds to your account](../accounts_and_addresses/03_request_funds.mdx), define
 the native token's options and call the `Account.mint_native_token(native_token_options, options)` function.
 
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/native_tokens/02_send_native_token.mdx b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/native_tokens/02_send_native_token.mdx
index bbdc3b09215..ac14d9d8673 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/native_tokens/02_send_native_token.mdx
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/native_tokens/02_send_native_token.mdx
@@ -27,12 +27,12 @@ import RustOutput from '../../libraries/rust/how_to/native_tokens/_02_send_nativ
 import ReplaceNativeTokenId from '../../_admonitions/_note_replace_native_token_id.md';
 
 After you have [minted](01_mint_native_token.mdx) a
-[native tokens](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/tokenization#native-tokens),
+[native tokens](/introduction/stardust/explanations/what_is_stardust/tokenization#native-tokens),
 you can easily send it by calling the `Account.send_native_tokens(addresses_native_tokens, options)` function.
 
 As with any output, you can set a
-[storage deposit](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/storage_deposit) and
-[output unlock conditions](https://wiki.iota.org/shimmer/introduction/explanations/what_is_stardust/unlock_conditions).
+[storage deposit](/introduction/stardust/explanations/what_is_stardust/storage_deposit) and
+[output unlock conditions](/introduction/stardust/explanations/what_is_stardust/unlock_conditions).
 Keep in mind that if you set unlock conditions, whoever you send the native tokens to may need to
 [claim them](../outputs_and_transactions/04_claim_outputs.mdx).
 
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/native_tokens/05_destroy_foundry.mdx b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/native_tokens/05_destroy_foundry.mdx
index 5145008fb91..2cafe751b3c 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/native_tokens/05_destroy_foundry.mdx
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/native_tokens/05_destroy_foundry.mdx
@@ -27,14 +27,14 @@ import RustOutput from '../../libraries/rust/how_to/native_tokens/_05_destroy_fo
 
 You can destroy a foundry by calling the `Account.destroy_foundry(foundry_id, options)` function. The function will
 destroy a foundry output as long as its circulating
-[native token](https://wiki.iota.org/shimmer/introduction/explanations/ledger/foundry) supply is zero. Any native tokens
+[native token](/introduction/stardust/explanations/ledger/foundry) supply is zero. Any native tokens
 which were minted by other foundries will be sent to the controlling
-[alias](https://wiki.iota.org/shimmer/introduction/explanations/ledger/alias).
+[alias](/introduction/stardust/explanations/ledger/alias).
 
 ## Code Example
 
 Before you run the example you should update the `foundry_id` to one available in your account that has no available
-[native tokens](https://wiki.iota.org/shimmer/introduction/explanations/ledger/foundry). If you have no available
+[native tokens](/introduction/stardust/explanations/ledger/foundry). If you have no available
 foundries, you can create one by [minting a native token](./01_mint_native_token.mdx). If you've already minted your
 tokens but need to empty the foundry, you can decrease your native token supply by [melting them](./03_melt_native_token.mdx).
 
@@ -43,7 +43,7 @@ The following example will:
 1. Create an account manager.
 2. Get Alice's account which was [created in the first guide](../accounts_and_addresses/01_create_a_wallet_account.mdx).
 3. [Get the account's balance](./../accounts_and_addresses/04_check_balance.mdx).
-4. Destroy a [foundry](https://wiki.iota.org/shimmer/introduction/explanations/ledger/foundry) output by id.
+4. Destroy a [foundry](/introduction/stardust/explanations/ledger/foundry) output by id.
 5. Get the account's balance again to show the difference after step 4.
 
 <Tabs groupId='language' queryString>
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/native_tokens/06_destroy_alias_output.mdx b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/native_tokens/06_destroy_alias_output.mdx
index c0bc0e7770c..2de66d57f18 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/native_tokens/06_destroy_alias_output.mdx
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/native_tokens/06_destroy_alias_output.mdx
@@ -33,7 +33,7 @@ The following example will:
 1. Create an account manager.
 2. Get Alice's account which was [created in the first guide](../accounts_and_addresses/01_create_a_wallet_account.mdx).
 3. [Get the account's balance](./../accounts_and_addresses/04_check_balance.mdx).
-4. Destroy an [alias output](https://wiki.iota.org/shimmer/introduction/explanations/ledger/alias) by id.
+4. Destroy an [alias output](/introduction/stardust/explanations/ledger/alias) by id.
 5. Get the account's balance again to show the difference after step 4.
 
 <Tabs groupId='language' queryString>
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/outputs_and_transactions/01_send_transaction.mdx b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/outputs_and_transactions/01_send_transaction.mdx
index 6f7fb0e0fd4..b0c4d86cf19 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/outputs_and_transactions/01_send_transaction.mdx
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/outputs_and_transactions/01_send_transaction.mdx
@@ -30,9 +30,7 @@ transaction.
 
 <TipFaucet />
 
-<IOTAJsExample
-  exampleURL={'https://wiki.iota.org/iota.js/how_tos/transaction'}
-/>
+<IOTAJsExample exampleURL={'/iota.js/how_tos/transaction'} />
 
 ## Code Example
 
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/outputs_and_transactions/04_claim_outputs.mdx b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/outputs_and_transactions/04_claim_outputs.mdx
index b6734c76932..03aeb2d8357 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/outputs_and_transactions/04_claim_outputs.mdx
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/outputs_and_transactions/04_claim_outputs.mdx
@@ -26,7 +26,7 @@ import RustCode from '../../_admonitions/_guide_coming_soon.md';
 import RustOutput from '../../_admonitions/_guide_coming_soon.md';
 
 You can use wallet.rs to send
-[funds with an expiration](https://wiki.iota.org/shimmer/introduction/explanations/ledger/simple_transfers#transfer-of-funds-with-expiration).
+[funds with an expiration](/introduction/stardust/explanations/ledger/simple_transfers#transfer-of-funds-with-expiration).
 If you don't claim these funds within the expiration period, they will be returned to the sender.
 
 ## Code Example
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/outputs_and_transactions/06_check_unlock_conditions.mdx b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/outputs_and_transactions/06_check_unlock_conditions.mdx
index 962b31a24fd..3c65c63de02 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/outputs_and_transactions/06_check_unlock_conditions.mdx
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/outputs_and_transactions/06_check_unlock_conditions.mdx
@@ -23,7 +23,7 @@ import JavaOutput from '../../libraries/java/how_to/outputs_and_transactions/_06
 import RustCode from '../../libraries/rust/how_to/outputs_and_transactions/_06_check_unlock_conditions/_code_sample.mdx';
 import RustOutput from '../../libraries/rust/how_to/outputs_and_transactions/_06_check_unlock_conditions/_expected_output.md';
 
-Outputs may have multiple [UnlockConditions](https://wiki.iota.org/shimmer/tips/tips/TIP-0018/#unlock-conditions), which may require [returning some or all of the transferred amount](https://wiki.iota.org/shimmer/tips/tips/TIP-0018/#storage-deposit-return-unlock-condition). The outputs could also [expire if not claimed in time](https://wiki.iota.org/shimmer/tips/tips/TIP-0018/#expiration-unlock-condition), or may not be [unlockable for a predefined period](https://wiki.iota.org/shimmer/tips/tips/TIP-0018/#timelock-unlock-condition).
+Outputs may have multiple [UnlockConditions](/tips/tips/TIP-0018#unlock-conditions), which may require [returning some or all of the transferred amount](/tips/tips/TIP-0018#storage-deposit-return-unlock-condition). The outputs could also [expire if not claimed in time](/tips/tips/TIP-0018#expiration-unlock-condition), or may not be [unlockable for a predefined period](/tips/tips/TIP-0018#timelock-unlock-condition).
 
 ## Code Example
 
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/run_how_tos.mdx b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/run_how_tos.mdx
index 89c086065e0..0cb93f4e253 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/run_how_tos.mdx
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/run_how_tos.mdx
@@ -36,11 +36,11 @@ carry on to the next guide.
 
 ### Hornet Node
 
-Most of the examples require a [Hornet Node](https://wiki.iota.org/shimmer/hornet/welcome) running the
-[Stardust](https://wiki.iota.org/shimmer/introduction/welcome) upgrade. You can connect to the
+Most of the examples require a [Hornet Node](/hornet/welcome) running the
+[Stardust](/introduction/stardust/welcome) upgrade. You can connect to the
 [Shimmer Testnet](#shimmer-testnet), a node you trust,
-[run your own node](https://wiki.iota.org/shimmer/hornet/how_tos/using_docker) or
-[run a local private tangle](https://wiki.iota.org/shimmer/hornet/how_tos/private_tangle).
+[run your own node](/hornet/how_tos/using_docker) or
+[run a local private tangle](/hornet/2.0.0-rc.6/how_tos/private_tangle).
 
 #### Shimmer Testnet
 
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/use-python-with-IOTA.mdx b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/use-python-with-IOTA.mdx
index 07e65aa680f..912fff520ca 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/use-python-with-IOTA.mdx
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/how_tos/use-python-with-IOTA.mdx
@@ -22,7 +22,7 @@ First install the Shimmer version following the [installation guide](/getting_st
 
 ### Install IOTA Version
 
-To install the IOTA version you need to follow the [Install from source](https://wiki.iota.org/wallet.rs/getting_started/python#install-from-source) guide.
+To install the IOTA version you need to follow the [Install from source](/wallet.rs/getting_started/python#install-from-source) guide.
 Before you continue with the steps after having cloned the repo, we need to apply some changes to the repo first.
 
 :::info
@@ -41,7 +41,7 @@ In `wallet/bindings/python/native/Cargo.toml` change both names:
   authors = ["IOTA Stiftung"]
   edition = "2021"
   description = "Python bindings for the IOTA wallet library"
-  documentation = "https://wiki.iota.org/wallet.rs/welcome"
+  documentation = "/wallet.rs/welcome"
   homepage = "https://www.iota.org/"
   repository = "https://github.com/iotaledger/wallet.rs"
   license = "Apache-2.0"
@@ -86,7 +86,7 @@ And in `wallet/bindings/python/native/src/lib.rs`:
       .
 ```
 
-Now you can continue the installation from [here](https://wiki.iota.org/wallet.rs/getting_started/python#change-to-the-python-binding-directory).
+Now you can continue the installation from [here](/wallet.rs/getting_started/python#change-to-the-python-binding-directory).
 
 ### Usage
 
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/libraries/java/how_to/_run_how_tos.mdx b/docs/build/wallet.rs/1.0.0-rc.6/docs/libraries/java/how_to/_run_how_tos.mdx
index 9687727b3d3..a42b6428081 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/libraries/java/how_to/_run_how_tos.mdx
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/libraries/java/how_to/_run_how_tos.mdx
@@ -13,7 +13,7 @@ the following variables:
 https://github.com/iotaledger/wallet.rs/tree/develop/wallet/.env.example
 ```
 
-The `.env.example` uses public [Shimmer Beta](https://wiki.iota.org/shimmer/introduction/reference/networks/betanet/)
+The `.env.example` uses public [Shimmer Beta](/build/networks-endpoints#public-testnet)
 URLS. If you want to use another node, you should update the `NODE_URL` and `FAUCET_URL` values to match the
 [Hornet node](#hornet-node) you want to use.
 
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/libraries/nodejs/how_to/_run_how_tos.mdx b/docs/build/wallet.rs/1.0.0-rc.6/docs/libraries/nodejs/how_to/_run_how_tos.mdx
index bd60286468e..25bcf27ec62 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/libraries/nodejs/how_to/_run_how_tos.mdx
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/libraries/nodejs/how_to/_run_how_tos.mdx
@@ -13,7 +13,7 @@ the following variables:
 https://github.com/iotaledger/wallet.rs/tree/develop/wallet/.env.example
 ```
 
-The `.env.example` uses public [Shimmer Beta](https://wiki.iota.org/shimmer/introduction/reference/networks/betanet/)
+The `.env.example` uses public [Shimmer Beta](/build/networks-endpoints#public-testnet)
 URLS. If you want to use another node, you should update the `NODE_URL` and `FAUCET_URL` values to match the
 [Hornet node](#hornet-node) you want to use.
 
diff --git a/docs/build/wallet.rs/1.0.0-rc.6/docs/libraries/rust/how_to/_run_how_tos.mdx b/docs/build/wallet.rs/1.0.0-rc.6/docs/libraries/rust/how_to/_run_how_tos.mdx
index 0bd3d788331..05a9ceaec35 100644
--- a/docs/build/wallet.rs/1.0.0-rc.6/docs/libraries/rust/how_to/_run_how_tos.mdx
+++ b/docs/build/wallet.rs/1.0.0-rc.6/docs/libraries/rust/how_to/_run_how_tos.mdx
@@ -13,7 +13,7 @@ the following variables:
 https://github.com/iotaledger/wallet.rs/tree/develop/wallet/.env.example
 ```
 
-The `.env.example` uses public [Shimmer Beta](https://wiki.iota.org/shimmer/introduction/reference/networks/betanet/)
+The `.env.example` uses public [Shimmer Beta](/build/networks-endpoints#public-testnet)
 URLS. If you want to use another node, you should update the `NODE_URL` and `FAUCET_URL` values to match the
 [Hornet node](#hornet-node) you want to use.
 
diff --git a/docs/build/wasp/0.7.0/docs/guide/evm/examples/ERC20.md b/docs/build/wasp/0.7.0/docs/guide/evm/examples/ERC20.md
index 70444959668..39d58e403f7 100644
--- a/docs/build/wasp/0.7.0/docs/guide/evm/examples/ERC20.md
+++ b/docs/build/wasp/0.7.0/docs/guide/evm/examples/ERC20.md
@@ -18,14 +18,14 @@ keywords:
 
 - [Remix IDE](https://remix.ethereum.org/).
 - [A Metamask Wallet](https://metamask.io/).
-- [Connect your MetaMask with the public Testnet](../../tooling/#metamask).
+- [Connect your MetaMask with the public Testnet](../../tooling#metamask).
 
 ### Required Prior Knowledge
 
 This guide assumes you are familiar with [tokens](https://en.wikipedia.org/wiki/Cryptocurrency#Crypto_token)
 in [blockchain](https://en.wikipedia.org/wiki/Blockchain),
 [Ethereum Request for Comments (ERCs)](https://eips.ethereum.org/erc)(also known as Ethereum Improvement Proposals (EIP))
-, [NFTs](https://wiki.iota.org/learn/future/nfts), [Smart Contracts](/learn/smart-contracts/core_concepts/smart-contracts) and have
+, [NFTs](learn/protocols/stardust/core-concepts/multi-asset-ledger#non-fungible-tokens-nfts), [Smart Contracts](/learn/smart-contracts/core_concepts/smart-contracts) and have
 already tinkered with [Solidity](https://docs.soliditylang.org/en/v0.8.16/).
 ERC20 is a standard for fungible tokens and is defined in
 the [EIP-20 Token Standard](https://eips.ethereum.org/EIPS/eip-20) by Ethereum.
@@ -39,7 +39,7 @@ You can use the [Remix IDE](https://remix.ethereum.org/) to deploy any regular S
 
 Set the environment to `Injected Web3` and connect Remix with your MetaMask wallet.
 If you haven’t already, please follow the instructions
-on [how to connect your MetaMask with the public Testnet.](../../tooling/#metamask).
+on [how to connect your MetaMask with the public Testnet.](../../tooling#metamask).
 
 ## 1. Create a Smart Contract
 
diff --git a/docs/build/wasp/0.7.0/docs/guide/evm/examples/ERC721.md b/docs/build/wasp/0.7.0/docs/guide/evm/examples/ERC721.md
index 395c2ee2564..0a5ce8585f3 100644
--- a/docs/build/wasp/0.7.0/docs/guide/evm/examples/ERC721.md
+++ b/docs/build/wasp/0.7.0/docs/guide/evm/examples/ERC721.md
@@ -25,7 +25,7 @@ NFTs.
 
 - [Remix IDE](https://remix.ethereum.org/).
 - [A Metamask Wallet](https://metamask.io/).
-- [Connect your MetaMask with the public Testnet](../../tooling/#metamask).
+- [Connect your MetaMask with the public Testnet](../../tooling#metamask).
 
 ### Required Prior Knowledge
 
@@ -33,7 +33,7 @@ This guide assumes you are familiar with [tokens](https://en.wikipedia.org/wiki/
 in [blockchain](https://en.wikipedia.org/wiki/Blockchain),
 [Ethereum Request for Comments (ERCs)](https://eips.ethereum.org/erc)(also known as Ethereum Improvement Proposals (
 EIP))
-, [NFTs](https://wiki.iota.org/learn/future/nfts), [Smart Contracts](/learn/smart-contracts/core_concepts/smart-contracts) and have
+, [NFTs](/learn/protocols/stardust/core-concepts/multi-asset-ledger#non-fungible-tokens-nfts), [Smart Contracts](/learn/smart-contracts/core_concepts/smart-contracts) and have
 already tinkered with [Solidity](https://docs.soliditylang.org/en/v0.8.16/).
 
 ## About ERC721
@@ -144,7 +144,7 @@ task. If you are using hardhat or truffle, you should customize the config file
 ### Connect to the ISC Testnet
 
 You can find instructions on this in
-the [testnet endpoints section](https://wiki.iota.org/smart-contracts/guide/chains_and_nodes/testnet#endpoints).
+the [testnet endpoints section](/smart-contracts/testnet#endpoints).
 
 ### Change the Environment to Injected Web3
 
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/example_projects/fair_roulette.md b/docs/build/wasp/0.7.0/docs/guide/wasm_vm/example_projects/fair_roulette.md
index 35a99dba3f6..e863018d6b9 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/example_projects/fair_roulette.md
+++ b/docs/build/wasp/0.7.0/docs/guide/wasm_vm/example_projects/fair_roulette.md
@@ -36,7 +36,7 @@ Therefore the roulette is Fair.
 
 The mandatory setup consists out of:
 
-- 1 [GoShimmer](https://wiki.iota.org/goshimmer/welcome) node >= 0.7.5v ([25c827e8326a](https://github.com/iotaledger/goshimmer/commit/25c827e8326a))
+- 1 [GoShimmer](/goshimmer/welcome) node >= 0.7.5v ([25c827e8326a](https://github.com/iotaledger/goshimmer/commit/25c827e8326a))
 - 1 Beta [Wasp node](/wasp/running-a-node).
 - 1 Static file server (nginx, Apache, fasthttp)
 
@@ -74,7 +74,7 @@ As these requests cost some fees, and to be able to bet with real tokens, the pl
 
 As the game runs on a testnet, you can request funds from the GoShimmer faucets inside the network.
 
-See: [How to Obtain Tokens From the Faucet](https://wiki.iota.org/goshimmer/tutorials/obtain_tokens)
+See: [How to Obtain Tokens From the Faucet](/goshimmer/tutorials/obtain_tokens)
 
 After you have acquired some funds, they will reside inside an address that is handled by a wallet.
 
@@ -105,7 +105,7 @@ This frontend sends On-ledger requests to place bets towards the fair roulette s
 
 ### The Smart Contract
 
-See: [Anatomy of a Smart Contract](https://wiki.iota.org/wasp/guide/core_concepts/smart-contract-anatomy)
+See: [Anatomy of a Smart Contract](/learn/smart-contracts/core_concepts/smart-contract-anatomy)
 
 As the smart contract is the only actor that is allowed to modify state in the context of the game, it needs to handle a few tasks such as:
 
@@ -167,7 +167,7 @@ However, there is a bit more to the concept than to simply subscribe to a web so
 
 On and Off Ledger requests have a predefined structure. They need to get encoded strictly and include a list of transactions provided by Goshimmer. They also need to get signed by the client using the private key originating from a seed.
 
-Wasp uses the [ExtendedLockedOutput](https://wiki.iota.org/goshimmer/protocol_specification/components/advanced_outputs) message type, which enables certain additional properties such as:
+Wasp uses the [ExtendedLockedOutput](/goshimmer/protocol_specification/components/advanced_outputs) message type, which enables certain additional properties such as:
 
 - A fallback address and a fallback timeout
 - Unlockable by AliasUnlockBlock (if address is of Misaddress type)
@@ -232,13 +232,13 @@ This transaction also requires an address to send the request to, and also a var
 For Wasp, the address to send funds to is the chainId.
 :::
 
-See: [CoreTypes](https://wiki.iota.org/wasp/misc/coretypes) and [Invoking](https://wiki.iota.org/wasp/guide/solo/invoking-sc)
+See: [Invoking](/smart-contracts/guide/solo/invoking-sc)
 
 ##### CallView
 
 The [callView](https://github.com/iotaledger/wasp/blob/7b3ddc54891ccf021c7aaa32db35d88361fade16/contracts/wasm/fairroulette/frontend/src/lib/fairroulette_client/fair_roulette_service.ts#L165) function is responsible for calling smart contract view functions.
 
-See: [Calling a view](https://wiki.iota.org/wasp/guide/solo/view-sc)
+See: [Calling a view](/smart-contracts/guide/solo/view-sc)
 
 To give access to the smart contracts state, you can use view functions to return selected parts of the state.
 
diff --git a/docs/build/zebra-iota-edge-sdk/tutorials/in-app-tutorial.md b/docs/build/zebra-iota-edge-sdk/tutorials/in-app-tutorial.md
index 36e08472530..9fe70a39f21 100644
--- a/docs/build/zebra-iota-edge-sdk/tutorials/in-app-tutorial.md
+++ b/docs/build/zebra-iota-edge-sdk/tutorials/in-app-tutorial.md
@@ -13,9 +13,9 @@ For each step, a function is defined that you should be able to reuse in your ap
 
 ## Before you begin
 
-If you are unfamiliar with W3C Decentralized Identifiers (DID) and Verifiable Credentials (VCs), we recommend reading the overviews of chapters 2, 3.1 and 3.2 of the [IOTA Identity guide](https://wiki.iota.org/identity.rs/introduction).
+If you are unfamiliar with W3C Decentralized Identifiers (DID) and Verifiable Credentials (VCs), we recommend reading the overviews of chapters 2, 3.1 and 3.2 of the [IOTA Identity guide](/identity.rs/introduction).
 
-The IOTA Identity framework is implemented in Rust. In order to use it in JavaScript, WASM bindings are available from the NPM package `@iota/identity-wasm`. Please refer to [IOTA Identity WASM - Getting Started](https://wiki.iota.org/identity.rs/libraries/wasm/getting_started) for set up instructions in both NodeJS and web (browser) contexts. This tutorial assumes a web context, but code comments show where usage is not the same as in NodeJS.
+The IOTA Identity framework is implemented in Rust. In order to use it in JavaScript, WASM bindings are available from the NPM package `@iota/identity-wasm`. Please refer to [IOTA Identity WASM - Getting Started](/identity.rs/libraries/wasm/getting_started) for set up instructions in both NodeJS and web (browser) contexts. This tutorial assumes a web context, but code comments show where usage is not the same as in NodeJS.
 
 To complete the tutorial, you will need the following imports:
 
@@ -207,4 +207,4 @@ run()
 
 ## Further Reading
 
-To engross yourself further, please refer to the [IOTA Identity Wiki](https://wiki.iota.org/identity.rs/introduction) and the [GitHub repository](https://github.com/iotaledger/identity.rs).
+To engross yourself further, please refer to the [IOTA Identity Wiki](/identity.rs/introduction) and the [GitHub repository](https://github.com/iotaledger/identity.rs).
diff --git a/docs/get-started/faq.md b/docs/get-started/faq.md
index 66c617cd806..1fc54e0af5d 100644
--- a/docs/get-started/faq.md
+++ b/docs/get-started/faq.md
@@ -3,7 +3,7 @@ title: FAQ's
 description: Questions and answers collections. Clear outlined information for the most common questions around IOTA.
 ---
 
-- [Chrysalis mainnet FAQ](https://wiki.iota.org/introduction/explanations/faq/)
-- [Firefly wallet FAQ](https://wiki.iota.org/use/wallets/firefly/faq-and-troubleshooting)
+- [Chrysalis mainnet FAQ](/introduction/explanations/faq/)
+- [Firefly wallet FAQ](/use/wallets/firefly/faq-and-troubleshooting)
 - [Identity FAQ](http://localhost:3000/identity.rs/faq/)
-- [GoShimmer devnet FAQ](https://wiki.iota.org/goshimmer/faq/)
+- [GoShimmer devnet FAQ](/goshimmer/faq/)
diff --git a/docs/get-started/introduction/iota/introduction.md b/docs/get-started/introduction/iota/introduction.md
index dcfabdf6fb3..64d2e04bd4b 100644
--- a/docs/get-started/introduction/iota/introduction.md
+++ b/docs/get-started/introduction/iota/introduction.md
@@ -33,8 +33,8 @@ performant consensus and ledger solution.
 
 ## IOTA Mainnet
 
-The IOTA mainnet is the production grade network on which the [IOTA token](/get-started/introduction/iota/iota-token/)
-is available. It currently runs the [Chrysalis protocol version](/learn/protocols/chrysalis/introduction/).
+The IOTA mainnet is the production grade network on which the [IOTA token](/get-started/introduction/iota/iota-token)
+is available. It currently runs the [Chrysalis protocol version](/learn/protocols/chrysalis/introduction).
 
 ## Feeless Transactions
 
@@ -51,6 +51,6 @@ based in Berlin, Germany.
 
 The IOTA protocol is continuously evolving through research and development. It consists of two main public networks:
 the IOTA mainnet, which is the production-level network managing IOTA tokens, and
-the [Shimmer the staging network](/get-started/introduction/shimmer/introduction/) for testing and deploying the
+the [Shimmer the staging network](/get-started/introduction/shimmer/introduction) for testing and deploying the
 latest protocol updates. The Shimmer network acts as a testing ground to validate new features and improvements before
 they are implemented on the IOTA mainnet.
diff --git a/docs/get-started/introduction/shimmer/introduction.md b/docs/get-started/introduction/shimmer/introduction.md
index ed00426b3df..811eb5d6c2c 100644
--- a/docs/get-started/introduction/shimmer/introduction.md
+++ b/docs/get-started/introduction/shimmer/introduction.md
@@ -18,11 +18,11 @@ keywords:
 
 Shimmer acts as the production-grade staging network for the IOTA mainnet where new protocol changes are introduced and
 evaluated for functionality, scalability, and security before they are made available on the IOTA mainnet. However,
-unlike most staging networks, Shimmer has a [token called SMR](/get-started/introduction/shimmer/shimmer-token/), which
+unlike most staging networks, Shimmer has a [token called SMR](/get-started/introduction/shimmer/shimmer-token), which
 is traded on major exchanges, thus giving the network real monetary value, which in turn is beneficial to foster the
 testing of upcoming protocol changes even further.
 
-Currently, Shimmer runs the [Stardust protocol](/learn/protocols/stardust/introduction/) version, enabling tokenization and the anchoring of L2 smart contract
+Currently, Shimmer runs the [Stardust protocol](/learn/protocols/stardust/introduction) version, enabling tokenization and the anchoring of L2 smart contract
 chains into L1.
 
 Shimmer is also the network on which the Shimmer EVM runs, an L2 solution that provides smart contract
diff --git a/docs/get-started/introduction/shimmer/shimmer-token.md b/docs/get-started/introduction/shimmer/shimmer-token.md
index b39709582df..fbb0e438b34 100644
--- a/docs/get-started/introduction/shimmer/shimmer-token.md
+++ b/docs/get-started/introduction/shimmer/shimmer-token.md
@@ -38,7 +38,7 @@ participation, community engagement, and innovation within the Shimmer ecosystem
 ### IOTA Stakers Allocation
 
 A significant portion of the Shimmer tokens, accounting for 80% of the total supply, is allocated to IOTA stakers. This
-amounts to 1,450,896,407 SMR tokens. IOTA token holders who [staked their tokens had the opportunity](/get-started/introduction/iota/staking/#iota-staking-for-smr-rewards) to receive SMR tokens as rewards for participating in the IOTA mainnet.
+amounts to 1,450,896,407 SMR tokens. IOTA token holders who [staked their tokens had the opportunity](/get-started/introduction/iota/staking#iota-staking-for-smr-rewards) to receive SMR tokens as rewards for participating in the IOTA mainnet.
 
 ### Community DAO Allocation
 
diff --git a/docs/learn/governance/shimmer-governance-intro.md b/docs/learn/governance/shimmer-governance-intro.md
index 65fa55e0c42..90b49987534 100644
--- a/docs/learn/governance/shimmer-governance-intro.md
+++ b/docs/learn/governance/shimmer-governance-intro.md
@@ -20,7 +20,7 @@ The Shimmer community, supported by the IOTA Foundation, has developed a Governa
 
 **3. Fully utilized decentralized and immutable On-Chain Governance [voting functionality](./governance-tech.md)** integrated into the [Firefly Shimmer Wallet](https://firefly.iota.org/) and the [Hornet Nodes](/hornet/2.0.0-rc.6/welcome). This allows every SMR Token holder to make decisions in the SMR network based on proposals passed through the forum's governance process. Voting is a protocol feature of L1, so no Smart Contracts are needed for this type of voting.
 
-Governance processes in SMR are defined in the **[Shimmer Governance Framework](https://wiki.iota.org/shimmer/learn/governance/the-shimmer-governance-framework.md)**. This framework has been developed by the Community Governance working group in many months of discussions and is the foundational building block of how Governance in SMR works.
+Governance processes in SMR are defined in the **[Shimmer Governance Framework](./the-shimmer-governance-framework.md)**. This framework has been developed by the Community Governance working group in many months of discussions and is the foundational building block of how Governance in SMR works.
 It mainly defines:
 
 - Who are the stakeholders, and their roles in Governance processes?
@@ -72,9 +72,9 @@ This feature consists of 2 components:
     - **Counting:** Now all participating Nodes are actively counting and accumulating votes on this proposal. The longer a user keeps its tokens actively voting on this proposal. The more votes will be counted for the user. Users can change their voting power and opinions during the counting phase. Still, this change only influences the future count from the time of the change and does not influence the already counted votes of a user on this proposal.
     - **Ended:** The Proposal counting is over, and the final vote result is displayed.
 
-A detailed technical description of this voting functionality can be found in the [Governance - tech](https://wiki.iota.org/shimmer/learn/governance/governance-tech.md) section of the Wiki.
+A detailed technical description of this voting functionality can be found in the [Governance - tech](./governance-tech.md) section of the Wiki.
 
-A detailed description of how to participate in Governance votes can be found in the [Firefly Shimmer Governance Guide](https://wiki.iota.org/shimmer/learn/governance/shimmer-firefly-governance-guide.md)
+A detailed description of how to participate in Governance votes can be found in the [Firefly Shimmer Governance Guide](./shimmer-firefly-governance-guide.md)
 
 ### Shimmer Governance Resources
 
diff --git a/docs/learn/protocols/chrysalis/core-concepts/EdDSA-support.md b/docs/learn/protocols/chrysalis/core-concepts/EdDSA-support.md
index ad37b928d22..3d2168c1664 100644
--- a/docs/learn/protocols/chrysalis/core-concepts/EdDSA-support.md
+++ b/docs/learn/protocols/chrysalis/core-concepts/EdDSA-support.md
@@ -42,6 +42,6 @@ benefiting users who have network usage constraints or wish to minimize data tra
 
 :::tip Learn More
 
-You can learn more about the [Ed25519 signature in IOTA](https://wiki.iota.org/tips/tips/TIP-0014) in the [TIPS section](../tips.md).
+You can learn more about the [Ed25519 signature in IOTA](/tips/tips/TIP-0014) in the [TIPS section](../tips.md).
 
 :::
diff --git a/docs/learn/protocols/chrysalis/core-concepts/binary-transaction-layout.md b/docs/learn/protocols/chrysalis/core-concepts/binary-transaction-layout.md
index 8f390abf32e..41ac90d45a3 100644
--- a/docs/learn/protocols/chrysalis/core-concepts/binary-transaction-layout.md
+++ b/docs/learn/protocols/chrysalis/core-concepts/binary-transaction-layout.md
@@ -47,8 +47,8 @@ potentially slowing development and increasing complexity.
 
 :::tip Learn More
 
-You can learn more about the [Binary to ternary conversion](https://wiki.iota.org/tips/tips/TIP-0005/),
-[transaction payloads](https://wiki.iota.org/tips/tips/TIP-0007/),
-and [Tangle messages](https://wiki.iota.org/tips/tips/TIP-0006/) in the [TIPS section](../tips.md).
+You can learn more about the [Binary to ternary conversion](/tips/tips/TIP-0005/),
+[transaction payloads](/tips/tips/TIP-0007/),
+and [Tangle messages](/tips/tips/TIP-0006/) in the [TIPS section](../tips.md).
 
 :::
diff --git a/docs/learn/protocols/chrysalis/core-concepts/switch-to-UTXO.md b/docs/learn/protocols/chrysalis/core-concepts/switch-to-UTXO.md
index ac2d98cef70..1bfe96a806b 100644
--- a/docs/learn/protocols/chrysalis/core-concepts/switch-to-UTXO.md
+++ b/docs/learn/protocols/chrysalis/core-concepts/switch-to-UTXO.md
@@ -58,7 +58,7 @@ meaning that addresses in Chrysalis are reusable and can be safely used to send
 
 :::tip Learn More
 
-You can learn more about the [switch to UTXO](https://wiki.iota.org/tips/tips/TIP-0007) and
-[Ed25519](https://wiki.iota.org/tips/tips/TIP-0017/) in the [TIPS section](../tips.md).
+You can learn more about the [switch to UTXO](/tips/tips/TIP-0007) and
+[Ed25519](/tips/tips/TIP-0017/) in the [TIPS section](../tips.md).
 
 :::
diff --git a/docs/learn/protocols/chrysalis/core-concepts/white-flag-consensus.md b/docs/learn/protocols/chrysalis/core-concepts/white-flag-consensus.md
index 584a3bbb815..5932e84bfbc 100644
--- a/docs/learn/protocols/chrysalis/core-concepts/white-flag-consensus.md
+++ b/docs/learn/protocols/chrysalis/core-concepts/white-flag-consensus.md
@@ -50,7 +50,7 @@ The White Flag Consensus approach offers several key benefits:
 
 :::tip Learn More
 
-You can learn more about the [White Flag Consensus in IOTA](https://wiki.iota.org/tips/tips/TIP-0002) in the
+You can learn more about the [White Flag Consensus in IOTA](/tips/tips/TIP-0002) in the
 [TIPS section](../tips.md).
 
 :::
diff --git a/docs/learn/protocols/chrysalis/tips.md b/docs/learn/protocols/chrysalis/tips.md
index 9a156a50e56..3bced98a613 100644
--- a/docs/learn/protocols/chrysalis/tips.md
+++ b/docs/learn/protocols/chrysalis/tips.md
@@ -2,21 +2,21 @@
 
 The following Tangle Improvement Proposals (TIPs) are currently implemented in the IOTA protocol.
 
-| #   | Title                                                                    | Description                                                                      | Type      | Layer     | Status | Initial Target |
-| --- | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------- | --------- | --------- | ------ | -------------- |
-| 1   | [TIP Process](https://wiki.iota.org/tips/tips/TIP-0001)                  | Purpose and guidelines of the contribution framework                             | Process   | -         | Active | -              |
-| 2   | [White Flag Ordering](https://wiki.iota.org/tips/tips/TIP-0002)          | Mitigate conflict spamming by ignoring conflicts                                 | Standards | Core      | Active | Chrysalis      |
-| 3   | [Uniform Random Tip Selection](https://wiki.iota.org/tips/tips/TIP-0003) | Perform fast tip-selection to increase message throughput                        | Standards | Core      | Active | Chrysalis      |
-| 4   | [Milestone Merkle Validation](https://wiki.iota.org/tips/tips/TIP-0004)  | Add Merkle tree hash to milestone for local ledger state verification            | Standards | Core      | Active | Chrysalis      |
-| 5   | [Binary To Ternary Encoding](https://wiki.iota.org/tips/tips/TIP-0005)   | Define the conversion between binary and ternary data                            | Standards | Core      | Active | Chrysalis      |
-| 6   | [Tangle Message](https://wiki.iota.org/tips/tips/TIP-0006)               | Generalization of the Tangle transaction concept                                 | Standards | Core      | Active | Chrysalis      |
-| 7   | [Transaction Payload](https://wiki.iota.org/tips/tips/TIP-0007)          | UTXO-based transaction structure                                                 | Standards | Core      | Active | Chrysalis      |
-| 8   | [Milestone Payload](https://wiki.iota.org/tips/tips/TIP-0008)            | Coordinator issued milestone structure with Ed25519 authentication               | Standards | Core      | Active | Chrysalis      |
-| 9   | [Local Snapshot File Format](https://wiki.iota.org/tips/tips/TIP-0009)   | File format to export/import ledger state                                        | Standards | Interface | Active | Chrysalis      |
-| 11  | [Bech32 Address Format](https://wiki.iota.org/tips/tips/TIP-0011)        | Extendable address format supporting various signature schemes and address types | Standards | Interface | Active | Chrysalis      |
-| 12  | [Message PoW](https://wiki.iota.org/tips/tips/TIP-0012)                  | Define message proof-of-work as a means to rate-limit the network                | Standards | Core      | Active | Chrysalis      |
-| 13  | [REST API](https://wiki.iota.org/tips/tips/TIP-0013)                     | Node REST API routes and objects in OpenAPI Specification                        | Standards | Interface | Active | Chrysalis      |
-| 14  | [Ed25519 Validation](https://wiki.iota.org/tips/tips/TIP-0014)           | Explicitly define Ed25519 validation criteria                                    | Standards | Core      | Active | Chrysalis      |
-| 15  | [Dust Protection](https://wiki.iota.org/tips/tips/TIP-0015)              | Prevent bloating the ledger size with to dust outputs                            | Standards | Core      | Active | Chrysalis      |
-| 16  | [Event API](https://wiki.iota.org/tips/tips/TIP-0016)                    | Node event API definitions in AsyncAPI Specification                             | Standards | Interface | Active | Chrysalis      |
-| 17  | [Wotsicide](https://wiki.iota.org/tips/tips/TIP-0017)                    | Define migration from legacy WOTS addresses to post-Chrysalis Phase 2 network    | Standards | Core      | Active | Chrysalis      |
+| #   | Title                                               | Description                                                                      | Type      | Layer     | Status | Initial Target |
+| --- | --------------------------------------------------- | -------------------------------------------------------------------------------- | --------- | --------- | ------ | -------------- |
+| 1   | [TIP Process](/tips/tips/TIP-0001)                  | Purpose and guidelines of the contribution framework                             | Process   | -         | Active | -              |
+| 2   | [White Flag Ordering](/tips/tips/TIP-0002)          | Mitigate conflict spamming by ignoring conflicts                                 | Standards | Core      | Active | Chrysalis      |
+| 3   | [Uniform Random Tip Selection](/tips/tips/TIP-0003) | Perform fast tip-selection to increase message throughput                        | Standards | Core      | Active | Chrysalis      |
+| 4   | [Milestone Merkle Validation](/tips/tips/TIP-0004)  | Add Merkle tree hash to milestone for local ledger state verification            | Standards | Core      | Active | Chrysalis      |
+| 5   | [Binary To Ternary Encoding](/tips/tips/TIP-0005)   | Define the conversion between binary and ternary data                            | Standards | Core      | Active | Chrysalis      |
+| 6   | [Tangle Message](/tips/tips/TIP-0006)               | Generalization of the Tangle transaction concept                                 | Standards | Core      | Active | Chrysalis      |
+| 7   | [Transaction Payload](/tips/tips/TIP-0007)          | UTXO-based transaction structure                                                 | Standards | Core      | Active | Chrysalis      |
+| 8   | [Milestone Payload](/tips/tips/TIP-0008)            | Coordinator issued milestone structure with Ed25519 authentication               | Standards | Core      | Active | Chrysalis      |
+| 9   | [Local Snapshot File Format](/tips/tips/TIP-0009)   | File format to export/import ledger state                                        | Standards | Interface | Active | Chrysalis      |
+| 11  | [Bech32 Address Format](/tips/tips/TIP-0011)        | Extendable address format supporting various signature schemes and address types | Standards | Interface | Active | Chrysalis      |
+| 12  | [Message PoW](/tips/tips/TIP-0012)                  | Define message proof-of-work as a means to rate-limit the network                | Standards | Core      | Active | Chrysalis      |
+| 13  | [REST API](/tips/tips/TIP-0013)                     | Node REST API routes and objects in OpenAPI Specification                        | Standards | Interface | Active | Chrysalis      |
+| 14  | [Ed25519 Validation](/tips/tips/TIP-0014)           | Explicitly define Ed25519 validation criteria                                    | Standards | Core      | Active | Chrysalis      |
+| 15  | [Dust Protection](/tips/tips/TIP-0015)              | Prevent bloating the ledger size with to dust outputs                            | Standards | Core      | Active | Chrysalis      |
+| 16  | [Event API](/tips/tips/TIP-0016)                    | Node event API definitions in AsyncAPI Specification                             | Standards | Interface | Active | Chrysalis      |
+| 17  | [Wotsicide](/tips/tips/TIP-0017)                    | Define migration from legacy WOTS addresses to post-Chrysalis Phase 2 network    | Standards | Core      | Active | Chrysalis      |
diff --git a/docs/learn/protocols/introduction.md b/docs/learn/protocols/introduction.md
index 31ac8592e7b..4781aca7860 100644
--- a/docs/learn/protocols/introduction.md
+++ b/docs/learn/protocols/introduction.md
@@ -17,10 +17,10 @@ keywords: [
 
 This page provides an overview around the different protocol versions within the IOTA ecosystem.
 
-| Name                                                         | Release Date               | Description                                                                                                                                                                                                                                                                                                                                             | Consensus                                         | Features                                                                                               | Networks                                                                                                   |
-| ------------------------------------------------------------ | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------- |
-| Legacy Trinary                                               | 2016                       | Based on a [probabilistic consensus algorithm using random walks on a DAG](https://assets.ctfassets.net/r1dr6vzfxhev/2t4uxvsIqk0EUau6g2sw0g/45eae33637ca92f85dd9f4a3a218e1ec/iota1_4_3.pdf), the original version of the IOTA protocol                                                                                                                  | [PoA - Coordinator](/learn/protocols/coordinator) | Bundles, trinary                                                                                       | -                                                                                                          |
-| [Chrysalis Phase 1](/learn/protocols/chrysalis/introduction) | August 2020 (IOTA Mainnet) | Replaced the heavy probabilistic consensus algorithm to use the [White-Flag approach](/learn/protocols/chrysalis/core-concepts/white-flag-consensus) instead                                                                                                                                                                                            | [PoA - Coordinator](/learn/protocols/coordinator) | White-Flag Confirmation                                                                                | [Legacy IOTA Mainnet](/build/networks-endpoints/#legacy)                                                   |
-| [Chrysalis Phase 2](/learn/protocols/chrysalis/introduction) | April 2021 (IOTA Mainnet)  | Switched from trinary to binary for data representation, changed from an account model to UTXO, removed Winternitz One Time Signatures (WOTS) and introduced EdDSA, dust protection and a complete overhaul of all APIs                                                                                                                                 | [PoA - Coordinator](/learn/protocols/coordinator) | Binary, EdDSA, UTXO, Removal of WOTS                                                                   | [IOTA Mainnet](/build/networks-endpoints/#iota-mainnet), [DevNet](/build/networks-endpoints/#devnet)       |
-| [Stardust](/learn/protocols/stardust/introduction)           | September 2022 (Shimmer)   | Upgraded the ledger to support multiple assets instead of just the base token, switched the dust protection to a more granular one based on exact byte costs, renamed vertices from "messages" to "blocks", introduced concepts such as `FoundryOutput`, `AliasOutput` and `NFTOutput`. Also added the foundation for ISC anchoring via `AliasOutput`s. | [PoA - Coordinator](/learn/protocols/coordinator) | Multi-Asset Ledger, ISC support, Byte Cost Based Dust Protection, Blocks as vertices, Bech32 addresses | [Shimmer](/build/networks-endpoints/#shimmer), [Public Testnet](/build/networks-endpoints/#public-testnet) |
-| IOTA 2.0                                                     | -                          | The upcoming version of IOTA running under a PoS scheme with a leaderless consensus algorithm called On-Tangle-Voting. Introduces the concept of mana, which is a resource used to pay for network utilisation.                                                                                                                                         | PoS - OTV                                         | Mana, Staking, PoS, AccountOutput, ICCA                                                                | -                                                                                                          |
+| Name                                                         | Release Date               | Description                                                                                                                                                                                                                                                                                                                                             | Consensus                                         | Features                                                                                               | Networks                                                                                                 |
+| ------------------------------------------------------------ | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------- |
+| Legacy Trinary                                               | 2016                       | Based on a [probabilistic consensus algorithm using random walks on a DAG](https://assets.ctfassets.net/r1dr6vzfxhev/2t4uxvsIqk0EUau6g2sw0g/45eae33637ca92f85dd9f4a3a218e1ec/iota1_4_3.pdf), the original version of the IOTA protocol                                                                                                                  | [PoA - Coordinator](/learn/protocols/coordinator) | Bundles, trinary                                                                                       | -                                                                                                        |
+| [Chrysalis Phase 1](/learn/protocols/chrysalis/introduction) | August 2020 (IOTA Mainnet) | Replaced the heavy probabilistic consensus algorithm to use the [White-Flag approach](/learn/protocols/chrysalis/core-concepts/white-flag-consensus) instead                                                                                                                                                                                            | [PoA - Coordinator](/learn/protocols/coordinator) | White-Flag Confirmation                                                                                | [Legacy IOTA Mainnet](/build/networks-endpoints#legacy)                                                  |
+| [Chrysalis Phase 2](/learn/protocols/chrysalis/introduction) | April 2021 (IOTA Mainnet)  | Switched from trinary to binary for data representation, changed from an account model to UTXO, removed Winternitz One Time Signatures (WOTS) and introduced EdDSA, dust protection and a complete overhaul of all APIs                                                                                                                                 | [PoA - Coordinator](/learn/protocols/coordinator) | Binary, EdDSA, UTXO, Removal of WOTS                                                                   | [IOTA Mainnet](/build/networks-endpoints#iota-mainnet), [DevNet](/build/networks-endpoints#devnet)       |
+| [Stardust](/learn/protocols/stardust/introduction)           | September 2022 (Shimmer)   | Upgraded the ledger to support multiple assets instead of just the base token, switched the dust protection to a more granular one based on exact byte costs, renamed vertices from "messages" to "blocks", introduced concepts such as `FoundryOutput`, `AliasOutput` and `NFTOutput`. Also added the foundation for ISC anchoring via `AliasOutput`s. | [PoA - Coordinator](/learn/protocols/coordinator) | Multi-Asset Ledger, ISC support, Byte Cost Based Dust Protection, Blocks as vertices, Bech32 addresses | [Shimmer](/build/networks-endpoints#shimmer), [Public Testnet](/build/networks-endpoints#public-testnet) |
+| IOTA 2.0                                                     | -                          | The upcoming version of IOTA running under a PoS scheme with a leaderless consensus algorithm called On-Tangle-Voting. Introduces the concept of mana, which is a resource used to pay for network utilisation.                                                                                                                                         | PoS - OTV                                         | Mana, Staking, PoS, AccountOutput, ICCA                                                                | -                                                                                                        |
diff --git a/docs/learn/protocols/stardust/core-concepts/multi-asset-ledger.md b/docs/learn/protocols/stardust/core-concepts/multi-asset-ledger.md
index ac1a7314f86..c775c8621db 100644
--- a/docs/learn/protocols/stardust/core-concepts/multi-asset-ledger.md
+++ b/docs/learn/protocols/stardust/core-concepts/multi-asset-ledger.md
@@ -33,7 +33,7 @@ some immutable data attached to them. Consequently, NFTs are supported on the ba
 
 Minting an NFT doesn't require expensive gas fees; all that needs to be in place is the right amount of storage deposit
 tokens that are 100% refunded after the NFT is destroyed. The issuer's identity may also be immutably attached to the NFT next to arbitrary data, making it possible to detect
-counterfeits. [TIP-27](https://wiki.iota.org/shimmer/tips/tips/TIP-0027/)
+counterfeits. [TIP-27](/tips/tips/TIP-0027)
 explains the recommended way of structuring NFT metadata for future verification and dApp interoperability.
 
 ### Asset Wrapping
@@ -47,8 +47,8 @@ you will first need to wrap assets to another chain as a native Layer 1 asset.
 
 :::tip Learn More
 
-You can learn more about the [tokenization](https://wiki.iota.org/tips/tips/TIP-0018),
-[NFTs](https://wiki.iota.org/tips/tips/TIP-0027) and [Native Tokens](https://wiki.iota.org/tips/tips/TIP-0030/) in
+You can learn more about the [tokenization](/tips/tips/TIP-0018),
+[NFTs](/tips/tips/TIP-0027) and [Native Tokens](/tips/tips/TIP-0030/) in
 the [TIPS section](../tips.md).
 
 :::
diff --git a/docs/learn/protocols/stardust/core-concepts/output-features.md b/docs/learn/protocols/stardust/core-concepts/output-features.md
index 9fe23991515..373d1d1ce92 100644
--- a/docs/learn/protocols/stardust/core-concepts/output-features.md
+++ b/docs/learn/protocols/stardust/core-concepts/output-features.md
@@ -45,7 +45,7 @@ built around the network. It becomes possible to map data (Metadata Feature) sto
 
 :::tip Learn More
 
-You can learn more about [outputs features in Shimmer](https://wiki.iota.org/tips/tips/TIP-0018/#nft-locking--unlocking)
+You can learn more about [outputs features in Shimmer](/tips/tips/TIP-0018#nft-locking--unlocking)
 in the [TIPS section](../tips.md).
 
 :::
diff --git a/docs/learn/protocols/stardust/core-concepts/output-unlock-conditions.md b/docs/learn/protocols/stardust/core-concepts/output-unlock-conditions.md
index 7fd3d671a73..9e7af857c29 100644
--- a/docs/learn/protocols/stardust/core-concepts/output-unlock-conditions.md
+++ b/docs/learn/protocols/stardust/core-concepts/output-unlock-conditions.md
@@ -50,7 +50,7 @@ the highest bidder at that moment.
 
 :::tip Learn More
 
-You can learn more about [output unlock conditions](https://wiki.iota.org/tips/tips/TIP-0018) in the
+You can learn more about [output unlock conditions](/tips/tips/TIP-0018) in the
 [TIPS section](../tips.md).
 
 :::
diff --git a/docs/learn/protocols/stardust/core-concepts/storage-deposit.md b/docs/learn/protocols/stardust/core-concepts/storage-deposit.md
index 18d399ff873..4904109ceb0 100644
--- a/docs/learn/protocols/stardust/core-concepts/storage-deposit.md
+++ b/docs/learn/protocols/stardust/core-concepts/storage-deposit.md
@@ -30,7 +30,7 @@ amount of base currency tokens to cover the storage on nodes. The amount depends
 ledger entry.
 
 The storage deposit is not a fee because it is fully refunded as soon as the ledger entry is cleaned up. Read more
-about the new storage deposit system in [TIP-19](https://wiki.iota.org/shimmer/tips/tips/TIP-0019/).
+about the new storage deposit system in [TIP-19](/tips/tips/TIP-0019).
 
 ## Data Storage in Outputs
 
@@ -51,7 +51,7 @@ Arbitrary data storage becomes a general feature of outputs. Some examples of wh
 
 :::tip Learn More
 
-You can learn more about the [storage deposits](https://wiki.iota.org/tips/tips/TIP-0019) in the
+You can learn more about the [storage deposits](/tips/tips/TIP-0019) in the
 [TIPS section](../tips.md).
 
 :::
diff --git a/docs/learn/protocols/stardust/tips.md b/docs/learn/protocols/stardust/tips.md
index 8857013bcf5..aa3a22cfcc0 100644
--- a/docs/learn/protocols/stardust/tips.md
+++ b/docs/learn/protocols/stardust/tips.md
@@ -9,24 +9,24 @@ the [IOTA](../chrysalis/introduction.md) mainnet.
 - `Proposed` TIPs are demonstrated to have a working implementation. These TIPs are supported on Shimmer, the staging
   network of IOTA.
 
-| #   | Title                                                                                    | Description                                                                                                                                    | Type      | Layer     | Status   | Initial Target |
-| --- | ---------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | --------- | --------- | -------- | -------------- |
-| 18  | [Multi-Asset Ledger and ISC Support](https://wiki.iota.org/tips/tips/TIP-0018)           | Transform IOTA into a multi-asset ledger that supports running IOTA Smart Contracts                                                            | Standards | Core      | Proposed | **Stardust**   |
-| 19  | [Dust Protection Based on Byte Costs](https://wiki.iota.org/tips/tips/TIP-0019)          | Prevent bloating the ledger size with dust outputs                                                                                             | Standards | Core      | Proposed | **Stardust**   |
-| 20  | [Transaction Payload with New Output Types](https://wiki.iota.org/tips/tips/TIP-0020)    | UTXO-based transaction structure with TIP-18                                                                                                   | Standards | Core      | Proposed | **Stardust**   |
-| 21  | [Serialization Primitives](https://wiki.iota.org/tips/tips/TIP-0021)                     | Introduce primitives to describe the binary serialization of objects                                                                           | Standards | Core      | Proposed | **Stardust**   |
-| 22  | [IOTA Protocol Parameters](https://wiki.iota.org/tips/tips/TIP-0022)                     | Describes the global protocol parameters for the IOTA protocol                                                                                 | Standards | Core      | Draft    | **Stardust**   |
-| 23  | [Tagged Data Payload](https://wiki.iota.org/tips/tips/TIP-0023)                          | Payload for arbitrary data                                                                                                                     | Standards | Core      | Proposed | **Stardust**   |
-| 24  | [Tangle Block](https://wiki.iota.org/tips/tips/TIP-0024)                                 | A new version of TIP-6 that renames messages to blocks and removes the Indexation Payload in favor of the Tagged Data Payload. Replaces TIP-6. | Standards | Core      | Proposed | **Stardust**   |
-| 25  | [Core REST API](https://wiki.iota.org/tips/tips/TIP-0025)                                | Node Core REST API routes and objects in OpenAPI Specification. Replaces TIP-13.                                                               | Standards | Interface | Proposed | **Stardust**   |
-| 26  | [UTXO Indexer REST API](https://wiki.iota.org/tips/tips/TIP-0026)                        | UTXO Indexer REST API routes and objects in OpenAPI Specification.                                                                             | Standards | Interface | Proposed | **Stardust**   |
-| 27  | [IOTA NFT standards](https://wiki.iota.org/tips/tips/TIP-0027)                           | Define NFT metadata standard, collection system and creator royalties                                                                          | Standards | IRC       | Proposed | **Stardust**   |
-| 28  | [Node Event API](https://wiki.iota.org/tips/tips/TIP-0028)                               | Node event API definitions in AsyncAPI Specification. Replaces TIP-16.                                                                         | Standards | Interface | Proposed | **Stardust**   |
-| 29  | [Milestone Payload](https://wiki.iota.org/tips/tips/TIP-0029)                            | Milestone Payload with keys removed from essence. Replaces TIP-8.                                                                              | Standards | Core      | Proposed | **Stardust**   |
-| 30  | [Native Token Metadata Standard](https://wiki.iota.org/tips/tips/TIP-0030)               | A JSON schema that describes token metadata format for native token foundries                                                                  | Standards | IRC       | Proposed | **Stardust**   |
-| 31  | [Bech32 Address Format for IOTA and Shimmer](https://wiki.iota.org/tips/tips/TIP-0031)   | Extendable address format supporting various signature schemes and address types. Replaces TIP-11.                                             | Standards | Interface | Proposed | **Stardust**   |
-| 32  | [Shimmer Protocol Parameters](https://wiki.iota.org/tips/tips/TIP-0032)                  | Describes the global protocol parameters for the Shimmer network                                                                               | Standards | Core      | Proposed | **Stardust**   |
-| 33  | [Public Token Registry](https://github.com/iotaledger/tips/pull/72)                      | Defines an open public registry for NFT collection ID and native tokens metadata                                                               | Standards | IRC       | Draft    | **Stardust**   |
-| 34  | [Wotsicide (Stardust update)](https://wiki.iota.org/tips/tips/TIP-0034)                  | Define migration from legacy W-OTS addresses to post-Chrysalis networks. Replaces TIP-17.                                                      | Standards | Core      | Proposed | **Stardust**   |
-| 35  | [Local Snapshot File Format (Stardust Update)](https://wiki.iota.org/tips/tips/TIP-0035) | File format to export/import ledger state. Replaces TIP-9.                                                                                     | Standards | Interface | Proposed | **Stardust**   |
-| 37  | [Dynamic Proof-of-Work](https://github.com/iotaledger/tips/pull/81)                      | Dynamically adapt the PoW difficulty                                                                                                           | Standards | Core      | Draft    | **Stardust**   |
+| #   | Title                                                               | Description                                                                                                                                    | Type      | Layer     | Status   | Initial Target |
+| --- | ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | --------- | --------- | -------- | -------------- |
+| 18  | [Multi-Asset Ledger and ISC Support](/tips/tips/TIP-0018)           | Transform IOTA into a multi-asset ledger that supports running IOTA Smart Contracts                                                            | Standards | Core      | Proposed | **Stardust**   |
+| 19  | [Dust Protection Based on Byte Costs](/tips/tips/TIP-0019)          | Prevent bloating the ledger size with dust outputs                                                                                             | Standards | Core      | Proposed | **Stardust**   |
+| 20  | [Transaction Payload with New Output Types](/tips/tips/TIP-0020)    | UTXO-based transaction structure with TIP-18                                                                                                   | Standards | Core      | Proposed | **Stardust**   |
+| 21  | [Serialization Primitives](/tips/tips/TIP-0021)                     | Introduce primitives to describe the binary serialization of objects                                                                           | Standards | Core      | Proposed | **Stardust**   |
+| 22  | [IOTA Protocol Parameters](/tips/tips/TIP-0022)                     | Describes the global protocol parameters for the IOTA protocol                                                                                 | Standards | Core      | Draft    | **Stardust**   |
+| 23  | [Tagged Data Payload](/tips/tips/TIP-0023)                          | Payload for arbitrary data                                                                                                                     | Standards | Core      | Proposed | **Stardust**   |
+| 24  | [Tangle Block](/tips/tips/TIP-0024)                                 | A new version of TIP-6 that renames messages to blocks and removes the Indexation Payload in favor of the Tagged Data Payload. Replaces TIP-6. | Standards | Core      | Proposed | **Stardust**   |
+| 25  | [Core REST API](/tips/tips/TIP-0025)                                | Node Core REST API routes and objects in OpenAPI Specification. Replaces TIP-13.                                                               | Standards | Interface | Proposed | **Stardust**   |
+| 26  | [UTXO Indexer REST API](/tips/tips/TIP-0026)                        | UTXO Indexer REST API routes and objects in OpenAPI Specification.                                                                             | Standards | Interface | Proposed | **Stardust**   |
+| 27  | [IOTA NFT standards](/tips/tips/TIP-0027)                           | Define NFT metadata standard, collection system and creator royalties                                                                          | Standards | IRC       | Proposed | **Stardust**   |
+| 28  | [Node Event API](/tips/tips/TIP-0028)                               | Node event API definitions in AsyncAPI Specification. Replaces TIP-16.                                                                         | Standards | Interface | Proposed | **Stardust**   |
+| 29  | [Milestone Payload](/tips/tips/TIP-0029)                            | Milestone Payload with keys removed from essence. Replaces TIP-8.                                                                              | Standards | Core      | Proposed | **Stardust**   |
+| 30  | [Native Token Metadata Standard](/tips/tips/TIP-0030)               | A JSON schema that describes token metadata format for native token foundries                                                                  | Standards | IRC       | Proposed | **Stardust**   |
+| 31  | [Bech32 Address Format for IOTA and Shimmer](/tips/tips/TIP-0031)   | Extendable address format supporting various signature schemes and address types. Replaces TIP-11.                                             | Standards | Interface | Proposed | **Stardust**   |
+| 32  | [Shimmer Protocol Parameters](/tips/tips/TIP-0032)                  | Describes the global protocol parameters for the Shimmer network                                                                               | Standards | Core      | Proposed | **Stardust**   |
+| 33  | [Public Token Registry](https://github.com/iotaledger/tips/pull/72) | Defines an open public registry for NFT collection ID and native tokens metadata                                                               | Standards | IRC       | Draft    | **Stardust**   |
+| 34  | [Wotsicide (Stardust update)](/tips/tips/TIP-0034)                  | Define migration from legacy W-OTS addresses to post-Chrysalis networks. Replaces TIP-17.                                                      | Standards | Core      | Proposed | **Stardust**   |
+| 35  | [Local Snapshot File Format (Stardust Update)](/tips/tips/TIP-0035) | File format to export/import ledger state. Replaces TIP-9.                                                                                     | Standards | Interface | Proposed | **Stardust**   |
+| 37  | [Dynamic Proof-of-Work](https://github.com/iotaledger/tips/pull/81) | Dynamically adapt the PoW difficulty                                                                                                           | Standards | Core      | Draft    | **Stardust**   |
diff --git a/docs/maintain/chronicle/1.0.0-rc.1/docs/getting_started/docker.md b/docs/maintain/chronicle/1.0.0-rc.1/docs/getting_started/docker.md
index de8253f75fd..7fac9a2279b 100644
--- a/docs/maintain/chronicle/1.0.0-rc.1/docs/getting_started/docker.md
+++ b/docs/maintain/chronicle/1.0.0-rc.1/docs/getting_started/docker.md
@@ -28,7 +28,7 @@ Configure the docker images via command-line arguments by editing the `docker-co
 
 Refer to the Chronicle CLI (run `inx-chronicle --help`) for details about configuring Chronicle via command-line arguments.
 
-See the [Hornet Wiki](https://wiki.iota.org/hornet/references/configuration/) for details about configuring `Hornet`.
+See the [Hornet Wiki](/hornet/references/configuration/) for details about configuring `Hornet`.
 
 ## Environment
 
diff --git a/docs/maintain/chronicle/1.0.0-rc.1/docs/welcome.md b/docs/maintain/chronicle/1.0.0-rc.1/docs/welcome.md
index ddc0526b9b0..8330a32665e 100644
--- a/docs/maintain/chronicle/1.0.0-rc.1/docs/welcome.md
+++ b/docs/maintain/chronicle/1.0.0-rc.1/docs/welcome.md
@@ -20,7 +20,7 @@ Through the INX interface, Chronicle listens to all blocks in the Tangle that ar
 
 ## Documentation
 
-The documentation for Chronicle can be found in [our wiki](https://wiki.iota.org/shimmer/chronicle/welcome), the supported APIs are documented [here](https://wiki.iota.org/shimmer/chronicle/reference/api).
+The documentation for Chronicle can be found in [our wiki](./welcome.md), the supported APIs are documented [here](./reference/api.md).
 
 ## Development
 
diff --git a/docs/maintain/hornet/1.2.4/docs/getting_started/getting_started.md b/docs/maintain/hornet/1.2.4/docs/getting_started/getting_started.md
index e9f0d71d6e4..f9af9173945 100644
--- a/docs/maintain/hornet/1.2.4/docs/getting_started/getting_started.md
+++ b/docs/maintain/hornet/1.2.4/docs/getting_started/getting_started.md
@@ -20,10 +20,10 @@ Running a node is an efficient way to use IOTA. By doing so, you have direct acc
 connect to and trust someone else's node. Additionally, you help the IOTA network to become more distributed and resilient.
 
 The node software is the backbone of the network. For an overview of tasks a node is responsible for, please
-see our [Node 101](https://wiki.iota.org/develop/nodes/explanations/nodes_101) section.
+see our [Node 101](/develop/nodes/explanations/nodes_101) section.
 
 To make sure that your device meets the minimum security requirements for running a node, please
-see our [Security 101](https://wiki.iota.org/develop/nodes/explanations/security_101) section.
+see our [Security 101](/develop/nodes/explanations/security_101) section.
 
 :::note
 
diff --git a/docs/maintain/hornet/1.2.4/docs/how_tos/post_installation.md b/docs/maintain/hornet/1.2.4/docs/how_tos/post_installation.md
index eff94c0819b..0c980fca3b7 100644
--- a/docs/maintain/hornet/1.2.4/docs/how_tos/post_installation.md
+++ b/docs/maintain/hornet/1.2.4/docs/how_tos/post_installation.md
@@ -23,7 +23,7 @@ The most important configuration files are:
 
 :::note
 
-Hornet version 0.5.x targets the legacy IOTA 1.0 network. Hornet version 1.x.x targets the IOTA 1.5 network, also known as [Chrysalis](https://wiki.iota.org/introduction/explanations/update/what_is_chrysalis), which is the focus of this documentation.
+Hornet version 0.5.x targets the legacy IOTA 1.0 network. Hornet version 1.x.x targets the IOTA 1.5 network, also known as [Chrysalis](/introduction/explanations/update/what_is_chrysalis), which is the focus of this documentation.
 
 :::
 
@@ -143,4 +143,4 @@ If you would like to offer proof of work to clients, consider increasing the `re
 We recommend that you provide your HTTP REST API behind a reverse proxy, such as [HAProxy](http://www.haproxy.org/), [Traefik](https://traefik.io/), [Nginx](https://www.nginx.com/), or [Apache](https://www.apache.org/) configured with TLS.
 When using our [recommended setup](using_docker.md) this is done for you automatically.
 
-You can explore more details regarding different API calls at the [IOTA client library documentation](https://wiki.iota.org/iota.rs/welcome).
+You can explore more details regarding different API calls at the [IOTA client library documentation](/iota.rs/welcome).
diff --git a/docs/maintain/hornet/1.2.4/docs/how_tos/run_as_a_verifier.md b/docs/maintain/hornet/1.2.4/docs/how_tos/run_as_a_verifier.md
index 782f95d5f66..5545291d4fc 100644
--- a/docs/maintain/hornet/1.2.4/docs/how_tos/run_as_a_verifier.md
+++ b/docs/maintain/hornet/1.2.4/docs/how_tos/run_as_a_verifier.md
@@ -12,7 +12,7 @@ keywords:
 
 # How to Run Hornet as a Verifier Node
 
-A verifier node is a node which validates receipts. Receipts are an integral component of the migration mechanism used to migrate funds from the legacy network into the Chrysalis Phase 2 network. You can find a more detailed explanation on how the migration mechanism works in the [Chrysalis documentation](https://wiki.iota.org/introduction/explanations/update/migration_mechanism).
+A verifier node is a node which validates receipts. Receipts are an integral component of the migration mechanism used to migrate funds from the legacy network into the Chrysalis Phase 2 network. You can find a more detailed explanation on how the migration mechanism works in the [Chrysalis documentation](/introduction/explanations/update/migration_mechanism).
 
 This guide explains how to configure a Hornet node as a verifier node:
 
diff --git a/docs/maintain/hornet/1.2.4/docs/how_tos/using_docker.md b/docs/maintain/hornet/1.2.4/docs/how_tos/using_docker.md
index 29c45875355..3864cc2e886 100644
--- a/docs/maintain/hornet/1.2.4/docs/how_tos/using_docker.md
+++ b/docs/maintain/hornet/1.2.4/docs/how_tos/using_docker.md
@@ -25,7 +25,7 @@ It includes everything required to setup a public node accessible by wallets and
 - [Grafana](https://grafana.com) - Data visualizer that can be used to display the metrics collected by Prometheus.
 
 We only recommend running a node on hosted servers and not on personal computers.
-Please take into consideration the points explained in the [Security 101](https://wiki.iota.org/develop/nodes/explanations/security_101#securing-your-device).
+Please take into consideration the points explained in the [Security 101](/develop/nodes/explanations/security_101#securing-your-device).
 
 Hornet Docker images (amd64/x86_64 and arm64 architecture) are available at the [iotaledger/hornet](https://hub.docker.com/r/iotaledger/hornet) Docker hub.
 
diff --git a/docs/maintain/hornet/1.2.4/docs/references/peering.md b/docs/maintain/hornet/1.2.4/docs/references/peering.md
new file mode 100644
index 00000000000..0c7d9a957f2
--- /dev/null
+++ b/docs/maintain/hornet/1.2.4/docs/references/peering.md
@@ -0,0 +1,152 @@
+---
+description: How to configure your nodes' peers, neighbors, and auto-peering.
+image: /img/Banner/banner_hornet_peering.png
+keywords:
+  - IOTA Node
+  - HORNET Node
+  - configuration
+  - peer
+  - peering
+  - identity
+  - autopeering
+  - explanation
+---
+
+# Peering
+
+![HORNET Node Peering](/img/Banner/banner_hornet_peering.png)
+
+The IOTA network is a distributed network. It uses a gossip protocol to broadcast data among nodes.
+To participate in a network, each node has to establish a secure connection to other nodes in the network (to its peer neighbors), and mutually exchange messages.
+
+## Node Identity
+
+Each node can be uniquely identified by a `peer identity`. `Peer identity` (also called `PeerId`) is represented by a public
+and private key pair.
+Since `PeerId` is a cryptographic hash of a peer's public key, the `PeerId` represents a verifiable link between the given peer and its public key.
+It enables individual peers to establish a secure communication channel as the hash can be used to verify an identity of the peer.
+
+When HORNET is started for the first time, it will automatically generate a `PeerId` and save the identity's private key in the `./p2pstore/identity.key` file.
+HORNET will keep the generated identity between subsequent restarts.
+
+Each time HORNET starts, the `PeerId` is written to stdout:
+
+```plaintext
+2022-07-19T13:27:18+02:00	INFO	P2P	peer configured, ID: 12D3KooWF4B2jdZbSZFX1Z9PPKp2YQs58Hh2WfnoMKYx7yuzVx53
+```
+
+Your `PeerId` is an essential part of your `multiaddr` used to configure neighbors. For example, `/dns/example.com/tcp/15600/p2p/12D3KooWHiPg9gzmy1cbTFAUekyLHQKQKvsKmhzB7NJ5xnhK4WKq`,
+where `12D3KooWHiPg9gzmy1cbTFAUekyLHQKQKvsKmhzB7NJ5xnhK4WKq` corresponds to your `PeerId`.
+Your `PeerId` is also visible on the start page of the dashboard.
+
+You can find more information on the `PeerId` in the [libp2p docs page](https://docs.libp2p.io/concepts/peer-id/).
+
+## Addressing Peer Neighbors
+
+To communicate to your peer neighbors, you will need an address to reach them. For that, HORNET uses the `MultiAddresses` format (also known as `multiaddr`).
+
+`multiaddr` is a convention on how to encode multiple layers of addressing information into a single path structure that is future-proof.
+Basically, `multiaddr` combines several pieces of information in a single human-readable and machine-optimized string, including network protocol and [`PeerId`](#node-identity).
+
+For example, a node is reachable using IPv4 `100.1.1.1` using `TCP` on port `15600` and its `PeerId`
+is `12D3KooWHjcCgWPnUEP8wNdbL2fx63Cmosk16xyZ25iUZagxmHb4`. A `multiaddr` encoding of this information would look like this:
+
+```plaintext
+/ip4/100.1.1.1/tcp/15600/p2p/12D3KooWHjcCgWPnUEP8wNdbL2fx63Cmosk16xyZ25iUZagxmHb4
+```
+
+:::note
+
+Consider how `ip4` is used. A common mistake is to use `ipv4`.
+
+:::
+
+If a node is reachable using a DNS name (for example `node01.iota.org`), then the given `multiaddr` would be:
+
+```plaintext
+/dns/node01.iota.org/tcp/15600/p2p/12D3KooWHjcCgWPnUEP8wNdbL2fx63Cmosk16xyZ25iUZagxmHb4
+```
+
+You will need to find out your own `multiaddr` to give to your peers for neighboring. To do so, combine the `peerId` you received
+from the stdout when the HORNET node started up, and your configured `p2p.bindAddress`.
+Replace the `/ip4/<ip_address>`/`/dns/<hostname>` segments with the actual information.
+
+You can find more information about `multiaddr` at the [libp2p docs page](https://docs.libp2p.io/concepts/addressing/).
+
+## Adding Node Peers
+
+Once you know your node's own `multiaddr`, it can be exchanged with other node owners to establish a mutual peer connection.
+We recommended several peer neighbors between 4-6 to get some degree of redundancy.
+
+## Finding Neighbors
+
+You can join the official IOTA Discord server and the `#nodesharing` channel.
+There, you will be able to describe your node location (Europe, Asia, etc.), with your allocated high watermark resources and ask for neighbors.
+
+:::note
+
+Do not publicly disclose your node `multiaddr` to all readers but wait for an individual direct chat.
+
+:::
+
+You can add peers using the HORNET [dashboard](../how_tos/using_docker.md#starting-hornet).
+To do so, go to _Peers_ and click on _Add Peer_. You can also add peers on the `peering.json` file.
+
+This is `peering.json` example, with `ip4`, `ip6` and `dns` peers:
+
+```json
+{
+  "peers": [
+    {
+      "alias": "Node1",
+      "multiAddress": "/ip4/192.0.2.0/tcp/15600/p2p/12D3KooWCKWcTWevORKa2KEBputEGASvEBuDfRDSbe8t1DWugUmL"
+    },
+    {
+      "alias": "Node2",
+      "multiAddress": "/ip6/2001:db8:3333:4444:5555:6666:7777:8888/tcp/16600/p2p/12D3KooWJDqHjhd8us8XdbKy1Adp5nV6XoI7XhjZbPWAfbAbkLbH"
+    },
+    {
+      "alias": "Node3",
+      "multiAddress": "/dns/example.com/tcp/15600/p2p/12D3KooWN7F4eRAYbavnasME8WGXwkrpzWWoZSXfNSEpudmWi9YP"
+    }
+  ]
+}
+```
+
+## Autopeering
+
+HORNET also supports automatic discovery of peers through the _autopeering_ module.
+To minimize service distribution in case your autopeered peers are flaky, we recommend you only use autopeering if you have at least four static peers.
+
+Autopeering is disabled by default. If you want to enable it, set the `"p2p.autopeering.enabled"` value to `"true"`.
+See the [configuration reference](configuration.md#-autopeering) for more information.
+
+:::note
+
+The autopeering plugin will disclose your public IP address to possibly all nodes and entry points.
+Do not enable this plugin if you do not want this to happen!
+
+:::
+
+Your node will use the specified entry nodes under `p2p.autopeering.entryNodes` to find new peers. `entryNodes` are also encoded as `multiaddr`:
+
+```
+/ip4/45.12.34.43/udp/14626/autopeering/8CZELJwB3aBzxJgnLMvvt1FirAwNN6jif9LavYTNHCty
+```
+
+where the `/autopeering` portion defines the base58 encoded Ed25519 public key.
+
+By default, HORNET will peer up to four autopeered peers and initiate a gossip protocol with them.
+
+### Entry Node
+
+If you want to run your own node as an autopeering entry node, you should enable `p2p.autopeering.runAsEntryNode`.
+The base58 encoded public key is in the output of the `p2pidentity-gen` HORNET tool.
+Alternatively, if you already have an identity in a `p2pstore`, you can use the `p2pidentity-extract` HORNET tool to extract it.
+
+### Low/High Watermark
+
+The `p2p.connectionManager.highWatermark` and `p2p.connectionManager.lowWatermark` configuration options define "watermark" points.
+Watermark points can be considered like a filling basin where if the `highWatermark` is reached, water will be drained until it reaches the `lowWatermark` again.
+Similarly, the connection manager within HORNET will start trimming away connections to peers if `highWatermark` peers are connected until it reaches `lowWatermark` count of peers.
+These watermarks exist for a certain buffer number of peers to be connected, which will not necessarily be targeted by the gossip protocol.
diff --git a/docs/maintain/hornet/1.2.4/sidebars.js b/docs/maintain/hornet/1.2.4/sidebars.js
index af468b50fd0..edd025e4a1c 100644
--- a/docs/maintain/hornet/1.2.4/sidebars.js
+++ b/docs/maintain/hornet/1.2.4/sidebars.js
@@ -54,6 +54,11 @@ module.exports = {
               id: 'references/configuration',
               label: 'Configuration',
             },
+            {
+              type: 'doc',
+              id: 'references/peering',
+              label: 'Peering',
+            },
             {
               type: 'doc',
               id: 'references/api_reference',
diff --git a/docs/maintain/hornet/2.0.0-rc.6/docs/getting_started/getting_started.md b/docs/maintain/hornet/2.0.0-rc.6/docs/getting_started/getting_started.md
index 7d1778d2b5b..776cc1e6f9f 100644
--- a/docs/maintain/hornet/2.0.0-rc.6/docs/getting_started/getting_started.md
+++ b/docs/maintain/hornet/2.0.0-rc.6/docs/getting_started/getting_started.md
@@ -20,10 +20,10 @@ Running a node is an efficient way to use IOTA or Shimmer. By doing so, you have
 connect to and trust someone else's node. Additionally, you help the network to become more distributed and resilient.
 
 The node software is the backbone of the network. For an overview of tasks a node is responsible for, please
-see our [Node 101](https://wiki.iota.org/develop/nodes/explanations/nodes_101/) section.
+see our [Node 101](/develop/nodes/explanations/nodes_101/) section.
 
 To make sure that your device meets the minimum security requirements for running a node, please
-see our [Security 101](https://wiki.iota.org/develop/nodes/explanations/security_101/) section.
+see our [Security 101](/develop/nodes/explanations/security_101/) section.
 
 :::note
 
@@ -57,7 +57,7 @@ the [`config.json`](../how_tos/post_installation.md) file.
 ## Operating System
 
 HORNET is written in Go and can be deployed on all major platforms.
-The [recommended setup](../how_tos/using_docker.md) uses Docker to run HORNET together with some [INX](https://wiki.iota.org/shimmer/develop/explanations/what-is-shimmer/nodes/about-nodes/) extensions secured behind a [Traefik](https://traefik.io) SSL reverse proxy.
+The [recommended setup](../how_tos/using_docker.md) uses Docker to run HORNET together with some [INX](/hornet/2.0.0-rc.6/inx-plugins) extensions secured behind a [Traefik](https://traefik.io) SSL reverse proxy.
 
 ## Configuration
 
diff --git a/docs/maintain/hornet/2.0.0-rc.6/docs/how_tos/using_docker.md b/docs/maintain/hornet/2.0.0-rc.6/docs/how_tos/using_docker.md
index 15e2da5f7f8..1bfae53221f 100644
--- a/docs/maintain/hornet/2.0.0-rc.6/docs/how_tos/using_docker.md
+++ b/docs/maintain/hornet/2.0.0-rc.6/docs/how_tos/using_docker.md
@@ -32,7 +32,7 @@ It includes everything required to setup a public node accessible by wallets and
 - [wasp](https://github.com/iotaledger/wasp) - L2 Node for IOTA Smart Contracts.
 
 We only recommend running a node on hosted servers and not on personal computers.
-Please take into consideration the points explained in the [Security 101](https://wiki.iota.org/develop/nodes/explanations/security_101#securing-your-device).
+Please take into consideration the points explained in the [Security 101](/develop/nodes/explanations/security_101#securing-your-device).
 
 HORNET Docker images (amd64/x86_64 and arm64 architecture) are available at the [iotaledger/hornet](https://hub.docker.com/r/iotaledger/hornet) Docker hub.
 
diff --git a/docs/maintain/hornet/2.0.0-rc.6/docs/inx-plugins/coordinator/welcome.md b/docs/maintain/hornet/2.0.0-rc.6/docs/inx-plugins/coordinator/welcome.md
index 76034eb920b..79963915fd2 100644
--- a/docs/maintain/hornet/2.0.0-rc.6/docs/inx-plugins/coordinator/welcome.md
+++ b/docs/maintain/hornet/2.0.0-rc.6/docs/inx-plugins/coordinator/welcome.md
@@ -20,7 +20,7 @@ It's task is to issue milestones at a constant rate. Validation of the issued mi
 
 ## Setup
 
-There is only one coordinator needed in a network. If you want to run your own private network with it's own coordinator, have a look at our [Run a Private Tangle](https://wiki.iota.org/hornet/develop/how_tos/private_tangle) guide.
+There is only one coordinator needed in a network. If you want to run your own private network with it's own coordinator, have a look at our [Run a Private Tangle](/hornet/2.0.0-rc.6/how_tos/private_tangle) guide.
 
 ## Configuration
 
diff --git a/docs/maintain/hornet/2.0.0-rc.6/docs/inx-plugins/faucet/welcome.md b/docs/maintain/hornet/2.0.0-rc.6/docs/inx-plugins/faucet/welcome.md
index d2fb0d29d7c..37803365c51 100644
--- a/docs/maintain/hornet/2.0.0-rc.6/docs/inx-plugins/faucet/welcome.md
+++ b/docs/maintain/hornet/2.0.0-rc.6/docs/inx-plugins/faucet/welcome.md
@@ -22,7 +22,7 @@ Faucets are useful in test and private networks to distribute test tokens to dev
 
 The recommended setup is to use the provided [Docker images](https://hub.docker.com/r/iotaledger/inx-faucet).
 
-If you want to run your own private network with it's own faucet, have a look at our [Run a Private Tangle](https://wiki.iota.org/hornet/develop/how_tos/private_tangle) guide.
+If you want to run your own private network with it's own faucet, have a look at our [Run a Private Tangle](/hornet/2.0.0-rc.6/how_tos/private_tangle) guide.
 
 To run your own faucet you need to provide a private key containing funds to the faucet. To do this you start `inx-faucet` by passing a `FAUCET_PRV_KEY` environment variable containing the private key.
 
diff --git a/docs/maintain/hornet/2.0.0-rc.6/docs/inx-plugins/participation/welcome.md b/docs/maintain/hornet/2.0.0-rc.6/docs/inx-plugins/participation/welcome.md
index a83d5d4fe51..84f2258af4d 100644
--- a/docs/maintain/hornet/2.0.0-rc.6/docs/inx-plugins/participation/welcome.md
+++ b/docs/maintain/hornet/2.0.0-rc.6/docs/inx-plugins/participation/welcome.md
@@ -23,7 +23,7 @@ You can find more information on how participation events work in the [HORNET Pa
 ## Setup
 
 The recommended setup is to use the provided [Docker images](https://hub.docker.com/r/iotaledger/inx-participation).
-These images are also used in our [HORNET recommended setup using Docker](https://wiki.iota.org/shimmer/hornet/how_tos/using_docker/).
+These images are also used in our [HORNET recommended setup using Docker](/hornet/how_tos/using_docker).
 
 ## Configuration
 
diff --git a/docs/maintain/hornet/2.0.0-rc.6/sidebars.js b/docs/maintain/hornet/2.0.0-rc.6/sidebars.js
index 4bc00c88bd3..cbf7b737def 100644
--- a/docs/maintain/hornet/2.0.0-rc.6/sidebars.js
+++ b/docs/maintain/hornet/2.0.0-rc.6/sidebars.js
@@ -48,6 +48,14 @@ module.exports = {
         {
           type: 'category',
           label: 'INX-Plugins',
+          link: {
+            type: 'generated-index',
+            title: 'INX-Plugins',
+            description:
+              'Use custom plugins to extend the functionality of your node.',
+            slug: '/inx-plugins',
+            keywords: ['inx', 'plugins'],
+          },
           items: [
             {
               type: 'autogenerated',
diff --git a/docs/maintain/wasp/0.7.0/docs/chain-management.md b/docs/maintain/wasp/0.7.0/docs/chain-management.md
index 30e0464f173..88d5abcc8b5 100644
--- a/docs/maintain/wasp/0.7.0/docs/chain-management.md
+++ b/docs/maintain/wasp/0.7.0/docs/chain-management.md
@@ -57,7 +57,7 @@ This node won't be "officially" recognized by the committee, but will still be a
 ### Changing the Set of Validators
 
 You can do this in different ways, depending on whom the
-[governor address](https://wiki.iota.org/shimmer/introduction/explanations/ledger/alias) of the alias output of the
+[governor address](/tips/tips/TIP-0018#alias-output) of the alias output of the
 chain is.
 
 - If the chain governor address is the chain committee, you can perform the rotation by calling
diff --git a/tutorials/pages/create-nft-with-iota-sdk.md b/tutorials/pages/create-nft-with-iota-sdk.md
index e0ac34be993..4f6fd843b15 100644
--- a/tutorials/pages/create-nft-with-iota-sdk.md
+++ b/tutorials/pages/create-nft-with-iota-sdk.md
@@ -185,7 +185,7 @@ You should prepare the parameters for minting the NFT and define them in a `Mint
 
 - `address`: (optional) Bech32 encoded address to which the Nft will be minted. The default will use the first address of the account.
 - `sender`: Bech32 encoded sender address
-- `metadata`: Hex encoded bytes containing metadata as per IRC27 from [TIP-27](https://wiki.iota.org/shimmer/tips/tips/TIP-0027/#nft-schema) as done in the previous step.
+- `metadata`: Hex encoded bytes containing metadata as per IRC27 from [TIP-27](/tips/tips/TIP-0027/#nft-schema) as done in the previous step.
 - `tag`: Hex encoded bytes with custom tags that can help you categorize.
 - `issuer`: Bech32 encoded issuer address
 - `immutableMetadata`: Similar to metadata as hex encoded bytes. However, this one can not be updated later once minted. It can contain core properties that are immutable.
diff --git a/tutorials/pages/send-shimmer-tokens-with-iota-sdk.md b/tutorials/pages/send-shimmer-tokens-with-iota-sdk.md
index 5b4268722bf..5fbfdcb79c1 100644
--- a/tutorials/pages/send-shimmer-tokens-with-iota-sdk.md
+++ b/tutorials/pages/send-shimmer-tokens-with-iota-sdk.md
@@ -145,4 +145,4 @@ Congratulations, you are now able to manage your tokens programmatically!
 
 ## What's next?
 
-You can now create an account, generate addresses, and transfer tokens. Check out the [documentation](https://wiki.iota.org/shimmer/iota-sdk/welcome) to see what more you can do. [Create native tokens](https://wiki.iota.org/shimmer/iota-sdk/how-tos/native-tokens/create/), or [mint non-fungible tokens (NFTs)](https://wiki.iota.org/shimmer/iota-sdk/how-tos/nfts/mint-nft/) and develop your application! Have fun and good luck!
+You can now create an account, generate addresses, and transfer tokens. Check out the [documentation](/iota-sdk/welcome) to see what more you can do. [Create native tokens](/iota-sdk/how-tos/native-tokens/create/), or [mint non-fungible tokens (NFTs)](/iota-sdk/how-tos/nfts/mint-nft/) and develop your application! Have fun and good luck!
diff --git a/tutorials/pages/send-shimmer-tokens-with-wallet-lib.md b/tutorials/pages/send-shimmer-tokens-with-wallet-lib.md
index 15bf42427d9..3744f23ca76 100644
--- a/tutorials/pages/send-shimmer-tokens-with-wallet-lib.md
+++ b/tutorials/pages/send-shimmer-tokens-with-wallet-lib.md
@@ -219,4 +219,4 @@ Congratulations, you are now able to manage your tokens programmatically!
 
 ## What's next?
 
-You now can create an account, generate addresses and transfer tokens. Check out the [documentation](https://wiki.iota.org/shimmer/wallet.rs/welcome) to see what more you can do. Create some native tokens, non-fungible tokens (NFTs) and develop your own application! Have fun and good luck!
+You now can create an account, generate addresses and transfer tokens. Check out the [documentation](/wallet.rs/welcome) to see what more you can do. Create some native tokens, non-fungible tokens (NFTs) and develop your own application! Have fun and good luck!
diff --git a/tutorials/pages/shimmerevm-dapp-voting.md b/tutorials/pages/shimmerevm-dapp-voting.md
index 4c82c799443..fc79593987b 100644
--- a/tutorials/pages/shimmerevm-dapp-voting.md
+++ b/tutorials/pages/shimmerevm-dapp-voting.md
@@ -269,7 +269,7 @@ contract Voting {
 }
 ```
 
-Now, you can deploy the above smart contract using Remix, Hardhat, or any tool you prefer. Here's a tutorial to follow to deploy to [ShimmerEVM using Remix](https://wiki.iota.org/shimmer/tutorials/shimmerevm-setup).
+Now, you can deploy the above smart contract using Remix, Hardhat, or any tool you prefer. Here's a tutorial to follow to deploy to [ShimmerEVM using Remix](/tutorials/shimmerevm-setup).
 
 Once you've deployed your contract, you can check the [Explorer](https://explorer.evm.testnet.shimmer.network) to see if it's confirmed. You can verify your contract on the Explorer by going to your [contract page](https://explorer.evm.testnet.shimmer.network/address/0x1154ACEc3b5Bc2A275f51A05400A8592465566fb).
 
@@ -283,7 +283,7 @@ Please make a note of the ABI while you're compiling it. You will need it later.
 
 Most of the front end is design work which is not the focus of this tutorial, so let's jump to the js part. You can use [this project](https://github.com/anistark/smart-contracts-demo/tree/main/voting) if you're looking for a ready design to get started. Feel free to make changes to the design to suit your needs.
 
-We will also use [Metamask](https://wiki.iota.org/shimmer/smart-contracts/guide/evm/tooling/#metamask) in this section, so please ensure you have installed and logged in to Metamask.
+We will also use [Metamask](/smart-contracts/guide/evm/tooling/#metamask) in this section, so please ensure you have installed and logged in to Metamask.
 The first thing you need to do is check that Metamask is accessible from your dApp:
 
 ```javascript!
diff --git a/tutorials/pages/shimmerevm-setup.md b/tutorials/pages/shimmerevm-setup.md
index 40f32470b84..f15ece23e26 100644
--- a/tutorials/pages/shimmerevm-setup.md
+++ b/tutorials/pages/shimmerevm-setup.md
@@ -13,7 +13,7 @@ In this tutorial, we will connect to Shimmer EVM Testnet, connect Metamask to it
 
 ## Connect to Shimmer EVM Testnet
 
-First, let's setup our Metamask with the EVM. For this exercise, we will use the testnet EVM chain. You can find all endpoints [here](https://wiki.iota.org/shimmer/smart-contracts/guide/chains_and_nodes/testnet).
+First, let's setup our Metamask with the EVM. For this exercise, we will use the testnet EVM chain. You can find all endpoints [here](/smart-contracts/testnet).
 
 Add a new network on your Metamask, as shown below: