Proof-of-Solvency Implementation with Privacy Protection Using Blockchain

Abstract

Trust in financial institutions hinges on the ability to prove solvency, yet recent crises have exposed the limits of audits and opaque governance. We introduce a practical protocol that enables crypto-exchanges and other financial actors to demonstrate real-time solvency without continuous third-party oversight, while preserving transparency and regulatory alignment. Complemented by a Particles model that fragments transactions to protect privacy and enhance liquidity, this framework integrates solvency, privacy, and governance into a unified standard. We argue that it represents a potential revolution in the financial industry.

1. Introduction

Recent years have witnessed a series of high-profile solvency crises within the cryptocurrency and traditional financial sectors, eroding public trust and highlighting the critical need for enhanced transparency and accountability. The collapse of FTX, a bankrupt crypto-exchange, where a significant portion of customer deposits were reportedly diverted to Alameda Research, exposed the dangers of opaque financial practices and inadequate oversight. Similarly, the challenges faced by Circle, with a substantial USD 3.3 billion held in the vulnerable SVB account, underscore the systemic risks that can impact even seemingly stable entities. Furthermore, the insolvency of Three Arrows Capital (3AC) following the sharp depreciation of Bitcoin in 2021 serves as a stark reminder of the volatile nature of cryptocurrency markets and the importance of robust risk management strategies. These events collectively raise a fundamental question: how can blockchain technology, with its inherent transparency and immutability, be effectively leveraged to prevent such solvency issues, restore confidence in financial institutions, and mitigate the systemic risks that threaten the stability of the entire ecosystem?

In response to these challenges, the concept of proof of solvency has emerged as a critical area of focus. Unlike traditional systems that rely on trust and periodic audits, proof of solvency seeks to provide verifiable and continuous assurance that an institution possesses sufficient assets to meet its liabilities at any given time. The core premise of proof of solvency lies in establishing a transparent and auditable framework where an institution can cryptographically demonstrate its solvency to stakeholders, thereby fostering trust and reducing the potential for fraudulent or irresponsible financial practices, and in a 24/7 live environment constituting the blockchain world. Achieving this requires addressing two fundamental questions: How can an institution convincingly prove its assets? And how can it transparently demonstrate its liabilities? The subsequent sections of this paper delve into these questions, exploring novel methodologies and architectural considerations for implementing robust and privacy-preserving proof-of-solvency solutions within blockchain-based financial systems.

Beyond its immediate applications in mitigating cryptocurrency-related risks, the proof-of-solvency framework represents a profound revolution in risk management principles, offering a blueprint for increased transparency and accountability across diverse financial sectors. This is not merely an incremental improvement but rather an invitation to reimagine the very foundations upon which corporate relationships are built within financial institutions. By shifting from a reliance on opaque, trust-based systems to verifiable, cryptographically backed solvency assurances, we can empower stakeholders with unprecedented insight into the financial health of organizations, fostering a more responsible and resilient global financial ecosystem. As thoroughly depicted in this paper, the implications extend far beyond cryptocurrency exchanges, offering a pathway toward systemic reforms that promote stability, reduce the potential for fraud, and ultimately reshape the landscape of risk management.

More specifically, proof of solvency hinges on two distinct proofs. The first concerns liabilities, wherein the institution (henceforth referred to as the exchange without loss of generality) demonstrates its unwavering commitment to honoring obligations to both customers and external liquidity providers. The second focuses on reserves or assets, where the exchange rigorously establishes that its holdings are sufficient to fully cover these liabilities.

Solvency has been a subject of extensive study within the realm of cryptocurrencies [1,2,3,4,5,6] (with mathematical blockchain properties providing a foundational starting point for solvency research, as noted in [7]). Existing proposals address proof-of-solvency within both audited environments (e.g., [2]) and unaudited scenarios (e.g., [3]). For early-stage ventures, a comprehensive audit may demand resources disproportionate to their means. While regular audits bolster the credibility of solvency verification, their associated costs can significantly diminish assets available for other crucial operations. Nonetheless, a third party will systematically be necessary for the control of the implementation (a state could represent this third party). The non-audited approaches to solvency proof, proposed to date, tend to be cryptographically driven (e.g., [3]). However, these approaches present challenges: (i) they primarily guard against the under-claiming of liabilities, offering limited protection against over-claiming, and (ii) they often presume access to public keys associated with Unspent Transaction Outputs (UTXOs) (or an address which contains bitcoins that have not been spent yet). A significant drawback lies in the susceptibility to inflating liabilities by strategically masking assets, potentially for tax optimization purposes. Furthermore, the cryptographic protocols underpinning asset verification are predicated on assumptions that may not hold true, e.g., the exchange might not possess the private key associated with the UTXOs, or it might decline to generate one upon request. The wealth of technical literature in this domain, while valuable, often lacks the practical considerations essential for real-world implementation, a gap this paper aims to bridge.

Therefore, existing research frequently overlooks the practical aspects of proof of solvency. Certain proposed solutions prove infeasible in practice, while others suffer from inherent limitations. Within the context of exchanges (typically Centralized Exchanges, or CEXs), prevailing implementations often fail to capture the nuanced dynamics and interdependencies between various counterparties. A truly effective proof-of-solvency mechanism must account for the full spectrum of relationships involved.

Beyond the establishment of a robust solvency proof, a further challenge arises: the potential for privacy breaches through UTXO tracing on the blockchain. The immutable ledger inherent to blockchain technology exposes user transaction data, creating opportunities for privacy attacks. This issue persists even in multi-transaction environments [8]. Moreover, statistical techniques, such as clustering spent and unspent outputs, have proven effective in unraveling the pseudonymity afforded by blockchains [9]. To counter these privacy risks, we introduce a method designed to reduce the probability of an attacker successfully linking address clusters to specific users.

This document aims to reconcile the goal of providing proof of solvency within a crypto-exchange-like company (comprising customers and external exchanges, i.e., liquidity providers). This approach, however, possesses the flexibility to be broadened to encompass any financial institution, or even states, contingent upon the presence of other stablecoin exchanges that serve as a bridge between the tokenized ecosystem and the traditional fiat currency system, and to which a standard audit cannot be avoided. Our solution will rigorously distinguish between assets and liabilities, offering a means to verify crypto assets recorded on a public blockchain, alongside fiat currencies (GBP, EUR, USD). The ultimate objective is to obviate the need for costly third-party audits by achieving an appropriate level of public disclosure. While implementing our solution will entail some expense, regular monitoring of its operation—particularly in its initial stages—remains essential. Furthermore, we address the privacy and security concerns stemming from public disclosure. Our proposal seeks to minimize the risk of user identification to near-negligible levels by employing multiple inputs and outputs, thereby increasing entropy, a privacy metric that we leverage to develop a fair price for typical transactions (for a blockchain introduction of the entropy of privacy, see [7]) [10,11,12]. Privacy has been studied in the literature [13,14,15,16,17,18].

In addition, ref. [19] addresses a critical challenge in the digital age: protecting intellectual property rights while preserving privacy. Their Ethereum-based system, employing ECC encryption and zk-SNARKs, mirrors our concern for balancing transparency with user privacy. Just as they leverage blockchain’s immutability for copyright authentication, our work utilizes blockchain for verifiable solvency, striving for a similarly robust and privacy-respecting framework in the financial domain. Ref. [20] deals with Sybil attacks in vehicular networks using a blockchain-based Proof-of-Location (PoL) system with privacy preservation. Similar to our approach in the financial domain, their work leverages blockchain’s immutability for verifiable data (location information) and implements mechanisms to protect user privacy. The challenges posed by Sybil attacks, where multiple fake identities are created, mirror the risks of over-claiming liabilities in our context, highlighting the broader need for robust verification methods and privacy-preserving techniques within decentralized systems. Ref. [21] tackles the challenge of data availability attacks on blockchains, a critical issue that limits their applicability. Their solution, combining coding theory with a zero-knowledge accumulator, shares a common goal with our work: ensuring data integrity and security while preserving privacy. Just as they aim to prevent fraudulent information generation by protecting the accumulation set, we strive to prevent the inflation of liabilities through privacy-preserving mechanisms in our proof-of-solvency framework. Finally, ref. [22] proposes a privacy-protection method for blockchain transactions using lightweight homomorphic encryption and zero-knowledge proofs. Like our work, their approach prioritizes data security and user privacy. By using the Paillier algorithm and zero-knowledge proofs to verify data legitimacy, they create a system where transaction details are encrypted, ensuring both security and efficiency, and this objective is in line with the privacy goals of our model.

In this paper, we propose a fundamental approach to build an order book respecting users’ privacy.

The remainder of this paper is structured as follows. Section 2 presents a solvency protocol tailored for cryptocurrencies, while Section 3 details a corresponding protocol applicable to fiat currencies through tokenization. These sections form the core of our proposed framework. Section 4 outlines recommendations for public disclosure that enhance the implementation of the solvency protocol. Subsequently, Section 5 introduces the Particles model, with Section 6 providing the mathematical underpinnings. Together, these sections represent the second key element of our approach. Finally, Section 7 develops a methodology for deriving a fair price based on an optimal calibration of trading costs, while Section 8 shows empirical evidence to support the proposed proof-of-solvency protocol and the Particles model. We conclude in Section 9.

Throughout this paper, $\lfloor ·\rfloor$ denotes the floor function, $\lceil ·\rceil$ represents the ceiling function, and $a,b=\{a,a+1,\cdots ,b-1,b\}$ defines the integer interval for integers $a<b$. All discussions are framed within the context of a specified exchange. Where ambiguity arises between different exchanges, we denote the exchange of interest as ‘E’.

Key contributions of the paper

• Practical Proof-of-Solvency Framework: A comprehensive, step-by-step protocol for cryptocurrency exchanges to demonstrate solvency or insolvency.
• Clear Distinction Between Assets and Liabilities: A methodology for rigorous separation and independent verification of assets and liabilities.
• Adaptation to Fiat Currencies: A practical approach to proving solvency for fiat holdings through tokenization.
• Guidance on Public Disclosure: Recommendations for transparent information disclosure that eliminates the need for costly third-party audits.
• Privacy Enhancement via Particles Model: A novel ‘Particles Model’ to mitigate privacy risks associated with UTXO tracing, improving user anonymity.
• Fair Price Derivation: A methodology for determining a fair transaction price through optimal calibration, balancing exchange profitability and user costs.
• Comprehensive Consideration of Counterparties: Accounting for the complexities of relationships between exchanges, customers, and external liquidity providers.

2. Proof-of-Solvency Protocol for Cryptocurrencies

2.1. Overall Protocol

Figure 1 shows a schema explaining the details for the protocol. The sequence of this section deals with explanation of this protocol.

Figure 1. Protocol implementation for proof of solvency, regarding bitcoin or ether assets (the b’s are the balances, x designates the private key, and B the total Liquidity Providers liability).

2.2. Exchange Proof of Reserves

In essence, cryptocurrency reserves come from addresses stored on the blockchain and owned by the exchange. This means that, for such a UTXO related to the address ${\mathrm{Address}}_i$ (i is the index identity of the considered address), the exchange possesses the private key $x_i$ (see the top green block in the blue ‘Exchange’ box on the top of Figure 1).

Schnorr Protocol

Providing proof of reserve for this address means proving to a counterparty that the exchange knows $x_i$. We can provide a proof of knowledge of $x_i$, for all the i’s, in a Zero-Knowledge framework, either by showing an adequate signature or by using the Schnorr protocol [23], which we remind as below, for any i.

