LPOR: A Layered Proof of Reserves Framework for Usable and Publicly Auditable Solvency Verication Donggoo Kim
Rajesh Upadhayaya
College of Computing Georgia Institute of Technology Atlanta, USA [email protected]
Computer Science University of New Mexico Albuquerque, USA [email protected]
Milosz Bator
Tao Le
College of Computing Georgia Institute of Technology Atlanta, USA [email protected]
College of Computing Georgia Institute of Technology Atlanta, USA [email protected]
Abstract—Proof of Reserves (PoR) enables centralized crypto exchanges to demonstrate that on-chain reserves are sufcient to cover customer liabilities. However, existing approaches, including Merkle-tree-based proofs and zero-knowledge PoR systems, remain difcult for everyday users to verify in practice, resulting in limited participation and weakened transparency. We introduce LPOR, a layered, usability-focused PoR framework that separates lightweight user-side checks from auditor-level cryptographic verication, enabling non-technical users to verify inclusion and publicly recompute total liabilities with minimal friction. By lowering verication barriers, LPOR increases user participation and substantially improves the probability of detecting omitted liabilities. We evaluate its scalability and omission detectability at a multi-million-user scale. Index Terms—proof of reserves, centralized exchanges, solvency verication, public auditability, Merkle trees
recompute total liabilities in a human-readable form, while auditors independently verify that the published ledger is bound to the exchange’s Merkle commitment. The system therefore assigns clear roles to the CEX, users, and auditors without requiring every participant to execute cryptographic verication code. Our contributions are: • Separation of user and auditor verication roles • Minimal technical effort for user-side verication • Publicly veriable computation of total liabilities • No disclosure of user-identiable information
I. I NTRODUCTION
Wallet address disclosure provides transparent evidence of on-chain assets, but it does not account for liabilities and therefore cannot establish solvency on its own [8]. It also remains vulnerable to snapshot manipulation such as temporary reserve borrowing, making it an incomplete PoR mechanism [6], [7].
Proof of Reserves (PoR) is intended to let centralized exchanges demonstrate that on-chain reserves are sufcient to cover customer liabilities. While we use the term Proof of Reserves (PoR) following industry convention, LPOR primarily addresses the proof of liabilities component. Custodial platforms remain a primary access point for digital assets, yet past failures such as Mt. Gox and FTX show that users cannot safely treat exchange solvency as implicit [1], [3]. Existing PoR approaches do not fully meet that goal. Address disclosure reveals assets but not liabilities, Merkletree PoR supports liability inclusion proofs but is cumbersome for ordinary users, and zero-knowledge PoR improves privacy and expressiveness at the cost of greater implementation and verication complexity. This creates asymmetric veriability: auditors can assess proofs, while users face high technical barriers. We propose LPOR, a layered PoR framework that separates lightweight checks from auditor-level cryptographic verication. LPOR exposes a public liability ledger built from tokenized balances, allowing users to verify inclusion and
II. E XISTING P O R T ECHNIQUES A. Wallet Address Disclosure PoR
B. Merkle-Tree-Based PoR Merkle-tree-based PoR adds user-level liability inclusion proofs while preserving privacy, and it is widely deployed in practice [4], [5], [9]. Its main limitations are poor usability for ordinary users and the inability to publicly recompute total liabilities from the opaque commitment alone [2]. C. Zero-Knowledge-Proof-Based PoR Zero-knowledge PoR can prove aggregate solvency while hiding individual balances and avoiding some forms of auditor trust [3], [10]. However, these systems rely on substantially more complex proof infrastructure and remain difcult for non-technical users to inspect or verify directly. Recent works on Proof of Liabilities (PoL), such as [11], [12], explore privacy-preserving constructions using commitments and zero-knowledge techniques. While these approaches
provide strong cryptographic guarantees, they often require specialized verication and introduce signicant complexity for end users. LPOR takes a complementary approach by focusing on usability and participation rather than stronger cryptographic expressiveness. III. LPOR: L AYERED P ROOF OF R ESERVES A. Protocol Overview System Roles. LPOR involves three parties: (i) the centralized exchange (CEX), which generates and publishes the proof; (ii) users, who verify inclusion of their balances and check total liabilities; and (iii) auditors, who recompute Merkle commitments to ensure cryptographic binding. LPOR assumes at least one honest auditor and relies on public veriability rather than trust in any single party. LPOR Classic Merkle PoR Auditor layer Rroot h1
h1,1
L1
L2
h2
h1,2
L3
L4
h2,1
L5
L6
h2,2
L7
L8
PLL1 PLL2 PLL3 PLL4 PLL5 PLL6 PLL7 PLL8 User layer
LPOR shifts cryptographic verication from end users to an open auditor layer (i.e., any independent, technically capable party) by decoupling (i) lightweight user checks from (ii) auditor recomputation of binding Merkle commitments, improving usability without weakening the binding property of the Merkle commitment. This separation shifts verication from institution-driven proofs to user-driven validation through simple aggregation. Specically, LPOR ensures: (1) individual liability values are publicly accessible in anonymized form, (2) no useridentiable information is disclosed, (3) the total sum of all user balances is publicly veriable, and (4) verication tasks are divided into a user-facing layer and a non-interactive auditor layer. Unlike classical Merkle-tree-based PoR schemes, LPOR does not require a trusted third-party auditor to privately aggregate user balances in order to compute total liabilities. Protocol 1: Balance Tokenizer. The exchange converts each user’s balance into standardized denomination tokens (e.g., 0.1 TBTC, 1 TBTC). Each token is assigned a unique identier (UUID) derived from the user’s account information in a privacy-preserving manner.
Protocol 2: Public Liability Ledger. The exchange publishes a publicly accessible data table containing the tokenized balances generated by the Balance Tokenizer. This enables users to independently verify the inclusion of their assets and validate the publicly computed total sum of all balances in a human-readable format. B. Trust Assumptions and Commitments For each proof epoch, the exchange publishes (i) the Public Liability Ledger (PLL), (ii) a Merkle root R committing to all PLL records, and (iii) a set of disclosed reserve wallet addresses. In classical Merkle PoR, the commitment binds to semantically opaque hash values (e.g., a leaf hash such as 688787d8f), which prevents public recomputation of total liabilities without access to the exchange’s internal records. In contrast, LPOR commits to an explicit, non-negative liability ledger. Each Merkle leaf corresponds to a tokenized balance record of the form (UUID, token, value) for example (688787d8f, TBTC, 0.1), where UUID is a deterministic hash over user-specic data, token attributes, and the proof identier. This preserves cryptographic binding while making total liabilities publicly veriable via a simple summation over the PLL. Under standard hash collisionresistance assumptions, the published Merkle root R is a binding commitment to the full liability set. As described in the system model, LPOR relies on open verication, where independent auditors can recompute and validate the published commitments. Verication is deterministic and publicly reproducible under standard cryptographic assumptions. C. Balance Tokenizer The Balance Tokenizer is the foundational component of LPOR that transforms user balances into standardized tokens, enabling public verication of liabilities. Tokenization serves a dual role: (i) enforcing non-negativity by construction, and (ii) enabling public aggregation without revealing exact user balances, which would otherwise be directly exposed in a raw balance list. Tokenization also introduces shared denomination patterns across users, providing limited k-anonymity while preserving public veriability. 1) Tokenization Process: The Balance Tokenizer operates by decomposing each user’s BTC balance into standardized denominations using a greedy algorithm. For a given user balance, the system creates tokens in descending order of value: 10 TBTC, 1 TBTC, 0.1 TBTC, and 0.01 TBTC tokens. For example, a user with a balance of 3.12 BTC would receive three 1 TBTC tokens, one 0.1 TBTC token, and two 0.01 TBTC tokens, fully representing their holdings through discrete, standardized units. U U IDi = H(user idi || tokeni || valuei || proof id) Each generated token receives a unique identier (UUID) derived from a cryptographic hash of the user’s account
information combined with token attributes and a public proof identier. The proof_id is xed for all tokens within a given proof epoch and changes across snapshots, ensuring that identiers remain consistent within a proof while differing across distinct proofs. Users can deterministically derive their identiers from account information, although in practice the exchange may provide these identiers to simplify verication. This hash-based construction enables users to verify token inclusion without revealing their identity to external observers, while preserving privacy and reducing linkage of user balances across different proof epochs. D. Public Liability Ledger The output of the Balance Tokenizer is the Public Liability Ledger (PLL), a critical interactive layer that enables publicly veriable proof of liabilities in a human-readable format. The Public Liability Ledger (PLL) is a mirrored data table derived from the User Balance Table in the CEX’s internal database. This transformation is performed by the LPOR Balance Tokenizer. TABLE I P UBLIC L IABILITY L EDGER E XAMPLE User (private) User 1 User 2 User 2 User 2 User 2 User 1 User 3
UUID 688787d8f 5fd924625 d8a928b20 b013907f9 3c95ec524 564e5ede3 9b19be624
Token TBTC TBTC TBTC TBTC TBTC TBTC TBTC
Value 0.1 0.1 1 1 1 10 100
Users can only verify the association between tokens and their own accounts, as the User column is private. Inclusion Proof: A user conrms that their tokens appear in the PLL. • Total Sum Proof: The total sum of all values in the PLL, with no negative balances, can be computed via a simple summation.
•
E. Public Auditor Verication The auditor layer is open: any independent party can recompute and verify the published commitments. Each PLL record is hashed as Li = H(UUIDi || tokeni || valuei ), and auditors recompute the Merkle tree to verify that the resulting root matches the published commitment. This process is deterministic and publicly reproducible, enabling independent verication. In practice, such verication is performed by third parties with economic or reputational incentives, including regulators, security rms, and independent researchers.
IV. T HREAT M ODEL AND S ECURITY G OALS Threat Model. We model the centralized exchange (CEX) as a potentially malicious prover that may misrepresent its solvency. We consider three adversarial behaviors: (i) omission of liabilities, (ii) manipulation via hidden negative balances, and (iii) inconsistent disclosure of liability data across users. LPOR adopts an open auditing model, where correctness holds as long as at least one independent verier recomputes and validates the published commitment. Security Goals. LPOR targets the following goals: (G1) Binding: a published snapshot cannot be altered without detection under standard hash assumptions; (G2) Public auditability: any party can recompute total liabilities and verify consistency with the published commitment; (G3) Omission detectability: missing liabilities can be detected with probability increasing in user participation. Defense Mechanisms. Omission (G3). LPOR exposes a human-readable Public Liability Ledger (PLL), allowing users to verify inclusion of their balances. Omitted liabilities can therefore be detected when affected users participate. Internal offsets (G1). All liabilities are represented as nonnegative standardized tokens, preventing hidden negative balances and enforcing non-negativity by construction. Inconsistent disclosure (G1, G2). LPOR commits to a single Merkle root over the PLL. Any inconsistent views result in mismatched commitments, which are detectable through public recomputation. Limitations. LPOR does not prevent short-term reserve borrowing (“window dressing”), a limitation shared by snapshotbased PoR systems. V. E VALUATION A. Qualitative Evaluation TABLE II C OMPARISON OF P O R METHODS . L. I NCLUSION DENOTES USER - VERIFIABLE LIABILITY INCLUSION ; L. S UMMATION DENOTES PUBLIC RECOMPUTATION OF TOTAL LIABILITIES . Property
Addr. disclosure
MerklePoR
zk-PoR
LPOR
Assets L. Inclusion L. Summation Veriability User Effort Complexity
O X X Public Low Low
O O X Partial High Medium
O O O Public High High
O O O Public Low Medium
We compare four PoR approaches along dimensions most relevant to practical transparency and user participation. Wallet Address Disclosure provides public visibility into on-chain assets with minimal user effort, but does not account for liabilities. Merkle PoR introduces cryptographic liability inclusion via Merkle commitments. While users can verify inclusion of their own balances, the opaque commitment prevents public recomputation of total liabilities and imposes high verication effort.
zk-PoR enables cryptographic verication of aggregate solvency, including liability summation, without revealing individual balances. However, proof generation and verication rely on specialized cryptographic infrastructure, limiting accessibility for non-technical users. LPOR (proposed) exposes a public, tokenized liability ledger that supports both user-veriable inclusion and public liability summation through simple checks. It achieves public auditability with low user effort and moderate complexity while maintaining cryptographic binding via Merkle commitments. B. Quantitative Evaluation We evaluate LPOR along deployment-critical scalability axes: (i) exchange-side proof generation cost, (ii) proof size, and (iii) public verication time. Experimental setup: We vary the number of users as the independent variable (N ∈ {104 , 105 , 106 , 107 }). All measurements are single-threaded on commodity hardware (macOS, Python 3.11; 16 CPU cores available, 128 GB RAM). Public verication assumes a realistic 100 Mbps download rate. Each proof epoch publishes: (i) the Public Liability Ledger (PLL), (ii) a Merkle root commitment, and (iii) minimal metadata. All experiments assume a single asset type (BTC). TABLE III Q UANTITATIVE SCALABILITY RESULTS ( SINGLE - THREADED ). “P ROOF SIZE ” INCLUDES PLL + M ERKLE ROOT + METADATA . “P UBLIC VERIFY ” INCLUDES DOWNLOAD + RECOMPUTATION ( SUM + M ERKLE RECOMPUTATION ) ASSUMING 100 M BPS . Users
Proof Size
Proof Generation
Public Recomputation
104
5.10 MB 51.13 MB 510.97 MB 5.11 GB
0.69 s 7.69 s 81.42 s 880.89 s
0.53 s 5.40 s 54.96 s 568.76 s
105 106 107
Across all scales, LPOR shows predictable linear growth in proof size, proof generation, and public recomputation time. Proof size stays near ≈536 bytes/user, and end-to-end proof generation reaches 10.5 minutes at 107 users. Public recomputation is similarly practical: at 107 users, full verication completes in 9.48 minutes under a 100 Mbps link, with most of the cost due to downloading the PLL rather than cryptographic processing. Takeaway: LPOR preserves public auditability at multimillion-user scale on commodity hardware, with costs dominated by simple linear data processing rather than specialized cryptography. C. Omission Detectability Analysis We analyze how LPOR improves the probability of detecting omitted liabilities by increasing user participation through low-friction verication. Let p denote the probability that a user performs inclusion verication during a proof epoch, and let k be the number of omitted users. An omission is detected if at least one omitted user veries inclusion: Pdetect = 1 − (1 − p)k .
In classical Merkle-tree-based PoR systems, inclusion verication requires executing cryptographic verication scripts, resulting in very low participation in practice. We therefore consider p ∈ [0.01%, 0.1%] for Merkle PoR. LPOR reduces verication to a human-readable check of token inclusion and public summation, enabling substantially higher participation; we evaluate p ∈ [0.5%, 5%]. TABLE IV O MISSION DETECTABILITY VS . USER PARTICIPATION . A SSUMPTIONS : 7 N = 10 USERS , OMISSION FRACTION f = 0.001%, OMITTED USERS k = 100. Participate rate p
Scheme
Detection prob.
0.01% 0.1% 0.5% 1% 5%
Merkle PoR (conservative) Merkle PoR (optimistic) LPOR (conservative) LPOR (moderate) LPOR (optimistic)
0.995% 9.52% 39.35% 63.45% 99.41%
Under these assumptions, LPOR increases omission detectability from below 10% to over 99% without altering the underlying Merkle commitment construction. The improvement arises solely from higher user participation enabled by simplied verication. VI. D ISCUSSION LPOR adopts controlled partial disclosure using standardized tokens and UUIDs, reducing direct user identiability and enforcing non-negativity without zero-knowledge complexity. Compared to zk-PoR, it trades stronger privacy guarantees for human-readable verication. Its core contribution is the separation of user checks and auditor verication. Users perform inclusion and summation checks, while auditors enforce binding via Merkle recomputation. This removes reliance on opaque auditor reports. LPOR incurs larger proof sizes due to tokenization overhead, a deliberate trade-off between storage efciency and verication accessibility, acceptable when transparency is prioritized. LPOR frames PoR verication as a socio-technical system rather than a purely cryptographic artifact, combining public readability with cryptographic commitments. VII. C ONCLUSION This work shows that PoR systems must balance cryptographic soundness with practical veriability. LPOR reframes PoR as a layered verication problem, separating low-friction, user-facing checks from auditor-level cryptographic verication. Our evaluation shows that this design enables public recomputation of liabilities at a multimillion-user scale and improves omission detectability without introducing complex zero-knowledge infrastructure. We view LPOR not as a replacement for existing PoR techniques, but as a complementary design point that highlights the role of usability in nancial transparency systems. More broadly, future PoR mechanisms should treat accessibility as a core design parameter alongside traditional cryptographic guarantees.
R EFERENCES [1] S. Fu, Q. Wang, J. Yu, and S. Chen, “FTX collapse: A Ponzi story,” 2022, arXiv:2212.09436. [Online]. Available: https://arxiv.org/abs/2212.09436 (accessed Jan. 4, 2026). [2] Z. Wilcox, “Proving your Bitcoin reserves,” Feb. 2014. [Online]. Available: https://web.archive.org/web/20171124195504/ https://iwilcox.me.uk/2014/proving-bitcoin-reserves (accessed Jan. 4, 2026). [3] G. G. Dagher, B. Bünz, J. Bonneau, J. Clark, and D. Boneh, “Provisions: Privacy-preserving proofs of solvency for Bitcoin exchanges,” in Proc. ACM SIGSAC Conf. Computer and Communications Security (CCS), 2015, pp. 720–731. [4] Kraken, “Proof of reserves.” [Online]. Available: https://www.kraken.com/en-pl/proof-of-reserves (accessed Jan. 4, 2026). [5] BitMEX, “Proof of reserves & liabilities.” [Online]. Available: https://www.bitmex.com/app/porl (accessed Jan. 4, 2026). [6] C. Decker and R. Wattenhofer, “Bitcoin transaction malleability and MtGox,” in Proc. Int. Conf. Financial Cryptography and Data Security, 2014. [7] J. Adelstein and N.-K. Stucky, “Behind the biggest Bitcoin heist in history: Inside the implosion of Mt. Gox,” The Daily Beast, May 2016. [Online]. Available: https://www.thedailybeast.com/behind-the-biggestbitcoin-heist-in-history-inside-the-implosion-of-mt-gox/ (accessed Jan. 4, 2026). [8] S. Fortis, “Binance shares wallet addresses and activity after proof of reserves pledge,” Cointelegraph, Nov. 2022. [Online]. Available: https://cointelegraph.com/news/binance-shares-walletaddresses-and-activity-after-proof-of-reserve-pledge (accessed Jan. 4, 2026). [9] A. M. Antonopoulos, Mastering Bitcoin, 2nd ed. Sebastopol, CA, USA: O’Reilly Media, 2017. [10] B. S. Reddy, “A zk-SNARK based proof of assets protocol for Bitcoin exchanges,” 2022, arXiv:2208.01263. [Online]. Available: https://arxiv.org/abs/2208.01263 (accessed Jan. 4, 2026). [11] A. Narayanan, J. Bonneau, E. Felten, A. Miller, and S. Goldfeder, “Proofs of Liabilities for Cryptocurrency Exchanges,” Cryptology ePrint Archive, Paper 2021/239, 2021. [Online]. Available: https://eprint.iacr.org/2021/239 [12] Y. Liu, K. Nayak, F. Zhang, and others, “Privacy-Preserving Proofs of Liabilities for Digital Asset Exchanges,” Cryptology ePrint Archive, Paper 2021/1350, 2021. [Online]. Available: https://eprint.iacr.org/2021/1350