An audit that can not be independently verified or that is not trustless can be very superficial that is why our intention is to provide our customers a cryptographic proof of reserves audit. Greg Maxwell's proposal was a start, but his method does operate without revealing private data, such as balance-containing addresses.

In an attempt to overcome this security issue, our process does not require to disclose addresses or keys to the public. We choose a path that allows us to balance transparency and security and shows all Fairlay's concern about our customers privacy.

Proof of reservers

In a way to prove to our customers and third parties that their funds are safely held, Fairlay provides mathematical proof that holds full reserves.

Over 100% of all customer funds are kept in a cold storage and the sum of all issued credit to our customers will always be less than the amount of Bitcoins in our cold storage address, which is 1EV8YeieYEZ7iksGT9jS7KdcbE12pk4FwZ.

A modified version of Merkle Sum Trees is used to perform the proof and as the test passes you are guaranteed that your balance is included in our cold storage funds. To reach the proof of reserves page, you have to open up the info menu on our homepage, where you may select Proof of reserves. Then, to continue the audit process, login on your Fairlay account.

Check how our merkle tree audit works:

the Merkel Tree Constrution

A process is executed every 30 minutes to generate the merkle-tree of Fairlay accounts and it begins in the creation of leaves. These leaves are composed of usernames and balances of each account. This data is converted into a ByteArray (reference), which is then serialized into a hash SHA256 (reference), thus, obtaining a set of characters similar to the following example:

<code>     DFE0BBAB55759AA3564F04A6268070563B09DBD5625EDF0C52189C68CC564D7C </code>

You can check the hash SHA256 usability at this page: Hash Generator. Type “fairlay is safe” and you will notice that the generated code is the same in the example above. After the user hash is generated the leaf content will be the next:

sha256(username + balance)

Ex.: sha256(‘myusername100.00’)

Each leaf of the tree is a transaction that combines username and user balance. After the leaves are generated for each user, the construction of the branches begins. The leaves are joined in pairs forming a new hash, the balance of the two leaves are added up and so every branch is formed.

sha256(hash1+balance1+hash2+balance2)

The branches are grouped together again until only one node is left which is called root. The merkle root contains the balance of all users added and the hash of the last two remaining branches.

PERSONAL AUDIT

Users can monitor the merkle tree personally using the current top hash at Twitter. This top hash represents the root of the tree, the user ID generates its leaf and the listing of nodes containing the user leaf's path to the mentioned root.

Each object in the list has the following elements:

• Layer: the number of respective layer node. Layer 1 will be generated through the user data.

• Balance: the summed balance of all branches (below the current)

• Hash: branch hash

• Neighbours: Current branch's neighbour (used to check the next hash).

An independently verified audit shows the transparency our customers deserve. Customers can make their personal audits by following these steps:

1. The balance of our cold storage address in mBTC (at time of writing 1274000) at blockchain.info address;

2. The current top hash from Twitter (is renewed every 30 minutes);

3. Logged with your user at Fairlay access proof of reserves page, There you’ll see:

   1. the current top hash to be verified

   2. Your proof ID to make verifications

   3. A list of leaves to check you user with the respective neighbour hashes start by layer 1 and climbing to the biggest layer

For advanced users it is also possible to make a call at Fairlay’s API to fetch the same informations and verify the merkle tree:

1. Fairlay DotNet Client (our .NET Client);

2. Exact total balance in mBTC;

3. Logged with your user at Fairlay access proof of reserves page, There you’ll see:

4. The current top hash from Twitter (is renewed every 30 minutes);

5. API Username (can be retrieved via proof of reserves page and also be changed via the API);

Now use the DotNet Client and call:

sha256(hash1+balance1+hash2+balance2)

And your independent and cryptographically verifiable proof of reserves audit will be done.