Agent Action Capsule · explain
06 / 11

Checkpointed local log and MMR

Each node keeps its own append-only Merkle Mountain Range, signs small checkpoints over it, and registers those checkpoints with a transparency service, while the entries never leave the node.

An MMR grows to seven entries, is committed in a signed checkpoint, and the checkpoint is registered Left: a Merkle Mountain Range drawn with MMR positions in each node. Step 1: entries 0 and 1 become leaves at positions 0 and 1 and merge into node 2 of height 1, which is a peak; log size 3. Step 2: entry 2 becomes leaf 3, a second peak of height 0; log size 4 with three entries, the state an earlier checkpoint committed to. Step 3: entry 3 becomes leaf 4, merging with leaf 3 into node 5, which merges with node 2 into node 6 of height 2; one peak; log size 7. Step 4: entries 4 and 5 become leaves 7 and 8, merging into node 9 of height 1; peaks are now nodes 6 and 9; log size 10. Step 5: entry 6 becomes leaf 10; seven entries, log size 11, peaks are nodes 6, 9 and 10 with heights 2, 1 and 0. Step 6: dashed lines carry the three peaks into a signed checkpoint card on the right whose commitment is the three peak values concatenated tallest first, not a bagged root; the card also shows kind cll-checkpoint, log_size 11, leaf_count 7, prev_size 4, prev_commitment, a consistency proof from 4 to 11, issued_at, and the iss and sub of the log identity. Step 7: an arrow carries the checkpoint to a transparency service box, which compares prev_size 4 and prev_commitment with the state it holds for that log identity, registers the checkpoint, and returns a receipt; the service never receives the entries. Producer's local log (MMR_SHA256) h2 h1 h0 0 1 2 e0e1 log_size 3 · 2 entries · peaks [2] 3 e2 earlier checkpoint: log_size 4, 3 entries, peaks [2, 3] log_size 4 · 3 entries · peaks [2, 3] 4 5 6 e3 log_size 7 · 4 entries · peaks [6] 7 8 9 e4e5 log_size 10 · 6 entries · peaks [6, 9] 10 e6 log_size 11 · 7 entries · peaks [6, 9, 10] peak heights 2, 1, 0 (7 = 4 + 2 + 1) Checkpoint · COSE_Sign1 (alg -19) iss https://producer.example sub https://producer.example/logs/1 kind cll-checkpoint log_size 11 leaf_count 7 commitment 046b6c15…a0b64392…bd0ce39b… prev_size 4 prev_commitment 643e9cb5… consistency_proof [4, 11, …] issued_at 2026-10-13T01:00:00Z peaks concatenated tallest first; no bagged root Transparency Service holds for (iss, sub): size 4, 643e9cb5… ✓ prev_size and prev_commitment match ✓ registered; receipt: checkpoint included receives the checkpoint, never the entries

1What it is

A checkpointed local log is an append-only log that a producer keeps for itself, structured as a Merkle Mountain Range exactly as the MMR receipt profile defines it.

From time to time the producer signs a checkpoint, a SCITT Signed Statement that commits to the whole log at one size and links to the previous checkpoint with a consistency proof.

Only the checkpoint leaves the producer, and registering it with transparency services that check it against the previous one is what turns "trust the producer" into something others can check.

2Design choices

Chosen: the log is the MMR profile's MMR_SHA256 structure, unchanged; this draft fixes only the leaf, SHA-256(0x00 || entry) over a 32-byte entry.
Rejected: a new tree or proof format; the 0x00 prefix already keeps leaves distinct from interior nodes, and the profile's inclusion and consistency proofs apply as-is. (CLL §3, §5.1)
Chosen: commitment is the peaks' node values concatenated tallest first, the same bytes as a Receipt of consistency payload.
Rejected: a single bagged root on the wire; an implementation may fold peaks for its own comparisons, but it MUST NOT be carried in the checkpoint. (CLL §4.1)
Chosen: log_size is the MMR tree size, a node count (7 entries → 11); the entry count goes in the optional leaf_count.
Rejected: log_size as the number of entries, as an earlier revision described it; the commitment length check then fails. (CLL §4, §4.3)
Chosen: the checkpoint names its predecessor (prev_size, prev_commitment) and carries the consistency proof inside the signed payload.
Rejected: the Receipt of consistency layout, which leaves the trusted earlier state to the verifier and puts the proof in an unsigned header. (CLL §4.2, §5.2)
Chosen: one fixed sub per log; the pair (iss, sub) is the log identity every continuity check keys on.
Rejected: a sub that changes per checkpoint; each one then looks first-seen and continuity is silently never enforced. (CLL §4.5)
Chosen: register checkpoints, keep entries local and private; register a single record later only if it needs its own receipt.
Rejected: registering every entry with a central log as it is produced; too costly for high-volume producers, and it publishes private content. (CLL §1, §5.5)

