What
The Slice-1b spec (Stage 3, C-PR-1) promised the confirmation card for an unlimited
ERC-20 approval would carry three things: UNLIMITED, an acknowledgement checkbox,
and the per-transaction PIN. The shipped console (v0.1.0) has two of the three:
HIGH RISK: unlimited_approval (bold) — src/ui.rs
decoded_call.method: approve, spender, amount: UNLIMITED (bold)
High-risk approval — enter your PIN: prompt with a masked entry
There is no checkbox anywhere in ui.rs / app.rs.
Why this issue exists
Found during the Stage-6 end-to-end acceptance of the shipped wallet image (repo mcp,
tests/e2e). The acceptance suite asserts what actually ships — risk banner, UNLIMITED
line, and the PIN gate — and those all hold: a bare y on a high-risk card sends nothing,
it opens the PIN prompt (app.rs::on_approve), and the server independently refuses a
pin-less approve with pin_required.
So the protection is in place; what is missing is the second deliberate act the
Stage-3 spec asked for. Arguably the PIN is the stricter gate — but the deviation from a
ratified spec should be decided in the open, not quietly inherited.
Options
- Accept the shipped design and amend the Stage-3 spec (PIN supersedes the checkbox).
- Add the checkbox before the PIN prompt on
high_risk cards (a [ ] I understand …
toggle that must be checked before the PIN entry unlocks).
Decision is the Captain's; this issue exists so it does not evaporate.
What
The Slice-1b spec (Stage 3, C-PR-1) promised the confirmation card for an unlimited
ERC-20 approval would carry three things:
UNLIMITED, an acknowledgement checkbox,and the per-transaction PIN. The shipped console (v0.1.0) has two of the three:
HIGH RISK: unlimited_approval(bold) —src/ui.rsdecoded_call.method: approve,spender,amount: UNLIMITED(bold)High-risk approval — enter your PIN:prompt with a masked entryThere is no checkbox anywhere in
ui.rs/app.rs.Why this issue exists
Found during the Stage-6 end-to-end acceptance of the shipped wallet image (repo
mcp,tests/e2e). The acceptance suite asserts what actually ships — risk banner,UNLIMITEDline, and the PIN gate — and those all hold: a bare
yon a high-risk card sends nothing,it opens the PIN prompt (
app.rs::on_approve), and the server independently refuses apin-less approve with
pin_required.So the protection is in place; what is missing is the second deliberate act the
Stage-3 spec asked for. Arguably the PIN is the stricter gate — but the deviation from a
ratified spec should be decided in the open, not quietly inherited.
Options
high_riskcards (a[ ] I understand …toggle that must be checked before the PIN entry unlocks).
Decision is the Captain's; this issue exists so it does not evaporate.