Research

Siontology’s code implements one architecture. Its research asks where that architecture breaks, and what would have to be true for it to go much further. This part of the book collects the notes. Each says what is built, what is measured, and what is only a plan.

The bet: count payments, not transactions

A general-purpose ledger is bounded by what its validators can check and prove each second. Our succinct-proof plan puts numbers on that bound: 100,000 operations a second, the Gate 3 target, needs about 500 to 2,000 prover machines even with the signature changes it proposes; a billion operations a second would need millions. No amount of engineering on one design closes that gap.

Most of the traffic a ledger would carry at that scale is not general, though. It is machines paying machines, a little at a time, over and over: an agent paying an API per call, a device paying a network per megabyte, a service paying a model per token. For that traffic we separate the two things a ledger does for a payment:

• Verification, when the payment is made. In a payment stream, each payment is one element of the payer’s hash chain, and the payee checks it with one hash. Nothing reaches the ledger.
• Settlement, when money moves. With checkpoints, the ledger settles any number of payments for a bounded number of hashes and one signature, and anyone can check any payment against what it settled.

On one core of a small cloud machine, settlements covering about 9 × 10⁸ payments a second executed with every signature checked. The note Billions of payments a second has the construction, the safety argument, the capacity law, the measurements and what remains unknown.

What this is, honestly. It is a measured separation and a design that exploits it, not a theorem, and not new cryptography: hash-chain payments date from 1996. We have not found the combination elsewhere, and we publish it so that others can check, break or improve it. A discovery is something the field agrees on after scrutiny; this is a claim, ready for it.

Agents at scale

The same separation runs through the design for billions of agents and robots. Their payments, memories and steps of work stay off the ledger, in streams and in logs that only their writers append to; the ledger holds identities, settlements and commitments, and checks that every log only grows. Billions of agents has the identities that are built, the memory layer, Task Charters for orchestration, a network that phones, desktops and pooled stake can join, and the arithmetic that says how far each is from the target.

The notes

Open problems we would like help with

1. A lower bound on the cost of publicly verifiable, post-quantum payments without a signature each.
2. Netting: paying many payees from one escrow, with settlement cost independent of the number of payees.
3. Proving SHA3-256 hash walks cheaply inside hash-based proof systems.
4. Pricing proving work in fees, so that what is cheap to execute but expensive to prove cannot be used to stall the prover.
5. A composition theorem for the Assurance Algebra: when two claims each cost at least C to corrupt, what does a claim built on both cost?
6. A proof that rate limits carved additively down a tree of agents bound every subtree’s spending in any interval.
7. Proofs of completeness for memory queries that stay small for maps and facts that span long periods.
8. An encoding unique to each storage node that is cheap enough for a desktop and costly to redo on demand.

Write to the maintainers (see Responsible disclosure for the address) or open an issue once the repository is public.