Introduction to Crypto-Accounting: An Analysis of Decred as an Accounting System

By Permabull Nino - Aug 1, 2019

Those who are close to me know very well that I have fallen deep down the crypto-accounting rabbit hole. This dive into the crypto-accounting deep end is far from a finished mission but has reached a level of completion that merits discussion on certain to-date findings. You now may be wondering — what is crypto-accounting? Simply stated:

Crypto-Accounting is the application of widely accepted and well understood accounting + audit principles into evaluating, deploying, and using cryptocurrency-based, public assurance networks.

It certainly is the dawn of a new age, as we now have access to distributed accounting systems that can provide us with absolute assurance over ledger data. Absolute assurance is a concept that is relatively easy to understand — ledger data past a certain block history can be completely relied upon. This new era of accounting and the exciting prospect of automated, high-reliability accounting brings a few interesting questions to the forefront:

How do we evaluate crypto-accounting models?

Which crypto-accounting models exist?

Which are the best coins to evaluate within an accounting model?

These questions will be the focus of this article, as we will aim to introduce accounting considerations relevant to any accounting system, their equivalents in crypto-accounting systems, and how well certain crypto-accounting models are able to satisfy these requirements. The section-by-section breakdown will go as follows:

Considerations relevant to crypto-accounting + What these considerations look like in crypto-accounting systems

How Proof of Work cryptocurrencies satisfy these requirements

How Proof of Stake cryptocurrencies measure up

How Decred satisfies these requirements

Key Takeaways

CONSIDERATIONS RELEVANT TO CRYPTO-ACCOUNTING + WHAT THESE CONSIDERATIONS LOOK LIKE IN CRYPTO-ACCOUNTING SYSTEMS

Accounting and any sort of education over accounting theory feels like eating vegetables for some, so I apologize in advance for those who hate this section. However, readers will be unable to fully appreciate and digest the information presented in later sections without setting the stage appropriately. The accounting concepts we will discuss *as concisely as possible* include:

Below we will explain the concepts in this table as they apply to traditional accounting systems, and venture off into how these concepts find their parallels in the crypto-accounting universe.

ACCOUNTING SYSTEM PILLARS

There are 3 core pillars to building accounting systems: (1) Transparency, (2) Redundancy, and (3) Tamper Resistance. These pillars have been prevalent in accounting for thousands of years and to this day remain present in traditional double-entry accounting systems. Every accounting consideration that follows in this article manifests itself somewhere within these 3 pillars. As such, these pillars should be viewed as the most general framework through which we can evaluate any accounting system.

Transparency

Transparency →Accountability

Transparency is core to any accounting system because it allows stakeholders within the system to hold each other accountable. Without transparency, we have no means to verify assertions that others make and thus forgo truth in exchange for “trust”. An accounting system’s ability to grant users a means for verification is mission critical to its longevity as this trait alone gives users confidence that recourse and an audit trail will be available in the case of errors, fraud or dispute.

Traditional Accounting Example: Publicly traded stocks, and their public release of quarterly / annually reviewed and audited financial statements.

Crypto-Accounting Equivalent: In public blockchains such as Bitcoin, the complete transactional history is available to audit for all users. This feature allows users to verify their own transactions, audit the outstanding supply of coins, etc.

Redundancy

Redundancy →Error and Fraud Prevention / Detection

Redundancy within any value-recording system serves as a safety net by catching mishaps before they cause problems, or by identifying what went wrong postmortem. Redundancy is notoriously painful, boring, inefficient, and expensive — just ask auditors and the accounting personnel that must deal with them. However, these aches and pains provide us with something incredibly valuable: accounting data that has gone through rigorous, systematic review, and as such can be relied upon more heavily.

Traditional Accounting Example: Internal controls help prevent fraud / errors, and auditors aid in identifying fraud / errors after.

Crypto-Accounting Equivalent: All full nodes provide redundancy by storing ledger data w/ consensus network rules to prevent + detect errors / fraud, and distribution of mining / staking nodes provides redundancy for applying those rules into the block creation + authorization process.

Tamper Resistance

Tamper Resistance →Dependability

Redundancy and Tamper Resistance have a great deal of overlap and certainly go hand in hand, as Redundancy serves as one part of deterring bad actors from exploiting / fudging a transactional history. What’s important to note though, is that not all tamper prevention revolves around redundancy — just proper system design. Tamper Resistance gives users confidence that Transparency + Redundancy are not implemented in vain, and that the transactional history remains true to economic reality.

