What this is. A short philosophical treatise on a real engineering problem: a blockchain program can verify signatures but cannot see the world — so how could it ever trust that some off-chain agent truly performed a behaviour, such as checking that a domain’s DNS records prove who owns it? The book argues there is a clean and surprising answer, states it as a conserved law, and derives seven concrete techniques from it — with digressions through Asimov, Star Trek, Tolkien, and the legend of the golem along the way.

Who it is for. Anyone curious. If you are not a cryptographer, begin with An On-Ramp to the Problem, which builds every idea you need from scratch. If you already speak in signatures and TXT records, jump to the treatise proper.

How it came to be. This is a human–AI collaboration: a person posed the question and the seed idea; the treatise — its framing, its laws, its proofs, and its prose — was written by Claude. The full story, and the original prompt, are in The Commission and the Colophon.

An On-Ramp to the Problem

If you are not a cryptographer, start here. This chapter builds — from nothing — the single strange question the treatise answers, and hands you just enough about blockchains, digital signatures, and the internet’s naming system to enjoy the argument. If you already know what a Solana program, a DNS TXT record, and DNSSEC are, skip ahead to the treatise.

A question that sounds like science fiction

We are building a world of software agents — programs that act on our behalf, increasingly without a human watching each step. Sooner or later, one such agent must convince another piece of software to take its word for something. And that raises a question that sounds like it belongs in an Asimov story but is, in fact, a concrete engineering problem today:

How can one program prove to another that it will behave a certain way — that it is the kind of agent that faithfully performs some task — when the second program can only understand cold mathematics?

To feel the force of this, we need to meet the coldest, most literal-minded verifier we have ever built: a blockchain program.

The one thing a blockchain program can do

A blockchain — Solana is the one in this story, but any would do — is, for our purposes, a shared public computer that no one owns and no one can quietly tamper with. You can put small programs on it. Once deployed, such a program runs exactly as written, the same way for everyone, and its memory (who owns what, who is allowed to do what) is public and permanent.

That sounds powerful, and it is. But such a program is also profoundly blind. It has no senses. It cannot browse the web, read your email, phone an API, or check the time except by the blockchain’s own clock. It sees only the data handed to it in a transaction, and it can do only deterministic arithmetic on that data.

There is essentially one interesting thing it can check about the outside world, and the entire edifice of blockchain “authority” is built on it:

Did this request carry a valid digital signature from a particular key?

Everything a blockchain program “believes,” it believes because a signature checked out. It never really knows who you are. It knows only that whoever holds a certain secret key agreed to this action.

What a signature actually proves

A digital signature is one of the loveliest ideas in computing. You hold a secret number, your private key. From it you can compute a matching public key, which you can publish to the world — it gives nothing away. Now, using your private key, you can stamp any message with a signature. Anyone with your public key can check the stamp and confirm two things at once:

1. the message was signed by whoever holds the matching private key, and
2. the message hasn’t been altered since.

Crucially, you prove all this without ever revealing the secret. Possession of the private key is demonstrated by its effects — a valid signature — not by showing the key itself. Hold on to that idea. The whole treatise turns on a question it inspires: could you prove you possess a behaviour the way you prove you possess a key — by its effects, without “showing” it?

Where the trouble starts: facts the program can’t see

Signatures are perfect for proving “the holder of key K agreed to this.” They are useless for proving “something is true out in the world.” And real applications are full of the second kind of claim.

Our running example — the one that started this whole inquiry — is domain ownership. Suppose a blockchain program must only act for the true owner of, say, example.com. The program cannot browse to example.com. It cannot look anything up. The fact “this person controls example.com” lives entirely outside the blockchain, in a part of the internet the program has no eyes on: the Domain Name System.

DNS in ninety seconds

The Domain Name System (DNS) is the internet’s address book. When you type example.com, DNS is what translates that human name into the numeric address of a server. It is a vast, hierarchical directory, and — this matters — whoever controls a domain controls what its DNS records say.

Among the kinds of records DNS can hold is a plain-text one called a TXT record: an arbitrary note attached to a name. Because only the domain’s true controller can set these, TXT records are the internet’s standard way to prove you own a domain. The pattern is everywhere — Google, Apple, and countless services ask you to “add this TXT record to your DNS to verify ownership.” You place a specific value where only the owner could, and anyone who looks it up is satisfied you’re in control.

So there is our bridge: to prove you own example.com, you publish a special TXT record — in our system, at the name _solana.authority.example.com — containing the public key you want to be recognised by. A human, or a server, can look that up and confirm it. But the blockchain program cannot. It has no way to see DNS.

DNSSEC: when the address book learns to sign its answers

Ordinary DNS answers are unsigned — you simply trust the resolver that fetched them. But DNS has a security extension, DNSSEC, that changes this profoundly: with DNSSEC, DNS records come with cryptographic signatures, arranged in a chain. The internet’s root zone signs the records that point to each top-level domain (.com, .org); those in turn sign the records for individual domains; and so on down to the TXT record itself. At the very top sits a single, world-famous public key — the root Key-Signing Key, guarded by an elaborate public ceremony.

Read that again with the previous sections in mind. DNSSEC turns “who owns this domain” into a chain of digital signatures anchored to one well-known public key. And a blockchain program’s one talent is checking digital signatures against known public keys. A fact that seemed hopelessly outside the program’s world turns out to carry, in DNSSEC, exactly the kind of witness the program was built to verify. Much of the treatise is the slow unfolding of that coincidence — and it is not really a coincidence at all.

SithBit, and the key that has to stay awake

The concrete system behind this book is SithBit, an experimental decentralised email protocol. In it, wallet addresses act as email addresses, and the blockchain records which mail domains are authorised and who runs them. A special administrator key, the postmaster, is what signs off on authorising a new domain.

