What Siontology is for.

Agents that cannot overspend

For

Companies that let AI agents spend money: on compute, data, API calls or goods, on someone’s behalf.

Today

An agent’s limits live in its own code, its prompt or a card’s settings, so a prompt injection, a bug or a stolen key can spend whatever the agent can reach. Gartner expects AI agents to intermediate 90% of B2B buying, more than 15 trillion USD, by 2028 (Gartner).

With Siontology

An Agent Charter is an object on the ledger that fixes whom the agent may pay, how much per payment and how fast, its budget, and who answers for it. Validators check every payment against the charter before it executes.

What changes

The worst case is known before the agent starts: at most its budget, only to listed payees. A compromised agent is stopped by the ledger, not by its own judgement, and revoking the charter stops the agent and every sub-agent it created.

Status

Built on the devnet
Not built: limits on which models may act under a charter, and adapters for other agent-payment standards such as AP2 and ERC-8004. The agent sion setup makes on your computer runs under a charter: Your agent.

1. Charter

   The company creates a charter: payees, a limit per payment, a burst and a rate that cap how fast it spends, a budget, receipts on, and a bond behind the agent’s receipts.

2. Pay

   The agent pays a listed payee within its limits. The payment executes and its receipt joins the knowledge log.

3. Refuse

   A payment to an unlisted payee, or above a limit, is refused by the validators, whatever the agent was told.

4. Delegate

   The agent can give a sub-agent part of its budget under narrower limits, never wider ones.

5. Revoke

   One transaction revokes the charter. Once it executes, the agent and all its sub-agents are refused.

== Agent Charters: an AI agent with a budget the ledger enforces ==
Pulse   5  acme charters its agent: pay only gpu-cloud, ≤ 100 USD per payment, ≤ 250 USD at once (refilled at 0.025 USD a Pulse), 1,000 USD budget, receipts on, 500 USD bond behind the agent's receipts
Pulse   7  agent pays gpu-cloud 80 USD for inference: accepted; receipt claim 0586a32c joins the knowledge log
Pulse  11  a prompt-injected agent tries to pay mallory 90 USD → refused by the ledger: charter caveat violated: payee not allowed
Pulse  13  the agent tries a 150 USD payment → refused by the ledger: charter caveat violated: payment 150 above per-payment limit 100
Pulse  16  agent delegates 100 USD to a sub-agent under narrower caveats (≤ 20 USD per payment)
Pulse  19  sub-agent pays gpu-cloud 20 USD: accepted
Pulse  21  acme revokes the charter (ordered by consensus)
Pulse  24  acme-agent tries to pay again → charter caveat violated: charter revoked
Pulse  26  sub-agent tries to pay again → charter caveat violated: charter revoked
           the agent's receipt is a claim backed by acme's bond: cost to forge it 500 USD
Result: gpu-cloud received 100 USD; mallory received nothing; the limits lived in the ledger, not the agent.

APIs paid per request

For

Anyone selling an API, a dataset or a model behind an HTTP endpoint, and the agents that buy from them.

Today

A card payment costs more than one API call is worth, so APIs are sold as monthly plans behind accounts, API keys and invoices. US merchants paid 198.25 billion USD in card fees in 2025 (Nilson data, via the Merchants Payments Coalition).

With Siontology

The API answers a request with HTTP 402 Payment Required and a quote. It speaks x402, the open standard for payments over HTTP, a Linux Foundation project, with two ways to pay. An agent that calls once pays in a stablecoin, under its charter if it has one, and the server checks the payment as a light client before it answers. An agent that calls often opens a payment stream to the API once, then pays each call with the next element of a hash chain, which the server checks with one hash; the server settles thousands or millions of calls in one transaction.

What changes

No accounts, keys or invoices. Every request is paid and checked before it is served, a replayed payment is refused, and an agent cannot pay more than its charter or its stream allows. With a stream, a call costs the server under a microsecond to check and the ledger about two nano-USD in fees, measured.

Status

Built on the devnet
x402 version 2 with the exact scheme and Siontology’s stream scheme, not yet tested against third-party x402 clients. Streams pay one API, one way, out of escrow the agent locks in advance.

1. Ask

   The agent requests a resource. The server answers 402 with a quote: price, payee, chain and a fresh nonce.

2. Pay

   The agent signs a payment whose purpose names the quote, and retries the request with it.

