How Machine Learning Evaluates New Crypto Tokens

New crypto tokens appear faster than people can manually inspect them. Machine learning helps analysts process that flood of information by comparing contract details, wallet behavior, trading activity, liquidity, and social signals against patterns associated with fraud, manipulation, volatility, or healthier market formation.

That does not make a model a financial adviser or a reliable price predictor. A model produces an estimate from incomplete and changing data. The strongest evaluation combines machine learning with smart-contract review, source verification, liquidity analysis, and human judgment.

What machine learning evaluates in a new crypto token

A token is not evaluated from one number. A useful system assembles multiple feature groups, where a feature is a measurable input supplied to the model.

The first group concerns the token contract. Analysts may inspect whether the contract allows an owner or administrator to mint more tokens, freeze transfers, blacklist addresses, change fees, pause trading, or alter transaction rules after launch. These permissions do not automatically prove that a token is malicious. They do show where control remains concentrated and what could happen if those permissions are abused.

The second group covers token distribution. Models can examine how many wallets hold the supply, how much is controlled by the deployer, whether related wallets received tokens early, and whether large holders transfer tokens among one another. Concentrated ownership creates a potential exit and governance risk because a small number of wallets may influence liquidity, voting, or selling pressure.

The third group describes market behavior. This includes transaction count, buy-to-sell balance, trading volume, price changes, spread, liquidity depth, and the age of trading pairs. Volume is especially difficult to interpret. The Securities and Exchange Commission has alleged that some crypto market-manipulation schemes used self-trading and algorithms to create the appearance of an active market.SEC enforcement release

The fourth group concerns liquidity. A token may have a high displayed market value while having little liquidity available for actual selling. A model can monitor the size and duration of liquidity pools, changes in reserves, the presence of lock mechanisms, and whether liquidity is rapidly removed. These signals are risk indicators rather than proof of future loss.

The fifth group includes off-chain information. Models may process project documentation, website changes, developer activity, social-media patterns, wallet labels, and news coverage. These inputs can help identify copied language, sudden promotional campaigns, or accounts that appear coordinated. They can also introduce bias, because public information may be incomplete, manipulated, or unavailable for smaller projects.

The machine learning workflow

A typical token-evaluation system follows a sequence rather than making a single instant judgment.

1. Collect blockchain and market data

The system gathers information from public ledgers, decentralized exchanges, token contracts, and market-data providers. Blockchain data can include transfers, wallet creation times, contract calls, liquidity events, and interactions between addresses.

The data must be time-stamped. A model that uses information appearing after a token collapsed would be unfairly advantaged when tested on earlier launches. This problem, called data leakage, can make a system look accurate in a lab while failing in live use.

2. Convert activity into features

Raw transactions are difficult for most models to interpret directly, so analysts transform them into measurable features. Examples include:

Percentage of supply held by the largest wallets
Number of unique buyers during the first trading period
Ratio of buys to sells over defined time windows
Changes in liquidity after launch
Number of contract permissions retained by the owner
Frequency of transfers between connected wallets
Time between deployment and first liquidity event
Volatility and price impact during larger trades

Some features describe the token itself. Others describe the network around it. A wallet that repeatedly funds deployers, receives tokens immediately after launch, and sells shortly after promotional activity may be more informative when viewed as part of a connected graph than as an isolated address.

3. Compare against labeled examples

Supervised learning uses historical examples with labels such as “rug pull,” “high-risk launch,” “manipulated volume,” or “continued trading.” The model learns relationships between features and those labels.

The label quality determines much of the result. If a dataset marks only tokens that received public accusations as fraudulent, it may miss quiet failures. If it labels every token with a large price decline as a scam, it confuses ordinary market risk with deliberate misconduct.

A 2026 preprint studying fraudulent Solana memecoins reported a dataset of 6.4 million tokens and tested models including Random Forest, XGBoost, and multilayer perceptrons using early trading information.Catching the Rug: Early Prediction of Fraudulent Memecoins on Solana Its reported approach is promising as research, but a preprint is not the same as an independently validated commercial screening system, and results from one chain or token category may not transfer to another.

4. Produce a score or classification

