{"id":"36801ad6-4db3-4d5c-9a10-d1b14753edfd","arxiv_id":"2505.22989","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A framework for blockchain apps that separates off-chain execution, verification, cross-chain messaging, and on-chain settlement, designed to combine Web2 speed with Web3 verifiability.","lead":"This paper describes \"Chainless Apps\", a method for building blockchain apps that run core logic off-chain, verify it with zero-knowledge proofs or trusted hardware, and settle on Ethereum through Polygon's Agglayer. It is a candidate architecture for developers who want web-speed interfaces without giving up cryptographic verifiability.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Agglayer's balance invariant does not protect users from false app-state withdrawals, so the claimed trust-model independence is unsupported.","rationale":"The reader identified the right weakest assumption; this concern sharpens it with a concrete failure mode. The central claim is that Chainless Apps get Web3-grade verifiability while decoupling execution, trust, bridging, and settlement. The part that makes this novel is the modular Trust Layer plus Agglayer's claimed isolation. If pessimistic proofs only enforce a global invariant, they cannot catch app-internal double spends or false state-root authorizations, so \"regardless of the internal trust model\" is not justified. This is not a disagreement with the consensus on bridge design; it is an internal gap between the claimed guarantee and the described mechanism. No formal proof, simulation, or measurement is provided for Agglayer; the references are self-published blog and whitepaper material. zkSpot is a named proof-of-concept, but no code, benchmarks, or adversarial analysis appear in the paper. A simple two-chain model test would settle the point. The verdict remains conditional: the concept is plausible, but the central safety claim needs either a formal invariant or a restriction to trust models that prove state authenticity.","tokens_in":9496,"tokens_out":5136,"duration_ms":55626,"concrete_test":"Build a minimal adversarial model of the §3.3 invariant: Chain A deposits 100 USDC into a Chainless App; the app publishes an Operator Trust state root (no validity proof) crediting an attacker-controlled account with 100 USDC; the attacker exits 100 USDC to Chain B through Agglayer. Run the pessimistic-proof predicate described in §3.3 (total withdrawals <= total deposits) and check whether it accepts. If it accepts, the claim that Agglayer protects cross-chain transfers independently of app trust models is refuted; if it rejects, identify the additional check that rejected it and show how Operator Trust apps satisfy it.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The load-bearing condition is the §3.2.2/§3.3 claim that Agglayer's pessimistic proofs keep cross-chain asset transfers safe \"even if the internal security model of the application varies.\" The described mechanism is only a token balance check ensuring that no chain withdraws more than it deposited; that invariant is aggregate and chain-level. It does not constrain which account, inside a Chainless App, is credited when an exit message is created. Under the paper's own Operator Trust mode (§3.2.1), or a TEE-only model without zk state verification, the operator/enclave 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 to the app, so the pessimistic proof accepts; the bridge pool is not drained, but the user's funds are. Thus Agglayer does not \"separate internal application security from cross-chain settlement guarantees\" for weak trust models: the safety of the cross-chain step depends on the authenticity of the app's state root, which is exactly the thing the weaker trust models do not prove. The framework's Web3-grade verifiability therefore rests on the app's Trust Layer (as in zkSpot's zkVM), not on Agglayer, and the paper's broader flexible-trust-model story is unsupported.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":9700,"tokens_out":3163,"duration_ms":35896,"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":[{"comment":"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.","section":"§3.2.2, §3.3"},{"comment":"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.","section":"§4.1, §5"},{"comment":"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.","section":"§2.2, §3.3, §4.1"},{"comment":"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.","section":"§3.1, §3.2.2"}],"minor_comments":[{"comment":"'compostable layers' should be 'composable layers'.","section":"Abstract"},{"comment":"'rely s on hardware' should be 'relies on hardware'.","section":"§2.1"},{"comment":"'Agglayer will supports fast interop' should be 'Agglayer will support fast interop'.","section":"§2.2"},{"comment":"'institutional developers who has other web2 constraints' should be 'institutional developers who have other Web2 constraints'.","section":"§3.2.1"},{"comment":"'without re-architect the core system' should be 'without re-architecting the core system'.","section":"§3.2.2"},{"comment":"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.","section":"§4.1, References"}],"recommendation":"major_revision","confidential_remarks":"The paper reads as a vendor-adjacent architecture vision rather than a standalone systems contribution: most of the load-bearing guarantees are attributed to Polygon's Agglayer and cited to Polygon-authored blog posts and repositories, while the only validation example, zkSpot, is also authored by the same team. This is not inherently disqualifying, but it increases the importance of independent specification and measurement, which are currently absent. The referee report's skepticism about the pessimistic-proof invariant is well founded, and the authors should be asked to either prove it or substantially weaken the corresponding claims. If the journal has a vision/position track, this paper may be better suited there than as a full research article."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","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.\n\nWhat 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.\n\nMinor 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.\n\nBottom 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.","headline":"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.","tokens_in":10225,"tokens_out":2421,"would_cite":false,"duration_ms":25470,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper proposes a modular Chainless App architecture that separates execution, trust, bridging, and settlement to offer Web2 speed with Web3-grade verifiability.","keywords":["Chainless Apps","verifiable compute","app-specific sequencing","cross-chain interoperability","pessimistic proofs","zero-knowledge virtual machine","trusted execution environment","settlement layer"],"falsifier":"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.","tokens_in":9261,"feed_emoji":"⚡","tokens_out":8533,"duration_ms":78577,"temperature":0.7,"pith_summary":"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.","feed_headline":"Chainless Apps get Web2 speed and Web3 trust by splitting layers","feed_subtitle":"Off-chain execution plus zk proofs means trading engines and games can be fast, verifiable, and cross-chain.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"supplies the app-specific sequencing model where each application controls its own transaction ordering and state evolution.","marker":"[1]"},{"why":"supplies the autonomous-verifiable-service committee model used as a verification option in the Trust Layer.","marker":"[2]"},{"why":"supplies challenge-based off-chain verification as another committee-based trust mechanism.","marker":"[3]"},{"why":"provides the zkVM execution-replay method the Trust Layer uses to prove execution traces.","marker":"[4]"},{"why":"defines the zk proving stack listed as the basis for zkVM verification.","marker":"[5]"},{"why":"supports TEE-based sequencing fairness and MEV mitigation in the Execution Layer.","marker":"[9]"},{"why":"describes Agglayer, the interoperability and settlement infrastructure the whole architecture relies on.","marker":"[10]"},{"why":"documents the concrete zkVM used to prove each batch in the zkSpot proof of concept.","marker":"[16]"},{"why":"grounds the zkSpot example as an implemented proof of concept of the Chainless App design.","marker":"[19]"}],"fun_headline_variants":["Chainless Apps: split execution and trust for speed and verifiability","Fast apps with zk proofs: Chainless Apps settle on Ethereum","No chain needed: off-chain execution, on-chain trust with zkVMs","Modular trust layers let apps sequence their own transactions","Chainless Apps: Web2 UX, Web3 trust via composable layers"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Chainless Apps: split execution and trust for speed and verifiability","Fast apps with zk proofs: Chainless Apps settle on Ethereum","No chain needed: off-chain execution, on-chain trust with zkVMs","Modular trust layers let apps sequence their own transactions","Chainless Apps: Web2 UX, Web3 trust via composable layers"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000462,"raw_usage":{"total_tokens":2264,"prompt_tokens":851,"completion_tokens":1413,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":467,"completion_tokens_details":{"reasoning_tokens":1320}},"tokens_in":467,"tokens_out":1413,"duration_ms":13329,"temperature":1.0,"reasoning_tokens":1320,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T12:55:42.795035+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"zkHyperliquid: A Proof of Concept Chain- less App for High-Performance Spot Trading","cited_arxiv_id":null,"evidence_quote":"grounds the zkSpot example as an implemented proof of concept of the Chainless App design."},{"cited_title":"Demystifying Application Spe- cific Rollups on Solana VM — An Eclipse Deep Dive","cited_arxiv_id":null,"evidence_quote":"supplies the app-specific sequencing model where each application controls its own transaction ordering and state evolution."},{"cited_title":"EigenLayer: The Restaking Collective","cited_arxiv_id":null,"evidence_quote":"supplies the autonomous-verifiable-service committee model used as a verification option in the Trust Layer."},{"cited_title":"A scalable verification solution for blockchains","cited_arxiv_id":"1908.04756","evidence_quote":"supplies challenge-based off-chain verification as another committee-based trust mechanism."},{"cited_title":"RISC Zero zkVM: Scalable, Transparent Arguments of RISC-V Integrity","cited_arxiv_id":null,"evidence_quote":"provides the zkVM execution-replay method the Trust Layer uses to prove execution traces."},{"cited_title":"Plonky3: Recursive zk- SNARKs over Modern Curves","cited_arxiv_id":null,"evidence_quote":"defines the zk proving stack listed as the basis for zkVM verification."},{"cited_title":"Introducing Rollup-Boost: Launching on Unichain","cited_arxiv_id":null,"evidence_quote":"supports TEE-based sequencing fairness and MEV mitigation in the Execution Layer."},{"cited_title":"Aggregated Blockchains: A New Thesis","cited_arxiv_id":null,"evidence_quote":"describes Agglayer, the interoperability and settlement infrastructure the whole architecture relies on."},{"cited_title":"SP1: A General-Purpose zkVM for Verifying Arbitrary Programs","cited_arxiv_id":null,"evidence_quote":"documents the concrete zkVM used to prove each batch in the zkSpot proof of concept."}],"review_version":1}