Base in numbers.
Builder Codes we track, the apps that are verified, and the activity they bring on Base.
Every number on this page follows these three filters. Periods are the last N × 24 hours, the same window as the leaderboard; charts use UTC days. All indexed = every Builder Code operation we index. BuildBoard codes = the codes in our registry. Verified apps = the approved subset of those. Details under “How this is counted”.
Loading Base activity…
Activity
Users per day · 30 days
Wallets
Successful sender addresses · no addresses shown
Retention
Share of new wallets that came back later
Each row is a group of wallets first seen on that day. D1, D7 and D30 show how many came back on or after that milestone. Rows that are still too recent to measure show a dash.
| First seen | New wallets | D1 · 1 day | D7 · 7 days | D30 · 30 days |
|---|---|---|---|---|
| Loading… | ||||
A dash means there is not enough history yet, not a zero result.
BuildBoard codes vs verified
Users · last 24 hours and 7 days
How much activity do we cover?
Loading…
Coverage is the share of indexed Base activity attributed to Builder Codes we track, and to the verified apps among them. Users are unique successful senders, counted once across apps within each window. Transactions include failed and unknown-status operations.
How this is counted
Definitions
Periods. The 1, 7, 14, 30 and 90 day figures are rolling windows: the last N × 24 hours up to the newest indexed block, the same window the leaderboard uses. The KPIs, the total in period, the 24-hour and 7-day comparison and the wallet totals all use it.
Charts. Daily and weekly bars and the wallet chart use calendar buckets in UTC, with weeks starting on Monday. The day still in progress is shown but left out of peak and latest-day figures, and weekly bars include complete weeks only.
Why a total can differ from the bars. A rolling window starts at the same time of day it ends, so it does not line up with calendar days. Adding up the bars for the same number of days can give a different figure.
Unique wallets are distinct sender addresses with at least one successful attributed operation in the window, counted once across all apps in scope. Wallet-days count each wallet once per UTC day; app-days count each wallet once per app per UTC day.
New wallets are first seen on a UTC day inside the period, or inside the chart bucket. Returning wallets were active on an earlier day, before the period or bucket, or came back on a later day inside the period. A wallet can be both new and returning in a total, so the two can add up to more than the unique count.
Retention. Wallets are grouped by the UTC day they were first seen. D1, D7 and D30 show the share of a group that was active again on or after day 1, 7 or 30. A group only counts once its milestone day has been indexed.
Fees are L2 gas fees in ETH: gas used × effective gas price for a normal transaction, or the actual gas cost of an ERC-4337 operation. Base's L1 data fee is not indexed, so the full cost paid is higher. Like transactions, an operation carrying several Builder Codes counts for each code, and failed operations are included because they still pay gas.
What we track: Base mainnet, Builder Code attribution and sender addresses. Transactions include failed and unknown-status operations. Data starts on October 7, 2026, the first day the index covers, so earlier days are not shown.