Enclave measurements.

Every enclave image BurnLedger has run in production, by its PCR0 measurement and the date it went live. This page is a commitment, not a proof. Read what this proves before you rely on it — the honest answer is narrower than the presence of a number suggests.

What a measurement is

The Ed25519 key that signs a BurnLedger verification record is generated inside an AWS Nitro Enclave and never leaves it. When that enclave boots, the hardware hashes the image it is about to run into a platform configuration register — PCR0, 48 bytes, written below as 96 hex characters. A different image measures differently. There is no way to run code inside the enclave without changing the number, and no way to change the number after boot.

That measurement is what the key release is conditioned on. It is the whole reason enclave custody is worth stating: the constraint is enforced by AWS KMS against a value we pinned in advance, not by our own process discipline.

Where each measurement is enforced

The same value is pinned in three independent places for every release. All three are ours — that is the point of the next section — but they fail in different directions, so a mistake in one is caught by another.

The release runbook tightens the KMS policy after each cutover so it admits the new measurement and no other, including the one it replaced. Rolling back is therefore a deliberate re-pin, not a file copy.

The history

Newest first. source is the git commit the image was built from, in a repository that is not public; it is published because a commit identifier the reader cannot fetch is still a commitment we cannot later restate.

EIF v43 — cut over 2026-09-10, in production now

PCR0    10ed72207ffd6a14f5913130eca69e9f4f9de0447b360e9cfd8aa8e349681c6fe98c515499a38a347d67932a6201a9b4
source  49562de908b57723ac6bc545d66ec6deed7b2170

Carries the writer half of registration: the enclave can now issue the three signed documents it has been able to check since protocol 9 — an enrollment naming a customer key group, a registration pinning which datastore and question may later be measured, and a rotation link from one key group to its successor. Until this release nothing could issue them, so the checks had nothing to check against. Nothing enrols a real key yet: the mechanism exists and is unused, deliberately, because an enrolled key is a published fact with a migration attached. The wire moves from protocol 9 to 11. Issuance stays at format 9.0 — a holder reads exactly what they read before, and no verifier needs updating. It also carries a fix to the Oracle connector, which shared one TLS configuration across a connection pool and could verify a certificate against another connection’s hostname.

EIF v42 — installed 2026-09-10, ran for seven minutes, rolled back. Never in production.

PCR0    f1e02ace0011bfc0d60d6dd76da0078b7706f3165eff6904a36e97e5d2029246099ef20bf15f87d0263dd843f878731c
source  02938bc87110eca6ab45692d09dfb60279ccdd5f

This image is recorded because it ran, not because it shipped. It was installed on 2026-09-10 and the enclave started under it, but the host API server would not boot beside it — a route it added failed a startup check — so it was rolled back after about seven minutes and issued no verification records at all. No holder has a record signed by this measurement, and none ever will. It appears here because an image that ran in production and was never published is the failure this page exists to prevent, and “briefly” is not an exemption. The measurement below is what a reader would need if one ever turned up.

What it would have carried, and what a later release will: the enclave can now issue the three signed documents it has been able to check since protocol 9 — an enrollment naming a customer key group, a registration pinning which datastore and question may later be measured, and a rotation link from one key group to its successor. Until this release nothing could issue them, so the checks had nothing to check against. Nothing enrolls a real key yet: the mechanism exists and is unused, deliberately, because an enrolled key is a published fact with a migration attached. The wire moves from protocol 9 to 11. Issuance stays at format 9.0 — a holder reads exactly what they read before, and no verifier needs updating.

EIF v41 — cut over 2026-09-08

PCR0    7a61327a0ee11508764a8ad03d68e81e3b374e4e605a284e9e815ec9cf57de8497e59d57048977441f9c5c98bee1d14b
source  0a3d9da0bb555c256f5a0faddb36ef04bb6dcce7

Carries a change to how subject salts are stored: a salt may now be rotated, and rotation appends a new salt rather than replacing one, because the subject hash is inside signed material and existing records are never re-signed. Nothing a holder reads changes — issuance stays at format 9.0 and the wire stays at protocol 9 — and the change itself is host-side. The measurement moves because the enclave compiles a shared package that was also touched, which is why every release is measured rather than reasoned about.

EIF v40 — cut over 2026-09-08

PCR0    665864551aeb57705c3b3721018112cbd0e2be98de2e0ff9142a6c0abf366c72c6ba6cdcd31cd6ed8471862e1b9187ce
source  4d2aa24afa389cae00cf1d975d0b0e70bef3da7b

Moves the Go toolchain the enclave is compiled with, and nothing else: no change to what a record contains, how it is signed or what the service does. Issuance stays at format 9.0. The compiler is part of what PCR0 measures, so a toolchain change moves the measurement even when no source line changes — and it is released on its own, so a measurement that moved can be attributed to the toolchain rather than guessed at.

EIF v39 — cut over 2026-09-08

