Evidence
Every claim, with the mechanism and the check behind it.
This page lists what TulaDB claims, how the code enforces it, and the test or tool that would fail if it stopped being true. Each row was read against the source, not against our own docs — the material a risk committee, an auditor or a third-party-risk review asks for before a new system enters the payment path.
Counts taken from the repositories’ main branches on 2026-10-29. Test totals count targets and test functions; they are a measure of coverage effort, not a proof of correctness.
Under fault, on real fleets
Money conserved in every run that produced a verdict.
Beyond the test suites, the full platform runs for an hour at a time on cloud fleets while the harness kills leaders and followers, partitions the network, freezes processes and fills disks. Every run ends with a money oracle and a check that all replicas agree.
2b2f8b96), 75 minutes of faults at 50,001 transfers per second offered, three Arm nodes in us-east4, the Iceberg exporter on: CHAOS_CLEAN=YES. Money oracle and final agreement passed (balances, history, holds, idempotency, registry); every leader loss under 1,000 ms of unavailability; steady-state p99 7.3 ms; 194.5 million transfers accepted. The verdict →Money
What a posting can and cannot do.
Retries
Why a redelivered request is the same operation, not a new one.
Durability and recovery
What “acknowledged” means, and what happens when the disk misbehaves.
Replication
How replicas prove they hold the same ledger.
Iceberg export
Getting committed history into the lake exactly once.
Operating it
What ships so the people on call aren’t guessing.
What we don’t claim yet
Current limitations.
Knowing where a system stops is part of the evidence. These are true of 0.0.1-preview today.
Check it yourself
Bring the evidence to your review — then test it against your workload.
Ask for evaluation access to see the retry and hold behaviour for yourself, then bring the rows that matter to you to a pilot conversation.