Overview
When a sale is oversubscribed (more demand than tokens available), you need to decide how tokens are allocated among participants. Specifically, you determine how much of each participant’s commitment is accepted (used to purchase tokens) and how much is refunded. Sonar does not provide off-the-shelf settlement computation — you implement the allocation logic yourself. The sections below describe common approaches at a high level to help you decide on a strategy. This decision is independent of your pricing strategy.Pro-Rata Allocation
Every participant’s commitment is scaled down by the same percentage so that total allocations match the available supply.How It Works
- If 2M is committed but only 1M worth of tokens are available, everyone receives 50% of their commitment
- The remainder is refunded
Example
| Value | |
|---|---|
| Tokens available | 1,000,000 worth |
| Total commitments | 2,000,000 (2x oversubscribed) |
| Alice commits | 100,000 |
| Alice receives | 50,000 allocation (50%) |
| Alice refunded | 50,000 |
Pros
- Simple and easy to understand
- Everyone gets something
- Larger participants receive larger allocations (which may attract institutional interest)
- No FOMO—timing doesn’t matter
Cons
- Can be gamed by participants who overcommit to secure a larger share
- Small participants may end up with very small allocations in highly oversubscribed sales
Iterative Fill (Bottom-Up)
This strategy prioritizes filling more participants by ensuring everyone receives at least a minimum allocation before distributing the remainder.How It Works
- Participants are placed in a random order
- Each participant is allocated the minimum commitment amount (e.g., 200)
- The process repeats, adding another minimum increment to each participant who committed more
- This continues until all available tokens are allocated
Example
| Participant | Committed | Allocated |
|---|---|---|
| 1,000 small participants | 200 each | 200 each (full) |
| 1,000 medium participants | 400 each | 400 each (full) |
| 1 large participant | 1,000,000 | 400,000 (partial) |
- Small participants: fully filled at 200
- Medium participants: fully filled at 400
- Large participant: receives 400,000 (remaining supply)
Pros
- More participants end up with meaningful allocations
- Reduces the advantage of large participants
- No incentive to overcommit
Cons
- More complex for participants to understand
- May be less attractive to large investors seeking significant allocations
- In highly oversubscribed sales, some participants may receive reduced allocations
First-Come First-Served
Commitments are accepted in the order they are received until supply is exhausted. Early participants receive guaranteed allocations.How It Works
- Participants submit commitments during the sale
- Commitments are queued in the order received
- When the sale closes, allocations are assigned in queue order until supply runs out
- If a participant cancels during the cancellation phase, their spot is freed and the next commitments in the queue move up
Example
| Position | Participant | Committed | Allocated |
|---|---|---|---|
| 1 | Alice | 200,000 | 200,000 (full) |
| 2 | Bob | 300,000 | 300,000 (full) |
| 3 | Carol | 400,000 | 400,000 (full) |
| 4 | Dave | 500,000 | 100,000 (partial—supply exhausted) |
| 5 | Eve | 200,000 | 0 (no supply remaining) |
Pros
- Clear, predictable rules—early participants get priority
- Strong incentive for early commitment
- Full allocations for successful participants (no scaling down)
Cons
- Creates urgency/FOMO at sale opening
- Discriminates against participants in unfavorable timezones
- Concentrates traffic at sale opening, increasing infrastructure load
- Late participants may receive nothing
- Rewards speed over conviction (smaller early commits beat larger late commits)
Custom Allocation
You can implement any allocation logic that fits your sale objectives. For example, you might factor in external data such as testnet participation, community contributions, or Discord activity.Next Steps
Pricing Strategies
Choose how your token price is determined
Configuration Options
View all sale configuration options