PCR0    0e79f985c287fbad3ed9aa1d5443189c45428929086dc4d4312ba71c4039742a8bca02f4ea15ab318d82e1d86ff883d3
source  08bf106a7a2080d2bbcb76cee932715e8d6179de

Moves record issuance to format 9.0, which adds authorization and customer_key_id to every attested system: whether the enclave checked that system against a registration certificate the customer signed before it ran the query, and which of the customer’s key groups authorized it. Before 9.0 a record produced on the registered path and one produced without were the same bytes, so a holder could not tell which had happened. It also carries wire protocol 9. The format constant is compiled into the enclave, so changing it changes the measurement.

EIF v38 — cut over 2026-09-07

PCR0    4195c7056269bff589859e91e3a2fa01a3dae5dbe9970fd02c8a3e76ae47d578edf5e762239db71b8d904c59b100a104
source  ea97f8fc382f7e026fed88caa5a1c2ab895cb5f9

Moves the check that a verification asked the question the attestation names into Certify, after the attestation signature has been verified. Previously the value was read at VERIFY, where the payload being judged is composed by the host — so the check was made against a value the enclave had not signed. Issuance is unchanged: format 8.0, wire protocol 6.

EIF v37 — cut over 2026-09-07

PCR0    57b23d70ef77f349e99804f6d6a188c358bb42b0cd668f6922b630db6c64289c44d9e16483bb9436162638ceb9781348
source  ee65594cb499ae4e3de03e5355e91d049a84f74a

Moves record issuance to format 8.0, which adds recoverable_state to every attested system: whether anything checked for a restorable copy of the records the document certifies removed, and what it found. Six connectors ask the datastore and refuse while such a copy exists; fourteen cannot, for reasons that differ in kind, and before 8.0 both produced identical bytes. It also carries wire protocol 6. The format constant is compiled into the enclave, so changing it changes the measurement.

EIF v36 — cut over 2026-09-06

PCR0    a598e1e672a21b03a371fb840c74f6967b78282361ea9973d20bc4baa7c1206c26323887a814c73f1c5ab178dccef740
source  5866fbde2ed74224d419c47e45c67a9f5bdeca76

Moves record issuance to format 7.0, which measures read-only enforcement and transport security per system, names the signing algorithm, and keys each record commitment with a key the enclave draws for one attestation and destroys with it. It also carries wire protocol 5. The format constant is compiled into the enclave, so changing it changes the measurement.

EIF v35 — cut over 2026-09-04

PCR0    70b0b998a7e4408e47180c1f96cfb0f4ab0ed2967eadce48605775bdf499a5fa6050c15cfe14641a4932aa37cf5e62da
source  60e7badb25ec9850801474b98b9384816a42ab5e

Moves record issuance to format 6.0. The format constant is compiled into the enclave, so changing it changes the measurement.

EIF v34 — cut over 2026-09-03

PCR0    9d97b1f6651613e200c142518d17341ee78d72762ae4cc8348daa3ceab2007659e5290de832b6779ca45eada49ba881b
source  7eb33b0048c0e1801fcf1d4db214f90157cc3aa9

Removed a legacy key-derivation read path from the enclave, completing a per-purpose key migration.

EIF v33 — cut over 2026-09-03

PCR0    bfc53f163d9272bfdca98120a901adda4c1cc788eca7d2049b9fc1e3a2b8adf2a17e50dd414de2dca01e7e625823883f
source  70e2ac8b19094666fbd438b1e80fda8961167aa5

API audit fixes; added a tenant identifier to the enclave’s wire types.

EIF v32 — cut over 2026-09-02

PCR0    4c045c731eaa61aede5fbf69808ba5a2e4ca4f4035945081de5332b728a6bdbcdd5fa3086ced0391f48c138f6e23badc
source  d634a38ce1f103c6ad60f7ba45489f0830cf212f

Record format 5.0.

EIF v31 — installed 2026-09-01

PCR0    876323e4420e7c2c5ed07c2e02b8df7abf39af16b8b50cf909fc5f8aa5f0241aa416e46c4486d90106980bd45ff23aea
source  0c5a1d117a1e622574e5370444eca0cffe50dc03

A different commit that measures identically to v30, because nothing in it reaches the enclave image. Published as its own entry rather than folded into v30: two source commits behind one measurement is a fact about how the measurement works, and hiding it would make the series look tidier than it is.

EIF v30 — cut over 2026-09-01

PCR0    876323e4420e7c2c5ed07c2e02b8df7abf39af16b8b50cf909fc5f8aa5f0241aa416e46c4486d90106980bd45ff23aea
source  a7d0f10f8dbdb48953437310673e2c8d877b3e75

The first release whose source commit was stamped into the image and into every parent binary. This page starts here because this is where recording the commit became mandatory rather than customary.

The unversioned image — superseded 2026-09-01

