> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rondo.finance/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

## 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.

<Note>
  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.
</Note>

## 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](/protocol/pricing#premium-and-fee-—-who-actually-pays).

## 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:

```ts theme={"system"}
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.