"Why doesn't ChatGPT ever mention my project?" The honest answer is usually that nothing outside your own website confirms you exist the way you say you do, and a lot of crypto marketing teams reading this have never once checked.
A Wikidata item, a Crunchbase profile, and a GitHub organization won't fix that on their own. They solve three distinct pieces of the problem, not one interchangeable piece three times. Fill in all three as a checklist and you get three nicely dressed witnesses who can't agree on the time, and that convicts you faster than having no alibi at all. Treat them instead as a triangulation system, each doing a specific evidentiary job, and you've built something closer to what a model actually needs before it will stake its answer on you.
Why Off-Site Signals Matter in Web3
A Web3 project isn't one entity. It's five wearing a trench coat: the token, the protocol, the company behind it, the community running on its own momentum, and a codebase that may or may not match what the homepage promises.
Web2 companies have it easy by comparison. One legal entity, one product, one domain, done. A crypto project routinely runs a foundation in one jurisdiction, a development company in another, a token traded under a name neither entity's filings mention, and a Discord that has outlived two rebrands and a rename nobody updated the About page for.
When that fragmentation never gets resolved anywhere a model can read it, every surface becomes a separate, unverified claim shouting over the others. The project's site says one founding date, a blog post says another, and nobody outside the project has confirmed either. Off-site signals exist to close that gap. Not by repeating the claim louder in more places, but by putting it somewhere independent of the project's own say-so, which is the same logic behind resolving generative engine optimization for Web3 entity resolution for tokens in the first place: a model can't trust a name it can't disambiguate.
The Triangulation Principle
Wikidata, Crunchbase, and GitHub verify three different kinds of fact, and none substitutes for the other two. Wikidata gives you a structured, openly editable entity record. Crunchbase gives you corporate and funding context. GitHub gives you observable technical history. None of the three, alone or stacked together, proves a project is legitimate.
That last sentence is the whole point of this post. A project can have a tidy Wikidata item, a complete Crunchbase profile, and an active GitHub organization, and still be nothing: three self-authored or self-reported surfaces agreeing with each other because the same marketing team wrote all three. That isn't corroboration. It's an echo with good formatting.
The fourth, non-negotiable layer is independent evidence: an audit report from a named security firm, a regulator filing, reporting from a publication that isn't the project's own blog. Without that layer, the first three are a consistent story. With it, they become a verification stack where each piece does a job the others physically cannot.
Here's the practical version of that distinction.
| Source | What it can confirm | What it cannot confirm |
| Wikidata | A structured record of entity facts, with qualifiers and references attached to each statement | Whether the facts are true. Wikidata's own standard is only that a claim appears in a cited reference, not that the reference is correct |
| Crunchbase | Corporate structure, funding rounds, founder names, as reported | Whether the reporting party had any duty to be accurate. Much of a profile is self-submitted |
| GitHub | Code existed, when it changed, who committed it, whether it's maintained | Whether the code is secure, audited, or the same code running in production |
| Independent evidence | Whatever the auditor, regulator, or journalist actually verified | Nothing beyond its own scope. But it's the only layer with no self-interest in the answer |
Get the ordering backwards and you'll spend a sprint polishing a Wikidata item while the actual question a skeptical reader, or a cautious model, is asking goes unanswered: who checked this, and were they paid by you?
Wikidata: Build a Structured Entity Record Ethically
A Wikidata item is a collection of statements, and each statement is a property-value pair that can carry qualifiers, references, and a rank showing which value is preferred where several exist. That structure is the point: a model reading a Wikidata item isn't parsing marketing prose, it's reading declared facts with their sourcing attached like a bibliography that never gets lost.
Build it carefully. Every meaningful statement, founding date, official website, legal entity, token identifier, needs a citation pointing to a source independent of the project itself. Wikidata's own standard is explicit that its goal is verifiability of the claim appearing in a reference, not an independent judgment on whether the claim is true. A weak reference produces a weak item no matter how complete it looks on screen.
This is also where most Web3 attempts fail before they start. Wikidata's self-promotion guidance states plainly that editing an item about your own organization creates an unavoidable conflict of interest, and that personal websites, press releases, and marketing material don't clear the notability bar an item needs to survive.
Wikidata's own editors have flagged exactly this pattern: items created by what they call web reputation agencies on behalf of paying clients, routinely failing the platform's verifiability standard and getting deleted on review. That's not a footnote. It's the central risk, and it's one the platform is actively policing.
An item built entirely from your own announcements, with no independent coverage behind it, is precisely the pattern those editors are watching for. If your project has genuine independent coverage, use aliases to capture the names people actually search, link the canonical official website, attach the identifiers that exist, and stop there. If it doesn't have that coverage yet, an item isn't ready. Forcing one tends to get flagged, not cited.
Crunchbase: Clarify Corporate Context
Crunchbase doesn't verify your project. It organizes what you, or someone else, has told it. Treat the profile as a place to align your legal name, founders, funding history, headquarters, category tags, and founding date with what you state elsewhere, and assume everything on it is self-reported unless visibly claimed and verified.
That distinction is built into the platform itself, not something you have to take on faith. Claiming a Crunchbase company profile requires logging in with an email address matching the company's domain, which is the mechanism separating a profile someone at the company actually controls from one assembled by a third party, or left sitting unclaimed and quietly wrong. A reader has no way to tell the difference just by looking at the page, and neither does a model summarizing it.
What a Crunchbase profile is genuinely useful for is consistency, not proof. Say your site claims you raised a round one quarter and Crunchbase says another. That's a discrepancy a careful reader, or an AI system cross-referencing sources, will notice, and it costs more trust than having no profile at all would. Align the dates, the amounts, the investor names, the official links, then let the profile do the narrow job it's actually built for.
GitHub: Demonstrate Technical Provenance
A public GitHub repository is observable, not certified. GitHub's own documentation describes a repository as storing code and its full revision history, accessible to anyone on the internet who cares to look. A developer, a journalist, a model doing retrieval, all of them can check whether the commit history matches the story your marketing tells.
That's the asset, and it's a genuinely strong one. Commit frequency, release tags, and changelog entries form a dated record nobody can quietly rewrite after the fact. A project claiming active development with a repository that last shipped eighteen months ago isn't fooling anyone who checks, and increasingly something is checking on your behalf.
Three things turn a GitHub presence into credible provenance instead of decoration. First, the organization account needs to be the one your official site actually links to, not a personal account somebody forgot to transfer before they left. Second, releases need notes explaining what changed, not bare version bumps nobody can interpret.
Third, add a SECURITY.md file. GitHub ships a built-in workflow for a security policy that tells a researcher how and where to report a vulnerability, a feature GitHub introduced specifically so disclosure has a clear channel rather than a scramble through social media when something breaks.
What GitHub cannot do is confirm the deployed contract matches the repository, or that the audited version is the version actually running on-chain. That link, repo commit hash to deployed bytecode to audit scope, has to be made explicit somewhere, usually in the audit report itself. GitHub's history stops at the code. It has no opinion on the chain.
A dormant repository is worse than no repository. One archived repo from two years ago, nothing since, invites the exact question you don't want asked: is anyone still building this? If the answer is yes, the commit history should say so without anyone needing to explain it in a tweet.
Connect Surfaces Without Creating Circular Proof
The fix for fragmented identity isn't repeating the same promotional paragraph across five platforms. It's maintaining one canonical description of who you are and linking every surface back to the same official sources. Your Wikidata item's official website statement, your Crunchbase profile's company site field, your GitHub organization's bio link: all three should point at the identical canonical URL, not three plausible variants that each look fine alone.
Consistency is necessary and not sufficient. Three profiles that agree because the same team wrote all three are still one source, just copied three times and dressed up as corroboration. This is where the fourth layer stops being optional. For anything with real stakes, a security claim, a regulatory status, a funding figure a reader will act on, the citation needs to point outward, to an audit firm, a regulator, a publication with nothing riding on the outcome.
Here's a practical way to sort claims by what they actually need standing behind them:
- Low-risk identity facts. Founding date, token ticker, official domain: consistent self-reported statements across surfaces are adequate on their own.
- Medium-risk corporate facts. Funding amount, headquarters, team size: self-reported is fine if clearly disclosed as such, ideally backed by one independent corroboration.
- High-risk claims. "Audited," "licensed," "no critical vulnerabilities," any regulatory status: these require independent primary evidence, full stop. No amount of cross-platform agreement substitutes for it.
A model weighing conflicting claims about a project it's never seen isn't reassured by three sources agreeing if all three trace back to the same press release. It's reassured by one source that doesn't. That's the actual target: not more surfaces, better-sourced ones, the same discipline that sits underneath E-E-A-T for crypto websites more generally.
Maintenance: the 90-Day Evidence Hygiene Routine
Off-site evidence rots faster than most teams expect, and nobody owns the rot by default. A Wikidata item from launch day still claims your launch-day team size. A Crunchbase profile still lists a seed round as your most recent funding, two rounds later. Assign an owner for each surface before the first one goes stale, not after a reader points it out.
Run a quarterly pass with four checks.
- Confirm every official link still resolves and points to the canonical domain, not a redirect somebody forgot to update.
- Check each surface's core facts against your current public statements: funding stage, team size, product status. Flag anything that's drifted.
- Confirm your GitHub security policy still lists a working contact and your latest release notes aren't months behind the actual commit log.
- Review any discrepancy flags across the three platforms and settle which version is correct before anyone else does it for you.
Here's an example of how a simple internal log for that routine might look.
| Surface | Last reviewed | Last actioned | Discrepancy found | Owner | Next action |
| Wikidata item | 3 Jul | 3 Jul | None | Communications lead | Quarterly citation check |
| Crunchbase profile | 3 Jul | 9 Jul | Funding round outdated | Founder / ops lead | Confirm latest round reflected |
| GitHub org | 3 Jul | 3 Jul | None | Engineering lead | Verify SECURITY.md contact is current |
The routine isn't the point. Catching the moment your public record and your actual status diverge, before a journalist, an auditor, or a model surfacing a summary catches it first, is the point. A stale log is just a slower way of finding out the hard way.
Eligibility, Ethics, and Failure Modes
Most of what goes wrong here isn't malicious. It's shortcut-seeking wearing the costume of efficiency, and it fails in a handful of entirely predictable ways.
Paid profile inflation is the most common: hiring a service to pad a Wikidata item or a Crunchbase profile with flattering but unverifiable detail. Wikidata's own guidance anticipates exactly this, describing agency-created items that don't hold up against its verifiability standard. Those items tend to get edited back or deleted, not quietly accepted.
Undisclosed conflicts of interest are the second failure mode: a team member editing their own project's Wikidata item without declaring the connection, against the platform's own norms and typically caught by other editors watching for precisely this. Edited promotional records follow the same pattern one level up, where an item that started neutral gets gradually rewritten toward marketing copy until someone reverts it.
Inactive repositories and stale profiles round out the list. Less a violation of anyone's rules than a quiet admission nobody's maintaining the story. And then there's the failure mode none of the above cover: three surfaces that simply disagree, a funding date here, a different one there, with nobody noticing because nobody was assigned to check. Every one of these is avoidable with ownership and a maintenance routine. Less exciting than a growth hack, but it's the one that actually holds up when someone pulls the thread.
Conclusion
The verification stack behind durable off-site trust is Wikidata for structured entity facts, Crunchbase for corporate context, GitHub for technical provenance, and independent evidence underneath all three for anything that genuinely matters to a reader's decision. None of them is a shortcut to being cited. Done honestly and kept in sync, together they reduce the ambiguity that stops a model from citing you at all, which is the only lever any of this actually pulls.
Pick one claim your project makes publicly right now and ask where the proof actually lives. If the honest answer is "our own website says so," that's your starting point. Contact Coinpresso for an off-site Web3 evidence audit if you'd rather have someone map the discrepancies before a reader, or a model, finds them first.
FAQs
Does every Web3 project need a Wikidata item?
No. Teams should respect notability, verifiability, and conflict-of-interest guidance before attempting to create one. Forcing an item that doesn't yet meet Wikidata's bar is likely to see it flagged or deleted, which does more damage to your credibility than having no item at all.
Is a Crunchbase profile proof that a project is legitimate?
No. It can provide consistent corporate context, legal name, funding history, founders, but material claims still need their own primary or independent evidence. A profile is only as reliable as what's behind it, and most of what's on it is self-reported.
Why does GitHub matter for a crypto brand?
A public repository can demonstrate code provenance, release history, and maintenance activity, provided it's clearly official and tied to the actual product. It's a useful companion to the credibility work covered in our crypto GEO guide, since observable activity is exactly the kind of evidence a model can corroborate on its own.
Should all three sites use identical text?
Use consistent core identifiers and facts across all three, but adapt the framing to the platform. Copying the same promotional paragraph into a structured entity record, a corporate profile, and a code repository strips out the context each one needs to be useful on its own.
Will this get a project cited by ChatGPT, Gemini, or Claude?
It may reduce ambiguity and improve corroboration, but citation depends on the prompt, the sources available at that moment, and model behavior that varies response to response. If you want a clearer read on where your project currently stands, our case studies show how that groundwork plays out for other teams.
