How to Build a Powerful Rug Checker in 5 Steps for Solana and EVM

---

A token can pass every surface glance, a clean name, a real logo, a live price, and still be built to trap your money. A rug checker API exists to find the traps a price chart hides: a mint authority that can print more supply, a freeze authority that can lock your wallet, liquidity that looks deep but cannot actually be sold into. This guide builds that rug checker Birdeye Data, a multi chain market data service covering token security, creation info, mint and burn history, holder stats, and liquidity across Solana and major EVM networks.

The rug checker runs several independent checks, then folds them into one risk score. Run the checks in parallel, since none depends on another, and treat any single hard fail as enough to flag the token.

One thing to be honest about up front: coverage is not symmetric across chains. The deepest checks, mint and burn history, holder concentration, and holder behavior, are Solana only. On EVM the scan leans on the security object and a sellability test. Each check below is labeled with the chains it actually supports.

Direct Answer: Build a Rug Checker API in 5 Checks

To build a rug checker API with Birdeye Data, run five checks against a token and combine the results into a risk score.

1. Call GET /defi/token_security and GET /defi/token_creation_info for authority, metadata, tax, and creator risk on Solana and EVM.
2. Call GET /defi/v3/token/mint-burn-txs to catch stealth supply inflation or fake burns on Solana.
3. Call GET /defi/v3/token/holder and GET /holder/v1/distribution to measure how concentrated the supply is on Solana.
4. Call GET /token/v1/holder-profile to break holders into behavior tags such as bundler and insider on Solana.
5. Confirm real sellability with GET /defi/v3/token/exit-liquidity on Base, or GET /defi/token_overview liquidity on Solana, or the honeypot and tax fields from token_security on other EVM chains.

All requests share the base URL https://public-api.birdeye.so, authenticate with the X-API-KEY header, and select the network with the x-chain header. That header matters more here than usual: it decides whether token_security returns the Solana or the EVM schema, and the sellability endpoint only answers for Base when you send x-chain: base. Every endpoint in this scanner is REST. Check 1, which calls token_security and token_creation_info, needs the Lite or Starter package or higher; the remaining checks run on any paid tier including Standard.

A quick note on parameter names, since a wrong one returns an invalid value error: the defi endpoints take the token as address, while holder/v1 and token/v1 endpoints take it as token_address.

Check 1: Scan Authority and Contract Risk

Endpoint: GET /defi/token_security, GET /defi/token_creation_info

Chains: Solana and EVM

Plan availability: Lite or Starter package and up, not Standard

Docs: Token – Security

This is the check that does the most work, and the one that behaves differently per chain. The x-chain header selects the response schema, so your parser has to branch.

curl --request GET \
  --url '<https://public-api.birdeye.so/defi/token_security?address=TOKEN_ADDRESS>' \
  --header 'accept: application/json' \
  --header 'x-chain: solana' \
  --header 'X-API-KEY: YOUR_API_KEY'

On Solana, read mutableMetadata, freezeable and freezeAuthority, transferFeeEnable, isToken2022, creatorPercentage, and top10HolderPercent. There is no honeypot flag on Solana, because the equivalent danger is a live freeze authority: if the issuer can freeze tokens, they can lock your position after you buy, which is a honeypot by another name.

On EVM, the same endpoint returns a different set: isHoneypot, buyTax and sellTax, canTakeBackOwnership, hiddenOwner, isMintable, and lpHolders with lock details. Field coverage varies by EVM chain, with Ethereum returning the fullest set, so null check every field rather than assuming it is present.

token_creation_info rounds out the picture with the creation transaction, the creator wallet, and the block time, which lets you flag tokens deployed minutes ago by a wallet with no history.

Check 2: Catch Stealth Mint and Burn Events

Endpoint: GET /defi/v3/token/mint-burn-txs

Chains: Solana only

Docs: Token – Mint/Burn

A static supply number hides a moving one. A project can mint quietly after launch or stage a fake burn that never leaves their control. This endpoint lists the actual mint and burn transactions so you can see supply changing rather than trusting a snapshot.

Parameter	Required	Notes
address	Yes	Token address
type	Yes	all (default), mint, or burn
sort_by	Yes	block_time (default and only value)
sort_type	Yes	desc (default) or asc
limit	No	Up to 100

curl --request GET \
  --url '<https://public-api.birdeye.so/defi/v3/token/mint-burn-txs?address=TOKEN_ADDRESS&type=all&sort_by=block_time&sort_type=desc&limit=100>' \
  --header 'accept: application/json' \
  --header 'x-chain: solana' \
  --header 'X-API-KEY: YOUR_API_KEY'

A burst of mint transactions after a quiet launch is a clear flag. So is a burn sent to an address the team still controls, which only looks like a burn.

Check 3: Measure Holder Concentration

Endpoint: GET /defi/v3/token/holder, GET /holder/v1/distribution

Chains: Solana only

Docs: Token – Holder

If a handful of wallets hold most of the supply, a coordinated sell can erase your position regardless of how clean the contract looks. The fastest signal is already in your Check 1 response: top10HolderPercent from token_security. For the full picture, pull the top holder list and the distribution stats.

