A Pre-Buy Checklist for AI Agents on New Meme Coins
Build a pre-buy checklist for new pump.fun coins: creator history, graduation type, curve progress, liquidity, position limits, and exits before an entry.
On this page
Disclosure: QuantBase is made by the team behind memecoin.buzz.
Risk: Most meme coins go to zero. Not financial advice.
A pre-buy checklist gives an AI agent a narrower job than finding a promising new coin: collect evidence, compare it with written rules, and stop when something is missing. The useful output is a decision you can inspect—not a confident paragraph about the meme.
For new pump.fun coins, that means checking the creator, launch path, current trading state, liquidity, position limit, and exit instructions before allowing an entry. A token name and a busy chart do not answer those questions.
This guide describes a screening workflow, not a claim that any particular agent performs every check. Start on paper money, set hard limits, and never share a seed phrase or private key with an AI, bot, or agent.
Build the pre-buy checklist around evidence
An agent here means software that can gather information and act through connected tools. Its checklist should separate what it observed from what your rules permit.
Use 3 possible results for each required check: pass, fail, or unknown. Unknown should block entry rather than quietly become a pass. That includes an unavailable quote, a failed creator lookup, or a trading state the software cannot interpret.
Each result should include:
- Identity: the token's mint address, meaning its on-chain identifier, rather than just its name or ticker.
- Evidence: the source and observation time for the checked value.
- Condition: the exact requirement being evaluated.
- Decision: pass, fail, or unknown, with a short reason.
Keep screening separate from transaction permission. A screening agent can assemble a report without authority to spend. Any execution system should require a complete, current report—not free-form enthusiasm.
Our pump.fun launch-screening guide covers the broader workflow. Here, the focus is the final gate before an entry: every required condition passes, or the system does nothing.
Check the creator and graduation type
Creator record
Ask for the creator address, the number of earlier launches associated with it, and how many of those launches graduated. Graduation means the launch curve sold out and the coin moved to an open market.
QuantBase shows who created each new pump.fun coin and the creator's prior launch and graduation counts. Those counts describe a launch record; they do not establish the creator's intentions or predict the current coin's price.
Make missing-data handling explicit. A creator with no recorded earlier launches is different from a failed lookup. The report should preserve that distinction rather than label both as a clean record. Nor should it treat an address-level record as proof of a person's identity.
Graduation type
For a graduated coin, record how it graduated. QuantBase labels an instant graduate as bought out within 2 seconds of launch, with 1 buyer taking the whole curve. Its organic label describes a curve filled through many buys.
If your rule excludes instant graduates, treat that as a hard exclusion. A lively description should not override it. Equally, an organic label is not a safety certificate.
For a coin still on its curve, graduation type is not yet applicable. That is a defined state, not missing evidence. Do not assign an organic label before graduation happens. Our instant-versus-organic graduation guide explains why these labels describe the launch path, not what happens afterward.
Check curve progress and executable liquidity
A bonding curve is the launch mechanism used to price trades before graduation. The agent needs to identify whether the coin is still trading there, transitioning, or already trading in an open-market pool.
Record curve progress with its source and observation time. Your rule can define an allowed progress range, but there is no universal threshold supplied here. A progress reading answers where the launch stands, not whether an entry meets your other conditions.
The transition needs its own check. The pump.fun public documentation describes a migration state in which curve trading is unavailable after the final curve buy until migration happens. A completed curve should trigger a fresh state check, not an assumption that trading is immediately available elsewhere.
Ask what the planned trade can execute against
Liquidity means the funds or tokens available for trading. Rather than accepting a vague liquidity label, design the checklist to require a current quote for the proposed entry and a sell quote for the resulting position. Record the route, quote asset, fees, and price impact—the change in execution price caused by the trade itself.
For PumpSwap integrations, the documentation specifies pricing against effective quote reserves, which include an adjustment to the pool's quote-token balance. Reading a raw pool balance alone is not the documented quoting method.
This requirement needs a quoting tool that supports it. If your chosen tool does not expose the necessary information, mark the check unknown. Do not ask a language model to fill the gap with a plausible liquidity estimate.
A liquidity check is not a complete rug check, either. Our rug-pull guide explains the distinction between warning signs and evidence of fraud. Keep the checklist's conclusion narrow: a quote check is a quote check, not a verdict on the project.
Set the size limit and exits before entry
The size check should compare the proposed purchase with a cap already chosen by the user. It should not ask the agent to decide how much conviction the coin deserves.
Define separate limits for each position, total open exposure, and cumulative spending during the chosen operating window. Specify whether fees count toward each cap. Also define how pending orders count, so simultaneous entries cannot quietly bypass the limit.
These are configuration requirements, not suggested allocation amounts. An unset limit should block entry, just like a failed lookup.
Make exit instructions complete
Require a take-profit condition, a stop-loss condition, and a time limit before the entry passes. Take profit means an instruction to exit after a specified favorable price move; stop loss means an instruction to exit after a specified adverse move.
The specification also needs to say whether exits close the whole position or part of it, which price source triggers them, and how execution failures are handled. These details should not be improvised after entry.
Treat a trigger as an instruction to attempt an exit, not a promise about the execution price. Define retry limits and when automation stops for review. An exit that exists only in the agent's explanation is not an operational exit rule.
Keep wallet safety outside the agent's discretion
Begin with paper money: simulated funds that cannot spend from a wallet. Use that stage to inspect whether the checklist blocks incomplete entries, respects limits, and records understandable reasons.
Hard limits should be enforced by the spending system, not merely included in a prompt. An agent should not be able to raise its own cap, remove a stop condition, or expand its permissions because a launch looks unusual.
Never share a seed phrase or private key with any AI, bot, agent, plugin, website, or person. A screening task does not require those secrets. If a workflow asks for them, stop rather than treating the request as another setup step.
Before wallet-connected execution, define a stop switch and its scope. Specify whether it blocks new entries, cancels pending activity, or leaves existing exit instructions active. Those are different behaviors; the interface should make the distinction clear.
Turn the checklist into a readable paper rule
A plain-language specification can start with this structure:
- Require verified token identity and current source timestamps.
- Check the creator record against my saved conditions.
- Apply my graduation-type exclusion when graduation has occurred.
- Require an allowed trading state and curve-progress range.
- Require current quotes within my saved execution limits.
- Reject entries that exceed spending caps or lack complete exits.
- Stop on missing required information and record every decision's reason.
This is a proposed checklist, not a statement that every trading app supports every field. Replace vague terms such as “current” and “allowed” with explicit conditions before treating it as an executable specification.
QuantBase is a meme-coin trading app for Solana pump.fun coins. It turns plain-language instructions about what to buy, skip, and sell into readable, editable rules, with take profit, stop loss, and a time limit included. Today it runs rules on paper; live trading is coming soon.
Its rule tests use launches from its own recorder and show the sample size beside each result. That does not establish support for every liquidity, routing, or wallet-control requirement above. Confirm support for each required condition rather than assuming a written prompt makes it available.
To practice translating a screening idea into explicit conditions, test a rule on paper with QuantBase. The traders' Telegram includes a free bot for coin checks covering dev dumps and daily pump.fun statistics.
FAQ
Can this checklist prove a new coin is safe?
No. It checks whether specified evidence and controls are present, not whether fraud or loss is impossible. A passing result means only that the coin met the written conditions at the recorded time.
Should an agent skip a coin with missing creator history?
Distinguish an empty recorded history from unavailable data. A conservative checklist blocks entry when required evidence cannot be retrieved, while applying a separately written condition to creators with no prior recorded launches.
Is an organic graduation enough to approve an entry?
No. It describes how the launch curve filled, not the creator's intentions or the quality of current liquidity. The remaining checklist conditions still apply.
Can I run the checklist without connecting a wallet?
A research-only workflow can be designed to produce a report without spending permission. QuantBase's current paper trading uses no real funds, and its sign-up does not require a wallet connection.
What should happen when a check fails during execution?
A failed check before submission should block the entry and produce a recorded reason. If execution has already begun, follow predefined failure handling and retry limits rather than letting the agent invent new permissions.
Sources
Written with AI assistance and checked by automatic gates: every number must trace to a source above, and quotes are short. Spot an error? Tell us in Telegram.
