Premium ratio

Leg-by-leg RFQ offers, CLOB PairKeys, and maker EIP-712 payloads encode premium as a discrete signed tick. Strike is a direct WAD ratio (uint144).

R = LibPremiumTickMath.premiumRatioFromTick(premiumTick)
  # premiumTick == 0  →  R = 0  (zero premium; no ladder)
  # else              →  R = ⌊1e18 × 1.0001^tick⌋

premium_raw ≈ amount × R ÷ 1e18            # buyer pays ceil; seller earns floor

amount: trade size in underlying base units (the same integer the intent / PairKey uses).
premiumTick / premium_tick: on-chain and API fields (int32).
premium_raw: amount of the premium token pulled or paid, in that token’s base units.

Zero premium: premiumTick == 0 always means zero premium. Required for FixedPackage / Dutch legs (fillMatched after an absolute package premium) and any RFQ leg priced at zero option premium.

There is no decimal conversion between underlying and premium. The chain multiplies and divides integers only. How that raw number reads in a wallet depends on whether the premium token is the same asset (and decimals) as the underlying.

Protocol and referral fees are separate from this ratio: Fees. On the resting book the fill fee is taken out of the posted amount. Package premium adds the protocol fee on top, at half rate when the maker pays.

Tick math

Ticks follow a Uniswap V3–style geometric ratio (1.0001^t), implemented in LibPremiumTickMath:

Tick	Ratio `R` (WAD)	Approx. % of size
`0`	`0`	0% (zero premium; not on the ladder)
nearest ceil to `1e16`	`≈ 1e16`	~1%
nearest ceil to `3.6e16`	`≈ 3.6e16`	~3.6%

Nonzero ticks must stay in [MIN_RATIO_TICK, MAX_TICK] ([-414486, 887272]). Out-of-range ticks revert on post / validate paths.

The trading app still accepts percent input in some flows (e.g. CLOB post: 1.5 → 1.5% of size). It encodes that as the nearest ceil tick before calling the mothership (encodePremiumTickFromPercent / ceilTickFromRatio in the trading app).

The UI shows the absolute premium (formatted with the premium token’s ERC-20 decimals) as the lead figure, with percent underneath when helpful.

Same token as the underlying

When the premium token is the underlying (or another token with the same decimals and economic scale), the ratio reads like a normal percent of size.

Example: 1 WETH size, premium paid in WETH (18 decimals), ~3.6% (R ≈ 36e15)

amount       = 1_000_000_000_000_000_000   # 1 WETH
premium_raw  = ceil(amount × R ÷ 1e18)
             ≈ 36_000_000_000_000_000      # 0.036 WETH

Use this mode when you want premium to read as a clean percentage of the underlying notional.

Different token from the underlying

When the premium token is not the underlying, for example WETH size priced in USDC (6 decimals), the formula is unchanged. The raw product is still interpreted in premium-token base units.

Example: 1 WETH size, premium paid in USDC (6 decimals), ~3.6%

amount       = 1_000_000_000_000_000_000   # 1 WETH (18 decimals)
premium_raw  = amount × R ÷ 1e18
             ≈ 36_000_000_000_000_000      # still that integer

Formatted as USDC (6 decimals), that integer is enormous, not “3.6% of a dollar price.” The raw formula does not convert decimals.

The trading app (and the local fake maker) therefore scale a human percent of size by 10^(premiumDecimals − sizeDecimals) before encoding the tick, so 3.6% of 1 WETH pays 0.036 USDC, not 36 billion. Offer cards show the human percent and the scaled token amount.

Premium token vs underlying	How the ratio feels
Same token (e.g. WETH / WETH)	≈ percent of size; human amounts look right
Same decimals, different token	Same numeric percent of raw size; value depends on relative token prices
Different decimals (e.g. WETH size / USDC premium)	Raw `amount × R / 1e18` in USDC units: not “percent of USD spot”

Practical guidance:

Prefer premium = underlying (or same decimals) when quoting per-leg ratios so 1% encodings read as 1% of size in wallet terms.
If premium must be a stablecoin while size is an 18-decimal asset, treat the absolute premium as the real price: or use package / Dutch paths that settle an absolute premium instead of per-leg ratios.

Strike WAD

Intents and PairKeys store strike as strikeWad (uint144): a direct WAD ratio. Settlement: strikeCost ≈ amount × strikeWad / 1e18. Human-readable strike views: on-chain strikePriceViews (token decimals + optionType).

For a whole-number strike in premium-token decimals (e.g. USDC-6 → 2500 USDC), set strike_wad to that integer string in API JSON (e.g. "2500000000").

Trading app setting

In the quote box gear menu, Premium chooses how the premium token is picked:

Mode	Behavior
Same as quote (default)	Premium follows the pair quote token
Same as underlying	Premium matches the underlying (ratio reads as % of size)
Manual	Toolbar Premium pick is fixed until you change this setting again

Picking a different token in the toolbar Premium dropdown switches to Manual automatically.

Package and Dutch (absolute premium)

Not every path uses per-leg ratios for the money that changes hands:

Mode	How premium is set
Leg-by-leg RFQ / CLOB PairKey	`premiumTick` → `R` → `amount × R / 1e18`
FixedPackage	Absolute package premium in the premium token
Dutch	Absolute start / end premium schedule in the premium token

FixedPackage and Dutch still end in fillMatched with premiumTick = 0 on each leg after the package premium is settled. See CLOB and On-chain fill modes.

Where this shows up

Surface	Premium fields
Maker RFQ offer (`premium_tick`)	Directionless Buy / Sell ticks per leg
Trading app offer list	Absolute premium primary; percent secondary
Manual CLOB post	You enter a percent; UI encodes a ceil tick and shows total premium tokens
PairKey / ERC-6909 id	Packs `premiumTick` + `strikeWad` into the option id

Tick math​

Same token as the underlying​

Different token from the underlying​

Strike WAD​

Trading app setting​

Package and Dutch (absolute premium)​

Where this shows up​