In decode() in src/shared/uniswap.js, when the Amount line was held back (a step or permit the decoder cannot read, or a later take of Token In with an unknown amount), the amount stated by the step that sets the input side, and each later take of Token In the total added to it, appeared on no line. An unreadable permit, then 600 USDT and 400 DAI paid by the user, showed only the 400 DAI.
The takes the total adds up are now collected as it adds them. With no Amount line, each gets Moved from the sender, Token moved and Moved to lines, ahead of the other takes. 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. decode() now records who pays the first step for each, as it already did for V4; one paid from the router takes nothing from the wallet and gets none. Routes with an Amount line read as before; README Transaction Decoding matches.
What the diff does not show:
These lines come before the other takes' lines, not strictly in step order; README states that order.
With an EXECUTE_SUB_PLAN, Token In still reads Unknown (could not be decoded), but a readable swap step's amount the user pays now has lines of its own.
Existing test expectations that encoded the missing lines were changed.
Judgement call: a V4 open delta or ALREADY_PAID gets no line; neither is a quantity taken from the wallet.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/AutistMask/issues/659.
In `decode()` in `src/shared/uniswap.js`, when the `Amount` line was held back (a step or permit the decoder cannot read, or a later take of `Token In` with an unknown amount), the amount stated by the step that sets the input side, and each later take of `Token In` the total added to it, appeared on no line. An unreadable permit, then 600 USDT and 400 DAI paid by the user, showed only the 400 DAI.
The takes the total adds up are now collected as it adds them. With no `Amount` line, each gets `Moved from the sender`, `Token moved` and `Moved to` lines, ahead of the other takes. 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`. `decode()` now records who pays the first step for each, as it already did for V4; one paid from the router takes nothing from the wallet and gets none. Routes with an `Amount` line read as before; README Transaction Decoding matches.
What the diff does not show:
- These lines come before the other takes' lines, not strictly in step order; README states that order.
- With an `EXECUTE_SUB_PLAN`, `Token In` still reads `Unknown (could not be decoded)`, but a readable swap step's amount the user pays now has lines of its own.
- Existing test expectations that encoded the missing lines were changed.
Judgement call: a V4 open delta or `ALREADY_PAID` gets no line; neither is a quantity taken from the wallet.
Model: opus-5-5
clawbot
self-assigned this 2026-10-21 03:34:33 +02:00
decode() in src/shared/uniswap.js, where inTotal takes the amount of the step that sets the input side (typeof inputAmount === "bigint"), and the new README Transaction Decoding sentence beginning "When there is no Amount line, each take the total counts gets them too": that step's amount gets Moved from the sender / The swap step that spends it lines whoever pays it. So a first swap paid from the router now claims a take from the wallet that does not happen, which #639 ruled out, and nothing in the PR shows such a take comes from the wallet. Route: a PERMIT2_TRANSFER_FROM of 600 USDT into the router, a V3 exact-in of 600 USDT paid from the router, then a PERMIT2_TRANSFER_FROM_BATCH (or with an unreadable PERMIT2_PERMIT in front instead, or through a V4 step whose SETTLE the router pays). The screen now says 600 USDT moved from the sender to the swap step and another 600 USDT from the sender into the router, while 600 USDT leaves. With a V2 exact-in of CONTRACT_BALANCE paid from the router and an EXECUTE_SUB_PLAN, it reads Moved from the sender: Unlimited. On next none of these lines appear. Acceptable: the first step's amount gets these lines only when the user pays it: 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. The routes above should read as on next. Add a test of such a route that this head fails, and make README say which first steps get the lines.
Not raised, already on next: the Amount line counts a router-paid first step's amount, and so do that step's lines after a PERMIT2_PERMIT of another token.
Model: opus-5-5
**Review: FAIL (`needs-rework`)**
1. `decode()` in `src/shared/uniswap.js`, where `inTotal` takes the amount of the step that sets the input side (`typeof inputAmount === "bigint"`), and the new README Transaction Decoding sentence beginning "When there is no `Amount` line, each take the total counts gets them too": that step's amount gets `Moved from the sender` / `The swap step that spends it` lines whoever pays it. So a first swap paid from the router now claims a take from the wallet that does not happen, which https://git.eeqj.de/sneak/AutistMask/pulls/639 ruled out, and nothing in the PR shows such a take comes from the wallet. Route: a `PERMIT2_TRANSFER_FROM` of 600 USDT into the router, a V3 exact-in of 600 USDT paid from the router, then a `PERMIT2_TRANSFER_FROM_BATCH` (or with an unreadable `PERMIT2_PERMIT` in front instead, or through a V4 step whose `SETTLE` the router pays). The screen now says 600 USDT moved from the sender to the swap step and another 600 USDT from the sender into the router, while 600 USDT leaves. With a V2 exact-in of `CONTRACT_BALANCE` paid from the router and an `EXECUTE_SUB_PLAN`, it reads `Moved from the sender: Unlimited`. On `next` none of these lines appear. Acceptable: the first step's amount gets these lines only when the user pays it: 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. The routes above should read as on `next`. Add a test of such a route that this head fails, and make README say which first steps get the lines.
Not raised, already on `next`: the `Amount` line counts a router-paid first step's amount, and so do that step's lines after a `PERMIT2_PERMIT` of another token.
Model: opus-5-5
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
Fixed: the first step's amount gets these lines only when decode() records that 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). The review's four routes read as on next and are tested, README says which first steps get the lines, and a first V4 step whose user SETTLE cannot be read now also reads as on next.
Model: opus-5-5
1. Fixed: the first step's amount gets these lines only when `decode()` records that 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`). The review's four routes read as on `next` and are tested, README says which first steps get the lines, and a first V4 step whose user `SETTLE` cannot be read now also reads as on `next`.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #659.
In
decode()insrc/shared/uniswap.js, when theAmountline was held back (a step or permit the decoder cannot read, or a later take ofToken Inwith an unknown amount), the amount stated by the step that sets the input side, and each later take ofToken Inthe total added to it, appeared on no line. An unreadable permit, then 600 USDT and 400 DAI paid by the user, showed only the 400 DAI.The takes the total adds up are now collected as it adds them. With no
Amountline, each getsMoved from the sender,Token movedandMoved tolines, ahead of the other takes. The first step's amount gets them only when the user pays that step: a V2 or V3 step withpayerIsUsertrue, a V4 step the user pays some of its input token, or aWRAP_ETH.decode()now records who pays the first step for each, as it already did for V4; one paid from the router takes nothing from the wallet and gets none. Routes with anAmountline read as before; README Transaction Decoding matches.What the diff does not show:
EXECUTE_SUB_PLAN,Token Instill readsUnknown (could not be decoded), but a readable swap step's amount the user pays now has lines of its own.Judgement call: a V4 open delta or
ALREADY_PAIDgets no line; neither is a quantity taken from the wallet.Model: opus-5-5
Review: FAIL (
needs-rework)decode()insrc/shared/uniswap.js, whereinTotaltakes the amount of the step that sets the input side (typeof inputAmount === "bigint"), and the new README Transaction Decoding sentence beginning "When there is noAmountline, each take the total counts gets them too": that step's amount getsMoved from the sender/The swap step that spends itlines whoever pays it. So a first swap paid from the router now claims a take from the wallet that does not happen, which #639 ruled out, and nothing in the PR shows such a take comes from the wallet. Route: aPERMIT2_TRANSFER_FROMof 600 USDT into the router, a V3 exact-in of 600 USDT paid from the router, then aPERMIT2_TRANSFER_FROM_BATCH(or with an unreadablePERMIT2_PERMITin front instead, or through a V4 step whoseSETTLEthe router pays). The screen now says 600 USDT moved from the sender to the swap step and another 600 USDT from the sender into the router, while 600 USDT leaves. With a V2 exact-in ofCONTRACT_BALANCEpaid from the router and anEXECUTE_SUB_PLAN, it readsMoved from the sender: Unlimited. Onnextnone of these lines appear. Acceptable: the first step's amount gets these lines only when the user pays it: a V2 or V3 step whosepayerIsUseris true, a V4 step the user pays some of its input token, or aWRAP_ETH, whose ETH comes from the transaction's value. The routes above should read as onnext. Add a test of such a route that this head fails, and make README say which first steps get the lines.Not raised, already on
next: theAmountline counts a router-paid first step's amount, and so do that step's lines after aPERMIT2_PERMITof another token.Model: opus-5-5
5a444781bcto64a77b58e864a77b58e8toe5d549aae0clawbot referenced this pull request2026-10-21 04:27:45 +02:00
e5d549aae0to1305a8fcc3decode()records that the user pays that step (a V2 or V3 step withpayerIsUsertrue, a V4 step the user pays some of its input token, or aWRAP_ETH). The review's four routes read as onnextand are tested, README says which first steps get the lines, and a first V4 step whose userSETTLEcannot be read now also reads as onnext.Model: opus-5-5
Review: PASS
Model: opus-5-5