Support
We're here to help you get the most out of Truestamp. Find answers to common questions or get in touch with our support team.
Community & Updates
Share feedback, follow what we're building next, and see what just shipped. Each opens right here in a popup, so no separate account is needed.
Knowledge Base
Browse the concepts behind Truestamp. Pick a domain to explore, follow the links between concepts, or search across everything.
Tagged: hash
20
Cryptography
Byte-Prefix Registry
The complete lookup table of every single-byte SHA-256 domain-separation prefix Truestamp reserves, mapping each prefix value to the object and domain it isolates, so a verifier can reproduce any hash exactly.
Domain-Separated Hashing (SHA-256 Byte Prefixes)
How Truestamp separates SHA-256 hash contexts with single-byte domain prefixes (RFC 6962 style), keeping leaf hashes, node hashes, and each kind of hashed object in distinct hash spaces to prevent ambiguity and second-preimage confusion.
Ed25519 Signatures
How Truestamp uses Ed25519 to sign the 32-byte domain-separated hashes of items, blocks, entropy observations, and proof bundles, what a signature proves to a verifier, and how to fetch and pin the public signing keyring (key ids, rotation lineage) from /.well-known/keyring.json.
Glossary
Block hash
The SHA-256 digest (prefix 0x32) identifying a Truestamp block, binding its UUIDv7 id, previous-block hash, Merkle root, metadata hash, and signing-key ID; it chains blocks, commits to every item and observation in the block, is batched into epochs, and published as a beacon.
Byte prefix
The reserved single byte prepended to data before SHA-256 hashing for domain separation; every hashed object kind in Truestamp has its own registered prefix (0x00 Merkle leaf, 0x01 internal node, 0x11 item claims, 0x61 proof signing payload), enumerated in the byte-prefix registry.
Claims
The user-supplied data map an item is made of - a required name plus optional external content hash and algorithm, description, URL, location, freeform metadata, and user timestamp, JCS-canonicalized so the claims hash stays independently reproducible by the submitter.
Claims hash
The claims fingerprint, a SHA-256 hash, under the item-claims byte prefix 0x11, of the JCS-canonicalized claims a user submitted and nothing else; independently reproducible by anyone holding the claims, and one of the two inputs bound into the item's composite fingerprint.
Data integrity
The affirmative guarantee that the exact bytes submitted to Truestamp remain unchanged - any alteration changes the data's SHA-256 fingerprint and breaks the proof, so a verifier who re-hashes the data detects even a single changed byte; one of the three product pillars.
Domain separation
Truestamp's rule that every hash over its own evidence is SHA-256 computed over a reserved single-byte prefix plus the data (RFC 6962 style), so a hash made for one purpose (Merkle leaf, node, item claims, proof payload) can never collide with or be replayed as a hash for another purpose.
Item hash
The item's composite fingerprint, a SHA-256 hash (prefix 0x13) binding an item's ULID, claims hash, metadata hash, and signing-key ID into one value; it becomes the item's Merkle-tree leaf in a Truestamp block and is the value Truestamp signs, with authorship and ownership deliberately excluded.
JCS (JSON Canonicalization Scheme)
RFC 8785, the deterministic JSON serialization Truestamp applies to a JSON map (item claims and metadata, block metadata, entropy values, commitment data) before SHA-256 hashing, so the same logical data always yields the same bytes and the same hash regardless of key order.
Merkle leaf
The bottom-level entry of a Merkle tree, hashed as SHA-256(0x00 || hash) under the RFC 6962 leaf prefix so it can never be confused with an interior node (prefix 0x01); block-tree leaves are item and entropy observation hashes, epoch-tree leaves are block hashes.
Merkle root
The single hash at the top of a Merkle tree that commits to every leaf below it; a block's Merkle root (the mr field in a proof bundle) commits to that block's items and entropy observations, and an epoch's root is the value recorded on a public blockchain.
Merkle tree
A binary hash tree where each parent is the SHA-256 hash of its two children, reducing a whole set of leaves to one root; Truestamp builds RFC 6962 trees over item and entropy observation hashes per block and over block hashes per epoch.
Metadata hash
The timing fingerprint, a SHA-256 hash (prefix 0x12) over the small system-generated record capturing an item's moment of submission, the id and hash of the most recent block existing at submission, committing to the submitted-after edge of the submission window without touching user data.
Items
Submit an Item
How to timestamp data by submitting an item on the web form, JSON:API, GraphQL, console WebSocket, CLI, or an MCP agent, with every claims field (name, hash and hash type, description, URL, location, timestamp, metadata), hash mode versus plan-gated claims-only mode, and the limits that apply.
The Item's Composite Fingerprint
How an item's claims fingerprint and timing fingerprint are bound into the composite fingerprint (item_hash) so user data stays independently verifiable, the submission window is committed, and authorship is deliberately excluded from every hash.
Get Help
API Documentation
Comprehensive guides for the REST and GraphQL APIs, including interactive documentation and code examples.
View API DocsFAQ
Quick answers to the most commonly asked questions about timestamping and verification.
Browse FAQSecurity Issues
Report security vulnerabilities through our responsible disclosure program.
[email protected]