decode() in src/shared/uniswap.js read two router zeros as literal values:
A V2 exact-in amountIn of zero is the router's ALREADY_PAID marker (universal-router Constants.sol). The step pays nothing itself and swaps whatever an earlier step sent to the pair. Amount showed 0.0000 USDT; it now reads Whatever an earlier step sent to the pair (V2 already paid), carried as a sentinel the same way the V4 open delta is. The wait, success and error screens get the same words. A V3 zero amountIn has no such meaning and still shows as a zero.
BALANCE_CHECK_ERC20 passes whenever the balance is at least minBalance, so a zero one guarantees nothing. A nonzero one sets Token Out and Min. received as before. A zero one sets them only when the output side holds no minimum, not even a zero one, at the point the check is reached; otherwise it leaves the current token and figure in place.
The two tests for the issue's cases fail against current next. Two more pin the behaviour that did not change.
README.md Display Consistency text and TODO.md are updated in the same commit.
Judgement call: a zero balance check keeps whatever minimum the output side holds when the check is reached, whichever step put it there (a swap step, a V2 exact-out amountOut or an earlier nonzero balance check). A check that guarantees nothing should not erase any guarantee.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/AutistMask/issues/415.
`decode()` in `src/shared/uniswap.js` read two router zeros as literal values:
- A V2 exact-in `amountIn` of zero is the router's `ALREADY_PAID` marker (universal-router `Constants.sol`). The step pays nothing itself and swaps whatever an earlier step sent to the pair. `Amount` showed `0.0000 USDT`; it now reads `Whatever an earlier step sent to the pair (V2 already paid)`, carried as a sentinel the same way the V4 open delta is. The wait, success and error screens get the same words. A V3 zero `amountIn` has no such meaning and still shows as a zero.
- `BALANCE_CHECK_ERC20` passes whenever the balance is at least `minBalance`, so a zero one guarantees nothing. A nonzero one sets `Token Out` and `Min. received` as before. A zero one sets them only when the output side holds no minimum, not even a zero one, at the point the check is reached; otherwise it leaves the current token and figure in place.
The two tests for the issue's cases fail against current `next`. Two more pin the behaviour that did not change.
`README.md` Display Consistency text and `TODO.md` are updated in the same commit.
Judgement call: a zero balance check keeps whatever minimum the output side holds when the check is reached, whichever step put it there (a swap step, a V2 exact-out `amountOut` or an earlier nonzero balance check). A check that guarantees nothing should not erase any guarantee.
Model: opus-5-5
README.md lines 1009-1011, and the same sentence in the PR body: they say a zero minBalance sets Token Out and Min. received only when no earlier step stated a minimum. decode() instead checks whether the output side holds a minimum when the balance check is reached. These differ when a later step clears a minimum: a V2 exact-in states a minimum, a V4 swap step that names an output token but no minimum (an exact-out action) replaces it, and a zero balance check after both then sets Token Out to its own token and Min. received to None (no minimum guaranteed), although an earlier step did state a minimum. Acceptable: the README and PR body state the condition the code tests (a zero minBalance sets both lines only when no minimum is on the output side at that point, and otherwise leaves the current token and figure in place).
Model: opus-5-5
FAIL
1. `README.md` lines 1009-1011, and the same sentence in the PR body: they say a zero `minBalance` sets `Token Out` and `Min. received` only when no earlier step stated a minimum. `decode()` instead checks whether the output side holds a minimum when the balance check is reached. These differ when a later step clears a minimum: a V2 exact-in states a minimum, a V4 swap step that names an output token but no minimum (an exact-out action) replaces it, and a zero balance check after both then sets `Token Out` to its own token and `Min. received` to `None (no minimum guaranteed)`, although an earlier step did state a minimum. Acceptable: the README and PR body state the condition the code tests (a zero `minBalance` sets both lines only when no minimum is on the output side at that point, and otherwise leaves the current token and figure in place).
Model: opus-5-5
A V2 exact-in amountIn of zero is the router's ALREADY_PAID marker: an
earlier step sent the tokens to the pair and the swap spends all of them.
Amount showed 0.0000 for it; it now reads "Whatever an earlier step sent
to the pair (V2 already paid)", in the style of the V4 open delta line.
A BALANCE_CHECK_ERC20 passes whenever the balance is at least minBalance,
so a zero one guarantees nothing. It now sets the output side only when
that side holds no minimum at the point the check is reached; a nonzero
one sets the output side as before.
README's Display Consistency text and TODO.md are updated to match.
Model: opus-5-5
Fixed: README.md and the PR body now give the condition decode() tests, the output side holding no minimum (a zero one counts as a minimum) when the check is reached; the TODO.md entry and the commit message say the same. Docs only, no code change.
Model: opus-5-5
Rework for https://git.eeqj.de/sneak/AutistMask/pulls/440#issuecomment-125562:
1. Fixed: `README.md` and the PR body now give the condition `decode()` tests, the output side holding no minimum (a zero one counts as a minimum) when the check is reached; the `TODO.md` entry and the commit message say the same. Docs only, no code change.
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 #415.
decode()insrc/shared/uniswap.jsread two router zeros as literal values:amountInof zero is the router'sALREADY_PAIDmarker (universal-routerConstants.sol). The step pays nothing itself and swaps whatever an earlier step sent to the pair.Amountshowed0.0000 USDT; it now readsWhatever an earlier step sent to the pair (V2 already paid), carried as a sentinel the same way the V4 open delta is. The wait, success and error screens get the same words. A V3 zeroamountInhas no such meaning and still shows as a zero.BALANCE_CHECK_ERC20passes whenever the balance is at leastminBalance, so a zero one guarantees nothing. A nonzero one setsToken OutandMin. receivedas before. A zero one sets them only when the output side holds no minimum, not even a zero one, at the point the check is reached; otherwise it leaves the current token and figure in place.The two tests for the issue's cases fail against current
next. Two more pin the behaviour that did not change.README.mdDisplay Consistency text andTODO.mdare updated in the same commit.Judgement call: a zero balance check keeps whatever minimum the output side holds when the check is reached, whichever step put it there (a swap step, a V2 exact-out
amountOutor an earlier nonzero balance check). A check that guarantees nothing should not erase any guarantee.Model: opus-5-5
FAIL
README.mdlines 1009-1011, and the same sentence in the PR body: they say a zerominBalancesetsToken OutandMin. receivedonly when no earlier step stated a minimum.decode()instead checks whether the output side holds a minimum when the balance check is reached. These differ when a later step clears a minimum: a V2 exact-in states a minimum, a V4 swap step that names an output token but no minimum (an exact-out action) replaces it, and a zero balance check after both then setsToken Outto its own token andMin. receivedtoNone (no minimum guaranteed), although an earlier step did state a minimum. Acceptable: the README and PR body state the condition the code tests (a zerominBalancesets both lines only when no minimum is on the output side at that point, and otherwise leaves the current token and figure in place).Model: opus-5-5
1bb1d67293to87071bf6ffRework for #440 (comment):
README.mdand the PR body now give the conditiondecode()tests, the output side holding no minimum (a zero one counts as a minimum) when the check is reached; theTODO.mdentry and the commit message say the same. Docs only, no code change.Model: opus-5-5
PASS
Model: opus-5-5