• The exchange commits to the random integer $r\in 0, q-1$ (q is a large prime number which is the order of the elliptic curve secp256k1 group—a specific elliptic curve endowed with an additive operation and which is used for the Bitcoin signature; see [24], with generator G), and sends to the client $m=G^{\times r}$. (The ‘times’ product × is the multiplication on the elliptic curve, e.g., $G^{\times 2}=G\times G$. This step deviates from the traditional Pedersen commitment which involves two generators. Only G is sufficient here.)
• The client (or any party) sends the challenge $c\in 0,q-1$ to the exchange.
• The exchange sends to the client $s\equiv r+c{x}_i\left[q\right]$, (This is the usual congruence relation on $\mathbb{Z}/q\mathbb{Z}$; for the mathematical details of operations on an elliptic curve, see [7,24]) and the client validates the exchange’s knowledge of $x_i$ if $G^{\times s}=m\times y^{\times c}$, where $y=G^{\times x_i}$ (the number y is the public key $y=G^{\times x_i}$). The exchange must commit to sending the public key to the client (generate one if it does not exist).

The exchange is honest if and only if the client validates, i.e., the correctness proof is given as follows:

• The client accepts if $G^{\times s}=m·y^{\times c}$, and thus, substituting s with $r+cx$, we have the following:
• $G^{\times (r+c{x}_i)}=G^{\times r}·G^{\times \left(c{x}_i\right)}$,
• $G^{\times r}·G^{\times c{x}_i}=m\times y^{\times c}$.

The exchange thus will prove to the client its knowledge of $x_i$ (see the green blocks in the red ‘Public’ box on the center of Figure 1).

Thus, at will, the exchange could provide proof of reserve from individual addresses (and can even charge anyone who wishes to validate).

An adaptation of a ZK-STARK Protocol

The reader is welcome to replace this with another Zero-Knowledge Proof of Knowledge algorithm, at their convenience, for instance, the ZK-STARK Proof, e.g., [5]. For each on-chain address ${\mathrm{Address}}_i$, the exchange proves knowledge of $x_i$ for $y=G^{\times x_i}$ by committing (via Merkle roots) to an execution trace that computes scalar multiplication from G and the secret $x_i$ and satisfies an Algebraic Intermediate Representation (AIR; see [25]) whose boundary constraint enforces the public output y. Fiat–Shamir (seed c) derives the verifier’s random queries. The prover answers decommitments and supplies a Fast Reed–Solomon Interactive Oracle Proof of Proximity (FRI, ibid) low-degree proof. The verifier checks openings, constraint satisfaction at the sampled positions, low-degree via FRI, and the boundary $A_k=y$. Zero-knowledge is preserved by trace randomization. This can be batched over all i to yield a single proof for all exchange-owned addresses.

The selection of a specific protocol rests entirely with the exchange, bearing in mind that Schnorr-style protocols involve interaction, whereas STARK-based approaches do not need to. This choice will ultimately be shaped by the exchange’s strategic priorities.

Man-in-the-middle Attack

A man-in-the-middle (MITM) attack poses a significant threat by allowing an adversary to intercept and potentially alter communications between the exchange and the client during the signature process. This could enable the attacker to forge signatures or manipulate transaction data undetected. While our adapted Schnorr protocol aims to maintain the core security properties of the original, a formal analysis is essential to ensure resilience against MITM attacks. Integrating mitigation strategies, such as those proposed by [26], who introduces a public third party (PTP) to secure multi-signature schemes against k-sum attacks, are necessary (but beyond the scope of the paper). This approach, which involves verifiable commitments and direct communication with the PTP, could offer enhanced security against MITM vulnerabilities in our adapted protocol.

2.3. External Exchanges’ Proof of Reserves

The exchange E also possesses some cryptos at external exchanges’ (see the bottom green block in the blue “Exchange” box on the top of Figure 1). The above should apply identically, but these external exchanges may have not necessarily implemented any proof protocol yet. Thus, the only ‘evidence’ the exchange has is a piece of paper, or receipt (what we call ‘receipt’ in this paper is a document which legally proves we have reserves to the external exchange; if no such document is available, then the exchange should gather the most documented paper/notification which writes it as the reserve in this exchange) as for any bank. The external exchanges provide the address ${\mathrm{Address}}_j$ and related balance $b_j$, for all j’s. These addresses are not owned by the exchange E (which does not possess the private key) and cannot be proven in a zero-knowledge environment as above. However, the addresses ${\mathrm{Address}}_j$’s are supposed to be in the blockchain, and anyone can check their contents (including date of transaction).

Thus, there may be one way the exchange E can prove the external exchange owes cryptos to it: see $(\ast )$ in green in Figure 1. Specifically, if the external exchange owes the exchange E a balance $b_j$, this means the exchange E could have sent $b_j$ from a previous address ${{\mathrm{Address}}^{\prime }}_j$ for which the exchange E owns the private key $x_j$. Thus, the exchange E can prove it owned this address using the Schnorr protocol, depicted in Section 2.2.

In another scenario where the external exchange owes the exchange E a balance $b_j$, it may also be because the exchange gave some fiats in exchange for an amount $b_j$ of bitcoins. In this case, ${{\mathrm{Address}}^{\prime }}_j$ refers to the receipt proving the exchange occurred. It is important to keep in mind that this receipt is the original one, used for filling the company’s balance sheet.

As a sum-up, the exchange could disclose the following:

• All the addresses ${\mathrm{Address}}_i$’s and ${\mathrm{Address}}_j$’s. The exchange can prove it owns the addresses ${\mathrm{Address}}_i$’s and ${{\mathrm{Address}}^{\prime }}_j$’s.
• The double-sh256 hash of the balances $b_i$’s and $b_j$’s—written $\mathrm{H}\left(b_i\right)$ and $\mathrm{H}\left(b_j\right)$, respectively—related to the ${\mathrm{Address}}_i$’s and the ${\mathrm{Address}}_j$’s, to the public.
• The total reserve amount ${\sum }_i{b}_i+{\sum }_j{b}_j$.

From these three points, there are two levels of confidentiality disclosure here:

• The exchange E does not provide any individual balance but their hashes;
• The exchange E provides all the addresses publicly so that the individual balances can be checked, but it will ask for further effort from the verifier.

Despite its non-necessary step, the hashes disclosure (point 2. above) allows the verifier to check that the reserves have been considered in the total reserve; see point 3 above. For this reason, the exchange can choose to disclose the double-sha256 hash of the total reserve $\mathrm{H}({\sum }_i{b}_i+{\sum }_j{b}_j)$ instead of the total reserve itself ${\sum }_i{b}_i+{\sum }_j{b}_j$, to further mask the reserve information. It is worth pointing out that the amounts $b_i$’s and $b_j$’s are shown in the blockchain.

2.4. Proof of Liabilities

This is the most sophisticated part of the proof-of-solvency aspects. The liabilities are acting as a symmetry to the reserves as illustrated in Figure 1: the exchange E possesses a list of addresses—which have cryptos they owe to clients, but also they owe cryptos to the external exchanges. However, the symmetry is broken due to the fact that the clients need to validate the liabilities of the exchange.

We specifically focus on addresses that are related to the exchange’s clients in this section, while next section deals with external exchanges’. Contrary to the reserves, there is a high confidentiality level when focusing on the information of the clients (e.g., their individual privacy), who have all legitimate reasons not to want to disclose their balances. Acting essentially the same as for the reserves is thus problematic. There are two causes that actually break the symmetry we have just mentioned:

• Clients do not want the public to see their information, some of which are in their addresses ${\mathrm{Address}}_k$’s (contrary to point 1 in Section 2.3) (see the top yellow block in the blue ‘Exchange’ box on the top of Figure 1);
• Clients can verify their own balance.

Bearing this in mind, three levels of disclosure are possible (and we believe only three are possible):

• Either the exchange E discloses all the client balances or $b_k$’s only. This will allow individuals to see all the liabilities and simply add them to obtain the exchange’s total liability. The problem with this possibility is that it does not prove that exchange E owes these values, and it does not allow individual clients to check if they indeed have an indicated balance, only that there are two identical balances, which is not trustworthy. This possibility is confusing, non-informative, and it violates point 1 above.
• To remedy the issue raised in point 1, the only way exchange E proves it owes the above disclosed balances is to disclose the related addresses ${\mathrm{Address}}_k$’s so that the exchange provides a proof it owns the private keys using the Schnorr protocol and follows the protocol given in Section 2.2. The strong disadvantage is that clients’ addresses are disclosed, which is dissatisfying.
• The last solution is that the exchange E is an intermediate between its clients and the public by providing, for example, the Liability Tree service (see Section 2.7). Although it does not provide a proof at any time contrary to the previous point, it does not invalidate that exchange E did not provide all its clients’ liabilities, unless the exchange has been dishonest and that a client realizes that their balance is incorrect. In this case, exchange E should take the risk to be severely punished by a third party, e.g., regulators or state, who likely will require any exchange to provide a solid blockchain-based balance sheet. There is simple evidence that anyone could see a number of addresses on the blockchain, which are related to liabilities: when a customer makes a buy order as an input, an explosion of outputs will be localized into the blockchain; see Section 5 explaining the Particles model. As such, a cluster of transactions will be necessarily identified to the exchange E’s platform. For this reason, we will indicate that exchange E implements this last point, in addition to the Particles model.

As a result, it seems essential to make explicit the constitution of the leaves for the Liability Tree. Section 2.7 explains in detail how to construct a Liability Tree.

2.5. External Exchanges Proof of Liabilities

In the context in which exchange E owes bitcoins to an external exchange (see the bottom yellow block in the blue “Exchange” box on the top of Figure 1), it could mean the external exchange has given bitcoins to the exchange E from address ${\mathrm{Address}}_l$ (external exchange) to address ${{\mathrm{Address}}^{\prime }}_l$’s owned by exchange E (see $(\ast \ast )$ in yellow in Figure 1), which thus possesses the private key $x_l$ and can prove it knows this using the Schnorr protocol (Section 2.2).

In the scenario where exchange E owes bitcoins because it received fiats in exchange for an amount of $b_l$ bitcoins, here again, ${{\mathrm{Address}}^{\prime }}_l$ refers to the receipt showing this transaction occurred. As for the proof of reserve, it is important to keep in mind that this receipt is the original one, used for filling the company’s balance sheet. In all the cases, exchange E can prove liability to external exchanges.

To sum up, the exchange could disclose the following:

• All the (exchange’s) clients’ leaves hashes $h_k$’s (see Section 2.7);
• The total external exchanges’ liability ${\sum }_l{b}_l$;
• The liability root as well as its balance ${\sum }_l{b}_l+{\sum }_k{b}_k$, which is the total liability;
• All the external exchanges addresses ${\mathrm{Address}}_l$’s.

In order to further mask information, the exchange could provide the hash $\mathrm{H}\left({\sum }_l{b}_l\right)$, instead of ${\sum }_l{b}_l$ in point 2 above, and the verifier could indeed check that these liabilities have been considered.

2.6. General Proof of Solvency Protocol in the Crypto Case

Figure 2 synthesizes the above proofs in the crypto case. Two main questions are indicated, and we provide answers to them below.

Figure 2. General solvency protocol for the crypto environment. The considered institution is in a center of a market (right-hand-side in the figure) within its clients and external liquidity providers (both left-hand-side). The considered institution has reserves (green) in UTXOs and they own the private keys $x_i$’s, allowing them proving reserves through a Schnorr protocol, given the fact that the underlying blockchain is public. The institution also has reserves elsewhere, raising question Q1 (see text). In addition, the considered institution has liabilities (yellow) regarding their clients, and it possesses the private keys. Running the Liability Tree (see Section 2.7) is a possibility to allow the clients to check that the institution does have their money. The considered institution also has liabilities to external liquidity providers, leading to question Q2.

