Routing #58

ewilz · 2023-09-01T21:12:22Z

Probably of interest to note that foundry gas snapshots are not accounting for storage clear refunds, so before we get transient storage in here, gas is incredibly exaggerated.

Could cut down on bytecode by removing Single options

single hops passing on exactOut

contracts/V4Router.sol

contracts/interfaces/IV4Router.sol

hensha256 · 2023-09-08T14:13:01Z

contracts/V4Router.sol

+
+    function _swapExactOutput(ExactOutputParams memory params, address msgSender) private {
+        unchecked {
+            for (uint256 i = params.path.length; i > 0; i--) {


ugh i dislike that this is from n to 1 not n-1 to 0... but I see the issue.
I guess it could be
for (uint256 i = params.path.length-1; i < params.path.length; i--) {
but thats also ugly so i guess theres no good way 😂

dude yah, I actually searched all Uniswap for i-- to see how ppl deal with this type of thing. And I found ANOTHER POC v4 router that Pote wrote ages ago and he did the same thing baha

I feel like this is typical for for loops iterating backwards through the path though.. like doesn't seem too weird to me. Is there a reason we force it to be backwards though? I guess compatibility with how other routers work but there is no reason we couldn't just encode the path the other way also

contracts/V4Router.sol

test/shared/implementation/V4RouterImplementation.sol

contracts/interfaces/IV4Router.sol

contracts/V4Router.sol

snreynolds · 2023-09-18T19:17:21Z

contracts/V4Router.sol

+
+    function _swapExactOutput(ExactOutputParams memory params, address msgSender) private {
+        unchecked {
+            for (uint256 i = params.path.length; i > 0; i--) {


I feel like this is typical for for loops iterating backwards through the path though.. like doesn't seem too weird to me. Is there a reason we force it to be backwards though? I guess compatibility with how other routers work but there is no reason we couldn't just encode the path the other way also

src/base/DeltaResolver.sol

src/libraries/CalldataBytesLib.sol

snreynolds · 2024-07-25T19:14:57Z

src/libraries/CalldataBytesLib.sol

+            res.offset := offset
+        }
+    }
+
    /// @notice Performs the equivalent of `abi.decode(data, (uint256[], bytes[]))` in calldata
    /// @param _bytes The input bytes string to extract input arrays from
    /// @return actions The uint256 calldata array of actions


I think decodeInCalldata is not memory-safe?

What about it isnt memory safe?

src/libraries/Actions.sol

src/V4Router.sol

snreynolds · 2024-07-27T20:46:43Z

src/V4Router.sol

+                if (delta > 0) revert InvalidDeltaForAction();
+
+                // TODO support address(this) paying too
+                // TODO should it have a maxAmountOut added slippage protection?


my thought is that slippage protection should be with the swap commands? why do we also need slippage protection with settle commands?

i think we can make settle just take an amount, and if you're ok with the full settle amount then you pass in a constant/sentinel

Its to support split route trades. Lets say youre trading 1000 DAI for USDC, where you want at least 998 USDC

500 DAI -> USDT -> USDC

500 DAI -> USDC

Then you would do a command thats like "take all USDC, and check we're receiving at least 998".

We implement the same style of logic in UR using the sweep command e.g. here

For v3 split routes it trades both routes, with the recipient of the UR, and then calls SWEEP(USDC, 998) which will revert the trade if 998 weren't received

And we do it with the unwrapETH command to do the same check for ETH output trades e.g. here

but surely you're also checking slippage from USDT to USDC and from DAI to USDC? or are you ignoring those checks until the end? My concern is that we're doing lots of slippage checks and the ones in the middle then dont even matter?

My other thought process then also is just if posm & routers take/settle commands looks different now bc I was not planning on doing extra slippage checks on take/settle. (IK this is a future TODO but just adding my thoughts in this thread. Not blocking on getting this PR merged)

but surely you're also checking slippage from USDT to USDC and from DAI to USDC? or are you ignoring those checks until the end? My concern is that we're doing lots of slippage checks and the ones in the middle then dont even matter?

yeah the ones in the middle dont matter. the user doesnt care if one half of the trade gets hit with more slippage than the other - theres just an output amount that they want from the trade in total and thats it

for split route trades we pass in 0 as minAmountOut at each stage - and then do aggregated slippage checks on total output

My other thought process then also is just if posm & routers take/settle commands looks different now

yeah i could do it as a different cmmand or something depending how the other commands end up

src/V4Router.sol

snreynolds · 2024-07-29T19:05:02Z

src/base/DeltaResolver.sol

@@ -7,6 +7,9 @@ import {ImmutableState} from "./ImmutableState.sol";
 /// @notice Abstract contract used to sync, send, and settle funds to the pool manager
 /// @dev Note that sync() is called before any erc-20 transfer in `settle`.
 abstract contract DeltaResolver is ImmutableState {
+    /// @notice Emitted trying to settle a positive delta, or take a negative delta


should we make this type(uint256).max so its super explicit? Also matches other patterns like approving with type(uint256).max to mean my entire balance

Oh weird.. on codespaces the code I was reviewing had the changes where you kept the flag for checking to use the contract balance.. I guess we can do that in a different PR!

snreynolds · 2024-07-29T19:12:37Z

src/V4Router.sol

+                // equivalent: abi.decode(params, (Currency, address))
+                Currency currency;
+                address recipient;
+                assembly ("memory-safe") {


#199 just tagging that 199 should also put these in a lib so we can use in both contracts

snreynolds · 2024-07-29T19:18:01Z

src/V4Router.sol

+            for (uint256 i = pathLength; i > 0; i--) {
+                pathKey = params.path[i - 1];
+                (PoolKey memory poolKey, bool oneForZero) = pathKey.getPoolAndSwapDirection(currencyOut);
+                amountIn = uint128(-_swap(poolKey, !oneForZero, int256(uint256(amountOut)), 0, pathKey.hookData));


I feel like I commented at some point about documenting/adding a little comment about the return signs but can't find it anywhere.. Anyways I do think it would be nice explaining that the output is guaranteed to be negative for exactOutput in the reciprocal token.

have actually added a safecast on this - i think with custom accounting hooks on low liquidity pools its technically not guaranteed

snreynolds

ok looks good! I do think we should be adding some more tests (like split routes) but we can followup?

snreynolds · 2024-07-29T19:22:22Z

src/base/DeltaResolver.sol

@@ -7,6 +7,9 @@ import {ImmutableState} from "./ImmutableState.sol";
 /// @notice Abstract contract used to sync, send, and settle funds to the pool manager
 /// @dev Note that sync() is called before any erc-20 transfer in `settle`.
 abstract contract DeltaResolver is ImmutableState {
+    /// @notice Emitted trying to settle a positive delta, or take a negative delta


Oh weird.. on codespaces the code I was reviewing had the changes where you kept the flag for checking to use the contract balance.. I guess we can do that in a different PR!

test/shared/RoutingTestHelpers.sol

snreynolds · 2024-07-29T19:31:24Z

test/router/V4Router.t.sol

+
+    function test_swapExactInputSingle_oneForZero() public {
+        uint256 amountIn = 1 ether;
+        uint256 expectedAmountOut = 992054607780215625;


where is this number from? I think you could use deltas instead of hardcoding?

gonna do this in the next PR - #221

snreynolds · 2024-07-29T21:44:11Z

src/libraries/SafeCast.sol

+
+/// @title Safe casting methods
+/// @notice Contains methods for safely casting between types
+library SafeCast {


why not just import SafeCast from core?

this function doesnt exist in core rip

snreynolds

approving, but will need to move that func to core! (alice opening issue)

ewilz added 11 commits August 24, 2023 13:38

start routing

b6f8d3b

start routing contract

d5dc31a

naive swapExactIn impl

2ca710a

lint + bytecode snapshot

664d2c2

change concept of hops to token hops

8b687b8

UniswapV4Routing --> Routing

1717039

use PathKey

2549c3a

exactInputSingle

e1c46fd

save DRY progress

8aae01b

no sqrtPriceLimit for multipool hops

5823d2f

exactOut implemented w awkward loops/int conversions

7e25390

single hops passing on exactOut

ewilz force-pushed the routing branch from 679682d to 7e25390 Compare September 5, 2023 19:17

ewilz added 3 commits September 5, 2023 16:12

gas savings from not doing double negative number

607ea3b

gas savings from unchecked math

cf82527

add swapExactOuputSingle

9ebc9d5

ewilz marked this pull request as ready for review September 5, 2023 21:01

ewilz changed the title ~~[WIP] Routing~~ Routing Sep 5, 2023

break out structs into interface

54a48e5

ewilz commented Sep 5, 2023

View reviewed changes

contracts/V4Router.sol Outdated Show resolved Hide resolved