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 assumeA neo-blockchain inverts itMechanism
Verify by re-executing: every node repeats the workVerify by checking a proof, at near-constant costProof-carrying state; the Fold
Totally order every operationOrder only operations that conflictTwo-sorted state; Linear Lanes
The ledger knows only its own stateThe ledger records claims about the world, with their assumptions pricedClaims; the Assurance Algebra
Transparent by defaultPrivate by default, provable on demandCompliance-by-proof (not built yet)
A human signs each actionAgents act inside limits the protocol enforcesAgent Charters
Market outcomes depend on who orders transactionsMarket outcomes carry a certificate that no better allocation existsVerifiable Clearing
Fees rise when demand meets fixed capacityThe cost per verified claim falls as volume growsBatching, folding, sampling
One cryptographic assumption guards each functionUnrelated families guard authorization; independent implementations guard validityDual-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.

  1. Issue

    A person, device, program or agent creates the claim and signs it under its account or Agent Charter.

  2. Check evidence

    Proofs are verified; attestations are checked and their assumptions written into the claim’s trust formula.

  3. Publish

    The payload, or a commitment to it, lands on the data layer and becomes available to sample.

  4. 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.

  5. Join the knowledge log

    The claim and its formula are appended to the grow-only knowledge log.

  6. Fold

    The next World Proof covers the claim, its formula and its bonds.

  7. Use

    A consumer checks the claim against the World Proof, computes its cost of corruption under its own policy, and acts or declines.

  8. 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.

Coordination classes, from the architecture paper. The finality targets are design targets.
ClassExampleWhat must be preventedMechanismFinality target
KnowledgeIssue a claim, attest, publish a proofNothing: claims never conflictAvailability and a proof checkOne round trip to the data layer
Owned linearPay from your balanceThe owner signing two spends of one versionQuorum certificate, no consensusOne round trip to the committee
Shared, boundedTicket inventory, budgets, rate limitsOverdrawing a shared totalSingle-writer allotments (Escrow Lanes)One round trip; rare rebalancing
Shared, contendedA liquidity pool, an auctionConflicting updates to one objectConsensus per contention domain, batch clearingOne 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.

Status
Built

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.

Status
Built

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.

Status
Simplified: a certified DAG; the design targets an uncertified one

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.

Run it
sion verify --samples 16
Status
Built

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:

  1. every linear transition followed its object’s rules and carried a valid committee certificate;
  2. every contended batch cleared under a valid optimality certificate;
  3. the knowledge log only grew, and every claim’s formula and bond references are correct;
  4. every forced-inclusion obligation older than its deadline was met;
  5. the data the history depends on was published and correctly encoded;
  6. 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.

Run it
sion verify --chain <identity>
Status
Simulated: replay proofs with real bindings

Two levels of finality

From the architecture paper. Targets are design targets, not measurements.
LevelWhat it guaranteesWho relies on itTarget
Certificate finalityMore than two thirds of the committee approved it and will not approve a conflict, if fewer than a third are faultyUsers, merchants, agentsUnder one second
Proof finalityThe World Proof covers it; anyone can check validity without trusting the committeeLight clients, bridges, auditors10 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.

Run it
sion demo invoice --local
Status
Built

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.

Run it
sion demo market --local
Status
Built

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.

Caveats the reference implementation enforces.
CaveatWhat it fixes
PayeesAn allow-list of accounts the agent may pay
Per paymentThe largest single payment
Burst and rateA 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
ExpiryThe Pulse after which the charter is dead
EvidenceAbove a threshold, a payment needs a claim that passes the decision rule under a stated policy
ReceiptsEvery payment issues a receipt claim, backed by the principal’s bond
DelegationWhether 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.

Run it
sion demo agents --local
Status
Built

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.

Run it
sion demo streams --local
Status
Built on the devnet; measured on one machine

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.

Run it
sion demo censorship --local
Status
Simplified: committee rotation, but the shard is not frozen

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.

Run it
sion demo staking --local
Status
Built on the devnet

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.

Design targets from the architecture paper.
QuantityTestnet targetMaturity target
Simple operations per second100,0001.6 million
Owned-lane capacity per shard50,000 per second50,000 per second
Shards232
Owned-lane certificate0.1 to 0.5 s, plus one batch-vote interval
Contended commitAbout 0.5 s, plus one batch window
World Proof cadenceEvery 10 to 30 sEvery second
Light-client checkWell under 1 s on a phone, still to be measured
The devnet, from the repository’s defaults.
ParameterDefault
Validators and shards4 validators, 2 shards, 4 seats per shard committee
Pulse4 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 orderRun back to back; with --idle-round-ms, the chain waits that long between them (10 seconds on the chain sion setup makes)
Lane approvalsBatched and signed every 25 ms
Proving16 transactions per chunk, replay proofs from two stacks
Forced inclusion8 Pulses to execute a forced intent
Payment streamsA walk settles at most 65,536 steps; a jump at most spacing + 21 hashes; 2 micro-USD per hash checked
EpochsOne epoch that never ends; --epoch-length sets Pulses per epoch and --standby adds validators without a seat
Light client16 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.