The gateway to digital assets: on-chain data infrastructure

Author: Jay Jo | Source: Tiger Research | Translation: Shan OBA, Jinse Finance

I. On-chain data does not yet meet institutional commercial-use requirements

The digital asset market is developing rapidly; the annual transfer and remittance volumes for stablecoins have already reached several tens of trillions. The tokenization process of traditional assets such as stocks and bonds continues to accelerate. Blockchain now runs through the entire value chain of finance, covering asset issuance, distribution, payments, and settlement and clearing.

The core issues that institutions focus on have shifted. It is no longer about whether blockchain technology can be implemented; it is about how to embed it into existing accounting, tax, audit, and compliance workflows. Although blockchain is a brand-new underlying infrastructure, institutional finance still requires it to follow unified business processes, internal control mechanisms, and industry standards.

The shift in demand exposes clear data pain points. Traditional systems rely on standardized structured records, while on-chain data is only raw execution information—direct output of state changes in the ledger. Institutions must index, parse, and standardize the data before it can be put to use. On-chain data is more like a pile of disorderly transaction receipts than a neatly organized financial ledger.

Institutions therefore need a dedicated data pipeline: capture transaction data from the distributed ledger, complete cleansing and processing at the business layer, and store and retrieve data on demand at the scale of dozens of TB. Although on-chain data is publicly readable, data being public does not equal being able to meet institutional business deployment requirements.

II. On-chain data infrastructure: current state and limitations

In the early days of digital asset development, the problem of data acquisition was not taken seriously. At that time, most related businesses were aimed at niche participants and carried out small-scale pilots. For example, JPMorgan’s deposit token project provided limited payment tools only to a small number of institutional clients. The boundaries of participating entities and application scenarios were clear; transaction types were simple, and the demand for real-time data accuracy was not high.

In the early stage, the on-chain data threshold was relatively low. Business operations did not require all ledger states to be synchronized in real time; after a brief delay, final consistency (finality) could basically meet requirements. A small number of self-built nodes, third-party RPC interfaces, or basic on-chain data APIs were enough to support most operational scenarios.

But as the on-chain ecosystem continues to expand, this approach gradually becomes ineffective. Asset types keep increasing and transaction volumes grow rapidly, requiring the data infrastructure to process massive information faster and more accurately. Once digital-asset businesses move toward large-scale operations, industry technical requirements upgrade from simple data queries to high standards for timeliness, accuracy, and reliability.

III. Three core standards for institutional-grade on-chain data infrastructure

Higher business requirements mean a need to establish an entirely new infrastructure evaluation system. Tiger Research believes that on-chain data infrastructure usable for institutional finance must simultaneously meet three indicators—completeness, consistency, and stability—without any one of them missing.

3.1 Completeness: fully capture every transaction

Completeness is the most fundamental metric. It measures whether every transaction on the blockchain can be fully collected and continuously processed, with no data gaps. In institutional business, missing even a single transaction can cause errors in balance accounting, distorted accounting entries, and deviations in settlement results.

Data gaps first commonly occur in the collection stage. Blockchain packages transactions within a period into blocks and writes them to the ledger; infrastructure collects block data in sequence. Once a node fails or the network disconnects and block collection pauses, all transactions within that interval are synchronously lost. Such gaps are relatively easy to repair and can be filled by backfilling missing blocks.

The second vulnerability occurs after the original block data has been fully collected. An indexer extracts transaction records from raw data and converts them into query-friendly formats. If the parsing logic is not perfect, it can also cause records to be lost. Taking Solana data indexing as an example: native token standards and extended token standards both exist on-chain. If an indexer only supports the native standard, transfer records for tokens issued under the extended standard will be completely omitted.

High-performance public chains further raise the difficulty of achieving completeness. Shorter block intervals and higher transaction throughput require the data pipeline to process massive data within extremely short time windows. Even if the collection and parsing logic has no defects, if real-time processing speed cannot keep up with the chain’s block production cadence, new transaction data will be delayed in being stored. In short, completeness is not only about capturing all transactions; it also requires continuously matching the public chain’s operating speed and protocol iteration changes.

