Skip to content
One system, three sites
CAIN-42 CAIN Studio

CAIN-42 now

The current state, from its sources

The first block is a snapshot built by scripts/cain42_site/build_now.py from git, the running gateway process and its live endpoints; its build time is shown, so you can see how old it is. The second block is fetched by your browser now. Overall status: LIVE, self-attested.

Snapshot

Loading /now.json…

What is live, what is verified, what is not

Your browser fetches every row below from its source when this page loads: the live pipeline's own status endpoint, the gateway's signed node state, the soak's latest signed checkpoint and the Ed25519-signed claims registry. A source that does not answer shows as NOT LIVE.

CAIN-42 Byzantine multi-region trust fabric: where it stands

New: cain-mr-02, 4 replicas on 4 servers in 4 regions (Atlanta, Los Angeles, Miami, Silicon Valley), one each. It kept committing with any single server offline, including a leader change every time, and refused with two offline (evidence, live health). The pages below still track cain-mr-01 until its 72-hour soak ends: 4 replicas on 3 hosts in 3 regions (Atlanta, Los Angeles, Miami), n=4, f=1, quorum 3. Replicas talk over an encrypted mesh, and each one's Ed25519 key was generated on its own host. On the live cluster we stopped Miami, then one Los Angeles replica, then the whole Los Angeles host (it refused to commit, as it must), then Atlanta with the primary (view change), and recovered. 336 certificates, 49/49 standalone checks. A second drill restarted every replica under live traffic with zero client-visible failures and rebuilt one replica from a total disk loss in 13.6 s. Under real network partitions a cut-off replica committed nothing, and a 2|2 split committed nothing on either side.

Live cluster: checking…

Operational proof: checking…

cain-mr-02 proof: checking…

Production gates (14 of 15 passed)

The gates below come from the CAIN-42 evolution directive: a multi-region production claim needs all fifteen. Each row states what has been demonstrated and what has not.

GateRequirementStatusEvidence / what remains
AIndependent geographic failure domainsPASScain-mr-02: 4 replicas on 4 servers in 4 regions (Atlanta, Los Angeles, Miami, Silicon Valley), one each. Every server was taken offline in turn and the cluster kept committing (6/6 each time, including a leader change each time); with two servers down it refused verify 264 certificates · computed resilience; one provider (Vultr): a provider-wide outage is not covered
BReal cross-region consensusPASScain-mr-01 orders decisions across all three regions over WireGuard; every decision carries signatures from at least 2 regions live · certificates
CRegional failure testPASSMiami down: 6/6 committed. Atlanta and the primary down: view change, 6/6 committed with no Atlanta signature fault schedule and results
DNetwork partition testPASSlive: a host cut off while running (the other three committed 6/6, the isolated replica refused writes and committed nothing), and a 2|2 split (neither side committed: no split brain); all four agreed within about 3 s of each heal verify 2,960 certificates ; one-way (asymmetric) partitions on the 4-server cluster: a deaf replica, a one-way link and a mute replica, the cluster kept committing and converged after each heal, no fork verify 968 certificates (complete one-way loss only; not flapping links, partial loss or delay); and under 10% loss, 120±40 ms jitter, 5% duplication and reordering on all four replicas: no fork, but throughput fell from 1.76 to 0.16 commits/s and 22 of 61 writes timed out (recovered fully afterwards) verify 2,728 certificates
EByzantine-node testPASSacross the three regions on the production image: a replica forging votes was rejected by every honest replica (6/6 committed); an equivocating primary was proven from its own two signatures, quarantined by all 3 honest replicas, and replaced by a view change (6/6 committed) verify certificates and the proof; run on a disposable cluster with the same placement, since production refuses fault injection by design; f=1, two behaviours
FState convergencePASSall four replicas hold an identical decision chain and state after the fault run (336 certificates) verify in your browser
GEvidence continuityPASSdecision chain folded from genesis on every replica; standalone verifier 49/49 verifier output
HRecovery verificationPASSlive: every replica restarted under continuous writes (83/83 committed, 0 client failures, catch-up 9-12 s); one replica lost its whole disk and rebuilt from peers in 13.6 s with an identical quorum-signed history verify all 2,832 certificates
IClean-room verificationPASSverifiers import no CAIN code; your browser re-checks every signature the verifier
JRepeatable benchmarkPASS3 independent runs per level on the live cluster, every write committed: 1 client 2.0-2.4 commits/s (p50 409-438 ms), 4 clients 4.1-4.8/s (p95 1.07-1.26 s), 8 clients 4.1-4.5/s (p95 3.0-3.4 s) all runs and method
KSecurity invariant suitePASS870 passed, 0 failed in the published run (consensus engine, Byzantine, evidence, multi-region, hosted pipeline, site truth, secrecy, package mirror); the earlier 4 failures were fixed, including a real approval-workflow bug test report; operator-run, not independent CI
LSupply-chain verificationPASSthe 4-server cluster runs an image (commit 948b189 since 2026-09-27, upgraded replica by replica under live traffic) that rebuilds bit-for-bit: two independent from-scratch builds of its commit produced exactly the deployed image ID; the base image is pinned by digest, every package is pinned, the files are byte-identical to the commit, and it has an SBOM and an Ed25519-signed release manifest (verifier 17/17) release manifest; the 3-server soak cluster moves to it after the soak
MRollback verificationPASSlive: rolled back to the previous engine (9fedb49) and forward again (81bdf84), one replica at a time with the primary last; every replica caught up in 10-14 s, cluster HEALTHY 4/4 after each direction, no quarantines rollback record (both engines share one storage format)
NDisaster-recovery verificationPASScain-mr-02: two replicas on two servers (Miami, Silicon Valley) lost their storage at once and were rebuilt only from off-host backups held in other regions; with both down the cluster committed 0 of 4 writes; afterwards 0 decisions lost, identical height and state on all four 10.3 s after restart verify 416 certificates. Earlier: one replica restored from a snapshot 12 decisions old in 8.3 s under writes verify 3,096 certificates. Hourly backups of both clusters go to another region, and every day each backup is proven to be a quorum-signed prefix of the live history daily restore validation; not covered: backups on another provider, encryption at rest, losing 3 of 4 replicas
OIndependent reproductionNOT YETno third party has reproduced the results yet

