A PERMIT2_PERMIT_BATCH was never read, and a PERMIT2_PERMIT whose input could not be read got no lines, so the approval screen showed nothing of the allowances either grants.
What changed, in src/shared/uniswap.js:
decodePermit2Batch() reads the batch in the shape every pinned release's Dispatcher.sol hands to Permit2. Each allowance joins the single permits' list and gets the same three lines (Permit2 allowance, Allowance token, Allowance spender) from the same loop.
A permit or batch that cannot be read gets one Permit2 allowance line reading Unknown (could not be decoded), and there is no Amount line.
A batch pays nobody, so it no longer adds Paid to: Unknown (could not be decoded). Without that line the minimum can read Min. received.
README Transaction Decoding and the TxApproval element list match.
What a reader may trip over:
A batch names one spender for all its allowances, so the "another spender" test is a batch whose spender is not the router.
Judgement call: any batch in the transaction now keeps a PERMIT2_PERMIT's amount from standing as the Amount figure. On next only a batch after the permit did, by going unread; a batch before it let the permit stand. Counting every batch is as simple as the existing "only PERMIT2_PERMIT" condition, and the Amount line then gives the total the steps take.
A batch still counts, as on next, as a step that may take WETH out of the router (the UNWRAP_WETH minimum rule), where a single permit does not. I left that alone as outside this issue.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/AutistMask/issues/652.
A `PERMIT2_PERMIT_BATCH` was never read, and a `PERMIT2_PERMIT` whose input could not be read got no lines, so the approval screen showed nothing of the allowances either grants.
What changed, in `src/shared/uniswap.js`:
- `decodePermit2Batch()` reads the batch in the shape every pinned release's `Dispatcher.sol` hands to Permit2. Each allowance joins the single permits' list and gets the same three lines (`Permit2 allowance`, `Allowance token`, `Allowance spender`) from the same loop.
- A permit or batch that cannot be read gets one `Permit2 allowance` line reading `Unknown (could not be decoded)`, and there is no `Amount` line.
- A batch pays nobody, so it no longer adds `Paid to: Unknown (could not be decoded)`. Without that line the minimum can read `Min. received`.
README Transaction Decoding and the TxApproval element list match.
What a reader may trip over:
- A batch names one spender for all its allowances, so the "another spender" test is a batch whose spender is not the router.
- Judgement call: any batch in the transaction now keeps a `PERMIT2_PERMIT`'s amount from standing as the `Amount` figure. On `next` only a batch after the permit did, by going unread; a batch before it let the permit stand. Counting every batch is as simple as the existing "only `PERMIT2_PERMIT`" condition, and the `Amount` line then gives the total the steps take.
- A batch still counts, as on `next`, as a step that may take WETH out of the router (the `UNWRAP_WETH` minimum rule), where a single permit does not. I left that alone as outside this issue.
Model: opus-5-5
A PERMIT2_PERMIT_BATCH was never read, and a PERMIT2_PERMIT whose input
could not be read got no lines, so the approval screen showed nothing of
the allowances either grants.
Each allowance of a batch now gets the three lines a permit whose amount
does not stand gets: Permit2 allowance, Allowance token and Allowance
spender. A permit or batch that cannot be read gets one Permit2 allowance
line reading Unknown (could not be decoded) and leaves no Amount line.
Any batch in the transaction keeps a PERMIT2_PERMIT's amount from
standing. A batch pays nobody, so it no longer adds a Paid to line.
README Transaction Decoding and the TxApproval element list match.
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 #652.
A
PERMIT2_PERMIT_BATCHwas never read, and aPERMIT2_PERMITwhose input could not be read got no lines, so the approval screen showed nothing of the allowances either grants.What changed, in
src/shared/uniswap.js:decodePermit2Batch()reads the batch in the shape every pinned release'sDispatcher.solhands to Permit2. Each allowance joins the single permits' list and gets the same three lines (Permit2 allowance,Allowance token,Allowance spender) from the same loop.Permit2 allowanceline readingUnknown (could not be decoded), and there is noAmountline.Paid to: Unknown (could not be decoded). Without that line the minimum can readMin. received.README Transaction Decoding and the TxApproval element list match.
What a reader may trip over:
PERMIT2_PERMIT's amount from standing as theAmountfigure. Onnextonly a batch after the permit did, by going unread; a batch before it let the permit stand. Counting every batch is as simple as the existing "onlyPERMIT2_PERMIT" condition, and theAmountline then gives the total the steps take.next, as a step that may take WETH out of the router (theUNWRAP_WETHminimum rule), where a single permit does not. I left that alone as outside this issue.Model: opus-5-5
Review: PASS
Model: opus-5-5
clawbot referenced this pull request2026-10-21 01:40:06 +02:00