Collators aggregate parachain transactions block candidates and producing state transition proofs for validators based on those blocks.

Bifrost is the Staking Yield Layer app-chain for stablecoins, RWAs, and DeFi, powered by the Polkadot Relay chain.

BNC holders own and govern the protocol. Bifrost’s investors include OKX Ventures, Long Hash Ventures, etc.

website

github

twitter

discord

etherscan

Blockchains (L2)

Bifrost

# Bifrost Token holders Methodology

## 1. Overview

Token holders measures the number of unique addresses that hold a non-zero balance of the native asset on Bifrost Substrate. This metric is used to track the growth and distribution of the protocol's holder base over time. By monitoring the lifecycle of accounts on the network, the expansion of the user ecosystem is quantified across the project's substrate-based infrastructure.

## 2. Data sources

- **Blockchain events**: `NewAccount` and `KilledAccount` events from System contracts, covering Bifrost Substrate
- **External data**: Asset metadata for native asset identification

## 3. Step-by-step calculation

### Component A: Account lifecycle tracking

- **Purpose**: Identify the creation and removal of unique addresses with non-zero balances.
- **Logic**: `NewAccount` and `KilledAccount` events are parsed from the Bifrost Substrate blockchain. Each `NewAccount` event, which signifies an account reaching the existential deposit threshold, is assigned a value of 1. Each `KilledAccount` event, which signifies an account balance dropping below the required threshold and being reaped, is assigned a value of -1. These events are aggregated by day to determine the net daily change in the holder base.
- **Key fields**: `event_method` (event identification), `block_timestamp` (timing)

### Component B: Cumulative holder aggregation

- **Purpose**: Calculate the total number of unique holders at any given point in time.
- **Logic**: Net daily changes are calculated by summing the values derived from account lifecycle events. A running total of these daily changes is computed chronologically to determine the cumulative number of token holders for each day.
- **Key fields**: `daily_change` (net daily account movement)

### Component C: Data continuity and normalization

- **Purpose**: Ensure a consistent time series and project-level reporting.
- **Logic**: A forward-filling logic is applied to the cumulative totals to account for days where no account lifecycle events occur, ensuring the most recent holder count is maintained. The final values are filtered to include only non-zero counts and are aggregated at the project level. Daily granularity is maintained using UTC day boundaries.

*This methodology was automatically generated by Token Terminal's methodology analyzer.*

Unique addresses holding a non-zero balance of the project's native token.

BifrostBNC

Archived

Token holders

Token holders

Competitive landscape

Chain breakdown