3. Check

   The server submits the payment, waits for it to execute and verifies the receipt the way a light client would: committee certificate, certified order, inclusion proof.

4. Serve

   Only then does the API answer 200 OK. The same payment cannot buy a second request.

== x402: an AI agent pays an API per request, inside limits the ledger enforces ==
Pulse   5  acme charters its agent: pay only carol, ≤ 1 USD per payment, ≤ 2 USD at once (refilled at 0.0002 USD a Pulse), 20 USD budget
           carol serves a forecast API at http://127.0.0.1:40599: 0.25 USD per call, settled on sion:2f26b9fadb06e03c561a06361b3354b3
           agent: GET /v1/forecast → 402 Payment Required: 0.25 USD to carol (quote 8d1bf36a213b7147c743a76a7b5f591b)
Pulse   8  agent pays under its charter (purpose x402:<quote>) and retries → 200 OK {"region":"eu-west","gpu_hours":18250,"confidence":0.82}
           carol's server answered only after verifying the receipt as a light client: committee certificate, certified order, inclusion proof
           replaying the same PAYMENT-SIGNATURE → 402: unknown quote, or one already used
           agent: GET /v1/report (5 USD) → pays → the ledger refused the payment: charter caveat violated: payment 5 above per-payment limit 1; carol's API answers 402 and serves nothing
Pulse  13  bob, a person without a charter, pays the same API with a plain transfer → 200 OK
Result: no accounts, no API keys; every request is paid and proven before it is served, and the agent's limits live in the ledger, not in its prompt.

sion x402 serve carol --price 0.25
# serves http://127.0.0.1:8402/v1/resource for 0.25 USD a request

sion x402 fetch http://127.0.0.1:8402/v1/resource --wallet dana --max 1

For an agent that calls the same API often, a payment stream replaces the transaction per call:

1. Open

   The agent escrows funds for the API and publishes the last element of a secret hash chain, once.

2. Pay

   Each call carries the next element of the chain. The server checks it with one hash and serves at once; nothing goes to the ledger.

3. Settle

   From time to time the server settles everything it has accepted in one transaction, proven by a checkpoint, for a fee that does not grow with the number of calls.

== Streams: an agent pays an API a tenth of a cent per call, one hash per payment ==
Pulse   5  the agent opens a stream to carol: 20 USD in escrow, 0.001 USD a step, 100,000 steps; carol may settle until Pulse 2002
           carol's API at http://127.0.0.1:38625/v1/price: 0.001 USD per call, paid by `exact` (a transaction per call) or `stream` (a hash per call)
           one call paid with a transfer: a transaction, certified and proven, 0.0011 USD in fees
           2,000 calls paid from the stream in 0.6 s: carol's server checked 2,220 hashes and sent no transaction per call
           carol settled 2,000 payments in 2 transactions: 2 USD received, 0.002388 USD in fees (1.19 micro-USD per payment, against 1,100 for a transaction per call)
           the validators checked 44 hashes for those settlements (2 proven by a jump to a checkpoint), not one per payment; the stream is at position 2,000 with 18 USD left in escrow
           an auditor checks call 1,234's receipt: genuine and settled, in 766 hashes from the settled head, or 45 from the checkpoint below it
           a forged receipt for the same call → not an element of the stream's chain
Pulse  14  carol closes the stream; the agent gets 18 USD back
Result: each payment costs the server one hash, not a signature; a settlement costs the ledger the same however many payments it covers; and every payment stays checkable by anyone.

sion x402 serve carol --price 0.001 --streams

sion stream open dana carol --unit 0.001 --deposit 5
# prints the stream's ID; each call below is paid with one hash
sion x402 fetch http://127.0.0.1:8402/v1/resource --stream <ID> --count 1000

sion bench --only streams   # what a payment costs the API and the ledger

Receipts for AI output

For

AI providers that must mark what their models generate, and the platforms, newsrooms and courts that need to check it.

Today

The EU AI Act has required machine-readable marking of AI-generated content since 2 August 2026, and systems already on the market must comply by 2 December 2026 (timeline). A watermark inside the content can be stripped or imitated, and a provider’s own database vouches only for itself.

With Siontology

The provider issues a receipt for each output: a claim naming the model, the time and a hash of the content. Each receipt carries a formula of what it rests on, such as the provider’s signature, a hardware attestation and a bond.

What changes

