> For the complete documentation index, see [llms.txt](https://docs.callhouse.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.callhouse.finance/product/weekly-cycle.md).

# The weekly cycle

The vault moves through four phases every cycle:

```
Idle ──rollOpen──► Listed ──lockBook──► Exercisable ──rollClose──► Settling ──► Idle
                      │                                   ▲
                      └────────────── rollClose ──────────┘
                              (lockBook is optional)
```

The vault has no calendar of its own. Every deadline comes from Overcall's registry for the NVDA market, which publishes each cycle's strikes, its exercise timestamp and its expiry. The vault copies those timestamps when it writes, so a cycle keeps its own deadlines even after the registry moves on to the next one.

{% hint style="info" %}
**Overcall's current window** is book close on Friday at 20:00 UTC and expiry on Saturday at 20:00 UTC, in a seven-day cycle with a 24-hour exercise window. Those times belong to the venue, not to Callhouse. If the registry moves them, the vault moves with it.
{% endhint %}

## The phases

| Phase           | Starts when                                    | Who triggers it                                 | Deposits                          | Withdrawals   |
| --------------- | ---------------------------------------------- | ----------------------------------------------- | --------------------------------- | ------------- |
| **Idle**        | The vault is flat                              | —                                               | Open, up to the cap               | Instant       |
| **Listed**      | `rollOpen` writes this cycle's calls           | Keeper only                                     | Open until the exercise timestamp | Queue         |
| **Exercisable** | `lockBook`, at or after the exercise timestamp | Anyone                                          | Closed                            | Queue         |
| **Settling**    | `rollClose`, at or after expiry                | Keeper from expiry; anyone from expiry + 1 hour | Closed                            | Being settled |
| **Idle** again  | End of the same `rollClose` transaction        | —                                               | Open                              | Instant       |

### Idle → Listed: `rollOpen`

Only the keeper can open a cycle, and only while the registry says writing is open. The keeper chooses one of the registry's strike rungs (up to five per cycle) and a number of contracts. The vault then checks everything itself before any NVDA moves:

* the vault is Idle and writes are not halted;
* the option is approved in the registry's current cycle, is an NVDA call settled in USDG with a lot size of exactly one NVDA per contract, and its exercise and expiry match the cycle's;
* the cycle's expiry is after its exercise timestamp and no more than 21 days away;
* the strike is 3% to 12% above spot (launch band);
* the price feed is no older than 4 days (launch setting) and the Stock Token has not paused its oracle;
* the number of contracts is at least 1, at most 50, and at most 95% of idle NVDA in whole tokens;
* Valorem's engine fee is off, or the admin has accepted it.

If any check fails, nothing is written and the vault stays Idle. The keeper tries again while the registry's write window is open, so a temporary problem such as a stale price feed can still end in a write later that week. If no write lands before the window closes, the week is skipped. Deposits and instant redemptions stay open, and a skipped week is a normal outcome.

### During Listed: listings

The keeper proposes a Seaport order, and the vault authorises it on chain only if every field matches the vault's own state and the gross premium is at least 0.40% of spot notional. One listing can be live at a time, at most three can be signed per cycle, and every listing must end by the exercise timestamp. The keeper or the Guardian can cancel a listing.

Buyers can fill a listing in part or in full. Each fill pays USDG to the vault immediately.

### How the keeper chooses, by default

The contracts set the bounds. Inside them, the keeper software (`keeper/src/policy.ts` and `keeper/src/config.ts` in the app repository) makes these choices with its default settings. They are operating choices, not commitments, and whoever runs the keeper can change them in its configuration, without a contract change.

* **Strike:** the nearest out-of-the-money rung, meaning the lowest strike inside the band. That is where a weekly call has premium, and it is also the rung most likely to be assigned.
* **Size:** the largest the policy allows, 95% of idle NVDA in whole tokens, capped at the contract limit. The whole written size goes into one listing.
* **Price:** the vault's premium floor for the current spot (0.40% of spot per contract at launch), raised to the last observed fill on Overcall's book for that rung, but never more than three times the floor, never below 20 base units and never above the strike. With the default margin setting of 0, a week with no fill history lists at the floor.
* **Listing length:** until the exercise timestamp.
* **Relisting:** after a cancel or an invalidated order, the keeper relists once by default, never below its previous ask. The vault's limit of three signed listings a cycle applies regardless.

If Overcall's book does not show the listing, the keeper keeps the signed order and serves it from its own `/orders` endpoint. When Overcall's book does not show the vault's live listing, the app's cycle page falls back to the keeper: it fetches the keeper's signed order, checks it against the chain (Seaport's counter and order hash must match the listing the vault authorised, every leg must pay the vault and Overcall's 5%, and the order must not be cancelled or sold out), and offers a fill from the page, labelled as the keeper's listing. The order is still invisible to buyers who only use Overcall.

### Listed → Exercisable: `lockBook`

From the exercise timestamp, anyone can call `lockBook`. It cancels any listing still live and moves the vault to Exercisable. Nothing depends on it being called: deposits close on the timestamp itself, and `rollClose` also accepts a vault that is still Listed.

During the exercise window, holders of this cycle's calls can exercise them in Valorem. The vault does nothing in this phase. See [Assignment](/product/assignment.md).

### Exercisable → Settling → Idle: `rollClose`

From expiry, the keeper can call `rollClose`. One hour after expiry, anyone can. This is the fallback if the keeper is down: nobody needs a key to get the week closed.

`rollClose` runs as one transaction, in this order:

1. Cancels any listing still live.
2. Redeems the vault's Valorem claim: NVDA that was not assigned comes back, and strike USDG comes back for what was.
3. Harvests the USDG: the 5% protocol fee is taken from the premium only, and the rest, including strike proceeds in full, is credited per share.
4. Settles the redeem queue for this epoch.
5. Returns the vault to Idle.

## What stops at each phase, and what never does

A halt on writes blocks `rollOpen` and new listings. It never blocks deposits, instant or queued redemptions, USDG claims, cancelling a listing, `lockBook` or `rollClose`.

| Action                        | Idle                                 | Listed                       | Exercisable |
| ----------------------------- | ------------------------------------ | ---------------------------- | ----------- |
| Deposit                       | Yes                                  | Until the exercise timestamp | No          |
| Instant redemption            | Yes                                  | No                           | No          |
| Queue a redemption            | Yes, but it waits for the next close | Yes                          | Yes         |
| Complete a settled redemption | Yes                                  | Yes                          | Yes         |
| Claim USDG                    | Yes                                  | Yes                          | Yes         |

## Related

* [How Callhouse works](/getting-started/how-it-works.md)
* [Launch policy and hard caps](/product/policy.md)
* [Roles and admin powers](/protocol/roles.md)


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.callhouse.finance/product/weekly-cycle.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.