Registry / Anchor
EC-M-1.1 · ledger integrity

How a record stays a record.

The registry is append-only. To make that property independently verifiable — not "trust the registry operator" — every batch commits to a fixed schema, and at the close of each vintage the entire ledger is summarised into a single ledger fingerprint that is published on durable public infrastructure. Anyone can re-derive that fingerprint from the public dataset and confirm the registry hasn't been altered.

Who can read, who can write

The registry follows the standard credit-registry model: read access is open; issuance is operated by a single accountable party. This is how Verra, Gold Standard, and other established registries work, and it is what credits need to have legal and regulatory standing.

ActionWho can do itNotes
Read any record Anyone Every batch detail page is public, indexable, and free of permission walls. The full dataset is downloadable as JSON.
Verify any record's integrity Anyone Three commands against the public dataset. No Landseed permission, no account, no tokens.
Issue new credit batches Landseed PBC Sole issuer. Each batch is produced by running the EC-M-1.1 methodology against a property at a specific vintage. The Calculator's output and the dimension-by-dimension scoring trail are published with the batch.
Modify an existing record No one Records are append-only by both convention and construction. Methodology revisions produce a new vintage; the original record is never edited.
Retire credits from circulation Landseed PBC When operating retirement is added to the registry, the retirement event will be recorded as a separate append-only entry referencing the original batch — leaving the original record intact.

The flow at a glance

Each batch becomes a single hash. All batch hashes combine, two at a time, into a single value at the top — the ledger root. The root gets published externally so it cannot be silently changed later.

LEVEL 1 · BATCHES Each batch is one record: a property at a vintage. P01-2026 Flint Hills P02-2026 Hoh Rainforest P03-2026 ACE Basin P04-2026 Organ Pipe … SHA-256 the commitment LEVEL 2 · LEAF HASHES One hash per batch. Same input → same hash, always. ee02300e… b7c1f5a3… 0c23bbf6… a98144d2… Pair adjacent hashes, hash again LEVEL 3 · PAIR HASHES Each pair becomes one new hash, halving the count. 5fd2c6b1… e89014af… …repeat until one value remains LEVEL 4 · LEDGER ROOT A single value that summarises every batch. LEDGER ROOT 949f25ec…8a56c4a8 publish externally LEVEL 5 · EXTERNAL ANCHOR Published on durable public infrastructure
BATCHES → LEAF HASHES → PAIR HASHES → LEDGER ROOT → EXTERNAL ANCHOR

Aqua boxes are batches and their leaf hashes (one per batch). Yellow boxes are intermediate values that combine pairs of hashes — they exist only to climb from the leaves up to the root. Green is the single ledger root that summarises the entire registry. The dashed amber box at the bottom is the external anchor — the root, copied to public infrastructure that Landseed does not control.

How vintages and the tree fit together

The most common misreading of this scheme: "is there a separate tree per project?" or "is there a separate tree per vintage?" Neither. Both questions resolve the same way:

So the answer to "are vintages organised by project?" is: at the level of the URL, yes — P01-2026 and P01-2027 are both reachable at /a/P01-… as separate, immutable records, each with its own commitment. At the level of the tree, all records sit in a single sorted ledger, regardless of which property or which year they came from. That single tree is what the external anchor commits to.

For someone unfamiliar with this

Think of the registry like a public record book. Every credit batch is one signed entry. Once the book is closed for the year, we publish a short fingerprint that summarises every entry in the book. The fingerprint is recorded somewhere durable that we don't control — so neither we, nor anyone else, can later go back and quietly change an entry without the fingerprint no longer matching.

If you ever want to confirm that a specific entry is what we say it is, you re-derive its fingerprint from the public dataset and compare. If anything in that entry had changed, the fingerprint wouldn't match. No special access needed. No accounts. No tokens.

For someone familiar

Each record is reduced to a deterministic commitment — a fixed-schema subset of fields covering only the credit-producing inputs. The commitment is canonicalised (recursive sorted-keys JSON, raw UTF-8, no whitespace) and SHA-256 hashed with a label to produce a leaf. Leaves form a tree of cumulative hashes; the single value at the top — the ledger root — is what gets anchored externally. Per-record inclusion proofs (O(log n) sibling hashes) let any party verify a single record against the published root without reproducing the whole tree.

