Data Trigger

This page is intended to provide a brief description of how data triggers work in Dash Platform.

Overview

Although data contracts provide much needed constraints on the structure of the data being stored on Dash Platform, there are limits to what they can do. Certain system data contracts may require server-side validation logic to operate effectively. For example, DPNS must enforce some rules to ensure names remain DNS compatible. Dash Platform supports this application-specific custom logic using Data Triggers, which are executed by the node’s execution layer (Drive) as part of state transition validation.

Attention

Given a number of technical considerations (security, masternode processing capacity, etc.), data triggers are not considered a platform feature at this time. They are currently hard-coded in the Drive execution layer, versioned with the protocol, and only used in system data contracts.

Details

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 a separate trigger can be created for any document transition action: create, replace, delete, transfer, purchase, updatePrice, and indexOnlyDelete.

Which trigger runs for a given contract, document type, and action is defined in the data trigger binding list. The binding list is versioned with the protocol, so the set of active triggers can change when a new protocol version activates. 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, Drive contains several data triggers for DPNS. The domain document has added constraints for creation, replacing, and deleting:

Data Contract	Document	Action(s)	Trigger Description
DPNS	domain	CREATE	Enforces DNS compatibility, validate provided hashes, and restrict top-level domain (TLD) registration
—-	—-	—-	—-
DPNS	domain	REPLACE	Prevents updates to DPNS domain documents
DPNS	domain	DELETE	Prevents deletion of DPNS domain documents

Note

The REPLACE and DELETE rows for DPNS both link to the same shared reject trigger, which DPNS reuses to disallow those actions on domain documents. The DPNS preorder document type has no data triggers at all - its immutability comes from the contract schema rather than from trigger logic.

The absence of a trigger matters too: DPNS domain documents deliberately have no trigger bound to the transfer, purchase, or updatePrice actions, so those actions fall through to generic document validation. That is what makes username transfers and sales possible, while REPLACE and DELETE remain rejected so name records stay immutable and permanent.

In addition to DPNS, Drive ships data triggers for a small set of other system contracts:

Data Contract	Document	Action(s)	Trigger Description
DashPay	contactRequest	CREATE	Enforces DashPay-specific rules on outgoing contact requests
DashPay	profile	CREATE/REPLACE	Validates that the optional core and Platform payment address fields carry a supported address type byte (P2PKH or P2SH), a rule the schema alone cannot express
—-	—-	—-	—-
Masternode Rewards	rewardShare	CREATE/REPLACE/DELETE	Rejects all three actions so ordinary identities cannot write reward share records
—-	—-	—-	—-
Withdrawals	withdrawal	REPLACE	Prevents direct external mutation of withdrawal documents
Withdrawals	withdrawal	DELETE	Allows deletion in COMPLETE status or terminal FAILED status

When document state transitions are received, Drive checks if there is a trigger associated with the document type and action. If a trigger is found, Drive executes the trigger logic. Successful execution of the trigger logic is necessary for the document to be accepted and applied to the platform state.