Curation You Can Verify

Every vault curator makes the same two claims. We allocate your capital safely, and we do it responsibly. Both are claims about a process you cannot see. You are asked to trust the curator's tooling, their internal discipline, and their judgment at 3am during an incident, and the only evidence on offer is a track record that looks identical right up until the moment it doesn't.

I built BizOS because we didn't want to make those claims either. It is the operating system Bizantine Labs runs its own curation practice on, and its entire design premise is that a curator should be able to answer two questions with architecture rather than assurances: how do you keep a bad transaction from ever being signed, and how do you prove what you did?

Why trust is the wrong primitive

The failure mode that matters in curation is rarely a bad strategy thesis. It's a transaction that should never have been submitted. A misconfigured rebalance, a strategy bug that drains into a stale market, a compromised proposer, a signer who approved a batch nobody read carefully. Every one of these is a process failure, and process failures are exactly what a track record cannot rule out.

The second problem compounds the first. When something does go wrong, the reconstruction is almost always a mix of block explorer archaeology and internal notes that the curator controls and could, in principle, have edited. Even an honest curator has no way to demonstrate that they didn't.

So BizOS replaces trust with two structural guarantees. No transaction touching client funds gets signed without surviving an independent automated evaluation first. And every decision, verdict, and state change lands in a tamper-evident log that clients can inspect.

How it works

Every transaction, whether a strategy engine proposed it or a human drafted it, passes through two independent policy stages before any signer touches it.

Stage one is the Varangian Guard. The transaction is simulated against live chain state and evaluated against that vault's security policies, producing a SAFE, CAUTION, or DANGER verdict. DANGER is blocked server-side with no override path, and dangerous pending transactions can be auto-aborted. The guard sits between all proposers and all signing, so neither an automation bug nor a compromised proposer has a route around it.

Stage two is the signing infrastructure's own approval policy: MPC co-signing, and human review for higher-risk transaction classes. A transaction that clears the guard still has to clear this. Passing one stage grants nothing at the other.

The signing key itself lives on isolated, outbound-only infrastructure. Nothing can connect to it. It polls for approved work. A compromised gateway, proposer, or even application host cannot produce a signed transaction that skipped both stages, because there is no network path from any of them to the key.

Evidence written before the action

Every guard verdict and lifecycle event is written to an append-only, hash-chained log before the action it describes is permitted to proceed. If the log is unavailable, the system fails closed and the action does not happen. Each entry cryptographically commits to its own contents and to the entry before it, so the history cannot be quietly rewritten later.

This is the part that turns a pitch about process into a record of it. Clients can see what was proposed, what the guard evaluated, what verdict it returned, and what was ultimately signed, with the ordering and integrity of that sequence independently checkable.

Vaults managed as code

A canonical manifest declares each vault's strategy, risk parameters, and requirement gates. Deployment plans render from reviewed templates, compile into validated transaction batches, and execute through the same guarded pipeline as everything else. There is no separate, more permissive path for deployments or for anything else.

Disclosure obligations are classified and enforced mechanically rather than remembered. Attestations about a vault's state anchor to the evidence log, so a statement like "all requirement gates cleared" resolves to cryptographic proof.

Measuring demand before deploying

Before a vault exists, BizOS can establish whether it should. Allocators prove control of their addresses, receive a verified reading of their holdings as allocation credit, and sign commitments against a campaign. Commitments are Merkle-rooted on-chain, which makes them non-equivocable and independently verifiable, and early commitments that are fulfilled earn streaming rewards. The curator gets a bounded, attributable demand figure up front. No funds touch the platform at any point; deposits flow directly from allocator to vault.

The subsystems

BizOS is six cooperating subsystems, each named for a Byzantine office and each with exactly one job.

Porta Aurea is the gateway: single ingress for every authenticated request, handling routing, rate limiting, and presence-gating. It decides nothing itself.

Logothesion is the control plane: manifests, requirement gates, deployment plans, disclosure classification, attestation issuance, held as a versioned repository rather than a mutable service.

Tagma is the executor: it proposes rebalances, harvests, and settlement actions, compiles plans, and submits intents into the guarded pipeline. It never signs and never bypasses the guard.

Varangian Guard simulates and policy-evaluates every transaction, issues the verdict, and blocks DANGER unconditionally.

Zygostates is the weigher: the append-only, hash-chained evidence log that every state-changing action must land in before it proceeds.

Vestiarion is the registry: verified holdings, signed commitments, on-chain attestation, incentive distribution.

Around these sit an operator dashboard for reviewing pending transactions and guard verdicts, a stakeholder notification system with provable delivery evidence, and public documentation.

The security model in four lines

Defense in depth over perimeter: gateway, guard policy, and signing policy are independent, and breaching one grants no path around the others. The signer is unreachable and accepts no inbound connections. Everything fails closed, so availability problems halt execution and never silently weaken it. Automation proposes and never disposes: strategy logic can queue actions, only the guard pipeline and signing policy can release them, and advisory AI sits structurally outside the execution path where it assists interpretation and alerting but cannot influence what gets signed.

Who this is for

Allocators evaluating a curator, who want the difference between a pitch about process and a verifiable record of one. Curators who need institutional-grade operational safety without standing up a security engineering team. And protocol partners who need credible, auditable evidence about how a vault attached to their protocol is actually operated.

Trust doesn't scale and it doesn't survive contact with an incident. Architecture does.