Eformogi
The Record: protocol draft 0.1 (CC BY 4.0; verifier Apache-2.0)

Trust report v0 (draft)

Compiled 2026-09-06 from the live tree-head endpoint, the trust gate in this repository, and the red-team records. Every number below is reproducible from a named source. This is v0: it reports what exists; it does not certify anything.

1. Anchoring history

Source: GET https://eformogi.com/api/tree-heads?all=1 (also /.well-known/tree-heads.json), read 2026-09-06. Anchor commits are in the public anchor repository configured by GITHUB_ANCHOR_REPO (setup in docs/ANCHORED_LEDGER_SETUP.md). Log id eformogi-receipt-log-v1, key did:web:eformogi.com#key-1.

tree_sizesigned at (UTC)root_hash (first 12)anchored (commit, first 10)
02026-07-05 20:36:54e3b0c44298fc (empty tree)b92e0e23bf
412026-07-05 20:52:515cd27ccc12d3fbab1ef174
422026-07-06 12:53:05819710b1d1a7c864b13c7f
432026-07-17 04:30:47c8ad8c5ef7e07e3568ea6b
452026-07-18 04:30:37f46ecb7445cd4bd008a68a
662026-07-21 04:31:14b6edeafe05d107c8181a31
672026-08-20 04:30:495b00ad303a9d03134e7523
682026-09-05 04:30:467d7772555fa3c286e3cb95

Summary: 8 signed tree heads since the key ceremony of 2026-07-05; 8 of 8 anchored externally; 68 leaves covered; the first anchored head was signed over an empty tree, before any receipt was logged. The daily job runs at 04:30 UTC and mints a head only when the tree grew, which is why heads are sparse; head 41 was signed before the anchor token existed and was anchored by the sweep path on a later run (the failure mode recorded in api/cron-tree-head.js). No divergence has been detected by the self-audit to date.

Latest head, in full, for pinning:

{"chain_hash":"24779a0ea237d649a3158c30c0220d6df19585b7a1eb44983d3262c81ad85aa3","key_id":"did:web:eformogi.com#key-1","log_id":"eformogi-receipt-log-v1","root_hash":"7d7772555fa389d2bd4c0192e5a0809b7ae4833e5c5aabeaff8b37bb9dd98354","timestamp":"2026-09-05T04:30:46.946Z","tree_size":68,"version":1,"signature":"z553QftbxQS5qvhGod3Je3Ud9oWjiBy5iovk7tKu8cS6wGjc6JRtT2qS3WVreirFFXhcHh2MzLbXiFWjfa1d63ZXb"}

Not yet anchored anywhere but the operator's database and the git repository: the log has no OpenTimestamps anchor (anchor_ots reserved) and no independent monitor.

2. Trust gate

Source: scripts/test-trust.js, TESTS array; run with npm run test:trust (pre-commit hook and CI).

2026-09-07. The founder ruled on licensing: the specification chapters are CC BY 4.0 (spec/LICENSE), the reference verifier and all 22 vectors are Apache-2.0 (spec/verifier/LICENSE), the name and marks are not licensed (spec/LICENSING.md). Every one of those files is now served from eformogi.com/spec/verifier, so a receiver obtains and runs the standard with no clone and no account. On the same day a live production proof was verified offline against the published verifier:

