Your edge

The number that decides whether an order is worth taking, and why the raw deviation from the oracle price is not that number.

Every order on the book carries a headline figure: what a taker actually nets by filling it, valued at the oracle price and after the desk fee. That is the number to read. It is not the order’s deviation from the oracle price, and the difference is not cosmetic.

Why deviation cannot answer the question

Deviation is what the maker controls and what the price band constrains, so it is the natural thing to publish. It just does not answer “is this worth taking”, for two independent reasons.

Its sign flips with the side of the order

A JPYC-offered order priced 0.80% below the oracle price is cheap JPYC — the taker hands over less USDT than the market says, so they gain.

A USDT-offered order priced 0.80% below the oracle price means the taker is handing over JPYC too cheaply — so their edge is negative.

Same −0.80%, opposite outcome. A reader who has not tracked which token is on offer cannot tell the two apart.

It ignores the fee, which comes out of the taker's proceeds

An order sitting exactly on the oracle price is a 0.00% deviation and a −0.30% outcome at a 30 bps fee. Nothing about the deviation hints at that.

The definition

Edge is (value received − value paid) / value paid, with both legs valued at the oracle price:

r = order price / oracle price          // the deviation, as a ratio
f = feeBps / 10000                      // the fee snapshotted on the order

taker buys JPYC   (JPYC offered):  edge = (1 − f) / r − 1
taker sells JPYC  (USDT offered):  edge =  r × (1 − f) − 1

The fee enters once, on the side the taker receives, because that is where the contract takes it.

The same spread, read both ways

At a 30 bps fee:

Order	Deviation	Your edge
JPYC offered, 1.00% below the oracle price	−1.00%	+0.71%
JPYC offered, exactly at the oracle price	0.00%	−0.30%
JPYC offered, 1.20% above the oracle price	+1.20%	−1.48%
USDT offered, 0.60% above the oracle price	+0.60%	+0.30%
USDT offered, 0.80% below the oracle price	−0.80%	−1.10%

Two rows share a −0.80%-ish deviation and land on opposite sides of zero. One row is at the oracle price exactly and still has negative edge. This is the reason the interface publishes edge instead.

Rondo’s book shows edge as the headline and keeps the raw deviation on hover — it remains the number the maker sees, since it is what they control and what the band constrains.

Pegged orders are simpler

A pegged order has no stored price, and the contract prices every fill so the taker’s realised edge lands exactly on the maker’s premium. So:

edge of a pegged order = premiumBps

No derivation, no dependence on where the oracle happens to be. A 25 bps premium is a +0.25% edge at every price the feed can print. That guarantee is the reason pegged orders exist, and it is what a maker is paying for — see who actually funds it.

Partial fills quote their own outcome

Edge is a property of a rate, so a fixed order’s headline edge applies to any size taken from it. What changes with size is the absolute amount, not the percentage. Rondo’s fill ticket recomputes on the exact amounts being taken rather than reusing the headline, so a partial fill states its own result rather than inheriting a number computed for the whole order.

Reproducing it

Use the following integer math and rounding. The extra 1e4 scale preserves sub-basis-point detail:

const mid = oracleAnswer * jpycAmount * BPS;
const x   = usdtAmount * priceScale;
const net = BPS - BigInt(feeBps);

const scaled = sellsJpyc
  ? (net * mid * PRECISION) / x      // taker buys JPYC
  : (x * net * PRECISION) / mid;     // taker sells JPYC

return Number(scaled - BPS * PRECISION) / Number(PRECISION);

Use this same function for the order book and every alerting process so they cannot disagree about what an order is worth.