Venue Risk¶
The vault depends on the prediction market venue for price discovery, order execution, and settlement. All venue-specific logic is encapsulated in MarketAdapter, but the underlying risks stem from the venue itself.
Venue Dependencies¶
| Dependency | Risk |
|---|---|
| Smart contract security | Bugs in the venue's contracts could lock or lose NO shares |
| Oracle for resolution | Oracle failures could delay or corrupt settlement outcomes |
| Settlement timing | Delayed or disputed settlements can extend the SETTLING state indefinitely |
| Liquidity | Venue liquidity withdrawal reduces market depth, impacting emergency exit |
| Venue availability | Venue downtime prevents price reads, blocking the keeper from processing withdrawals |
MVP Scope¶
For MVP, one venue is supported. Multi-venue support is explicitly deferred to post-MVP.
Single-venue dependency means: - A venue outage pauses all price discovery - A venue exploit affects all vault positions - There is no fallback pricing source
Mitigation¶
| Risk | Mitigation |
|---|---|
| Venue smart contract bugs | Use audited adapters; prefer well-established venues |
| Oracle failures | Monitor isSettled() and currentPrice() responses; alert on stale prices |
| Disputed settlements | Include settlement dispute mechanisms in adapter implementation |
| Venue downtime | The keeper should pause processWithdrawals() if currentPrice() returns stale or zero values |
Adapter as Risk Boundary¶
The MarketAdapter is the single point of integration with each venue. All venue-specific risk is bounded by the adapter. A well-implemented adapter should:
- Validate all responses from the venue before returning to the vault
- Implement circuit breakers for extreme price movements
- Handle settlement disputes gracefully
- Revert cleanly if the venue is unavailable rather than returning invalid data