Chainless Apps: A Modular Framework for Building Apps with Web2 Capability and Web3 Trust

Brian Seong; Paul Gebheim

REVIEW 4 major objections 6 minor 21 references

Chainless Apps: A Modular Framework for Building Apps with Web2 Capability and Web3 Trust

T0 review · 4 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper proposes a modular Chainless App architecture that separates execution, trust, bridging, and settlement to offer Web2 speed with Web3-grade verifiability.

desk verdict Chainless Apps is a readable architecture synthesis whose central claim—that Agglayer keeps cross-chain transfers safe even under weak internal trust models—does not survive the paper's own description of pessimistic proofs as an aggregate balance check. read the letter →

arxiv 2505.22989 v1 pith:BM42XAHZ submitted 2025-05-29 cs.CR

Brian Seong , Paul Gebheim This is my paper

classification cs.CR

keywords ChainlessAppsverifiablecomputeapp-specificsequencingcross-chaininteroperabilitypessimisticproofszero-knowledgevirtualmachinetrustedexecutionenvironmentsettlementlayer

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to establish that the familiar blockchain trade-off between user experience and trust is not inevitable. Its Chainless App architecture runs an application's logic off-chain under its own sequencing, records an execution trace, verifies that trace through zero-knowledge virtual machines, trusted execution environments, or validator committees, and then settles final state on a base chain through a unified interoperability protocol called Agglayer. The paper argues that because this protocol enforces pessimistic proofs, cross-chain asset withdrawals remain safe even when individual apps rely on weak internal trust. The intended payoff, demonstrated with a spot-trading proof of concept, is centralized-exchange-like speed with self-custody and verifiable, cross-chain settlement.

What carries the argument

The load-bearing mechanism is the layered decomposition itself, with Agglayer—a cross-chain interoperability and settlement protocol that the paper puts at the center of the model—carrying the safety claim. Agglayer's Unified Bridge standardizes asset and message routing across connected chains, its pessimistic-proof invariant checks that no chain withdraws more than it deposited, and its proof aggregation bundles multiple validity proofs into a single settlement submission. The second central object is the execution trace: each Chainless App records an ordered sequence of state transitions off-chain and commits it with Merkle roots or hash chains, giving the trust layer a deterministic artifact to replay or prove.

What would settle it

Construct a Chainless App that deliberately emits incorrect execution traces, skips trust-layer verification entirely, and sends conflicting withdrawals to two different chains through the interoperability layer; if the settlement contracts accept cumulative withdrawals greater than the original deposit, the pessimistic-proof invariant is refuted. Inspecting the bridge contracts for exactly such an over-withdrawal path is the direct empirical test.

Watch

Extended reading notes

Core claim

The central claim, stated on the paper's own terms, is that execution, trust, bridging, and settlement can be decomposed into independent composable layers, letting each application behave like its own sovereign execution chain without deploying one. Each app sequences its own transactions, logs ordered state transitions off-chain, and commits them cryptographically; the trust layer verifies those transitions using zkVM proofs, committee re-execution, TEE attestations, or lighter operator-trust modes; the interoperability layer moves assets and messages across chains and aggregates proofs for settlement; and the settlement layer anchors final state on Ethereum. The paper further claims that the interoperability layer's pessimistic-proof invariant caps any chain's withdrawals at its deposits, so weak internal verification inside an app does not endanger cross-chain liquidity. The zkSpot example applies this to a spot-trading engine that matches orders inside a trusted execution environment and proves each batch with a zkVM before settlement.

Load-bearing premise

The paper's strongest claim depends on an unproven assertion: Agglayer's built-in safety check always stops a chain from withdrawing more than it deposited, even when an app's own verification is weak or absent.

Editorial extensions

If this is right

