01
Signed
The canonical payload hash has a verifiable ML-DSA-65 signature and a discoverable organization public key.
Controlled preview
Proof should describe its state, not imply finality.
Synaura can sign supported operations with an organization key and attach progressive timestamp evidence. Payload integrity, calendar attestation, and Bitcoin confirmation are different claims and must be displayed separately.
Important: submission to an OpenTimestamps calendar is not the same as a verified Bitcoin anchor. Synaura should use “Bitcoin verified” only when the proof validates and a network transaction reference is present.
Receipt state model
Each state adds evidence. A receipt must never be promoted to a later state merely because a submission request succeeded.
02
Timestamp submitted
A Merkle root was accepted for timestamp processing. This records submission, not external finality.
03
Calendar attested
The returned proof contains a calendar attestation that can be retained and re-checked.
04
Bitcoin verified
The proof independently verifies against a confirmed Bitcoin transaction and exposes that reference.
Independent verification contract
A verifier should not need to trust a status badge. It needs the exact payload, algorithm, key, signature, and timestamp proof.
Cryptographic envelope
Canonicalization
sorted-key JSON · UTF-8Digest
SHA-256Signature
ML-DSA-65 · FIPS 204Key scope
organization versioned keyCurrent disclosure
Historical preview receipts span multiple implementation versions. Some records may not contain a complete signature or external timestamp proof. Those records should be shown as unavailable or incomplete—not verified.
Signing by an organization key proves integrity and key possession; it does not by itself prove the human identity or authorization context unless that context is included in the signed envelope and independently validated.