fix: the swap decoder names where a WRAP_ETH pays and shows a V4 step's ETH as a maximum when the router may hold ETH (closes #665)
A `WRAP_ETH` that sets the input side and pays its WETH to anyone but the router names that recipient on its `Moved to` line. V4 pays a `SETTLE` of ETH from the router's own ETH, whichever payer it names. When an earlier step may leave ETH in the router, the ETH that the user pays a later V4 step gets lines of its own. Their `Moved from the sender` line reads `Up to <amount>`, or `Unknown (could not be decoded)` when the amount is not known. The decoder never subtracts the router's ETH, so no line shows less ETH than can leave the wallet. Without such an earlier step, the lines read as before. Model: opus-5-5
This commit is contained in:
@@ -1265,7 +1265,9 @@ see Transaction Decoding), do not always read as a number. They can read:
|
||||
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 or V3 exact-out step sets `Min. received`, that line shows
|
||||
its `amountOut`, the exact amount it buys.
|
||||
its `amountOut`, the exact amount it buys. When the router may hold ETH from
|
||||
an earlier step, the `Moved from the sender` line of ETH that the user pays a
|
||||
V4 step also reads `Up to <amount>` (see Transaction Decoding).
|
||||
- `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
|
||||
@@ -3477,81 +3479,89 @@ Currently supported:
|
||||
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. A `PERMIT2_PERMIT` names `Token In` only when its amount,
|
||||
`Unlimited` included, stands as the `Amount` figure in place of the total,
|
||||
which it does only in the plain shape of Uniswap's own routes: it comes before
|
||||
the step that sets the input side, it is the only `PERMIT2_PERMIT` in the
|
||||
transaction and there is no `PERMIT2_PERMIT_BATCH`, its spender is the router,
|
||||
the router may not let it fail, no step before it takes its token, a
|
||||
`PERMIT2_TRANSFER_FROM` of it included, 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 before the permit takes under whatever allowance the router
|
||||
already had, so it may take more than the permit's amount, which would then
|
||||
read lower than what leaves the user's wallet: a `PERMIT2_TRANSFER_FROM` of
|
||||
2,000 USDT into the router, then a permit of 600 USDT to the router and a V3
|
||||
exact-in of 2,000 USDT paid from the router, read `Amount 2000.0000 USDT`. A
|
||||
later permit or batch may raise what Permit2 lets the router take, and so may
|
||||
a step the decoder does not read in full: 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. Every other `PERMIT2_PERMIT`, before
|
||||
the step that sets the input side or after it, leaves `Token In` and the
|
||||
`Amount` line as they read with no permit, unless it lets a spender other than
|
||||
the router take `Token In` (see below): a permit of 5,000 DAI to another
|
||||
address and then a V3 exact-in of 600 USDT read `Swap USDT → USDC` with
|
||||
`Amount 600.0000 USDT`, and so do that exact-in and then a permit of 5,000 DAI
|
||||
to the router. When a permit's amount stands and the step that sets the input
|
||||
side spends a token other than the permit's, or one the decoder does not know,
|
||||
that step's amount gets lines of its own, unless it states no amount and the
|
||||
user pays it none of its input token. 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 there is no `Amount` line, each
|
||||
take the total counts gets them too, so that every amount the decoder reads is
|
||||
shown: the amount the step that sets the input side states, when it is a
|
||||
quantity and the user pays that step (a V2 or V3 step whose `payerIsUser` is
|
||||
true, a V4 step the user pays some of its input token, or a `WRAP_ETH`, whose
|
||||
ETH comes from the transaction's value), and each later take of `Token In`
|
||||
added to it. A step that sets the input side and is paid from the router takes
|
||||
nothing from the user's wallet and gets none. A `PERMIT2_PERMIT` the decoder
|
||||
cannot read, then V3 exact-ins of 600 USDT and 400 DAI paid by the user, give
|
||||
lines for both amounts. When the step that sets the input side states no
|
||||
amount, the user pays it some of its input token, and there is no `Amount`
|
||||
line, that step gets them too whenever another take's lines give a figure, or
|
||||
a `PERMIT2_TRANSFER_FROM` of its token gives one, on the lines below or, into
|
||||
the router, on its `Paid to` line, so that figure cannot read as all that
|
||||
leaves. When it states no amount and the user pays it none of its input token,
|
||||
as when the router pays it, that step takes none of that token from the user's
|
||||
wallet and never gets them, with a permit or without. They come in step order,
|
||||
except that the step that sets the input side comes first when it has them,
|
||||
followed, when there is no `Amount` line, by the other takes the total counts:
|
||||
`Moved from the sender`, its amount, worded as the `Amount` line words one, or
|
||||
rest taken to another address, reads `5000.0000 USDT`. V4 pays a `SETTLE` of
|
||||
ETH from the router's own ETH, whichever payer it names. So when the router
|
||||
may hold ETH from an earlier step (see above), the ETH that the user pays a V4
|
||||
step gets lines of its own (see below). 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. A `PERMIT2_PERMIT` names `Token In` only when its amount, `Unlimited`
|
||||
included, stands as the `Amount` figure in place of the total, which it does
|
||||
only in the plain shape of Uniswap's own routes: it comes before the step that
|
||||
sets the input side, it is the only `PERMIT2_PERMIT` in the transaction and
|
||||
there is no `PERMIT2_PERMIT_BATCH`, its spender is the router, the router may
|
||||
not let it fail, no step before it takes its token, a `PERMIT2_TRANSFER_FROM`
|
||||
of it included, 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 before
|
||||
the permit takes under whatever allowance the router already had, so it may
|
||||
take more than the permit's amount, which would then read lower than what
|
||||
leaves the user's wallet: a `PERMIT2_TRANSFER_FROM` of 2,000 USDT into the
|
||||
router, then a permit of 600 USDT to the router and a V3 exact-in of 2,000
|
||||
USDT paid from the router, read `Amount 2000.0000 USDT`. A later permit or
|
||||
batch may raise what Permit2 lets the router take, and so may a step the
|
||||
decoder does not read in full: 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. Every other `PERMIT2_PERMIT`, before the step
|
||||
that sets the input side or after it, leaves `Token In` and the `Amount` line
|
||||
as they read with no permit, unless it lets a spender other than the router
|
||||
take `Token In` (see below): a permit of 5,000 DAI to another address and then
|
||||
a V3 exact-in of 600 USDT read `Swap USDT → USDC` with `Amount 600.0000 USDT`,
|
||||
and so do that exact-in and then a permit of 5,000 DAI to the router. When a
|
||||
permit's amount stands and the step that sets the input side spends a token
|
||||
other than the permit's, or one the decoder does not know, that step's amount
|
||||
gets lines of its own, unless it states no amount and the user pays it none of
|
||||
its input token. 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); one whose amount the decoder
|
||||
does not know; and one of ETH that the user pays a V4 step when the router may
|
||||
hold ETH. When there is no `Amount` line, each take the total counts gets them
|
||||
too, so that every amount the decoder reads is shown: the amount the step that
|
||||
sets the input side states, when it is a quantity and the user pays that step
|
||||
(a V2 or V3 step whose `payerIsUser` is true, a V4 step the user pays some of
|
||||
its input token, or a `WRAP_ETH`, whose ETH comes from the transaction's
|
||||
value), and each later take of `Token In` added to it. A step that sets the
|
||||
input side and is paid from the router takes nothing from the user's wallet
|
||||
and gets none. A `PERMIT2_PERMIT` the decoder cannot read, then V3 exact-ins
|
||||
of 600 USDT and 400 DAI paid by the user, give lines for both amounts. When
|
||||
the step that sets the input side states no amount, the user pays it some of
|
||||
its input token, and there is no `Amount` line, that step gets them too
|
||||
whenever another take's lines give a figure, or a `PERMIT2_TRANSFER_FROM` of
|
||||
its token gives one, on the lines below or, into the router, on its `Paid to`
|
||||
line, so that figure cannot read as all that leaves. When it states no amount
|
||||
and the user pays it none of its input token, as when the router pays it, that
|
||||
step takes none of that token from the user's wallet and never gets them, with
|
||||
a permit or without. They come in step order, except that the step that sets
|
||||
the input side comes first when it has them, followed, when there is no
|
||||
`Amount` line, by the other takes the total counts: `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
|
||||
`Moved to`, which reads `The swap step that spends it`. A token the decoder
|
||||
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 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
|
||||
`Moved to`, which reads `The swap step that spends it`. For ETH that the user
|
||||
pays a V4 step when the router may hold ETH, `Moved from the sender` reads
|
||||
`Up to <amount>` for a known amount. For a `WRAP_ETH` that pays its WETH to
|
||||
anyone but the router, `Moved to` names that recipient instead: `The sender`
|
||||
for `address(1)`, and otherwise the address. A token the decoder 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 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
|
||||
|
||||
Reference in New Issue
Block a user