👩💻
Active users
TLDR: An active user of a protocol is a user that interacts with that protocol during a predefined time interval (daily, monthly).
It is well-known that calculating active users is an activity that is fraught with technical limitations and challenges. There is no standardized definition for what types of interactions a user must undertake for them to be considered an active user, especially in a nascent field such as Web3 and decentralized finance.
Therefore, we aim to be pragmatic by providing a simple but useful metric that is correlated to the degree of usage of crypto protocols, particularly to their revenue-generating activities. Even with all the limitations that this metric carries, we believe it is still useful to provide active user figures that are directionally correct and whose difference can be tracked over time.
Furthermore, by clearly communicating how we define active users for each project, we empower Token Terminal users to themselves exercise judgement on whether they agree or not with how the metric is defined.
We use one of two main approaches to track active users:
- 1.Using events: we define relevant smart contract events and function calls, and track their parameters which refer to the addresses engaged in business-relevant activities. This allows us to track usage based on a particular usage type (e.g. Traders and/or Liquidity Providers in the case of Uniswap).
- 2.Using transactions: we define business-relevant wallets and smart contracts belonging to a project and track addresses sending transactions to these accounts.
We always prioritize tracking user activity from events. However, it is often the case that relevant events are not emitted due to a variety of reasons (e.g. smart contract optimization, lack of a focus in metric reporting). In these cases, we default to tracking user activity using transaction data.
The following two real examples are provided to clearly illustrate what we mean by tracking user activity using transactions and events.
The following table lists events and the specific parameters used to track addressess from which we derive user counts. This example refers to the Aave deployment on the Ethereum blockchain. The same logic can also be applied for their deployments on other blockchains (Avalanche, Polygon, etc.).
Contract | Address | Events | Parameters |
|---|---|---|---|
LendingPool | 0x7d2768dE32b0b80b7a3454c06BdAc94A69DDc7A9 | Borrow
Deposit
FlashLoan
RepayWithdraw | user
user
initiator
useruser |
AMMLendingPool | 0x7937D4799803FbBe595ed57278Bc4cA21f3bFfCB | Borrow
Deposit
FlashLoan
Repay
Withdraw | user
user
initiator
user
user |
By tracking these data points for any given lending pool we're able to categorize the users of the protocol according to 4 different user types: Borrowers, Depositors, Repayers and Withdrawers. The end result of this categorization can be seen on Aave's project dashboard:
Aave's daily active users composition for the past 180 days.
In the case of MetaMask, we determine user activity via transactions due to the lack of events related to the activity we're interested in tracking. We monitor transactions in the involving the following contracts:
Contract | Address |
|---|---|
MetaMask: Swap Router | 0x881D40237659C251811CEC9c364ef91dC08D300C |
MetaMask: DS Proxy | 0xF326e4dE8F66A0BDC0970b79E0924e33c79f1915 |
Once we have gathered what we consider to be MetaMask's business relevant contract addresses, we retrieve all the on-chain transactions received by those addresses and count users as the distinct addresses sending those transactions.
Even though this prevents us from categorizing usage at its most granular level, the smart contract-level aggregation gives enough information for doing baseline analysis of usage trends.
Last modified 5mo ago