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: item

23
Glossary
Authorship The immutable audit-trail record of who submitted an item (its creator), set once at submission, never consulted for rights decisions, and deliberately excluded from every cryptographic hash, so a Truestamp proof makes no claim about who authored the underlying data. 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. Claims-only submission Submitting an item without an external hash so the claims themselves are the timestamped content of record; requires a description of at least 32 characters or non-empty metadata, and the JCS-encoded claims must fit the team billing owner's per-plan byte budget (256 B Free up to 16 KB Enterprise). Committed The normal resting state on both Truestamp ledgers - an item is committed once its item hash is a leaf in a finalized block (Item Commitment), and a block is committed once its block hash is covered by an epoch recorded on a public blockchain (Block Commitment). Item A single unit of data submitted to Truestamp for timestamping - identified by its composite fingerprint, belonging to exactly one team, with a transferable owner and an immutable creator, advancing through the created, processing, and committed states. Item Commitment The first Truestamp commitment event: an item's item_hash becomes a Merkle-tree leaf in a finalized block, recorded with a compact inclusion proof, moving the item to the committed state and proving it was submitted within that block's submission window. 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. Item retention The per-plan window a Truestamp item is kept - 90 days on the Free tier (expired items enter the deleted_expired state with an email warning and a 7-day cancellable grace period), unlimited on paid tiers; team-owned items follow the team billing owner's plan. Item states The lifecycle states of a Truestamp item - created (waiting), processing (assigned to a block being built), committed (a leaf in a finalized block), redacted, plus the deletion states deleted_user and deleted_expired (7-day cancellable grace). Item visibility The per-item read scope - private (default; only the item's user-owner plus the owning team's admins and owners), team (any member of the owning team), or public (readable by anyone, including anonymous visitors); visibility controls who can read an item, ownership controls who can change it. 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. Ownership The transferable rights holder of a Truestamp item, either a single user or a team, that every rights decision (read, update, redact, restore, delete, reassign) is authorized against; ownership can change hands without altering any hash, so an existing proof stays valid across transfers. Redaction Removing a committed item's claims content while preserving every hash (claims, metadata, item) so the inclusion proof stays valid - restoring requires claims that canonicalize and hash to the preserved claims hash, making unredaction verifiable rather than a blind overwrite.

Get Help

API Documentation

Comprehensive guides for the REST and GraphQL APIs, including interactive documentation and code examples.

View API Docs

FAQ

Quick answers to the most commonly asked questions about timestamping and verification.

Browse FAQ

Email Support

Send us a message and our team will respond within 24 hours.

[email protected]

Security Issues

Report security vulnerabilities through our responsible disclosure program.

[email protected]