Skip to main content

checkpointed-local-log

The Checkpointed Local Log (CLL) — an IETF Internet-Draft specifying a producer-operated, append-only local log with periodic signed checkpoints. Entries are appended locally and never published; only a small checkpoint — a signed commitment to the log's entire history — ever leaves the producer. Checkpoints may be registered with one or more independent SCITT Transparency Services or witnesses, turning a set of individually signed records into a stream with provable order, contemporaneity, and completeness.

The log itself is a Merkle Mountain Range (MMR), whose COSE proof formats are specified in I-D.bryce-cose-receipts-mmr-profile. This document specifies the log discipline and the checkpoint structure on top of that MMR — it defines no new proof formats, no transparency service behavior, and no payload semantics. The append-only MMR log is implemented in this repo's cll Python package (below); capsule-emit and capsule-ledger consume it rather than each forking their own copy.

Status. This is an individual IETF Internet-Draft, not a Working Group document, and not an RFC.

The cll package

cll is the reference implementation of this spec: a Python package shipping the pieces a CLL producer or verifier needs.

pip install checkpointed-local-log

What it ships:

  • Append-only log store (cll.ledger) — JSONL segments plus a derived SQLite index, the three-state admission contract, and hash-chain / chain-gap detection.
  • Merkle Mountain Range (MMR) (cll.checkpoint.core/.index/.store) — the pure position math, domain-separated hashing, and inclusion/consistency proofs this spec's checkpoints commit to.
  • Signed COSE checkpoints (cll.checkpoint.emit/.cose_wire) — building, signing, and registering checkpoints with a Transparency Service over the COSE_Sign1 wire form this spec defines.
  • Disclosure bundles (cll.checkpoint.bundle) — the record/range-level, offline-verifiable evidence package (inclusion proof + covering checkpoint
    • witness stamp + consistency proof) for handing one log record to a stranger.

See docs/module-map.md for the section-by-section map from this spec to the package's modules.

Cross-language scope: the ledger layer is Python-only, by decision

The Go (cll-go) and TypeScript (@action-state-group/cll) implementations are the checkpoint + MMR + storage substrate only: the append-only log, the Merkle Mountain Range with inclusion/consistency proofs, signed COSE checkpoints, witness delivery, and the storage backends. They are deliberately application-neutral and do not interpret record bodies.

The ledger layer — cll.ledger (three-state admission control, segment closing and manifests, the rebuildable lookup index, the append-only capsule store) and cll.revocation (the key-validity timeline) — is not ported to Go or TypeScript, and this is a decision rather than a gap. That layer is the business logic of who may write and how records are admitted, archived, queried, and key-checked; it was folded into this Python package by the W3 "one neutral library per spec" extraction of capsule-ledger (2026-09-01), and nothing downstream in the AAC ecosystem requires it in Go or TypeScript. Cross-language byte-parity is therefore required for the substrate (MMR proofs, checkpoints) and is explicitly not claimed for the ledger layer. Should a Go or TS consumer ever need admission or revocation semantics, adding them is a new, separately-scoped decision, not a matter of "catching up" to the reference.

Building the draft

The build toolchain is kramdown-rfc (Markdown → RFCXML v2) and xml2rfc (v2 → v3 → text):

cd spec
make DRAFT=draft-mih-scitt-checkpointed-local-log-00 \
     KDRFC=kramdown-rfc2629 \
     XML2RFC=xml2rfc \
     draft-mih-scitt-checkpointed-local-log-00.xml \
     draft-mih-scitt-checkpointed-local-log-00.txt

spec/.refcache/ is committed so the build never depends on bib.ietf.org being reachable. See comments in spec/Makefile for rebuild and refresh-refs targets.

License

See LICENSE: the specification text is governed by BCP 78 and the IETF Trust's Legal Provisions; code and reference material are under the Revised BSD License.

Metadata

Release files for checkpointed-local-log 0.4.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for checkpointed-local-log 0.4.0
File Size Uploaded
checkpointed_local_log-0.4.0.tar.gz 82.3 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for checkpointed-local-log 0.4.0
File Interpreter ABI Platform
checkpointed_local_log-0.4.0-py3-none-any.whl Python 3 none any Details

Total release size: 175.0 kB

Release files / checkpointed_local_log-0.4.0.tar.gz

Download URL checkpointed_local_log-0.4.0.tar.gz
Size 82.3 kB
Tags Source
SHA-256 checksum
How to use checksums
d173b8e4886cf2fd2da725cd80bbe0786c7920d0f3016549350d1a49625158f1
BLAKE2b-256 checksum
How to use checksums
95edb71ce124d2c774cb104435d20a1aae3a69832623f3aceeb26486bbd87d00
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 19, 2026.

Transparency log

Release files / checkpointed_local_log-0.4.0-py3-none-any.whl

Download URL checkpointed_local_log-0.4.0-py3-none-any.whl
Size 92.7 kB
Tags Python 3
SHA-256 checksum
How to use checksums
e5b6a9767acad22166c5c07a4fba536ed5bf0dfc9bdf8f8af40ddda0eaae714b
BLAKE2b-256 checksum
How to use checksums
293fa7177d3f950098d81f090523c22f5a330d5af156c3d3d99f6039f964a566
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 19, 2026.

Transparency log

Release history Release notifications | RSS feed

0.6.0

2 release files

0.5.1

2 release files

0.5.0

2 release files

0.4.1

2 release files

This release

0.4.0 This release

2 release files

0.3.0

2 release files

0.2.0

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page