Traditional Accounting Example: Accounting software that rejects entries where debits and credits do not balance, rejects entries that are signed off by inappropriate personnel, or rejects entries with metadata that is nonsensical. Also — another thing that keeps these systems resistant to tampering are the incentives implicitly baked into the system, as fraud may be cheap up front but could become expensive via penalties and reputational risk.

Crypto-Accounting Equivalent: Tampering with the ledger needs to be expensive and difficult, and this costliness is enforced via the block creation process. Network rules also enforce tamper proofing, as certain transactions are invalid under all circumstances.

Our goal is to create accounting systems that we can depend on, which is accomplished through building frameworks and processes designed to prevent errors / fraud reliably. In the case that that something goes wrong within the system, we want to be able to detect the issue(s) so that we can remedy the situation + hold relevant stakeholders accountable.

FINANCIAL STATEMENT (F/S) ASSERTIONS

Financial statement assertions are:

The explicit or implicit assertions made by a company regarding the fundamental accuracy of information contained in its financial statements…When a company’s financial statements are audited, the principal element an auditor reviews is the reliability of the financial statement assertions.

Now, there are 5 different F/S assertions company management + auditors alike take into consideration when evaluating financial / accounting data:

Existence: do assets / liabilities presented exist?

Completeness: is data missing / not presented that should be?

Accuracy: is data valued correctly? or is there nuance in valuing the assets / liabilities in question (i.e. cash’s straightforward valuation vs difficulties found in accurately valuing intangible assets)

Presentation + Disclosure: is data presented correctly?

Rights + Obligations: are assets / liabilities appropriately categorized?

There’s a lot to unpack here, so let’s break this down into terms that most would understand. Publicly issued financial statements are constructed with internally compiled + externally verified accounting data. The goal of management + the auditors is to ensure the accounting data used to build these financial statements is accurate prior to the financial statement issuance date, which is accomplished via gaining assurance over the various assertions. More simply put:

Goal →Publish financial statements that reflect reality

How to Accomplish Goal →Ensure accounting data is accurate at the conclusion of the financial statement audit

More specifically →Gain assurance over various F/S assertions

What does this have to do with crypto-accounting networks and their respective blockchains? Plenty. The aim of crypto-accounting networks is to publish a transactional history that is 100% accurate. This aim is satisfied by ensuring data included in blocks is accurate in real-time, and assurance over this data is gained through meeting the requirements of the relevant F/S assertions, (1) Existence and (2) Completeness. In summary:

Goal →Publish an accurate transactional history

How to Accomplish Goal →Ensure data included in blocks is accurate in real time

More specifically →Gain assurance over data Existence and Completeness assertions

Prior to exploring the Existence and Completeness assertions in more detail, I would like to make note of the remaining assertions that will be excluded for purposes of our discussion. There’s a singular reason for their exclusion, and it’s not worth spending too much time on it. However, the gist is this: these remaining assertions are less operational in nature and more focused on cosmetic considerations related to accounting data. In traditional accounting the Existence and Completeness considerations are prioritized higher, and the same treatment goes for crypto-accounting networks. Furthermore — these crypto-accounting networks have automated + set standards for Accuracy (valuation is cryptocurrency within the network — no weird valuation issues such as intangible assets on a company’s balance sheet), Presentation + Disclosure (blocks are uniform from a presentation standpoint, with a block header + transactions), and Rights + Obligations (owner = private key holder). Now — without further delay, we are now ready to discuss both the traditional accounting approach and the crypto-accounting approach to existence and completeness.

Existence

Traditional Accounting Example: If you want to gain assurance over the existence of an asset / liability in traditional accounting systems, you need to vouch to the source documentation that accompanies such items. In the case of inventory, you could literally go to the warehouse to find the inventory item in question (auditors do this all the time, and I can tell you from experience — doing inventory counts are the worst thing ever). In the case of sales, you could go review the third-party documentation for proof that a sale was made. These tests help provide confidence that transactions are not being fabricated and that the accounting records support real economic activity.

