Asset holders

1. Overview

Asset Holders is the count of unique addresses holding a positive token balance for a given asset deployment, reported per chain and token per UTC day. Each day's value reflects the number of accounts — including both externally owned wallets and contract addresses — for which a positive cumulative balance was maintained by the close of that day. Counts are independent per chain and token deployment; the same address holding the same asset across two chains is counted once on each. Days for which no count observation is recorded carry a value of zero, indicating that no positive-balance intervals were active for that deployment on those days.

2. Data sources

• EVM chain transfer events: ERC-20 Transfer events, covering Ethereum, Arbitrum, Base, Polygon, Optimism, and others
• Non-EVM chain transfer records: SPL token transfers on Solana; equivalent transfer instructions on Aptos, Algorand, Stellar, and other supported chains
• Opening balance snapshots: For select chains, per-account token balances recorded at a fixed historical boundary, used as the starting point for the cumulative ledger
• Asset metadata: Token contract addresses and chain identifiers, sourced from the asset registry

3. Step-by-step calculation

Component A: Build the cumulative balance ledger

• Purpose: Establish each account's token balance for every day across the history of a deployment.
• Logic: On EVM-compatible chains, ERC-20 Transfer events are parsed to derive each account's daily net balance change: the balance is incremented by inbound transfers and decremented by outbound transfers. On Solana and other non-EVM chains, the equivalent transfer instructions are parsed in the same manner. Depending on the chain, one of two replay paths is applied. In the full-replay path, the cumulative balance is initialized at zero and all daily net flow changes are accumulated from the earliest recorded event forward. In the snapshot path, the cumulative balance is initialized from each account's recorded token balance at a fixed historical boundary date, and subsequent daily net flow changes are accumulated on top of that opening amount; the snapshot supplies the starting amount for each account, not an additional holder count.

Component B: Identify positive-balance intervals

• Purpose: Determine the continuous time intervals during which each account holds a positive balance.
• Logic: The cumulative balance series produced in Component A is evaluated per account and token. An account is added to the holder cohort on the first day its balance rises above zero, and it is removed on the first day its balance falls to zero or below. These entry and exit boundaries delimit positive-balance intervals; the holder count on any given day equals the number of accounts whose positive-balance interval covers that day.

Component C: Compute daily holder counts

• Purpose: Aggregate per-interval data into a daily count of holders per token deployment.
• Logic: For each token deployment, holder-interval entry and exit events are accumulated into a daily count series spanning from the first recorded observation through yesterday. Counts are maintained per chain and token deployment; the same address holding the same asset on multiple chains is counted independently on each.

Component D: Fill gaps and join to the asset registry

• Purpose: Produce a complete, contiguous daily series and associate each count with its asset.
• Logic: Token-deployment days for which no count observation exists are filled with a value of zero. This fill is applied from the first recorded day for each deployment through yesterday, including days that follow the most recent non-zero observation. The completed series is joined to the asset registry by token address and chain to associate each daily count with the corresponding asset.