Applications with stringent responsiveness requirements—trading engines, multiplayer games, social platforms—could run at Web2 latency while settling verifiable state on a public chain.
Developers can launch with operator trust and progressively upgrade to zkVM or committee verification without re-architecting, because trust is an isolated layer.
Users no longer manage gas fees or bridge routers; the interoperability layer abstracts chain choice and moves assets across networks with a unified interface.
Settlement costs shrink across the ecosystem, since proof aggregation lets many apps submit one finalized proof batch to the base chain.
A Chainless App can ingest Web2 HTTPS data via zkTLS and turn it into verifiable on-chain input, extending trustless data flows into off-chain systems.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The paper leaves unmeasured the actual latency and cost of its trusted-execution-then-zkVM pipeline; a direct benchmark against a Layer-2 rollup would show whether the Web2-like UX claim holds in production.
If an over-withdrawal path in the pessimistic-proof invariant were ever found, the 'Web3-grade trust' claim would reduce to trusting the interoperability operator and its off-chain state commitments, not a blockchain guarantee.
The pluggable trust layer invites hybrid settlement policies—optimistic for low-value transfers, zk-proven for high-value ones—which the paper names as possible but does not develop.
A chainless app whose execution trace is stored privately rather than on a public data-availability layer has a hidden dependency: verifiers must obtain that trace, so availability, not correctness alone, becomes the trust bottleneck.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Short version: this is a clean synthesis of known modular and verifiable-compute building blocks, and the layer decomposition is useful. But the headline guarantee—that Agglayer protects cross-chain asset transfers even when the app uses a weak trust model—does not hold on the paper's own description. Pessimistic proofs are a token balance invariant at the chain level; they do not constrain who is credited inside the app's state. An Operator Trust app (or a compromised TEE) can commit a false state root that assigns a user's balance to the attacker and then sign a withdrawal. Total withdrawals still equal total deposits, so the aggregate check passes, and the user loses funds. Agglayer verifies that the app did not withdraw more than it deposited, not that the withdrawal went to the right account. So the claimed separation between internal security and settlement guarantees is real only when the Trust Layer actually proves state-root authenticity, as in the zkVM case. For the lighter models the paper promotes, the "Web3-grade verifiability" rests on the Trust Layer, not on Agglayer.

What the paper does well: the four-layer model (execution, trust, interop, settlement) is clearly presented and is a reasonable vocabulary for these designs. It is honest that trust models form a spectrum, including Operator Trust, and it explicitly notes the burden this puts on users and auditors. The citations to vApps, RISC Zero, EigenLayer, and the author's earlier [A-Z]app post are appropriate, and the paper openly frames itself as generalizing prior work rather than claiming a from-scratch result. The zkSpot example is motivating, though it is unmeasured: no benchmarks, no latency or proving-cost numbers, so "CEX-like speed" is asserted, not shown.

Minor issues: Fast Interop and third-party shared sequencing are introduced with future-tense language but then treated as available; data availability and TEE-compromise scenarios are mentioned but not analyzed. The prose has a few rough edges ("relys", "will supports"). None of these are fatal on their own.

Bottom line: the architecture is coherent and worth a serious referee, but the central trust-model-independence claim needs to be either weakened or replaced with a precise statement of what pessimistic proofs actually guarantee. As written, the paper overstates Agglayer's role. A revision that scopes the guarantee to apps with authenticated state roots would be far more defensible.

Referee Report

4 major / 6 minor

Summary. The paper proposes a modular application architecture called Chainless Apps, which separates execution, trust, bridging, and settlement into distinct layers. Applications execute off-chain with app-specific sequencing, obtain verification through a pluggable Trust Layer (zkVM, validator committee, TEE attestation, or pure operator trust), move assets and messages across chains via Polygon's Agglayer with pessimistic proofs, and settle final state on Ethereum. The architecture is illustrated with zkSpot, a proof-of-concept high-performance spot trading application that combines a TEE execution engine with zkVM verification and Agglayer-based cross-chain settlement. The central claim is that this layering delivers fast Web2-like user experience while preserving Web3-grade verifiability and safety even for applications that adopt weak internal trust models.

Significance. If the central claims were established, the framework would be a useful synthesis of existing ideas in modular blockchains, verifiable compute, and cross-chain interoperability, and it would offer a concrete path toward CEX-like decentralized exchanges. The paper has real strengths: it clearly articulates a layered architecture, explicitly maps a spectrum of trust mechanisms from zkVM to operator trust, acknowledges that TEEs can be compromised, and grounds the discussion in a concrete application. However, the significance is limited by the absence of formal specification and security proofs, the lack of any benchmarks or measurements for the zkSpot prototype, and the reliance on Agglayer mechanisms that are cited to vendor documentation rather than independently specified. The paper is best read as an architecture position paper rather than a validated systems contribution, and the strongest claimed guarantee—that Agglayer preserves cross-chain safety independently of the app's internal trust model—is not supported by the described mechanism.

major comments (4)

