dashpay · thephez · Apr 16, 2026 · Apr 15, 2026 · Apr 15, 2026 · Apr 15, 2026
diff --git a/CLAUDE.md b/CLAUDE.md
@@ -65,6 +65,15 @@ The site uses a hierarchical structure with:
 - Google Analytics tracking configured
 - Uses pydata-sphinx-theme with custom CSS overrides
 
+## Editing Guidelines
+
+When updating documentation values that include GitHub source links:
+
+- Preserve the existing link markup — do not replace `[value](url#Lnn)` with plain text
+- Update the URL if the file path has changed (e.g. directory renames)
+- Update the line anchor (`#L`) to match the correct line **in the branch the link points to**
+- When available, use the local platform repository checkout to verify line numbers against the correct branch
+
 ## File Patterns
 
 - Documentation files: `docs/**/*.md`

diff --git a/docs/explanations/dashpay.md b/docs/explanations/dashpay.md
@@ -75,9 +75,9 @@ used to store private information about other Dash identities.
 ### Implementation
 
 DashPay has many constraints as defined in the [DashPay data
-contract](https://github.com/dashpay/platform/blob/master/packages/dashpay-contract/schema/dashpay.schema.json).
+contract](https://github.com/dashpay/platform/blob/master/packages/dashpay-contract/schema/v1/dashpay.schema.json).
 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)
+[rs-drive-abci](https://github.com/dashpay/platform/tree/master/packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/dashpay)
 enforce additional validation rules related to the `contactRequest` document.
 
 :::{tip}

diff --git a/docs/explanations/dpns.md b/docs/explanations/dpns.md
@@ -40,7 +40,7 @@ In the registration phase, the domain name (e.g. `alice.dash`) is once again sub
 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 (0.2 DASH) to cover the masternode voting costs.
 
 :::{note}
-This process only applies to names that meet the following conditions:
+This process only applies to valid 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")
@@ -74,13 +74,14 @@ Locked names cannot currently be re-requested or awarded. This policy may be rev
 
 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:
 
+1. Minimum length - 3 characters
 1. Maximum length - 63 characters
 1. Usable characters - `0-9`, `-` (hyphen), `a-z`, and `A-Z` (case sensitive)
-    * 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]$`
+    * 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).
+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/batch/data_triggers/triggers/dpns).
 
 ```{eval-rst}
 ..

diff --git a/docs/explanations/fees.md b/docs/explanations/fees.md
@@ -26,14 +26,13 @@ The current cost schedule is outlined in the table below:
 
 | Operation | Cost (credits) |
 | - | - |
-| Permanent storage | 40000 / byte |
-| Base processing fee | 100000 |
-| Write to storage | 750 / byte |
-| Load from storage | 3500 / byte |
+| Permanent storage | 27000 / byte |
+| Base processing fee | 10000 |
+| Write to storage | 400 / byte |
+| Load from storage | 20 / byte |
 | Seek storage | 2000 |
-| Query | 75 / byte |
-| Load from memory | 20 / byte |
-| Blake3 hash function | 400 + 64 / 64-byte block |
+| Load from memory | 10 / byte |
+| Blake3 hash function | 100 base + 300 / 64-byte block |
 
 :::{note}
 Refer to the [Identity explanation](../explanations/identity.md) section for information regarding how credits are created.
@@ -57,17 +56,18 @@ An in-depth look at the Fee Multiplier can be found at **link**
 
 In an attempt to minimize Dash Platform's storage requirements, users are incentivized to remove data that they no longer want to be stored in the Dash Platform state for a refund. Data storage fees are distributed to masternodes over the data's lifetime which is 50 years for permanent storage. Therefore, at any time before the data's fees are entirely distributed, there will be fees remaining which can be refunded to the user if they decide to delete the data.
 
-## User Tip
+## User Fee Increase
 
-Platform supports a user tip component that can be used to incentivize inclusion of a state
-transition in the next block, especially during periods of high traffic.
+Platform supports a user fee increase that can be used to incentivize inclusion of a state
+transition in the next block, especially during periods of high traffic. This is expressed as an
+integer percentage increase applied to the processing fee.
 
 ## Formula
 
 The high level formula for a state transition's fee is:
 
 ```text
-    fee = storageFee + processingFee - storageRefund + userTip
+    fee = storageFee + processingFee + (processingFee * userFeeIncrease / 100) - storageRefund
 ```
 
 <!-- Uncomment once DIP available

