T27.AI

Blog

Two keys, one verdict: a second lab signed the same t27 run

2026-10-10 · 3 min read

[two keys and two machines under one operator; the 3-of-4 rule exists only in the MVP model] Two t27b labs ran the same t27 commit, a16231329d13, and signed it with different registered Ed25519 keys. The input, verdict and output roots of the two receipts are byte-identical, and t27c corpus-receipt compare judged the pair EQUIVALENT, exit 0. Until today one lab signed every receipt, so in practice it was a chief validator; this is the first real 2-of-2.

Until today every receipt in the t27 network was signed by one lab with one key. Now a second lab, under its own registered key, ran the same commit and signed a receipt whose input, verdict and output roots are byte-identical to the first. t27c judged the pair EQUIVALENT, exit 0. It is the first t27 result that does not rest on a single signer.

What ran

A t27b lab runs the whole spec corpus at one commit and writes a receipt: a hash of every input file (1787), a verdict for every file (1787) and a hash of every output (1276), one root hash over each list, all signed with the lab's Ed25519 key. Both labs ran gHashTag/t27 commit a16231329d13, with the same t27b and t27c builds: both receipts record the same SHA-256 for each.

The compare run

t27c corpus-receipt compare reads two receipts, says for each whether it is signed and whether its leaves are bound to its roots, and then compares totals, inputs, verdicts and outputs. Run on t27b-lab against its own receipt and the one fetched from t27b-lab-2, it printed:

base "a16231329d134aaaf8922cd7b65ef8890084ac77" AUTH_MISSING_NONE AUTHOR leaves-bound true
head "a16231329d134aaaf8922cd7b65ef8890084ac77" AUTH_MISSING_NONE AUTHOR leaves-bound true
totals true inputs true verdicts true outputs true: EQUIVALENT
exit=0

t27c corpus-receipt compare · two labs, two keys, one verdict

Why a second signer matters

The GOLDEN CHAIN white paper (golden-chain-international#140) opens its rules with S1: no chief validators; authority is protocol, not person. A network where one lab signs every receipt has a chief validator, whatever its documents say: if that one key is wrong, lost or dishonest, nobody can tell. A second key that reaches the same roots on its own machine is the smallest step away from that.

The network MVP, specs/network/mvp.t27 (t27#8638), models the next step: a run is admitted only with agreeing receipts from 3 of 4 signers, and a signer whose receipt disagrees is slashed. Until now that agreement existed only in the model. This is the first real one, 2 of 2.

What this does not show

Both labs run under one Railway account and one operator, so this is two keys and two machines, not two operators. Both ran the same t27b and t27c builds, so the agreement shows that the run reproduces on a second machine, not that the tools are right. And the lab-2 receipt carries no challenge nonce, so it shows what was signed, not when.

Next: an outside operator running the same image (contrib/railway/t27b-lab in gHashTag/t27) under their own account, a k-of-n rule checked on real receipts instead of in a model, and a transparency-log (Rekor) anchor for receipt digests, so that a signed receipt cannot be quietly replaced. All three are open in t27#8606.

Work with me

Want this kind of check on your own design?

I audit RTL and build independent, bit-exact models, then take the result through synthesis and, when useful, onto an Artix-7 board. The first conformance module is free.

Discuss your projectSee the verification service