# Web3 project reputation: what to control, in what order

Web3 project reputation is collective: official surfaces, impersonators, audits, moderation and AI answers. Who owns each, and the order to fix them.

---


Web3 project reputation is the shared picture that users, auditors, partners, journalists and AI assistants hold of a protocol, DAO, token or app, and unlike a company's reputation it has no single owner. It is built from the project's official surfaces, from everything people say and link in its name, and from the evidence the project leaves behind: audits, disclosures, governance records and how its community behaves under pressure.

The difficulty is structural. A company has a communications team and a legal entity that can sign a complaint. A project often has a core team, a foundation or none, a multisig, a Discord with volunteer moderators, a documentation site, three social accounts and a domain registered by someone who left a year ago. When a fake link circulates or an answer engine repeats a wrong claim, nobody is clearly responsible, so nobody acts for days. Most of the damage in these cases comes from that delay, not from the original problem.

This guide is about the project as a whole. It covers the map of surfaces and who should own each, how impersonation and scam links are contained, what audits and disclosures do for trust and what they cannot do, how moderation becomes part of the record, and how search engines and AI assistants end up describing the project. It says nothing about prices, tokens as investments or any named project. Rules and policies are described as the pages read for this guide state them, and they change, so read the source before you act. This is information, not legal advice.

<div class="box"><b>The short version</b>
<ul><li>A project's reputation is a record you publish and maintain, not a mood. One page that lists every official domain, account, contract address and contact is the base of everything else.</li><li>Every surface needs a named owner, a second person with access and a written rule for who may speak for the project. Unowned surfaces are where fakes and stale claims take root.</li><li>Impersonation is contained by speed and by being easy to verify: a canonical list, a fast reporting path and a community that knows what you will never ask for.</li><li>Audits, disclosures and governance records earn trust only when they are dated, complete and honest about limits. Search engines and AI assistants repeat what is easiest to find, so make the accurate record the easiest thing to find.</li></ul></div>

## Why a project's reputation behaves differently from a company's

A project's reputation is collective, public and permanent in layers, and each of the three properties changes the work. It is collective because many people speak in its name: contributors, moderators, ambassadors, integrators and token holders. It is public because the code, the governance votes and the treasury movements are readable by anyone. It is permanent in layers because some records can be edited (a web page, a help article) and others cannot (a transaction, a vote), so the correct response differs by layer.

That produces four failure patterns that a conventional brand guide does not cover. The first is unowned surfaces: an old documentation subdomain, a forgotten social account, a registry entry nobody maintains. The second is spoken-for authority: a volunteer or contributor says something that sounds official, and it is quoted as the project's position. The third is lookalike substitution, where a link or account that appears official collects trust meant for the real thing. The fourth is stale proof: an audit report or risk statement from an earlier version of the code that is still the first thing found.

A founder's personal reputation, a full takedown playbook for cloned websites and the privacy of individual wallets are separate subjects. This guide touches them only where they change what a project should do: it tells you to prepare for impersonation, not how to run a takedown, and it treats the founder as one surface among many.

## The surface map: who owns what, and what each one tells a visitor

Start with an inventory, because the first useful fact about a project is how many places claim to be it. The table below is a working template from practice, not an official standard. For each surface it asks who owns it, what a visitor concludes from it and what the usual failure is.

