docs: misc updates

docs/explanations/dashpay.md

@@ -12,12 +12,6 @@ contract that enables a decentralized application that creates bidirectional [di
 payment channels](../reference/glossary.md#direct-settlement-payment-channel-dspc) between
 [identities](../explanations/identity.md).
 
-> 📘
->
-> For previews of an updated Dash mobile wallet UI based on the DashPay contract or to join the
-> alpha test program, please visit the <a href="https://www.dash.org/dashpay/"
-> target="_blank">DashPay landing page at dash.org</a>.
-
 The DashPay contract enables an improved Dash wallet experience with features including:
 
 * **User Centric Interaction**: DashPay brings users front and center in a cryptocurrency wallet.
@@ -86,11 +80,11 @@ Additionally, the DashPay data triggers defined in
 [rs-drive-abci](https://github.com/dashpay/platform/tree/master/packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/documents_batch/data_triggers/triggers/dashpay)
 enforce additional validation rules related to the `contactRequest` document.
 
-> 👍 DashPay DIP
->
-> Please refer to the [DashPay Dash Improvement Proposal
-> (DIP)](https://github.com/dashpay/dips/blob/master/dip-0015.md) for more extensive background
-> information and complete details about the data contract.
+:::{tip}
+See the [DashPay Dash Improvement Proposal
+(DIP)](https://github.com/dashpay/dips/blob/master/dip-0015.md) for more extensive background
+information and complete details about the data contract.
+:::
 
 * <a href="https://github.com/dashpay/dips/blob/master/dip-0015.md#the-contact-request"
   target="_blank">Contact request details</a>
@@ -99,6 +93,7 @@ enforce additional validation rules related to the `contactRequest` document.
 * <a href="https://github.com/dashpay/dips/blob/master/dip-0015.md#contact-info"
   target="_blank">Contact Info details</a>
 
+:::{dropdown} DashPay data contract
 ```json
 {
   "profile": {
@@ -129,31 +124,45 @@ enforce additional validation rules related to the `contactRequest` document.
       "avatarUrl": {
         "type": "string",
         "format": "uri",
-        "maxLength": 2048
+        "minLength": 1,
+        "maxLength": 2048,
+        "position": 0
       },
       "avatarHash": {
         "type": "array",
         "byteArray": true,
         "minItems": 32,
         "maxItems": 32,
-        "description": "SHA256 hash of the bytes of the image specified by avatarUrl"
+        "description": "SHA256 hash of the bytes of the image specified by avatarUrl",
+        "position": 1
       },
       "avatarFingerprint": {
         "type": "array",
         "byteArray": true,
         "minItems": 8,
         "maxItems": 8,
-        "description": "dHash the image specified by avatarUrl"
+        "description": "dHash the image specified by avatarUrl",
+        "position": 2
       },
       "publicMessage": {
         "type": "string",
-        "maxLength": 140
+        "minLength": 1,
+        "maxLength": 140,
+        "position": 3
       },
       "displayName": {
         "type": "string",
-        "maxLength": 25
+        "minLength": 1,
+        "maxLength": 25,
+        "position": 4
       }
     },
+    "minProperties": 1,
+    "dependentRequired": {
+      "avatarUrl": ["avatarHash", "avatarFingerprint"],
+      "avatarHash": ["avatarUrl", "avatarFingerprint"],
+      "avatarFingerprint": ["avatarUrl", "avatarHash"]
+    },
     "required": [
       "$createdAt",
       "$updatedAt"
@@ -195,21 +204,25 @@ enforce additional validation rules related to the `contactRequest` document.
         "type": "array",
         "byteArray": true,
         "minItems": 32,
-        "maxItems": 32
+        "maxItems": 32,
+        "position": 0
       },
       "rootEncryptionKeyIndex": {
         "type": "integer",
-        "minimum": 0
+        "minimum": 0,
+        "position": 1
       },
       "derivationEncryptionKeyIndex": {
         "type": "integer",
-        "minimum": 0
+        "minimum": 0,
+        "position": 2
       },
       "privateData": {
         "type": "array",
         "byteArray": true,
         "minItems": 48,
         "maxItems": 2048,
+        "position": 3,
         "description": "This is the encrypted values of aliasName + note + displayHidden encoded as an array in cbor"
       }
     },
@@ -224,6 +237,8 @@ enforce additional validation rules related to the `contactRequest` document.
     "additionalProperties": false
   },
   "contactRequest": {
+    "documentsMutable": false,
+    "canBeDeleted": false,
     "requiresIdentityEncryptionBoundedKey": 2,
     "requiresIdentityDecryptionBoundedKey": 2,
     "type": "object",
@@ -283,45 +298,49 @@ enforce additional validation rules related to the `contactRequest` document.
         "byteArray": true,
         "minItems": 32,
         "maxItems": 32,
+        "position": 0,
         "contentMediaType": "application/x.dash.dpp.identifier"
       },
       "encryptedPublicKey": {
         "type": "array",
         "byteArray": true,
         "minItems": 96,
-        "maxItems": 96
+        "maxItems": 96,
+        "position": 1
       },
       "senderKeyIndex": {
         "type": "integer",
-        "minimum": 0
+        "minimum": 0,
+        "position": 2
       },
       "recipientKeyIndex": {
         "type": "integer",
-        "minimum": 0
+        "minimum": 0,
+        "position": 3
       },
       "accountReference": {
         "type": "integer",
-        "minimum": 0
+        "minimum": 0,
+        "position": 4
       },
       "encryptedAccountLabel": {
         "type": "array",
         "byteArray": true,
         "minItems": 48,
-        "maxItems": 80
+        "maxItems": 80,
+        "position": 5
       },
       "autoAcceptProof": {
         "type": "array",
         "byteArray": true,
         "minItems": 38,
-        "maxItems": 102
-      },
-      "coreHeightCreatedAt": {
-        "type": "integer",
-        "minimum": 1
+        "maxItems": 102,
+        "position": 6
       }
     },
     "required": [
       "$createdAt",
+      "$createdAtCoreBlockHeight",
       "toUserId",
       "encryptedPublicKey",
       "senderKeyIndex",

docs/explanations/dpns.md

@@ -8,21 +8,19 @@
 
 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.
+:::{tip}
+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](../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
 
-### Name Registration Process
+Given the DNS-compatible nature of DPNS, all DPNS names are technically domain names and are registered under a top-level DPNS domain (`.dash`). Some applications may abstract the top-level domain away, but it is important to be aware that it exists.
 
-> 📘
->
-> Given the DNS-compatible nature of DPNS, all DPNS names are technically domain names and are registered under a top-level DPNS domain (`.dash`). Some applications may abstract the top-level domain away, but it is important to be aware that it exists.
+### Name Registration Process
 
 To prevent [front-running](https://en.wikipedia.org/wiki/Domain_name_front_running), name registration is split into a two phase process consisting of:
 
@@ -39,25 +37,32 @@ In the registration phase, the domain name (e.g. `alice.dash`) is once again sub
 
 ### Conflict resolution
 
-Since some names may be popular, the registration process includes a voting mechanism to resolve conflicts when multiple identities request the same name. This is only done for names that meet both of the following conditions:
+Since some names may be popular, the registration process includes a voting mechanism to resolve conflicts when multiple identities request the same name. Identities requesting premium names must pay a fee (200 credits) to cover the masternode voting costs.
+
+:::{note}
+This process only applies to names that meet the following conditions:
+
+* Less than 20 characters long (i.e. "alice", "quantumexplorer") AND
+* Contain no numbers or only contain the number(s) 0 and/or 1 (i.e. "bob", "carol01")
 
-* Less than 20 characters long (i.e. "alice", "quantumexplorer")
-* Contains no numbers or only contains the number(s) 0 and/or 1 (i.e. "bob", "carol01")
+All other available names can be registered immediately.
+:::
 
-Identities requesting contested names must pay a fee (200 credits) to cover the masternode voting costs. The voting window begins when a name matching the criteria above is requested and ends after two weeks. Additional identities can request the same name during the first week. Masternodes and evonodes can vote for one of the identities, abstain, or vote to lock the request.
+The voting window begins when a name matching the criteria above is requested and ends after two weeks. Additional identities can request the same name during the first week. Masternodes and evonodes can vote for one of the identities, abstain, or vote to lock the request.
 
 After voting concludes, the name is either awarded to one of the identities or locked. If the vote locks the name, no identity receives it. Locked names can no longer be requested or awarded in Dash Platform v1.0, but future updates may add unlock capabilities.
 
 Assuming masternodes do not vote to lock, the identity receiving the most votes takes ownership of the name. If only one identity requests the name, they will receive it even if no masternodes vote.
 
 ### Implementation
 
-DPNS names have several constraints as defined in the [DPNS data contract](https://github.com/dashpay/platform/blob/v1.0.0-beta.3/packages/dpns-contract/schema/v1/dpns-contract-documents.json). The constraints provide compatibility with DNS and protection from homograph attacks:
+DPNS names have several constraints as defined in the [DPNS data contract](https://github.com/dashpay/platform/blob/master/packages/dpns-contract/schema/v1/dpns-contract-documents.json). The constraints provide compatibility with DNS and protection from homograph attacks:
 
-* Maximum length - 63 characters
-* Character set - `0-9`, `-` (hyphen), and `A-Z` (case insensitive)
-  * Note: Use of `-` as a prefix/suffix to a name is _not_ allowed (e.g. `-name` or `name-`). This constraint is defined by this JSON-Schema [pattern](https://github.com/dashpay/platform/blob/master/packages/dpns-contract/schema/dpns-contract-documents.json#L38) in the DPNS data contract: `^[a-zA-Z0-9][a-zA-Z0-9-]{0,61}[a-zA-Z0-9]$`
-* Domain labels are converted to lowercase for case-insensitive uniqueness validation. Then, "o", "i" and "l" replaced with "0" and "1" to mitigate [homograph attacks](https://en.wikipedia.org/wiki/IDN_homograph_attack). For example, "Alice" is normalized "a11ce".
+1. Maximum length - 63 characters
+1. Character set - `0-9`, `-` (hyphen), and `A-Z` (case insensitive)
+    * Note: Use of `-` as a prefix/suffix to a name is _not_ allowed (e.g. `-name` or `name-`). This constraint is defined by this JSON-Schema [pattern](https://github.com/dashpay/platform/blob/master/packages/dpns-contract/schema/v1/dpns-contract-documents.json#L44) in the DPNS data contract: `"^[a-zA-Z0-9][a-zA-Z0-9-]{0,61}[a-zA-Z0-9]$`
+1. Domain labels are converted to lowercase for case-insensitive uniqueness validation.
+1. To mitigate [homograph attacks](https://en.wikipedia.org/wiki/IDN_homograph_attack), `o` is replaced with `0` and `i`/`l` are replaced with `1`. For example, "Alice" is normalized to "a11ce".
 
 Additional validation rules related to the `domain` document are enforced by the DPNS [data triggers](../explanations/platform-protocol-data-trigger.md) defined in [rs-drive-abci](https://github.com/dashpay/platform/tree/master/packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/documents_batch/data_triggers/triggers).
 

docs/explanations/fees.md

@@ -15,9 +15,9 @@ Fees on Dash Platform are divided into two main categories:
 
 Storage fees cover the costs to store the various types of data throughout the network, while processing fees cover the computational costs incurred by the masternodes to process state transitions. For everyday use, processing fees are minuscule compared to storage fees. However, they are important in the prevention of attacks on the network, in which case they become prohibitively expensive.
 
-> 👍 Fee System DIP
->
-> Comprehensive details regarding fees will be available in an upcoming *Dash Platform Fee System* DIP.
+:::{tip}
+Comprehensive details regarding fees will be available in an upcoming *Dash Platform Fee System* DIP.
+:::
 
 ## Costs
 
@@ -34,9 +34,9 @@ The current cost schedule is outlined in the table below:
 | Load from memory | 20 / byte |
 | Blake3 hash function | 400 + 64 / 64-byte block |
 
-> 📘 Credits
->
-> Refer to the [Identity explanation](../explanations/identity.md) section for information regarding how credits are created.
+:::{note}
+Refer to the [Identity explanation](../explanations/identity.md) section for information regarding how credits are created.
+:::
 
 ## Fee Multiplier
 

docs/explanations/identity.md

@@ -10,9 +10,9 @@ Identities are foundational to Dash Platform. They provide a familiar, easy-to-u
 
 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
->
-> The [Identities Dash Improvement Proposal (DIP)](https://github.com/dashpay/dips/blob/master/dip-0011.md) provides more extensive background information and details.
+:::{tip}
+The [Identities Dash Improvement Proposal (DIP)](https://github.com/dashpay/dips/blob/master/dip-0011.md) provides more extensive background information and details.
+:::
 
 ## Identity Management
 
@@ -22,9 +22,9 @@ Once an identity is created, its credit balance is used to pay for activity (e.g
 
 ### Identity Create Process
 
-> 📘 Testnet Faucet
->
-> On Testnet, a [test Dash faucet](https://testnet-faucet.dash.org/) is available. It dispenses small amounts to enable all users to directly acquire the funds necessary to create an identity and username.
+:::{note}
+On Testnet, a [test Dash faucet](https://insight.testnet.networks.dash.org:3002/insight/) is available. It dispenses small amounts to enable all users to directly acquire the funds necessary to create an identity and username.
+:::
 
 First, a sponsor (which could be a business, another person, or even the same user who is creating the identity) spends Dash in a transaction to create an invitation. The transaction contains one or more outputs which lock some Dash funds to establish credits within Dash platform.
 
@@ -36,9 +36,9 @@ Users who already have Dash funds can act as their own sponsor if they wish, usi
 
 The identity balance topup process works in a similar way to the initial identity creation funding. As with identity creation, a lock transaction is created on the layer 1 core blockchain. This lock transaction is then referenced in the [identity topup state transition](https://github.com/dashpay/dips/blob/master/dip-0011.md#identity-topup-transition) which increases the identity's balance by the designated amount.
 
-> 📘  
->
-> Since anyone can topup either their own account or any other account, application developers can easily subsidize the cost of using their application by topping up their user's identities.
+:::{note}
+Since anyone can topup either their own account or any other account, application developers can easily subsidize the cost of using their application by topping up their user's identities.
+:::
 
 ### Identity Update Process
 
@@ -66,6 +66,6 @@ Note: the payout key is associated with the masternode owner identity, so both t
 
 DPP v0.13 introduced the initial implementation of credits. As mentioned above, credits provide the mechanism for paying fees that cover the cost of platform usage. Once a user locks Dash on the core blockchain and proves ownership of the locked value in an identity create or topup transaction, their credit balance increases by that amount. As they perform platform actions, these credits are deducted to pay the associated fees.
 
-> 📘
->
-> As of Dash Platform Protocol v1.0, credits deducted to pay state transition fees cannot be converted by masternodes back into Dash. This aspect of the credit system will come in a future release.
+:::{attention}
+As of Dash Platform v1.0, credits deducted to pay state transition fees cannot be converted back into Dash by masternodes. This aspect of the credit system will come in a future release.
+:::

docs/explanations/platform-consensus.md

@@ -29,17 +29,15 @@ Tendermint has been mainly designed to enable efficient verification and authent
 - The Validator set committing the block.
 - Various results returned by the application.
 
-> 📘 Notes about Tendermint
->
-> - Block execution only occurs after a block is committed. So, cryptographic proofs for the latest state are only available in the subsequent block.
->
-> - Information like the transaction results and the validator set is never directly included in the block - only their Merkle roots are.
->
-> - Verification of a block requires a separate data structure to store this information. We call this the “State.”
->
-> - Block verification also requires access to the previous block.
->
-> Additional information about Tendermint is available in the <a href="https://docs.tendermint.com/master/spec/#overview" target="_blank">Tendermint Core spec</a>.
+:::{note}
+
+- Block execution only occurs after a block is committed. So, cryptographic proofs for the latest state are only available in the subsequent block.
+- Information like the transaction results and the validator set is never directly included in the block - only their Merkle roots are.
+- Verification of a block requires a separate data structure to store this information. We call this the “State.”
+- Block verification also requires access to the previous block.
+
+Additional information about Tendermint is available in the <a href="https://docs.tendermint.com/master/spec/#overview" target="_blank">Tendermint Core spec</a>.
+:::
 
 ### Tendermint Limitations