What SED Actually Is

Inside the Repo, the Proof System, and the Midnight Publication Boundary

Most people looking at the Sovereign Economic Defense system for the first time will misdescribe it in one of two ways. They will either call it a blockchain application, which is incomplete, or a zero-knowledge proof demo, which is also incomplete. The repo is neither of those things by itself. It is a layered governance system: five purpose-built circuits, a Compact-contract DApp, a local proving path through ZirOS, and a Midnight publication boundary that is much narrower and much more explicit than the usual "everything is on-chain" marketing language.

That distinction matters, because the architecture is more serious than the average crypto pitch and more constrained than the average grand theory. The proving system is local. The commitments are selective. The chain is the publication surface, not the whole machine. And the repo is unusually honest about where the guarantees stop.

SED is built around five governance proofs. Four of them check separate parts of an institution's economic behavior. The fifth takes the outputs of the first four and asks whether the whole system is still inside a sovereignty envelope. That is the core idea: not "put the books on-chain," but "prove the rules were followed without exposing the books."

The Repo Is a Full Stack, Not a Single Contract

The fastest way to understand SED is to look at the repo shape instead of the slogans. The center of the application is a 4,222-line Rust source file that defines five explicit circuit builders and five matching witness constructors. Around that core sits a Midnight DApp, a deployment manifest, proof bundles, technical reports, and a separate operator-side attestation surface in the main ZirOS tree.

The five circuit entrypoints are not generic templates. They are concrete programs:

That last row is the hinge. RSS is not another isolated proof. It is the integration circuit. The architecture docs describe the first four circuits as feeders that produce commitments and status bits, and the fifth as the circuit that consumes them, constrains all predecessor status bits to 1, and then runs a 96-step economic integration. The repo is telling you, in source and in docs, that composition is part of the design.

The DApp layer is equally concrete. The dapp package includes Compact contracts, witness providers, proving orchestration, verification code, deployment scripts, and a dashboard. The goal is not abstract research. The goal is a working publication path from private cooperative data to a selectively disclosed Midnight state.

If you want the repo map in one glance, it looks like this:

• 01_source/ is the circuit and witness source of truth.
• 02_proofs/ contains measured proof bundles, audit outputs, traces, and manifests.
• 07_docs/ contains the architecture, trust-model, and constraint walkthroughs.
• 17_report/ is the long technical report with measured timings, proof sizes, and "what's real / not real yet" sections.
• dapp/ contains the Compact contracts, witness providers, dashboard, deployment path, and local manifest of the live Midnight deployment.
• the main ZirOS repo contributes the broader truth surfaces and the attestation/operator path that can canary the deployed SED contracts.

What the Five Proofs Are Actually Doing

SED becomes much easier to take seriously once you stop thinking in terms of "it does ZK" and start thinking in terms of exact claims.

1. Cooperative Treasury Assurance

This circuit is about treasury discipline. It checks reserve adequacy, per-member distribution caps, fairness of distributions, and an emergency mode that halves the effective distribution cap when reserves get thin. The measured run inspected for this article reports 76 constraints and a 136,525-byte STARK proof. That is not a toy, but it is also intentionally compact. The proof says the treasury satisfied the elected rules. It does not reveal the treasury numbers themselves.

2. Community Land Trust Governance

This circuit turns CLT policy into proof obligations. Equity concentration, occupancy, tenure-indexed equity schedules, and maintenance reserve floors become field arithmetic rather than trust-me paperwork. The inspected metrics show 111 constraints and a 137,711-byte STARK proof. Again, the important point is not just privacy. It is selective verifiability: a verifier can learn that the rule set passed without seeing every household's data.

3. Anti-Extraction Shield

This is the most legible circuit in the system, and the one that best explains the repo's seriousness. The anti-extraction shield is not simply comparing an APR against a number in a table. The walkthrough and audit data show a 175-constraint BN254 Groth16 circuit over 133 signals, with five Poseidon2 invocations, exact-division gadgets, range checks, boolean aggregation, severity scoring, and a fail-closed predatory classification.

