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.