Transparency log trust

Log state

Checkpoints are signed only by Dekimu's operator key. This log has no independent witnesses yet, so a compromise of that key could present different histories to different viewers (a split view). Equivocation resistance is NOT yet established — trust here still rests on Dekimu.

Bitcoin anchoring (supplementary)

This checkpoint root was submitted to 2 OpenTimestamps calendars at 2026-07-01 12:20:55 UTC. Once the calendars batch it into a Bitcoin transaction and it confirms, the timestamp proves the root existed before that block. Bitcoin is a supplementary existence-and-time attestation — it is not the equivocation defense (the witnesses above are).

Awaiting Bitcoin confirmation — the hourly upgrade cron checks the calendars until the root lands in a block, then shows the height and time here.

Verify it yourself — pull the .ots proof and check it offline against Bitcoin with the ots client.

• https://alice.btc.calendar.opentimestamps.org
• https://btc.calendar.catallaxy.com

Verify this yourself

Pull the signed checkpoint, a consistency proof between any two tree sizes, the Bitcoin receipt, and the operator's public key — then check the signatures with your own tooling.

# 1. The latest signed C2SP checkpoint note (operator + witness lines)
curl -s https://verify.dekimu.com/log/checkpoint

# 2. Append-only proof: the log at size N extends the log at size M (M < N)
curl -s "https://verify.dekimu.com/log/consistency?from=1&to=52"

# 3. The Bitcoin (.ots) receipt for the current checkpoint root
curl -s "https://verify.dekimu.com/api/ots/checkpoint/9aeaf11359bb7396cb1dbb50fd61b38265cb0749393ac391d1905659c070fae2?format=ots" \
  > checkpoint.ots
# verify offline against Bitcoin:  ots verify checkpoint.ots

# 4. The operator's audit-root public keys (verify the checkpoint signature)
curl -s https://verify.dekimu.com/.well-known/dekimu-audit-root-keys.json