TL;DR
Fair allocation in an oversubscribed token sale comes from rules set before the sale opens. Projects should first define the holder base they want after TGE. That goal then drives the allocation method. Fill-from-the-bottom or a capped lottery spreads supply broadly, while capped pro-rata preserves larger committed buyers. Coinbase proved the first approach at scale when its Monad sale closed 1.47 times oversubscribed. Per-wallet caps, sybil-resistant priority tiers, and a dated refund procedure complete the rule set. Publishing these rules before the window opens, with worked examples, reduces post-sale disputes when demand exceeds supply.

Oversubscription is a trust event, not only a sales event. Buyers judge a token sale by how it divides tokens under pressure. That judgment starts before the sale opens, with the rules the team publishes.

What Does Oversubscription Mean in a Token Sale?

When a token sale receives more demand than supply, the allocation method a project chooses determines who becomes a holder and how concentrated the supply becomes. Oversubscription is a situation where buyers demand more tokens than a sale offers. For example, a $10 million sale receives $25 million in demand. This makes the sale 2.5x oversubscribed. If this happens, the project must decide who receives an allocation, how much each buyer gets, and who receives a refund.

Recent sales show how extreme this can get. According to Crypto Briefing, "MegaETH...completed its initial coin offering with nearly $1.4 billion in total bids, oversubscribed 27.8 times against its $50 million raise cap." Demand at this scale can arrive faster than most teams expect.

The allocation decision then shapes the holder base at launch. It decides how many wallets hold the token and how concentrated the supply becomes. It also gives an early picture of possible sell pressure after TGE.

Fair allocation matters because buyers screenshot fills and post results. A single unfair decision spreads instantly. A sale that favors whales or bots loses trust before the token even trades. Fairness can also be measured, not just claimed. Teams can track two signals. The first is how many buyers dispute their allocation after results. The second is how concentrated the holdings are at TGE. Careful allocation design keeps both numbers low. Without preset rules, teams improvise under pressure. Improvised decisions are usually the ones that trigger disputes. Disputes then eat up the launch window that should build momentum.

Oversubscription tests whether the project can execute fairly under pressure. Transparent allocation rules prevent post-launch controversies. Opaque rules invite disputes that derail momentum.

Which Allocation Methods Work for an Oversubscribed Sale?

Once demand exceeds supply, the next question is how to divide the tokens. A project that expects oversubscription needs to pick its allocation method before the sale opens. Five methods cover most public token sales. Each one favors a different type of buyer, so each one creates a different holder base.

No method is neutral. Pro-rata sounds fair because every buyer gets cut by the same percentage. In practice, whales still walk away with most of the tokens. First come, first served turns the sale into a race, and bots win races. A lottery gives everyone equal odds but ignores loyalty and past contribution.

In practice, each method has found its own territory. Pro-rata stays popular on public launchpads because it is simple to explain and cheap to compute. Fill-from-the-bottom is rare outside large exchanges, partly because processing a big contribution list costs more on-chain. Lotteries suit smaller rounds where holder count matters more than raise size. Tiered allocation fits projects that want to reward an existing user base. Pure first come, first served has fallen out of favor in professional sales. It invites gas wars, and it quietly rewards bots over real users.

This is why the choice is a distribution decision, not a technical detail. Whichever method the project picks, that method decides who the first holders of the token will be.

How Does Coinbase's Fill-From-the-Bottom Model Work?

According to Coinbase's official documentation, Coinbase answers the oversubscription problem with a model called fill-from-the-bottom. The idea is simple. Every buyer fills up at the same time, level by level, and the smallest requests complete first. The process works in five steps:

1. Buyers submit their requests during a fixed window of about one week.

2. Nothing is allocated during the window. Speed gives no advantage because the calculation only starts after the window closes.

3. The system finds the smallest unfilled request amount across all buyers.

4. It grants that amount to every buyer. It then repeats at the next smallest amount, raising every remaining request level by level.

