Building a filter set
How to assemble rules in an order that fails cheap, how to write a threshold you can defend, and how to test a set against history without fooling yourself.
FLT-01 Open the pageFilters: What the Program Rejects
A filter set is a rejection machine. On any active day it will turn down almost everything it sees, and the quality of the set is decided by which rare thing it lets through and which failure it accepts in exchange. Written that way, screening becomes an engineering problem with visible trade-offs rather than a search for a secret list of rules.
These three pages cover assembling a set, reading the authority and liquidity fields honestly, and reading distribution without being fooled by the easiest thing on Solana to stage.
- 01 Order by cost Cheap local checks run before anything that needs a network round trip, so the common rejection never spends a request.
- 02 One claim per rule A rule that checks a single field and states a single conclusion can be debugged. A composite score cannot be argued with.
- 03 Thresholds with reasons A liquidity floor exists to bound slippage on a size you chose. If the size changes, the floor changes with it or it means nothing.
- 04 Named false positives Each rule is published with the legitimate candidate it would reject. A rule with no known false positive has not been examined.
- 05 Fail closed When a lookup times out or returns unexpected data, the candidate is rejected rather than admitted. Missing evidence is not evidence of safety.
- 06 Audit the rejections The rejection log is the only place a set can be improved. Reviewing admissions tells you about outcomes; reviewing rejections tells you about rules.
3 pages in this section
Rule design as an engineering problem: authority and liquidity gates, distribution reads, thresholds that can be justified, and the arithmetic of a filter set that rejects far more than it admits.
Authority and liquidity filters
Mint and freeze authority, transfer hooks, pool ownership and lock claims: what each field proves, what it does not, and where the honeypot check actually sits.
FLT-02 Open the pageDistribution and holder filters
Reading supply concentration from token accounts, why a clean holder chart is the easiest thing on Solana to fake, and which distribution rules survive that.
FLT-03 Open the pageWhat a filter set cannot do
It cannot detect intent. Every on-chain field it reads is a fact about an account, and every fact about an account can be arranged in advance by someone who knows the fields are being read. A filter set raises the cost of staging a launch that passes, and that is a real effect, but it is not the same as knowing what the deployer plans to do next. Any rule described as a guarantee has been oversold.
- Reads well
- Authority fields, pool reserves, supply concentration across token accounts, metadata mutability, program ownership
- Reads badly
- Intent, coordination between wallets, off-chain agreements, whether a lock actually binds the party that matters
- Cheap to fake
- A holder list spread across dozens of funded wallets, early volume, socials, and a token name that resembles something credible
- Expensive to fake
- Real locked pool tokens with a verifiable lock account, and a deployer history that predates the launch by a long way
Detection Where the event comes from How a new token becomes visible to a program at all: which event a bot is actually subscribed to, how much of the token state exists at that moment, and how the source of the signal limits every decision made after it. Outcomes What the entry was worth The part of the problem that starts once the fill exists: exit rules written before entry, the depth on the other side of the position, and the reason a fast entry into a bad candidate is still a bad entry. Terms The vocabulary, defined once Every term this site leans on, defined in the sense it is used here rather than the sense a marketing page uses, so a rule written on one page reads the same way on another.