How to Research AI Crypto Projects in 2026: A Due Diligence Checklist

Published on August 10, 2026 by Steven Jones

Researching an AI crypto project properly means proving three separate claims before you even think about price: the product genuinely uses AI, blockchain solves a real coordination or trust problem, and the native token has a job that cannot be replaced without changing the product. A convincing website can satisfy none of those tests.

This due diligence checklist is designed for people evaluating AI tokens, agent projects, decentralised AI networks and crypto presales. It focuses on evidence you can verify: architecture, working product, developer activity, token utility, vesting, wallet concentration, treasury movements, liquidity, audits, partnerships and centralised dependencies. It is a credibility framework, not a predictive model or a buy recommendation.

That last point deserves emphasis. A legitimate project can still be a terrible investment at the wrong valuation. A technically weak project can also rise sharply because a market narrative is strong. Due diligence helps you avoid confusing credibility with price momentum.

Start with the 10-minute rejection test, not the token price

Most research processes start too late. People check the chart, market cap and social following, become interested, and only then try to justify the project. Reverse the order. Your first pass should be designed to quickly reject weak ideas.

1. Open the product. Can you use something now, or are all the important features still on the roadmap?
2. Find the technical explanation. Can you identify what the AI actually does, where inference happens and what data or models it depends on?
3. Find the contract and token allocation. Are the token contract, vesting arrangements and major wallets publicly verifiable?
4. Check the token’s compulsory function. If users could pay with a stablecoin or a normal subscription and nothing important would break, then the native token would need much more scrutiny.
5. Verify one claimed partnership independently. Look for confirmation from the partner, not another article that merely repeats the project’s announcement.
6. Run the shutdown test. Ask what still works if the company’s website, Cloud servers and private API keys disappear tomorrow.

If the project cannot answer several of those questions with evidence, stop. More hours of reading promotional material rarely repairs a weak first pass.

---

---

The three-necessity test: AI, blockchain and the token must each earn their place

AI crypto combines two technologies and usually adds a third economic layer, the token. That creates three separate opportunities for unnecessary complexity. DIY AI’s three-necessity test treats each layer as guilty until proven useful.

1. Does the product genuinely need AI?

Do not accept labels such as AI agent, intelligent network or autonomous protocol as technical evidence. Identify the actual job performed by machine learning or a language model. Is the system ranking data, generating outputs, routing transactions, training models, validating inference, controlling an agent or simply presenting a chatbot over ordinary crypto data?

Ask what model is used, what inputs it receives, where inference runs, how outputs are checked and what happens when the model is unavailable. Calling a third-party model API can still produce a useful product, but it is very different from building decentralised AI infrastructure.

A useful warning comes from the 2026 preprint Paper Agents, Paper Gains by Jay Yu, Amy Zhao and Danning Sui. The researchers surveyed more than 1,900 AI-tagged crypto projects before studying investment-agent deployments in depth. Their analysis found that many projects in the sample lacked clear evidence of autonomous trade execution, while developer interviews suggested some visible deployments were still basic API integrations. It is a preprint focused on investment agents rather than on every AI token, but the research supports a practical rule: verify the architecture rather than infer sophistication from the word “agent”.

2. Does the product genuinely need blockchain?

Run a database counterfactual. Replace the blockchain with a conventional database, normal user accounts and standard payments. What important property disappears?

Good answers can include permissionless settlement, verifiable ownership, coordination among parties that do not trust a single operator, open access to a shared state, cryptographic proof of activity, or economic incentives that require public settlement. “Transparency” on its own is weak if the important AI work happens on a private server and only a receipt is written on-chain afterwards.

3. Does the product genuinely need its own token?

Now run the stablecoin counterfactual. Could the same network charge users in USDC, ETH, fiat or an ordinary subscription without changing its security model or resource allocation?

A native token can be justified where it is integral to staking, slashing, collateral, resource allocation, network security, governance with meaningful control, or incentives between otherwise independent participants. The harder question is whether project success creates any necessary demand for that token. A successful AI product and a successful token are not automatically the same economic outcome.