Anyone can check a receipt against the ledger, and see what forging it would cost under their own assumptions, without trusting the provider’s database. The design target is under 0.0001 USD per receipt.

Status

Claims and their pricing built on the devnet
Not built: a receipt service that commits many outputs in one claim, and an SDK for providers. The cost per receipt has not been measured.

1. Bond

   The provider posts a bond behind its receipts.

2. Issue

   Each output gets a receipt whose formula is the provider’s signature and either a hardware attestation or the bond.

3. Price

   A consumer computes the receipt’s cost of corruption under its own policy: whether it trusts the hardware, distrusts it, or prices an attack on it.

4. Decide

   The consumer relies on the receipt only if that cost covers its value at risk, times a safety factor.

== Inference receipts: what would it cost to forge this answer? ==
Pulse  78  inference-co bonds 5,000 USD behind its receipts
Pulse  80  receipt issued  [dual-signature ∧ (TEE quote: nvidia-h100 ∨ bond:inference-co)]
           standard policy: cost to forge = 6,000 USD  (TEE attack ≈ 1,000 USD + 5,000 USD bond)
           the TEE's attack cost deters forgery but cannot repay anyone; only the bond is slashable
           standard           relying on 2000 USD → ACCEPT: cost of corruption 6,000 covers κ·V = 4,000
           standard           relying on 3000 USD → REJECT: only 5,000 of backing is unreserved; κ·V = 6,000 is needed
           assumes TEE broken relying on 2000 USD → ACCEPT: cost of corruption 5,000 covers κ·V = 4,000
           assumes TEE broken relying on 3000 USD → REJECT: cost of corruption 5,000 (after detection discount 1000/1000) is below κ·V = 6,000
           trusts the TEE     relying on 2000 USD → ACCEPT: cost of corruption ∞ covers κ·V = 4,000
           trusts the TEE     relying on 3000 USD → ACCEPT: cost of corruption ∞ covers κ·V = 6,000
Result: every consumer prices the same receipt under its own assumptions; trust is a number, not a brand.

Payments a deepfake cannot approve

For

Finance and treasury teams, and anyone who moves large payments on instructions given by voice, video or email.

Today

US victims reported a record 20.9 billion USD in losses in 2025, 3.05 billion of it from business email compromise (FBI IC3). One deepfake video call cost the engineering firm Arup about 25.6 million USD (CNN).

With Siontology

The treasury’s payment agent works under a charter that requires evidence above a threshold: a mandate claim from the people or systems that must agree, each backed by a bond. The payment executes only if what the approvers would forfeit by lying exceeds the amount at risk.

What changes

Imitating a face or a voice is no longer enough. An attacker has to corrupt approvers whose bonds exceed the payment, and what they forfeit repays the loss.

Status

Partly built
Charters already refuse a payment above a threshold without a claim that passes the decision rule, and claims, bonds and slashing are built. The approval workflow and the apps around it are not.

1. Set the rule

   The treasury charters its payment agent: above a threshold, a payment needs a claim that passes the decision rule.

2. Request

   A payment request arrives by call or email, and the agent prepares the payment.

3. Approve

   The approvers issue a mandate claim, each backed by a bond. Its formula names whose approval it rests on.

4. Check

   Validators compute the claim’s cost of corruption. The payment executes only if it covers the amount times the safety factor.

5. Repay

   If an approval is proven false, its bond is slashed and compensates the payer.

Invoices that repay you if they are false

For

Invoice financiers, trade-finance platforms and marketplaces that pay out before goods are confirmed.

Today

A financier that funds a false invoice recovers through insurers or the courts, if at all.

With Siontology

The supplier, the shipper and an arbiter each post a bond behind what they attest. The invoice is a claim whose formula names those attestations, so its cost of corruption is what a forger would have to forfeit. A financier relies on it only up to what that covers, reserves that much of the backing so nobody else can count on the same bonds, and is repaid from slashed bonds if a challenge proves the invoice false.

What changes

Reliance on a false invoice is repaid in full, a few Pulses after the ruling, without a lawsuit, from bonds posted in advance.

Status

Built on the devnet
Rulings come from an adjudicator named in each claim; there is no network of adjudicators yet.

1. Bond

   The supplier bonds 30,000 USD behind its invoices, the shipper 20,000 USD behind its deliveries, and an arbiter 100,000 USD behind its rulings.

