The strongest crypto project announcement is not a pitch. It is a falsifiable evidence package with a product attached.
A logo, a token ticker, a roadmap graphic, and a list of partners are cheap signals. A legitimate project should compete on something harder to imitate: making its claims, dependencies, privileges, incentives, and failure conditions easy for a skeptical stranger to verify.
What must be true? A reader should be able to distinguish what exists today from what is promised, identify who controls the system, and reproduce the core evidence without requesting private access.
Why now? Launch tooling has reduced the cost of deploying tokens, interfaces, and polished narratives. The disclosure burden should therefore rise, not fall.
What is the moat? Not the announcement itself. The moat is a versioned record of shipping what was promised, correcting errors promptly, and reducing privileged control over time.
Why does a token need to exist? The project must identify a function that cannot be performed as well by ordinary software, an existing asset, or a simple payment method.
What would falsify this view? If evidence-complete introductions produce no better record of accurate claims, disclosed controls, and timely corrections than ordinary promotional posts, the template is bureaucracy rather than signal.
The contrarian rule: launch with liabilities, not adjectives
Every material statement should carry one of five visible states:
- Live and independently verifiable
- Live, but reported only by the project
- Planned, with a target window and acceptance test
- Not applicable, with a reason
- Not disclosed
Missing information must remain visible. A team should not delete an inconvenient field, bury it in a chat channel, or replace it with “coming soon.” “Not disclosed” is a valid answer. It is also useful information.
This is a due diligence interface, not a legal safe harbor or a forum endorsement. Still, the separation is not arbitrary. The EU’s MiCA disclosure categories distinguish issuer identity, project participants, milestones, use of funds, offer terms, token functions, underlying technology, audit outcomes, and material risks. A forum introduction can be much shorter than a regulatory white paper while preserving that evidence-first logic.
Copy-paste project introduction template
1. Product in plain language
- Project in one sentence:
- Intended user:
- Problem being solved:
- How the product solves it:
- What a user can do today:
- What is not yet live:
- Networks or environments currently supported:
- One public test a new user can perform:
- What fails or becomes unnecessary if the blockchain component is removed:
Avoid category stacks such as “AI-powered omnichain RWA liquidity infrastructure.” Explain the action. Who deposits what, who receives what, what changes on-chain, and why is the result better than the non-crypto alternative?
A product description passes only when a technically literate outsider can restate it without using the project’s slogans.
2. Canonical official links
Provide direct links to:
- Main website
- Documentation
- Live application or public demo
- Source-code organization
- Contract explorers
- Governance forum and voting interface
- Status page
- Bug bounty
- Official announcement account
- Contact email
- Legal terms and privacy policy, where applicable
Name one canonical domain and the official accounts authorized to announce contract migrations, security incidents, token changes, or fundraising. Do not use link shorteners for contract addresses or security reports.
3. Product evidence
State:
- Mainnet, testnet, private beta, or design stage
- First public release date
- Current release identifier
- Public usage metrics, including calculation method and date range
- Known dependencies on third-party RPCs, bridges, oracles, custodians, sequencers, cloud services, or data providers
- A reproducible transaction, query, or workflow demonstrating the core product
- Any material component that remains manual, permissioned, subsidized, or simulated
Do not present testnet activity as mainnet adoption, gross transaction volume as revenue, wallet addresses as users, or incentives as organic demand without labeling the distinction.
4. Team, entity, and conflicts
Disclose:
- Operating entity, jurisdiction, and registration status, if one exists
- Team members or durable pseudonyms, roles, and relevant prior work
- Which contributors are employees, contractors, advisors, investors, or service providers
- Material related-party relationships
- Team members who control treasury, upgrades, deployments, social accounts, or governance delegation
- Publicly announced investors and strategic partners
- Any compensation received for endorsements, liquidity provision, listings, or integrations
Anonymity is not automatic evidence of fraud. Unverifiable authority is the real problem. A pseudonymous team can still disclose role continuity, signing structure, conflicts, repositories, contract powers, and a record of previous work. The more power an unidentified person holds, the stronger the compensating controls should be.
5. Code and repositories
Provide:
- Repository links
- License
- Production release tag or commit
- Build and test instructions
- Deployment scripts
- List of critical closed-source components
- Material forks and upstream dependencies
- Process for reporting vulnerabilities
- Explanation of how the public repository maps to the deployed product
A repository containing a token interface, an old prototype, or code unrelated to production is not meaningful proof. State precisely which commit produced the deployed contracts and which services cannot be reproduced publicly.
6. Contracts and administrative powers
For every material contract, list:
- Chain and network
- Contract purpose
- Address in copyable text
- Deployment transaction
- Source verification status
- Proxy, implementation, beacon, and admin addresses, where applicable
- Owner or controlling role
- Multisig threshold and signer categories
- Timelock and minimum delay
- Pause, upgrade, mint, burn, blacklist, seize, fee-change, oracle-change, bridge-change, and treasury-transfer powers
- Emergency procedure
- Conditions for reducing or removing each power
The Etherscan verification documentation describes verification as publishing source code for a deployed contract. That makes inspection possible, but it is not itself a security opinion.
For EVM proxy systems, list the proxy and implementation separately. The ERC-1967 proxy standard defines storage slots that allow tools to identify implementation and admin information. Saying “the contract is verified” while omitting the upgrade path leaves the most important control question unanswered.
“Ownership renounced” is not a complete answer. State whether any other contract, guardian, role, beacon, governance module, oracle, bridge, or off-chain signer can still alter outcomes.
7. Token necessity, supply, and distribution
First state one of these:
- No token exists and none is planned
- A token is planned but not issued
- A token exists but is not required to use the product
- A token exists and is functionally required
Then disclose:
- Chain, symbol, and canonical contract address
- Current function
- Rights granted and rights explicitly not granted
- Why an existing asset or ordinary database entry is insufficient
- Maximum supply, current supply, and initial circulating supply
- Inflation, burns, rebases, or other supply-change rules
- Allocation by category, totaling 100 percent
- Recipient groups within broad allocation categories
- Vesting, cliffs, unlock dates, and acceleration rights
- Treasury allocation and decision process
- Market-maker inventory, loan terms, and return obligations
- Liquidity arrangements
- Fee flows and who receives them
- Conditions under which the token thesis would be abandoned
No projected price, guaranteed yield, implied listing, or “number goes up” logic belongs in a project introduction. If the token’s only defensible function is fundraising before product-market fit, say so plainly.
8. Funding and treasury
Disclose:
- Total external funding raised
- Round dates
- Equity, token, warrant, grant, debt, or mixed instrument
- Publicly named investors
- Material preferential token, governance, liquidation, information, or unlock rights
- Public-sale proceeds
- Intended use of funds
- Treasury custody structure
- Current runway as a range, if disclosed
- Revenue today, clearly separated from token sales, grants, and incentive emissions
A project does not need to publish sensitive bank details. It does need to reveal who financed it, what claims those funders received, and whether insiders can exit before the system reaches the milestones marketed to the public.
9. Security evidence
For every audit, provide:
- Auditor
- Report link
- Date
- Scope
- Commit hash
- Contracts excluded from scope
- Findings by severity
- Unresolved findings and accepted risks
- Material code changes after the audit
- Retest status
Also disclose active bug bounties, incident history, monitoring, emergency contacts, and post-mortem policy. “Audited” without a report, scope, commit, and unresolved-issue list is branding.
The OWASP smart contract risk taxonomy can help structure technical risks such as access control, business logic, oracle manipulation, input validation, unsafe external calls, arithmetic errors, reentrancy, and upgradeability. It is a checklist aid, not a substitute for system-specific analysis.
10. Roadmap with acceptance tests
For each milestone, state:
- Deliverable
- Target window
- Public acceptance test
- Critical dependency
- Responsible function or team
- Funding or governance dependency
- Consequence of delay or failure
Replace “launch governance” with a measurable outcome such as: deploy the voting contracts, publish the addresses, transfer the named powers, activate a stated quorum, and execute one public test proposal.
Separate committed work from experiments. A roadmap is not a promise that uncertainty has disappeared. It is a declaration of how progress and failure will be observed.
11. Material risks and kill conditions
List the most material risks across:
- Smart-contract and infrastructure failure
- Admin-key or governance capture
- Oracle, bridge, sequencer, validator, or custodian dependence
- Liquidity and market-making failure
- Regulatory or legal restrictions
- Treasury exhaustion
- Incentive-dependent demand
- Token concentration and unlock pressure
- Key-person dependence
- Inability to reach sustainable revenue or usage
For each risk, provide the trigger, likely impact, mitigation, and observable warning signal.
Then state three kill conditions: events that would invalidate the product thesis, token thesis, security model, or business model. A credible launch explains not only how it wins, but how observers will know it is losing.
12. Update and correction schedule
State:
- Regular update cadence
- Location of the canonical changelog
- Events that trigger an immediate update
- Maximum time for correcting a material error
- Policy for contract migrations and deprecated addresses
- Policy for publishing incidents and post-mortems
- Date when the introduction becomes stale if no update appears
Material changes should edit the original post and add a dated changelog entry rather than silently rewriting history. MiCA similarly requires modified disclosure when a significant new factor, material mistake, or material inaccuracy could affect assessment of the asset.
How the forum should reward evidence
The forum should not certify that a project is legitimate. It should classify the quality and freshness of its disclosure.
- Evidence complete: Every mandatory field is answered, with direct proof where proof can reasonably exist.
- Partial disclosure: The project is understandable, but one or more material fields remain unsupported or undisclosed.
- Promotion without proof: The post relies mainly on claims, slogans, partnerships, or future plans.
- Stale disclosure: The project missed its own update schedule or materially changed without updating the introduction.
Completeness is not truth. A complete post can still contain false claims. The advantage is that false claims become specific, timestamped, and testable. That is a better starting point for scrutiny than a narrative that can change shape after every objection.
Projects should be rewarded for correcting errors visibly, not punished for every revision. The behavior to discourage is silent mutation, selective deletion, and pretending that a changed contract, allocation, or control structure was always disclosed.
Primary research question
Across project introductions posted over 12 months, does requiring a complete contract-control section before promotional claims reduce the 90-day rate of material corrections, undisclosed privileged roles, or contract-address replacements compared with introductions allowed to omit that section?
A forum could test this by coding disclosure completeness at publication, then recording corrections, privilege discoveries, address changes, missed updates, and security incidents. The thesis gains support only if structured evidence predicts fewer surprises or materially faster correction.
Falsification conditions
This template should be revised or abandoned if:
- Completion becomes boilerplate that does not improve independent verification
- Projects marked evidence complete show the same rate of hidden controls and material corrections as promotional posts
- Readers cannot reproduce the evidence without privileged access
- The burden systematically excludes credible early-stage builders while failing to deter deceptive teams
- Update compliance provides no useful signal about operational discipline
The goal is not to make every project look trustworthy. The goal is to make trust unnecessary where evidence can do the work, and visibly conditional where it cannot.