Risk Invariants

Risk invariants are the properties that must hold for the safety envelope and daily accounting boundary to remain coherent.

They do not describe policy choices or operational procedure. They describe the non-negotiable rules that make exposure, fees, and daily attribution well-defined across time.

The easiest way to read these invariants is to separate three layers:

• Mechanism semantics: what a trade means, what a tick means, what a claim means.
• Accounting grammar: how daily PnL and fees are realized and allocated.
• Admissibility boundaries: when the system rejects a configuration or a day update by reverting instead of silently clipping.

This page lives mostly in the last two layers. It treats the daily boundary as a deterministic function and describes the constraints that prevent the boundary from becoming discretionary.

Fee allocation invariants

Fee allocation turns a market day into a set of transfers across the capital stack. The core invariant is conservation: the accounting layer may decide how fees are split, but it must not create or destroy them.

At the daily boundary, the protocol can summarize fee allocation as a set of nonnegative transfers to destinations. Conservation can be written as:

$$\sum_k \text{alloc}_k = F$$

where $F$ is the total fees generated for the day and $\text{alloc}_k$ are the per-destination allocations.

Key properties:

• Conservation: total allocated fees equal the total fees generated that day.
• Single allocation: each unit of fee is allocated exactly once.
• Bounded compensation: loss compensation cannot exceed realized loss.

Bounded compensation prevents double counting on loss days. A day can be negative, but the accounting cannot "pay itself twice" by allocating more loss offset than the realized loss.

Fee allocation also has parameter invariants. Residual fee shares must sum to 1, and the NAV floor parameter must stay inside a valid range. These are accounting well-formedness constraints, not market opinions.

In symbols:

$$\phi_\text{LP} + \phi_\text{BS} + \phi_\text{TR} = 1$$

and

$$-1 < p_\text{dd} < 0$$

In v1, the system maintains the relationship $p_\text{dd} = -\lambda$ where $\lambda \in (0,1)$ is the safety parameter used in depth admissibility.

Determinism and conservation are both required. Given the same day inputs, the same allocation ordering must produce the same outputs. Otherwise, the protocol is no longer a reproducible mechanism and turns into a discretionary ledger.

One consequence is that fee accounting can be replayed. For a fixed regime, an observer who reads the day inputs and the configuration should be able to reproduce the same allocations. If two observers can disagree about where a unit of fee went, the system has lost the property that makes it analyzable.

Accounting invariants

Signals v1 realizes maker-side results on a daily boundary. That boundary is what makes "a day of risk" comparable across time: trading is continuous, but attribution is discrete.

The accounting boundary can be modeled as a pure function:

$$\text{state}_{t+1} = f(\text{state}_t, \text{dayInputs}_t)$$

The invariant is not that outcomes are smooth. The invariant is that the update is deterministic and single-step.

Key properties:

• Single daily update: a market day produces one accounting update.
• Deterministic rounding: rounding rules are fixed and applied consistently.
• Monotone reference tracking: peak tracking is monotone and deterministic.

Deterministic rounding is part of the specification. Without it, two observers can compute different day results from the same public inputs, and the notion of a "final" daily attribution stops making sense.

Peak tracking anchors drawdown and safety accounting to a single reference. If the reference can move backward, drawdown becomes re-definable after the fact.

The daily boundary is also an admissibility boundary. The protocol does not silently "make it work" on infeasible days by clipping a transfer or inventing a new ordering. Instead, infeasible updates revert. This is part of the invariant surface: the system either performs the specified update or performs no update.

Request queue invariants

Request queues (deposits and withdrawals) are intentionally batched. The invariant is not "instant execution"; it is that execution is well-defined at a single checkpoint.

The queue invariants can be stated as a boundary rule: requests execute only at batch boundaries and only when eligible. Intraday execution is not allowed because it would make exposure timing-dependent.

Key properties:

