Data Contract
Defining an application's data structure on Dash Platform
New site!
All content has been migrated to docs.dash.org. You will be automatically redirected momentarily.
Overview
As described briefly in the Dash Platform Protocol explanation, Dash Platform uses data contracts to define the schema (structure) of data it stores. Therefore, an application must first register a data contract before using the platform to store its data. Then, when the application attempts to store or change data, the request will only succeed if the new data matches the data contract's schema.
The first two data contracts are the DashPay wallet and Dash Platform Name Service (DPNS). The concept of the social, username-based DashPay wallet served as the catalyst for development of the platform, with DPNS providing the mechanism to support usernames.
Details
Ownership
Data contracts are owned by the identity that registers them. Each identity may be used to create multiple data contracts and data contract updates can only be made using the identity that owns it.
Structure
Each data contract must define several fields. When using the JavaScript implementation of the Dash Platform Protocol, some of these fields are automatically set to a default value and do not have to be explicitly provided. These include:
- The platform protocol schema it uses (default: defined by js-dpp)
- A contract ID (generated from a hash of the data contract's owner identity plus some entropy)
- One or more documents
In the example contract shown below, a contact document and a profile document are defined. Each of these documents then defines the properties and indices it requires.
Registration
Once a Dash Platform Protocol compliant data contract has been defined, it may be registered on the platform. Registration is completed by submitting a state transition containing the data contract to DAPI.
The drawing below illustrates the steps an application developer follows to complete registration.
Data Contract Registration
Updates
Since Dash Platform v0.22, it is possible to update existing data contracts in certain backwards-compatible ways. This includes adding new documents, adding new optional properties to existing documents, and adding non-unique indices for properties added in the update.
For more detailed information, see the Platform Protocol Reference - Data Contract page.
Example Contract
An example contract for DashPay is included below:
{
"profile": {
"type": "object",
"indices": [
{
"properties": [
{
"$ownerId": "asc"
}
],
"unique": true
},
{
"properties": [
{
"$ownerId": "asc"
},
{
"$updatedAt": "asc"
}
]
}
],
"properties": {
"avatarUrl": {
"type": "string",
"format": "url",
"maxLength": 2048
},
"avatarHash": {
"type": "array",
"byteArray": true,
"minItems": 32,
"maxItems": 32,
"description": "SHA256 hash of the bytes of the image specified by avatarUrl"
},
"avatarFingerprint": {
"type": "array",
"byteArray": true,
"minItems": 8,
"maxItems": 8,
"description": "dHash the image specified by avatarUrl"
},
"publicMessage": {
"type": "string",
"maxLength": 140
},
"displayName": {
"type": "string",
"maxLength": 25
}
},
"required": [
"$createdAt",
"$updatedAt"
],
"additionalProperties": false
},
"contactInfo": {
"type": "object",
"indices": [
{
"properties": [
{
"$ownerId": "asc"
},
{
"rootEncryptionKeyIndex": "asc"
},
{
"derivationEncryptionKeyIndex": "asc"
}
],
"unique": true
},
{
"properties": [
{
"$ownerId": "asc"
},
{
"$updatedAt": "asc"
}
]
}
],
"properties": {
"encToUserId": {
"type": "array",
"byteArray": true,
"minItems": 32,
"maxItems": 32
},
"rootEncryptionKeyIndex": {
"type": "integer",
"minimum": 0
},
"derivationEncryptionKeyIndex": {
"type": "integer",
"minimum": 0
},
"privateData": {
"type": "array",
"byteArray": true,
"minItems": 48,
"maxItems": 2048,
"description": "This is the encrypted values of aliasName + note + displayHidden encoded as an array in cbor"
}
},
"required": [
"$createdAt",
"$updatedAt",
"encToUserId",
"privateData",
"rootEncryptionKeyIndex",
"derivationEncryptionKeyIndex"
],
"additionalProperties": false
},
"contactRequest": {
"type": "object",
"indices": [
{
"properties": [
{
"$ownerId": "asc"
},
{
"toUserId": "asc"
},
{
"accountReference": "asc"
}
],
"unique": true
},
{
"properties": [
{
"$ownerId": "asc"
},
{
"toUserId": "asc"
}
]
},
{
"properties": [
{
"toUserId": "asc"
},
{
"$createdAt": "asc"
}
]
},
{
"properties": [
{
"$ownerId": "asc"
},
{
"$createdAt": "asc"
}
]
}
],
"properties": {
"toUserId": {
"type": "array",
"byteArray": true,
"minItems": 32,
"maxItems": 32,
"contentMediaType": "application/x.dash.dpp.identifier"
},
"encryptedPublicKey": {
"type": "array",
"byteArray": true,
"minItems": 96,
"maxItems": 96
},
"senderKeyIndex": {
"type": "integer",
"minimum": 0
},
"recipientKeyIndex": {
"type": "integer",
"minimum": 0
},
"accountReference": {
"type": "integer",
"minimum": 0
},
"encryptedAccountLabel": {
"type": "array",
"byteArray": true,
"minItems": 48,
"maxItems": 80
},
"autoAcceptProof": {
"type": "array",
"byteArray": true,
"minItems": 38,
"maxItems": 102
},
"coreHeightCreatedAt": {
"type": "integer",
"minimum": 1
}
},
"required": [
"$createdAt",
"toUserId",
"encryptedPublicKey",
"senderKeyIndex",
"recipientKeyIndex",
"accountReference"
],
"additionalProperties": false
}
}
This is a visualization of the JSON data contract as UML class diagram for better understanding of the structure:
Dashpay Contract Diagram
Updated 7 months ago