Figure 2 sheds light on two essential questions in case the external institution has not implemented the above proof-of-solvency protocol.

Exchange E could possess its reserves elsewhere, hence the question Q1: what if the external exchange cannot provide a proof of asset? We see two possibilities:

• Either exchange E provides a proof of address input (if any) from which the funds have traveled (from exchange to external institution) (see (*) in Figure 1);
• Or there is no choice of a usual governance (the exchange E is free to ask a proof to the external institution though).

Similarly, the exchange E could owe some cryptos to external institutions, leading to the question Q2: How do we prove exchange E has external institution liability? Here again, there are two possibilities:

• Either the exchange E provides proof of address output (if any) from which the funds have traveled (from external institution to exchange) (see (**) in Figure 1),
• Or there is no choice of a usual governance (and again exchange E is free to ask for proof to the external institution).

We conclude that to avoid usual audits and allow 24/7 proof of solvency from a blockchain, the above process has to be standardized.

2.7. The Liability Tree

This section explains a method which actually is inspired from the Merkle Tree. The method is explained in [2], but we propose simplifications for building the Liability Tree. It is worth pointing out that the exposed algorithms here use a vectorization approach: all the hashes are calculated at the same time. One could still complexify the leaves to further respect privacy as in [6].

2.7.1. Construction of the Tree

We set $B={\sum }_l{b}_l$ the total liability owed by the exchange to the external exchanges (the exchange can always prove it owes individual liabilities to its liquidity providers; see Section 2.5).

Particular Case

We suppose we have a number of clients which is a power of 2. The exchange may create the tree as follows; see Figure 3. First, each account is organized as a leaf of a binary tree. To each leaf, we associate its hash given by $h_k=\mathrm{H}({\mathrm{Address}}_k\left|\right|b_k\left|\right|B)$, with the associated balance $b_k+B$ (and not only $b_k$). Then, each odd-ranked leaf has its hash, concatenated with the next even-ranked leaf’s, and the whole obtained vector is hashed once more. The account balance associated with this parent node is the sum of its children balance, minus B. The process is repeated again until reaching the root of the binary tree. It turns out that the balance associated with the root represents all the liabilities the exchange owes to its clients and external exchanges.

Figure 3. The Liability Tree. Each customer account is a leaf, and their hash and account balance, added with the total external exchanges’ liability B, are associated. Then each pair of IDs is concatenated and hashed into a node in the first floor, to which the sum of the below balances is associated, minus the total external exchanges’ liability. The process is iteratively repeated until reaching the root. The root and the leaves are shown to the customers for verification of their account. The balance associated with the root is the exchange’s total liability. In the notations of Algorithms 1–3, for instance, ${\mathcal{L}}_0\left(4\right)$ (ground floor $h=0$) is the node under ‘Client Hash 4’, $n_0=\dim {\mathcal{L}}_0=8$ (there are 8 leaves); ${\mathcal{L}}_1\left(3\right)$ is the node under ‘Hash 13’ (first floor $h=1$), $n_1=\dim {\mathcal{L}}_1=4$; the height of the tree is $H=3$, etc.

To elaborate more on the associated balances, the balance of a parent node is not given only by the sum of balances $b_{k_1}+b_{k_2}$ of its two children, but we now require the balance to be $b_{k_1}+b_{k_2}-B$. In this case, it can easily be proven that the balance associated with the liability root is the exchange total liability. Indeed, two brother leaves have balance $b_1+B$ and $b_2+B$, where $b_1$ and $b_2$ are the balances of the two considered clients. The parent node therefore has balance $(b_1+B)+(b_2+B)-B=b_1+b_2+B$. This easily generalizes to each floor. Thus, the last floor balance is ${\sum }_k{b}_k+B$, which is the exchange total liability.

It is worth pointing out that the hash function can be an appropriate one, particularly the SHA 3 (solving the issue of the CVE from using once the SHA 256 function) or the fast SHA256 function; see [27].

General Case

We suppose that the number of clients is not necessarily a power of 2. We consider a given floor. If the number of nodes is even, then we perform the hashing as previously explained to obtain the nodes at the above floor. If the number of nodes is odd, then we do the same but by not considering the last node, and we put this later node at the above floor. This simple process can be repeated iteratively. See Figure 4 and Figure 5 for examples.

Figure 4. General case 1: client number 5 is considered a node in the second floor.

Figure 5. General case 2: client number 7 is considered a node in the first floor.

More generally, we have the following Algorithm 1. We still call f the hashing function, and ${\mathcal{L}}_h$ the $n_h$-dimensional vector of nodes at floor $h\in 0, H$. We note $b_h$ the balance vector at floor h. Finally, note that ‘$r=\varnothing$’ means that r is removed from memory if it has not already performed.

There are at most three vector operations per loop: concatenation of ${\mathcal{L}}_h$ with the last element of ${\mathcal{L}}_{h-1}$ in case $n_{h-1}$ is odd, then concatenation of ${\mathcal{L}}_h\left(\mathrm{odd}\right)$ (odd components of ${\mathcal{L}}_h$) with ${\mathcal{L}}_h\left(\mathrm{even}\right)$, and the f application to it. The complexity of this algorithm is therefore $\mathcal{O}\left(\log N\right)$.

Algorithm 1: Liability Tree computation.

Algorithm 2: Authentication Path Computation

Algorithm 3: Liability Tree and authentication path computations.

2.7.2. Verification by Client

From the construction of the Liability Tree owned by the exchange, and only the exchange, we are going to explain how the client can verify their account well.

Liability Root and Authentication Path

The exchange provides to the client, who wants to verify that their account is an exchange’s liability, the Liability root, and the Authentication path. The following Algorithm 2 provides an efficient iterative way to calculate the authentication path from the tree.

The complexity of this algorithm is $\mathcal{O}\left(\log N\right)$ with two calculations per loop. Indeed, the primary loop iterates from the client’s starting floor up to the root of the tree, with height $H=\lceil \log N/\log 2\rceil$. Therefore, the number of loop iterations is directly related to the height of the tree.

It is worth pointing out that space can be saved by not remembering the full tree ${\left\{{\mathcal{L}}_h\right\}}_{h\in 0,H}$ (simply replace ${\mathcal{L}}_h$ and ${\mathcal{L}}_{h-1}$ both by $\mathcal{L}$ (independent of h) in the above Algorithms 1 and 2).

Verification

The client has the provided data ${\mathrm{MPath}}_0$ (their hashed account) and ${\left\{{\mathrm{Auth}}_h\right\}}_{h\in 0,H-1}$, as well as the root. She therefore iteratively can use

$${\mathrm{MPath}}_h=f({\mathrm{MPath}}_{h-1}\left|\right|{\mathrm{Auth}}_{h-1}),\forall \mathrm{TXID},\forall h\in 1,H.$$

(1)

to find the liability root at final, and see if this coincides with the one provided by the exchange. The client is sure their account is an exchange’s liability is both liability roots coincide.

For the reader’s convenience, Algorithm 3 includes the Liability Tree and authentication path calculations at the same time.

3. Proof-of-Solvency Protocol for Fiats

To the best of our knowledge, there are only two possibilities for providing proof of solvency for the fiats.

• Receipts: The exchange is providing a receipt to the users as well as a live statement generated by the external liquidity provider. This ideal case is possible without blockchain and requires trust.
• Tokenization: The exchange possesses one token per fiat, and there is a blockchain associated with the token version of the fiat so that all transactions can be followed live. Tokens are redeemed to the client each time they sell crypto-assets (see [28]). The exchange E can then systematically prove it has assets and liabilities, and a stablecoin exchange, which thus possesses all the fiat collateral, are subject to usual audits. This stablecoin exchange plays the role of a bridge between the world of cryptos and the world of fiats. It could be a regulator or a state.

3.1. On Stablecoins Creation

The only possibility to make cryptographic proofs, such as the ones for the crypto case (see previous sections), is to create a token pegged to a given fiat and use these instead of pure fiats. In this case, the previous Section 2 applies.

Although providing a receipt is the simplest way to show proof of transaction, we all know that a receipt is a piece of paper that does not guarantee the statement truth at any time, because it is showing cash flow between two distinct parties at a given date. For any given time, a receipt is not telling where the cash is (e.g., FTX, 3 Arrows Capital): in an exchange, users’ money is subject to Order Book, validating transactions by matching with others so that money cannot be ‘sleeping’ in an account just after the time of the transaction (any bank client can have access to bank reports explaining how the exchange proceeds but reports generally are heavy, and client’s knowledge is not necessarily advanced in banking and its jurisdiction, so their understanding highly is limited). Nevertheless, a statement does not provide the situation of users’ money within the Order Book neither but states what the exchange owes to the client, even if it is not guaranteed that the bank has sufficient reserve. It is worth pointing out that this issue might be solved in Decentralized Exchanges (DEX), though still representing a strong minority in the market.

We see that the only possibility to follow the trace of one’s money is to expose precisely where it is, and the concept of blockchain does satisfy this requirement. This means that the exchange should operate with stablecoins backed to fiat, and have access to the underlying blockchains thus created.

As indicated earlier, the entities which issue stablecoins are playing the role of bridges. They cannot use blockchain to prove they have fiat reserves, and thus they must be usually audited. However, the rest of the world could exclusively possess tokens and could therefore seize the opportunity to prove they are solvent or not in a 24/7 manner through blockchains. In particular, the full previous sections apply.

3.2. General Proof of Solvency Protocol in the Fiat Case

Figure 6 sheds light on two essential questions in case the external institutions have not implemented the above proof of solvency protocol and in the context of fiats.

Figure 6. The considered institution is in a center of a market (right-hand-side in the figure) within its clients and external liquidity providers (both left-hand-side), at the likes of Figure 2. The ‘Stablecoin Exchange’ (i.e., the bridge) allows fiat tokenization, and it issues token versus fiat cash. Thus the ‘Stablecoin Exchange’ will need regular usual audits to manage its fiat reserves. If it is a state, the fiat cash could be used for further investments or debt payments with other states. Thus, ‘Stablecoin Exchanges’ are bridges between the fiat world (set of states in the world if they are states) and the token/crypto world (set of companies in the world). The interaction with external institutions and the considered one, as well as with the ‘Stablecoin Exchange’, raise two questions, Q3 and Q4, which we address in the text.

The exchange E could possess its reserves and liabilities elsewhere, hence question Q3: what if the external institution does not have stablecoins or tokenized reserves? We see two possibilities:

• Exchange E asks the external institution to tokenize their fiat cash and to align with the solvency protocol;
• Or there is no choice of a usual governance.

Similarly, the following question Q4 is very natural: How do we prove the stablecoin exchange has the reserves? The only possibility here is usual audits.

In order to work fluently, tokenization needs to be performed altogether to gain its efficiency. Bearing with all the above in mind, we conclude that the above solvency protocol should be standardized and its implementation controlled by authorities as regulators and states.

4. Some Suggestions for Information Disclosure

In addition to the above solvency protocol, we propose the following disclosure plan. This is unnecessary but it still provides further transparency.

4.1. Proving the Reserves

• All the addresses ${\mathrm{Address}}_i$’s (the exchange) and ${\mathrm{Address}}_j$’s (other external exchanges—see text for more details);
• The hash of the balances $b_i$’s and $b_j$’s-resp. written $\mathrm{H}\left(b_i\right)$ and $\mathrm{H}\left(b_j\right)$-resp. related to the ${\mathrm{Address}}_i$’s and the ${\mathrm{Address}}_j$’s, to the public;
• The total reserve amount ${\sum }_i{b}_i+{\sum }_j{b}_j$.

