Policy Document
Execution Eligibility Policy
The public definition of what makes a pool execution-eligible under Depth policy, and what causes ineligibility.
Policy purpose
Execution eligibility answers a narrow question:
Under current Depth policy, is this pool eligible for execution-sensitive treatment?
This is not a guarantee of execution quality. It is not a trading recommendation. It is not a safety label. It is a public, versioned policy outcome derived from observed evidence plus supported model constraints.
What eligibility is not
Execution eligibility is not:
- a price signal
- a profitability signal
- a guarantee of future liquidity persistence
- a complete statement of pool quality
- a replacement for downstream routing logic
A consumer still needs to apply its own decision rules.
Inputs considered by the policy
At a high level, Depth's execution eligibility policy considers:
- structural support
- TVL posture
- recent execution evidence and observation coverage
- supported execution model constraints
- policy exclusions and unsupported model paths
The policy result is surfaced per pool under execution_policy.
Relationship to the four-object model
Execution eligibility is only one of four objects. It is distinct from structural support, observation coverage, and computation disclosure.
This means a pool can be:
- structurally supported, observed, and execution-ineligible
- structurally supported, observed, execution-eligible, and still have some downstream computation sections marked
not_modeled
That is intentional.
High-level eligibility posture
A pool is only execution-eligible when Depth is willing to treat the observed liquidity surface as suitable for execution-sensitive interpretation under the current policy. At a high level, that requires:
- the pool to be structurally legible
- policy-acceptable valuation posture
- sufficient recent execution evidence under current policy
- a supported execution model for that pool type
If one or more of those conditions fail, the pool remains ineligible.
Public ineligibility categories
| Category | Meaning |
|---|---|
| low_tvl | TVL posture does not satisfy the policy for execution-sensitive treatment |
| tvl_unknown | Policy-acceptable TVL could not be established for the pool |
| tvl_hop_derived | TVL established via single-hop anchor-derived fallback; does not upgrade eligibility under current policy |
| insufficient_recent_swaps | Insufficient recent execution-derived evidence to treat the pool as execution-eligible |
| stale_observations | Observed evidence is outside acceptable freshness posture for execution-sensitive treatment |
| unsupported_execution_model | Pool structure or mechanics not supported for execution-sensitive treatment under current policy path |
| policy_excluded_pool_type | Pool type is recognized but excluded from execution-sensitive treatment under current policy |
Exact numeric thresholds for TVL, swap count, and freshness cutoffs are not published. The public contract is the ineligibility category, not the specific gate value.
Structural support vs eligibility
Structural support and execution eligibility are separate.
A pool may be structurally supported but still execution-ineligible because:
- valuation posture is insufficient
- observation evidence is insufficient
- the execution model is unsupported
- the pool is excluded under policy
Structural support answers whether Depth can reason about the pool at all. Execution eligibility answers whether Depth is willing to qualify it for execution-sensitive interpretation.
Coverage vs eligibility
Coverage and eligibility are also separate. A pool can have observed execution evidence and fresh observation metadata and still be execution-ineligible.
Coverage tells the reader what was observed.
Eligibility tells the reader whether Depth is willing to treat that pool as execution-eligible under policy. Coverage alone does not imply eligibility.
TVL posture and eligibility
TVL matters to eligibility, but not all TVL postures are equivalent.
Directly supported valuation — When TVL is established through supported valuation inputs, the policy may use it as part of execution eligibility.
Hop-derived valuation — When TVL is established through the single-hop anchor-derived fallback, the TVL may still be shown for observability. However, under execution_eligibility_v1.2, hop-derived TVL does not upgrade eligibility. It is explicitly disclosed via tvl_hop_derived.
Pool-type interaction with policy
The execution policy does not treat all pool types identically.
- some pool types are both recognized and execution-model supported
- some are recognized but only partially modeled downstream
- some may remain excluded or unsupported for execution-sensitive treatment even when structurally legible
Consumers should not infer from structural support alone that a pool's execution model is fully supported.
Eligibility vs downstream computation
Execution eligibility does not mean every downstream section is modeled. A pool may be execution-eligible while one or more computation sections are still marked not_modeled, not_computed, or not_applicable. This is especially important for concentrated-liquidity and other partially modeled structures.
Consumers should read execution_policy and computation as complementary, not interchangeable.