5. It stops when the tokens run out. Small requests fill in full, the largest requests end at near-equal partial fills, and unfilled funds return to buyers.

Example scenario: a 2x oversubscribed sale
Supply: 10 million USDC → Total requests: 20 million USDC → Sale ends 2x oversubscribed

• 500 USDC request → filled in full → no refund needed

• 50,000 USDC request → filled in full → no refund needed

• 5 million USDC request → stopped at the final level → partial fill, unfilled USDC refunded

No buyer leaves with nothing. Large buyers end at near-equal partial fills instead of racing each other. The outcome is a token spread across many wallets instead of a few large ones.

Coinbase adds one more incentive on top of this model. According to Coinbase's token sales blog, "Users that sell their tokens shortly after they get listed (less than 30 days) may receive smaller allocations in subsequent sales. This is designed to prioritize access to a project's real users." This pushes tokens toward a project's real users instead of short-term flippers.

However, tThe Monad sale put this model under real pressure. According to Coinbase's token sales page, Monad's sale was 1.47x oversubscribed, with 276.05M USDC requested against 187.5M USDC available. Even at that level of demand, the structure still spread tokens widely instead of serving the biggest requests first.

The lesson here goes beyond one exchange. The fairness came from the design, not from the Coinbase brand. Any project can apply the same logic on its own sale. Founders weighing launch venues can compare how each one handles allocation in this public token sale platforms comparison.

How Allocation Logic Gets Built On-Chain

Allocation rules only work if they execute reliably. Most modern token sales automate allocation through smart contracts, removing manual decision-making and making every calculation auditable. The technical foundation shapes which allocation methods are practical and how fairly they actually perform.

1. Escrow and refund mechanics

A sale contract holds buyer contributions in escrow until the allocation calculation runs. Once the sale window closes and oversubscription is known, the contract executes the allocation formula against the full list of contributions. For fill-from-the-bottom, the contract raises every request to a shared fill level until supply runs out, then flags the largest requests as partial. For pro-rata, it calculates each wallet's proportional share and flags amounts exceeding that share for refund. The contract then releases allocated tokens to winners and refunds to losers in separate transactions to manage gas limits.

2. Refund automation prevents delays

Manual refunds introduce two problems. The process depends on human speed, and buyers wait in uncertainty. Automated refunds execute on a preset schedule, often within days of allocation results, without team intervention. This removes the trust gap. Sale-hosting platforms such as Saleium finalize allocations on-chain after the sale closes and keep excess funds withdrawable by the buyer. Contributors can then verify their refund against on-chain data instead of waiting for a team email. Gas cost is the tradeoff. Every refund is a transaction, and the total cost grows with the wallet count. Projects with large buyer lists often batch refunds or run the sale on a cheaper network to keep this manageable.

3. Sybil defense at the whitelist layer

Allocation fairness depends on one wallet per buyer. Without sybil defense, a single actor can create 100 wallets, split capital across them, and receive 100 allocations at max tier caps. This concentrated supply defeats fill-from-the-bottom and lottery methods entirely. Sale platforms defend through KYC checks, proof of prior product usage, or documented contribution history before a wallet enters the whitelist. These checks run before the sale opens, not during allocation, so the allocation formula only receives legitimate entries. The cost is time. Building and auditing a sybil-resistant whitelist takes weeks, not days, so it belongs early in the launch plan.

4. Gas cost and method choice

Some allocation methods are cheaper to execute on-chain than others. First-come-first-served requires minimal contract logic. The contract accepts valid transactions until the cap and rejects the rest. Pro-rata requires one calculation per contributor and storage of the final ratio. Fill-from-the-bottom requires sorting the entire contribution list, which is expensive on Ethereum but cheap on Layer 2s. Lottery requires random number generation, which introduces complexity and costs. For high-volume sales (10,000+ contributors), gas cost often tips the balance toward pro-rata or toward using a Layer 2 launchpad that batches transactions.

How Should a Project Choose Its Allocation Method?