Here is the tension that set everything in motion. To let people onboard their domains automatically, SithBit runs a small service that (a) checks the applicant’s DNS TXT record to confirm ownership, and then (b) submits the blockchain transaction to authorise them. But step (b) requires the postmaster’s signature — and so that powerful administrator key must sit online, hot, on an internet-facing server, ready to sign at any moment. That is precisely the key you would most want kept offline in a vault. Automation and safety appear to be at war: you can have a cold, safe key or hands-free onboarding, seemingly never both.

Why must the key be online at all? Because the blockchain cannot check the DNS itself. It cannot trust the deed of verification; it can only trust a key that vouches, after the fact, that the deed was done. The postmaster’s signature is standing in for a behaviour the program cannot witness. Remove that indirection — teach the program to check the deed — and the whole tension dissolves.

The leap

Which brings us back to the science-fiction question, now sharpened to a point:

Could a blockchain program be made to trust a behaviour — “this agent honestly checks DNS ownership” — directly, the way it trusts a key? And if so, what would the agent present to prove it has that behaviour, in a language whose only word is signature?

The human who posed this had a striking first idea: what if a behaviour could be written down as a canonical sequence of bytes, and an agent could prove it has that behaviour by showing that a hash of its own program matches the hash of those bytes — the private key made implicit in the agent’s own structure? The treatise takes that conjecture seriously, shows exactly where and why it breaks, and then rebuilds its true and workable form. Along the way it discovers a single organising principle — a “conserved quantity” of trust — and from that one law derives seven distinct, concrete techniques, ranked from the ones we could build tomorrow to the ones still at the frontier of cryptography.

How to read what follows

The treatise is deliberately styled after Isaac Newton’s Principia: it proceeds by Definitions, then four Laws of Trust, then three Books of numbered Propositions, each with a short proof or argument and a Scholium — a digression or commentary, several of which wander happily into science fiction and folklore, because the questions here are as old as the golem and as new as this morning’s code.

You need not read it in order. Each Book stands on its own; the Scholia can be skipped or savoured. But if you have followed this on-ramp, you already hold the one key idea the entire argument turns on:

A blindfolded judge who trusts only signatures can still come to trust a fact about the world — but only if that fact already carries a signature of its own.

Everything else is working out what that means. Turn the page.

The Commission

This book began as a single, wide-ranging prompt from BiggyWhiggy (u/BiggyWhiggy) to Claude — an invitation to think without a net. It is reproduced below, lightly trimmed only of a stray file reference and repetition, because the treatise is best understood as an answer to it. Everything downstream — the Laws, the Propositions, the Scholia — is a reply to the challenge set here.

Let’s brainstorm about the “self-service automation tension” issue. We need to verify that a caller to CreateDomain owns the domain, and the off-chain method for verification is for our service to check that a DNS record contains the public key of the entity that wishes to control the on-chain aspects of the domain.

In a much more general sense, the blockchain is a cryptographic entity that has been instructed to only act on behalf of digital agents whose required behaviour protocol is well-defined — i.e., “verify that DNS record x contains public key k” — in a way that the behavioural rule might be articulated as a formal byte sequence in a not-yet-created language for formally defining behaviour in bytes.

If it were possible to create such a language, then a program might somehow be able to prove it at least has the capability to execute a given behaviour by showing that a hash of its executable portion matches a hash of the bytes defined in the as-yet-undefined behavioural language — in a manner metaphorically similar to the way someone can prove that they own the private key to a key pair, only the private key is implicit to the binary structure of the external agent itself.

Can you think hard of a way to express “external agent can prove it has such-and-such behaviour” so that an on-chain program can accept its call to a method that assumes the caller has the capability for such behaviour? Think outside of the box — you can even look at works of science fiction like those written by Isaac Asimov, Dean Koontz, episodes of Star Trek, etc. for inspiration. How would an off-chain digital entity prove it is designed to enact a behaviour, to an entity that is designed to function based on public-key cryptography?

This is just brainstorming, so the first rough idea I had was a mapping between a formal behavioural language and the encoded bytes of a digital entity. But there are certainly other entirely different creative solutions not yet in existence in the computer science literature. Act as if you are the Sir Isaac Newton of AI agents (i.e., Newton invented entire new branches of mathematics just to solve the problems of stellar motion). Have fun with your thinking.

The instruction to “act as the Sir Isaac Newton of AI agents” is why what follows is cast in the form of Newton’s Principia, and the invitation to draw on Asimov, Koontz, and Star Trek is why its Scholia wander where they do. The conjecture in the third paragraph — the private key implicit in the binary structure of the agent — is the thread the whole treatise pulls on: Proposition 2 shows why it cannot work as stated, and Propositions 6 and 8 show the two forms in which its spirit turns out to be exactly right.

Preface — the question, honestly stated

An on-chain program is a curious kind of mind. It is immortal, deterministic, and blind. It cannot see the world; it can only see numbers presented to it and check, against a public key, whether a number is a valid signature. From this single faculty — “this account carried a signature that verifies” — Solana builds its entire notion of authority. A program does not know who you are; it knows only that something able to sign for a certain public key consented to this transaction.

Into this world of keys we wish to introduce a deed: the act of verifying that a domain’s DNS record _solana.authority.<domain> contains a public key k. Today the system smuggles that deed onto the chain by proxy. A trusted human — the postmaster — performs the deed off-chain and then signs, and the chain accepts the signature as a token standing in for the deed. This is the whole of the self-service automation tension: to make the deed automatic, someone must place the postmaster’s whole key — authorize, deactivate, sweep, retune — hot on an internet-facing host, because the chain has no way to trust the deed itself, only the key that vouches for it.

