How does Data Completeness Look in a Crypto Subledgers?
In this technical guide, Dr. Andrew Belonogov dives into the challenges of maintaining complete blockchain data. Especially within a crypto accounting sub-ledger. He offers expert insights and solutions for professionals navigating this complex domain.
Completeness of blockchain data entered into the entity’s crypto accounting sub-ledger is critical. However, we often see situations where the transaction details do not add up to the current account balance. Resolving this difference usually becomes a daunting task that consumes an extreme amount of time.
I dug into the most common reasons for such discrepancies. I describe how each of these reasons may be solved too. And, at the end of this article, I’ll also share my preferred sub-ledger choice based on its ability to address these persistent challenges.
Table of Contents
Internal transactions
For Ethereum and other EVM blockchains blockchains, internal transactions are not stored in blockchain records. Resulting types of state changes may not always be captured and indexed properly resulting in a missing activity.
We can find some details of what an internal transaction is below:
While internal transactions have real consequences to account balances, surprisingly the internal transactions themselves are not stored in on-chain. To see internal transactions, you have to run the transaction and trace the calls that it makes. While some contracts do log events to the chain that record internal activity, many do not because doing so requires additional gas.
[Blockchain.com Blog]
“Internal transactions aren’t actual transactions on the blockchain and therefore aren’t included directly in the blockchain. Internal transactions are value transfers initiated by a contract or when a contract simply makes a call to another contract. The result of the value transfer or contract call isn’t stored on the blockchain and therefore you cannot return the result of the internal transaction from the blockchain.
Etherscan obtains the results of these transactions by running a modified node that records all the value transfers by looking at the actual transaction that resulted in the change, and then stores the effects of the transaction separately as an ‘internal transaction’. Currently, there is not any way to imitate this process simply using the web3 API.
Another example is the different message types on Cosmos networks.
Solution:
- Advanced explorers that provide a better view of each transaction:
- For the minimal view use Arkham,
- For the most functional view use Blocksec,
- For the most detailed view use BitQuery,
- For human-readable transaction labels use Noves / Blockscout.
- Etherscan API for internal transactions.
To better understand how to read data on Etherscan, read How to Read Block Explorers and Understand Transactions, Traces, and Logs on Ethereum.
Genesis allocations
Initial (genesis) allocations of tokens by accounts are not reflected in any of the blocks validated by miners. They have to be identified by a reference to the underlying network genesis file. These files are not easy to locate and difficult to understand.
Solution: Genesis file libraries like StakeLabs
Complex transactions
For blockchains with multiple account state changes, some may not be captured properly. Account state changes are transactions, transfers, events, messages, etc. This can result in missing activity within the sub-ledger.
For transactions with multiple logged items, only the first logged item may be imported. Incorrect interpretation of complex transactions (liquidity provisioning).
We recommend adding an index to each amount of transaction, for example:
Events that change the qualities of tokens owned but do not transfer assets. For example, tokens deposited to the wallet with transfer restrictions based on the vesting schedule on Avalanche regularly produce events for each vesting tranche. Vested tokens are reflected as deposits although tokens are not transferred between the accounts.
The owner of tokens does not change, therefore, to properly roll the token balance, the sub-ledger should either:
- Import both withdrawals of unvested and deposits of an equal number of vested tokens.
- Reflect the value of the transaction in tokens as zero.
(which can typically be achieved by checking the “ignore” box next to the transaction in any sub-ledger accounting system).
Solution: See #1.
Data pruning
To efficiently manage storage space and ensure high speed of processing, it has become popular to only store recent blocks in the light validation clients. The hash of all previous blocks is stored in each new block as proof. While the blocks themselves are only stored on archival nodes. As such old transaction data may not be imported. This happens when the sub-ledger is connected to a pruned node with only a recent history of on-chain transactions.
Pruning is the process of removing non-critical blockchain information from local storage. Full nodes keep an entire copy of everything that is stored on the blockchain, including data that is not very useful anymore. Pruned nodes remove much of this less relevant information to have a lighter footprint.
[Monero]
Solution: To solve this issue, ensure that the sub-ledger is connected to an archive (full) node. It will contain a copy of the full transaction history.
Lazy Blockchains
Certain blockchain data sources include both successful and failed transactions. This happens on so-called “lazy blockchains”. The process of transaction validation is decoupled from the protocol consensus. This favors the use of light clients while leaving the validation of transactions to full nodes. This approach is widespread among Cosmos ecosystem blockchains, like Celestia. It results in the production of “dirty ledgers” that contain both successful and failed transactions.
One might have concluded that they can simply exclude failed transactions from the ledger. However, both failed and successful transactions require gas payment to be included in the block. So, failed transactions result in a change of account balance by the amount of gas consumed by these transactions. Usually, the gas fees are not as material for this type of blockchain. The scenario is different for companies with a high volume of transactions. Their cumulative amount of fees may become material.
Solution: Use detailed audit logs in the sub-ledger to identify any hidden, ignored, or deleted transactions.
Missing wallets
It is very common for startups to find difficulty tracking and identifying their complete list of all wallets. Because of this, new wallets are being regularly discovered during the audit at every web3 company.
Solution: Use my tracker for early-stage startups in Notion.
Centralized exchange API
CEX APIs are often messy. Several past data incidents at Kraken are good examples of this fact. Access to older transactions on CEX is often limited. Frequently, we encountered situations when entities and individuals lost access to historical data. API payloads may provide incomplete transaction details and behave as unreliable.
Solution: We are working on creating a training that will cover this topic. Please stay alerted to notifications about course availability.
Module accounts
Let’s take a look at two ecosystems: Solana and Cosmos.
Cosmos.
The user’s unrestricted asset balance consists of five components: Available, Delegatable Vesting, Delegated, Unbonding, and Reward. Only Available assets are tracked inside the bank module of the blockchain and represent the actual account balance. When staked/unbonded/unstacked, these tokens are transferred to the bonded and/or unbonded pool accounts managed by the staking program module. In return, the program module tracks Delegatable Vesting, Delegated, Unbonding, and Reward balances of wallets that staked their assets. These records of the staking program module are what users see in cosmos wallets, even though these assets are technically outside of user wallets.
Solana.
Solana account model separate functionality to different accounts instead of a single user account like on Ethereum. Having multiple accounts associated with the wallet address is further complicated by multiple types of account balances on these accounts. For example, to properly include all account funds we need to add the active and inactive balance of the stake account and the balance of the vote account.
Similarly to Cosmos, Solana’s token balances may belong to a program or other system account. So it’s not directly tied to the owner’s identity account.
Solution: See more resources on the Solana account model recently published by CryptoCFO community.
Block header events
Continuing the illustrative example with cosmos modules. The states of each module behave differently and we need to properly account not only for transactions recorded on the chain but also for events and messages. On cosmos blockchains, an event is an object that contains information about the execution of application messages and transactions. Events are returned by the consensus engine in response to four types of ABCI messages:
- ResponseBeginBlock,
- ResponseEndBlock,
- ResponseCheckTx, and
- ResponseDeliverTx.
Event structure includes type, a list of attributes, and corresponding values. As a result of block header events, the account state may change without any corresponding transaction recorded in the block.
Solution:
- SubQuery
- Custom indexing solutions
Non-transactional Debits and Credits
Many unusual situations and events have happened in the history of blockchains. Sometimes, such situations and events were causing additional adjustments recorded without transactions accompanying these adjustments. Some examples are discussed below. One good example found in Coinmetrics documentation:
“Even though the overwhelming majority of debits and credits take place within a transaction, some protocols have balance updates that occur outside of transactions (for example, Ethereum blocks rewards are credited implicitly, outside of any transaction). There are also unusual circumstances where a block may carry additional credits and debits so that the ledger can be accurately balanced. For example, the irregular ledger update following Ethereum’s notorious DAO hack required us to append additional credits and debits to that block in order for the irregular ledger change to be accounted for.”
Staking Rewards
Often we see that high-volume intensive allocations to network participants are recorded without separate transactions that would contain an identifier. Instead of including the related transactions in the block, these allocations are recorded at a protocol level directly. This has changes in the state of the recipient’s addresses. This is typical for allocations that have a high number of recipients or have a frequent rate of occurrence.
Governance Income
This is also an important feature of protocol distributions related to blockchains with built-in asset management. This functionality allows for the automatic distribution of tokens based on the accepted governance proposals. Because such distributions are recorded originally via submitted governance proposal transactions that may or may not be approved. When the submitted proposal is approved, the recipient’s account state changes. When the submitted proposal is denied, no subsequent change in the state of account of the recipient’s address occurs. However, regardless of whether it is approved or denied, the following change in the account state happens without an additional transaction included in other blocks.
Further, there is a way to transfer funds to the community fund without creating a separate transaction.
Solution:
- Custom indexing solutions
Why Cryptoworth Is My Preferred Solution
Having spent years dissecting the intricacies of blockchain data for crypto accounting, I’ve come to rely on Cryptoworth as my preferred sub-ledger to tackle the challenges outlined in this article. Although it doesn’t tackle all of them, its strength lies in its ability to aggregate and process data from a vast array of sources. It currently covers over 200 blockchains, numerous DeFi protocols, and centralized exchanges—providing a more complete picture than many alternatives.
For example, it’s quite useful when handling internal transactions on Ethereum or reconciling pruned data from light nodes. Cryptoworth’s syncing capabilities and data support help capture details that might otherwise slip through the cracks. Its detailed transaction logs and flexible categorization also make it easier to audit issues. Especially failed transactions on Cosmos networks or vesting events on Avalanche.
Cryptoworth reduces the manual effort required to align the sub-ledger with actual account states
.
That said, the complexities I’ve described—ranging from genesis allocations to non-transactional state changes—are still very much prevalent, even with a tool like Cryptoworth. It streamlines the process and cuts down reconciliation time significantly, which is why I favor it, but it doesn’t eliminate the underlying challenges entirely. As new token behaviors emerge in the space—think novel staking mechanisms, cross-chain interactions, or zero-knowledge roll-up transactions—these introduce fresh layers of complexity that demand continuous adaptation.
For now, it’s my sub-ledger of choice for its efficiency and coverage, though I remain vigilant for the next set of tools or updates needed to address tomorrow’s quirks in crypto accounting.
Afterthoughts
Ensuring blockchain data completeness in crypto sub-ledgers is a multifaceted challenge. It requires deep blockchain understanding and robust technical solutions.
From internal transactions to data pruning, this article covers common discrepancies. It also addresses lazy blockchains and module accounts with practical tools. Additional tools like Blocksec, BitQuery, archive nodes, and custom indexing help resolve them.
Additionally, integrating blockchain data with traditional accounting software and the evolving regulatory landscape present ongoing challenges. Most users still rely on both parties to have a full reliable picture of a business’s financial footprint.
About the Author.
Dr. Andrew Belonogov is the Founder of TechAccountingPro, a licensed CPA, FCCA, and holds a Ph.D. in Accounting and Statistics. He specializes in blockchain accounting, helping Web3 startups navigate US GAAP and achieve audit readiness. With 14 years in public accounting, including seven at a Big 4 firm, Andrew has worked with companies from Fortune 500 giants to pre-seed startups. His expertise ensures compliance and clarity in complex financial reporting for the evolving digital asset ecosystem
FAQ
Data completeness refers to how thoroughly all crypto transactions—deposits, withdrawals, trades—are captured and recorded in a subledger to ensure accuracy and transparency.
Incomplete data can lead to inaccurate reporting, compliance issues, and missed tax obligations. Full data ensures trust, audit readiness, and accurate financial statements.
They use API integrations, blockchain explorers, and reconciliation tools to automatically track and validate every transaction across wallets and exchanges.
