Pricing

Three decimal systems in one expression, the two quote paths, and who really pays the fee.

priceScale — derived, never written down

The selected base token, USDT, and the feed can use different decimals. An incorrect scale produces materially incorrect quotes, so the scaling factor is derived at initialisation from the live contracts and recalculated whenever the oracle changes.

priceScale = 10 ** (baseDecimals + oracleDecimals + 4 − quoteDecimals)

JPYC: 10 ** (18 + 8 + 4 − 6) = 1e24
IDRX: 10 ** ( 2 + 8 + 4 − 6) = 1e8
IDRP: 10 ** ( 6 + 8 + 4 − 6) = 1e12

The +4 carries the basis-point denominator so band and premium arithmetic stay integral. Addition is performed before subtraction so IDRX’s 2 decimals do not underflow against USDT’s 6.

The reference is a five-minute Orakl TWAP

Rondo calls twap(300, maxOracleAge, 5) on the selected Orakl feed. The returned answer averages the observations published during the previous five minutes and requires at least five of them. getOraclePrice() returns this value together with the latest observation timestamp and a stale flag; it does not return the latest individual round.

The same reference is used for Fixed-order band checks, Pegged-order creation, live Pegged quotes, and Pegged fills. A stale latest observation, a non-positive answer, or an unavailable five-minute average blocks those oracle-dependent actions. Fixed fills and cancellations remain independent of the feed.

The two quote paths

Fixed

amountIn = mulDiv(sellAmountOut, buyAmount, sellAmount, Rounding.Ceil);

No oracle dependency and no price drift. Ceil, so the fraction of a unit rounding cannot represent always lands on the maker’s side.

Pegged

fee      = floor(out × feeBps / BPS)
netOut   = out − fee
discount = BPS + premiumBps

// maker sells the regional base token
amountIn = ceil(netOut × answer × BPS² / (priceScale × discount))

// maker sells USDT (the quote token)
amountIn = ceil(netOut × priceScale / (answer × discount))

The taker’s net proceeds are valued at the five-minute reference price, then discounted so their realised edge lands exactly on the premium.

peggedRateNow rounds down, the fill’s amountIn rounds up, and the floor check compares un-normalised amounts. This ensures a floor accepted at creation cannot exceed the amount a fill actually settles. FloorAboveMarket rejects an order that would be unable to fill immediately.

Premium and fee — who actually pays

The premium is defined as the taker’s realised edge after the desk fee, not as an approximation of it. That single decision determines who funds the fee, and it is the thing most likely to be misread from outside.

One fill, end to end

The following is a JPYC-market example: pegged JPYC-sell · premium 40 bps · fee 30 bps · oracle answer 632836 (8 dp).

taker pays	628.423797 USDT
gross released from escrow (the argument)	100,000 JPYC
desk fee, out of that	−300 JPYC
taker receives	99,700 JPYC
…worth, valued at the oracle price	630.937492 USDT

Party	Outcome vs the oracle price	bps
Taker	exactly the advertised premium, all in	+40.00
Maker	funds the taker’s edge and the desk’s cut	−69.72
Desk	300 JPYC ≈ 1.898508 USDT	+30.00

makerCost = 1 − (BPS − fee)/(BPS + premium) = 1 − 9970/10040 = 69.72 bps

A maker who types 0.25% against a 0.30% fee does not give up 0.25%. They give up 0.55%.

Two-sided pegged execution

Filling a pegged JPYC-sell and a pegged USDT-sell in one transaction nets 2 × premium, independent of the fee, because the fee divides out of the pegged ratio on both legs.

This is the intended economic model. The desk exists for fast rebalancing, and the premium pays for it. A bot closing both legs completes both makers’ rebalances instantly and takes exactly the edge those makers advertised. The lever on it is maxPremiumBps, not the fee.

Pricing on the gross amount and forcing premiumBps ≤ feeBps would make the round trip unprofitable, but it would also give the taker premium − fee ≤ 0, so pegged orders could never pay a taker anything.

Fixed orders behave differently: the same round trip on a fixed book priced at the oracle produces an outcome of roughly −2 × fee.