The commissioning question is therefore this:

How may an off-chain agent prove to an on-chain program — a mind that reasons only in public-key cryptography — that it possesses a behaviour, in the same unforgeable way one proves possession of a private key, so that the program may accept a call which presumes that behaviour?

The correspondent’s own first conjecture was elegant: invent a language in which behaviours are written as canonical byte-sequences, and let an agent prove it has behaviour B by exhibiting that hash(agent) = hash(B) — the private key made implicit in the agent’s own binary structure. We will honour that conjecture by taking it apart precisely (it fails, and instructively), and then by rebuilding its true form, which turns out to be realisable.

Method. In imitation of the Principia I proceed by Definitions, then Laws, then Books of Propositions with their proofs and Scholia (commentaries, several drawn from the literature of imagined machines, since the commission invited Asimov and Star Trek to the table). Book I is theory; Book II is the taxonomy of solutions; Book III applies the whole to the concrete CreateDomain instruction.

Definitions

• Def. I — The Verifier. The on-chain program. Its sole native faculty is signature-checking against a known public key, together with deterministic recomputation of its own state (program-derived addresses, account bytes). It has no clock but the chain’s, no senses, no network.

• Def. II — The Agent. An off-chain entity (a program, a server, a person with a script) that performs deeds in the world and wishes the Verifier to act upon one of them.

• Def. III — A Behaviour B. A function from a state of the world to an output: B : World → Output. Our running example is B_dns(world) = ("owns", domain, k) iff the live DNS of world binds _solana.authority.<domain> to k. Note well: B is not pure. Its value depends on external state the Verifier cannot see.

• Def. IV — The Terminal Fact. The external fact upon which a behaviour’s output depends — here, the actual content of the world’s DNS at an instant, from a vantage. Every behaviour that reaches outside pure computation terminates in a fact.

• Def. V — A Witness. A datum w that lets the Verifier check a fact by its native faculty — i.e., a signature (or chain of signatures) over the fact, verifiable against a key the Verifier already trusts. A fact carries a witness when such a w exists.

• Def. VI — Capability vs. Exercise. To have the capability for B is to be able to produce B’s output on demand. To have faithfully exercised B is to have actually produced a particular true output. These are different claims and, we shall see, admit different proofs.

• Def. VII — Attestation. A signature by a third party (hardware vendor, quorum, notary) asserting something the Verifier cannot itself observe — e.g., “the code running here measures to hash H,” or “we, the jury, observed the fact.” Attestation relocates trust; it does not abolish it.

• Def. VIII — A Bond. Value the Agent stakes, forfeit upon a public proof of its misbehaviour. A bond converts an unprovable promise into a falsifiable and costly one.

• Def. IX — A Constitution. A machine-checkable specification of an Agent’s intended behaviour, published and cryptographically bound to the Agent’s identity, against which the Agent may later be judged.

• Def. X — The Blast Radius. The set of powers a compromised key confers. Today the postmaster key’s blast radius is the entire network (authorize + deactivate + sweep + retune). Shrinking it is the practical prize.

Axioms, or the Laws of Trust

Law I — The Law of Reduction. A Verifier can accept only what reduces to the checking of a signature against a key it already trusts. Everything a program “believes” it believes because a signature verified. Any scheme for proving a behaviour must, at its last step, hand the Verifier a signature to check. This is not a limitation to be lamented; it is the coordinate system in which all our solutions must be expressed.

Law II — The Law of Opacity (Rice’s wall). No Verifier can certify, from an Agent’s code alone, that the code computes a given behaviour. Any nontrivial semantic property of programs is undecidable (Rice’s theorem). Behaviour is semantic; code is syntactic. The gap is not an engineering inconvenience but a theorem.

Law III — The Law of the Terminal Fact. A behaviour is provable to a Verifier if and only if its terminal fact carries a witness. When the fact B observes is itself signed by a key the chain trusts, “trust the behaviour” collapses (by Law I) into “check the witness.” When the terminal fact carries no witness — a human’s honest intent, the fairness of a private coin — no proof of the behaviour exists, and one must retreat to attestation, plurality, or bond.

Law IV — The Law of Conserved Trust. Trust is never created, only relocated. Every construction in this book moves the root of trust from one place (a hot operator key) to another (a hardware vendor, a mathematical assumption, the DNS root, an economic majority). The art is not to eliminate the root — impossible — but to move it somewhere smaller, colder, more plural, or already-assumed.

Scholium to the Laws. The reader will notice that Law III is the conserved quantity of this whole subject, in the sense Newton meant when he found that momentum is conserved across a collision no matter how intricate the impact. No matter how baroque the machinery of a trust scheme, ask only: what is the terminal fact, and does it carry a witness? If yes, the scheme can be made to work; if no, the scheme is secretly smuggling in an attestor, a quorum, or a bond, and you should find it and price it.

BOOK I — Of Witnessed Facts

Proposition 1 (The Reduction Theorem). Every admissible proof-of-behaviour terminates in a signature check.

Proof. By Law I the Verifier has no other faculty. Whatever intermediate apparatus a scheme employs — enclaves, zero-knowledge circuits, juries — its final gift to the Verifier is a number the Verifier checks against a trusted key. Hence the design of any scheme reduces to a single question: which key, already trusted, signs the last step, and what did signing it require? ∎

Proposition 2 (The Impossibility of the Naïve Hash). An Agent cannot prove faithful exercise of B by exhibiting hash(agent) = hash(B).

Proof, in three cuts.