3.2 Consistency: data fully matches the on-chain ledger state

Completeness checks whether data is missing. Consistency checks whether collected data remains unified with the on-chain ledger; both are equally critical. Any incorrect piece of data will distort all downstream accounting results derived from it.

Before final confirmation lands, on-chain data has probabilistic characteristics. Traditional financial systems record data via centralized servers; blockchains let multiple parties independently validate blocks and reach consensus to update the ledger. Network latency and differences in validation timing can lead to multiple seemingly valid blocks appearing temporarily.

A block deemed valid at one stage may later be removed from the ledger, or replaced and covered by a different block—i.e., a chain reorganization (Reorg). Transactions in the eliminated blocks either disappear entirely from the final ledger or move to other blocks. Data captured at a specific time point will therefore deviate from the ultimately finalized ledger, creating a consistency risk.

Consistency problems can also originate from node client software—the core program that runs the blockchain, akin to a blockchain operating system. Bugs in the client can cause errors in ledger data parsing and computation. Mainstream Ethereum clients have repeatedly seen anomalies in transaction processing and fee accounting—equivalent to a financial institution misreporting customer assets and wrongly calculating clearing fees.

Collecting data alone cannot guarantee consistency. Snapshot-captured data may differ from the final ledger, and client defects can also cause ledger interpretation deviations. To use on-chain data as a trusted data source for institutional finance, it is necessary to continuously cross-validate against the on-chain ledger.

3.3 Stability: uninterrupted operation in large-scale scenarios

Completeness and consistency measure static data quality. Stability examines whether the collection, processing, and query workflows can continue to run uninterrupted under large-scale load. In the financial industry, a single service interruption or data latency can cause major losses; the 7×24 uninterrupted operation characteristic of blockchain further raises stability requirements.

Large-scale business implies massive concurrent requests. Traditional servers use load balancing to distribute requests and increase throughput, but blockchain infrastructure cannot simply replicate this pattern: each node may be at a different block synchronization progress, and the same query can return differentiated results. For example: after a user initiates a transfer and immediately queries transaction status, the node that first receives the transaction may show it as confirmed, while another node has not finished synchronization yet. The infrastructure returns results that are individually correct, but the user sees two different states for the same transaction.

As data volume keeps growing, the difficulty of maintaining stability increases continuously. Institutional finance not only needs to query the real-time ledger, but also to backtrack asset states at specific time points and the full transaction history. Therefore it must rely on archival nodes to store massive historical data; for some public chains, the archival data size can reach dozens of TB. Massive data storage and querying easily cause interface latency and system performance bottlenecks.

Ongoing iterative maintenance is also a key factor for stability. Public chains continuously undergo hard forks, network upgrades, and client version iterations. If the data pipeline cannot synchronize and keep up with these changes, infrastructure that was previously operating normally may fail without warning. Stability cannot be achieved once and then completed; it requires continuous adaptation to on-chain environment changes and long-term dynamic maintenance.

IV. Lambda256: on-chain data infrastructure for institutional finance

Enterprises rarely choose to build full-stack infrastructure for digital-asset businesses from scratch. Most adopt mature public-chain infrastructure layers and build services on top of them. The same applies to on-chain data infrastructure: achieving the standards of completeness, consistency, and stability cannot be done by simply deploying a database.

In a multi-chain environment, it is necessary to parse each chain’s differing data structures in real time while also carrying high-concurrency traffic and continuously adapting to new standards and on-chain upgrades. On-chain data infrastructure is not a short-term development project; it is more like a capital-heavy, long-cycle, large infrastructure business with a high dependence on operational experience.

By choosing a mature infrastructure service provider, enterprises can focus on core business. Compared with self-development, it is more realistic and feasible. This is also why Lambda256 has become a technical cooperation partner for many leading South Korean digital asset enterprises. Lambda256 belongs to the Dunamu Group. It provides blockchain infrastructure for exchanges, financial institutions, and Web3 companies, and has accumulated deep operational experience in the South Korean market.

