06Market design

Fees that can adapt to risk

Tokenized real-world markets do not have one constant risk profile. Volatility, earnings events, traditional market hours, and reference-data quality can all change the cost of providing liquidity.

Normal conditionsTighter fees may support efficient trading.

Elevated volatilityHigher fees may compensate LPs for additional risk.

Market closedFees may account for gaps in the external reference market.

Oracle uncertaintyRisk controls may restrict or pause execution.

The case for varying the fee at all rests on an observation about who bears the cost when conditions change. A fixed fee is set for average conditions, which means it overcharges during quiet periods and undercharges during volatile ones. The undercharging is the expensive half. It is precisely when the market is moving fastest that LPs are most exposed to being picked off, and a rate calibrated for calm markets does not come close to covering it.

Adverse selection is the mechanism underneath that. An LP quoting a fixed price trades against whoever finds that price attractive, and the traders who find it most attractive are the ones acting on something the market has not reflected yet. In a quiet market that flow is a small share of volume. During a fast move, or while an external market is closed and the onchain price is running on stale information, it can be most of it.

The design principle is simple: when providing liquidity becomes riskier, the fee reflects that risk. A market that charges the same rate through a calm session and a violent one is mispricing at least one of them.

How fee value can flow

Trading fees accrue primarily to liquidity providers, with the protocol retaining a configurable share. The interface discloses the current fee and its distribution before a user confirms an action.

Inputs a fee model can use

A dynamic fee is only as good as what it observes. These are the inputs a model can reasonably take into account for a tokenized real-world market.

Realized volatilityHow far the market has moved recently, measured over a stated window.
Reference divergenceThe distance between the onchain price and an external reference.
Market sessionWhether the external market for the underlying is open, closed, or about to open.
Data qualityWhether reference inputs are fresh, delayed, or unavailable.

None of those inputs is reliable alone. Realized volatility is backward-looking and says nothing about a move that is about to happen. Reference divergence detects a market that has already drifted rather than one that is about to. Session awareness is a calendar fact rather than a market observation. A workable model combines them so that the failure of any single input degrades the fee rather than breaking it.

The shape of a fee response

A dynamic fee is a function from observed conditions to a rate. The useful design question is not the exact formula but how sharply the rate should respond, and how quickly it should return to normal once conditions do.

Response sizeHow far the fee moves for a given change in volatility or divergence.

Response speedHow quickly the fee rises once conditions deteriorate.

DecayHow quickly it returns to the base rate once conditions normalize.

HysteresisWhether the fee is deliberately slower to fall than to rise, so it does not oscillate.

A fee that rises and falls instantly can oscillate with the market and make quotes unstable. A fee that rises slowly protects LPs too late to matter. Both failure modes are more consequential than the choice of base rate.

Hysteresis is worth stating plainly because it looks like a bug to anyone reading the fee alone. A market whose volatility has returned to normal but whose fee has not yet fallen appears to be overcharging. What it is actually doing is declining to assume that one calm interval means the episode is over, which is the same judgment a market maker makes by hand when they widen a spread and then wait before tightening it again.

Bounds a dynamic fee needs

An adaptive rate without limits is a source of risk rather than a control on it. Every schedule carries explicit bounds, visible to LPs and traders alike.

A floorThe rate below which the fee never falls, so LPs are compensated even in calm conditions.
A ceilingThe rate above which it never rises, so a data problem cannot make a market unusable by accident.
A maximum rate of changeA limit on how far the fee can move between observations, so a quote stays meaningful for the length of a transaction.
A defined fallbackThe rate that applies when the inputs the model depends on are unavailable.

The bound that matters most in practice is the ceiling, because fee models fail toward high values rather than low ones. A stale input looks like extreme divergence, a gap in the data looks like a volatility spike, and both push the rate upward. Without a ceiling a data problem becomes a market that is technically operating and practically closed, which is worse for everyone than a market that has restricted execution and said so.

Worked scenarios

These illustrate how the inputs above combine across the conditions a tokenized real-world market actually passes through in a week.

Quiet session, live referenceVolatility low and reference fresh, so the fee sits at or near its floor.

Earnings releaseRealized volatility rises sharply while the reference stays live, so the fee rises and then decays over the following session.

Underlying market closedNo fresh reference and real gap risk on reopen, so the fee accounts for a price that can jump.

Reference stale or missingThe model has no reliable input, so execution guards matter more than the rate does.

What must be disclosed

A fee that can change is only acceptable if it is legible at the moment it applies. The interface carries that obligation, not the contract.

Before a tradeThe exact fee that will be charged, not a range or an average.

Before a depositThe current fee level and how fee value is split between LPs and the protocol.

After the factThe fees a position actually earned, separated from projected or estimated values.