TILLNOTARY · CHANGELOG

TillNotary, in order.

What we shipped in the transparency log. Newest first. Material breaking changes are flagged in bold.

v1.0 — September 2026 · Launch

TillNotary is a tamper-evident transparency log. Submit a hash and get back a signed inclusion proof and a witness-cosigned timestamp that you verify yourself, against keys you pinned, online or with no network at all. Nothing is tamper-proof: a rewrite cannot be prevented, but it is detectable by anyone holding an earlier proof. Start with the quickstart.

Logs and entries

  • Create a log in the dashboard or with tilldev notary logs create. Pick the standard suite (SHA-256) or the government suite (SHA-384 + ML-DSA-87, CNSA 2.0 algorithm levels); a log’s suite is fixed for its lifetime. Reads can be public or token-only.
  • Submit a hash, or, as an explicit opt-in, publish up to 4 KB of bytes as a public attestation. tilldev notary submit --file hashes the file locally and sends only the digest.
  • Each value appears at most once per log. Submitting it again returns the original receipt (200, "duplicate": true), so a retried submit never logs twice.
  • Find an entry by its value: GET /v1/logs/{slug}/leaves/by-value/{value}, tilldev notary lookup or findLeaf in the SDK. An absent value answers 404 ENTRY_NOT_FOUND.
  • Page through entries with ?limit and ?before, or listLeaves in the SDK. The dashboard lists a log’s entries, pages back through them and finds one by value.
  • Each log has a daily cap on new entries, 1 to 50,000 per rolling 24 hours (--daily-cap). Freeze a log to seal it for good: its proofs keep working and new entries are refused.

Verification

  • Checkpoints carry hybrid Ed25519 + ML-DSA (FIPS 204) signatures, and both must verify.
  • tilldev notary trust-init pins a log’s key and its witnesses’ keys and prints their fingerprints to check out of band. Running it again only adds witnesses and raises the threshold; --prune accepts a removal or a lower threshold.
  • The CLI and @tillstack/sdk-notary-node verify every answer against the pinned keys before returning it. A server that lies produces an error, never data. The SDK loads the same trust file with parseTrustFile and trustFromFile.
  • Evidence bundles verify with no network: tilldev notary verify bundle.json or verifyEvidence.
  • An entry verifies once witnesses have cosigned a head that includes it. Until then verify says so, and --latest accepts the newest signed head. In the SDK this is NotaryIncompleteError, a subclass of NotaryVerificationError.
  • consistency proves the log still extends a checkpoint you kept, and note prints a checkpoint as signed note text to compare with others.

Witnesses

  • TillDev runs a platform witness with its own key. Run your own with tilldev notary witness-node, register it, attach it to a log and require its cosignature, so no checkpoint completes without you. A log can require up to 16.
  • A witness cosigns only after checking that the new head extends the last one it cosigned. It refuses a head that does not, or one timestamped in the future or earlier than the last, and publishes a signed refusal. Refusals are listed by tilldev notary refusals and emailed to the org’s owners and admins.
  • Retired witness keys still verify the cosignatures they made. Detaching a witness is refused while it would leave fewer witnesses than the threshold.

Mirrors

  • tilldev notary mirror keeps a full copy of a log on your machine. Every entry it fetches must rebuild the signed root, and it resumes where it stopped. If the log shrinks, forks, rewrites history or serves entries that do not match, it saves both signed heads as evidence and exits 3. --offline re-checks a mirror with no network.
  • The same from Node, in the @tillstack/sdk-notary-node/mirror subpath: mirrorPass and verifyMirror.

Tokens and the API

  • Service tokens (tnot_…) with read, submit or admin scope, optionally pinned to one log and set to expire. Mint and revoke them in the dashboard or with tilldev notary tokens. Revoking is immediate; entries a token already submitted stay in the log.
  • An invalid or revoked token is refused with 401, even on a public log, rather than being read as anonymous. TillDev API keys reach the dashboard API with the notary.logs.read, notary.logs.write and notary.tokens.write scopes.
  • Every error has one shape, {error, code, request_id}, and every response an x-request-id header; the CLI prints the request id with an error. Rate-limited requests answer 429 with Retry-After, and the SDK and CLI wait and retry.
  • The REST API is described at /v1/openapi.json. See the CLI and SDK references.