Provenance Data: Index Asset, Ledger, and Transfer Events

Index Provenance Blockchain's module events, HASH transfers, and transaction results in one pipeline, delivered to your own database. Real-time and complete historical data, no node to run.

Provenance Blockchain is a public, open-source Layer 1 built for financial services, using the Cosmos SDK and the CometBFT consensus engine. It is purpose-built for real-world asset tokenization, with chain-level modules for a financial ledger, an asset registry, and an on-chain exchange, plus the HASH token and the YLDS stablecoin. The network is stewarded by the Provenance Blockchain Foundation.

You can read how the team frames it at provenance.io, with developer documentation at docs.provenance.io. That module-heavy design is the data problem: the activity that matters, asset scopes changing status, ledger updates, fee grants, and HASH transfers, arrives as typed ABCI events inside CometBFT block results. Indexing Co reads those blocks, lets you shape the events in a transform, and delivers rows to your own PostgreSQL, warehouse, or webhook. Real-time and full history, with no node to operate.

Source pio-mainnet-1 blocks

Ingest block results, tx results

Decode module events to fields

Transform your JavaScript

Deliver your database

Why Provenance data is hard

Custom Modules, Custom Events Provenance's financial logic lives in its own modules, not in general-purpose contracts. Their activity surfaces as typed events such as `provenance.ledger.v1.EventLedgerUpdated`, carrying scope IDs, asset class IDs, and update types. Each module has its own event vocabulary to map before the data means anything.

Typed Event Values Are JSON Typed module events encode their attribute values as JSON, so a scope ID arrives wrapped in its own quotes, while standard events like `transfer` carry plain strings such as `3333333334nhash`. A loader that treats every attribute the same way stores broken keys.

Fee Grants Change Who Paid Provenance transactions can be paid through fee grants, so the account that signed and the account whose HASH covers the fee can differ. `use_feegrant`, `update_feegrant`, and the `tx` fee events have to be read together to attribute costs correctly.

Your Own DB, Not a Hosted API Financial applications need complete, auditable history in a store they control. Public endpoints are rate-limited and prune history, so owning the data means indexing it into your own database, shaped the way your product and reporting query it.

What Indexing Co delivers for Provenance

The DIY Path

Stand up and maintain the whole stack yourself.

Run a Provenance archive node or depend on public RPC endpoints.
Poll block results and pair each tx result with its raw transaction.
Map each module's typed events and unwrap their JSON values by hand.
Build backfill and real-time delivery from scratch.

Indexing Co

One pipeline sources, shapes, and delivers Provenance to your store.

Provenance tx results, module events, and block-level events in a single pipeline.
Event attributes, shaped by your JavaScript transform.
Lands in your PostgreSQL, BigQuery, warehouse, or webhook.
Real-time delivery plus complete backfilled history. No node, no RPC babysitting.

What you can index

ABCI data type	On Provenance, for example
Provenance module events	Ledger updates with scope IDs, asset class IDs, and update types
Token movements	`transfer`, `coin_spent`, and `coin_received` events in `nhash` and other denoms
Fee grants and fees	`use_feegrant` and `update_feegrant` granter and grantee, fee and fee payer
Transaction results	Success code, gas wanted and used, message type, block-level events

A transform, not a subgraph

You write the transform in JavaScript, not AssemblyScript, and change it without re-indexing from block zero. Indexing Co runs your function over each block server-side: walk the transaction results, pick the events you care about, and return rows for your destination.

// Indexing Co transform: rows for Provenance module events
function transform(block) {
  const results = [];
  const txs = block.txs_results || [];

  txs.forEach((tx, txIndex) => {
    if (tx.code !== 0) return; // skip failed transactions
    const events = tx.events || [];
    const msg = events.find(e => e.type === 'message' &&
      (e.attributes || []).some(a => a.key === 'action'));
    const action = msg ? msg.attributes.find(a => a.key === 'action').value : null;

    for (const event of events) {
      if (!event.type.startsWith('provenance.')) continue;
      const attrs = {};
      for (const a of event.attributes || []) attrs[a.key] = a.value;
      results.push({
        chain: block._network,
        height: Number(block.height),
        time: block.block.header.time,
        tx_index: txIndex,
        action,
        event_type: event.type,
        attributes: attrs,
      });
    }
  });
  return results;
}

Provenance with Indexing Co

Run it yourself if

You want full control of node infrastructure and have the team to operate a Provenance archive node, map every module's typed events, and build backfill and delivery in-house.

Use Indexing Co if

You want Provenance module events, HASH transfers, and transaction results delivered to your own database, with real-time plus complete history and no infrastructure to run.

Get a Demo Open the Console

FAQ

Do I need to run a Provenance node?

No. Indexing Co sources Provenance blocks and block results for you, including full historical data, so you never operate an archive node or depend on public endpoints.

Can I index a specific Provenance module?

Yes. Typed module events are named by their protobuf package, for example provenance.ledger.v1.EventLedgerUpdated, so a transform can filter on one module, one event type, or all provenance. events, as in the example above.

Are messages decoded from protobuf?

The pipeline delivers the transaction results and their ABCI events, which carry the message type, sender, fees, gas, and module attributes. The raw transaction bytes in the block are base64 protobuf and are passed through as-is.

Where does the Provenance data go?

Into your own destination: PostgreSQL, BigQuery, a warehouse, or a webhook. You define the output schema and own the storage.

Can I get complete historical Provenance data?

Yes. We backfill from your chosen start block and merge it with real-time data, so your Provenance dataset is gap-free from genesis forward if you want it.

Get Started

Index Provenance in minutes. Set up your first Provenance pipeline without running a node.