dashpay / platform

Seriously fast decentralized applications for the Dash network Per-Crate Coverage | Crate | Lines | Coverage | |-------|------:|----------| | rs-dpp | 129k | | | rs-drive | 171k | | | rs-drive-abci | 125k | | | rs-sdk | 23k | | For in-depth architecture, internals, and developer documentation, see The Dash Platform Book. What is Dash Platform Dash Platform is a decentralized data storage and application layer built on top of the Dash payment network. It lets developers store, query, and cryptographically verify structured data on the Dash masternode network without deploying or executing user-written code on-chain. Instead of smart contracts, developers define **data contracts** -- JSON Schema-based specifications that describe the structure and validation rules for their application data. The network stores, indexes, and enforces these schemas directly. Applications interact with the platform through structured data reads and writes (called **state transitions**) rather than arbitrary code execution. Smart contract support is planned for Platform v4.0 (targeted for mainnet in 2027). How Dash Platform compares | | Ethereum | Solana | Dash Platform | |---|---|---|---| | **Primary purpose** | General-purpose smart contracts | High-throughput smart contracts | Decentralized data storage and querying | | **Consensus** | Gasper (PoS) | Tower BFT (PoS) | Tenderdash SBFT (masternode quorums, BLS threshold signatures) | | **Finality** | ~13 min (2 epochs) | **~0.4s (optimistic)** | **Instant (1 block)** | | **Decentralized querying** | Keys only (no native indexing) | Keys only (via RPC, no proofs) | **Rich queries with indexes, ordering, and ranges -- all with proofs** | | **State proofs** | Merkle-Patricia proofs | No native proofs | **GroveDB Merkle proofs for every query** | | **Light client trust** | Needs sync committee | Trusts RPC provider | **Cryptographic proof per response -- same security as a full node** | | **Data model** | Account / key-value | Account / key-value | **Structured documents with secondary indexes** | | **Smart contracts** | **Yes (Solidity / Vyper on EVM)** | **Yes (Rust / C on SVM)** | Coming in v4.0 | The standout difference is light client verification. Most chains either offer no state proofs (Solana) or give proofs that are expensive to verify (Ethereum's sync committee). Dash Platform serves a cryptographic proof with every query response, and a single BLS threshold signature is all a client needs to verify it. A mobile wallet gets the same security guarantees as a full node. For a comprehensive comparison across more chains, see the Platform Comparison chapter in The Dash Platform Book. Architecture deep dive The central problem Dash Platform solves is: how do you let a light client -- a mobile wallet, a browser app, a third-party service -- query decentralized state and **know** the answer is correct, without running a full node and without trusting the node that served the response? Platform's answer stacks four layers. At the bottom, GroveDB provides the raw authenticated storage -- a hierarchy of Merkle trees where every key-value pair has a cryptographic path up to a single root hash. GroveDB handles insertions, deletions, and proof generation, but it knows nothing about documents, identities, or application logic. Think of it as Platform's assembly language: powerful and provable, but operating at the level of individual tree operations. **Drive** is the layer that gives GroveDB meaning -- much as C gives structure and abstraction over assembly. Drive organizes GroveDB's raw trees into a structured query system with secondary indexes: it defines how documents, identities, balances, tokens, and data contracts are laid out across the tree hierarchy, how indexes are maintained, and how queries are translated into authenticated tree operations. When an application asks "give me all documents where , sorted by ", it is Drive that maps that query onto the right set of GroveDB tree traversals and returns a result with a proof. Above Drive sits **Drive-ABCI**, the execution layer that ties everything together. It connects Drive to Tenderdash consensus via ABCI, validates and applies state transitions, enforces protocol rules, and commits the GroveDB root hash into each consensus block. Tenderdash itself runs Scalable Byzantine Fault Tolerant (SBFT) consensus across a rotating quorum of masternodes. Unlike classical BFT where every validator signs every block, Tenderdash selects a deterministic quorum for each block and recovers a single BLS threshold signature from that quorum. One compact signature attests to the entire committed state, and that state root cryptographically commits to every individual piece of data in the system. The result is that to verify any single query result, a client needs only three things: the data itself, its Merkle proof against the state root, and the threshold signature on that root. No full node, no chain of block headers, no trust in the serving node. Key capabilities **Identities and naming.** Users register identities on-chain -- first-class protocol objects with hierarchical key management, not just addresses. Identities can hold multiple authentication and encryption keys with different security levels and purposes. The Dash Platform Naming Service (DPNS) maps human-readable usernames to identities, resolved directly by the network. **Credits and fees.** Users convert Dash into credits that pay for storage and state transitions. Fees are deterministic and based on the actual storage and processing cost of each operation. The platform supports transparent fee payment from Dash addresses as well as private fee payment through a shielded pool using Orchard-based zero-knowledge proofs (Halo2). **Tokens.** The platform supports user-created tokens with protocol-enforced rules for minting, burning, transferring, and freezing. Token behavior is configured declaratively through data contract definitions. Pre-pr…