Skip to content

Add per-underlying, per-strike-bucket, and per-expiry exposure limits - #353

Merged
techisigu merged 8 commits into
Zenith-options:mainfrom
emilylevi025-wq:drips/273-274-276
Oct 24, 2026
Merged

techisigu merged 8 commits into
Zenith-options:mainfrom
emilylevi025-wq:drips/273-274-276

Conversation

@emilylevi025-wq

Copy link
Copy Markdown
Contributor

Summary

Add per-underlying, per-strike-bucket, and per-expiry exposure limits

What was solved

#273 — Implement Per-Underlying, Strike-Bucket, and Expiry Concentration Limits With Position-Sizing Policies

Add a declarative exposure-policy layer to the vault: per-underlying, per-strike-bucket (moneyness band), and per-expiry limits as fractions of committed-epoch NAV, evaluated by one shared evaluate_exposure() used by both a pre-submission sizing step and contract-boundary enforcement. Sizing clamps requested notional to the tightest remaining headroom and records the clamp decision (reason, remaining headroom) for observability. Limits are configurable per vault through the existing timelock/multisig parameter-change workflow with an emitted event, validated on write so they cannot be jointly unsatisfiable, and degrade gracefully (block new writes, allow roll-off) when a vault is already over a tightened limit. Out of scope: drawdown circuit breakers, oracle mark-to-market valuation authority, and the strategy modules themselves.

Addressed:

  • Changed: src/lib/api/vaults.ts
  • Vault configuration gains independently enforceable, on-chain-readable per-underlying exposure limits expressed as a fraction of NAV
  • Vault configuration gains per-strike-bucket (moneyness band) exposure limits expressed as a fraction of NAV
  • Vault configuration gains per-expiry exposure limits expressed as a fraction of NAV

#274 — Implement Share Transfer Restrictions, Allowlisting, and Compliance Hooks for Vault LP Shares

Add a configurable transfer-restriction layer to vault LP shares: per-vault policy (OPEN / ALLOWLISTED / BLOCKED), a versioned allowlist/denylist with deny-wins resolution, a single can_transfer(from, to) gate used by all transfer paths, exemptions for the contract itself and the redemption queue, a compliance hook surface (pre-transfer advisory + post-settlement reconciliation feed), and surfacing policy/allowlist state in the depositor disclosure and transparency UI. Redemptions and forced burns must always succeed under every policy.

Addressed:

  • Changed: src/lib/api/vaults.ts
  • Support per-vault transfer policy: OPEN (default), ALLOWLISTED, BLOCKED (transfers disabled, mint/burn still permitted).
  • Enforce all transfer restrictions through a single can_transfer(from, to) function invoked by every transfer path, including future batch paths.
  • When ALLOWLISTED, transfers to a non-allowed address must fail with a distinct, documented error code from the error taxonomy.

#276 — Implement Frontend Vault Read-Path Caching, Revalidation, and Optimistic Deposit/Withdrawal State

Add a shared client-side data layer for vault reads and mutations: a cache keyed by vault id and epoch with configurable NAV staleness, explicit invalidation after deposit/withdraw/epoch-close/operator actions, optimistic deposit/withdraw state that reconciles or rolls back, and typed query/mutation hooks exposed from src/lib/api/vaults.ts so components cannot bypass the cache. Revalidation policy must be documented per surface and avoid duplicate fetches on pages already receiving WebSocket ticks, with distinct loading/empty/stale/offline states. Server-side caching/pagination for vault list and epoch history is explicitly out of scope.

Addressed:

  • Changed: src/env.ts
  • Provide a single shared cache keyed by vault id and epoch, with configurable staleness for NAV reads
  • Explicitly invalidate cache after deposit, withdraw, epoch-close, and operator actions
  • Implement optimistic state for deposit and withdraw submissions: show pending position/queue entry immediately, then reconcile to confirmed values or roll back with a clear error

Changes

  • src/env.ts (modify)
  • src/lib/api/vaults.ts (modify)

Approach

  1. Implement Per-Underlying, Strike-Bucket, and Expiry Concentration Limits With Position-Sizing Policies #273 — Implement Per-Underlying, Strike-Bucket, and Expiry Concentration Limits With Position-Sizing Policies (Changed: src/lib/api/vaults.ts)
  2. Implement Share Transfer Restrictions, Allowlisting, and Compliance Hooks for Vault LP Shares #274 — Implement Share Transfer Restrictions, Allowlisting, and Compliance Hooks for Vault LP Shares (Changed: src/lib/api/vaults.ts)
  3. Implement Frontend Vault Read-Path Caching, Revalidation, and Optimistic Deposit/Withdrawal State #276 — Implement Frontend Vault Read-Path Caching, Revalidation, and Optimistic Deposit/Withdrawal State (Changed: src/env.ts)

Issues

Closes #273
Closes #274
Closes #276

@drips-wave

drips-wave Bot commented Oct 21, 2026

Copy link
Copy Markdown

@emilylevi025-wq Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

techisigu and others added 5 commits October 24, 2026 12:59
- src/env.ts: merged [markers] — model resolved the conflict markers
- src/lib/api/vaults.ts: merged [markers] — model resolved the conflict markers

Co-authored-by: Simple Agent <agent@simple.dev>
- src/lib/api/vaults.ts: merged [markers] — model resolved the conflict markers

Co-authored-by: Simple Agent <agent@simple.dev>
- src/lib/api/vaults.ts: merged [markers] — model resolved the conflict markers

Co-authored-by: Simple Agent <agent@simple.dev>
- src/lib/api/vaults.ts: merged [markers] — model resolved the conflict markers

Co-authored-by: Simple Agent <agent@simple.dev>
- src/lib/api/vaults.ts: merged [markers] — model resolved the conflict markers

Co-authored-by: Simple Agent <agent@simple.dev>
@techisigu
techisigu merged commit 1c818c9 into Zenith-options:main Oct 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

2 participants