What is Richter
Richter is an exchange for realized-variance perpetual contracts on Monad testnet. It has one market for MON and one market for ETH. Each market uses USDC as margin.
A new type of market
Richter is a new type of market on Monad. A spot market or a perpetual market trades the price of a token. Richter trades the volatility of that price as an asset of its own.
- The asset is realized variance: the size of the price moves, without the direction.
- Each market has one price, the annualized variance mark. It has no strike and no expiry date.
- A trader can buy volatility, sell volatility, or hold it as a hedge. MON has no other volatility product.
The LP hedge in the demo is one use case of this market. It is not the product. The product is the market itself.
What you trade
The order price is annualized variance. It is not the spot price of MON or ETH.
- A long position receives a payment when the oracle price moves. The direction of the move is not important. The long pays a fixed charge for each second of time.
- A short position receives that fixed charge. The short pays when the oracle price moves.
A position has no expiry date. You open it and close it with orders in the order book.
See How variance perpetuals work for an explanation with numbers.
What is in the build
| Part | What it does |
|---|---|
Market contract, one for each asset | Holds collateral. Matches orders. Calculates funding, margin, and liquidation. |
SessionRegistry contract | Records which session key can trade for which account in which market. |
| Services | A relayer that pays gas for signed orders, an event indexer, and an HTTP API. |
| Web application | A trading terminal, a portfolio page, and a demo page with an LP hedge panel. |
| Scripts | Deployment, maker quotes, random taker orders, and oracle price shocks for the local chain and for Monad testnet. |
| Simulation | A Python reference model for the contract accounting, and research notebooks. |
The contracts make all trading and risk decisions. The services do not match orders.
Who it is for
| User | Use |
|---|---|
| Traders | Trade the expected size of price moves |
| 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 loss that an AMM position has when the price moves |
The LP hedge is one use. The exchange does not need an LP position or an LP integration. A variance position does not protect against a directional loss.
Why Monad
Monad is the only place for this exchange. The product has frequent state changes. Price observations feed the variance accounting. Makers move their quotes. Accounts receive funding and pass margin checks. The product thesis is that this full workload stays practical on one chain.
Two facts of Monad shape the design:
- Monad charges for the gas limit of a transaction, not for the gas used. The scripts estimate each transaction and add a small margin.
- The maker ladders are parametric. One
quotecall moves all ladder levels of a market and can carry the oracle observation. See Order book and mark.
The full exchange runs on chain: the order book, the matching, the mark, the funding, and the margin checks. Makers must move all their price levels each time the market moves, and each move is a transaction. This needs fast blocks, high throughput, and a low gas cost on an EVM chain. Monad is the only chain that gives these together, so Monad is the only place where this design is practical. On a slower or more expensive chain, the same product needs an off-chain matching engine.
What is for testnet only
Two parts of the current operation are for the testnet deployment only. They are not the design for a market with real funds.
| Part | On testnet | Why it is for testnet only |
|---|---|---|
| Observation model | One operator signs each oracle price and sends it with a quote, at a fixed interval. | The operator sets the price. An independent price feed must replace it. See Oracle and observations. |
| Fill model | The operator pushes the fills. It sends the taker orders, and on the fast deployment it sends one quote and one fill in the same transaction. | The fills come from the operator, not from independent traders. They exist so that the book, the mark, and the trade feed stay active. See Order book and mark. |
The contracts, the matching, the funding arithmetic, and the margin checks are the same for each fill. Only the source of the prices and of the orders is a test arrangement.
What is not in the build
These items are in the requirements or the target design. They are not implemented.
- Pyth price verification. The test oracle accepts prices from one operator.
- A database. The indexer keeps its state in one JSON file.
- A WebSocket transport. The terminal polls the HTTP API. The API also sends SSE notices.
- An automatic fallback from the relayer to main-wallet orders in the web application.
- A real DEX pool for the LP hedge. The LP position is a calculation in the browser.
- An insurance fund or a rule that allocates bad debt.
See Decisions and open work for the full list.
Do not claim
- Do not claim that this is the first variance perpetual. Related products exist. See Product requirements.
- Do not claim that the hedge covers all LP losses. It offsets part of the loss from moves.
- Do not show the Python demo totals as measured testnet results.
Where to start
| You are | Read first |
|---|---|
| A judge with ten minutes | This page, then How variance perpetuals work |
| A developer who wants to run it | Quick start, then Run the local exchange |
| A developer who changes the contracts | System overview, Funding, and the contract reference |
| A person who checks the claims | Decisions and open work and Implementation status |