Docs
Open app
REARCTOR / BUILD WITH REARCTOR6 min read

How indexing works

Source-aligned guide · Updated 16 September 2026

On this pageWhat the index coversOne background reader, saved snapshotsTrades and burnsHolder concentrationFreshness and recoveryDemo data and official identityWhat still reads the chain

Rearctor keeps a persistent read index for the launchpad. Catalogue search, token pages, execution charts, fee analytics, burn history and holder concentration read saved data through the read API. Browsing these views does not start an independent RPC scan for each visitor.

What the index covers#

The scope is every launch returned by the configured Rearctor factory. It is not a chain-wide list of Arc assets or every market where a launch token might trade.

Indexed information Source and scope
Launch identity, metadata and fee settings Factory catalogue, including its token, pool, vault and creator relationships.
Price, supply, reserves and graduation state Contract reads at one confirmed snapshot block. After graduation, reserve fields contain recorded migration amounts.
Curve execution history The launch pool's Trade events before graduation.
V4 execution history Swap events for that pool's canonical V4 ID, including swaps through external routers. Other pools are outside scope.
Project buybacks Each launch's fee-vault Buyback events and cumulative counters.
Protocol-funded Rearctor buybacks Dedicated treasury ProtocolBuyback events and protocol accounting counters.
Manual-graduation transfer to dead Pool GraduationRemainderSentToDead event, returned separately on token detail; not a burn or market execution.
Holder balances and concentration Token Transfer logs, including minting and burning, reconciled with current total supply.
Official Rearctor identity Reciprocal factory/treasury configuration, the first factory launch and its canonical token/pool/vault.

The displayed volume remains the canonical launch-pool contract's counter. V4 execution history includes external-router swaps, so its coverage is broader than that counter. Do not describe the volume field as all-market or all-router volume.

One background reader, saved snapshots#

The worker starts at the configured factory deployment block or an earlier block. It checks that the factory had no code immediately before the configured boundary, preventing a deliberately late start from silently omitting history. Historical contract calls and event logs must be available from the RPC provider.

By default, it works twelve blocks behind the observed chain head, processes at most 1,000 blocks per batch and permits four concurrent RPC requests. A completed catch-up batch is followed by another after a short delay; once caught up, the default poll interval is thirty seconds. Confirmation depth is a configured safety margin, not a claim of irreversible chain finality or a fixed update-time guarantee.

Every batch scans the new event range in bounded groups of pool, vault and token addresses, plus canonical V4 pool IDs. Newly launched or active tokens have their market and fee state refreshed at the fixed endpoint; inactive token snapshots are retained. Treasury and factory state are refreshed each batch. Event block hashes and both the endpoint and preceding checkpoint are rechecked. SQLite commits the data and new cursor together. A failed batch does not advance the cursor or replace valid financial figures with zeroes.

Contract snapshots are currently refreshed for all registered launches on each batch. This centralizes the work but still grows with the launch count; the implementation is not an event-only or per-token incremental snapshot reader. Indexed GET handlers read SQLite and never call RPC. Transaction preparation uses a separate read-only RPC relay for fresh reads and simulations.

Trades and burns#

The graduation boundary determines whether a curve Trade belongs in history. After migration, the V4 core event is the source of truth; a mirrored launch-pool trade event is not counted twice. Distinct log indexes are preserved even inside one transaction. Persisted event identity includes chain ID, block hash, transaction hash and log index.

Chart prices are execution-derived USDC/token values. For buys, quote amount is the USDC input; for sells, it is the USDC output. V4 amounts come from core swap deltas. These prices reflect the execution's fee effects and are not an external price feed, an OHLC candle series or a fresh quote. A V4 event with a zero token/quote amount is explicitly counted as omitted from priced history.

Project-vault buybacks and treasury-funded Rearctor buybacks stay in separate event streams and budgets. Direct holder burns reduce supply and affect indexed balances, but do not become project or protocol buyback events. Quantities belonging to different tokens are never one interchangeable total.

The database retains all indexed events. Public responses deliberately have smaller limits: the latest 5,000 priced executions per token, paginated project/protocol burns, and capped aggregate analytics. Each relevant response exposes counts or truncation; a short API window is not a statement that older events never existed.

Holder concentration#

New Transfer logs update saved balances as each batch progresses. Duplicate records are removed before applying balance changes. Negative balances, inconsistent duplicate events, a total that differs from totalSupply, or an incorrect top-five balanceOf check reject the batch.

The ranking excludes the pool, fee vault, V4 manager and fixed dead address. Creator and creator-fee-wallet balances are shown separately. Percentages use the token's full current supply, including infrastructure and dead-address balances; they are not percentages of circulating supply. Address counts cannot establish how many distinct people own a token.

Holder history is persistent rather than rescanned in the browser. The API returns a concentration summary and five leaders, not a complete address ledger or an arbitrary wallet's portfolio. There is no lifetime 100,000-transfer storage limit; configurable per-batch budgets prevent an oversized RPC response from being published partially.

Freshness and recovery#

Every response identifies its mode, snapshot block and time. A healthy but still-catching-up index can return an earlier complete snapshot with state: "syncing". Failed refreshes retain the last successful snapshot and expose it as stale. If no usable snapshot exists, data routes return HTTP 503.

Health HTTP 200 means saved data is readable. It does not promise freshness. A live ready snapshot older than two minutes is marked stale by the API; that can also happen if the chain has not produced new confirmed blocks.

A checkpoint mismatch or a canonical chain shorter than the saved confirmed boundary triggers a rebuild from the configured start. Orphaned rows are removed rather than mixed with the replacement chain. The API can become temporarily unavailable until the rebuilt index commits a valid snapshot. Changing the chain/factory/treasury/start/confirmation configuration also creates a new index namespace.

Demo data and official identity#

With no factory configured, a versioned sample fixture is stored in the database and the worker makes no RPC calls. Responses identify mode: "demo"; history additionally sets sample: true. Sample addresses can be zero placeholders, and sample events have no fabricated transaction hashes. Demo holder concentration and the current demo treasury snapshot are unavailable (null). Do not interpret these values as deployed contracts, trading activity or protocol revenue.

The official Rearc token is not inferred from a symbol, image or matching name. The API returns verified only after the configured treasury points to the first launch and canonical relationships match. Until then it returns upcoming or unavailable. The website's /token/rearc page is a user-facing alias (/token/rearctor remains supported); applications resolve official identity through /official.

What still reads the chain#

The index is for discovery and display. Connected-wallet balances, allowances, personal claimable rewards, trading quotes, authority checks and transaction simulations remain fresh on-chain reads. A cached price or admin-looking UI state cannot authorize a transaction. The indexer has no signing key and does not initiate buybacks, migration or any other on-chain operation.

Download Markdown ↓