Risk Framework

Understanding and managing protocol-level risks in the Rate Swap Protocol.

Risk Categories

1. Market Risk

Definition: Risk from adverse rate movements affecting pool positions

Sources:

• Pool takes opposite side of user trades
• Unbalanced flow (all users one direction)
• Large concentrated positions

Mitigation:

• DV01-Based Reserve: Reserve liquidity proportional to DV01 exposure
• DV01 Liquidity Gating: Reduce available depth for risk-increasing trades
• Utilization-Based Scalar: Further restrict depth at high utilization
• Per-Market DV01 Caps: Hard limits on market-level rate sensitivity
• Risk Weights: Adjust reserve contribution per market

Key Parameters:

• max_rate_move_bps: Maximum expected rate move for reserve calculation
• util_kink_wad: Utilization threshold where scalar starts decreasing
• util_max_wad: Maximum utilization where scalar reaches minimum
• min_risk_scalar_wad: Minimum depth scalar at max utilization
• dv01_cap_wad: Maximum allowed DV01 per market
• risk_weight_wad: Market's weight in pool-wide reserve

Metrics:

• Net pool DV01 per market
• Weighted total DV01 across pool
• DV01 reserve utilization
• Position concentration

2. Credit Risk

Definition: Risk of user defaults (undercollateralized positions)

Sources:

• Rapid rate movements reduce position health
• Adverse funding settlement drains equity
• Liquidation failures or delays

Mitigation:

• Margin Requirements: Initial and maintenance margins per market
• Margin Floors: Rate-and-time-based minimum margins (MRN floors)
• Health Monitoring: Continuous position health checks
• Crank-Only Liquidation: Permissionless liquidation triggers
• Accounting-Only Settlement: Efficient, gas-less funding accrual

Key Parameters (per market):

• initial_margin_bps: Required to open/increase positions
• maintenance_margin_bps: Minimum to avoid liquidation
• liquidation_penalty_bps: Penalty rate for liquidations
• min_rate_floor_wad: Minimum rate for floor margin calculation
• im_mult_wad, mm_mult_wad: Floor margin multipliers

Metrics:

• Average health factor across positions
• Liquidation frequency and volume
• Bad debt incurred (if any)
• Margin utilization distribution

3. Liquidity Risk

Definition: Risk of insufficient liquidity to support markets

Sources:

• LP withdrawals during stress
• Large swaps exceed available liquidity
• DV01 reserve consumes available depth

Mitigation:

• DV01 Reserve Lock: Prevent LP withdrawals from depleting reserve
• Liquidity Weights: Allocate pool depth across markets
• Multi-Market Pools: Up to 16 markets share pool liquidity
• Utilization Gating: Reduce depth as utilization increases

Key Parameters:

• liquidity_weight_bps: Market's share of pool liquidity (per market)
• total_liquidity_weight_bps: Sum across all markets (max 10000)

LP Withdrawal Protection:

available_for_withdrawal = LP_NAV - DV01_reserve
DV01_reserve = weighted_total_dv01 × max_rate_move_bps / 10000

Metrics:

• Available liquidity / Total NAV per market
• LP share concentration
• Withdrawal volume trends
• Reserve utilization

4. Open Interest Risk

Definition: Risk from concentrated notional exposure

Sources:

• Large positions dominating a market
• Unidirectional flow creating imbalance

Mitigation:

• OI Caps: Maximum gross open interest per market
• Cap Enforcement: Reject trades exceeding cap (except liquidations)

Key Parameters:

• oi_cap_notional_wad: Maximum allowed gross OI per market
• oi_gross_notional_wad: Current gross OI (tracked on-chain)

Metrics:

• Gross OI vs cap per market
• OI concentration by user
• Net vs gross OI ratio

5. Oracle Risk

Definition: Risk from oracle failures or manipulation

Sources:

• Stale oracle data
• Oracle provider outage
• Rate index manipulation
• Incorrect oracle updates

Mitigation:

• Staleness Checks: Reject stale oracle data
• Pool Authority Validation: Only pool authority can update
• Circuit Breakers: Halt market if oracle issues detected
• Max Staleness Parameter: Configurable per oracle

Key Parameters:

• max_staleness_secs: Maximum age before oracle is stale

Metrics:

• Oracle uptime
• Update frequency
• Rate volatility
• Staleness incidents

6. Smart Contract Risk

Definition: Risk from bugs, exploits, or vulnerabilities

Sources:

• Code vulnerabilities
• Logic errors in math
• Reentrancy or privilege escalation
• Accounting errors

Mitigation:

• Audits: Professional security audits
• Testing: Comprehensive unit and integration tests
• Checked Arithmetic: All math uses overflow-safe operations
• Zero-Copy Accounts: Efficient, safe account handling
• Gradual Rollout: Testnet → Devnet → Mainnet

Security Features:

• Idempotent settlement (no double-settlement)
• NAV-before-transfer pattern (prevents manipulation)
• PDA validation (prevents account substitution)
• require_msg! macro for debuggable errors

Metrics:

• Test coverage
• Audit findings
• Bug reports
• TVL limits in early stage

7. Operational Risk

Definition: Risk from operational failures or admin errors

Sources:

• Incorrect parameter settings
• Admin key compromise
• Failed oracle updates
• Protocol upgrades

Mitigation:

• Multi-Sig Controls: Distributed admin authority (future)
• Circuit Breakers: Emergency market controls
• Parameter Bounds: On-chain validation of parameters
• Monitoring: Alerting for anomalies

