First, let’s start with a simple definition of a block explorer: it’s a software tool that makes blockchain data human-readable. Their general purpose is to confirm the quantity of coins available at a certain address on a certain date. Bitcoin, for example, has dozens of publicly available block explorers.
We have seen certain auditors using these to obtain audit evidence. Unfortunately, and unbeknownst to many, block explorers may disagree with each other and can impact the audit’s results.
Sometimes, these disagreements are rooted in undisclosed interpretations of a gray area. Sometimes, these disagreements are due to bugs in the explorer’s code. In both cases, the credibility of these block explorers is undermined. Furthermore, we are unaware of any block explorers assuring their stakeholders that adequate and sufficient controls exist around their development and operation. In these cases, how can we rely on the completeness and accuracy of the information being provided?
While building our own practices for reading blockchains directly, we routinely compare our results to third parties. When we find discrepancies, we dive deeply, looking for the source. Continuing with Bitcoin as example, here are two recent issues:
- The same wallet in Bitcoin can be represented as an address or a public key. Some block explorers will automatically sum their balances together on the premise that they are necessarily controlled by the same entity. Other block explorers, for various reasons, will keep these distinct.
- Bitcoin can be locked by a spending script. That script can require two (or more) public keys to produce signatures to unlock the script and send the enclosed bitcoin. For many years now, this technique has been replaced with a more efficient mechanism. However, some block explorers appear to have forgotten this earlier strategy. They wrongly attribute funds to the first or both addresses, rather than to a dually controlled address. This oversight can lead to unfortunate results. An inexperienced auditor using an impacted explorer might actually count too many or too few bitcoins in a given entity’s name. A malicious entity could use this to report ownership of fictitious coins.
So that you, the reader, can try this for yourself, we’ve provided a real address (1MbCDrD8fkqXr4M2HXYuyzLfYGEN4evUer, the “Address”) with its balance and number of transactions, as seen by six block explorers:
|Block Explorer 1
|Block Explorer 2
|Block Explorer 3
|Block Explorer 4
|Block Explorer 5
|Block Explorer 6
What is the correct answer? The entity should be reporting 0.0005 BTC, being both the bitcoins controlled by this address and the funds paid to the matching unhashed public key (0243c17584f2a00d7c22429e1444e2a94cae0a657b9a58ee6a87c33ef7bca97245, the “Key”).
What is causing the block explorers to present a different version of the Bitcoin truth? A real-world equivalent would be inspecting the contents of Safe A, and finding the key to another Safe B. Let’s say Safe A has $0 in it, but Safe B has $50. It is literally correct to say that Safe A has $0 in it, but it disregards the content of Safe B. A more holistic response is to report the “total” content of Safe A as being $50.
So, what does it mean for the block explorers mentioned above? Block Explorers #1 and #2 are missing the funds sent to the Key (i.e., they only consider the Address). They are returning a “literal” answer. In this case, Block Explorers #5 and #6 report the correct answer, but for some technical reasons the sleuthing they perform must be limited (i.e., they can never guarantee completeness). Furthermore, there is often no documentation explaining how this sleuthing is done and if it’s done consistently.
Block Explorers #3 and #4 are simply incorrect. They make the gross error of adjusting the balance on the Address when the Key shows up in an old multi-signature script, as described in the second issue above.
With three perspectives in direct conflict, it should be clear that the use of these untested public tools is both insufficient and highly risky for audit purposes. These tools need to be both properly interpreted and vetted.
Blockchain expertise is needed when conducting the audit engagement of an entity with digital assets. This expertise is essential when not only interpreting data, but in evaluating the reliability of data as audit evidence. Only then can auditors navigate these complex systems. At Catallaxy, we can help you with that!