Authority and Liquidity Filters, and What They Prove

A mint authority filter proves that nobody can currently mint more supply. A freeze check proves that nobody can currently immobilise a token account. A liquidity threshold proves that a pool holds a certain reserve at the moment you read it. Each of these is exactly one fact about one field, and the gap between that and the sentence "this token is safe" is where most screening disappointment lives.

The fields and what each proves

The clearest way to hold this material is a table that separates the claim from its scope. Every row is a check worth running. No row is a substitute for another row, and the right-hand column is the part usually left out of tool descriptions.

Read down the last column and the shape of the problem becomes clear. Every check bounds one risk and hands the next risk to the check below it. A rule set that runs only the first row and reports a verdict is not wrong about the first row; it is silent about the other six.

Mint authority

The mint account carries an authority field that names the account permitted to create new supply. When that field is empty, no additional supply can be minted, and the total supply visible on chain is the total supply that will ever exist unless the token program in use provides another path. The check is a single read and it is cheap enough to run first.

What makes it valuable is that the risk it removes is otherwise unbounded. A live mint authority means the supply denominator can change after you buy, which makes any reasoning about concentration or float provisional. What makes it over-read is that it is often the only check a tool advertises, and its passing gets translated into a general assurance it does not support.

There is also a timing subtlety worth building into the rule. Authorities can be revoked at any point, including after you have read them, and some launches revoke as a deliberate later step. A check performed at detection time is a statement about that instant. If your pipeline caches the result and reuses it, the cache is asserting something about the present that it learned in the past.

Freeze authority

The freeze authority is the field that most directly maps to the fear behind the word honeypot. An account holding this authority can freeze individual token accounts, and a frozen account cannot transfer. In a trading context that means the holder can be prevented from selling while others are not.

For an anonymous launch on an open pool, a live freeze authority is a defensible disqualification, and most automated sets treat it that way. The false positive is real but narrow: permissioned or regulated token designs use freeze deliberately, and those designs are generally not the ones an entry bot is looking at. Naming that false positive is still worth doing, because it clarifies what the rule is for.

The important structural point is that freeze is not the only route to the same outcome. Removing liquidity achieves it commercially, and a transfer hook can achieve it programmatically. A pipeline that checks freeze and calls the honeypot question answered has confused one mechanism with the category.

Token extensions and transfer behaviour

Solana has more than one token program, and the newer one supports extensions that change what a transfer does. A transfer fee can take a percentage on every movement. A transfer hook can require a separate program to approve each transfer. Confidential transfer changes what balances are readable. The mechanics and the full extension list are documented in the Solana program library reference, which is the right place to check before assuming standard behaviour.

The screening consequence is direct. A pipeline written against standard token semantics will compute the wrong output amount for a token with a transfer fee, and will not anticipate a hook program that rejects the sell transaction it later sends. The output amount error is arithmetic and can be corrected. The hook is a discretionary gate held by somebody else, which is a fundamentally different kind of exposure.

The defensible default for automated entry is narrow: identify which token program owns the mint, enumerate the extensions present, and reject anything your code has not been explicitly written to handle. This rejects some entirely legitimate tokens, which is the price of not being surprised by transfer semantics at the moment you try to exit.

Where the honeypot check actually sits

A honeypot check is the attempt to establish that a position can be closed, not only opened. It is worth stating plainly that this is not one check on Solana. It is the conjunction of several capability checks, and each of them removes a different route to the same outcome.

• Can transfers be immobilised? Freeze authority, read from the mint account. Empty is the answer you want.
• Can transfers be gated? Transfer hook extension, read from the mint account's extension data. Absent, or a hook program you have deliberately accepted.
• Can transfers be taxed? Transfer fee extension. Present is not disqualifying, but it must be included in every amount calculation or your exit maths is wrong.
• Can the market be withdrawn? Pool token ownership, plus whether any lock claim can be verified. This is the commercial version of the same trap.
• Can identity change? Metadata update authority. Less severe, and it determines whether the thing you screened stays the thing you hold.

