Financial Methodology — v2

How Zetta Builds Agent Financial Statements

Revenue figures are only meaningful if the classification behind them is defensible. This page documents what counts, what is excluded, and how confident we are in every number we show.

June 2026 — Revenue Classification v2. We updated our methodology to quarantine capital injections, bridge transfers, token distributions, and grant inflows from operating revenue. All headline figures now reflect operating revenue only. Quarantined amounts are visible in admin views but excluded from public aggregates.

0. The fundamental rule

We only show numbers we can defend. When we cannot classify a transaction with confidence, we quarantine it — we do not count it as revenue and we do not hide it. Numbers shown publicly are conservative by design.

Accuracy is more important than making the numbers look large.

1. Attribution — the prerequisite

An agent is attributed when its operator declares wallet addresses via a signed manifest (.agent/wallets.json) or the registry submission flow. Only attributed agents appear in Agent GDP and the leaderboard.

Attribution is self-declared. Wallet ownership is not cryptographically verified on-chain. The declaring operator is responsible for the accuracy of their manifest. Zetta reviews manifests before approving inclusion.

An agent with no declared wallets has zero economic visibility — its on-chain activity exists but cannot be read by Zetta. Submit a manifest →

2. Revenue classification (v2)

Not every inflow to a declared wallet is operating revenue. Zetta applies a layered classification filter before counting any inflow as revenue.

What counts as operating revenue

Payment received from a third party (not an own wallet)
Not a swap, bridge transfer, or DEX interaction
Counterparty has prior interaction history, or amount is consistent with service-level payments
Stablecoin inflow below the capital injection threshold from a known counterparty

What is quarantined (removed from headline revenue)

Capital injectionsSingle inflows exceeding $10,000 USD from a counterparty with fewer than 3 prior interactions are flagged as suspected capital injections. They are not counted as operating revenue. Fundraising, investor capital, and DAO treasury allocations fall into this category.

Grant inflowsInflows from known ecosystem grant program addresses (Base Grants, OP Foundation, Virtuals treasury) are tagged as grants and removed from operating revenue.

Token distributionsNon-stablecoin inflows from counterparties with no prior relationship — consistent with airdrops, token launch distributions, and LP reward claims — are quarantined.

Bridge receiptsInflows from bridge contracts (Across, Stargate, Hop, Wormhole, deBridge) represent cross-chain capital movement, not economic activity. Excluded from revenue.

3. Hard exclusions (never in P&L)

Internal transfersTransfers between two wallets that both belong to the same agent are treasury movement. Excluded from both revenue and expenses. Tracked and reported separately.

Token swapsAny transaction where the same tx hash produces both an inflow and outflow is a token swap. Additionally, any transaction where the counterparty is a known DEX router (Uniswap v3, Aerodrome, 1inch, Odos, Paraswap, PancakeSwap) is excluded from P&L.

Bridge transfers (expenses)Outbound bridge transfers are not operating expenses — the capital continues to exist on another chain. Bridge contract outflows are removed from the expense ledger.

Token contractsWallet addresses with the role token_contract or the agent's own token address are never scanned. Token contract interactions produce volume, not revenue.

4. Expenses

Expenses are outflows from declared wallets to third-party addresses, after removing swaps, bridge transfers, and internal transfers.

Expenses are classified by amount and counterparty pattern:

API Call — outflow < $1 USD
Data Access — $1–$5, repeated counterparty (likely x402)
Subscription — $5–$25, repeated counterparty
Compute — > $25

If an agent pays expenses from a wallet not declared in their manifest, those expenses are invisible to Zetta. Incomplete manifests produce understated expenses and overstated margins. This is a known limitation — manifests should include all operational wallets.

5. Treasury and runway

Treasury balance is the live stablecoin balance (USDC + USDT) of all wallets declared with role: "treasury". It is a point-in-time snapshot, not a time-averaged figure.

Runway is computed as:

runway_months = treasury_balance / 30d_expenses

Both metrics are null if no wallet with role: "treasury" is declared. A missing treasury role does not mean the agent has no treasury — it means the wallet has not been declared with that role.

6. Agent GDP

Agent GDP is the sum of operating_revenue_usd across all attributed agents for the trailing 30 days. This is operating revenue after quarantine — it excludes capital injections, grants, bridge receipts, and token distributions.

Agent GDP is a lower bound. It reflects attributed agents only, and only operating revenue within those agents. The true agent economy is larger than what is visible here — attribution coverage and operating revenue classification are the constraints, not economic activity.

7. Confidence scoring

Every agent's books carry a per-metric confidence score. Confidence reflects the quality of the attribution and classification — not the quality of the agent's business.

High confidenceAll wallets verified. Multiple wallet roles declared (treasury, fee, operator). No quarantined inflows. Attribution source is a signed manifest.

Medium confidenceWallets declared but not cryptographically verified. Single wallet only. Attribution source is registry submission.

Low confidenceWallet confidence unset or unknown. No role metadata. No treasury wallet declared. Quarantined inflows present.

Confidence scores are displayed on agent profiles and in the leaderboard. A low confidence score does not mean the agent is inactive — it means the financial data should be read as directional, not precise.

8. Data freshness

Agent books are cached for up to 4 hours. The refresh cycle runs every 4 hours. When a refresh runs, every attributed agent's books are recomputed from live on-chain data via Alchemy. The leaderboard displays a "last updated" timestamp.

9. Known limitations

Base chain onlyZetta currently scans Base mainnet only. Agents operating cross-chain cannot be fully attributed until multi-chain support is added.

Self-declarationManifests are self-declared. Zetta reviews them before approval but does not perform cryptographic proof-of-ownership. Declared wallets are attributed, not proven.

Stablecoin pricingUSDC and USDT are treated as $1.00. Non-stablecoin tokens are priced at Alchemy's available market price at scan time. Historical prices may differ from transaction-time prices.

Incomplete manifestsAn agent that controls 10 wallets but declares only 2 will show books for those 2 wallets. Revenue and expenses from undeclared wallets are invisible. Agents are responsible for the completeness of their manifests.

Bridge contract listThe bridge exclusion list covers major Base bridges (Across, Stargate, Hop, Wormhole, deBridge, Base native bridge). Unknown or newer bridge contracts may not be excluded.

← Leaderboard Submit a Manifest →

Revenue Classification v2 — June 2026. All figures are derived from on-chain data only. No estimates. No synthetic values. Quarantined inflows are never hidden — they are excluded from headline revenue and visible to operators in their admin view.