Although accounting might seem like a wheezing institution, it’s filled with landmines and horcruxes in the convoluted world of Proof of Stake (PoS) blockchains. This topic may seem niche, but as PoS chains become widely adopted, these issues will only become more difficult to solve as the problems scale. In most industries, accounting is fleshed out and snooze-worthy, but in the PoS ecosystem regulations have yet to be penned and auditors are just learning fundamental vocabulary, like what the word “validator” means. It’s a fascinating time to be thinking about revenue recognition on Avalanche’s P-chain or the tax implications of an ERC-20 token bonus. While most days I’m thoroughly bamboozled by the numbers, the moments of clarity (so that’s how rewards on Cosmos work!) are priceless.
The goal of this article is to lay out the most pressing and interesting issues I’ve come across as a financial analyst and CPA for Figment, an industry-leading staking provider. Figment runs validators on over 40+ PoS blockchains ranging from Ethereum 2.0 and Polkadot to more esotic chains like Chihuahua chain and Kava. No one chain is alike, which means applying blanket accounting policies and estimates isn’t possible – if anything, being an analyst for Figment is more akin to a researcher or forensic accountant. This piece assumes the reader has foundational knowledge on blockchains and the PoS consensus mechanism (if you’re a little rusty, I recommend this article by Decrypt and this video by Figment Learn).
Staking Revenue Recognition
The biggest complication is how and when to recognize staking rewards earned by the validator, either staking rewards earned from self-stake or commissions from delegators(1). Generally, there are two different types of chains: those with rewards that need to be manually claimed (i.e. Cosmos ecosystem, FLOW, DOT) and those with automatic re-staking of rewards (i.e. NEAR, VEGA, MINA). In the former, rewards are accrued to the validator beneficiary account(2) and have to be manually claimed by the private key holder. Once claimed, these rewards are liquid/transferrable and can be re-staked to an active validator. In the latter case, rewards are continuously earned and added to the staked balance.
The nuance here is the difference between when rewards are earned and when they digitally land in your wallet. For networks with manual claiming, there’s often a significant delay in the two events. The validator (assuming it’s behaving) is constantly earning rewards every block, epoch, slot, etc but they’re accruing in some nebulous protocol account, what I call the staking rewards purgatory. Claiming could be put off indefinitely, leading to earnings manipulation if a company needed an extra hit of OSMO one month.
Unfortunately, no clear guidance exists for this dilemma. The closest I’ve seen is what Coinbase reported in their Q3 2021 10-Q (Coinbase acquired Bison Trails, another staking provider, in January 2021):
“Blockchain rewards are primarily comprised of Staking revenue in which the Company participates in networks with proof-of-stake consensus algorithms, through creating or validating blocks on the network. In exchange for participating in the consensus mechanism of these networks, the Company earns rewards in the form of the native token of the network. Each block creation or validation is a performance obligation. Revenue is recognized at the point when the block creation or validation is complete and the rewards are transferred into a digital wallet that the Company controls. Revenue is measured based on the number of tokens received and the fair value of the token at contract inception.”
The “and” in the second to last sentence is the head-scratcher here. Coinbase is recognizing revenue when tokens are in their possession, regardless of when the work is performed by the validator. This raises an interesting question – what performance obligations does a validator have? What contract does our staking revenue relate to? I’m referring to the 5 steps to revenue recognition, obviously the sexiest topic in financial accounting and reporting. ICYMI, the 5 Steps under US GAAP are:
- Identify the Contract
- Identify Performance Obligations
- Determine the Transaction Price
- Allocate the Transaction Price
- Recognize Revenue
There is no clear guidance for validators yet, but one view is that the contract is created when a delegator points their stake to the validator – in other words, the contract is baked into the protocol rules (aka code). Per the protocol rules, the validator has an obligation to propose and vote on valid blocks which are added to the canonical chain. The transaction price would be the commission fee the validator charges (which typically ranges from 5% to 15%), and allocation doesn’t apply since the validator is only exchanging one broad service for the fee.
Per this analysis, it seems like revenue recognition should be a walk in the park – it’s all on-chain, right? But given that blockchains are just dumb databases, it quickly becomes overwhelming as rewards are earned every second, minute, hour, day, or week depending on the chain you’re accounting for(3). Crypto accounting software has definitely not caught up to the pace the 5 Steps demand, which is why rewards are typically calculated and booked at the end of the month. This affects the cost basis involved, which bleeds into your trading gains and losses and alters your tax liability. As you can see, the current methods are full of imperfections but it’s also exhilarating knowing that your work is setting a precedent for future blockchain accounting standards.
I could go on about revenue recognition for several Solana epochs(4), but I’ll save that soap box for another article – which brings me to another relevant topic in PoS accounting.
Audit Worthy Data
As I alluded to earlier, blockchains are not the data panacea they’re made out to be. The transaction history might be ensconced within bare metal servers but actually extracting that data in a useful and auditable format is a nightmare. In an ideal world, there would be a database that can be queried which has a unit of time associated with a reward (i.e. on 5/10/2021, address 0x…6q1sX earned 15 LPT tokens). The database would be wrapped within layers of internal controls and best practices, also called a SOC (Service Organization Controls) report. Having this report is something auditors drool over because it allows them to trust third-party data providers and limit the amount of substantive testing needed during the audit. Instead, they can lean on an intricate web of IT general controls and sign off on the data generated in the database.
There are two types of snafus in the Proof of Stake world:
- Few data providers have a SOC report, and
- Reliable databases that have these “point in time” chain balances are sparse. The technical term for this giant database is an indexer, which is a piece of software that “walks the chain” and calculates a wallet balance by adding up each individual transaction. An example is:
1/1/2021 – Starting balance: 100 ATOM
3/02/2021 – Sent 50 ATOM to cosmos…Nmq2. New balance: 50 ATOM
3/31/2021 – Claimed 150.67 ATOM in staking rewards. New balance: 200.67 ATOM
As you can see, this process is laborious and computationally intense – and blockchains don’t hand you nicely packaged code. Teams have to write the code themselves and intimately understand the chain in order to index it. Because of this complexity, indexers are prone to breaking and can’t be relied upon for critical month-end numbers. The Graph protocol aims to solve this issue for Ethereum-based chains (and a handful of non-ETH ones), but they’re in a never-ending game of catchup. As soon as they can support a chain like Solana or NEAR, five more non-ETH PoS chains pop up, each with their own idiosyncrasies.
You might be wondering how accounting teams at PoS companies calculate revenue if the data is buggy or unavailable. Data collection is still in a primitive state but we can usually arrive at a semi-correct answer through block explorers. These explorers are like mini Google webpages that let you search the transactions and addresses on a particular chain – good examples are Etherscan for Ethereum chains and Mintscan for all the Comos-based networks. Similar to Google, you can type in a wallet address (try searching cosmos1hjct6q7npsspsg3dgvzk3sdf89spmlpfg8wwf7 here) and information such as current balance, rewards claiming history, sent transactions and staked balances will appear. Block explorers interface with the actual chain, and at month end, I typically check ~50 different block explorer pages to piece together our revenue.
While I mostly trust the explorer data, this setup isn’t ideal. The developer teams building these protocols do not have SOC reports and so auditors view the information as risky and unreliable (for good reason). The same applies to pricing engines such as Coingecko or CoinMarketCap – we have to rely on them for pricing, but their aggregation methodologies are often obfuscated. One of my favorite emails I’ve written for Figment was one to CryptoCompare with the subject line, “Does CryptoCompare have a SOC report?” The answer was a swift “no,” but they are registered as a Benchmark Administrator in the UK (a licensed pricing provider).
Another solution is to build these indexers in-house, but the costs are high and maintenance is a constant headache(5). In order for the auditors to get comfortable with this internal data, additional internal controls and reconciliation processes must be designed and implemented. This data blockage doesn’t just affect the accountants either. It spills into customer service when a customer asks for historical yields for a network, and we can’t provide a solid answer. It impacts marketing because we can’t build flashy graphs showing the overall growth of the PoS ecosystem with a high degree of certainty. This is an industry-wide issue and bigger than an individual staking provider trying to build this infrastructure on their own. It’s going to take a fleet of engineers to turn these clunky blockchains into data machines.
Wrangling the Token Balance Sheet
Staking providers are bound to accumulate a treasure chest of PoS tokens – after all, our revenue is denominated in crypto and can only be converted to fiat through an exchange. Assuming the providers are long-term holders and believers in the ecosystems they’re securing, this can lead to a ballooning balance sheet of crypto assets. Who needs depreciating fixed assets when you can hold the HUAHUA token instead? When your balance sheet has a token component though, there are risks of under-reporting or over-reporting tokens.
This is a huge area and in audit speak, a risk to the existence, completeness, rights & obligations and valuation account balance assertions (basically all of them). The three most concerning ones are:
- Existence: how is the auditor sure the tokens we’re reporting actually exist on the blockchain? What if the block explorer we’re showing them is fraudulent or outdated? It’s easy to copy and paste a number from an Etherscan account onto your balance sheet, but auditors will want to ensure 1) you own the account address and 2) the tokens are real. This gets into the audit-worthy data issue discussed above but there are some auditing techniques around this (i.e. sending your entire token balance to another wallet and auditors verifying it on-chain).
- Completeness: In my experience, the completeness of your token holdings is the biggest risk, especially for a staking company. It takes about five seconds to spin up a new wallet, and there’s usually a time delay between the developers creating a company-owned wallet and finance finding out about it. Your company could have hundreds – thousands – of wallets that need to be accounted for but unless you have an alerting system or a well-defined process, some tokens will slip through the cracks. There isn’t a magical dashboard (yet) that displays all your tokens across all the PoS chains – there are instances for specific blockchains like the Polkadot.js wallet or Ethereum watch list, but they can’t interact with SCRT or SOL. I’m betting that the risk of under-reporting a token balance sheet is higher than over-reporting it (unless there are token loans involved, discussed below).
- Rights & obligations: to verify this assertion, the auditor can have your wallet “sign” a certain transaction or send a small amount of crypto to their address (mentioned above). The risky part here is knowing if you own your own keys/crypto – this might sound obvious, but as the years compound and your team grows, some details might get lost. I’m referring specifically to the self-bond requirements for several PoS networks. In some instances, the protocol foundation might “lend” the self-bond to the validators to kickstart activity on the chain. Since these tokens are technically a loan, they don’t belong on your balance sheet. The problem is that the foundation might be two people working from an apartment in Bali, so documentation might be lacking(6).
This is why we refer to our tokens as “horcruxes” at Figment. It feels like they’re hiding in the dingy places of the netherweb, waiting for us to discover them. There’s another interesting aspect to the balance sheet as well; the self-stake for a validator should count as part of your total token balance. These tokens might be locked away in an on-chain staking contract, but you have the rights to those locked tokens that are earning rewards. The same goes for vesting contracts – if you invested in a protocol early and received locked launch tokens, oftentimes those tokens are eligible for staking. Again, it could be argued the crypto belongs on your balance sheet since you could theoretically sell your private keys to someone else and gain from the transaction. There’s no US GAAP guidance for this yet but just a word of caution to hyper-track your wallets.
On the Staking Accounting Frontier
I could spend days writing about the peculiarities of staking rewards on The Graph or how parachain auctions work, but I’ll end here with a few additional thoughts. There is endless opportunity for clarification and growth in the PoS accounting profession. Regulations are unwritten, and there aren’t enough people thinking about these issues – blockchains are pervasive and nearing the critical mass of adoption. If we can’t get our basic revenue numbers right, that will affect the perception and legitimacy of this industry. We have the potential to be extremely transparent with our financial data, but it will take a partnership between both accountants and developers to realize this goal. I don’t know of any other space where you can “find” revenue horcruxes on the daily and have documentation to support it. Blockchains are here to stay – and so is accounting.
__________________________
(1) For several PoS chains, a self-bond (synonymous with self-stake) is required for the validator to be provisioned and added to the active validating set. An example is FLOW, where the collection node must have a self-bond of 250,000 FLOW and consensus nodes need 500,000 FLOW. This theoretically incentivizes the node operator to act honestly because they have “skin the game.” If the validator is dishonest (i.e. double-signed transactions, downtime), their self-bond can be slashed according to protocol rules.
(2) For most networks, there is a validator operating address (the public address that delegators stake to) and an associated beneficiary address where staking rewards and commissions accrue and land once they are claimed. A good example is Fiment’s Osmosis validator, which can be viewed on Mintscan here.
(3) Figment currently operates on 43 chains (mainnet + testnet) so you can imagine how chaotic our close weeks are.
(4) One Solana epoch is ~2 days
(5) If the chain updates (i.e. the Terra update from Columbus 4 to Columbus 5), the indexer has to be recalibrated.
(6) A side note on self-bonds – it’s an interesting financing dynamic because you can either 1) buy the tokens yourself, 2) borrow them from the foundation (sometimes) or 3) borrow them from an OTC/market maker. There’s a risk profile involved here that the staking provider needs to think through – do they have enough liquidity to buy the tokens? If so, do they want to risk holding them in a downturn?
