Gas Adjustment Feature #273

codyborn · 2024-09-11T17:16:35Z

Adjusts the auction start price based on the change in block.basefee from the time the swapper signed the order to the time of execution. The adjustment can be in favor of the swapper (unlimited) or against the swapper (bounded by slippage).

The goal of this mainnet-focused feature is to:

improve PI (give users more tokens when gas decreases)
decrease fade rate and missing-exclusivity when gas prices increase

To know how much to adjust the input/output token by, I introduce a new field adjustmentPerGweiBasefee which is the amount of token to change per gwei of change to the basefee. As @0age mentioned on the call, it should be calculated by (total gas of swap * token/eth).

src/lib/MathExt.sol

src/lib/NonlinearDutchDecayLib.sol

src/lib/V3DutchOrderLib.sol

zhongeric · 2024-09-11T17:45:07Z

src/reactors/V3DutchOrderReactor.sol

+        int256 gasDeltaGwei = block.basefee.sub(order.gasSnapshot);
+
+        // Gas increase should increase input
+        int256 inputDelta = int256(order.baseInput.adjustmentPerGweiBasefee) * gasDeltaGwei / 1 gwei;


is gwei too large of a denominator? I wonder if wei or some percentage of a gwei would be better, then we can move this into a constant

mulDivDown? or does that not support signed ints

@marktoda yeah mulDivDown only supports uint256.

@zhongeric I was thinking about this a lot too.. I think gwei is the easiest to reason about with today's gas prices. The int256 gives us ~1e76 of space and if we assume gas is around 1e9-1e11 we get a range of 1 wei - 1e65 for possible adjustmentPerGweiBasefee values.

If we look at low value token like SHIB for example which has 18 decimals and is worth 0.0000000057064226 ETH, 1 gwei = 5.7064226 SHIB, so we'd want the adjustmentPerGweiBasefee = 5706422600 * 10k gas and we'd still have 1e53 of wiggle room before overflowing.

src/reactors/V3DutchOrderReactor.sol

codyborn · 2024-09-11T17:54:56Z

src/lib/DutchDecayLib.sol

