What is standardized
- public declaration of Datamorphosis
- state-specific reconstruction object model
- digest cross-binding
- canonical payload offset semantics
- layout strategy semantics
- JPEG, TXT, and PDF carrier profiles
Datamorpho Specification v0.001
Normative core specification for multi-state files
This document defines the normative structure of Datamorpho v0.001: the public manifest, concealed payload semantics, reconstruction object model, digest binding, and the initial carrier profiles for JPEG, TXT, and PDF.
Scope
What the specification defines
Datamorpho v0.001 is the first normative public release of the protocol. It defines the file-level structure and semantics required for interoperable Datamorpho creation and reconstruction, while intentionally leaving many deployment-specific behaviors out of scope.
What is intentionally out of scope
- viewer UX details
- trigger execution engines
- wallet-specific release logic
- smart contract business logic
- secret delivery infrastructure beyond the reconstruction object model
- implementation-specific UI and workflow choices
Important boundary
Datamorpho standardizes the structure of files and reconstruction semantics. It does not attempt to standardize every future viewer, decryption interface, or trigger-verification workflow.
Core model
Four logical layers define a Datamorphed file
Datamorpho organizes a file into clear protocol layers so implementations can reason about discoverability, hidden bytes, and reconstruction without ambiguity.
Base Carrier
The original visible file that remains valid in its native format.
Public Manifest
The declared metadata layer that identifies states, triggers, MorphoStorage, and reconstruction digests.
Concealed Payload
The byte region or regions from which hidden states may later be reconstructed.
Reconstruction Object
The state-specific secret-bearing object that provides fragment map, key material, and reconstruction instructions.
Carrier profiles
The first three carrier profiles
Version 0.001 begins with JPEG, TXT, and PDF. These provide a practical starting point across image, text, and structured document carriers.
jpeg-trailer
A valid JPEG image followed by a Datamorpho Binary Block appended after the final end-of-image marker.
txt-envelope
A visible text file followed by a terminal Datamorpho envelope containing the public manifest and encoded payload.
pdf-incremental
A valid PDF followed by Datamorpho objects and payload streams appended through an incremental-update section.
Public declaration
The public manifest makes Datamorphosis explicit
Datamorpho is not steganography. The standard requires a public declaration that hidden states exist and where reconstruction information may later be found.
Required top-level concepts
The public manifest identifies the Datamorpho version, manifest type, carrier, profile, and the declared set of hidden states.
State descriptors
Each state descriptor identifies a state_id, its declared triggers, one or more MorphoStorage directions, and the expected reconstruction-object digest.
MorphoStorage
MorphoStorage is a generalized locator model. It may point to a URI, an IPFS CID, an EVM contract call, a textual instruction, or another implementation-defined retrieval direction.
Reconstruction semantics
A reconstruction object targets exactly one hidden state
In Datamorpho v0.001, the reconstruction object is a complete secret-bearing artifact for one target state. It contains the fragment map, ordering, layout strategy, digest binding, cryptographic information, and key material required to reconstruct that hidden state.
What it identifies
- the target
state_id - layout strategy
- carrier file digest
- fragment offsets and lengths
- fragment order
- state or fragment key material
What it allows
- independent release of states
- non-sequential state publication
- different cryptographic suites within one state
- shared key material or fragment-level overrides
- deterministic reconstruction from sparse byte spans
Normative assumption in v0.001
The reconstruction object is treated as the secret object. If it is already sensitive because it reveals the fragment map and suite instructions, there is no strong architectural reason to forbid it from also carrying the key material needed for reconstruction.
Layout strategy
Sparse and sparse-with-chaff
Datamorpho v0.001 standardizes two payload layout strategies so implementations can choose between efficiency and additional ambiguity depending on carrier size, bandwidth, and practical constraints.
sparse
Meaningful bytes are non-contiguous and only the referenced spans matter. This option remains useful for very large carriers or environments where payload size, storage, or transfer costs matter significantly.
sparse-with-chaff
Meaningful bytes are non-contiguous and unreferenced bytes are intentionally present as ambiguity-increasing material. Those bytes may include chaff, filler, or bytes belonging to other states.
Boundaries
What the standard does not try to do
Datamorpho deliberately keeps the core specification focused. It standardizes the structure of multi-state files and reconstruction semantics, but avoids overreaching into every implementation-specific decision.
Not a viewer standard
The standard does not define a universal viewer UX or interpretation flow.
Not a trigger engine
Trigger declaration is standardized, but trigger execution logic is not.
Not a wallet-specific protocol
Onchain integrations are possible, but wallet logic and business rules remain implementation-specific.
Review
This specification is meant to be discussed in public
Datamorpho is an open protocol project. Public review, implementation feedback, examples, and criticism are part of how the standard should mature.
Read the Whitepaper
Use the whitepaper for the conceptual rationale, security framing, and long-term project direction.
Open the repository
Specification work, tooling, examples, and project structure live in the public repository.
Join the discussion
Questions, proposals, and design discussion should happen in public and remain easy to review.