Read Layer

TLDR

Blockchain data queries and distribution need to reach parity with TradFi in richness, flexibility and performance. What is provided by today's blockchain explorers and RPC providers is not sufficient. Vulcan Forge aims to do its part to fill at least some of the gaps.

Offchain twins datastore

The database that Vulcan Forge keeps in sync with the onchain state (through the mirrored offchain twins) provides very powerful capabilities in terms of the type of queries that can be performed against it. It is a full relational datastore where complex joins, filtering criteria, subqueries and aggregations are first-class citizens.

Before diving deeper into Vulcan Forge's capabilities, the next section covers what is already available on the marketplace today and areas of potential upcoming developments.

Existing Solana Infrastructure

While Vulcan Forge provides some of the best capabilities for data queries, the beauty of blockchains is that a data consumer does not have to rely on only one provider for its data needs. All the raw data associated with transactions processed through Vulcan Forge can be accessed, as well, via the mechanisms described below.

RPC Providers

Within the Solana community, a strong set of mature, sophisticated and large scale RPC providers has developed over the years. The entire ecosystem realies very heavily on them for Web3 applications development. A well defined set of RPC methods exists to query blockchain data, supported by all RPC providers. Many RPC providers complement these base capabilities with more advanced features.

Additionally, the wide support for and deployment of different variants of Geyser Plugins allow any enterprise to tap into the firehose of real-time data streaming of blockchain events and to perform low-latency updates to its internal data stores.

And of course, as a permissionless blockchain, any enterprise can chose to join the Solana network with its own deployment of RPC nodes, thus reducing even further the need for third parties for its data needs.

We believe that the following special TradFi use case represents a substantial (and overlooked) untapped potential for leveraging the Solana blockchain. The ecosystem of existing RPC providers is well positioned to support it.

Financial master files data distribution

By financial master files we mean the full definition of tradeable instruments through all the data structures & fields needed to manage their full lifecycle. Over the decades, standardization efforts to bring alignment across market participants in how they represent this data have resulted in widely used industry standards - e.g. the FIX Protocol and ISO 20022.

The backbone of well-functioning financial markets relies heavily on the ability to ship such data between its originators, the data providers/distributors and financial institutions. As an example, Bloomberg and Thompson Reuters derive substantial revenues by providing these data distribution services and act as important gateways in these distribution channels.

If substantial volumes of clearing and settlement in TradFi capital markets are to migrate onchain, this will call for bringing a lot more of these product master files onchain as well.

The Solana Token Metadata extension is a good first step in allowing more expressive metadata, for a tradeable item, to be stored onchain. We hope that over the coming years future versions of Solana Tokens programs will incorporate in them more flexible ways to organize, manage and update this data. Providing templates/standard definitions for the onchain metadata representation, akin to the standards mentioned above, would be a large boost for adoption.

Once this type of data is onchain, the inherit append-only and transparent characteristics of blockchains would be a perfect fit for providing lineage and wide-reach to product master files in capital markets. The infrastructure built by existing RPC providers can provide a very viable and cohesive alternative for data distribution compared to the amalgamation of file transfers, real-time data messaging and protocols that forms today's spagetti web of data distribution in TradFi.

Alphaledger aims to support these efforts over time.

Read endpoints

Types

High level categories for read endpoints:

Type	Endpoint Path Pattern	Request Body	Description
Single	/single	Account or Position or Transaction Lookup	Fetches full details or certain subsets of data on a single blockchain entity
Bulk/Multiple	/bulk	Items Query	Fetches a list of items that match the specified query criteria

Since all these endpoints require a JSON request payload they are setup as POST method enpoints. The word get in these endpoints' names and descriptions is avoided to not introduce confusion with the GET method.

Fetch endpoints with a plural in their name are bulk endpoints. The rest are single item fetch endpoints.

Response detail level

Most of the bulk endpoints include support for a detail-level path parameter which allows the client to control the amount of fields/metadata to be retrieved for the fetched items. Options available:

Detail Level	Description	Examples
detailed	All available details are fetched	Account Detailed
compact	Identifiers and offchain metadata	Account Compact
identifiers	Identifiers only	Account Identifiers

Note that the compact and identifiers schemas include only a subset of the fields provided in the detailed schema - i.e. the detailed schema completely overlaps the other 2 schemas. As such, the response body on the endpoints will support the compact and identifiers options as well, even if the API endpoint spec specifies the detailed level in the response body.

Flexible Filtering and Sorting

As part of the bulk endpoints, the Items Query schema provides the ability to paginate the fetch of items with the optional limit and skip fields.

The breadth of metadata for the blockchain entities tracked in the offchain database is wide. To make the best use of it, the system allows filtering an a large number of the metadata fields - the filter criteria can be combined in the way the best fits the API client's needs.

An array of filters can be specified on either or all of the fields that are listed in the Filter & Sort Options tables provided on the description for each of the bulk endpoints.

The same tables specify which fields are supported for sorting the data. And what is the default sort order.

The example itemQuery specified below, applicable to the Fetch Acccounts endpoint, would fetch the following items:

A. Page 3 with a page size of 20

B. Meeting this filter criteria:

comments: comments contain "Setup for test only" AND

managed: include only managed accounts AND

type: include only blockchain accounts of type LOAN_ESCROW and LOAN_LENDER AND

lastTransactionAt: which have a last transaction posted against them between Jan 1st 2025 and March 1st 2025

C. Sorted by:

lastTransactionAt: Descending chronological order

{
  "limit": 20,
  "skip": 40,
  "filter": [
    {
      "fieldName": "comments",
      "filterValues": [
        {
          "dataType": "TEXT",
          "filterType": "CONTAINS",
          "valueString": "Setup for test only"
        }
      ]
    },
    {
      "fieldName": "managed",
      "filterValues": [
        {
          "dataType": "TEXT",
          "filterType": "EQAULS",
          "valueBoolean": true
        }
      ]
    },
    {
      "fieldName": "type",
      "filterValues": [
        {
          "dataType": "OFFCHAIN_REFRENCE_TYPE",
          "filterType": "IN",
          "valuesString": [
            "LOAN_ESCROW",
            "LOAN_LENDER"
          ]
        }
      ]
    },
    {
      "fieldName": "lastTransactionAt",
      "filterValues": [
        {
          "dataType": "TIMESTAMP",
          "filterType": "IN_RANGE",
          "valueFromString": "2025-01-01T00:00:00Z",
          "valueToString": "2025-03-01T00:00:00Z"
        }
      ]
    }
  ],
  "sort": [
    {
      "fieldName": "lastTransactionAt",
      "sortDirection": "DESC"
    }
  ]
}

Future considerations

Data export formats

In the future Vulcan Forge will make data available in these other formats:

Human readable reports needed for auditing and reporting requirements

Exports in CSV and XML formats (exact formats will depend on customer demand)

Blockchain Explorer

All the metadata and relationships between blockchain entities captured within Vulcan Forge, open up the possibility for creating very powerful UI blockchain explorers for ad-hoc data exploration and retrieval.

Websockets & Webhooks

Websockets and/or webhooks support could be added in future releases, depending on the market demand for real-time distribution of Vulcan Forge data.

TLDR#

Offchain twins datastore#

Existing Solana Infrastructure#

RPC Providers#

Financial master files data distribution#

Read endpoints#

Types#

Response detail level#

Flexible Filtering and Sorting#

Future considerations#

Data export formats#

Blockchain Explorer#

Websockets & Webhooks#