> For the complete documentation index, see [llms.txt](https://docs.selcier.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.selcier.xyz/walkthroughs/schedule-a-window.md).

# Put a Liquidity Window on the calendar

Offer shareholders an exit on your terms through a batch auction or fixed-price tender with a set time limit and atomic on-chain settlement.

Scheduled and time-boxed, a Liquidity Window is a market for a single share class. Sellers who qualify post asks, buyers who qualify post bids, and at close all of it clears at one price in a single transaction. It takes the place of a traditional tender offer, with timing, participation and volume all set by you. [Scheduled Liquidity Windows](/markets-and-capital/scheduled-windows.md) explains the full mechanics.

{% stepper %}
{% step %}

### Pick an auction or a tender

In the Console, open **Liquidity** and choose **New window**. Then pick a format:

| Format                 | How it works                                                                                                                                                      |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Batch auction**      | Each seller names a minimum price and each buyer a maximum. Clearing happens at the one price that matches the most volume.                                       |
| **Fixed-price tender** | The price comes from you or a named buyer, and sellers choose how much to tender at it. If tendered shares exceed what the buyer wants, allocations are pro-rata. |

Batch auctions suit routine liquidity at most companies. Tenders fit cases where a specific buyer, or the company itself, wants to buy back a set amount.
{% endstep %}

{% step %}

### Decide who can take part

Settle who may sell and who may buy.

| Setting          | Examples                                                                                  |
| ---------------- | ----------------------------------------------------------------------------------------- |
| Eligible sellers | Anyone holding the class, employees whose lots have vested, or a list of names            |
| Eligible buyers  | Current holders, investors you invite, or any wallet holding an `INVESTOR_ELIGIBLE` claim |
| Per-seller cap   | A fixed limit on how many shares each seller can offer                                    |
| Maximum volume   | The most shares that can trade overall                                                    |

Orders still have to pass the class's [compliance modules](/fundamentals/compliance-modules.md). Sellers whose lots are unvested or locked are limited to their unlocked balance.
{% endstep %}

{% step %}

### Add pricing controls

Batch auctions accept these optional controls:

* **Reserve price.** Trades can't clear beneath this level.
* **Per-seller cap.** The ceiling on shares offered by any single seller.
* **Right of first refusal** gives the company or its designee first call at the clearing price after close. You name the right holder and how long the priority period lasts.

A buyback is simply a bid: once the window opens, place one from the company treasury as any other buyer would. When nothing can trade at the reserve price, the window ends without trades and all orders go back to their owners.
{% endstep %}

{% step %}

### Set the dates and get approval

Pick when the window opens and when it closes. Windows usually run two to five business days, leaving employees time to decide. Then submit to **Approvals**. After approval, `LiquidityWindow` emits `WindowOpened`, the window shows up in Portfolio for eligible holders, and they get an email notice.

A class with `TransferWindowModule` allows transfers only during company-defined periods, so all trading stays inside windows you control.
{% endstep %}

{% step %}

### Monitor orders

While the window runs, **Liquidity** displays total demand and supply by price level. In the Explorer, each order is an `OrderPlaced` event that shows the wallet but no identity. Orders are always fully funded, since placing one locks the seller's tokens or the buyer's USDG.

A window can be cancelled at any point before it clears. Doing so emits `WindowCancelled` and releases all orders.
{% endstep %}

{% step %}

### Settle the window

`clear(windowId)` can be called by anyone once the close time and any right of first refusal period have passed, and Selcier's operator calls it automatically. A single transaction then does the following, in order:

1. Works out the clearing price with the most matched volume.
2. Executes orders at the price found, scaling marginal orders pro-rata.
3. Pays sellers in USDG after fees and hands buyers their tokens.
4. Releases whatever didn't fill.

`WindowCleared` reports the price and volume. If any volume traded, the price also becomes a Reference Valuation with source `WINDOW_CLEARING`.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
Employees need the seller's view of this process, so send them [Sell your shares in a window](/walkthroughs/sell-your-shares.md) ahead of the open time.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.selcier.xyz/walkthroughs/schedule-a-window.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.