FAQs

A Merkle Tree is a cryptographic technique used to efficiently summarize large datasets into a single hash known as the Merkle Root. This Merkle Root functions like a cryptographic fingerprint, encapsulating all the input data. The structure of Merkle Trees also allows for efficient verification of specific data elements within a large dataset.

This feature is particularly useful in our Proof of Reserves assessments, where we these properties of Merkle Trees to verify and confirm the inclusion of individual user accounts in the Proof of Reserves Attestation Report. Merkle Trees are integral to the functioning of major blockchain protocols such as Bitcoin and Ethereum, where they provide a unique cryptographic hash for every block of transactions.

In our Proof of Reserves, we employ a similar approach to generate a unique hash for all user accounts in a trading platform’s database. Additionally, Merkle Trees gives users the ability to verify specific contents were included within a particular set of “sealed” data This process ensures the integrity and verifiability of the data, bolstering trust and transparency in digital transactions.

By constructing a Merkle Tree from the complete list of user account balances, Moore offers a privacy-centric method for users of platforms like exchanges or crypto lenders to participate in assessments.

This process involves publishing the Merkle Root Hash derived from our assessment. Users can then use the tools available on Moore Jonesburg’s assurance platform, TrustReserve™ to independently confirm that their individual User Account balances (such as BTC or ETH) were included in the Proof of Reserves assessment.

This feature empowers users, allowing them to personally ensure that the platform has accurately represented their account in the Proof of Reserves assessment conducted by Moore Johannesburg.

Essentially, this approach not only maintains user privacy but also fosters trust and transparency by enabling users to directly verify the integrity of the platform’s reported reserves.

The Merkelization process is a key step in conducting Proof of Reserves assessments. It starts by isolating each specific data point within a dataset.

In the context of a Proof of Reserves, every data point consists of a unique hashed user ID along with the user’s platform balances as recorded in the platform’s database.

During this process, Moore Johannesburg, accesses only the hashed user IDs, ensuring no personally identifiable information is revealed.

Each user’s hashed ID and account balances are then hashed again using SHA256, creating a distinct and confidential hash value. This value serves as a personal Merkle Leaf for every user.

The use of SHA256 for hashing adds an extra layer of security and privacy, making the Merkelization process a crucial part of maintaining the integrity and confidentiality of the Proof of Reserves assessments.

In Proof of Reserves assessments, a technique similar to that used in Bitcoin and other blockchains is employed to amalgamate all individual Merkle Leaves into a single hash, known as the Merkle Root. This process begins by pairing one user’s Merkle Leaf with another (referred to as a Sibling Leaf) and hashing them together. This action generates a new, unique hash that encapsulates the data of both users within a single Merkle Branch. This pairing and hashing are repeated iteratively until all user Merkle Leaves are integrated into the single Merkle Root. This Merkle Root is a comprehensive hash that represents all hashed user IDs and platform account balances from the platform’s database.

To further enhance privacy and prevent the deduction of the total number of users, “dummy” records may be added as padding. This step is crucial because, without padding, the total number of users could potentially be estimated by calculating 2^n, where n is the number of levels in the Merkle Tree. These supplemental records, if used, carry no balances and don’t affect the user liability totals. The decision to add such records depends on the digital asset platform being assessed and their preference regarding the disclosure of platform data.

Importantly, due to the nature of hash functions as “one-way streets”, possessing the Root Hash alone does not enable one to trace back through the tree to uncover details about individual leaves or branches. However, a user who knows their original input data for a specific Merkle Leaf can verify that their unique data were indeed included in the Merkelization process. This aspect of the process ensures the security and verifiability of the data without compromising individual user privacy.

The completion of a full Merkle Tree in the Proof of Reserves process begins with the Merkle Leaves, which are composed of hashed User IDs combined with their respective Asset balances. These leaves are the foundational elements of the tree.

As the process progresses, these leaves flow upward through the Merkle Branches, which are intermediate hashes formed by pairing and hashing individual leaves together. This step-by-step consolidation continues until it culminates in the Merkle Root.

The Merkle Root is a comprehensive hash that encapsulates all the data from the various leaves, effectively summarizing the entire dataset into a single hash value.

This final step completes the full Merkle Tree structure, ensuring that all user data is securely represented in a consolidated and verifiable form. This structure not only provides a clear and concise representation of user balances but also maintains the integrity and confidentiality of individual user information throughout the assessment process.

Verifying a balance in the Merkle Tree involves a user confirming that their specific details are accurately included within the Proof of Reserves. Each individual Merkle Leaf, which represents a user’s hashed data, is directly connected to the Merkle Root.

To verify their balance, a user can recompute their unique path leading to the Merkle Root. This is done using their personal Merkle Leaf hash along with every Sibling Leaf hash encountered on their path to the Merkle Root. This sequence of hashes is known as the user’s Merkle Path.

By retracing this path and validating each step, users can independently confirm that their personal data was correctly incorporated in the Proof of Reserves. This process not only provides a means for users to ensure the accuracy and integrity of their recorded balances but also adds a layer of transparency and trust to the system. It gives users the capability to independently verify their data, reducing their reliance solely on Moore Johannesburg or the Crypto platform and empowering users to perform independent verifications.

TrustReserve Proof of Reserves™, powered by Moore Johannesburg, is a sophisticated web application, accessible through an embeddable web widget, designed to display information from Proof of Reserves attest engagements.

This tool serves two primary functions for its users: (1) It enables users to verify that their account balance was included in a specific Proof of Reserves attest engagement, and (2) it allows users to download the relevant point-in-time Agreed Upon Procedures attest reports.

The system is particularly beneficial for management teams of digital asset platforms, as it provides a transparent way to share periodic attestation reports with their customers.

These reports focus on two key areas: (1) the total in-scope token liabilities, which encompass all user account balances for the in-scope tokens (referred to as “on-platform liabilities”), and (2) the total in-scope tokens or digital assets held as reserves to fulfill obligations to customers (collectively termed the “subject matter”).

Proof of reserves attest engagements, conducted by Moore Johannesburg, are specifically limited to examining the specified customer on-platform liabilities and the corresponding digital assets held in reserve. It’s important to note that neither the proof of reserves attest engagement itself nor the presentation of its results through the web application pertains to a company’s other liabilities or assets. As a result, the reports available for download on this widget are not intended to replace financial statement audits. Instead, they should be viewed as supplementary information. Additionally, these reports are not designed to, nor can they, provide a comprehensive assessment of a company’s overall financial condition or “solvency”.

No, the Agreed Upon Procedures and the customer verification process provided through the TrustReserve™ widget are not in Real-Time but are instead it is specific to a clearly defined point in time.

This specific point in time is explicitly listed in both the Agreed Upon Procedures (AUP) reports and on the widget interface when selecting a date for current or past assessments.

Typically, Moore Johannesburg schedules these Proof of Reserves Attestation Engagements with their clients on a regular basis, which may be semi-annual, quarterly, or monthly.

Therefore, while the TrustReserve widget provides a powerful tool for customer verification, it’s important for users to note that the information it presents corresponds to the data from the most recent assessment, as of the date and time listed, rather than providing a real-time or continuously updated view. This approach ensures that each assessment is thorough and accurate, reflecting the state of reserves at a specific moment in time.