❗️This page is intended to provide a brief description of how data triggers work in the initial version of Hellar Platform. The design will likely undergo changes in the future.
Although data contracts provide much needed constraints on the structure of the data being stored on Hellar Platform, there are limits to what they can do. Certain system data contracts may require server-side validation logic to operate effectively. For example, HPNS must enforce some rules to ensure names remain DNS compatible. Hellar Platform Protocol (HPP) supports this application-specific custom logic using Data Triggers.
❗️ Constraints
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 Hellar Platform Protocol and only used in system data contracts.
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 separate triggers can be created for the CREATE
, REPLACE
, or DELETE
actions.
As an example, HPP contains several data triggers for HPNS. The domain
document has added constraints for creation. All HPNS document types have constraints on replacing or deleting:
Data Contract | Document | Action(s) | Trigger Description |
---|---|---|---|
HPNS | domain |
CREATE |
Enforces DNS compatibility, validate provided hashes, and restrict top-level domain (TLD) registration |
—- | —- | —- | —- |
HPNS | All Document Types | REPLACE |
Prevents updates to any HPNS document type |
HPNS | All Document Types | DELETE |
Prevents deletion of any HPNS document type |
When document state transitions are received, HPP checks if there is a trigger associated with the document type and action. If a trigger is found, HPP executes the trigger logic. Successful execution of the trigger logic is necessary for the document to be accepted and applied to the platform state.