4.2. Proving the Liabilities

• All the (exchange) clients’ leaves hashes $\mathrm{H}\left({\mathrm{Address}}_k\right|\left|b_k\right|\left|{\sum }_l{b}_l\right)$’s;
• The total external exchanges’ liability ${\sum }_l{b}_l$;
• All the external exchanges addresses ${\mathrm{Address}}_l$’s (see text for more details);
• The liability root as well as its balance ${\sum }_l{b}_l+{\sum }_k{b}_k$, which is the total liability.

5. The Particles Model

We have proposed, in the previous sections, a practical protocol for proof of solvency. There is one particular point the above protocol does not solve: it has to provide information which the exchange may want not to provide. It is thus likely that the privacy requirement will not be fully satisfied. To solve this issue, we may propose a model which in the order book (the Pool) divides one address into millions of sub-addresses (particles) in order to further mask privacy. This is the Particles model.

It is worth pointing out that the content of this section is a immediate continuation of Chapter 7, Section 4 of [7], where the Particles model was introduced. We completely reintroduce it and much further develop the fundamentals and practical implementation.

5.1. Setting the Model Scene

An innovative method to enhance transaction anonymity within the Pool involves the strategic dilution of transaction amounts when a client places an order. This process entails the division of an amount X BTC ($X>0$) into a variety of distinct UTXOs for recording on the blockchain. The Pool orchestrates a transaction where X BTC serves as the input, and the output consists of n UTXOs ($n\ge 1$). The amounts are distributed such that the first UTXO contains $Z_1$ BTC and the second $Z_2$ BTC, continuing in this manner. Such transactions can be arranged to incur no fees, facilitated through pre-agreed contracts with miners, who are compensated separately. This methodology can result in extensive UTXOs per transaction, indicating a potentially large n.

The concept extends to all transactional procedures within the Pool, whereby each client’s orders generate a multitude of smaller UTXOs, hereafter called particles. These particles contain fragmentary amounts of cryptocurrency, too small to serve as standalone inputs for conventional transactions. Nonetheless, by aggregating an appropriate combination of particles, it becomes possible to construct valid transfer transactions. For example, when executing a sell operation, particles can be selectively combined to produce a precise BTC quantity, effectively retracing the original BTC supply (depicted in the inverse route within Figure 7). This particle-based approach resembles the mechanics of an order book, with the added advantage of order fragmentation, which promotes greater matching efficiency. Over time, the Pool transforms into a dynamic assembly of particles, where repulsive interactions encourage the splitting of X BTC into smaller units, and attractive forces foster the recombination of particles to form Y BTC, maintaining systemic stability. The conceptual model is visually summarized in Figure 7 (from [7]).

Figure 7. The Particles model: a customer balance is decomposed into several particles, i.e., UTXOs of very small BTC amounts. The particles constitute the matter of each amounts, and gravitating in the Exchange pool system where reign forces of repulsion (giving the particles in case of buy order) and of attraction (in case of sell order). This results in significant improvement of privacy, as it becomes much harder to follow the identity of customers (Source: [7]).

From a practical standpoint, a key challenge is to define a methodology for determining the optimal number of particles n generated from a given amount X, along with the respective amounts ${\left(Z_i\right)}_{i\in 1,n}$. Furthermore, it is necessary to establish procedures for selecting a subset of these particles whose combined value closely approximates Y BTC. It is important to note that an exact reconstruction of Y may not always be feasible; the reconstructed sum should never exceed Y, as clients are not authorized to transact beyond their original request. Nevertheless, with a sufficiently large and diverse set of particles, the likelihood of achieving a sum near Y increases statistically. The particles are heterogeneous, akin to different kinds of fundamental matter, each characterized by distinct properties that influence their selection and combination.

5.2. Trading Dynamics

In the following, the monetary unit is the satoshi (so all variables are integers).

5.2.1. The Mathematical Problems

We focus on the following mathematical problem: how many particles constitute an amount of X satoshis, and what are their associated values?

Definition 1.

We set the  buy order  problem as 

$$\forall X\in {\mathbb{N}}^{*}\mathrm{find}n\in {\mathbb{N}}^{*}\mathrm{and}{\left(Z_i\right)}_{i\in 1,n}\in {\left({\mathbb{N}}^{*}\right)}^n\mathrm{such}\mathrm{that}X=Z_1+Z_2+\cdots +Z_n,$$

(2)

with constraints

$$l_i\le Z_i\le r_i,\forall i\in 1,n,$$

(3)

where $1\le l_i\le r_i$ are given integers (independent of X).

We set the  sell order  problem as 

$$\forall Y\in {\mathbb{N}}^{*}\forall {\left(Z_i\right)}_{i\in 1,N}\in {\left({\mathbb{N}}^{*}\right)}^N,\mathrm{with}N\in {\mathbb{N}}^{*}\mathrm{find}n\in 1,N\mathrm{such}\mathrm{that}$$

$$Z_1+Z_2+\cdots +Z_n\mathrm{is}\mathrm{the}\mathrm{closest}\mathrm{to}Y.$$

(4)

In the buy-order problem set, the numbers X, the $l_i$’s and the $r_i$’s are all given integers. The goal is thus to derive n and the $Z_i$’s. In practice, we may choose $l_i=1$ (a UTXO has minimum 1 satoshi) for all i, while $r_i=r$ (which is the maximum relevant UTXO value to consider it as a particle, perhaps around 100,000 satoshis) for all i. We keep the general case by considering $l_i$ and $r_i$ a priori function of i.

The solution for the sell-order problem is highly dependent on the one for the buy-order problem. In the latter, the numbers ${\left(Z_i\right)}_{i\in 1,n}$ are derived for a given X. In the former, there is a bunch of existing numbers ${\left(Z_i\right)}_{i\in 1,N}$ derived from several values of X (several buy orders), and there are N particles in total in the Exchange Pool system (see Figure 7). We obviously expect that $n\ll N$, at least in the long run, once there have been sufficient buy orders. Contrary to the buy-order problem, there always is a solution for the sell-order problem, where the idea is to have $Y\approx Z_1+\cdots +Z_n$, and the equality is statistically guaranteed if N and n are sufficiently large (which is expected since these UTXOs are particles): once the exchange receives the sell order for amount Y, an appropriate number of particles gather to form the amount Y. In addition, we see that not only does the above framework provide further privacy but it also allows higher liquidity in the exchange, particularly for sell orders.

Before proposing a solution, we need to make sure that this problem makes sense, i.e., if there are indeed solutions, and, in the ideal case, how many. This is related to the partition of integers problem; see [29,30,31]. As an illustration, if we take the simple case where $X=5$, then $n\in \{1,2,3,4,5\}$ and $5=5$, $4+1$, $3+1+1$, $2+2+1$, and $1+1+1+1+1$ are possible solutions.

5.2.2. Buy-Order Problem—Conditions for the Existence of Solutions

First note that we immediately have a condition on X, which is given by

$$nl\le X\le nr,$$

(5)

where ${\displaystyle l=\frac{1}{n}\sum _{i=1}^n{l}_i}$ and ${\displaystyle r=\frac{1}{n}\sum _{i=1}^n{r}_i}$ are the empirical means for the $l_i$’s and the $r_i$’s, respectively.

We claim that at least one solution exists if and only if X satisfies Inequalities (5), which is equivalent to giving a necessary and sufficient condition on n for the existence of solutions: Inequalities (5) are equivalent to

$${\displaystyle \frac{X}{r}}\le n\le {\displaystyle \frac{X}{l}}.$$

(6)

Thus, the number n can be any integer contained in the interval $[X/r,X/l]$.

5.2.3. Number of Solutions for the Buy-Order Problem

This section develops the number of solutions ${\mathcal{N}}_X$ for the above problems (2) and (3) in Section 5.2.1 from the most general case to our particular case of interest $l_i=l$ and $r_i=r$ (constant values). We may choose the generating function lead to solve the question. We assume that the conditions on Section 5.2.2 are satisfied so that there exists at least one solution to problems (2) and (3).

Theorem 1.

The number of solutions ${\mathcal{N}}_X$ for the buy-order problems (2) and (3), by considering a sum of n terms, with condition (6) satisfied, in case $l_i=l$ and $r_i=r$ for all $i\in 1,n$, is given by

$$\begin{array}{|c|}\hline {\mathcal{N}}_X={\displaystyle \sum _{j=0}^{⌊{\displaystyle \frac{X-nl}{r-l+1}}⌋}}{(-1)}^j\left({\displaystyle \genfrac{}{}{0pt}{}{n}{j}}\right)\left({\displaystyle \genfrac{}{}{0pt}{}{X-(n-j)(l-1)-jr-1}{n-1}}\right)\\ \hline\end{array}$$

(7)

Proof. 

We first simplify the problem, without any loss of generality. We set

$$\begin{array}{ccc}{Z}_i^{\prime }\hfill & =& Z_i-l_i\hfill \\ X^{\prime }\hfill & =& X-nl\hfill \\ k_i\hfill & =& r_i-l_i+1\hfill \end{array}$$

where l is the empirical mean for the $l_i$’s so that problems (2) and (3) are equivalent to

$$\forall X^{\prime }\in {\mathbb{R}}_{+}^{*}\mathrm{find}n\in {\mathbb{N}}^{*}\mathrm{and}{\left(Z_i^{\prime }\right)}_{i\in 1,n}\mathrm{such}\mathrm{that}{X}^{\prime }=Z_1^{\prime }+Z_2^{\prime }+\cdots +Z_n^{\prime },$$

(8)

with constraints

$$0\le Z_i^{\prime }\le k_i-1,\forall i\in 1,n,$$

(9)

where $k_i\ge 1$ is a given integer (independent of $X^{\prime }$) for any i.

We derive below the number of solutions for problems (8) and (9). The generating function for the number of partitions satisfying the problem’s constraints can be derived using standard combinatorial arguments (see [29,30,31] for background on partition generating functions). The function given by

$$f\left(x\right)=\sum _{m=0}^{+\infty }{p}_m{x}^m,$$

(10)

which indeed normally converges for any real x such that $\left|x\right|<1$, and $p_m$ is the number of solutions for problems (8) and (9), when m is the integer to partition, can actually be written as [31]

$$f\left(x\right)=\prod _{j=1}^n{\displaystyle \frac{1-x^{k_j}}{1-x}},$$

(11)

when we consider a sum of n integers. We are looking for the derivation of $p_{X^{\prime }}$. By bearing in mind the fact that

$$\prod _{j=1}^n(1-x^{k_j})=1+\sum _{j=1}^n{(-1)}^j\sum _{1\le i_1<\cdots <i_j\le n}{x}^{k_{i_1}+\cdots +k_{i_j}},$$

we expand the generating function as follows:

$$f\left(x\right)=\prod _{j=1}^n{\displaystyle \frac{1-x^{k_j}}{1-x}}={\displaystyle \frac{1}{{(1-x)}^n}}\left(1+\sum _{j=1}^n{(-1)}^j\sum _{1\le i_1<\cdots <i_j\le n}{x}^{k_{i_1}+\cdots +k_{i_j}}\right).$$

From the formal power series expansion

$${\displaystyle \frac{1}{{(1-x)}^n}}=\sum _{m=0}^{+\infty }\left({\displaystyle \genfrac{}{}{0pt}{}{m+n-1}{n-1}}\right)x^m,$$

