What is Dash Platform?
See what Dash Platform adds to Dash and what you can build with it.
A Dash payment can settle before the rest of an application has done anything useful. You're building a ticket marketplace: Bob lists a ticket, Alice pays for it, and Core settles the money in seconds. Your app still has to remember that the ticket is now hers, what it admits her to, and who she is on the marketplace. Those records aren't payments, and parking them in a database you run hands the meaningful part of the app back to a single operator to control.
Two layers, two jobs
Dash is really two systems working as one. Dash Core keeps the payment ledger: moving Dash from one person to another. Dash Platform keeps everything an app might want to share beyond that. You still write your own frontend and business logic and run them wherever you like. Platform stores and validates shared state; it doesn't run arbitrary programs you upload.
That split doubles as your routing rule. A request that only moves Dash belongs on Core. A request that needs shared, queryable records owned by the people using the app, such as usernames, tickets, or assets, belongs on Platform. Your marketplace can take Alice's payment on Core and keep her ticket on Platform at the same time; that's normal, not a conflict.
The record after the payment
In a conventional app, Alice's marketplace profile is a row in your database. On Platform it's a document: an application record held in Drive, the network's storage layer. Drive keeps Platform's current state, and each app gets its own slice of that state, keyed by contract.
That relocation is what makes her profile portable. Because the record lives in Drive rather than your database, a second app reading the same contract shows Alice the same biography, and neither app is the copy that counts.
Nothing lands in Drive just because a client asked for it. Before an app can store anything, it publishes a data contract describing the record types it uses, their fields, and the rules a record must satisfy. The contract is the schema; the document is a record that fits it. A write that breaks the schema is refused, whoever sends it.
A valid record still needs an author
The contract settles "is this shaped correctly?" It says nothing about "who asked for this?"
An identity answers that. An identity is a persistent account on Platform that owns data. To create or change that data, the identity submits a signed ; the network checks the signature to learn who authorized the change, then checks the change against the contract. Alice's profile is owned by Alice's identity, so Bob can't quietly rewrite it, even if his replacement is well formed.
Names hang off identities too. The Dash Platform Name Service, DPNS, registers readable names and ties each to an identity, so a user can be addressed by a name rather than a bare identifier. Core moves money; it keeps no register of who owns which name. That register is itself an app built on Platform, the first hint that Platform's conveniences come from the same documents and identities you'll use.
Reaching the network
You don't run a full node just to record a profile. An app talks through DAPI, the decentralized API served by the masternodes that store Platform state, the kind called . DAPI exposes Core and Platform through one interface, and the SDKs wrap it, so your code reads and writes state without hosting any of it.
That convenience raises a question a private database never did: if a server hands you an answer, how do you know it's true? A Platform query can return a alongside the data, tying the answer to the state the network has committed. Your app verifies that instead of trusting whichever node happened to reply. Without it, shared storage would just be a database run by a stranger.
Two ways to hold value
Platform state holds more than plain rows. An app can issue assets, and the first design choice is which kind it needs.
A token is interchangeable value you configure inside your data contract: your app's own currency, say. Any two units are the same thing. Transfer is built in, as is buying units directly with credits.
An NFT isn't a separate kind of object. It's a document that stands for one distinct, ownable item like a ticket, a collectible, or a plot of land. Because it's a document it has a unique identity within its contract, and the ability to transfer it or sell it at a set price comes from the protocol rather than code you write. The shortcut: interchangeable value is a token; a specific thing one person can own is an NFT.
What stays private
Storing records on a network you don't run invites the opposite worry: is any of it private? The line that matters separates value from data.
Value can be. Platform supports a shielded pool for privately moving value, including credits created from Dash and supported app tokens. Within the pool, zero-knowledge proofs hide the sender, receiver, and amount.
Documents aren't private by default. A document in Drive is replicated, queryable state, and shielding a payment doesn't shield the related app data. If a record is confidential, keep it off Platform or encrypt it before writing it.
Who pays for the work
None of this runs for free. The network meters its work in , a balance kept separate from Dash. You create credits by locking Dash, and each identity carries a credit balance that Platform draws on when it stores data or processes a change.
Two choices stop every operation from starting with an empty-account dead end. A Platform address can hold credits, so funding exists before any identity does. And because anyone may top up any identity's balance, an app can simply cover its users' fees. Call that fee sponsorship. It isn't a special mechanism; it's a normal consequence of the open top-up rule, and it's what lets a product feel free to the user while the network still gets paid.
One app, assembled
Now the whole marketplace. Core settles Alice's Dash payment. Bob registers a DPNS name so buyers see a readable seller rather than a bare identifier. Your data contract declares a ticket record, and each ticket in Drive is a unique, transferable document (an NFT) that Alice purchases at Bob's set price through the protocol's built-in purchase. Her identity owns the ticket afterward, and your frontend tops up her credits so a fee never greets her. The event page, the pricing, the seat-inventory checks: that's your own code on your own servers. The network's job is holding the tickets, enforcing who owns each one, and running the purchase rules, the part that needed to outlive anyone's database.
Check your understanding
Restoring your progress…
6 correct to pass