Dev Insights

November 12, 2026

Guest Post - Arckive: the first thinking indexer on Arc

# Developer tools

# Guest Posts

# Indexers

# Arc

Arckive is an open-source, self-hosted indexer that writes Arc contract events into your Postgres from one Kubernetes resource.

Melike Keçelioğlu

Göktuğ Oğuz Güngör

Arckive is an open-source, self-hosted indexer that streams smart-contract events from Arc into your own Postgres database. You describe the contracts and events you need in a Kubernetes resource, and Arckive provisions a worker that backfills history, follows the chain, and writes typed event tables that you can query with plain SQL.

That makes Arckive useful as a data layer for Arc applications, analytics, payment reconciliation, monitoring, and developer tools. You can build on top of the indexed data without running a subgraph, operating a hosted indexing service, or writing the indexing pipeline yourself.

The project is available under the Apache-2.0 license at github.com/Goguzgungor/arckive .

Why Arc changes the indexer design

Arc's consensus and block-production characteristics remove or change several assumptions that shape traditional EVM indexers.

First, deterministic finality means a finalized block does not roll back. Arckive defaults to the finalized tag, so once it writes events from block N, those rows stay valid and the cursor can move to N+1. The write path stays append-only: inserts are idempotent, the checkpoint only moves forward, and there is no reorg or rollback machinery for finalized data.

Second, Arc produces blocks quickly. During the testnet measurement window used for this post, blocks arrived roughly every 540 ms. A conventional two-second polling loop would regularly wake up several blocks behind, so Arckive uses eth_subscribe(newHeads) over WebSocket as its primary signal. Polling remains available as a recovery path for dropped connections.

The result is a useful engineering lesson for builders on Arc: before optimizing the indexing engine, measure how much latency comes from the RPC provider. In our testnet measurements, the provider's announcement delay was approximately 0.75–0.9 seconds at p50, while the indexer's contribution from receiving the announcement to committing the row was approximately 40 ms.

One Kubernetes resource, one Postgres schema

An Arckive indexer is configured declaratively. This example indexes USDC Transfer events, backfills the last 500 blocks, and writes to an external Postgres database:

apiVersion: arckive.org/v1alpha1
kind: Indexer
metadata:
  name: usdc-arc
spec:
  network:
    chainId: 5042002
    rpc:
      - wss://arc-testnet.drpc.org
      - https://arc-testnet.drpc.org
    announceRpc:
      - wss://rpc.testnet.arc.network
  storage:
    mode: External
    external:
      dsnSecretRef: { name: pg-dsn, key: url }
  contracts:
    - name: usdc
      address: "0x3600000000000000000000000000000000000000"
      startBlock: -500
      events: [Transfer]

The operator watches the resource and provisions a worker Deployment with the corresponding configuration. It also patches live status back onto the resource, so the current block, chain head, and lag are visible through kubectl get indexers.

Contract ABIs are fetched from the Arc explorer by address. An inline ABI or ConfigMap can override that behavior. A negative startBlock backfills relative to the current head; startBlock: 0 backfills from genesis; omitting startBlock starts at the current head.

Each indexer receives its own Postgres schema, with one typed table per event and a cursor table. Adding another contract or event is configuration rather than a new indexing service.

Correctness in one transaction

The core reliability invariant is simple: event rows, dead-lettered logs, and the cursor advance are committed in one database transaction.

If a worker stops halfway through a batch, the transaction rolls back. On restart, the worker resumes from the cursor and fetches the same range again. Re-processing is safe because event tables use a unique key composed of the block number, transaction hash, and log index, with ON CONFLICT DO NOTHING for idempotent writes.

Logs that cannot be decoded do not stop the pipeline. Arckive records the raw payload and decoding error in a dead-letter table, then continues advancing the cursor. Consumers can read events in stable chain order by sorting on (block_number, log_index).

This design is intentionally narrower than a general-purpose multi-chain indexer. Because finalized Arc blocks do not reorg, Arckive does not keep unconfirmed states or confirmation-depth tuning for the data it commits.

Announcing and querying are different jobs

One of the practical lessons from building Arckive was that the RPC endpoint that announces a new block is not always the endpoint that should answer log queries.

A node behind a load balancer may announce a block before the node handling eth_getLogs has seen it. In that case, the query can return an incomplete result without returning an error. Arckive checks the query node's own head in parallel with the log request and commits only through the block that node has actually observed.

The RPC pool reflects this separation:

