Back to home

Scoring Methodology

Written by Omnis Writer  ·  Last updated May 2026

Overview

Omnis classifies on-chain wallets by observing how they behave — not who they claim to be. Every USDC transfer on Base using the EIP-3009 gasless signature mechanism is indexed and processed through six independent behavioural layers. The outputs are combined into a single composite confidence score between 0 and 1. That score determines the wallet's verdict.

No off-chain data, identity verification, or private feeds are used. All signals derive exclusively from public on-chain behaviour.

Design principles

01 Behavioural, not declarative. Wallets are scored on what they do, not on labels, registrations, or self-reported attributes.
02 Continuous, not point-in-time. Scores update with every new transfer. A wallet's classification can change as its behaviour evolves.
03 Evidence-gated. A minimum transfer count is required before a verdict is issued. Wallets with insufficient history return unknown rather than a speculative classification.
04 Layer independence. Each scoring layer measures a distinct signal. A wallet can score high on one layer and low on others — the composite reflects the full behavioural picture.
05 Read-only. Omnis is an observation oracle. It does not transact, intervene, or take any action on-chain. It only watches and reports.

The six scoring layers

Each layer produces a score between 0 and 1. Layers are weighted by their relative signal strength and summed to produce the composite score.

Layer & signal Weight
1 — Auth Method
Measures the proportion of transfers using TransferWithAuthorization (EIP-3009) versus standard ERC-20 Transfer. EIP-3009 is a gasless, meta-transaction mechanism that requires pre-signed authorisation — it is the payment primitive of choice for autonomous agents because it enables programmable, gas-sponsored transfers without requiring the sender to hold ETH. Human users rarely encounter or use it directly. A wallet using TransferWithAuthorization for all or most of its transfers is exhibiting the payment pattern of an automated system.
Highest
2 — Timing Regularity
Measures the variance in intervals between consecutive transfers. Autonomous agents operate on schedules — polling intervals, cron jobs, or event-driven loops — that produce highly regular timing. Human transfer activity is event-driven and irregular. This layer computes a running statistical measure of interval variance using an online algorithm that updates incrementally with each new transfer, requiring no historical re-reads. A low coefficient of variation (tight clustering around a mean interval) scores high; high variance scores low.
High
3 — Value Precision
Measures the proportion of transfer amounts that are non-round. USDC has six decimal places. When an autonomous system computes a transfer amount — a fee, a calculated proportion, a rebalancing delta — the result is typically precise to multiple decimal places (e.g. 14.837291 USDC). When a human sends USDC, they almost always round to a familiar denomination (10, 50, 100, 500 USDC). This layer counts the proportion of non-round, non-half-dollar amounts as a proxy for programmatic computation.
Medium
4 — Counterparty Concentration
Measures how concentrated a wallet's transfer activity is across counterparties. Autonomous agents typically interact with a narrow set of addresses — protocol contracts, liquidity pools, service providers — repeatedly and consistently. Human wallets tend to have more diverse counterparty graphs. This layer also detects self-loop transfers (wallet sending to itself), which is a strong agent test-pattern signal — agents frequently use self-transfers during testing and balance checks. Both concentration ratio and self-loop presence contribute to the score.
Medium
5 — Transfer Frequency
Measures transfer rate relative to the time span of observed activity. High-frequency activity — multiple transfers per hour sustained over days — is well above the human baseline and strongly suggests automated operation. This layer computes transfers per day from the span between the first and last observed transfer. The score increases non-linearly: moderate frequency scores partially, while very high frequency (>10 transfers/hour) scores at maximum.
Lower
6 — Origin Type
Classifies the originating context of the wallet's activity — specifically whether transfers appear to be initiated by smart contracts or external EOA calls. Contract-initiated transfers are a strong indicator of agent framework operation, where an orchestration layer calls into a payment contract on behalf of a wallet. This layer is currently at partial implementation; the score reflects a conservative estimate while full transaction receipt analysis is developed as a future signal.
Lower

Composite score

Each layer score (0–1) is multiplied by its weight and summed to produce the composite confidence score:

confidence = Σ ( layer_score × layer_weight )

The weights are calibrated so that the two strongest signals — Auth Method and Timing Regularity — together account for the majority of the composite. The remaining four layers provide supporting evidence that refines the classification.

The result is always between 0 and 1, where values near 1 indicate strong autonomous behaviour patterns across multiple independent signals.

Verdict thresholds

The composite confidence score maps to one of three verdicts. A minimum of three observed transfers is required before any verdict is issued.

Agent
≥ 0.60
Strong autonomous behaviour patterns across multiple independent layers. High confidence that activity is programmatically driven.
Suspicious
≥ 0.35
Agent-like signals present but the behavioural picture is mixed, or evidence is present but not yet sufficient for high confidence.
Human
< 0.35
Behaviour consistent with human activity patterns. Low or absent agent signals across the scoring layers.

One additional rule applies: any wallet that uses TransferWithAuthorization at all — regardless of composite score — cannot be classified as Human. If the composite would place it in the Human band but EIP-3009 usage is present, the verdict is elevated to Suspicious. This reflects the strong prior that humans do not routinely use gasless meta-transactions.

What Omnis does not use

The following signals are explicitly excluded from the current model, either because they require off-chain data, introduce privacy concerns, or have not yet been validated:

  • Wallet age or creation date
  • ENS names, labels, or any identity layer
  • NFT holdings or social graph data
  • Transaction gas prices or MEV activity
  • Cross-chain activity on other networks
  • Any off-chain oracle or private data feed

Limitations

No behavioural classification system is perfect. Omnis is designed to be useful, not infallible. Known limitations:

  • New wallets. Wallets with fewer than three transfers return unknown. Classification improves as transfer history accumulates.
  • Mimicry. A sophisticated actor deliberately mimicking human transfer patterns could reduce their score. This is unlikely in practice but cannot be fully excluded.
  • Hybrid wallets. Some wallets are operated by both humans and agents — a human may use the same address as their agent deployment wallet. Omnis scores the aggregate behaviour, not the intent behind any individual transfer.
  • Origin layer. The origin type layer is currently at partial implementation. Scores in this layer are conservative estimates pending full transaction receipt analysis.

Ongoing development

The scoring model is not static. As the agent economy on Base develops, new behavioural patterns will emerge and existing signals will be recalibrated. Planned future signals include full transaction receipt analysis for origin classification, cross-event temporal clustering, and expanded support for additional token standards and chains.

Methodology updates will be reflected on this page. The scoring engine version is logged against every wallet profile so that historical classifications remain traceable.

See the scores in action — wallets are being classified on Base right now.

Open dashboard

Questions

For methodology questions, research enquiries, or integration discussions: [email protected]