Technology.

What it establishes

Three statements, each checkable.

1. Position. These exact bytes, by SHA-256, were bound at count N+1 of one enclave’s sequence, immediately after a fresh hardware nonce at count N, in a single signed action. Nothing was counted between them, and no count is ever given out twice.
2. Origin of the record. The binding was performed by a specific enclave build whose measurement (PCR0) is published, as AWS Nitro hardware attests in a document signed for that exact proof.
3. Time. The binding happened by the time in the hardware’s signed attestation. Through bitgraph.ing it also falls inside a window of public time: after a named Base block, and before the block where the proof’s hash was written.

What it does not establish

• When the content was created. An old file can be bound today. The proof fixes when it was bound.
• Who made it, or whether it is true. It binds bytes, not authorship or meaning.
• That nothing else exists. It proves a record was made, not that no other record was.
• Order across epochs from the enclave alone. Each epoch is its own sequence; epochs are placed in time by Base, not by each other.

The mechanism

What happens when a digest arrives.

1. Gate. The enclave refuses to bind until the host has initialised it, and accepts only a canonical 32-byte SHA-256.
2. Nonce. 32 bytes are drawn from the Nitro Secure Module’s hardware RNG, after the digest arrives and inside the enclave. Nobody, the host included, sees it before the proof is released.
3. Count N: the slot. A slot record (nonce, count N, epoch, key) is signed with the enclave’s Ed25519 key and hashed.
4. Count N+1: the content. The commit names the digest, count N+1, the slot’s count and hash, the epoch, and the hash of the previous proof.
5. Attest, then sign. The hardware is asked for an attestation whose user data is the SHA-256 of the canonical signed body; the body is then signed.
6. Advance. Only now does the counter move to N+1 and the chain hash update. The proof is released.

Why the nonce: it is what makes the position its own. Because it is drawn after the digest arrives, a position cannot be reserved in advance and filled later, and every proof carries a value no one could have known before it existed. Work made from one BitGraph’s published nonce could not have existed before that BitGraph, which is how two BitGraphs bracket work between them.

Atomic by construction

There is no partial state.

Every step that can fail (the random draw, the signature, the attestation) comes before the counter moves. If any fails, nothing is released, the counter stays where it was, and the drawn nonce is discarded without ever leaving the enclave. Requests are serialised inside the enclave, so two binds cannot interleave.

Tested on the unmodified enclave code with injected faults in the RNG, the signer and the attestation: server/commit-service/src/enclave/__tests__/bind-failure.test.ts.

The sequence

Counted, chained, gaps visible.

Every proof after an epoch’s first carries prevB64, the SHA-256 of the whole previous proof. Within an epoch the counts climb by two per BitGraph, nonce then content. Given a run of proofs, the verifier checks that each is atomic, that counts are consecutive and that each links to the one before; a missing proof shows as a gap (verifyStretch). Anything bound between BitGraph A and BitGraph B was bound after A and before B (verifyBetween).

Epochs

The enclave’s key and counter live only in its memory, so each start is a new epoch: a new key, a counter from zero, and an epochId signed into every proof. Epochs are independent sequences. Each one’s first BitGraph binds a record of the Base blockchain, which places that epoch’s start in public time.

The measured enclave

The hardware names the code that made each proof.

Each proof carries an AWS Nitro attestation document, signed by AWS’s hardware (ES384, certificate chain to the AWS Nitro root). It states the enclave image’s measurement, PCR0, and carries as its user data the SHA-256 of the exact signed body of that proof. The signing key is generated inside the enclave at start and never exported; it is tied to the hardware through that per-proof attestation.

The current image, v13, measures:

adaad0bef62292d35197ae8db19e40685229f1a1e6070a7c77a148c4ada88ee66a1ca50819eebc2017c6716a49f2692f

It is reproducible: two independent builds from the enclave-v13 branch produced this PCR0. (The image file itself differs build to build because its header holds a build time; the measurement does not.) Every published image back to the first is listed in the verifier, and only those are accepted by default.

Time

The hardware’s clock, then a public window.

The enclave adds no clock of its own. The time in a proof is the attestation’s timestamp, set and signed by the AWS Nitro Secure Module.

Through bitgraph.ing, every BitGraph is also placed in the time of a public chain BitGraph does not operate:

