Glossary concepts | Truestamp

AI chat assistant The in-app slide-out AI chat sidebar that answers questions about Truestamp and, for signed-in users, their own items and teams through a read-only actor-scoped toolset, also available to anonymous guests with a smaller toolset and tighter limits when anonymous chat is enabled.

API key A long-lived opaque credential (prefix truestamp_) that authenticates programmatic requests as your whole account, sent as an Authorization Bearer header on JSON:API and GraphQL or as a connection parameter on the console WebSocket; the MCP surface never accepts one and requires OAuth 2.1.

Audit path The ordered list of sibling hashes in a Merkle inclusion proof; each entry is tagged left or right so a verifier can recompute the root from a leaf and match it against the published root.

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.

Beacon A public, verifiable snapshot of the Truestamp chain, the hash of a finalized or committed block published on the public /beacons page as verifiable randomness and a moment-in-time marker, with four fields (id, hash, timestamp, previous_hash) and a stable permalink per hash.

Billing owner The user who created a team, whose plan plus any administrator overrides sets the effective limits and entitlements for all work done in that team, whichever teammate does it - including the pooled monthly item allowance and member limits counted across every team that person created.

Bitcoin A public proof-of-work blockchain Truestamp uses two ways, capturing new Bitcoin block hashes as entropy observations and committing epoch roots into a transaction OP_RETURN output, which appears in a proof bundle as a commitments entry with chain bitcoin and a regtest, testnet, or mainnet network.

Block (Truestamp block) A minute-cadence unit of Truestamp's internal ledger: a Merkle tree over the item hashes and entropy observations collected in that window, hash-chained to the previous block and Ed25519-signed, created finalized and transitioning to committed once an epoch commitment covers it.

Block Commitment The second Truestamp commitment event: finalized block hashes are batched into an epoch whose single Merkle root is recorded on a public blockchain (Stellar MEMO_HASH, Bitcoin OP_RETURN), moving each covered block from finalized to committed and adding an external timing witness.

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, is batched into epochs, published as a beacon, and committed by each item as its block witness.

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.

CBOR Concise Binary Object Representation (RFC 8949), the compact binary encoding of a Truestamp proof bundle, interchangeable with the JSON form, wrapped in the self-describing tag 55799, carrying hash and key fields as raw byte strings instead of hex or base64 text.

Chronolocation The investigative practice of establishing when digital evidence such as a photo existed or was captured - Truestamp supports it by proving a submission window, giving evidence a verifiable existed-by guarantee while never claiming creation time.

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 fingerprints 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).

CLI (truestamp) The open-source truestamp command-line client, a single static binary for macOS, Linux, and Windows that submits items, downloads proof bundles, and verifies proofs fully offline without an account, signing in through the browser as a pre-registered OAuth 2.1 PKCE client.

Commitment Truestamp's term for recording a hash somewhere durable and checkable: Item Commitment places an item's hash in a finalized block's Merkle tree, Block Commitment records an epoch root of batched block hashes on a public blockchain, and a complete proof requires both events.

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).

Compact proof encoding The binary wire form of a Merkle inclusion proof used in a proof bundle's inclusion_proof and epoch_proof fields, packing a depth byte, a left/right direction bitfield, and raw 32-byte sibling hashes into unpadded base64url, mapping losslessly to and from the JSON direction:hash form.

Console (WebSocket) The authenticated multiplexed WebSocket surface at /console/websocket for real-time programmatic access, where clients subscribe to live streams, issue commands such as items.create and items.watch, and receive stream events under per-connection rate, stream, and payload limits.

Creation time The moment content was originally authored, which a Truestamp proof deliberately does not attest - a proof brackets when data was submitted, and data can exist long before it is submitted, so the guarantee is always a submission window, never a creation time.

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, 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.

Ed25519 signature The deterministic 64-byte elliptic-curve signature scheme Truestamp uses to sign the 32-byte domain-separated SHA-256 hashes of items, blocks, entropy observations, and proof bundle payloads, proving Truestamp's signing key endorsed exactly that object.

Entitlement A named Truestamp plan capability that cannot be reduced to a numeric limit, such as team-retained item ownership or the support level (community, email, priority); administrators can grant extra entitlements and limit overrides per account, and every check uses the effective values.

Entropy observation A captured record of unpredictable public entropy from the NIST Randomness Beacon, the Stellar ledger, or the Bitcoin blockchain, hashed, Ed25519-signed, folded directly as a Merkle leaf into a Truestamp block, and named as a witness by the items submitted after it.

