CIRIS fabric · measured performance
Every number below is measured on a GitHub Actions runner. No projections, no marketing math — run it yourself and you get these numbers.
Each row is a criterion microbenchmark on the CI runner. The plain-English sentence is the takeaway; the value is the raw measurement; the last column is the exact bench id.
| what it means | measured | bench |
|---|---|---|
| One CPU core can decrypt about this many gigabytes of video per second on the receive side. | 2.87GiB/s/core | av_frame_halves/open/16384 |
| One CPU core absorbs about this many fresh signed traces per second (verify + decompose + persist). | 2,680traces/s/core | replication_ingest/ingest_new |
| Re-delivered (already-seen) traces are rejected at about this rate — still paying full signature verify, so a gossip flood is bounded by verify speed. | 2,806traces/s/core | replication_ingest/ingest_dedup |
| Relaying one small (~208 B) blinking-dot frame through one mesh hop costs about this many microseconds of CPU. | 0.80µs/hop | alm_chain_hop/208 |
| Sealing 2,000 simultaneous blob streams at 30 fps uses about this fraction of one CPU core. | 0.03core-fraction @ N=2000, 30fps | stream_fanout_seal_tick/2000 |
| Computing one agent's coherence-capacity score over a full 500-trace window takes about this many microseconds. | 90.63µs/agent @ N=500 traces | n_eff_e2e/500 |
| Starting one post-quantum key exchange (X25519 + ML-KEM-768) takes about this many microseconds. | 121µs | pqc_kex/hybrid_initiate |
| Starting one classical-only (X25519) key exchange takes about this many microseconds. | 69.89µs | pqc_kex/classical_initiate |
| Sealing then opening one 16 KiB 720p video frame end-to-end takes about this many microseconds. | 11.82µs/frame | av_frame_e2e/16384 |
The production FountainSwarmRuntime (the same code the node ships)
run in-process on the runner. A publisher in group A reaches every group-A peer; the cohort
gate means group B is never in the closure, so its leak count is structurally zero — and
that's exactly what the measurement shows at every scale.
| nodes | group-A converged | group-B leaks | propagation |
|---|---|---|---|
| 50 | 24 / 24 | 0 | 6.5ms |
| 100 | 49 / 49 | 0 | 6.2ms |
| 200 | 99 / 99 | 0 | 6.2ms |
| 400 | 199 / 199 | 0 | 7.4ms |
Replication A→B: A signed holding-claim emitted at node A is observed at node B over the real in-process swarm path in about this many milliseconds. Emitted 1, observed 1 at ~6.0 ms.
Content is split into redundant fountain shares across holders; this is the measured chance it can still be rebuilt as each tier's fraction of holders goes offline. Empirical reconstruction rate from real encode→drop→decode trials against the substrate's own codec — not a survival formula. Config: ciris_edge codec-fountain (RaptorQ RFC 6330) · 20 source + 10 repair shares across 30 holders.
| network condition | holders offline | recovered | trials |
|---|---|---|---|
| datacenter | 5% | 100% | 4,000 |
| typical wifi | 10% | 100% | 4,000 |
| medium churn (design target) | 15% | 99.7% | 4,000 |
| high churn | 20% | 97.6% | 4,000 |
| battlefield mesh | 30% | 72.7% | 4,000 |
We don't hide this: a post-quantum signature is real work. Per signed event, the hybrid Ed25519 + ML-DSA-65 sign+verify is 1,023 µs vs 55.4 µs for classical Ed25519 alone — about 18×. ML-DSA dominates; that's the price of being quantum-resistant today, measured rather than waved away. Even so, a single core still ingests ~2,680 of these signed events per second — the verify is one stage of a pipeline, and throughput stays high.
A small relay tree forwards traffic between participants, so capacity grows as people join instead of requiring bigger servers. The relays forward sealed bytes they can never read.
Every event and stream is signed and encrypted with hybrid classical + post-quantum cryptography (Ed25519+ML-DSA, X25519+ML-KEM). The provenance survives a future quantum computer.
The corpus is split into fountain-coded shares spread across holders, so it rebuilds even as a large fraction of them go offline — the resilience table above is measured, not assumed.
Kept honest: these have no benchmark yet, so they appear here rather than as a number.
mls_commit_barrier — no MLS-commit-barrier bench yetcold_join_burst_latency — no cold-join-burst-latency bench yet