Circuit Breaker Controls:

• MarketStatus::Normal: All operations allowed
• MarketStatus::ClosingOnly: Only risk-reducing trades
• MarketStatus::Halted: Only liquidations and admin ops

Metrics:

• Parameter change frequency
• Admin action logs
• Incident response time

Risk Limits and Parameters

Pool-Level Parameters

Parameter	Description	Typical Range
max_rate_move_bps	Max rate move for DV01 reserve	100-500 (1-5%)
util_kink_wad	Utilization kink threshold	0.5-0.7 × WAD
util_max_wad	Maximum utilization	0.8-0.95 × WAD
min_risk_scalar_wad	Min scalar at max util	0.1-0.3 × WAD

Market-Level Parameters

Parameter	Description	Typical Range
initial_margin_bps	Initial margin	500-1000 (5-10%)
maintenance_margin_bps	Maintenance margin	300-500 (3-5%)
liquidation_penalty_bps	Liquidation penalty	200-500 (2-5%)
swap_fee_bps	Trading fee	5-20 (0.05-0.2%)
oi_cap_notional_wad	Max gross OI	Based on pool size
dv01_cap_wad	Max gross DV01	Based on pool size
liquidity_weight_bps	Market's liquidity share	1000-5000 (10-50%)
risk_weight_wad	DV01 weight in reserve	0.5-2.0 × WAD

Margin Floor Parameters

Parameter	Description	Purpose
min_rate_floor_wad	Minimum rate for floor	Prevents zero margin at low rates
im_mult_wad	IM floor multiplier	Scales floor for initial margin
mm_mult_wad	MM floor multiplier	Scales floor for maintenance margin

Stress Testing

Scenario 1: Rate Spike

Scenario: Rates jump 5% overnight

Impact:

• Users with pay-fixed positions profit (pool loses)
• DV01 reserve should cover pool losses
• Potential liquidations on undercollateralized positions

Test: Verify pool remains solvent with DV01 reserve buffer

Scenario 2: Unbalanced Flow

Scenario: All users take receive-fixed (short rates)

Impact:

• Pool net exposure: Pay-fixed (long rates)
• OI cap limits maximum exposure
• DV01 gating restricts new risk-increasing trades

Test: Verify caps and gating prevent excessive exposure

Scenario 3: Oracle Outage

Scenario: Oracle stale for 24 hours

Impact:

• Trading halts (stale oracle rejection)
• No funding settlements
• Positions frozen

Test: Ensure graceful degradation, no exploits

Scenario 4: Mass Liquidations

Scenario: Volatile rates trigger many liquidations

Impact:

• Liquidation volume increases
• All penalties go to pool (crank-only model)
• OI and DV01 decrease as positions close

Test: Verify liquidation system handles load, pool benefits from penalties

Scenario 5: LP Run

Scenario: 50% of LPs attempt to withdraw

Impact:

• DV01 reserve lock limits withdrawals
• Available LP equity reduced
• Remaining LPs have proportionally higher exposure

Test: Ensure reserve lock protects remaining LPs

Scenario 6: High Utilization

Scenario: DV01 reserve approaches pool equity

Impact:

• Utilization scalar reduces available depth
• Risk-increasing trades see minimal liquidity
• Risk-reducing trades unaffected

Test: Verify utilization scalar correctly throttles new risk

Monitoring and Alerts

Key Metrics Dashboard

• Pool NAV and DV01 reserve
• Net DV01 exposure per market
• Gross OI and DV01 vs caps
• Average position health
• Liquidation queue and volume
• Oracle status and staleness
• Trading volume and fees
• Market status (circuit breakers)

Alert Thresholds

• High DV01 Utilization: >70% of reserve consumed
• Approaching OI Cap: >80% of cap
• Low Health Cluster: Multiple positions < 120% maintenance
• Stale Oracle: >50% of max staleness
• Low Liquidity: <20% of allocated depth available
• Large Loss: Pool NAV down >3% in day

Incident Response

1. Detect: Automated monitoring triggers alert
2. Assess: Evaluate severity and impact
3. Respond: Execute mitigation (circuit breaker, parameter adjust)
4. Communicate: Notify users of issue and resolution
5. Post-Mortem: Analyze root cause and improve

Risk Governance

Parameter Updates

Who: Pool authority (initially), governance (future)

What:

• Risk parameters (margins, fees, caps)
• Circuit breaker status
• Oracle settings

Process:

1. Propose change with rationale
2. Risk analysis and modeling
3. Community review (if governance)
4. Execution (with timelock in future)
5. Monitor impact

Emergency Procedures

Set Closing-Only: If market conditions deteriorating

• Prevents new risk, allows risk reduction
• Protects pool from further exposure

Halt Market: If critical issue detected

• Freezes all trading
• Liquidations still function
• Allows investigation

Oracle Override: If oracle clearly manipulated

• Requires admin intervention
• Should be rare, well-documented

Long-Term Risk Management

Decentralization

• Move from single authority to DAO governance
• Distribute oracle responsibilities
• Multi-sig for critical functions

Insurance

• Protocol insurance fund for bad debt
• Integration with DeFi insurance protocols
• Backstop for catastrophic events

Continuous Improvement

• Regular audits and reviews
• Incorporate lessons from incidents
• Adapt to evolving DeFi landscape
• Improve risk parameters based on data

Next Steps

• Business Overview - Strategic context
• Engineering Testing - How risk is tested
• User Risk Management - Trader-level risk practices