• Eligibility: requests execute only at eligible batch boundaries.
• Single processing: no request can be processed more than once.
• Conservation: batch totals equal the sum of eligible requests.

The queue also has monotonicity constraints: once a batch has been processed, requests eligible for that batch cannot be retroactively removed. In v1, this appears as "too late" cancellation reverts after a request's batch has already been processed. This is part of the accounting boundary, not a UI convention.

The queue model has one core safety goal: eliminate timing advantage around days. If deposits could enter mid-day and earn only after observing outcomes, or withdrawals could leave mid-day after observing losses, the daily boundary would stop representing shared exposure. Batching makes exposure a day-level object.

Admissibility and grant invariants

Signals v1 uses a safety layer that is enforced at explicit boundaries. In the current release, two boundaries are central:

• market creation (admissible configuration), and
• daily batch processing (admissible accounting updates).

These invariants describe well-formedness. If they fail, the system is no longer a reproducible mechanism at the day boundary.

Market creation invariants

Market creation gates enforce that depth and prior concentration stay inside an admissible region derived from maker-side state at the moment of creation.

Two inequalities are central:

$$\alpha \le \alpha_\text{limit}$$

and

$$\Delta E_t \le B^\text{eff}$$

where $\alpha_\text{limit}$ is derived from maker NAV and peak drawdown, and $\Delta E_t$ is derived from the market's seed factors (prior concentration). $B^\text{eff}$ is the effective backstop budget (backstop NAV in v1).

These are enforced at market creation time in the current release. Trade entrypoints call risk-gate hooks, but exposure cap enforcement is not active.

Batch tail budget invariants

Each market stores a tail budget $\Delta E_t$ computed from seed factors at creation. When markets settle into a daily batch, their tail budgets are summed:

$$\Delta E^\text{sum} = \sum_{m \in \text{batch}} \Delta E_m$$

The implementation performs an early bound check when recording settlement into the batch:

$$\Delta E^\text{sum} \le B_t$$

where $B_t$ is the current backstop NAV. This does not complete batch processing, but it rejects obviously infeasible batches from accumulating silently.

At batch processing, the fee waterfall computes a grant need $G^\text{need}$ to restore the NAV floor after applying P&L and loss compensation. The key invariant is:

$$G^\text{need} \le \Delta E^\text{sum}$$

If the inequality does not hold, the batch reverts. The grant is not capped down silently; it is either admissible or it is rejected.

Backstop solvency is also explicit:

$$G^\text{need} \le B_t$$

These invariants define when daily maker-side updates are admissible under the tail budget model.

A concrete loss-day check

Consider a day where maker-side trading PnL is negative and fees are small. The waterfall can compensate losses out of fees up to the realized loss amount. That is the bounded-compensation invariant: fees can offset losses, but they cannot offset more loss than occurred.

Now consider a day that is so negative that the NAV floor would be violated. The waterfall computes a grant need $G^\text{need}$ to restore the floor. The key admissibility invariant is that the needed grant must fit inside budgets:

$$G^\text{need} \le \Delta E^\text{sum} \qquad\text{and}\qquad G^\text{need} \le B_t$$

If those inequalities fail, the batch reverts rather than partially applying a smaller grant. This prevents a subtle failure mode where the system continues processing days but the accounting boundary stops being a deterministic grammar.

Regime boundary invariants

Signals v1 treats upgrades and policy changes as explicit regime boundaries. The invariant is not that policy never changes. The invariant is that a change is observable and attributable as an on-chain state transition.

This is a safety property for analysis. When a regime boundary exists, the protocol state before and after the boundary is comparable only inside the same regime. The boundary itself must be unambiguous.

Key properties:

• Attribution: an upgrade or policy change has a concrete activation point.
• Legibility: post-change behavior can be tied to a specific configuration state and module set.
• Comparability: within a fixed regime, daily accounting and safety rules remain stable and reproducible.

Related reading

• Risk Gates
• Safety and Performance Layer
• Vault Fee Waterfall
• Vault Invariants