# Provenance: independent time roots and intrinsic identifiers

Two things live here, both free, both checkable without asking us for anything.

## 1. A second time root over the Granth chain head

The append-only chain is already anchored to RFC-3161 time authorities. Those are one
family. If you distrust that family, you distrust every anchor at once. So the head is
also stamped with [OpenTimestamps](https://opentimestamps.org/), which anchors the same
hash to Bitcoin through public calendar servers. The two roots share no operator, no key
and no failure mode.

Files in `opentimestamps/`:

| File | What it is |
|------|------------|
| `helix-head-<prefix>.txt` | The commitment: node id, chain head hash, index, length, and the public endpoint that serves the chain. Plain text, readable without tools. Tip may advance after the stamp; verify the pledged `(index,hash)`. |
| `helix-head-<prefix>.txt.ots` | The OpenTimestamps proof for that exact file. |

### Verify it yourself

```bash
brew install opentimestamps-client
# alternative: pipx install opentimestamps-client
curl -sSO https://kaydeep0.github.io/eigenstate-research/provenance/opentimestamps/helix-head-917f0e3036931e14.txt
curl -sSO https://kaydeep0.github.io/eigenstate-research/provenance/opentimestamps/helix-head-917f0e3036931e14.txt.ots
# Proof already upgraded; upgrade is idempotent if calendars have newer merkle data.
ots upgrade helix-head-917f0e3036931e14.txt.ots
# Prefer lite-client verify if bitcoind is not local:
ots verify --lite-client helix-head-917f0e3036931e14.txt.ots
# Host-confirmed: Bitcoin block 960660 attests this helix-head.
```

On-disk mirrors of the same proof (Host upgrade from engine, then copy to Pages):

- Engine: `~/Desktop/GENIUSFLOW_OS/workspace/geniusflow/data/attestation/opentimestamps/helix-head-917f0e3036931e14.txt.ots`
- Pages: `~/GENIUSFLOW_OS/workspace/eigenstate-research/public/provenance/opentimestamps/helix-head-917f0e3036931e14.txt.ots`

Then confirm the pledged entry is still in the public chain (tip may be newer than the stamp):

```bash
curl -sS https://geniusflow-federation.vercel.app/api/chain \
  | python3 -c "import sys,json;d=json.load(sys.stdin);h='917f0e3036931e14e4aa8eeaddc3b6ef5c9946e452d2d70312e94b161fe564ab'; print([e for e in d.get('entries')or[] if e.get('hash')==h or e.get('index')==918]); print('tip',d.get('length'), (d.get('head')or'')[:16])"
```

If the endpoint reports a different hash for index 918, the history was rewritten and the
timestamped commitment is the evidence. A newer tip head alone is expected growth, not a rewrite.

### What a fresh stamp does and does not prove

A stamp submitted today sits in the calendar servers as a pending attestation until it is
folded into a Bitcoin block, usually within a few hours. Until `ots upgrade` succeeds the
proof is a calendar promise, not a Bitcoin proof. The helix-head commitment published here
has already been upgraded: Host lite-client verify reports Bitcoin block **960660**. Fresh
stamps for a newer head still begin as calendar promises.

## 2. SWHID: an intrinsic identifier for the code state

[SWHID](https://www.softwareheritage.org/software-hash-identifier-swhid/), ISO/IEC
18670:2025, identifies a software artifact by content rather than by location. For git,
`swh:1:rev:<sha>` is the commit object hash, so anyone holding the revision can recompute
it with no registry, no account and no network in the trust path.

The current SWHIDs for the code behind each bake are published in the federation agent
descriptor under `provenance.software_identifiers`:

```bash
curl -sS https://geniusflow-federation.vercel.app/api/agent | python3 -m json.tool
```

This repository has been submitted to Software Heritage for archival. Checked
2026-08-02 against the save request API:

- <https://archive.softwareheritage.org/api/1/origin/save/2407683/>
- `save_request_status`: accepted
- `save_task_status`: **succeeded**
- `visit_status`: full
- `snapshot_swhid`: `swh:1:snp:821f510dc9b5f0db7d265be85287e6046470b91b`

The engine repository is private, so its revisions are not archivable; the identifier is
still intrinsic and still checkable by anyone who receives the revision.