Five Stacks in Search of an Architecture
What the Race to Verify AI Still Cannot Govern
In a matter of weeks, Europe's AI policy moved in two directions at once. EU institutions adopted a Digital Omnibus that simplifies parts of the AI Act and defers its most consequential high-risk deadlines,1 while leaving most of the Act's transparency regime on its original schedule. The Commission, meanwhile, has pressed a tech-sovereignty agenda aimed at tightening European control over the cloud, compute, chips, and data infrastructure on which AI depends. Europe is renegotiating when its AI rules bite, while moving the sovereignty fight down the stack — from labels on artificially generated content to control over the infrastructure that produces and serves it.
That only looks contradictory if you still expect verification to arrive as a rule. It points to something the technology world is already working out in practice: verification is shifting from a rule you impose to an infrastructure you build.
That shift has started to acquire names, products, drafts, and papers. Chainlink has announced a "Verifiable AI Stack." Mysten Labs has positioned Walrus, Nautilus, and Seal within the broader Sui Stack. EigenLayer has published a formal paper; EigenCloud has launched EigenAI on mainnet alpha. The IETF SCITT Working Group's architecture draft, approved by the IESG, now sits in the RFC Editor Queue awaiting publication as a Proposed Standard. A fifth answer is not a system but a map: the Verifiable Trust Stack, a five-layer model describing what the others are still building.
None is complete, but incompleteness is not the point. What matters is what each fails to address, and how those failures cluster.
This essay maps those answers. The absences are not random: stacks inherit questions before they inherit components, and the question a stack inherits determines what it can verify, what it treats as foundational, and what it leaves outside the frame. What none of the five inherits, at least not explicitly, is the political philosophy of who gets to verify reality.
That absence matters more in what I have elsewhere called the post-perception era — an era in which perception is no longer sufficient to distinguish what is authentic from what is fabricated, and verification becomes the structural alternative to assumed trust. The question is who builds that alternative, and according to which theory of authority.
Five answers, four kinds
The five stacks are not the same kind of object. The taxonomy is imperfect, but useful. Comparing them as feature sets would miss the more interesting point: five answers have arrived, but they fall into four kinds.
Chainlink and Sui are commercial vendor stacks — different architectures (Chainlink oracle-led and horizontal, Sui infrastructure-led and vertical), but both vendor-defined attempts to make verification operational through a broader platform. Chainlink routes off-chain data, computation, and compliance through Decentralized Oracle Networks and the Chainlink Runtime Environment (CRE). Sui composes storage, access control, and attested compute through Walrus, Seal, and Nautilus around its Layer 1 coordination plane.
EigenAI is a formal engineering proposal: bit-exact inference, optimistic re-execution, economic slashing, threshold key management, and trusted execution environments (TEEs). It is unusually explicit about what it cannot verify. It verifies inference, not intelligence.
SCITT is a standards-track interoperability substrate: signed statements, transparency services, verifiable receipts, and SCRAPI as the HTTP interface for registration and verification. It is content-agnostic by design: it does not know what an AI model is, and that is part of its strength.
The Verifiable Trust Stack is a conceptual model with five layers: Production, Agents, Execution, Registry, Identity. Its contribution is conceptual rather than deployable: it maps what deployable systems are trying, separately and unevenly, to do.
The taxonomy does real work here. Each kind of object inherits a different question, and therefore leaves out a different part of the trust problem.
What they share
The differences matter. But the same few things keep recurring across all of them.
First, none assumes that AI itself becomes native to the chain. The model remains outside. Verification happens around it: through receipts, attestations, statements, commitments, logs, enclaves, signatures, or consensus mechanisms.
Second, none eliminates intermediaries. They redistribute them. Chainlink distributes trust across oracle operators; Sui across storage committees, key servers, and cloud-rooted attestation; EigenAI across restakers, verifiers, key-management shards, and TEEs; SCITT across issuers, transparency services, auditors, and relying parties. The Verifiable Trust Stack describes that redistribution as the central move. Kevin Werbach had this part right: blockchain does not abolish trust, it relocates it.
Third, all five shift the burden from institutional assertion toward cryptographic evidence. Receipts, attestations, signatures, and inclusion proofs do not replace the bank, the notary, the regulator, or the auditor; they change what those institutions are asked to confirm.
Fourth, each claims some version of decentralization while depending on at least one centralized root of trust. Sui's Nautilus currently anchors Nitro Enclave attestation to AWS as the root certificate authority. EigenAI's confidential re-execution depends on TEE vendor attestation. Chainlink's CRE deployment is gated by Early Access approval. SCITT pushes trust policy to relying parties, who must still choose which transparency services they accept.
Their dependence on centralized roots is not hypocrisy; it is an honest artifact of the current problem. Verification systems rarely remove trust. They make it more explicit, more distributed, and sometimes more contestable.
What they disagree about
The disagreements are more revealing than the agreements because they expose each stack's intellectual lineage.
Chainlink inherits the oracle problem: how can smart contracts trust external data? Its answer is consensus computing. The Verifiable AI Stack is best understood as an extension of an existing oracle architecture, presented in the language of AI verification.
Sui inherits the infrastructure question: how do you compose a complete Web3 stack vertically? Walrus stores artifacts. Seal controls access. Nautilus attests computation. AI is not the founding problem. It is one workload the stack can support.
EigenAI inherits the rollup question: how can a result be accepted cheaply, challenged efficiently, and penalized economically? It takes the logic of optimistic verification and applies it to LLM inference. The lineage is explicit: rollups, restaking, deterministic systems, trusted hardware.
SCITT inherits the transparency-log question: how can signed claims become independently auditable across organizational boundaries? It generalizes a Certificate Transparency intuition to arbitrary supply-chain artifacts — less exciting than the others in one sense, more important in another: it does not try to run the system. It records what the system claims.
The Verifiable Trust Stack inherits something different: the political philosophy of infrastructure, drawn from Langdon Winner, Paul Starr, Tim Wu, Primavera De Filippi, and Aaron Wright. From that lineage comes the recognition that the choice between centralized and decentralized verification is constitutional, not merely technical.
These lineages are not footnotes. They determine what each stack treats as foundational. Chainlink treats external data as the problem. Sui treats infrastructure composition as the problem. EigenAI treats reproducible inference as the problem. SCITT treats accountable claims as the problem. The Verifiable Trust Stack treats the distribution of verification power as the problem.
That is why their gaps take different shapes.
What none of them mechanizes
The most revealing convergence is what remains absent in all five.
Chainlink encodes compliance. Sui encodes access control. EigenAI governs parameters — stake requirements, slashing fractions, challenge thresholds. SCITT delegates trust policy to relying parties. Each mechanizes some form of governance. None mechanizes the governance of legitimacy.
The unanswered questions are familiar, but they become sharper once the technical pieces are in view. Who should be accepted as a legitimate issuer? Which models should be allowed to act in domains of consequence — health, justice, credit, public information? Who governs the cloud provider whose enclave is the compute root of trust? Who arbitrates when a verifiably executed output is socially harmful?
The problem is less an engineering failure than a lineage failure. The oracle problem, the rollup question, the transparency-log question, and the infrastructure question are technical traditions: they produce mechanisms that work, but do not, by themselves, contain a political philosophy of legitimacy.
The Verifiable Trust Stack is the partial exception. It names the problem because it inherits a constitutional view of infrastructure, yet still does not model governance as a layer. Governance is the argument's centre of gravity, not yet a component of the stack.
The political layer is not idle; it is building elsewhere, along a different axis. As these stacks were shipping, the European Commission clarified a Cloud Sovereignty Framework that scores providers across forty-eight criteria2 — a direct attempt to govern which infrastructure may sit beneath sensitive computation. But that governs the location and control of the machine, not the legitimacy of what it certifies. Even the most assertive regulator is answering "whose cloud can we trust?", not "who is entitled to verify what is true?"
That distinction is the missing layer.
A verifiably executed wrong model is still wrong. Consensus among oracle operators can agree on a hallucination. Slashing can enforce consistency, not truth. Receipts prove that claims were made, not that they were true.
What this means
In the post-perception era, verification stops being a rule imposed after the fact and becomes the structural alternative to assumed trust. That alternative is now arriving through different kinds of objects: vendor stacks, engineering proposals, interoperability standards, and conceptual models. Their gaps follow from their lineages.
The complete stack of verifiable trust will not emerge from any one of these proposals. It will emerge, if it emerges at all, from the collision between commercial vendor stacks, formal engineering, interoperability standards, and the political theory that none of them currently carries.
The five stacks examined here are necessary. None is sufficient. Each reveals the shape of a question the others have not asked.
The next eighteen months will determine whether this collision produces an architecture or a fragmentation. The question is not which stack wins. It is who, if anyone, is willing to govern the layer that none of them inherits.
Notes
- The Council of the EU gave final adoption to the Digital Omnibus on AI on 29 June 2026 (press release 553/26). The regulation defers stand-alone high-risk obligations to 2 December 2027 and high-risk systems embedded in regulated products to 2 August 2028, while most Article 50 transparency obligations remain due 2 August 2026. It enters into force on the third day after publication in the Official Journal. ↩
- European Commission, Cloud Sovereignty Framework (clarified June 2026). Providers are scored across 48 criteria grouped into eight categories: strategic; legal and jurisdictional; data and AI; operational; supply chain; technological; security and compliance; and environmental sustainability. ↩
Sources
- David Ribeiro Alves, Vishnu Patankar, Matheus Pereira, Jamie Stephens, Nima Vaziri, and Sreeram Kannan, "EigenAI: Deterministic Inference, Verifiable Results," arXiv:2602.00182 (2026).
- IETF SCITT Working Group, "An Architecture for Trustworthy and Transparent Digital Supply Chains," draft-ietf-scitt-architecture (RFC-to-be 9943), RFC Editor Queue.
- Kevin Werbach, The Blockchain and the New Architecture of Trust (MIT Press, 2018).
- Regulation (EU) 2024/1689 (Artificial Intelligence Act) and the Digital Omnibus on AI (2026).