Product requirements
This page is a summary of the product requirements document. The full text is the root file PRD.md. Status of that document: draft, 13 October 2026.
Requirements, not behavior
This page gives requirements and intent. Some items are not implemented. For the current behavior, see the System overview and the Implementation status.
Product
Build a fully on-chain exchange for perpetual exposure to realized variance. Users take long or short positions to trade the size of price changes without a choice of price direction. Positions have no scheduled expiry.
Start with MON and ETH realized-variance markets, both with USDC margin and settlement. Each market has separate observations, variance accounting, liquidity, and risk limits.
Product thesis: use the execution capacity and the fast finality of Monad to make frequent variance accounting, active trading, and margin management practical in one fully on-chain exchange.
Users
| User | Use case |
|---|---|
| Traders | Trade expected changes in price variation |
| Quantitative funds | Trade differences between expected and realized variance, or between venues |
| Market makers | Quote the two sides and manage variance inventory |
| Hedgers | Offset part of the variance exposure of a portfolio |
| Liquidity providers | Hedge part of the exposure of an AMM position |
MON and ETH are different risk products
The two markets share a contract structure. Their economics are different.
| Market | Pricing and hedging basis | Consequence |
|---|---|---|
| ETH | External options can support implied-variance estimates and partial hedges | Options give an economic reference, not an exact peg |
| MON | The project has not found an external options market with sufficient depth. Quotes rely on forecasts, inventory, and the capital of sellers. | Plan for a large and unstable risk premium, wider spreads, and abrupt mark changes |
ETH liquidity must not imply that MON can be hedged. Each market needs its own margin requirements, open-interest limits, and stress scenarios.
Fixed requirements
- Order placement, cancellation, matching, position accounting, variance calculation, funding, margin checks, liquidation, and settlement run in Monad contracts.
- Contracts hold the collateral. No operator can move user collateral outside the published contract rules.
- Settlement inputs, formulas, position state, and charges are publicly verifiable.
- Direct contract access works without the website or a private matching service.
- Any address can submit a valid observation and trigger a permitted liquidation. Keepers only submit transactions.
The price-source boundary is open. The draft assumes that external price observations can be verified on-chain. Do not describe the external-oracle design as oracle-free.
MVP scope
| Component | Requirement | In this build |
|---|---|---|
| Markets | MON and ETH variance markets with isolated USDC margin | Yes, with test USDC |
| Trading | On-chain limit orders, cancellation, matching, and partial fills | Yes |
| Positions | Open, increase, reduce, close, deposit, and withdraw | Yes |
| Variance engine | Verified observations, shared accumulator, replay protection | The accumulator and the time rules, yes. Verified observations, no: the oracle is a test oracle. |
| Risk engine | Initial and maintenance margin, exposure limits, liquidation, explicit bad-debt rules | Margin, limits, and liquidation, yes. Bad-debt rules, no. |
| Web trading UI | Terminal with chart, book, trade feed, order entry, positions, balances | Yes |
| Trading session | One wallet authorization, then orders without wallet prompts | Yes |
| History | Fills, charges, deposits, withdrawals, liquidations | From the JSON event index |
Trading session requirements
- Contracts restrict the session key to order placement and cancellation for the authorized account and market. It cannot withdraw or transfer collateral, grant permissions, or change ownership.
- Signed actions are bound to the chain, the exchange contract, the account, and the session. Nonces, deadlines, expiry, and revocation are enforced on-chain.
- The session private key stays on the device of the user.
- A relayer submits signed actions and pays gas. It cannot change signed orders or match them off-chain.
- An expired or revoked key must fail, also when it submits through a different client.
See Wallet and sessions for the implemented flow.
Why Monad
The product has frequent state updates: price observations feed variance accounting, traders change orders, and accounts settle payments and manage margin. The thesis is that this complete workload stays practical on-chain at useful trade sizes and response times.
| Design choice | Intended benefit |
|---|---|
| Frequent on-chain order changes and matching | Traders react quickly while contracts enforce execution |
| Shared variance accumulator in each market | Observation and accounting costs spread across positions |
| Separate MON and ETH market state | Fewer dependencies between markets |
| Margin operations and settlement on the same chain | Less delay between execution and account updates |
Monad documents 300 ms blocks and 600 ms finality. These are network properties. They do not guarantee the application response time or new oracle data. See the Monad documentation.
The claim is that Monad is the only place for this exchange. The target fully on-chain trading experience needs fast blocks, high throughput, and a low gas cost on an EVM chain, and Monad is the only chain that gives these together. On a slower or more expensive chain, the same product needs an off-chain matching engine. No benchmark against other chains is complete; that comparison is open work.
Market position
Volatility perpetuals already exist. Volmex lists products on several venues. GammaSwap and Panoptic give related perpetual options exposure. The Gamma Swap of Deri Protocol is the nearest known live product: a perpetual that isolates gamma, priced by a protocol AMM. A 2022 paper with the title "The Perpetual Variance Swap" describes a different mechanism: an AMM with a logarithmic trading function, without an order book or a funding payment.
WARNING
Do not claim that this project is the first variance perpetual.
The proposed distinction is direct MON and ETH realized-variance exposure with frequent on-chain calculation, trading, and settlement. Novelty and better execution remain hypotheses.
Naming: Variational is an existing perpetual exchange. Use "variance" in public names for this project, not "variational".
Validation before a funded launch
- Complete the sampling research separately for MON and ETH. See Research baseline.
- Validate the traded quote, the price scale, the payoff, the funding, the entry, and the exit model with an independent economic review.
- Verify that contract accounting matches a reference model within a specified rounding tolerance.
- Test price jumps, oracle outages, manipulation, thin liquidity, and simultaneous liquidations.
- Complete an independent security review.
- Fix numeric risk limits and launch thresholds before a funded pilot.
Outside the MVP
Assets other than MON and ETH, volatility-index products, options, portfolio margin, cross-chain collateral, LP position management, and automated hedge execution.