Crypto-Accounting Equivalent: Existence comes into play in 2 different forms in crypto-accounting networks — via (1) the blockchain being able to account for every single coin in existence and (2) the ability for users to prove ownership over any claimed coin.

(1) Account for Every Single Coin in Existence: The most important question for blockchains is whether they are adequately tracking the genesis (coinbase) and flow of coins between holders over time. By making sure that every coin is minted / produced / issued within consensus rules and subsequently transferred legitimately we can get comfortable with the assertion that the coins “exist”. Examples of failures in this regard would be in the case of exploited inflation bugs, which are particularly difficult to identify + remedy in default-private crypto-accounting networks.

Traditional: Vouch from the ledger to the source documentation

Crypto: Vouch from the current address to the coinbase transaction

(2) Ability to Prove Coin Ownership: Point #1 allows for users to prove ownership of coins claimed. For example, if an exchange claims to hold XX amount of coins, they can prove ownership (i.e. they have the coins they claim exist in their reserves) by signing a transaction with the coins in the address they’re purporting to control on the public ledger. The most similar exercise in the traditional accounting world is requesting a bank confirmation to verify existence of cash balances (the most similar asset to a cryptocurrency).

Overall, crypto-accounting networks and their ability to fulfill the existence assertion is astoundingly strong. The public nature of these ledgers, enabled by asymmetric cryptography, allows for full verification of a coin’s transactional history and any user to prove ownership over any user’s assets within the ledger.

Completeness

Traditional Accounting Example: Completeness is the concern that relevant data is being excluded from the financial statements / accounting ledger. Generally, liabilities are the types of things that one would exclude from financial data. Why? Because liabilities *in some cases* are not good! A good example of this is potential lawsuits against a company during a financial reporting period. Auditors gain assurance over the potential that the company is neglecting to report pending lawsuits by reaching out to their contracted law firms. Being able to check in with third-party verifiers / external sources is always a good way to satisfy completeness concerns.

Crypto-Accounting Equivalent: Completeness is an interesting issue in crypto, especially when compared to Existence related issues. Existence issues are exploited with code related issues i.e. buggy code, whereas Completeness issues are exploited through brute force. Which begs the question — what kind of data is being withheld from a crypto-ledger? Secretively mined blocks. For those who aren’t familiar with this — malicious miners / stakers can build a chain in secret, and when it is longer / has more accumulated work than the current public + consensus chain, the secret chain can be presented to overtake the benevolent chain in what is popularly known as a 51% or majority attack. Unfortunately, most crypto-accounting networks do not have a solution to this problem, whereas the Existence issues are largely already solved as a result of the transparency these crypto-ledgers have. We will discuss these in more detail and how they’re addressed within the different crypto-accounting schemes later on.

SEGREGATION OF DUTIES (SOD)

This is arguably my favorite part of analyzing accounting systems (particularly crypto-accounting). However before getting ahead of ourselves, I will explain what SOD is and what it has to do with accounting in the traditional sense. For starters, the three duties are as follows:

Custody: Control over company assets

Authorization: Right to move / transact with those assets

Recording: Responsibility for recording transactions including assets in question

It’s important to understand that these 3 duties need to be performed / dominated by 3 different groups of people, or at a minimum, no single group should be *completely* in control of more than 1 of the duties.

You may now be wondering why this is the case — which is very fair, and best explored through example. Let’s imagine Company Satoshi, a seller of BTC Merchandise, receives all sales in bitcoins, which are stored on the company Trezor that uses Casa 2 of 3 multisig to move coins. Now, the segregation of duties for the bitcoins go as follows:

Custody: Trezor sits in Bob’s office under his protection

Authorization: Moving bitcoin requires Bob and Alice’s signatures

Recording: Carla records inbound and outbound transactions from the Trezor in the company books

This is a well-designed segregation of duties system as you can see. Bob can’t move coins without Alice’s approval, and Alice can’t get control of the bitcoins without taking them from Bob and getting Bob’s signature. Carla can record whatever she wants in the books, but that will do very little as her records will not agree with the balances and transactional history in the Trezor (because she can’t get ahold of the bitcoins, nor is authorized to even move them). As you can now see, each person is checked by someone else, which ultimately leaves little room for abuse by any single party.

The fun now begins here — time to talk about what SOD looks like in crypto-accounting networks. A breakdown of the 3 duties are listed below:

Custody: Block creation via discovering hash below difficulty target

