Staking Income for Validators
Brief introduction in Proof of Stake (PoS) blockchains and review of the presentation of staking income in Coinbase Form 10-K
On proof of stake blockchains, the network's security is ensured by users who stake their scarce resources (crypto assets) on chosen validators. This is how it happens:
Validators deploy blockchain software binary files (files that contain the compiled protocol code) on servers, whether owned or rented, that function as nodes on the blockchain network. This software enables validators to verify transaction accuracy and sequence and group validated transactions into blocks.
Validators are chosen from a pool to propose new transaction blocks. The selection follows protocol-specific rules that typically consider factors like the number of staked tokens and node historical performance (past instances of downtime and double-signing, etc.). But in order to be added to the blockchain, each new block requires achievement of consensus among all active validators. To achieve consensus, validators vote on the proposed blocks using digital signatures derived from private keys of each node. A validator's power to vote on proposed blocks directly corresponds with the number of tokens staked with the validator. Once voting is completed and the consensus has been achieved, the newly forged block is added to the blockchain. The need for consensus means that any attacker on the PoS network needs to control a majority of the native tokens of this network to succeed in a 51% attack. Thus, staking is designed to ensure the blockchain network security.
Validators earn rewards in two primary ways:
First, by staking their own tokens, they receive staking rewards proportional to their investment.
Second, they share rewards with other users (delegators) who decide to stake their tokens with them by allocating or delegating their tokens to validators.
Thus, the reward system benefits both validators and delegators, providing two streams of income: direct staking rewards for validators and shared rewards for both parties.
In addition, validators often enter into agreements with the blockchain foundations (or other similar entities responsible for the network governance), where foundations allocate returnable grants of the massive balance of native tokens to validators and give up delegator rewards for the benefit of validators. Foundations do this to incentivize validators who enter the ecosystem early. The rewards earned by validators on these assets are roughly 5-8% compared to 0.01-0.05% on assets staked by delegators not affiliated with the Foundations (although these reward rates can vary widely across different networks and over time due to changes in network policies, token economics, and market conditions).
Each blockchain is unique and you can find different variations of PoS. Some networks allow anyone to join as validator as long as the new entrant has sufficient stake (e.g. 32 ETH on Ethereum), others have a limited number of validators (e.g. only 105 validators can be active on Polygon network), third have a combination of both (e.g. in the NEAR ecosystem).
With this in mind, let’s dive into a few questions specific to staking income accounting in the financial statements of validators in the light of requirements of ASC 606 “Revenue from contracts with customers”:
Know Your Customers. Who are the validators’ customers?
Principal vs. Agent. Is the validator a principal or an agent in staking revenue arrangements?
Consideration Payable to Customers. Do delegator rewards fall under consideration payable to customers’ guidance?
Know Your Customers
The structure of staking arrangements is complex because it involves multiple parties acting in the role of customers from the perspective of a validator. These customers are also directly involved in the provision of services by validators.
We can identify the following key parties of staking arrangements:
End users. The role of end users is to execute transactions on the blockchain. Users who want to send crypto to another party or buy NFT on a blockchain initiate transactions by submitting them to a blockchain client (wallet). The client broadcasts submitted transactions to the network for validation. Validated transactions are included in a new block appended to the blockchain. Once a block is appended, the transaction is included in the blockchain. End users are ultimate consumers of services provided by validators. However, end users should not be viewed as direct customers. They should be viewed as direct customers of the blockchain. Blockchain acts as an intermediary responsible for setting protocols of network operation and interactions between users and validators.
Blockchain networks. Network protocols may be controlled by another business or nonprofit or governed in a decentralized manner. As such, it is appropriate to identify the network as a separate entity. This entity may act as a validator’s customer. The network's role is to pool and then allocate transactions to validators, who are responsible for building new blocks of the blockchain from such transactions in compliance with the established protocols.
Delegators. Delegators stake their limited resources to secure the network based on the mechanism built into the protocol. To choose validators or to purchase crypto assets for staking, delegators must execute transactions on the blockchain network (either via direct on-chain interaction with a staking smart contract or via the mechanism established by the custodian of crypto assets). This means that delegators are customers of the network. Delegators are the sub-group of end users who engage validators to provision validation services to all other end users. This engagement is executed by staking assets and assigning validation voting rights embedded in crypto assets to validators. However, staking arrangements do not oblige validators, nor do they oblige delegators, to pay any consideration in exchange for validation services rendered.
Staking arrangements include contracts between validators & delegators as well as validators & end users. From perspective of ASC 606, both of these contracts should be combined and analyzed as a single arrangement because:
Delegators are always participants in the network.
Consideration payable under arrangements with delegators depends on the performance and rewards earned by validators in the arrangements with end users of the network.
As such, contracts with delegators are only contracts with customers to the extent that they are combined with validators’ arrangements to validate transactions on the network. Therefore, we can identify that:
Delegators are de jure customers.
Blockchain networks are de facto customers who engage validators to perform validation services.
End users are indirect customers consuming the results of services provided with mediation of the blockchain network.
Principal vs. Agent
ASC 606 requires us to assess whether we act as agents or principals for each good and service transferred to customers when other parties are involved. Staking services represent a single performance obligation. These services are performed for the blockchain networks AND delegators, as both customers are contracting with validators for the same service (transaction validation on the network), which represents a single combined performance obligation to ensure that the validator nodes are running with maximum up-time in a manner reasonably intended to arrange for the generation of digital asset rewards for delegators. Since there is only one service and validators are primarily responsible for such service, they are (clearly) the principal1.
In US public companies with significant staking revenues agree that their businesses act as principals in staking arrangements because, as validators, they control the only service being provided (which is validation of transaction on blockchain networks). As such, we can find in SEC filings of these companies’ disclosures stating that management record as revenue the gross amount consisting of both validator and delegator rewards from staking. This is consistent with our conclusion above.
Consideration Payable to Customers
The guidance over consideration payable to customers requires companies to assess any payment made to customers to understand if the payment was made in exchange for a distinct product or service. Based on this understanding:
Payments made without distinct services or goods received in exchange are treated as a reduction in revenue;
Payments equal to or less than the fair value of distinct services or goods received are accounted as costs of goods or services purchased2;
"An entity needs to determine whether consideration payable to a customer represents a reduction of the transaction price, a payment for a distinct good or service, or a combination of the two".
Depending on the blockchain, delegators act as either direct or indirect customers of validators. Because delegators are customers, rewards paid to delegators are subject to the guidance on consideration payable to customers. It would be easier to understand this issue if we could account for the fact that the validator may never obtain control over delegator rewards as these rewards are (with rare exception like MINA network) distributed to delegators automatically by the protocol. However, both the delegator’s and validator’s portions of rewards are transferred in exchange for a single performance obligation (validation of transactions on the network). The form/method of settlement does not affect whether the payment should be included or excluded from the transaction price (refer to Questions 25-26 of the Revenue Recognition Implementation Q&As published by FASB for further discussions).
The consideration payable to customers’ guidance applies to payments made to any customers in the distribution channel, including payments made in cash, equity instruments, or items that can be applied against amounts owed to the entity [606-10-32-25]. As the native cryptocurrency of the network can be applied against amounts owed to validators for services on this network, token payments to customers are subject to the guidance on consideration payable to customers. This, in particular, means that the transfer should be measured based on the fair value of tokens at the contract inception date rather than at costs of digital assets transferred to customers.
As such, our analysis may follow one of the two routes depending on whether a validator is believed to receive a distinct service(s) in exchange for delegator rewards:
If delegation is not viewed as a distinct service, then the guidance would require us to reduce the transaction price by the amount of consideration payable to customers. This is because delegator rewards are paid in tokens, and delegators can apply these tokens against amounts owed to validators for transactions executed on respective blockchain networks. Hence, the noncash form of payment does not preclude us from accounting for these payments under the guidance for consideration payable to customers. As no distinct services are received in exchange for a consideration transferred to customers (delegators), these rewards should reduce the revenue presented in the validator's financial statements.
If we were to conclude that delegation is a separate service (distinct from validation), this conclusion would imply that the primary responsibility for delegation services would reside with delegators rather than validators. Hence, validators would act as agents of delegators, and related rewards would be presented by validators on a net basis.
Since the validator is a principal, rewards paid to delegators (customers) fall under the scope of the guidance on consideration payable to customers. Because no distinct service is being received in exchange for rewards transferred to customers, delegator rewards must be deducted from the transaction price. So, even though the validator is a principal, validators should present the revenue net of delegator rewards earned.
What is the impact?
Now, we do not know the actual amount of delegator rewards presented on a gross basis in Coinbase’s financial statements, but we can derive a good estimate based on the information about increases in rewards paid to customers discussed on page 107 in Form 10-K for 2022 fiscal year and on page 99 in Form 10-K for 2021 fiscal year:
And here you could see the estimated impact as % of the metrics listed above:
Considering the impact this treatment may have on the company’s results3, we think that as a minimum, Coinbase needs to disclose own assessment of the consideration payable to customers guidance for its staking revenues in the years affected.
To Be Continued…
This was the first but not last blog posts where I will discuss the accounting for staking income. Today we concentrated on the accounting treatment of staking income from the point of view of validators, next time we will discuss accounting for delegators.
KPMG was the first and still is the only Big 4 company to explicitly address the topic of staking accounting. Based on KPMG’s Accounting for crypto staking rewards, in a typical staking arrangement, a validator acts as a principal because it controls the service. Hence, it should account for staking rewards on a gross basis. Neither PwC nor EY addresses our current topic in their respective accounting guides. Deloitte has not published a crypto asset accounting guide like other Big 4 companies.
Costs of purchases are not the same as costs of sales. The cost of sales is a line item in the income statement (it is an expense). Costs of purchases include both costs of purchases capitalized as part of assets on the balance sheet or expensed as part of any of the expense categories in the income statements.
The ultimate responsibility for the decision on the appropriate application of accounting principles generally accepted in the USA for an actual transaction rest with the preparers of financial statements, who should consult with their continuing accountant. My judgment on the appropriate application of accounting principles generally accepted in the USA for the described specific transaction is based solely on the facts available to me. Should these facts and circumstances differ, my conclusion may change. This publication is intended solely for the information and use of the readers of TechAccountingPro.substack.com blog and is not intended to be and should not be used by anyone other than these specified parties.