Why execution systems need explicit liquidity qualification

Onchain liquidity is visible everywhere, but execution context is not.

Depth is not a price oracle, a safety score, or a recommendation engine. It is a qualification layer that makes explicit what was observed, what is eligible under policy, and what remains unmodeled or refused.

Most systems still operate with shallow proxies:

• TVL
• recent volume
• venue reputation
• price-adjacent heuristics
• internal routing logic that is hard to inspect and harder to audit

Those proxies are useful, but they do not answer the operational question that matters:

What liquidity should an execution system actually trust under explicit assumptions?

That gap creates quiet failure modes:

• routing into pools whose nominal liquidity overstates usable depth
• automating against partially observed liquidity surfaces
• treating concentrated liquidity as if it behaved like generic liquidity
• smoothing unknowns into implied confidence

The problem is not a lack of data. The problem is that too many systems still move value onchain with hidden liquidity assumptions.

Depth exists to make those assumptions explicit.

It does this by qualifying liquidity at the pool level and publishing the result as signed execution context. For each token snapshot, Depth surfaces four distinct things:

• whether a pool is structurally supported
• what execution-derived evidence was actually observed
• whether the pool is eligible under current policy
• what was modeled, left unmodeled, or refused

Depth does not replace the systems that make execution decisions. It gives them a cleaner qualification layer to build on.

Base is the right first proving ground for Depth because it already combines:

• meaningful liquidity and live execution activity
• multiple venue and liquidity-mechanic types, including concentrated liquidity and Aerodrome-specific structure
• builders shipping automation, routing, and agent workflows
• a growing consumer and application layer where better execution infrastructure can affect real usage
• an ecosystem that is explicitly leaning into agent-driven and autonomous onchain applications

This is not infrastructure for a hypothetical future market. Base already has the mix of liquidity, venue diversity, automation, agent-facing application energy, and distribution where hidden assumptions change real execution outcomes.

Depth can make more Base-native execution automation viable by making liquidity qualification explicit.

That can support more onchain activity through several concrete paths:

• routers can narrow candidate pools with an explicit policy layer before routing flow
• treasury systems can automate swaps and rebalances against explicit qualification plus their own sizing and venue rules instead of ad hoc assumptions
• agents can degrade gracefully when evidence is partial instead of silently overreaching
• teams can integrate a shared qualification layer instead of rebuilding brittle private heuristics

That matters because systems submit more transactions when they can operate with fewer hidden assumptions. Better qualification can make automation more viable, make execution systems more willing to stay onchain, and let more teams build transaction-driving systems on Base without first owning the full policy burden themselves. Depth becomes enabling infrastructure for systems that actually submit the transaction.

A concrete integration path looks like this:

1. A system fetches the latest public token snapshot from Depth (/v1/public/tokens/{token}/latest) for the token it wants to trade, rebalance, or route.
2. It treats pools that passed the current policy and have bounded observation coverage as candidates, and treats policy failure as a no-go.
3. It inspects pool-level evidence such as TVL posture, effective depth, observable liquidity share, execution structure, and computation disclosure.
4. It applies its own strategy-specific heuristics and sizing rules across the remaining candidates.
5. It chooses a venue or degrades gracefully when evidence is partial.
6. It submits the resulting swap, rebalance, or routing transaction on Base.

That is the operating shape: Depth qualifies liquidity, and the downstream system uses that qualification inside a real execution loop. A policy pass narrows the field; it does not by itself authorize execution size or venue selection.

Simple execution flow

Pseudocode example

A downstream strategy may prefer pools with richer computed liquidity-state fields, but that is an integrator choice rather than a universal Depth gate.

This is a direct transaction path: a system can call Depth, qualify candidate venues, apply its own sizing and routing rules, and then submit an onchain transaction on Base.

Execution happens at the pool level, not at the level of token branding or token-level aggregate metrics.

