[ PROOFECONOMY ]™GlossaryOriginSpecsZero-Host Architecture (ZeHA)
Zero-Host Architecture (ZeHA) is a way of building software that has no home: one disposable controller holds all of the logic and none of the state, runs anywhere a container runs, and reaches out to the services it needs, such as cloud providers for disposable arenas and a state store the customer owns for every record. There is no SaaS, no vendor host to trust, and nothing is lost when the controller is destroyed.
What it means
Most software lives somewhere. SaaS lives on the vendor’s servers. Installed software lives on your machine. Either way, there is a host, and whoever owns the host owns the data and can change it.
ZeHA has no host. The software is a single controller, the kickstarter. It carries all the logic, keeps none of the state, and can run on a laptop, a build server or a cloud instance. Wherever it runs, it reaches out to the services it needs, does the work, and can be thrown away.
The three rules
- The controller is stateless. It holds the logic, not the data. Destroy it and start another one anywhere, and nothing is lost.
- State belongs to the customer. Users, configuration, runs and results live in a state store the customer owns, such as their own bucket or database. The controller attaches to it; it does not keep a copy.
- Everything else is reached out to, and disposable. Compute, such as a cloud arena on AWS, GCP or Azure, is created for the job and destroyed after it. Work can be split across providers. Credentials are passed in at start or read from the customer’s own secrets manager, held in memory for the run, and never written to disk.
What it is not
| SaaS | Installed software | ZeHA | |
|---|---|---|---|
| Where the logic runs | Vendor’s servers | Your machine | Anywhere, disposable |
| Where the data lives | Vendor’s account | Your machine | Your state store |
| Who can change the records | The vendor | Whoever has the machine | Only you |
| What a lost host costs | Your access | Your data | Nothing |
| Leaves behind | An account and a copy of your data | An install | Nothing |
ZeHA is not serverless either. Serverless code still runs in someone’s account, usually the vendor’s. A ZeHA controller runs where the customer decides and answers to nobody’s account but theirs.
Why it matters for proof
A vendor that hosts the proof about its own product is a Self-Attestation Oxymoron: it runs the test, stores the result and can edit it. ZeHA removes the host. The controller cannot keep or quietly change a result, because it keeps nothing. The records sit in a store the customer controls, which supports structural independence between the party that sells a control and the party that holds the evidence of how it performed.
Where the term comes from
Coined by Craig Thomas Ellrod and Seth in October 2026 while building Proof Controller. Written ZeHA and said as one word, “zeha,” in the tradition of architecture names like RISC.
Example
Proof Controller runs as a Docker container on a MacBook. It holds no database. On start it attaches to the customer’s state store, an S3 bucket encrypted with the customer’s own key. To run a proof, it builds a disposable arena in the customer’s AWS account, runs the campaign, writes the result to the state store, and destroys the arena. The next day the same customer starts the controller on a different machine, attaches the same state store, and every user, campaign and proof is still there.