The Curve and Invariants
Every V6 intent utilizes a two-segment curve to define the signed floor at any given moment. This
pricing mechanism is verified by IntentLib.requiredOut and enforced during settlement. The
solver’s gross requirement also includes the protocol fee and, for outsiders at or before startTime,
the exclusivity override.
The Two-Segment Curve
Section titled “The Two-Segment Curve”The required output floor drops linearly and then rests flat.
- Before or at
startTime: The required output is strictlystartAmountOut. - Between
startTimeanddecayEndTime: The required output drops linearly fromstartAmountOutdown toendAmountOut. - At or after
decayEndTime: The required output rests atendAmountOutuntil the order completely expires atendTime.
startTime only SystemFillerGate may fill at the floor; an outsider fills that window at the dashed line. The 3 bps protocol fee is added on top of whichever floor applies and is paid by the solver.nowTs <= startTime -> startAmountOutnowTs >= decayEndTime -> endAmountOutotherwise -> startAmountOut - mulDiv(startAmountOut - endAmountOut, nowTs - startTime, decayEndTime - startTime)The resting stretch is the reason decayEndTime exists as a separate field from endTime. Separating
the two lets the floor rest after decay, leaving a fill window at the final price.
Soft Exclusivity and the Fee
Section titled “Soft Exclusivity and the Fee”At or before startTime, the order is fillable at its startAmountOut floor. Only
SystemFillerGate may fill at that floor. An outsider may still fill, but must
pay floor + 25 bps to the recipient. After startTime, everyone fills at the
curve floor. In every case, the solver also pays a 3 bps protocol fee on top of
the applicable floor; the fee is sent to FeeVault and never reduces the
owner’s proceeds.
Order Invariants
Section titled “Order Invariants”announce and fill run the structural checks in IntentLib.validate before doing anything
else. IntentLensV3.preview does not —
it computes observations directly and never calls validate, so a screener cannot treat a successful
preview as evidence that an order is well-formed.
| Check | Reverts with |
|---|---|
owner != 0, recipient != 0 |
InvalidOrder |
startTime < decayEndTime <= endTime |
InvalidOrder |
startAmountOut >= endAmountOut, both non-zero |
InvalidOrder |
amountIn != 0 |
InvalidOrder |
Neither token is 0x0 or the native sentinel (0xEeee...) |
NativeNotSupportedInOrder |
tokenIn != tokenOut |
SameToken |
The startTime < decayEndTime check is strict to ensure the division denominator when calculating the curve decay can never be zero. decayEndTime == endTime is permitted to support single-deadline limit behaviors if desired.
The protocol requires ERC-20 tokens only. Native ETH is fundamentally unsupported on both the input and output legs.