How to avoid rug pulls on Solana, with a 60 second check

Four mechanisms, one word

People use rug pull for any launch that went to zero, which makes the term useless for deciding what to check. Underneath there are 4 distinct mechanisms, they fail in different ways, and only some of them leave a signature you can read before you buy.

Notice the pattern. Three of those 4 are contract level, which means software can prove them in the same slot a token appears. The fourth is a person deciding to sell, and no amount of screening turns that into a certainty.

So the practical goal isn't avoiding every loss. It's making sure the losses you take are the fourth kind, because the first 3 are avoidable and paying for them is a choice.

The liquidity pull

When a token launches into an AMM, somebody deposits SOL and tokens into a pool and receives LP tokens representing that deposit. Whoever holds those LP tokens can take the pool back out. That's the whole mechanism, and it's why question 1 about any pool is where the LP tokens ended up.

Two details catch people who were sure they had checked. A lock is only as good as its date, and plenty of launches lock liquidity for 24 hours and then describe it as locked without qualification. A partial burn also reads as burned in some tools, so 5% of the LP burned and 95% held is technically a burn and practically a rug waiting for a quiet moment.

Supply inflation

Every SPL token has a mint authority field. If it holds an address rather than null, that address can create more tokens whenever it likes, and the supply you did your maths on becomes a number that only moves in one direction.

Trivially checkable, and it still catches people, because the check has to happen before the buy rather than after price does something strange. A creator who mints 10 times the circulating supply and sells it does not need liquidity access or a transfer rule. Your bids do all the work.

Freeze authority sits in the same account and does something different but equally final. An address in that field can freeze any token account holding this mint, which means your balance stops being transferable at a moment of somebody else's choosing. Both fields should read null on anything you buy, and both are 1 lookup away.

One wrinkle is worth knowing. On Pump.fun and most curve launchpads, the program revokes both authorities at creation on every token, so seeing them null there tells you the launchpad works rather than anything about this particular launch. On a token that launched straight into an AMM, the same 2 fields are genuinely informative.

Being blocked from selling

A honeypot is a token you can buy and cannot sell. Charts look healthy for hours, because every buy goes through and no sell ever does. Four different things produce that.

• A live freeze authority, used selectively on the accounts that try to leave rather than on everyone at once.
• A Token-2022 transfer hook, which is a program that runs on every transfer and can reject the ones it does not like.
• A transfer fee set high enough that selling is technically possible and economically pointless.
• A permanent delegate, a Token-2022 extension letting a named address move anyone's balance without asking.

Reading flags is not the reliable defence. Simulating the sell is. Route a dry sell through the venue before committing the buy, and if the simulation reverts, no SOL was ever at risk. That single check catches every variation above, including the ones nobody has invented yet, because it tests the outcome rather than the cause.

Token-2022 deserves its own moment of attention. It's a legitimate standard with genuinely useful extensions, and it also gives a creator tools that the original token program never had. When you see a Token-2022 mint, read the extensions rather than assuming either the best or the worst.

The slow rug nobody calls a rug

This is the one that takes the most money and generates the least outrage, because nothing illegal or even unusual happens. The creator holds a large share of supply from the first block and sells it into every buy for the next several hours.

No moment exists to point at. Liquidity stays, the contract behaves, sells work perfectly. Price just bleeds, and everyone concludes the launch died of natural causes.

Distribution warns you in advance, and 3 numbers are worth reading:

Row 3 is the one most people never check, and it hides the real story. Twenty wallets holding 2% each looks like healthy distribution until you trace where they got their SOL and find a single funding wallet 1 hop back. That's not 20 holders. It's 1 seller wearing 20 hats, and it reads as decentralised on every tool that only counts addresses.

Your strongest single predictor sits somewhere else entirely: what the deployer did before. A wallet that abandoned 4 launches last week will behave the same way on the fifth, and that history is public, permanent and takes 1 lookup. If you only have time for one check, make it that one.

The 60 second manual check

If you're buying by hand rather than running a bot, this is the order we'd work in. It fits into about a minute on any Solana explorer and it removes most of the avoidable losses.

1. 1Open the mint accountCheck mint authority and freeze authority. Both should read null unless the token launched on a curve launchpad, where the program handles it for every token anyway.
2. 2Look at the token programIf it's Token-2022 rather than the original SPL token program, read the extensions. A transfer fee, a transfer hook or a permanent delegate each change what you are buying.
3. 3Find the LP tokensBurned, locked or held by the deployer. If locked, open the lock and read the unlock date and the amount, because both are frequently less than the announcement implied.
4. 4Read the top holdersCreator share first, then the top 10 combined. Then click 2 or 3 of the largest wallets and see whether they were funded from the same place within a few minutes of each other.
5. 5Look up the deployerOpen the wallet that signed the mint and scroll its history. Earlier mints, and how each one ended, tell you more than everything above combined.
6. 6Try a tiny sellIf you buy, sell a small part immediately. A sell that goes through proves the exit exists, and it costs you a fraction of a percent to know.

Six steps, 60 seconds, and on a fresh launch nobody has 60 seconds. That gap is the whole argument for automating the check rather than the buy. Our engine runs the same logic as up to 12 checks in the slot the mint appears, and writes down which one refused a launch so the log is a record of decisions rather than a list of fills.

What no check can catch

Being honest about the limits matters more than listing the wins, because a false sense of coverage is how people size too large.

• A creator who genuinely intends to build and changes their mind in week 3. Nothing on chain distinguishes that from bad luck on the day you bought.
• A launch with clean contracts, burned liquidity, fair distribution and no buyers. Most tokens fail this way rather than dramatically, and no safety check has an opinion about demand.
• A team that sells through wallets with no visible connection to the deployer, funded weeks earlier through a mixer or an exchange. Cluster mapping catches the lazy version and not the patient one.
• A same slot drain, where the pool is created and removed inside the same block. Auto exit on liquidity movement is fast and it is not faster than atomic.

Screening removes the mechanical traps that can be proven on chain. It does not remove the risk of a bad trade, and anyone selling you a check that does is selling a feeling.

Position sizing is the last line of defence

Every check above reduces how often you lose. Just 1 thing reduces how much you lose when a check misses, and it isn't a check at all.

Size so that the worst realistic outcome on a single launch is boring. At 0.1 SOL a buy with 3 positions open, a total loss on all 3 costs 0.3 SOL, which is annoying and changes nothing about your week. At 2 SOL a buy, one honeypot that slipped through is a genuinely bad day and, more dangerously, the start of trying to make it back.

Two settings do the same job automatically, and both are worth setting before you need them:

• A maximum hold. Liquidity pulls cluster in the first minutes, so a 20 to 45 minute cap closes positions before the window where most of them happen.
• A daily loss limit. Pick the number that would make you close the laptop, then let software enforce it, because the version of you at loss number 4 is not the version that set the rule.

Checks decide what you buy. Sizing decides whether being wrong matters. Most people spend all their attention on the first and lose their money on the second.

Questions people ask

These come up in the ticket queue often enough to answer once, properly. If yours is not here, send it over and it probably ends up on this page.

Key takeaways

• Four different mechanisms get called a rug pull, and 3 of them are visible on chain before you spend anything.
• Burned liquidity removes one risk and says nothing about supply, authorities or how much the creator kept.
• A simulated sell is the only check that catches every honeypot variant, because it tests the outcome rather than the cause.
• Deployer history is the strongest single predictor available, and it takes one lookup.
• Twenty wallets funded from one source read as healthy distribution on tools that only count addresses.
• No check catches a creator who changes their mind, which is why sizing is the last line of defence.