Building on industry experience, Lambda256 launched a Web3 development platform, Nodit, in 2024. The platform’s latest release is an on-chain data infrastructure product called Datashare, built entirely around institutional finance’s data-quality and operational standards. Before official commercial use, the Datashare data warehouse version had been piloted with partner customers for two years, fully validated through real business scenarios.

4.1 Technical advantages: self-developed indexing engine and high-performance data pipeline

Datashare’s core technical strength lies in converting fragmented multi-chain raw data into standardized datasets that can directly integrate with existing business systems. Each public chain has unique data structures and accounting rules, so collection and parsing logic must be specifically customized. On top of that, as new protocol standards emerge and networks keep upgrading, operational complexity increases further. Datashare relies on a professional R&D team, a self-developed indexing engine, and a high-performance data pipeline to handle each chain’s differentiated characteristics and ongoing iteration needs.

The prerequisite for the entire system to run stably is reliable upstream raw node services. Datashare relies on the Nodit Hyper Node node architecture to flexibly handle massive requests and manage node single-point failures calmly. Hyper Node maintains a minimum threshold of available nodes, controls latency and failure-recovery indicators, so anomalies at a single node do not propagate to the entire data collection chain. It can also provide uninterrupted service during main-net upgrades and client version swaps.

Another differentiated capability: independent data-collection verification is added throughout. Datashare continuously cross-validates against the on-chain ledger state to identify data discrepancies caused by chain reorgs, client anomalies, and chain upgrades, ensuring that each transaction’s execution results, event logs, and balance changes match each other. Multi-level on-chain validation effectively reduces data omissions and parsing errors, enabling it to be used as a trusted data source embedded into institutional existing business workflows.

Accuracy alone is not enough to unlock on-chain data value; institutions also need broad coverage of public chains and data types. Datashare defaults to support 13 market-leading public chains. Leveraging the 50+ public-chain resources already covered by Nodit, customized datasets can be expanded quickly. Lambda256 plans to later launch labeled data services, integrating exchange wallet addresses, DeFi contract data, and market price information—expanding application scenarios from accounting and tax to risk management and anomalous transaction monitoring.

4.2 Operational advantages: compliance capabilities and deep integration with business systems

For institutional finance to deploy on-chain data, compliance capabilities and data quality are equally important. Especially when South Korean financial institutions introduce external infrastructure, they strictly require network isolation, permission control, and internal network operations standards. Datashare supports local deployment in local IDC data centers to meet regulatory requirements, and it also holds SOC 2 certification,完善安全管理体系, making it convenient for financial institutions to use on-chain data within their own risk-control and regulatory frameworks.

Autonomous control over data ownership and access permissions is crucial for financial institutions. Datashare supports an architecture direct-transmission mode: on-chain data is pushed directly to the enterprise’s own cloud storage, such as AWS S3. When enterprises choose third-party infrastructure, they still fully retain data management rights and access control rights.

The product continuously strengthens integration capabilities with mainstream data analytics tools. It natively supports data warehouses and analytics platforms such as Snowflake, BigQuery, and Databricks, enabling on-chain data to seamlessly integrate into existing business workflows.

Lambda256’s accompanying operational support is also competitive. Blockchains run without休眠. Quickly discovering and handling interruptions and latency is critical. Datashare provides a local team with 7×24 monitoring and dedicated technical support, significantly reducing the burden on financial institutions that would otherwise build and operate their own blockchain operation teams, enabling stable usage of on-chain data at low cost.

V. Core on-chain data infrastructure deployment scenarios

Scenario 1: Tracking tokenized stock on-chain shareholder ledgers