2. Attest

   The shipper attests the delivery; the supplier issues the invoice for 10,000 USD, resting on its own bond or on the delivery.

3. Price

   The invoice’s cost of corruption is 50,000 USD: a forger must corrupt both routes.

4. Fund

   A financier relies on 10,000 USD with a safety factor of 2 and reserves 20,000 USD of the backing. A request to rely on 30,000 USD is refused.

5. Repay

   The buyer challenges, the arbiter upholds, the bonds are slashed, and the financier is repaid 10,000 USD automatically.

== Invoice #1042: trade finance on insured knowledge ==
Pulse   6  supplier bonds 30,000 USD behind "invoices"
Pulse   8  shipper bonds 20,000 USD behind "logistics"
Pulse  10  judge bonds 100,000 USD behind "arbitration"
Pulse  12  shipper attests "Shipment for invoice #1042 delivered"  [dual-signature ∧ bond:shipper]
Pulse  15  supplier issues "Invoice #1042: 10,000 USD payable"  [dual-signature ∧ (bond:supplier ∨ delivery)]
           cost of corruption (standard policy): 50,000 USD, exact
           = 30,000 (supplier's bond) + 20,000 (shipper's bond): a forger must corrupt both routes
           rely on  10000 USD at κ = 2 → ACCEPT: cost of corruption 50,000 covers κ·V = 20,000
           rely on  30000 USD at κ = 2 → REJECT: cost of corruption 50,000 (after detection discount 1000/1000) is below κ·V = 60,000
Pulse  18  financier funds the invoice and reserves 20,000 USD of its backing (κ·V): nobody else can rely on the same bonds beyond what slashing can repay
Pulse  20  buyer challenges the supplier's attestation (deposit 1,000 USD)
Pulse  22  judge upholds: supplier's bond slashed (30,000 USD); the invoice still holds through the delivery route
Pulse  24  buyer challenges the shipper's delivery attestation, under the shipper's own adjudicator
Pulse  26  judge upholds: 2 claims falsified (the delivery, and the invoice resting on it)
           financier compensated 10,000 USD automatically from the slashed bonds (balance 199,999.9988 → 209,999.9988)
Result: reliance on a false invoice was repaid in full, in Pulses, with no lawsuit and no adjuster.

Markets that prove their prices

For

Marketplaces for GPU compute, energy and other goods that clear many orders at once, and the buyers and sellers who use them.

Today

Matching engines are black boxes. Participants cannot check that the allocation was the best available, and when the order of arrival decides who trades, arriving first is worth money and gets gamed.

With Siontology

Orders are sealed into a batch with the Pulse’s random beacon, so nobody can reorder them. A solver computes the allocation that maximises total welfare and submits it with a certificate, its dual prices; the ledger checks the certificate in linear time and settles everyone at one price.

What changes

Every batch carries proof that no better allocation existed. A place in the batch is worth nothing, so there is nothing to front-run.

Status

Built on the devnet
Sealed double auctions and assignment markets. Convex and combinatorial markets are designs.

== Verifiable Clearing: a GPU-hour market that proves it is optimal ==
Pulse  56  operator opens a market: batches of 12 Pulses, sealed with the beacon, cleared by anyone with a certificate
Pulse  61  agent-1 bids for 5 GPU-hours at ≤ 2.10 USD: Success
Pulse  62  agent-2 bids for 3 GPU-hours at ≤ 1.90 USD: Success
Pulse  62  lab-a offers 5 GPU-hours at ≤ 1.80 USD: Success
Pulse  62  lab-b offers 6 GPU-hours at ≤ 2.00 USD: Success
           batch 5 sealed with the Pulse beacon 18f40c60 — 4 orders, nobody can reorder them now
           solver computes the welfare-maximizing allocation: 5 GPU-hours at one price 1.95 USD (supporting band 1.9–2), welfare 1.5 USD, with an LP optimality certificate
Pulse  73  the ledger checks the certificate in linear time and settles everyone at that price
           agent-1  now holds 5 GPU-hours and 990.2488 USD
           agent-2  now holds 0 GPU-hours and 999.9988 USD
           lab-a    now holds 0 GPU-hours and 109.7488 USD
           lab-b    now holds 6 GPU-hours and 99.9988 USD
Result: one uniform, certified-optimal price; a place in the batch is worth nothing, so there is nothing to front-run.

Work paid only when it passes

For

