BitGraph — Origin Controlled Computing

Portable cryptographic proof of construction for digital artifacts.

---

Origin can be enforced or it can be claimed. Most digital provenance systems claim it. They produce an artifact and then attach a signature, a timestamp, or a metadata block describing where the artifact came from. The claim arrives after the artifact already exists, which is the wrong end of the timeline.

OCC enforces origin. A measured trusted execution environment creates an unpredictable cryptographic slot before the artifact's hash is known. The artifact's hash arrives later and is bound into the slot. The slot is consumed and cannot be reused. What emerges is not a description of provenance but a proof of construction.

OCC turns randomness into one-time causal space: a nonce becomes origin space when a TEE can prove it was unused before and consumed once.

This exact digital state was committed through this measured process, in this order, under these constraints.

The primitive

Nonce first. Hash second. Atomic binding third.

The TEE generates hardware entropy inside the enclave. That entropy becomes a slot, signed with the enclave's key, with an identity no attacker could have precomputed. The slot exists as a cryptographic object before any artifact hash has been seen.

The artifact hash arrives. The TEE binds the hash into the slot, signs the binding, and advances its internal order. The slot becomes consumed.

UNUSED slot exists first. Artifact hash enters later. TEE binds the hash to the slot. Slot becomes CONSUMED. Proof travels with the artifact.

The atomicity is the whole guarantee. The slot is allocated and signed before the hash is known. The slot can be consumed exactly once by a single binding operation. The artifact itself can be produced anywhere, by any process, using any tools. What matters is that when the hash arrives, the slot is already there waiting.

Most systems say: "Here is a file hash. Now let's sign it." OCC says: "Here is a pre-existing origin slot. Now this file hash has occupied it."

Why nonce-first matters

If a nonce, timestamp, or credential is added after the hash is already witnessed, it is just a label. It can prove someone signed something. It can prove a record existed by some moment. It cannot constrain the artifact's origin, because the artifact already existed before the nonce entered the picture.

That leaves a forgery window. A malicious actor can prepare old hashes, replay prior material, backfill records, or attach fresh randomness to something never produced through the claimed path. The label looks valid. The construction was never constrained.

OCC closes the window by requiring the slot to exist first. The slot is not evidence added afterward. It is the condition the artifact must satisfy.

What an OCC proof contains

An OCC proof is a portable proof object, typically JSON, that travels with the artifact. It can include:

Component	Purpose
Artifact hash	Identifies the exact file or digital state
Nonce	The pre-existing causal slot
Slot counter	Shows the slot was allocated before the commit
Commit counter	Shows the artifact consumed the slot later
Epoch ID	Groups an ordered run of commitments
Previous hash link	Connects proofs into a chain
Signer public key	Identifies the proof-signing authority
Signature	Verifies the proof was issued by the enclave-controlled key
TEE measurement	Shows what code and environment produced the proof
Attestation	Shows the proof came from measured hardware
Public anchor	Tethers OCC logical time to a public reference

The result is not "a file was signed." It is: this hash was committed into this causal slot, by this measured environment, at this position in logical order, under this signing identity.

Logical time

Every proof has order. Every slot and commit has a position. The system can prove that this happened after that, that this slot existed before this hash was bound, that this proof came before the next, that this epoch has an internal cryptographic history.

OCC proves causal order first. Clock time is optional.

Ethereum: the backward seal

OCC's internal ordering does not require Ethereum. The chain creates internal order through slot allocation, consumption, counters, signatures, and chained proof history. Ethereum anchors add a different property on top: a public backward seal that any third party can independently verify.

An Ethereum block hash that becomes available after the artifact has been committed could not have been known at the moment of commitment. This produces an entropy sandwich:

1. Private TEE entropy before the artifact.
2. Artifact commitment in the middle.
3. Public blockchain entropy after it.

The artifact was committed after the TEE-created slot existed and before the later Ethereum block was knowable. That bounds the commitment in adversary-resistant entropy, witnessed in a public timeline anyone can check years later.

Ethereum is not asked to prove the artifact's origin. OCC does that. Ethereum provides the backward seal that makes the commitment publicly verifiable.