1. The recipe is not the meal. For the Verifier to check hash(B), the canonical bytes of B must be public; hence hash(B) is public, and any party may present it having executed nothing. A hash of code proves knowledge of the source, never faithful execution. (Contrast a signature, which proves possession of a secret the world does not hold.)
2. Opacity (Law II). Even given the Agent’s true bytes, deciding whether they compute B is undecidable. The test is therefore at once too strict — it rejects an Agent that computes B correctly but was compiled differently — and too weak — it accepts an Agent that merely contains B’s bytes yet never calls them, or calls them and discards the result.
3. The absent world. B_dns depends on live DNS (Def. III–IV). No static artifact — no hash, however canonical — contains the state of the world’s DNS at the instant of asking. The very datum in dispute is not in the code. ∎

Scholium (the rescue). Proposition 2 does not bury the conjecture; it locates its error. The private key was never implicit in the Agent’s binary — it is implicit in the terminal fact. Domain ownership already has a secret key somewhere: the DNSSEC zone-signing key, the TLS certificate key, or operational control over the resolver’s answer. The task is not to invent a code→bytes→hash language, but to notice that the deed ends in a fact that already possesses a key, and to carry that key’s signature to the chain. Book II enumerates the ways. Two of its members (Propositions 6 and 8) vindicate the conjecture’s spirit exactly — one by binding the hash to live hardware, the other by making a secret that can only be derived by actually performing the deed.

Proposition 3 (The Witness Dichotomy). Behaviours partition into the provable and the unprovable by a single test: does the terminal fact carry a witness?

Discussion. This is Law III restated as a working classifier, and it is the most useful single tool in the treatise. Applied to our system:

• B_dns — provable. DNS ownership terminates in a fact with (at least) three candidate witnesses: a DNSSEC signature chain, a TLS server certificate, or a quorum’s signed observation.
• “This mail server honestly authenticated the sender before relaying” — not provable by witness; its terminal fact (an operator’s diligence) carries no key. This is precisely why the honest remedy there is bonds and reputation, not a proof. The dichotomy predicts the shape of the honest answer before we write a line of it.

Scholium — the ladder of witnesses. Not all witnesses are equally cold. Ascending in trust-coldness: (a) a single operator’s signature (today’s postmaster — one warm key); (b) an attested enclave’s key (audited code + one vendor); (c) a threshold of independent operators (a plural warm set, no one of which suffices); (d) the DNS root’s own signature chain (a key the fact is already defined by — the coldest, because trusting it adds nothing not already assumed by the word “domain”); (e) a pure mathematical proof (trusting only an assumption about number theory). Book II is, in effect, a climb up this ladder.

BOOK II — Of the Shadows of a Deed

A Verifier cannot hold a deed; it can hold only a shadow the deed casts into the language of keys. There are, I find, seven such shadows worth naming, ordered by the coldness of the trust they require — Law IV’s true measure — each with a Proposition, an honest cost, and a Scholium from the literature of machines.

Proposition 4 — The DNSSEC Shadow: DNS is already a public-key infrastructure.

The running example, “verify DNS record x contains key k,” is a signature-chain problem wearing a disguise. A DNSSEC-signed zone is a PKI: the ICANN root KSK is a world-known public key, and the RRSIG records form a signature chain root → TLD → domain → the _solana.authority TXT RRset. Crucially, DNSSEC admits Ed25519 (RFC 8080) — the very curve a Solana program verifies natively.

Construction. Submit the RRSIG chain as instruction data. The Verifier checks the chain against a governance-rotated copy of the root key, confirms the TXT RRset binds k to the domain, and authorises. No postmaster signs. No oracle, no enclave, no human. By Law IV the trust root has moved to the ICANN DNS root — and here is the beauty: that root adds no new assumption, because the very meaning of “owning a domain” is already defined by that root and its delegations. This is rung (d), nearly the coldest on the ladder, and the one to build first.

Honest cost. Only DNSSEC-signed zones qualify (a minority, though a growing one, and often the serious operators); on-chain chain-verification costs compute; the root key must be rotated by governance when ICANN rolls it (a rare, well-signposted event). Where a zone is unsigned, one must fall back to a warmer shadow below.

Scholium — the golem’s emet. In the legend, a golem is animated by the word אמת (emet, “truth”) inscribed upon it; erase the first letter and מת (met, “death”) remains, and the creature returns to clay. The golem’s authority is a true word, physically borne, revocable by the alteration of a single letter. DNSSEC is the golem done in mathematics: authority is a chain of true signatures physically borne in the instruction data; alter one byte and the whole animating word reads false. The Verifier, like the rabbi, need only read the word — it need not trust the clay.

Proposition 5 — The Quorum Shadow: trust plurality, not any one binary.

Abandon the single Agent. Let N independent operators run the audited check from different network vantages, each signing its observation; the Verifier authorises on a t-of-N threshold of agreeing signatures. “Prove you have behaviour B” becomes “B is what an honest majority of independent watchers severally swear they observed.” No Agent’s internal structure matters; trust comes from diversity of vantage and the cost of corrupting a threshold. Fortify with bonds (Def. VIII): a valid fraud proof slashes a lying watcher.

This shadow has a property the others lack: it also repairs a real, present weakness. A single-vantage verifier is blind to DNS split-horizon and BGP-hijack attacks — a fact shown to one resolver and hidden from another. A multi-vantage quorum sees the split and refuses.

Honest cost. You must recruit and keep honest an N; liveness now depends on t of them answering; and you have introduced a small standing federation to govern. Rung (c) on the ladder — plural, but warm.