[§3.2.2, §3.3] The claim that Agglayer's pessimistic proofs keep cross-chain asset transfers safe 'even if the internal security model of the application varies' is unsupported and, as described, false. Section 3.3 defines pessimistic proofs as 'a real-time token balance check that ensures no chain can withdraw more assets than it originally deposited.' This is an aggregate chain-level invariant: it constrains total withdrawals relative to total deposits, but it does not authenticate which account is credited or whether an exit message is authorized by the application's verified state. In the Operator Trust mode described in §3.2.1, an operator can commit a false state root that assigns a user's balance to the attacker and sign a withdrawal; total withdrawals still equal total deposits, so the pessimistic proof accepts. The user's funds are drained even though the bridge pool is not. Thus Agglayer does not separate internal application security from cross-chain settlement guarantees; the safety of the cross-chain step depends on the authenticity of the app's state root, which is precisely what the weaker trust models do not prove. The paper should either prove a stronger invariant or revise the claimed separation of concerns, acknowledging that Web3-grade verifiability in the framework rests on the Trust Layer, not on Agglayer.
[§4.1, §5] The zkSpot example is presented as demonstrating the viability of the framework today ('The zkSpot example demonstrates the viability of Chainless Apps today', §5), but no experimental evidence is provided. There are no measurements of order-matching latency, throughput, zk-proving time, verification gas cost, or end-to-end cross-chain settlement delay; nor is there any comparison against a CEX, a DEX, or a rollup-based alternative. The only artifact cited is a GitHub repository [19], which is not evaluated in the text. Without quantitative data, the claim that zkSpot achieves 'CEX-like UX while preserving Web3-grade guarantees' remains an assertion. The authors should add benchmarks from the prototype or explicitly downgrade the claim to an architectural illustration.
[§2.2, §3.3, §4.1] The paper conflates planned Agglayer features with available capabilities. Section 2.2 states that Agglayer 'will support' fast interop and third-party shared sequencing, and §3.3 describes Fast Interop's sub-second cross-chain messaging as enabling high-frequency trading and gaming. Yet the zkSpot narrative in §4.1 and the conclusion treat these as part of the present framework. Since the paper's motivating examples depend on sub-second cross-chain messaging, the authors must clearly distinguish roadmap items from currently implemented functionality, and state which claims hold if those features are not available.
[§3.1, §3.2.2] There is no formal specification of the security invariant that the framework is supposed to satisfy, and the informal definitions are too weak to support the paper's conclusions. Section 3.2.2 lists several verification strategies but does not define what each guarantees about state authenticity, and §3.1 explicitly permits execution traces to be stored privately, which complicates any data-availability assumption. The paper should provide a precise threat model, define Web3-grade verifiability formally (e.g., as a property of state transitions and withdrawals), and state the data-availability requirements for each trust mode. Without such a specification, the claim that 'Agglayer guarantees the correctness and safety of cross-chain asset transfers' cannot be assessed or falsified.

minor comments (6)

[Abstract] 'compostable layers' should be 'composable layers'.
[§2.1] 'rely s on hardware' should be 'relies on hardware'.
[§2.2] 'Agglayer will supports fast interop' should be 'Agglayer will support fast interop'.
[§3.2.1] 'institutional developers who has other web2 constraints' should be 'institutional developers who have other Web2 constraints'.
[§3.2.2] 'without re-architect the core system' should be 'without re-architecting the core system'.
[§4.1, References] The text refers to zkSpot [19], but reference [19] is titled 'zkHyperliquid: A Proof of Concept Chainless App'; the relationship between zkSpot and zkHyperliquid should be clarified, and a versioned artifact link would help reproducibility.

Circularity Check

2 steps flagged · score 4.0 of 10

No derivation-level circularity, but the central Web3-trust claim rests on self-citations: Agglayer's independence guarantee [10] and zkSpot's viability [19] are asserted from the authors' own prior materials without independent proof.

self citation load bearing [Section 4.1 (zkSpot), with reference [19]]
"zkSpot demonstrates how Chainless Apps eliminate traditional trade-offs. It offers CEX-level UX without compromising Web3-grade guarantees — and without launching a dedicated rollup or validator set."

