Every TODA object carries its own verifiable integrity, authorization policy, and provenance — so it can be verified locally, even when disconnected from the authority that issued it. This is possible because TODA separates integrity from state management: the proof travels with the data instead of living in a system of record that must be queried. No blockchain, no shared ledger, no round-trip to a database.
Modern computing assumes that the system managing an object's state must also provide its integrity. Databases maintain both. Blockchains maintain both. Identity systems maintain both. Even conventional Zero Trust architectures ultimately depend on centralized policy services that continuously manage the current state of authorization.
For decades this coupling has been treated as unavoidable. TODA begins with a different observation.
State changes constantly. Files move. Databases replicate. Services migrate. Devices disconnect. Users delegate authority. Integrity should not depend on any of those things.
PROVENANCE
TODA is an open protocol originated and stewarded by TODAQ, with the specifications and formal proofs authored by Kris Coward, Dann Toliver, and Adam Gravitis. The reference implementation is published open-source at TODAQopen/toda. Related research is carried out with the Cambridge Centre for ReDecentralisation, co-founded by Jon Crowcroft, Carlos Molina-Jimenez, Dann Toliver, and Hazem Danny Nakib.
Tusculum Technology builds on TODA; it does not own it. This page is an independent explainer maintained by Tusculum. For the authoritative specifications, see trie.site.
A digital signature answers exactly one question: did this key sign these bytes? It does not answer three questions that become critical in distributed systems.
A signed object can be copied indefinitely. Every copy carries a perfectly valid signature. Nothing in the signature distinguishes an original from a duplicate.
The same signing key can legitimately sign two different states. A signature alone cannot distinguish the current state from a stale one.
A signature proves an approval occurred once. It cannot prove that the approval has not subsequently been revoked.
Traditional systems solve these by maintaining authoritative state on an online server. When that server becomes unreachable, so does the authority needed to answer any of them.
TODA treats integrity as a property of the object rather than the infrastructure. Every TODA object carries the cryptographic information necessary to verify who created it, how it evolved, which successor is canonical, what authority governs it, and whether the presented state remains valid.
Verification becomes a local cryptographic operation. No blockchain. No distributed consensus. No round-trip to a database. No dependency on continuous connectivity.
Once an object has been correctly rigged, its state may move between cloud services, laptops, mobile devices, edge systems, autonomous agents, or disconnected platforms while its integrity remains anchored to a trusted authority. Verification requires only the proof already contained within the object together with the integrity line to which it was anchored. This property — integrity-at-a-distance — is the central architectural idea behind the protocol.
TODA is not a replacement for cryptographic hashes, digital signatures, or Merkle structures — it builds upon them. Architects may recognize familiar shapes:
A named moment in an object's history.
The ordered sequence of states an object has passed through.
The proof structure binding states together.
The trusted authority line an asset is anchored to.
These comparisons are deliberately approximate — useful mental models, not formal definitions. TODA introduces primitives including hitches, rigs, and Asset-Integrity Lines that have no direct equivalent in existing systems.
Most distributed systems ask where is the authoritative database? TODA asks whether the object can prove its own integrity. Everything that follows — atoms, twists, lines, hitches, rigs, and abjects — is the machinery that makes that possible.
TODA constructs proof from the smallest possible units. Each layer adds structure until an entire chain of custody is encoded in the file itself.
An atom is an identifier (a cryptographic hash) concatenated with its matching packet (the content). An atom is valid if and only if hashing the packet produces the identifier's digest. No external authority needed — the math is the check.
Layout: alg | digest | shape | length | content. The shape byte describes the packet's data structure. The Atomic Serialization Protocol makes atoms self-describing in length and safely concatenatable into lists (lats).
A twist is a structured atom with six semantic slots: prev (link to prior state), teth (tether to another line), shld (cryptographic shield for hoisting), reqs (successor requirements), rigs (rigging key-value trie), and carg (application cargo).
A fast twist has a non-NULL tether — these are the structural load-bearers of a rig. A loose twist has a NULL tether and carries state but no rigging obligations. Legitimate successors must cryptographically satisfy the predecessor's reqs — via ECDSA or Ed25519 signatures, or weighted multi-party approval lists.
A line is a sequence of twists where each is the unique predecessor of the next via the prev hash. Because each twist includes the hash of its predecessor, every twist has exactly one history — but potentially multiple futures. The past is immutable; the future is the problem.
Resolving which future is canonical is precisely what rigging solves. A segment has defined endpoints. Lines can extend indefinitely. The integrity of succession flows from the requirements/satisfactions (reqsats) system and the hitch mechanism above it.
A hitch connects two lines: a topline (the trusted authority, called the corkline in a rig) and a footline (the managed asset, called the leadline). The hitch's hoist — a twist on the topline — canonizes the meet as the unique legitimate successor of the lead.
Shielding prevents anyone, including the topline operator, from squatting the hoist slot before it's committed. Once published, the proof is immutable. If the topline hasn't equivocated, the footline can't either.
A rig is a collection of twists with a corkline and a leadline, sufficient to prove that the leadline holds fast to the corkline — meaning the corkline causally precedes the entire leadline segment. Rigs are built by composing hitches with two operations:
Splicing (horizontal) extends the leadline across time by chaining consecutive hitches. Lashing (vertical) adds intermediate lines between the leadline and corkline, enabling indirect tethering. The guild G↑ — all rigs closed under splicing and lashing — is formally proven supportive: no double-spend is possible.
An ADOT Object — or abject — is the application layer of TODA. An abject is a list of atoms (a lat) with a final focus atom that defines its class. Each class has an interpreter that consumes the abject and produces a view object: a natural, ergonomic representation within the host environment (a string, integer, typed object, or stateful entity).
View objects carry one of three proof statuses: valid (proof data fully satisfying), incomplete (proof data missing), or invalid (provably wrong). A twisted abject's interpreter walks its line, invisibly skipping twists that belong to other classes — allowing multiple abject types to coexist on a single line. Interpreters in different languages must produce identical abjects even when their view objects differ.
A hitch involves exactly five twists in precise positional relationships. Together they construct a proof that a specific twist on the footline (the meet) is the unique canonical successor of the lead.
The key mechanism: the hoist is the first twist on the topline after the fastener to include a shielded version of the lead's identifier as a rigging trie key. Because only the footline operator knows the shield secret (stored in lead.shld), no one can pre-emptively occupy that slot with a conflicting value.
Two entries are required in the hoist's rigging trie — a single-shielded and double-shielded pair — creating a mathematical proof that the hoist was authored by the footline operator and that the meet is authentic. Once the hoist is committed to the topline, the lead's secret is safely disclosed to complete the proof. The verification is entirely local.
The guild G↑ — all rigs closed under splicing and lashing operations — is formally proven to be supportive. A supportive guild cannot contain misaligned rigs: no two conflicting states of an object can both be certified as valid. This is the mathematical guarantee that prevents double-spend.
If two rigs in G↑ share a common twist on their leadlines and their corklines are aligned, the leadlines must be aligned too. Theorem 3 (proved by structural induction) guarantees no conflicting histories can coexist for the same object.
The proof is local. Verifying a TODA file's integrity requires only the atoms inside the file itself — no network call, no consensus round, no chain query. The math is the ledger. Settlement can complete in under 100ms.
State management and integrity are fully decoupled. An asset's current state can live on any untrusted server, phone, or device — while its cryptographic lineage remains anchored to a trusted authority it may never need to contact again.
| Property | Blockchain / Ledger | TODA Protocol |
|---|---|---|
| Settlement speed | Seconds–minutes (block time + confirmations) | Sub-100ms, atomic per request |
| Proof verification | Requires live chain query or full node | Offline — the file carries its own proof |
| Transaction cost | Gas fees — can exceed the payment itself | Under $0.01, no gas, no minimum |
| Global consensus | Required — all nodes must agree before finality | Not required — local cryptographic proof suffices |
| Custody model | Lose seed phrase = lose asset permanently | Delegated custody with recovery options |
| Micropayments | Impractical — gas and latency dominate | Native — per-call, per-byte, per-outcome |
| Double-spend prevention | Via global consensus (slow) | Via G↑ supportiveness theorem (local) |
| State mobility | Tied to the ledger's location and availability | State moves freely; integrity stays anchored |
This page describes the protocol, not the products built on it. TODA is running in production today as a commercial payment and ownership rail — that work is TODAQ's, and it is the best place to see the protocol's guarantees operationalized rather than described.
The originator and steward of TODA. TODAQ builds the commercial infrastructure on the protocol — digital ownership, media licensing, and the full payment stack — and publishes the engineering documentation for building against it.
The clearest working example of integrity-at-a-distance under load: an MCP rail where AI agents discover, pay for, and earn from APIs in-flight — per call, atomic, verified without a round-trip to a central ledger.
TODA is an open research project as much as it is a product protocol. The specifications are maintained as living documents, and the underlying cryptographic theory was co-developed with academic partners.
T.R.I.E. is the research group that authors and maintains the TODA protocol specifications. trie.site is the canonical home for all living documents — meaning the specs evolve alongside the protocol rather than being frozen at a version.
The Rigging Specification is the normative description of atoms, twists, lines, hitches, rigs, status objects, and the traversal algorithm. The Abject Specification defines the application layer: ADOT Objects (abjects), interpreters, view objects, primitive types (Boolean, String, Float), R1 relationships, M1 media wrapping, and the rules for line traversal across multi-class lines.
The Simple Rigs Hold Fast paper provides the formal mathematical proofs — Theorem 1 (GH is supportive), Theorem 2 (Ψ(G) preserves supportiveness), and Theorem 3 (G↑ is supportive) — that underpin the double-spend prevention guarantee.
The Centre for ReDecentralisation (CRDC) at Cambridge's Department of Computer Science and Technology pursues research into new technological primitives that can rebuild digital infrastructure without extractive intermediaries — reinstating the internet's original principles of decentralisation, openness, and inclusivity.
The CRDC was co-founded in 2019 by Jon Crowcroft, Carlos Molina-Jimenez, Dann Toliver (TODAQ's Chief Science Officer), and Hazem Danny Nakib. TODAQ has contributed infrastructure to several CRDC research initiatives, including the FEWD (Fair Exchange Without Disputes) protocol — a provably fair, privacy-preserving exchange mechanism with no disputes upon completion — and to smart sustainable city projects in collaboration with Unijui University and the city of Santa Rosa, Brazil.
Related work includes the CAMB project (Cloud Attestables on Morello Boards, £525K UKRI-funded) and ongoing research into decentralised smart contracts and attestable systems.
The reference implementation of the protocol is published open-source as TODAQopen/toda — a JavaScript library covering atom serialization, twist construction, rigging, and the traversal algorithm described in the Rigging Specification. A Clojure implementation also exists.
TODAQ maintains engineering documentation and API references for building against the protocol, including the Digital Twin service. These are the practical starting points for integrating TODA into an application, as distinct from the normative specifications hosted at trie.site.