LP Vault and Daily Batches
The LP vault aggregates maker capital that underwrites the shared pricing curve. Maker-side results are realized once per day through a batch update that runs at a fixed boundary in the market lifecycle. The batch is the accounting boundary: everyone who carried the day’s exposure receives the same share-price update.
LP access is private in v1. This page describes the maker capital accounting model that supports liquidity depth.
Maker capital as depth
Depth is the surface traders feel. Maker capital is the economic capacity that absorbs maker-side trading results and makes depth credible. Because the curve is shared, one vault supports all ranges simultaneously: narrow and wide ranges pull from the same underlying capital.
The vault can be viewed as the balance sheet behind the curve. Trades change the pricing state continuously during the day. The maker-side balance sheet is not marked continuously. It is realized at the daily boundary so that one market day corresponds to one maker-side result.
This design puts a clean boundary around maker exposure. Maker capital is a daily commitment. The protocol expresses that commitment in accounting rather than in intraday mark-to-market.
Daily batch accounting
During a market day, trades update the shared curve state. Settlement finalizes a single tick. Claims read that tick after the claim delay. Maker accounting runs at the daily boundary after settlement: the day closes with one realized update.
At a high level, the batch update does three things:
- Realizes the day’s net maker-side trading PnL and fees into maker accounting.
- Applies the fee and loss allocation ordering.
- Updates vault value and the reference share price used for the next day.
The mechanism is intentionally discrete. A day produces one checkpoint. This keeps attribution stable across time: "a day of maker exposure" is a well-defined unit because it has one realized result.
Share price model
Maker participation is represented by a share token. Shares are proportional claims on vault value. The share price is the derived ratio:
The ratio is only meaningful at the batch boundary because vault value is only realized at the batch boundary. Intraday trades move the curve and accumulate fees, but the vault does not continuously mark share price.
The share model serves two purposes at once:
- It creates a proportional ownership claim on maker capital.
- It makes the daily accounting update observable as a single price update.
The share price is also the bridge between "economic value" and "request execution." Deposits and withdrawals do not execute at arbitrary intraday marks. They execute against the batch share price, which turns a day into a coherent accounting object.
Request queues and eligibility
Deposits and withdrawals are represented as requests that become eligible at a future batch boundary. Requests do not execute inside an active day. They execute at boundaries between days.
This queue model is the fairness device. It prevents mid-day entry and exit after intraday information is visible, and it makes exposure legible: a share position either carried the day’s risk or it did not.
The queue model also keeps accounting single-step. Requests are processed against one batch price rather than against a stream of intraday marks.
At an abstract level:
- A deposit request converts an amount of ctUSD into shares at the batch price.
- A withdrawal request converts shares into ctUSD at the batch price.
Rounding rules apply at the unit boundary. Those rules are part of the specification, not a UI detail. See Units and Rounding.
Two additional accounting concepts appear around requests.
Reservation. A withdrawal request can reserve value so the system can remain solvent under concurrent claims and subsequent batches. Reserved value is not the same as free balance. The vault tracks what is available for new obligations separately from what is already promised to existing requests.
Eligibility. Requests are assigned to future batch boundaries. Before a boundary, a request is pending and cannot execute. At the boundary, an eligible request is executed at the same price as every other eligible request for that boundary. This keeps batch execution fair and makes the accounting boundary single-step.
Batch readiness and sequencing
Batch processing is gated by settlement completeness. For a batch day, the protocol tracks:
- the total number of markets assigned to that day, and
- the number of those markets that have been resolved (primary or secondary settlement).
Batch processing is admitted only when resolved equals total. If unresolved markets remain, the batch update reverts. This keeps maker accounting tied to explicit settlement finality rather than to assumed completion.
The daily sequence is:
- markets settle and record day-level P&L and fee totals,
- unresolved-market count reaches zero for the batch day,
- fee waterfall runs and updates maker-side state,
- eligible deposit and withdrawal requests are processed at the batch price,
- batch ID advances.
This sequencing is an invariant surface for accounting reproducibility.
Worked example
Consider a day that begins with vault value 1,000 ctUSD and total shares 1,000. The reference share price is 1.00.
During the day, trading generates fees and a net maker-side trading result. At the daily boundary, the protocol applies the realized update.
Example A: gain day.
- Pre-batch: vault value 1,000, total shares 1,000.
- Realized net to the vault after allocation: +20 ctUSD.
- Post-batch: vault value 1,020, share price 1.02.
Example B: loss day.
- Pre-batch: vault value 1,000, total shares 1,000.
- Realized net to the vault after allocation: -30 ctUSD.
- Post-batch: vault value 970, share price 0.97.
Now add a deposit request. Suppose a deposit of 102 ctUSD becomes eligible at the gain-day batch boundary with share price 1.02. The minted shares are approximately shares, subject to rounding. The next day starts from the new share count and the new reference price.
The point is not the particular numbers. The point is the accounting grammar: realize once per day, derive one reference share price, then process eligible requests at that price.
The same logic applies to withdrawals. Suppose 51 shares are eligible at a batch price of 1.02. The withdrawal asset amount is approximately ctUSD, subject to rounding and reservation rules. The shares are removed from the request owner's claim on the vault, and the reserved ctUSD amount is tracked separately until the withdrawal claim is executed.
Now consider two deposit requests that become eligible at the same boundary:
- deposit A of 102 ctUSD
- deposit B of 10.2 ctUSD
Both are priced at the same share price, which means they receive shares proportional to value. The only way they differ is rounding at the unit boundary. That rounding is deterministic: given the same inputs and the same share price, the minted share amounts are reproducible.
Boundary cases
Settlement delay. If settlement finality is delayed, the batch boundary cannot complete. Share price remains unchanged until the realized update occurs. This is the same design choice as claim gating: the protocol waits for explicit finality rather than guessing.
Large loss days. A large maker-side loss produces a large negative update to vault value. The allocation ordering defines which layers absorb the deficit first and how buffers are refilled over time. This is part of the capital-stack model described in Capital Stack and Fee Waterfall.
Queue pressure. Requests are processed only at eligible boundaries. A request is either eligible and processed at a boundary, or it remains pending. This keeps ownership accounting deterministic.
Dead shares and minimum supply. Vault share systems typically include a minimum share supply pattern to prevent division-by-zero and extreme share price jumps when the supply is very small. Signals v1 uses a dead-shares style pattern so that the share price remains well-defined across boundary cases.