Astrea grew out of the hardest problems blockchains have, but the machine underneath is bigger than any chain. It is a proof manifold, one space where compute, confidentiality, and trust collapse into verifiable proofs, packaged as an operating system for verification. Its first deployment is the bridge: private economies, settled in ZEC. Anywhere a computer changes state that later matters, the same machine can record the change together with a proof that it followed the rules: in a public network, in one institution’s installation, or on a chip inside a device.
01 · the bigger machine
A universal signaling system
Astrea begins with a larger idea: every computation should be able to produce evidence that it was performed correctly. Its first deployment applies that idea to private financial activity reaching programmable markets, with ZEC as the money at rest. Underneath is a general machine. A signal is a typed state-change plus the proof that it followed its declared rules, published into one replayable history. A ledger is one application of that machine. So is a hospital’s access journal, a factory’s quality gate, and a city’s traffic controller.
This is why calling Astrea a blockchain stopped making sense. There is no chain of blocks at the center — validators weave concurrent proposals into a graph, a deterministic rule reads one history out of that graph, and every accepted action carries its receipt. The block was never the point; the proof was. Astrea turns software-defined systems into proof-defined ones: instead of a database that says a fact was recorded, you get a history that shows every change was allowed. That is the next generation of computing on trust, and it is what “verification operating system” and “proof manifold” mean when this site uses them.
ZEC is the first coin the bridge carries; the machine underneath does not depend on any one coin. Resource metering is native and the tariff is a policy choice, fees, quotas, sponsorship, or a bounded zero-price profile, so a civic deployment can run its infrastructure on proofs without pretending every action is a trade. And because the mathematics was shaped for silicon from the start, the same machine scales down as well as out. Section 08 follows it into dedicated chips.
A NOTE ON “BLOCKCHAIN”
This guide calls Astrea a blockchain wherever the familiar word helps; read it as shorthand. Technically the design has left the category. There is no chain of blocks inside, and agreement comes from checking proofs rather than re-running work. A computer scientist grading on the internals would need a different name, and we use two: the proof manifold at the core, and the operating rules and subsystems around it that make the whole a verification operating system. The whole system runs on verification, and no layer of it runs on trust.
ONE SUBSTRATE, MANY HOUSINGS
a blockchain is one configuration
The same core runs the bridge as a public network, a dedicated deployment, or an embedded device. A blockchain-shaped network is one configuration of the manifold, not its definition.
02 · where it matters
Proof-backed records change high-stakes industries
Astrea can support a shared public network or a dedicated installation for one industry, institution, or regulated group. The payoff is concrete: participants can independently check the consistency, authorization, order, versions, custody, and registered computation in the accepted history. Who governs that history depends on who operates and controls the validators.
THE PRACTICAL TEST
If a record may later face a regulator, court, customer, insurer, or incident review, a proof-backed history lets reviewers independently check the consistency, authorization, and accepted order of its recorded events. The validator structure determines who governs that history.
Healthcare
Private records with a checkable registered-access trail
Keep medical content encrypted while recording each protocol-mediated authorization, access grant, record version, and resulting receipt in authenticated state.
encrypted record → access grant → registered journal → verified entry
Patients, hospitals, and regulators can check the registered route without placing the medical file in public consensus. Endpoint controls cover copies or decryptions made outside that route.
Finance & banking
Approvals, trades, and settlement in one checkable sequence
For Astrea-native settlement, bind the authorization policy, ordered action, private journal entry, and settlement receipt. When a bank or venue settles externally, import its named receipt or attestation.
approval rule → ordered action → settlement or imported receipt
Institutions and auditors can reduce reconciliation work by checking who approved what, which version applied, and which result Astrea accepted.
Pharma & cold chain
One custody record from plant to patient
Join batch manifests, authorized handoffs, submitted temperature evidence, exception records, and delivery receipts under named versions and sources.
A recall can narrow affected batches faster because the accepted custody path identifies exactly where an outside sensor or operator supplied each fact.
Aviation & manufacturing
Parts, maintenance, and quality gates stay attached
Give a component a versioned history of provenance, maintenance actions, certified software, inspections, and registered pass-or-fail checks.
part identity → service action → quality check → signed receipt
Operators can trace the exact accepted configuration and evidence behind a release decision after the part moves between organizations.
Energy & critical infrastructure
Authorized control commands with durable incident evidence
Connect role-gated operator commands, controller versions, canonical time facts, submitted signed inputs, and registered execution results without forcing raw operational data into consensus.
authorized operator → certified version → accepted command → incident record
An investigation can reconstruct which approved rule governed the recorded command even after a provider changes. Device or operator evidence establishes what physically happened.
Traffic & civic systems
Public infrastructure that can explain its decisions
Use submitted signed sensor evidence, certified controller programs, schedules, messages, and versioned incident documents as parts of one coordinated application.
named input → canonical clock → authorized command → public audit
Cities can review the accepted program, input, timing, and recorded command after a malfunction. Physical actuation remains tied to device or operator evidence.
AI & model governance
Named models, datasets, policies, and registered-workload receipts
A registered PixelVM workload can bind model and dataset digests to a policy version, then produce a receipt for the declared computation.
named digests → registered workload → policy → checked receipt
A customer can check the named artifacts and rules for that workload. Dataset provenance comes from the manifest's source path; external or black-box inference needs its own evidence.
Courts, evidence & media
Authenticity claims with an explicit chain of custody
Start with an attested capture or named source, bind the media through a manifest, and record each authorized handoff, version, and disclosure.
The record shows what evidence entered Astrea and which handoffs were recorded; the source attestation remains visible instead of hiding behind a generic “verified” badge.
Supply chain & logistics
Custody that survives every provider handoff
Bind product and batch manifests, authorized custody transfers, imported carrier receipts, and submitted condition evidence to named versions.
Recall scoping and provider replacement get faster because the accepted custody history travels with the shipment. Physical condition remains source-attested.
External evidence boundary
Astrea makes the accepted evidence, policy, order, and state transition checkable. A camera, sensor, laboratory, bank, agency, or attestation system still supplies facts about the outside world. That boundary is explicit, so every deployment knows where to attach its source controls and what the Astrea receipt does—and does not—establish.
03 · protocol building blocks
A signal carries enough context to be checked
An Astrea signal is a typed request, state change, checkpoint, or receipt. Its identity, authorization, version, and relationship to shared state are explicit, so another participant can tell what the network accepted.
signal
A compact statement with a declared meaning: transfer this value, publish this document version, deliver this encrypted message, run this registered computation, or record this service result. The type determines which checks and evidence apply.
01
Payments and receipts
Authenticated balances, transfers, authorization rules, and receipts use the same ordered state foundation as the rest of an application. A payment can authorize later work without turning the payment system into the service itself.
02
Private messages
An encrypted body lives under an authenticated manifest, a compact record that binds its content and layout. The header, mailbox placement, replay rules, retention policy, and mutation order remain checkable while fanout and push delivery stay outside consensus.
03
Versioned documents and journals
Named versions, document headers, patch journals, and manifests bind structured records and attachments to an authenticated root. Replicas and indexes can help readers without replacing that root.
04
Authenticated reads and imported roots
A client can check a bounded answer against a certified snapshot. State from another system enters through a named importer, attestation, or proof path. Its imported root, a compact fingerprint of that state, preserves the boundary. The bridge is the first user of this path: Zcash's chain is proved in, headers, work, anchor, and deposit note, and Ethereum's state arrives through a proof of the beacon chain's finalized checkpoint and the Merkle Patricia path beneath it.
05
Schedules and subscriptions
Canonical time facts, due-work records, authorization, and completion evidence support recurring or delayed work. A scheduler observes due state and proposes an ordinary candidate; it does not acquire special authority.
06
Coordinated services
Offers, requests, receipts, and checkpoints let storage, delivery, query, proving, and application services coordinate without making one operator the hidden source of truth.
07
Resource budgets
Storage, retention, bandwidth, query work, and proving receive explicit bounds. Payment is a separate policy layer, so fees, quotas, sponsorship, subscriptions, and operator funding can use the same meters.
PROOF-BACKED APPLICATION FLOW
intent · authority · proof · services
Consensus supplies the shared order. PixelVM supplies a proof path when registered computation is part of the action. Versioned state anchors the result, and replaceable services return proofs, receipts, or explicit freshness labels to the application.
04 · split authority from convenience
The shared facts survive service replacement
Astrea keeps the authoritative plane compact. Search engines, delivery networks, replicas, schedulers, provers, and archives can specialize around it without quietly creating another ledger.
Authoritative plane
Small facts that everyone must share
Consensus orders accepted actions, versions, roots, authorizations, ownership changes, schedule state, and other facts that require one network-wide answer.
Service plane
Rich work tied back to certified state
Search, ranking, notifications, message fanout, analytics, archive repair, query planning, and scheduling can use different operators and machines. Registered bounded reads can return proof evidence. Derived search and ranking expose a checkpoint, a freshness watermark that says how far the view has caught up, or a clear convenience-only label.
Replacement test
If an indexer or delivery provider disappears, the accepted root, version, authorization, and receipt remain. A replacement service reconstructs its view from the journal and certified state. If the authoritative root changes, every service must follow the new certified history.
COORDINATED SERVICE MAP
one root · many replaceable services
The certified root is the shared anchor. Services can fan out, return proof-backed answers or explicit watermarks, and be replaced without becoming a second source of truth.
THE LIBRARY MODEL
A catalogue helps you find a book while the book remains the authoritative text. Astrea gives specialized services the same relationship to certified state: useful, replaceable, and checkable wherever the registered read path supplies a proof.
05 · end-to-end application paths
Writes become state; services turn state into experience
The same pattern carries a private message, a document revision, and scheduled work. Canonical state—the protocol-defined version everyone follows—records what must be shared. Specialized services move bodies, build views, or wake work, then clients return to the authoritative root for the checks that matter.
The document path anchors point reads in a versioned Authenticated Sparse Tree (AST). A client can prove that one key is present or absent at a named version; derived search keeps a separate freshness boundary.
THREE APPLICATION LIFECYCLES
canonical state · replaceable service · checked result
Message delivery can retry and duplicate network packets; consume-once behavior belongs to canonical mailbox state. Derived document search carries a checkpoint or watermark, while registered point reads can return inclusion or absence evidence. A scheduler only proposes work that passes ordinary admission and consensus rules.
PAYMENT + COMMUNICATION
A transfer can carry its own follow-up
A balance mutation and receipt become authoritative state. The same accepted action can append a receipt to a private journal and authorize a delivery request. Losing the notification provider does not lose the transfer or its receipt.
The sender commits an encrypted body through a manifest and creates canonical message state. Fanout providers move availability notices. The recipient checks a mailbox read against the declared snapshot instead of trusting the push packet as authority.
encrypted body → manifest → mailbox state → proof-backed read
DOCUMENT + QUERY
A workspace keeps every revision named
A revision advances the document version, appends a patch journal entry, and binds its body through a manifest. Replicas serve the bytes. Registered point reads can prove inclusion or absence; richer search identifies the checkpoint or watermark behind its view.
revision → journal → AST root → proof or watermark
IMPORTED STATE + SCHEDULE
A service can react to state from another system
A named proof or attestation path admits an external root. A subscription can reference that root and a canonical due record. The scheduler proposes the registered action, and ordinary validation decides whether it enters Astrea's history.
import path → root → due record → ordinary candidate
06 · connect to the outside world
Every outside claim keeps its evidence path
Astrea can coordinate software around an email receipt, an HTTP response, a sensor report, a delivery notice, or a root from another network. The record names who or what supplied the evidence and which verification rule applied.
A claim about an email, HTTP action, sensor reading, or delivery also needs evidence from outside the protocol. A source might be an identified operator, a threshold of independent reporters, an attested device, a signed receipt from the external system, or an application-specific proof. Astrea authenticates and orders the submitted object. The source remains responsible for what the object says about the outside world.
EXTERNAL EVIDENCE PATH
source attestation · protocol acceptance
The source attests to the event. Astrea's receipt shows that the typed object passed its registered checks and entered the authoritative history. Ordering the evidence does not turn the protocol into a witness to the physical event.
SOURCE STATEMENT
“This outside event occurred.”
The operator, reporter set, device, external network, or application-specific proof path supports this part of the claim.
ASTREA STATEMENT
“This evidence object was accepted.”
The protocol receipt ties the object to its source, type, checks, position in history, and resulting authenticated state. The event or action described by that object requires its own evidence from outside the protocol.
07 · meter work explicitly
Measure the work before choosing who pays
Astrea treats resource accounting and funding as separate decisions. The action declares its bounds. The deployment chooses a funding policy: fees, quotas, sponsorship, operator funding, subscriptions, or a bounded zero-price profile.
This separation lets a consumer application hide infrastructure billing from the user, lets an organization allocate quotas, and lets an open service charge per action. Every version still has admission rules and abuse controls.
stored bytes and retention
network bytes and lane budget
execution and proof packets
query work and answer bounds
history and archive duty
RESOURCE ADMISSION
measurement and funding remain separate
A zero-price profile still has a finite budget. It changes the funding path, not the amount of storage, bandwidth, proving, query work, or retained history that the system admits.
08 · into silicon
Designed for chips from the math up
Long executions, proof jobs, and data stores are shaped as deterministic streams of bounded work. That is not an implementation detail — it is a decision made at the level of the mathematics, and it is what lets the same pipeline run on server cores today and move into dedicated silicon.
PIXELVM PROOF STREAM
Proof pieces keep one canonical statement
Scheduled execution produces structured traces. CHARK, PixelVM's transparent proof architecture, turns bounded trace work into proof chunks. CHASM, its streaming accumulator, binds those chunks into one ordered stream. NeoFold combines neighboring intervals; NeoFold/UM-QFNA compresses the final package into the verifier-facing receipt.
VERSIONED DATA STREAM
Storage changes shape without changing meaning
An append-only journal feeds in-memory state and immutable sorted runs. Background compaction reorganizes local bytes, while the named version and authenticated sparse-tree root preserve the public meaning of the data.
The proving pipeline is deliberately regular: hashing, small-field arithmetic, and fixed folding and accumulation steps over bounded chunks. Proof generation behaves like a streaming data pipeline rather than exotic cryptography, and streaming pipelines are exactly what purpose-built chips do best.
FROM PIPELINE TO PROOF COPROCESSOR
the math was shaped for silicon
Because proving is regular streaming work, the pipeline that runs on cores and accelerators maps onto a dedicated proof coprocessor. A device that carries one signs its state-changes with proofs and anchors them into the shared history.
The future we are building
Astrea · what comes next
That is the endpoint of the verification operating system: a proof coprocessor — a CHARK chip — inside a router, a camera, a factory gateway, or a satellite. A device that carries one does not just keep a log; it emits signals: state-changes with proofs that they followed the device’s declared policy, anchored into the same replayable history every other signal shares. The signal a chip emits and the signal a validator orders are the same object — one substrate from silicon to consensus. What a chip cannot do is make a bad sensor honest: it proves the state-change followed the attested rule from the attested path, and names the source that vouched for the outside world.
Carry that into the devices and the claims get concrete. A camera whose chip proves its footage: this frame, from this attested sensor, at this moment, untouched since capture. A messaging gateway that proves a message reached the mailbox of exactly the person it was addressed to, and nobody else’s. A router that proves, to cryptographic certainty, that it enforced its declared anonymity policy on every packet it moved — the mixing, the padding, the rotation, all of it receipted rather than promised. A satellite or a factory gateway that proves it is still running the software it attested, so a compromise announces itself as the one thing an intruder cannot forge: the missing proof.
And there is a further step, the one our custom in-house mathematical framework was built for. The same framework that makes Astrea’s primitives computable shows that a program can be encrypted and scrambled so that it still runs — an outside observer watches it execute, correctly and on time — while, to a stated cryptographic certainty, the logic inside cannot be read back out. The literature calls the full-strength version of this indistinguishability obfuscation, iO; what our framework shows is possible is a loose form of it (in the lab we call it QQ-iO, quantifiable quasi-iO; it builds on the published quasi-linear iO line of Ma, Dai, and Shi, on foundations laid by Jain and Jin). That is a statement about the future: we believe this is where the technology goes — programs shipped, hosted, even burned into someone else’s silicon, without ever becoming legible to the machine that runs them. To our knowledge, nobody else knows how to build this today. We believe we do.
The future is closer than it sounds: loose iO already runs, today, as a working demo in our lab. For scale, the strongest privacy technology any chain currently advertises is FHE, fully homomorphic encryption: a machine computes on data it cannot read. That is a real guarantee, and a narrower one. FHE hides the data while the program sits in the open; loose iO is provably the stronger class, because it seals the logic itself. Fold it into the rest of the manifold, zero-knowledge receipts underneath and PRISM’s metadata defense around it, and you get what we are comfortable calling the ultimate system: hidden data, hidden logic, hidden traffic, and a proof that every step followed the rules. The numbers hold up too. In our lab tests, loose iO with zk proofs runs faster than the public FHE systems we measured against once the comparison is fair — proof for proof. Raw TFHE alone is quicker; the lead flips the moment the encrypted run must also prove itself correct, which in a verification operating system it always must. And our demo outruns the nearest public ancestor of working iO — Machina iO’s first hello-world execution — at a higher post-quantum security rating.
The commercial and military implications of the finished form have no ceiling worth naming. A drone that falls into the wrong hands carries software that can be run but not read — capture stops meaning compromise. A trading firm’s strategy keeps its logic sealed even on hardware the firm does not control. An AI model can be distributed, weights and serving stack and all, without handing every recipient a blueprint to reverse-engineer. Whole industries are organized around the fear of losing the machine. This retires the fear.
The nearest step is the bridge. Before any of that silicon ships, the same substrate proves the Zcash chain in, keeps bridged ZEC private as zero-knowledge receipts, runs contracts on it, reaches Ethereum through a proof of the beacon chain, and returns it to the shield, with PRISM covering every route and post-quantum cryptography under all of it. The chips, the drones, and the sealed models are the far end of the road. Private economies settled in ZEC come first, and the Zcash page walks them.
Regular work packets and bounded buffers map naturally across ordinary multicore systems and specialized accelerator profiles. Canonical interval order keeps worker placement from changing the final statement. Hardware availability and measured performance remain deployment-specific.
BOUNDED HARDWARE STREAM
placement changes · meaning does not
Worker assignment and the reduction tree may change, but canonical chunk order and the final statement do not. The same architecture can map to different hardware profiles without changing what the verifier checks.