sneak/AutistMask
1
0
Fork 0
Code Issues 23 Pull Requests 2 Actions 162 Packages Projects Releases Wiki Activity

fix: a V3 exact-out swap step shows its tokens and amounts (closes #601)
check / check (push) Waiting to run
Details
e2e / e2e-chrome (push) Waiting to run
Details
e2e / e2e-firefox (push) Waiting to run
Details

Browse Source 
A V3_SWAP_EXACT_OUT step was named in the Steps line but never read, so
its tokens read as not named in the calldata and it gave no amounts. It
is now read as a V2_SWAP_EXACT_OUT is: its path from the token it buys
to the token it spends, as the router reads it, its amountInMax as the
most it spends, its amountOut as the minimum, and its recipient as the
address it pays. One the user pays for after the step that sets the
input side joins the Amount total. A V3 path with bytes after its last
whole hop, which the router ignores, leaves either V3 swap step unread.

Also closes #637.

Model: opus-5-5
This commit was merged in pull request #636.
This commit is contained in:
clawbot
2026-10-20 10:06:09 +02:00
parent ba27ddced0
commit 657dc14f04
4 changed files with 392 additions and 174 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+136 -127
View File
@@ -1176,18 +1176,18 @@ number. They can read:
- `Unlimited`: on the ERC-20 `Amount` line, an `approve` of the `uint256`
maximum, an unbounded allowance. On the swap's `Amount` line, any amount at or
above the `uint160` maximum, whichever step set the line: a `PERMIT2_PERMIT`
amount at that maximum, which is an unbounded permit, or a V2 or V3 exact-in,
V2 exact-out or `WRAP_ETH` amount that large, which is not an allowance. The
amount at that maximum, which is an unbounded permit, or a V2 or V3 exact-in
or exact-out or `WRAP_ETH` amount that large, which is not an allowance. The
router's whole-balance value, `CONTRACT_BALANCE` (`2^255`), is one such
amount.
- `Up to <amount>`: the swap's `Amount` line, when the transaction has a V2
exact-out step, whichever step set the line, including the `WRAP_ETH` of a
- `Up to <amount>`: the swap's `Amount` line, when the transaction has a V2 or
V3 exact-out step, whichever step set the line, including the `WRAP_ETH` of a
swap paid in ETH and a `PERMIT2_PERMIT`. The swap spends at most that figure,
not necessarily all of it; the wait, success and error screens show it with
the same words. `Unlimited`, `All available (V4 open delta)` and
`Whatever an earlier step sent to the pair (V2 already paid)` keep their
wording. When a V2 exact-out step sets `Min. received`, that line shows its
`amountOut`, the exact amount it buys.
wording. When a V2 or V3 exact-out step sets `Min. received`, that line shows
its `amountOut`, the exact amount it buys.
- `All available (V4 open delta)`: the swap's `Amount` line, when the amount it
shows is a V4 exact-in `amountIn` of zero. V4 reads that zero as "use the
whole open delta", so the calldata states no quantity. Transaction Decoding
@@ -3011,29 +3011,35 @@ Currently supported:
Router addresses Uniswap publishes for the network: on TxApproval the network
the transaction is for, on TransactionDetail the network it was sent on. The
same calldata sent to any other address is shown as raw data. Decodes Permit2,
V2/V3/V4 swaps, wrap/unwrap, and balance checks. A V4 swap action is read only
in the parameter shape deployed on mainnet and Sepolia, not in the newer one
on `v4-periphery` `main`, which adds a `minHopPriceX36` field. An action in
any other shape is not read, and its step is listed as
`V4 Swap (could not be decoded)`. Each step is named and read as the command
that the release of the router at that address runs for its command type, as
that release's `contracts/libraries/Commands.sol` names it. The decoder reads
the type from the command byte with the mask that router uses: `0x1f` for
`UniversalRouterV1`, `0x3f` for `UniversalRouterV1_2_V2Support` and
`UniversalRouterV2`, and `0x7f` for `UniversalRouterV2_1_1` and
`UniversalRouterV2_1_2`. The allow-revert flag (`0x80`) therefore does not
change the command a step is read as. Releases run different commands for some
types: on `UniversalRouterV1` and `UniversalRouterV1_2_V2Support`, `0x10` to
`0x13` are NFT commands, where the later routers run `V4_SWAP`,
`V3_POSITION_MANAGER_PERMIT`, `V3_POSITION_MANAGER_CALL` and
`V4_INITIALIZE_POOL`. The decoder does not read those routers' NFT commands,
and lists each by its name there, for example `Seaport` for `SEAPORT` (`0x10`
on `UniversalRouterV1`). A type a release names no command for is listed by
its number, for example `Command 0x0e` on `UniversalRouterV1`, which has no
`BALANCE_CHECK_ERC20` and reverts on it. The router reverts the whole
transaction when a step fails, unless the step's command byte has that flag
set and its command is one the router lets fail, as each release's
`contracts/base/Dispatcher.sol` shows: on `UniversalRouterV2`,
V2/V3/V4 swaps, wrap/unwrap, and balance checks. A V3 swap step's path is read
as the router reads it: a `V3_SWAP_EXACT_IN` path runs from the token it
spends to the token it buys, and a `V3_SWAP_EXACT_OUT` path from the token it
buys to the token it spends, so that step's input token is its path's last
token and its output token the first. The router reads a path as one token
address followed by whole hops of a 3-byte fee and a token address, and
ignores any bytes after the last hop, so the decoder does not read a path with
such bytes. A V4 swap action is read only in the parameter shape deployed on
mainnet and Sepolia, not in the newer one on `v4-periphery` `main`, which adds
a `minHopPriceX36` field. An action in any other shape is not read, and its
step is listed as `V4 Swap (could not be decoded)`. Each step is named and
read as the command that the release of the router at that address runs for
its command type, as that release's `contracts/libraries/Commands.sol` names
it. The decoder reads the type from the command byte with the mask that router
uses: `0x1f` for `UniversalRouterV1`, `0x3f` for
`UniversalRouterV1_2_V2Support` and `UniversalRouterV2`, and `0x7f` for
`UniversalRouterV2_1_1` and `UniversalRouterV2_1_2`. The allow-revert flag
(`0x80`) therefore does not change the command a step is read as. Releases run
different commands for some types: on `UniversalRouterV1` and
`UniversalRouterV1_2_V2Support`, `0x10` to `0x13` are NFT commands, where the
later routers run `V4_SWAP`, `V3_POSITION_MANAGER_PERMIT`,
`V3_POSITION_MANAGER_CALL` and `V4_INITIALIZE_POOL`. The decoder does not read
those routers' NFT commands, and lists each by its name there, for example
`Seaport` for `SEAPORT` (`0x10` on `UniversalRouterV1`). A type a release
names no command for is listed by its number, for example `Command 0x0e` on
`UniversalRouterV1`, which has no `BALANCE_CHECK_ERC20` and reverts on it. The
router reverts the whole transaction when a step fails, unless the step's
command byte has that flag set and its command is one the router lets fail, as
each release's `contracts/base/Dispatcher.sol` shows: on `UniversalRouterV2`,
`UniversalRouterV2_1_1` and `UniversalRouterV2_1_2`, `PERMIT2_PERMIT`,
`PERMIT2_PERMIT_BATCH`, `BALANCE_CHECK_ERC20`, `V3_POSITION_MANAGER_PERMIT`,
`V3_POSITION_MANAGER_CALL`, `V4_INITIALIZE_POOL`, `V4_POSITION_MANAGER_CALL`
@@ -3096,40 +3102,42 @@ Currently supported:
as a swap paid in ETH does, but only when that amount is not
`CONTRACT_BALANCE` and the router held no WETH from an earlier step when the
`WRAP_ETH` ran: after two `WRAP_ETH`s of 0.5 ETH into the router, a swap of 1
WETH from it reads as leaving the WETH there. A `SETTLE` of `OPEN_DELTA`
(zero), and a `SETTLE_ALL`, pay only what the step still owes of their token
when they run. The decoder takes that to be the amounts the step's swap
actions state they spend of that token only when every action in the step
could be read, every swap action names the token it spends and the token it
buys (a swap action with an empty path swaps nothing), the `SETTLE` or
`SETTLE_ALL` is the step's only `SETTLE` or `SETTLE_ALL` of that token and
comes after every swap action, no swap action buys that token, no `TAKE`,
`TAKE_ALL` or `TAKE_PORTION` in the step takes it (a `TAKE` of a stated amount
adds to what the step owes), and the swap actions that spend it state a
quantity together; otherwise it does not know the amount, and such a `SETTLE`
from the router counts as spending nothing. So the rest of a V4 `SETTLE` of
more than its swap spends, taken to the router, the WETH of a `WRAP_ETH`, and
a token a swap pays the router on the way to the output, each stays in the
router when later steps do not spend all of it, where anyone can take it in a
later transaction. The router sends ETH as written, so a `TRANSFER` of
`CONTRACT_BALANCE` of ETH always reverts and pays out nothing. A step paying a
token to the V2 pair that the very next step spends, as a V2 exact-in of that
token whose `amountIn` is `ALREADY_PAID` (zero) or `CONTRACT_BALANCE`, is a
hop, not a payout: Uniswap's mixed routes pay the next V2 pair directly, and
the router enforces that swap's own minimum. The decoder checks that the
address paid is that pair, deriving it from the V2 factory and pair init code
hash the network's routers were deployed with and the first two tokens of that
step's path; a payment to any other address is named. (Sepolia's
`UniversalRouterV1_2_V2Support` was deployed with placeholders for both
values, so no V2 swap step can succeed on that router.) Every other payment
counts, in whichever step and of whatever token, a share of the output
included: an interface fee paid to another address by `PAY_PORTION`,
`TRANSFER` or `TAKE_PORTION` is named, and the minimum reads `Min. paid out`,
because the swap's minimum includes the fee. The minimum reads `Min. received`
only when some step pays the transaction's sender (the From address on
TxApproval, the sender the explorer reports on TransactionDetail) and no
`Paid to` line is shown. `Paid to` lines after `Token Out` name each other
address paid; one reads
WETH from it reads as leaving the WETH there. A V2 or V3 exact-out step paid
from the router spends an amount the calldata does not state, at most its
`amountInMax`, so the decoder counts it as spending nothing the router holds.
A `SETTLE` of `OPEN_DELTA` (zero), and a `SETTLE_ALL`, pay only what the step
still owes of their token when they run. The decoder takes that to be the
amounts the step's swap actions state they spend of that token only when every
action in the step could be read, every swap action names the token it spends
and the token it buys (a swap action with an empty path swaps nothing), the
`SETTLE` or `SETTLE_ALL` is the step's only `SETTLE` or `SETTLE_ALL` of that
token and comes after every swap action, no swap action buys that token, no
`TAKE`, `TAKE_ALL` or `TAKE_PORTION` in the step takes it (a `TAKE` of a
stated amount adds to what the step owes), and the swap actions that spend it
state a quantity together; otherwise it does not know the amount, and such a
`SETTLE` from the router counts as spending nothing. So the rest of a V4
`SETTLE` of more than its swap spends, taken to the router, the WETH of a
`WRAP_ETH`, and a token a swap pays the router on the way to the output, each
stays in the router when later steps do not spend all of it, where anyone can
take it in a later transaction. The router sends ETH as written, so a
`TRANSFER` of `CONTRACT_BALANCE` of ETH always reverts and pays out nothing. A
step paying a token to the V2 pair that the very next step spends, as a V2
exact-in of that token whose `amountIn` is `ALREADY_PAID` (zero) or
`CONTRACT_BALANCE`, is a hop, not a payout: Uniswap's mixed routes pay the
next V2 pair directly, and the router enforces that swap's own minimum. The
decoder checks that the address paid is that pair, deriving it from the V2
factory and pair init code hash the network's routers were deployed with and
the first two tokens of that step's path; a payment to any other address is
named. (Sepolia's `UniversalRouterV1_2_V2Support` was deployed with
placeholders for both values, so no V2 swap step can succeed on that router.)
Every other payment counts, in whichever step and of whatever token, a share
of the output included: an interface fee paid to another address by
`PAY_PORTION`, `TRANSFER` or `TAKE_PORTION` is named, and the minimum reads
`Min. paid out`, because the swap's minimum includes the fee. The minimum
reads `Min. received` only when some step pays the transaction's sender (the
From address on TxApproval, the sender the explorer reports on
TransactionDetail) and no `Paid to` line is shown. `Paid to` lines after
`Token Out` name each other address paid; one reads
`The bridge, which pays the deposit's recipient on another network` for a
bridge deposit; one reads, for example,
`The router, 2000.0000 USDT from the sender (later steps may not spend all of it)`
@@ -3143,52 +3151,52 @@ Currently supported:
`Unknown (not named in the calldata)`. Wherever there is a `Paid to` line, the
minimum reads `Min. paid out`. The `Amount` line gives the total the steps
take of `Token In`, from the step that sets the input side on: the first V2 or
V3 exact-in, V2 exact-out, `WRAP_ETH` or V4 swap step that names an input
token or amount. A V4 step with a swap action sets the input side when no
earlier step set it, even when it names neither (see Display Consistency).
That step counts its own amount, whoever pays it: a V2 exact-out step its
V3 exact-in or exact-out, `WRAP_ETH` or V4 swap step that names an input token
or amount. A V4 step with a swap action sets the input side when no earlier
step set it, even when it names neither (see Display Consistency). That step
counts its own amount, whoever pays it: a V2 or V3 exact-out step its
`amountInMax`, and a V4 step what it takes of its input token from the user's
wallet, as below, or, when the user pays it none of that token, the `amountIn`
of the swap action that spends it. Each later V2 or V3 exact-in or V2
exact-out step whose `payerIsUser` is true takes its amount, found in the same
way, from the user's wallet. Every V4 step, with a swap action or without,
takes from the user's wallet what its `SETTLE`s paid by the user
(`payerIsUser` true) and its `SETTLE_ALL`s pay, for each token on its own;
what the step that sets the input side takes of any other token counts as a
later step's take. A `SETTLE` of any amount but `OPEN_DELTA` pays that amount,
and a `SETTLE` of `OPEN_DELTA` or a `SETTLE_ALL` pays what the step owes, as
above. So a V4 step that swaps 400 USDT, with a `SETTLE` of 5,000 USDT paid by
the user and the rest taken to another address, reads `5000.0000 USDT`. A
later step paid from the router spends what the router holds and takes
nothing, and so does a V2 exact-in whose `amountIn` is `ALREADY_PAID`. A later
take of `Token In` is added to the total while both are quantities: a V3
exact-in of 600 USDT and a V2 exact-in of 400 USDT, both paid by the user,
read `1000.0000 USDT`. When the decoder does not know a take's amount, the
total is not known and there is no `Amount` line. `Token In` is the token of
the last `PERMIT2_PERMIT` the decoder reads, when there is one. Its amount,
`Unlimited` included, stands as the `Amount` figure in place of the total only
in the plain shape of Uniswap's own routes: it is the only `PERMIT2_PERMIT`,
its spender is the router, the router may not let it fail, no step before it
takes its token or a token the decoder does not know, and the decoder reads
every step after it in full. Permit2 then lets the router take no more of the
token than that amount, so the permit covers every take of it. A step the
decoder does not read in full may raise what Permit2 lets the router take, as
a `PERMIT2_PERMIT_BATCH` can: a command the decoder does not read (listed at
the end of this section), a step whose input it cannot read, in whole or in
part, and a step it fails on. In any other case the line gives the total, as
with no permit. When the step that sets the input side spends a token other
than the permit's, or one the decoder does not know, its amount gets lines of
its own and the total has no figure to start from: unless the permit's amount
stands there is no `Amount` line, and each take of the permit's token gets
lines of its own. Each take the total does not count gives three lines after
the `Amount` line (after `Token In` when there is none): one of a token other
than `Token In`; one of `Token In` after an amount that is not a quantity (a
V4 open delta, `ALREADY_PAID`, which keep their wording on the `Amount` line,
or no stated amount, as of a V4 exact-out step); and one whose amount the
decoder does not know. When the step that sets the input side states no amount
and there is no `Amount` line, that step gets them too whenever another take's
lines give a figure, so that figure cannot read as all that leaves. They come
in step order, the step that sets the input side first when it has them:
of the swap action that spends it. Each later V2 or V3 exact-in or exact-out
step whose `payerIsUser` is true takes its amount, found in the same way, from
the user's wallet. Every V4 step, with a swap action or without, takes from
the user's wallet what its `SETTLE`s paid by the user (`payerIsUser` true) and
its `SETTLE_ALL`s pay, for each token on its own; what the step that sets the
input side takes of any other token counts as a later step's take. A `SETTLE`
of any amount but `OPEN_DELTA` pays that amount, and a `SETTLE` of
`OPEN_DELTA` or a `SETTLE_ALL` pays what the step owes, as above. So a V4 step
that swaps 400 USDT, with a `SETTLE` of 5,000 USDT paid by the user and the
rest taken to another address, reads `5000.0000 USDT`. A later step paid from
the router spends what the router holds and takes nothing, and so does a V2
exact-in whose `amountIn` is `ALREADY_PAID`. A later take of `Token In` is
added to the total while both are quantities: a V3 exact-in of 600 USDT and a
V2 exact-in of 400 USDT, both paid by the user, read `1000.0000 USDT`. When
the decoder does not know a take's amount, the total is not known and there is
no `Amount` line. `Token In` is the token of the last `PERMIT2_PERMIT` the
decoder reads, when there is one. Its amount, `Unlimited` included, stands as
the `Amount` figure in place of the total only in the plain shape of Uniswap's
own routes: it is the only `PERMIT2_PERMIT`, its spender is the router, the
router may not let it fail, no step before it takes its token or a token the
decoder does not know, and the decoder reads every step after it in full.
Permit2 then lets the router take no more of the token than that amount, so
the permit covers every take of it. A step the decoder does not read in full
may raise what Permit2 lets the router take, as a `PERMIT2_PERMIT_BATCH` can:
a command the decoder does not read (listed at the end of this section), a
step whose input it cannot read, in whole or in part, and a step it fails on.
In any other case the line gives the total, as with no permit. When the step
that sets the input side spends a token other than the permit's, or one the
decoder does not know, its amount gets lines of its own and the total has no
figure to start from: unless the permit's amount stands there is no `Amount`
line, and each take of the permit's token gets lines of its own. Each take the
total does not count gives three lines after the `Amount` line (after
`Token In` when there is none): one of a token other than `Token In`; one of
`Token In` after an amount that is not a quantity (a V4 open delta,
`ALREADY_PAID`, which keep their wording on the `Amount` line, or no stated
amount, as of a V4 exact-out step); and one whose amount the decoder does not
know. When the step that sets the input side states no amount and there is no
`Amount` line, that step gets them too whenever another take's lines give a
figure, so that figure cannot read as all that leaves. They come in step
order, the step that sets the input side first when it has them:
`Moved from the sender`, its amount, worded as the `Amount` line words one, or
`Unknown (could not be decoded)` when the decoder does not know it;
`Token moved`, giving the token's address as the `Token In` line does; and
@@ -3196,32 +3204,33 @@ Currently supported:
does not know gives the `Moved from the sender` line alone. A step may also
take from the user's wallet what the decoder did not read: a V4 step whose
input or one of whose `SETTLE`s or `SETTLE_ALL`s it cannot read, which the
router still runs; a V2 or V3 exact-in or V2 exact-out step or a
`PERMIT2_TRANSFER_FROM` whose input it cannot read; every
`PERMIT2_TRANSFER_FROM_BATCH`; every `V3_SWAP_EXACT_OUT`, which the decoder
does not read, wherever it stands; every `EXECUTE_SUB_PLAN`, wherever it
stands; and every step it fails on. Each such step gives one
`Moved from the sender` line among those, reading
`Unknown (could not be decoded)`. That line, or any line for a token the
decoder does not know, leaves no `Amount` line, whose figure might be too low,
and such a step before a `PERMIT2_PERMIT` keeps the permit's amount from
standing. Then each `PERMIT2_TRANSFER_FROM` but one into the router, in step
order, gives three lines: `Moved from the sender`, the amount it moves, for
example `1000000.0000 USDT`; `Token moved`, giving the token's address as the
`Token In` line does; and `Moved to`, which reads
router still runs; a V2 or V3 exact-in or exact-out step or a
`PERMIT2_TRANSFER_FROM` whose input it cannot read, such as a V3 step whose
path is shorter than one token address or has bytes after its last hop; every
`PERMIT2_TRANSFER_FROM_BATCH`; every `EXECUTE_SUB_PLAN`, wherever it stands;
and every step it fails on. Each such step gives one `Moved from the sender`
line among those, reading `Unknown (could not be decoded)`. That line, or any
line for a token the decoder does not know, leaves no `Amount` line, whose
figure might be too low, and such a step before a `PERMIT2_PERMIT` keeps the
permit's amount from standing. Then each `PERMIT2_TRANSFER_FROM` but one into
the router, in step order, gives three lines: `Moved from the sender`, the
amount it moves, for example `1000000.0000 USDT`; `Token moved`, giving the
token's address as the `Token In` line does; and `Moved to`, which reads
`The V2 pair the next swap spends` for a hop and `The sender` for `address(1)`
on every router but `UniversalRouterV1`, and otherwise gives the address. A
move into the router needs none of them, because its `Paid to` line and
`Token moved into the router` line already give the amount, the token and
where it goes, and so its amount is shown once. These lines change neither the
`Paid to` lines nor the minimum's label. A step goes unread when its recipient
does not decode as an address, or when it is a command the decoder does not
read: every command other than `PERMIT2_PERMIT`, `PERMIT2_TRANSFER_FROM`,
`V2_SWAP_EXACT_IN`, `V2_SWAP_EXACT_OUT`, `V3_SWAP_EXACT_IN`, `V4_SWAP`,
`SWEEP`, `TRANSFER`, `PAY_PORTION`, `PAY_PORTION_FULL_PRECISION`,
`ACROSS_V4_DEPOSIT_V3`, `WRAP_ETH`, `UNWRAP_WETH` and `BALANCE_CHECK_ERC20`
(`V3_SWAP_EXACT_OUT`, `PERMIT2_TRANSFER_FROM_BATCH`, `EXECUTE_SUB_PLAN` and
the NFT commands among them), or a type its release names no command for.
does not decode as an address, when it is a V3 swap step whose path is shorter
than one token address or has bytes after its last hop, or when it is a
command the decoder does not read: every command other than `PERMIT2_PERMIT`,
`PERMIT2_TRANSFER_FROM`, `V2_SWAP_EXACT_IN`, `V2_SWAP_EXACT_OUT`,
`V3_SWAP_EXACT_IN`, `V3_SWAP_EXACT_OUT`, `V4_SWAP`, `SWEEP`, `TRANSFER`,
`PAY_PORTION`, `PAY_PORTION_FULL_PRECISION`, `ACROSS_V4_DEPOSIT_V3`,
`WRAP_ETH`, `UNWRAP_WETH` and `BALANCE_CHECK_ERC20`
(`PERMIT2_TRANSFER_FROM_BATCH`, `EXECUTE_SUB_PLAN` and the NFT commands among
them), or a type its release names no command for.
### Non-Goals Forever
src/shared/uniswap.js
+63 -28
View File
@@ -592,13 +592,17 @@ function decodeV2SwapExactOut(input) {
}
}
// Decode V3 swap path (packed: token(20) + fee(3) + token(20) ...)
// The first and last token of a V3 swap path (packed: token(20) + fee(3) +
// token(20) ...), or null when it is not one token followed by whole hops of
// a fee and a token (40 hex digits, then 46 per hop). The router reads only
// whole hops and ignores any bytes after the last one, so the last 20 bytes
// of such a path are not the token it reads there.
function decodeV3Path(pathHex) {
const hex = pathHex.startsWith("0x") ? pathHex.slice(2) : pathHex;
if (hex.length < 40) return null;
const tokenIn = "0x" + hex.slice(0, 40);
const tokenOut = "0x" + hex.slice(-40);
return { tokenIn, tokenOut };
if (hex.length < 40 || (hex.length - 40) % 46 !== 0) return null;
const first = "0x" + hex.slice(0, 40);
const last = "0x" + hex.slice(-40);
return { first, last };
}
// Decode V3_SWAP_EXACT_IN (command 0x00) input bytes.
@@ -617,8 +621,39 @@ function decodeV3SwapExactIn(input) {
recipient: d[0],
amountIn: d[1],
amountOutMin: d[2],
tokenIn: path.tokenIn,
tokenOut: path.tokenOut,
tokenIn: path.first,
tokenOut: path.last,
payerIsUser: d[4],
};
} catch {
return null;
}
}
// Decode V3_SWAP_EXACT_OUT (command 0x01) input bytes.
// ABI: (address recipient, uint256 amountOut, uint256 amountInMax,
// bytes path, bool payerIsUser)
// The router reads an exact-out path from the token it buys to the token it
// spends: it buys `amountOut` of the path's first token from the path's first
// pool and pays at most `amountInMax` of its last token to its last pool
// (`v3SwapExactOutput()` and `uniswapV3SwapCallback()` in each release's
// `contracts/modules/uniswap/v3/V3SwapRouter.sol`, at the commit linked for
// it above).
// With `payerIsUser` false the router pays the input from its own balance.
function decodeV3SwapExactOut(input) {
try {
const d = coder.decode(
["address", "uint256", "uint256", "bytes", "bool"],
input,
);
const path = decodeV3Path(d[3]);
if (!path) return null;
return {
recipient: d[0],
amountOut: d[1],
amountInMax: d[2],
tokenIn: path.last,
tokenOut: path.first,
payerIsUser: d[4],
};
} catch {
@@ -1180,7 +1215,7 @@ function decode(data, toAddress, chainId, sources, fromAddress) {
let minOutput = null;
let outputEstablished = false;
let hasUnwrapWeth = false;
let hasV2ExactOut = false;
let hasV2OrV3ExactOut = false;
let swapUndecoded = false;
let hasSubPlan = false;
const commandNames = [];
@@ -1236,9 +1271,8 @@ function decode(data, toAddress, chainId, sources, fromAddress) {
};
// A step may take from the sender what this decoder did not read: a
// V4 step whose input or one of whose SETTLEs or SETTLE_ALLs it
// cannot read; a V2 or V3 exact-in or V2 exact-out step or
// PERMIT2_TRANSFER_FROM whose input it cannot read; a
// PERMIT2_TRANSFER_FROM_BATCH; a V3_SWAP_EXACT_OUT; an
// cannot read; a V2 or V3 swap step or PERMIT2_TRANSFER_FROM whose
// input it cannot read; a PERMIT2_TRANSFER_FROM_BATCH; an
// EXECUTE_SUB_PLAN; and a step it fails on. It is recorded with a null
// token and amount: one line says so, there is no Amount line, whose
// figure may then be too low, and the amount of a permit after it
@@ -1493,14 +1527,6 @@ function decode(data, toAddress, chainId, sources, fromAddress) {
stepsUnread.push(i);
spentUnread();
}
} else if (command === "V3_SWAP_EXACT_OUT") {
// This decoder does not read it
// (https://git.eeqj.de/sneak/AutistMask/issues/601). It
// may pay any address and take from the sender, so
// wherever it stands it leaves no Amount figure.
payeeUnread = true;
stepsUnread.push(i);
spentUnread();
} else if (command === "V2_SWAP_EXACT_IN") {
const s = decodeV2SwapExactIn(inputs[i]);
if (s) {
@@ -1521,10 +1547,19 @@ function decode(data, toAddress, chainId, sources, fromAddress) {
stepsUnread.push(i);
spentUnread();
}
} else if (command === "V2_SWAP_EXACT_OUT") {
} else if (
command === "V2_SWAP_EXACT_OUT" ||
command === "V3_SWAP_EXACT_OUT"
) {
// Buys exactly amountOut and spends at most amountInMax.
hasV2ExactOut = true;
const s = decodeV2SwapExactOut(inputs[i]);
// Paid from the router, it spends an amount the calldata
// does not state, so it spends nothing spendFromRouter()
// could count.
hasV2OrV3ExactOut = true;
const s =
command === "V2_SWAP_EXACT_OUT"
? decodeV2SwapExactOut(inputs[i])
: decodeV3SwapExactOut(inputs[i]);
if (s) {
if (!inputEstablished) {
setInputOnce(s.tokenIn, s.amountInMax);
@@ -1943,12 +1978,12 @@ function decode(data, toAddress, chainId, sources, fromAddress) {
if (amount >= MAX_UINT160) {
return { raw: "Unlimited", display: "Unlimited" };
}
if (hasV2ExactOut) {
// A V2 exact-out swap spends at most this figure, whichever
// steps gave it (an amountInMax, the WRAP_ETH of a swap paid
// in ETH, a permit, or several steps' total), so it is said to
// be a maximum, in `raw` too: the wait, success and error
// screens show `raw` as the transaction's amount.
if (hasV2OrV3ExactOut) {
// A V2 or V3 exact-out swap spends at most this figure,
// whichever steps gave it (an amountInMax, the WRAP_ETH of a
// swap paid in ETH, a permit, or several steps' total), so it
// is said to be a maximum, in `raw` too: the wait, success and
// error screens show `raw` as the transaction's amount.
const most = amountText(amount, info);
return {
raw: "Up to " + most.raw,
tests/uniswap.test.js
+181 -15
View File
@@ -88,17 +88,42 @@ function encodeV2SwapExactOut(recipient, amountOut, amountInMax, pathAddrs) {
);
}
// Helper: encode a V3_SWAP_EXACT_IN input (command 0x00)
function encodeV3SwapExactIn(recipient, amountIn, amountOutMin, pathTokens) {
// V3 path: token(20) + fee(3) + token(20) ...
// Helper: a V3 path: token(20) + fee(3) + token(20) ...
function encodeV3Path(pathTokens) {
let pathHex = pathTokens[0].slice(2).toLowerCase();
for (let i = 1; i < pathTokens.length; i++) {
pathHex += "000bb8"; // fee 3000 = 0x000bb8
pathHex += pathTokens[i].slice(2).toLowerCase();
}
return "0x" + pathHex;
}
// Helper: encode a V3_SWAP_EXACT_IN input (command 0x00)
function encodeV3SwapExactIn(recipient, amountIn, amountOutMin, pathTokens) {
return coder.encode(
["address", "uint256", "uint256", "bytes", "bool"],
[recipient, amountIn, amountOutMin, "0x" + pathHex, true],
[recipient, amountIn, amountOutMin, encodeV3Path(pathTokens), true],
);
}
// Helper: encode a V3_SWAP_EXACT_OUT input (command 0x01). Its path lists
// the token bought first and the token spent last.
function encodeV3SwapExactOut(
recipient,
amountOut,
amountInMax,
pathTokens,
payerIsUser = true,
) {
return coder.encode(
["address", "uint256", "uint256", "bytes", "bool"],
[
recipient,
amountOut,
amountInMax,
encodeV3Path(pathTokens),
payerIsUser,
],
);
}
@@ -644,6 +669,79 @@ describe("uniswap decoder", () => {
expect(detail(result, "Min. received").value).toBe("1500.0000 USDC");
});
// https://git.eeqj.de/sneak/AutistMask/issues/601 — a V3_SWAP_EXACT_OUT
// was named but not read, so its tokens read "Unknown (not named in the
// calldata)" and it showed no amounts. It is read as a V2_SWAP_EXACT_OUT
// is, with its path read as the router reads it: from the token it buys
// to the token it spends. Read the other way, each path below would be a
// swap of WETH for USDT.
test.each([
{ hops: "single-hop", path: [WETH_ADDR, USDT_ADDR] },
{ hops: "multi-hop", path: [WETH_ADDR, USDC_ADDR, USDT_ADDR] },
])(
"decodes a $hops V3_SWAP_EXACT_OUT, stating the input amount as a maximum",
({ path }) => {
// Buy exactly 1 WETH for at most 2,000 USDT, paid by the user.
const data = buildExecute(
"0x01", // V3_SWAP_EXACT_OUT
[encodeV3SwapExactOut(USER_ADDR, ONE_WETH, 2000000000n, path)],
9999999999n,
);
const result = uniswap.decode(
data,
ROUTER_ADDR,
"0x1",
{},
USER_ADDR,
);
expect(result.name).toBe("Swap USDT → WETH");
expect(detail(result, "Token In").address).toBe(
USDT_ADDR.toLowerCase(),
);
expect(detail(result, "Token Out").address).toBe(
WETH_ADDR.toLowerCase(),
);
const amount = detail(result, "Amount");
expect(amount.value).toBe("Up to 2000.0000 USDT");
expect(amount.rawValue).toBe("Up to 2000.0000");
expect(detail(result, "Min. received").value).toBe("1.0000 WETH");
},
);
// The V2 exact-out swap paid in ETH above, as a V3_SWAP_EXACT_OUT paid
// from the WETH the router holds: it takes nothing more from the user's
// wallet.
test("a V3 exact-out swap paid in ETH from the router shows the token it buys and a maximum", () => {
const data = buildExecute(
solidityPacked(["uint8", "uint8", "uint8"], [0x0b, 0x01, 0x0c]),
[
encodeWrapEth(ROUTER_ADDR, 500000000000000000n),
encodeV3SwapExactOut(
USER_ADDR,
1500000000n, // amountOut: 1,500 USDC
500000000000000000n, // amountInMax: 0.5 WETH
[USDC_ADDR, WETH_ADDR],
false, // paid from the router
),
encodeWrapEth(USER_ADDR, 0n), // UNWRAP_WETH same encoding
],
9999999999n,
);
const result = uniswap.decode(data, ROUTER_ADDR, "0x1", {}, USER_ADDR);
expect(result.name).toBe("Swap ETH → USDC");
expect(detail(result, "Amount").value).toBe("Up to 0.5000 ETH");
expect(detail(result, "Moved from the sender")).toBeUndefined();
expect(detail(result, "Token Out").address).toBe(
USDC_ADDR.toLowerCase(),
);
expect(detail(result, "Paid to")).toBeUndefined();
expect(detail(result, "Min. received").value).toBe("1500.0000 USDC");
});
// Buy exactly 0.5 ETH for at most 1,500 USDC under a permit: the swap buys
// WETH and UNWRAP_WETH turns it into ETH.
test("a V2 exact-out swap that buys ETH shows ETH and the permit as a maximum", () => {
@@ -2048,11 +2146,9 @@ describe("uniswap decoder", () => {
);
// A V3_SWAP_EXACT_OUT the user pays for, of at most `amountInMax`
// USDT for USDC. Its input is (recipient, amountOut, amountInMax,
// path, payerIsUser), laid out as encodeV3SwapExactIn() writes one;
// an exact-out path lists the token bought first.
// USDT for USDC.
const v3ExactOut = (amountInMax) =>
encodeV3SwapExactIn(USER_ADDR, 390000000n, amountInMax, [
encodeV3SwapExactOut(USER_ADDR, 390000000n, amountInMax, [
USDC_ADDR,
USDT_ADDR,
]);
@@ -2070,14 +2166,16 @@ describe("uniswap decoder", () => {
[USDC_ADDR, USER_ADDR, 0n],
),
];
// This decoder does not read a V3_SWAP_EXACT_OUT, so what one takes
// leaves no Amount figure wherever it stands, and a permit's amount
// does not stand.
// What a V3_SWAP_EXACT_OUT takes, at most its amountInMax, counts
// as a V2_SWAP_EXACT_OUT's does, and the Amount line is a maximum.
// The permit of 10,000 USDT stands; the one of 600 USDT does not,
// because the step before it took its token.
test.each([
{
kind: "a V3 exact-in of 600 USDT, then a V3_SWAP_EXACT_OUT",
kind: "a V3 exact-in of 600 USDT, then a V3_SWAP_EXACT_OUT of at most 400 USDT",
commands: [0x00, 0x01],
inputs: [V3_600, v3ExactOut(USDT_400)],
amount: "Up to 1000.0000 USDT",
},
{
kind: "a PERMIT2_PERMIT of 10,000 USDT, then a V3_SWAP_EXACT_OUT, a V2_SWAP_EXACT_OUT and a SWEEP",
@@ -2086,11 +2184,13 @@ describe("uniswap decoder", () => {
encodePermit2(USDT_ADDR, 10000000000n, ROUTER_ADDR),
...EXACT_OUT_SPLIT,
],
amount: "Up to 10000.0000 USDT",
},
{
kind: "a V3_SWAP_EXACT_OUT, a V2_SWAP_EXACT_OUT and a SWEEP",
commands: [0x01, 0x09, 0x04],
inputs: EXACT_OUT_SPLIT,
amount: "Up to 10000.0000 USDT",
},
{
kind: "a V3_SWAP_EXACT_OUT of at most 9,400 USDT, then a PERMIT2_PERMIT of 600 USDT and a V3 exact-in of 600 USDT",
@@ -2100,17 +2200,83 @@ describe("uniswap decoder", () => {
encodePermit2(USDT_ADDR, USDT_600, ROUTER_ADDR),
V3_600,
],
amount: "Up to 10000.0000 USDT",
},
])(
"$kind, all paid by the user, shows no Amount figure",
({ commands, inputs }) => {
"$kind, all paid by the user, shows the total as a maximum",
({ commands, inputs, amount }) => {
const result = decodeSteps(commands, inputs);
expect(linesBetweenTokens(result)).toEqual([
["Moved from the sender", UNDECODED],
["Amount", amount],
]);
},
);
// A V3_SWAP_EXACT_OUT whose path is shorter than one token cannot be
// read. It may pay any address and take from the sender, so it
// leaves no Amount figure.
test("a V3 exact-in of 600 USDT, then a V3_SWAP_EXACT_OUT whose path cannot be read, shows no Amount figure", () => {
const unreadable = coder.encode(
["address", "uint256", "uint256", "bytes", "bool"],
[USER_ADDR, 390000000n, USDT_400, "0x", true],
);
const result = decodeSteps([0x00, 0x01], [V3_600, unreadable]);
expect(linesBetweenTokens(result)).toEqual([
["Moved from the sender", UNDECODED],
]);
expect(detail(result, "Paid to").value).toBe(UNDECODED);
});
// https://git.eeqj.de/sneak/AutistMask/issues/637 — the router reads
// a V3 path as one token and whole hops of a 3-byte fee and a token,
// and ignores any bytes after the last hop. Each path below is
// `tokens` and then the last 19 bytes of a bundled token's address
// whose first byte is the last token's last byte, so the path's last
// 20 bytes spell a token the router does not read. Such a path is not
// read, as one shorter than one token is not.
const pathEndingIn = (tokens, address) =>
encodeV3Path(tokens) + address.slice(4).toLowerCase();
const SPK_ADDR = "0xc20059e0317DE91738d13af027DfC4a50781b066";
const IUSD_ADDR = "0x48f9e38f3070AD8945DFEae3FA70987722E3D89c";
const v3Swap = (amount, otherAmount, path) =>
coder.encode(
["address", "uint256", "uint256", "bytes", "bool"],
[USER_ADDR, amount, otherAmount, path, true],
);
// A V3 exact-in of 1 WETH for USDC pays out USDC, not IUSD.
test("a V3_SWAP_EXACT_IN whose path has bytes after its last hop names no Token Out", () => {
const path = pathEndingIn([WETH_ADDR, USDC_ADDR], IUSD_ADDR);
const result = decodeSteps([0x00], [v3Swap(ONE_WETH, 1n, path)]);
expect(detail(result, "Token Out").address).toBeUndefined();
expect(linesBetweenTokens(result)).toEqual([
["Moved from the sender", UNDECODED],
]);
});
// A V3 exact-out of 1,500 USDC for at most 0.5 WETH spends WETH, not
// SPK. After it, a PERMIT2_PERMIT of 1 WETH and a V3 exact-in of 0.5
// WETH: the permit's amount does not stand, because the step before
// it also takes WETH.
test("a V3_SWAP_EXACT_OUT whose path has bytes after its last hop, then a PERMIT2_PERMIT and a V3 exact-in, shows no Amount figure", () => {
const path = pathEndingIn([USDC_ADDR, WETH_ADDR], SPK_ADDR);
const result = decodeSteps(
[0x01, 0x0a, 0x00],
[
v3Swap(1500000000n, ONE_WETH / 2n, path),
encodePermit2(WETH_ADDR, ONE_WETH, ROUTER_ADDR),
encodeV3SwapExactIn(USER_ADDR, ONE_WETH / 2n, 1n, [
WETH_ADDR,
USDC_ADDR,
]),
],
);
expect(linesBetweenTokens(result)).toEqual([
["Moved from the sender", UNDECODED],
]);
expect(detail(result, "Paid to").value).toBe(UNDECODED);
});
// A later step's amount that cannot be added to the Amount line,
// because the amount of the step that set the input side is not a
// quantity, gets lines of its own. When that step stated no amount,
tests/uniswapRecipient.test.js
+12 -4
View File
@@ -387,6 +387,18 @@ describe("each swap command's recipient", () => {
data: (r) => execute(swapToWeth(r)),
min: "1.0000 WETH",
},
{
// Its input has V3_SWAP_EXACT_IN's layout, with amountOut and
// amountInMax in place of amountIn and amountOutMin, and a path
// that lists the token bought first.
kind: "V3_SWAP_EXACT_OUT",
data: (r) =>
execute([
0x01,
v3SwapExactIn(r, ONE_WETH, USDT_2000, WETH, USDT)[1],
]),
min: "1.0000 WETH",
},
{
kind: "V4_SWAP with TAKE",
data: (r) =>
@@ -2019,10 +2031,6 @@ describe("a payout that cannot be read is never said to be received", () => {
),
],
},
{
kind: "V3_SWAP_EXACT_OUT",
step: [0x01, swapToWeth(OTHER)[1]],
},
{
kind: "EXECUTE_SUB_PLAN",
step: [