UAT20: Unifying Liquidity Across Rollups

Han Liu; Yue Li

REVIEW 6 major objections 4 minor 21 references

UAT20: Unifying Liquidity Across Rollups

T0 review · 6 major / 4 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 UAT20 is a proposed universal abstract token standard that makes a user's ERC20 balances across rollups behave as a single consistent global balance.

desk verdict 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. read the letter →

arxiv 2502.08919 v1 pith:6SZJFKPW submitted 2025-02-13 cs.DC

Yue Li , Han Liu This is my paper · ORCID

classification cs.DC

keywords liquidityfragmentationrollupsERC20universaltokenstandardCRDTtwo-phasecommiteventualconsistencyEthereum

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 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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

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.

Reading between the lines

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

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.

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

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.

But 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.

The 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.

What 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.

Referee Report

6 major / 4 minor

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.

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 (6)

[§II-C (Definition 1, Definition 2)] 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).
[§II-C (UAT20 transfer example)] 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.
[§II-A vs. §II-C] 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.
[§II-A, §II-B] 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.
[Abstract and Introduction vs. rest of paper] 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.
[§III] 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.

minor comments (4)

[§II-C] There are typographical errors: 'tranfer' should be 'transfer', and '∓20' should be 'Υ20' in the UAT20 transfer example.
[§II-C, Definition 2] 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.
[§II-B example] 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'.
[Figure 1] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's consistency/unification claim rests on an asserted commit protocol and CRDT citation, not on fitted parameters or self-citation; the global-balance identity is definitional, not a derived prediction.

full rationale

UAT20's central derivation chain is not circular. The protocol introduces a two-phase Execute-Commit design with Ethereum ordering; eventual consistency is asserted by invoking CRDT properties from external references [18], [19], and no load-bearing premise is justified by a self-citation or by an author-imported uniqueness theorem. Definition 1 sets Bu[C] = sum_i B_i_e[C], but this is a definition of the aggregated balance, not a claimed result derived from it; the paper's actual contribution is the claim that the commit protocol can maintain that aggregate while resolving conflicts, and that claim is asserted rather than formally proved. That omitted proof is a soundness/completeness gap, not a circular reduction. The empirical section uses external BigQuery and ZKsync Explorer data with a stated heuristic to measure fragmentation; it fits no parameter that is later renamed as a prediction. The accounting inconsistency noted in the skeptic brief (applying a Sigma20 transfer during execution and again during synchronization, and crediting A with 80 tokens for a 50-token transfer) is an internal correctness problem in the state-update rule, but it does not make any claimed derivation equivalent to its inputs. With no fitted-input prediction, no self-citation chain, and no definitional equivalence carrying the central claim, the circularity score is 0.

Assumptions & free parameters 1 free parameters · 5 assumptions · 2 invented entities

The ledger shows that the paper's central claims rest on several unverified domain assumptions: CRDT convergence applied to an unspecified merge function, a trusted and always-available Ethereum ordering and synchronization layer, and custom per-rollup token contracts that can be written by a remote commit. The only explicit free parameter is the empirical two-hour window used to define liquidity unification, which shapes the reported effectiveness numbers.

free parameters (1)

two-hour lookback window = 120 minutes
A transfer-out on a second rollup within two hours of a transfer-in is counted as liquidity unification in the empirical study. This threshold is chosen by hand and directly affects the reported 12.37% and 22.21% figures; no robustness analysis is given.

assumptions (5)

domain assumption CRDT convergence: a state-based CRDT converges to the same state when all replicas merge the same set of updates.
§II-A and §II-C rely on CRDT theory from [18] and [19] to assert that rollup replicas converge, but the paper never defines the actual CRDT state, merge function, or causality labels for UAT20.
domain assumption Ethereum L1 provides a trusted, available total order for token transactions and rollups can always synchronize that order.
The two-phase Execute-Commit protocol in §II-B depends on Ethereum ordering all synchronizer broadcasts and on every rollup receiving Sync(TO, Ri); no liveness, reorg, or sequencer failure handling is specified.
ad hoc to paper Per-rollup ERC20 contracts can be upgraded or replaced with UAT20-compatible Σ20 contracts that allow the UAT20 commit phase to modify local balances.
§II-C states that commit operations will be synchronized to the balance of Σ20 (B) on RX and RY by calling Σ20.transfer, which assumes existing standard ERC20 tokens can be modified or that all assets migrate to a custom contract. This assumption is not analyzed and contradicts the stated compatibility requirement.
domain assumption The synchronizer is honest and available.
The protocol assumes the broadcast and sync functions from §II-A are performed correctly by the synchronizer, with no trust model, incentive, or failure recovery specified.
domain assumption The operation sets generated by Σ20 and Υ20 transfers can be applied as commutative or order-resolved CRDT operations on every rollup.
§II-C assumes operation sets such as SUB(Bu[C],10) and ADD(Bu[A],10) can be replayed on every rollup without further coordination, but the paper does not define resolution rules for concurrent SUB operations or for negative balances beyond order-based failure.