The output may be a probability, risk tier, anomaly flag, or ranked list. For example, a system might classify a token as low, medium, or high risk based on a combination of contract permissions, holder concentration, and trading behavior.

A score is not a verdict. A high-risk classification can mean that the token resembles prior risky cases, not that fraud has been established. Conversely, a low-risk score can mean only that the available features do not resemble known failure patterns.

5. Monitor the token after launch

Evaluation cannot end at deployment. A contract owner may change permissions, liquidity may be withdrawn, wallets may coordinate, or a previously inactive address may begin selling. Models therefore need repeated observations and alerts.

Market conditions also change. A model trained during one cycle may learn relationships that weaken during another. Research on crypto risk monitoring has explored clustering and other unsupervised methods to identify changing volatility patterns and concept drift, meaning that the behavior of the underlying data changes over time.Risk monitor system for blockchain-based security issuing system

Main model types and what they reveal

Different methods answer different questions. No single approach captures every token risk.

Approach	What it can detect	Main limitation	Best use
Rule-based checks	Explicit permissions, holder concentration, liquidity changes, and known contract patterns	Misses unfamiliar behavior and can create false positives	Fast first-pass screening
Supervised classification	Similarities to labeled historical token failures or outcomes	Depends on accurate labels and representative training data	Ranking known risk patterns
Anomaly detection	Activity that differs sharply from normal launches or wallet behavior	Unusual does not always mean harmful	Finding new or coordinated behavior
Graph analysis	Connections among wallets, deployers, funders, and trading addresses	Relationships can be difficult to interpret and may include innocent links	Investigating coordinated activity
Natural-language models	Repeated claims, copied documents, promotional patterns, and disclosure gaps	Text can be fabricated, vague, or rapidly changed	Supporting project and communication review

Rule-based systems are often easier to explain. If a contract allows an owner to disable transfers, an analyst can understand the warning directly. Machine learning becomes more valuable when signals interact in ways that are difficult to encode manually.

Graph analysis is particularly useful for wallet relationships. A model can represent addresses as nodes and transfers or shared funding as connections. Clusters may reveal groups of wallets that behave similarly, but a cluster is not automatically a criminal organization. Exchanges, market makers, automated strategies, and ordinary users can also create connected activity.

How models identify common token risks

Rug-pull indicators

A rug pull generally describes a situation in which insiders or controlling participants drain value, remove liquidity, restrict selling, or abandon a project after attracting buyers. Models may look for rapid liquidity removal, concentrated insider holdings, suspicious deployer funding, unusual wallet coordination, or contract permissions that enable restrictive behavior.

These indicators are strongest when they appear together. A newly launched token naturally has few holders and volatile activity, so any one feature can produce a misleading alert.

Honeypot and sell-restriction indicators

A honeypot is a token that appears purchasable but prevents or severely limits selling. Static contract analysis can search for restrictive transfer logic, while transaction simulation can test whether representative wallets can buy and sell under expected conditions.

Simulation is not perfect. A contract may behave differently depending on wallet status, block timing, fees, liquidity, or administrative changes. A successful test at one moment does not prove that trading will remain possible later.

Concentration and exit risk

Ownership concentration is a direct input for many screening systems. If a small group controls much of the circulating supply, a coordinated sale may create severe price impact. Concentration can also affect governance if token voting is used.

The context matters. Treasury wallets, vesting contracts, exchanges, and liquidity pools may appear as large holders but serve different functions. A model should classify known addresses where possible instead of treating every large balance as insider ownership.

Wash trading and artificial volume

Wash trading involves transactions that create the appearance of market activity without genuine economic transfer of exposure. It can make a token appear liquid and popular while disguising the amount real buyers could absorb.

The SEC has described alleged crypto schemes involving self-trading and artificial volume intended to induce retail purchases.SEC charges concerning crypto-asset market manipulation A model may compare wallet overlap, repeated trade sizes, timing patterns, and volume relative to liquidity. Even so, automated detection usually identifies suspicious behavior rather than proving intent.

Volatility and liquidity risk

