fix: with no Amount line, the user's takes the total adds up get lines of their own (closes #659)
When a step this decoder cannot read, an unreadable permit, or a take of Token In with an unknown amount held back the Amount line, the amount the step that sets the input side states, and each later take of Token In added to it, appeared on no line, while other takes kept their own Moved from the sender lines. Those takes now get the same lines, first. The first step's amount gets them only when the user pays that step (a V2 or V3 step with payerIsUser true, a V4 step the user pays some of its input token, or a WRAP_ETH): one paid from the router takes nothing from the wallet. Routes with an Amount line read as before. Model: opus-5-5
This commit is contained in:
@@ -3251,15 +3251,25 @@ Currently supported:
|
||||
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, 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, the step that sets the input side first when it has them:
|
||||
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
|
||||
`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
|
||||
|
||||
Reference in New Issue
Block a user