1️⃣General & Scoping
1. General & Scoping Section Summary
This section is made up of 4 preparatory steps, all aimed at determining what assets and liabilities are to be included within the scope of the Proof of Reserves. This is likely the most important section to ensure you get right!
1a. Determine the Entities & Platforms In-Scope
Frequently, digital asset service providers may have various entities and multiple trading or custody platforms that hold assets on behalf of customers. This can include spot trading platforms, futures platforms, or bridging services. It is crucial to take into account all these custodial relationships.
The initial phase involves identifying the specific platforms and their associated entities that fall within the scope of the Proof of Reserve assessment.
Along with step 1b, this is one of the most important steps in the Proof of Reserves Preparation process. We encourage readers to read the expanded "manual" on this step!
1a. Management Outputs
1a. Example Scenario
TNF.COM operates a family of exchanges, namely TNF.US, TNF.SG, and TNF.MENA. TNF segregates exchange platform databases and assets by country of operation. The primary impetus for TNF's pursuit of a Proof of Reserves stems from Texas legislation. Consequently, TNF.COM has opted to incorporate only customer liabilities and corresponding assets pertaining to TNF.US in the assessment
1b. Determine the Customer Liabilities & Assets In-Scope
The next step for a custodian in the Proof of Reserves process is to determine which pairs of custodial assets and customer liabilities can, should, and are preferable to be included within the scope of the Proof of Reserve. Asset/Liability pairs refer to a fundamental principle in the financial system where what one party considers an "asset" is often a "liability" (an IOU) for another party. Generally, financial instruments that individuals treat as assets are also considered liabilities issued by another entity. This asset/liability relationship is inherent in the financial system and introduces an element of counterparty risk, which is mitigated through Proof of Reserves.
In the context of Proof of Reserves, an asset/liability pair is a financial instrument where the "asset holder" and "liability issuer" are explicitly defined. In other words, it is about identifying who owes what to whom.
In the realm of cryptocurrency, understanding these asset/liability pairs is a complex but essential part of the Proof of Reserves process. A certain asset, such as Bitcoin, may collateralize multiple types of Bitcoin-denominated liabilities, or a single pool of assets may back up several types of customer liabilities. This suggests potential "one-to-many" or "many-to-one" relationships between assets and liabilities.
When conducting a Proof of Reserve, it's crucial to accurately identify the pairs of assets and liabilities within its scope. This typically starts with creating a list of customer platform liabilities, then identifying the associated asset pools. The goal is to ensure that all liabilities that have a claim on the same pool of assets are accounted for, to prevent unintentional understatement of assets. This process often involves the use of a modified "T-Account" or a "Balance Sheet" for visualizing the asset/liability pairs.
The scope of the Proof of Reserves is primarily determined by the custodian, at least until regulatory or other standards are established. But if the custodian is using an auditor, the auditor's considerations may also influence the scope of the Proof of Reserves.
1b. Management Outputs
1b. Example Scenario
Example List of Platform Liability Types & Mapping to Underlying Collateral Assets:
1c. Determining the 'Snapshot Time'
Each Proof of Reserves represents a snapshot at a specific point in time. The Customer Liability Extract report is generated at this chosen moment, and the asset balances are pulled concurrently, mirroring the concept of a 'Balance Sheet snapshot.' For the Proof of Reserves, it is crucial to select an appropriate snapshot time and have the PoR methodology fully detailed prior to that moment.
If the Exchange platform has the capability to extract historical customer balances at specified time points, it offers us considerably more flexibility in deciding on a snapshot time.
Ultimately, the snapshot time is up to you. The most popular characteristics of the snapshot time include:
End of day/month/quarter
Specific times with less activity on the platform
Alignment with regulatory requirements
1c. Management Outputs
1c. Example Scenario
You can view a "live" widget with all historical snapshots available via the dropdown.
1d. Creating an Architecture Diagram
This step involves outlining and communicating a detailed understanding of the system's infrastructure that generates the Customer Liability Extract Data. Two main components require attention:
Database/Tables: An architectural overview diagram of the underlying databases and tables that facilitate the generation of the Customer Liability Extract Data is needed. This diagram would ideally outline how different databases and tables interact and contribute to the extraction of the data.
Wallets: Understanding the wallet/private key architecture is another crucial aspect. An overview architecture diagram can help provide insights into how various wallets and private keys are managed and their roles in the system.
In essence, the main aim of this step is to grasp how information or data are aggregated and organized to create the Customer Liability Extract. This process involves understanding the roles of different databases, tables, and wallets in this system.
1d. Management Output
1d. Example Scenarios
Below is an example that provides a visual representation of the database architecture, individual databases, and tables utilized for generating the Customer Liability Extract Data.
Displayed below is an illustrative example that provides a comprehensive view of the general wallet and private key architecture.
Last updated
