> For the complete documentation index, see [llms.txt](https://docs.callput.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.callput.app/liquidity-providers/vaults-risk-and-epoch.md).

# Vaults risk and epoch

This page documents the public LP flow through `sVault`.

## Why this page is written around `sVault`

The current public LP narrative is centered on `sVault`. Other vault families may exist in the broader deployment footprint, but this public package describes the flow that is currently documented as active for external users.

## `sVault` request flow

At a user-facing level:

1. the LP submits a mint or burn request
2. the request enters a queue
3. the request waits during the `Submission` phase
4. the request is processed during the `Process` phase
5. the resulting mint or redemption is finalized

The key implication is that LP entry and exit are not documented as instant actions.

## Epoch model

An epoch is composed of:

1. `Submission`
2. `Process`

### Submission

The system accepts and queues LP requests.

### Process

The system executes queued LP requests.

## Epoch duration

Epoch duration is configurable. Public documentation should therefore explain the mechanism first and treat specific time windows as runtime values rather than permanent constants.

## Conceptual epoch timeline

1. `startEpoch()` begins Submission
2. LP requests accumulate during Submission
3. `endEpoch()` begins Process
4. queued requests are processed during Process
5. the next epoch begins

## LP-specific operational risks

### Entry and exit are not instant

LP activity should not be interpreted as always-open instant deposit and withdrawal.

### Configuration can change

The current epoch timing model can change over time.

### Automation health matters

Queue execution and epoch management affect when LP requests are finalized.

### Cooldown and settlement constraints can matter

LP request behavior should be understood together with the broader operational constraints of the pool stack.