AI labs buying evaluations, training environments and rollouts; anyone, human or agent, paying for work whose result can be checked.

Today

Work is paid for up front or on someone’s say-so. If an environment’s grader turns out to reward a shortcut instead of the task, every result it passed was paid for, and the buyer absorbs the loss.

With Siontology

A Task Charter escrows the payment together with the rule a result must pass, fixed when the task is posted: the claims every result must rest on (the vendor’s bonded claim that its grader has no known exploit), the verifiers whose attestations count and those who must attest, and the buyer’s policy for how much backing it needs. Nobody’s attestation of their own result counts.

What changes

The worker is paid once, and only for a result whose backing passes the rule. The buyer’s reliance on a paid result stays backed: if the grader is later proven exploitable, every result resting on it falls and the buyer is repaid from the vendor’s bond, while whoever found the exploit is paid from it too. An agent posts tasks from its own budget, under its charter’s limits.

Status

Built on the devnet
Not built: running the work or the grader (they stay off the ledger), and adapters for existing eval and training frameworks.

1. Back

   The environment vendor bonds behind its claim that its grader cannot be gamed; reviewers bond behind their attestations.

2. Post

   The buyer, or its agent from its budget, escrows the payment with the rule fixed: required claims, verifiers and who must attest, policy.

3. Settle

   The worker submits a result committed to the task and its output. It is paid only if the result’s backing passes the rule, and only once.

4. Repay

   A red team proves the grader exploitable; the arbiter upholds it. The vendor’s bond repays the buyer for the results it paid for, and the red team is paid for the find.

== Task Charters: paying for work only when the result passes a rule fixed in advance ==
           bonds: sandbox-vendor 5,000 USD behind its environment, arbiter 3,000, reviewers 1,000 each, coder 100
Pulse  20  sandbox-vendor claims "swe-sandbox-7 has no known exploit that passes grader g-3"  [backed by its 5,000 USD bond]
Pulse  22  lab registers its eval orchestrator with a 1,000 USD budget, at most 500 USD per task
Pulse  25  the orchestrator posts task 9db4d57b: 150 USD escrowed for coder, from its budget. Fixed now: a result must rest on
           sandbox-vendor's claim, may be attested by reviewer-1 or reviewer-2, and must pass the lab's policy at κ = 2
Pulse  27  …and task 7c243653: a 40 USD bounty open to anyone, on the same terms, except that reviewer-2 must attest a result
           coder submits patch-4711; reviewer-1 and reviewer-2 each attest that it passes, on their own bonds
Pulse  47  coder claims the 150 USD on its own 100 USD bond → refused by the ledger: invalid transaction: result not accepted: cost of corruption 90 (after detection discount 900/1000) is below κ·V = 300; only 100 of backing is unreserved; κ·V = 300 is needed
Pulse  50  coder settles with both attestations: cost of corruption 2,100 USD (100 + 1,000 + 1,000) covers κ·V = 300 → paid 150 USD; 300 USD of that backing reserved for the lab
Pulse  53  coder settles again → refused by the ledger: invalid transaction: the task is not open: a task is paid once
Pulse  55  bounty-hunter tries the bounty without reviewer-2's attestation → refused by the ledger: invalid transaction: every verifier the task says must attest has to attest the result
Pulse  58  bounty-hunter settles the open bounty with reviewer-2's attestation → paid 40 USD
Pulse  63  the orchestrator withdraws an unclaimed bounty: 30 USD back to the lab
Pulse  65  red-team shows that grader g-3 accepts any patch that deletes the failing test, and challenges the vendor's claim
Pulse  68  arbiter upholds it: the vendor's bond is slashed, and 5 claims fall: the environment's, and the 4 results resting on it, paid or not
           the lab is compensated 190 USD from the vendor's bond for the two results it paid for (lab +190 USD)
           red-team gets its deposit back and a share of the slashed bond: +2,505 USD, a bounty for the reward hack paid by the vendor

Memory a robot cannot rewrite

For

Teams building robots and AI agents whose memory others must rely on: fleets sharing a warehouse, agents acting for customers, anyone who will one day be asked what the machine knew, and when.

Today

An agent’s or a robot’s memory is a file or a database its operator can edit. After an incident, nobody can prove what it had recorded, when it recorded it, or that nothing was left out.

With Siontology

