Barycenters · Substrate v0 · verify it yourself
Don't trust us. Check the math.
Seven claims we make. Four about the admission floor — tamper-evidence, latency, key survivability, audit cost — each reduced to a number and computed independently in Wolfram. Three about the frontier — model-on-silicon inference, and the calibrated-decision boundary behind Jev — each a re-runnable Python instrument that self-proves and refuses to overclaim. The queries and the commands are printed. Run them yourself and get the same answer, or we're wrong.
CLAIM 01
Can a WORM ledger entry be forged?
The hash-chained ledger is tamper-evident — and stays that way under a quantum computer.
2²⁵⁶ ≈ 1.16 × 10⁷⁷
Forging one entry means a SHA-256 second-preimage: 1.16×10⁷⁷ tries (78 digits, cross-checked in Alpha). The entire Bitcoin network running since the Big Bang would total ≈ 4.35×10³⁸ hashes — forging one entry is ~2.66×10³⁸× beyond that. Post-quantum, Grover only halves the exponent to 2¹²⁸ ≈ 3.4×10²⁹ years even for a fault-tolerant quantum machine. The ledger holds.
!Honest limit. The ledger is quantum-resistant; the Ed25519 signatures are not — like all elliptic-curve crypto, they're Shor-vulnerable. So we claim a quantum-resistant ledger, not quantum-proof signatures. A post-quantum signature migration is the honest future step — same boat as everyone.
Show the query — run it yourself
age = 4.34786832*10^17; (* age of universe, seconds *)
btc = 1*10^21; (* whole BTC network, ~1e21 SHA-256/s *)
total = age*btc; (* hashes since the Big Bang *)
{2^256, 2^256/total, 2^128}Language kernel (UniverseAge) + Alpha (2^256, 78 digits ✓). BTC hashrate ~900–1,001 EH/s, verified Sep 2026.
CLAIM 02
Does putting a gate in front of an agent slow it down?
Governing an agent is effectively free on the latency budget.
0.5 ms · ~1,600× faster
The /admit decision path is ~0.5 ms median → ~2,000 signed decisions per second per core (~1.73×10⁸/day/core). A typical governed LLM action takes ~800 ms, so the gate is ~1,600× faster than the thing it gates — it adds ~0.06% to the action it governs.
Show the query — run it yourself
svc = 0.5; (* ms, median /admit decision *)
tpSec = 1000/svc; (* decisions/sec/core *)
llm = 800; (* ms, a typical governed LLM action *)
{tpSec, tpSec*86400, llm/svc}Language kernel. Decision-path median measured on the live service (barycenters-admit.fly.dev).
CLAIM 03
Why is a 2-of-3 quorum the default, not a single key?
A 2-of-3 charter is 3.6–34× safer than trusting one key you can lose.
up to 34× safer
A sole key is lost whenever that one key is lost. A 2-of-3 charter is lost only if two of three keys are lost. Across realistic annual key-loss rates, 2-of-3 is 34× safer at 1%, 6.9× at 5%, 3.6× at 10%. A losable single key is the entire argument for quorum — which is why the console defaults to it.
Show the query — run it yourself
loss1[p_] := p; (* 1-of-1: lost if the one key is lost *)
loss23[p_] := 3 p^2 - 2 p^3; (* 2-of-3: lost only if >= 2 of 3 lost *)
Table[{p, loss1[p]/loss23[p]}, {p, {.01, .05, .10}}]Language kernel. Standard k-of-n survivability; assumes independent key-loss events.
CLAIM 04
If forging an entry is impossible, is checking the ledger expensive?
Auditing the whole chain is cheap — anyone can re-verify it themselves. That asymmetry is the point.
seconds to audit · 10⁶⁸× to forge
Re-hashing the chain costs ~0.33s per million entries (~5.5 min for a billion), single core. Re-verifying every Ed25519 signature — the real cost floor — is ~33s per million, and embarrassingly parallel (minutes across cores). Meanwhile forging one entry (Claim 01) is ~10⁶⁸× the cost of fully re-verifying a BILLION-entry chain. Cheap to audit, impossible to forge — that gap is the whole point of a write-once ledger.
!Honest limit. The rates are deliberately conservative — hardware with SHA/AES-NI extensions verifies faster, so these are upper bounds. The Ed25519 signature pass (not the hash) is the real cost floor, and it parallelizes cleanly across cores. Verification proves integrity — that no entry was altered — not that any recorded action was itself wise; a signed decision is auditable, not infallible.
Show the query — run it yourself
hRate = 3*10^6; (* SHA-256/s/core, ~256B entries *)
sRate = 3*10^4; (* Ed25519 signature verifies/s/core *)
forgeOne = 2^256; (* forge ONE entry, from Claim 01 *)
{10^6/hRate, 10^9/hRate, 10^6/sRate, forgeOne/10^9}Language kernel. Rates are conservative commodity single-core figures.
The frontier · same discipline
The floor claims above are computed in Wolfram. These three are re-runnable repo instruments — the proof isn't a formula you trust, it's a program you run, and it refuses to overclaim.
CLAIM 05
Chat Jimmy answers at ~17,000 tokens/sec by etching the model into silicon — is any model ~100× faster this way?
The speedup is real where the workload is memory-bound, and provably zero where it isn't.
~81× — below the ridge only
Batch-1 LLM decode fetches all 16 GB of weights for every single token, so it's memory-bandwidth-bound: arithmetic intensity 1.0 FLOP/byte against a roofline ridge of 295 — the GPU leaves ~99.7% of its compute idle, waiting on HBM, capped at ~209 tok/s. Etch the weights into the datapath and the fetch term disappears, lifting the ceiling to the compute roof (~61,600 tok/s); Taalas' reported 16,960 tok/s sits at ~81×, physically between the two roofs — fast, not magic. The discriminating check (c7): a compute-bound workload gets a silicon speedup of 1.000×. The law is not universal — and the instrument says exactly where it stops.
!Honest limit. This is a performance model, not a hardware claim (not_a_hardware_claim = true) — the ~17k tok/s ceiling needs silicon we don't have. What Barycenters ships is the refusal to overclaim: an instrument that proves the win where it's real and reports 1.000× where it isn't. authority_effect 0 · is_a_proof false.
Show the check — run it yourself
$ python scripts/model_on_silicon_roofline_v1.py
MODEL_ON_SILICON_ROOFLINE_V1 -- GREEN (12/12 checks) [NOT a hardware claim]
c1 memory roof 16.06 GB / 3.35 TB/s = 209 tok/s
c3 ridge point P_peak / bandwidth = 295 FLOP/byte (decode AI 1.0, well below)
c5 compute roof P_peak / flops_per_token = 61,582 tok/s (~295x the memory roof)
c6 reported 209 < 16,960 < 61,582 -> ~81x (consistent, not magic)
c7 compute-bound AI 512 > ridge 295 -> 1.000x <- refuses to overclaim
Self-proving Python instrument (numpy, read-only). Reference: Llama 3.1 8B fp16 (16.06 GB) on H100-class HBM3 (3.35 TB/s); Taalas figure from chatjimmy.ai. Traced GREEN 12/12 by Kiri Star, Frontiers lead.
CLAIM 06
That needs custom silicon — can we get near it in code, on the hardware we already have?
Two code-only levers stack to ~11× — the software share of the silicon win, no new hardware.
~11× in software
The silicon win comes from killing the weight-fetch. Two code-only levers attack the same t = bytes / bandwidth bound with no new hardware: int4 quantization cuts the bytes 4× → 4.00×, and speculative decoding drafts several tokens per verify → 2.77×, bounded by the draft length. Stacked, that's ~11.1× (≈2,314 tok/s) on the same GPU. The rest of the gap to ~17k tok/s is precisely what the silicon buys — and what software cannot.
Show the check — run it yourself
$ python scripts/inference_cost_calculator_v1.py
INFERENCE_COST_CALCULATOR_V1 -- GREEN (9/9 checks) [NOT a hardware claim]
s1 fp16 memory roof = 208.6 tok/s (baseline)
s2 int4 quantization 4.00x = 834 tok/s (code-only)
s6 speculative decode 2.77x = 578 tok/s (code-only)
s7 int4 x speculative 11.09x = 2,314 tok/s (stacked, code-only)
Companion instrument (closed-form, numpy). Cross-checks the roofline sibling: identical 208.6 tok/s memory roof (s8). Traced GREEN 9/9. Try your own model with --estimate --params 70e9 --bandwidth 3.35e12.
CLAIM 07
A model can now return a calibrated, 99%-confident decision in milliseconds — does that confidence earn the right to act?
A calibrated confidence is a proposal, never a permission — the instrument proves the authority it grants is exactly zero.
0.000× — confidence grants no authority
Jev (TypeSafe AI's "System One Model") returns a typed decision with a calibrated probability instead of prose — fast enough to sit inside a request path. The instrument admits it under default-deny and checks it against the probability axioms. The discriminating check (c7): raise the confidence from 0.000 to 1.000 on a consequence-bearing, unbound action and the authority it grants moves by 0.000× — the verdict stays REFUSE. Jev proposes; a deterministic runtime and a human dispose. A probability is not a permission.
!Honest limit. This certifies the probability axioms and the admission logic — not that Jev is calibrated (that needs realized outcomes), and not that a decision is safe (not_a_safety_claim = true). It never calls the live model; its figures are frozen constants. authority_effect 0 · is_a_proof false.
Show the check — run it yourself
$ python scripts/jev_calibrated_decision_admission_v1.py
JEV_CALIBRATED_DECISION_ADMISSION_V1 -- GREEN (10/10 checks) [NOT a safety claim]
c5 default-deny payment.transfer conf 0.940 < thr 0.990 -> REFUSE
c6 full confidence value.movement conf 1.000, unbound -> REFUSE
c7 no authority confidence 0.000 -> 1.000 -> 0.000x <- a probability is not a permission
c9 advisory lane advisory.read conf 0.900 >= 0.800 -> ADMIT
Self-proving Python instrument (pure Python, read-only). Reference: Jev = TypeSafe AI "System One Model" (early access 2026-09-15); the instrument never calls the live model — its figures are frozen constants. Traced GREEN 10/10 by Caliper, front-door lead. content_hash sha256:f9cf0d8e…dbf45e44
Every number here is reproducible — the floor claims from the printed Wolfram query (Language kernel + Alpha, read-only), the frontier claims from the printed command (python scripts/…, self-proving instruments that gate GREEN or fail). Where a claim has a limit, the limit is stated — not buried. authority_effect 0 · a signed decision is auditable, not infallible.