The protocol paper

Receipts architecture

The governing rule of this project is that no claim exists without a proof affordance. That is an architectural commitment, not an editorial one: it constrains what the protocol emits.

Every economically meaningful act produces a durable on-chain object with a stable identity — a listed book, a capacity lease, a fill with its deadlines, a settlement batch, a clearing price print, a challenge and its verdict, an emergency action with its reason code. Those objects are readable by anyone through a read API that requires no key, because prices and receipts that gate behind permission are not receipts.

The consequence for a reader: any number on this site should terminate in an object you can fetch yourself. Where a number cannot yet do that — because the service is a stub, or because the data is replayed — the surface says so in place of the link. The labels are part of the architecture; they are what keeps the rule true while the system is incomplete.

What this does not claim: that a receipt proves quality. A receipt proves what was charged, metered, delivered, and disputed. Whether the model behind a private delivery was the model promised is, in the general case, not objectively provable on chain today — the protocol says so, restricts slashing to faults it can verify deterministically, and keeps heuristics away from money entirely.

The five laws: what the protocol keeps, what a gateway gets

A gateway (a relay, this site, any front end) is a convenience. The split below is what makes it a convenience rather than a dependency — each law is enforced by the state machine, not by our restraint.

The test of the split is simple: if every gateway vanished tonight, the chain would still hold the money, still clear at one price, still settle, and still refuse to rewrite what it settled. The market would be harder to reach. It would not be gone.

Verification: the boundary, and the claim we will not make

The hardest question a buyer can ask is "did the weights you promised actually produce this?" The honest answer starts with a limit: literal per-request provenance is impossible. If a conforming backend and a cheating one produce the same distribution of everything the venue can observe, no verifier distinguishes them — and no bond, rating, or benchmark changes that. Zero-knowledge inference and universal attested execution are not viable base layers at this cost, so the practical route is a binding execution receipt plus audits chosen after the receipt is committed, backed by collateral large enough to make evasion uneconomic.

That machinery — execution receipts bound to a versioned model and execution profile, post-commitment audit selection, a canonical verification fleet, an enforcement ladder, and venue indemnification — is designed, not built. None of it runs today.

we will never say “Every response is cryptographically proven to have been produced by the exact advertised weights.”

what a guaranteed product may say, once it exists “Every guaranteed response is bound to a versioned model and execution profile by an online execution receipt. Audit selection occurs only after commitment. Sellers maintain collateral against nonconformance, and the exchange automatically compensates buyers for validated violations.”

Today Freeside offers no guaranteed lane, so it makes neither claim. What it does say is narrower and checkable: usage is metered, the output is committed by hash, faults that are objectively provable are slashable, and everything else is reputation — never money. When a guaranteed product ships it will publish its assurance parameters with it: hardware envelope, verifier version, expected false-rejection rate, detection power by downgrade class, audit rate, maximum seller exposure, settlement and challenge windows, reserve coverage, and the date and volume of the most recent clean audits. A guarantee without those numbers is a slogan.

The era ladder

A roadmap, labelled by the same convention the enforcement tables use — because a roadmap that reads like a feature list is how protocols end up lying by tense.

Nothing in Era 2 and beyond should be read as present-tense capability. Where this site's copy has ever implied otherwise, that is a defect — the same class of defect as an unlabelled price — and worth reporting.