Limits
A BitGraph proof establishes one narrow thing: these exact bytes were committed at this position in one sequence, the position existed before their digest arrived, and the position was placed after the Base block its floor names (an Ethereum block on earlier proofs). A reader tends to assume neighboring claims. None of them follow, and this page says which ones.
Not established by any proof
- TruthA recorded document can be wrong in exactly the form it was recorded. The proof binds bytes, not their meaning.
- AuthorshipA proof attests the boundary that committed the digest, not the person or program that made the file. A signed attribution is a note bound into the proof, not a verified identity.
- OwnershipNothing in the protocol touches rights. Holding a proof of some bytes says nothing about being entitled to them.
- First creationThe same bytes may have existed elsewhere before, and an old file can be committed today. What is fixed is the position the bytes took here. A fused file carries a bound on its own bytes, not on the original it was built from.
- An exact timeThe floor is a time: the block the proof names as its floor was made before the position existed. The ceiling in time is the Base block that later includes the record’s proof hash, seconds after the commit, so the answer is a window, not an instant. Order after the record is a position, not a time: the next BitGraph in the chain. No field in a proof is a trusted timestamp.
- CompletenessA record that was never made leaves no trace, and an allocated position can be abandoned unused. What is shown is the order of what was committed, never that everything was.
- A universal orderOrder is total within one epoch of one sequence. Two unrelated sequences, or two epochs of the same one, are related only through the public blocks their floors name: Base blocks, or Ethereum blocks on earlier proofs.
- That an action occurredA record of a delivery, a signing or a decision is placed; whether the thing it describes happened is for whatever produced the record.
- Physical captureThe enclave receives a digest. It has no sensor path, so it cannot say a photograph was taken by a camera, or when.
- Human intentNothing in a proof identifies a person or their intent. The optional agency envelope can bind a device key to a commit; that is actor binding, not authorship.
- Correct inputIf the client hashes the wrong bytes, or a compromised client hashes whatever it likes, BitGraph positions that digest faithfully.
- Legal effectA proof is evidence a reader can check. Whether a jurisdiction admits it or gives it weight is not something the protocol establishes.
What a BitGraph proof catches, and what it does not
Five things someone can do to a record, and whether the BitGraph proof shows it. Two of the five it shows, one it shows only in part, and two it cannot see at all.
| What is done to the record | Does the BitGraph proof show it? |
|---|---|
| A false record is written, then committed | No. A false record is committed exactly like a true one. Nothing in a proof inspects content. |
| The record is changed after it was committed | Yes. The bytes no longer hash to the committed fingerprint, so the check fails for anyone holding the record and the proof. |
| The record is claimed to be older than it is | Yes. The proof names a Base block that the enclave bound into the position when it opened, so the position cannot be moved earlier than that block. |
| The record is destroyed after it was committed | In part. The position stays in the sequence, so its absence is visible. What the record said is gone. |
| The record is never written at all | No. Nothing that was never committed leaves a trace. |
The second row is the one that is hard to settle without evidence like this. In August 2026 METR published an independent investigation into the incident in which OpenAI agents attacked Hugging Face. Agents there worked at editing their own transcript logs after the fact, and the investigators reported detecting no case where that succeeded while stating they could not rule one out, partly because the container resets the agents were trying to trigger would themselves have erased the evidence. That is the question a committed position answers, and it is answered by the reader rather than by an investigator with privileged access. The report is here. METR has no association with BitGraph and proposes no remedy of this kind.
Recording existing bytes versus building a fused file
Recording a file that already exists gives its digest a position. The bound is on the placement: the bytes existed no later than the commit. It says nothing about whether they could have existed before the position. Building a fused file writes a position commitment into new bytes, so the new bytes could not have been finished before the position was allocated. That bound reaches the new bytes and stops there: the original inside them can be any age. Neither operation says when the content was made, whether it is authentic, or whether what it describes happened. The overview shows the difference.
Systems BitGraph is mistaken for
Each of these is good at what happens inside its own boundary, and each labels a record with something that refers back to its issuer: the time on the record, its place in a log the issuer keeps, the tags attached to it. A label can be changed, removed or moved to another record, and nothing shows it. What none of them gives its own record is a position issued outside that boundary.
| System | What it establishes | How BitGraph differs |
|---|---|---|
| A digital signature | A key holder endorsed these bytes. | The signer chooses when to sign and can sign anything at any time. BitGraph’s position exists before the digest is received and cannot be occupied twice. |
| A timestamp authority | A trusted party saw this digest at its stated time. | One-sided, and a trusted third party in the verification path. BitGraph’s floor is a public Base block anyone can look up, and offline verification contacts no one. |
| A secure clock | A server or a piece of hardware signs the time it reports, and chained requests can catch a server whose answers disagree. | A signed reading is still an assertion by whoever holds the clock, and it is applied to bytes that already exist. BitGraph reads time from a block nobody signs, and the position it gives out exists before the bytes’ fingerprint reaches it. |
| Blockchain notarization | This digest existed no later than block N. | Any bytes from any source can be committed after the fact. BitGraph gives a floor as well, from the Base block the enclave binds when the position opens, and takes its ceiling in time exactly this way: a Merkle root on Base, written after the commit. The notarization is the second half, never the first. |
| A beacon and blockchain sandwich | A portable proof holding a public randomness value and a blockchain anchor: the proof was assembled after that value was published, and the record existed by that block. | The closest neighbor, and the bounds sit differently. Its lower bound covers the assembly of the proof rather than the record, because nothing is issued to the holder before they submit, so the record itself can carry nothing. BitGraph allocates the position first, signs it, and returns it before the digest arrives. |
| A transparency log | An append-only, publicly audited record of entries, with inclusion and consistency proofs. | Stronger against equivocation than BitGraph’s per-verifier fork check; weaker on the position side, because entries are submitted after they exist. |
| A hash-chained audit log | Each entry commits to the one before it, so altering an entry breaks every link after it. | It detects an edit, not a rebuild. Whoever holds the log can recompute the whole chain and present a consistent one, unless the head was published somewhere they cannot reach. Publishing the head outside the operator is what BitGraph does for every proof. |
| A ledger database | Rows in a table are hash-chained inside the database, so an altered or deleted row is detectable there. | The chain is built and held by the operator running the database, and its head goes nowhere else. Whoever can rewrite the history can rewrite the chain over it. BitGraph’s sequence is signed inside a measured enclave and its floors and ceilings are public Base blocks, so the operator is not the witness. |
| Write-once storage | Stored bytes cannot be overwritten or deleted until a retention period expires. | It prevents an edit in the place the bytes are kept and says nothing about when they were made. The guarantee belongs to the operator and does not travel with a copy. BitGraph keeps its own copy this way for the same reason anyone would, and no claim in a proof rests on it: a proof is checked against bytes you hold. |
| Content credentials (C2PA) | A signed manifest of claims about origin and edits, attached to the file. | A packaging and disclosure layer that can be stripped in transit. BitGraph is external to the file, survives stripping, and carries no identity of its own. Complementary, not competing. |
| A watermark | A mark hidden in the content. | BitGraph hides nothing. A fused file’s commitment is documented, placed in a registered spot, and the original is never modified. |
| DRM | Control over copying. | BitGraph prevents nothing. Every copy of the bytes carries the same position, and no copy is the special one. |
| A blockchain | Global consensus over shared transactions. | No consensus, no tokens, no global order. One boundary constrains one sequence. Base is read as a clock for the floor, and carries one small transaction per batch of records as the ceiling in time. |
| A freshness window | A record was seen recently enough to fall inside an accepted window. | It can say a record looks too old. It cannot say whether the record’s claimed time agrees with anything outside it, and a small enough backdate passes any window. |
| Hardware attestation alone | Specific code ran inside specific hardware. | Attestation is evidence BitGraph carries, per proof. The protocol is the commit path the attestation fits into. |
What other evidence can add
These limits are boundaries, not gaps to be papered over. Authorship and intent can be approached with the optional agency envelope, which binds a device key that required user verification to the commit; that raises the claim to “this key authorized this commit” and no further. Content credentials can ride beside a proof and say who signed a manifest. A transparency log can hold the same digest. None of these convert into BitGraph claims; they are separate evidence a reader may combine, and the proof stays honest about what it alone establishes.
Where next
- Trust modelThe assumptions behind the claims that do hold, and how they fail.
- VerificationWhat a verifier checks and what each result means.
- Use casesWhere a position is worth proving despite these limits.