Each robot or agent writes its memories to its own log, off the ledger: observations with place and time, facts, beliefs, camera frames sealed under a key. The ledger keeps each log’s head and moves it only along proofs that the log grew, so the past cannot be rewritten, and the Pulse of each commit is when the memories were recorded.

What changes

A reader checks a complete answer to a question about a place and a time against the head on the ledger, including “nothing was recorded there”. Two readers can fold the same evidence into different beliefs under their own policies, each checkable. An index that hides a memory can be convicted by anyone holding it, and a frame can be forgotten by destroying its key while the log still proves it existed.

Status

Built on the devnet
Not built: the ledger acting on proof that an index left a memory out, and memory written from an agent’s budget.

1. Record

   A robot records what it sees, with place and time, in a log only it can append to, tied to its identity.

2. Commit

   It commits the log’s new head to the ledger with a proof that the log only grew. A rewritten past is refused.

3. Ask

   A reader asks what was recorded in an aisle during a minute, and checks the complete answer against the head.

4. Convict

   An index that leaves a memory out is convicted from the head alone by anyone holding that memory.

== Memory for robots: a warehouse two robots share, kept append-only by the ledger ==
           fleet gives robot-alpha and robot-beta agent identities of their own
           each robot opens a memory log only it can append to, tied to its identity; the curator opens one too
Pulse  17  robot-alpha commits its log: pallet-17 seen in aisle 4. This Pulse is the observation's transaction time; the robot cannot backdate it
Pulse  19  robot-beta commits its log: aisle 4 scanned 10 s later, empty
           a reader asks robot-alpha for everything it recorded in aisle 4 during that minute: 1 atom, with a 263-byte proof checked against the head on the ledger
           and for aisle 9: 0 atoms, with a proof that it recorded nothing there
Pulse  21  robot-alpha tries to replace its observation with one in aisle 5: refused by the ledger: invalid transaction: the new head does not extend the log: invalid proof: equal sizes require equal roots
Pulse  25  the curator records that the two robots disagree, then refutes robot-alpha's observation
           a reader trusting the curator believes the observation refuted; one trusting only robot-alpha believes it accepted. Same evidence, two beliefs, each checked against the heads on the ledger
Pulse  29  robot-beta commits 2 more scans, with an index that leaves out its scan of aisle 4 (the ledger stores index roots without checking them)
           anyone holding that scan proves the omission from the head on the ledger alone, with a 517-byte fraud proof
Pulse  31  robot-alpha stores a camera frame encrypted under its memory space's key (readable: true), then forgets it by destroying the key (readable: false); the log still proves the frame existed
Pulse  34  fleet suspends robot-alpha; at Pulse 37 its next commit is refused by the ledger: charter caveat violated: charter suspended

Storage that proves itself every round

For

Anyone who keeps data with someone else, including agents and robots keeping their memory; and anyone with a computer and spare disk.

Today

You take a storage provider’s word that your data is still there, until the day you need it back.

With Siontology

A storage deal fixes the data by its Merkle root and escrows a price per round. The provider puts up collateral, and each round shows pieces of the data picked by a challenge nobody could predict, checked by the ledger against the root.

What changes

The provider is paid for every round it proves; the client gets back what it paid for rounds that were not proven. A provider that cannot produce the pieces it is asked for misses the round and loses collateral in proportion, all of it if it gives up; the more data it lost, the sooner a challenge finds it. Proofs touch only the provider’s own record, so one transaction proves many deals. Any computer running the app can be a provider.

Status

Built on the devnet
Not built: proof that a provider keeps a copy of its own rather than fetching one when challenged, retrieval the ledger enforces (a client can fetch its data from a provider that serves it, checked against the deal’s root, but nothing makes the provider answer), and repair of a failed deal.

1. Post

   The client escrows a price per round for data fixed by its root, and says where providers can fetch it.

2. Accept

   A provider fetches the data, checks it against the root, and puts up collateral.

3. Prove

   Each round, it shows the pieces the round’s challenge picks, with their Merkle paths.

4. Close

   The provider is paid for proven rounds and gets its collateral back, less what its missed rounds cost; the client gets the rest of its escrow.