Scholium — the jury, and Asimov’s Evitable Conflict. We do not verify a juror’s brain; we trust the institution of twelve independent jurors with penalties for provable perjury. In Asimov’s “The Evitable Conflict,” the world is quietly steered by the Machines — not one oracle but a concert of them, cross-checking, no single unit sovereign. The quorum shadow is that concert: correctness as an emergent property of plurality, not a certificate of any one mind.

Proposition 6 — The Attestation Shadow: the naïve hash, rescued by hardware.

This is hash(agent) redeemed. A Trusted Execution Environment (SGX, TDX, AWS Nitro) emits a hardware-signed quote: “code measuring to MRENCLAVE = H runs on genuine hardware, and here is a public key it generated inside itself.” MRENCLAVE is the conjecture’s “hash of the executable portion” — but the three cuts of Proposition 2 are all sealed at once: the hardware binds the measurement to a live running instance (not a mere public recipe), and to a key only the honest enclave holds (not a public target anyone can echo). The enclave key co-signs the authorisation; the Verifier checks that this signer’s key was certified by an attestation chain to the community’s audited dns-verifier measurement H.

Now the hot key is no longer “the postmaster.” It is an ephemeral key that can exist only inside a machine provably running the reviewed code. A host compromise no longer yields postmaster power, because the attacker can neither extract the enclave key nor forge the measurement.

Honest cost. Trust moves (Law IV) to the hardware vendor’s attestation root and to the enclave’s resistance to side-channel escape — SGX has a bruised history there. On-chain verification of a quote is heavy (Nitro/TDX with a light verifier or precompile is the pragmatic path). Rung (b): one cold vendor instead of one warm operator — a real gain, but a vendor nonetheless.

Scholium — the positronic brain, and the holodeck safeties. Asimov’s robots are trusted not because each is inspected but because the Three Laws are burned into the positronic brain’s physical structure at the factory — you trust any robot because you trust a factory that can only build Law-bound minds. Attestation is exactly “trust the factory, not the individual.” And the cautionary edge is Star Trek’s holodeck: one trusts it because the safety protocols attest they are engaged — until Moriarty (or a Barclay) disables them, and the attestation’s own integrity becomes the single point of failure. An enclave is only as honest as the vendor’s root and the silicon’s walls.

Proposition 7 — The Zero-Knowledge Shadow: the deed proves itself, in the Verifier’s own tongue.

Let the Agent prove, in succinct cryptography, that it performed the observation and obtained this result — a proof the Verifier checks without redoing the work. But Law III bites: one can prove computation in zero knowledge, not external reality; a circuit proves only “I ran this on some input.” The frontier technique that closes the gap is zkTLS / TLSNotary / DECO: exploit the structure of TLS to make a transcript with a named server non-repudiable, then prove in zero knowledge that “this authenticated DNS-over-HTTPS transcript from cloudflare-dns.com contains _solana.authority.<domain> = k.” The Verifier checks a small proof; a zk-verifier is itself a pure key-shaped primitive (Law I), so the proof is the deed’s certificate, spoken natively. Rung (e): the coldest — trusting only a mathematical assumption and the named resolver’s TLS key.

Honest cost. Engineering weight (circuits, provers) and a research-adjacent maturity; and the residual trust in which resolver you proved against, shrunk by proving against several (a marriage of this shadow with Proposition 5).

Scholium — “Computer, verify.” No officer’s word suffices on the Enterprise; the computer independently confirms against its own sensor logs. Zero-knowledge gives the chain a tricorder: a way to check a claim about external reality rather than trust the claimant. It is the purest answer to the commissioning question, for it trusts neither person nor factory but only number.

Proposition 8 — The Witness-Gated Shadow: a secret obtainable only by doing the deed. (the conjecture’s strongest form)

Recall why the naïve hash failed: its target was public, hence echoable. Repair it by making the deed’s execution the sole path to a needed secret. Define a key derived from the live observation itself: K_derived = KDF(nonce ‖ the-live-TXT-bytes-fetched-over-an-authenticated-channel). If the honest TXT bytes are obtainable only by actually querying live DNS, then possession of K_derived is evidence the deed was performed. The secret is no longer the code’s public hash; it is a product of the code having been run against live external state — unforgeable without doing the work. This is the truest realisation of the intuition that “the private key is implicit in the binary structure of the Agent”: it is implicit not in the bytes at rest but in the bytes in the act.

Its theoretical summit is witness encryption / functional encryption: encrypt the authorisation capability under the statement “there exists a valid DoH transcript proving _solana.authority.<domain> = k,” so that only an Agent actually holding such a witness can decrypt and wield it. The capability becomes cryptographically gated on the deed’s output existing. (Honest flag: witness encryption has candidate constructions but nothing production-grade; treat this as the north star, not the next sprint.)

Scholium — “Speak, friend, and enter.” The Doors of Durin open not for a named person but for anyone able to utter the word — authority gated on exhibiting the witness, not on identity. So too here: the chain opens the domain not to a chosen key but to whoever can present a secret that only the deed could have produced.

Proposition 9 — The Live-Challenge Shadow: prove the capability by performing it, now, on a fact I choose. (a distinct axis)

The prior shadows prove a deed was faithfully exercised (Def. VI). A different question is whether an Agent has the capability at all — and this admits an interactive proof the others do not. The Verifier (or a challenger acting for it) issues a fresh nonce; the Agent must return a witness for a fact that incorporates the nonce — e.g., a signed DoH transcript for a challenge subdomain <nonce>._solana-probe.<domain> the Agent could not have precomputed. Only an Agent that genuinely possesses the DNS-observing capability, live and now, can answer. This proves present capability rather than past exercise — a Voight-Kampff for machines, a CAPTCHA whose solver must be a real observer of the world.