invented entities (2)

UAT20 Token (Υ20)
purpose: A CRDT-based token that aggregates a user's per-rollup ERC20 balances into one global balance and supports cross-rollup transfers.
Defined as a tuple (B, Fo, Fc) in Definition 1, but no implementation, deployed contract, test vectors, or external observable prediction is provided, so there is no falsifiable handle outside the paper.
Synchronizer
purpose: An off-chain or separate component that broadcasts rollup transactions to Ethereum and synchronizes the ordered transaction queue back to all rollups.
No implementation, trust assumptions, or failure behavior is specified; the entire protocol depends on it operating correctly.

how reviews work

0 comments

Cite this review

Pith. "Pith review of UAT20: Unifying Liquidity Across Rollups." pith.science (2026). https://pith.science/paper/6SZJFKPW

@misc{pith2026250208919,
  author       = {Pith},
  title        = {Pith review of: UAT20: Unifying Liquidity Across Rollups},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6SZJFKPW}},
  note         = {Machine review of arXiv:2502.08919}
}

read the original abstract

Ethereum has been a cornerstone of the decentralized ecosystem, with rollup-based scaling solutions like Arbitrum and Optimism significantly expanding its capabilities. These rollups enhance scalability and foster innovation, but their rapid proliferation has introduced \emph{liquidity fragmentation}. Specifically, tokens distributed on multiple rollups fragment the liquidity of users, complicating participation in trading and lending activities bound by minimum liquidity thresholds. This paper proposes UAT20, a universal abstract token standard, to address liquidity fragmentation across rollups. Leveraging Conflict-free Replicated Data Types (CRDTs), UAT20 ensures consistent states across multiple rollups. We introduce a two-phase commit protocol to resolve transaction conflicts, enabling seamless and secure liquidity unification. Finally, our empirical analysis demonstrated the necessity and effectiveness of UAT20 in mitigating liquidity fragmentation within Rollups.

Figures

Figures reproduced from arXiv: 2502.08919 by the authors.

**Figure 1.** The Workflow of UAT20 protocol and confirmation, ensuring security and consensus. Users U are allowed to send transactions in both Ethereum (L1) and Rollups (L2). ERC20 Token (Σ20), UAT20 Token (Υ20). Two types of tokens contract is deployed in Rollups: ERC20 Token (Σ20) and UAT20 Token (Υ20). Σ20 follows the mature ERC-20 standard, preserving user assets on the current chain and enabling token transfers within the … view at source ↗

**Figure 2.** The result of liquidity unification IV. CONCLUSION This paper addresses the pressing issue of liquidity fragmentation within Ethereum’s rollups by introducing UAT20, a universal abstract token standard. By leveraging Conflict-free Replicated Data Types (CRDTs), UAT20 ensures consistent and unified token states across multiple rollups, eliminating the inefficiencies and complexities caused by fragmented liquidity. T… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

21 extracted references · 15 canonical work pages

[1]

Ethereum: A secure decentralised generalised transaction ledger,

G. Wood, “Ethereum: A secure decentralised generalised transaction ledger,” Ethereum Project Yellow Paper, vol. 151, 2014

work page 2014
[2]

Arbitrum: Scalable, private smart contracts,

H. Kalodner, S. Goldfeder, X. Chen, S. M. Weinberg, and E. W. Felten, “Arbitrum: Scalable, private smart contracts,” in 27th USENIX Security Symposium (USENIX Security 18) , 2018, pp. 1353–1370

work page 2018
[3]

Optimistic and validity rollups: Analysis and comparison between optimism and starknet,

L. Donno, “Optimistic and validity rollups: Analysis and comparison between optimism and starknet,” arXiv preprint arXiv:2210.16610 , 2022

arXiv 2022
[4]

Scroll is the leading zero-knowledge rollup. scaling ethereum for good

“Scroll is the leading zero-knowledge rollup. scaling ethereum for good.” https://scroll.io/, 2022

work page 2022
[5]

Zksync is an ever expanding verifiable blockchain network, secured by math,

“Zksync is an ever expanding verifiable blockchain network, secured by math,” https://zksync.io/, 2022

work page 2022
[6]

The superchain ecosystem platform accelerates the adoption and de- velopment of the op stack

“The superchain ecosystem platform accelerates the adoption and de- velopment of the op stack.” https://www.superchain.eco/, 2023

work page 2023
[7]

Liquidity fragmentation on decentralized exchanges,

A. Lehar, C. Parlour, and M. Zoican, “Liquidity fragmentation on decentralized exchanges,” arXiv preprint arXiv:2307.13772 , 2023

arXiv 2023
[8]

Hop: Send tokens across rollups,

C. Whinfrey, “Hop: Send tokens across rollups,” 2021

work page 2021

Show all 21 references

[9]

