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 Revenue Methodology

## 1. Overview

Toucan Protocol revenue represents the total redemption fees collected by Toucan from carbon credit token redemptions. The calculation captures token transfers to Toucan's ecosystem fund addresses and retirement pool addresses across Polygon and Celo networks. These transfers represent fees paid by users when redeeming carbon credit tokens (BCT and NCT) from Toucan's pools. The metric aggregates these fee transfers daily and converts them to USD for standardized reporting.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Token transfer events**: Parsed `Transfer` events from Polygon and Celo blockchains, specifically filtering transfers to Toucan Protocol addresses
- **End-of-day token price feeds**: USD price data for token valuation and currency conversion
- **Token metadata**: Contract information including decimal precision for amount normalization
- **Hardcoded configuration**: Predefined lists of Toucan Protocol addresses (ecosystem funds and retirement pools) and denylisted scam token addresses

## 3. Step-by-step calculation

### Component A: Redemption fee extraction
- **Purpose**: Identifies all token transfers representing redemption fees paid to Toucan Protocol
- **Logic**: Extracts token transfer events where the recipient address matches specific Toucan Protocol addresses. These addresses include ecosystem fund addresses and retirement pool addresses (BCT and NCT pools) on both Polygon and Celo. The system filters for transfers to six predefined addresses: ecosystem fund addresses and two retirement pool addresses on each chain. Only non-removed transfer events are included to ensure data quality.
- **Key fields**: Block timestamp for daily aggregation, recipient address (`to_address`) for fee identification, token contract address, and transfer `value` amount representing the fee

### Component B: Scam token filtering  
- **Purpose**: Removes fraudulent or scam token transfers from revenue calculations
- **Logic**: Applies a denylist of known scam token addresses on Polygon to exclude transfers involving these tokens. The denylist contains hardcoded addresses of tokens identified as scams or fraudulent projects attempting to inflate Toucan's apparent revenue.
- **Key fields**: Token contract `token_address` matched against denylisted addresses, `chain` for chain-specific filtering

### Component C: Token address standardization
- **Purpose**: Normalizes token addresses across chains for consistent processing
- **Logic**: Maps Celo versions of NCT and BCT tokens to their corresponding Polygon addresses. This mapping allows the system to use Polygon-based token metadata and pricing for all tokens regardless of their origin chain. Celo NCT address maps to Polygon NCT address, and Celo BCT address maps to Polygon BCT address.
- **Key fields**: Original `token_address` from source chain, mapped `token_address` for processing, `real_chain` preserving the actual source blockchain

### Component D: Currency conversion and decimal correction
- **Purpose**: Converts raw token amounts to standardized USD values with correct decimal precision
- **Logic**: Applies token-specific decimal corrections based on contract specifications, then converts amounts to USD using end-of-day price feeds. The system temporarily treats all tokens as if they were on Polygon for lookup purposes while preserving the actual chain information. This standardization enables consistent pricing across different blockchain networks.
- **Key fields**: Raw `amount` from transfer events, corrected decimal-adjusted amounts, USD-converted values using end-of-day prices

### Component E: Business metadata population
- **Purpose**: Enriches revenue data with business classification and project information
- **Logic**: Applies the finalize metric macro to populate standard business metadata fields including business line (Asset management), market sector (infrastructure), business segment (other), and version information (v1). The system also applies account names based on the recipient address type (Ecosystem fund vs specific retirement pool names).
- **Key fields**: `business_line`, `market_sector_id`, `business_segment_id`, `account_name` indicating whether fees came from ecosystem fund or specific retirement pools

### Final aggregation
- **Combining components**: All processed redemption fee transfers are aggregated by day, chain, token, and account dimensions
- **Currency conversion**: Amounts are converted to USD using end-of-day token prices with proper decimal normalization applied first
- **Time aggregation**: Data is truncated to daily boundaries using block timestamps, with each day representing the total redemption fees collected
- **Final calculation**: The final revenue metric represents the sum of all redemption fee transfers to Toucan Protocol addresses, converted to USD and aggregated daily, with scam tokens excluded and proper decimal corrections applied

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

Toucan Protocol

Revenue

Revenue

Competitive landscape

Chain breakdown