DIY AI three-necessity test: If you cannot explain why the product needs AI, why AI needs this blockchain design, and why the blockchain system needs this specific token, you do not yet understand the investment thesis.

Build an evidence ladder so marketing cannot grade its own homework

The biggest research mistake is counting all evidence equally. A whitepaper, a founder interview, and a project blog may provide useful details, but they are still project-controlled evidence. The next step is to reproduce the claim independently.

Claim	Project-controlled evidence	Stronger evidence	What would concern us
“We use advanced AI”	Whitepaper architecture diagram	Working product, technical documentation, code, reproducible model behaviour	No explanation beyond branding or a generic chatbot
“The token is essential”	Token utility page	Observable network function that requires the token	Product works equally well without it
“Team tokens are locked”	Allocation graphic	Published vesting contracts or verifiable wallet controls	Contracts withheld while funds are already being raised
“We have major partners”	Logo wall and announcement	Confirmation from the named counterparty	The supposed partner does not confirm the relationship
“The project has traction”	User or transaction figures	Reproducible on-chain activity, usage data, fees or independent integrations	Metrics cannot be reconciled with observable activity

Do not total these into a neat score and average away serious problems. A fabricated partnership, a hidden token contract, or an unexplained treasury movement should remain a live issue even if the project has an active repository and a polished product.

Trace the token from allocation to the wallets that can actually sell

Tokenomics slides tell you the intended allocation. Wallets and contracts tell you what can happen.

Start with circulating supply, total supply, and the allocation to the team, investors, treasury, ecosystem incentives, and community distribution. Then map the vesting schedule. Large future unlocks can change the supply available to the market, but an unlock is not automatically bearish. You need to know who receives the tokens, how large the unlock is relative to current liquidity, whether recipients have sold previous unlocks and whether the schedule is actually enforced on-chain.

Holder concentration also needs interpretation. A top-holder table can make a token look dangerously concentrated when the largest addresses are an exchange, a liquidity pool, a burn address, or a vesting contract. The opposite problem also occurs: related insiders can split holdings across several wallets. Label the addresses before drawing conclusions.

For wallet profiling, holder labels and treasury movements, our Nansen AI review explains where labelled on-chain intelligence helps and where its interpretations still need checking. The research question here is not “are whales buying?” It is “who controls supply, what can become liquid, and what have those entities actually done before?”

Treat audits, partnerships and press coverage as scoped claims

An audit is useful evidence, but only for the code and version that was audited. It may say nothing about the AI backend, off-chain databases, admin keys, front-end wallet permissions, token economics or code deployed after the review. Check the audit date, contract addresses, scope, unresolved findings and whether the deployed bytecode matches the version reviewed.

Partnerships need the same discipline. A project announcing a relationship is one source. A partner independently confirming a production integration is stronger. Look for the partner who names the project, describes what is being used, and shows evidence that the relationship is more than an event appearance, a grant, an accelerator placement, or a loose technology collaboration.

Press coverage is even easier to misread. One recurring pattern in presale post-mortems is that buyers saw pages of positive search results, videos with substantial audiences and busy chat groups and treated the volume of attention as independent validation. Sponsored articles, syndication, affiliate videos and project-controlled communities can create a large publicity footprint without adding a single new piece of technical evidence.

Use a source-dependency test: if 20 articles ultimately repeat one press release, you have one source, not 20.

Use the shutdown test to expose hidden centralisation

A project can place a token on a blockchain while keeping every important part of the product under a single company’s control. This is especially common in AI because model inference, data pipelines and orchestration can be expensive and difficult to decentralise.

Ask what happens if the company disappears. Can users still access the protocol? Can another team operate the interface? Are model weights or inference providers replaceable? Does a central server decide outputs? Can a single private key upgrade contracts, move treasury funds, or change critical parameters? Does the application depend on a single commercial AI API, Cloud account, RPC provider or proprietary database?

Centralised dependencies do not automatically make a project bad. They make its risk model different from the decentralised story being sold. A useful hybrid product should be described as such. If the token thesis depends on censorship resistance or autonomous operation, a single-company shutdown path deserves much more weight.