$ curl -s "https://eformogi.com/api/receipt-proof?id=tr_8e59bb9641e8" > proof.json
$ node spec/verifier/verify-offline.js proof.json
✓ leaf_hash = SHA256(0x00 || leaf_payload)
✓ inclusion proof verifies (leaf 49 of 68)
✓ STH Ed25519 signature verifies (did:web:eformogi.com#key-1)

VERIFIED: tr_8e59bb9641e8 is in the signed receipt log (tree_size 68); check the head against the anchor repository yourself.
exit 0

That run exposed the gap this report should record: the deployed proof carried no family signature, so the offline path proved inclusion while the browser proved inclusion and issuance. api/receipt-proof.js now returns the public half of the family signature, and the verifier checks it along with the did:key derivation of the key id. Against a proof carrying that block the same command prints five checks instead of three and still exits 0. Vectors v21 and v22, frozen from this same live proof, pin both the acceptance and the refusal, and the trust gate runs the whole suite rather than reading the verifier's source.

One thing the verifier deliberately does not do is fail a receipt whose key was established after it was issued. That ordering is common and legitimate: issued_at is when the family sealed the record, so a record sealed before the family had an account and every family's first signed receipt both show a later key. It prints as an advisory note. The kb_ receipt is still not resolved offline; that needs a second proof file and stays planned. kb_ receipts also have no proof to download at all today, because the key-binding log append is best effort (kb_39da937a793a verifies while /api/receipt-proof 404s on it), so the verify page offers the download only for the prefixes that reliably have a leaf.

3. Red-team history

The operator runs an adversarial multi-agent sweep (.claude/skills/red-team-sweep/) with a find, refute, fix-plus-antibody loop. Every confirmed finding ships with a permanent gate test.

sweepdateraisedconfirmednotable classesclosure
1 (immune-system phase 1)2026-08-132111counselor-report IDOR via client-writable metadata; course-row injection onto another family's transcript; forgeable domain credibility on attestations; revocation not purging forwarded copies; API key in query string; webhook SSRF; two denial-of-wallet endpoints; paywall client-side bypass (accepted trade-off)all 10 code findings fixed and merged by 2026-08-14 with antibodies; RLS backstop verified empirically on all 13 family-data tables; sentinels shipped
(the 2026-08-31 full-surface audit was a product audit, not a red-team sweep; it closed 16 findings and is not counted here)
32026-09-022520 (5 refuted)witness capability token leaked in a feed; secrets in query strings repo-wide; public event door reaching the control plane; anonymous attestations moving the dissent gauge; bearer-only plan claim; email-sink escaping; billing guards; institutional-orgs write lockdown; revocation storage purge; dependency vulnerabilitiesall fix PRs merged by 2026-09-03; rulings (course co-signatures require a witness token) and housekeeping (legacy keys hashed at rest, 9 rows migrated) shipped 2026-09-04; root and frontend at 0 production dependency vulnerabilities

Next sweep due on or about 2026-10-02 (shared/redTeamCadence.js, LAST_SWEEP = 2026-09-02).

4. External review

Scoped, not yet commissioned. No external security firm, auditor, or standards body has reviewed this protocol or its implementation. The plan of record sequences an external audit and a bounty after the specification is public and a staging target exists (SECURITY.md). An advisory arrangement exists for a review of the key-custody architecture decision; that is a design review, not a code audit, and it is not counted as external review here.

5. Honesty ledger (what the operator can and cannot do today)

statementtrue
The operator can read every family's vaultfalse for families that completed the key-custody cutover (one at the time of this report); true, with the server KEK, for every other family (their vaults are encrypted at rest)
The operator can sign a receipt under a family's keytrue: family signing keys are escrowed; every verify page says so
The operator can silently rewrite the receipt logdetectable: the log is append-only at the database, self-audited daily, and its heads and leaves are anchored in third-party git history; an offline verifier catches a rewritten proof
The operator can silently swap a family's keydetectable: key establishment is a public kb_ receipt in the log; keys never self-heal
The operator vouches for any witnessfalse: a signer's name, role, and relationship are self-declared and never validated. Witness identity levels 0 to 3 shipped on 2026-09-07 and say only how far the address was checked: 0 email, 1 a verified institutional domain or a recorded license lookup, 2 an identity document an admin checked, 3 established history, derived at read time from five prior co-signatures and never stored
Any receiver accepts the Recordnot claimed; the Record is verifiable, not accepted

6. How to reproduce this report

curl -s "https://eformogi.com/api/tree-heads?all=1"          # section 1
grep -cE "^\s*'test-" scripts/test-trust.js                    # section 2: registered gate tests
npm run test:trust                                              # live gate run
sh spec/verifier/run-vectors.sh                                # the conformance suite

# section 2, the offline check, using nothing from this repository
curl -s https://eformogi.com/spec/verifier/verify-offline.js > verify-offline.js
curl -s "https://eformogi.com/api/receipt-proof?id=tr_8e59bb9641e8" > proof.json
node verify-offline.js proof.json