Validators process transactions and receive fees from users (supply-side fees).

Astar is a collective driving web3 adoption by connecting people through blockchain technology, business innovation, decentralized applications, and seamless digital experiences in the Polkadot ecosystem. Astar was founded by Sota Watanabe and launched in 2021.

ASTR tokenholders own and govern the protocol. Part of the transaction fees is burned (revenue). Astar’s investors include Binance, Polychain Capital, Crypto.com, etc.

website

twitter

github

discord

Blockchains (L2)

Astar

# Astar Contract deployers Methodology

## 1. Overview

The Astar contract deployers metric measures the number of unique addresses that deployed smart contracts on the Astar network on a given day. This metric helps track developer activity and ecosystem growth by identifying distinct entities creating new contracts. The calculation leverages Astar's substrate-based event system to identify contract deployments through system events and match them with deployer addresses from execution events.

## 2. Data sources

- **Astar blockchain events**: Raw event logs from the Astar substrate-based blockchain containing pallet-specific event data
- **System pallet events**: Substrate system events that track account creation, including contract deployments via `NewAccount` events
- **Ethereum pallet events**: Substrate Ethereum compatibility layer events that capture EVM execution details via `Executed` events
- **Extrinsic records**: Substrate transaction execution records that link related events through unique identifiers
- **Event metadata**: Structured event data including timestamps, pallet names, method names, and JSON-encoded parameters

## 3. Step-by-step calculation

### Component A: Raw event processing
- **Purpose**: Extract and prepare all relevant Astar blockchain events for analysis
- **Logic**: Pull all events from Astar blockchain event logs, truncate timestamps to daily boundaries for consistent aggregation, and filter to include only events with complete metadata including `event_pallet`, `event_method`, `event_data`, and `extrinsic_id` fields
- **Key fields**: `timestamp` (truncated to day), `event_data` (JSON array containing event parameters), `event_pallet` (substrate module name), `event_method` (specific event type), `extrinsic_id` (transaction identifier)

### Component B: Contract creation identification  
- **Purpose**: Identify when new contracts are deployed by detecting contract address creation events
- **Logic**: Filter events to System pallet `NewAccount` events which indicate creation of new accounts including contracts, extract contract addresses from the first element of the `event_data` JSON array, normalize addresses to lowercase, and ensure events are linked to valid extrinsic transactions
- **Key fields**: `contract_address` (extracted from `event_data[0]`), `extrinsic_id` (linking key), `timestamp` (deployment date)

### Component C: Deployer address identification
- **Purpose**: Identify the addresses responsible for deploying contracts through EVM execution events  
- **Logic**: Filter events to Ethereum pallet `Executed` events which contain deployer information from EVM compatibility layer, extract signer addresses from the first element of the `event_data` JSON array, normalize addresses to lowercase, and link to contract deployments via `extrinsic_id`
- **Key fields**: `signer_address` (extracted from `event_data[0]` as deployer), `extrinsic_id` (linking key), `evm_hash` (EVM transaction hash from `event_data[2]`)

### Component D: Contract deployment linking
- **Purpose**: Connect contract addresses with their deployers by matching related events from the same transaction
- **Logic**: Perform left join between contract creation events and deployer events using `extrinsic_id` as the linking key, ensuring each contract deployment is matched with its corresponding deployer address when available, and preserve all contract creations even if deployer information is missing
- **Key fields**: `contract_address`, `deployer_address`, `timestamp`, `extrinsic_id`

### Final aggregation
- **Combining components**: Group all contract deployments by daily timestamp and count distinct `deployer_address` values to identify unique deployers per day
- **Currency conversion**: No currency conversion required as this is a count metric
- **Time aggregation**: Data is aggregated to daily boundaries using timestamp truncation, with each day representing a complete 24-hour period in UTC
- **Final calculation**: Count of distinct deployer addresses that successfully deployed at least one contract on each day, with missing days filled with zero values using the fill_zeros strategy

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

Unique addresses that deployed at least one smart contract.

AstarASTR

Contract deployers

Contract deployers

Competitive landscape

Chain breakdown