Check developer activity for shipped work, not commit theatre

GitHub activity is easy to overrate. Hundreds of commits can come from documentation changes, dependency updates, generated files or a fork of someone else’s code. A repository can also be quiet because the important code is private.

Look for releases that correspond to roadmap claims, unique contributors working across meaningful components, issues being closed with working changes, tests, deployment instructions and technical documentation that matches the live product. If the project claims a new inference network shipped last month, you should be able to find evidence of that system somewhere beyond a marketing post.

The strongest signal is consistency across layers: the roadmap says the feature shipped, code or documentation changes support it, the product exposes it, and users or on-chain activity show it being used.

Research liquidity separately from market cap

Market capitalisation can make a token look substantial while the amount you can actually buy or sell near the quoted price is small. For younger AI tokens, inspect trading venues, pool depth, daily trading volume quality, slippage on realistic order sizes, and liquidity sources.

Also examine who controls liquidity-provider positions and whether liquidity commitments expire. A token with concentrated ownership and thin liquidity poses two linked risks: insiders may control a large share of the supply, and liquidity may be limited if several holders try to exit at once.

Do not treat a centralised exchange listing as proof of project quality. Listings improve access and sometimes liquidity, but they do not validate the AI architecture, token utility, treasury controls or long-term economics.

Presales need a stricter checklist because you are verifying promises before a market exists

AI crypto presales combine narrative and operational risks. You may be sending funds before a liquid token, public market or mature product exists, so missing information deserves more weight than it would for an established network.

• Confirm the official contract or presale router from more than one project-controlled channel.
• Check whether the token contract exists and whether team, treasury and investor vesting can be verified.
• Trace where presale funds move rather than assuming the receiving wallet is the final treasury.
• Read wallet approval requests before signing. A familiar wallet-connect screen is not a safety check.
• Never enter a wallet seed phrase or private key into a presale site.
• Check the claim and withdrawal mechanics before purchase, including any lock period or vesting applied to buyers.
• Separate paid promotion from independent analysis. Repeated coverage is not repeated verification.

A hard rule helps here: if a project is already taking money while refusing to publish evidence it says already exists, such as deployed contracts or enforceable vesting, treat the missing evidence as unresolved rather than trusting a promise to reveal it later.

A practical AI crypto due diligence workflow

You do not need one platform that claims to answer everything. Better research uses different evidence layers and checks whether they agree.

1. Write the thesis in one sentence. State the user problem, AI function, blockchain function and token function. If you cannot do this, keep researching before looking at valuation.
2. Use the product. Record what works now, what requires a token and what remains promised.
3. Inspect technical evidence. Read architecture documentation, repositories, model dependencies and the shutdown path.
4. Map token supply. Check allocations, vesting, unlocks, major holders and treasury addresses.
5. Verify activity. Compare claimed users, transactions, fees or integrations with observable evidence.
6. Verify people and counterparties. Check the team’s history and confirm key partnerships with the other party.
7. Read the audit properly. Match scope and contract version rather than treating the audit logo as a pass mark.
8. Check liquidity and exit mechanics. Model what happens if you need to sell into the actual available depth.
9. Write the bear case before the bull case. Identify what would falsify the thesis and which signals you will monitor after purchase.

If you need software for the evidence-gathering stage, our guide to the best AI crypto research tools compares platforms for on-chain intelligence, project research, narrative monitoring and custom analysis. Use tools to retrieve and organise evidence. Do not let an AI-generated score or summary become the evidence itself.

Keep a one-page evidence sheet for every project

The best way to stop research turning into confirmation bias is to make every project fit the same template. Keep one page with the following fields:

• Problem the product solves
• AI necessity and architecture evidence
• Blockchain necessity
• Native token necessity and value-capture mechanism
• Working product and measurable usage
• Team and independently verified partners
• Developer activity and shipped releases
• Token allocation, vesting and next major unlock
• Largest labelled holders and treasury movements
• Audit scope and unresolved findings
• Centralised dependencies and admin powers
• Liquidity and realistic exit conditions
• Three strongest reasons the thesis could be wrong