The paper's central validation of the framework is a GitHub proof-of-concept by the first author and collaborators; no benchmark, audit, or formal verification appears in the paper. The assertion that Chainless Apps offer 'CEX-level UX without compromising Web3-grade guarantees' therefore reduces to trusting the self-cited artifact, which is not independently established in the text.
self citation load bearing [Section 3.2.2 and Section 3.3, with reference [10]]
"This flexibility is made possible because Agglayer isolates and secures interoperability independently of the internal trust assumptions of each app or chain. Through pessimistic proofs, Agglayer ensures that assets bridging out from a chain or Chainless App cannot be double spent or overdrawn, even if the internal security model of the application varies."

This load-bearing guarantee is imported from a Polygon Labs document [10] and asserted as fact rather than derived. The only mechanism described in Section 3.3 is a token balance check ensuring no chain withdraws more than it deposited; that aggregate invariant does not validate the authenticity of the app's internal state root. In Operator Trust or TEE-only modes, a false state root could reassign balances while still satisfying the aggregate invariant, so the claimed independence from the app's trust model presupposes exactly the state-authenticity guarantee that flexible trust models leave open. The conclusion is therefore carried by an unverified self/organizational citation, not by the stated mechanism.

full rationale

Chainless Apps is an architecture-position paper, not a mathematical derivation: there are no fitted parameters, equations whose outputs are compared with predictions, or formal proofs that could reduce to their inputs. The reader-level circularity concern is epistemic rather than derivation-level. The main 'Web3-grade verifiability' conclusion leans on two supports authored by the same team or employer: Agglayer's pessimistic-proof safety/independence ([10], asserted in Sections 3.2.2 and 3.3) and the zkSpot demonstration ([19], cited in Section 4.1). Neither is given independent proof in the paper; Agglayer's described balance invariant is narrower than the trust-model-independence claim drawn from it, and zkSpot is presented as a proof-of-concept without benchmarks or audit. Since the framework also incorporates independent external results (zkVM soundness, AVS, shared sequencing, micro-rollups) and the architecture is not forced by definition, the appropriate score is 4 rather than higher. The strongest skeptical objection about user-level asset safety under Operator Trust is a correctness/security gap, not a self-referential derivation, and should be evaluated separately from circularity.

Assumptions & free parameters 0 free parameters · 6 assumptions · 0 invented entities

The architecture depends on several unproven domain assumptions. The most important is that Agglayer's pessimistic proof mechanism actually guarantees cross-chain safety, which is cited only from Polygon-authored sources. Feasibility also assumes zkVM proof generation is fast and cheap enough for each app, that execution traces are available to verifiers, that TEE attestations are meaningful, and that planned features like Fast Interop arrive. These are stated as design premises, not demonstrated in the manuscript.

assumptions (6)

domain assumption Agglayer's pessimistic proofs prevent a connected chain or app from over-withdrawing assets.
Invoked in Sections 3.2.2 and 3.3 to justify cross-chain safety for apps with weak internal trust. Cited only to Polygon-authored material, with no independent specification or proof in this paper.
domain assumption A zkVM can deterministically replay app execution traces and produce succinct proofs at acceptable latency and cost.
Used in Sections 3.2.1 and 4.1 to argue for maximum trustlessness and CEX-like performance. No proving-time or cost measurements are given.
domain assumption Execution traces are available to validators or provers when needed.
Section 3.1 permits private storage with only a hash committed on-chain, which creates a data-availability dependency for verification that the paper does not analyze.
domain assumption TEE attestations provide integrity and ordering guarantees in practice.
Section 3.1 relies on TEEs for millisecond-order matching and MEV mitigation, while also conceding TEEs can be compromised; the resulting security posture is not quantified.
ad hoc to paper Agglayer's planned Fast Interop and shared sequencing will deliver sub-second cross-chain messaging.
Sections 2.2 and 3.3 say Agglayer "will support" these features and use them to justify real-time use cases. The paper depends on a future capability.
standard math Underlying SNARK/STARK proof systems are sound under standard cryptographic assumptions.
Relied on when claiming that a verifying zk proof implies negligible chance of invalid computation passing (Section 3.2.1). This is standard and uncontroversial, inherited from cited prior work.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Chainless Apps: A Modular Framework for Building Apps with Web2 Capability and Web3 Trust." pith.science (2026). https://pith.science/paper/BM42XAHZ

@misc{pith2026250522989,
  author       = {Pith},
  title        = {Pith review of: Chainless Apps: A Modular Framework for Building Apps with Web2 Capability and Web3 Trust},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/BM42XAHZ}},
  note         = {Machine review of arXiv:2505.22989}
}