curl --request GET \
  --url '<https://public-api.birdeye.so/holder/v1/distribution?token_address=TOKEN_ADDRESS>' \
  --header 'accept: application/json' \
  --header 'x-chain: solana' \
  --header 'X-API-KEY: YOUR_API_KEY'

distribution returns supply share statistics across holder bands. Add include_list=true when you also need the wallet list behind those bands. Note the parameter here is token_address, not address.

Check 4: Profile Holder Behavior

Endpoint: GET /token/v1/holder-profile, GET /token/v1/holder-positions

Chains: Solana only

Docs: Token – Holder Profile

Concentration tells you how the supply is split. Behavior tags tell you who is holding it. holder-profile breaks the holder base into tags such as bundler, sniper, insider, dev, and smart_trader, which exposes a launch that is mostly insiders and bundlers wearing different wallets.

curl --request GET \
  --url '<https://public-api.birdeye.so/token/v1/holder-profile?token_address=TOKEN_ADDRESS>' \
  --header 'accept: application/json' \
  --header 'x-chain: solana' \
  --header 'X-API-KEY: YOUR_API_KEY'

Two caveats. The bundler tag is reliable only for tokens created from 2026-03-01 onward, so treat it as absent for older tokens rather than as a clean signal. And confirm this endpoint is available on your package before you depend on it, since holder-profile and the companion holder-positions sit outside the core accessibility table. Treat this whole check as an enrichment layer, not a gate.

Check 5: Confirm Real Sellability

Endpoint: GET /defi/v3/token/exit-liquidity (Base), GET /defi/token_overview (Solana), GET /defi/token_security (other EVM)

Chains: Base for the dedicated endpoint, approximations elsewhere

Docs: Token – Exit Liquidity

A token can clear every check above and still be impossible to exit, because the liquidity is fake, one sided, or about to be pulled. How you test this depends on the chain, and there is no single endpoint that covers all of them.

On Base, the dedicated exit-liquidity endpoint answers directly how much can be sold. It requires x-chain: base, and returns a chain not supported error on anything else.

curl --request GET \
  --url '<https://public-api.birdeye.so/defi/v3/token/exit-liquidity?address=TOKEN_ADDRESS>' \
  --header 'accept: application/json' \
  --header 'x-chain: base' \
  --header 'X-API-KEY: YOUR_API_KEY'

On Solana, there is no exit liquidity endpoint, so approximate sellable depth from the liquidity field on token_overview, or price an actual swap through an external router. On other EVM chains, lean on isHoneypot, buyTax, and sellTax from the Check 1 security object, which already encode whether and how much you can sell.

Utility: Monitor Your CU Budget

Endpoint: GET /utils/v1/credits

Docs: Utils – Credits Usage

A rug checker that fires five checks per token adds up fast, so track consumption from day one.

curl --request GET \
  --url '<https://public-api.birdeye.so/utils/v1/credits>' \
  --header 'X-API-KEY: YOUR_API_KEY'

It returns the current cycle usage and remaining credits. If you scan on every page load, cache results for a short window so the same token is not rescanned on every view, and watch this endpoint to catch a runaway batch before it hits overage.

Putting It Together: Reference Architecture

The five checks in your rug checker have no ordering dependency, so fire them together with Promise.all and combine the results once they return. On Solana you get all five. On EVM you get Check 1 and the EVM branch of Check 5, which is why the security object carries most of the weight there.

Checklist before you ship your rug checker:

• The token_security parser branches on x-chain, since Solana and EVM return different fields.
• exit-liquidity is only called with x-chain: base, and Solana falls back to token_overview liquidity.
• token_address is used for the holder/v1 and token/v1 calls, and address for the defi calls.
• holder-profile is treated as optional enrichment, not a required gate.
• Results are cached for a short window so a token is not rescanned on every page view.

FAQ

Does this rug checker API work the same on Solana and EVM?

No, and the article is explicit about it. Authority and contract risk (Check 1) works on both. Mint and burn history, holder concentration, and holder behavior are Solana only. On EVM the scan relies on the security object plus a sellability test, with exit liquidity available only on Base.

Why does token_security return different fields on Solana versus EVM?

The schema is chain specific and selected by the x-chain header. Solana returns mint and freeze authority, mutable metadata, and transfer fee fields. EVM returns honeypot, buy and sell tax, ownership, and LP lock fields. Branch your parser on chain rather than expecting one shape.

How do I check whether a Solana token can actually be sold?

There is no dedicated exit liquidity endpoint on Solana. Approximate sellable depth from the liquidity field on token_overview, or price a real swap through an external router. The dedicated exit-liquidity endpoint only covers Base.

What parameter name does each endpoint expect for the token?

The defi endpoints use address. The holder/v1 and token/v1 endpoints use token_address. Sending the wrong one returns an invalid value error.

Is a single freeze authority really a rug signal on Solana?

It is one of the strongest. A live freeze authority lets the issuer lock your tokens after purchase, which functions as a honeypot. Solana has no honeypot flag precisely because freeze authority covers that risk.

---

You now have a five check rug checker that scores a token before anyone trades it. Get an API key at Birdeye Data to start scanning, and keep the full endpoint reference handy as you add checks.