— · checking
trusted utc

Accurate time, made certain.

so everything your system produces is stamped with a verifiable timestamp.

so instead of stamping objects one at a time, the stamp is built into your system — and runs on its own.

$ trustedutc anchor --demo checking
01 accurate
clock —source=navigator · drift=unknown · trust=none
02 transform
POST /v1/anchordevice_pubkey —nonce —tas_signature waiting…
03 certain
anchorutc_ms — ±—tas_sig —verify —
— /v1/pubkey · /healthz

What it does § 01

The classical timestamping approach — TSA RFC 3161, OpenTimestamps — stamps one object at a time: send a document, receive a stamp, attach it. Works, but costs one explicit call per object.

Trusted UTC stamps the system. Once integrated, every object the system produces is born with a verifiable timestamp, no explicit call per object. 

   TSA / OpenTimestamps         Trusted UTC
   ────────────────────         ─────────────────────────────
   one timestamp per object     periodic TAS anchor
   N objects → N requests       N objects signed locally
   on-demand, documents         continuous, systems
Trusted UTC is not a qualified timestamping authority under eIDAS, and does not replace RFC 3161 TSAs in regulated contexts. It is a software-only cryptographic primitive for temporal attestation, built for developers who want verifiable time in their systems without the friction of enterprise timestamping.

How it works § 02

  TAS       issues Ed25519-signed anchors, rooted in NTP/NTS.
   │
   ├──▶ SDK       keeps a local monotonic clock anchored to the latest anchor.
   │     │
   │     ├──▶ Event     every event is signed locally with the device key.
   │     │
   ▼     ▼
  Verifier    offline verification against the TAS public key.

$ curl — request an anchor:

# POST /v1/anchor
curl -X POST https://api.trustedutc.com/v1/anchor \
  -H "X-API-Key: <your-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "device_label": "my-device",
    "device_pubkey": "<base64-ed25519-32B>",
    "nonce": "<base64-random-32B>",
    "data_hash": "<base64-sha256-32B>",
    "identity_attestation": null
  }'

— response:

{
  "anchor_id": "anc-1745396893412",
  "utc_ms": 1745396893412,              // UNIX ms at TAS signing time
  "uncertainty_ms": 2,                  // declared band (RTT/2 + margin)
  "valid_until_ms": 1745400493412,      // anchor validity window (1h)
  "identity_verified": false,
  "identity_attestation_hash": "AAAA…", // 32B zero (no attestation)
  "data_hash": "x4Fz9a…",             // echo of pre-committed hash
  "tas_signature": "VwgbD9B4…",        // Ed25519 over canonical payload
  "nonce": "IWnVwlb4…"               // echo for anti-replay
}

For whom § 03

  1. i
    Audit trails for critical operations. Financial transactions, cash handling, industrial events — each event carries a timestamp verifiable after the fact, without trusting the producing machine's clock.
  2. ii
    Provenance of generated content. Photos, documents, logs: when the file was produced, provable mathematically. The CBOR bundle travels with the object; verification is offline.
  3. iii
    Tracking systems. Position, presence, activity: where you were, and when, with temporal guarantees. Useful where the device clock is not trusted and a TSA call per ping is disproportionate.

Status § 04

api.trustedutc.com/healthz GET checking…
tas_version v0.2.0 current
tas_pubkey (Ed25519) U4RSC+/Qxl8w9JvUlbDdxDBQ/Syqrhn5eVZJnKUFYI0= checking…
fetch GET /v1/pubkey
latest anchor observed — —

Security & limits § 05

Trusted UTC uses Ed25519 signatures, SHA-256 hashing, CBOR canonical encoding, and monotonic clock anchoring. The TAS enforces rate limiting, API key authentication, and request size limits. SSH access to the production VPS is key-only.

Time is sourced from 3 independent NTP pools with median consensus. Each anchor is cryptographically bound to the data being signed (pre-commitment hash). Trust depends on the TAS for time source integrity. If the TAS is compromised or its NTP sources are poisoned, bundles signed in that window carry false time. Mitigation via NTS-KE and OpenTimestamps anchoring is on the roadmap.

The device_label field is self-declared and opaque: the TAS does not validate it. Applications must bind identity to device_pubkey, never to device_label.

A full security audit with severity ratings is published with every release.

Changelog § 06

Docs & code § 07