read the original abstract

Modern blockchain applications are often constrained by a trade-off between user experience and trust. Chainless Apps present a new paradigm of application architecture that separates execution, trust, bridging, and settlement into distinct compostable layers. This enables app-specific sequencing, verifiable off-chain computation, chain-agnostic asset and message routing via Agglayer, and finality on Ethereum - resulting in fast Web2-like UX with Web3-grade verifiability. Although consensus mechanisms have historically underpinned verifiable computation, the advent of zkVMs and decentralized validation services opens up new trust models for developers. Chainless Apps leverage this evolution to offer modular, scalable applications that maintain interoperability with the broader blockchain ecosystem while allowing domain-specific trade-offs.

Figures

Figures reproduced from arXiv: 2505.22989 by the authors.

**Figure 2.** The more re-execution you run in the trust [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗

**Figure 4.** A highlevel sequence diagram of a Chain [PITH_FULL_IMAGE:figures/full_fig_p007_4.png] view at source ↗

Figures from the paper (2 more)

**Figure 3.** Figure 3: A detailed looks of Chainless-App’s Agglayer integration. By leveraging Agglayer, Chainless Apps gain access to secure and standardized cross-chain functionality. Apps can enable seamless deposits and withdrawals across chains, maintain unified liquidity tracking, a…

**Figure 5.** Figure 5: Flow of zkSpot execution, trust verifica [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

21 extracted references · 19 canonical work pages

[19]

zkHyperliquid: A Proof of Concept Chain- less App for High-Performance Spot Trading

Brian Seong, Pablo Vigara and Sa´ ul Garc ´ ıa. zkHyperliquid: A Proof of Concept Chain- less App for High-Performance Spot Trading. GitHub repository, 2024

work page 2024
[1]

Demystifying Application Spe- cific Rollups on Solana VM — An Eclipse Deep Dive

Yash Agarwal. “Demystifying Application Spe- cific Rollups on Solana VM — An Eclipse Deep Dive.” Medium, December 2022

work page 2022
[2]

EigenLayer: The Restaking Collective

EigenLayer Team. EigenLayer: The Restaking Collective. Whitepaper, 2023

work page 2023
[3]

A scalable verification solution for blockchains

Jason Teutsch and Christian Reitwiessner. “A Scalable Verification Solution for Blockchains.” arXiv preprint arXiv:1908.04756 (2019)

work page Pith review arXiv 2019
[4]

RISC Zero zkVM: Scalable, Transparent Arguments of RISC-V Integrity

Jeremy Bruestle, Paul Gafni, et al. RISC Zero zkVM: Scalable, Transparent Arguments of RISC-V Integrity. RISC Zero Technical Whitepaper, 2023

work page 2023
[5]

Plonky3: Recursive zk- SNARKs over Modern Curves

Polygon Zero Team. Plonky3: Recursive zk- SNARKs over Modern Curves. GitHub reposi- tory, 2023

work page 2023
[6]

Succinct Non-Interactive Zero Knowledge for a von Neumann Ar- chitecture

Eli Ben-Sasson et al. “Succinct Non-Interactive Zero Knowledge for a von Neumann Ar- chitecture.” IACR Cryptology ePrint Archive 2013/879 (2013)

work page 2013
[7]

Scalable, Transpar- ent, and Post-Quantum Secure Computational Integrity

Eli Ben-Sasson et al. “Scalable, Transpar- ent, and Post-Quantum Secure Computational Integrity.” IACR Cryptology ePrint Archive 2018/046 (2018)

work page 2018

Show all 21 references

[8]

Arbitrum: Scalable, Pri- vate Smart Contracts

Harry Kalodner et al. “Arbitrum: Scalable, Pri- vate Smart Contracts.” 27th USENIX Security Symposium, 2018

2018
[9]

Introducing Rollup-Boost: Launching on Unichain

Flashbots Team. “Introducing Rollup-Boost: Launching on Unichain.” Flashbots Writings, October 2024

2024
[10]

Aggregated Blockchains: A New Thesis

Polygon Labs. Aggregated Blockchains: A New Thesis. Polygon Technology Blog, January 2024

2024
[11]

The [A-Z]app Paradigm: Trust- less Apps with Web2 UX and Web3 Verifiabil- ity

Brian Seong. “The [A-Z]app Paradigm: Trust- less Apps with Web2 UX and Web3 Verifiabil- ity.” Personal Blog, 2024

2024
[12]

LazyLedger: A Dis- tributed Data Availability Ledger with Client-Side Smart Contracts

Mustafa Al-Bassam. “LazyLedger: A Dis- tributed Data Availability Ledger with Client-Side Smart Contracts.” arXiv preprint arXiv:1905.09274 (2019)

2019 arXiv
[13]

An Incomplete Guide to Rollups

Vitalik Buterin. “An Incomplete Guide to Rollups.” Vitalik.ca Blog, January 2021

2021
[14]

Endgame (Thoughts on Blockchain Decentralization)

Vitalik Buterin. “Endgame (Thoughts on Blockchain Decentralization).” Vitalik.ca Blog, December 2021

2021
[15]

A Layer-2 Expansion Shared Sequencer Model for Blockchain Scalability

Huijian Han et al. “A Layer-2 Expansion Shared Sequencer Model for Blockchain Scalability.” Blockchain Research and Applications, 2024

2024
[16]

SP1: A General-Purpose zkVM for Verifying Arbitrary Programs

Succinct Labs. “SP1: A General-Purpose zkVM for Verifying Arbitrary Programs.” Succinct Documentation, 2023

2023
[17]

Scaling Blockchains: The Mod- ularity Thesis

Christine Kim. “Scaling Blockchains: The Mod- ularity Thesis.” Galaxy Research Report, 2023

2023
[18]

Whitepaper, 2024

Avail Team.Avail: A Modular Data Availabil- ity Layer for Scalable Blockchain Applications. Whitepaper, 2024

2024
[20]

vApps: Verifiable Applications at Internet Scale

Isaac Zhang, Kshitij Kulkarni, Tan Li, Daniel Wong, Thomas Kim, John Guibas, Uma Roy, Bryan Pellegrino, and Ryan Zarick. “vApps: Verifiable Applications at Internet Scale.” arXiv preprint arXiv:2504.14809, 2024

2024 arXiv
[21]

Micro-Rollups: Modu- lar Micro-Services for Web3

Kautuk Kundan. “Micro-Rollups: Modu- lar Micro-Services for Web3” 2024. Avail- able at:https://assets.stackrlabs.xyz/ litepaper.pdf 10

2024

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [19]

zkHyperliquid: A Proof of Concept Chain- less App for High-Performance Spot Trading

Brian Seong, Pablo Vigara and Sa´ ul Garc ´ ıa. zkHyperliquid: A Proof of Concept Chain- less App for High-Performance Spot Trading. GitHub repository, 2024

work page 2024

[2] [1]

Demystifying Application Spe- cific Rollups on Solana VM — An Eclipse Deep Dive

Yash Agarwal. “Demystifying Application Spe- cific Rollups on Solana VM — An Eclipse Deep Dive.” Medium, December 2022

work page 2022

[3] [2]

EigenLayer: The Restaking Collective

EigenLayer Team. EigenLayer: The Restaking Collective. Whitepaper, 2023

work page 2023

[4] [3]

A scalable verification solution for blockchains

Jason Teutsch and Christian Reitwiessner. “A Scalable Verification Solution for Blockchains.” arXiv preprint arXiv:1908.04756 (2019)

work page Pith review arXiv 2019

[5] [4]

RISC Zero zkVM: Scalable, Transparent Arguments of RISC-V Integrity

Jeremy Bruestle, Paul Gafni, et al. RISC Zero zkVM: Scalable, Transparent Arguments of RISC-V Integrity. RISC Zero Technical Whitepaper, 2023

work page 2023

[6] [5]

Plonky3: Recursive zk- SNARKs over Modern Curves

Polygon Zero Team. Plonky3: Recursive zk- SNARKs over Modern Curves. GitHub reposi- tory, 2023

work page 2023

[7] [6]

Succinct Non-Interactive Zero Knowledge for a von Neumann Ar- chitecture

Eli Ben-Sasson et al. “Succinct Non-Interactive Zero Knowledge for a von Neumann Ar- chitecture.” IACR Cryptology ePrint Archive 2013/879 (2013)

work page 2013

[8] [7]

Scalable, Transpar- ent, and Post-Quantum Secure Computational Integrity

Eli Ben-Sasson et al. “Scalable, Transpar- ent, and Post-Quantum Secure Computational Integrity.” IACR Cryptology ePrint Archive 2018/046 (2018)

work page 2018