Security Considerations¶
9.1 Queue Ordering and MEV¶
Risk: The FIFO withdrawal queue gives earlier positions better curve pricing. A sophisticated actor could attempt to manipulate queue ordering to obtain favorable fill levels.
Mitigations:
- Permissioned keeper — only an authorized address can call processWithdrawals()
- Keeper should batch-process in a single transaction per day to prevent ordering manipulation within a day window
- Consider a commit-reveal scheme for withdrawal requests if MEV becomes problematic in practice
9.2 Reserve Depletion¶
Risk: Rapid, sustained withdrawals could deplete the idle reserve faster than the HouseBuffer can replenish it.
Mitigations:
- Pause triggers automatically if idleReserve < dailyCap — preventing withdrawals when cash is insufficient
- HouseBuffer top-up is capped at 10% of buffer per call — multiple transactions required for large top-ups, giving governance time to react
- reserveTargetBps (15%) and the 50% topup trigger provide early warning
9.3 Price Manipulation¶
Risk: Thin prediction market order books can be manipulated to distort the market NAV reported by adapters. An attacker could temporarily push the market price to affect the gap calculation and either trigger/clear the pause.
Mitigations: - Minimum liquidity depth requirements prevent entry into thin markets - Operator should validate adapter price readings against reasonable bounds before the keeper processes withdrawals - Future mitigation: TWAP or multi-source price verification (deferred to post-MVP)
9.4 Governance Centralization¶
Risk: The operator/governance address has significant power: opening/closing positions, rebasing, writing off, emergency liquidation. A compromised or malicious operator could harm investors.
Mitigations:
- Multisig recommended — requires multiple authorized parties to execute governance functions
- Timelocks on openPosition and rebasePosition for post-MVP hardening
- writeOff is safe to allow without delay — it can only decrease NAV, never increase it
- changeGovernance requires a timelock to prevent sudden handoff
- All governance actions are transparent on-chain and auditable
9.5 Position Correlation¶
Risk: If multiple positions share causal drivers, a single real-world event can trigger multiple simultaneous write-offs, causing a catastrophic NAV collapse.
Mitigation: - Operator must document independence assessments for every market pair before opening - The contract cannot enforce correlation constraints on-chain — this is pure operator discipline - Correlation must be checked not just at position entry but monitored for emerging correlations over time
9.6 Reentrancy¶
Risk: External calls to USDC transfers and adapter interactions could enable reentrancy attacks.
Mitigation: All external calls follow checks-effects-interactions pattern. ReentrancyGuard is applied to:
- deposit()
- processWithdrawals()
- openPosition()
- closePosition()
- emergencyLiquidate()
- topUpReserve() (HouseBuffer)
9.7 Adapter Trust¶
Risk: Each MarketAdapter is deployed by governance and holds vault USDC. A malicious or buggy adapter could steal or lock funds.
Mitigations:
- Adapters should be deployed from a verified factory or use a standardized, audited implementation
- The vault must never approve an adapter that has not been reviewed
- vault address in each adapter is immutable — cannot be redirected post-deployment
- Adapter authorization is checked on every call from the vault
9.8 Rebase Front-Running¶
Risk: A keeper with advance knowledge of an upcoming rebase could front-run it by processing withdrawals at the pre-rebase (higher) price, extracting value from remaining holders.
Mitigations: - Daily cap limits how much can exit before a rebase - The quadratic curve penalizes high-volume redemptions - Consider making rebase effective in the next day window (post-MVP) for additional protection
9.9 Emergency Liquidation Risks¶
The emergencyLiquidate function introduces the only path where NO shares are sold on the open market. Specific risks:
Slippage Amplification¶
Selling during a stress event means selling when the market is already under pressure — the order book is thinnest exactly when selling is needed. The 200 bps slippage guard helps but does not eliminate this. Sell in small increments with time between calls.
Cascading Liquidation¶
If the vault approaches the 10% open interest limit, selling a large block can push the market price down, widening the gap on the remaining position. Size each call to sell just enough to restore the reserve above the pause threshold — not more.
Governance Abuse¶
A malicious operator could theoretically pause the system by draining the reserve, then use emergencyLiquidate() to sell positions at distressed prices.
Mitigations: - Pause requirement is enforced on-chain — cannot be called during normal operation - All liquidation actions are visible on-chain — misuse is transparent - Multisig governance with multiple required signers reduces single-party risk
Timing of Post-Liquidation Withdrawals¶
After emergencyLiquidate() adds USDC and the system unpauses, queued investors receive exit prices that reflect the post-liquidation NAV — which is lower due to the slippage cost. This is correct behavior, not a bug — it reflects the true economic reality after the liquidation.