Token-level summaries are still useful, but they can hide the facts that matter operationally:

• which venue dominates usable liquidity
• which pools are only partially observed
• which structures are supported for execution-sensitive use
• which sections of the model are intentionally unavailable

Depth starts with pools, then aggregates upward. That is the right direction of reasoning for execution systems.

Depth is built around a strict separation between:

• what was observed
• what is structurally legible
• what is eligible under policy
• what was modeled or refused

This separation matters because consumers need to distinguish:

• a pool with missing evidence
• a pool with unsupported structure
• a pool that is observed but not eligible
• a pool that is eligible but only partially modeled downstream

Depth treats refusal as part of the product.

That means the system is designed to say:

• this was not modeled
• this was not computed
• this is unsupported
• this is ineligible under policy

instead of silently inflating certainty.

A capable team can always build heuristics. What most teams don't want to own is the ongoing policy burden: defining modeling boundaries, handling edge cases, refusing weak evidence, versioning assumptions, and making all of it inspectable enough to trust in production. Depth exists to absorb that burden into shared infrastructure instead of forcing every execution system to maintain its own drifting private logic.

At a high level, Depth's outputs let consumers reason about four distinct questions.

Structural support — Can the pool be reasoned about under the current structural model? This is about legibility, not attractiveness.

Observation coverage — What execution-derived evidence was actually observed, and over what bounded window? This is evidence, not recommendation.

Policy eligibility — Under current public policy, did this pool pass Depth's execution-context qualification policy? This is a policy output, not a promise of execution quality. A false value can be a no-go signal; a true value is not a sufficient execution decision on its own.

What is modeled vs refused — What was computed, what was left unmodeled, and what did Depth refuse to imply? This is where Depth makes its modeling boundaries visible.

Concentrated-liquidity pools are a good example of why this distinction matters.

Depth can still surface meaningful concentrated-liquidity structure, including fields like fee, tick spacing, current tick, and active spot liquidity. But not every downstream concentrated-liquidity section is modeled equally.

That means a pool can still be:

• structurally supported
• observed
• eligible under policy

while some deeper liquidity-state sections remain explicitly not_modeled.

This is intentional. Depth is designed to expose a partial but honest view rather than imply a fuller model than it actually supports.

Depth values TVL conservatively, but TVL alone is not the product.

The relevant distinction is not just whether TVL exists, but how it was established and whether that posture is acceptable for execution-sensitive use.

A pool may have observable TVL while still remaining ineligible under policy.

This matters especially where fallback valuation paths are involved. Depth is designed to preserve observability without silently upgrading that observability into execution confidence.

Depth performs computation offchain, but it does not ask consumers to trust the output blindly.

Public payloads are anchored through oracle commitments so consumers can verify:

• what was published
• when it was committed
• which chain and commitment path apply
• which policy and spec versions govern interpretation

This gives integrators a stable artifact they can inspect and verify instead of relying on an opaque API response with shifting semantics.

The commitment surface is narrow by design. It does not attest that a routing decision was correct. It attests that the published artifact was produced and anchored under explicit semantics.

Depth is intentionally narrow.

It does not aim to:

• predict prices
• recommend trades
• rank tokens by safety
• guarantee execution outcomes
• replace execution engines or analytics platforms

Its role is upstream of those decisions. It qualifies liquidity for execution and makes uncertainty explicit.

That narrowness is a strength. It keeps the trust boundary legible.

Depth is early, but the core system is live.

Today the project includes:

• live oracle infrastructure
• signed payload commitments
• explorer and API surfaces
• explicit policy and spec versioning
• real Base pool and token coverage

The next step is integration into real Base execution workflows.

Execution onchain depends on assumptions about liquidity.

Depth exists to make those assumptions explicit in a form that execution systems can actually use.

Depth is not another analytics surface or another opaque scoring layer. It is Base-native infrastructure that enables systems to move value onchain with explicit liquidity context.