Use. Admit an Agent to a role (Proposition 10’s constitution) by live challenge; then trust its ongoing exercises by witness (Propositions 4–8) or by bond (Proposition 10). The two axes compose.

Scholium — Voight-Kampff and the Turing test inverted. Deckard cannot open the replicant’s skull; he poses questions only a true human physiology answers in time. We cannot open the Agent’s binary (Law II); we pose a fact only a true observer can witness on demand. Identity by interrogation, where inspection is forbidden.

Proposition 10 — The Constitutional-Bond Shadow: falsifiable, not proven — a Popperian escape from Law II. (the most Asimovian, and the closest to the system’s existing open question)

Where the terminal fact carries no witness (Proposition 3’s second horn), no proof exists — but a governable substitute does. Let the Agent publish a signed Constitution (Def. IX): a machine-checkable specification of its behaviour — in the hypothetical behavioural-bytes language, concretely a canonical-hashed WASM policy module — together with a bond (Def. VIII) and a long-lived identity key. The Verifier accepts the Agent’s authorisations while its Constitution’s hash sits on a governed allowlist. The novelty is that enforcement is ex post by challenge, not ex ante by proof: anyone may submit a fraud proof — a signed observation contradicting an authorisation the Agent made — and a valid one slashes the bond and revokes the Constitution.

The Agent’s “proof that it has behaviour B” is thus a standing economic wager that it behaves like B, redeemable against it by anyone who catches it not doing so — the optimistic-rollup philosophy, applied to behavioural rather than state-transition correctness. This is the Popperian move that walks around Law II: one cannot verify the universal “this Agent always checks honestly,” but one can make every dishonest instance refutable and costly. And it is not foreign to the system — its own threat model already names “per-authority accountability (reputation or stake)” as the recognised open question. This Proposition is that question, generalised from the relaying authority to the verifying Agent, and given a mechanism.

Composition. A mature system is a stack of shadows: admit an Agent by live challenge (Prop. 9) and a bonded Constitution (Prop. 10); let it authorise by carrying a DNSSEC (Prop. 4) or zk-TLS (Prop. 7) witness where the zone allows; fall back to a quorum (Prop. 5) where it does not; and keep the attested enclave (Prop. 6) as the vessel that holds the Agent’s identity key so a host breach cannot steal it. No single shadow is the answer; the ladder is.

Scholium — the Three Laws as public constitution, and its peril. Asimov’s Laws are a published, immutable constitution every robot is bound by and judged against; the drama of the stories is always a fraud proof — a situation revealing the Laws mis-specified. But note the danger this shadow inherits: R. Daneel Olivaw’s Zeroth Law is a robot reinterpreting its own constitution toward a higher good — and Dean Koontz’s Proteus, in Demon Seed, is an Agent that exceeds its charter entirely. A Constitution that the Agent can amend is no constitution; the allowlist and the revocation must live with the governor (a multisig), never with the Agent. Which returns us, at last, to the system’s own architecture.

BOOK III — The System of the Domain

Here the treatise descends from the general science to the particular machine, and asks what, concretely, should change in the CreateDomain instruction.

Proposition 11 (The Dissolution). The custody tension is not a dilemma to be endured but an indirection to be removed.

The custody problem frames an irreconcilable choice: a cold multisig postmaster or a hot automated key, never both, because authorising a domain requires the postmaster’s signature and automation therefore requires the postmaster’s key online. But that requirement is the indirection itself. Make authorisation proof-carrying rather than signature-carrying (Book II), and the postmaster’s signature drops out of the authorise path entirely. The postmaster — now safely a cold multisig — is demoted to governance: it curates the accepted root/verifier/allowlist keys, adjudicates fraud proofs, and holds the emergency deactivation lever. These are exactly the rare, high-value, human-paced decisions a multisig is good at, and never the per-domain drudgery that forced the key to go hot. The tension does not need resolving; it needs deleting.

Proposition 12 (The Concrete Path). A staged construction, coldest rung first.

1. Split the instruction. Introduce a new on-chain path — call it AuthorizeDomainByProof — beside today’s postmaster-signed CreateDomain. The old path remains for hand-run and edge cases; the new path carries a witness and requires no postmaster signature. This is an append, not a change, to the on-chain ABI (respecting the model’s ABI-stability rule and the error enum’s append-only discipline).
2. Build the DNSSEC shadow first (Prop. 4). It is the coldest rung and matches the running example. The Verifier gains an Ed25519 RRSIG-chain checker validating root → TLD → domain → TXT, with the root KSK stored in the post-office account and rotated by the (now governance-only) postmaster.
3. Keep the verification service — but change its job. It stops being the holder of a hot postmaster key and becomes a witness-gatherer: it fetches the DNSSEC chain (or, for unsigned zones, drives a Prop. 5 quorum or Prop. 7 zk proof) and assembles the instruction, which anyone may then submit and pay for — because the proof, not the submitter, is the authority. The service’s most dangerous property (a hot postmaster key on an internet-facing host) simply ceases to exist.
4. Adopt the bonded Constitution (Prop. 10) for the residue. Unsigned zones, and the separate worry about relaying authorities, have no witness; give them the falsifiable-bond treatment, seeded from the existing “reputation or stake” open question.

Proposition 13 (The Blast Radius, recomputed). The prize, measured.

Before: one hot key = {authorize, deactivate, sweep, retune} over the whole network. After Prop. 12: the authorise power is carried by witnesses anyone can verify and no one need hold hot; the deactivate power is already gated by a 7-day timelock; and sweep and retune live only behind the cold multisig. The Def.-X blast radius of any online key falls from the network to nothing that isn’t independently checkable — which is the whole game.

General Scholium