Entropy source One of the three independent public systems Truestamp captures unpredictable randomness from, the NIST Randomness Beacon, the Stellar ledger, and the Bitcoin blockchain, each yielding entropy observations with its own proof bundle subject type (entropy_nist, entropy_stellar, entropy_bitcoin).

Epoch The batch Truestamp uses for Block Commitment: all block hashes finalized since the last commitment of a given kind form one Merkle tree whose single root is recorded on a public blockchain, with each chain (Stellar, Bitcoin) advancing its own independent series of epochs.

Epoch root The single Merkle root summarizing every block hash in an epoch, the exact value written on-chain as a Stellar transaction memo hash or a Bitcoin OP_RETURN payload, carried in a proof bundle as each commitment's epoch_merkle_root and the root its epoch_proof walks a block hash up to.

External Commitment Truestamp's permanent per-block, per-chain record that a block was committed to a public blockchain, carrying the Merkle proof from block_hash to the on-chain epoch root; appears in a proof bundle as an entry in the commitments array naming its chain, and every bundle carries at least one.

GraphQL Truestamp's authenticated GraphQL endpoint at /gql with an interactive playground at /gql/playground, accepting an API key or OAuth 2.1 bearer token, whose introspectable schema of queries and mutations is generated from the same resource domains as the JSON:API.

Inclusion proof A short list of ceil(log2(N)) sibling hashes, also called an audit proof, proving one Merkle leaf belongs to a tree with a given root without revealing other leaves; a Truestamp proof bundle uses one subject-into-block inclusion_proof and one block-into-epoch epoch_proof per 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.

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.

JSON:API Truestamp's authenticated REST surface at /api/json following the JSON:API specification, with API-key or OAuth 2.1 bearer authentication, an OpenAPI spec rendered by Swagger UI and ReDoc, and resource endpoints with standard filtering, sorting, and pagination.

Magic link A single-use, time-limited sign-in link Truestamp emails to your address as a passwordless alternative to password sign-in; if no account exists for that email one is created on the spot, and an enabled TOTP second factor still applies after the link signs you in.

MCP (Model Context Protocol) The Model Context Protocol, which connects an LLM agent (Claude Code, IDE agents, Claude Desktop) to a Truestamp account at /mcp, a three-tool code-mode surface authenticated exclusively by OAuth 2.1 with an mcp:read/mcp:write scope split and a preview-then-submit write flow.

Merkle leaf The bottom-level entry of a Merkle tree, hashed as SHA-256(0x00 || hash) under the reserved 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 merkle_root field of every block map 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 these 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 naming the witnesses an item was submitted after, committing to the submitted-after edge without touching user data; a bundle carries the record itself, so the hash is recomputed, never trusted.

NIST Randomness Beacon The US National Institute of Standards and Technology public randomness service publishing cryptographically signed random pulses about once a minute in a tamper-evident chain, one of Truestamp's three entropy sources, captured by HTTP polling and re-verifiable by chain and pulse index.

OAuth 2.1 Truestamp's built-in authorization server (authorize, token, register, revoke endpoints with RFC 8414/9728 discovery) issuing audience-bound access tokens and rotating refresh tokens via PKCE S256 consent, with per-surface mcp/api/console read and write scopes; the only credential MCP accepts.

Offline verification Checking a Truestamp proof bundle using only its own contents with no call to any Truestamp server, by recomputing domain-separated hashes, walking the Merkle inclusion and epoch proofs, and verifying the Ed25519 signature; on-chain confirmation is the only optional network step.

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.