PCR0    79e53c51afdf41905c9b60c6573eb7a740819ed8a50ba10bdeb32f88e70e6ebfc2252083d293c5d9b3ec56cc3cd7a1ea
source  unrecorded

The image v30 replaced. It went into production on 2026-08-29 and we can measure it exactly — but the commit it was built from was never written down and cannot now be recovered. It is listed with the gap left open. Removing it would make the history continuous and false; the defect it represents is what v30 exists to close.

What this proves, and what it does not

A third party cannot reproduce these measurements. The enclave source, the enclave image and the toolchain that builds them are not published, and are not going to be: the enclave source is the product, and a compiled image is that source one disassembly away. That is a settled decision, not a gap we are working on. So nobody outside BurnLedger can take a value from this page, build the image themselves, and confirm the two agree. We rebuild every release twice from the same commit and confirm it measures identically, which is how we know the build is deterministic — but that check is ours, and we would rather say so than let the presence of a number imply otherwise.

What it proves is narrow: that we committed to these values publicly, on these dates, and cannot now revise them unnoticed. Before this page existed, every copy of a BurnLedger measurement sat somewhere we control and can edit — a key policy, a host configuration, a file on a server, an internal record. A page on the public web is copied by crawlers and archives within days of going up. If we ever restated which image had been running on a given date, or claimed an image we had not declared, an archived copy of this page would contradict us. That is a constraint on us. It is not arithmetic you can do.

Specifically, this page does not establish:

• That a measurement corresponds to particular source code. The binding between the two is our assertion. Nothing here lets a reader test it.
• That the image behaves as described. A measurement is a hash of an image, not a statement about what the image does. The one-line summaries above are our description of each release, offered for context and carrying exactly the weight of a description.
• That the list is complete. It is complete as far as our own records go, and those records are what this page is a commitment about. An image we never recorded is an image we cannot publish; the entry above with an unrecorded source commit is the one case of that we know of, and it is listed rather than dropped.

What a record holder can do with this

One thing, and it is worth spelling out because it is the reason this page exists rather than a paragraph of reassurance.

From record format 5.0 onward, a verification record names the measurement of the image that signed it, in the field issuer.enclave_pcr0, inside the Ed25519 signature. Anyone holding a record can read that field and compare it against the entry on this page covering the record’s issued_at. Two strings and two dates; no account, no request to us, no tooling beyond what already verifies the signature.

If they match, the image the signer names is one BurnLedger had already declared publicly at the time the record was issued. If they do not match, the record names an image we never declared — and that is a question worth asking us in writing.

The stronger check needs the hardware attestation document itself, which is produced inside the enclave per record and does not travel inside the record file. The per-record document is returned alongside the record on GET /v1/certificates/{id}, as nsm_attestation, to the team that record belongs to and to nobody else; it stays unpublished, because it is bound to one customer’s record. A team holding one can check that it chains to the AWS Nitro root and that its PCR0 is the value published above, which is the strongest check the system offers. Before this page there was no published value to pin it to.

Asking the enclave yourself

The paragraph above needs a record and an account. There is a check that needs neither. It arrives with the EIF v36 cutover — until that entry appears in the history above, this command has nothing to talk to:

burnledger enclave attest --api-url https://api.burnledger.io \
                          --pcr0 <a measurement from this page>

The command draws 32 random bytes on your machine, calls the unauthenticated endpoint GET /v1/enclave/attestation?nonce=…, and checks the document that comes back against the AWS Nitro root CA compiled into the binary — not fetched from us. It fails on a bad COSE signature, a chain that does not reach the root, a PCR0 other than the one you passed, a timestamp outside a five-minute window, or a nonce that is not the one it sent.

The nonce is the part that matters. Every attestation document this enclave has ever produced is genuine, including ones from images retired months ago, so a document alone proves only that some enclave existed at some point. AWS signs over your nonce, which is what makes the answer a statement about now rather than a recording. The relay cannot forge it: it holds no Nitro key and no NSM device, so its only options are to pass the request through or to refuse it, and refusing is visible.

What a pass establishes: the Ed25519 key that signs verification records is held by an enclave running an image measuring that PCR0, at the moment you asked. What it does not establish is the same thing this whole page does not establish — that the image was built from any particular source. You are comparing a live measurement against a dated public commitment on this page. That is a real check and it is exactly that much.

What is checkable without any of this

Everything in a verification record itself, and it is deliberately separate from the above. The two Ed25519 signatures, the canonical payload, the scope commitment and the RFC 6962 inclusion proof are recomputable offline by anyone holding the file, with no BurnLedger account and no request to us — and the transparency log’s consistency between any two heads is checkable against the live log. That is the part of the system that does not ask for trust. Enclave custody is the part that does, and this page is us writing the claim down where we cannot quietly edit it. See Verify a record.

Next

Read Verification Record anatomy for what a record contains and what each field binds, or Verify a record to check one yourself.