There are plenty of difficulties tracking Solana, but they generally stem from three categories:

1. Blockchain Size (so big)
2. Transaction Model (inconvenient for categorization)
3. Related Accounts (spreads activity over multiple “derived” accounts)

Blockchain Size and Cost to Operate

When your job is to track and understand any transaction, you need access to the full dataset, which means using an archive node. Solana weighs in at a whopping 300 terabytes and growing at a rate of several terabytes per month. For comparison, Bitcoin is a lightweight at a very tiny 640G. You can keep that on a memory card. Hosting such a massive dataset on AWS can become prohibitively expensive, with storage costs alone reaching $30,000 per month in disk space for just one node. This doesn’t even account for additional operational and redundancy costs. Beyond cost, maintaining a node (or multiple nodes) requires extensive DevOps expertise, introducing a whole new layer of complexity to managing Solana data. As a result, we developed a more specialized and cost-effective approach.

Supporting Solana at NODE40

At NODE40, AWS has been a strong foundation for our service because it aligns well with our mission to scale predicatably, deploy quickly, and deliver reliably.  For example, our Ethereum and DeFi support was built to scale easily to other EVM-based chains, like Polygon and Avalanche. But when we encountered Solana’s exponentially larger dataset, it became clear that our existing architecture wasn’t sufficient. Supporting Solana was a non-trivial commitment—both financially and technically. As an engineer who’s life blood is problem sovling, this nagged me like only other engineers will ever understand. As the CTO and product manger, it was my call to time our support correctly. As more of our customers entered the Solana ecosystem and more businesses gravitated toward Solana’s performance benefits, it became essential for NODE40 to prioritize the technical investment ahead of 2025 reporting.

Data Availability

Running a Solana node in-house demands not only financial resources but also a dedicated in-house DevOps team. This tight coupling of resources can lead to scalability bottlenecks and introduce business continuity risks. Third-party data providers are an attractive solution for Solana data, but the data landscape for Solana is fragmented. No single provider had all the data we required in a format that fit well into our workflow. We found ourselves juggling multiple providers. Once we felt comfortable with access to data we still had to build a new high-throughput retrieval and transformation engine to support the massive volumes we were seeing before we could even begin working with customer data. This was …an experience, but it unlocked new levels of data support at NODE40 we can now leverage for other similar chains.

Transaction model, Related Accounts, and Slots

In Solana, a single transaction can invoke multiple operations across different programs (smart contracts). Tracking each sub-operation is challenging because the data structure passed to each program can vary, and how that data is serialized depends on the specific program. Unpacking this data to understand what happened during a transaction is important to our partners, but quickly becomes a complex task.

In contrast, most EVM-based blockchains, like Ethereum, use a more straightforward model. Typically, one address stores or references data associated with it. For instance, when you deposit into a liquidity pool (LP), the LP token (if one exists) is sent back to your address, and the accrued value is credited to that same address. However, Solana often uses a different paradigm involving Program Derived Addresses (PDAs). PDAs are essentially new accounts that are derived from another account. For example, when you stake SOL with a validator, a staking account is created, derived from your primary account, and the SOL you earn is credited to this new staking account. As a result, it’s not sufficient to track activity on a single account—you must also track all related derived accounts to get a complete picture of what’s happening.

Another layer of complexity in Solana’s model is the concept of slots and blocks. In Solana, time is divided into slots, with each slot intended to produce a single block. However, not every slot results in a block. Some slots are skipped due to network conditions or validator performance issues. This means that while blocks are the containers for transactions, not all slots contain blocks. Skipped slots create gaps in the expected sequence, complicating the process of linking transactions to a continuous timeline.

None of these characteristics prevent us from turing Solana data into consumable information reports, but they do present obstacles that must be understood then carefully addressed inside a platform designed to handle many other blockchains and brokers.

Unique Challenges for Validators

Validators in Solana manage two primary accounts: an identity account and a vote account. A third account is linked to the vote account, used for withdrawing accrued tokens. While the vote account is responsible for casting votes, the identity account (or another associated account) covers the transaction fees. Right away, this makes support for validators different from standard accounts used by individuals.

Voting

Validators perform one of the most critical tasks on the network: validating transactions and casting votes. Each vote costs a small fee, approximately $0.0006 USD. While that may seem immaterial, over time, it accumulates to roughly $51,000 annually. With validators casting hundreds of thousands of votes per day, tracking this expense quickly becomes a significant challenge.

Rent

Early on, Solana introduced a “rent” mechanism to manage on-chain storage efficiently, preventing accounts from consuming storage indefinitely without incurring costs. Validators, responsible for maintaining storage and participating in consensus, received rent as compensation for these services. Though rent has since been effectively removed from Solana, validators who collected rent still face tracking issues. High-performing validators could receive hundreds of thousands of rent payments per day, sometimes amounting to only a few dollars, yet tracking these microtransactions at such volume contributes to the complexity of validator support at NODE40.

Jito Tips

To add even more layers to this already complex system, many Solana validators are supported by Jito’s MEV-Protect, which introduced the concept of tipping. Jito tipping allows users to include priority tips in their transactions, incentivizing validators to prioritize those transactions. These tips are paid out directly to the validator, but only to specific accounts supporting them, creating a new category of transactions/revenue that needs to be tracked. For validators who support Jito, tracking tipping payments—on top of vote fees, rewards, and rent (for those who collected it)—adds another dimension of complexity. This web of financial flows are difficult to manage at scale without highly specialized tracking systems like we built at NODE40.

NODE40’s Core Focus: Financial Reporting

At NODE40, our primary role is to generate comprehensive financial reports that turn the confusion of blockchain activity into clear, actionable insights. These reports include balance sheets, gain/loss statements, transaction summarization and categorization, and unrealized gains—each designed to meet the needs of financial professionals such as CFOs, auditors, accountants, and advisors.

We handle everything from high-frequency validator transactions to individual HODLers, ensuring that our clients’ financial records are accurate and compliant with regulatory standards. This level of data refinement requires technical expertise and a deep understanding of blockchain mechanics as they relate to traditional finance.

NODE40’s sophisticated infrastructure and expertise in handling Solana allow us to build financial statements that make sense to those working in finance. In doing so, we help bridge that gap between blockchains and the practical needs of financial professionals.