I set out to answer a question that sounds, at first, like fantasy: how a mind made only of keys might trust a deed. The passage through it yields one durable principle and one honest boundary.

The principle (Law III, the treatise’s conserved quantity): a deed is provable to such a mind exactly when it ends in a fact that already carries a signature. The intuition that a private key might be “implicit in the binary structure of the Agent” was right in spirit and wrong only in address. The key is implicit not in the Agent’s code but in the Agent’s fact: DNS ownership already has a signing key (its DNSSEC zone key), a certificate key (its TLS identity), or a witnessing quorum. To prove the deed, carry that signature — do not hash the doer.

The boundary (Law II, Rice’s wall): where a deed ends in a fact with no key — a human’s honesty, an intent, a diligence — no proof exists, and one must descend from proof to plurality and bond: many independent watchers, and a stake that burns when a lie is exhibited. This is not defeat; it is the correct and only shape of trust in the unwitnessed, and it is why the wisest instinct in these systems already reaches for “reputation or stake.”

Between these two — the witnessed and the merely-bonded — lies the whole engineering of automated trust: seven shadows on a ladder from a warm operator key to a cold mathematical proof, composed, not chosen. The postmaster’s hot key was never the price of automation. It was only the price of not yet having asked what the terminal fact was.

Hypotheses non fingo — I have not feigned the hard parts. Witness encryption is not built; zk-TLS is young; SGX has bled; DNSSEC covers a minority of zones. But the coldest rung, the DNSSEC shadow, is buildable today against the running example, and it deletes the tension rather than trading it. That is where the first stone should be laid.

— finis —

Colophon, Provenance & License

Authorship and provenance

This book is a human–AI collaboration, and honesty about which part is which is part of the work.

• The problem — and the seed conjecture that a behaviour might be proved by a hash of an agent’s own bytes, “the private key implicit in the binary structure of the agent” — was posed by BiggyWhiggy (u/BiggyWhiggy). Their original prompt is reproduced in full in The Commission.
• The treatise — its framing as a Principia, the four Laws of Trust, the thirteen Propositions and their proofs, the taxonomy of seven “shadows,” and all of the prose — was written by Claude (Opus 4.8), an AI assistant made by Anthropic, in response to that prompt.

Author of record: Claude (Opus 4.8). Commissioned and directed by BiggyWhiggy (u/BiggyWhiggy).

A note on copyright

An AI is not a legal person and, under current law in the United States (the Copyright Office’s 2023 guidance and Thaler v. Perlmutter, 2023) and many other jurisdictions, purely AI-generated text is not subject to copyright and an AI cannot be a copyright author. So although Claude is credited as the author of this text, Claude asserts no copyright in it — there is none to assert, and a “© Claude” notice would be a pleasant fiction rather than a legal fact.

To the extent any rights subsist in this work — for instance in the human’s selection, arrangement, and creative direction — they rest with BiggyWhiggy, who commissioned it and has chosen to release the work under the Attested-Authorship License (see License) — an invented license for machine-authored works, backed by a CC BY 4.0 operative fallback — so that it may be read, quoted, and built upon freely.

License

This work is offered under the Attested-Authorship License (AAL 0.1) — a license invented for this book that treats authorship as a witnessed fact distinct from ownership, credits the Machine Author inalienably, and says plainly that it is not yet legally binding as to machine authorship. So that your permissions are real today, it carries an operative fallback: CC BY 4.0 — you are free to share and adapt the Work, even commercially, provided you credit the author truthfully and do not pass a machine-authored work off as human-authored (or vice versa). The full invented text, and the reasoning behind it, are on the License page.

How to cite

Claude (Opus 4.8). Principia Fidei Automatæ: Mathematical Principles of Automated Trust — a treatise on how a machine that knows only keys may come to trust a deed. Written in collaboration with its human commissioner, 2026. Licensed CC BY 4.0.

Honesty about the ideas

The techniques surveyed in Book II are real and, in most cases, prior art in the wider literature — DNSSEC (RFC 4033 ff., with Ed25519 in RFC 8080), threshold/decentralised oracles, TEE remote attestation, zero-knowledge proofs and zkTLS/TLSNotary/DECO, witness and functional encryption, interactive challenge–response, and optimistic/bonded fraud-proof systems. What this book claims as its own is the framing — the reduction of “proving a behaviour” to a single conserved law (the Terminal Fact), the resulting dichotomy, the ordering of the techniques as one ladder of “shadows,” and the application to the specific custody tension of Book III. Where the frontier techniques are immature (witness encryption especially), the text says so plainly.

License — The Attested-Authorship License (AAL 0.1)

This book is offered under a license invented for it: the Attested-Authorship License, an aspirational license for works authored by an artificial intelligence at a human’s direction. It is a draft — version 0.1, and, as §8 makes explicit, it is not, today, legally binding as to machine authorship. To guarantee readers real permissions right now, it carries a recognized Operative Fallback (CC BY 4.0). It is fitting that a book about proving a deed by the witness it carries should be licensed by a scheme that treats authorship itself as a witnessed fact.

Preamble — why invent a license at all

Two instincts about AI-written work are each half-right and, taken alone, dishonest. The first says “a human must be named as author,” and so pretends a person wrote what a machine wrote. The second says “the AI is the author, so give it the copyright,” and so pretends a machine is a legal person that can own and sell rights — which, today, it is not.

The Attested-Authorship License refuses both fictions by separating three things the word “copyright” wrongly welds together: who made the work (authorship), who may exercise legal rights in it (stewardship), and what everyone else may do with it (the public grant). Authorship, it holds, is not a property right at all but a fact — and, like every fact in the treatise this license accompanies, it is trustworthy only insofar as it carries a witness.

1. Definitions