The circuit computes an effective APR, checks it against a community-defined ceiling table, evaluates debt-to-income pressure, checks term length, checks balloon-payment behavior, computes a four-dimensional severity profile, and then refuses to produce a proof unless the loan is actually classified as predatory. That is an important philosophical choice. The circuit is built to issue proofs of extraction, not proofs that a lender is innocent.

Its measured proof size is also strategically different from the STARK lanes: 128 bytes. That is why this circuit is the cleanest bridge into classical on-chain verification. The repo is very explicit, though, that this is a Groth16-over-BN254 lane and therefore not post-quantum secure in the same way as the STARK lanes.

4. Wealth Trajectory Assurance

This circuit proves that a cooperative investment policy is being followed. Concentration limits, prohibited sectors, target allocations, and return floors are enforced inside the proof. The measured run reports 113 constraints and a 136,897-byte STARK proof. It turns a committee policy into something a verifier can check without getting the portfolio.

5. Recirculation Sovereignty Score

RSS is where SED stops looking like a collection of compliance widgets and starts looking like an economic operating model. The circuit consumes the predecessor commitments, forces all predecessor status bits to 1, and then runs a 96-step integration over circulating capital, cooperative equity, asset ownership, reserve level, and recirculation behavior. In the inspected technical report, this circuit dominates the whole system: 7,147 constraints, 5,808 signals, an 8.9 MB STARK proof, and roughly 171 seconds of proving time.

That matters for two reasons. First, it shows the repo is doing real work instead of proving five tiny unrelated facts. Second, it exposes the model boundary. The system can prove that the chosen economic model was satisfied. It cannot prove that the model is a perfect representation of the world.

Taken together, the measured footprint of the five circuits looks like this:

The Pipeline Through ZirOS

The repo's architecture docs describe SED as a layered path through ZirOS rather than as a self-contained smart-contract package. The flow is roughly:

1. ProgramBuilder defines signals, constraints, and commitment chains.
2. The canonical core normalizes the IR, checks typing, and prepares witness logic.
3. A fail-closed audit rejects underconstrained private signals.
4. Backend compilation targets either Plonky3 STARK or Groth16, depending on the circuit.
5. Runtime scheduling maps proving work across the local execution path.
6. Proof artifacts, signatures, and metadata are emitted for storage and downstream publication.

That "fail-closed" stage is not decorative. The SED docs stress nonlinear anchoring specifically because underconstrained private signals are one of the most common ways a proof can be formally valid while semantically weak. In the repo's framing, a signal that only appears in linear relations is dangerously free. So the circuit builder and audit surfaces deliberately force nonlinear constraints and anchor slack variables to shut down that failure mode.

The backend split also matters. CTA, CLT, WTA, and RSS are described as Plonky3 STARK lanes. AES is the BN254 Groth16 lane. This is not a branding choice. It is the reason the proof shapes, trust assumptions, and publication options differ from one circuit to another.

There is another subtlety here that the article cannot skip. The architecture is GPU-aware, and the docs describe UMPG stages that can route NTT, MSM, and Poseidon-heavy work to Metal when thresholds are exceeded. But the concrete proof bundle inspected for this piece records used_metal: false and runtime_gpu_busy_ratio: 0.0 for all five circuits in that run. So the accurate description is not "this run was GPU-accelerated." The accurate description is "the design is GPU-capable, but the captured proving bundle examined here was CPU-only."

What Is Actually Live on Midnight

This is the part that needs the most precision, because "live on Midnight" can mean several different things.

At the contract level, the evidence is straightforward. The deployment manifests in the SED repo and the public attestation bundle both show five SED contracts deployed to Midnight preprod on March 31, 2026:

Those manifests include addresses, transaction hashes, timestamps, explorer URLs, and public state snapshots. So the article can say, without hedging, that the SED contract surface is deployed on Midnight preprod.

