dashpay · thephez · Aug 15, 2023 · Aug 14, 2023 · Aug 14, 2023 · Aug 14, 2023
diff --git a/docs/explanations/dapi.md b/docs/explanations/dapi.md
@@ -24,8 +24,8 @@ To overcome these obstacles, the Dash decentralized API (DAPI) uses Dash's robus
 
 ## Security
 
-DAPI protects connections by using TLS to encrypt communication between clients and the masternodes. This encryption safeguards transmitted data from unauthorized access, interception, or tampering. [Platform gRPC endpoints](reference-dapi-endpoints-platform-endpoints) provide an additional level of security by optionally returning cryptographic proofs. Successful proof verification guarantees that the server responded without modifying the requested data.
+DAPI protects connections by using TLS to encrypt communication between clients and the masternodes. This encryption safeguards transmitted data from unauthorized access, interception, or tampering. [Platform gRPC endpoints](../reference/dapi-endpoints-platform-endpoints.md) provide an additional level of security by optionally returning cryptographic proofs. Successful proof verification guarantees that the server responded without modifying the requested data.
 
 ## Endpoint Overview
 
-DAPI currently provides 2 types of endpoints: [JSON-RPC](https://www.jsonrpc.org/) and [gRPC](https://grpc.io/docs/guides/). The JSON-RPC endpoints expose some layer 1 information while the gRPC endpoints support layer 2 as well as streaming of events related to blocks and transactions/transitions. For a list of all endpoints and usage details, please see the [DAPI endpoint reference section](reference-dapi-endpoints).
+DAPI currently provides 2 types of endpoints: [JSON-RPC](https://www.jsonrpc.org/) and [gRPC](https://grpc.io/docs/guides/). The JSON-RPC endpoints expose some layer 1 information while the gRPC endpoints support layer 2 as well as streaming of events related to blocks and transactions/transitions. For a list of all endpoints and usage details, please see the [DAPI endpoint reference section](../reference/dapi-endpoints.md).
diff --git a/docs/explanations/dashpay.md b/docs/explanations/dashpay.md
@@ -2,7 +2,7 @@
 
 ## Overview
 
-DashPay is one of the first applications of Dash Platform's [data contracts](explanation-platform-protocol-data-contract) . At its core DashPay is a data contract that enables a decentralized application that creates bidirectional [direct settlement payment channels](reference-glossary#direct-settlement-payment-channel-dspc) between [identities](explanation-identity).
+DashPay is one of the first applications of Dash Platform's [data contracts](../explanations/platform-protocol-data-contract.md) . At its core DashPay is a data contract that enables a decentralized application that creates bidirectional [direct settlement payment channels](../reference/glossary.md#direct-settlement-payment-channel-dspc) between [identities](../explanations/identity.md).
 
 > 📘
 >
@@ -25,8 +25,8 @@ The contract defines three document types: `contactRequest`, `profile` and `cont
 ### Establishing a Contact
 
 1. Bob installs wallet software that supports DashPay.
-2. Bob [registers an identity](tutorial-register-an-identity) and then [creates a username](tutorial-register-a-name-for-an-identity) through [DPNS](explanation-dpns).
-3. Bob searches for Carol by her username. Behind the scenes this search returns the unique identifier for Carol's identity. An example of doing this can be seen in the [Retrieve a Name tutorial](doc:tutorial-retrieve-a-name).
+2. Bob [registers an identity](../tutorials/identities-and-names/register-an-identity.md) and then [creates a username](../tutorials/identities-and-names/register-a-name-for-an-identity.md) through [DPNS](../explanations/dpns.md).
+3. Bob searches for Carol by her username. Behind the scenes this search returns the unique identifier for Carol's identity. An example of doing this can be seen in the [Retrieve a Name tutorial](../tutorials/identities-and-names/retrieve-a-name.md).
 4. Bob sends a contact request containing an encrypted extended public key to Carol. This establishes a one way relationship from Bob to Carol.
 5. Carol accepts the request by sending a contact request containing an encrypted extended public key back to Bob. This establishes a one way relationship from Carol to Bob.
 6. Bob and Carol are now contacts of one another and can make payments to each other by decrypting the extended public key received from the other party and deriving payment addresses from it. Since both have established one way relationships with each other, they now have a two way relationship. If Bob gets a new device, he can use his recovery phrase from step one and restore his wallet, contacts (including Carol) and payments to and from his contacts.

diff --git a/docs/explanations/dpns.md b/docs/explanations/dpns.md
@@ -2,14 +2,14 @@
 
 ## Overview
 
-Dash Platform Name Service (DPNS) is a service used to register names on Dash Platform. It is a general service that is used to provide usernames and application names for [identities](explanation-identity) but can also be extended in the future to resolve other cryptocurrency addresses, websites, and more. DPNS is implemented as an application on top of the platform and leverages platform capabilities.
+Dash Platform Name Service (DPNS) is a service used to register names on Dash Platform. It is a general service that is used to provide usernames and application names for [identities](../explanations/identity.md) but can also be extended in the future to resolve other cryptocurrency addresses, websites, and more. DPNS is implemented as an application on top of the platform and leverages platform capabilities.
 
 > 👍 DPNS DIP
 >
 > The [DPNS Dash Improvement Proposal (DIP)](https://github.com/dashpay/dips/blob/master/dip-0012.md) provides more extensive background information and details.
 
 ###  Relationship to identities
-DPNS names and [Identities](explanation-identity) are tightly integrated. Identities provide a foundation that DPNS builds on to enable name-based interactions -- a user experience similar to what is found in non-cryptocurrency applications. With DPNS, users or application developers register a name and associate it with an identity. Once linked, the identity's private keys allow them to prove ownership of the name to establish trust when they interact with other users and applications.
+DPNS names and [Identities](../explanations/identity.md) are tightly integrated. Identities provide a foundation that DPNS builds on to enable name-based interactions -- a user experience similar to what is found in non-cryptocurrency applications. With DPNS, users or application developers register a name and associate it with an identity. Once linked, the identity's private keys allow them to prove ownership of the name to establish trust when they interact with other users and applications.
 
 ## Details
 
@@ -40,7 +40,7 @@ DPNS names currently have several constraints as defined in the [DPNS data contr
 > "^[a-zA-Z0-9][a-zA-Z0-9-]{0,61}[a-zA-Z0-9]$"
 > ```
 
-Additionally, the DPNS [data triggers](explanation-platform-protocol-data-trigger) defined in [js-dpp](https://github.com/dashevo/platform/tree/master/packages/js-dpp/lib/dataTrigger) enforce additional validation rules related to the `domain` document.
+Additionally, the DPNS [data triggers](../explanations/platform-protocol-data-trigger.md) defined in [js-dpp](https://github.com/dashevo/platform/tree/master/packages/js-dpp/lib/dataTrigger) enforce additional validation rules related to the `domain` document.
 
 For more implementation details, please reference the open-source JavaScript DPNS client reference implementation found in the [js-dpns-client](https://github.com/dashevo/js-dpns-client) repository. Additionally, the DPNS data contract is available in the [dpns-contract](https://github.com/dashevo/platform/blob/master/packages/dpns-contract/schema/dpns-contract-documents.json) repository.
 

diff --git a/docs/explanations/drive-platform-chain.md b/docs/explanations/drive-platform-chain.md
@@ -2,7 +2,7 @@
 
 ## Overview
 
-The platform chain is the [Drive](explanation-drive) component responsible for replicating the platform state across all masternodes participating in the network. Masternodes operate this Proof of Service (PoSe) chain to provide layer 2 consensus and support Dash Platform-specific requirements without impacting layer 1 functionality. Although the platform chain can read from the Dash layer 1 core blockchain, the core blockchain is not dependent on it or aware of it. 
+The platform chain is the [Drive](../explanations/drive.md) component responsible for replicating the platform state across all masternodes participating in the network. Masternodes operate this Proof of Service (PoSe) chain to provide layer 2 consensus and support Dash Platform-specific requirements without impacting layer 1 functionality. Although the platform chain can read from the Dash layer 1 core blockchain, the core blockchain is not dependent on it or aware of it. 
 
 ## Details
 
@@ -15,7 +15,7 @@ Early designs of Drive were based on using on the layer 1 core blockchain and [I
 In order to support Dash Platform's performance requirements, the platform chain has the following design characteristics:
 - Relies on masternode Proof of Service, not miner Proof of Work (PoW)
 - Hosted exclusively on masternodes
-- Uses a [practical Byzantine Fault Tolerance (pBFT)](reference-glossary#practical-byzantine-fault-tolerance-pbft) consensus algorithm
+- Uses a [practical Byzantine Fault Tolerance (pBFT)](../reference/glossary.md#practical-byzantine-fault-tolerance-pbft) consensus algorithm
 - Has a deterministic fee structure
 - Provides fast (< 10 seconds) and absolute block finality (no reorgs) 
 

diff --git a/docs/explanations/drive.md b/docs/explanations/drive.md
@@ -2,24 +2,24 @@
 
 ## Overview
 
-Using the traditional, layer 1 blockchain for data storage is widely known to be expensive and inefficient. Consequently, data for Dash Platform applications is stored in Drive, a layer 2 component that provides decentralized storage hosted by masternodes. As data changes over time, Drive maintains a record of the current state of each item to support easy retrieval using [DAPI](explanation-dapi).
+Using the traditional, layer 1 blockchain for data storage is widely known to be expensive and inefficient. Consequently, data for Dash Platform applications is stored in Drive, a layer 2 component that provides decentralized storage hosted by masternodes. As data changes over time, Drive maintains a record of the current state of each item to support easy retrieval using [DAPI](../explanations/dapi.md).
 
 ## Details
 
 ### Drive Components
 
 There are a number of components working together to facilitate Drive's overall functionality. These components are listed below along with a brief description of service they provide:
 
- - [Platform chain](explanation-drive-platform-chain) (orders state transitions; creates and propagates blocks of state transitions)
- - Platform state machine (validates data against the [Dash platform protocol](explanation-platform-protocol); applies data to state and storage)
- - [Platform state](explanation-drive-platform-state) (represents current data)
+ - [Platform chain](../explanations/drive-platform-chain.md) (orders state transitions; creates and propagates blocks of state transitions)
+ - Platform state machine (validates data against the [Dash platform protocol](../explanations/platform-protocol.md); applies data to state and storage)
+ - [Platform state](../explanations/drive-platform-state.md) (represents current data)
  - Storage (record of state transitions)
 
 ### Data Update Process
 
 The process of adding or updating data in Drive consists of several steps to ensure data is validated, propagated, and stored properly. This description provides a simplified overview of the process:
 
-1. [State transitions](explanation-platform-protocol-state-transition) are submitted to the platform via [DAPI](explanation-dapi)
+1. [State transitions](../explanations/platform-protocol-state-transition.md) are submitted to the platform via [DAPI](../explanations/dapi.md)
 2. DAPI sends the state transitions to the platform chain where they are validated, ordered, and committed to a block
 3. Valid state transitions are applied to the platform state
 4. The platform chain propagates a block containing the state transitions

diff --git a/docs/explanations/fees.md b/docs/explanations/fees.md
@@ -45,7 +45,7 @@ The current cost schedule is outlined in the table below:
 [/block]
 > 📘 Credits
 >
-> Refer to the [Identity explanation](explanation-identity) section for information regarding how credits are created.
+> Refer to the [Identity explanation](../explanations/identity.md) section for information regarding how credits are created.
 
 ## Fee Multiplier
 

diff --git a/docs/explanations/identity.md b/docs/explanations/identity.md
@@ -4,7 +4,7 @@
 
 Identities are foundational to Dash Platform. They provide a familiar, easy-to-use way for users to interact and identify one another using names rather than complicated cryptocurrency identifiers such as public key hashes.
 
-Identities are separate from names and can be thought of as a lower-level primitive that provides the foundation for various user-facing functionality. An identity consists primarily of one or more public keys recorded on the platform chain that can be used to control a user's profile and sign their documents. Each identity also has a balance of [credits](#credits) that is established by locking funds on layer 1. These credits are used to pay fees associated with the [state transitions](explanation-platform-protocol-state-transition) used to perform actions on the platform.
+Identities are separate from names and can be thought of as a lower-level primitive that provides the foundation for various user-facing functionality. An identity consists primarily of one or more public keys recorded on the platform chain that can be used to control a user's profile and sign their documents. Each identity also has a balance of [credits](#credits) that is established by locking funds on layer 1. These credits are used to pay fees associated with the [state transitions](../explanations/platform-protocol-state-transition.md) used to perform actions on the platform.
 
 > 👍 Identities DIP
 >

diff --git a/docs/explanations/platform-protocol-data-contract.md b/docs/explanations/platform-protocol-data-contract.md
@@ -2,15 +2,15 @@
 
 ## Overview
 
-As described briefly in the [Dash Platform Protocol explanation](explanation-platform-protocol#data-contract), Dash Platform uses data contracts to define the schema (structure) of data it stores. Therefore, an application must first register a data contract before using the platform to store its data. Then, when the application attempts to store or change data, the request will only succeed if the new data matches the data contract's schema.
+As described briefly in the [Dash Platform Protocol explanation](../explanations/platform-protocol.md#data-contract), Dash Platform uses data contracts to define the schema (structure) of data it stores. Therefore, an application must first register a data contract before using the platform to store its data. Then, when the application attempts to store or change data, the request will only succeed if the new data matches the data contract's schema.
 
-The first two data contracts are the [DashPay wallet](https://www.dash.org/dashpay/) and [Dash Platform Name Service (DPNS)](explanation-dpns). The concept of the social, username-based DashPay wallet served as the catalyst for development of the platform, with DPNS providing the mechanism to support usernames.
+The first two data contracts are the [DashPay wallet](https://www.dash.org/dashpay/) and [Dash Platform Name Service (DPNS)](../explanations/dpns.md). The concept of the social, username-based DashPay wallet served as the catalyst for development of the platform, with DPNS providing the mechanism to support usernames.
 
 ## Details
 
 ### Ownership
 
-Data contracts are owned by the [identity](explanation-identity) that registers them. Each identity may be used to create multiple data contracts and data contract updates can only be made using the identity that owns it.
+Data contracts are owned by the [identity](../explanations/identity.md) that registers them. Each identity may be used to create multiple data contracts and data contract updates can only be made using the identity that owns it.
 
 ### Structure
 
@@ -23,7 +23,7 @@ In the [example contract](#example-contract) shown below, a `contact` document a
 
 ### Registration
 
-Once a [Dash Platform Protocol](explanation-platform-protocol) compliant data contract has been defined, it may be registered on the platform. Registration is completed by submitting a state transition containing the data contract to [DAPI](explanation-dapi).
+Once a [Dash Platform Protocol](../explanations/platform-protocol.md) compliant data contract has been defined, it may be registered on the platform. Registration is completed by submitting a state transition containing the data contract to [DAPI](../explanations/dapi.md).
 
 The drawing below illustrates the steps an application developer follows to complete registration.
 [block:image]
@@ -48,7 +48,7 @@ Since Dash Platform v0.22, it is possible to update existing data contracts in c
 
 > 📘
 >
-> For more detailed information, see the [Platform Protocol Reference - Data Contract](platform-protocol-reference-data-contract) page.
+> For more detailed information, see the [Platform Protocol Reference - Data Contract](../protocol-ref/data-contract.md) page.
 
 ## Example Contract
 

diff --git a/docs/explanations/platform-protocol-data-trigger.md b/docs/explanations/platform-protocol-data-trigger.md
@@ -6,7 +6,7 @@
 
 ## Overview
 
-Although [data contracts](explanation-platform-protocol-data-contract) provide much needed constraints on the structure of the data being stored on Dash Platform, there are limits to what they can do. Certain system data contracts may require server-side validation logic to operate effectively. For example, [DPNS](doc:explanation-dpns) must enforce some rules to ensure names remain DNS compatible. [Dash Platform Protocol](explanation-platform-protocol) (DPP) supports this application-specific custom logic using Data Triggers.
+Although [data contracts](../explanations/platform-protocol-data-contract.md) provide much needed constraints on the structure of the data being stored on Dash Platform, there are limits to what they can do. Certain system data contracts may require server-side validation logic to operate effectively. For example, [DPNS](../explanations/dpns.md) must enforce some rules to ensure names remain DNS compatible. [Dash Platform Protocol](../explanations/platform-protocol.md) (DPP) supports this application-specific custom logic using Data Triggers.
 
 > ❗️ Constraints
 > 
@@ -25,4 +25,4 @@ As an example, DPP contains several [data triggers for DPNS](https://github.com/
 | DPNS | All Document Types | [`REPLACE`](https://github.com/dashevo/platform/blob/master/packages/js-dpp/lib/dataTrigger/rejectDataTrigger.js) | Prevents updates to any DPNS document type |
 | DPNS | All Document Types | [`DELETE`](https://github.com/dashevo/platform/blob/master/packages/js-dpp/lib/dataTrigger/rejectDataTrigger.js) | Prevents deletion of any DPNS document type |
 
-When document state transitions are received, DPP checks if there is a trigger associated with the document type and action. If a trigger is found, DPP executes the trigger logic. Successful execution of the trigger logic is necessary for the document to be accepted and applied to the [platform state](explanation-drive-platform-state).
+When document state transitions are received, DPP checks if there is a trigger associated with the document type and action. If a trigger is found, DPP executes the trigger logic. Successful execution of the trigger logic is necessary for the document to be accepted and applied to the [platform state](../explanations/drive-platform-state.md).