When do cryptocurrency audits go from simple to complex? Part 1: Ownership

When do cryptocurrency audits go from simple to complex? Part 1: Ownership

As an Entity that is going through or that needs to go through a financial statement audit, you must wonder how the auditors come up with their audit fees. There are plenty of factors auditors consider while providing a quote for a cryptocurrency audit engagement. This blog post will highlight why some audits can be more resource intensive (i.e. requiring additional expertise, time, and people) than others.

As part of their audit procedures, auditors need to obtain audit evidence for several “Assertions” as they relate to cryptocurrencies held by an Entity, such as Bitcoin. The topic of this post is ownership, but stay tuned for an exploration of Existence, Completeness, Valuation.

When discussing ownership, often enthusiasts in the cryptocurrency community repeat the mantra “not your keys, not your bitcoin.” To them the implication is that you cannot own cryptocurrency without being the custodian of your private keys. The converse is also implied: if they are your keys, then they are your coins. In other words, cryptocurrency is commonly construed as a bearer asset (like cash, simply holding it means you own it). This is NOT the stance that regulators or mainstream users take.

The concept of Ownership of cryptocurrencies can be split between control and rights. To demonstrate control of a cryptocurrency, you can either move it or sign a message (i.e. show you know the key). However, there is this fundamental risk that many people can control a cryptocurrency (such as when two people know the private key) without the legal rights associated to this cryptocurrency. During a financial audit, not only will you need to show to your auditor knowledge of a private key, but that you are the rightful owner of the assets it guards. If a client has only a handful of addresses, the auditor can manually handle these. Seeing as each one takes some time, documentation and reporting to validate, costs rise with the number of addresses. Excitingly, there is a standard in the cryptocurrency world that was created by Bitcoin Improvement Proposal 32, where people who require many Bitcoin addresses may link these together in what is called a Hierarchically Deterministic Wallet (HD wallet).

Instead of creating a private key, the Entity creates an extended private key which generates an extended public key. This extended public key can be used to generate millions of public keys. Each public key can be spent by the extended private key. The auditor can then prove ownership of the extended public key without any need to prove ownership of the multiple addresses. However, the auditor needs to demonstrate that those millions of addresses are indeed derived from the extended public key, a process which can be automated with software tools.

Generally, when entities do use extended public keys, they have one for each cryptocurrency type (Bitcoin, Ethereum, etc.). If they hold 15 types, then all is required is 15 tests (assuming of course that all cryptocurrency types are significant enough for the auditor to be tested). Interestingly, BIP 32 was further improved by BIP 44, which created a way to signal the derivation of addresses across many blockchains (such as Ethereum or Litecoin). As a result, it is entirely possible to have all asset types controlled by a single extended private key.  Theoretically, a cryptocurrency exchange with dozens if not hundreds of cryptocurrencies, could prove to an auditor that they owned millions of addresses of different types with a single proof.  This would be an efficient process

The other challenge we mentioned is address complexity. Most people do not realize this, but almost all addresses are a hash (a.k.a. a digital fingerprint) of a set of requirements for unlocking funds. When Alice sends funds to Bob’s address, she must meet the requirements to unlock her funds (by providing her signature) and then she must also add the requirements of the payee, in this case Bob’s address. For example, let’s say that Bob wanted his address to have a co-signer. When Bob created his address, he would add the requirement that two signatures be provided for any spending. Rather than publish the code that handles these requirements, he would convert them to an address. Later, when Bob wants to send his funds, he will publish the list of requirements, demonstrate that these are the “pre-image” of the address (i.e. are the source of the fingerprint), and then go ahead and meet those requirements with his and his partner’s signatures. This is the most common kind of address complexity we see, and it is widely called a “multi-signature” or “multi-sig address”. In some sense it was the first and simplest smart contract.

In additional to requiring more than one key, addresses may require that a certain amount of time has elapsed (a.k.a. time-locking) or even require some arbitrary information. Interestingly, because of Bitcoin’s inflexible nature, there is a specific operation code for creating a multi-signature address. Ethereum, on the other hand, does not have a standard multi-signature scheme but allows people to create their own smart contracts to replicate multi-signature functionality. Costs can increase here as documented in the below example.

Imagine two different entities, Entity A which decides to write its own smart contract and Entity B which takes an open-source, code reviewed, widely used multi-signature smart contract. Take a wild guess which auditor is going to have a more difficult time? Reviewing Entity A’s smart contracts to validate ownership may take additional time for the auditor. They will need to ensure the smart contract does not include bugs or fraudulent features that could impact the procedures.  The auditor of Entity A will need to perform a review of the entity’s smart contract to validate the ownership of digital assets and this will normally take longer. The auditor will need to ensure that the smart contract does not contain any bugs or fraudulent features that could affect the procedures to be performed.

To sum up self-custody: certain procedures can be more costly than others. If the client has a renowned wallet, with signature features, that use BIP 44, and is not participating in an under-tested multi-signature smart contract, audit procedures to validate ownership could be relatively straightforward.  

Outside of self-custody, there are varying options as well.  Certain custodians have proven their seriousness though the obtention of SOC 2 reports. Without going into detail, such reports provide relevant information on the systems used by the custodians to ensure that certain trust criteria are met as it relates to customer data. When custodians have this type of certification, user entity auditors can then review the SOC report and reduce the scope of the procedures they must perform, including the necessary work to validate ownership. Again, this can be a very efficient process.

When those reports aren’t available, auditors may need to open a dialogue with the custodian, get an understanding of the internal controls and even test those controls to ensure they operated effectively during the audited period. This process can be time consuming and requires the full collaboration of the custodian. Without this comfort, validating ownership may represent yet another a challenge for the auditor to overcome.

If you have any questions on the above or on your ability to provide sufficient audit evidence of cryptocurrency holdings, do not hesitate to reach out! Your cryptocurrency experts at Catallaxy are here to help.