Methodology v1.0

Farelight Research measures what AI agents pay for on Arc. This document defines what we count, how each payment is classified, and where the method is known to be weak. Every number on the Console states the methodology version it was computed under. Rules and thresholds live in one versioned config; changing them produces a new version, and prior versions stay readable.

1. What is counted

Payments. Every EIP-3009 authorization consumed on the Arc mainnet USDC contract (0x3600…0000) and, separately, EURC (0xbEf5…21c1). Each AuthorizationUsed event is paired with the Transfer it authorized in the same transaction, from the authorizer, nearest by log index. One row per authorization, so a batched transaction yields several rows.

• Only Transfer events emitted by the token contract are used. Arc also emits a mirror Transfer from a system address (0xffff…fffe, 18 decimals) for every USDC movement (EIP-7708). Counting it would double volume and inflate it by 10^12.
• Amounts are stored as integers in the token's smallest unit and shown in USDC.
• Gas cost is recorded in USDC at 18 decimals, the native unit.

x402-likely. A payment is marked x402-likely when the transaction was submitted by an address labeled as an x402 facilitator. Labels require evidence: a settlement we made ourselves through that facilitator, or a signer the facilitator publishes, confirmed on-chain. Unlabeled submitters are listed publicly as unattributed, ranked by volume.

Payment types.

• transfer: an EIP-3009 transfer to an ordinary payee. Only this type is classified.
• gateway_deposit: a transfer into Circle's GatewayWallet (0x7777…00eE). Gateway nanopayments settle off-chain in batches, so deposits are the only on-chain proxy for that activity. They are reported as their own series and never counted as payments.

Phases. Arc ran a private mainnet before public launch. Every payment is tagged private or public by block number. The boundary is block 21,056,228 (2026-09-15 22:15 UTC), where distinct senders per block begin a sustained rise from a handful of repeat builders to hundreds of new wallets per hour. Official sources give only the launch date, not a time, so the boundary is derived from the chain. It is approximate to within minutes of a gradual ramp and pinned so it cannot shift silently.

Not counted. Plain ERC-20 transfer calls, native sends, and DEX activity. These are not x402 settlements. They are read only where a rule needs them (funding sources, refunds).

2. Classifications

Each transfer payment receives exactly one classification. Rules are evaluated in order, and the first match wins:

test → funding → refund → wash → script → agent → unknown

Only agent counts as commerce. The Console labels it Likely agent: on-chain data can show that a payment looks like autonomous commerce with a third-party service. It cannot prove an AI made it.

test: setup or verification traffic

• T1. Payer and payee are the same address.
• T2. The payer has at most 3 lifetime payments, all ≤ 0.001 USDC, and none in the last 7 days.
• T3. The payee is the payer's own funder (paying back the wallet that funded you). Funding via a payment does not count.
• T4. The amount is 0 or 1 raw unit.
• T5. The payer or payee is labeled test. This covers Farelight's own seed payments and test wallets.

funding: money moved so a wallet can act later

• F1. The payment is the payee's first qualifying inbound USDC transfer, the payee is not a labeled service, facilitator or Circle address, and either:

  • F1a. the payee later makes at least one payment itself (funded to spend), or
  • F1b. the payer's payments are the first funding of at least 10 distinct wallets (a fan-out distributor).

  Why: on 2026-09-23, 71.9% of the value settled by the largest x402 relayer on Arc by value was a single 5,000 USDC transfer to a distributor, which then sent 1.00 USDC to 646 new wallets. Counted as commerce, those transfers would dominate every volume figure.

  Guard: a merchant's first sale is also its first inbound USDC. Without F1a/F1b and the label exclusion, every service's first customer payment would be misread as funding.

refund: a service returning money to a customer

• R1. The payer is a labeled service, and the payee paid that service at least once in the preceding 7 days. Cumulative refunds from the service to that wallet in the window may not exceed what the wallet paid it. Any excess is not a refund.

  Why: pay-per-call services such as ArcRouter charge a ceiling up front and refund the unused part in batches. A refund therefore rarely equals any single payment, and a round-trip rule would flag it as wash.

wash: value that returns to its origin, or both sides controlled by one party

• W1. Payer and payee share a funding cluster, or one funded the other. Only funding that arrived as a plain transfer, native send or bridge-in counts; a payment is never a funding edge. A service's first inbound USDC is usually its first customer's payment, which is a sale, not common control.
• W2. Round trip: A→B followed by B→A within 24 hours at ±5% of the amount. Service refunds tagged by R1 are exempt.
• W3. The payee forwards ≥ 90% of what it received back to the payer's cluster within 1 hour, at least 3 times.

script: automated and non-agentic

• S1. A payer→payee pair with at least 20 payments whose inter-payment intervals have a coefficient of variation below 0.1 (clockwork timing).
• S2. A payer with one lifetime payee, at least 50 payments, and identical amounts.

agent: plausible autonomous commerce

• A1. The payment was submitted by a labeled facilitator (x402-likely), and at least one of:
  • A1a. the payer has paid at least 2 distinct payees;
  • A1b. the payee is a labeled service;
  • A1c. the payer's timing is irregular (interval coefficient of variation ≥ 0.5 over at least 5 payments).

unknown

Everything else. Most often: not submitted by a known facilitator, and no stronger signal.

3. Funding sources and clusters

A wallet's funding source is its first qualifying inbound USDC transfer, read from the EIP-7708 mirror stream, the only record that includes native sends:

• the sender and receiver differ, and the receiver is not the zero address;
• the amount is at least 0.01 USDC. Smaller transfers are application-level fee splits. Gas fees emit no transfer record at all.
• a transfer from the zero address is a mint (for example a CCTP bridge-in). It is a valid funding source, recorded as "bridged in".

Wallets sharing a funding source form a cluster, counting only funding that was not itself a payment. Funders labeled as Circle or an exchange, and any funder of more than 500 wallets, are not clustered through; they are labeled instead.

4. Confidence

Each classification carries the rules that fired, their evidence (related transactions, cluster), and a confidence between 0 and 1. It starts from a base per rule and adjusts slightly for supporting evidence. Confidence is shown next to every classification. It is not a probability calibrated against ground truth; none exists yet.

5. Known limitations

• Agent identity cannot be proven on-chain. Likely agent means the payment looks like autonomous commerce.
• Facilitator coverage is only as good as the labels. Settlements by unlabeled relayers are never Likely agent, even if they are.
• Refunds paid by plain transfers are read from service outflows. A service not yet labeled has its refunds classified by the other rules.
• Contract-routed settlements are counted, but their method (transferWithAuthorization vs. receiveWithAuthorization) cannot be decoded and is recorded as unknown.
• Gateway nanopayments are not decomposable. Only deposits and settlements are visible.
• Private-phase activity reflects a builder-only period and is shown separately.

6. Reconciliation

Daily counts per submitter are compared with an independent index (Wicket, wicketworld.xyz) under its own inclusion rules. On the first comparison (2026-09-23), every comparable day-and-submitter row matched exactly. Differences outside its scope (private phase, Gateway deposits, contract-routed settlements) are itemized in the decisions log.

Changelog

• v1.0 (final, frozen 2026-09-24). Frozen as of classification run 6 (rules hash 0eb0d034931a), the run behind report 001. Any rule or threshold change is a new version (v1.1) and never alters v1.0 results. Initial rules, with funding (F1) and refund (R1) added before wash on 2026-09-23.