This structure also makes projects comparable. A new token with a spectacular story but blank evidence fields looks very different once placed beside a less exciting project with a live product, verifiable contracts and years of developer history.

Common mistakes that make weak AI crypto projects look stronger

• Starting with upside. A price target encourages you to interpret later evidence in favour of a decision you already want to make.
• Counting publicity as proof. Ten sponsored articles derived from a single press release still support one underlying claim.
• Treating a doxxed team as sufficient. Known identities improve accountability but do not prove the architecture, economics, or security are sound.
• Using audit status as a binary label. An audit is scoped evidence, not insurance against every technical or economic failure.
• Reading tokenomics without wallets. Allocation diagrams describe intended structure; contracts and wallet behaviour reveal control and execution.
• Copying profitable wallets. You may see the entry after the useful information has already been priced in, and you rarely share the same cost basis, liquidity access or risk limits.
• Confusing project quality with token value. A useful network can still have a poorly designed token, excessive valuation or supply schedule that weakens the investment case.

When should you stop researching an AI crypto project?

Stop when the project asks you to replace evidence with trust. That could mean an unverifiable contract, a supposedly major partnership that the other party does not acknowledge, withholding vesting details during an active sale, unexplained treasury transfers, claims of decentralisation that depend on a single private backend, or pressure to act before basic questions are answered.

Also stop when your own thesis becomes unfalsifiable. If every weakness can be explained away as “early”, every delay becomes bullish and every missing metric is dismissed because the market will understand later, you are no longer doing due diligence.

The FCA crypto investment guidance remains a useful baseline for UK readers: crypto is high-risk and speculative, and investors should be prepared to lose all their money. This checklist can help expose weak evidence. It cannot make a speculative asset safe.

AI crypto due diligence checklist

• Can I explain the real user problem without mentioning the token price?
• What exactly does the AI do, and where does it run?
• What fails if AI is removed?
• What would fail if blockchain were replaced by a normal database?
• What fails if the native token is replaced by a stablecoin or subscription?
• Is the live product consistent with the whitepaper?
• Can I verify meaningful development work and shipped releases?
• Are important partnerships independently confirmed?
• Are token allocation and vesting enforceable and verifiable?
• Who controls the largest wallets, treasury and admin keys?
• Does the audit cover the contracts currently deployed?
• What critical parts still depend on a single company, server, or API provider?
• Is there enough real liquidity for the position size being considered?
• What evidence would make me reject the thesis?

If you can answer those questions with evidence rather than promotional claims, you have completed the credibility stage. Only then do valuation, portfolio fit, and the decision to take financial risk belong on the table.

Frequently asked questions

How do I know if an AI crypto project is legitimate?

You cannot prove legitimacy from one signal. Build a chain of evidence across the working product, team, code, token contract, vesting, wallet activity, partnerships and liquidity. The strongest projects let important claims be independently verified rather than asking you to trust their own marketing.

What should I check before investing in an AI crypto presale?

Prioritise contract verifiability, buyer claim mechanics, team and treasury controls, vesting, wallet permissions, planned liquidity and whether the product exists independently of the token sale. Be especially cautious when the project is already collecting funds but material contracts or lock arrangements remain hidden.

Does a smart contract audit mean an AI crypto project is safe?

No. An audit reviews a defined scope at a point in time. It may not cover the AI backend, token economics, centralised services, admin-key risk, website security or later code changes. Always match the audit to the contracts and versions currently deployed.

How important is token holder concentration?

It is important, but raw percentages can mislead. Identify exchanges, liquidity pools, vesting contracts, treasury wallets, bridges and related insider addresses before judging concentration. The practical concern is who can make supply liquid and how that compares with available market depth.

Can AI research tools do this due diligence for me?

They can accelerate research by retrieving wallet, market, project and event data, but they should not make the credibility decision for you. Generated answers can omit context or repeat incorrect source material. Use AI to locate evidence, then verify the evidence at its source and on-chain where possible.