What This Desk Does, and What It Refuses To Do

First Block covers one narrow thing: the decisions an automated entry program makes between hearing about a Solana token and agreeing to buy it, plus the decisions that follow once a position exists. Detection sources, filter design, false positives, and what happens after the fill. Everything else is deliberately somebody else's subject.

What the desk covers

The scope is the decision layer. Which event a program subscribed to and what that event contained. How screening rules are ordered, written and reviewed. What the authority, liquidity and distribution fields actually establish, and what they leave open. How a position is sized against pool depth, how an exit rule is written before entry, and why an early fill is so often a poor one.

These questions have a property that makes them worth writing about carefully: they are all answerable from public data. Every field a rule reads is readable by anyone with an ordinary endpoint, and every claim on this site can in principle be checked against the chain by a reader who does not trust the desk.

What the desk does not cover

Transaction delivery is out of scope. Priority fees, compute budgets, blockhash lifetime, retry behaviour and landing rate are a real and well documented discipline, and they are not this one. Pages here assume the send path works and ask what the program was told to buy. Where delivery is mentioned, it is mentioned in one sentence and handed on.

Also out of scope: which tools to buy, which providers are fastest, and which launches are worth entering. The first two are commercial claims that change weekly and cannot be verified from outside. The third is not a filter problem, it is a market view, and this desk has no business publishing one.

How a page gets built

Each page starts from a mechanism that can be read in public documentation or observed in account state, and reaches a recommendation only once that mechanism is on the page. If a rule cannot be traced back to a specific field or account, it does not get published as a rule. Where the desk could not establish something, the page says so rather than filling the gap with a plausible sentence.

Every threshold that appears is either worked arithmetic with visible inputs or a protocol constant. No page tells a reader to use a particular liquidity floor or a particular concentration limit, because the correct value depends on a position size that only the reader knows. Numbers here exist to show the shape of a relationship, not to be copied.

The rules on numbers

Three categories are allowed. Protocol facts, such as how fees are charged or how account state is structured. Arithmetic clearly labelled as illustrative, where the inputs are invented for readability and stated as such. And figures attributed to a named public source that a reader can check.

Everything else is excluded, and the exclusion is absolute. This site publishes no win rates, no returns, no profit or loss figures, no backtest summaries, no measured latency, no measured landing rates, no counts of users, no reviews and no ratings. A filter set that looked good over one window is not evidence about the next one, and presenting it as evidence is the most common way screening advice becomes confidently wrong.

What will never appear here

• Invented people. No fabricated author biographies, no photographs of analysts who do not exist, no credentials. Pages carry a desk byline because the desk is what wrote them.
• Fabricated evidence. No testimonials, no case studies, no screenshots of runs, no aggregate ratings, no wallet balances presented as results.
• Backdated pages. Publication dates are the real build date and modification dates are real. A page that is updated says so.
• Runnable automation. Rules are described as rules and thresholds, in prose. This site does not publish code that automates entry, and it does not publish anything designed to help stage a launch that passes screening.
• Guarantees. No page describes any check as making a token safe. Every field a filter reads can be arranged in advance by somebody who knows it is being read.

Who this is for

Readers who are running entry automation, or seriously considering it, and who want the decision layer described without a sales pitch attached. The tone assumes a reader who would rather hear that most entries lose than hear a number they cannot check.

It is not written for readers looking for a configuration to copy. The most consistent message across the pages here is that a threshold copied from somewhere else encodes somebody else's size, tolerance and venue, and carries no information beyond that.

Corrections

If something on this site is wrong, the desk wants to know, and the amendment happens in the open rather than quietly. Corrections that change the substance of a page are noted on the page itself. The route is on the corrections page, and a message that names the page, quotes the sentence and says what is wrong will always get further than one that does not.

The same applies to a mechanism that has changed. Protocol behaviour moves, token programs gain features, and a page written accurately at one point can drift out of date without anybody making a mistake. Those reports are as useful as reports of errors.