Assessing VASP Solvency For Cryptoassets: Closing The Data Gap
2024-6-20 04:0:27 Author: hackernoon.com(查看原文) 阅读量:5 收藏

Authors:

(1) Pietro Saggese, Complexity Science Hub Vienna (CSH);

(2) Esther Segalla, Oesterreichische Nationalbank (OeNB);

(3) Michael Sigmund, Oesterreichische Nationalbank (OeNB);

(4) Burkhard Raunig, Oesterreichische Nationalbank (OeNB);

(5) Felix Zangerl, Austrian Financial Market Authority (FMA);

(6) Bernhard Haslhofer, Complexity Science Hub Vienna (CSH).

Abstract and 1. Introduction

  1. Background and related literature
  2. VASPs: A Closer Examination
  3. Measuring VASPs Cryptoasset Holdings
  4. Closing The Data Gap
  5. Conclusions, Declaration of Competing Interest, and References

Appendix A. Supplemental material

5. Closing The Data Gap

We presented an approach to measure the cryptoasset holdings of VASPs by correlating data from multiple on-chain and off-chain sources. Empirical analysis of four VASPs reveals that only two of them show consistent comparisons of on-chain and off-chain data, indicating potential data-related problems. In this section, we systematically discuss the encountered data issues and provide suggestions for possible improvements.

5.1. On-chain data issues

Different wallet management strategies. VASPs employ diverse approaches to manage their cryptoasset transfers and holdings. While some create new addresses for each user transaction, others might reuse addresses. Moreover, their approach varies when dealing with UTXO-based or account-based ledgers. We observed that VASPs deploy user-specific Ethereum smart contracts wallets for each customer and subsequently forward the funds to a collector wallet. We did not observe this pattern with Bitcoin. This organization strategy makes it more challenging to identify cryptoasset holdings associated with VASPs. Identification largely relies on heuristics approaches, which can produce false positives and are often inadequately understood.

Lack of attribution data. Another issue concerns the lack of attribution data, i.e., associations of addresses with additional contextual information allowing the identification of their owner. Our attribution dataset contains more than 265,000,000 deanonymized Bitcoin addresses and 278,244 tagged Ethereum addresses. Furthermore, we have conducted additional manual transactions with their services to identify and tag the specific addresses associated with the VASPs investigated in our study. Despite this, the resulting data only provide a partial view of their holdings, as shown in the previous section.

Another issue associated with manual tagging is that it misses historical data. As we showed in Section 4 for VASP-12 and VASP-5, we could only trace the Bitcoin transaction history of a VASP back in time for a few months when using re-identification techniques.

Missing cross-ledger perspective. The data collected for both ledger types face a common issue — they may only represent a portion of the total cryptoassets holdings. This could be because manual transactions used to tag hot wallets, which are addresses used for daily deposit and withdrawal operations, may not successfully identify cold wallets, i.e., the addresses that manage most of the VASP funds. The latter are subject to stricter security measures that may prevent association with hot wallet addresses. Additionally, wallets such as VASP-2 and VASP-12 contain more funds than reported to authorities, making it difficult to differentiate between customers’ funds and other cryptoassets managed under the same wallet, such as equity or private funds.

5.2. Off-chain data collection issues

In addition to on-chain data, we used all data sources currently available for VASPs in Austria: balance sheet data from the commercial register and data from the supervisory entities.

Long reporting periods. Balance sheets are only published yearly, and asset holdings might differ before and after the exact reporting due date. Thus, the balance sheet statements of VASPs are only partially suitable for assessing their solvency.

Missing breakdown by cryptoasset type. Nevertheless, it is important to outline the type of data and a good reporting practice for such data to improve the transparency of virtual assetproviding companies. Not all firms report balance-sheet items for crypto and fiat asset holdings separately. In the data comparison in Section 4, we sometimes needed to use proxies for some VASPs that overestimate the actual cryptoasset holdings of a VASP, primarily due to the aggregation of multiple items within the same balance sheet entry. It is, therefore, essential that VASPs report their fiat and crypto asset and liability positions at a reasonable frequency separately from other activities within a company’s holding structure.

Subsidiary companies and different jurisdictions. VASPs may be subsidiaries of larger corporations. For VASP-9, we could not precisely determine the proportion of assets attributable to the subsidiary we examined. Moreover, many companies operate in several countries and fall under multiple jurisdictions, which adds another layer of complexity.

5.3. Limitations of our approach

Other limitations related to our approach stand out. First, data are extracted from the two major DLTs, Bitcoin and Ethereum, and only on a limited number of tokens supported by the latter. While these are the most relevant for market capitalization, including other DLTs and Ethereum tokens would be a straightforward improvement. Second, we gather Ethereum data by querying the account balances. Thus, we do not reconstruct balances from transactions, and we repeat the procedure on an interval of 10,000 blocks. We favor the approach based on querying the account states as it facilitates reproducibility at the cost of a lower granularity. We also note that this time interval can be easily changed with a shorter one. Third, our current approach is limited to end-year of 2021, but the analysis can potentially be extended to subsequent years.

