Raven MarketDOCS

AMM & Pricing

4 min read

The pricing engine behind Raven — a coupled automated market maker where a single variable governs both CALL and PUT prices simultaneously.

The Problem

In any digital options protocol, if all traders bet on the same side, the protocol becomes insolvent — there isn't enough capital on the losing side to pay winners. Traditional solutions require centralized market makers, position caps, or outright trade rejection. None of these work for a decentralized, permissionless protocol.

The Solution — Complete Sets

Every option pair is backed by complete sets. One complete set equals one CALL token plus one PUT token, always backed by exactly 1 CC of collateral locked at mint time.

1 CALL + 1 PUT = 1 CC
At expiry, exactly one side pays out 1 CC. The other expires worthless.

Because collateral is locked at mint time, the protocol remains solvent regardless of how lopsided trading becomes — even if every trader bets the same direction, every winning position has its 1 CC already reserved.

Coupled Pricing Model

Raven uses a coupled pricing model — a single variable, call_reserve (r), governs both CALL and PUT prices simultaneously. The two sides are mathematically linked: when one rises, the other falls by exactly the same amount. Their prices always sum to exactly 1.0 CC.

call_price = k / (r² + k)
put_price = 1 − call_price
k = seed²  ·  seed = initial reserve size  ·  r = call_reserve
Pool Statecall_reserve (r)CALL pricePUT price
Neutral — balanced poolr = seed0.500.50
Calls being bought — reserve depletingr < seed> 0.50< 0.50
Puts being bought — reserve growingr > seed< 0.50> 0.50
ℹ️ No Independent PUT Reserve
There is no independent pricing state for PUT. put_reserve is purely a bookkeeping mirror: put_reserve = 2 × seed − call_reserve. All price movement flows through call_reserve alone.

The Arctan Bonding Curve

Trade costs are not computed at a single spot price — they are calculated by integrating over the bonding curve as call_reserve moves. This means the cost of a trade reflects the full price impact across the entire quantity, not just the entry price.

Buy CALL    cost = √k × [arctan(r / √k) − arctan((r − qty) / √k)]
Buy PUT     cost = qty − √k × [arctan((r + qty) / √k) − arctan(r / √k)]
Sell CALL   payout = √k × [arctan((r + qty) / √k) − arctan(r / √k)]
Sell PUT    payout = qty − √k × [arctan(r / √k) − arctan((r − qty) / √k)]

The integrals are path-reversible: the cost to buy equals the payout to sell for the same reserve range. The protocol fee is applied on top separately as cost × (1 + feeRate) — the math itself carries no hidden spread.

How Every Trade Moves the Pool

All trades operate on call_reserve only. Buying one side automatically makes the other side cheaper — creating a natural incentive for contrarian positions to balance the pool.

ActionEffect on call_reserveEffect on prices
Buy CALLDecreasesCALL ↑, PUT ↓
Buy PUTIncreasesPUT ↑, CALL ↓
Sell CALLIncreasesCALL ↓, PUT ↑
Sell PUTDecreasesCALL ↑, PUT ↓

IV-Aware Pool Initialization

Markets do not open at a naive 50/50. When a contract is created, an opening implied probability P is derived from a Black-Scholes model using a Garman-Klass volatility estimator from live price data. The pool is then seeded with an imbalanced call_reserve so the opening price matches this theoretical fair value.

r = seed × √((1 − P) / P)
Example: P = 0.70 → r = seed × √(0.30 / 0.70) ≈ seed × 0.655 → call_price = 0.70

Since r < seed in this example, call_price = k / (r² + k) = 0.70. The market opens at the theoretically correct price — not an arbitrary 50/50.

Price Sum Guarantee

CALL price + PUT price = 1.0 is enforced at all times by the formula itself — not as a constraint, but as a mathematical identity. There is no spread between the two sides. Protocol revenue comes entirely from the fee layer applied on top of trade costs.

What This Means for Traders