How to Check If a Crypto Team Is Legitimate: Evidence Checklist

Key takeaway: A legitimate-looking team page is not verification. Check four separate claims: the people are who they say they are, they have evidence of relevant work, a real entity or governance structure is accountable, and the people controlling code, upgrades, treasury, liquidity, and communications match the public story. Build independent evidence links; never treat LinkedIn, a conference photo, an audit logo, or a “Verified” social badge as proof by itself.

Known founders can still fail or commit misconduct, and anonymous developers can build legitimate open-source systems. Team verification does not predict success. Its job is narrower: detect fabrication, unexplained conflicts, capability gaps, and hidden control before they become your risk.

Team evidence is one part of the complete what to check before buying crypto process, alongside tokenomics, ownership, liquidity, security, and usage.

The four questions behind team legitimacy

1. Identity: Do these people exist, and are the profiles connected to them?

2. Capability: Have they done work relevant to the claims?

3. Accountability: What legal, governance, or reputational consequences apply?

4. Control: Who can actually change the software or move the assets?

A project can pass one and fail another. A real founder with a strong résumé does not make an upgrade key safe. An anonymous team may have a long, verifiable code history and constrained governance. Keep the dimensions separate.

Step 1: Freeze the team’s claims

Save dated copies or links to:

• official team and foundation pages;
• whitepaper and disclosures;
• legal entity names and jurisdictions;
• founder and executive biographies;
• repository organizations;
• audit and security pages;
• governance documentation;
• treasury, multisig, and admin addresses;
• official social accounts and contact domains.

Record exact claims: employer, dates, role, credential, product shipped, amount raised, partner, investor, audit, and governing entity. Vague claims are hard to disprove by design.

Step 2: Verify identity through independent paths

For each public team member, seek evidence that predates the project:

• profile history with consistent dates;
• old repository commits, talks, articles, patents, or publications;
• former employer pages or archived announcements;
• interviews hosted by independent organizations;
• prior projects with users, releases, or verifiable outcomes;
• public interactions with established peers over time.

Cross-link the evidence. A project site linking to a profile and that profile linking back to the project is one self-asserted loop, not two independent confirmations.

Reverse-image and media checks

Search headshots and key promotional frames for unrelated identities or stock images. Examine whether videos originate from the claimed account and event. Deepfakes and stolen media make visual familiarity weak evidence.

The CFTC specifically recommends researching personnel, running reverse-image searches, and checking domain registration history before trusting AI or crypto trading promotions (CFTC).

Watch for résumé inconsistencies

• overlapping full-time roles with no explanation;
• titles that grow more senior across newer biographies;
• a former employer that never mentions the person;
• credentials with no institution, year, or record;
• one biography copied across supposed team members;
• profile creation or activity beginning immediately before fundraising;
• followers and endorsements disconnected from the claimed field.

Absence is not proof of fraud. Record it as unverified and adjust confidence.

Step 3: Verify the organization and domain

Find the legal entity behind the website, token sale, terms, employment, trademarks, and treasury. Depending on jurisdiction, check official corporate registries and regulator databases. Ask:

• Does the entity exist and remain active?
• When was it formed relative to fundraising?
• Do directors or beneficial owners match disclosures where public?
• Which entity owes users obligations?
• Which law and dispute forum do the terms name?
• Are token issuer, foundation, developer company, and marketing entity different?

Check the domain through ICANN’s RDAP lookup. ICANN explains that RDAP provides current registration data and replaced WHOIS as the standard protocol, while privacy rules may redact personal fields (ICANN).

Domain age is a clue, not a verdict. A new domain can belong to a real new project; an old domain can be acquired by scammers. Look for registrant or registrar changes, look-alike spelling, inconsistent email domains, certificate history, and archived content.

Step 4: Verify capability in the repository

Do not count commits and stop. Inspect:

• who authored substantive code;
• whether core developers match the public team;
• release tags and deploy history;
• dependency and fork history;
• issue and pull-request discussion quality;
• whether development is ongoing or imported in one dump;
• test, security, and review practices;
• the relationship between public code and deployed contracts.

GitHub’s contributor graph can show top contributors to the default branch, but GitHub notes it has scope limits and does not count some contributions, such as unmerged work or certain commits (GitHub). A sparse public profile may hide private or unmerged work; a dense graph may contain trivial changes.

Signed commits provide evidence about a cryptographic key associated with an account. GitHub’s “Verified” status means the signature was successfully verified; it does not certify code quality, employer history, or that every claimed author personally wrote the change (GitHub).

Step 5: Verify shipped work, not roadmap language

For each major claim, look for a live artifact:

• deployed contract at a documented address;
• product users can access;
• release matching repository code;
• protocol activity consistent with the claimed use;
• governance proposals and execution;
• independent integrations confirmed by both parties;
• incident history and postmortems.

A slick demo can be staged. A contract can exist with no meaningful users. A high transaction count can be incentives or bots. Combine artifacts rather than elevating one.

For “partnership” claims, seek an independent announcement from the named partner and clarify whether it means a paid vendor relationship, technical integration, investment, pilot, or marketing campaign.

Step 6: Trace who controls the system

This is often more important than biographies. Identify:

• contract owner and upgrade admin;
• proxy implementation and change process;
• pause, freeze, mint, blacklist, fee, and rescue powers;
• treasury and liquidity multisigs;
• signer identities and threshold;
• timelocks and emergency bypasses;
• governance concentration and delegation;
• front-end domain and deployment control;
• social, repository, package-registry, and DNS administrators.

Compare public decentralization claims with actual control. A nine-member advisory board does not matter if one person controls a 1-of-1 upgrade key and treasury.

Use the holder workflow in How to check token holder distribution to separate team, vesting, treasury, exchange, and infrastructure balances.

Step 7: Read audits in scope

An audit logo does not mean “safe.” Open the report and verify:

• auditor and report URL;
• repository commit or source files reviewed;
• contract addresses, if deployment was reviewed;
• audit date relative to later changes;
• severity definitions;
• unresolved and acknowledged findings;
• whether fixes were retested;
• excluded components and assumptions;
• admin-key and economic-design observations.

Confirm the auditor links to the report from its own domain or repository. Scammers can upload altered PDFs or use logos without permission. Multiple audits may share the same outdated scope.

Step 8: Investigate incentives and conflicts

Map:

• team and advisor allocations;
• vesting cliffs and unlocks;
• treasury compensation;
• market-maker loans or options;
• investor terms where disclosed;
• affiliate and influencer payments;
• related entities receiving protocol fees;
• founder sales or transfers supported by evidence.

Do not call a transfer a sale without execution evidence. Do flag an undisclosed economic relationship when independent documentation supports it.

Step 9: Search for failures and responses

Look for lawsuits, regulator notices, hacks, abandoned products, failed prior tokens, censored criticism, and conflicting explanations. Distinguish allegation, filed complaint, judgment, settlement, and rumor.

How a team responds to a real failure can be more informative than a clean marketing history:

• Did it disclose promptly?
• Did it preserve evidence and publish a postmortem?
• Did claims change after the fact?
• Were affected users given a clear accounting?
• Were permissions or processes improved?

Chainalysis estimated that scams and fraud received at least $14 billion on-chain in 2025 and projected the figure could exceed $17 billion as more illicit addresses were identified; it also documented rapidly growing impersonation and AI-enabled tactics (Chainalysis). That scale makes independent verification more important, but it does not mean every pseudonymous team is fraudulent.

An evidence graph you can reuse

Create one row per claim:

Confidence should attach to each claim, not the whole team. “Partially verified” is more useful than a binary legitimate/scam label.

Red flags that justify stopping

• stolen or mismatched identities;
• guaranteed returns or risk-free language;
• pressure to transfer funds before verification;
• seed phrase, private key, or remote-access requests;
• fake audit reports or contract addresses;
• material biography claims contradicted by primary records;
• undisclosed admin powers that conflict with public claims;
• treasury or liquidity controlled by an unexplained single key;
• “partnerships” denied by the named party;
• refusal to identify the token contract or legal counterparty;
• coordinated attacks on anyone asking basic verification questions.

Investor.gov lists guarantees, risk-free claims, pressure, fake testimonials, and exaggerated credentials among classic investment-fraud warning signs (Investor.gov).

How AI can help without certifying a team

AI can collect claims, build timelines, compare biographies, search archived records, inspect repository patterns, summarize audits, and flag contradictions. Ask it to cite every material fact and distinguish absence of evidence from evidence of absence.

It cannot perform a definitive identity check from public profiles, know private arrangements, or certify motive. AI-generated biographies and deepfakes also make apparent corroboration cheaper to fabricate.

Use this prompt:

Build an evidence graph for every team, entity, partner, audit, and control claim. Prioritize official registries, employer or partner records, auditor-hosted reports, repositories, and on-chain contracts. Mark self-referential loops, date conflicts, and unverified claims. Do not assign a universal legitimacy score or recommend an investment.

BlockMind’s agent can assist with this research, while the manual 12-step DYOR checklist covers the rest of the asset. If the team controls liquidity or upgrade keys, continue with the rug-pull checker limitations matrix rather than treating identity verification as a safety certificate.

Limitations and counterevidence

• Real people and registered companies can still act badly.
• Anonymous teams can ship secure, durable open-source software.
• Corporate and identity records differ by jurisdiction and may be private.
• Repository data can be incomplete, purchased, forked, or outsourced.
• Audit quality varies, and audited code can still contain bugs.
• Lack of online history can reflect privacy or early career rather than fraud.

The conclusion should be “verified to this confidence under these sources,” never “safe.”

The Bottom Line

Verify a crypto team as a network of claims about identity, capability, accountability, and control. Seek independent evidence, inspect code and deployed permissions, read audits in scope, map incentives, and preserve unresolved conflicts. A face and a résumé are only the beginning.

This is research, not financial advice. BlockMind’s agent never tells you what to buy or sell and cannot touch funds.

Sources

• CFTC — AI Won’t Turn Trading Bots into Money Machines
• Investor.gov — Red Flags of Investment Fraud Checklist
• GitHub Docs — Viewing a Project’s Contributors
• GitHub Docs — Commit Signature Verification
• ICANN — Information for RDAP Users
• Chainalysis — 2026 Crypto Crime Report: Scams