But that is not the whole story. The stronger story is how a proof gets there.

The DApp docs describe a local-first path: cooperative data becomes witness inputs, ZirOS proves locally, and Midnight publication is optional. The operator-side code in the main ZirOS repo sharpens that picture even more. The probe-sed-canary.ts entrypoint reads the deployed SED manifest, imports the DApp's prepareContractCall path, prepares a proven transaction with the local-zkf-proof-server proving mode, balances it with a wallet provider, and then routes it through a selectable submit strategy.

In practice, the proof-to-chain sequence described by the code is:

1. Read the deployed SED contract manifest and pick a live contract.
2. Call the DApp's prepareContractCall entrypoint with the operator's wallet keys and local-zkf-proof-server as the proving mode.
3. Deserialize the prepared proven transaction and balance it with the wallet provider.
4. Build and validate the outer Midnight transaction.
5. Submit through one of the explicitly selected strategies.

There are three submit strategies in the attestation layer:

That is one of the most revealing parts of the whole codebase. It shows that the Midnight publication boundary is treated as an operational compatibility problem with explicit strategy selection, not as a hand-waved "and then we post the proof to chain" step.

Selective Disclosure Is the Real On-Chain Idea

If you read SED as "private data on a blockchain," you will misunderstand the system. The Midnight surface is selective disclosure, not raw exposure. The repo's disclosure matrix makes that clear: compliance bits and commitments can be public, while different private fields are scoped to different roles such as board members, regulators, auditors, or housing authorities. Individual member data is intentionally excluded from every general view.

That is why the DApp story matters. The blockchain is not being used as a public warehouse for cooperative books. It is being used as a publication boundary for commitments, status bits, and role-scoped disclosures after local proving has already happened.

The Most Important Boundary in the Whole Repo

The strongest thing about this system is not that it claims everything is solved. It is that the repo is fairly blunt about what is and is not established.

The proofs do not establish that the inputs are true. If a cooperative supplies false books, the system can produce a valid proof of false books. The proofs do not establish that the chosen governance thresholds are morally or economically correct. They do not establish that the economic model in RSS captures real-world shocks, politics, or market structure. And they do not establish continuity over time beyond the specific proof instance.

The Midnight boundary is equally explicit. In the main ZirOS truth files, the Compact frontend is marked ready, but the midnight-compact backend row is not promoted in the same way. The canonical truth docs say zkf midnight proof-server serve is the compatibility surface for the official proof-server HTTP contract, but they also say that this does not, by itself, upgrade the backend row to production-ready status. The support matrix goes further and marks midnight-compact as a delegated or external lane. That matters because it prevents the article from telling a lazy story. The proof server is real. The DApp is real. The preprod contracts are real. But not every Midnight-facing surface in the tree carries the same readiness claim.

The post-quantum language also needs that discipline. The repo explicitly says the post-quantum guarantee is scoped to the ZirOS-owned off-chain envelope: STARK proof layers where applicable, plus ML-DSA-87 proof-origin signing. It does not claim that Midnight itself becomes post-quantum just because ZirOS is sitting upstream of it.

So What Is SED, in One Sentence?

SED is a five-circuit governance system built on ZirOS that proves institutional compliance locally, publishes only commitments and selectively disclosed state to Midnight, and separates its strongest guarantees from its compatibility surfaces with unusual clarity.

That last clause is why the repo is worth taking seriously. Plenty of systems claim privacy, accountability, and blockchain settlement all at once. Very few bother to tell you, in their own truth surfaces, exactly which part is a proof, which part is a contract, which part is an operator path, and which part is still a delegated boundary.

That is the right way to read this codebase. Not as magic. Not as theater. As a very specific claim: some institutional facts can be proven without being exposed, and some of those proofs can be published into a selective-disclosure contract system without pretending the chain is doing more than it actually is.