dashpay · thephez · Jul 6, 2026 · Jul 1, 2026 · Jul 2, 2026 · Jul 2, 2026
diff --git a/_templates/sidebar-main.html b/_templates/sidebar-main.html
@@ -447,6 +447,11 @@
        </ul>
       </details>
      </li>
+     <li class="toctree-l1">
+      <a class="reference internal" href="docs/reference/platform-proofs.html">
+       Platform Proofs
+      </a>
+     </li>
      <li class="toctree-l1">
       <a class="reference internal" href="docs/reference/query-syntax.html">
        Query Syntax

diff --git a/docs/explanations/platform-protocol-data-contract.md b/docs/explanations/platform-protocol-data-contract.md
@@ -75,7 +75,7 @@ For more detailed information, see the [Platform Protocol Reference - Data Contr
 
 ## Example Contract
 
-The [DashPay contract](https://github.com/dashpay/platform/blob/master/packages/dashpay-contract/schema/dashpay.schema.json) is included below for reference. It defines a `contact` document and a `profile` document. Each of these documents then defines the properties and indices they require:
+The [DashPay contract](https://github.com/dashpay/platform/blob/master/packages/dashpay-contract/schema/v1/dashpay.schema.json) is included below for reference. It defines a `contactRequest` document, a `profile` document, and a `contactInfo` document. Each of these documents then defines the properties and indices they require:
 
 :::{dropdown} DashPay contract
   ```json

diff --git a/docs/explanations/platform-protocol-data-trigger.md b/docs/explanations/platform-protocol-data-trigger.md
@@ -18,6 +18,8 @@ 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.
 
+Which trigger runs for a given contract, document type, and action is defined in the data trigger [binding list](https://github.com/dashpay/platform/blob/master/packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/bindings/list/v0/mod.rs). The trigger implementations linked in the tables below (for example the shared `reject` trigger) are generic and do not name the contracts that use them - the binding list is what associates each action with its trigger.
+
 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 |
@@ -40,6 +42,6 @@ In addition to DPNS, DPP ships data triggers for a small set of other system con
 | - | - | - | - |
 | DashPay | `contactRequest` | [`CREATE`](https://github.com/dashpay/platform/tree/master/packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/dashpay) | Enforces DashPay-specific rules on outgoing contact requests |
 | ---- | ---- | ---- | ---- |
-| Withdrawals | `withdrawal` | [`CREATE`/`REPLACE`/`DELETE`](https://github.com/dashpay/platform/tree/master/packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/withdrawals) | Enforces withdrawal status transitions and prevents direct external mutation of withdrawal documents |
+| Withdrawals | `withdrawal` | [`REPLACE`/`DELETE`](https://github.com/dashpay/platform/tree/master/packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/withdrawals) | Enforces withdrawal status transitions and prevents direct external mutation of withdrawal documents |
 
 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
@@ -14,7 +14,7 @@ Documents are defined in an application's [Data Contract](../explanations/platfo
 
 ### Base Fields
 
-Dash Platform Protocol (DPP) defines a set of base fields that must be present in all documents. For the [reference implementation](https://github.com/dashpay/platform/tree/master/packages/rs-dpp), the base fields shown below are defined in the [document base schema](https://github.com/dashpay/platform/blob/master/packages/rs-dpp/src/schema/document/v0/documentBase.json).
+Dash Platform Protocol (DPP) defines a set of base fields that must be present in all documents. For the [reference implementation](https://github.com/dashpay/platform/tree/master/packages/rs-dpp), the base fields shown below are defined in the [document base fields](https://github.com/dashpay/platform/blob/master/packages/rs-dpp/src/document/fields.rs).
 
 | Field Name | Description |
 | - | - |

diff --git a/docs/explanations/platform-protocol-state-transition.md b/docs/explanations/platform-protocol-state-transition.md
@@ -51,6 +51,12 @@ The following table contains a list of currently defined payload types:
 | [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 |
+| [Shield](../protocol-ref/shielded-pool.md#shield) (`15`) | Move transparent Platform funds into the [shielded pool](../explanations/shielded-pool.md) |
+| [Shielded Transfer](../protocol-ref/shielded-pool.md#shielded-transfer) (`16`) | Transfer value privately between shielded notes |
+| [Unshield](../protocol-ref/shielded-pool.md#unshield) (`17`) | Move funds from the shielded pool back to a Platform address |
+| [Shield From Asset Lock](../protocol-ref/shielded-pool.md#shield-from-asset-lock) (`18`) | Fund the shielded pool directly from an asset lock proof |
+| [Shielded Withdrawal](../protocol-ref/shielded-pool.md#shielded-withdrawal) (`19`) | Withdraw funds from the shielded pool to Dash Core (L1) |
+| [Identity Create From Shielded Pool](../protocol-ref/shielded-pool.md#identity-create-from-shielded-pool) (`20`) | Create a new identity funded from the shielded pool |
 
 ### Application Usage
 

diff --git a/docs/explanations/shielded-pool.md b/docs/explanations/shielded-pool.md
@@ -6,9 +6,9 @@
 
 ## Overview
 
-The shielded pool is an optional privacy layer on Dash Platform that lets users hold and move credits without revealing balances, sender, or recipient on-chain. Funds move *into* the pool through a shield transition, move *within* the pool privately, and exit through an unshield or shielded withdrawal. While funds remain inside the pool, only their owner can see them.
+The shielded pool is an optional privacy layer on Dash Platform that lets users hold and move credits without revealing balances, sender, or recipient on-chain. Funds move *into* the pool through a shield transition, move *within* the pool privately, and exit through an unshield, a shielded withdrawal, or by funding a newly created identity. While funds remain inside the pool, only their owner can see them.
 
-The pool uses the [Orchard](https://zips.z.cash/protocol/protocol.pdf) shielded protocol — the same zk-SNARK-based design used by Zcash for its current shielded pool. Transactions inside the pool prove their own validity without disclosing the amounts or parties involved.
+The pool uses the [Orchard](https://zips.z.cash/protocol/protocol.pdf) shielded protocol — the same zero-knowledge design (Halo 2 proofs, with no trusted setup) used by Zcash for its current shielded pool. Transactions inside the pool prove their own validity without disclosing the amounts or parties involved.
 
 ## When to use the shielded pool
 
@@ -40,11 +40,11 @@ When a note is created for a recipient, the platform stores an **encrypted note
 
 ### Actions and the action-count limit
 
-A shielded transition is composed of one or more **actions**. Each action structurally pairs one spend (consuming a prior note) with one output (creating a new note), bundled together so observers cannot tell which spend funded which output. A single shielded transition is limited to **16 actions** to keep transitions within the platform's 20 KB state-transition size budget.
+A shielded transition is composed of one or more **actions**. Each action structurally pairs one spend (consuming a prior note) with one output (creating a new note), bundled together so observers cannot tell which spend funded which output. The consensus rules cap a single shielded transition at **16 actions**. In practice the ~20 KiB (20,480-byte) state-transition size budget is the binding limit: because the Halo 2 proof grows with each action, a real transition fits only around 6 actions well before it reaches the 16-action cap.
 
 ## Transition types
 
-Five state transition types interact with the shielded pool. The wire-level structure of each — including field-by-field tables and source links — is documented in the [Shielded Pool protocol reference](../protocol-ref/shielded-pool.md).
+Six state transition types interact with the shielded pool. The wire-level structure of each — including field-by-field tables and source links — is documented in the [Shielded Pool protocol reference](../protocol-ref/shielded-pool.md).
 
 ### Shield
 
@@ -66,6 +66,10 @@ Moves credits *out of* the pool to a [Platform address](../protocol-ref/address-
 
 Moves credits *out of* the pool back to Dash Core (L1) via the platform's withdrawal mechanism. Like an unshield, it reveals an amount and an L1 destination, but the funds leave Platform entirely rather than landing in a Platform address.
 
+### Identity create from shielded pool
+
+Creates a new identity funded directly from the pool by spending one or more notes. Like an unshield, this moves credits *out of* the pool — here into a freshly created identity rather than a Platform address. The new identity's ID is derived from the sorted set of spend nullifiers, making it unique and single-use.
+
 ## What the pool does not provide
 
 - **Anonymity sets**: The privacy guarantee depends on how many other notes exist in the pool. A pool with a single user offers limited cover; privacy improves as more users participate.

diff --git a/docs/explanations/tokens.md b/docs/explanations/tokens.md
@@ -107,8 +107,8 @@ When creating a token, you define its configuration using the following paramete
 |:------------------------|:------------------|:--------|
 | Description                              | Yes | None |
 | [Conventions](#display-conventions)      | Yes | N/A. Depends on implementation |
-| [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) |
+| [Decimal precision](#display-conventions)| Yes | [8](https://github.com/dashpay/platform/blob/v4.0.0/packages/rs-dpp/src/data_contract/associated_token/token_configuration_convention/v0/mod.rs#L47) |
+| [Base supply](#token-supply)             | **No**  | [100000](https://github.com/dashpay/platform/blob/v4.0.0/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 (all history types) |
 | [Start paused](#initial-state)           | Yes | False |
@@ -290,9 +290,8 @@ When enabled, the authorized party can set the token price using a state transit
 
 ### Marketplace
 
-Token contracts already expose marketplace rules in their configuration, which declares a trade mode that governs how tokens may be traded on Platform. The currently supported trade modes are:
+Token contracts already expose marketplace rules in their configuration, which declares a trade mode that governs how tokens may be traded on Platform. The only trade mode currently defined is:
 
-- **`NotTradeable`** - the token cannot be traded on Platform (default).
-- **`TradeableOnMarketplace`** - the token is eligible for trading via Platform's marketplace mechanism.
+- **`NotTradeable`** - the token cannot be traded on Platform. This is the default and, at present, the only available value.
 
-The protocol-level marketplace rules are in place, but broader client tooling and user-facing marketplace experiences are expected to continue evolving in future releases.
+A dedicated marketplace trade mode is reserved for a future release. The protocol-level marketplace rules exist to support this, but the trade mode itself, along with broader client tooling and user-facing marketplace experiences, is expected to continue evolving in future releases.
diff --git a/docs/index.md b/docs/index.md
@@ -149,6 +149,7 @@ explanations/query
 reference/dapi-endpoints
 reference/query-syntax
 reference/data-contracts
+reference/platform-proofs
 reference/glossary
 ```
 

diff --git a/docs/intro/testnet.md b/docs/intro/testnet.md
@@ -24,6 +24,7 @@ The Dash Platform features available on testnet include:
 - [Data Contracts](../explanations/platform-protocol-data-contract.md): creation of data contracts
 - [Documents](../explanations/platform-protocol-document.md): used to store/update/delete data associated with data contracts
 - [DashPay](../explanations/dashpay.md): a data contract enabling a decentralized application that creates bidirectional direct settlement payment channels between identities and supports contact (name) based payments
+- [Tokens](../explanations/tokens.md): creation and management of tokens (similar to ERC-20 style assets) using data contracts, without writing smart contracts
 
 ## Getting involved
 

diff --git a/docs/intro/what-is-dash-platform.md b/docs/intro/what-is-dash-platform.md
@@ -61,7 +61,7 @@ verification, making it practical for light clients and user-facing applications
 
 ### DAPI - A decentralized API
 
-DAPI is a _decentralized_ HTTP API exposing [JSON-RPC](https://www.jsonrpc.org/) and [gRPC](https://grpc.io/) endpoints. Through these endpoints, developers can send and retrieve application data and query the Dash blockchain.
+DAPI is a _decentralized_ HTTP API exposing [gRPC](https://grpc.io/) and [JSON-RPC](https://www.jsonrpc.org/) endpoints. Developers send and retrieve Dash Platform application data over the gRPC endpoints, while the JSON-RPC endpoints expose some layer 1 (Dash Core blockchain) information.
 
 DAPI provides developers the same access and security as running their own Dash node without the cost and maintenance overhead. Unlike traditional APIs which have a single point of failure, DAPI allows clients to connect to different instances depending on resource availability in the Dash network.