Fill-from-the-bottom worked for Coinbase, but it is not the answer for every project. The right method depends on the holder base the project wants after TGE. In other words, allocation is a distribution tool first and a fundraising tool second. The table below maps each goal to its best-fit approach.

Below are the four most common post-TGE goals and the allocation approach that fits each one:

Governance goals belong in this decision too. A governance token needs many independent voters, so broad distribution helps. A project that needs deep, patient capital can accept more concentration with strict caps.

Market health after TGE matters as well. Thousands of small holders sell differently than a few large ones. Teams should model both scenarios before locking in a method.

How Should Buyer Caps, Priority Tiers, and Refunds Be Structured?

Choosing a method is only half of the allocation plan. The method still needs working rules around it. Three components complete it: buyer caps, priority tiers, and refund rules. Buyer caps set a floor and a ceiling for each wallet. Tiers decide who enters first or gets a higher limit. Refund rules decide how unfilled money goes back to buyers.

Each one protects the sale from a different failure. Without caps, one large buyer can take over the round. Without clear tier criteria, sybil actors can farm the sale with fake accounts. Without refund rules, buyers wait in the dark and trust collapses. All three must be fixed and published before the sale opens, not improvised during it.

1. Buyer caps

Buyer caps set a floor and a ceiling for each wallet. The minimum keeps out dust requests that only add admin work. The maximum stops one buyer from taking over the round.

Sizing starts from the target holder count. Picture a $5 million round that aims for 5,000 holders. The average ticket is $1,000. A minimum near $100 and a maximum near $10,000 keeps the round close to that target. Practical requirements include:

• Set the maximum buyer cap from the target holder count, not from revenue goals.

• Keep the minimum low enough for real community members to join.

• Publish both buyer caps in the sale terms before the window opens.

2. Priority tiers

Priority tiers decide who enters first or gets a higher buyer cap. Building them takes three steps. First, define two or three tiers at most. More tiers become hard to explain and defend. Second, set clear entry criteria for each tier. Strong criteria include completed KYC, prior product usage, and documented contributions. Third, attach one concrete benefit to each tier, such as earlier access or a higher buyer cap.

For example, Tier 1 can cover active product users and carry a doubled buyer cap. Tier 2 covers everyone else who passes KYC. Vague criteria invite sybil farming, where one actor pretends to be many buyers. This guide on building a token sale whitelist that filters real users, not sybils explains the setup.

3. Refunds

Refund rules decide how unfilled money returns to buyers. Setting them takes four decisions. Pick the refund currency, which should match the payment currency. Set a firm timeline, such as seven days after allocation results. Decide who pays the network fees. Then automate the flow, so refunds do not depend on manual work.

One clear line in the sale terms prevents most complaints. For example, "unfilled USDC returns to wallets within seven days of allocation results." Slow or vague refunds burn the goodwill a strong sale just created. A complete rule set belongs in the sale documents, as outlined in this public token sale terms checklist.

How Should Projects Communicate Allocation Rules?

Buyer caps, tiers, and refund rules only build trust when buyers can actually read them. A fair system that nobody sees still looks unfair from the outside. That makes communication the final step of allocation design.

The work splits into before and after the sale. Before the sale opens, the project should publish one allocation rulebook on the sale page. It should cover:

• The allocation method and its formula.

• The minimum and maximum buyer caps.

• The tier criteria and the benefit of each tier.

• The refund currency, timeline, and fee handling.

• The full sale timeline, from window open to token distribution.

One worked example should sit next to these rules. For example, state what a 1,000 USDC request receives if the sale ends 2x oversubscribed. Buyers who can predict their own outcome rarely dispute it.

After the sale closes, the same discipline applies. The project should publish:

• The total demand and the final oversubscription level.

• The fill results across request sizes or tiers.

• Confirmation that refunds were sent, with the date.

Clear results turn an oversubscribed round into public proof of demand. Silence turns the same round into rumors about favoritism.

How Allocation Method Shapes Post-TGE Holder Health: The Ape in Poker Case

