“Primary names” are a cornerstone of the ENS protocol. They allow any client or third party app to use the address of a connected account to reverse-lookup the name associated with that account. This is the mechanism that allows a user to look like they’re logged in as `jesse.base.eth` in the wallet pip in-app instead of appearing as a `0x…` address.

Today, Basenames natively supports primary names but with some caveats:

• When Basenames launched there wasn’t an ENS-sanctioned way to achieve L2 primary names. The only supported path to primary name setting required a transaction on mainnet against the ENS ReverseRegistrar.

• Apps that want to support Basenames primary names have to use a Basenames-specific lookup, supported most commonly by our onchainkit snippet.

     What this means is that apps that don’t specifically integrate with the Basenames reverse resolver are unable to do reverse resolutions for our users’ addresses. Additionally, if a user wants to take their Basename identity to other chains like mainnet or Optimism, their Basename can’t follow them.

     In close collaboration with the Basenames team, ENS has refined and produced a formal specification for supporting L2 primary names. When ENS launches their contracts and offchain infrastructure, the Basenames protocol will enable end-to-end L2 primary names. Once fully supported, we get the following benefits for all Basename users:

• Primary name resolution on ALL apps using modern webapp clients like viem, not just ones that integrate directly with Basenames via onchainkit

• Basenames can serve as primary names for many networks, not just Base

     Soon. Just this week Spearbit completed a formal audit of two new Basenames contracts that will enable seamless migration to a fully compliant ENSIP-19 system. Though this is a significant milestone, there’s still lots of work to do on our front-ends and backend services. Stay tuned… and in the meantime, stay based.

     “Primary names” are a cornerstone of the ENS protocol. They allow any client or third party app to use the address of a connected account to reverse-lookup the name associated with that account. This is the mechanism that allows a user to look like they’re logged in as `jesse.base.eth` in the wallet pip in-app instead of appearing as a `0x…` address.

Today, Basenames natively supports primary names but with some caveats:

• When Basenames launched there wasn’t an ENS-sanctioned way to achieve L2 primary names. The only supported path to primary name setting required a transaction on mainnet against the ENS ReverseRegistrar.

• Apps that want to support Basenames primary names have to use a Basenames-specific lookup, supported most commonly by our onchainkit snippet.

     What this means is that apps that don’t specifically integrate with the Basenames reverse resolver are unable to do reverse resolutions for our users’ addresses. Additionally, if a user wants to take their Basename identity to other chains like mainnet or Optimism, their Basename can’t follow them.

     In close collaboration with the Basenames team, ENS has refined and produced a formal specification for supporting L2 primary names. When ENS launches their contracts and offchain infrastructure, the Basenames protocol will enable end-to-end L2 primary names. Once fully supported, we get the following benefits for all Basename users:

• Primary name resolution on ALL apps using modern webapp clients like viem, not just ones that integrate directly with Basenames via onchainkit

• Basenames can serve as primary names for many networks, not just Base

     Soon. Just this week Spearbit completed a formal audit of two new Basenames contracts that will enable seamless migration to a fully compliant ENSIP-19 system. Though this is a significant milestone, there’s still lots of work to do on our front-ends and backend services. Stay tuned… and in the meantime, stay based.