Authorization: Right to add block to the blockchain, depends on validity of block data and valid signature to add block (in most systems just the same hash used to create the block)

Recording: Storing blockchain

The sad truth is that 99.9% of crypto-accounting networks do not have a proper segregation of duties design. Their ability / inability to work around this design flaw will be discussed later on, but for now I want to explain why the SOD framework isn’t satisfied by the standard crypto-accounting scheme:

A hash below the difficulty target not only grants the right to block creation (custody), but it also provides authorization for the creator’s block to get added to the blockchain. Full nodes (those in charge of recording) have no means to check on these block creators/authorizers and as such are forced to accept whatever blocks are broadcast to them.

As a result, the duties are dominated by / segregated as follows:

Custody: Block creators

Authorization: Block creators

Recording: Full nodes

Block creators are miners in PoW coins and stakers in PoS coins. Just as we mentioned beforehand — we will go into further detail on the nuances of this system design flaw in each system in later sections. However, if you’re going to take anything away from this section it should be that the block hash serves as both the right to custody + authorize blocks, and that there are some issues that come with this design.

RELIABLE RANDOMNESS

Randomness is key to third party verification of accounting records. In my experience it’s quite understated and discussed sparingly, but it’s prevalent in audit procedures at multiple levels. A few examples include:

Random sampling:

Auditors use random sampling to ensure that they don’t incorporate bias into their sample selections. Random number generators are used to accomplish this.

Auditors also use random sampling so that the client cannot predict what items will be selected for testing.

Materiality:

Definition: The threshold above which missing or incorrect information in financial statements is considered to have an impact on the decision making of users.

Auditors make it a gigantic point to not disclose materiality thresholds to their clients, because if they know the threshold, bad actors can plan on burying transactions / balances below the threshold by breaking them up.

Randomness is a tool for spreading honest behavior — in the face of unpredictable outcomes people are inclined to play fair, as they have no edge for cheating. This same rationale applies to crypto-accounting networks as well, as randomness keeps crypto-accounting stakeholders honest:

Block Discovery:

Blocks are discovered in these networks by finding a block hash below the network difficulty target. This hash should only be able to be discovered via brute force as enforced by randomness.

Finding Collisions:

The beauty of public/private key cryptography is that nobody can derive your private key from your public key without inputting an outrageously large amount of effort. This large effort is a function of the fact that the asymmetric nature of the cryptography imposes a large randomness factor into discovery of a collision (i.e. deriving private key from public key).

Generally stated, asymmetric cryptography at its core simply provides randomness + unpredictability in a domain where it previously didn’t exist — public accounting ledgers. This seemingly expanding universe of randomness demands brute force to “cheat”, which really isn’t cheating in substance. Application of hard work and brute force to reach a certain outcome is behavior we reward in nature + society quite regularly, and it’s important that we apply similar principles to the systems we rely on for recording our transactional histories. If somebody wants to beat these crypto-accounting systems, let’s make sure they earn it.

TAMPER RESISTANCE OUTSIDE / WITHIN CONSENSUS RULES

Tamper resistance plays a role outside the consensus ruleset of crypto-accounting networks and within, so we need to briefly map the connection between them and the traditional equivalents. Here are the tamper resistance considerations from the traditional accounting viewpoint:

Outside Consensus: “Consensus rules” are inviolable accounting-based truths. Attempts to break the rules (i.e. stepping outside of consensus) are always rejected. A good example of this is debits and credits should always balance — under no circumstance should an accounting system allow this to happen.

Within Consensus: Any sort of circumstance that falls within the rules (i.e. valid under the general rules established by consensus) has the potential for abuse by actors who are looking to “act within the rules of the law, but not the spirit of the law”. In accounting / audit, it is well known and understood that professional judgement should be exercised under these circumstances - which includes examples like evaluating an asset for impairment, valuing intangible assets, or any other case where estimation might be involved for coming up with an asset / liability balance. A bad actor or any other stakeholder who has an incentive to provide an incomplete or inaccurate version of economic reality can leverage these cases to make the financial statements look better / worse, whichever is more to their benefit. For these situations, it’s generally helpful to have third parties providing evidence / support showing why the final figures in this grey area in accounting treatment is justified.