The choice between allocation methods has downstream effects. TokenMinds' work on Ape in Poker's tokenomics illustrates how distribution strategy prevents both market flooding and concentration risk.

Ape in Poker faced three core challenges: 

• Ensuring fair distribution across seed investors, the core team, and public participants.

• Preventing market dumping that would crater price post-TGE

• Sustaining liquidity and demand over time. 

The solution was not a single allocation method, but a balanced distribution strategy across buyer cohorts. Seed and private investors received tokens over a 15-month vesting schedule to prevent early dumping while supporting project development. The public sale used immediate unlock, allowing regular investors to participate without lock delays. The team and developers faced longer holds. The team accepted a 12-month lock with 18-month vesting. Developers accepted a 3-month lock with 24-month vesting. These terms aligned their incentives with platform growth.

The result was a holder base where no single cohort could dominate post-TGE price action. TokenMinds modeled token value growing from $0.03 in Year 1 to $0.10 in Year 2 and $0.30 in Year 3, contingent on platform adoption increasing and staking adoption reducing circulating supply. These are illustrative projections tied to specific platform-adoption scenarios, not guaranteed outcomes. The vesting schedule ensured gradual token release over 36 months, avoiding the market saturation that kills new tokens in their first quarter.

This case shows why allocation method choice is inseparable from vesting design. A fill-from-the-bottom allocation with no vesting creates many small holders who can dump immediately. A pro-rata allocation with strict vesting on large holders can leave small buyers vulnerable to price collapse when their tokens unlock first. Ape in Poker's approach used differentiated vesting by buyer type to align incentives: early capital got long locks, public participants got immediate access, and core contributors faced the strictest terms.

Read the full Ape in Poker tokenomics advisory case study.

How Should Projects Handle Edge Cases and Disputes?

Even with clear rules and fair allocation, edge cases arrive. A buyer's KYC fails mid-sale. Two wallets claim to represent the same person. A tier rule is ambiguous and buyers appeal their tier assignment. These situations are rare but they can derail a launch if no process exists to handle them.

Failed KYC and contribution refunds

A wallet that fails KYC verification should be excluded from allocation and refunded in full. The key is timing: refund failed-KYC contributors within 3 days of the KYC rejection, not after allocation closes. This prevents disputes about whether a failed-KYC wallet was included in the oversubscription ratio. The refund should land before the allocation runs, so the total-demand figure used for the calculation only includes verified contributors.

Tier eligibility disputes

Vague criteria invite disputes. Buyers cannot predict their tier assignment when rules use terms like "active community members" or "significant prior usage." Prevent this by publishing measurable criteria before the sale opens. Example: "Tier 1 requires minimum 50 transactions on the platform in the 90 days before sale opens, verified on-chain." Measurable criteria are auditable and leave no room for subjective judgment. Buyers who still dispute should have a 5-day appeal window after tier assignments are published, with a clear process: submit evidence, receive a decision within 2 days, and move forward. Appeals that arrive after the sale closes should not delay allocation. Resolve them post-TGE via refund or additional token distribution if warranted.

Wallet consolidation and duplicate claims

A buyer may request allocation across multiple wallets, then ask to consolidate them after the sale closes. They split capital to stay under individual caps, such as $5,000 in one wallet and $3,000 in another. After the sale, they ask to merge the allocations. This happens often enough that rules must address it beforehand. The right approach is to deny post-sale consolidation to preserve fairness to other buyers who stayed within caps individually. Publish this rule before the sale. If a buyer can document that both wallets belong to the same person, offer to honor the allocation as originally calculated but prevent future consolidation requests in writing.

Refund processing delays and support escalation

If a refund does not arrive within the published window, typically seven days, the buyer should be able to escalate. Establish a 3-tier process: (1) automatic check showing the refund on-chain within 7 days, (2) manual verification of the refund transaction if the buyer claims non-receipt (usually a wallet indexing delay), and (3) team reissuance of the refund if an on-chain error occurred. Document all three in a public support ticket system. Most refund "failures" are wallet sync delays, not contract failures, so publishing a "how to check if my refund arrived" guide prevents most support tickets.

