Risk Disclosure

This is the same disclosure the Parquet app shows once when you first connect a wallet on mainnet. Acknowledging the in-app modal sets a local flag so it does not appear again. Please read this before trading on mainnet.

Mainnet — real funds at risk

This is the production deployment. All trades use real USDC. Smart contracts can fail, oracle feeds can stale, and you can lose your funds. Winning closes may be queued and paid as the pool recovers. Use at your own risk.

Smart-contract risk

Parquet is on-chain software running on a permissionless blockchain. The deployed bytecode is the final word on what the protocol will and will not do. Even correct-looking software can behave unexpectedly under edge conditions, adversarial inputs, or compounding interactions with other on-chain or off-chain systems. Loss arising from program bugs is borne by users.

Oracle staleness and disagreement

Prices used for marking, liquidating, and settling positions come from external feeds. During regular trading hours (RTH, Mon-Fri 09:30-16:00 ET on US business days), Parquet uses Pyth Network as the primary on-chain feed and falls back to a relayer-written secondary feed when the primary ages past its staleness threshold. Outside RTH, the secondary feed becomes the on-chain price — sourced from Pyth pre-market, after-hours, and overnight session feeds on weeknights, and from Hyperliquid Mark on weekends. Feeds can stale, disagree, lag, or report incorrect values; the on-chain deviation circuit breaker is intentionally disabled so Monday-morning gaps can process cleanly, which means bad-data rejection happens off-chain in the aggregator rather than at the program level.

Off-hours pricing

On weeknights, off-hours pricing comes from Pyth's pre-market, after-hours, and overnight session feeds. On weekends, it is sourced from Hyperliquid's xyz perp DEX, not the underlying US equity venues — Hyperliquid's feed tracks the underlying equity via its own market, which can drift from where the underlying would actually trade at RTH open. Positions held across the RTH boundary mark continuously against the prevailing off-hours regime — there is no gap at next-open, but the off-hours mark can deviate materially from where the equity opens at 09:30 ET. SPY and QQQ track scaled Hyperliquid indices on weekends, which adds an additional layer of basis risk.

Tighter off-hours risk parameters

Leverage is up to 200x in every session — the same across the board. The wallet-notional-tiered leverage table is identical during regular hours and off-hours; there is no longer a reduced off-hours leverage cap. 200x is the maximum you can open, set by the 50 bps initial margin. At the 200x cap a freshly-opened position sits essentially at its liquidation point once the open fee is taken, so even a small adverse move can liquidate it — high leverage is high risk in every session.

What still tightens off-hours is not leverage but the per-market open-interest cap (it drops to $500K) and an armed auto-deleveraging (ADL) tail-backstop that can apply a capped, last-resort haircut to the oldest unbacked entries in the payout queue. These are intentional defenses against thinner off-hours liquidity; all of these risk parameters may be changed by the upgrade authority without notice. The tighter off-hours limits may constrain new opens or margin removes that would have been allowed during RTH, and off-hours liquidations may happen at levels you would not have hit during RTH.

Hyperliquid feed disagreements can drop a market

Earlier in the 24/7 rollout, individual symbols were temporarily pulled when Hyperliquid's price diverged sharply from other reference feeds on the same equity, breaking the cross-feed agreement check. Such symbols can be reactivated once feeds re-converge, and any symbol whose Hyperliquid feed similarly diverges from US venues may become inert without notice. An inert market still has its PDA initialized but rejects opens because the oracle is stale — existing positions remain on the books and may be affected by the loss of fresh pricing. Check the Markets page for the current active and inert list.

Counterparty pool exhaustion and payout queue

All trades are filled against per-market USDC pools. Large positions on highly-correlated names (for example tech-heavy single-names) can produce concentrated payouts that drain a pool's free liquidity and route winning closes through a FIFO payout queue. Time-in-queue is unbounded; payouts depend on subsequent pool inflows (counterparty losses, LP deposits) to replenish free liquidity. You assume the risk that a winning position may not be paid immediately or, in an extreme case, at all.

Liquidations

Positions falling below maintenance margin are liquidated by permissionless keeper bots. Keeper behavior depends on RPC availability, oracle freshness, network conditions, and the keeper's own software. A delayed, missed, or partial liquidation can result in larger losses than the maintenance-margin level suggests, including losses that exceed posted collateral in the worst case.

Funding rates

Open perpetual positions pay or receive funding on a recurring basis. Funding rates can move quickly, compound against your position, and erode collateral over time even if the mark price does not move against you. The funding-rate cap is 10 bps per hour, which is meaningful at high leverage.

Infrastructure and third parties

The frontend, indexer, price-pusher, keeper, and the underlying Solana network can be degraded, paused, unavailable, or incorrect. Solana RPC providers, third-party hosting and network providers, multiple licensed equity-data providers, Hyperliquid, and Pyth Network are operated by parties outside Parquet's control. An outage at any of these can prevent you from opening, closing, adjusting, or even observing your positions while market prices continue to move.

Parameter changes

Trading fees, funding-rate caps, liquidation fees, margin requirements, leverage tiers, open-interest caps, oracle staleness thresholds, and payout queue rules may be changed by the on-chain upgrade authority without prior notice or user consent. Continued use of the protocol after a parameter change constitutes acceptance of the new parameters.

Last updated: 2026-06-06