1. On-Chain Data Is Not Ready for Use
The digital asset market is advancing rapidly. Stablecoins already process trillions of dollars a year in payments and remittances, and tokenization of traditional assets such as stocks and bonds is gaining momentum. Blockchain’s role now spans the financial value chain, from issuance and distribution to payment and settlement.
The question institutions ask has shifted from whether blockchain works to how to run it within existing accounting, tax, audit, and compliance workflows. Blockchain may sit at a new infrastructure layer, but institutional finance still holds it to the same procedures, controls, and standards.
This shift exposes a data challenge. Legacy systems run on standardized, structured records, but on-chain data is raw execution data, the direct output of state transitions, and institutions must index, decode, and normalize it before they can use it. It looks less like a tidy ledger and more like an unsorted pile of receipts.
Institutions therefore need a dedicated data pipeline that collects transaction data from distributed ledgers, refines it for business use, and stores and retrieves tens of terabytes on demand. On-chain data is public, but public access does not make it usable for institutional operations.
2. On-Chain Data Infrastructure: Reality and Limits
In the early stage of the digital asset market, this data access problem drew limited attention, since most digital asset services were small-scale pilots for a narrow set of participants. JPMorgan’s deposit token project, for example, functioned as a restricted payment instrument for a small group of institutional clients. In an environment where participants and use cases were clearly defined, transaction types stayed simple, and real-time precision carried limited importance.
On-chain data faced a lower bar at the time, since operations did not need every state to match in real time. Eventual consistency, the final state converging after a short delay, was often enough. A limited number of self-hosted nodes, an external RPC (Remote Procedure Call) endpoint, or a basic on-chain data API could support most operational needs in this environment.
This approach breaks down as on-chain environments expand. Asset types have diversified and transaction volumes have grown quickly, and data infrastructure now has to process more data, faster and more accurately. As digital asset services move into full-scale operation, the technical bar has risen from simple data lookup to something far more precise, timely, and reliable.
3. Institutional-Grade On-Chain Data Infrastructure Requirements
This higher bar requires a different standard for evaluating infrastructure. Tiger Research identifies three core requirements for on-chain data infrastructure that institutional finance can trust and use: completeness, consistency, and stability. On-chain data has to meet all three before institutions can actually rely on it in production.
3.1. Completeness: Capturing Every Transaction
Completeness is the most basic requirement for on-chain data infrastructure. It measures whether every transaction recorded on the blockchain ledger is collected and carried through processing without gaps. In institutional finance, a single missing transaction can change a balance calculation, an accounting entry, or a settlement result.
Gaps can first appear at the collection stage. A blockchain groups transactions from a given period into blocks and writes them to the ledger, and data infrastructure collects and processes these blocks in order. If node failures or network issues interrupt block collection for a stretch, the transactions in that stretch go missing along with it. This type of gap is comparatively easy to catch and fix, because a backfill operation can recollect the missing blocks and close the gap.
A second problem arises after infrastructure has collected all the raw block data. An indexer extracts the needed transaction records from that raw data and converts them into a queryable form, and records can be lost here if the parsing is incomplete. Consider indexing token transfer data on Solana, which runs an original token standard alongside an extended standard. An indexer built to parse only the original standard will miss the transfer history of tokens issued under the extended one.
High-performance chains raise the bar for completeness further. Shorter block times and higher transaction throughput both increase the volume of data the pipeline has to process within a short window. Even flawless collection and processing logic can fall behind if real-time processing cannot keep pace with the chain’s speed, and new transactions then take longer to show up. Completeness, in the end, means more than capturing every transaction. It means keeping pace with how fast a chain moves and how often it changes.
3.2. Consistency: Matching the Ledger
While completeness checks for missing data, consistency checks whether the data collected matches the blockchain ledger. It matters just as much as completeness in institutional finance, because a single bad data point can distort every calculation built on it.
On-chain data is probabilistic until finality. Traditional financial systems record and manage data on a central server, while blockchains update the ledger through multiple participants who validate blocks and reach consensus independently. Network delays or differences in validation timing can make two different blocks appear valid at the same time.
A block initially treated as valid can later drop out of the final ledger and get replaced by another, an event known as a reorg. Transactions in the dropped block can then fall out of the final ledger entirely or reappear in a different block. Data collected at one point in time can therefore diverge from the ledger state that is eventually finalized. This is a consistency problem.
Consistency problems can also originate in the node client, the core software that runs a blockchain node and functions much like the blockchain’s operating system. A flaw in this software can produce errors when it interprets and calculates ledger data. Major Ethereum node clients have, in fact, produced errors in transaction processing and fee calculation. This resembles a financial service that misreports a customer’s assets or settles fees incorrectly.
Collecting data alone does not guarantee consistency. Data captured at one point can diverge from the ledger that later finalizes, and node client defects can cause ledger data to be misread. Using on-chain data as institutional finance’s source of truth therefore requires continuously checking the collected data against the ledger.
3.3. Stability: Maintaining Operation at Scale
While completeness and consistency verify data quality, stability checks whether data collection, processing, and retrieval can continue without interruption at scale. This is a non-negotiable requirement in an industry where a single outage or delay can cause serious damage. On-chain infrastructure also runs on a network that never stops, which raises the bar for stability even further.
Large-scale operation means handling many requests at once. Traditional server infrastructure raises throughput through load balancing, which spreads requests across multiple servers. Blockchain infrastructure cannot get the same result just by running multiple nodes, because nodes can sit at different points in block sync and return different results for the same query.
Consider a user checking whether a transaction has processed right after sending it. The node that first received the transaction may have confirmed it, while another node handling the query hasn’t caught up yet. The infrastructure has responded correctly in both cases, but the user sees two different states for the same transaction.
Stability gets harder to maintain as data volume grows. Checking the current state isn’t enough for institutional finance, which also needs to calculate an asset’s state at a specific point in time and trace the transaction history behind it. This requires an archive node that preserves historical records, and depending on the chain, that record can run to tens of terabytes. Storing and querying data at this scale raises the risk of query delays and system bottlenecks.
Ongoing maintenance is another key piece of stability. Blockchains keep changing through hard forks, chain upgrades, and node client updates even while running in production. If the data pipeline can’t keep up with these changes, infrastructure that had been working fine can stop without warning. Stability, in the end, isn’t something a system secures once at launch. It has to be maintained by continuously adapting to changes in the chain environment.
4. Lambda256: On-Chain Data Infrastructure for Institutional Finance
Companies preparing to launch a digital asset business rarely build every layer of infrastructure themselves. Most choose a proven global chain infrastructure and build their business model on top of it. On-chain data infrastructure deserves the same approach, since meeting the completeness, consistency, and stability bar outlined above takes more than building a database.
A complex multi-chain environment requires indexing each chain’s data structure in real time while holding up under heavy traffic. It also demands constant adaptation to new standards and chain upgrades. On-chain data infrastructure isn’t a short development project. It’s closer to a large-scale infrastructure business that takes substantial capital, time, and operational experience.
A proven infrastructure partner lets a company focus on its core business. That’s a more realistic path than building everything in-house. This is why Lambda256 has become a technology partner for major digital asset businesses in Korea. Lambda256, the blockchain technology subsidiary of Dunamu, provides blockchain infrastructure to exchanges, financial institutions, and Web3 companies and has built operational experience in the Korean market along the way.
Building on this experience, Lambda256 launched Nodit, a Web3 development platform, in 2024. Datashare, Nodit’s recently unveiled on-chain data infrastructure product, was built around the data quality and operating standards institutional finance demands. Lambda256 ran a data warehouse version of the service for select partners for more than two years before the official launch, so the infrastructure has already been tested under live conditions.
4.1. Technical Edge: An In-House Indexing Engine and High-Performance Pipeline
Datashare’s technical edge lies in turning fragmented multi-chain data into datasets that fit existing workflows. Each chain has its own data structure and recording method, so collection and processing rules have to be built around each chain’s specifics. New standards and network upgrades keep changing each chain’s operating environment on top of that, and the more that happens, the harder data infrastructure is to manage. Datashare handles these chain-specific differences and ongoing changes through domain experts, an in-house indexing engine, and a high-performance data pipeline.
This structure only holds up if the node infrastructure feeding it raw data holds up too. Datashare runs on Nodit's Hyper Node architecture, which lets it handle heavy request volumes and node failures with flexibility. The Hyper Node architecture maintains a minimum threshold of available nodes and controls latency and recovery thresholds, so a problem on one node doesn't spread through the rest of the collection process. It also keeps running without interruption through mainnet upgrades and node software swaps.
Another key differentiator is that collected data goes through a separate verification process. Datashare checks the data against the chain state on an ongoing basis. It flags discrepancies from reorgs, node client errors, and chain upgrades, and confirms that each transaction’s outcome matches the resulting event record and balance change. This cross-check against the chain cuts data gaps and processing errors and gives Datashare the reliability it needs to serve as a source of truth within existing workflows.
Accuracy alone isn’t enough to put on-chain data to work. Institutions also need broad coverage across chains and data types. Datashare supports 13 core chains with high market demand by default and can extend to custom datasets built on the 50-plus chains Nodit already operates. Lambda256 plans to add labeled data next, combining exchange wallet addresses, DeFi smart contracts, and pricing data. That would extend the use cases beyond accounting and tax into risk management and anomaly monitoring.
4.2. Operational Edge: Compliance and Workflow Integration
Using on-chain data in institutional finance takes compliance, not just data quality. Korean financial institutions in particular apply strict standards, such as network segregation, access controls, and internal network operating rules, when they bring in outside data infrastructure. Datashare supports on-premise deployment within domestic IDCs to meet these requirements and holds SOC 2 certification to back up its security management framework. This lets financial institutions adopt on-chain data within their own security policies and regulatory guidelines.
It also matters that financial institutions can manage where their data lives and who can access it. Datashare supports an architecture that sends on-chain data straight to the cloud storage an institution already uses. It can load on-chain data in real time into an institution’s own environment, AWS S3, for example, so institutions get an outside infrastructure solution while keeping data management and access control in-house.
Datashare also plans to keep strengthening its integration with the data analysis tools financial institutions already run. It supports major data warehouses and analytics platforms such as Snowflake, BigQuery, and Databricks, so on-chain data connects organically into existing workflows.
Lambda256’s operational support is another strength. On-chain data infrastructure runs on a blockchain network that never stops, so catching and responding to outages or delays quickly matters. Datashare provides round-the-clock monitoring and dedicated technical support through a domestic team, and this cuts the operational load financial institutions would otherwise carry themselves. Institutions can then manage and use on-chain data reliably without significantly expanding their own blockchain infrastructure teams.
5. Where On-Chain Data Infrastructure Matters
Scenario 1: Tracking On-Chain Holders of Tokenized Stocks
A growing number of institutions are issuing listed stocks on chain as tokens alongside their traditional listings. Galaxy Digital, a global digital asset firm, tokenized its common stock as $GLXY and issued it on Solana. Securitize, an asset tokenization company, issued its own stock ($SECZ) on Solana the same day it listed on the NYSE. Solana’s speed and low cost have made it the go-to infrastructure for financial firms tokenizing listed stocks in a regulatory-compliant form.
Institutions handling both traditional assets and on-chain tokenized securities face a new operational challenge. Broker-dealers need to track token holders and beneficial owners on the blockchain accurately and prove that record to regulators and auditors. This work repeats not just at closing but at every dividend record date and voting record date. Missing data or a miscalculated balance at any of these points can lead to serious risks, including misdirected payments, disclosure errors, and failed audits.
The problem is that Solana’s data structure makes this hard. Solana wins on cost and speed, but it stores transaction records across a large number of separate accounts. A single DeFi transaction can scatter data across token accounts, liquidity pools, and fee accounts. Solana’s archive nodes also hold hundreds of terabytes of accumulated data, which makes it impractical for most institutions to reconstruct historical holder records and transaction history at a given point in time on their own.
Integrating Solana-based tokenized assets into institutional finance therefore requires data infrastructure built for immediate analysis, with no further processing needed. Datashare refines fragmented source data into a normalized form institutions can query directly in their existing data warehouses. It has optimized its pipeline for Solana's sub-0.4-second block times, which gives it the throughput to process roughly 20,000 transactions per second per chain in real time and keeps indexing delay to a minimum.
Scenario 2: Risk Management in Agentic Payment Settlement
A market for agentic payments, where AI agents decide and execute payments on a user’s behalf, is emerging. Since Coinbase launched its on-chain payment protocol x402, stablecoin-based autonomous payment infrastructure has picked up real momentum.
For agent-to-agent autonomous payments to work as a commercial financial service, the quality of the on-chain data behind each decision matters above all else. As human review drops out of the loop, the system has to judge available balance, transaction finality, and fraud risk from data alone. Missing or distorted on-chain data at this stage can cause serious errors across both payment approvals and rejections.
Several concrete factors in real blockchain environments drive this kind of data loss and distortion. The most significant is transactions that fail to execute. Depending on network congestion, more than 20% of all blockchain transactions fail, and on Solana specifically, the failure rate among non-vote transactions can exceed 40%.
If a payment system mistakes one of these failed transactions for a successfully processed one, it treats the balance as reduced even though no payment actually went through, then rejects the next payment over a balance mismatch that shouldn’t exist. Block reorgs are another critical factor that deepens this distortion, because a transaction that looked approved at one point can later get cancelled and pulled from the record.
To address this reliability problem at the source, Datashare filters for data with confirmed finality and supplies payment systems only with transactions confirmed as successful. It runs unconfirmed transactions and failure records from the raw blockchain data through real-time verification at the pipeline stage and indexes and delivers only the refined dataset. This removes the risk of malfunction from on-chain distortion.
Datashare is also extending its coverage to major local blockchains at home and abroad, such as GIWA and Kaia, which broadens its business versatility. This matters because it gives agentic payment infrastructure a stable data foundation that isn’t locked into a single global mainnet, and lets it adapt flexibly to each region’s service environment and regulatory requirements.
6. Conclusion
A digital asset business succeeds or fails on how accurately it handles data, because on-chain data now underpins every financial process, from issuance to payment to settlement. Missing or incorrect data can therefore erode trust in a service and trigger serious regulatory risk. Datashare functions as the infrastructure that reduces this operational risk and connects institutional finance to on-chain data it can actually use in its workflows.
Financial institutions can also extend their systems with Lambda256’s other financial technology solutions beyond Datashare. SCOPE, for digital asset settlement and operations, and CLAIR, for regulatory compliance, can be added as the business grows and build out a more complete system over time. This lets institutions add the functions they need in stages, without rebuilding their infrastructure from scratch.
As a result, financial institutions can offload complex infrastructure management and system maintenance and focus on their core business, service innovation and product differentiation. It lowers the barrier to entry while giving institutions a stable way to add capabilities as the business grows and regulations change.
This report was produced with the support of Lambda256.
Nodit, featured in this report, is Lambda256's SOC 2 Type II–certified on-chain data infrastructure. For consultation or inquiries about adopting the solution, please use the button below.
Disclaimer
This report was partially funded by Lambda256. It was independently produced by our researchers using credible sources. The findings, recommendations, and opinions are based on information available at publication time and may change without notice. We disclaim liability for any losses from using this report or its contents and do not warrant its accuracy or completeness. The information may differ from others’ views. This report is for informational purposes only and is not legal, business, investment, or tax advice. References to securities or digital assets are for illustration only, not investment advice or offers. This material is not intended for investors.
Terms of Usage
Tiger Research allows the fair use of its reports. ‘Fair use’ is a principle that broadly permits the use of specific content for public interest purposes, as long as it doesn’t harm the commercial value of the material. If the use aligns with the purpose of fair use, the reports can be utilized without prior permission. However, when citing Tiger Research’s reports, it is mandatory to 1) clearly state ‘Tiger Research’ as the source, 2) include the Tiger Research logo following brand guideline. If the material is to be restructured and published, separate negotiations are required. Unauthorized use of the reports may result in legal action