More and more institutions are issuing stock tokenized on-chain alongside listing on traditional exchanges. Galaxy Digital, a global digital asset group, has tokenized ordinary shares: GLXY发行于Solana; SECZ is tokenized stock issued on Solana on the day asset tokenization service provider Securitize listed on the NYSE. Solana’s low costs and high speed make it the preferred underlying layer for compliant security tokenization.

Meanwhile, institutions that operate both traditional securities and on-chain token securities face new operational challenges: broker-dealers need to accurately track on-chain token holders and beneficial owners, and submit complete ledgers to regulators and audit institutions. Share registration not only happens at market close after listing; on the dividend and record date, as well as on shareholder meeting voting registration days, complete data is also required. Missing any node’s data or errors in balance accounting can lead to major risks such as mis-sent dividends, violations of information disclosure rules, and failed audits.

The difficulty lies in Solana’s unique data architecture. Although transaction costs are low and confirmation is fast, transaction records are stored dispersed across many independent accounts. Data from a single ordinary DeFi interaction gets distributed across token accounts, liquidity pools, and fee accounts. Solana archival node data can reach hundreds of TB, making it hard for institutions to independently backtrack holder lists and complete transaction histories at any arbitrary time point.

To bring Solana token assets into an institutional system, it is necessary to rely on a data infrastructure that can be analyzed immediately without further reprocessing. Datashare cleans fragmented raw data into standardized formats that can directly connect to the institution’s own data warehouse queries. The product pipeline is deeply optimized for Solana’s block production cycle below 0.4 seconds. Its real-time processing capacity per chain is about 20 thousand TPS, minimizing indexing latency as much as possible.

Scenario 2: AI autonomous payment settlement and clearing risk management

The autonomous payment track—where AI agents initiate payments on behalf of users—is emerging. After Coinbase launched the on-chain payment protocol x402, it has accelerated adoption through automated payment infrastructure based on stablecoins.

For autonomous payments to be commercialized, the quality of on-chain data behind the decision-making is the lifeline. Once manual review is removed, the system can only rely on data to judge available balances, transaction finality, and fraud risk. Missing or distorted data directly causes wrong payment approval decisions.

In real on-chain environments, multiple factors can easily cause data anomalies. The most prominent is transaction execution failure. Due to network congestion, the overall on-chain transaction failure rate is generally higher than 20%; Solana’s failure rate for non-vote transactions is even higher than 40%.

If a payment system mistakenly identifies failed transactions as successful transfers, it will incorrectly deduct balances on the books. Later normal payments will then be intercepted due to balance validation anomalies. Chain reorganization is another major risk: transactions that were once confirmed can later be revoked and removed from the ledger, easily causing chaos in fund reconciliation.

Datashare addresses reliability defects from the source: it only delivers valid transactions that have completed final confirmation to the payment system. At the pipeline stage, it distinguishes unconfirmed and failed transactions in real time. Only indexed outputs that have been verified are included as standardized datasets, avoiding business failures caused by on-chain data distortion.

The product continues to expand coverage of major domestic and overseas public chains such as GIWA and Kaia, improving solution generality. With this, autonomous payment infrastructure obtains stable and diversified data foundations—it is not limited to a single public chain and can flexibly adapt to business scenarios and regulatory rules across regions.

VI. Conclusion

The success or failure of digital-asset businesses highly depends on the precision of data processing. On-chain data runs through the entire financial workflow, including issuance, payments, and clearing settlement. Missing or distorted data not only damages business credibility but also brings serious compliance risks. As an infrastructure, Datashare effectively reduces these operational risks and removes barriers between institutional finance and usable on-chain data.

Besides Datashare, financial institutions can also choose Lambda256’s other fintech products: the digital asset clearing operations platform SCOPE and the compliance monitoring tool CLAIR. Enterprises can stack additional functions step by step as the business develops, without having to rebuild the entire infrastructure from scratch.

With this, financial institutions can outsource the heavy work of infrastructure building and operations, focus on core business, and drive innovation in services and product differentiation. While lowering the entry barrier, they can progressively improve technical capabilities as business scale and regulatory changes evolve.