diff --git a/docs/explanations/identity.md b/docs/explanations/identity.md
@@ -66,6 +66,4 @@ 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.
 
-:::{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.
-:::
+Credits can be converted back to Dash using the identity credit withdrawal state transition, subject to a daily network-wide limit.
diff --git a/docs/explanations/nft.md b/docs/explanations/nft.md
@@ -40,7 +40,7 @@ NFTs can be directly transferred or traded without the need for a marketplace:
 To preserve the authenticity of NFTs, Dash Platform includes creation restriction options. This ensures that only authorized entities can create certain types of NFTs. For example, in the case of land ownership NFTs, a designated authority may be the only one that can issue tokens. Restriction options are:
 
 * **Owner Only**: Only the contract owner can create NFTs (**_Note: this is the only option implemented for the initial release_**)
-* **System Only**: Only the system can create NFTs (used for specific system contracts)
+* **No Creation Allowed**: NFT creation is disabled for this contract
 * **No Restrictions**: Anyone can create NFTs for the contract
 
 ```{eval-rst}

diff --git a/docs/explanations/platform-protocol-data-trigger.md b/docs/explanations/platform-protocol-data-trigger.md
@@ -18,13 +18,16 @@ Given a number of technical considerations (security, masternode processing capa
 
 Since all application data is submitted in the form of documents, data triggers are defined in the context of documents. To provide even more granularity, they also incorporate the document `action` so separate triggers can be created for the `CREATE`, `REPLACE`, or `DELETE` actions.
 
-As an example, DPP contains several [data triggers for DPNS](https://github.com/dashpay/platform/tree/master/packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/documents_batch/data_triggers/triggers/dpns). The `domain` document has added constraints for creation. All DPNS document types have constraints on replacing or deleting:
+As an example, DPP contains several [data triggers for DPNS](https://github.com/dashpay/platform/tree/master/packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/dpns). The `domain` document has added constraints for creation, replacing, deleting, transferring, purchasing, and updating prices:
 
 | Data Contract | Document | Action(s) | Trigger Description |
 | - | - | - | - |
-| DPNS | `domain` | [`CREATE`](https://github.com/dashpay/platform/blob/master/packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/documents_batch/data_triggers/triggers/dpns/v0/mod.rs) | Enforces DNS compatibility, validate provided hashes, and restrict top-level domain (TLD) registration |
+| DPNS | `domain` | [`CREATE`](https://github.com/dashpay/platform/blob/master/packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/dpns/v0/mod.rs) | Enforces DNS compatibility, validate provided hashes, and restrict top-level domain (TLD) registration |
 | ---- | ----| ---- | ---- |
-| DPNS | All Document Types | [`REPLACE`](https://github.com/dashpay/platform/blob/master/packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/documents_batch/data_triggers/triggers/reject/v0/mod.rs) | Prevents updates to any DPNS document type |
-| DPNS | All Document Types | [`DELETE`](https://github.com/dashpay/platform/blob/master/packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/documents_batch/data_triggers/triggers/reject/v0/mod.rs) | Prevents deletion of any DPNS document type |
+| DPNS | `domain` | [`REPLACE`](https://github.com/dashpay/platform/blob/master/packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/reject/v0/mod.rs) | Prevents updates to any DPNS document type |
+| DPNS | `domain` | [`DELETE`](https://github.com/dashpay/platform/blob/master/packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/reject/v0/mod.rs) | Prevents deletion of any DPNS document type |
+| DPNS | `domain` | [`TRANSFER`](https://github.com/dashpay/platform/blob/master/packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/reject/v0/mod.rs) | Prevents transfer of any DPNS document type |
+| DPNS | `domain` | [`PURCHASE`](https://github.com/dashpay/platform/blob/master/packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/reject/v0/mod.rs) | Prevents purchase of any DPNS document type |
+| DPNS | `domain` | [`UPDATE_PRICE`](https://github.com/dashpay/platform/blob/master/packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/reject/v0/mod.rs) | Prevents price updates on 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](../explanations/drive-platform-state.md).
diff --git a/docs/explanations/platform-protocol-document.md b/docs/explanations/platform-protocol-document.md
@@ -21,13 +21,20 @@ Dash Platform Protocol (DPP) defines a set of base fields that must be present i
 | $id | The document ID (32 bytes) |
 | $type | Document type defined in the referenced contract |
 | $revision | Document revision (=>1) |
-| $dataContract | Data contract the document is associated with |
+| $dataContractId | Data contract the document is associated with (32 bytes) |
 | $ownerId | [Identity](../explanations/identity.md) of the user submitting the document (32 bytes) |
 | $createdAt | Time (in milliseconds) the document was created |
 | $updatedAt | Time (in milliseconds) the document was last updated |
+| $transferredAt | Time (in milliseconds) the document was last transferred |
+| $createdAtBlockHeight | Platform block height when the document was created |
+| $updatedAtBlockHeight | Platform block height when the document was last updated |
+| $transferredAtBlockHeight | Platform block height when the document was last transferred |
+| $createdAtCoreBlockHeight | Core block height when the document was created |
+| $updatedAtCoreBlockHeight | Core block height when the document was last updated |
+| $transferredAtCoreBlockHeight | Core block height when the document was last transferred |
 
 :::{attention}
-The `$createdAt` and `$updatedAt` fields will only be present in documents that add them to the list of [required properties](../reference/data-contracts.md#required-properties).
+The timestamp and block height fields will only be present in documents that add them to the list of [required properties](../reference/data-contracts.md#required-properties).
 :::
 
 ### Data Contract Fields
@@ -36,16 +43,15 @@ Each application defines its own fields via document definitions in its data con
 
 | Document Type | Field Name | Data Type |
 | - | - | - |
-| preorder | saltedDomainHash | string |
+| preorder | saltedDomainHash | array (32 bytes) |
 | --- | --- | --- |
 | domain | label | string |
 | domain | normalizedLabel | string |
 | domain | parentDomainName | string |
 | domain | normalizedParentDomainName | string |
 | domain | preorderSalt | array (bytes) |
 | domain | records | object |
-| domain | records.dashUniqueIdentityId | array (bytes) |
-| domain | records.dashAliasIdentityId | array (bytes) |
+| domain | records.identity | array (32 bytes) |
 | domain | subdomainRules | object |
 | domain | subdomainRules.allowSubdomains | boolean |
 
@@ -63,15 +69,15 @@ The following example shows the structure of a DPNS `domain` document as output
   "parentDomainName": "dash",
   "preorderSalt": "bcCSdtGqqZdXBQB4DDBIU2RPAwFDFt9tMr0LX6m5qCQ=",
   "records": {
-    "dashUniqueIdentityId": "UQTRY+wqPyL27V7YjJadJdyXVBETj6CfzvqUg5aY5E4="
+    "identity": "UQTRY+wqPyL27V7YjJadJdyXVBETj6CfzvqUg5aY5E4="
   },
   "subdomainRules": {
     "allowSubdomains": false
   },
   "$revision": 1,
   "$createdAt": null,
   "$updatedAt": null,
-  "$dataContract": {
+  "$dataContractId": {
     // Truncated ...
    },
   "$type": "domain"

diff --git a/docs/explanations/platform-protocol-state-transition.md b/docs/explanations/platform-protocol-state-transition.md
@@ -45,6 +45,12 @@ The following table contains a list of currently defined payload types:
 | [Identity Credit Withdrawal](../protocol-ref/identity.md) (`6`) | Information required to withdraw credits from Dash Platform |
 | [Identity Credit Transfer](../protocol-ref/identity.md) (`7`) | Information required to transfer credits |
 | Masternode Vote (`8`) | Contested resource vote details (e.g., [DPNS premium name vote](../explanations/dpns.md#conflict-resolution)) |
+| [Identity Credit Transfer To Addresses](../protocol-ref/address-system.md#identity-credit-transfer-to-addresses) (`9`) | Transfer identity credits to one or more Platform addresses |
+| [Identity Create From Addresses](../protocol-ref/address-system.md#identity-create-from-addresses) (`10`) | Create a new identity funded from Platform addresses |
+| [Identity Top Up From Addresses](../protocol-ref/address-system.md#identity-top-up-from-addresses) (`11`) | Add credits to an existing identity from Platform addresses |
+| [Address Funds Transfer](../protocol-ref/address-system.md#address-funds-transfer) (`12`) | Transfer funds between Platform addresses |
+| [Address Funding From Asset Lock](../protocol-ref/address-system.md#address-funding-from-asset-lock) (`13`) | Fund a Platform address using an asset lock proof |
+| [Address Credit Withdrawal](../protocol-ref/address-system.md#address-credit-withdrawal) (`14`) | Withdraw credits from a Platform address |
 
 ### Application Usage
 

diff --git a/docs/explanations/platform-protocol.md b/docs/explanations/platform-protocol.md
@@ -30,11 +30,11 @@ For additional detail, see the [Document](../explanations/platform-protocol-docu
 
 A state transition represents a change made by a user to the application and platform states. It consists of:
 
-* Either:
-  * An array of documents, or
-  * One data contract
-* The contract ID of the application to which the change is made
-* The user's signature.
+* A header (version and payload type)
+* A payload
+* The user's signature
+
+The payload varies by type and covers a range of operations including document and token updates, data contract creation, identity management, credit transfers, and masternode voting.
 
 The user signature is made for the binary representation of the state transition using a private key associated with an [identity](../explanations/identity.md). A state transition is constructed by a client-side library when the user creates documents and submits them to the platform API.
 

diff --git a/docs/explanations/tokens.md b/docs/explanations/tokens.md
@@ -103,15 +103,17 @@ When creating a token, you define its configuration using the following paramete
 
 | Configuration Parameter | Mutable           | Default |
 |:------------------------|:------------------|:--------|
+| Description                              | Yes | None |
 | [Conventions](#display-conventions)      | Yes | N/A. Depends on implementation |
-| [Decimal precision](#display-conventions)| Yes | [8](https://github.com/dashpay/platform/blob/v2.0.1/packages/rs-dpp/src/data_contract/associated_token/token_configuration/v0/mod.rs#493) |
-| [Base supply](#token-supply)             | **No**  | [100000](https://github.com/dashpay/platform/blob/v2.0.1/packages/rs-dpp/src/data_contract/associated_token/token_configuration/v0/mod.rs#L495) |
+| [Decimal precision](#display-conventions)| Yes | [8](https://github.com/dashpay/platform/blob/v3.1-dev/packages/rs-dpp/src/data_contract/associated_token/token_configuration_convention/v0/mod.rs#L46) |
+| [Base supply](#token-supply)             | **No**  | [100000](https://github.com/dashpay/platform/blob/v3.1-dev/packages/rs-dpp/src/data_contract/associated_token/token_configuration/v0/mod.rs#L498) |
 | [Maximum supply](#token-supply)          | Yes | None |
-| [Keep history](#history)                 | Yes | True |
+| [Keep history](#history)                 | Yes | True (all history types) |
 | [Start paused](#initial-state)           | Yes | False |
 | [Allow transfer to frozen balance](#allow-transfer-to-frozen-balance) | Yes | True |
 | [Main control group](#main-control-group)| Yes | None |
 | Main control group can be modified       | Yes | NoOne |
+| Marketplace rules                        | Yes | None |
 
 #### Display Conventions
 
@@ -231,7 +233,7 @@ Groups can be used to distribute token configuration and update authorization ac
 
 - Each group member is assigned an integer power.
 - The group itself has a required power threshold to authorize an action.
-- Groups can have up to 256 members, each with a maximum power of 2^16 - 1 (65536).
+- Groups can have up to 256 members, each with a maximum power of 2^16 - 1 (65535).
 - Changes to a token (e.g., mint, burn, freeze) can be configured so they require group authorization. This is done by assigning the group under the [token rule configuration](#rules).
 
 **Example**