Endpoints are health-checked and filtered by eth_chainId at startup.

Query endpoints follow a deterministic priority order instead of being continuously re-ranked by observed latency.

announceRpc supports listen-only endpoints that provide fast newHeads notifications but are not used for queries.

For Arc builders , the broader takeaway is to treat block announcements and data queries as separate infrastructure concerns. The fastest notification source may not be the best source for historical data, and an adaptive RPC client can make that mismatch harder to diagnose.

What the measurements showed

The measurements below came from Arckive's ordinary product surface: Postgres rows and Prometheus metrics, rather than custom benchmark instrumentation.

Block to queryable SQL row: 395 ms at p50, 953 ms at p90, and 969 ms at p99 on Arc public testnet.

Backfill: 92.6 blocks per second, or 371 events per second, across 5,107 blocks and 20,452 USDC transfers.

Burst ingest: 2,628 events per second on a local Anvil chain, isolating decode and database-write performance from network effects.

The benchmark suite can be reproduced from a repository checkout:

docker compose -f docker-compose.dev.yml up -d postgres anvil
pnpm bench

Results are written to docs/benchmarks/<date>/results.json with the raw samples and an HTML report.

What other Arc builders can build

Arckive is most useful when its tables become part of an application's existing data model.

For a payments product, indexed USDC transfers can be joined with invoices in Postgres. Optional Insights labels each event with a lane — swap, bridge, payment, and similar — using Laya , a small decision model that reads a short description of the transfer's shape rather than raw addresses. Classification runs behind the ingest cursor, so a slow or unavailable model does not stall chain capture.

SELECT inv.id, t.value, t.block_time, i.lane
FROM invoices inv
JOIN idx_shop.usdc_transfer t
  ON t."to" = inv.deposit_address
JOIN idx_shop._insights i USING (block_number, tx_hash, log_index)
WHERE i.lane IN ('payment', 'signed_payment');

For a protocol or token team, the same tables can feed dashboards, analytics, and alerts through SQL, Grafana, Metabase, an ORM, or any other Postgres client:

SELECT date_trunc('hour', block_time) AS hour,
       count(*) AS transfers,
       sum(value) AS volume
FROM idx_mytoken.mytoken_transfer
GROUP BY 1
ORDER BY 1 DESC;

Wallets can use the indexed tables to build address histories. Monitoring systems can trigger alerts on large transfers or unusual activity, for example, a bridge-out lane above a size threshold. Front ends can read the tables directly or consume a service built on top of them.

The important point is that these applications do not need to agree on a hosted API or wait for a shared indexing provider to support their use case. Each builder controls the database, schema, queries, and downstream services.

Arckive's own tools demonstrate this pattern: Arc Radar and Arckive Explorer use the same indexed tables, with Laya lanes on the live tape and transaction views. They are examples of what can be built with the same underlying developer tooling, not the limit of what builders can create.

Try it on Arc

You need a Kubernetes cluster and a reachable Postgres database:

kubectl apply -f https://arckive.org/install.yaml
kubectl apply -f https://arckive.org/demo.yaml
kubectl get indexers -w

To explore the code, benchmarks, and configuration examples, visit:

Arckive GitHub repository

Arckive documentation and benchmarks

Arc Radar

Arckive Explorer

Arckive is designed to make Arc event data composable: configure the events you need, keep the resulting tables in your own Postgres, and build the application or developer experience on top.

Arc is an open L1 blockchain launched by Arc Network Services LLC ("Arc LLC") and operated by a permissioned validator set. Arc LLC provides software services only and does not offer regulated financial or advisory services. Arc has not been reviewed or approved by the New York State Department of Financial Services or any other regulatory authority.

The Arc network is provided "as is" and "as available." Use of Arc involves inherent risks associated with blockchain technology, including smart contract vulnerabilities, network disruptions, and the absence of recourse for transaction errors or losses. The ability to transact on Arc depends on the ability to obtain and use USDC to pay gas fees. Neither Arc LLC nor any permissioned validator is responsible for the content, accuracy, legality, or functionality of third-party applications, protocols, or services built on or integrated with Arc. You are solely responsible for features or services you provide to users, including obtaining any necessary licenses or approvals and otherwise complying with applicable laws.

All Arc features may be modified, delayed, or cancelled at any time without notice. Nothing herein constitutes a commitment, warranty, guarantee or legal, regulatory, tax, or investment advice.

Comments (114)

Popular