enssdk: brainstorm the application of stricter constraints to the `NormalizedAddress` type

[Y3drk]

Goal

There is an idea to implement the same formalities around NormalizedAddress as we implemented for InterpretedName, and that we need utility functions such as asNormalizedAddress, which would then guarantee the value returned is a NormalizedAddress.

We are aware that there are technical reasons in Ponder for why it hasn't been done before, so we need to consider if that approach is reasonable before actually actioning it.

Priority

Fairly low

Shouldn't distract @shrugs from any of his current tasks.

Why

• Requested here by @lightwalker-eth

[coderabbitai]

🔗 Related PRs

#1938 - Using NormalizedAddress in referral program logic [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!