Smart account activity: transactions are not users
Smart-account activity has several counting layers: base-layer transactions, bundled operations, smart accounts and underlying people or organizations. Define the layer before comparing adoption across applications. A single transaction can represent several operations, while one account can execute many actions without representing many users.
ERC-4337 describes UserOperations, bundlers and EntryPoint handling. It provides the mechanism for distinguishing these objects, not a person-level user census. This worksheet applies that distinction to research statistics without assuming every chain or wallet uses the same account architecture.
Specify the activity unit
Identify network, EntryPoint deployment, observation block range and operation version. Record whether the dataset includes submitted requests, accepted operations or successful execution. A failed request can be meaningful operational activity but should not silently count as a completed application action.
Build a mapping from transaction hash to operation identifier, sender account and execution outcome. Keep inner application calls as another layer if they are part of the research question. An operation performing several calls should not be equated with one economically meaningful purchase unless the application evidence establishes that meaning.
Distinguish the bundler from the account whose action it carries. Counting base transaction senders can measure bundler infrastructure rather than end-user accounts. Likewise, a fee sponsor is not necessarily the beneficiary or controller of the account. Preserve these roles instead of putting every address into a single user column.
Hypothetical bundle comparison
Assume fictional Application Brook observes ten base transactions containing 60 accepted operations from 45 distinct smart accounts during a day. Of those operations, 54 complete the intended execution and six fail. The dataset supports several valid statistics, but none is automatically 60 users.
If the previous day had 20 transactions containing 40 operations, transaction count fell while operation count rose. A transaction-only chart would tell the opposite activity story. If the bundler sender is the same for all transactions, counting senders would reduce the apparent audience to one infrastructure address.
Suppose five of the 45 accounts are known test accounts under a documented rule. Report 45 raw active accounts and 40 after that exclusion, with the rule attached. Do not claim 40 distinct people: one person may control multiple accounts, and one organization may share an account. Every number here is hypothetical.
Counting bridge
| Layer | Example | Interpretation |
|---|---|---|
| Base transactions | 10 | Bundle submission activity |
| Accepted operations | 60 | Included operation population |
| Successful operations | 54 | Defined execution outcome |
| Distinct sender accounts | 45 | Onchain account activity |
| Adjusted accounts | 40 | Result under stated test-account exclusions |
| Distinct people | Unknown | Requires additional identity evidence |
For repeat activity, define whether an account is active once per day, per application or over the whole interval. Sum of daily active accounts is not the number of distinct accounts in the month. Retain the set-based definition rather than simply adding daily totals.
Compare like measurements
Check whether a change in EntryPoint coverage or indexer support altered the measured population. Newly indexed operations can look like new adoption even if the underlying behavior already existed. Preserve coverage by deployment and version, with explicit gaps.
Also distinguish subsidized activity from evidence of willingness to pay. Sponsored fees can support genuine usage, but operation counts alone cannot establish demand at an unsubsidized cost. The appropriate memo reports account activity, success criteria, sponsorship scope and unknown identity overlap. It avoids converting infrastructure statistics into claims about human adoption or spot price.
FAQ
Is one UserOperation one user?
No. It is an operation associated with an account; repeated operations and multiple accounts can belong to the same actor.
Can I use transaction senders as smart-account users?
Not without separating bundler transactions from the accounts represented inside their bundles.