Support

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 RFC 6962 name for the ordered list of sibling hashes in a Merkle inclusion proof, each tagged with a left or right direction, that recomputes the root from a leaf; if the recomputed root matches the published root, the leaf is proven to belong to the tree.

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: new Bitcoin block hashes are captured as entropy observations, and epoch roots are committed into a transaction OP_RETURN output, appearing in proof bundles as cx entries with type code 41 and net regtest, testnet, or mainnet.

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

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

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 proof bundle ip and ep 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 (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.

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, and folded directly as a Merkle leaf into a Truestamp block, proving the block could not have been precomputed before the entropy existed.

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 type code (30 NIST, 31 Stellar, 32 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; it is the exact value written on-chain (the Stellar transaction memo hash or the Bitcoin OP_RETURN payload) and the root each proof bundle commitment's epoch proof (ep) 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 a cx entry (type 40 Stellar, 41 Bitcoin), 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 about 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 (ip) and one block-into-epoch (ep) 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 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.

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, chat messages) and named entitlements; the team billing owner's plan governs all work in that team.

Proof bundle The single self-contained JSON or CBOR file downloaded for a committed subject, carrying subject data, hashes, Merkle proofs, an Ed25519 signature, and at least one public-blockchain commitment so anyone can verify it offline, discriminated by an integer top-level t type code.

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 whose Merkle tree construction Truestamp implements, using SHA-256 with 0x00 leaf and 0x01 node domain-separation prefixes and defining how leaves, nodes, roots, and audit paths are computed so independent verifiers can check proofs.

Signing-key ID (kid) The 4-byte identifier of an Ed25519 signing key, SHA-256 of the 0x51 byte prefix plus the public key truncated to 4 bytes and written as 8 hex characters; recorded on items, blocks, entropy observations, and proof bundles so a verifier knows which key signed what.

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 proof bundles as cx entries with type code 40 and net testnet or public.

Submission window Truestamp's honest time guarantee - the cryptographic proof that data was submitted after the most recent internal block at submission and before the finalized block that includes it, always phrased as submitted and submission window, never created or creation time.

t type code The integer discriminator at the top of every proof bundle and inside each cx entry, drawn from a frozen registry namespaced by decade (10-19 block-like, 20-29 item, 30-39 entropy, 40-49 commitment chains); never renumbered or reused, and bound into the signed payload.

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.

Community & Updates

Feedback

Roadmap

Changelog

Knowledge Base

Glossary

Get Help

API Documentation

FAQ

Email Support

Security Issues

Truestamp AI