Atlas Timestamping

Timestamping provides cryptographic proof of when envelopes existed. Atlas supports two complementary mechanisms: peer witnessing within the network, and blockchain anchoring via the Bitcoin blockchain for externally verifiable, immutable timestamps.

Writing "I trust Alice" isn't enough. For a trust allocation to become recognized by the network, it must be witnessed — observed and timestamped by peers with the authority to do so. For critical envelopes, Bitcoin anchoring provides an additional trust-minimized guarantee.

Peer Witnessing

The witnessing process has three stages:

1. Publish — A verified human publishes a trust allocation envelope to a registry.
2. Observe — Peers with witnessing competence observe the envelope and publish an Observation envelope referencing the original hash and recording the observation date.
3. Threshold — Once enough cumulative witness power has observed the envelope, the allocation becomes valid and independently verifiable by anyone on the network.

{
  "@context": "https://schema.org",
  "@type": "Observation",
  "additionalType": "atlas:witness",
  "about": {
    "@type": "PropertyValue",
    "propertyID": "atlas:envelopeHash",
    "value": "<hash-of-trust-allocation-envelope>"
  },
  "observationDate": "2026-04-03T12:00:30.000Z"
}

Witnessing Competence

Not everyone can witness. The authority to observe and timestamp envelopes is earned through trust allocations on the "witnessing" topic that are currently recognized (matured and not superseded). This creates a self-governing loop: the community decides who can verify trust, and that decision is itself subject to trust and rolling recognition.

Bitcoin Blockchain Anchoring

For envelopes that require externally verifiable, trust-minimized timestamps, Atlas supports anchoring to the Bitcoin blockchain via OpenTimestamps. A Bitcoin anchor provides proof that an envelope existed at or before a specific block — independently verifiable by anyone with access to the Bitcoin blockchain, without trusting any Atlas node.

{
  "@context": "https://schema.org",
  "@type": "Observation",
  "additionalType": "atlas:btcTimestamp",
  "about": {
    "@type": "PropertyValue",
    "propertyID": "atlas:envelopeHash",
    "value": "<hash-of-envelope>"
  },
  "observationDate": "2026-04-03T12:00:30.000Z",
  "instrument": {
    "@type": "SoftwareApplication",
    "name": "OpenTimestamps",
    "url": "https://opentimestamps.org"
  },
  "result": {
    "@type": "PropertyValue",
    "propertyID": "ots:proof",
    "value": "<base64-encoded-ots-proof>"
  }
}

The two mechanisms are complementary. Peer witnessing provides fast, in-network timestamps for everyday operations. Bitcoin anchoring provides an immutable external anchor for envelopes where the stakes justify the latency — governance documents, snapshot anchor points, and any envelope where future disputes may require proof that no Atlas participant can revoke.

Liveness Challenges

Timestamping also underpins registry liveness verification. Registries periodically send random challenge strings to peers and verify the signatures, confirming the peer is live and owns its claimed identity. The lastSeenAt field records the last successful challenge — registries with stale timestamps are considered offline.

POST /identity/challenge HTTP/2.0
Content-Type: application/json
atlas-identity:  <requester-public-key>
atlas-signature: t=1712150400; s=<falcon-signature>
atlas-proofs:    [...]

{ "challenge": "<random-string>" }

// Response — registry signs the challenge with its own key
{
  "publicKey": "<registry-public-key>",
  "signature": "<falcon-signature-over-challenge>"
}

Why It Matters