The ideal accounting system will be able to accommodate for tamper prevention outside of consensus rules (broad) and within consensus rules (specific). If we can capture both, we will have a greater degree of precision in value recording by being able to zoom in closer on relevant issues.

The tamper resistance considerations for crypto-accounting are listed below:

Outside Consensus: An example of an inviolable truth within crypto-accounting networks is that outputs < inputs, or the coinbase reward per block is agreed upon and enforced by network rules.

Within Consensus: Mining empty blocks is probably the most obvious example of this — most crypto-accounting schemes do not have a means to capture this level of precision for review in this grey area, and for this reason maliciously mined empty blocks get added to blockchains on occasion.

This concludes our introduction to crypto-accounting. In the following sections we will lean into our analysis now that we’ve covered the basics. Before moving on, feel free review this table that summarizes our discussion so far:

ANALYSIS: PROOF OF WORK

For the remaining sections we will show a table which summarizes our analysis, and then engage in our analysis afterwards to provide more detail of the conclusions reached in the table. Proof of Work and its ability to satisfy accounting considerations are below:

These analysis sections will be constructed in a more free-flowing / discussion type format. However, just as a general framework — we will focus on where these accounting schemes are flawed, or particularly flex their ability to incorporate well-understood accounting theory into creating a more secure system for accounting.

Proof of Work systems’ SOD and Completeness go hand in hand. In PoW, the miners find a hash below the difficulty target, and that hash serves as the (1) right to custody / create a block and (2) add that block to the blockchain. We didn’t fully hit on this in the earlier section, but shortcomings in SOD play out in different ways. The different combinations of lacking SOD design can vary in the following ways:

One party dominates Custody and Authorization

One party dominates Custody and Recording

One party dominates Authorization and Recording

What’s particularly of importance for our discussion is the first of the three, one party dominating Custody and Authorization. The comingling of these two duties under a single party naturally leads to data completeness issues. How? Easy — the party can move the assets around without anybody’s permission (because they can authorize the movement themselves), and they can choose to not disclose the movement of those assets to the party in control of the Recording function. PoW systems have this same issue, with the asset in custody being blocks of transactions that they’re authorized to use to build a blockchain in secret — unbeknownst to other full nodes on the network. However, this does not make PoW systems unreliable, as this secretive mining / data incompleteness doesn’t come cheaply as a result of the brute force that needs to be put in on the front end of the process (discovering hashes below the network difficulty target). In this regard PoW systems are flawed, but they are most certainly good enough at reliably accounting for value by making it expensive to cheat / keep certain data hidden from other network stakeholders.

Segregation of duties isn’t an issue that is limited to data completeness — it also has an impact on activity that goes on publicly. Since miners have the right to authorize their own blocks (if they’re constructed within consensus rules), they can add blocks to the blockchain that should not be there — such as empty blocks. To date this problem hasn’t proven to be that big of a deal, especially as transaction fees become more important over time to compensate miners. Nonetheless it is worthwhile noting, as having a cheap check on expensive, malicious behavior is something that could benefit any system, not just accounting systems.

Overall, PoW accounting systems are reliable vessels (under the correct implementation + resource commitment) for delivering absolute assurance. However — they do suffer from SOD issues that result in data completeness + checks on public, malicious behavior from network stakeholders.

ANALYSIS: PROOF OF STAKE

Proof of Stake and its ability to satisfy accounting considerations are below:

Just like Proof of Work, Proof of Stake accounting suffers from SOD + data completeness issues, which results in an ability to secretively create blocks for any overly-selfish / malicious party. Further, this malicious block creation goes unchecked by incentives, as these blocks can be created at little to no cost for the party in question. This absence of upfront cost can bleed into the public, as even within Proof of Work accounting there are occasions where 2 chains exist, and are known by network stakeholders. However, with Proof of Stake there is an obvious incentive to build on both public chains as they can collect rewards from both chains with no associated costs, which is an issue in a system where reaching the consensus chain is the most important goal. With this in mind, PoS accounting fails arguably the most important Accounting System Pillar, Tamper Resistance.