zkbridge: Trustless cross-chain bridges made practical,

T. Xie, J. Zhang, Z. Cheng, F. Zhang, Y . Zhang, Y . Jia, D. Boneh, and D. Song, “zkbridge: Trustless cross-chain bridges made practical,” in Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 3003–3017

2022
[10]

Horizon: A gas- efficient, trustless bridge for cross-chain transactions,

R. Lan, G. Upadhyaya, S. Tse, and M. Zamani, “Horizon: A gas- efficient, trustless bridge for cross-chain transactions,” arXiv preprint arXiv:2101.06000, 2021

2021 arXiv
[11]

Zetachain: the future of multichain

“Zetachain: the future of multichain.” 2022. [Online]. Available: https://www.zetachain.com/

2022
[12]

Native cross chain swaps

“Native cross chain swaps.” 2021. [Online]. Available: https://chainflip. io/

2021
[13]

Interlay:use your bitcoin. anywhere

“Interlay:use your bitcoin. anywhere.” 2021. [Online]. Available: https://interlay.io/

2021
[14]

Sok: Security and privacy of blockchain interoperability,

A. Augusto, R. Belchior, M. Correia, A. Vasconcelos, L. Zhang, and T. Hardjono, “Sok: Security and privacy of blockchain interoperability,” in 2024 IEEE Symposium on Security and Privacy (SP) . IEEE, 2024, pp. 3840–3865

2024
[15]

1inch network offers a defi ecosystem with products like 1inch dapp, wallet, developer portal, portfolio, and fusion for secure web3 opera- tions

“1inch network offers a defi ecosystem with products like 1inch dapp, wallet, developer portal, portfolio, and fusion for secure web3 opera- tions.” https://1inch.io/, 2023

2023
[16]

Swoop exchange: A decentralized exchange aggregator,

“Swoop exchange: A decentralized exchange aggregator,” https:// swoopexchange.com, 2024

2024
[17]

Matcha: A decentralized exchange aggregator,

“Matcha: A decentralized exchange aggregator,” https://matcha.xyz, 2024

2024
[18]

Conflict-free replicated data types (crdts),

N. Preguiça, C. Baquero, and M. Shapiro, “Conflict-free replicated data types (crdts),” arXiv preprint arXiv:1805.06358 , 2018

2018 arXiv
[19]

Efficient syn- chronization of state-based crdts,

V . Enes, P. S. Almeida, C. Baquero, and J. Leitão, “Efficient syn- chronization of state-based crdts,” in 2019 IEEE 35th International Conference on Data Engineering (ICDE) . IEEE, 2019, pp. 148–159

2019
[20]

Google bigquery: Serverless, highly scalable, and cost-effective multi- cloud data warehouse,

“Google bigquery: Serverless, highly scalable, and cost-effective multi- cloud data warehouse,” https://cloud.google.com/bigquery, 2024

2024
[21]

Zksync block explorer api

“Zksync block explorer api.” 2021. [Online]. Available: https: //docs.zksync.io/zksync-era/tooling/block-explorers

2021

Pith tools

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

[1] [1]

Ethereum: A secure decentralised generalised transaction ledger,

G. Wood, “Ethereum: A secure decentralised generalised transaction ledger,” Ethereum Project Yellow Paper, vol. 151, 2014

work page 2014

[2] [2]

Arbitrum: Scalable, private smart contracts,

H. Kalodner, S. Goldfeder, X. Chen, S. M. Weinberg, and E. W. Felten, “Arbitrum: Scalable, private smart contracts,” in 27th USENIX Security Symposium (USENIX Security 18) , 2018, pp. 1353–1370

work page 2018

[3] [3]

Optimistic and validity rollups: Analysis and comparison between optimism and starknet,

L. Donno, “Optimistic and validity rollups: Analysis and comparison between optimism and starknet,” arXiv preprint arXiv:2210.16610 , 2022

arXiv 2022

[4] [4]

Scroll is the leading zero-knowledge rollup. scaling ethereum for good

“Scroll is the leading zero-knowledge rollup. scaling ethereum for good.” https://scroll.io/, 2022

work page 2022

[5] [5]

Zksync is an ever expanding verifiable blockchain network, secured by math,

“Zksync is an ever expanding verifiable blockchain network, secured by math,” https://zksync.io/, 2022

work page 2022

[6] [6]

The superchain ecosystem platform accelerates the adoption and de- velopment of the op stack

“The superchain ecosystem platform accelerates the adoption and de- velopment of the op stack.” https://www.superchain.eco/, 2023

work page 2023

[7] [7]

Liquidity fragmentation on decentralized exchanges,

A. Lehar, C. Parlour, and M. Zoican, “Liquidity fragmentation on decentralized exchanges,” arXiv preprint arXiv:2307.13772 , 2023

arXiv 2023

[8] [8]

Hop: Send tokens across rollups,

C. Whinfrey, “Hop: Send tokens across rollups,” 2021

work page 2021