• Floor. The latest Base block is read just before the bind and bound with it (in a collection, as its first leaf). A block hash cannot be known before its block exists.
• Ceiling. After the bind, the proof’s hash is batched into a Merkle root and written to Base in a self-addressed transaction. The proof existed by that block.

No blockchain is needed to verify a proof. Base is only needed to check the floor and ceiling claims.

Collections

A million files, one BitGraph.

Many items are recorded at once as an RFC 6962 Merkle tree over their SHA-256s (leaf = SHA-256(0x00 ‖ digest), node = SHA-256(0x01 ‖ left ‖ right)). One BitGraph binds a short text naming the root and the count. Each item then proves its own inclusion with a path of sibling hashes, without the others being disclosed. The format allows up to 1,000,000 items in a tree.

Measured 2026-10-28 on the current flow, in Node on an 8-core Apple M3 laptop: one million files hashed in 1.9 s, the tree built in 2.4 s, and the root bound 6.1 s after the drop. Open the result as BitGraph #34, or download the run’s files: timings, corpus seed, root text and proof file. Reproduce it with website/scripts/bench-million.mjs.

Without disclosure

Prove a record exists without showing what it bound.

Each proof holds two signed records: the slot at count N, with the nonce, epoch and key and no field from the content; and the binding at count N+1, which names the digest. The slot record is signed on its own. So a holder can withhold the binding and the content entirely and still show the slot: an auditor checks its signature under the same key as an attested proof from that epoch, and learns that the measured enclave established that position, without learning what was bound there.

Built into the proof format today. The check uses the verifier’s existing signature and canonical-encoding steps; it is not yet a one-line command.

The proof

Small, self-contained JSON.

{
  "version": "bitgraph/1",
  "artifact":  { "hashAlg": "sha256", "digestB64": "…" },
  "commit": {
    "nonceB64": "…", "counter": "16", "slotCounter": "15", "slotHashB64": "…",
    "epochId": "…", "atomic": true, "prevB64": "…", "chainId": "bitgraph:main"
  },
  "signer":      { "publicKeyB64": "…", "signatureB64": "…" },
  "environment": { "enforcement": "measured-tee", "measurement": "<PCR0>",
                   "attestation": { "format": "aws-nitro", "reportB64": "…" } },
  "slotAllocation": { "version": "bitgraph/slot/1", "nonceB64": "…", "counter": "15", … }
}

The signature covers a canonical serialisation of the body. A collection member also carries its inclusion path, as unsigned metadata that is checked, not trusted. Download a real proof, or verify it.

Verification

Offline, with an open verifier.

The verifier is MIT-licensed. It needs the data, the proof, and nothing of BitGraph’s running:

npx @mikeargento/bitgraph-sdk verify <file> --proof <file>.bitgraph.json --pcr0 adaad0bef62292d35197ae8db19e40685229f1a1e6070a7c77a148c4ada88ee66a1ca50819eebc2017c6716a49f2692f

1. The attestation verifies: AWS signature, certificate chain to the pinned Nitro root, PCR0 equal to the proof’s measurement, user data equal to the hash of the proof’s signed body.
2. The PCR0 is a published image the verifier accepts.
3. For a collection member, the data’s hash walks up its path to the bound root.
4. The data’s SHA-256 matches the digest; the Ed25519 signature over the canonical body checks.
5. The slot record checks: its own signature, the same nonce, key and epoch, and content at exactly the slot’s count plus one.

A key anyone can generate can sign a body that passes a signature check alone. It fails the attested check, because no AWS document covers it. The verifier’s own test does exactly this: packages/verify/src/__tests__/attested.test.ts.

Threat model

What each party can and cannot do.

What you trust

The hardware root, the published build, standard cryptography.

• AWS Nitro. The Secure Module’s RNG, clock and attestation key, and the Nitro root certificate. A flaw in Nitro is a flaw in every proof.
• The enclave image. Its source is public on the enclave-v13 branch and its measurement reproduces, so what it does can be read and rebuilt rather than taken on trust.
• SHA-256, Ed25519, ES384.

Not trusted: BitGraph’s website, its servers, its storage, or its word. A proof that checks offline against the published measurement checks whether or not BitGraph is still running.

Comparisons

Where it differs, and where it fits beside.

These systems answer different questions, and most products combine several. The aim here is the difference in what is enforced, not a ranking.

Next

Check it yourself.

The evaluation guide walks through making a BitGraph, verifying it offline, and watching each kind of tampering fail.