My Solana validator accounting journey began in 2021 while I was a crypto accountant at Figment. I was puzzling over how commissions were earned and muddling through the never-ending list of validator addresses. Everything was so confusing, from the vote accounts to the vote authority and identity addresses. 

On top of the terminology barrier, I could never tie out the vote authority addresses to any of the on-chain transactions I saw on the Solana Beach or Explorer.Solana block explorers. Our balance just mysteriously increased, and I would wrack my brain while trying to find shreds of information online (this was before Perplexity could search anything instantaneously for me). As it turns out, the block rewards were the missing ingredient to our vote authority addresses and Figment was very pleased when I “discovered” this extra revenue stream. 😁 However, our processes were still manual and messy, and these rewards were lump sum adjustments to reconcile to an ending balance on-chain. I still didn’t fully understand what was going on…until this past month!

This article is meant to be the magnum opus of my Solana validator learnings, discovered and refined over four years in the industry. The big breakthrough came when one of our customers shared the link to JPool, a liquid staking platform that also has an amazing validator explorer page. Everything suddenly became clear and I felt like the fog had finally lifted. All of the puzzle pieces fit snugly together.

So let’s dive in!

Solana Validator Basics

When you set up a Solana validator, there are three main addresses involved:

• Vote Account: when a delegator goes to stake on Solana, they “point” their stake to the vote account. This address stores information like commission rate and validator votes per block. I consider this the “main” validator address because the commission earned by the validator lands here.
• Validator Identity: the identity account pays for all the vote transaction fees submitted to the vote account (i.e. the validators have to vote on blocks in order for them to be posted to the blockchain). For an active validator, this account can produce millions of transactions that are just gas-fee only...which makes it impossible to reconcile this address just by looking at the block explorer. Sweep outs of this wallet are frequently “buried” between all of the micro-transactions. Block rewards also land in this account.
• Vote Authority: responsible for signing the vote transactions. This address is often the same as the validator identity. Per the Solana docs, “If the validator identity is also the vote authority, only one signature per vote transaction is needed in order to both sign the vote and pay the transaction fee.” → this effectively reduces the vote fees by half
• Withdraw Authority: has the ability to withdraw funds from the vote account (it doesn’t do much else - it’s more of a security feature)

Here’s what all of these addresses look like on an actual validator page:

https://solscan.io/account/CcaHc2L43ZWjwCHART3oZoJvHLAe9hzT2DJNUpBzoTN1

‍

Pulling Revenue & Expense Numbers for these Addresses

Part One: Commission

It’s always been relatively easy to pull commission revenue for Solana validators. The OG explorer that had this data was Explorer.Solana → if you head to the “Rewards” tab on a vote account, you can pull commission by epoch and also see the “post balance” amount (i.e. the ending token balance to reconcile to). For example,

Each epoch lasts roughly two days, and these dates are usually available on the block explorer (click the hyperlink for each epoch). This website was awesome because I could download all the commission data by epoch, subtract any sweeps of SOL out to a treasury address, and the ending balance would tie out to the post balance column. I could always tell when a sweep occurred because the “post balance” number would drop significantly while the rewards per epoch stayed constant. This would be a clue for me to check custodian logs to see when the sweep was executed. You can also find this epoch-level commissions data on Solscan (the “rewards” tab).

A quick note on definitions here: “commission” refers to the cut of staking rewards the validator keeps from their delegators. For example, let’s say the Figment validator earns 100 SOL worth of rewards. They get to keep 7 SOL (assuming a commission rate of 7%) and the remaining 93 SOL is distributed to the delegators based on their stake weight. This split happens automatically on-chain and is a beautiful example of how efficient blockchains can be. The source of the commission comes from inflationary rewards i.e. new SOL that is minted and split between validators and delegators.

Part Two: Block Rewards and Vote Fees

All of the gray hairs on my head can be attributed to these pesky numbers. As a reminder, this other revenue bucket is related to the Validator Identity address (usually the same address as the vote authority). Reconciling this account stumped me for years. I could see large chunks of SOL leaving this account, but there was never any “rewards” tab on Solscan. The “Transfers” tab, which shows inflows and outflows of SOL, was also useless because it never surfaced any revenue data. Instead, I was typically left with a large variance between the on-chain balance and my calculated balance at year-end, and I had no choice but to plug it (OooOo so bad!). It wasn’t until a few years later that the engineering team confirmed what I had suspected all along - there was a second source of revenue being earned by the validator. Enter block rewards!

