What is Dash Platform?
See what Dash Platform lets you build, and what you will build here.
Learning objectives
By the end of this lesson, you will be able to:
- separate Dash Core's job — moving money — from Dash Platform's job — storing application data;
- describe how Platform stores data: a schema you declare, records the schema accepts, and signed changes that update them;
- name concrete kinds of applications you can build on Dash; and
- outline the application you will assemble, end to end, later in this course.
In the previous lesson you met Dash the money. This lesson introduces the other half of the same network: Dash Platform, the layer that gives your application somewhere to keep its data.
One network, two jobs
Dash is one network organized as two layers, each focused on its own job. You already met the first:
- Dash Core is the layer-1 money layer. It settles Dash payments and carries the currency itself.
- Dash Platform is the layer-2 application-data layer. It stores structured application data — the records behind usernames, profiles, listings, and other app state — and verifies that only authorized operations change it.
The relationship runs one way: Platform can read what is on Core, but Core does not depend on Platform. Splitting the network this way keeps the money layer focused on money while the data layer handles everything an application needs to keep.
A useful mental model
Core is the payment rail. Platform is the database. One network, two jobs.
How Platform stores your data
Most blockchains add application logic by letting you deploy a — program code the network runs for you. Platform takes the opposite approach: there is no contract code of your own to upload or run. Instead, you describe your data, and the network stores and validates it.
Three ideas carry the whole thing:
- A data contract describes the shape of your data. It is a schema — a JSON Schema document that declares the kinds of records your app stores, with their fields and types. It is the same idea as defining a schema for a document-oriented database such as MongoDB: you say what a record may contain, and the network holds you to it.
- Documents are the records. Each record your app actually stores is a document, in the same sense as a row in a table or an object in a database. Every document must conform to the data contract it belongs to, and each one is owned by an identity.
- State transitions are the only way data changes. Nothing writes to Platform directly. Every create, update, or delete is a signed state transition from the identity that owns the record. The network checks the change against the contract, and only then records it.
Here is the smallest possible taste of idea one. A note-taking app might describe its records like this:
{
"note": {
"type": "object",
"properties": {
"message": { "type": "string", "position": 0 }
},
"required": ["message"],
"additionalProperties": false
}
}This is a declaration, not code. (The position entry is an ordering detail you will meet when you write contracts yourself later on — for now, notice only the shape.) Hold onto the pattern: declare the data, submit signed changes, let the network validate and store them.
Two components do the storing and serving:
- Drive is Platform's decentralized storage. It validates each signed change and keeps the network's copy of every app's data in , a storage engine that can hand back cryptographic proofs with an answer to a query.
- DAPI — the decentralized API — is how your app talks to all of it. It exposes and endpoints, so a client can read and write Platform data (and query Core) through the SDK without running a node of its own.
Why the proofs matter
Because GroveDB answers come with proofs, your app can check that the data it reads is genuinely the network's data — not something a single server made up. You do not have to trust the node you queried; you verify what it returns.
What you can build
With storage, identities, and signed writes in place, the same primitives combine into many different applications. Concrete things developers build on Platform include:
- Usernames. The Dash Platform Name Service (DPNS) registers human-readable
.dashnames likealice.dashand ties each one to a Platform identity — a persistent account that owns data and signs the changes to it. DPNS is itself just an app built on Platform. - Shared application data. Publish a data contract and submit documents, so your users share verifiable records — profiles, posts, listings — instead of trusting one company's database.
- Tokens. Create configurable fungible tokens (interchangeable, one-like-another units) for rewards, memberships, or loyalty points, without deploying contract code.
- NFTs. Build unique, document-based non-fungible tokens for collectibles and digital goods — each one is a document with a unique ID, with transfer and purchase built in.
- Payments by name. DashPay, Dash's flagship wallet, sends and receives money addressed to a username instead of a bare address by building on Platform's identities and DPNS names.
The documentation's own tutorials build working examples with these pieces: Dashnote (a small notes app), DashMint Lab (an NFT marketplace), and DashPay.
Notice what is absent from the list: a marketplace for arbitrary user-deployed programs. Platform gives you storage, validation, and signed operations — it does not run unrestricted code on every node. You design the data and the rules around it in your own application code.
What you will build in this course
The rest of the course is hands-on. Working entirely on — the parallel copy of the network that runs on free coins — you will assemble one small application from end to end:
- Connect to DAPI and make a verified read.
- Derive and fund a Platform address.
- Create a Platform identity.
- Register a DPNS username.
- Publish a data contract for your app's records.
- Submit and query documents.
- Transfer a document and run a purchase flow.
- Create a native token and charge tokens for document operations.
By the final module you will have touched every layer introduced here — the Core payment rail, identities, names, a data contract, documents, and a token — all without running a node of your own. Each hands-on lesson builds one piece; together they make one working app.
Checkpoint
Pass the quiz to complete the lesson.
Knowledge check
Restoring your progress…
4 correct to pass
What you accomplished
You can now separate Dash Core's money job from Dash Platform's data job, and describe how Platform stores data — a schema you declare, documents it accepts, and signed state transitions that change them. You can name the concrete applications that combination makes possible, from .dash usernames to tokens and NFTs, and you know the path ahead: a hands-on, testnet build that takes you from your first verified read to a token-charged application.