The tree is a Merkle tree — the same primitive used by Certificate Transparency, Sigstore, ZFS, and most modern audit trails. The architecture predates and is independent of any specific public chain.

What we hash

Not the URL. Not the rendered page. Not the prose. Only the fields that determine the credit count under the methodology:

Anything outside this list — vegetation profile prose, hardware spec details, photo paths — can update without invalidating the credit commitment. Conversely, if any committed input changes, the leaf changes and the next vintage's root binds to the new state. The narrow surface is intentional: it keeps the commitment stable across cosmetic edits and pinned to the credit math itself.

Two anchor roles

The published root is anchored externally in two roles. We have not committed to specific public infrastructure for either role. The architecture works with any combination, the registry does not depend on a particular network, and the choice is being made carefully — including consultation with traditional registry partners who do not need any of this to use the system.

Permanence anchor
Cryptographic timestamp

Establishes that a given record existed by a given moment. Optimised for durability over decades, with the lowest possible operational dependency. A consumer only needs to verify a hash matches; no special software required after the fact.

Programmable anchor
Machine-readable reference

Establishes that downstream systems and ledgers can cite a specific batch by its canonical commitment without re-publishing the underlying data. Optimised for fast lookup and integration with future credit-market or governance surfaces.

Both anchors point to the same ledger root. Anchoring under multiple roles is by design — if any single network became unavailable, the other carries the proof. If neither were available to a verifier, the in-repository commitments and proofs are still independently checkable, and any future anchor can attest to the same root.

What this is not

How to verify a record

Three commands. No Landseed permission required.

# 1. Download the public dataset and the anchor file
curl -sS https://landseed-registry.pages.dev/data/portfolio.json > portfolio.json
curl -sS https://landseed-registry.pages.dev/data/anchor.json    > anchor.json

# 2. Rebuild the commitment for a record, hash it, compare to its published leaf
#    Canonical form: recursive sorted-keys JSON, raw UTF-8, no whitespace.
python3 - <<'PY'
import hashlib, json
COMMIT_VERSION = "ec-m-1.1.commitment.v1"
def canonical(v):
    if isinstance(v, dict):
        return "{" + ",".join(json.dumps(k, ensure_ascii=False) + ":" + canonical(v[k]) for k in sorted(v)) + "}"
    if isinstance(v, list):
        return "[" + ",".join(canonical(x) for x in v) + "]"
    return json.dumps(v, separators=(",",":"), ensure_ascii=False)

a = json.load(open("anchor.json"))
commitment = a["records"]["P03-2026"]["commitment"]
leaf = hashlib.sha256(("leaf:" + COMMIT_VERSION + ":" + canonical(commitment)).encode("utf-8")).hexdigest()
print("computed leaf:", leaf)
print("anchor leaf:  ", a["records"]["P03-2026"]["leaf"])
print("match:        ", leaf == a["records"]["P03-2026"]["leaf"])
PY

# 3. Walk the inclusion proof and confirm it reaches the published ledger root
python3 - <<'PY'
import hashlib, json
COMMIT_VERSION = "ec-m-1.1.commitment.v1"
a = json.load(open("anchor.json"))
rec = a["records"]["P03-2026"]
h = rec["leaf"]
for step in rec["proof"]:
    pair = step["sibling"] + ":" + h if step["side"] == "left" else h + ":" + step["sibling"]
    h = hashlib.sha256(("node:" + COMMIT_VERSION + ":" + pair).encode("utf-8")).hexdigest()
print("derived root:", h)
print("anchor root: ", a["ledger_root"])
print("match:       ", h == a["ledger_root"])
PY

If both leaves match and the derived root matches the published root, the record's commitment is mathematically present in the published ledger — independent of anything Landseed says. Once the root is anchored externally at vintage close, that anchor adds the further property that the registry could not have been silently rewritten after the anchor moment.

Operational rhythm