What does it mean when a token sale is oversubscribed?
Oversubscribed is the state where a token sale receives more valid contributions than it can accept, so demand outstrips the supply for sale. When that happens, pro-rata allocation is the mechanism most sales use to divide what is available: every contributor gets a share proportional to their contribution, and the rest is refunded. If a sale caps at $500,000 and $2,000,000 in valid contributions arrive before the cap is reached, the sale is 4x oversubscribed, and every contributor is competing for a smaller slice of tokens than they tried to buy.
The term borrows directly from traditional finance. Investopedia describes an oversubscribed offering the same way: more orders than shares available. It is a routine outcome for a popular raise, not a failure, and IDOs make up a large share, over 70% by some counts, of all public token sales. See the glossary for related sale terms like hard cap, soft cap, and allowlist.
Why do token sales get oversubscribed in the first place?
Token sales get oversubscribed because visible early traction pulls in more capital than the project chose to raise. A launch with a capped hard cap, a completed audit, and a track record of prior sales performing well trains buyers to show up early and contribute the maximum the moment a sale opens.
Track record compounds this. ChainGPT Pad, the infrastructure Saleium is built on, has run 50 IDOs for $12.7M raised at a 9.94x average peak multiple, exactly the kind of history that pushes demand well past a sale's cap in its opening minutes. A white-label launchpad that launches fast and looks credible will see this pattern more, not less, which is why allocation design has to be decided before the sale opens, not improvised once it does.
What allocation models exist for oversubscribed sales?
Three allocation models handle oversubscription: first-come-first-served, pro-rata (including weighted pro-rata), and lottery. Each answers the same question, who gets tokens when demand exceeds supply, with a different tradeoff between speed, fairness, and gas cost.
First-come-first-served fills the cap in the order valid transactions land, and rejects everything after. Pro-rata allocation lets every valid contribution in, then sizes each wallet's tokens as a share of the total raised. Lottery randomly draws winners from the eligible pool and gives each winner a full allocation. The rest of this guide focuses on pro-rata, because it is the model most public sales, including Saleium's, default to.
FCFS vs pro-rata vs lottery: which allocation model is fairest?
Pro-rata is generally the fairest model because it rewards contribution size instead of transaction speed, and it does not turn the sale into a race. FCFS and lottery each solve part of the problem while creating a different one.
| First-come-first-served (FCFS) | Pro-rata / weighted | Lottery | |
|---|---|---|---|
| How allocation is decided | Order transactions land, until the cap fills | Each contribution's share of the total raised | Random draw from the eligible pool |
| Fairness | Favors the fastest wallet, not the most committed one | Every contributor gets a proportional share | Equal odds regardless of contribution size |
| Gas-war risk | High, wallets overbid gas to land in the first block | Low, arriving a block later does not shrink your share | None, entry does not depend on transaction order |
| Refund behavior | None for winners; latecomers are rejected outright | Excess above your share is refunded automatically | Non-winners get a full refund; winners get the full ask |
FCFS is simplest to build but produces gas wars and shuts out anyone with a slower connection or a smaller gas budget. Lottery removes the speed advantage entirely but gives winners more than a proportional share and losers nothing. Pro-rata splits the difference: everyone who contributes gets in, and how much they get in for is set by how much they put up, not how fast they clicked.
What is pro-rata allocation, and how is it calculated?
Pro-rata allocation is a distribution method where each contributor receives a share of the available tokens proportional to the size of their own contribution relative to the total raised. If the sale is 4x oversubscribed, every wallet gets roughly a quarter of what it contributed, and the other three quarters come back as a refund.
The calculation is simple: a wallet's allocation equals its contribution divided by total valid contributions, multiplied by the sale's hard cap. Contribute $1,000 into a sale that receives $4,000,000 against a $1,000,000 hard cap, and your allocation is set by $1,000 divided by $4,000,000, times $1,000,000, which comes to $250 worth of tokens, with the remaining $750 returned to you. Investopedia's definition of pro rata covers the same proportional-share logic used across finance, not just token sales.
How does weighted allocation differ from simple pro-rata?
Weighted allocation is pro-rata with an added multiplier, so contribution size still decides the split but a wallet's tier, stake, or loyalty status can scale its share up before the proportional math runs. Simple pro-rata treats every dollar the same; weighted pro-rata treats a dollar from a higher tier as worth more shares.
Saleium's token sale product supports both weighted and pro-rata oversubscription natively, alongside tiered minimum and maximum contribution limits per wallet. A project can give a higher tier more weight in the pro-rata formula while still capping any single wallet's maximum allocation, so no tier can absorb the entire sale even if it wins the largest proportional share.
How do tiered min and max limits interact with pro-rata?
Tiered min and max limits set a floor and a ceiling on what any one wallet can contribute before pro-rata math ever runs. The tier decides eligibility and the ceiling; pro-rata decides the actual allocation within that ceiling once the sale oversubscribes.
This combination stops a single large wallet from contributing an outsized amount and capturing most of the pool even under a fair proportional formula. A public tier might cap contributions at $2,000 per wallet, while a higher allowlist tier caps at $10,000, and pro-rata still applies within each tier if that tier's pool oversubscribes. It is the same layered structure behind a well-run token sale: eligibility first, then a fair split of what is actually available.
How do excess-refund and full-refund windows work?
An excess-refund window is the on-chain process that returns the difference between what a wallet contributed and what its pro-rata allocation actually costs, automatically, once the sale closes and the final ratio is known. A full-refund window is separate: it returns every contribution, in full, if the sale never reaches its soft cap.
These are two different failure modes with two different fixes. Oversubscription means too much demand, so the excess-refund window trims each contribution down to its fair share and returns the rest. A missed soft cap means too little demand, so the full-refund window returns everything, because a raise below its funding floor should not proceed at all. Saleium's token sale contracts run both windows on-chain, so no team has to manually calculate or wire back a single refund.
How does on-chain settlement make oversubscribed refunds trustless?
On-chain settlement makes refunds trustless because the contract, not the team, calculates and executes every allocation and every refund from the same public data: the list of valid contributions and the hard cap. A contributor can verify their own allocation and refund against the same numbers everyone else sees, instead of taking a project's word for it.
This matters most exactly when a sale oversubscribes, because that is when trust is tested hardest: thousands of wallets are owed a partial refund at once, and a manual process invites both error and suspicion. The EIP-20 standard that most sale tokens follow settles transfers the same deterministic way, so extending that determinism to the sale and refund logic keeps the whole flow auditable end to end.
How do you prepare a token sale for oversubscription?
You prepare for oversubscription by deciding the allocation model, the tiers, and the refund logic before the sale opens, not while contributions are pouring in. Treat oversubscription as the likely outcome of a successful sale, not an edge case.
- Choose pro-rata, weighted, or lottery allocation before launch, and publish which one you are using.
- Set the hard cap and soft cap, and decide what happens if the soft cap is missed.
- Configure tiered minimum and maximum contribution limits per wallet.
- Confirm the excess-refund window activates automatically once the final ratio is known.
- Confirm the full-refund window activates automatically if the soft cap is not reached.
- Communicate the allocation model and refund timing to contributors ahead of the sale.
- Test the full flow, including an oversubscribed scenario, before taking it live.
Running a sale without a launchpad means building all of this yourself; see running a token sale without a launchpad for what that build actually involves. Whichever route a team takes, the allocation model belongs on the same pre-launch token launch checklist as KYC, vesting, and the audit.