> ## Documentation Index
> Fetch the complete documentation index at: https://docs.echo.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Settlement Strategies

> How tokens are allocated when demand exceeds supply

## 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](/sonar/planning/pricing-strategies).

***

## 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

1. Participants are placed in a random order
2. Each participant is allocated the minimum commitment amount (e.g., 200)
3. The process repeats, adding another minimum increment to each participant who committed more
4. 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) |

With 1,000,000 available and minimum commitment of 200:

* 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

1. Participants submit commitments during the sale
2. Commitments are queued in the order received
3. When the sale closes, allocations are assigned in queue order until supply runs out
4. 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)            |

With 1,000,000 available, the first three participants are fully filled, Dave receives a partial allocation, and Eve receives nothing.

### 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

<CardGroup cols={2}>
  <Card title="Pricing Strategies" href="/sonar/planning/pricing-strategies" icon="tag">
    Choose how your token price is determined
  </Card>

  <Card title="Configuration Options" href="/sonar/planning/configuration-options" icon="sliders">
    View all sale configuration options
  </Card>
</CardGroup>