<div class="tablewrap"><table><thead><tr><th>Surface</th><th>What visitors conclude</th><th>Usual failure</th><th>Owner should be</th></tr></thead><tbody>
<tr><td><strong>Main domain and docs</strong></td><td>The authoritative description of what the project is</td><td>Stale pages, expired subdomains, a registrant who left</td><td>Named lead plus a second admin</td></tr>
<tr><td><strong>Contract and registry listings</strong></td><td>Which addresses are the real ones</td><td>Old deployments still listed as current</td><td>Engineering lead</td></tr>
<tr><td><strong>Social accounts</strong></td><td>Whether the team is active and reachable</td><td>Shared logins, no recovery path, unlabeled secondary accounts</td><td>Communications owner</td></tr>
<tr><td><strong>Community chat</strong></td><td>How the project treats people who ask for help</td><td>Impersonating support staff, unmoderated links</td><td>Moderation lead</td></tr>
<tr><td><strong>Audit and security pages</strong></td><td>How seriously risk is taken</td><td>Reports for old versions, no scope statement</td><td>Security lead</td></tr>
<tr><td><strong>Governance forum</strong></td><td>Who decides, and whether decisions are traceable</td><td>Disputes with no outcome recorded</td><td>Governance steward</td></tr>
<tr><td><strong>Name and identity records</strong></td><td>Whether a name or address is official</td><td>Lookalike names, a team member's personal profile used as proof</td><td>Whoever controls the project wallet</td></tr>
<tr><td><strong>Third-party listings and answers</strong></td><td>What strangers say the project is</td><td>Outdated descriptions, copied scam warnings</td><td>Communications owner</td></tr>
</tbody></table></div>

Two rules make the table useful: every surface has two people with access, and every surface appears on the canonical page described next. A surface on neither list is the first candidate for impersonation, because a visitor cannot tell it from a fake.

## The canonical page: the single record everything else points to

The most valuable reputation asset a project can publish is a page on its own domain that lists every official domain, social account, contract address, support channel and contact method, with the date it was last reviewed. It answers the question that every scam exploits: how does a stranger know this is real.

Three details make it work. The page is short, plain text first, with no scripts needed to read it. It states what the project will never do, for example that staff do not message first to ask for recovery phrases or to move funds, and that support is only given in named public channels. And it is linked from every official surface, in the same words, so that a visitor who starts anywhere can reach the same list.

Search engines and AI assistants then have a clear source to repeat. A project without one leaves the answer to whichever third-party listing was indexed first.

