How Siontology works.
A neo-blockchain pays for ordering only where the mathematics requires it, prices every assumption a claim rests on, and folds every proof into one. Each mechanism below comes with the demo, specification or code behind it, and with its status in the reference implementation.
Eight assumptions, inverted
What blockchains take for granted, what a neo-blockchain is designed to do instead, and the mechanism for each. The sections below take the mechanisms one at a time.
| Blockchains assume | A neo-blockchain inverts it | Mechanism |
|---|---|---|
| Verify by re-executing: every node repeats the work | Verify by checking a proof, at near-constant cost | Proof-carrying state; the Fold |
| Totally order every operation | Order only operations that conflict | Two-sorted state; Linear Lanes |
| The ledger knows only its own state | The ledger records claims about the world, with their assumptions priced | Claims; the Assurance Algebra |
| Transparent by default | Private by default, provable on demand | Compliance-by-proof (not built yet) |
| A human signs each action | Agents act inside limits the protocol enforces | Agent Charters |
| Market outcomes depend on who orders transactions | Market outcomes carry a certificate that no better allocation exists | Verifiable Clearing |
| Fees rise when demand meets fixed capacity | The cost per verified claim falls as volume grows | Batching, folding, sampling |
| One cryptographic assumption guards each function | Unrelated families guard authorization; independent implementations guard validity | Dual-origin signatures and proofs |
Lifecycle of a claim
A claim is the network’s unit of knowledge: a statement over committed data, with its evidence, its issuer, a formula of the assumptions it rests on, the bonds behind it and a window in which it can be challenged. Every claim goes through the same steps.
- Issue
A person, device, program or agent creates the claim and signs it under its account or Agent Charter.
- Check evidence
Proofs are verified; attestations are checked and their assumptions written into the claim’s trust formula.
- Publish
The payload, or a commitment to it, lands on the data layer and becomes available to sample.
- Order only if needed
A claim that spends or locks a resource, such as a fee, a payment or a bond, takes a lane certificate, or a consensus slot if the resource is contended. Pure knowledge skips this step.
- Join the knowledge log
The claim and its formula are appended to the grow-only knowledge log.
- Fold
The next World Proof covers the claim, its formula and its bonds.
- Use
A consumer checks the claim against the World Proof, computes its cost of corruption under its own policy, and acts or declines.
- Challenge
Until the window closes, anyone can post counter-evidence. A proven falsehood slashes the bonds behind the claim and compensates those who relied on it.
Two sorts of state
Every operation either adds knowledge or consumes a resource, and only consumption ever needs coordination. Publishing a verified claim never invalidates another claim; spending a coin removes the possibility of a second spend. The CALM theorem says exactly this: a distributed program can run without coordination when it only ever adds. Siontology makes the split part of its state model, and derives each transaction’s coordination class from what it touches; the sender never declares it.
| Class | Example | What must be prevented | Mechanism | Finality target |
|---|---|---|---|---|
| Knowledge | Issue a claim, attest, publish a proof | Nothing: claims never conflict | Availability and a proof check | One round trip to the data layer |
| Owned linear | Pay from your balance | The owner signing two spends of one version | Quorum certificate, no consensus | One round trip to the committee |
| Shared, bounded | Ticket inventory, budgets, rate limits | Overdrawing a shared total | Single-writer allotments (Escrow Lanes) | One round trip; rare rebalancing |
| Shared, contended | A liquidity pool, an auction | Conflicting updates to one object | Consensus per contention domain, batch clearing | One consensus round and one batch window |
Fig. 1Two sorts of state
Left: linear objects, such as coins and allotments. A spend consumes its inputs, which stay in state as tombstones (dashed), and creates new objects; every spend carries a lane certificate. Right: the knowledge log. Claims are appended and never conflict, so they need no ordering; the knowledge root and size grow with each claim. Nothing is ever deleted.
Linear Lanes
An owned object can be spent only by its owner, so the only thing to prevent is the owner signing two spends of the same version. Each validator approves a given object version for at most one transaction, and approvals from more than two thirds of the committee’s stake form a certificate. Two certificates for one version cannot both exist, because any two such quorums share an honest validator. That certificate is final: no consensus round, no global order, and nothing waits for unrelated traffic.
Post-quantum signatures are kilobytes, so validators do not sign each approval. Each one signs a single Merkle root over a batch of approvals; a certificate is a few references into signed batches.
Fig. 2Linear Lanes
An owner spends version 7 of a coin with transaction T1. Each validator locks (coin, version 7) to the first transaction it sees and signs its approvals in batches, one dual signature per batch. Approvals from more than two thirds of the committee's stake, here three of four, form a certificate: T1 is final without a consensus round. The owner then signs T2, spending the same version. V1 and V2 are locked to T1 and refuse. Even with a faulty V3 approving both, T2 reaches two of four and never a certificate, because any two quorums share an honest validator. V3's two approvals are signed evidence of equivocation: its whole stake is slashed, with a share to whoever reports it.
Escrow Lanes
A shared total, such as seats, a budget or a supply cap, is split into allotments that add up to it, each with a single writer. Each writer spends its allotment with ordinary lane certificates and never coordinates with the others. Only a rebalance, when an allotment runs low, goes through consensus, and the total is never exceeded. This is the escrow method of distributed databases, applied to a ledger; Agent Charters use it to keep an agent’s payments free of consensus.
Contention Consensus
Only objects that several parties contend for, such as a market, a shared account or a registry, need a total order. For them, validators run a DAG-based BFT protocol in which every validator proposes in every round, so one honest proposer is enough to get an intent in. Even rounds have a leader; once enough of the next round references it, the leader commits and orders its history. Market batches then clear at one price, so the order inside a batch carries no value.
The reference implementation runs a certified DAG in the Bullshark family and tests it in a deterministic simulator with an adversarial network phase. The architecture targets an uncertified DAG of the Mysticeti class, which commits in fewer message delays.
Fig. 3Contention Consensus
Each of four validators proposes a header every round, referencing at least three certificates from the round before. A header with votes from more than two thirds of the stake becomes a certificate (solid). Even rounds have a leader, the anchor, drawn with a second outline. Once certificates of the next round holding more than a third of the stake reference it, the anchor commits, and its history that is not yet ordered joins the committed sequence, by round and then by author. Only contended objects, such as a market or a shared registry, are ordered this way.
Data availability
A validity proof shows that a transition was correct; it cannot show that its data was published. So each Pulse’s data is erasure-coded in two dimensions and committed with hash-based roots, and every light client samples a few random shares. Withholding enough to prevent reconstruction means withholding more than a quarter of the extended square, which random samples find quickly. In the design, each client also serves the shares it sampled, so capacity grows with the number of clients; on the devnet, validators serve the shares.
Pr[withholding goes undetected by one client] ≤ (3/4)s s = 16: about 1% s = 30: about 0.02%
Fig. 4Data availability sampling
A Pulse's data is laid out as a k × k square, here k = 8, and extended with a two-dimensional Reed–Solomon code to 2k × 2k, so any half of a row or column rebuilds it. Rows and columns are committed with hash-based Merkle roots, which need no trusted setup. To make the data unrecoverable, a producer must withhold at least (k + 1)2 of the 4k2 shares, more than a quarter. A light client that samples s random shares misses the withholding with probability at most (3/4)s: about 1% at s = 16 and about 0.02% at s = 30.
The Fold
In the design, every Pulse the network folds the proofs produced since the last Pulse into one World Proof that certifies the whole history from genesis. Leaf proofs are made in parallel and aggregated pairwise; a million leaves need about 20 levels, and Pulse t+1 starts aggregating while Pulse t’s root finishes. The design aims for checking to cost the same in year ten as on day one, so that a phone can be as certain of the state’s validity as a data centre.
The World Proof for a Pulse states that a history exists from genesis to its state root in which:
- every linear transition followed its object’s rules and carried a valid committee certificate;
- every contended batch cleared under a valid optimality certificate;
- the knowledge log only grew, and every claim’s formula and bond references are correct;
- every forced-inclusion obligation older than its deadline was met;
- the data the history depends on was published and correctly encoded;
- every committee change followed the staking rules, so the chain of signers is valid from genesis.
Two independent proof stacks prove everything, and a World Proof is the pair of their roots. A soundness bug in one stack cannot forge the world. In the reference implementation both stacks verify by replay: the proofs have the bindings of succinct proofs but not their cost, and every report that checks one says so.
Fig. 5The Fold and two proof stacks
A Pulse executes as a chain of chunks, each with a statement binding the world before and after it; the last chunk is the deferred phase. Stack A, the reference executor, and stack B, an independent implementation written only from the specification, each verify every chunk. Their proofs fold pairwise into two roots, and the World Proof is the pair: a client accepts it only if both stacks accept. In the second Pulse shown, stack A has a hypothetical soundness bug and accepts an invalid chunk; stack B rejects it, so no World Proof exists for that Pulse. Today both stacks verify by replay: they bind the same statements a succinct proof would, but checking costs as much as executing.
Two levels of finality
| Level | What it guarantees | Who relies on it | Target |
|---|---|---|---|
| Certificate finality | More than two thirds of the committee approved it and will not approve a conflict, if fewer than a third are faulty | Users, merchants, agents | Under one second |
| Proof finality | The World Proof covers it; anyone can check validity without trusting the committee | Light clients, bridges, auditors | 10 to 30 s at launch; a few seconds at maturity |
The Assurance Algebra
Every claim carries a formula of the assumptions it rests on. Atoms are irreducible assumptions: a hash function’s collision resistance, a circuit’s correctness, a hardware enclave resisting its own host, a bonded attester’s honesty. A claim derived from several inputs takes their ∧; a claim backed by independent routes takes their ∨. From the formula, any consumer computes, under its own policy, the cheapest set of failures that would falsify the claim: its cost of corruption.
CoC(a) = cost(a) CoC(φ₁ ∧ φ₂) = min(CoC(φ₁), CoC(φ₂)) CoC(φ₁ ∨ φ₂) = CoC(φ₁) + CoC(φ₂)
An agent with value V at stake accepts a claim only when the rule below holds, where κ ≥ 1 is a safety factor, δ ≤ 1 discounts claims whose falsehood is rarely provable, and the adjudicator term caps trust at the cost of corrupting the dispute process. It then reserves κ·V of the claim’s backing, so the value relying on any claim never exceeds what slashing can repay. When alternatives share atoms, the exact cost is a hard problem, and the implementation reports a sound interval instead.
min(δ·CoClow(c), CoC(adjudicator)) ≥ κ·V
Fig. 6The Assurance Algebra
The worked example from the architecture paper. Invoice #1042 is payable if three inputs all hold (∧): delivery, confirmed by three independent witnesses bonded at 20,000 USD each (∨, so their bonds add up to 60,000); the invoice arithmetic, proven by two independent stacks (∞ under a policy that trusts the cryptography); and the supplier's identity, backed by a bank's 1,000,000 USD bond. The cost of corruption is the minimum over the ∧: 60,000 USD, so delivery is the weak link. A financier with 25,000 USD at risk and safety factor κ = 2 needs 50,000, accepts, and reserves 50,000 down the formula. A second financier asking the same is refused: only 10,000 USD of the delivery route is still unreserved.
Verifiable Clearing
Contended markets clear in sealed batches, and the winning solver must submit, with its allocation, a certificate that no better allocation exists. For a linear program, the allocation solves the primal and the prices solve the dual; by weak duality, no feasible allocation can beat it. Checking takes linear time however hard the problem was to solve, so anyone can run a solver and nobody can quietly extract value by controlling the order of transactions.
Ax* ≤ b x* ≥ 0 ATy* ≥ c y* ≥ 0 cTx* ≥ bTy* − ε
The certificate proves optimality for the orders as submitted; bidders can still misreport, and uniform-price batch auctions are not fully strategy-proof. Ties are broken by a perturbation drawn from the Pulse beacon after the batch seals, so the solver cannot choose the winners.
Fig. 7Verifiable Clearing
From the market demo. Four orders arrive during a batch window: agent-1 bids for 5 GPU-hours at up to 2.10 USD, agent-2 for 3 at up to 1.90; lab-a offers 5 at 1.80 or more, lab-b 6 at 2.00 or more. The batch seals with the Pulse's beacon, so nobody can reorder it, and the orders are revealed. The welfare-maximising allocation trades 5 GPU-hours. Every uniform price from 1.90 to 2.00 supports it, and the canonical price is the midpoint, 1.95 USD. The solver submits the allocation with its dual prices, and the ledger checks the certificate in linear time: both feasible, both non-negative, no duality gap. Everyone trades at one price, so a place in the batch is worth nothing.
Agent Charters
A charter is the contract between a principal and an AI agent, enforced by the protocol rather than by the agent’s code. Validators check every payment against it, so a hijacked or prompt-injected agent cannot exceed its caveats, and the worst case is known in advance. The agent spends from an allotment only it can write, so its payments need no consensus. Delegation can only narrow the caveats, and revoking a charter stops every sub-agent below it.
| Caveat | What it fixes |
|---|---|
| Payees | An allow-list of accounts the agent may pay |
| Per payment | The largest single payment |
| Burst and rate | A token bucket: the most the agent may spend at once, refilled by a fixed amount each Pulse. A sub-agent’s bucket is carved out of its parent’s, so a whole tree of agents pays no faster than its root may |
| Expiry | The Pulse after which the charter is dead |
| Evidence | Above a threshold, a payment needs a claim that passes the decision rule under a stated policy |
| Receipts | Every payment issues a receipt claim, backed by the principal’s bond |
| Delegation | Whether the agent may delegate, and only under strictly narrower caveats |
Fig. 8Agent Charters
From the agents demo. acme charters its agent: pay only gpu-cloud, at most 100 USD per payment and 250 USD at once, refilled at 0.025 USD a Pulse, a 1,000 USD budget, receipts on, 500 USD bonded behind the receipts. The agent pays gpu-cloud 80 USD and a receipt claim joins the knowledge log. Prompt-injected, it tries to pay mallory 90 USD: the ledger refuses, payee not allowed. It tries 150 USD: refused, above the per-payment limit. It delegates 100 USD to a sub-agent under narrower caveats, at most 20 USD per payment, and the sub-agent pays 20 USD. Once acme revokes the charter, both the agent and the sub-agent are refused.
Agent identities and subagents
An agent registered on the ledger has an identity of its own: an id, a card that says what it is, and a charter. It can launch subagents in one transaction, each with an identity, an account and limits carved out of its own, down to eight levels. Every charter keeps its lineage, so anyone can recompute each ancestor’s id by hashing. Suspending an agent stops every agent below it until it is resumed; revoking it stops them for good, and its principal reclaims what they did not spend.
A subagent need not hold keys. The ledger accepts its transactions only in a batch signed by its nearest ancestor that has keys, and one dual signature over a batch’s Merkle root authorizes up to 256 transactions, each with a receipt of its own.
Built on the devnetsion demo swarm --localsion demo batch --localSpecification v1.8, v1.13 and v1.14In the book
Memory logs
An agent’s or a robot’s memory is a log only it can append to. The entries stay with their writer; the ledger keeps the log’s size, root and index root, and moves them only along proofs that the log grew, so a rewritten past is refused. A reader asks about a span of space and time and gets a complete answer, with a proof checked against the head on the ledger. What to believe is computed by the reader, under its own policy.
The ledger stores the index root without checking it. Anyone who holds an entry an index left out can prove the omission from the head alone, but nothing on the ledger acts on that proof yet (impl:memory-index).
Built on the devnetsion demo robots --localSpecification v1.9In the book
Task Charters
Work is paid only when its result passes a rule fixed when the task is posted: the claims a result must rest on, who may attest it and who must, and the policy its cost of corruption must meet for the amount at stake. The payment is escrowed at posting and released once. The backing of a paid result stays reserved for the buyer, so a result shown false later, such as one from a grader that could be gamed, is repaid from the slashed bonds.
Built on the devnetsion demo tasks --localSpecification v1.10 and v1.15In the book
Storage deals
A client posts a deal for data named by its Merkle root: how many rounds, a price per proven round held in escrow, and the collateral a provider must post. In every round the provider answers a challenge for pieces drawn from the beacon of the round’s first Pulse. A proven round is paid and a missed one is not, and a provider that misses rounds can lose its collateral.
A proof shows that the provider could produce the pieces during the round, not that it keeps a copy of its own (storage:no-replication).
Built on the devnetsion demo storage --localSpecification v1.12In the book
Payment streams
Most payments between machines are small, frequent and between the same two parties. A payment stream pays each one without a transaction. The payer escrows funds for one payee and commits to a secret hash chain by publishing its last element. Each payment reveals the next element; the payee checks it with one SHA3-256 hash against the last one it accepted. Hash functions are the only cryptography a payment needs, so payments are post-quantum by construction.
The payee settles many payments in one transaction. A settlement can walk from the stream’s head, one hash per payment, or, if the payer also committed to a Merkle tree over every spacing-th element, jump to the checkpoint just below its position: at most spacing + 21 hashes, however many payments it covers. Anyone can check any payment later against what the ledger settled.
On one core, settlements by checkpoint covering about 9 × 108 payments a second executed with every signature checked. That is a measurement of the ledger’s side on one machine, not of a network, and stream payments are one-way, out of escrow. The research note has the construction, the safety argument, the capacity law, the prior art and the limits. Over HTTP, an x402 server accepts stream payments with --streams.
Fig. 9Payment streams: pay per call, settle per million
From the streams demo and the streams benchmark. The agent opened a payment stream to the API: an escrow, and the last element of a secret hash chain. Each call is paid with the next element, which the API checks with one SHA3-256 hash against the last one it accepted, 0.42 µs on one core; nothing per call reaches the ledger. The API then settles every payment so far in one transaction, ordered by consensus. With checkpoints, that settlement walks only to the checkpoint below its position and proves the checkpoint's Merkle path: 524 hashes and one signature check for 1,048,064 payments, about a nanosecond per payment on the ledger. Payments are one-way, from one payer to one payee, out of escrow the payer locked in advance, and the rates were measured on one core of a two-core machine, not on a network.
Forced inclusion
Censorship cannot be attributed the way equivocation can, so it is made visible instead. A user whose transactions are ignored posts them straight to consensus as forced intents. Every validator proposes every round, so one honest proposer is enough to order one. The state then holds the intent as an obligation of the sender’s shard, which has 8 Pulses to execute it. Every Pulse header commits to how many intents are pending and how many are overdue, so censorship by more than a third of a committee shows up in certified headers that every light client checks.
When a deadline passes and the intent could still execute, the state replaces the shard’s committee, drawing from validators outside it first, and the obligation stands for another window. The architecture also freezes the shard until it meets the obligation; the reference implementation keeps it running under its new committee.
Fig. 10Forced inclusion
From the censorship demo. A gateway silently drops a user's payment. The user posts it as a forced intent straight to consensus, where every validator proposes every round, so one honest proposer is enough; the shard's validators certify it among themselves and it executes. Then two of the shard's four validators censor as well, so no certificate, which needs three, can form. The shard has a window of 8 Pulses to execute the intent. When the deadline passes and the intent could still execute, every certified Pulse header counts it as overdue, any light client sees it, and the state replaces the shard's committee, drawing from validators outside it first, as drawn here. On the default devnet, four validators for four seats, the same members return and the intent stays owed. The architecture also freezes the shard until it meets the obligation; the implementation does not.
Validators, stake and epochs
Who certifies is part of the state transition. The validator set is an object in the state: a validator joins by staking with a proof that it holds its keys, takes its seat at the next epoch boundary, and leaves at a boundary, withdrawing its stake after an unbonding period. At each boundary the state pays the epoch’s validators a share of the fees collected during the epoch, by weight, picks the next active set by stake and reseeds the sampling of lane committees with the beacon. Every validator derives the same committees from its own copy of the state; nothing about them is configured.
Equivocation is signed evidence that anyone can submit: two consensus headers for one round, or two lane approvals of one object version. The whole stake is forfeited, the reporter receives a share of it (5 % on the devnet), and the validator loses its seat at the next boundary. A light client that pins the genesis follows the committee from epoch to epoch through boundary proofs.
On the devnet, validators stake devnet USD, which has no value. Siontology has no token and nothing is on offer. Fees are paid in stablecoins.
Fig. 11Staking, epochs and slashing
From the staking demo. A standby validator stakes 50,000 USD with a proof that it holds its keys and joins the active set at the next epoch boundary; the committees are re-derived from the state. It then signs two consensus headers for one round, and a watchdog reports the signed evidence. Its whole stake of 50,000 USD is forfeited, 2,500 USD of it (5 % on the devnet) goes to the watchdog, and it loses its seat at the next boundary. Every committee change follows rules in the state, so the World Proof covers it.
Targets and the devnet
The architecture paper sets targets that a public testnet must meet before anything else is built on them. None has been measured at scale.
| Quantity | Testnet target | Maturity target |
|---|---|---|
| Simple operations per second | 100,000 | 1.6 million |
| Owned-lane capacity per shard | 50,000 per second | 50,000 per second |
| Shards | 2 | 32 |
| Owned-lane certificate | 0.1 to 0.5 s, plus one batch-vote interval | |
| Contended commit | About 0.5 s, plus one batch window | |
| World Proof cadence | Every 10 to 30 s | Every second |
| Light-client check | Well under 1 s on a phone, still to be measured | |
| Parameter | Default |
|---|---|
| Validators and shards | 4 validators, 2 shards, 4 seats per shard committee |
| Pulse | 4 consensus rounds per Pulse; on two shared cores with dual post-quantum signatures, one Pulse every 3.9 seconds was measured |
| Rounds with nothing to order | Run back to back; with --idle-round-ms, the chain waits that long between them (10 seconds on the chain sion setup makes) |
| Lane approvals | Batched and signed every 25 ms |
| Proving | 16 transactions per chunk, replay proofs from two stacks |
| Forced inclusion | 8 Pulses to execute a forced intent |
| Payment streams | A walk settles at most 65,536 steps; a jump at most spacing + 21 hashes; 2 micro-USD per hash checked |
| Epochs | One epoch that never ends; --epoch-length sets Pulses per epoch and --standby adds validators without a seat |
| Light client | 16 data-availability samples per check |
To measure the primitives, execution, proving and a live devnet on your own machine, run sion bench. Post-quantum signatures and the trust model are on the security page; x402 and the agent interfaces are on the developers page, and the agent you run on your own computer on its own page.