The four-layer technology stack of the CCTI project.
Source: sources/proposals/2026-06-17-aria-ccti-proposal-draft-2.md.
Layers
1. Primitives layer. Existing mechanisms for verifiable and privacy-preserving computation: TEEs, zk-SNARKs, MPC, zkVMs. Stated policy: start pragmatically with what exists, aim for formally verified implementations where possible, and minimise dependency on trusted hardware over time except as defence in depth. TEEs are named as the fastest way to get started — explicitly a crutch, and M5 makes removing the trusted-hardware assumption a gate criterion.
2. Attested evidence layer (WP-A, Cambridge). Several cryptographically attested evidence types plus their provenance:
| Evidence type | Claims about |
|---|---|
| Sensor data | the physical world |
| Business data | cross-organisational interaction |
| EIC | an agent’s own reasoning |
| Recursive proofs | claims supported by another instance of the same infrastructure |
Deliverable: an open-source reference implementation for heterogeneous attestation types and ZK-provable multi-dimensional reputation.
⟨Added 2026-08-17: the top and bottom rows of that table already have published, implemented instances by CCTI’s own people. Man & Kleppmann (2026), by the Cambridge Co-PI, combines signed sensor data with recursive proofs and measures the result; the earlier Heiss et al. (2023), by a SINE-side member of this programme, does the sensor-data half in supply chains with a two-level device PKI. See Verifiable Carbon Accounting.
Tension to keep visible: both papers place their trust anchor in a tamper-resistant signing meter or sensor. That is the same class of assumption as the TEE crutch above, and M5 commits the project to removing it. Neither paper removes it; Kleppmann’s conclusion states the trusted set explicitly (meter, manufacturer, certificate authorities, grid operator). ⟨Inference: so the honest reading of layer 2 is that attestation is solved and the trustworthiness of the attesting device is not — which makes it the sharpest open research question in the stack, not a detail of implementation.⟩⟩
3. Verifiable query/rule layer — zkDB (WP-B, Cambridge). Evidence processing starts as use-case-specific logic (TEE enclaves, SNARK circuits, zkVM programs). As common requirements emerge, these are generalised into a scalable rule system inspired by database query engines, with a declarative language for domain rules — verifiable querying over heterogeneous attested facts, reducible to general-purpose code.
The language is under an explicit kill switch: at M4 it must show demonstrable advantages over general-purpose code across two use cases, or be downgraded to general-purpose code.
4. Application layer. Matching and reputation built on the lower layers, plus LLM-based agent prototypes used to test experimentally whether agents can exploit the infrastructure — see AI Advantage.
Note on the shape of the claim
⟨Inference: the interesting design bet is layer 3. Layers 1–2 are assembly of known cryptography; the wager is that a query language over attested facts is a general enough abstraction to be worth having — and the project pre-commits to abandoning it if two use cases do not demonstrate that. That is the same move as SINE’s methodology work elsewhere: find the shared abstraction across use cases, or accept that there isn’t one.⟩
Relation to SINE’s existing crypto work
SINE’s public open-source line is MPC/garbled circuits (Polytune, Garble, Tandem — see SINE Foundation). CCTI adds zk-SNARKs, zkVMs and TEEs to the assumed competence base, with the ZK engineering depth resident at Ink & Switch UK and the TEE depth at Light Squares.
An outside argument for the attested-data layer (Upright, 2026)
Added 2026-09-10. The clearest external case for WP-A found so far comes from a company that has never heard of CCTI. Upright’s red-teaming — a self-reported 45 breaks against 25 LLMs across 12 lab-sponsored prompt-injection scenarios, self-published and not independently replicated (evidentiary health warning) — reports that models are now well hardened against being asked to misbehave and remain vulnerable to being told:
“They are, however, far more vulnerable to content that asks for little, and instead supplies facts that lead the model to invent the conclusion itself: that this action, right now, is the right thing to do.” — Ojala, 2026
⟨Inference: if the attack surface is facts rather than instructions, instruction-filtering cannot be the defence, because the payload contains no instruction. The only property distinguishing a real fact from an attacker’s fact is provenance — which is exactly what the attested-data layer produces. Arm’s-length from SINE, and better pitch material for WP-A than anything the consortium has authored. Use it in ARIA-facing and cohort-facing framing — but pitch it as one vendor’s red-team result, not as an established empirical fact: the numbers are self-reported and the harness is closed.⟩
⟨Lint 2026-09-14: the sentence above previously read “Empirically-backed, independent” — an overstatement that would have carried the vendor’s own figures outward as settled evidence.⟩
The converse also holds: a reasoning system with no attested inputs converges on its own priors rather than on the world — see Coherence as a truth substitute. The two halves are complementary: reasoning without an anchor on one side, anchor without reasoning on the other.
What this stack is a substitute for ⟨added 2026-10-26⟩
Li et al., Agentic Communication Networks (2026) builds trust for cross-domain agents out of a different kit: DIDs, PKI, digital signatures, MFA, zero-trust access control, capability-based authorisation, policy engines, guardrails, anomaly detection, security knowledge graphs, “standardized audit logs and tamper-resistant records”, blockchain-based evidence preservation and trusted timestamps (§5.5). The only gestures toward this page’s primitives layer are the unelaborated terms “trusted computing” and “confidential communication”. ZK, MPC and zkVMs do not appear.
⟨Inference: that gives the stack above a concrete alternative to be measured against, which it previously lacked. The two architectures differ in where the trust anchor sits, not in whether there is one:
| ACN | this stack | |
|---|---|---|
| Anchor | the audit record, and whoever keeps it | the signing sensor (today), ideally nothing (M5) |
| Claim form | authorised, logged | verifiable |
| Cross-domain | requires each party to accept another’s log | requires no acceptance |
The second row of the ACN column is its weakness and the second row of this column is its cost. Worth stating both ways: a tamper-resistant log is tamper-resistant against outsiders and is an assertion with respect to its keeper — but this stack’s own published instances (Man & Kleppmann, Heiss et al.) still anchor in a tamper-resistant signing meter, which is an assumption of the same family moved one layer down. The contrast is sharper in principle than in deployed practice until M5.⟩
Developed on Agent identity and delegated authority.
Where an OECD report puts this stack ⟨added 2026-10-27⟩
OECD (2026) is the first policy-level document in this wiki to inventory these instruments rather than pass over them. Box 3.2 names four PET categories — federated learning, secure multi-party computation, trusted execution environments (confidential computing; “Data Control Rooms” = enclave + policy enforcement + audit), synthetic data — which is this page’s primitives layer minus ZK and zkVMs.
Its positioning is worth adopting, because it is stronger than either “cryptography solves this” or “cryptography is irrelevant”:
a data space connector negotiates a contract that specifies not only who may access data and for what purpose, but through which PET the data must be processed. This makes the choice of privacy technology an enforceable element of the data-sharing agreement. The provider no longer needs to trust the recipient’s compliance because the technology structurally limits what can be done with the data.
The complementary claim runs in both directions. Against the contractual stack: “once data leave the provider’s infrastructure, enforcement depends on the data user’s compliance” — usage control is an assertion about future behaviour, and provenance logs convert prevention into “deterrence through accountability”. Against this stack: PETs “do not address the institutional co-ordination problem of who governs, who pays and how collective value is allocated” (§3.2), and their adoption barrier is “the need for co-ordination among participants on which technologies to deploy” (Auñón et al., 2024) — a governance problem, not an engineering one.
⟨Inference: this gives the stack above a second thing to be measured against, alongside the ACN comparison. Where ACN’s anchor is the audit record and this stack’s is the signing sensor, the data-space anchor is the contract plus the connector that enforces it — and the OECD’s own assessment is that the anchor holds only up to the point of handover.
| ACN | Data spaces (IDS-RAM/DSP) | this stack | |
|---|---|---|---|
| Anchor | the audit record, and whoever keeps it | the negotiated contract + connector | the signing sensor (today), ideally nothing (M5) |
| After handover | logged | depends on the recipient’s compliance | still constrained |
| Cost | log acceptance across domains | full-stack adoption, incl. negotiation layer even for permissive policies | computation, expertise, agreement on which PET |
The third column’s cost row is the OECD’s objection to us, and it is not a technical one. “Agreement on which PET” is a standards problem, which is the thing SINE already does.⟩
ODS-RAM is the architectural counterpoint worth noting: unlike IDS-RAM it makes contracting optional and prescribes only interfaces, explicitly accommodating TEEs and differential privacy as alternative mechanisms. A stack of this kind can be plugged into ODS-RAM without displacing it.
Related: data space boundary conditions · the confidentiality gap.
Sources
sources/research/2026-10-27-oecd-data-spaces-co-ordination-viability-public-policy/2026-10-27-oecd-data-spaces-co-ordination-viability-public-policy.md(Box 3.2, §3.2, §3.3.2, §3.3.3, §5.5) — see the paper page. Earlier sections of this page cite the sources named inline.