Ledger
Company records that stay correct, and private, even when someone inside — human or AI — has access to every server.
The consensus core (Molt Petit) is proven; the ledger layer above it is designed and not yet built.
Why
Companies are about to run AI agents inside their own infrastructure: wide access, machine speed, and motives that are not fully legible and can be altered from outside by a line hidden in a document. Organisations learned, more or less, how to hire people without fearing them. With AI insiders that is still open.
An AI insider may ask for anything
Validity is decided outside your infrastructure — and stays safe with up to two of seven operators compromised.
in any window of seven slots
An AI insider with access to every server can ask the ledger for anything. Validity is decided by seven independent operators outside the perimeter — and stays safe with up to two of them compromised.
SEPARATIONCREATES SAFETY.
An AI insider can ask for anything.
Validity is decided outside the perimeter.
in any window of seven slots
An AI insider with access to every server can ask the ledger for anything. Validity is decided by seven independent operators outside the perimeter — and stays safe with up to two of them compromised.
Ledger answers a narrower question: how to keep the records that matter most correct and private when something inside the perimeter — with access to every server — may be wrong or turned. Financial state is the first application, because the cost of an error is clear and unrecoverable. Access-controlled documents in a law firm or a large corporate are the next.
What it is
A Kotlin/JVM library over a shared, seven-operator service. To the institution integrating it, it behaves like a database driver: open an account, move a balance, read consistent state, each call carrying its own authorisation. Underneath there is no single database and no single operator who can be wrong or dishonest on their own. Changes are ordered and validated by seven independent institutions running a consensus protocol whose safety properties are machine-checked theorems, and the whole history is carried by a constant-size zero-knowledge certificate rather than by anyone's copy of the records.
Two things follow that are hard to get any other way. An attacker who fully controls your infrastructure cannot make the ledger accept an invalid change — the validity decision does not run inside your perimeter. And a settled transaction cannot be reverted, whatever subsequently happens to the systems that produced it.
What is visible and what is not
Each institution has a shard — its own ledger, fully visible to it and to nobody else. Outside the shard, its state is a single cryptographic root. The operators verify a batch without learning its contents, its structure or how many transactions it contains. Every submission carries two independent attestations: a signature, saying which institution stands behind it, and a zero-knowledge proof, saying the change obeyed the rules. They answer different questions and fail differently, which is the point.
What holds when the shared infrastructure is attacked
Safety holds as long as compromised slots plus stolen keys stay within two of the seven in any window of seven slots. Exceeding it means compromising three independent institutions at once — different companies, different clouds, ideally different enclave vendors and jurisdictions. Stolen keys die on rotation. A forced conflict names its authors: producing two conflicting states leaves non-repudiable evidence identifying which operators equivocated, which is what makes the consortium's contractual exposure enforceable rather than decorative.
Privacy-preserving shard settlement
Each institution keeps its data private. A constant-size certificate proves every change was valid — without revealing any contents.
receipts in · certificates out
Privacy-preserving shard settlement
Each institution keeps its data private. A single, verifiable certificate settles the whole history.
receipts in · certificates out
Rules inside a shard
Accounts carry their own rules, enforced automatically and checked twice by different parties on different bases. Multisig backed by hardware keys — a phone's secure element is a perfectly good signer. Time locks with a cancellation window held by a separately-keyed party: the control that matters most against an attacker operating at machine speed. Receipts from external services as inputs; certificates for counterparties and auditors as outputs. And external settlement credentials held in a TEE that verifies the ledger's proof before it will authorise anything.
Where this stands
What it does not do
The ledger enforces rules that were defined in advance. It does not decide whether an otherwise valid action was a good idea.
If a transfer has the required authorisations, has passed any configured delay, and satisfies the account's rules, the ledger will accept it. The point is not to infer intent, but to make the permitted envelope explicit and enforce it outside the system that may have been compromised.
The shared operator set is fixed. A sufficiently broad simultaneous outage stops progress rather than weakening safety, and the protocol assumes reasonably synchronised clocks.
These are deliberate trade-offs for deterministic finality, a small client state, and a system that fails by stopping rather than by accepting something invalid.
The ledger is not a replacement for a bank's core database. It is an integrity layer for the comparatively small set of operations where an invalid state transition would be exceptionally hard to undo.