The Zero Gravity (0G) blockchain has made a splash recently, probably because it’s one of those eye-catching projects that is combining blockchain with AI compute. I started working with this blockchain recently, but I actually had no idea it was AI focused until we researched it for this article. It sounds like the benefits of blockchains (like verifiability, record-keeping, transparent incentives) are being used to ensure decentralized AI compute does its job correctly and fairly. 

I find 0G intriguing because it appears you can actually do useful work on it - it’s not a pump-and-dump blockchain whose only purpose is to make a quick gain. If I needed GPU power to create, let’s say, an LLM that is trained specifically on GAAP, I could buy this power from 0G.

Other use cases for Zero Gravity could include deploying on-chain agents, decentralized ChatGPT alternatives or AI-powered DeFi applications. Basically, you can purchase AI compute power from 0G instead of big companies like AWS and the blockchain layer makes sure everyone plays by the same rules.

This context was completely missing when I rolled up my sleeves and tackled 0G validator accounting for the first time. The ingredients were similar (i.e. I knew validators earned rewards for producing valid blocks and that there was “claiming” involved), but the existing block explorer I used (https://explorer.0g.ai/) was confusing - it definitely was no Mintscan. However, after switching to https://chainscan.0g.ai/, the full accounting picture became much clearer.

Here are a few facts about 0G validators that will make the accounting easier:

• A 0G validator has its own smart contract address
  
  • In addition to the contract address, validators also have “operator” addresses → these helper addresses sign claim transactions
  • Once claimed, rewards land in an address of the validator’s choosing (it can be the operator address or a totally different wallet)
• When the validator is ready to claim, the operator address makes the call withdrawCommission(withdrawalAddress)
  
  • The amount claimed has to wait for about two days before it’s liquid in the rewards address (this is called the validator's withdrawal queue)
• In addition to earning commission (which is just a % of the total rewards the validator earns), validators can also earn tip fees. I think of these as additional transaction/AI-service fees that also need to be claimed.
• Rewards accrue until they are claimed (similar to how rewards work on the Cosmos chains)

Let’s break this down further with an actual validator and real revenue numbers. 😎

Validator Address: 0x859050edf0151C8fC317eAAcF84601E344231347

Initially, I was using https://explorer.0g.ai/ to figure out the claims - when you head to this validator page, it looks something like this:

This explorer displays the commission rate (1% in this case), and a field called “Commission Rewards” → this represents the accrued and unclaimed commission for the validator. Other fields like total 0G delegations and number of delegators are present too. What’s so confusing is that this explorer has different views for the same address; you can view the Validator page (what we have above) or the Account page (which is the smart contract page).

The actual contract page mystified me because it showed a much higher balance of 0G than I expected - a whopping 14,888 0G in this screenshot. It’s important to note that the contract balance here represents network-held funds like staked delegator tokens and the accrued/unclaimed rewards. And since it contains customer assets, it typically shouldn’t be included in your balance sheet (only the accrued commission should be on your books as a receivable).

Just by looking at these transactions, I could tell something wasn’t right. I went down a Perplexity rabbit hole and asked everything I could about the validator claiming mechanics on 0G. I learned a valuable nugget: method “0x16c58d04” corresponds to withdrawCommission(address), which is the operator-only call that queues commission for withdrawal. Here’s one of those transactions on the explorer.

What’s so confusing is that explorer.0g.ai doesn’t actually tell you the amount claimed. I combed through the logs and internal transactions, and the only number that appears is under the “DelegateCall” trace type. For example, based on this explorer, I thought 22,458 0G was being claimed. But that’s not what is happening at all! The numbers just didn’t add up - when I added all of these “DelegateCall” numbers together, the balance was way off compared to what the contract address or the rewards address showed. Reconciling to any ending balance seemed impossible. But we finally had a real breakthrough with the new explorer, https://chainscan.0g.ai/.

The same contract address (0x8…1347) looks like this on Chainscan. This explorer was a level-up for a few reasons:

• It actually exposes the withdrawTipFee and withdrawCommission methods & actual amounts claimed
• You can download transactions via csv (although only delegation amounts show up, not any of the claims…I built a mini app at https://0g-claims.pplx.app/ to solve this problem)

The transaction hash we referenced above looks like this on Chainscan:

The Overview tab gives us the same general information as Explorer.0G.ai, but the “logs” tab is where all the magic is happening. If you scroll down to the third log, we can finally see the holy grail: the WithdrawCommission() function. The amount claimed reads “252335650104460000000”, but once you divide that by 10^18, the number turns into the human-readable format of 252.33 0G. We can also glean the withdrawal address - 0xed488e6cc4b030eb5bfdde3227c3d5da2b9040e8 (be sure to remove all the leading zeros). The 252.33 0G is a far cry from the earlier amount I thought it was (22,458 0G), which only shows how critical it is to 1) use the right tools and 2) reconcile your ending wallet balances. Once this transaction is triggered, the 252.33 0G will sit in the withdrawal queue for two days before it officially lands in 0xed488e6cc4b030eb5bfdde3227c3d5da2b9040e8. Because of this delay, keep in mind that your 0G balances on the block explorer might slightly lag behind your calculated balances in your crypto subledger - I’ve noted this difference as an expected reconciling difference in our workpapers (it’s usually pretty immaterial anyway).

Different Blockchain, Same Accounting Issues

As I’ve recounted several times, the most difficult part of being a crypto accountant is pulling all the wallet transactions for your client and making sure all the data is complete & accurate. I’ve had to rely on block explorers for years, and this case study only proves how finicky and misleading they can be. Always cross reference between multiple explorers to settle on the right answer…or, build your own intuitive explorer using AI tools (that’s next on my radar for 0G - stay tuned 😎).

‍

Thanks for reading!