Overcollateralized borrowers deposit funds into Abracadabra and receive MIM stablecoin.

Abracadabra is a non-custodial stablecoin protocol built on Ethereum and other adjacent blockchains. Abracadabra was founded by Daniele Sestagalli and launched in 2021.

SPELL tokenholders own and govern the protocol. Currently, the interest and borrowing fees paid by borrowers (revenue) are shared between tokenholders and the project treasury.

governance

github

twitter

discord

etherscan

website

Stablecoin issuers

Abracadabra.money

# Abracadabra.money Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the number of unique users who interact with Abracadabra protocol over a 30-day rolling window. This metric captures users engaging in core protocol activities including borrowing, repaying loans in Cauldron contracts, and bridging tokens through LayerZero infrastructure. The calculation uses HyperLogLog probabilistic data structures for efficient unique user counting across multiple blockchains and activity types.

## 2. Data sources

The methodology relies on the following raw blockchain data sources:

- **Protocol events**: Parsed `LogBorrow` and `LogRepay` events from Abracadabra Cauldron contracts deployed on Ethereum, Arbitrum, Avalanche, BSC, and Fantom
- **Bridge events**: Parsed `SendToChain` events from LayerZero OFT contracts including `LzIndirectOFTV2` events from Base, Arbitrum, Avalanche, BSC, Fantom, and Polygon, and `LzProxyOFTV2` events from Ethereum
- **Token transfers**: Token transfer event logs used to identify actual users behind wrapper contract interactions for bridge transactions
- **Chain availability data**: Configuration data defining which chains are available for analysis at different time periods

## 3. Step-by-step calculation

### Component A: User identification and classification

- **Purpose**: Extract and classify unique user addresses from Abracadabra protocol interactions across multiple blockchains
- **Logic**: The system processes two types of user activities. For direct protocol interactions (borrowing and repaying), user addresses are extracted directly from the `from` parameter in `LogBorrow` and `LogRepay` events emitted by Cauldron contracts. For bridge transactions, the process is more complex because users interact through wrapper contracts. The system identifies bridge events (`SendToChain`) where the recipient address matches known OFT wrapper addresses, then cross-references these transactions with token transfer events to identify the actual user addresses behind the wrapper interactions. Users are classified by activity type as Borrower, Repayer, or Bridger, and tagged with the originating blockchain.
- **Key fields**: User activities include `user_address` (the actual user), `user_type` (Borrower/Repayer/Bridger), `chain` (originating blockchain), `block_timestamp` (when the activity occurred), and `transaction_hash` (unique transaction identifier)

### Component B: Daily active user aggregation

- **Purpose**: Aggregate user activities into daily unique user counts using probabilistic data structures
- **Logic**: Raw user activities are grouped by day using timestamp truncation to daily boundaries. The aggregation groups by timestamp, chain, user type, and product dimensions. Instead of exact counting, the system uses HyperLogLog (HLL) data structures initialized with precision parameter 15 to efficiently estimate unique user counts. This approach enables scalable cardinality estimation while maintaining reasonable accuracy for large user sets.
- **Key fields**: The output includes `timestamp` (daily boundary), `chain_id`, `user_type`, `product_id`, and `hll` (HyperLogLog sketch containing user count estimates)

### Component C: Rolling window construction

- **Purpose**: Create a systematic 30-day rolling window structure for calculating monthly active users
- **Logic**: The system generates a comprehensive datespine covering all days from the earliest available data to yesterday. For each day in this spine, it creates associations with the current day plus the previous 29 days, forming complete 30-day windows. This ensures consistent MAU calculation even when certain days have no activity. The process uses timestamp generation functions to create these rolling windows and joins them with the daily HLL sketches from Component B.
- **Key fields**: The window structure includes `timestamp` (the end date of each 30-day window), `joinday` (each of the 30 days in the window), and associated HLL sketches for user counting

### Component D: Monthly active user calculation by dimension

- **Purpose**: Calculate unique users over 30-day windows across multiple analytical dimensions
- **Logic**: For each 30-day window, the system merges all HLL sketches from the constituent days to estimate the total unique users. This calculation is performed across four different dimensional breakdowns. Project-level MAU aggregates all users regardless of chain, product, or user type. Chain-level MAU breaks down users by originating blockchain. User type-level MAU segments users by activity type (Borrower, Repayer, Bridger). Product-level MAU would break down by specific products, though Abracadabra currently uses null product identifiers. The HLL merge operations efficiently combine sketches while maintaining cardinality accuracy.
- **Key fields**: Each dimensional breakdown includes `timestamp`, `dimensions` (the breakdown type), relevant dimension values (`chain_id`, `user_type`, `product_id`), and `user_mau` (the estimated unique user count)

### Final aggregation

- **Combining components**: The four dimensional breakdowns are combined using union operations to create a unified dataset containing MAU values across all analytical perspectives
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: The calculation maintains daily granularity for the 30-day rolling windows, with each day representing the MAU for the preceding 30-day period
- **Final calculation**: The methodology applies the `finalize_metric_user_mau` macro to standardize the schema, add metadata fields like data source identifier ('abracadabra'), and implement a fill strategy that inserts zeros for missing days to ensure complete time series continuity

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

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

Abracadabra.moneySPELL

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown