A public token sale goes well when real, distinct buyers get the allocation you intended, on terms they understood, and when the tokens reach them at a moment the market can absorb. It goes badly when one operator holding hundreds of wallets takes the allocation, when the process is a gas war, or when the claim opens before liquidity exists. Whether you run the sale on your own site or through a launchpad, most failures come from design and operations rather than from the token itself. Below are eight of the most common mistakes, each with the fix, followed by a pre-sale checklist.
Mistake 1: A Whitelist That Rewards Sybil Farms
Whitelists are meant to select a community. In practice, many reward whatever is cheapest to fake: following an account, joining a server, retweeting a post, or filling in a form. A single operator can complete those tasks across hundreds of wallets, and the "community" that wins allocation is mostly one person.
The cause is that the criteria measure effort that scales with automation, not with genuine interest. Every wallet that passes costs the farmer almost nothing and takes a slot from a real user.
The fix: Build criteria that are expensive to replicate and tied to behaviour you actually value. That can mean a verified identity check, a history of using your product or testnet, holding or staking something over a period of time, or contributing in ways that need human judgement. Keep the list of criteria short, publish it before applications open, and decide in advance how ties and borderline cases are handled.
Mistake 2: No or Weak Sybil and KYC Filtering
Even a well-designed whitelist leaks without enforcement. Teams often collect applications, then do little to check them: no deduplication across wallets, no review of clusters funded from the same source, no identity step. The result is that token sale sybil protection exists on paper only.
The fix: Treat filtering as a pipeline with several layers, not a single gate. Typical layers include identity verification where it is appropriate for your sale, deduplication of applicants, on-chain review of wallets that share funding sources or move in lockstep, and a manual review queue for flagged groups. Be clear in your terms that allocations tied to duplicated or coordinated accounts can be cancelled and refunded. No filter is perfect, so plan for a small appeal process and a way to reverse a bad call before tokens are distributed.
Mistake 3: Per-Wallet Caps That Are Bypassed or Meaningless
A per-wallet cap is the simplest tool for spreading allocation. It also fails in two opposite ways. Set it per address with no identity link, and one participant simply splits funds across many addresses. Set it so low that the sale cannot fill, or so high that a few buyers take most of it, and the cap no longer shapes anything.
The fix: Make the cap apply to a verified participant, not to a raw address. Decide what you want the distribution to look like first (many small holders, a mix of tiers, a floor for committed supporters) and then set caps that produce it. If you use tiers, publish how each tier is earned and what each tier can buy. Check the maths before launch: if every eligible person bought the maximum, how much would you raise, and is that the outcome you want?
Mistake 4: First-Come-First-Served Gas Wars
A pure first-come-first-served sale rewards bots, private mempool access and whoever pays the most in fees. Ordinary buyers lose, the network congests, and the people who needed the tokens least often get the most. Support channels then fill with people asking why a transaction failed.
The fix: Remove speed as the deciding factor. Common alternatives are a lottery among eligible participants, pro-rata allocation where everyone commits and receives a proportional share, and overflow designs where oversubscribed funds are returned. Each has trade-offs in fairness, simplicity and how clearly price is discovered. Our comparison of LBP, fixed-price and Dutch auction token sales walks through how those mechanisms differ so you can pick one that fits your goals.
Mistake 5: Unclear Refund and Overflow Terms
If demand exceeds the allocation, someone gets refunded, and someone has to decide when and how. Teams frequently leave this vague. Buyers do not know whether unused funds come back automatically, how long that takes, whether fees are deducted, or what happens if the sale is cancelled. Vague terms turn a normal oversubscription into a trust problem.
The fix: Write the refund and overflow rules in plain language and publish them before the sale opens. Cover the calculation for oversubscription, the timing of returns, who pays transaction costs, and what triggers a cancellation. Where possible, automate refunds in the contract or platform so that people are not relying on a manual promise. Then follow the rules exactly as written.
Mistake 6: Handling Geo-Restriction and Eligibility Carelessly
Selling tokens to the public raises eligibility questions: which jurisdictions can participate, what buyers must confirm, and what you are allowed to say in your marketing. Teams sometimes treat this as a checkbox, add a vague disclaimer, and rely on a self-declaration that nothing enforces. Others copy terms from another project without understanding whether they fit.
The fix: Involve qualified legal counsel early, and do it before you design the sale rather than after. Counsel can advise on eligibility rules, restricted regions, required disclosures and how your communications should be worded. Operationally, make sure the rules you publish match what your tools actually enforce, so that your terms and your behaviour agree. This article is general information, not legal advice, and the right approach depends on your structure and where you operate.
Mistake 7: Claim Timing That Ignores Listing and Liquidity
Many teams treat the claim as a separate event from the listing. Buyers claim tokens before any venue is live, before market maker inventory is in place, or before depth exists to absorb sales. Alternatively, listing goes live and the claim is delayed, so early traders have nothing to anchor on. Both produce thin books and sharp moves.
A related problem is the gap between the sale price and the opening market price. If participants hold tokens bought well below where the market opens, selling pressure arrives the moment the claim does. Our guide on how to set a token listing price covers how to think about that relationship.
The fix: Plan the claim, the unlock schedule and the listing as one sequence with a single owner. Confirm that pools or order books are funded and quoting before tokens become transferable, and agree the order of events in advance with your launchpad if you use one. Consider unlock schedules that spread supply over time instead of releasing it all at once, and be honest with participants about when they can expect to claim and trade.
Mistake 8: Sale Proceeds Landing in a Single-Signer Wallet
After a successful sale, a large amount of value sits in one place. When that place is a wallet controlled by one person, the project carries a single point of failure: one lost key, one compromised laptop, or one person leaving the team can put the whole raise at risk. It also looks bad to buyers who are watching the address.
The fix: Route proceeds directly to a multi-signature wallet with signers, thresholds and recovery procedures decided before the sale. Use a separate, clearly labelled address for sale funds so that anyone can track them, and document who approves spending and how. Our multisig treasury setup checklist goes through signer selection, thresholds and operating rules in detail.
Communicating Results Is Part of the Sale
One more point cuts across all eight: communicate results clearly. People who applied and received nothing, or less than they expected, will assume the process was unfair unless you explain it. Publish the outcome criteria, the number of participants, how filtering worked at a high level, and the timeline for refunds and claims. A short, factual post on the day results are final prevents weeks of rumours.
Pre-Sale Checklist
- Whitelist criteria are published, hard to automate and tied to real engagement
- Sybil and identity filtering has several layers, with a review and appeal process
- Caps apply per verified participant and produce the distribution you intend
- Allocation method does not depend on speed or gas bidding
- Refund, overflow and cancellation terms are written, published and automated where possible
- Eligibility rules were reviewed by legal counsel and match what your tools enforce
- Claim, unlock and listing form one sequence, and liquidity is ready before tokens move
- Sale proceeds go to a multisig, with signers and thresholds agreed in advance
- A results announcement and support plan are prepared before the sale opens
Plan the Sale With the Listing in Mind
A public sale is not a standalone event. It decides who holds your token on day one, how much supply arrives at once, and how the first hours of trading feel. Fibonacci Capital works with teams on the liquidity side of that moment, from planning inventory and depth ahead of the claim to quoting through the first days of trading. If you want to talk through your sale design and launch plan, get in touch.