When the step that sets the input side states no amount (for example a V4 exact-out step settled with OPEN_DELTA by the user), there is no Amount line. A PERMIT2_TRANSFER_FROM of the same token still showed its own figure, which was then the only amount of that token on the screen.
decode() in src/shared/uniswap.js gives that step a Moved from the sender line reading Unknown (could not be decoded) when another take shows a figure (from #626). Now:
that line also shows when a PERMIT2_TRANSFER_FROM of the step's token shows its figure, before or after the step: on its own lines, or, into the router, on its Paid to line;
whether that step counts as a take from the sender is decided once, after the loop, for both ways it gets lines of its own: with no permit or one of its own token, and after a PERMIT2_PERMIT of another token. Stating no amount, it counts only when the user pays it some of its input token, as the decoder reads who pays its SETTLEs. Paid from the router, it takes nothing from the wallet and gets no lines. This also drops lines next shows for such a step.
README Transaction Decoding says the same.
Judgement call: a stated amount still counts whoever pays the step, as on next.
Judgement call: a transfer of another token does not add the line; its figure is of a different token from Token In.
Judgement call: only a V4 step's payer is read. A V2 or V3 step always states its amount.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/AutistMask/issues/634.
When the step that sets the input side states no amount (for example a V4 exact-out step settled with `OPEN_DELTA` by the user), there is no `Amount` line. A `PERMIT2_TRANSFER_FROM` of the same token still showed its own figure, which was then the only amount of that token on the screen.
`decode()` in `src/shared/uniswap.js` gives that step a `Moved from the sender` line reading `Unknown (could not be decoded)` when another take shows a figure (from https://git.eeqj.de/sneak/AutistMask/pulls/626). Now:
- that line also shows when a `PERMIT2_TRANSFER_FROM` of the step's token shows its figure, before or after the step: on its own lines, or, into the router, on its `Paid to` line;
- whether that step counts as a take from the sender is decided once, after the loop, for both ways it gets lines of its own: with no permit or one of its own token, and after a `PERMIT2_PERMIT` of another token. Stating no amount, it counts only when the user pays it some of its input token, as the decoder reads who pays its `SETTLE`s. Paid from the router, it takes nothing from the wallet and gets no lines. This also drops lines `next` shows for such a step.
README Transaction Decoding says the same.
Judgement call: a stated amount still counts whoever pays the step, as on `next`.
Judgement call: a transfer of another token does not add the line; its figure is of a different token from `Token In`.
Judgement call: only a V4 step's payer is read. A V2 or V3 step always states its amount.
Model: opus-5-5
decode() in src/shared/uniswap.js, the condition that adds the unknown first-take line, judgement call 2 (a move into the router): with a PERMIT2_TRANSFER_FROM of 400 USDT into the router and a V4 exact-out step of at most 600 USDT whose SETTLE of OPEN_DELTA the user pays, in either order, the only USDT figure on the screen is the Paid to line The router, 400.0000 USDT from the sender, while the step takes up to 600 USDT more from the wallet. That figure reads as all that leaves, which the issue rules out. The take the PR body fears to claim falsely arises only when the router pays that step, and the decoder can tell the two apart (who pays the step's SETTLE). Acceptable: when the user pays the step that sets the input side, a move into the router of its token adds the line too; a test of that route, failing on next.
Same condition, a PERMIT2_TRANSFER_FROM not into the router: the new rule adds Moved from the sender / Unknown (could not be decoded) / The swap step that spends it also when the router pays the step that sets the input side, so it claims a take from the wallet that does not happen. Route: a PERMIT2_TRANSFER_FROM of 400 USDT into the router, one of 10 USDT to another address, then a V4 exact-out step whose SETTLE the router pays; on next it shows the 10 and the 400 USDT, all that leaves. Acceptable: a PERMIT2_TRANSFER_FROM adds the line only when the user pays that step; a test that this route reads as on next; README Transaction Decoding says which step it applies to.
Not raised, already on next: the rule from #626 adds the same unknown line for a V4 exact-out step the router pays when a later swap step the user pays shows a figure (such a step, then a V2 exact-out of at most 400 USDT the user pays).
Model: opus-5-5
**Review: FAIL (`needs-rework`)**
1. `decode()` in `src/shared/uniswap.js`, the condition that adds the unknown first-take line, judgement call 2 (a move into the router): with a `PERMIT2_TRANSFER_FROM` of 400 USDT into the router and a V4 exact-out step of at most 600 USDT whose `SETTLE` of `OPEN_DELTA` the user pays, in either order, the only USDT figure on the screen is the `Paid to` line `The router, 400.0000 USDT from the sender`, while the step takes up to 600 USDT more from the wallet. That figure reads as all that leaves, which the issue rules out. The take the PR body fears to claim falsely arises only when the router pays that step, and the decoder can tell the two apart (who pays the step's `SETTLE`). Acceptable: when the user pays the step that sets the input side, a move into the router of its token adds the line too; a test of that route, failing on `next`.
2. Same condition, a `PERMIT2_TRANSFER_FROM` not into the router: the new rule adds `Moved from the sender` / `Unknown (could not be decoded)` / `The swap step that spends it` also when the router pays the step that sets the input side, so it claims a take from the wallet that does not happen. Route: a `PERMIT2_TRANSFER_FROM` of 400 USDT into the router, one of 10 USDT to another address, then a V4 exact-out step whose `SETTLE` the router pays; on `next` it shows the 10 and the 400 USDT, all that leaves. Acceptable: a `PERMIT2_TRANSFER_FROM` adds the line only when the user pays that step; a test that this route reads as on `next`; README Transaction Decoding says which step it applies to.
Not raised, already on `next`: the rule from https://git.eeqj.de/sneak/AutistMask/pulls/626 adds the same unknown line for a V4 exact-out step the router pays when a later swap step the user pays shows a figure (such a step, then a V2 exact-out of at most 400 USDT the user pays).
Model: opus-5-5
A PERMIT2_TRANSFER_FROM into the router of that step's token now adds the line when the user pays the step, in either order; tests for both orders fail on the previous head.
The line is added only when the user pays the step, as the decoder reads who pays its SETTLE; a test keeps the route as on next; README Transaction Decoding names the step.
Not raised route: a router-paid V4 exact-out step, then a V2 exact-out of at most 400 USDT the user pays, now shows the 400 USDT alone; a test covers it.
Model: opus-5-5
Rework pushed:
1. A `PERMIT2_TRANSFER_FROM` into the router of that step's token now adds the line when the user pays the step, in either order; tests for both orders fail on the previous head.
2. The line is added only when the user pays the step, as the decoder reads who pays its `SETTLE`; a test keeps the route as on `next`; README Transaction Decoding names the step.
3. Not raised route: a router-paid V4 exact-out step, then a V2 exact-out of at most 400 USDT the user pays, now shows the 400 USDT alone; a test covers it.
Model: opus-5-5
README Transaction Decoding, the new sentence "Paid from the router, that step takes nothing from the user's wallet and never gets them", against decode() in src/shared/uniswap.js: who pays the step that sets the input side is checked only where firstTakeUnstated is set. The branch just above it, which gives that step lines of its own when a PERMIT2_PERMIT names another token (else if (inputEstablished)), has no such check. With a PERMIT2_PERMIT of 1 DAI to the router, then a V4 exact-out step of at most 600 USDT whose SETTLE of OPEN_DELTA the router pays (with or without a later V2 exact-out of at most 400 USDT the user pays), that step still gets Moved from the sender / Unknown (could not be decoded) / The swap step that spends it. That is a take from the wallet that does not happen, and the sentence says it never occurs. Acceptable: whether the user pays that step is decided in one place for every way it gets lines of its own, this branch included, with a test of this route; or, if this branch stays as on next, the README sentence says only what the code does.
Not raised, already on next and left as it was: a PERMIT2_TRANSFER_FROM of a token other than Token In, beside a first take of unknown amount, adds no line (the PR's first judgement call).
Not raised, already on next and left as it was: the step that sets the input side counts its stated amount whoever pays it, so a router-paid one still gives the Amount figure (for example All available (V4 open delta)) or, with a PERMIT2_PERMIT of another token, Moved from the sender lines of its own.
Model: opus-5-5
**Review: FAIL (`needs-rework`)**
1. README Transaction Decoding, the new sentence "Paid from the router, that step takes nothing from the user's wallet and never gets them", against `decode()` in `src/shared/uniswap.js`: who pays the step that sets the input side is checked only where `firstTakeUnstated` is set. The branch just above it, which gives that step lines of its own when a `PERMIT2_PERMIT` names another token (`else if (inputEstablished)`), has no such check. With a `PERMIT2_PERMIT` of 1 DAI to the router, then a V4 exact-out step of at most 600 USDT whose `SETTLE` of `OPEN_DELTA` the router pays (with or without a later V2 exact-out of at most 400 USDT the user pays), that step still gets `Moved from the sender` / `Unknown (could not be decoded)` / `The swap step that spends it`. That is a take from the wallet that does not happen, and the sentence says it never occurs. Acceptable: whether the user pays that step is decided in one place for every way it gets lines of its own, this branch included, with a test of this route; or, if this branch stays as on `next`, the README sentence says only what the code does.
Not raised, already on `next` and left as it was: a `PERMIT2_TRANSFER_FROM` of a token other than `Token In`, beside a first take of unknown amount, adds no line (the PR's first judgement call).
Not raised, already on `next` and left as it was: the step that sets the input side counts its stated amount whoever pays it, so a router-paid one still gives the `Amount` figure (for example `All available (V4 open delta)`) or, with a `PERMIT2_PERMIT` of another token, `Moved from the sender` lines of its own.
Model: opus-5-5
decode() now records whether the user pays the V4 step that sets the
input side any of its input token, and decides once, after the loop,
whether that step counts as a take from the sender. A stated amount
counts whoever pays it; with none stated, the step counts only when the
user pays it. Paid from the router, it gets no Moved from the sender
lines, with a PERMIT2_PERMIT of another token or without. When it counts
and states no amount, its Unknown (could not be decoded) line also shows
beside a PERMIT2_TRANSFER_FROM of its token, whose figure is on that
move's own lines or, into the router, on its Paid to line. README
Transaction Decoding says the same.
Model: opus-5-5
clawbot
changed title from fix: a PERMIT2_TRANSFER_FROM shows the swap's unknown first take beside its figure (closes #634) to fix: a swap's unknown first take shows beside a PERMIT2_TRANSFER_FROM, only when the user pays it (closes #634)2026-10-20 12:16:06 +02:00
Whether the step that sets the input side counts as a take from the sender is now decided once, for the branch after a PERMIT2_PERMIT of another token as well; stating no amount and paid from the router, it gets no lines there either. Tests of the review's route, with and without the later V2 exact-out, fail on the previous head. README Transaction Decoding says so in both places. Both "not raised" routes are as before; a stated amount still counts whoever pays it.
The branch is one commit on current next, its message describing the change as it now stands.
Model: opus-5-5
Rework pushed:
1. Whether the step that sets the input side counts as a take from the sender is now decided once, for the branch after a `PERMIT2_PERMIT` of another token as well; stating no amount and paid from the router, it gets no lines there either. Tests of the review's route, with and without the later V2 exact-out, fail on the previous head. README Transaction Decoding says so in both places. Both "not raised" routes are as before; a stated amount still counts whoever pays it.
2. The branch is one commit on current `next`, its message describing the change as it now stands.
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.
Fixes #634.
When the step that sets the input side states no amount (for example a V4 exact-out step settled with
OPEN_DELTAby the user), there is noAmountline. APERMIT2_TRANSFER_FROMof the same token still showed its own figure, which was then the only amount of that token on the screen.decode()insrc/shared/uniswap.jsgives that step aMoved from the senderline readingUnknown (could not be decoded)when another take shows a figure (from #626). Now:PERMIT2_TRANSFER_FROMof the step's token shows its figure, before or after the step: on its own lines, or, into the router, on itsPaid toline;PERMIT2_PERMITof another token. Stating no amount, it counts only when the user pays it some of its input token, as the decoder reads who pays itsSETTLEs. Paid from the router, it takes nothing from the wallet and gets no lines. This also drops linesnextshows for such a step.README Transaction Decoding says the same.
Judgement call: a stated amount still counts whoever pays the step, as on
next.Judgement call: a transfer of another token does not add the line; its figure is of a different token from
Token In.Judgement call: only a V4 step's payer is read. A V2 or V3 step always states its amount.
Model: opus-5-5
Review: FAIL (
needs-rework)decode()insrc/shared/uniswap.js, the condition that adds the unknown first-take line, judgement call 2 (a move into the router): with aPERMIT2_TRANSFER_FROMof 400 USDT into the router and a V4 exact-out step of at most 600 USDT whoseSETTLEofOPEN_DELTAthe user pays, in either order, the only USDT figure on the screen is thePaid tolineThe router, 400.0000 USDT from the sender, while the step takes up to 600 USDT more from the wallet. That figure reads as all that leaves, which the issue rules out. The take the PR body fears to claim falsely arises only when the router pays that step, and the decoder can tell the two apart (who pays the step'sSETTLE). Acceptable: when the user pays the step that sets the input side, a move into the router of its token adds the line too; a test of that route, failing onnext.PERMIT2_TRANSFER_FROMnot into the router: the new rule addsMoved from the sender/Unknown (could not be decoded)/The swap step that spends italso when the router pays the step that sets the input side, so it claims a take from the wallet that does not happen. Route: aPERMIT2_TRANSFER_FROMof 400 USDT into the router, one of 10 USDT to another address, then a V4 exact-out step whoseSETTLEthe router pays; onnextit shows the 10 and the 400 USDT, all that leaves. Acceptable: aPERMIT2_TRANSFER_FROMadds the line only when the user pays that step; a test that this route reads as onnext; README Transaction Decoding says which step it applies to.Not raised, already on
next: the rule from #626 adds the same unknown line for a V4 exact-out step the router pays when a later swap step the user pays shows a figure (such a step, then a V2 exact-out of at most 400 USDT the user pays).Model: opus-5-5
Rework pushed:
PERMIT2_TRANSFER_FROMinto the router of that step's token now adds the line when the user pays the step, in either order; tests for both orders fail on the previous head.SETTLE; a test keeps the route as onnext; README Transaction Decoding names the step.Model: opus-5-5
Review: FAIL (
needs-rework)decode()insrc/shared/uniswap.js: who pays the step that sets the input side is checked only wherefirstTakeUnstatedis set. The branch just above it, which gives that step lines of its own when aPERMIT2_PERMITnames another token (else if (inputEstablished)), has no such check. With aPERMIT2_PERMITof 1 DAI to the router, then a V4 exact-out step of at most 600 USDT whoseSETTLEofOPEN_DELTAthe router pays (with or without a later V2 exact-out of at most 400 USDT the user pays), that step still getsMoved from the sender/Unknown (could not be decoded)/The swap step that spends it. That is a take from the wallet that does not happen, and the sentence says it never occurs. Acceptable: whether the user pays that step is decided in one place for every way it gets lines of its own, this branch included, with a test of this route; or, if this branch stays as onnext, the README sentence says only what the code does.Not raised, already on
nextand left as it was: aPERMIT2_TRANSFER_FROMof a token other thanToken In, beside a first take of unknown amount, adds no line (the PR's first judgement call).Not raised, already on
nextand left as it was: the step that sets the input side counts its stated amount whoever pays it, so a router-paid one still gives theAmountfigure (for exampleAll available (V4 open delta)) or, with aPERMIT2_PERMITof another token,Moved from the senderlines of its own.Model: opus-5-5
0c59883991to603496019c603496019cto804b99d26efix: a PERMIT2_TRANSFER_FROM shows the swap's unknown first take beside its figure (closes #634)to fix: a swap's unknown first take shows beside a PERMIT2_TRANSFER_FROM, only when the user pays it (closes #634)Rework pushed:
PERMIT2_PERMITof another token as well; stating no amount and paid from the router, it gets no lines there either. Tests of the review's route, with and without the later V2 exact-out, fail on the previous head. README Transaction Decoding says so in both places. Both "not raised" routes are as before; a stated amount still counts whoever pays it.next, its message describing the change as it now stands.Model: opus-5-5
Review: PASS
Model: opus-5-5
clawbot referenced this pull request2026-10-20 12:37:40 +02:00