Block rewards, called “Leader Rewards” on JPool, are additional rewards earned by validators that lead block production. They are generated from transaction fees (further split into the base fee and the prioritization fee) and are kept by the validator (i.e. not split with the delegator). These rewards were so tricky to account for because no explorer exposed these rewards, either by epoch or in total. I could only tell SOL was being earned because the total wallet balance kept rising and then would sharply drop whenever a sweep occurred.

The other complication here is that the voting fees are also paid by the validator identity address. You can think of voting fees as mini gas fees that add up to a hefty amount because of the transaction volume. Multiple votes are cast each second and a carry of fee of 0.000005 SOL. From what I’ve seen, average monthly vote fees are around 30 SOL for larger validators - which adds up over time.

Capturing this data the traditional way was impossible because of the volume and block explorer limitations. So we would back into the netted rewards & fees by pulling the ending SOL balance at month-end (i.e. in this transaction on October 31, we would be reconciling to 54.99 SOL). It’s a scrappy method, but it works and ties out to on-chain data.

However, this accounting conundrum ended once we were introduced to JPool, the snappy block explorer referenced earlier. Here is the Figment page:

This is revolutionary! We can finally pull commission, block rewards (called Leader Rewards here), voting fees and JITO rewards by epoch. We can also filter to specific date ranges and download the data as a csv, which is a luxury feature for most block explorers. For the first time in my accounting journey, I have full visibility into the guts of a Solana validator. My reconciliation skills cannot be tamed. We’ve already covered commissions,leader rewards and voting fees, but here’s what the other fields mean:

• Jito Reward: MEV rewards for running a Jito-Solana client → basically, validators can reorder transactions to earn profits. These rewards land in the vote account.
• Voting Compensation: this field was new for me and unexpected. It’s related to the Solana Foundation Delegation Program, which reimburses new validators for their voting fees. Per this program, “The SFDP will cover voting costs for validators in their first year…Starting from onboarding for the first three months participants will have 100% of vote costs covered, for the next three months 75%, for the third three months 50% and for the final three months 25%, with vote coverage ending after 12 months.” It’s essentially a fee reimbursement that lands as a separate transaction in the validator identity account. For example, see this reimbursement distribution that happened on October 27. The foundation is sending from this account: DtZWL3BPKa5hw7yQYvaFR29PcXThpLHVU2XAAZrcLiSe

Armed with these critical pieces of data, you can reconcile any Solana validator. Here’s what my reconciliation matrix looks like for a validator identity account:

* For example, an internal transfer “in” could be a small amount of SOL from another wallet - this is needed to kickstart the wallet. An internal transfer “out” could be a withdrawal to a custodian or exchange address.

Part Three: Other Useful Facts I’ve Accrued

A few other tidbits related to Solana validators that might come in handy during month-end close:

• Rewards typically start accruing two epochs after a stake becomes active (there is a “warm up” period when staking and a “cool down” period when undelegating)
• Staking rewards & commissions compound automatically each epoch and don't require manual claims (they are swept out with the blessing of the withdraw authority address)
• Most crypto subledgers have pitiful Solana validator support, but Bitwave recently introduced a new feature that rolls up commission, block rewards and voting fees for validators (not contract executions though - watch out for those transactions as they can add a lot of volume). I’ve tried out the feature and it works pretty well!
• I’ve said this a million times, but always, always reconcile to an ending on-chain balance. If your ending token balances are correct, your accounting is wrong.

In parting, Solana validators have been my personal headache for years - but now, I feel like I’ve climbed the Mount Everest of crypto accounting. Decoding the validator identity data felt like a long-awaited revelation, and it feels fitting to come at a time when I’m tinkering with my new Solana phone. Kismet maybe? Or maybe the universe finally decided it was time for me to figure out Solana validator accounting, once and for all. Thank goodness!

Shoutout to the Hash Basis customer who introduced me to JPool - you are truly heroes!