Fair Allocation Starts Before the Token Sale Opens

An oversubscribed token sale can end in two ways. It produces a measurable record of demand that shapes a healthy holder base, or it produces post-launch disputes that erode buyer confidence and derail momentum. The difference is not luck. The difference is whether the rules existed before the sale opened.

The preparation list is short. Pick the allocation method that matches the target holder base. Set the buyer caps. Define the priority tiers. Write the refund rules. Then publish all of it before the window opens. Teams that publish rules before the sale window opens reduce post-launch disputes. They move from managing crises to executing launches. The full token launch sequence, from tokenomics through post-TGE vesting, is outlined in this guide on how to launch a token.

TokenMinds supports projects at this design stage. The team helps select the allocation model, set buyer caps and priority tiers, plan refunds, and align distribution with post-TGE goals. Founders preparing a public round can request a sale allocation design review.

Design Fair Oversubscription Rules With TokenMinds

Allocation design affects more than one sale event. It determines who becomes a holder, how concentrated the supply gets, how refunds are handled, and how the round positions the token for TGE.

TokenMinds helps projects design fair oversubscription rules before the sale opens. This covers selecting the allocation model, setting buyer caps and priority tiers, planning refund logic, and aligning distribution with the desired holder base and post-TGE goals. Projects receive a recommended allocation method, a complete rule set for the sale terms, and a communication plan covering pre-sale publication and post-sale reporting. The review also includes a worked allocation example at the project's own sale size. It arrives ready to publish before the window opens, so buyers can predict their fill instead of disputing it.

Book a sale allocation design review with TokenMinds.

FAQs

1. What is the best allocation method for token sales?
   The best allocation method depends on the holder base the project wants after TGE. Fill-from-the-bottom works for broad community distribution. Pro-rata with hard caps suits projects that need committed capital with limits. Tiered allocation rewards existing users. Each method creates a different outcome, so the choice should follow the distribution goal, not simplicity

2. How should a project allocate tokens if its sale is oversubscribed?
   The project should apply the allocation method published before the sale opened. Common options include pro-rata scaling, a lottery, tiered allocation, and fill-from-the-bottom. Every unfilled amount should be refunded under a clear, dated procedure.

3. What is a fair allocation method for public token sales?
   A fair allocation method is one with published rules applied consistently, measured by dispute rate and holder concentration at TGE. Fill-from-the-bottom spreads supply across many wallets, reducing concentration risk. Pro-rata with hard caps preserves committed capital while capping any single holder's share.

4. How do token sales avoid whales taking the whole round?
   Sales limit whales through per-wallet maximum caps and allocation methods that favor smaller requests. Fill-from-the-bottom and capped lotteries are the strongest tools. Sybil-resistant whitelists stop whales from splitting funds across many wallets.

Sources

1. Coinbase, "The Ideal Way to Launch: Introducing Token Sales on Coinbase" - https://www.coinbase.com/blog/the-ideal-way-to-launch-introducing-token-sales-on-coinbase

2. Coinbase Help, "Token Sales" (official documentation for the fill-from-the-bottom model, partial fills, refunds, and the 30-day resale rule) - https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/token-sales

3. Coinbase, Monad (MON) Token Sale page (276.05M USDC requested, 187.5M USDC available, 1.47x oversubscribed) - https://www.coinbase.com/token-sales/monad

4. Crypto Briefing, "MegaETH token sale ends with $1.4B in bids, reaching $27.8B FDV" - https://cryptobriefing.com/megaeth-ico-1-4-billion-bids-27-billion-fdv/

5. ChainGPT Documentation, "Saleium: Host Token Sales Where Your Community Already Lives" - https://docs.chaingpt.org/our-ecosystem/saleium-host-token-sales-where-your-community-already-lives (keep only if the Saleium mention stays after the manager's decision)