Some systems forecast volatility or estimate downside risk instead of looking for fraud. They may use historical returns, trading depth, spreads, and correlations with broader markets. This can help describe how difficult a token may be to trade, but it does not establish that the project is legitimate.

Investor.gov warns that crypto-asset investments can involve significant volatility, illiquidity, fraud, theft, and the possibility that customers cannot recover assets after a failure.Investor.gov crypto asset securities alert

Why a high machine learning score can be wrong

The most important limitation is that models learn from historical data, not from the future. A novel scam can avoid known patterns, while an honest project can look suspicious because it has concentrated early ownership or thin liquidity.

False positives arise frequently in new markets. A project may launch with a treasury wallet, automated market maker, or early contributor allocations that resemble insider control. A false negative can be more dangerous: a carefully designed scheme may use dispersed wallets, established accounts, and normal-looking transactions.

Data quality creates another problem. Blockchain records are public, but identity and intent are not always visible. One person may control many addresses, while one address may be used by many people. Labels from public reports can also be delayed, incomplete, or disputed.

Models can also become stale. Developers change contract practices, trading bots adapt, and market participants learn the features used by screening tools. Regular backtesting, out-of-time testing, and monitoring for performance degradation are essential.

A responsible system should therefore show reasons behind a score. “High risk” is less useful than a clear explanation such as “owner retains a transfer-freeze permission,” “top wallets control a large share of supply,” or “trading activity is concentrated among connected addresses.” Explanations let a reviewer challenge bad assumptions.

A practical evaluation process for readers

Machine learning is most useful as a filter within a broader review.

Confirm the exact contract address and blockchain. Similar names and copied symbols can point to different assets.
Read the contract permissions. Check minting, pausing, blacklisting, fee changes, upgradeability, and ownership controls.
Examine holders and transfers. Separate known treasury, liquidity, exchange, and vesting addresses from unexplained concentrated wallets.
Inspect liquidity. Look at depth, duration, ownership, withdrawal permissions, and the likely price impact of a sale.
Test buying and selling cautiously. A simulation or small test does not remove smart-contract or market risks.
Compare displayed volume with wallet behavior. Repeated patterns, shared funding, or unusually synchronized trades deserve further review.
Check project disclosures. Verify the team, code repositories, token allocation, vesting terms, and stated utility rather than relying only on promotional posts.
Treat the model output as one input. Do not interpret a low-risk label as approval or a high-risk label as proof of wrongdoing.
Recheck after launch. Permissions, liquidity, holders, and market behavior can change quickly.

This process also helps separate three different questions: whether the contract can harm holders, whether the market is tradeable, and whether the project has a credible purpose. A token can pass one question and fail another.

How to judge an evaluation model

A model should be assessed with more than overall accuracy. If risky tokens are rare, a system can appear accurate by labeling nearly everything safe. Precision asks how often a risk alert is correct. Recall asks how many risky cases the system catches. Both matter, but their importance depends on the cost of missed risks and unnecessary warnings.

Testing should reflect real deployment. Train on earlier launches and test on later ones. Keep chains, token categories, and market periods separate when possible. Report performance across different conditions instead of presenting one headline number.

Look for these qualities:

Clear definitions for every label
Time-aware testing without future-data leakage
Evidence that the model works outside one chain or launch period
Explanations for individual alerts
Monitoring for changing performance
A process for correcting mislabeled data
Human review for high-impact decisions
No claim that a score predicts price or guarantees safety

A vendor that cannot explain its data sources, labels, testing period, and alert logic should be treated cautiously. Proprietary methods are not necessarily unreliable, but opacity makes independent evaluation difficult.

Conclusion

Machine learning evaluates new crypto tokens by combining contract permissions, wallet distribution, transaction patterns, liquidity, market behavior, connected addresses, and sometimes project communications. Classification models compare tokens with labeled historical cases, anomaly systems look for unusual behavior, and graph methods examine relationships that are difficult to see from individual wallets.

The result is a screening signal, not a safety certificate. New tokens have limited history, public blockchain data rarely reveals intent, and market conditions change quickly. The most defensible approach uses machine learning to prioritize investigation, then verifies the underlying contract, ownership, liquidity, trading behavior, and disclosures before making a decision.