+    /// @param currentPoint The current position in the decay
+    /// @param startAmount The amount of the start of the decay
+    /// @param endAmount The amount of the end of the decay
+    function linearDecay(


I added another version of this that accepts int256 for start and end amount.

I wanted to decay only through the relative amounts so that I can apply the bounding logic (min/max) check after the decay.

It was too convoluted to try to support both in the same function.

Note that this linearDecay performs mulDivDown in both positive and negative cases as it felt more intuitive. Happy to discuss!

can the uint one call this one w/ casted params?

Yup! I was trying to do the other way around, but as long as we're okay with losing 1 bit of precision, it's cleaner.

codyborn · 2024-09-11T17:56:21Z

src/lib/V3DutchOrderLib.sol

            OrderInfoLib.ORDER_INFO_TYPE,
-            DutchOrderLib.TOKEN_PERMISSIONS_TYPE
+            DutchOrderLib.TOKEN_PERMISSIONS_TYPE,
+            V3_DUTCH_INPUT_TYPE,


Some of these are fixes from this PR
#269

marktoda · 2024-09-12T15:20:10Z

src/lib/DutchDecayLib.sol

+            return endAmount;
+        }
+        unchecked {
+            uint256 elapsed = currentPoint - startPoint;


do we need to check for startPoint > currentPoint to avoid overflow here?

Good question. It's not possible with the current code since the caller passes in either 0 or relativeBlocks.getElement(prev) for the startPoint where relativeBlocks.getElement(prev) is guaranteed to be less than the currentPoint.

Similarly it's not possible for the startPoint to be greater than or equal to the endPoint. It could be equal if (currentPoint > endPoint) but we check that above. Otherwise, the locateCurvePosition() call ensures that it halts the search as soon as it finds a block that is greater than or equal to the blockDelta, meaning every value that came before it would be less than the blockDelta (and transitively less than the block it finds).

It IS possible for this int256 cast to overflow if startAmount is max int256 and endAmount is negative:
int256(0 - uint256(startAmount - endAmount).mulDivDown(elapsed, duration)

Going to remove the unchecked.

marktoda · 2024-09-12T15:20:25Z

src/lib/DutchDecayLib.sol

+    /// @param currentPoint The current position in the decay
+    /// @param startAmount The amount of the start of the decay
+    /// @param endAmount The amount of the end of the decay
+    function linearDecay(


can the uint one call this one w/ casted params?

marktoda · 2024-09-12T15:25:17Z

src/reactors/V3DutchOrderReactor.sol

+        int256 gasDeltaGwei = block.basefee.sub(order.gasSnapshot);
+
+        // Gas increase should increase input
+        int256 inputDelta = int256(order.baseInput.adjustmentPerGweiBasefee) * gasDeltaGwei / 1 gwei;


mulDivDown? or does that not support signed ints

marktoda · 2024-09-12T15:28:08Z

src/lib/V3DutchOrderLib.sol

-                output.recipient
+                output.recipient,
+                output.minAmount,
+                output.adjustmentPerGweiBasefee


is gwei enough granularity? think even partial gwei changes in basefee may be impactful

Yeah, it's denominated in gwei but since the division by 1 gwei happens after the multiplication, we can take advantage of wei-level changes in the gas fee.
int256 inputDelta = int256(order.baseInput.adjustmentPerGweiBaseFee) * gasDeltaGwei / 1 gwei

See this test for example:

UniswapX/test/reactors/V3DutchOrderReactor.t.sol

Line 1127 in c0d6998

assertEq(resolvedOrder.input.amount, 1 ether - 0.5 gwei);

zhongeric

looks good with some comments!

src/lib/DutchDecayLib.sol

src/lib/MathExt.sol

src/lib/NonlinearDutchDecayLib.sol

src/lib/V3DutchOrderLib.sol

zhongeric · 2024-09-13T16:17:29Z

test/lib/DutchDecayLib.t.sol

@@ -74,27 +74,26 @@ contract DutchDecayLibTest is Test {
        assertEq(DutchDecayLib.decay(2 ether, 1 ether, 100, 200), 1 ether);
    }

-    function testDutchDecayBounded(uint256 startAmount, uint256 endAmount, uint256 decayStartTime, uint256 decayEndTime)
+    function testDutchDecayBounded(int256 startAmount, int256 endAmount, uint256 decayStartTime, uint256 decayEndTime)


why change types to int256 to cast to uint256 in the test?

it helps bound the values to a range to prevent overflow.. I tried vm.assume(startAmount < 2* 255 - 1) but forge testing would fail saying it hit the max number of failing input.

Ah I see, and bound would reject too many probably

zhongeric

Niceee!!

* WIP * Builds successfully * First set of tests * Unit tests + array packing * More tests * Moar tests * Remove yarn.lock * forge fmt * Custom types * Missed file * Improve readibility and add gas test * Binary search * Linear search + gas tests * Rename to V3 * Reactor tests pt1, refactor tests, fmt * More reactor tests, address PR feedback * Forge fmt * More tests * Fix old exclusivity test * Consolidate decay logic * Address PR feedback * PR feedback * Gas Adjustment Feature (#273) * Gas adjustment feature and tests * Update 712 structs * Final tests * Address PR feedback * Natspec * PR Feedback * edge case fix and gas improvements * Simplify NonlinearDecay logic

codyborn added 3 commits September 10, 2024 16:41

Gas adjustment feature and tests

87af942

Update 712 structs

c7f9158

Final tests

c0d6998

codyborn requested review from zhongeric and marktoda September 11, 2024 17:16

zhongeric reviewed Sep 11, 2024

View reviewed changes

codyborn commented Sep 11, 2024

View reviewed changes

marktoda reviewed Sep 12, 2024

View reviewed changes

codyborn added 2 commits September 12, 2024 17:31

Address PR feedback

2739a3a

Natspec

4b7c620

zhongeric approved these changes Sep 13, 2024

View reviewed changes

PR Feedback

fd42565

zhongeric approved these changes Sep 13, 2024

View reviewed changes

edge case fix and gas improvements

b25157e

marktoda approved these changes Sep 18, 2024

View reviewed changes

Merge main

1d15301

codyborn merged commit e29b287 into nonlinear_decay Sep 18, 2024
3 checks passed

codyborn deleted the gas_volatility branch September 18, 2024 22:49

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Gas Adjustment Feature #273

Gas Adjustment Feature #273

codyborn commented Sep 11, 2024 •

edited

Loading

zhongeric Sep 11, 2024

marktoda Sep 12, 2024

codyborn Sep 12, 2024 •

edited

Loading

codyborn Sep 11, 2024

marktoda Sep 12, 2024

codyborn Sep 12, 2024

codyborn Sep 11, 2024

marktoda Sep 12, 2024

codyborn Sep 12, 2024 •

edited

Loading

codyborn Sep 13, 2024

marktoda Sep 12, 2024

marktoda Sep 12, 2024

marktoda Sep 12, 2024

codyborn Sep 12, 2024

zhongeric left a comment

zhongeric Sep 13, 2024

codyborn Sep 13, 2024

zhongeric Sep 13, 2024

zhongeric left a comment

Gas Adjustment Feature #273

Gas Adjustment Feature #273

Conversation

codyborn commented Sep 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codyborn Sep 12, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codyborn Sep 12, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zhongeric left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zhongeric left a comment

Choose a reason for hiding this comment

codyborn commented Sep 11, 2024 •

edited

Loading

codyborn Sep 12, 2024 •

edited

Loading

codyborn Sep 12, 2024 •

edited

Loading