Ownership model The per-team setting choosing who owns newly submitted items - creator retains (the default; the submitting user owns their items) or team retains (the team owns them; plan-gated, requires each invitee's acknowledgment of ownership terms, and blocks plan downgrades while in effect).

Passkey A phishing-resistant WebAuthn sign-in credential on a Truestamp account, approved with Touch ID, Face ID, Windows Hello, or a security key, completing sign-in in one usernameless step that skips the TOTP prompt; added, renamed, and removed from the profile page.

Plan The account-level tier (Free, Starter, Pro, Enterprise) setting numeric limits (items per month, teams owned, members per team, metadata size, claims-only budget, webhooks, retention, daily chat messages and knowledge-base searches) and named entitlements; the billing owner's plan governs the team.

Proof bundle The self-contained JSON or CBOR file downloaded for a committed subject, carrying the subject data and its metadata, Merkle proofs, an Ed25519 signature, the witness detail that opens the submitted-after edge, and at least one public-blockchain commitment, every hash recomputed from carried bytes.

Provenance The third pillar of Truestamp's product framing - the traceable origin and history of data as a signed, publicly verifiable chain of evidence from submission through block inclusion to public-blockchain commitment, deliberately bounded to make no claim about who authored the content.

Public randomness beacon A service that periodically publishes unpredictable, bias-resistant, publicly verifiable random values everyone can observe; Truestamp both consumes external beacons such as the NIST Randomness Beacon as entropy and acts as one itself through the public /beacons page.

Recovery code A single-use backup code issued in a batch when Truestamp two-factor authentication is enrolled, entered in place of a TOTP code at the second-factor step; each code works exactly once, only a hashed form is stored, and regenerating a batch invalidates the previous one.

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.

RFC 6962 The Certificate Transparency standard Truestamp takes its Merkle hash primitives from - SHA-256 with 0x00 leaf and 0x01 node domain-separation prefixes, and the empty-tree root - while shaping the tree above them by its own key-sort and power-of-two padding rules.

Signing-key ID (kid) The 4-byte identifier of an Ed25519 signing key, SHA-256 over the 0x51 byte prefix and the public key truncated to 4 bytes and written as 8 lowercase hex characters, recorded on items, blocks, entropy observations, commitments, and the signing_key_id field of a bundle's subject and block maps.

Stellar A public blockchain Truestamp uses two ways: Stellar ledger closes are captured as entropy observations, and epoch roots are committed as a transaction MEMO_HASH, appearing in a proof bundle as a commitments entry with chain stellar and a network of testnet or public.

Submission window Truestamp's honest time guarantee, the cryptographic proof that data was submitted after a set of public records the item's fingerprint commits to and before the finalized block that includes it, always phrased as submitted and submission window, never created or creation time.

t type code The frozen integer discriminator of a proof subject type, drawn from a registry namespaced by decade (10-19 block-like, 20-29 item, 30-39 entropy, 40-49 reserved for commitment chains); a bundle carries the matching registry name in its type key while the integer is what the signed payload binds.

Team The unit of tenancy in Truestamp - every item belongs to exactly one team, every signed-in request is evaluated against your identity plus one active team, and team membership is what grants any visibility into a team's items and members.

Team role The single role each Truestamp team membership carries, in a strict privilege hierarchy - team owner (full control), team admin (team settings plus member and viewer memberships), team member (submits and works with items), team viewer (read-only); roles govern actions, plans govern features.

Timestamp What a Truestamp timestamp is - a cryptographic submission window proving data was submitted after one block and before the finalized block that includes it, immutable and independently verifiable, never a creation-time claim; the first of the home page's three pillars.

TOTP Time-based One-Time Password, the optional authenticator-app second factor on a Truestamp account; after a password or magic-link sign-in you enter the app's rotating six-digit code, with code entry rate-limited to 3 attempts per 5-minute window against brute-force guessing.

ULID The 26-character Crockford Base32, timestamp-prefixed, lexicographically sortable 128-bit identifier used exclusively for Truestamp Item IDs; every other resource uses UUIDv7, and both are stored as raw 16-byte binary in Postgres uuid columns.

UUIDv7 The time-ordered UUID version (RFC 9562) used for every Truestamp identifier except Item IDs, covering blocks, teams, users, and entropy observations; its leading 48-bit millisecond timestamp makes values lexicographically sortable by generation time.

Verification level One of the two independent checks on an entropy observation - internal verification recomputes the stored hash and Ed25519 signature offline, external verification re-fetches the value from the original public source, and the merged summary adds the Merkle inclusion check.

Verification summary The combined pass/fail report over every verification layer of an entropy observation (data hash, Ed25519 signature, Merkle inclusion, external source); it passes only when no individual check fails and marks the Merkle step skipped, not failed, until the observation is committed.

Webhook (outgoing) An HTTPS endpoint registered with Truestamp to receive outgoing item event callbacks, managed over the JSON:API and GraphQL surfaces, with optional bearer-token authentication, delivery tracking, private-IP SSRF safeguards, no HMAC payload signing, and a per-plan endpoint limit.

Witness A public record that already existed when a subject was submitted and that the subject's composite fingerprint commits to, opening the submitted-after edge of the submission window; the registry is the head block plus one entry per captured entropy source, plus the signing-key event.

Knowledge Base

Glossary