Trust Model

BitGraph guarantees single-successor semantics within the verifier-accepted measurement and monotonicity domain of the enforcing boundary.

Read precisely: the boundary enforces this within an epoch, and a fork across epochs is detected rather than prevented. Detection requires a verifier that has observed both branches, so an auditor holding the full ledger sees a fork that a verifier checking one proof cannot.

Assumptions

Assumption	If it fails
Boundary isolation - TEE prevents external key access	All guarantees collapse
Key secrecy - Ed25519 private key never leaves boundary	Proof forgery becomes possible
Nonce freshness - ≥128 bits, never reused	Replay within a session
Honest measurement - hardware correctly measures enclave	Delegated to TEE vendor
Monotonic counter durability - survives restarts	Anti-rollback degrades to single session
Causal slot integrity - slot allocated before artifact hash known	Without pre-allocation, commit order could be forged
Strict verifier policy - caller pins measurements + counters	Weak policy accepts more than intended

Honest measurement is verifiable, not just assumed. The enclave build is bit-for-bit reproducible: rebuild it from source on any linux/amd64 host and you re-derive the exact PCR0 the production enclave reports. You confirm yourself that the measurement corresponds to the published source, trusting no one, so the only part delegated to the TEE vendor is the hardware honestly reporting that measurement (and AWS's signed kernel, which PCR1 measures independently). Rebuild and verify the PCR0 →

Threat model

In-scope threats

Proof replay

minCounter in policy rejects old proofs

Measurement substitution

allowedMeasurements pins exact values

Signature forgery

Ed25519 unforgeability

Downgrade attack

Enforcement tier is signed; requireEnforcement rejects weaker tiers

Chain gap insertion

prevB64 chaining: any removed link breaks hash continuity

Counter position forgery

Causal slot pre-allocation: slotHashB64 binding + slotCounter < counter ordering proves pre-allocation

Agency replay across batches

Single-use challenge consumed on first validation; batch context scoped to declared digests

Retroactive forgery after compromise

Per-epoch keypair destroyed on restart + anchors hash-link prior history, fixing pre-anchor proofs against rewrite

Cross-epoch identity confusion

epochId binds every proof to a specific compartment; verifiers pin allowed epochs

Out-of-scope threats

• Signing key exfiltration - assumes boundary is secure
• TEE firmware vulnerability - delegated to hardware vendor
• Weak verifier policy - caller responsibility
• Physical access to enclave host - outside threat model

Ethereum anchors

BitGraph does not require a blockchain to operate, but it uses Ethereum as an external public timeline. The same TEE that signs user proofs periodically commits the hash of a recent Ethereum block into its own counter chain as an ordinary anchor proof. The anchor carries the enclave's public key, the epoch identifier, the current counter, and the block it references: nothing about any individual user or file. Nothing is written to Ethereum.

Each anchor is itself a BitGraph proof signed by the enclave, so it participates in the same counter chain as the user proofs that came before it. Its artifact is the hash of a recent Ethereum block, a value that did not exist before that block was produced, so the anchor and everything chained after it provably follow that block's public date. Every proof committed before the anchor is fixed against retroactive rewrite: the anchor is hash-linked to the entire chain behind it, so any alternative earlier history breaks the chain that reaches an anchor already stored and observed, and once the epoch's key is destroyed no alternative can ever be signed.

This is the mechanism behind the phrase "everything before me already existed." An anchor fixes backward, not forward. It does not prove when individual proofs were created, only that they preceded the anchor in the chain, while the anchor itself provably followed its block. Combined with per-epoch keypairs, anchors give BitGraph a bounded breach window: between one anchor and the next, a compromise could in theory rewrite the live chain, but anything behind the most recent stored anchor cannot be rewritten without breaking the chain that reaches it.

Anchors are public, but they reveal no user-identifying information. A verifier can fetch any anchor from Ethereum and use it to bound when a proof must have existed by, without ever contacting BitGraph.

Epoch isolation: blast-radius containment

BitGraph's strongest containment property is structural, not behavioral. Each restart of the enclave generates a new Ed25519 keypair inside the boundary, derives a new epochId from fresh hardware entropy, and resets the monotonic counter. This means every epoch is a sealed compartment, identified by a key that exists nowhere else in the world.

The consequence: a compromise can only forge proofs that carry the live epoch's public key. It cannot retroactively produce valid proofs under any prior epoch's key, because that key was destroyed when its enclave terminated and never existed outside the boundary in the first place. Past proofs remain verifiable because their signatures bind to a public key that no surviving system can sign with.

Ethereum anchors tighten this further. The same TEE periodically commits the hash of a recent Ethereum block into the epoch's counter chain. Each anchor is hash-linked to every proof before it, so once an anchor exists, the history behind it is fixed: nothing earlier can be altered without breaking the chain that reaches the anchor, and everything after it provably follows that block's public date. A breach window is therefore bounded on one side by the epoch boundary and on the other side by the most recent anchor that preceded it.

Restarting the TEE is not just operational hygiene — it is a deliberate containment action. Each restart closes one compartment and opens a fresh one, so any undetected compromise is quarantined to the bounded window of a single epoch. Verifiers can refuse to accept proofs from any epoch they have not pinned, narrowing trust to known-good compartments only.

Containment property	What it bounds
Per-epoch keypair	A compromise of one epoch cannot sign as another epoch
Key destroyed on restart	No surviving artifact can produce a valid signature under a closed epoch
Ethereum anchors	Pre-anchor proofs are hash-linked into the anchor, fixed against retroactive rewrite
Verifier epoch pinning	Trust scope can be restricted to known-good compartments only

Non-goals

• Global ordering from the counter alone - every TEE instance and every new epoch resets the counter to 1, so the counter by itself only orders proofs within a single epoch. Ordering relative to the outside world is established by Ethereum anchors: each anchor records the hash of a recent finalized block, so everything chained after it provably follows that block's public date — across epochs, across TEE instances, and against any other event that can be placed on the same public timeline.
• Cross-boundary double-spend - same artifact can be submitted to separate boundaries
• Copy prevention - BitGraph does not prevent raw byte copying
• Consensus replacement - BitGraph constrains a single boundary, not distributed parties
• Metadata integrity - the metadata field is advisory and unsigned