Update ERC-7730: Generalize "mustMatch" feature with boundaries object with constraints leading to automatic signing refusal

[forshtat]

Summary

Early-stage idea, opened as a draft to gather feedback before finalizing.

Sometimes a parameter only makes sense within a bounded range (e.g. pauseAccount(uint256 time) intended to take a duration of at most ~10 days). A call with a wildly out-of-range value (time = 864000000, ~27 years) is very likely a mistake or malicious intent. Clear signing shows the raw value, but there's currently no way for a spec author to tell a wallet "this value is implausible, don't sign it without extra friction."

This PR adds an optional boundaries property to the field formatter (v3.0.0-next schema only):

"boundaries": {
  "min": "0",
  "max": "864000",
  "excludes": ["1337"],
  "mustMatch": [0, 1, 2],
  "errorMessage": "You are locking your account for {time} seconds — this may be a mistake."
}

Wallets SHOULD refuse to sign by default when the underlying value violates the declared boundaries, and MAY offer an explicit override. It's independent of format and of visible — the field still displays normally.

As part of this, mustMatch moves out of visible into boundaries. It was never really a display concern — it forced the field to always be hidden and had nothing to do with visibility, it just didn't have anywhere else to live. visible now covers display only (always/never/optional/ifNotIn); boundaries covers refusal only, and no longer requires hiding the field to validate it.

Open questions (feedback welcome)

• Should tokenAmount's existing threshold/message (the "Unlimited" display swap) be related to or folded into boundaries? They're triggered by a similar condition (crossing a limit) but take different actions (display substitution vs. refusal) — leaning towards keeping them separate to avoid mixing display and refusal concerns again, but open to discussion.
• Byte-slice/sub-range bounds on bytes values, array-valued fields, and per-field severity levels (e.g. warn vs. refuse) are intentionally out of scope for now.

Test plan

• Schema changes validated as syntactically valid JSON
• New example-boundaries.json validates against the updated schema
• Existing v3.0.0-next-targeted examples still validate (no regressions)
• Community feedback on the shape of boundaries and the open questions above

🤖 Generated with Claude Code

[eip-review-bot]

✅ All reviewers have approved.

[github-actions]

The commit 48c225d (as a parent of bacb1c5) contains errors.
Please inspect the Run Summary for details.