5.4. Towards a systematic assessment of proof of solvency

Having discussed the data issues and limitations of our approach, we would like to sketch out our vision for a more systematic, reliable, and highly automated assessment of proof of solvency.

Assessing proof of solvency today. Fiat assets and liabilities are held at traditional financial intermediaries and undergo audits based on established standards. On the other hand, cryptoassets are held in cryptoasset wallets, scattered across various, potentially privacy-preserving DLTs, and are not subject to systematic and consistent audits. By measuring the cryptoassets held by one VASP, we can validate the amounts reported in the balance sheets. Given that the difference between assets and liabilities on a balance sheet equals equity, our method offers an initial, systematic validation and proof of solvency. However, balance sheets currently disclose crypto and fiat deposits from customers under one balance sheet position. Thus, we cannot answer whether the VASPs retain the customer funds in crypto or convert them to fiat (or vice-versa).

Improving on-chain data reporting. Regarding on-chain data, we note that determining the solvency of VASPs is unfeasible without knowledge of the crypto addresses they control. Hence, any auditing entity must be aware of the on-chain cryptoasset holdings a particular VASP manages. Furthermore, sharing a list of on-chain wallet addresses alone is insufficient. In a system with weak identities, anyone could hold the corresponding private keys and control the associated funds. VASPs need to prove they also control the funds they hold in custody for their users.

Revealing a list of on-chain wallet addresses and transferring funds proves that a VASP possesses and manages specific funds. However, this approach can create privacy, security, and operational efficiency concerns. One way to mitigate these issues is to share this information only with trusted entities such as certified auditors or regulatory authorities. Furthermore, this approach would not disclose any information on actual user deposits.

Finally, in addition to disclosing their on-chain wallets, VASPs should provide additional metadata describing the use of these wallets. Most importantly, they should differentiate between hot and cold wallets and customer and non-customer (corporate) wallets. With hot wallets, they could also distinguish between deposit and withdrawal wallets and specify whether they are used per customer or across customers. In addition to the amounts contained therein, it would also be important for auditors to know what digital and physical security measures are taken to prevent cold wallets from being compromised.

Improving off-chain data reporting. On the off-chain side, reporting requirements for a VASP should include a breakdown of asset holdings differentiating between fiat and crypto holdings. Such a breakdown is necessary for items on the asset side but also for items on the liability side. A step towards even more granularity is to differentiate the crypto items according to major cryptoassets and to provide wallet information on the storage of crypto asset holdings and liabilities. To understand the implications of VASPs on financial stability, frequent and detailed reports on the distribution of who are the counter-parties of VASPs (private customers, companies, other VASPs, . . . ) and concepts of how and where crypto assets are stored are necessary information.

Enhancing VASP solvency assessment. One possible strategy to improve the assessment process is to use cryptographic primitives. The academic literature has already proposed cryptographically secure proof-of-concept implementations for proofing the solvency of cryptoasset exchanges. Decker et al., 2015, in particular, proposed an audit process in a trusted computing environment that exploits digital signatures on their associated addresses for proofing reserves. Merkle trees, instead, are used to prove the total size of user deposits without directly leaking user-specific information. This technique has already been implemented by several centralized exchanges (e.g., Binance[14]). However, that method has two flaws: first, an attacker that controls many accounts could still potentially learn a significant amount about the exchange’s users; second, Merkle trees could allow an exchange that has more customer deposit assets than reserves to make up the difference by adding fake accounts with negative balances. To improve the privacy and robustness of that approach, Buterin (2022) recently proposed to use ZK-SNARK to prove that all balances in the tree are non-negative.

A more forward-thinking strategy goes in the direction of automation. Given access to both on- and off-chain data with specific detail and granularity, the entire audit process could be streamlined and performed more systematically, frequently, and reliably than current methods allow. In line with this perspective, Auer (2019) introduced the concept of “embedded supervision” enabling automated monitoring of decentralized finance (DeFi) services to ensure compliance with regulatory objectives. Buterin et al. (2023) studied an automated privacy-enhancing protocol that utilizes smart contracts and ZK-SNARKS to prove that the users’ assets were received from lawful sources. Additionally, Eichengreen et al. (2023) suggest that real-time audits carried out by independent proof-of-reserve systems and facilitated by smart contracts could effectively mitigate the threat of stablecoin devaluation.

In conclusion, it is noteworthy that, according to Article 29 (1) of the Austrian AML-Act, the FMA already possesses the authority and legal mandate to request essential data from all obliged entities (i.e., VASPs) at any time on all issues that are addressed in the Austrian AML-Act and Regulation (EU) 2015/847, e.g. a list of cryptoasset addresses under their control[15].


[14] https://www.binance.com/en/proof-of-reserves

[15] https://www.ris.bka.gv.at/eli/bgbl/i/2016/118/P29/NOR40189690, https://eur-lex.europa.eu/eli /reg/2015/847/oj


文章来源: https://hackernoon.com/assessing-vasp-solvency-for-cryptoassets-closing-the-data-gap?source=rss
如有侵权请联系:admin#unsafe.sh