{
  "id": 8466680,
  "title": "An address validator should return a reason, not a boolean",
  "url": "https://urgent.news/2026/09/19/an-address-validator-should-return-a-reason-not-a-boolean",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-19T13:27:17.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/polycratia/an-address-validator-should-return-a-reason-not-a-boolean-1m05"
  },
  "original_language": "en",
  "account": "An address validator should provide a reason for rejection instead of simply returning a boolean value. When users paste an address into a withdrawal form, it may be truncated, belong to a different network, or use an encoding format not supported by the current build. A boolean-only validation fails to capture these distinctions and discards valuable information that could be acted upon by the caller. By returning validation results with a typed reason, the UI and support tooling can branch based on the specific issue, improving the user experience without requiring changes to existing branches. For example, a checksum mismatch indicates a problem with the bytes on screen, while an address decoding cleanly but belonging to another network suggests the user should be redirected to a different withdrawal flow or support conversation. Version bytes inside well-formed encodings that do not match the expected encoding are often not the user's fault and should be handled separately as a roadmap signal. Returning a single boolean value leads to inconsistent and ambiguous messages for the user, as different call sites invent their own explanations based on the absence of information. A validator returning a structured result carrying a reason, format name, and network allows callers to make informed decisions about the next steps, whether it involves asking the user to repeat the entry, redirecting them to a different process, or informing them about unsupported formats. This design choice prevents the propagation of incomplete information throughout the codebase and ensures that new address formats can be added without requiring extensive modifications to existing call sites.",
  "summary": "A user pastes an address into a withdrawal form and gets back \"invalid address\". Sometimes the string was truncated by a copy that clipped at a line break. Sometimes it is a perfectly good address for a network you are not sending on. Sometimes it is an encoding your build does not know yet. Three different situations, three different fixes, and a validator that returns a boolean has thrown away…",
  "key_points": [
    "Address validator should return reason, not boolean",
    "Boolean-only validation fails to capture address distinctions",
    "Structured result with reason enables informed decisions"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}