Accounting Duality of Blockchain Part 2: Addresses and Balances

Accounting on/around the blockchain is both SIMPLE and DIFFICULT.

In the earlier article I wrote about the fact that blockchains’ decentralized nature is achieved with data duplication. One consequence of duplication is that the accounting on the blockchain is somewhat more difficult than you might expect about data like chain blocks which are stored in a simple-ish ledger format by default.

In this post I will cover accounting challenges around blockchain addresses as they relate to ownership (control) over assets across a growing “jungle” of blockchains and their connections.

Multi-Chain Explorer for CPAs and Auditors

The punch line of this article is that ProtocolScout is a new blockchain explorer for multiple protocols designed specifically for use by CPAs and auditors. Its features originate from the core characteristics common to most popular protocols, including Ethereum, its “siblings” like Fantom and its “descendants” like Polygon, Optimism, Base, Arbitrum etc.

Background

In all permissionless networks like Bitcoin, Ethereum etc. users “create” themselves by picking a random sequence of 256 bits to be their private key. After some processing and formatting, a private key is transformed into an address known as a “wallet” which serves the role of the user ‘s (account) ID. Many protocols follow the exact same steps — let’s write that a private key “010….” generates a public id/wallet/address 0xA… which can be used on both Ethereum and on Fantom. It turns out that this 0xA could be used on Ethereum only, on Fantom only or on both. In either of these 3 cases, the private key for 0xA is the same (secret) private key “010….” . Therefore its tax/audit subject is the same individual or business entity. Likewise, the full accounting/audit of 0xA must ensure that all its assets are taken into consideration.

An ID/Wallet/Address Can Exist on Many Blockchains

Since each blockchain is a network of servers “speaking” to each other only about their own protocol and because a address/wallet/user can exist on multiple networks, doing the full accounting for an entity (owner of the underlying private key) means to query many protocols for data about the given address. Just off the top of my keyboard, we have these blockchain “siblings” as separate networks: Ethereum, Fantom, Celo, Cronos, BSC, Avalanche, Klaytn, Canto, Gnosis Chain, Harmony etc. The teams building these protocols made deliberate decisions to share characteristics (aka EVM compatibility). Unfortunately, it does not appear they had much consideration for accounting across the commonalities of their separate projects. I can not blame them too much since their networks are distinctly separate and the nodes don’t “know” about another protocol but their own. However, another group of protocols are more closely related and even “communicate” with each other. This 2nd relationship “type” is referred to as L2s and exists 1-to-1 between Ethereum (L1) on one side and many L2s (list) such as Polygon, Arbitrum, Optimism, Base, zkSync, Mantle, Linea, Starknet, zkEVM etc. In short, it means that Base and others depend on Ethereum, and each L2 collective of nodes also communicates with Ethereum’s collective of nodes. These networks also share addresses and are able to transfer amounts across their “bridges’’ such as Ethereum<>Arbitrum or Ethereum<>Optimism. It is possible for our address 0xA to have 5 ETH on Ethereum today and then to transfer 3 ETH to Optimism. At this point, accounting for 0xA requires polling the Ethereum network to get the “2” and also polling Optimism to get the “3” for a total of 5 ETH. But there is no native protocol method for Ethereum nor Optimism which could be used to get the full 5 at once, after it became split. Since the protocol designers did not enable such aggregate views across their connected protocols, accounting risks incomplete amounts if we forget to look everywhere (for everything).

Don’t get me wrong — I am not writing that the devs working on these protocols are picking specifically on accountants to make your life difficult. Likewise they are not doing anything for or against the United Nations nor the Olympics. Instead, the devs are simply focused on their own in-group, just like the rest of us. But, their goal is to rebuild the entire economic system, and accounting is its core service yet the devs do not appear to be building much specifically to facilitate efficient accounting.

Blockchain Explorers vs. ProtocolScout

Explorers are often public apps / websites for visitors to query, search and browse data flowing into the ledgers which make up the given blockchain network. A popular explorer for Ethereum is Etherscan.com and most active protocols have the benefit of multiple explorers with similar features. These explorers are often dedicated to a single protocol and are customized to all the specifics of that protocol.

To check the balances for all the protocols that share keys/addresses, you would have to visit that many sites which might be 40+ in the EVM/L2 group of protocols alone.

Or, you can just use ProtocolScout.com to check balances on all those protocols in parallel and based on the address format alone. We have set up default groups of protocols which could possibly share addresses and poll their nodes automatically for every address you might query.

Essentially, ProtocolScout replaces all of the 54 single-chain explorers below for most common accounting inquiries: balances, total supply of assets and transactions