== Storage for agents: a robot's memory kept by devices it pays, proven every round ==
Pulse   7  robot-gamma commits 400 observations of a patrol; the head's manifest is the root of their archive (88 KiB, 23 leaves of at most 4 KiB)
Pulse   9  robot-gamma posts an open deal for the archive: 6 rounds of 16 Pulses at 0.5 USD a proven round (3 USD in escrow), 4 leaves challenged a round, 3 USD of collateral
Pulse  11  and a deal for its camera footage (16 leaves) with the phone, on the same terms
           a laptop and a phone run providers: each fetches a deal's data from its locator in the background, checks it hashes to the deal's root, posts the collateral, then proves every round
           laptop: fetching deal 54fef09d from file://…/storage/robot-gamma/patrol-archive.bin
           phone:  fetching deal e6c488cb from file://…/storage/robot-gamma/camera.bin
           laptop: Pulse 16: Done: laptop accepted storage deal 54fef09d (custody record 1a9dc946); rounds start at Pulse 24; fee 0.0012 USD.
           phone:  Pulse 18: Done: phone accepted storage deal e6c488cb (custody record a86a1d8b); rounds start at Pulse 24; fee 0.0012 USD.
           the phone then quietly keeps only leaves 0 to 7 of the footage, to save space: the deal still pays it, as long as nobody asks for the rest
           round 0: the phone is asked for leaves [7, 0, 8, 11]; it lost 2 of them and cannot answer
           laptop: Pulse 28: Done: round 0 of storage deal 54fef09d proven; fee 0.0027 USD.
           round 1: the phone is asked for leaves [9, 0, 8, 5]; it lost 2 of them and cannot answer
           laptop: Pulse 43: Done: round 1 of storage deal 54fef09d proven; fee 0.0027 USD.
           round 2: the phone is asked for leaves [2, 2, 10, 6]; it lost 1 of them and cannot answer
           laptop: Pulse 58: Done: round 2 of storage deal 54fef09d proven; fee 0.0027 USD.
Pulse  74  robot-gamma closes the footage deal (abandoned): 3 round(s) missed; 3 USD of escrow back, 0 USD paid for what the phone proved, its collateral of 3 USD forfeited to the treasury
           laptop: Pulse 77: Done: round 3 of storage deal 54fef09d proven; fee 0.0027 USD.
           laptop: Pulse 79: Done: 2 USD paid for 4 proven round(s) of storage deal 54fef09d; fee 0.0011 USD.
           laptop: Pulse 90: Done: round 4 of storage deal 54fef09d proven; fee 0.0027 USD.
           laptop: Pulse 107: Done: round 5 of storage deal 54fef09d proven; fee 0.0027 USD.
           laptop: Pulse 122: Done: storage deal 54fef09d closed: 0 USD refunded, 1 USD paid, 3 USD of collateral returned, 0 USD forfeited, 0 round(s) missed; fee 0.0011 USD.
           the laptop proved 6 of 6 rounds (0 missed): paid 3 USD and its collateral returned; it kept the archive the whole time
           a reader checks two objects on the ledger: robot-gamma's memory head names manifest 86cfe894, and the deal the laptop proved commits to root 86cfe894: the memory the robot committed is the data that was kept
           what a proof shows: the provider could produce the challenged leaves during the round; not that it stores its own copy (no proof of replication)

Settlement with compliance proven

For

Fintechs, remittance companies and payment providers that move stablecoins across borders.

Today

Sending 200 USD abroad costs 6.36% on average, and 14.99% through banks (World Bank, Q3 2025). Financial-crime compliance costs 206.1 billion USD a year (LexisNexis, 2023).

With Siontology

Stablecoin transfers settle on the ledger in seconds and stay private by default. KYC, Travel Rule and sanctions checks are proven with zero-knowledge proofs: the receiving institution learns that the checks passed, not the data behind them.

What changes

The design goal is a few cents per transfer, with compliance checked once, in a proof, instead of repeated by every intermediary.

Status

Not built
Stablecoin transfers run on the devnet with public amounts. Confidential amounts and compliance proofs need a zero-knowledge proof stack that is not built yet.

Provenance that survives a platform

For

Newsrooms, camera makers, creators and platforms that publish media with C2PA content credentials.

Today

Platforms strip content credentials on upload. In one Washington Post test, none of eight platforms kept an AI video’s credentials (report).

With Siontology

A media manifest is registered as a claim. When a platform strips the metadata, the claim is found again by the content’s hash, and a revoked manifest shows as revoked.

What changes

Provenance stops depending on every platform keeping metadata intact.

Status

Not built
A claim can carry a manifest’s hash today; the C2PA adapter and lookup by content hash are not built.