> For the complete documentation index, see [llms.txt](https://perena.gitbook.io/perena/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://perena.gitbook.io/perena/protocol/perena-vault-v2/vault-v2-whitepaper.md). # Vault V2 Whitepaper ### A Programmatic Structured Credit Framework for Solana *** ### Abstract Most on-chain vaults collapse capital into a single undifferentiated share token. This is efficient for simple yield aggregation, but structurally insufficient for the next phase of on-chain credit markets. A treasury seeking predictable stablecoin income, a DeFi participant seeking levered upside, and an issuer seeking structured distribution are forced into the same risk-return profile. Perena Vaults introduce a programmatic structured credit framework for Solana. A single managed pool of assets can issue multiple tokenized claims against the same underlying portfolio, beginning with a senior tranche and a junior tranche. The senior tranche targets a fixed-style return and benefits from first-loss protection. The junior tranche absorbs initial losses and receives residual upside. This creates a programmable capital stack: one pool, multiple risk profiles, code-enforced priority. The system combines tranche accounting, net asset value validation, queued subscription and redemption, concentration limits, scoped operational authority, high-water mark fee accounting, and optional return-smoothing mechanics. The result is infrastructure for creating on-chain structured credit products that are transparent, composable, and continuously auditable. This paper formalizes the Perena Vault model, the tranche waterfall, the loss-allocation function, haircut scenarios, high-water mark mechanics, and the security boundaries required to operate structured financial instruments on-chain. *** ## 1. Motivation: From Yield Aggregation to Structured Credit The first generation of DeFi vaults solved a distribution problem. Users could deposit assets into a pool, receive a share token, and outsource strategy execution to a manager, protocol, or automated allocator. The share token represented a pro rata claim on a blended pool of risk. This design is useful, but incomplete. A single-token vault has no native language for capital structure. It cannot distinguish between senior capital and first-loss capital. It cannot sell predictability to one user and convexity to another. It cannot transform one risky portfolio into multiple risk-adjusted instruments. Every depositor receives the same blended exposure. Traditional credit markets solved this through tranching. A pool of assets can be divided into prioritized claims. Senior claims receive payments first and absorb losses last. Junior claims receive residual upside but absorb losses first. This structure is the foundation of collateralized loan obligations, asset-backed securities, mortgage-backed securities, structured notes, and many forms of private credit. Perena brings this design pattern on-chain. The goal is not to copy traditional structured finance blindly. The goal is to make the useful part programmable: transparent waterfall logic, explicit first-loss capital, automated NAV-based accounting, constrained asset deployment, and composable tokenized claims. In short: > Stablecoins made dollars programmable. > > DeFi made liquidity programmable. > > Perena Vaults make risk programmable. *** ## 2. System Overview A Perena Vault is a managed on-chain pool that holds approved assets, deploys capital into approved strategies, and issues tranche tokens representing different claims on the same underlying portfolio. At launch, the canonical structure contains two tranches: | Tranche | Economic Role | Payment Priority | Loss Priority | Target User | | ------- | ----------------------- | ----------------- | ------------------ | -------------------------------------------- | | Senior | Fixed-style yield claim | Paid first | Loses after junior | Treasuries, allocators, stablecoin holders | | Junior | Residual / equity claim | Paid after senior | Loses first | Yield-seekers, risk underwriters, DeFi users | The senior tranche is not risk-free. It is protected by the junior tranche up to the size of the junior capital buffer. If portfolio losses exceed that buffer, senior holders can be impaired. The junior tranche is not merely “higher APY.” It is structurally levered exposure to the performance of the vault. When the pool performs above the senior target return, residual gains accrue to junior holders. When the pool loses value, junior holders absorb the first loss. The central mechanism is the **programmatic waterfall**. At each valuation epoch, the vault: 1. Marks the portfolio to current NAV. 2. Validates freshness and admissibility of pricing inputs. 3. Accrues the senior target return. 4. Allocates value first to the senior claim. 5. Allocates residual value to the junior claim. 6. Applies applicable fees subject to high-water mark constraints. 7. Updates tranche share prices. 8. Enforces risk, accounting, and operational invariants. This creates a financial instrument whose payoff profile is determined by code rather than manual calculation, spreadsheet reconciliation, or discretionary allocation. *** ## 3. Notation Let time be indexed by valuation epochs `t = 0, 1, 2, ...`. ### 3.1 Vault-level variables Let: `V_t` = total allocable NAV of the vault at epoch `t`, after validated marking and before final tranche allocation. `A_t` = raw marked value of all assets held by the vault. `R_t` = smoothing reserve, if enabled. `F_t` = fees accrued or crystallized at epoch `t`. `Δt` = elapsed time since the previous valuation epoch, measured in years. `r_S` = senior target annualized rate. `r_cap` = maximum recognized APY between valuation epochs, if return smoothing is enabled. ### 3.2 Tranche variables Let: `Q^S_t` = senior shares outstanding. `Q^J_t` = junior shares outstanding. `B^S_t` = senior target claim, meaning the amount of value required to make senior holders whole according to principal plus accrued target return. `V^S_t` = value allocated to the senior tranche. `V^J_t` = value allocated to the junior tranche. `P^S_t` = senior share price. `P^J_t` = junior share price. Then: `P^S_t = V^S_t / Q^S_t` `P^J_t = V^J_t / Q^J_t` provided the relevant share count is non-zero. ### 3.3 Capital structure ratios Define the senior attachment point as the portfolio loss level at which the senior begins to lose value. Let: `S_t = B^S_t` `J_t = max(V_t - B^S_t, 0)` The junior buffer as a percentage of vault NAV is: `σ_t = J_t / V_t` The senior overcollateralization ratio is: `OC_t = V_t / B^S_t` If `OC_t ≥ 1`, the senior claim is fully covered. If `OC_t < 1`, the senior tranche is impaired. The senior impairment amount is: `I^S_t = max(B^S_t - V_t, 0)` The junior tranche is exhausted when: `V_t ≤ B^S_t` or equivalently: `OC_t ≤ 1` *** ## 4. The Programmatic Waterfall The tranche waterfall determines how value is allocated between senior and junior holders. ### 4.1 Senior target accrual The senior tranche accrues a target return over time. In simple discrete form: `B^S_t = B^S_{t-1} × (1 + r_S × Δt) + D^S_t - W^S_t` where: `D^S_t` = fulfilled senior deposits during the epoch. `W^S_t` = fulfilled senior withdrawals or redemptions during the epoch. For higher precision, the vault may use continuous compounding: `B^S_t = B^S_{t-1} × e^(r_S × Δt) + D^S_t - W^S_t` The senior target claim is not a guarantee. It is a priority claim against vault NAV. If NAV is sufficient, senior holders accrue toward the target. If NAV is insufficient after junior exhaustion, senior holders are impaired. ### 4.2 Allocation rule Once the vault has a validated NAV, value is allocated as follows: `V^S_t = min(V_t, B^S_t)` `V^J_t = max(V_t - B^S_t, 0)` This simple function encodes the full senior/junior priority structure. The senior receives value up to its target claim. The junior receives residual value after the senior target claim has been satisfied. If losses occur, the junior absorbs those losses first because the junior value is the residual claim. ### 4.3 Loss allocation Suppose the vault has pre-shock NAV: `V` Senior target claim: `S` Junior value: `J = V - S` Now suppose the portfolio suffers a loss: `L` Post-shock NAV is: `V' = V - L` Post-shock tranche values are: `V^J' = max(J - L, 0)` `V^S' = S - max(L - J, 0)` Senior loss is: `Loss_S = max(L - J, 0)` Junior loss is: `Loss_J = min(L, J)` The senior begins losing value only when: `L > J` The portfolio loss threshold before senior impairment is: `L* = J` As a percentage of portfolio NAV: `ℓ* = J / V` This is the core structural protection of the senior tranche. ## 5. Haircut Modeling Haircut modeling is central to understanding tranche behavior. A portfolio haircut can be represented in two ways: 1. **Total portfolio haircut:** the entire portfolio declines by `h%`. 2. **Exposure-specific haircut:** a position representing `w%` of the portfolio suffers a haircut of `λ%`. For exposure-specific haircuts, the total portfolio loss is: `L = V × w × λ` The portfolio-level loss percentage is: `ℓ = w × λ` Example: A 5% portfolio position that suffers a 100% write-down creates a 5% portfolio loss. A 10% portfolio position that suffers a 50% haircut also creates a 5% portfolio loss. A 15% protocol exposure that suffers a 40% haircut creates a 6% portfolio loss. *** ## 6. Base Case: $10M Vault, 80/20 Capital Structure Assume the vault begins with: `V_0 = $10,000,000` `S_0 = $8,000,000` `J_0 = $2,000,000` Senior target APY: `r_S = 6%` Initial senior share price: `P^S_0 = $1.00` Initial junior share price: `P^J_0 = $1.00` Initial junior buffer: `σ_0 = J_0 / V_0 = 20%` Initial overcollateralization: `OC_0 = V_0 / S_0 = 125%` In this structure, the first 20% of portfolio loss is absorbed by the junior tranche before the senior is impaired. ### 6.1 Immediate haircut scenarios, before senior accrual The following table assumes an instantaneous portfolio loss at inception, before senior coupon accrual. | Portfolio NAV Loss | Dollar Loss | Senior Value | Senior Loss | Junior Value | Junior Loss | OC Ratio | | ------------------ | ----------- | ------------ | ----------- | ------------ | ----------- | -------- | | 0% | $0 | $8.00M | 0.00% | $2.00M | 0.00% | 125.0% | | 5% | $0.50M | $8.00M | 0.00% | $1.50M | 25.00% | 118.8% | | 10% | $1.00M | $8.00M | 0.00% | $1.00M | 50.00% | 112.5% | | 15% | $1.50M | $8.00M | 0.00% | $0.50M | 75.00% | 106.3% | | 20% | $2.00M | $8.00M | 0.00% | $0.00M | 100.00% | 100.0% | | 25% | $2.50M | $7.50M | 6.25% | $0.00M | 100.00% | 93.8% | | 40% | $4.00M | $6.00M | 25.00% | $0.00M | 100.00% | 75.0% | This table is the cleanest explanation of the product. A 5% portfolio loss does not mean the senior loses 5%. With a 20% junior buffer, a 5% portfolio loss is fully absorbed by junior capital. The junior tranche experiences a 25% loss because the junior is levered exposure to the first-loss layer. A 20% portfolio loss exhausts the junior tranche but does not impair senior principal. A 25% portfolio loss exhausts the junior and impairs the senior by 6.25%. This is the capital structure doing its job. *** ## 7. Exposure-Specific Haircut Examples The previous table treats the entire vault portfolio as if it experiences a uniform NAV decline. Real portfolios lose money through specific exposures: a lending market depegs, a tokenized T-bill issuer gates withdrawals, a strategy takes a basis loss, or a venue-specific position is written down. Let: `w_i` = portfolio weight of exposure `i` `λ_i` = haircut severity of exposure `i` Then: `Portfolio Loss = Σ(w_i × λ_i)` Assume again a $10M vault with $8M senior and $2M junior. ### 7.1 Single-position shock examples | Exposure | Exposure Weight | Haircut Severity | Portfolio Loss | Senior Outcome | Junior Outcome | | -------------------------------- | --------------- | ---------------- | -------------- | ----------------------- | ------------------ | | Small strategy full write-down | 5% | 100% | 5.0% | Unimpaired | Junior loses 25% | | Max 10% strategy full write-down | 10% | 100% | 10.0% | Unimpaired | Junior loses 50% | | 15% protocol 50% haircut | 15% | 50% | 7.5% | Unimpaired | Junior loses 37.5% | | 15% protocol full write-down | 15% | 100% | 15.0% | Unimpaired | Junior loses 75% | | Two 15% protocols each down 50% | 30% | 50% | 15.0% | Unimpaired | Junior loses 75% | | Correlated 30% book down 80% | 30% | 80% | 24.0% | Senior impaired by 5.0% | Junior wiped out | This table shows why concentration limits matter. If a vault limits any single strategy to 10% of NAV, then a complete write-down of one max-sized strategy creates a 10% portfolio loss. With a 20% junior buffer, the senior remains protected. If a vault limits any single protocol to 15% of NAV, then even a complete write-down of that protocol creates a 15% portfolio loss. The junior is severely impaired, but the senior remains protected. The senior becomes vulnerable when losses are either: 1. Larger than the junior buffer, or 2. Correlated across multiple exposures, or 3. Caused by a system-wide event that affects the portfolio faster than the vault can rebalance. The design objective is not to pretend those risks do not exist. The objective is to define them, measure them, cap them, and make the loss waterfall explicit. *** ## 8. Coupon Accrual and Buffer Decay The senior tranche accrues a target return over time. This matters because the junior buffer is not static. If the portfolio does not generate enough return to pay the senior target, the senior claim grows relative to total NAV, and the junior buffer shrinks. Assume: `V_0 = $10,000,000` `S_0 = $8,000,000` `J_0 = $2,000,000` `r_S = 6%` After one year, the senior target claim becomes: `B^S_1 = $8,000,000 × 1.06 = $8,480,000` Now suppose the gross portfolio return over the year is 0%. Vault NAV remains: `V_1 = $10,000,000` The junior residual becomes: `J_1 = $10,000,000 - $8,480,000 = $1,520,000` The junior buffer has declined from 20.0% of NAV to 15.2% of NAV. This is economically correct. The senior coupon is not free. If the portfolio does not earn the senior target, the economic burden is borne by junior capital. ### 8.1 Haircut scenarios after one year of zero gross return | Scenario | Post-Coupon Pre-Shock NAV | Senior Target Claim | Junior Buffer | Additional Portfolio Loss | Senior Value | Junior Value | | --------- | ------------------------- | ------------------- | ------------- | ------------------------- | ------------ | ------------ | | No shock | $10.00M | $8.48M | $1.52M | 0% | $8.48M | $1.52M | | 5% shock | $10.00M | $8.48M | $1.52M | $0.50M | $8.48M | $1.02M | | 10% shock | $10.00M | $8.48M | $1.52M | $1.00M | $8.48M | $0.52M | | 15% shock | $10.00M | $8.48M | $1.52M | $1.50M | $8.48M | $0.02M | | 20% shock | $10.00M | $8.48M | $1.52M | $2.00M | $8.00M | $0.00M | A senior holder can look “protected” in the initial 80/20 structure, but the protection level depends on current overcollateralization, not initial overcollateralization. Therefore, the vault should continuously publish: `OC_t = V_t / B^S_t` `σ_t = max(V_t - B^S_t, 0) / V_t` `Distance to senior impairment = V_t - B^S_t` This is the on-chain equivalent of structured credit surveillance. *** ## 9. Upside Allocation and Junior Leverage When the portfolio performs above the senior target, the junior receives residual upside. Assume again: `V_0 = $10M` `S_0 = $8M` `J_0 = $2M` `r_S = 6%` After one year, suppose the portfolio returns 10%. Vault NAV becomes: `V_1 = $11M` Senior target claim becomes: `B^S_1 = $8M × 1.06 = $8.48M` Junior residual becomes: `J_1 = $11M - $8.48M = $2.52M` Senior return: `($8.48M - $8.00M) / $8.00M = 6.0%` Junior return: `($2.52M - $2.00M) / $2.00M = 26.0%` The portfolio returned 10%. The junior returned 26%. This is because junior is a residual claim on the pool after paying the senior cost of capital. Junior holders are effectively underwriting the senior tranche in exchange for levered exposure to portfolio performance. The junior return can be expressed as: `R_J = (V_1 - B^S_1 - J_0) / J_0` If the portfolio return is `R_P`, and the senior rate is `r_S`, then with initial senior capital `S_0` and junior capital `J_0`: `R_J = [(S_0 + J_0)(1 + R_P) - S_0(1 + r_S) - J_0] / J_0` Simplifying: `R_J = [(S_0 + J_0)R_P - S_0r_S] / J_0` Let leverage ratio be: `L_J = (S_0 + J_0) / J_0` and senior funding burden be: `C_S = S_0 / J_0` Then: `R_J = L_J × R_P - C_S × r_S` describes the junior tranche only before the first-loss layer has been exhausted. Below that point, the junior tranche is wiped out, and additional losses begin to impair the senior tranche. In the 80/20 example: `L_J = 10 / 2 = 5` `C_S = 8 / 2 = 4` So: `R_J = 5R_P - 4r_S` In the 80/20 example with a 6% senior target, the junior break-even threshold is a portfolio return of -15.2%; below that, junior value is zero, the junior tranche is wiped out, and the linear return formula no longer applies. If `R_P = 10%` and `r_S = 6%`: `R_J = 5 × 10% - 4 × 6% = 50% - 24% = 26%` This is the junior tranche in one equation. It is not simply “higher APY.” It is a levered residual claim. *** ## 10. Return Smoothing and APY Recognition Caps Structured credit products should not mark share prices in a way that creates artificial cliffs, obvious timing opportunities, or sudden APY spikes that can be exploited by opportunistic depositors. For this reason, Perena Vaults may include a smoothing reserve and maximum recognized APY parameter. Let: `A_t` = raw marked NAV. `V_t` = allocable NAV recognized for tranche share pricing. `r_cap` = maximum APY that can be recognized between valuation epochs. Then the maximum recognized NAV at epoch `t` can be expressed as: `V_t^max = V_{t-1} × (1 + r_cap × Δt)` If raw marked NAV exceeds the maximum recognized NAV: `A_t > V_t^max` then the excess may be credited to a smoothing reserve: `R_t = R_{t-1} + (A_t - V_t^max)` and allocable NAV becomes: `V_t = V_t^max` The smoothing reserve can later be released under defined conditions, such as: 1. Funding senior target return during periods of temporary underperformance. 2. Gradually recognizing previously unrecognized gains. 3. Reducing volatility in tranche share prices. 4. Preventing short-interval mark manipulation from producing excessive share-price jumps. The reserve should not be treated as discretionary profit. It is part of the vault’s economic balance sheet and must be governed by explicit release rules. A conservative release rule could be: `Release_t = min(R_{t-1}, Senior Shortfall_t, Release Cap_t)` where: `Senior Shortfall_t = max(B^S_t - V_t, 0)` This means reserve assets can support the senior target before junior capital is further impaired, but only if those reserves were previously accumulated from realized or recognized portfolio gains. The important design principle is that return smoothing should not obscure risk. The vault should report both: `Raw NAV = A_t` and `Allocable NAV = V_t` as well as: `Smoothing Reserve = R_t` Investors should be able to observe whether senior stability comes from recurring portfolio income, junior subordination, reserve release, or some combination of the three. ## 11. High-Water Mark Fee Accounting Performance fees in structured vaults must be handled carefully. Without high-water mark accounting, a manager could charge performance fees multiple times on the same recovery, or charge new depositors for gains they did not experience. Perena’s high-water mark system should be share-price based. For tranche `k`, where `k ∈ {S, J}`, define: `H^k_t` = high-water mark for tranche `k` at epoch `t`. `P^{k,pre}_t` = pre-fee share price for tranche `k`. `P^{k,post}_t` = post-fee share price for tranche `k`. `φ_k` = performance fee rate for tranche `k`. Performance fee is charged only on new gains above the previous high-water mark: `Gain^k_t = max(P^{k,pre}_t - H^k_{t-1}, 0) × Q^k_t` `PerfFee^k_t = φ_k × Gain^k_t` The post-fee share price becomes: `P^{k,post}_t = P^{k,pre}_t - PerfFee^k_t / Q^k_t` The high-water mark updates to the post-fee share price: `H^k_t = max(H^k_{t-1}, P^{k,post}_t)` This makes the high-water mark net of fees. ### 11.1 Example: junior high-water mark Assume: Initial junior share price: `P^J_0 = $1.00` Initial high-water mark: `H^J_0 = $1.00` Performance fee: `φ_J = 20%` At the next crystallization, suppose the junior pre-fee share price is: `P^{J,pre}_1 = $1.30` New gain above high-water mark: `$1.30 - $1.00 = $0.30` Performance fee per share: `20% × $0.30 = $0.06` Post-fee share price: `P^{J,post}_1 = $1.24` New high-water mark: `H^J_1 = $1.24` Now suppose the junior share price falls to $1.10 and later recovers to $1.20. No performance fee is charged, because the share price remains below the $1.24 high-water mark. If the junior later reaches a pre-fee price of $1.30 again, the fee is charged only on: `$1.30 - $1.24 = $0.06` Fee per share: `20% × $0.06 = $0.012` Post-fee share price: `$1.288` New high-water mark: `$1.288` The manager is compensated only for new net value creation. ### 11.2 Series-based high-water marks for continuous subscriptions A single global high-water mark works if no new shares are minted between crystallization periods. But Perena Vaults allow subscriptions over time. New depositors should not pay fees on gains earned before they entered. The more precise design is **series-based high-water mark accounting**. Each subscription epoch creates a share series with its own high-water mark: `H^k_{e,t}` where: `e` = subscription epoch or share series. New shares minted at epoch `e` begin with: `H^k_{e,e} = P^k_e` At crystallization, performance fees are computed separately for each series: `Gain^k_{e,t} = max(P^{k,pre}_t - H^k_{e,t-1}, 0) × Q^k_{e,t}` `PerfFee^k_{e,t} = φ_k × Gain^k_{e,t}` After fees are crystallized, series with equalized high-water marks can be merged to reduce accounting complexity. This prevents cross-subsidization between old and new investors. For an investor-grade structured credit product, this distinction matters. *** ## 12. Subscription, Fulfillment, and Redemption Instant minting and instant redemption are convenient, but they create adverse selection problems when NAV is updated periodically or when underlying assets are less liquid than the vault token. Perena uses a three-stage lifecycle: 1. **Subscribe** 2. **Fulfill** 3. **Claim** ### 12.1 Subscribe A user submits an asset to the vault. The asset is locked in a program-controlled account. No shares are minted at this stage. This is important because the user should not receive shares against stale NAV. ### 12.2 Fulfill At fulfillment, the vault establishes a fresh NAV. The program verifies: * Asset prices are fresh. * Required oracle inputs are present. * Venue marks are within configured staleness thresholds. * The vault remains within concentration limits. * The action does not violate rolling withdrawal limits. * The action does not break tranche accounting invariants. Only after these checks pass are shares priced and minted. ### 12.3 Claim After fulfillment, the user claims the minted tranche shares or redeemed assets. If a request has not yet been fulfilled, it can be cancelled according to vault rules, returning the original pending asset. ### 12.4 Why queueing matters The queue prevents a user from entering or exiting against a stale or manipulable price. Without a queue, an informed actor could observe that the vault’s reported NAV is stale, submit capital before a favorable mark, or redeem before an unfavorable mark. The queue converts vault entry and exit from a race against stale accounting into a deterministic process based on a freshly validated valuation event. This is not merely a UX choice. It is a market integrity mechanism. *** ## 13. NAV Validation The vault’s NAV is the foundation of the entire system. If NAV is wrong, tranche pricing is wrong, subscriptions are wrong, redemptions are wrong, fees are wrong, and high-water marks are wrong. Therefore, NAV validation must be treated as a first-class protocol function. A vault’s NAV can be decomposed as: `A_t = Σ_i PositionValue_{i,t}` For each position `i`: `PositionValue_{i,t} = Quantity_{i,t} × Price_{i,t} × LiquidityAdjustment_{i,t}` Where appropriate, the liquidity adjustment can reflect: * Withdrawal gates. * Maturity mismatch. * Market depth. * Slippage on exit. * Haircut assumptions. * Oracle confidence intervals. * Off-chain settlement delay. A conservative structured credit vault should not mark every asset at optimistic spot price. It should mark according to realizable value under defined exit assumptions. ### 13.1 NAV freshness Each pricing input should have a timestamp. Let: `τ_i` = timestamp of price input for position `i`. `T_t` = current epoch timestamp. `θ_i` = maximum allowed staleness for position `i`. Then the pricing input is valid only if: `T_t - τ_i ≤ θ_i` If any required price is stale, the vault should block settlement-sensitive actions such as minting, redemption fulfillment, and fee crystallization. ### 13.2 NAV quorum and deviation bounds For higher-value vaults, NAV should not depend on a single reporter. Let there be `m` authorized NAV reporters. Each reporter submits: `A^{(j)}_t` for reporter `j`. A valid NAV can require: 1. Minimum quorum: at least `q` reporters. 2. Maximum deviation: submitted values must lie within an accepted band. 3. Median or trimmed mean aggregation. For example: `A_t = median(A^{(1)}_t, A^{(2)}_t, ..., A^{(m)}_t)` subject to: `max_j |A^{(j)}_t - A_t| / A_t ≤ ε` where `ε` is the maximum allowed deviation. If deviation exceeds the threshold, settlement is halted until resolved. This converts NAV reporting from a trusted input into a bounded consensus process. *** ## 14. Concentration Limits and Structural Resilience Tranching protects the senior only if losses remain inside the junior buffer. Concentration limits help bound how large a single loss can become. Let: `w_strategy_i` = NAV percentage allocated to strategy `i`. `w_protocol_j` = NAV percentage allocated to protocol `j`. A vault can enforce: `w_strategy_i ≤ c_strategy` `w_protocol_j ≤ c_protocol` For example: `c_strategy = 10%` `c_protocol = 15%` These caps create a relationship between exposure design and tranche safety. If the junior buffer is 20% and no single strategy can exceed 10%, then a complete write-down of one strategy cannot impair senior capital, assuming marks are accurate and losses are not correlated. If no single protocol can exceed 15%, then even a full protocol write-down remains inside a 20% junior buffer. This does not eliminate risk. It bounds single-name risk. The relevant question becomes: > What combination of correlated failures is required to pierce the junior buffer? That is the correct institutional framing. *** ## 15. Correlated Loss and Stress Testing Structured products fail when correlation rises. A vault may look diversified across ten positions, but if all ten depend on the same stablecoin, oracle, custodian, bridge, market maker, or liquidity venue, then the economic risk is not actually diversified. Therefore, Perena Vaults should model risk at multiple levels: 1. Asset exposure. 2. Strategy exposure. 3. Protocol exposure. 4. Counterparty exposure. 5. Oracle exposure. 6. Custody or issuer exposure. 7. Liquidity exposure. 8. Stablecoin exposure. 9. Smart-contract dependency. 10. Economic risk factor. Let there be risk factors `f = 1, ..., n`. Each position `i` has loading: `β_{i,f}` to risk factor `f`. If risk factor `f` experiences shock `s_f`, then portfolio loss is approximately: `L = V × Σ_i Σ_f w_i β_{i,f} s_f` This is a simplified linear model, but it makes the important point: diversification across positions is not the same as diversification across risk factors. A more sophisticated vault surveillance report should include: * Single-position shock. * Single-protocol shock. * Stablecoin depeg shock. * Liquidity exit shock. * Funding-rate compression shock. * Oracle delay shock. * Correlated Solana DeFi venue shock. * Maximum drawdown before senior impairment. * Time-to-liquidate under stressed liquidity. For each stress, the output should show: `Senior impairment = max(L - J, 0)` `Junior impairment = min(L, J)` `Post-stress OC = (V - L) / B^S` This is how the vault turns “trust us” into observable risk math. ## 16. Fee Architecture Perena Vaults can support several fee types: 1. Management fee. 2. Protocol fee. 3. Performance fee. 4. Redemption or unstake fee. 5. Early withdrawal fee. 6. Strategy-specific fee sharing. ### 16.1 Management fee A management fee can accrue continuously on NAV: `MgmtFee_t = m × V_t × Δt` where: `m` = annual management fee rate. This fee should be charged before final tranche allocation or according to a disclosed fee waterfall. The cleanest approach is to treat management and protocol fees as vault-level expenses: `V_t^{after fees} = V_t^{before fees} - MgmtFee_t - ProtocolFee_t` Then allocate remaining NAV to senior and junior via the waterfall. ### 16.2 Performance fee Performance fees should be charged only on gains above high-water mark, as described in Section 11. Performance fee design should differ by tranche. A conservative approach: * Senior performance fee is zero or limited, because senior buyers are purchasing target yield, not active upside. * Junior performance fee is applied to residual gains above junior high-water mark. * Strategy manager economics are therefore aligned with the tranche that receives upside. This is cleaner than charging performance fees on senior coupon accrual, which may make the advertised senior target return harder to interpret. ### 16.3 Junior redemption fee A junior redemption fee can compensate the vault for liquidity and adverse selection risk. If junior capital is the first-loss buffer, rapid junior exits during stress can weaken senior protection. A junior redemption fee can be routed back into the vault: `RedemptionFee_t = ψ × RedemptionAmount_t` where `ψ` is the fee rate. Economically, this makes exiting junior capital compensate remaining holders for the reduction in protection. In stressed conditions, the vault may also apply: * Lockups. * Notice periods. * Rolling withdrawal caps. * Pro rata redemption fulfillment. * Circuit-breaker halts. These are not cosmetic constraints. They preserve the integrity of the capital stack. *** ## 17. Accounting Invariants A structured vault must enforce invariants at every valuation and state transition. ### 17.1 Conservation of value Ignoring fees, slippage, and external P\&L: `V_t = V^S_t + V^J_t` If smoothing reserve is enabled: `A_t = V^S_t + V^J_t + R_t` depending on whether reserve is included in allocable or non-allocable NAV. The implementation must specify this treatment precisely. ### 17.2 Senior priority The senior tranche cannot receive less than junior while senior target value remains unsatisfied. Formally: If `V_t < B^S_t`, then: `V^J_t = 0` and: `V^S_t = V_t` ### 17.3 Junior residual The junior tranche cannot receive value until senior target value is satisfied. If `V_t > B^S_t`, then: `V^S_t = B^S_t` and: `V^J_t = V_t - B^S_t` ### 17.4 Non-negative tranche value `V^S_t ≥ 0` `V^J_t ≥ 0` ### 17.5 High-water mark monotonicity For each tranche or series: `H^k_t ≥ H^k_{t-1}` High-water marks can stay flat or increase. They cannot decrease. ### 17.6 Staleness blocking If any required price input is stale: `T_t - τ_i > θ_i` then settlement-sensitive instructions must fail. ### 17.7 Concentration compliance After any manager action: `w_strategy_i ≤ c_strategy` `w_protocol_j ≤ c_protocol` If an action would violate concentration caps, it should revert. ### 17.8 Scoped authority An operational key authorized for one action should not be able to perform another action. A manager key should not be able to reconfigure the vault. A fulfiller key should not be able to move funds except through the fulfillment instruction. A circuit-breaker key should be able to halt but not steal. This is the operational equivalent of least-privilege access control. *** ## 18. Execution Boundary The vault should not be able to interact with arbitrary programs, arbitrary mints, or arbitrary accounts at runtime. The execution boundary consists of: 1. Asset allowlist. 2. Venue registry. 3. Strategy allowlist. 4. Account pinning. 5. Scoped delegates. 6. Instruction-level validation. 7. Concentration caps. 8. Rolling movement limits. 9. Circuit breaker. ### 18.1 Asset allowlist The vault can accept and hold only approved mints. This prevents accidental or malicious introduction of unapproved collateral. ### 18.2 Venue registry The vault can interact only with approved venues. Adding a new venue should require curator-level authorization, audit review, and ideally a timelock before activation. ### 18.3 Account pinning The program should verify that accounts passed into instructions correspond to expected program-derived addresses or approved venue accounts. This prevents malicious account substitution. ### 18.4 Scoped delegates Operational authority should be narrow. A hot wallet that reports NAV should not be able to withdraw assets. A manager that rebalances within Kamino should not be able to redirect funds to an arbitrary wallet. A fulfiller that processes subscriptions should not be able to change vault parameters. This is the difference between “non-custodial by marketing” and “non-custodial by construction.” *** ## 19. Liquidity and Redemption Risk Structured credit products are not only about solvency. They are also about liquidity. A vault can be solvent but illiquid. Let: `LiquidAssets_t` = assets immediately available for redemption. `PendingRedemptions_t` = queued redemption claims. `LiquidCoverage_t = LiquidAssets_t / PendingRedemptions_t` If `LiquidCoverage_t < 1`, redemptions must be fulfilled over time, pro rata, or according to tranche-specific rules. For senior products, liquidity language must be precise. The senior tranche can have: * Target return. * First-loss protection. * Priority redemption. * Shorter duration assets. But none of these means instant liquidity unless the underlying assets support it. A credible vault should disclose: 1. Redemption frequency. 2. Notice period. 3. Settlement period. 4. Liquid asset percentage. 5. Maximum daily or rolling withdrawal percentage. 6. Treatment of withdrawal queues during stress. 7. Whether senior redemptions are prioritized over junior redemptions. The cleanest model is: * Senior receives payment priority in the economic waterfall. * Redemption priority is separately specified. * Junior lockups or withdrawal fees protect the capital stack from first-loss capital flight. This distinction matters. Payment priority and redemption priority are not the same thing. *** ## 20. Security and Maturity Disclosure Perena Vaults are designed for constrained operation, but no vault should claim risk elimination. The relevant risk categories include: 1. Smart-contract risk. 2. Oracle and NAV-reporting risk. 3. Strategy risk. 4. Venue risk. 5. Liquidity risk. 6. Stablecoin risk. 7. Counterparty or issuer risk. 8. Manager key risk. 9. Governance risk. 10. Correlation risk. 11. Legal and regulatory risk. The v2 vault infrastructure should be presented honestly as new infrastructure until audits, caps, and production history justify stronger claims. The correct posture is: > The team has operating history. > > The design is constrained and mathematically specified. > > The code should still be treated according to its actual maturity. This is more credible than saying “secure,” “risk-free,” or “battle-tested.” A fixed-income product lives or dies on precision. *** ## 21. Why This Matters The largest opportunity in stablecoins is not simply moving dollars on-chain. It is creating a native financial system around those dollars. That system needs: * Liquid base assets. * Credit creation. * Yield distribution. * Risk transformation. * Institutional-grade accounting. * Composable claims. * Transparent settlement. Perena Vaults are infrastructure for risk transformation. A single pool of stablecoin-denominated assets can support multiple instruments: * A senior fixed-style product for conservative capital. * A junior first-loss product for risk-seeking capital. * Future mezzanine tranches. * Protocol-owned liquidity products. * RWA issuer distribution vehicles. * Treasury management products. * Structured stablecoin yield markets. The primitive is general. Once the vault can define claims programmatically, the design space expands: `One pool → many risk profiles` `One strategy → multiple buyer segments` `One NAV engine → many structured products` `One capital stack → composable on-chain credit` This is why the product is not merely another Solana vault. It is a mechanism for manufacturing structured credit on-chain. *** ## 22. Conclusion The next stage of on-chain finance will not be won by the highest advertised APY. It will be won by protocols that make risk explicit, measurable, and programmable. Perena Vaults introduce a structured credit framework for Solana: senior and junior claims issued against a single managed pool, governed by a code-enforced waterfall, priced through validated NAV, protected by constrained execution boundaries, and made composable through tokenized tranche shares. The senior tranche offers fixed-style yield with first-loss protection. The junior tranche offers residual upside in exchange for absorbing first loss. The vault does not remove risk. It structures it. That distinction is the product. Perena’s core thesis is that stablecoin capital will not scale into serious on-chain credit markets until allocators can choose where they sit in the capital stack. Perena Vaults make that capital stack programmable. One pool. Multiple risk profiles. Structured credit, natively on-chain.