{"id":"547192d8-52ae-4e67-859b-88e2cbea7deb","arxiv_id":"2502.08919","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"high","formal_verification":"none","parameter_count":1,"one_line_summary":"A proposed universal token standard, UAT20, aims to unify ERC20 liquidity across rollups using CRDT state and L1-ordered commits, but the protocol and its empirical support are not fully specified.","lead":"UAT20 is a proposed token standard that uses CRDTs and a two-phase commit protocol to treat a user's ERC20 tokens on multiple Ethereum rollups as one unified balance. The paper also measures how often users already move liquidity between rollups, claiming this shows the standard would reduce fragmentation and cost.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The core accounting is internally inconsistent: §II-C applies a Σ20 transfer to the local ERC20 balance both during execution and again via commit/synchronization, and its own example credits the recipient 80 UAT20 for a 50-token transfer, so the protocol cannot guarantee correct unified balances…","rationale":"The reader's weakest assumption concerns deployment: existing standard ERC20 contracts would need to be replaced by UAT20-compatible versions, and users would need to migrate assets. That is a real external barrier, but a protocol proposal can reasonably target future tokens or migrations. The more load-bearing concern is internal to the protocol description. Section II-C's execution phase updates the local Σ20 balance B immediately, yet the commit phase later applies the same SUB/ADD operations to the same logical balances and then synchronizes to Σ20 by calling transfer. This creates a double-application ambiguity that is not resolved anywhere in the paper. The example itself compounds the problem by crediting the recipient 40 + 40 = 80 UAT20 for a 50-token transfer. These are not typos in an unimportant passage: they affect the very mechanism by which UAT20 claims to maintain a unified balance across rollups. If the described operations are implemented literally, a user's balances diverge from the claimed invariant; if the synchronizer is instead an overwrite, the paper does not say so and the ERC20 transfer function's normal semantics are violated. Because this concern is about the protocol's core accounting rule, it is more fundamental than the deployment objection and independently justifies the REJECT verdict. The reader and I agree on the final verdict, but we identify different load-bearing weaknesses, hence 'disagree' on the weakest-assumption match.","tokens_in":6989,"tokens_out":6504,"duration_ms":66953,"concrete_test":"Implement the §II-C workflow as a small state machine with variables Bx, By (local Σ20 balances), Bx_e, By_e, Bu, and the exact operations O1, O2, O3 from the example. Apply execution-phase updates exactly as written (Σ20 updates B immediately; Υ20 only emits operations), then apply the commit phase with TE before TU, and finally apply the described synchronization \"by calling Σ20.transfer\". Check the invariants Bx[C] == Bx_e[C], By[C] == By_e[C], and Bu[C] == Bx_e[C]+By_e[C]. If the run produces Bx[C]=20 while Bx_e[C]=30, or if any consistent interpretation of \"calling Σ20.transfer\" requires overwriting rather than transferring to keep the arithmetic coherent, the protocol as specified is unsound.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section II-C states that when user C calls Σ20.transfer, the Σ20 contract updates B[C] and B[A] immediately during the execution phase, and also emits O1 containing SUB(B_i_e[C],10) and ADD(B_i_e[A],10). In the commit phase it says \"With operations in O1, Υ20 on each rollup updates both Bu and Bi_e balances for A and C,\" and then \"these updates to Bx_e and By_e will be synchronized to the balance of Σ20 (B) on RX and RY by calling Σ20.transfer.\" If B_i_e is the same logical ledger as the local Σ20 balance, as Definition 1 implies, the transfer is applied twice to the same balance; if the second call is instead meant to align two separate ledgers, the paper never defines the semantics (overwrite versus transferring again). Following the written sequence, after t1 and its synchronization the sender's RX balance would be 20 rather than 30, violating both local-ERC20 consistency and the invariant Bu[C] = Σ_i B_i_e[C]. Separately, the example's policy for t2 increases Bx_e[A] by 40 and By_e[A] by 40, crediting A with 80 tokens for a 50-token transfer. This is not a deployment limitation; it is an internal inconsistency in the central state-update rule that would break the \"single global balance\" claim even if all contracts were custom-deployed as the paper imagines.","agreement_with_reader":"disagree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes UAT20, a universal abstract token standard intended to unify ERC20 balances across Ethereum rollups. The protocol combines CRDTs with a two-phase Execute-Commit protocol in which Ethereum orders transactions from all rollups and a synchronizer distributes the order; per-rollup Σ20 and Υ20 contracts update aggregated and rollup-specific balances. The paper also reports an empirical study of token transfers on Arbitrum, Optimism, and ZKsync to motivate the problem. The central claims are eventual consistency across rollups and seamless, secure unification of liquidity.","tokens_in":7319,"tokens_out":7140,"duration_ms":68824,"significance":"If the protocol were fully specified and correct, it would address a real pain point in the multi-rollup ecosystem. The empirical dataset is a useful descriptive contribution, and the use of Ethereum as an ordering service is a plausible way to turn concurrent CRDT updates into a total order. However, the manuscript does not provide the formal machinery needed to substantiate its consistency claims, and the central state-update rule as written contains accounting errors that break balance conservation and the stated invariant. The compatibility requirement is also contradicted by the design. These are load-bearing defects, not presentational issues.","major_comments":[{"comment":"Definition 1 defines B_i^e as the balance of ERC20 token held by each user on R_i, i.e., the same mapping as the Σ20 balance B of Definition 2. In the Σ20 transfer example, the execution phase already updates B[C] and B[A] on RX, and the operation set O1 contains SUB(B_i^e[C],10) and ADD(B_i^e[A],10). The commit phase then says that 'Υ20 on each rollup updates both B_u and B_i^e balances' and afterwards 'these updates ... will be synchronized to the balance of Σ20 (B) on RX and RY by calling Σ20.transfer'. If B_i^e and Σ20.B denote the same ledger, the 10-unit debit is applied twice; if they are different ledgers, the semantics of the second call (overwrite vs. transfer) is never specified. Under either reading the invariant B_u[C] = sum_i B_i^e[C] is not maintained. The example then continues as if Bx_e[C] were still 40 after t1, although a committed O1 would make it 30 (or 20 if applied twice).","section":"§II-C (Definition 1, Definition 2)"},{"comment":"The description of t^{(2)}_{x,u} violates conservation. The operation set O2 is SUB(B_u[C],50), ADD(B_u[A],50), and the commit step deducts 40 from Bx_e[C] and 10 from By_e[C]. But it then increases Bx_e[A] by 40 and By_e[A] by 40. This gives A a net credit of 80 UAT20 while C is debited only 50, and B_u[A] was only increased by 50. The error is internal to the example and cannot be attributed to deployment assumptions.","section":"§II-C (UAT20 transfer example)"},{"comment":"The compatibility requirement in §II-A says UAT20 should 'minimally impact both the original rollup design and the underlying ERC20 token (Σ20) design'. However, Definition 2 changes Σ20 so that transfer and approve functions invoke Fe to emit UAT20 operations and F can be called by Fc to modify B during the commit phase. This is a modified token contract, not standard ERC20. Users with existing balances in standard ERC20 contracts would have to migrate to this new contract on every rollup before UAT20 can 'unify' them. The paper never acknowledges this migration constraint, and it contradicts the stated compatibility goal and the empirical section's framing that UAT20 addresses the currently fragmented standard-token liquidity.","section":"§II-A vs. §II-C"},{"comment":"Although the paper invokes CRDTs as the foundation of consistency, no concrete CRDT is defined. The text mentions 'merge functions that reconcile concurrent updates' but neither specifies the merge operation nor proves that the two-phase Execute-Commit protocol yields convergence. There is also no failure or liveness model: the synchronizer's behavior under crash, Byzantine, or reorg conditions is not analyzed, and no argument is given that valid transactions eventually commit. The eventual consistency claim in the abstract and requirements list is therefore asserted, not established.","section":"§II-A, §II-B"},{"comment":"The abstract and introduction promise 'secure' liquidity unification 'without introducing security risks', but the manuscript contains no security analysis: no adversarial model, no trust assumptions about the synchronizer, no treatment of replay attacks, ordering manipulation by Ethereum block proposers, or cross-rollup double-spend. The security claim is load-bearing and is left completely unsupported.","section":"Abstract and Introduction vs. rest of paper"},{"comment":"The empirical study cannot support the 'effectiveness' claim. The identification of a 'liquidity unification behavior' requires a transfer-out within two hours after a transfer-in on another rollup, but the two-hour threshold is arbitrary and no sensitivity analysis is reported. The observed 12.37% share of bridge-like transactions is descriptive; it does not measure what share of that activity UAT20 would actually eliminate, nor does it quantify gas or latency savings. At most the study motivates the problem, not the solution.","section":"§III"}],"minor_comments":[{"comment":"There are typographical errors: 'tranfer' should be 'transfer', and '∓20' should be 'Υ20' in the UAT20 transfer example.","section":"§II-C"},{"comment":"The term 'E-Token' is used in Definition 2 without being introduced; the surrounding text refers to the token as Σ20, so the definition should be aligned with the notation used elsewhere.","section":"§II-C, Definition 2"},{"comment":"The example says user C has 100 UAT20 composed of 40 ERC20 tokens on RX and '60 ERC20 tokens on RX', which should presumably be 'on RY'.","section":"§II-B example"},{"comment":"The figure labels are hard to parse: the same symbol B is used for both the UAT20 aggregated balance and the ERC20 balance, and the labels 'Bex' and 'Bey' are not defined in the text.","section":"Figure 1"}],"recommendation":"reject","confidential_remarks":"The manuscript reads as an extended abstract rather than a fully specified protocol paper. The core state-update semantics need to be redesigned or precisely defined before a consistency claim can be evaluated. I would encourage the authors to provide formal CRDT definitions, a security model, and either a corrected accounting example or a revised compatibility statement."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague, quick take on UAT20. The paper names a real problem — fragmented ERC20 liquidity across rollups — and the empirical section does quantify it on real data, which is useful. The idea of combining CRDTs with L1-ordered two-phase commit for a cross-rollup token standard is also a fresh combination, not a restatement of prior work. That is the good part.\n\nBut the central protocol as written does not work. The state-update rules in §II-C double-apply a Σ20 transfer. In the execution phase the local ERC20 balance is updated, then the commit phase applies the same SUB/ADD operations to Bi_e again, and Definition 2 explicitly equates Bi_e with the ERC20 balance. The example then credits the recipient 80 UAT20 for a 50-token transfer (40 to Bx_e[A] and 40 to By_e[A]). This is not a deployment limitation; it breaks the conservation invariant the whole design depends on. Even if every asset were migrated to a custom contract, the ledger would not balance.\n\nThe paper also lacks the CRDT merge function, gives no failure or liveness model, and provides no security analysis. The stated compatibility requirement is contradicted by the design: Σ20 is not standard ERC20, it is a modified contract that forwards operations to Υ20, so the claimed ability to unify existing liquidity is unsupported. The empirical analysis quantifies fragmentation but does not test UAT20 in any way.\n\nWhat is genuinely new is the problem framing and the intent to use CRDT plus L1 ordering, but the execution is not ready. If the authors fix the accounting and add a formal semantics, the idea might become worth a workshop discussion. As submitted, a serious referee would spend effort demonstrating the example error. I would not send this to peer review in its current form.","headline":"An internally inconsistent protocol proposal: the empirical fragmentation data is useful, but the central state-update rules don't conserve balance, so the paper isn't ready for peer review.","tokens_in":7824,"tokens_out":3841,"would_cite":false,"duration_ms":36085,"reading_group":"maybe","serious_thinker":"no","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"UAT20 is a proposed universal abstract token standard that makes a user's ERC20 balances across rollups behave as a single consistent global balance.","keywords":["liquidity fragmentation","rollups","ERC20","universal token standard","CRDT","two-phase commit","eventual consistency","Ethereum"],"falsifier":"Deploy UAT20 on two test rollups, let two users send concurrent UAT20 transfers that together exceed the sender's balance, finalize them through Ethereum in a known order, and inspect both rollups: if the two replicas end with different balances, or if the transaction appearing earlier in the queue is the one that fails, the protocol's claimed deterministic convergence is false.","tokens_in":6766,"feed_emoji":"🔗","tokens_out":6556,"duration_ms":58715,"temperature":0.7,"pith_summary":"This paper tries to establish that liquidity fragmentation across Ethereum rollups can be solved at the token layer. It proposes UAT20, a universal abstract token standard built on conflict-free replicated data types, so that a user's ERC20 holdings on different rollups read and act as one global balance. To keep all rollup replicas consistent, the protocol uses a two-phase Execute-Commit scheme in which Ethereum orders transactions and commits them in priority queues. If this works, users would no longer need bridges or aggregators to pool their own fragmented positions, and concurrent transfers would converge to the same state on every rollup. The paper supports the need for such a standard with an empirical study of token holdings across three rollups.","feed_headline":"UAT20 unifies rollup liquidity with a CRDT token standard","feed_subtitle":"One global balance replaces fragmented per-rollup token piles; Ethereum ordering settles transfer conflicts.","key_machinery":"The load-bearing mechanism is a two-phase Execute-Commit protocol layered over CRDTs, with Ethereum acting as the global transaction orderer. In phase one, a UAT20 transfer only generates pending operations; in phase two, the ordered operations are committed through the functions commitE and commitU, with ERC20 transactions processed before UAT20 transactions and each queue processed in order. Rollup-specific balance deductions are resolved by a user-defined priority policy that all replicas agree on, which is what lets concurrent updates converge.","core_discovery":"UAT20's central claim is that combining CRDT replicas with an Ethereum-ordered two-phase commit protocol yields a token whose state is eventually consistent across all rollups while still allowing each rollup to process transfers independently. Concretely, the UAT20 balance of a user is the sum of their per-rollup ERC20 balances; transactions generate operation sets that are broadcast to Ethereum, and the commit phase applies those operations in a deterministic order, giving ERC20 transactions priority over UAT20 transactions and resolving conflicting UAT20 transfers by queue order. The paper argues this removes the need for manual bridging and lets a transfer initiated on any rollup update the user's unified balance everywhere.","pith_inferences":["Editorial inference: the protocol only unifies liquidity that has been moved into UAT20-compatible contracts; the paper's empirical numbers describe existing standard ERC20 fragmentation, so the realized benefit depends on migration and adoption, not just the protocol.","Editorial inference: by making rollup-specific balances a priority-ordered deduction policy, UAT20 effectively turns cross-rollup transfer into a deterministic multi-account balance update; the same CRDT-plus-ordering pattern could generalize to other state, such as lending positions or non-fungible ownership.","Editorial inference: a direct testable extension is to measure convergence latency and gas overhead of the commit phase on a public testnet with adversarial concurrent transfers, since the paper does not benchmark protocol cost."],"forward_implications":["A user holding UAT20 on several rollups can transfer from any one rollup and see the balance change consistently on all others.","Conflicting simultaneous transfers of the same UAT20 balance settle deterministically by Ethereum's ordering, so later-ordered transfers fail rather than double-spend.","Users no longer need to bridge assets manually or rely on aggregator pre-authorizations for UAT20-compatible tokens, reducing gas and security exposure.","The empirical finding that roughly 12 percent of analyzed rollup token transactions are liquidity-aggregation moves implies a large class of activity that UAT20 could render unnecessary."],"supporting_citations":[{"why":"Defines CRDTs and their convergence property, the foundation for UAT20's cross-rollup consistency.","marker":"[18]"},{"why":"Provides state-based CRDT synchronization techniques that the design relies on for merging replicas.","marker":"[19]"},{"why":"Establishes the rollup execution model that UAT20 runs on and targets.","marker":"[2]"},{"why":"Documents liquidity fragmentation and its costs, motivating the problem UAT20 solves.","marker":"[7]"},{"why":"Surveys security and privacy of blockchain interoperability, supporting the claim that bridge-based aggregation adds risk.","marker":"[14]"},{"why":"Supplies the on-chain datasets for two of the rollups studied in the empirical analysis.","marker":"[20]"},{"why":"Supplies the on-chain dataset for the third rollup studied in the empirical analysis.","marker":"[21]"}],"fun_headline_variants":["UAT20 token merges rollup liquidity via CRDTs","Rollup liquidity unified by UAT20's CRDT token","UAT20: one global balance across all rollups","UAT20 unifies rollup liquidity via CRDTs and Ethereum ordering","CRDT token standard UAT20 ends rollup liquidity fragmentation"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The protocol only works if every participating rollup runs a special version of the token contract that UAT20 can write to, and users move their existing tokens into it; standard ERC20 liquidity already sitting on rollups is untouched by UAT20 as described.","fun_headline_variants_meta":{"raw":{"variants":["UAT20 token merges rollup liquidity via CRDTs","Rollup liquidity unified by UAT20's CRDT token","UAT20: one global balance across all rollups","UAT20 unifies rollup liquidity via CRDTs and Ethereum ordering","CRDT token standard UAT20 ends rollup liquidity fragmentation"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000535,"raw_usage":{"total_tokens":2507,"prompt_tokens":816,"completion_tokens":1691,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":432,"completion_tokens_details":{"reasoning_tokens":1602}},"tokens_in":432,"tokens_out":1691,"duration_ms":11528,"temperature":1.0,"reasoning_tokens":1602,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T23:12:27.146143+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Deploy UAT20 on two test rollups, let two users send concurrent UAT20 transfers that together exceed the sender's balance, finalize them through Ethereum in a known order, and inspect both rollups: if the two replicas end with different balances, or if the transaction appearing earlier in the queue is the one that fails, the protocol's claimed deterministic convergence is false.","supporting_citations":[{"cited_title":"Google bigquery: Serverless, highly scalable, and cost-effective multi- cloud data warehouse,","cited_arxiv_id":null,"evidence_quote":"Supplies the on-chain datasets for two of the rollups studied in the empirical analysis."},{"cited_title":"Zksync block explorer api","cited_arxiv_id":null,"evidence_quote":"Supplies the on-chain dataset for the third rollup studied in the empirical analysis."},{"cited_title":"Efficient syn- chronization of state-based crdts,","cited_arxiv_id":null,"evidence_quote":"Provides state-based CRDT synchronization techniques that the design relies on for merging replicas."},{"cited_title":"Arbitrum: Scalable, private smart contracts,","cited_arxiv_id":null,"evidence_quote":"Establishes the rollup execution model that UAT20 runs on and targets."}],"review_version":1}