Multi-TEE breach detection

OCC's architecture supports running three independent TEEs in parallel as a tripwire, not a consensus system. Three TEEs witness the same input and produce three individual proofs with different nonces, signatures, and attestations. They agree on the meaningful result: same artifact hash, same policy decision, valid measurements, valid signatures, expected ordering behavior.

If one diverges, the system does not need to know which one is compromised. It only needs to know something is wrong. The batch is quarantined, the affected range is marked suspect, the epoch is rotated, and downstream verification accounts for the gap.

This is not "trust this TEE forever." It is: compromise is assumed, silence is what gets eliminated.

The trust model

OCC does not depend on blind trust in any single component. Not the operator, the TEE, Ethereum, the clock, a certificate authority, or a live server. Each layer adds an independently verifiable property.

Layer	What it contributes
TEE	Measured execution and protected key use
Nonce-first slot	Causal precondition
Atomic binding	Prevents post-hoc attachment
Counters	Internal logical order
Proof chain	Historical continuity
Ethereum anchor	Public backward seal
Multi-TEE redundancy	Breach visibility
Epoch rotation	Damage containment
Portable verification	Independence from the original server

What OCC applies to

OCC works on any digital state that can be hashed. The same primitive applies whether the artifact is a photograph, a contract, a model output, a dataset, or a software release.

Media. Photos, videos, audio, edited files, generative outputs. The question shifts from "is this real?" to "what origin path does this artifact satisfy?"

AI outputs. Model results bound to authenticated identity and causal position without requiring the model to run inside an enclave.

Software supply chain. Build artifacts, releases, model weights, and deployment packages bound to a measured construction path.

Legal and clinical records. Contracts, filings, telehealth session manifests, lab results, and consent forms with independently verifiable causal ordering.

Research and IP. Datasets, experimental outputs, and possession proofs that commit to a hash without requiring the file to leave the user's device.

How OCC differs from existing approaches

OCC is often confused with adjacent systems. The differences are structural:

System	Says	OCC says
Signatures	This key signed this data	This key was controlled by a measured environment that consumed an unused slot
Timestamps	This hash existed by time T	This hash consumed a pre-existing slot at this position in causal order
C2PA	Here are signed claims about this content	Here is the construction path this content satisfied
Blockchains	Public ordering of shared transactions	Private origin coordinates with optional public anchoring

Signatures, timestamps, content credentials, and blockchains all answer "who claimed what, when?" OCC answers "what construction path did this exact artifact satisfy?" They are complementary, not competing. A signature can be inside an OCC proof. A timestamp can decorate one. Content credentials can ride alongside one. None of them, alone, do what OCC does.

Multiple copies of the same original

Physical originality depends on singularity. There is one canvas, one negative, one signed paper. Digital files broke that because perfect copies are indistinguishable from the source.

OCC introduces a different category. A digital artifact can be copied without losing its original provenance. The proof travels with the bytes or alongside them. Instead of every copy being a degraded copy, OCC allows multiple copies of the same original. Originality moves from physical container to causal proof. Singularity is no longer required for originality.

The simplest version

A measured TEE creates a random unused slot before the artifact hash arrives. The hash arrives. The TEE binds it to the slot, consumes the slot, signs the result, and links it into an ordered chain. Three TEEs can run in parallel so silent compromise becomes visible. The same mechanism periodically commits an Ethereum block hash, sealing everything before it in a public timeline.

The result is a provenance system that does not say "someone signed this." It says: this exact artifact occupied this origin coordinate.

---

Quickstart

Try it live: drop a file at bitgraph.ing. The file never leaves your device; only its SHA-256 hash is sent to the enclave.

Verify a proof in code:

npm install @mikeargento/occproof

import { verify } from "@mikeargento/occproof";

const result = await verify({ proof, bytes });
if (result.ok) {
  // signature, slot binding, attestation, and chain link all checked
}

See bitgraph.ing/docs for the full proof format, verification checklist, attestation handling, and self-host instructions.

License

Copyright 2024-2026 Mike Argento. Patent Pending.

Licensed under the Apache License, Version 2.0.