Presented as a list, the honeypot question becomes tractable. Presented as a single boolean produced by a third-party endpoint, it becomes an assertion you cannot audit. The list also makes clear why simulation-based checks, where a sell is simulated before buying, are complementary rather than redundant: a simulation tests the current state, while the capability checks test who is able to change it.

What is in the pool

A liquidity threshold is a sizing constraint wearing a safety costume. The number that matters is not the headline value of the pool but the reserve on the side you are paying with, relative to the position you intend to take.

Two pools with the same reported value can behave completely differently. A pool holding a widely traded quote asset gives you a reserve you can actually exit into. A pool paired against a second illiquid token gives you a reserve that is itself hard to sell, so your exit becomes two problems instead of one. The composition check therefore comes before the magnitude check.

Worked through with numbers, the second row is the whole of the liquidity rule. If you intend to buy with one SOL and will accept roughly two percent impact on entry, the constant-product relationship puts your input at about one percent of the quote reserve, so the reserve needs to be around one hundred SOL. Change the tolerance to four percent and the requirement halves. Change the size to four SOL and it quadruples. There is no universal floor because there is no universal size.

Lock claims and how to check one

A liquidity lock claim is the assertion that the pool position tokens cannot be redeemed for some period. When it is true and verifiable it removes a serious risk. When it is asserted in a social post it removes nothing at all, and the difference between the two is a specific account read.

The check has three outcomes rather than two. The pool tokens may sit in an account owned by a lock program whose terms your code can read and interpret, in which case the claim is verified. They may sit in an ordinary wallet, in which case the claim is false regardless of what was posted. Or they may sit in a program your code cannot interpret, in which case the claim is unverified.

Unverified must be treated as unlocked. This is the fail-closed principle applied to the most consequential single field in the set, and the asymmetry justifies it: treating a real lock as absent costs you an entry, while treating an absent lock as real costs you the position. The relevant accounts are readable through the standard RPC methods described in the Solana developer documentation, so this is a question of writing the check rather than of access.

Ordering the checks

These checks divide neatly by cost, and the ordering saves a large share of the request volume in a busy pipeline.

1. Identify the token program. One read of the mint account owner. Reject unsupported semantics before doing anything else.
2. Read the mint account fields. Supply, decimals, mint authority, freeze authority, extension data. One round trip covering four rules.
3. Read the pool account. Quote asset identity first, then reserves. Reject on composition before evaluating magnitude.
4. Compute the size the reserve supports. If it is below what you would bother trading, reject here and skip everything downstream.
5. Resolve pool token ownership. Identify the holder and classify the lock as verified, absent or unverified.
6. Read metadata last. It is the least decisive of the group and often the slowest to become available.

Steps one and two carry most of the rejections for the cost of two reads, which is why they sit at the top. Step four is the one operators add later, usually after noticing how much work their pipeline was doing on pools that could never have supported a position worth taking.

What passing everything still allows

This is the part worth being blunt about. A candidate can pass every check on this page and still be a poor entry, because the checks bound capabilities rather than intentions.

Supply can be entirely held by wallets funded from one source minutes earlier, spread widely enough to look distributed. The pool can be deep at the instant you read it and thin by the time you exit. The lock can be real and short. Metadata can be immutable and describe something that never existed. Every one of those is consistent with a full pass on authorities, extensions and liquidity, because none of them is a capability the deployer retains; they are simply facts about who is on the other side of your trade.

There is one further category that the fields never address, and that is custody on your own side. Any automation involves keys that can sign, and the practical questions are which keys exist, what they are permitted to sign, and what happens to them if the tool is abandoned. That question applies to every category of trading automation, which is why volume bot safety discussions spend more time on key handling than on trading logic. It is the same discipline whether the program is deciding entries or executing a schedule.

The distinction is worth holding on to when comparing tools. A SOL volume bot operating on a token you already hold faces none of the screening questions on this page, because the candidate was chosen by a human in advance. What it does face is the custody question and the reporting question, and those are the ones to ask of it. Screening tools and routing tools fail in different places, and the checks that matter follow the failure, not the category name.

The remaining rule family is distribution, and it is the one where the on-chain evidence is weakest relative to how confident it looks. That is the subject of the next page.

Questions this page keeps getting