Indexing, venues and limitations

Approach The indexer reads every finalized transaction that references the token's mint, in chain order, from a known start point (the mint's creation). Each transaction is normalized from its own balance metadata: token changes are netted per owner across all of that owner's token accounts, and the owner's SOL change (native plus wrapped) is taken from the same transaction. Each (transaction, owner) pair has a unique identity, so re-reading a transaction never double counts. A durable cursor lets the indexer resume after restarts.

Supported venues - Pump bonding curve (before migration) - PumpSwap canonical pool (after migration) - Aggregator routes (for example Jupiter) that settle against one of these venues inside the same transaction. Netting per transaction means intermediate hops are not double counted.

Purchases paid with assets other than SOL are tracked as quantity without cost basis. Other venues are not supported.

Reconciliation Indexed quantity per owner is regularly compared with actual on-chain balances across all token accounts of the mint. A wallet that disagrees on consecutive checks is marked History still indexing: it is re-indexed from its own token accounts' history and withheld from evaluation until it reconciles. No cost basis is invented in the meantime.

Limitations - Transfers that do not reference the mint are found through reconciliation and re-indexing, not instantly. - Wallets that held tokens before the indexing start point have untracked quantity for that balance. - Production indexing is implemented but has not yet been verified against mainnet history.