Another relevant issue to PoS systems is the source of randomness used for validation. Please recall that in Proof of Work, brute force is required to find a hash below the network required difficulty target. This “brute force” is input via electricity, and the winner of the brute force competition is just whoever *randomly* happens to find a hash that meets requirements faster than everyone else. Proof of Work is able to implement brute force i.e. randomness because it has an external source (electricity) to work its way through the randomness enforced by the PoW algorithm. PoS does not have this external plug, and therefore is incapable of fully enforcing randomness in the same manner that PoW reliably does. As such, PoS systems generally leverage deterministic means for block creation, which by definition do not fully enforce randomness. PoS systems are considered to not possess the type of randomness we as crypto-accountants like to see in our high-reliability accounting systems.

Proponents of PoS accounting schemes *generally* tout them as outright improvements on the notoriously “wasteful” PoW scheme. They argue that PoS systems are cheaper for validation, and burn through less resources in order to achieve the same end result that PoW systems aim for. However, as we concisely discussed in this section — these design choices are not ideal for building accounting systems, as cheap + convenient is obtained at the cost of high-reliability record keeping by sacrificing the disincentives that deter tampering and the randomness to keep all stakeholders honest.

ANALYSIS: DECRED’S HYBRID PROOF OF WORK + PROOF OF STAKE

Decred’s Hybrid Proof of Work + Proof of Stake and its ability to satisfy accounting considerations are below:

In this section we’re going to discuss what makes Decred’s hybrid accounting model the ultimate accounting scheme in the crypto space.

At the core of Decred’s genius is its implementation of PoS on top of PoW. This additional layer of validation allows the hash below the difficulty target to serve a single role instead of the two (Custody + Authorization) that it needs to fill in the standalone PoW model. By doing this, we finally have a proper breakup of the 3 duties in the SOD:

Custody: PoW Miners

Authorization: PoS Stakers

Recording: ALL fully validating nodes

Appropriate design and assignment of duties solves our problems surrounding (1) completeness and (2) tamper resistance within consensus rules in one go of it. How? For starters, let’s explain how blocks get added to the Decred blockchain, leveraging some language from Richard Red’s article “The role of Decred voters in defending against majority attacks”:

Miners find hash below difficulty target, and a new block is created

New blocks cannot be built upon until they incorporate the votes of at least 3 of the 5 tickets selected, with the selection of tickets being random and based on the previous block

As a miner, the only way to collect those votes and start working on the next block is to show your block to the rest of the network

As you can now see — blocks created by PoW miners cannot be built upon without authorization from PoS stakers. This dependency that miners have on stakers keeps miners honest, as they no longer have the freedom to do what they please with their blocks, such as building a competing Decred chain in private (completeness issues = solved). Furthermore, this prerequisite to have PoS authorization allows Decred to have protection from tampering WITHIN consensus rules, which gives network stakeholders full protection from both private and public accounting considerations. All of this is accomplished without sacrificing randomness, as the PoS tickets are selected to vote as a function of the previous block’s hash (which as we recall is discovered randomly, via trial and error). And for the cherry on top — this PoS system maintains competitive / meritocratic standards by retargeting the PoS ticket price every 144 blocks, which represents a stake-based equivalent to what we see in mining difficulty adjustments in PoW.

KEY TAKEAWAYS

Within this article we (1) introduced the concept / field of crypto-accounting, (2) drew parallels between traditional accounting concepts and crypto-accounting networks, and (3) performed an analysis on PoW accounting, Decred’s accounting scheme, and PoS accounting. The results of our analysis are summarized as follows:

Decred’s accounting scheme (hybrid PoW+PoS) covers accounting considerations across the board better than all other cryptocurrencies, with pure PoW coming in second

PoW is the backbone of these systems, as it provides the foundation of Redundancy, Tamper Resistance, and Randomness

Pure PoW validation covers the accounting assertions well, but lacks a little bit in the Completeness department as a result of the hash below difficulty target serving as both the Custodial + Authorization roles within the SOD framework

Pure PoS schemes have the same completeness / SOD issues as PoW, but lack the upfront costs for keeping selfish block creators honest, which make them substantially less reliable (or dependent on more complex means to enforce honest behavior)

These takeaways are best summarized in tables, as presented below:

Now before letting you go — here is a big picture view of what this article + other articles I’ve written in the past have been working towards:

Signing out,

Permabull Nino

Huge thank you to Oke Pearson for his thorough review of all accounting / audit theory included within, and to Richard Red for his detailed review. Big thanks as well to Jake Yocom-Piatt, Max Bronstein & Murad Mahmudov.