decision: a trailing PERMIT2_PERMIT replaces the swap's input side on the approval screen #370

New Issue

clawbot · 2026-08-23T20:46:27+02:00

clawbot commented

2026-08-23 20:46:27 +02:00

Raised by the review of #368 (#368 (comment)). Pre-existing and unchanged by that PR — verified byte-identical in behaviour before and after it.

A PERMIT2_PERMIT arriving AFTER a swap step has already established the input side still REPLACES it. So the Token In and Amount shown can be the permit's token and allowance rather than the swap's actual input.

Why it is not obviously wrong: the permit is a real authorization in the same transaction, and #368's stated invariant — that an amount and the token it is counted in always come from the same source — is honoured, because both halves come from the permit together. Nothing displayed is internally inconsistent.

Why it is worth deciding: "the first source that states either half" is not what a trailing permit does, and this is the one remaining route by which the displayed input side is not the swap's input. On a screen whose job is to state what is being authorized, showing an allowance where the user expects the amount being swapped is a plausible misreading.

The reviewer declined to file it as a defect because it is deliberate and unchanged; it is filed here as a decision rather than a bug.

Options

(a) Leave it. The permit is the more consequential authorization — an allowance usually outlives the swap — so showing it is arguably the safer default.
(b) Show both. Keep the swap's input as Token In, and render the permit as its own labelled line, so neither displaces the other.
(c) First-writer-wins. Do not let a later permit replace an already-established input side.

Recommendation: (b), since both facts are true and the screen currently has to discard one of them. It is also the only option under which nothing the user is authorizing goes unstated.

Definition of done

Decision recorded, and implemented if it is (b) or (c).
Whichever is chosen, the behaviour is recorded at the code site so the next reader does not re-derive it.
Test pinning the chosen behaviour for a swap followed by a permit naming a different token.
make check green.

Raised by the review of https://git.eeqj.de/sneak/AutistMask/pulls/368 (https://git.eeqj.de/sneak/AutistMask/pulls/368#issuecomment-69335). Pre-existing and unchanged by that PR — verified byte-identical in behaviour before and after it. A `PERMIT2_PERMIT` arriving AFTER a swap step has already established the input side still REPLACES it. So the `Token In` and `Amount` shown can be the permit's token and allowance rather than the swap's actual input. Why it is not obviously wrong: the permit is a real authorization in the same transaction, and https://git.eeqj.de/sneak/AutistMask/pulls/368's stated invariant — that an amount and the token it is counted in always come from the same source — is honoured, because both halves come from the permit together. Nothing displayed is internally inconsistent. Why it is worth deciding: "the first source that states either half" is not what a trailing permit does, and this is the one remaining route by which the displayed input side is not the swap's input. On a screen whose job is to state what is being authorized, showing an allowance where the user expects the amount being swapped is a plausible misreading. The reviewer declined to file it as a defect because it is deliberate and unchanged; it is filed here as a decision rather than a bug. ## Options - **(a) Leave it.** The permit is the more consequential authorization — an allowance usually outlives the swap — so showing it is arguably the safer default. - **(b) Show both.** Keep the swap's input as `Token In`, and render the permit as its own labelled line, so neither displaces the other. - **(c) First-writer-wins.** Do not let a later permit replace an already-established input side. Recommendation: **(b)**, since both facts are true and the screen currently has to discard one of them. It is also the only option under which nothing the user is authorizing goes unstated. ## Definition of done - [ ] Decision recorded, and implemented if it is (b) or (c). - [ ] Whichever is chosen, the behaviour is recorded at the code site so the next reader does not re-derive it. - [ ] Test pinning the chosen behaviour for a swap followed by a permit naming a different token. - [ ] `make check` green.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/AutistMask#370