docs: v4.1.0 audit updates

CLAUDE.md

@@ -89,7 +89,7 @@ The DAPI endpoint reference is split between an overview page (`docs/reference/d
 When you add or materially update an entry on a detail page, also update the matching row on `dapi-endpoints.md`:
 
 - Keep the description in sync between the two pages.
-- Prefix the overview row's description with `**Added in Dash Platform vX.Y.Z**` (new endpoints) or `**Updated in Dash Platform vX.Y.Z**` (modified endpoints), followed by `<br>` and the description. Use **bold** for the current release's annotations; older releases use *italics*.
+- Prefix the overview row's description with `**Added in Dash Platform vX.Y.Z**` (new endpoints) or `**Updated in Dash Platform vX.Y.Z**` (modified endpoints), followed by `<br>` and the description. Use **bold** for the current major release's annotations; older major releases use *italics*.
 - For a whole new endpoint group, wrap the new section in a `:::{versionadded} X.Y.Z` admonition above its table — see Security Groups, Tokens, Address System, and Shielded Transactions for the pattern.
 
 For the full per-release endpoint review process (proto diff, example refresh, demoting annotations to italics), see [RELEASE.md](RELEASE.md).

_static/dashmint-lite.html

@@ -119,7 +119,7 @@ <h2>Browse cards</h2>
     // package and serves it as a browser-native ES module. Pinned to the same
     // version the React app at ../package.json depends on so both UIs behave
     // identically against the same testnet contract.
-    import { EvoSDK } from 'https://esm.sh/@dashevo/evo-sdk@4.0.0';
+    import { EvoSDK } from 'https://esm.sh/@dashevo/evo-sdk@4.1.0';
 
     // The token-enabled "card" data contract is already published on testnet by
     // the React app. Anyone querying with the same contract id hits the same
@@ -131,12 +131,11 @@ <h2>Browse cards</h2>
     // nodes — no node URL or config needed. connect() does the gRPC handshake
     // + initial sync. No identity or signing is required for read-only queries.
     //
-    // Workaround: pin the platform protocol version for evo-sdk dev.6 so the
-    // SDK doesn't ask testnet for a newer protocol it can't decode. Mirrors
-    // PLATFORM_VERSION_OVERRIDE in setupDashClient-core.mjs. Remove once a
-    // fixed SDK release lands.
+    // The platform protocol version is left unset on purpose: the SDK negotiates
+    // it with the network. Passing `version` pins it and disables that, so a
+    // hardcoded value silently goes stale at the next network upgrade.
     async function connectSdk() {
-      const sdk = EvoSDK.testnetTrusted({ version: 11 });
+      const sdk = EvoSDK.testnetTrusted();
       await sdk.connect();
       return sdk;
     }

_static/dashnote-lite.html

@@ -129,7 +129,7 @@ <h2>Get note by ID</h2>
     // package and serves it as a browser-native ES module. Pinned to the same
     // version the React app at ../package.json depends on so both UIs behave
     // identically against the same testnet contract.
-    import { EvoSDK } from 'https://esm.sh/@dashevo/evo-sdk@4.0.0';
+    import { EvoSDK } from 'https://esm.sh/@dashevo/evo-sdk@4.1.0';
 
     // The "note" data contract is already published on testnet by the React app.
     // Anyone querying with the same contract id hits the same documents.

_static/dashproof-lite.html

@@ -120,7 +120,7 @@ <h2>History by chainId</h2>
     // package and serves it as a browser-native ES module. Pinned to the same
     // version the React app at ../package.json depends on so both UIs behave
     // identically against the same testnet contract.
-    import { EvoSDK } from 'https://esm.sh/@dashevo/evo-sdk@4.0.0';
+    import { EvoSDK } from 'https://esm.sh/@dashevo/evo-sdk@4.1.0';
 
     // The "anchor" data contract is already published on testnet by the React app.
     // Anyone querying with the same contract id hits the same documents.

docs/explanations/dapi.md

@@ -31,4 +31,4 @@ retrieval.
 
 ## 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, transactions/transitions, and masternode-list updates. For a list of all endpoints and usage details, please see the [DAPI endpoint reference section](../reference/dapi-endpoints.md).
+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. The layer 1 Core gRPC service additionally provides streaming of events related to blocks, transactions, and masternode-list updates; the layer 2 Platform endpoints are request/response only. For a list of all endpoints and usage details, please see the [DAPI endpoint reference section](../reference/dapi-endpoints.md).

docs/explanations/dpns.md

@@ -42,8 +42,8 @@ Since some names may be popular, the registration process includes a voting mech
 :::{note}
 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")
+* Between 3 and 19 characters long (i.e. "alice", "quantumexplorer") AND
+* Contain no numbers other than 0 and/or 1, and no characters besides letters and hyphens (i.e. "bob", "carol01", "quantum-explorer")
 
 All other available names can be registered immediately.
 :::
@@ -70,14 +70,20 @@ Assuming masternodes do not vote to lock, the identity receiving the most votes
 Locked names cannot currently be re-requested or awarded. This policy may be revisited in future Platform releases.
 :::
 
+### Name transfers and sales
+
+Registering a name is not necessarily the end of its lifecycle. A registered name can be transferred to another identity or offered for sale and bought by another identity. The DPNS contract has always declared names transferable and available for direct purchase, but Platform's validation rules rejected those operations until protocol version 13 (introduced in Dash Platform v4.1) lifted the restriction. Once ownership changes, the name resolves to its new owner, and that identity's private keys are what prove ownership from then on.
+
+The name record itself remains immutable and permanent: it cannot be edited or deleted, only transferred or sold. A name's transfer, purchase, and listing history is recorded, so the chain of ownership and the prices it was offered at can be retrieved and verified.
+
 ### Implementation
 
-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:
+DPNS names have several constraints as defined in the [DPNS data contract](https://github.com/dashpay/platform/blob/master/packages/dpns-contract/schema/v2/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/v2/dpns-contract-documents.json#L47) 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".
 

docs/explanations/drive-platform-chain.md

@@ -6,7 +6,7 @@
 
 ## Overview
 
-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.
+The platform chain is the [Drive](../explanations/drive.md) component responsible for replicating the platform state across all evonodes participating in the network. Evonodes (the high-performance masternode tier) 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
 
@@ -19,7 +19,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
+- Hosted exclusively on evonodes (the high-performance masternode tier)
 - Uses a [practical Byzantine Fault Tolerance (pBFT)](../reference/glossary.md#practical-byzantine-fault-tolerance-pbft) consensus algorithm
 - Has a deterministic fee structure
 - Provides fast (~5 second target block spacing) and absolute block finality (no reorgs)

docs/explanations/drive.md

@@ -6,7 +6,7 @@
 
 ## 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](../explanations/dapi.md).
+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 evonodes. 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
 

docs/explanations/fees.md

@@ -42,13 +42,13 @@ Refer to the [Identity explanation](../explanations/identity.md) section for inf
 
 ## Fee Multiplier
 
-Given fluctuations of the Dash price, a variable *Fee Multiplier* provides a way to balance the cost of fees with network hosting requirements. All fees are multiplied by the Fee Multiplier:
+The *Fee Multiplier* provides a mechanism to balance the cost of fees against network hosting requirements as the Dash price fluctuates. It is recorded per epoch and used when distributing collected fees from the credit pools, along with epoch accounting.
 
-```text
-    feePaid = initialFee * feeMultiplier
-```
+The multiplier does not scale the fee a user is charged. The active fee version fixes it at 1.0x,
+and the final fee charged for a state transition is calculated using the complete formula below,
+including any user fee increase and storage refund.
 
-The Fee Multiplier is subject to change at any time via network governance and protocol updates.
+Fee parameters, including the multiplier, are fixed by the active fee version. They change only when the network activates a new protocol version, which happens once enough evonodes signal the newer version and the threshold is met at an epoch change.
 
 <!-- Uncomment once link available
 An in-depth look at the Fee Multiplier can be found at **link**

docs/explanations/identity.md

@@ -8,18 +8,25 @@
 
 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](../explanations/platform-protocol-state-transition.md) 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), most commonly 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.
 
 :::{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
 
-In order to [create an identity](#identity-create-process), a user pays the network to store their public key(s) on the platform chain. This is done by locking Dash on the Core chain in an asset lock transaction and then submitting an identity create state transition that references a proof of that lock.
+In order to [create an identity](#identity-create-process), a user pays the network to store their public key(s) on the platform chain. On the Core-chain path, this is done by locking Dash in an asset lock transaction and then submitting an identity create state transition that references a proof of that lock.
 
 Once an identity is created, its credit balance is used to pay for activity (e.g. use of applications). The [topup process](#identity-balance-topup-process) provides a way to add additional funds to the balance when necessary.
 
+Locking Dash on layer 1 is the primary funding route, but it is not the only one. An identity can also be created or topped up from credits already held at a [Platform address](../protocol-ref/address-system.md), or created directly from the [shielded pool](./shielded-pool.md) by spending shielded notes. Both routes fund the identity entirely on layer 2, without a Core chain asset lock.
+
+The processes below describe the Core-chain asset-lock path. For the layer 2 paths, see
+[Identity Create From Addresses](../protocol-ref/address-system.md#identity-create-from-addresses),
+[Identity Top Up From Addresses](../protocol-ref/address-system.md#identity-top-up-from-addresses),
+and [Identity Create From Shielded Pool](../protocol-ref/shielded-pool.md#identity-create-from-shielded-pool).
+
 ### Identity Create Process
 
 :::{note}
@@ -54,7 +61,7 @@ Unique identities are created for the owner, operator, and voting roles, with ea
 
 #### Voting
 
-All masternodes can use their identities to vote on Platform polls for contested resources. In Platform v1.0, masternode voting is used to resolve cases where multiple identities attempt to register the same [DPNS name](./dpns.md).
+All masternodes can use their identities to vote on Platform polls for contested resources. The best-known example is [DPNS](./dpns.md), where voting resolves cases in which multiple identities attempt to register the same name. Contested resources are a general data contract feature: any contract can mark a unique index as contested, so that competing attempts to claim the same value are settled by a masternode vote.
 
 #### Reward distribution
 
@@ -64,6 +71,6 @@ Note: the payout key is associated with the masternode owner identity, so both t
 
 ## Credits
 
-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 state transition, their credit balance increases by that amount. As they perform platform actions, these credits are deducted to pay the associated fees.
+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 state transition, their credit balance increases by that amount. Credits can also reach an identity from a [Platform address](../protocol-ref/address-system.md) or the [shielded pool](./shielded-pool.md) without a layer 1 lock. As they perform platform actions, these credits are deducted to pay the associated fees.
 
-Credits can be converted back to Dash using the identity credit withdrawal state transition, subject to a daily network-wide limit.
+Credits can be converted back to Dash using the identity credit withdrawal state transition, subject to a daily network-wide limit. That limit is a proportion of the total credits held on Platform rather than a fixed amount, so it grows and shrinks with the size of the network.

docs/explanations/nft.md

@@ -26,7 +26,7 @@ The following sections describe the features and options available for NFT creat
 
 ### Transfer and Trade
 
-NFTs can be directly transferred or traded without the need for a marketplace:
+NFTs can be directly transferred or traded without the need for a marketplace, provided the contract author enabled those options on the document type. Trading is off by default.
 
 * Transferring allows the owner to assign a new owner without making the NFT available for purchase.
 * Trading involves a two-step process where the seller sets the NFT's price, and the first buyer that matches this price receives the NFT automatically. Once the transaction is complete, the price is reset to prevent further immediate purchases, ensuring a non-interactive and seamless trading experience.
@@ -49,15 +49,15 @@ To preserve the authenticity of NFTs, Dash Platform includes creation restrictio
 
 ### Mutate
 
-NFTs can be immutable or mutable, depending on their intended use. Immutable NFTs cannot be altered after creation. This is crucial for items like digital artwork, where authenticity and originality are necessary. Mutable NFTs can be helpful in scenarios like updating a character in a game or altering a digital asset.
+NFTs can be immutable or mutable, depending on their intended use. Immutable NFTs cannot be altered after creation. This is crucial for items like digital artwork, where authenticity and originality are necessary. Mutable NFTs can be helpful in scenarios like updating a character in a game or altering a digital asset. Mutability is fixed when the document type is defined in the data contract.
 
 ```{eval-rst}
 .. _explanations-nft-delete:
 ```
 
 ### Delete
 
-Since some NFTs may represent transient or consumable things, Dash Platform allows NFTs to be deleted. This is more efficient than the "burn" mechanism many projects use to make an NFT unusable and provides flexibility in managing assets that may no longer be needed or valid.
+Since some NFTs may represent transient or consumable things, Dash Platform allows NFTs to be deleted. This is more efficient than the "burn" mechanism many projects use to make an NFT unusable and provides flexibility in managing assets that may no longer be needed or valid. Whether deletion is permitted is fixed when the document type is defined in the data contract.
 
 ```{eval-rst}
 .. _explanations-nft-create: