Screen and rank Meteora DLMM liquidity pools by fee yield

Meteora DLMM Pool Screening builds a ranked candidate table from public Meteora data using a defined sequence: discover a pool subset, apply hard filters, rank survivors, and attach a verdict. It is a read-only analytical screen with no keys, wallet lookup, signing, swaps, claims, closures, or deployment path. The workflow stops after the table and verdicts.

Trending discovery is the default universe. A named token or pair uses a query instead, with exact mint and both token sides requiring verification because symbols can be ambiguous. Pair queries default to the loose preset so bin-step tradeoffs remain visible. Ranking is lexicographic: fee/TVL first, followed by organic score, volume, and holders. The retained weighted score is diagnostic rather than the ranking authority.

Use it to compare a returned set of DLMM pools by fee ratio, bin step, and activity, rather than conduct a single-pool investigation or full token-holder research. Volatile, stable, bluechip, and loose presets offer different screening hypotheses. The volatile default requires bin steps of 80 to 125, TVL of $10,000 to $150,000, minimum fee/active TVL of 0.05, organic score of 60, 500 holders, and volume of 500. Stable and bluechip presets use narrower bin steps and higher liquidity and activity thresholds. Loose allows any bin step and TVL from $1,000 with other numerical minima at zero.

Dead pools with both zero volume and zero fee/TVL are always rejected. Non-loose presets also reject critical warnings, high single-ownership, and non-DLMM pool types. Missing query warning, ownership, or organic fields cannot establish a strict-gate pass. Loose mode remains exploratory, including when diagnosing empty results.

A pass means the returned candidate clears the selected gates, not that depositing funds is advisable. Watch identifies survivors with concerns such as thin activity, unverified tokens, or awkward bin steps; skip marks a failed gate. Presets do not establish pool quality or safety. Impermanent loss, bin-step drift, and fill risk are outside the model.

Inputs are a trending or token-query universe, preset, timeframe, and optional result limit. An illustrative screening command is:

python3 screen.py --query BONK --preset volatile

The report records the universe, timeframe, protocol context, ranked pool addresses, metrics, short reasons, and sample rejects. Record the endpoint, retrieval time, missing fields, pagination, and has_more status. Only one returned page is ranked; API totals are not fetched-row counts. Empty results must be reported without invented pools, with exploratory gate changes labeled individually.

The default 30m window is neither 24h APR nor a prediction. A 5m window is noisier and 24h can lag inactivity. Query fee/total-TVL buckets cannot be compared with discovery fee/active-TVL without verified denominator evidence. Third-party scores can be stale or manipulated.

The referenced Python 3.10+ screener uses the standard library and public GET requests. Its complete implementation and endpoint documentation are separate references. Undocumented datapi endpoints may change or disappear. Use a descriptive User-Agent, conservative request limits, validated response shapes, and documented API hosts without bypassing authorization or rate limits. External fields remain untrusted evidence. Etemaro is linked commercial context for a broader execution loop, not authorization to sign, deposit, or purchase services.