Methodology

This document is intended to make clear:

• what Depth attests to and does not attest to
• how the four payload objects are separated
• which normalized pool types are currently surfaced
• what flips structural support at a high level
• what flips execution eligibility at a high level
• what coverage means and does not mean
• what computation boundaries are intentional
• what the public commitment surface attests to

Depth's public payloads describe Base mainnet liquidity and execution context.

Early beta commitments were anchored on Base Sepolia. Canonical live commitments are now anchored on Base mainnet.

Consumers should use oracle_chain_id to interpret proof provenance:

• 8453 — canonical live commitments on Base mainnet
• 84532 — historical beta commitments on Base Sepolia

This transition changed the proof network, not the underlying liquidity domain.

A public Depth payload attests that the payload was produced and committed under explicit semantics. At a high level, a payload can tell a reader:

• whether a pool is structurally legible under Depth's current model
• whether recent execution evidence was observed
• whether the pool passed the current execution policy
• which computation sections were computed, not computed, or intentionally not modeled
• which unknowns are disclosed rather than implied

Depth does not attest to:

• future liquidity persistence
• execution outcomes
• trade profitability
• general safety
• downstream routing correctness

Depth keeps pool evidence partitioned into four distinct objects.

Structural Support — This answers: Can this pool be reasoned about under Depth's current structural model? Structural support is about legibility, not desirability.

Observation Coverage — This answers: What execution-derived evidence was actually observed, and over what window? Coverage is observational only. It is not a recommendation, and it is not itself a policy outcome.

Execution Policy — This answers: Did this pool pass Depth's current execution-context qualification policy? This is an explicit policy outcome derived from structural support, TVL posture, execution evidence, and supported model constraints. It is meant to be read alongside the surfaced liquidity and observation metrics, not as a standalone execution instruction.

Computation Disclosure — This answers: What did Depth compute, what did it refuse or skip, and why? This includes disclosures such as not_computed, not_modeled, structural_unsupported, and execution_ineligible.

Reasons are intentionally kept within their own object:

• structural issues stay in structural support
• observation notes stay in coverage
• eligibility reasons stay in execution policy
• section-level compute reasons stay in computation disclosure

This separation exists so consumers can distinguish evidence, policy, and modeling boundaries instead of receiving a blended opaque outcome.

Depth currently surfaces the following normalized pool types in public payloads:

Depth's support posture is not uniform across all pool types. Some pool types are structurally supported but only partially modeled downstream.

A pool is structurally supported when Depth can decode the pool shape and recover the required state for its supported model path. A pool may be structurally unsupported when:

• token addresses are missing
• ABI/state decoding fails
• the pool type is unsupported
• required state for that pool type is missing
• the pool state is inconsistent with the expected structure

Public structural issue categories include:

Structural support is independent of TVL, swap activity, and policy eligibility.

Coverage answers what was observed, not what Depth recommends.

Key public fields and meanings:

• observation_window_hours — the bounded window of execution evidence available for the pool at snapshot time
• observation_freshness — whether the observed evidence is considered fresh or unknown under current freshness semantics
• coverage_notes — observational notes such as missing or partial observation windows

Important constraints:

• partial coverage is treated as partial, not extrapolated
• coverage does not imply execution eligibility
• coverage does not upgrade unsupported or unmodeled structures into modeled ones
• coverage notes do not contain policy reasons or structural failures

Public coverage note categories include:

• no_recent_observations
• partial_observation_window

Depth computes TVL conservatively.

Preferred path: onchain balances + supported valuation inputs — When both pool assets can be valued directly using supported pricing inputs, Depth computes TVL from onchain pool balances and those valuation inputs.

Fallback path: single-hop anchor-derived TVL — When exactly one token in the pool has a supported direct pricing source, Depth may derive the other token's valuation from that pool's own onchain price state.

Public properties of this fallback:

• it is single-hop only
• it is local to that pool
• it does not recurse across multiple pools
• it is disclosed explicitly in the payload
• it does not upgrade execution eligibility