we then have

$$\begin{array}{ccc}\hfill f\left(x\right)& =& {\displaystyle \left(\sum _{m=0}^{+\infty }\left(\genfrac{}{}{0pt}{}{m+n-1}{n-1}\right)x^m\right)\left(1+\sum _{j=1}^n{(-1)}^j\sum _{1\le i_1<\cdots <i_j\le n}{x}^{k_{i_1}+\cdots +k_{i_j}}\right)}\hfill \\ & =& {\displaystyle \sum _{m=0}^{+\infty }\left(\left(\genfrac{}{}{0pt}{}{m+n-1}{n-1}\right)x^m+\sum _{j=1}^n{(-1)}^j\sum _{1\le i_1<\cdots <i_j\le n}\left(\genfrac{}{}{0pt}{}{m+n-1}{n-1}\right)x^{m+k_{i_1}+\cdots +k_{i_j}}\right).}\hfill \end{array}$$

Now, we use the appropriate variable change:

$$\begin{array}{cc}\hfill {\displaystyle \sum _{m=0}^{+\infty }\sum _{j=1}^n{(-1)}^j}& {\displaystyle \sum _{1\le i_1<\cdots <i_j\le n}\left(\genfrac{}{}{0pt}{}{m+n-1}{n-1}\right)x^{m+k_{i_1}+\cdots +k_{i_j}}}\hfill \\ \hfill =& {\displaystyle \sum _{m=0}^{+\infty }\sum _{j=1}^n\sum _{1\le i_1<\cdots <i_j\le n}{(-1)}^j\left(\genfrac{}{}{0pt}{}{m+n-1-(k_{i_1}+\cdots +k_{i_j})}{n-1}\right)x^m,}\hfill \end{array}$$

by bearing in mind that $\left({\displaystyle \genfrac{}{}{0pt}{}{\alpha }{\beta }}\right)=0$ if the integers $\alpha$ and $\beta$ are such that $\alpha <\beta$ so that

$$f\left(x\right)=\sum _{m=0}^{+\infty }\left(\left({\displaystyle \genfrac{}{}{0pt}{}{m+n-1}{n-1}}\right)x^m+\left[\sum _{j=1}^n\sum _{1\le i_1<\cdots <i_j\le n}{(-1)}^j\left({\displaystyle \genfrac{}{}{0pt}{}{m+n-1-(k_{i_1}+\cdots +k_{i_j})}{n-1}}\right)\right]x^m\right).$$

By the unicity of coefficients, we conclude by extracting the coefficient $p_{X^{\prime }}$ of $x^{X^{\prime }}$, which is the number of solutions for problems (8) and (9):

$$p_{X^{\prime }}=\left({\displaystyle \genfrac{}{}{0pt}{}{X^{\prime }+n-1}{n-1}}\right)+\sum _{j=1}^n\sum _{1\le i_1<\cdots <i_j\le n}{(-1)}^j\left({\displaystyle \genfrac{}{}{0pt}{}{X^{\prime }+n-1-(k_{i_1}+\cdots +k_{i_j})}{n-1}}\right).$$

The number of solutions ${\mathcal{N}}_X$ for the general problems (2) and (3) therefore is

$$\begin{array}{cc}\hfill {\mathcal{N}}_X=& {\displaystyle \left(\genfrac{}{}{0pt}{}{X-n(l-1)-1}{n-1}\right)}\hfill \\ \hfill +& {\displaystyle \sum _{j=1}^n\sum _{1\le i_1<\cdots <i_j\le n}{(-1)}^j\left(\genfrac{}{}{0pt}{}{X-n(l-1)-(r_{i_1}+\cdots +r_{i_j}-l_{i_1}-\cdots -l_{i_j}+j)-1}{n-1}\right)}\hfill \end{array}$$

where ${\displaystyle l=\frac{1}{n}\sum _{i=1}^n{l}_i}$. Suppose that $r_i=r$ for all i, and $l_i=l$ for all i. By noticing the fact that the sum over the $i_j$’s contains $\left({\displaystyle \genfrac{}{}{0pt}{}{n}{j}}\right)$ terms, we finally obtain

$${\mathcal{N}}_X=\left({\displaystyle \genfrac{}{}{0pt}{}{X-n(l-1)-1}{n-1}}\right)+\sum _{j=1}^n{(-1)}^j\left({\displaystyle \genfrac{}{}{0pt}{}{n}{j}}\right)\left({\displaystyle \genfrac{}{}{0pt}{}{X-(n-j)(l-1)-jr-1}{n-1}}\right).$$

Note that the only non-zero terms for the sum over j are such that $X-(n-j)(l-1)-jr-1\ge n-1$, i.e., $j\le {\displaystyle \frac{X-nl}{r-l+1}}$. The number of solutions for the problems (2) and (3) for $l_i=l$ and $r_i=r$, for all i, therefore is

$$\begin{array}{|c|}\hline {\mathcal{N}}_X={\displaystyle \sum _{j=0}^{⌊{\displaystyle \frac{X-nl}{r-l+1}}⌋}}{(-1)}^j\left({\displaystyle \genfrac{}{}{0pt}{}{n}{j}}\right)\left({\displaystyle \genfrac{}{}{0pt}{}{X-(n-j)(l-1)-jr-1}{n-1}}\right)\\ \hline\end{array}$$

(12)

which is the wanted expression.    □

Now, also suppose that $l=1$ (relevant practical case for implementation purposes). Equation (12) becomes

$${\mathcal{N}}_X=\sum _{j=0}^{⌊{\displaystyle \frac{X-n}{r}}⌋}{(-1)}^j\left({\displaystyle \genfrac{}{}{0pt}{}{n}{j}}\right)\left({\displaystyle \genfrac{}{}{0pt}{}{X-jr-1}{n-1}}\right).$$

Examples

As an illustration, suppose that $X=4$, $n=2$, and $r=4$ (no constraint since $r=X$). Then the sum over $j\ge 1$ is zero since $X-jr-1=3-4j<0<1=n-1$ for any $j\in {\mathbb{N}}^{*}$, so there are

$${\mathcal{N}}_4=\left({\displaystyle \genfrac{}{}{0pt}{}{3}{1}}\right)=3$$

possibilities to write $4=Z_1+Z_2$ with the constraints $1\le Z_i\le 4$, which indeed are $4=2+2$, $4=3+1$ and $4=1+3$. As another verification, choose $X=4$, $n=2$, and $r=2$. Then   

$${\mathcal{N}}_4=\left({\displaystyle \genfrac{}{}{0pt}{}{4-1}{2-1}}\right)-\left({\displaystyle \genfrac{}{}{0pt}{}{2}{1}}\right)\left({\displaystyle \genfrac{}{}{0pt}{}{4-2-1}{2-1}}\right)=\left({\displaystyle \genfrac{}{}{0pt}{}{3}{1}}\right)-\left({\displaystyle \genfrac{}{}{0pt}{}{2}{1}}\right)\left({\displaystyle \genfrac{}{}{0pt}{}{1}{1}}\right)=3-2\times 1=1.$$

Indeed, there is just one way to write $4=Z_1+Z_2$, given the constraints $1\le Z_i\le 2$, that is $4=2+2$.

6. Practical Solutions and Algorithms

6.1. A Practical Solution for the Buy-Order Problem

We propose a simple solution—there exists at least one as proven in Section 5.2.3—to the problems (2) and (3).

Assumption 1.

We will make the following Assumptions all together:

• $l_i=l$ and $r_i=r$ for all i (all particles have the same properties);
• The $Z_i$’s are all the same (symmetry argument);
• For any X, n is a convex expression in the set $[X/r,X/l]$ (see Inequalities (6)).

By the third point of the previous Assumption, we mean that

$$\exists \alpha \in [0,1]\forall X\in {\mathbb{N}}^{*}n=⌊\alpha {\displaystyle \frac{X}{r}}+(1-\alpha ){\displaystyle \frac{X}{l}}⌋,$$

(13)

and that the parameter $\alpha$ is universal, i.e., independent of X. It is therefore a calibrated parameter.

Theorem 2.

There exists a solution to the buy-order problem, which is such that all the particles have an equal amount. In addition, this amount is independent of X when X is sufficiently high.

Proof. 

The buy-order problem then becomes

$$n{Z}_i=X.$$

(14)

Therefore, we have

$$\forall i\in 1,n{Z}_i={\displaystyle \frac{X}{{\displaystyle ⌊\alpha \frac{X}{r}+(1-\alpha )\frac{X}{l}⌋}}}.$$

We are going to see that this choice implies that $Z_i$ is approximately independent of X. Since, for any real x, we have that

$$\lfloor x\rfloor \le x<\lfloor x\rfloor +1,$$

that is

$$x-1<\lfloor x\rfloor \le x.$$

If $n=1$, then $Z_1=X$ and there is nothing else to do. Otherwise, we have

$$0<\alpha {\displaystyle \frac{X}{r}}+(1-\alpha ){\displaystyle \frac{X}{l}}-1<n\le \alpha {\displaystyle \frac{X}{r}}+(1-\alpha ){\displaystyle \frac{X}{l}}.$$

Thus, from Equation (14), we have

$${\displaystyle \frac{X}{{\displaystyle \alpha \frac{X}{r}+(1-\alpha )\frac{X}{l}-1}}}>Z_i\ge {\displaystyle \frac{X}{{\displaystyle \alpha \frac{X}{r}+(1-\alpha )\frac{X}{l}}}},$$

or

$${\displaystyle \frac{1}{{\displaystyle \frac{\alpha }{r}+\frac{1-\alpha }{l}-\frac{1}{X}}}}>Z_i\ge {\displaystyle \frac{1}{{\displaystyle \frac{\alpha }{r}+\frac{1-\alpha }{l}}}}.$$

Bearing this in mind, we may assert that ($X\gg 1$ since it is assumed that a customer buys (or sells) much more than a satoshi)

$$Z_i={\left({\displaystyle \frac{\alpha }{r}}+{\displaystyle \frac{1-\alpha }{l}}\right)}^{-1}\left(1+{\left({\displaystyle \frac{\alpha }{r}}+{\displaystyle \frac{1-\alpha }{l}}\right)}^{-1}{\displaystyle \frac{1}{X}}+\mathrm{o}\left({\displaystyle \frac{1}{X}}\right)\right).$$

(15)

This writes as

$$\begin{array}{|c|}\hline \underset{X\to +\infty }{\lim }{Z}_i={\left({\displaystyle \frac{\alpha }{r}}+{\displaystyle \frac{1-\alpha }{l}}\right)}^{-1}\\ \hline\end{array}$$

Hence the $Z_i$’s all have the same value. This also means that, for two distinct buy orders of respective amounts X and $X^{\prime }$, the difference in amount between the set of $Z_i$’s derived from X and the one derived from $X^{\prime }$ is

$$\mathcal{E}(X,X^{\prime })={\left({\displaystyle \frac{\alpha }{r}}+{\displaystyle \frac{1-\alpha }{l}}\right)}^{-2}\left({\displaystyle \frac{1}{X}}-{\displaystyle \frac{1}{X^{\prime }}}\right)+\mathrm{o}\left({\displaystyle \frac{1}{X}}-{\displaystyle \frac{1}{X^{\prime }}}\right)=\mathcal{O}\left({\displaystyle \frac{1}{X}}-{\displaystyle \frac{1}{X^{\prime }}}\right).$$

This is negligible when X and $X^{\prime }$ are in the neighborhood of infinity. All the particles have their amount approximately given by ${\left({\displaystyle \frac{\alpha }{r}}+{\displaystyle \frac{1-\alpha }{l}}\right)}^{-1}$.    □

