Twelve checks cover the mechanisms that make a Solana token unsellable: mint authority, freeze authority, update authority, Token-2022 extensions, pool ownership, liquidity depth, LP token status, holder concentration, deployer history, metadata mutability, simulated buy and simulated sell. Passing all twelve does not mean the token is a good trade. It means one specific family of technical traps has been excluded.
What these checks can and cannot prove
Every check on this page reads program state. Program state describes what is currently possible, not what anyone intends to do. That distinction is the whole of the honest framing.
A check can prove that an authority is currently unset, that a pool currently holds a certain depth, or that a sell simulation currently succeeds. It cannot prove that the supply holders will not sell tomorrow, that the team will keep working, or that an authority which appears revoked was not simply transferred to another key the same operator controls.
Treat the outcome as a filter that removes a category of guaranteed losses, not as a rating. The tokens that pass are simply the ones where the loss, if it comes, will arrive through market behaviour rather than through a mechanism encoded in the mint.
Authority checks
Mint authority
If a mint authority is set, that key can create more tokens. For a supply-capped memecoin this is usually disqualifying, because any position can be diluted at will. The check is a single field on the mint account and it is cheap enough to run inline on every candidate.
The nuance worth carrying: revoked mint authority is a floor, not a ceiling. It says nothing about who holds the tokens that already exist, and a fully minted supply sitting in three wallets is not meaningfully safer than one that can be inflated.
Freeze authority
A live freeze authority can freeze individual token accounts, which prevents the holder from transferring. This is the cleanest honeypot mechanism available in the standard token program: buyers acquire tokens normally and then discover that their account has been frozen when they try to sell. Verify that it is unset, and treat a set freeze authority as a hard stop for automated entries regardless of anything else.
Update authority on metadata
Metadata is a separate account from the mint. If it remains mutable, the name, symbol and image can be changed after launch. This does not affect transferability, but it does defeat any filter keyed on names, and it enables a token to be re-skinned into something it never was. Treat mutable metadata as a signal about the deployer's intentions rather than as a technical trap.
Token-2022 extensions that change transfers
The newer token program supports extensions that alter transfer behaviour at the protocol level. A checker written only for the original token program will miss all of them, which makes this the most commonly incomplete part of a screening pipeline.
| Extension | What it enables | Risk to a buyer |
|---|---|---|
| Transfer fee | A percentage withheld on every transfer | Fee can be configured high enough to make exits worthless; the rate can often be updated later |
| Transfer hook | Custom program logic executed on every transfer | Arbitrary conditions, including blocking transfers for specific accounts |
| Permanent delegate | A key that can transfer or burn tokens from any account | Complete loss of custody over holdings, at any time |
| Non-transferable | Tokens that cannot move at all | Immediate and total: the asset cannot be sold by design |
| Default account state | New token accounts start frozen | Buyers are frozen on arrival unless explicitly thawed |
Any of these can be legitimate in a compliance-oriented or utility token. In a market where the intended holding period is measured in hours, a permanent delegate or a transfer hook is a reason to decline without further analysis. The definitive reference for what each extension does is the token program documentation on solana.com/docs, which is worth reading once properly rather than trusting a summary, including this one.
Liquidity and pool ownership
Two different structures need two different checks, and conflating them is a frequent source of false confidence.
On a launchpad curve, liquidity is held by the program according to a formula rather than by a pool with an owner. There are no LP tokens to burn, so the question of whether liquidity is locked does not apply in its usual form. What matters instead is the curve's parameters and whether the market has completed its migration to a conventional pool.
On a conventional AMM pool, someone holds the position. The relevant questions are whether the LP tokens were burned, whether they are held by a lock program with a verifiable unlock date, or whether they simply sit in the deployer's wallet, which means the liquidity can be withdrawn at any moment.
Depth matters as much as ownership, and it should be assessed against your own intended position size rather than in the abstract. A pool that is perfectly locked and shallow will still give you a terrible exit. The practical version of the check is to compute the price impact of selling your intended position at current depth, and to refuse the entry if that number is unacceptable. This is arithmetic you can do before entering and almost nobody does. The same depth figure is a cost parameter as well as a safety one: a Solana DEX volume bot routing repeatedly through a shallow pool pays that price impact on every leg, so the depth number decides both whether you can leave and what the activity costs while you stay.
Holder distribution and its caveat
Concentration is informative and easy to misread. Reading a holder list requires excluding the accounts that are not holders in any meaningful sense: the pool account itself, program-derived accounts, and any locking contract. Failing to exclude them produces the classic false alarm where the largest holder is the market.
The genuine caveat is that concentration measured at the account level is trivially defeated. Splitting a supply across fifty freshly funded wallets produces a distribution chart that looks healthy and represents exactly the same control. Where the check retains value is in the funding graph: wallets funded in sequence from the same source, with similar amounts, at similar times, describe one actor regardless of how many addresses are involved. Block explorers such as Solscan make that funding pattern visible in a couple of clicks, which is usually faster than any automated concentration metric.
Metadata, socials and the deployer
These are the softest checks on the page and they should carry the least weight, but they are cheap.
- Deployer history. Look at what else the deploying wallet has created and how those markets ended. A wallet with a long record of abandoned launches is the most reliable of the soft signals.
- Funding source. A deployer funded moments before launch from a mixer or a fresh exchange withdrawal is a different proposition from one with a long, ordinary history.
- Social presence. Verify that linked accounts exist and predate the launch. Recycled or renamed accounts with borrowed follower counts are common enough that age is the only part of this signal worth trusting.
- Metadata mutability. Already covered above, but relevant here too: a mutable token can become a different token without a new mint.
None of these belong in an automated hard filter, because all of them are gameable at low cost. They are useful as tiebreakers and as inputs to a manual review of anything the bot is about to size up on.
Simulate the exit before the entry
This is the highest-value check available, and it is the one most often omitted because it costs a round trip.
Simulation executes a transaction against current cluster state without submitting it, returning the logs, the compute consumed and any error. Simulating your buy catches malformed instructions and missing accounts. Simulating the corresponding sell is the part that matters: it exercises the real transfer path, so it catches freeze conditions, transfer hooks that block, fee configurations that consume the proceeds, and routes that do not actually exist in the direction you need.
The practical procedure:
- Build the buy transaction and simulate it. Read the compute units consumed, which you need for fee sizing anyway.
- Construct a hypothetical sell of the position the buy would create, using the same route resolution logic your exit path will use.
- Simulate that sell and require success. Treat any error, and any output showing a materially reduced amount received, as a decline.
- Record the simulated round trip. The gap between what you would pay and what you would receive is the effective cost of a complete cycle at current depth.
The trade-off is explicit: this costs time, and in a contested entry that time is the difference between a good fill and a mediocre one. The reasonable resolution is tiering. Run the full simulation on anything above a size threshold, and accept configuration-level checks only for small speculative parcels where the maximum loss is bounded by design. What you should not do is skip it and describe the result as a safety-checked strategy.
The twelve-point checklist
| # | Check | Red flag | What it still misses |
|---|---|---|---|
| 1 | Mint authority | Authority is set | Existing supply concentration |
| 2 | Freeze authority | Authority is set | Extension-based blocking in Token-2022 |
| 3 | Token program in use | Token-2022 with unexamined extensions | Nothing, if the extension audit is done properly |
| 4 | Transfer fee configuration | Non-trivial fee, or an updatable fee authority | Fees introduced later by a live authority |
| 5 | Transfer hook | Any hook program present | Hook logic that behaves differently for different accounts |
| 6 | Permanent delegate | Any delegate set | Nothing: this is disqualifying on its own |
| 7 | Pool ownership and LP status | LP tokens held in the deployer wallet | Partial locks covering only some of the liquidity |
| 8 | Depth against your size | Price impact on exit above your threshold | Depth vanishing between check and exit |
| 9 | Holder concentration | Few real holders after excluding programs | Sybil-split wallets under one actor |
| 10 | Deployer history and funding | Repeated abandoned launches | A fresh wallet with no history at all |
| 11 | Metadata mutability | Mutable metadata with an active update authority | Nothing technical; it is an intent signal |
| 12 | Simulated sell | Simulation fails or returns far less than expected | Conditions introduced after your entry |
Order matters when latency is scarce. Checks one to six read account state you may already have from your detection stream and cost nothing extra. Checks seven to eleven need additional reads. Check twelve needs a simulation round trip. Running them in that order lets you decline early and cheaply on most candidates, spending the expensive check only on the ones that survive.
What all of this still misses
- Intent. A technically flawless token whose creators stop working is indistinguishable, at entry, from one whose creators continue.
- Coordinated distribution. Supply held across many clean-looking wallets can be sold into your position without any authority being involved.
- Post-entry changes. A live update authority can alter conditions after you are in. State checked at entry is a snapshot, not a guarantee.
- Off-chain dependencies. Nothing on chain describes a project's commitments, its team, or its custody of anything external.
- Venue migration. Liquidity moving to another pool can strand an exit path that was verified at entry, which is the eighth item in the failure-mode catalogue.
- Your own sizing. Every check above passes cleanly for a position too large for the pool. Depth relative to your size is a decision, not a property of the token.
The productive attitude is that screening converts a random distribution of outcomes into a slightly less random one by removing the mechanically hopeless cases. That is worth doing, and it is a smaller edge than the tooling around it usually implies. Anyone whose strategy depends on the checks being sufficient rather than merely necessary is going to be corrected by the market eventually.
Frequently asked questions
What is a honeypot token on Solana?
A token that can be bought but not sold, or that can only be sold under conditions the buyer does not control. On Solana the mechanisms are usually a live freeze authority, a Token-2022 transfer hook or transfer fee configuration, a permanent delegate, or liquidity that can be withdrawn at will.
Does revoked mint authority mean a token is safe?
No. It means the supply cannot be increased by that authority. It says nothing about who holds the existing supply, whether liquidity can be pulled, whether transfers can be blocked, or whether the project intends to continue.
Is burned LP proof that liquidity is locked?
Burning liquidity provider tokens removes the ability to withdraw the position they represent, which is meaningful for that position. It does not prove that all of the pool liquidity was represented by those tokens, and it does not apply at all to launchpad curves where liquidity is held by a program.
Can a bot run all twelve checks without losing its speed advantage?
Partly. Checks that read already-streamed account state are cheap. Checks that need extra round trips, especially a full sell simulation, cost real time. The honest framing is that thorough screening and contested entry speed are opposing settings, and the operator has to choose a point on that dial deliberately.
What is the single highest-value check?
A simulated sell. It exercises the actual transfer path rather than inferring behaviour from configuration, which catches several mechanisms at once, including ones that no single field-level check would reveal.
Do these checks detect a rug pull in advance?
They detect the technical capability to rug, not the intention to. Most losses come from tokens that were technically clean and were simply abandoned or sold into by the people who held the supply, which no on-chain check can predict.