Keep it separate from marketing copy: a short list of named editors, every change dated. If your project has onchain name records, point them at the same list. The [ENS documentation on primary names](https://docs.ens.domains/web/reverse/) describes a two-way relationship: the name must resolve forward to the same address, and a lookup from the address must resolve back to the name. If the two do not match, an app should show the address, not the name. A name is therefore only a proof of identity when both directions agree.

## Impersonation and scam links: contain by speed and verifiability

Impersonation of a project falls into a small number of patterns: a lookalike domain, a fake account that replies under official posts, a fake support agent in chat, a counterfeit contract or listing, and an advertisement that sends people to a page that is not yours. The US Federal Trade Commission's consumer advice on [cryptocurrency and scams](https://consumer.ftc.gov/articles/what-know-about-cryptocurrency-scams) is the neutral place to send users. It lists impersonation scams, fake coins and tokens and investment scams, and says that cryptocurrency payments typically are not reversible and carry no legal protections. It names where to report: the FTC, the CFTC, the SEC, the FBI's IC3 and the exchange used.

A project cannot stop impersonation. It can shorten how long a fake works, and that depends on five things.

1. **Publish what you will never ask.** If the community knows that no genuine staff member asks for a recovery phrase or a transfer, the most damaging scams fail on a known rule.
2. **Make the real thing easy to verify.** The canonical page, a pinned notice in each official channel and a consistent naming style reduce the chance that a lookalike passes.
3. **Have a reporting path that takes minutes.** One monitored address or form, a named responder and a short template with the evidence the platforms ask for.
4. **Pre-agree who can file.** A DAO with no legal entity cannot sign a trademark complaint or a registrar form. Decide in advance which party, usually a foundation or a service provider with authority from a governance vote, files on the project's behalf.
5. **Tell users once, plainly, and keep it up.** A warning that names the fake address and points to the canonical page, pinned where users look, beats repeated alarm.

Search engines treat deceptive pages under their own rules. Google's Search Central documents [social engineering content](https://developers.google.com/search/docs/monitor-debug/security/social-engineering) as pages that trick visitors into doing something dangerous, either by pretending to be a trusted entity or by asking for what only a trusted entity would get. The page is written for owners of flagged sites, not for victims of a fake, so it does not give a route for reporting a lookalike. It does matter to you in one way: if your own site or ads are flagged, it says to check Search Console, remove the deceptive content and request a review, which can take several days. Browser warnings and search removals take time and are not in your control; a project that has the canonical page and an alert community is protected during that gap.

<aside class="callout">
<span class="callout-label">Limit</span>
<h4>Reporting a fake removes a page, not the harm already done</h4>
<p>A takedown stops new visitors. It does not restore funds a user already sent, and it does not stop the same fake reappearing at a new address. Plan for repetition, and put effort into what makes the next one fail faster.</p>
</aside>

## Audits and disclosures: what builds trust and what cannot

An audit is a snapshot of specific code at a specific time, reviewed within a stated scope. For reputation, its value is the record it leaves: who reviewed what, which findings were raised, which were fixed and which were accepted. Its limits are as important as its findings, and a project that publishes the limits is more believable than one that publishes only a badge.

A trustworthy audit page has five parts. It names the version reviewed and the date. It states what was in scope and what was not. It lists findings with their status. It links to the full report, not a summary. And it says plainly when the deployed code has changed since the review. 

Disclosures work the same way. A plain statement of who controls upgrade keys, how the multisig is composed, what the treasury policy is and how vulnerability reports are handled is read by auditors, integrators and journalists first. A project that hides this information usually gets it described by others, less accurately.

On regulatory status, be careful. The US Securities and Exchange Commission has published staff statements on crypto assets, including a February 2025 statement by its Division of Corporation Finance on [meme coins](https://www.sec.gov/newsroom/speeches-statements/staff-statement-meme-coins). That statement gives the staff's view on a defined kind of coin, says it is not a Commission rule and has no legal force, and excludes coins that use the label to disguise a security. This article takes no position on how any asset is treated. Whether something is a security depends on facts and law that vary by country, and your counsel decides what a project may say. What a reputation guide can say is that public statements about returns, safety or regulatory status should be reviewed by counsel, written conservatively and kept consistent across every surface.

<aside class="callout">
<span class="callout-label">Rule</span>
<h4>Never publish a safety claim you cannot date and scope</h4>
<p>"Audited" without a version, a date and a scope is a claim a reader cannot check. It is also the sentence that is quoted back when something goes wrong.</p>
</aside>

## Moderation and governance records are part of the public record

For many users the project is its community, and the community is read through moderation. A scam link left up for an hour, a support question ignored, or a volunteer moderator who banned someone for a fair criticism all become screenshots, and screenshots are what reviewers and journalists cite. Moderation is therefore a reputation function, not housekeeping.

Four decisions turn it into an asset. First, a written code of conduct and a posted statement of what moderators may and may not do, so that a ban can be explained by a rule. Second, a rule about links: new accounts cannot post links, and links to financial actions are removed on sight. Third, a clear distinction between staff, moderators and volunteers, shown by labels and a posted list, so that nobody can borrow authority. Fourth, an appeal path, because fair criticism that is removed without reply grows into a story about censorship, and fair criticism answered calmly rarely does.

Treat accurate criticism as information. A pattern of complaints about withdrawals or delays should be investigated and answered publicly, not deleted. Deleting what is false, abusive or a scam is different, and should follow written rules with the removal logged.

### Governance records: say who can speak, and keep the outcome

Governance forums are the project's own minutes, and their failure mode is silence: a dispute with no recorded outcome, which a reader fills with the worst version. Write a short speaking policy, approved through whatever process the project uses. It states who may make statements on behalf of the project, who may speak about security incidents, who may speak to journalists and who may file legal or platform complaints. Contributors may share their own views if they say so. When an incident occurs, this is what lets the project respond in an hour instead of arguing over who is allowed to.

For a DAO, add the legal question early. If no entity can hold a domain, sign a complaint or retain a lawyer, decide who does so on the project's behalf and on what authority. The answer depends on the structure and the countries involved and belongs with the project's own counsel.

## What search engines and AI assistants say about the project

Search results and AI answers are where all the other surfaces get summarized. When someone types the project's name, the first page usually shows the main domain, documentation, social accounts, a listing or two, news coverage and any scam warnings. An assistant then draws on a similar pool and may blend it with older or lower-quality pages. If the pool is dominated by third-party summaries, the answer reflects those.

The working method has four steps.

<figure class="fig">
<figcaption><b>Auditing what the web says about a project</b></figcaption>
<ol class="fig-steps">
<li><b>Search the name and the common variants</b>Use the project name, its ticker or short name, and the words people add: official, support, airdrop, scam, review. Record what appears on page one and who owns each result.</li>
<li><b>Ask several assistants the questions a stranger would ask</b>Ask what the project is, whether the official site is a given address, who runs it and whether it is safe. Save the answers with the date and the assistant used.</li>
<li><b>Mark each error by cause</b>Trace each wrong statement to the page it came from: a stale listing, a copied warning, a confused name or an unsupported claim.</li>
<li><b>Fix the source, not the symptom</b>Update what you control, ask the owner of a third-party page to correct it with evidence, and strengthen the canonical page so it becomes the clearest source.</li>
</ol>
</figure>

A wrong assistant answer is rarely fixed at the assistant; it is fixed in the pages the assistant draws from. Our [AI search reputation service](/ai-search-reputation) exists for projects that want this audit run and repeated, and the same method applies if you do it yourself.

## A decision table: which problem needs which move

Different problems call for different routes. The table below matches common situations to the first move, who acts and the main risk. It is a planning aid, not a promise of any outcome.

<div class="tablewrap"><table><thead><tr><th>Situation</th><th>First move</th><th>Who acts</th><th>Main risk</th></tr></thead><tbody>
<tr><td><strong>Lookalike domain collecting wallet connections</strong></td><td>Warn users, then report to registrar, host and browser</td><td>Foundation or service provider</td><td>Slow takedown, quick reappearance</td></tr>
<tr><td><strong>Fake support agent in chat</strong></td><td>Remove the account, post the never-ask rule</td><td>Moderation lead</td><td>Users already contacted</td></tr>
<tr><td><strong>Old audit shown as current</strong></td><td>Add version and date, publish current scope</td><td>Security lead</td><td>Looks like concealment if done silently</td></tr>
<tr><td><strong>Wrong AI answer about the project</strong></td><td>Find the source page, correct it, strengthen the canonical page</td><td>Communications owner</td><td>Assistants may repeat the error for a while</td></tr>
<tr><td><strong>Accurate criticism going viral</strong></td><td>Answer the substance publicly and log the outcome</td><td>Named spokesperson</td><td>Deleting it creates a second story</td></tr>
<tr><td><strong>Volunteer speaks as the project</strong></td><td>Clarify roles, publish the speaking policy</td><td>Governance steward</td><td>Public disagreement with a volunteer</td></tr>
<tr><td><strong>Stale listing on a third-party site</strong></td><td>Ask the owner to update, with evidence</td><td>Communications owner</td><td>No response; the page may stay</td></tr>
</tbody></table></div>

## A worked scenario: a small protocol with three owners and one fake

This is an invented scenario with generic parties and stated assumptions, not a real case. A small lending-style protocol has a core team of five, a foundation that holds the domain, and a volunteer-run chat. The assumptions are: the documentation site lists two contract versions without saying which is live; one team member registered the main domain personally; and the chat has no link rule.

A lookalike domain appears and a fake support account contacts users in the chat. Because nobody owns reporting, the first warning appears after several hours, and it names no address. An assistant asked about the project's official site gives a mixed answer, because a third-party listing carries the older address.

What the project does, in order. It transfers the domain to the foundation and adds a second admin. It publishes the canonical page with the live contract version, the fake domain named once, the never-ask rule and a dated review. It turns on a link rule for new chat accounts and removes the fake account. The foundation, with authority from a governance vote it holds for this purpose, files with the registrar and host and reports the page through the search engine's reporting channel. The communications owner asks the third-party listing to update its address and attaches the canonical page as evidence.

What it cannot do: reverse any payment a user already made, or promise that the fake will not return. What it can do is make the next attempt shorter and make the answer to "what is official" the same everywhere. A review a month later repeats the search and assistant checks to see whether the old address still appears.

## A realistic timeline: ninety days from scattered to maintained

Most projects can move from scattered to maintained in about three months, though the pace depends on how many people hold keys and how many surfaces are unowned. The table gives a usual sequence, not a guarantee.

<div class="tablewrap"><table><thead><tr><th>Period</th><th>Work</th><th>Result</th></tr></thead><tbody>
<tr><td><strong>Days 1 to 7</strong></td><td>Inventory every surface, owner and admin; secure shared logins</td><td>One list, two admins per surface</td></tr>
<tr><td><strong>Weeks 2 to 3</strong></td><td>Publish the canonical page; link it from every channel</td><td>One record to point to</td></tr>
<tr><td><strong>Weeks 3 to 5</strong></td><td>Write the speaking policy, moderation rules and reporting path</td><td>Responses that do not wait for permission</td></tr>
<tr><td><strong>Weeks 5 to 8</strong></td><td>Bring audit and disclosure pages up to a dated, scoped standard</td><td>A security story that can be checked</td></tr>
<tr><td><strong>Weeks 8 to 12</strong></td><td>Run the search and assistant audit, correct sources, repeat monthly</td><td>Answers that match the record</td></tr>
</tbody></table></div>

Search results and assistant answers usually take weeks to reflect changes. Plan the first review a month after your updates.

## Your next step: one inventory, two admins, one page

List every surface, name an owner and a second admin for each, and publish the canonical page, before any campaign or statement. If a fake is already live, do this in the same week and run reporting in parallel.

<div class="box hot"><b>If this is happening to you now</b>
<p>If a fake is live, a wrong answer is spreading or you cannot tell who controls your surfaces, start with an inventory and a private review of what search engines and AI assistants show today. A private audit with Reputation Partners covers what is visible, who owns each surface and which problems come first. Request one at <a href="/audit">our private audit page</a>.</p></div>

Reputation Partners works on how accurate information appears in search engines and AI answers, and does not promise removal. For a project, the lasting work is the record you keep: a short list of official facts, maintained by named people and repeated in the places that matter. Monitoring that record month by month is the part most teams drop, and it is what [reputation monitoring](/reputation-monitoring) is for.

## Questions people ask

### How is a project's reputation different from its founder's?

A founder's reputation is a person's: biography, press, past roles and personal accounts. A project's reputation is collective and sits in its official surfaces, its audits and disclosures, its community behavior and the answers assistants give about it. They overlap because people check founders when they check projects, but they are fixed by different work, and a project should not rely on a founder's profile as proof of legitimacy.

### Who should file takedown requests if the project is a DAO?

Someone with legal standing must file, because registrars, hosts and platforms generally ask for a named complainant. Common choices are a foundation, a legal wrapper or a service provider acting under written authority from a governance vote. Decide this before an incident. The right structure depends on the countries involved, so the project's own counsel should settle it.

### Does an audit report protect a project's reputation?

It helps only when the report is dated, scoped, tied to the code version in use and shown in full. An audit is a snapshot, not a guarantee of safety. Readers trust projects that state what the audit did not cover and keep the page current, and they distrust a badge with no version, no date and no list of findings.

### Should we delete negative comments in our community channels?

Delete scams, abuse and clearly false claims, following written rules, and log what you removed. Do not delete accurate criticism. Answer it with facts and record the outcome. Removing fair complaints tends to produce a second, larger story about censorship, and it removes information the team needs about real problems.

### Why does an AI assistant give the wrong official site for our project?

Assistants draw on pages that are easy to find and widely repeated, and a stale third-party listing can outweigh your own page. Trace the wrong answer to the source page, ask its owner to correct it, and make your canonical page clear, dated and linked from every official surface. Changes usually take weeks to appear, and some sources never update.

### Can a project make sure users are never scammed in its name?

No. A project can make fakes harder to pass and quicker to remove by publishing a canonical list, stating what staff will never ask, moderating links and keeping a fast reporting path. It cannot prevent others from creating lookalikes or reverse payments already sent. Be honest about that limit in public statements, and point users to the FTC's consumer scam guidance.