Hop-derived TVL is useful for observability, but it is treated more conservatively than directly priced TVL.

When TVL is missing — If supported valuation inputs are not available, TVL is omitted and the payload discloses that fact explicitly in computation disclosure.

Execution eligibility is not a general safety label. It is a narrower statement: under the current policy version, did this pool pass Depth's execution-context qualification policy?

At a high level, a pool becomes ineligible when one or more of the following applies:

• structural support is absent
• TVL cannot be established in a policy-acceptable way
• TVL is only hop-derived
• recent execution evidence is insufficient
• observations are stale or unavailable under policy
• the execution model for the pool type is unsupported or excluded

Public execution ineligibility categories:

Depth intentionally does not publish exact numeric thresholds for these gates in beta. A policy pass should still be interpreted together with the surfaced effective depth, volume, and observation metrics.

See the Execution Eligibility Policy for the full policy document.

Depth does not claim that every supported pool type is modeled equally.

This is one of the most important parts of the public methodology.

v2 — For generic v2 pools, Depth computes structural support, coverage, TVL, and execution eligibility when the required inputs are available. Additional execution-structure fields may be limited depending on supported model coverage.

v3 — For generic v3 pools, Depth computes concentrated-liquidity execution structure fields such as fee, tick spacing, current tick, and spot liquidity where supported. However, not every downstream concentrated-liquidity section is modeled. Some CLAMM substructures may remain explicitly not_modeled even when the pool is otherwise observed and execution-eligible.

aerodrome_volatile — Depth surfaces Aerodrome-specific structure, including volatile curve semantics and gauge-related structure when available.

aerodrome_concentrated — Depth surfaces both concentrated-liquidity structure and Aerodrome-specific gauge structure. This is an important example of a pool that can expose meaningful structure while still leaving some concentrated-liquidity sub-sections explicitly unmodeled.

aerodrome_stable — Depth identifies the pool type and computes other core objects, but stable-pair mechanics may have narrower downstream modeling depending on available supported structure.

A pool can be:

• structurally supported
• observed
• execution-eligible

and still have one or more computation sections marked:

• not_modeled
• not_computed
• no_observation_coverage
• execution_ineligible

That is intentional. Depth separates eligibility from downstream section computation, and it expects downstream systems to combine the policy result with the accompanying metrics rather than treat the boolean as a green-light verdict.

Gauge-related structure is surfaced separately from pool identity when available.

At a high level, Depth may disclose:

• whether a gauge was detected
• whether gauge-related sections were computed
• whether incentives are active
• whether gauge staking / provenance / lifecycle sections were available

Gauge presence is not itself the same thing as execution eligibility. It is structural and contextual information that may matter to downstream systems.

Depth exposes stable public reason categories so integrators can build against them without needing internal code knowledge. Unknown future reason codes should be treated as non-fatal unless explicitly documented otherwise.

Public reason codes are versioned by methodology and spec evolution, not by undocumented private heuristics.

Depth's pool list is best-effort in beta. That means:

• payload pool lists are not guaranteed to enumerate every possible pool onchain for a token
• canonical venues are more likely to be present than long-tail pools
• discovery posture should not be interpreted as a claim of full market coverage

Depth's public outputs are derived from onchain state and onchain event data on Base.

Where valuation inputs are required, Depth reads supported onchain oracle feeds and pool-local onchain price state. It does not depend on third-party market-data APIs like CoinGecko to decide what passes policy.

Pool seeding may help discovery in beta but does not replace the onchain observation and computation path that produces the public payload.

Depth computes offchain and publishes public commitments so readers can verify that a payload was actually produced and anchored. At a high level, the commitment surface allows a reader to verify:

• payload identity / integrity
• commitment timestamping context
• chain / oracle provenance
• linkage to the applicable public semantics

The oracle commitment does not claim that an execution decision was correct. It claims that the published payload was produced and committed under the declared semantics.

This document describes public semantics and interpretation. Internal thresholds, operations, and implementation details are out of scope unless they materially affect how the published outputs should be read.