​
Oracle risk

Price markets depend on configured price feeds. A feed can be stale, unavailable, delayed, or rejected by validation rules. Some Pyth actions also require fresh update data and an ETH fee. Different markets can use different adapters, such as Pyth, Chainlink, or TWAP-style sources. Do not assume two markets use the same price source or freshness rules. Each oracle enforces a circuit breaker: a reported price of 0, or one outside its configured [minReasonablePrice, maxReasonablePrice] band, is rejected (BadPrice). A rejected price blocks actions that need it rather than feeding a bad value into pricing. On L2 deployments the oracle also checks sequencer liveness before any price is used (mandatory on Base mainnet). While the sequencer is down, and for a grace period after it restarts (one hour by default), every price-reading action reverts, including closing and liquidation. A Pyth oracle bound to a trading calendar serves a frozen price while the market is scheduled closed, up to its maxClosureStaleness cap; a feed that stays dead past the cap reverts until it recovers.

​
Oracle-change risk

A pool’s oracle cannot be swapped instantly. Changes are governed by a 24h timelock: the RISK_ROLE holder proposes a new oracle (proposePriceOracle), and it can only be accepted (acceptPriceOracle) after ORACLE_CHANGE_DELAY (24 hours) has passed. Acceptance re-validates that the candidate still matches the market and is the registry-authorized oracle, so a proposal revoked during the delay cannot be installed.
While positions are open, a rotation whose new price deviates more than 2% from the old (MAX_ORACLE_ROTATION_DEVIATION = 0.02e18), or whose old feed is unreadable, only succeeds after a guardian has put the market into reduce-only mode; otherwise it reverts (OracleRotationDeviationTooHigh / OracleRecoveryRequiresReduceOnly). This bounds the discontinuous health and value jump a feed swap can cause, while still allowing a two-role recovery away from a broken oracle. Reduce-only stays on until governance clears it.

​
Resolution module risk

Event markets depend on resolution modules and resolvers. A dispute path can take time, require bonds, and depend on a resolver decision. Permissionless creation increases market choice, but it also increases the need to read the question, rules, resolver, evidence standard, and invalid conditions before trading.

​
Admin and role risk

Some deployments include roles for pausing, risk parameters, oracle changes, treasury settings, market creation, or settlement configuration. These controls can protect users, but they also introduce governance and operational risk.

​
Upgrade risk

Some contracts may be upgradeable. Upgrades can fix bugs or add features, but they also change trust assumptions.

​
Integration risk

Frontends, indexers, metadata services, and wallet providers can fail or show incomplete data. A successful contract transaction may differ from what an offchain UI last displayed. When app data and contract state differ, the transaction follows the contract state. Refresh the page, check the connected network, and review wallet simulation details when available.

​
Trading-agent delegation risk

Authorizing a hot key with setTradingAgent delegates trade actions on your margin account until a chosen expiry. The agent can open, close, add collateral, and reduce leverage on your account. It cannot withdraw funds, change router approvals, deposit, run LP actions, or manage agents. A compromised or buggy agent can still trade your account and erode its value until the key expires or you revoke it (revokeTradingAgent, which takes effect immediately). Mitigate by using short expiries, keeping minimal balances in delegated accounts, and revoking promptly when an agent is no longer needed.

​
User safety

Verify official links, contract addresses, network names, and token approvals. Treat any unexpected wallet request as suspicious.