OpenChat users can send messages to each other containing tokens such as ICP. Users can upgrade to Diamond membership to have access to extra or enhanced features.

OpenChat is a chat application running end-to-end on the Internet Computer blockchain.

CHAT tokenholders own and govern the protocol.

github

twitter

website

Social

OpenChat

# OpenChat Maximum token supply Methodology

## 1. Overview

The OpenChat maximum token supply metric tracks the total circulating token supply for the OpenChat platform over time. This metric represents the net cumulative result of all token mint and burn operations, providing insight into the token's supply dynamics. The calculation aggregates daily mint and burn events into a running total that represents the maximum token supply at any given point in time.

## 2. Data sources

The calculation relies on the following data sources:
- **OpenChat platform events**: Raw event logs from the OpenChat platform's event system containing user actions and system operations
- **Mint event records**: Platform events specifically recording token creation operations with amount and transaction index data
- **Burn event records**: Platform events specifically recording token destruction operations with amount and transaction index data
- **Event metadata**: Timestamp, user identifier, event name, source system, and JSON payload data for each platform operation

## 3. Step-by-step calculation

### Component A: Event deduplication
- **Purpose**: Remove duplicate events from the raw OpenChat platform data
- **Logic**: Raw OpenChat events are processed to eliminate duplicate entries that may occur due to data ingestion issues or system retries. The deduplication process partitions events by `timestamp`, `user`, `name`, `source`, and the serialized JSON `payload` content, then assigns row numbers to identify unique occurrences. Only the first occurrence of each unique event combination is retained for further processing.
- **Key fields**: `timestamp` (event time), `name` (event type), `user` (user identifier), `source` (originating system), `payload` (JSON event data)

### Component B: Mint event extraction
- **Purpose**: Extract and standardize token mint operations from the deduplicated events
- **Logic**: The system filters deduplicated events to identify mint operations where the event `name` equals 'mint'. For each mint event, the token amount is extracted from the JSON `payload` using the `amount` field. The amount values are stored in 1e8 precision format and are converted to standard decimal format by dividing by 100,000,000. Additional metadata including the payload `index` field is also extracted for tracking purposes.
- **Key fields**: `amount` (token quantity minted, converted from 1e8 precision), `payload_index` (transaction sequence identifier)

### Component C: Burn event extraction
- **Purpose**: Extract and standardize token burn operations from the deduplicated events
- **Logic**: Similar to mint event extraction, the system filters for burn operations where the event `name` equals 'burn'. Token amounts are extracted from the JSON `payload` and converted from 1e8 precision to standard decimal format. The key difference is that burn amounts are treated as positive values during extraction, but will be converted to negative values when combined with mint events to represent supply reduction.
- **Key fields**: `amount` (token quantity burned, converted from 1e8 precision), `payload_index` (transaction sequence identifier)

### Component D: Token supply change calculation
- **Purpose**: Combine mint and burn events into a unified dataset showing net daily token supply changes
- **Logic**: Mint events are included with their positive amount values, while burn events are included with their amounts converted to negative values (multiplied by -1) to represent supply reduction. All events are then truncated to daily granularity using date truncation to the day level. Events occurring on the same day are aggregated by summing their amount values to produce the net daily change in token supply. A continuous date spine is generated from the earliest event date through the previous day to ensure complete daily coverage, with null values for days without events.
- **Key fields**: `change` (net daily token supply change), `timestamp` (daily granularity)

### Final aggregation
- **Combining components**: The daily token supply changes are joined to the continuous date spine, ensuring every day has a record even if no mint or burn events occurred
- **Running total calculation**: A cumulative sum is calculated over the daily changes using a window function ordered by date. This running sum represents the maximum token supply at each point in time, starting from zero and accumulating all historical mint and burn operations
- **Time aggregation**: Data is processed at daily granularity with timestamps truncated to day boundaries
- **Final calculation**: The maximum token supply on any given day equals the sum of all daily supply changes from the beginning of time through that day, where daily changes equal total mints minus total burns for that day. The final metric is processed through the finalize macro with a fill-forward strategy to handle any remaining gaps in the time series.

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

Maximum number of tokens that can exist under the current token economics.

OpenChatCHAT

Maximum token supply

Maximum token supply

Competitive landscape