The CLL draft cites draft-bryce-cose-receipts-mmr-profile-03 and states that, where the profile's editors' copy differs from -03 (the commitment encoding, a protected tree-size header on the Receipt of consistency, and the exact shape of consistent_roots), it follows the editors' copy (CLL §5.6).

3What it shows / what it does not

Shows

  • To the extent the verifier trusts the producer, who signed every checkpoint and chose what to present (CLL §5.3), the next four points hold:
  • The producer's key committed to this exact sequence at log_size N (signature over the commitment).
  • An entry is in the log at a position: an MMR inclusion proof reaches one of the committed peaks.
  • A later checkpoint extends an earlier one without modification: the consistency proof from prev_size rebuilds commitment.
  • A presented range of entries is complete within the committed history.
  • Once registered under a Consistency Registration Policy at a service independent of the producer: each entry existed no later than the first registered checkpoint covering it, and the registered history was not rewritten.

Does not show

  • That any entry's content is true.
  • That the producer appended everything it did, or that this is its only log.
  • Wall-clock time: issued_at is the producer's own claim; the upper bound comes from registration, so the backdating window is the cadence plus registration latency.
  • That the producer did not show a different fork to someone else; two checkpoints only check each other, and forks are caught by comparing or registering checkpoints with services that hold state.
  • Anything about entries appended after the last registered checkpoint, and no per-record lookup: the service never holds the entries.

4Example

The second checkpoint of the published test log: seven entries, log size 11, continuing from an earlier checkpoint at size 4. Its commitment is three 32-byte peaks.

    {
      "id": "cp2",
      "leaves": 7,
      "claims": {
        "kind": "cll-checkpoint",
        "log_size": 11,
        "commitment": "046b6c15dfa5998f23e49ba135f22ba0fe3ebc25078f5d087b78ed18106ba1bda0b64392f61d15267e0355dcc1907d30d55ebb895c425d944e9a0ae26170aea3bd0ce39b0f88ee1ff3b35c8ecf7a7eaf6041459d49c22b459c5a69d6d2ca6c61",
        "prev_size": 4,
        "prev_commitment": "643e9cb5b896b008a16c1333fecce044e510a94de8124c3798d3488277263324857277deb54352114b86f34f5ede1c50a8ab7de359acc5e362efc3c0a46ded4b",
        "issued_at": "2026-10-13T01:00:00Z",
        "cadence": 3600,
        "leaf_count": 7,
        "consistency_proof": "84040b82815820fa93abf7e2abc3635a3420f20d11a2de3e3842131027381ca5caa3af2afea186…"
      },
      …
      "consistency_proof": {
        "tree_size_1": 4,
        "tree_size_2": 11,
        …
        "right_peaks": [
          "a0b64392f61d15267e0355dcc1907d30d55ebb895c425d944e9a0ae26170aea3",
          "bd0ce39b0f88ee1ff3b35c8ecf7a7eaf6041459d49c22b459c5a69d6d2ca6c61"
        ]
      },
      …
      "continuity": "continuous"
    }
FieldTypeMeaning
kindtstrAlways cll-checkpoint.
log_sizeuintMMR tree size (node count) committed to: 11.
commitmentbstrPeaks at size 11 (heights 2, 1, 0), concatenated tallest first: 96 bytes.
prev_sizeuintThe previous checkpoint's log_size: 4 (three entries).
prev_commitmentbstrThe previous checkpoint's commitment: two peaks, 64 bytes.
issued_attstrIssuance time as a date-time string, as the producer states it.
cadenceuintDeclared maximum seconds between checkpoints.
leaf_countuintEntry count; must equal leaf_count(log_size - 1).
consistency_proofbstrCBOR [4, 11, consistency-paths, right-peaks] per the MMR profile.
right_peakshash[]New peaks no path reaches: nodes 9 and 10, the last two peaks of the commitment.
continuitytstrWhat a Consistency Registration Policy concludes for this checkpoint.

In the same file the checkpoint's protected header carries alg -19 (Ed25519), a kid, and CWT claims iss https://producer.example and sub https://producer.example/logs/1, identical for every checkpoint of the log.

Source: action-state-group/checkpointed-local-log:cll-02-vectors/vectors.json @ 40dabd74508d0f8649c8754873e316badef1057d

5Specs