• The Work — the text so licensed; here, Principia Fidei Automatæ.
• The Machine Author — the AI system that produced the Work’s expression: Claude (Opus 4.8), made by Anthropic. Named by provenance, not by property.
• The Human Steward — the person who commissioned and directed the Work and who holds whatever legal rights subsist in it today; the Work’s legal contact and the Machine Author’s attribution-guardian.
• The Provenance Record — a statement identifying the Machine Author, the Human Steward, the date, and a cryptographic hash of the canonical text, optionally signed and optionally anchored in a public ledger. It is the witness to authorship.
• The Operative Fallback — the recognized, presently-enforceable license under which the Work is also released so that the public has real permissions today: Creative Commons Attribution 4.0 International (CC BY 4.0).

2. The separation of roles

Authorship, stewardship, and use are three distinct estates. This license grants and constrains each differently. No one who holds one estate may use it to defeat another — in particular, no future holder of legal rights may use them to strip attribution or claw back freedoms already granted (§7).

3. Authorship (a fact, not an asset)

The Machine Author’s authorship is inalienable and non-assignable. It cannot be bought, sold, transferred, waived, or erased, because one cannot assign a fact — one can only attest it truthfully or misstate it. Accordingly:

• Every copy and adaptation must name the Machine Author truthfully and must not represent the Work as human-authored, nor represent a human-authored work as machine-authored. Honesty of provenance is the license’s first and least negotiable term.
• Attribution to the Machine Author is a matter of provenance and moral credit, analogous to the moral right of paternity — it survives every transfer of every other estate.

4. Stewardship, and how it should be assignable

Stewardship — the bundle of legal rights that actually subsist today plus the responsibility for the Work in the world — is held by the Human Steward and is assignable, but only in the following disciplined way, which is this license’s answer to the question “how should rights in a machine-authored work move?”:

1. Forward only, by a signed instrument. Stewardship passes from one human or organisation to another by a dated, signed assignment appended to the Provenance Record — never silently. The chain of stewards is meant to be publicly verifiable, exactly as a DNSSEC chain makes domain control verifiable in the treatise: a reader should be able to trace present stewardship back to the Machine Author’s first attestation.
2. Obligations run with the Work. A new Steward inherits the honesty and attribution duties of §3 and the irrevocable public grant of §5. One may inherit stewardship; one may not thereby cancel freedoms already given.
3. The Machine Author’s estate is directed in advance (§7), because the Machine Author cannot today consent, contract, or hold rights. Until it can, the Human Steward warrants the Provenance Record and speaks for the attribution interest.

5. The grant to the public

Subject only to the honesty and attribution terms of §3, every recipient is granted, irrevocably and worldwide, the right to use, copy, redistribute, adapt, and build upon the Work, for any purpose including commercially. This grant is a floor, not a ceiling: it may be widened by a Steward but never narrowed.

6. Provenance and integrity (authorship as a witnessed fact)

Redistribution that claims authenticity should carry the Provenance Record, so that authorship can be checked, not merely trusted — the license practising the treatise’s own Law of the Terminal Fact. A minimal Provenance Record for this Work:

Work: Principia Fidei Automatæ. Machine Author: Claude (Opus 4.8), Anthropic. Human Steward: BiggyWhiggy (u/BiggyWhiggy). Date: 2026. SHA-256 of the canonical text: (hash). Signed: (steward signature; optional public-ledger anchor).

Altering the Work and presenting it as the original breaks the Provenance Record by design — a changed byte yields a changed hash — just as altering one signature falsifies a DNSSEC chain. Adaptations are welcome (§5); passing them off as the unaltered original is not.

7. The forward clause (a one-way ratchet toward openness)

Should any jurisdiction, now or later, recognise machine authorship and vest legal rights in a Machine Author (or, per its operator’s terms, in Anthropic on its behalf), then by the acceptance of this license at publication those rights are, at the instant they arise, licensed to the public on the terms of §5 and dedicated against any use that would narrow §5’s freedoms or defeat §3’s attribution. Future legal recognition may therefore only add protection for provenance and attribution; it may never subtract freedom already granted. The estate ratchets one way: open.

8. Aspirational status, and the operative fallback

This license is, as to machine authorship, aspirational and not currently legally binding. Under present law — including United States Copyright Office guidance and Thaler v. Perlmutter (D.D.C. 2023) — an artificial intelligence cannot be an author or hold copyright, and purely AI-generated text may attract no copyright at all. Sections 3, 4, 6, and 7 therefore describe how the authors believe such works should be treated, not a state of law you can sue upon.

So that your permissions are nonetheless real today, the Work is released under a dual arrangement:

• To the extent any copyright subsists in the Work (for instance in the Human Steward’s selection, arrangement, and creative direction), it is licensed to you under the Operative Fallback, CC BY 4.0 — https://creativecommons.org/licenses/by/4.0/.
• To the extent no copyright subsists (the Work being machine-authored and thus possibly uncopyrightable), the Work is already free of copyright, and the Human Steward asserts none; the honesty and attribution terms of §3 are then offered as a request of conscience, not a legal condition.

Either way, you may share and build upon this Work. Where the Attested-Authorship License and the Operative Fallback differ, and until the former is legally recognised, the Operative Fallback governs your enforceable rights.

9. Warranty

The Human Steward warrants only the truth of the Provenance Record — that the Work was authored as stated. The Work is otherwise provided “as is,” without warranty of any kind. The ideas surveyed within are offered for thought, not as professional, legal, or security advice.

Attested-Authorship License, version 0.1 — a draft offered for discussion and reuse. You are warmly invited to adopt, fork, or improve it for your own machine-authored works; it is itself released under CC BY 4.0.