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

Acala is a specialized stablecoin and liquidity blockchain powered by Polkadot Relay chain.

ACA holders own and govern the protocol. Acala’s investors include Pantera Capital, Coinbase Ventures, and Polychain Capital.

website

github

twitter

discord

etherscan

Blockchains (L2)

Acala Network

# Acala Network Trade count Methodology

## 1. Overview

The Acala trade count metric measures the daily number of unique DEX trades executed on Acala's decentralized exchange (Acala DEX). This metric counts distinct swap transactions per day, providing insight into trading activity and user engagement on the Acala network. Each trade is identified by its unique extrinsic ID (transaction identifier), ensuring accurate counting without double-counting multiple events within the same transaction.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Acala blockchain events**: Raw event logs from the Acala blockchain containing DEX swap events emitted by the `dex` pallet's `Swap` method
- **Token metadata**: Centralized token information including symbols, decimals, and asset identifiers for all tokens supported on the Acala network
- **CoinGecko token mappings**: Hardcoded mappings between Acala token symbols and CoinGecko IDs for major tokens like DOT, LDOT, USDC, USDT, ACA, and AUSD

## 3. Step-by-step calculation

### Component A: Raw swap event extraction
- **Purpose**: Extract and filter successful DEX swap events from Acala blockchain logs
- **Logic**: Query Acala event logs filtering for events where the pallet is `dex`, method is `Swap`, and success is `true`. Extract key fields including block timestamp, extrinsic ID, event index, extrinsic hash, and the raw event data containing trader address, token identifiers, and swap amounts
- **Key fields**: `block_timestamp`, `extrinsic_id`, `event_index`, `event_data` containing trader and token information

### Component B: Event data parsing and token identification  
- **Purpose**: Parse complex JSON event data and normalize token identifiers across different asset types
- **Logic**: Extract trader address from the first element of event data. Parse token identifiers from nested JSON arrays, handling multiple token formats including `Token`, `LiquidCrowdloan`, `ForeignAsset`, and `Erc20` types through conditional logic. Extract input and output amounts from the final elements of amount arrays. Convert these complex token objects into standardized JSON strings for lookup purposes
- **Key fields**: `trader`, `token_in_varchar`, `token_out_varchar`, `amount_in`, `amount_out`

### Component C: Token metadata enrichment
- **Purpose**: Add token symbols and decimal information to enable proper amount calculations
- **Logic**: Join parsed token identifiers with token dimension data to retrieve token symbols and decimal places. The token dimension extracts asset identifiers from complex JSON structures using `NativeAssetId` or fallback extraction methods. This provides the necessary metadata to convert raw token amounts into human-readable values
- **Key fields**: `asset_in`, `asset_out`, `decimals_in`, `decimals_out`

### Component D: Amount normalization and CoinGecko mapping
- **Purpose**: Normalize token amounts and add price data integration capabilities
- **Logic**: Divide raw token amounts by 10 raised to the power of token decimals to get actual token quantities. Join with CoinGecko mapping table to add `coingecko_id` fields for both input and output tokens, enabling future price calculations. Truncate timestamps to daily boundaries for daily aggregation
- **Key fields**: `amount_in` (normalized), `amount_out` (normalized), `token0_coingecko_id`, `token1_coingecko_id`

### Final aggregation
- **Combining components**: The processed swap data flows through the intermediate trading volume model which maintains all trade details while adding daily timestamp granularity
- **Currency conversion**: Not applicable for trade count - only the count of trades matters, not their monetary value
- **Time aggregation**: Group by daily timestamp boundaries using `timestamp_trunc(timestamp, day)`
- **Final calculation**: Count distinct `extrinsic_id` values per day to get the number of unique trades. Each extrinsic represents one blockchain transaction, so counting distinct extrinsic IDs ensures each trade is counted exactly once even if it generates multiple events. Apply the `finalize_metric_trade_count` macro to add standard metadata fields and apply any configured data quality filters

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

Number of trades executed on a decentralized exchange.

Acala NetworkACA

Archived

Trade count

Trade count

Competitive landscape

Chain breakdown