Proof-of-Stake validators are trendsetters in many regards. And the same is true of those tasked with their financial accounting. With each new advancement in cryptocurrency and blockchain technology, a new set of challenges emerges for accountants to solve.
Perhaps one of the most significant challenges facing accountants in the cryptocurrency space is revenue recognition. The main steps involved in revenue recognition are:
- Identify the contract
- Identify the performance obligations
- Determine the transaction price
- Allocate the transaction price
- Recognize the revenue
By taking a closer look at each step, we can better understand what crypto accountants are up against.
Identify the contract and performance obligations
The directive is simple - identify the contract. But what sort of contract is involved in a blockchain transaction, and who is the proof of stake validator’s customer?
Typically, formal contracts are not involved when it comes to blockchain transactions. There is an implied understanding that proof of stake validators will be rewarded for successfully validating transactions, but there is no specific contract to point to. And even if there were, who would be the other contracting party?
There are many parties involved in a transaction on the blockchain. In theory, the proof of stake validator’s customer could be the transacting users, the delegators, or the protocol code itself. It could be one of these parties or a combination of all three. At this time, the answer is not clear.
Similar questions emerge with each successive step in the revenue recognition process.
Determine and allocate the transaction price
One of the most significant issues in crypto accounting involves the fallacy of network data. Many people assume that the blockchain is an all-seeing, all-documenting technology, and in some ways, it is.
However, the blockchain is really just a permanent record of letters and numbers that only makes sense to experienced coders. Yes, the blockchain can be examined with block explorers like Etherscan, but the information gathered there is still not comprehensible to most people.
Unfortunately, it’s difficult for financial accountants to gather information from block explorers and use that information in a meaningful way to create and maintain financial records.
Recognize the revenue
The crypto accountant must also determine at what point in the transaction process the revenue should be recognized. For the proof of stake validator, revenue is the native crypto reward that they receive after successfully validating a transaction on the blockchain. But should the accountant recognize staking rewards at the moment the rewards are earned or the moment the rewards are claimed? In this instance, the answer is clear - the rewards should be recognized when they are earned.
As previously mentioned, however, finding historical data on the blockchain is quite difficult. As a result, many accountants are forced to forego best practices and recognize the revenue at the moment it is claimed.
Bitwave to the rescue
We are going to highlight 2 types of revenue that can be captured from staking activities. The first will be rewards from staking activity, which is from the perspective of the entity that is doing staking. The second will be taking fees for setting up staking nodes on behalf of others, which is from the perspective of a staking service provider.
Accounting for Polygon Block Rewards in Bitwave
If you are using Bitwave to track rewards for staking activities such as securing a network by validating blocks or acting as a proof of stake validator, the process is very simple. The blockchain wallet that is validating the blocks on the polygon network is receiving rewards for each block that is successfully validated. In the example here we can see that there is an inbound transaction of MATIC token on the Polygon network.
This transaction is revenue activity and the value of the tokens is priced at the time of the transaction. When a wallet address is added to Bitwave, we query the blockchain for transaction information from the start of the wallet history and value the tokens using our pricing engine based on the time of the transaction.
Collecting Fees on Setting up Ethereum Nodes
If you are a proof of stake validator or staking service provider, you can also use Bitwave for intelligent capture of fees charged and collected when setting up Staking Nodes. In this example 32.5 ETH is sent to the staking provider and 32 of that ETH is sent to the Beacon Chain to establish an ETH Staking Node.
The wallet here is actually a Smart Contract input into Bitwave that the client of the Staking provider is interacting with. The contract is collecting a .5 ETH staking fee and sending the 32 ETH to the Beacon Chain. Note that the transaction fee associated with this contract call is paid by the client and not the staking provider.
In addition to questions surrounding revenue recognition for proof of stake validators, learn how other age-old accounting methods are being adapted for decentralized finance in our Proof-of-Stake Accounting article.
Accounting for Revenue Recognition in the Cryptocurrency Space: A Complex and Evolving Challenge
With the emergence of new blockchain technologies and crypto assets, accountants must navigate a landscape that is often unclear and difficult to interpret. Bitwave makes it easier to track and report on digital asset transactions and comply with tax laws. By leveraging the power of blockchain technology and advanced algorithms, Bitwave helps crypto accountants stay on the cutting edge of the digital asset industry and overcome the challenges of revenue recognition for proof of stake validators.
Contact us today to schedule a demo.
Disclaimer: The information provided in this blog post is for general informational purposes only and should not be construed as tax, accounting, or financial advice. The content is not intended to address the specific needs of any individual or organization, and readers are encouraged to consult with a qualified tax, accounting, or financial professional before making any decisions based on the information provided. The author and the publisher of this blog post disclaim any liability, loss, or risk incurred as a consequence, directly or indirectly, of the use or application of any of the contents herein.