Gateway to Digital Asset Services: On-Chain Data Infrastructure - Tiger Research

1. The Wall Faced by Digital Assets: Unfriendly On-Chain Data {#rps-1}

The digital asset market is rapidly evolving. Stablecoins are already processing transactions worth trillions of dollars annually and are being utilized in payment and remittance sectors, while the tokenization of traditional financial assets such as stocks and bonds is gaining momentum. This indicates that the role of blockchain technology is expanding across the entire financial value chain, from asset issuance and circulation to payment and settlement.

Blockchain has now moved beyond the stage of discussing possibilities to the stage of building practical infrastructure. Consequently, the focus of discussions has shifted from proving the necessity of technology adoption to how it will be operated within institutional finance. In particular, the challenge lies in how to integrate blockchain infrastructure with existing workflows in accounting, taxation, auditing, and compliance. Even if blockchain operates as a new foundational infrastructure, the procedures and standards required by institutional finance remain unchanged.

The problem is that integrating blockchain infrastructure into existing financial workflows is complicated. Legacy financial systems operate based on standardized structured data, while on-chain data is closer to raw data that requires separate indexing, decoding, and normalization processes. It is akin to a massive pile of unclassified receipts rather than a well-organized accounting ledger.

Therefore, a separate data pipeline is essential to utilize on-chain data. Transaction records must be collected from distributed ledgers and refined for specific purposes. Furthermore, infrastructure must be established to reliably store tens of terabytes of data and quickly retrieve it when needed. Ultimately, while on-chain data is publicly available, it is not easily usable on its own.

2. The Reality and Limitations of Building On-Chain Data Infrastructure {#rps-2}

However, in the early stages when the scale and utilization of the digital asset market were limited, these data accessibility issues were not prominently highlighted. Most digital asset services were akin to small-scale experiments targeting a limited number of participants. For instance, JP Morgan's deposit token project was a limited payment method designed for a small number of institutional clients. In environments where participants and usage purposes were clear, the types of transactions to be processed were simple, and the real-time nature or precision of data was not particularly critical.

At that time, the criteria required for on-chain data were relatively lenient. Even if all states did not strictly match in real-time, as long as consistency was ultimately achieved after a certain period, there were no significant operational issues. In other words, a processing method based on eventual consistency was sufficiently acceptable. In such environments, it was possible to respond adequately by operating limited nodes or integrating external RPC endpoints or simple on-chain data APIs.

However, as the on-chain environment expanded, it became increasingly difficult to manage with existing methods. The variety of asset classes being handled and the rapid increase in transaction volumes significantly expanded the scope of data processing. Consequently, the technical requirements that data infrastructure must meet have evolved beyond simple query levels to more sophisticated forms that guarantee real-time capabilities. As it enters a full operational phase, the standards required for infrastructure have fundamentally changed.

3. Requirements for On-Chain Data Infrastructure for Institutional Finance {#rps-3}

To meet these heightened requirements, the criteria for evaluating infrastructure must also change. Tiger Research presents three core criteria for on-chain data infrastructure that institutional finance can trust and utilize: Completeness, Consistency, and Stability. These are essential requirements that on-chain data must meet to function as the standard ledger for actual services.

3.1. Completeness: Are All Transaction Records Included? {#rps-4}

Completeness is the most fundamental requirement of on-chain data infrastructure. It is the criterion for determining whether all transaction records recorded in the blockchain ledger are collected without omission and whether they are reflected without missing in subsequent processing. In institutional finance, even a single missing transaction can alter balance calculations, accounting processes, and settlement results.

Data omissions can occur first at the collection stage. The blockchain records transactions that occur over a certain period in blocks. The data infrastructure collects and processes these blocks in order. However, if the collection of blocks for a specific interval is interrupted due to node failures or network issues, the transaction records included in that interval may also be omitted. However, omissions at the collection stage can be relatively clearly identified and addressed. Data can be filled in through backfill operations that re-collect the omitted block intervals.

Another issue arises during the processing stage after all original block data has been collected. An indexer extracts the necessary transaction records from the original data and converts them into a queryable format. If the data is not parsed correctly at this stage, some records may be lost during processing. For example, suppose we are indexing token transfer data from Solana. Solana has both existing token standards and extended standards. If the indexer is designed to parse only the existing standard, the movement history of tokens issued under the extended standard may be omitted.

In high-performance chains, the burden of maintaining completeness increases. The shorter the block generation cycle and the higher the transaction throughput, the greater the amount of data that the data pipeline must process in a short time. Even if there are no defects in the collection and processing logic itself, if real-time processing cannot keep up with the speed of the chain, the reflection of transaction records that occurred in the meantime may be delayed. Ultimately, completeness must go beyond merely obtaining data without omissions; it must continuously respond to changes and speeds of the chain.

3.2. Consistency: Is the Collected Data Accurate? {#rps-5}

While completeness verifies the absence of data omissions, consistency is the criterion for determining whether the collected data matches the blockchain ledger. In institutional finance, consistency is as important as completeness. If a single piece of data is incorrect, all calculations and judgments based on it can also be distorted.

In blockchain, the process of finalizing the ledger can lead to temporary discrepancies in data. Traditional financial systems record and manage data based on a central server, while blockchain allows multiple participants to validate blocks and update the ledger through consensus. During this process, network delays or differences in validation timing can create situations where different blocks appear to be valid simultaneously.

In this process, a block initially treated as valid may later be excluded from the final ledger and replaced by another block, leading to a block reorganization (Reorg). At this point, transactions included in that block may be excluded from the final ledger or included again in another block. This can result in inconsistencies as the data collected at a specific point in time may differ from the finalized ledger state.

Inconsistency issues can also arise at the node client level. The node client is the core software that operates blockchain nodes, akin to the operating system (OS) of the blockchain. If there are defects in this software, errors may occur in the process of interpreting and calculating ledger data. In fact, there have been instances of errors in transaction processing or fee calculations in major Ethereum node clients. This is similar to incidents in financial services where customer assets are misrepresented or fees are incorrectly settled.

Thus, the integrity of on-chain data cannot be guaranteed merely by collecting data. The data collected at a specific point in time may differ from the finalized ledger, and defects in the node client may lead to misinterpretation of ledger data. Therefore, to utilize on-chain data as standard data in regulated finance, it is essential to continuously compare and verify that the collected data matches the ledger.

3.3. Stability: Is it stable in large-scale operational environments?

If completeness and integrity are the criteria for verifying data quality, stability is the criterion for determining whether data collection, processing, and querying can continue without interruption in large-scale operational environments. Given the industry characteristics where even a single failure or delay can lead to catastrophic impacts, this is a non-negotiable requirement. Particularly, on-chain infrastructure is predicated on a network that does not stop 24/7, so the requirements for stability are inherently higher.

In large-scale operational environments, many requests must be processed simultaneously. In traditional server infrastructure, load balancing can increase throughput by distributing requests across multiple servers. However, in blockchain infrastructure, merely operating multiple nodes does not guarantee the same effect. The synchronization timing of blocks across nodes may differ, leading to different results being returned for the same query request.

For example, suppose a user queries the processing status immediately after sending a transaction. The first node that received the request may have confirmed the transaction, but another node that received the query request may not have reflected it yet. In this case, even if the infrastructure responds normally, the user may see different states for the same transaction.

As the volume of data increases, ensuring stability becomes more challenging. In regulated finance, merely confirming the latest state is not sufficient. It is necessary to assess the asset state at a specific point in time and verify the transaction history that led to that state. To achieve this, an archive node that preserves historical records is required, but depending on the chain, this can amount to tens of terabytes. In environments where vast amounts of data must be stored and queried, the likelihood of query delays and system bottlenecks also increases.

Continuous maintenance is also a crucial requirement for stability. Blockchain continues to evolve with hard forks, chain upgrades, and node client updates even while in operation. If the data collection and processing pipeline fails to adapt to these changes, even infrastructure that was previously functioning normally can come to a halt in an instant. Ultimately, stability cannot be secured merely through initial construction; it must be maintained by continuously responding to changes in the chain environment.

4. Lambda256: On-chain Data Infrastructure for Regulated Finance

It is rare for companies preparing for digital asset businesses to independently build all foundational infrastructure. Typically, they choose globally proven chain infrastructure and refine their business models on top of it. The on-chain data infrastructure should also be viewed from this perspective. The on-chain data infrastructure, equipped with the aforementioned completeness, integrity, and stability, is not simply a task of building a database.

In a complex multi-chain environment, fragmented data must be indexed in real-time according to different data structures for each chain, while maintaining high stability and processing performance even under high traffic. Additionally, continuous adaptation is required whenever new standards or chain upgrades occur. Ultimately, on-chain data infrastructure is not a short-term development task but rather a large-scale infrastructure project that demands substantial capital, time, and practical operational experience.

Therefore, from a corporate perspective, it is more practical to select a verified infrastructure partner and focus on core business rather than developing all infrastructure independently. This is the background behind Lambda256 becoming a technical partner for major domestic digital asset businesses. Lambda256, a blockchain technology subsidiary of Dunamu, provides blockchain infrastructure to exchanges, financial institutions, and Web3 companies, accumulating operational experience in the domestic market.

Based on this experience, Lambda256 launched the Web3 development platform 'Nodit' in 2024. The recently unveiled 'DataShare' is an on-chain data infrastructure product of Nodit, designed with consideration for the data quality and operational environment required by regulated finance. Notably, it has provided data warehouse services to some partners for over two years prior to its official release, indicating that it has already undergone validation in real-world environments.

4.1. Technical Differentiation: Proprietary Indexing Engine and High-Performance Data Pipeline

The technical differentiation of DataShare lies in its ability to provide fragmented data from a multi-chain environment as datasets that fit existing workflows. In a multi-chain environment, the data structure and recording methods differ for each chain, so the criteria for collection and processing must be designed according to the characteristics of each chain. Furthermore, as the operational environments of each chain continue to change with the introduction of new standards or network upgrades, the management complexity of the data infrastructure increases. DataShare has a structure capable of continuously responding to these chain-specific differences and operational changes, supported by domain knowledge, specialized personnel, a proprietary indexing engine, and a high-performance data pipeline. More detailed information about the technical differentiation of DataShare can be found in an article co-authored by Lambda256 and Discypher (Seoul National University Blockchain Technology Society).

To ensure that this structure operates stably, the node infrastructure environment that retrieves the source data must also be supported. DataShare operates on the Hyper Node architecture of Nodit, allowing it to flexibly respond to large-scale requests or node failures. It manages the minimum available node criteria and controls latency and recovery thresholds to prevent issues with specific nodes from spreading throughout the entire collection process. Additionally, it is designed to respond without interruption to environmental changes such as mainnet upgrades or node software replacements.

Another significant differentiator of DataShare is that the collected data undergoes a separate verification process. DataShare continuously verifies through its own validation process whether the collected data matches the actual chain state. This process checks for block reorganization, node client errors, and data discrepancies that may arise after chain upgrades, ensuring that the processing results of individual transactions are consistently reflected in event records and balance changes. In other words, by cross-verifying the recorded content on the chain with the processed results from DataShare, it reduces data omissions or processing errors and secures reliability that can be utilized as benchmark data in existing workflows.

However, to utilize on-chain data in actual operations, it is essential not only to ensure the accuracy of the data but also to provide a wide range of necessary chains and data types. DataShare currently supports 13 core chains that are in high market demand and can also support customized dataset expansions based on over 50 multi-chains operated by Nodit. In the future, it plans to provide labeled data that combines exchange wallet addresses, DeFi smart contracts, and price data, thereby broadening its application scope beyond accounting and taxation to risk management and abnormal transaction monitoring.

4.2. Operational Differentiation: Compliance Response and Integration with Existing Workflows

To utilize on-chain data in institutional finance, it is crucial to meet not only the quality of the data but also compliance requirements. In particular, the domestic financial sector has strict standards for introducing external data infrastructure, such as network separation, access control, and internal network operation criteria. DataShare supports on-premise construction within domestic IDC, considering these environments, and has secured reliability in its security management system through SOC2 certification. This enables financial institutions to adopt on-chain data in accordance with their internal security policies and regulatory guidelines.

It is also important that financial institutions can directly manage the storage location and access rights of the data. DataShare supports an architecture that directly transmits on-chain data to the cloud storage used by financial institutions. For example, by loading on-chain data in real-time into the institution's internal data environment, such as AWS S3, it allows the institution to maintain control over data management and access control while utilizing external infrastructure solutions.

Furthermore, DataShare plans to continuously enhance interoperability with the data analysis environments that financial institutions currently use. By supporting integration with major data warehouses and analysis platforms such as Snowflake, BigQuery, and Databricks, the goal is to ensure that on-chain data can be organically connected to existing workflows.

The operational support system of Lambda256 is also a strength of DataShare. Since the on-chain data infrastructure is based on a blockchain network that operates 24/7, the ability to quickly detect and respond to failures or delays is crucial. DataShare provides continuous monitoring and dedicated technical support through domestic professionals, reducing the operational burden that financial institutions must bear directly. This allows financial institutions to manage and utilize on-chain data reliably without significantly expanding their separate blockchain infrastructure organization.

5. Moments When On-Chain Data Infrastructure is Needed

Scenario 1: Accurately Tracking Tokenized Stocks and On-Chain Holders

In institutional finance, there is an increasing trend of issuing listed stocks in token form on-chain simultaneously. A representative example is Galaxy Digital, a global digital asset company, which tokenized its common stock ($GLXY) and issued it on the Solana blockchain. Asset tokenization company Securitize also issued its stock ($SECZ) on Solana simultaneously with its listing on the New York Stock Exchange (NYSE). Solana, with its fast processing speed and low costs, has been chosen as a key infrastructure for financial firms looking to tokenize listed stocks in a compliant manner.

Financial institutions handling both traditional assets and on-chain token securities face new operational challenges. Securities firms must accurately track the token holders recorded on the blockchain and prove this to regulatory authorities and auditors. This is a core task that recurs not only at the time of settlement but also on dividend record dates and voting rights calculation dates. If data is omitted or the balance at a specific point in time is incorrectly calculated, it can lead to critical risks such as overpayments, disclosure errors, and failures in audit responses.

The problem is that Solana's unique data structure complicates these financial tasks. While Solana is advantageous in terms of cost and speed, it has a structure where transaction records are distributed across numerous accounts. Even a single DeFi transaction can fragment data across token accounts, liquidity pools, and fee accounts. Given that the cumulative data size of Solana's archive nodes can reach hundreds of terabytes, reconstructing the holder status and transaction history at a specific point in the past becomes a significant challenge for individual institutions to manage directly.

Therefore, to integrate tokenized assets based on Solana into institutional finance, a data infrastructure that can be analyzed immediately without processing is essential. DataShare refines fragmented source data and provides it in a normalized form that can be queried immediately from the existing data warehouse of financial institutions. In particular, by optimizing the pipeline for a high-speed environment with a block generation cycle of less than 0.4 seconds, it has secured a performance base capable of processing approximately 20,000 transactions per second in real-time per chain, minimizing indexing delays.

Scenario 2: Agentic Payment and Risk Management Issues in On-Chain Transactions {#rps-12}

The market for Agentic Payment, where AI agents determine and execute payments on behalf of users, is emerging. Following the launch of the on-chain payment protocol x402 by Coinbase, the establishment of autonomous payment infrastructure based on stablecoins is also gaining momentum.

However, for autonomous payments between agents to become a viable financial service, the quality of on-chain data that serves as the basis for judgment is paramount. As human verification processes decrease, the system must determine available balances, transaction confirmations, and potential anomalies solely based on data. If on-chain data is missing or distorted during this process, it could lead to critical errors in payment approvals and rejections.

So, what are the specific factors causing such data omissions and distortions in real blockchain environments? One of the most representative causes is failed transactions. Depending on network congestion, over 20% of total transactions can fail, and in the case of Solana, the failure rate for non-vote transactions can exceed 40%.

If the payment system misinterprets these failed transactions as successfully processed, it may determine that a balance has been deducted even though no actual payment occurred, leading to a balance mismatch error that results in future payment rejections. Additionally, the phenomenon of block reorganization, where transactions that appeared to be approved at a certain point are canceled later, also acts as a critical variable that exacerbates data distortion.

DataShare aims to fundamentally resolve these data reliability issues by supplying only data that has achieved finality and confirmed success to the payment system. It verifies unconfirmed transactions or failure records included in the blockchain's raw data in real-time at the pipeline stage and provides only refined datasets, thereby alleviating concerns about malfunctions due to on-chain distortions.

Furthermore, it continues to expand its support scope with major local blockchains such as GIWA and Kaia, ensuring business versatility. This provides a stable data foundation that overcomes the limitations of the Agentic Payment infrastructure being dependent on specific global mainnets, allowing for flexible diversification according to the service environment and regulatory requirements of each region.

6. Conclusion {#rps-13}

The success or failure of digital asset businesses hinges on how accurately data is handled. This is because all financial processes, from asset issuance to payment and settlement, are being restructured around on-chain data. Therefore, omissions or errors in data can lead to a decline in service reliability and potentially result in critical regulatory risks. DataShare functions as a foundational infrastructure that reduces these operational risks and connects institutional finance to utilize on-chain data according to business standards.

Moreover, financial institutions can utilize various financial technology solutions from Lambda256, in addition to DataShare, to customize and expand necessary functionalities. For instance, they can introduce SCOPE for digital asset settlement and operations or CLAIR for regulatory compliance, enhancing system completeness according to business growth stages. In other words, they can gradually integrate necessary functionalities into the existing environment without the burden of completely rebuilding the infrastructure from scratch.

As a result, financial institutions can completely alleviate operational burdens such as complex infrastructure management or system maintenance, allowing them to focus on their inherent business values of service innovation and product differentiation. This structure enables them to lower initial entry barriers while ensuring that they can reliably secure necessary functionalities in line with future business expansion and regulatory changes.