Toucan receives fees when liquid carbon reference tokens are redeemed for carbon credits and when off-chain carbon credits are bridged on-chain (revenue).

Toucan is an infrastructure protocol that bundles illiquid carbon credits to liquid carbon reference tokens, and bridges off-chain carbon credits on-chain. Toucan is currently built on Polygon and was founded by Raphaël Haupt in 2020.

Toucan team & investors own and govern the protocol. Toucan’s investors include USV, Earthshot Ventures, etc.

github

twitter

website

Infrastructure

Toucan Protocol

# Toucan Protocol Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of unique users who interact with Toucan Protocol within any 7-day rolling window. This metric answers the business question: "How many distinct users are actively engaging with Toucan's carbon token ecosystem on a weekly basis?" The calculation uses HyperLogLog probabilistic data structures to efficiently count unique users across multiple dimensions while maintaining accuracy for large-scale blockchain data.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Carbon token redemption events**: Parsed smart contract events from Toucan Protocol capturing `BCT_Redeemed` and `NCT_Redeemed` events on Polygon and Celo networks
- **Blockchain transaction metadata**: Transaction timestamps, hashes, and log indices from Polygon and Celo blockchains
- **Smart contract event logs**: Parsed event logs containing redeemer addresses and transaction context from Toucan's carbon token contracts

## 3. Step-by-step calculation

### Component A: User interaction extraction
- **Purpose**: Identifies all user interactions with Toucan Protocol through carbon token redemptions
- **Logic**: Extracts redemption events for Base Carbon Tonnes (BCT) and Nature Carbon Tonnes (NCT) from both Polygon and Celo networks. Each redemption event captures the user address (`account` field) who performed the redemption, along with transaction metadata including block timestamp, transaction hash, and log index. Users are classified as 'Redeemer' type based on these redemption activities. The data includes chain identification, market sector classification as 'infrastructure', and business segment as 'other'
- **Key fields**: `block_timestamp` for timing, `user_address` for unique user identification, `chain` for network classification, `user_type` as 'Redeemer'

### Component B: Daily active user aggregation  
- **Purpose**: Converts raw user interactions into daily unique active user counts using probabilistic data structures
- **Logic**: Groups user interactions by day using timestamp truncation to daily granularity, then creates HyperLogLog sketches for each unique combination of date, chain, user type, and product. The HLL initialization uses 15-bit precision to balance memory efficiency with counting accuracy. This approach allows efficient approximate counting of unique users while handling the scale of blockchain data
- **Key fields**: `timestamp` (daily granularity), `chain`, `user_type`, `product_id`, `hll` (HyperLogLog sketch containing user addresses)

### Component C: Date spine generation
- **Purpose**: Creates a complete time series without gaps to ensure accurate rolling window calculations
- **Logic**: Generates a continuous daily timestamp array from the earliest data date to yesterday, ensuring no missing days in the time series. This prevents rolling windows from skipping periods due to missing data. For incremental updates, the spine starts from a calculated lookback period based on the last modification time
- **Key fields**: `timestamp` (complete daily series)

### Component D: Rolling window creation
- **Purpose**: Builds 7-day rolling windows by joining each day with its preceding 6 days
- **Logic**: For each date in the spine, creates a join table that includes that date plus the previous 6 days, resulting in 7-day windows. This uses timestamp arithmetic to subtract 6 days and generate arrays of dates for joining. Each row in the result represents one day within a 7-day window, enabling the aggregation of weekly unique users
- **Key fields**: `timestamp` (target date), `joinday` (individual days within the 7-day window)

### Component E: Weekly unique user calculation
- **Purpose**: Aggregates HLL sketches across 7-day windows to count weekly unique users
- **Logic**: Joins the rolling window structure with daily HLL data, then merges HLL sketches across all days within each 7-day period. The `hll_count.merge_partial` function combines multiple HLL sketches while maintaining uniqueness guarantees. Finally, `hll_count.extract` converts the merged HLL sketch back to an approximate unique count representing weekly active users
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, merged `hll` sketches

### Component F: Dimensional breakdowns
- **Purpose**: Creates separate analytical views for different business dimensions
- **Logic**: Generates four distinct breakdowns by aggregating weekly user data across different dimensions: project-level (all chains and products combined), chain-level (by individual blockchain), user type level (by user classification), and product-level (by specific products). Non-relevant dimensions are set to null for each breakdown, and a `dimensions` field identifies the aggregation level
- **Key fields**: `dimensions` (breakdown type), relevant dimension fields, nullified non-applicable fields, `user_wau` (final count)

### Final aggregation
- **Combining components**: The four dimensional breakdowns are combined using UNION ALL operations to create a single result set containing multiple analytical perspectives of the same underlying WAU data
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Data is aggregated to daily timestamps representing the end date of each 7-day rolling window, with weekly unique user counts calculated for each day
- **Final calculation**: The final metric value represents the approximate number of unique users who performed at least one carbon token redemption within any 7-day rolling window ending on the given date, calculated using probabilistic counting via merged HyperLogLog sketches across the time window

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

Unique revenue-generating users over a rolling 7-day window.

Toucan Protocol

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown