> ## Documentation Index
> Fetch the complete documentation index at: https://inflexion.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Senior & Junior tranches — the depositor product
> The dual-tranche ConvexityVault: how the premium waterfall in and the loss waterfall out create a first-loss junior buffer and a structurally protected senior tranche — with the quant's risk/return figures and the load-bearing senior-protection invariant.
The cvAMM ([Path A](/concepts/two-rails)) is more than an always-on underwriter — it
is a **depositor product**. When you deposit USDC into the `ConvexityVault` you become
the counterparty to LPs hedging their impermanent loss: you **sell convexity** and earn
the volatility-risk premium for taking the in-range IL risk LPs want to shed.
But selling volatility is not a savings account. A volatility seller earns a steady
premium in calm markets and pays out in crashes. So a single undifferentiated pool
forces every depositor onto the same risk/return point — and that point is too risky
for a conservative depositor and too tame for a vol specialist. Inflexion's answer is a
**dual-tranche vault from launch**: one pool, two claims on it.
Absorbs underwriting losses **first**, buffers senior, and earns the **larger share
of premium**. High-APY, high-variance. The "vol-seller" tranche.
Structurally **protected from underwriting loss** while the junior buffer holds.
Earns a **smaller, smoother** premium share. Exposed only to the systemic tail.
**Depositor capital is NOT guaranteed: the junior tranche is first-loss; the senior tranche is structurally protected from underwriting loss only, not systemic tail.**
Underwriting capital — whether supplied to the pooled cvAMM vault (Path A) or posted directly by a market maker (Path B) — is **at risk**:
* **Junior tranche — first-loss.** Junior depositors absorb underwriting losses first and buffer the senior tranche.
* **Senior tranche — protected from underwriting loss, exposed to the systemic tail.** The senior tranche is structurally shielded from ordinary underwriting loss while junior capital buffers, but it still takes the systemic tail once the junior buffer is exhausted.
No-bad-debt is a guarantee to the **LP being paid** (see the FULL-mode payout clause), **not** a guarantee that depositor or MM capital is preserved.
## One vault, two tranches
There is **one** `ConvexityVault` per pair, with fungible USDC backing all nine
[marketIds](/protocol/markets) for that pair (3 fee tiers × 3 durations). It is
**dual-tranche SENIOR / JUNIOR from launch** — not a roadmap upgrade, live at the
[deployed address](/reference/deployments).
The vault keeps the two tranches accounted separately end to end:
| Per-tranche state | Shared pool state |
| - | - |
| `seniorAssets` / `juniorAssets` | `totalLocked` (collateral locked across all open swaps) |
| `seniorShares` / `juniorShares` | `lockedByMarket[marketId]` (per-market lock) |
| `seniorBalanceOf` / `juniorBalanceOf` | `sumLockedSq` (O(1) Herfindahl accumulator for the [dispersion skew](/math/load-stack)) |
Two derived quantities drive everything downstream:
$$
\text{totalAssets} = \text{seniorAssets} + \text{juniorAssets},
\qquad
\text{freeAssets} = \text{totalAssets} - \text{totalLocked}
$$
`freeAssets` is what is available to underwrite the next swap; `totalLocked` is the sum
of collateral (each equal to a swap's [MaxIL](/concepts/maxil)) locked against open
positions.
## The premium waterfall — money in
Every premium paid on Path A is split before it ever touches a depositor. First the
protocol takes its cut, then the remainder is divided across the two tranches.
On `_executePathA` the premium is split **99% accrued into the vault**
(`accruePremium`) and **1% to the treasury**. There is
no per-tranche split at this layer — that happens inside the vault.
Inside `accruePremium` the pool's share is divided by
a single immutable parameter, `seniorPremiumShareBps`:
$$
\text{toSenior} = \text{amount}\cdot\frac{\text{seniorPremiumShareBps}}{10^4},
\qquad
\text{toJunior} = \text{amount} - \text{toSenior}
$$
`seniorPremiumShareBps` is **immutable** and read from the
[calibrated risk-parameter set](/reference/constants), never hardcoded.
Because senior is **protected** from underwriting loss (next section), it accepts a
**smaller slice of premium** — that is the price of safety. Junior takes the **larger
slice** as compensation for standing in front of every loss. This is the structural
reason the two tranches have genuinely different risk/return, not a cosmetic label:
senior is a low-yield "convexity savings account," junior is the high-APY vol-seller.
The premium split is purely a **distribution** of income. It does **not** touch the
no-bad-debt math, the [I10 price cap](/security/invariants), or `settle` semantics —
those are orthogonal. The tranche structure changes who earns and
who loses inside the pool; it never changes what the **LP** is paid.
## The loss waterfall — money out
When a swap settles with a positive payout, the LP is paid from locked collateral and
the loss is applied to depositors **junior-first**. The waterfall lives in
`releaseAndDistribute`:
$$
\text{juniorLoss} = \min(\text{payout},\ \text{juniorAssets}),
\qquad
\text{seniorLoss} = \text{payout} - \text{juniorLoss}
$$
Junior assets absorb the loss up to their full balance; only what spills over — if
anything — reaches senior. The waterfall first requires `payout ≤ lockedAmount`
(`PayoutExceedsCollateral`) and `lockedAmount ≤ lockedByMarket[marketId]`, then unlocks
the collateral, applies the junior-first split, transfers `payout` to the LP, and emits
`JuniorLoss`.
The `seniorLoss` arm is **defense-in-depth**. By the senior-protection invariant below,
`seniorLoss` is provably always **0** — the `min` can never bind against senior. The arm
exists so that even a future change that weakened the invariant would still fail
*closed* (junior-first) rather than silently socializing losses onto senior.
## The senior-protection invariant — why senior is structurally shielded
The reason `seniorLoss` is always 0 is a single structural invariant, enforced at
**every** `lockCollateral` via the `SeniorProtectionBreached` revert:
$$
\boxed{\ \text{totalLocked} \le \text{juniorAssets}\ }
$$
The proof that this protects senior is two lines. Every payout is capped at its swap's
MaxIL, and that swap's MaxIL is exactly the collateral locked for it. So:
$$
\sum \text{payouts} \ \le\ \text{totalLocked} \ \le\ \text{juniorAssets}
\quad\Longrightarrow\quad
\text{payout} \le \text{locked} \le \text{junior}
$$
Total underwriting loss can never exceed total locked collateral, and total locked
collateral can never exceed the junior buffer — so **junior absorbs all underwriting
loss before senior is ever touched** (see [the no-bad-debt math](/math/no-bad-debt-math)).
This is the **adaptive code form** of the roadmap's `u ≤ 1−sf` rule, keyed to the
*actual* junior buffer rather than a fixed ratio — which is strictly safer, because the
guard tracks reality (if junior shrinks, lock capacity shrinks with it). With the
calibrated target ratio `sf = 0.60`, the junior fraction is `1 − sf = 0.40`, so
`totalLocked ≤ juniorAssets` is exactly the utilization bound `u ≤ 0.40 = 1 − sf`
under which the depositor calibration holds.
**Senior protection is *calibrated*, not unconditional — and never covers the systemic tail.**
* **Limit:** "senior `P(loss) = 0`" is a calibration result, not a structural
guarantee. It holds only while utilization stays `u ≤ 1 − sf` (the regime the
invariant enforces) and only against **underwriting** loss. It does **not** shield
senior from systemic failure — a USDC depeg, an oracle/settlement fault, or a contract
bug.
* **Why:** `sf = 0.60` is a *target* tranche ratio for UX and incentives, not the hard
cap. The hard cap is the adaptive `totalLocked ≤ juniorAssets` invariant. Senior
protection from underwriting loss follows from that invariant; tail risk from a broken
*assumption* (peg, oracle, code) is outside any in-protocol waterfall.
* **Mitigation:** the invariant is checked on **every** lock and is the same accounting
that powers the [run defense](#the-run-defense) and prices the
[utilization skew](/math/load-stack) up before over-commitment. Capital-not-guaranteed
remains the umbrella for **both** tranches — see [ClaimB](#two-claims-never-merged)
above and the [risk disclosure](/risk-disclosure).
## The run defense
Both tranches share a deposit/withdraw model designed so the pool **cannot be run**
even though depositor capital is at risk:
* **Deposits are instant.** Capital can always join.
* **Withdrawals are cooldown-gated.** `requestWithdrawal` → `withdraw` only after
`withdrawalCooldown` elapses.
* **Junior cannot be drawn below `totalLocked`.** The `JuniorBelowLocked` revert
forbids withdrawing junior capital that is currently buffering live coverage.
The same locked/free accounting that prevents a run also prices the
[`util_skew`](/math/load-stack) **up** as the pool nears full commitment — so marginal
coverage gets more expensive *before* the pool over-commits, and the buffer that
protects senior is never quietly withdrawn out from under open swaps.
## The quant result — what each tranche actually earns and risks
The headline output of the [quant](/math/overview) is the depositor risk/return
profile. The figures below come from the **P1.13 heavy run** — a deliberately
adversarial model that is *stronger than GBM*: Student-t fat tails (`t_df = 4`), a
3-state Markov vol regime (calm 0.45 / normal 0.75 / stressed 1.30), tail-dependent
crash correlation → 1 (a single-pair book settles against the same move), Poisson
deep-crash months (\~0.8/yr, mean −45%), and a **lagging `σ_ref`** so coverage written
at a stress onset is underpriced exactly as it would be on-chain.
The monthly P\&L identity makes the volatility-seller nature explicit:
$$
\text{monthly\_return} = \text{utilization}\cdot\frac{\sum_i\bigl(\text{premium}_i - \text{payout}_i\bigr)}{\sum_i \text{MaxIL}_i}
$$
$$
\text{premium}_i = \text{fairRate}(\sigma_{\text{ref}})\cdot(1+\text{baseLoad})\cdot\text{MaxIL}_i
\quad\text{(income, risk-neutral at }\sigma_{\text{ref}}\text{)}
$$
$$
\text{payout}_i = \min(\text{IL}_i,\ \text{MaxIL}_i)
\quad\text{(claim, real measure)}
$$
Premium is collected under the **risk-neutral** measure at the conservative
[`σ_ref`](/math/sigma-ref); payout is paid under the **real** measure. The edge is the
gap between them — the volatility risk premium — earned in calm months and given back in
crashes.
### Bare-pool figures (unhedged, untranched)
These are the **single-asset bare pool** numbers — before tranching, before the optional
roadmap hedge — at base loads (calm/normal/stressed = 20/30/50%), gross of
demand/competition/fees. Lead with the **geometric 3y CAGR**, never the
arithmetic mean.
| Operating point | 3y CAGR (med / p10 / p90) | P(3y NAV\<1) | P(losing month) | 1-in-100 month | worst month | P(3y DD>50%) | no bad debt |
| - | - | - | - | - | - | - | - |
| **Disciplined `u = 0.40`** | **122% / 50% / 247%** | 0.3% | **26.5%** | **−20.1%** | **−26.8%** | **2.7%** | ✓ |
| Fully-deployed `u = 0.60` | 209% / 72% / 491% | 0.5% | 26.5% | −30.1% | −40.1% | 18.0% | ✓ |
How to read these:
* **3y CAGR** — the volatility risk premium compounds strongly in the median, with a
wide distribution. The p10 column (50% at `u = 0.40`) is the honest downside of the
*median run*, not the worst case.
* **P(losing month) ≈ 26.5%** — roughly one month in four is red. This is **intrinsic to
volatility selling** (you lose whenever realized vol exceeds the implied vol you priced
at), not a flaw to be tuned away.
* **1-in-100 month / worst month** — the tail of a single bad month. At `u = 0.40` a
1-in-100 month is −20.1% and the worst observed is −26.8%; both worsen materially at
`u = 0.60`.
* **P(3y DD > 50%)** — the probability of a peak-to-trough drawdown over 50% across three
years. **Utilization is the dominant drawdown lever:** `u = 0.40 → 2.7%` vs
`u = 0.60 → 18.0%`.
* **no bad debt ✓** — across **every** simulated path, `min(IL, MaxIL)/MaxIL ≤ 1.0`
(`max_payout_frac = 1.000000`). The LP guarantee holds structurally and
oracle-independently even while the depositor P\&L swings.
**The honest headline: an unhedged, untranched single-pair ETH pool CANNOT meet the spec safety targets at any *marketable* load.**
* **Limit:** the binding targets — 1-in-100 monthly loss `≤ 10%` and P(losing month)
`≤ 15%` — are unreachable for a bare single-asset pool at any load with
`premium ≤ MaxIL`.
* **Why:** these are **intrinsic to single-asset volatility selling** — you lose whenever
realized > implied, and a synchronized crash pays the whole correlated book at once. No
load setting changes that; raising load past `premium ≤ MaxIL` would mean charging more
than the maximum possible payout, which the [I10 cap](/security/invariants) forbids.
* **Mitigation:** the targets were **not loosened**. The *structural levers* are the
honest answer — and tranching is the launch one (next section). The targets were met by
changing the structure, not the bar.
### What tranching does to the picture
The dual-tranche structure is the **launch** lever that turns the bare-pool profile into
two genuinely different products:
| Tranche (`sf = 0.60`, `u = 0.40`, base loads) | Outcome |
| - | - |
| **Senior** | **`P(loss) = 0`, worst month `0%`**, gross CAGR \~197% — the "convexity savings account." Holds **jointly with `u ≤ 1 − sf`**, against underwriting loss only. |
| **Junior** | **worst `−67%`** — the high-APY first-loss vol tranche that earns the larger premium share for buffering senior. |
The senior tranche converts the bare pool's −26.8% worst month and 26.5% loss-month rate
into a **smooth, protected** return *while the junior buffer holds and utilization stays
disciplined*. The junior tranche concentrates the bare pool's downside (worst −67%) in
exchange for the larger premium slice. **Neither is risk-free** — junior can lose most of
its principal in a crash, and senior takes the systemic tail once the junior buffer is
exhausted or an assumption (peg / oracle / code) breaks.
There is a third, **roadmap** lever — a pool-side options hedge (`h ≈ 0.60`) that tightens
the *tail* (1-in-100 → \~−9.6%, P(DD>50%) → \~0%) without much CAGR change. It is
**tail-tightening, not solvency** (it carries basis risk from approximating a fixed v3
position with a perpetual options hedge), and it is **not** required for the no-bad-debt
guarantee. Tranching is the launch structure; the hedge is a future enhancement.
### The mandatory disclosure tone
The quant fixes the exact language depositor surfaces must use:
> "You earn the volatility risk premium in calm markets and absorb losses in crashes. In
> FULL the pool cannot become insolvent and cannot be run, but YOUR CAPITAL IS NOT
> GUARANTEED."
Never call it "stable" or "modest APY." APY figures are gross of demand, competition, and
fees and are model-illustrative — present the **risk panel** as the robust part and lead
with the geometric 3y CAGR, never the arithmetic mean. The model is in fact
**net-conservative** to depositors: the `σ_ref` floor of 0.50 sits *above* calm ETH vol
(\~0.45), so the pool overcharges the \~27% of months that are calm, and the heavy run's
all-months realized payout/premium came in at **0.654**.
**Structures ship from day one; the full DYNAMICS (pool-vs-MM spread as a forward-vol signal) mature with multiple competing MMs and volume. The dataset begins at the single redeploy; the off-chain telemetry halves begin at the first interaction logged.**
What Inflexion offers today is the **architecture and the first public view** into the microstructure of the DeFi LP volatility-risk premium — not yet a mature dataset:
* **Structures are present day-one.** All five non-circular behavioral signals are defined and queryable from launch.
* **Dynamics mature with volume.** The richer signal — the pool-vs-MM spread read as a forward-vol indicator — only sharpens once multiple market makers compete and real flow accumulates.
* **The dataset begins at the single redeploy**, and the off-chain telemetry halves begin at the first interaction logged. History is served live from the subgraph via the API; if a backing (subgraph URL / RPC / telemetry) is absent, surfaces degrade to a typed `pending` state — never an error.
## Two claims, never merged
The tranche structure is where the two load-bearing disclosures sit side by side. They
are **separate claims** and must never be combined.
The LP-facing guarantee is structural and oracle-independent — it holds regardless of how
the depositor P\&L moves:
**LPs are always paid with no bad debt in FULL mode — qualified: capped payoff + solvent USDC + oracle/settlement liveness.**
The no-bad-debt guarantee is **exact only** under the full clause:
* **FULL collateralization** — the underwriter has posted exactly `MaxIL` per swap, locked for the life of the position.
* **Capped payoff** — the payout is `min(realized_IL, MaxIL)`. The cap is load-bearing: it is what makes `payout ≤ collateral` hold by construction.
* **Solvent USDC** — the collateral numeraire (`dUSDC`) holds its peg and remains redeemable.
* **Oracle / settlement liveness** — the price oracle stays live and `settle()` runs within the protocol's settlement window.
* **No rehypothecation breach** — locked collateral stays instantly liquid; it is never routed to utilization-gated venues.
Stated without these qualifiers, the guarantee is **not** correct.
The depositor-facing reality is the opposite: capital is at risk for **both** tranches,
junior first.
**Depositor capital is NOT guaranteed: the junior tranche is first-loss; the senior tranche is structurally protected from underwriting loss only, not systemic tail.**
Underwriting capital — whether supplied to the pooled cvAMM vault (Path A) or posted directly by a market maker (Path B) — is **at risk**:
* **Junior tranche — first-loss.** Junior depositors absorb underwriting losses first and buffer the senior tranche.
* **Senior tranche — protected from underwriting loss, exposed to the systemic tail.** The senior tranche is structurally shielded from ordinary underwriting loss while junior capital buffers, but it still takes the systemic tail once the junior buffer is exhausted.
No-bad-debt is a guarantee to the **LP being paid** (see the FULL-mode payout clause), **not** a guarantee that depositor or MM capital is preserved.
The crucial split: the LP's no-bad-debt guarantee ([Claim A](/concepts/no-bad-debt)) is
*structural* — `collateral = MaxIL ≥ payout` by construction — and is **orthogonal to
every pricing oracle and to the tranche split**. The depositor's capital-at-risk
([Claim B](/concepts/tranches)) is the economic substance of being a volatility seller.
Senior protection sits *inside* Claim B (it reduces, but does not eliminate, junior-then-
systemic risk); it is not a separate guarantee and never reaches across to the LP side.
**Network:** Arbitrum Sepolia · **chainId** `421614` · **deploy block** `274081134` (subgraph startBlock) · **deployed** 2026-06-05
## Core protocol
| Contract | Address | Role |
| - | - | - |
| InflexionCore | `0xC19865cF8403F59B8Eca835833aFEe3Aa8DA4848` | Main entry point — quotes, createSwap, settlement |
| ILVault | `0x9f7615Aca943832977CEf3ac1862fD48B87b7664` | Holds LP premiums and protocol IL accounting |
| UnderwriterVault | `0x4Fb459F3393D206c2b7faD7f0fC9C35a78348D64` | Market-maker (Path B) collateral deposits |
| ConvexityVault | `0xDE2fFeBA2E6A18f3A53D43EC0fCCD299158eC30d` | Pooled cvAMM (Path A) underwriter collateral |
| Treasury | `0x96455C9b00D530BD0629b71B674298440328b1Dd` | Protocol fee recipient (also deployer) |
## Stylus & libraries
| Contract | Address | Role |
| - | - | - |
| FairValueOracle (Stylus) | `0x98a6aa75108b70fc0794bc3b87efe0ae99d5d52c` | Rust/WASM fair-premium pricing (set-once init to live VolOracle) |
| ILMath | `0x7e90362bc6Df9cb5faA13952e07853ab16c77bd2` | Core impermanent-loss math |
| TickMath (library) | `0xbf02bbc82e0fb1a4b9828bb90fc9dd9e97578965` | Tick ↔ sqrtPrice conversions (delegatecall) |
| CvammPricing (library) | `0x4a053d29a55a64172140f9ebbc27c321c0ba2b53` | Path-A pool pricing components (delegatecall) |
| SwapMath (library) | `0xf7be9745b6768d06a18c386c6db5c8cb065ba314` | Swap math helpers (delegatecall) |
| QuoteVerification (library) | `0x74819eed322f3e1a2dc10bb0d3cae50078d90807` | EIP-712 quote signature verification (delegatecall) |
## Oracles
| Contract | Address | Role |
| - | - | - |
| OracleManager | `0x2c18147B6ec75dcb330d9A48B6B96a4d1a8b529b` | Chainlink feed router, staleness & sequencer checks |
| VolOracle | `0xfdEafBB381192FC5337499d041eaead04d565Ed9` | Realized-volatility reference (sigma\_ref) |
## Uniswap
| Contract | Address | Role |
| - | - | - |
| UniswapV3Factory | `0x248AB79Bbb9bC29bB72f7Cd42F17e054Fc40188e` | v3 pool factory |
| NonfungiblePositionManager | `0x6b2937Bde17889EDCf8fbD8dE31C3C2a70Bc4d65` | LP position NFTs |
| SwapRouter02 | `0x101F443B4d1b059569D643917553c771E1b9663E` | Swap routing |
| QuoterV2 | `0x2779a0CC1c3e0E44D2542EC3e79e3864Ae93Ef0B` | Off-chain swap quoting |
## Chainlink feeds
| Contract | Address | Role |
| - | - | - |
| ETH / USD | `0xd30e2101a97dcbAeBCBC04F14C3f624E67A35165` | Price feed (8 dec, \~120s heartbeat) |
| BTC / USD | `0x56a43EB56Da12C0dc1D972ACb089c06a5dEF8e69` | Price feed (8 dec, \~120s heartbeat) |
| ARB / USD | `0xD1092a65338d049DB68D7Be6bD89d17a0929945e` | Price feed (8 dec, 86400s heartbeat) |
| USDC / USD | `0x0153002d20B96532C639313c2d54c3dA09109309` | Price feed (8 dec, 86400s heartbeat) |
## Demo tokens / pool / LP
| Contract | Address | Role |
| - | - | - |
| WETH9 | `0x980B62Da83eFf3D4576C647993b0c1D7faf17c73` | Canonical Arbitrum Sepolia WETH (18 dec) |
| USDC (Circle) | `0x75faf114eafb1BDbe2F0316DF893fd58CE46AA4d` | Circle native testnet USDC (6 dec) |
| dWETH (demo) | `0xA8C07E1B245B346c5D1910c5055Efe67bF9E7D1D` | Mock WETH, oracle-priced via Chainlink ETH/USD (18 dec) |
| dUSDC (demo) | `0xB89630Dc6e020ae2A84aE72b7d9EEDBDfb2C544d` | Mock USDC numeraire (6 dec) |
| Demo pool (dWETH/dUSDC, fee 500) | `0xfE1Eb4D5796a350B13852F822B3E6a9fDbb858a5` | Seeded v3 pool, tokenId 3218 \~\$100k unprotected LP |
## Lifecycle swaps
| Contract | Address | Role |
| - | - | - |
| Market maker (demo signer) | `0xe632B215120dD43A719458487bA3e03638fec953` | Path-B underwriter; deposited 5,000 dUSDC, own collateral paid settlement |
Live create→settle lifecycle (2026-06-05, short 300s fee-500 market `0xb8bbd684f213d5833886ade7b531a6949d85522249881a2b5d46a5cc76e439c2`):
* **Path A (cvAMM convexity)** — swapId 1, LP tokenId 3220 · V0 \$270,531.28 · MaxIL \$1,669.24 · premium \$9.70 (0.58% of MaxIL) · settled payout \$148.64 from ConvexityVault.
* **Path B (MM routing)** — swapId 2, LP tokenId 3221 · MM beat cvAMM (\$8.93 vs \$13.80) · MaxIL \$3,215.65 · MM collateral locked \$3,215.65 · settled payout \$245.66 from MM collateral.
## Where to go next
Deposit into senior or junior, see the live risk panel, and request a withdrawal.
The full statement of what each tranche risks and earns.
Path A end to end: pricing, locking, accrual, and the waterfall.
Why the LP guarantee is structural and orthogonal to the tranche split.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.