Every launchpad in Web3 claims to protect investors. The claims range from "rigorous due diligence" to "battle-tested vetting process" to vague references to "partnerships with leading security firms." Most of this is marketing. A relatively small number of platforms actually implement protections with teeth.
This post explains what real investor protection looks like in a launchpad context — and gives you a checklist for evaluating any platform you're considering participating on.
Why Most "Vetting" Is Insufficient
The baseline expectation most participants have is that a launchpad has reviewed the project before listing it. What they imagine is a thorough, independent review. What actually happens on many platforms is closer to a checklist confirmation: does the project have a whitepaper? Yes. Does it have a website? Yes. Did the team do a KYC? Yes. Approved.
That process takes less time than reading the whitepaper. It doesn't verify that the team's stated credentials are accurate. It doesn't review the smart contracts. It doesn't stress-test the tokenomics against reasonable market scenarios. And it definitely doesn't check whether the project's listed advisors are real participants or paid logos.
The incentive problem is significant: many launchpads earn their fees from project applications, not from participant returns. A platform that launches 200 projects a year captures far more in fees than one that launches 40. The economic incentive pushes toward volume, not quality. Understanding this helps explain why "vetted" often means very little.
Protections That Actually Matter
1. Independent Smart Contract Audits — Reviewed, Not Just Required
Requiring an audit is not the same as reviewing it. Any project with budget can purchase a report from a low-tier audit firm that generates minimal-scrutiny results. The meaningful protection comes from the launchpad's team actually reading the audit report, understanding what was found, verifying that critical and high-severity issues were remediated (not just acknowledged), and having technical staff capable of evaluating those claims.
Ask any launchpad you're considering: who on your team reviews audit reports? What's their smart contract security background? Can they identify a reentrancy vulnerability in FunC/Solidity? If the answer is vague, the audit requirement is theater.
2. Team Verification That Goes Beyond LinkedIn
Pseudonymous teams are a feature of Web3, not a bug — many legitimate builders prefer privacy. But when teams choose to present real identities, those identities should be verified. This means: cross-referencing stated credentials with public records, confirming previous employment or project involvement, checking whether listed advisors are actually engaged (not just logo farming), and running basic OSINT for regulatory or fraud history.
The question that reveals whether a launchpad does this seriously: "What happens when you discover a team member misrepresented their background?" The answer should be immediate rejection. If the answer is "we look at each case individually," that's a soft refusal to commit to standards.
3. Tokenomics Review With Real Constraints
A tokenomics review that "approves" any structure without constraints is not a review. Specific red flags that should disqualify or require significant modification:
- Team and advisor allocation above 25% combined with vesting under 12 months
- Investor (pre-sale VC) tokens unlocking at or before TGE at a price significantly below IDO price
- Circulating supply below 10% at TGE with no rationale for the long unlock schedule
- Token utility that is entirely speculative with no fee-generating or governance mechanism
- Emission schedule that would result in more than 50% supply unlock in the first 6 months
A launchpad that approves tokenomics fitting these descriptions is not protecting its participants — it's charging them for the privilege of being extraction targets.
4. Non-Custodial Fund Handling
Investor funds during an IDO should never pass through a launchpad-controlled wallet. The allocation should be executed by audited smart contracts that hold funds in escrow until TGE, at which point tokens are distributed and remaining funds are released to the project team — all on-chain, all verifiable.
Launchpads that collect participant funds into a platform wallet and then distribute manually introduce custodial risk that participants are often not aware of. If the platform is compromised — or simply dishonest — participants have no recourse. Non-custodial mechanics eliminate this risk at the structural level.
5. Locked Liquidity at TGE
A token launch without locked liquidity is a structured exit opportunity for insiders. Without a LP lock, project teams can remove DEX liquidity immediately after TGE — leaving participants holding tokens with no market to sell into. This is not a theoretical risk; it has happened repeatedly on platforms that don't require LP locks.
The minimum acceptable standard: LP seeded at TGE with a 12-month on-chain lock that cannot be unlocked by the project team. Participants should be able to verify the lock contract address independently.
6. KYC/AML for Participants
This is protective in a different sense — it protects participants from being co-mingled with bad actors in a token sale structure that could attract regulatory attention. It also prevents sophisticated attackers from creating multiple accounts to game allocation systems. KYC/AML is compliance infrastructure, but it's also practical participant protection.
The tradeoff is friction and privacy. KYC requirements exclude truly anonymous participation. For participants who value privacy above all else, this is a genuine cost. For participants who want to know that the person next to them in the allocation queue has been verified and is operating with a real identity, it's a meaningful assurance.
7. Post-Launch Accountability
What happens after TGE is where most launchpads disappear. The project is live, the fees are collected, and the relationship ends. This is the weakest point in most launchpad protection frameworks — the accountability structure evaporates at the moment when it would be most needed.
Meaningful post-launch protection includes: a defined incubation period with active engagement, public communication channels where project teams are accountable to participants, and a clear process for how the launchpad responds if a project team behaves badly after launch.
Questions to Ask Any Launchpad Before Participating
- Who on your team reviewed the smart contract audit, and what is their security background?
- Are funds during the IDO held in a smart contract or a platform wallet?
- Is LP liquidity locked at TGE? For how long? Can I verify the lock on-chain?
- What percentage of applications do you reject, and what are the most common rejection reasons?
- What is your process if a project team acts against participant interests after TGE?
- Can I see the audit report for this project's contracts?
A launchpad that can answer all of these questions specifically and in writing is operating at a different standard than one that deflects to general assurances.
Tonstarter was built with these questions in mind. Our vetting process, non-custodial mechanics, LP lock requirements, and 90-day post-launch incubation exist because we asked what actual protection looks like — and built toward that answer rather than toward the marketing version of it.
If you're a participant with questions about a specific project we've launched, reach out directly at [email protected].