The amount ${\left({\displaystyle \frac{\alpha }{r}}+{\displaystyle \frac{1-\alpha }{l}}\right)}^{-1}$ is controlled through the universal parameter $\alpha$, that can be calibrated.

Algorithm

Let us assume that $X\gg r\gg l=1$. We have $Z_i\approx {(1-\alpha )}^{-1}$ and $n\approx \lfloor (1-\alpha )X\rfloor$.

If one chooses $\alpha$ to be the initial calibrated number as the middle of $[0,1]$, i.e., $\alpha =1/2$, then

$$n=\left\{\begin{array}{cc}X/2\hfill & \mathrm{if}X\mathrm{is}\mathrm{even}\hfill \\ & \\ (X-1)/2\hfill & \mathrm{if}X\mathrm{is}\mathrm{odd}\hfill \end{array}\right.$$

and

$$Z_i=\left\{\begin{array}{cc}2\hfill & \mathrm{if}X\mathrm{is}\mathrm{even}\mathrm{or}(X\mathrm{is}\mathrm{odd}\mathrm{and}i<n+1)\hfill \\ & \\ 1\hfill & \mathrm{if}X\mathrm{is}\mathrm{odd}\mathrm{and}i=n+1\hfill \end{array}\right.$$

If one chooses $\alpha =1$ as the calibrated number, then $n=\lfloor X/r\rfloor$, and $Z_i=X/\lfloor X/r\rfloor \approx r$. If n does not divide X, then we could perform the Euclidean division of X by n so that $X=nr+z$, with $0\le z<r$, and allocate r to n UTXOs, then allocate z to one UTXO.

To sum up, we have the following more general Algorithm 4. In Section 7.3, we will see that the fair price-optimal calibrated number is indeed $\overline{\alpha }=1$.

There is one calculation for the value of n, and a Euclidean division, which means that the complexity of this algorithm only is $\mathcal{O}\left(1\right)$.

Add Randomness

We could decide to add randomness to the obtained result. This is convenient if the exchange wants to mask more of the the deterministic pattern above. Once we obtain the numbers ${\left(Z_i\right)}_{i\in 1,n}$, we may choose a random integer $n^{\prime }$ from 1 to n. We then randomly choose $n^{\prime }$ particles and, for each of them, we repeat the above process. This will result in more particles with smaller amounts.

Algorithm 4: Buy Order Algorithm

Result: Obtain the appropriate number of particles as the result of the buy order. The client is setting a buy order with amount X Choose $\alpha \in [0,1]$ and compute ${\displaystyle n=⌊\alpha \frac{X}{r}+(1-\alpha )\frac{X}{l}⌋}$; Perform the Euclidean division of X by n to obtain $X=nZ+z$, and allocate Z to n UTXOs and z to one UTXO ($0\le z<Z$). Inputs: Client’s request of amount X; Outputs: n UTXO particles of amount Z; UTXO particle of amount z.

Examples, $\mathit{\alpha }=\mathbf{1}/\mathbf{2}$

Choose $X=10$ satoshis. Then we obtain 5 UTXOs of 2 satoshis. If we choose to add randomness, let $n^{\prime }=3$ be the selected random number. Then randomly pick 3 UTXOs, e.g., the first, the third, and the fifth, and repeat the above process: each selected UTXO gives 2 UTXOs whose respective amount is 1 satoshi. We finally obtain 8 UTXOs, 6 with amount of 1 satoshi, and 2 with amount 2 satoshis.

Choose $X=11$ satoshis. Then we obtain 5 UTXOs of 2 satoshis and 1 UTXO of 1 satoshi. If we choose to add randomness, let $n^{\prime }=3$ be the selected random number, and we choose, say, the first, the third, and the fifth UTXO. According to the previous example, we finally obtain 8 UTXOs, 7 UTXOs with amount of 1 satoshi, and 2 UTXOs with an amount of 2 satoshis.

6.2. A Practical Solution for the Sell-Order Problem

In this section, we propose a solution for the sell-order problem (4), highly dependent on the solution to the problems (2) and (3). We suppose the Pool has a high quantity N of particles with amounts ${\left(Z_i\right)}_{i\in 1,N}$. The solution proposed below is practical and easily implementable, and it is essential that, during the process, we do not come to a higher amount than the required one—but the idea is to come closer and closer to it using all the available particles. We also give examples later below.

For a given $Y\in {\mathbb{R}}_{+}^{*}$, we proceed with the following Algorithm 5. Suppose the exchange has $n\in 1,N$ different amounts for all its particles (with indeed N particles in total), and set these amounts such that $Z_1\ge Z_2\ge \cdots \ge Z_n$. Let ${\left(q_i\right)}_{i\in 1,n}$ be the family of positive integers such that $q_i$ is the number of particles whose amount is $Z_i$, for all $i\in 1,n$. It is worth pointing out that the total number of particles is $N={\sum }_{i=1}^n{q}_i$.

The following Theorem 3 has its notations from Algorithm 5.

Theorem 3.

Algorithm 5 provides that the $Y^{\left(k\right)}$, $k\in 1,p$, are the closest to Y successively. In addition, if $Y^{\left(n\right)}<Y$, then $Z^{\prime }>0$ so that Step 4 is well defined.

Proof. 

We focus on the heredity of this algorithm (put $k\ge 1$, and set $Y^{\left(0\right)}=0$). Perform the Euclidean division of $Y-Y^{(k-1)}>0$ with respect to $Z_k$ to have $Y-Y^{(k-1)}=q_k^{\prime }{Z}_k+v$, with $0\le v<Z_k$. Then, for amount $Z_k$, $q_k^{\prime }$ is the maximal possible number of particles to implode since, if one was to implode $q_k^{\prime }+1$ particles with amount $Z_k$, we then would have $(q_k^{\prime }+1)Z_k>Y-Y^{(k-1)}$ hence

$$Y-Y^{(k-1)}-(q_k^{\prime }+1)Z_k<0,$$

(16)

which is unexpected. Therefore step k is imploding at most $q_k^{\prime }$ particles with amount $Z_k$, hence, if step k is imploding exactly $m_k=\min (q_k,q_k^{\prime })$ particles with amount $Z_k$, then we deduce that $m_k{Z}_k$ is the closest amount to $Y-Y^{(k-1)}$ involving all particles with amount $Z_k$, for any $k\in 1,p$. When $Y^{\left(n\right)}<Y$, Step 4 guarantees that, when there remains at least a particle (i.e., $\{Z_k,q_k\ne 0\}\ne \varnothing$), the algorithm obtains Y as the output amount for the sell order since, if $Z>0$, then $\exists k_0\in 1,n$ such that $m_{k_0}=q_{k_0}^{\prime }$, and, using Equation (16) with $k=k_0$ and that $Z\ge Z_{k_0}$, we have

$$Y-Y^{\left(n\right)}-Z\le Y-Y^{(k_0-1)}-q_{k_0}^{\prime }{Z}_{k_0}-\sum _{k=k_0+1}^n{m}_k{Z}_k-Z_{k_0}<-\sum _{k=k_0+1}^n{m}_k{Z}_k\le 0,$$

(17)

where the sum ‘${\sum }_{k=k_0+1}^n$’ is 0 if $k_0=n$, which ends the proof.    □

Algorithm 5: Sell-order algorithm.

Result: Obtain the most appropriate output value from a given bunch of particles. The client is setting a sell order with amount Y; Initiation—step 1: Set $m_1=\min (q_1,q_1^{\prime })\ge 0$, where $q_1^{\prime }$ is the quotient of the Euclidean division of Y with $Z_1$. Set $Y^{\left(1\right)}=m_1{Z}_1$ and $q_1\mapsto q_1-m_1$; Heredity—step $k>1$: Set $m_k=\min (q_k,q_k^{\prime })\ge 0$, were $q_k^{\prime }$ is the quotient of the Euclidean division of $Y-Y^{(k-1)}$ with $Z_k$. Set $Y^{\left(k\right)}=m_k{Z}_k+Y^{(k-1)}$ and $q_k\mapsto q_k-m_k$; Termination: the above iteration terminates at loop $p\ge 1$ in either of the following cases: The match is perfect: $Y^{\left(p\right)}=Y$, and set $m_i=0$ for all $i>p$, if $p<n$; Otherwise, $p=n$ and $Y^{\left(n\right)}\le Y$. Achievement when $Y^{\left(n\right)}<Y$ and it still remains particles: Let $Z=\underset{k\in 1,n}{\max }\{Z_k,q_k\ne 0\}$. Then set $y=Y-Y^{\left(n\right)}$ and $Z^{\prime }=Z-y>0$. Break the Z-amount particle into a $Z^{\prime }$-amount particle and a y-amount particle. We then implode particles with amount $Y^{\left(n\right)}$ and y so that $Y=Y^{\left(n\right)}+y$. Inputs: $m_1$ particles of amount $Z_1$; … $m_n$ particles of amount $Z_n$; A particle of amount Z; Outputs: UTXO particle of amount Y; UTXO particle of amount $Z^{\prime }$.

The advantage of this Algorithm 5 for the exchange is that particles with large amounts do not allow to precisely come closer, by below, to the required amount Y. Thus, the algorithm does not only utilize many particles with little amount, but also it converges fast in time by utilizing particles with large amounts first. There are at most $n=N$ distinct particles, thus this algorithm complexity is at most $\mathcal{O}\left(N\right)$.

Examples

• Suppose $Y=19$ and we have the following particle amounts $Z_1=4$ five times ($q_1=5$), $Z_2=2$ five times ($q_2=5$), and $Z_3=1$ eight times ($q_3=8$).
  We proceed as follows: the Euclidean division of $Y=19$ with respect to (w.r.t.) $Z_1=4$ is $19=4\times 4+3$, thus $m_1=\min (5,4)=4$, and set $Y^{\left(1\right)}=16$. It remains $5-4=1$ particle of amount $Z_1$.
  Next, the Euclidean division of $Y-Y^{\left(1\right)}=3$ w.r.t. $Z_2=2$ is $3=1\times 2+1$, thus $m_2=\min (1,5)=1$, and set $Y^{\left(2\right)}=Y^{\left(1\right)}+2=18$. It remains $5-1=4$ particles of amount $Z_2$.
  Finally, the Euclidean division of $Y-Y^{\left(2\right)}=1$ w.r.t. $Z_1=1$ is $1=1\times 1+0$, thus $m_3=\min (1,8)=1$, and set $Y^{\left(3\right)}=Y^{\left(2\right)}+1=19$. It remains $8-1=7$ particles of amount $Z_3$. The algorithm stops there, and $Y^{\left(3\right)}=Y$.
• Suppose $Y=53$ and we have the following particle amounts $Z_1=4$ ten times ($q_1=10$), 2 twenty times ($q_2=20$), and $Z_3=1$ hundred times ($q_3=100$).
  We proceed as follows: the Euclidean division of $Y=53$ w.r.t. $Z_1=4$ is $53=13\times 4+1$, thus $m_1=\min (10,13)=10$, and set $Y^{\left(1\right)}=40$. It remains no particle of amount $Z_1$.
  Next, the Euclidean division of $Y-Y^{\left(1\right)}=13$ w.r.t. $Z_2=2$ is $13=6\times 2+1$, thus $m_2=\min (20,6)=6$, and set $Y^{\left(2\right)}=Y^{\left(1\right)}+12=52$. It remains $20-6=14$ particles of amount $Z_2$.
  Finally, the Euclidean division of $Y-Y^{\left(2\right)}=1$ w.r.t. $Z_3=1$ is $1=1\times 1+0$, thus $m_3=\min (1,100)=1$, and set $Y^{\left(3\right)}=Y^{\left(2\right)}+1=53$. It remains $100-1=99$ particles of amount $Z_3$. The algorithm stops there, and $Y^{\left(3\right)}=Y$.
• Suppose $Y=185$ and we have the following particle amounts $Z_1=10$ nineteen times ($q_1=19$), and $Z_2=1$ three times ($q_2=3$).
  We proceed as follows: the Euclidean division of $Y=185$ w.r.t. $Z_1=10$ is $185=18\times 10+5$, thus $m_1=\min (19,18)=18$, and set $Y^{\left(1\right)}=180$. It remains one particle of amount $Z_1$.
  Next, the Euclidean division of $Y-Y^{\left(1\right)}=5$ w.r.t. $Z_2=1$ is $5=5\times 1+0$, thus $m_2=\min (3,5)=3$, and set $Y^{\left(2\right)}=Y^{\left(1\right)}+3=183$. It remains no particle of amount $Z_2$.
  Finally, set $Z=Z_1=10$, and we explode Z into $Z^{\prime }=8$ and $y=Y-Y^{\left(2\right)}=2$, so that we obtain $Y^{\left(2\right)}+y=Y$. One particle of amount $Z^{\prime }$ is created.
• Suppose $Y=185$ and we have the following particle amounts $Z_1=10$ twenty times ($q_1=20$), only.
  We proceed as follows: the Euclidean division of $Y=185$ w.r.t. $Z_1=20$ is $185=9\times 20+5$, thus $m_1=\min (20,9)=9$, and set $Y^{\left(1\right)}=180$. It remains $20-9=11$ particles of amount $Z_1$.
  Finally, set $Z=Z_1=20$, and we explode Z into $Z^{\prime }=15$ and $y=Y-Y^{\left(1\right)}=5$, so that we obtain $Y^{\left(1\right)}+y=Y$. One particle of amount $Z^{\prime }$ is created.
• Suppose $Y=247$ and we have the following particle amounts $Z_1=10$ thirty times ($q_1=30$), and $Z_2=3$ ten times ($q_2=10$).
  We proceed as follows: the Euclidean division of $Y=247$ w.r.t. $Z_1=10$ is $247=24\times 10+7$, thus $m_1=\min (30,24)=24$, and set $Y^{\left(1\right)}=240$. It remains $30-24=6$ particles of amount $Z_1$.
  Next, the Euclidean division of $Y-Y^{\left(1\right)}=7$ w.r.t. $Z_2=3$ is $7=2\times 3+1$, thus $m_2=\min (10,2)=2$, and set $Y^{\left(2\right)}=Y^{\left(1\right)}+6=246$. It remains $10-2=8$ particles of amount $Z_2$.
  Finally, set $Z=\max (Z_1,Z_2)=\max (10,3)=10$, and we explode Z into $Z^{\prime }=9$ and $y=Y-Y^{\left(2\right)}=1$, so that we obtain $Y^{\left(2\right)}+y=Y$. One particle of amount $Z^{\prime }$ is created.

6.3. Buy (Respectively, Sell)-Order Problem: Inputs (Respectively, Outputs)

For cost-reduction purposes, as well as masking more privacy, the exchange can consider a set of p distinct buy orders to form particles ($p>1$) from the same user or, better, distinct users. In this case, if we designate by $X_i$ the amount for the $i^{\mathrm{th}}$ buy order, we set $X={\sum }_{i=1}^p{X}_i$. Section 5.2.3 and Section 6.1 then apply to X thus defined. This means that the p orders are forming a unique ‘super’ buy order as shown in the bottom of Figure 7.

In addition, the Pool could form a set of $p^{\prime }$ outputs of a ‘super’ sell order, obtained by gathering the set of current sell orders in the market. If we introduce $Y_i$ as the amount of the $i^{\mathrm{th}}$ sell order, we set $Y={\sum }_{i=1}^{p^{\prime }}{Y}_i$. Section 6.2 then applies to Y thus defined.

6.4. Simulation of an Order-Book System Subject to the Particles Model

To illustrate the dynamic behavior of the Particles model, we conducted a simulation of a simplified order book subject to 10,000 consecutive random buy and sell orders. The initial state (depicted in blue in Figure 8) consisted of particles with relatively larger amounts of bitcoins. The simulation, implemented in R on a standard laptop (32 GB RAM, Windows 11) and completed in approximately 10 s, used $r=50$. After the 10,000 simulated orders, the resulting distribution (shown in pink) reveals a shift towards a greater abundance of smaller-cash particles, indicating a tendency for the system to fragment larger UTXOs into smaller denominations through the buy/sell action. This dynamical fragmentation is consistent with the theoretical framework above and enhances the exchange’s trading liquidity, as sell orders can be fulfilled more readily and with greater precision.

Figure 8. UTXO distribution before (blue) and after (pink) 10,000 random buy/sell orders in the Particles model, demonstrating fragmentation into smaller denominations and improving trading liquidity.

For illustration purposes, we also performed the simulation for 100,000 simulated orders in Figure 9 (3 min).

Figure 9. UTXO distribution before (blue) and after (pink) 100,000 random buy/sell orders in the Particles model.

7. Optimal Calibration

In this section—which is an application of the above modeling to an exchange which uses the Particles model—we introduce a novel approach to Optimal Calibration, an important component for the practical deployment of our proof-of-solvency framework. This section moves beyond simply ensuring solvency and privacy to address the economic viability of the proposed system. By deriving a fair price for transactions, we aim to create a sustainable ecosystem that benefits both the exchange and its users. This optimal calibration is a piece of the puzzle for encouraging the broader adoption of our framework and providing advantages to the CEX.

7.1. Transaction Fair Price

From [32], it is possible to evaluate the size (in bytes) of a transaction.

Definition 2.

If a system of T transactions has K inputs and M outputs in total, the total cost to perform this system of transactions is given by

$$C=K\mathrm{In}+M\mathrm{Out}+10T,$$

(18)

where In = 148 and Out = 34 (Input script type: P2PKH; one signature per input; no pubkey). In addition, we introduce the  fair price   of a transaction as

$$c=⌊{\displaystyle \frac{C}{T}}⌋,$$

(19)

which is the average cost per transaction of the system (note that, in Equation (18) and for a given number T of transactions, if K and M are random variables (hence C is random), then we would better use the definition $c=⌊\mathbb{E}\left(C\right)/T⌋$. The equality $\mathbb{E}\left(K\right)=\mathbb{E}\left(M\right)$ is an intuitive condition for an exchange to be sufficiently liquid).

For BTC, 1 byte is 1 BTC satoshi so that Equation (18) gives the price in BTC satoshis for one system with T transactions, K inputs, and M outputs.

7.2. Fair Price-Optimal Calibration

We consider $k_i$ total number of inputs of buy-order transactions, which have i inputs, and $m_i$ total number of outputs of sell-order transactions, which have i outputs. Let $k={\sum }_i{k}_i$ and $m={\sum }_i{m}_i$, which are the total inputs of buy-order transactions, respectively, outputs of sell-order transactions. We can calculate the total cost of the system in Figure 10. We indeed have $K=k+n{\sum }_i{m}_i/i$ ($m_i/i$ is the number of sell-order transactions of i outputs), $M=n{\sum }_i{k}_i/i+m$, and $T={\sum }_i(k_i+m_i)/i$ so that we have the following theorem.

Figure 10. Illustration of a sets of inputs and outputs interacting with the exchange. There are buy-order transactions (left-hand side, purple boxes) having in total k inputs, and sell-order transactions (right-hand side, blue boxes) having in total m outputs. We suppose, to simplify, that there are systematically n particles involved for explosions and implosions. We are able to derive a fair price-optimal calibrated strategy (source of the figure: [7]).

Assumption 2.

The average condition for the price refers to when $k_i=m_i$, for all i (as many buy orders with i inputs than sell orders with i outputs, for those existing).

Theorem 4.

With the above notations, and under the average condition, the optimal fair price $\overline{c}$ is given by

$$\begin{array}{|c|}\hline \overline{c}=91\left({\displaystyle \frac{\overline{X}}{l}}-\overline{\alpha }\overline{X}\left({\displaystyle \frac{1}{l}}-{\displaystyle \frac{1}{r}}\right)\right)+A\\ \hline\end{array}$$

(20)

where $\overline{X}$ is the average transaction value for buy orders, $\overline{\alpha }$ is the calibrated value giving the optimal price, and A is a constant depending on the system.

Proof. 

The total price of system shown in Figure 10 is given by

$$C=\left(k+n\sum _i{\displaystyle \frac{m_i}{i}}\right)\mathrm{In}+\left(n\sum _i{\displaystyle \frac{k_i}{i}}+m\right)\mathrm{Out}+10\sum _i{\displaystyle \frac{k_i+m_i}{i}}.$$

(21)

The fair price is given by

$$c={\displaystyle \frac{{\displaystyle \left(\sum _i\frac{k_i}{i}\right)\mathrm{Out}+\left(\sum _i\frac{m_i}{i}\right)\mathrm{In}}}{{\displaystyle \sum _i\frac{k_i+m_i}{i}}}}n+{\displaystyle \frac{k\mathrm{In}+m\mathrm{Out}}{{\displaystyle \sum _i\frac{k_i+m_i}{i}}}}+10.$$

(22)

From Equation (22), the average condition leads to

$$c={\displaystyle \frac{\mathrm{In}+\mathrm{Out}}{2}}n+A,$$

where ${\displaystyle A=10+\frac{{\displaystyle k/2}}{{\displaystyle \sum _i(k_i/i)}}(\mathrm{In}+\mathrm{Out})}$. We now set $\overline{X}$ as the average transaction value in the exchange, for buy and sell orders, that is, in light of Equation (13), the value $\overline{X}$ satisfies

$$\exists \alpha \in [0,1]n=⌊\alpha {\displaystyle \frac{\overline{X}}{r}}+(1-\alpha ){\displaystyle \frac{\overline{X}}{l}}⌋.$$

Since $(\mathrm{In}+\mathrm{Out})/2=91$, we have that

$$c=91⌊\alpha {\displaystyle \frac{\overline{X}}{r}}+(1-\alpha ){\displaystyle \frac{\overline{X}}{l}}⌋+A=91⌊{\displaystyle \frac{\overline{X}}{l}}-\alpha \overline{X}\left({\displaystyle \frac{1}{l}}-{\displaystyle \frac{1}{r}}\right)⌋+A.$$

Since the map $\alpha \mapsto \overline{X}/l-\alpha \overline{X}\left(1/l-1/r\right)$ is strictly non-increasing ($l\le r$), and since there are integers in $[\overline{X}/r,\overline{X}/l]$, there exists a maximal value $\overline{\alpha }\in [0,1]$ such that $\overline{X}/l-\overline{\alpha }\overline{X}\left(1/l-1/r\right)$ is the minimal-valued integer contained in $[\overline{X}/r,\overline{X}/l]$.

Thus, we obtain the optimal fair price $\overline{c}$, given by

$$\overline{c}=91\left({\displaystyle \frac{\overline{X}}{l}}-\overline{\alpha }\overline{X}\left({\displaystyle \frac{1}{l}}-{\displaystyle \frac{1}{r}}\right)\right)+A$$

This is the optimal fair price corresponding to the cost-optimal calibrated parameter $\overline{\alpha }$. □

It is worth mentioning that r can be interpreted as the average amount associated with particles.

7.3. Fair Price, Optimal Calibration—Numerical Application

We can obtain the value of $\overline{X}$ from the exchange. As an example, on average, customers make buy or sell orders with amount $\overline{X}=0.5$ BTC. Hence $\overline{X}=5\times {10}^7\gg r$ = 100,000 $\gg l=1$, so that, on the one hand, $\overline{\alpha }=1$ and $n=\overline{X}/r=500$. With $A\approx 10+(\mathrm{In}+\mathrm{Out})/2=101$, the minimal fair price is given by

$$\overline{c}\approx 45,601\mathrm{BTC}\mathrm{satoshis}\approx \$52.9.(\mathrm{At}\mathrm{the}\mathrm{time}\mathrm{of}\mathrm{writing},1\mathrm{BTC}=\$\mathrm{116,069}.)$$

With this calibration, the fair price of a transaction is given by USD 52.9.

8. Experiments and Results

In this section, we provide empirical evidence supporting the feasibility, scalability, and advantages of the proposed proof-of-solvency protocol and the Particles model. The evaluation focuses on five key aspects: (i) computational efficiency of the Liability Tree, (ii) privacy enhancement through particleization, and (iii) liquidity improvement and numerical validation of the fair price calibration.

All simulations were performed on a standard laptop (Intel i7, 32 GB RAM). Since real client liabilities are not publicly accessible, we set ourselves as a virtual exchange and generated synthetic datasets that mimic realistic exchange distributions: client liabilities were sampled from log-normal distributions, while order sizes were drawn from exponential distributions to replicate heavy-tailed trading behavior. Unless otherwise noted, we simulated between ${10}^3$ and ${10}^6$ clients and between $2\times {10}^3$ and $2\times {10}^4$ trading orders. Publicly available blockchain data were not required for these tests, though the algorithms are designed to operate, for instance, on actual Bitcoin or Ethereum address sets.

For comparative purposes, we contrast our approach with baseline solvency structures relying solely on naive Merkle Trees (without privacy enhancements) and simple UTXO pools (without particleization).

8.1. Liability Tree Efficiency

We first evaluate the computational feasibility of building and verifying Liability Trees for different client populations. Table 1 reports tree height, construction time, average verification latency, and proof sizes.

Table 1. Liability Tree simulations (10 runs—error bars not represented for the average verification time, as they are of the same magnitude order).

Client (N)	Tree Height ($\lceil {\mathbf{log}}_2\mathit{N}\rceil$)	Build Time (s)	Avg. Verify Time (s)	Proof Size (Bytes)
500	9	0.0010 ± 0.0001	0.000009	320
1000	10	0.0020 ± 0.0001	0.000010	352
2000	11	0.0041 ± 0.0003	0.000011	384
5000	13	0.0099 ± 0.0003	0.000013	448
10,000	14	0.0223 ± 0.0043	0.000014	480
20,000	15	0.0471 ± 0.0054	0.000015	512
50,000	16	0.1258 ± 0.0102	0.000016	544
100,000	17	0.2778 ± 0.0222	0.000017	576
1,000,000	20	2.198 ± 0.1518	0.000045	672

As shown in Figure 11 and Figure 12 (average over 10 runs), we have the following:

Figure 11. Liability Tree construction time as a function of the number of clients N, averaged over 10 independent runs. Error bars indicate one standard deviation around the mean. Build time scales linearly in N, yet remains within a few seconds even for ${10}^6$ clients.

Figure 12. Client-side verification time as a function of the number of clients N. Since verification requires $\lceil {log}_{2}N\rceil$ hash computations, the cost grows logarithmically. Verification remains in the order of tens of microseconds even for millions of clients, confirming the practicality of the approach (error bars not represented, as they are of the same magnitude order).

• The time to construct the Liability Tree grows linearly with N. Even for ${10}^5$ clients, the tree can be built in well under a second; at ${10}^6$ clients, extrapolated construction remains feasible in ∼2 s.
• Verification requires only $\lceil {\log }_{2}N\rceil$ hashes, resulting in sub-millisecond client-side verification times. Proof sizes remain compact (<1 kB even for a million clients).

These results demonstrate that the Liability Tree is both computationally and communicationally lightweight, enabling continuous proof-of-liability at exchange scale without burdening clients.

8.2. Privacy Enhancement via the Particles Model

We next quantify anonymity gains. Without particleization, each order generates a single UTXO, making entropy effectively zero. With the Particles model, buy orders are split into 2-100 fragments, and anonymity is measured as Shannon entropy of active user indistinguishability [7].

As Figure 13 illustrates, entropy increases steadily with order activity, yielding anonymity sets equivalent to several hundred indistinguishable users in practice. This demonstrates that the Particles model significantly reduces the probability of successful tracing attacks.

Figure 13. Anonymity entropy over time for the Particles model (mean of 10 runs). Entropy steadily increases as the number of processed orders grows, reaching double-digit values within a few thousand orders. This confirms that particleization substantially enhances privacy by enlarging the anonymity set over time.

8.3. Liquidity Improvement and Fair Price Validation

We compare the ability of baseline vs. particleized order books to satisfy sell orders. Baseline matching was restricted to direct, two-sum, or three-sum UTXO combinations, while the Particles model employed our greedy Algorithm 5 with splitting when necessary. More specifically, the fill ratio is the fraction of sell orders that can be exactly satisfied (matched) by available particles in the pool at the moment of the request. We ran the following experiment for 12 k buy orders and 5 k sell orders (which took ≈ 150 s):

• Baseline pool (particleization): Each buy creates one UTXO of size ${10}^6$ satoshis. For each sell, the matcher tries (in order): (i) exact match, (ii) two-sum, (iii) three-sum. To keep the runtime reasonable at this scale, the search was capped: candidates considered were sampled and bounded. This mirrors a practical ‘best effort’ book rather than an exhaustive subset-sum solver.
• Particles model: Each buy with amount X is split into many particles with a hard cap $r={10}^5$ satoshis on particle size, with $l=1$, $\alpha =1$ so $n\approx X/r$. Sell is described as in Section 6.2.

The Particles model dramatically improves liquidity, raising the fraction of perfectly matched orders from 46% to 100%, see Table 2 This validates that order fragmentation increases the probability of fulfilling sell requests with minimal slippage, and long-time exchange becomes more and more liquid, validating the other simulations in Section 6.4.

Table 2. Fraction of sell orders that can be exactly sastified (matched) by available particles in the pool at the moment of request.

Setting	Fill Ratio
Baseline (naive)	$0.460\pm 0.006$
Particles model	$1.0\pm 0.0$

Finally, we validate the theoretical calibration of Section 7.3. Using 50 randomly generated transaction systems, we compute the average transaction cost per system:

• Average transaction cost: 20,789 satoshis (std dev 891 satoshis) ≈ 0.000208 BTC;
• At 1 BTC = 116,069 USD: ≈24.1 USD per transaction.

Figure 14 shows the distribution of per-transaction costs across systems, centered around 20–22 k satoshis. This empirical estimate confirms our earlier theoretical calibration, demonstrating that the system remains economically viable.

Figure 14. Distribution of average transaction cost (bytes per transaction, i.e. satoshis) across 100 simulated transaction systems. The distribution centers around 20,784 satoshis (USD ≈ 24.1 at BTC = USD 116,069), confirming the theoretical fair price calibration.

9. Conclusions

This paper depicted a method for implementing a proof-of-solvency protocol and a way to enhance privacy on an exchange. Specifically, we attempted to provide concrete practice for proving reserves and liabilities when an exchange’s counterparties are limited to external liquidity providers (other exchanges) and exchange customers. The proposed proof of solvency takes into account two asset categories: (i) cryptocurrency assets, in which case all the transactions are stacked into the blockchain, and are therefore publicly available, and (ii) fiat currency holdings (GBP, EUR, and USD) where the exchange either chooses to prove solvency via receipts (the easiest way but requires usual trust), or tokenize the fiat currency from a stablecoin exchange (which could be state). Where tokenization is implemented, related transactions can be stored into a public blockchain owned by the stablecoin exchange (the blockchain can also be made available for use by other exchanges). For each type of asset, we introduced a protocol for proof of reserves and one for proof of liabilities (including the Liability Tree proposal—see the Section 2.7). These protocols are quite practical but could be further adapted.

As exchanges risk violating user privacy, we proposed a protocol that triggers an explosion of UTXOs (aka particles) of the buy order amount set by a customer, and an implosion gathering ready-made particles into a unique output to the value of a sell order. In this model, i.e., the Particles model, we established conditions for the existence of solutions, calculated the number of solutions, and provided algorithms for practical and efficient solutions’ implementation. Our solutions have the advantages of being intuitive, simple, and consistent. It is worth pointing out that we are providing a methodology for CEX to allow more liquidity. By adding the formula for calculating the fair price, we concluded with a specific calibration that minimizes the fair price. This calibration is an opportunity for a win–win relationship between the exchange and the miners.

From a managerial perspective, the implementation of this proof-of-solvency protocol and privacy-enhancing Particles model offers a pathway to restoring trust in cryptocurrency exchanges, differentiating them in a competitive landscape, and potentially attracting institutional investors who demand higher levels of transparency and security. The ability to provide continuous, verifiable proof of solvency can be a powerful marketing tool, demonstrating a commitment to responsible financial practices and setting a new standard for the industry. Furthermore, the Particles model, by increasing transaction anonymity, addresses growing user concerns about privacy, positioning exchanges as custodians of user data. However, managers must carefully weigh the costs of implementation, including the computational overhead, especially concerning scalability in high-frequency trading environments. Beyond these operational considerations, systemic trust incentives require careful examination. While the protocol aims to increase transparency, ensuring that exchanges are motivated to maintain its integrity and that users are able to effectively verify the provided information remains a key challenge. Further research is needed to explore the design of incentive structures, such as staking mechanisms or reputation systems, that reward honest participation and deter malicious behavior. Finally, the discussion remains open with regard to some regulatory conflicts in terms of governance needed to improve exchange trustworthiness. Future research should focus on refining the cost–benefit analysis of this approach in diverse market conditions and regulatory environments. The exploration of alternative privacy-preserving techniques, such as zero-knowledge succinct non-interactive arguments of knowledge (SNARK/STARK) or secure multi-party computation, and their integration with proof-of-solvency protocols could offer enhanced efficiency and scalability. Research should also investigate the use of automated governance mechanisms to ensure protocol compliance and reduce the risk of manipulation. Finally, developing a standardized framework for proof-of-solvency reporting, perhaps leveraging decentralized autonomous organizations (DAOs) to oversee implementation and validation, could foster greater consistency and comparability across the cryptocurrency ecosystem. Furthermore, careful consideration must be given to navigating the evolving regulatory landscape to ensure compliance with jurisdictional requirements and avoid potential conflicts with data privacy laws. While a comprehensive comparative analysis is beyond the scope of this paper, several ongoing developments are tackling related challenges. These include advancements in confidential computing, federated learning for fraud detection, and novel approaches to decentralized identity management. Beyond the banking sector, these models have significant potential in supply chain management (ensuring transparency and accountability), healthcare (protecting patient data while enabling data sharing), and voting systems (enhancing security and verifiability). The growing emphasis on blockchain security and privacy is driving demand for professionals skilled in cryptography, smart contract auditing, and decentralized system architecture, suggesting promising future job prospects in these areas. Moreover, expertise in regulatory compliance and risk management within the blockchain space will become increasingly valuable as the industry matures. By rigorously pursuing these avenues of research and development, we can unlock the full potential of blockchain technology to build a more transparent, secure, and equitable financial future for all.