Additional production gates P–X (5 of 9 passed)

Added by the CAIN-42 production completion directive. Blocked means it cannot be met on the current infrastructure, not that it was skipped.

GateRequirementStatusEvidence / what remains
PHosted PBFT in the live authorization pathPASSevery recorded hosted decision is ordered through the live cluster, and since 2026-09-27 the gateway verifies the quorum certificate itself (3 pinned signatures over this decision's digest; a replica's unproven "COMMITTED" is a denial). Try it: POST /fabric/try?scenario=safe-read, read consensus.certificate_verified_by_gateway, or verify a decision yourself. Since 2026-09-27 every tenant, free included, is in enforce mode by default (GET /fabric/status shows mode: enforce); a tenant can opt down to shadow mode, and that choice is logged
QMCPGate production enforcementPASSauthorizations committed by the live 4-server cluster; every call through the MCPGate proxy to a separate MCP server process: 5 authorized calls ran, 12 attacks blocked with signed denials returned to the caller verify (one command); the downstream is a sandbox server, and cainstudio.online does not route customer tool calls through this gate
RHardware attestationBLOCKEDnone of the 4 servers has a TPM, AMD SEV or Intel TDX (checked 2026-09-27); nothing is labelled hardware-attested. Needs servers with that hardware
SFormal protocol verificationPASSTLA+ models of the PBFT commit/view-change rules and of the MCPGate gate, checked exhaustively by TLC: 0 violations in 7.3 million distinct states; all 8 deliberately broken variants caught models, results, how to re-run; bounded models, not a proof about the code
TIndependent security reviewNOT YETno third party has reviewed CAIN-42
UContinuous production verificationPASSboth live clusters publish a signed, hash-chained proof of their live state every 30 minutes, checkable from the public URL cain-mr-01 · cain-mr-02; a health watcher alerts on failure; operator-run
VMulti-provider failure domainsNOT YETevery server is on one provider (Vultr); needs a second provider account
W72-hour production soakRUNNINGon the live multi-region cluster since 2026-09-26, verdict after 72 h (about 2026-09-29 21:40 UTC); every checkpoint so far is valid verify. The earlier single-host soak FAILED (liveness stall, fixed)
XFull evidence-chain verificationPASScluster decision chains, MCPGate proof chains, drills, daily backup validation and the signed claims registry all verify with standalone verifiers; every hosted decision record is Ed25519-signed by a key kept outside the database (public key) and its pre-consensus content is checked against the commitment the PBFT quorum signed (consensus_anchor); both are reported by GET /fabric/decisions/{id}/integrity and in every /fabric/try answer verify a hosted decision · daily backup validation; one operator: root on the gateway host holds both the signing key and the database

Architecture

Solid: in the live path today.Dashed: the consensus layer (live cluster cain-mr-01); it orders and signs every hosted decision.Verdicts: ALLOW · REQUIRE_APPROVAL · BLOCKED.