How .base.eth Names Work ?
This article provides a detailed explanation of “.base.eth” names, powered by the ENS protocol, which enables anyone to register and use a name like “name.base.eth”, as their main human readable identification on the blockchain.
We’ll cover their structure, how they function, the differences between “.base.eth” and “.eth” names, how Ethereum and Base are connected, and tackle important questions around decentralization, ownership, and effectiveness of these names.
Table Of Content
· What are .base.eth names ?
· How .base.eth names work ?
∘ How .eth names work ?
∘ Resolution of .base.eth names
∘ ENSIP-10: Wildcard Resolution
∘ EIP-3668: Offchain Resolvers
∘ Structure on Base
∘ Architecture Summary
· Potential Risks
∘ Ownership of base.eth
∘ Offchain Gateway Control
∘ Implications
∘ Mitigations
· How is it different from .eth Names ?
· Similar Cases: Uniswap uni.eth names
· Are .base.eth and .uni.eth Names Beneficial for the Ecosystem ?
· Summary
What are .base.eth names ?
Last week, Base launched “.base.eth” names, designed to function as human-readable identifiers on the blockchain, similar to “.eth” names. For example, instead of sending 1 ETH to the address “0x849151d…8CC2308bf1”, it can be sent to “jesse.base.eth”.
They were launched via a Dutch auction with prices starting at 100 ETH and decreasing over 36 hours to reach standard rates between 0.1 ETH and 0.0001 ETH. This pricing mechanism was used to prevent name squatting by bots, who might buy high-profile names at low prices and resell them at a premium.
How .base.eth names work ?
To understand how “.base.eth” names work, it is important to have at least a high-level understanding of how “.eth” names work.
How .eth names work ?
“.eth” names are formed from many components, the simplest way to understand the architecture of these names is the following:
The records of a “.eth” name are recorded in the main ENS Registry, where each name has the following information recorded:
- Address of the Owner
- Address of the Resolver
- TTL (not relevant in our article)
The resolver, stores relevant information for each name, for example, the address that it wants to resolve to, a content hash to parse links, etc.
For example, for the name “ens.eth”:
- 0xb6E040C9ECAaE172a89bD561c5F73e1C48d28cd9 is the owner.
- 0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7 is the resolved address.
The owner of a name has defined abilities:
- Ability to transfer the ownership of the name.
- Ability to create subnames and change their ownership seamlessly. (Owner of “ens.eth” can create and change ownership of “nick.ens.eth”)
The resolved address is the address returned in a query of the name on any interface or library.
This diagram summarizes the entire flow of a query from a client.
Resolution of .base.eth names
With a solid understanding of how “.eth” names work, it is now possible to explore “.base.eth” names.
The first assumption when examining the subdomains section on “base.eth” is to see all the “.base.eth” names registered. However, there are only 9 subdomains that exist. Only 9 !!!
Yet, when navigating to ens.domains and querying “jesse.base.eth”, records information is returned, indicating that the name exists.
A deeper investigation of the ENS Registry reveals that “jesse.base.eth” does not exist in the ENS Registry — there is no owner, no resolver, and no TTL set, and the record doesn’t exist.
This raises several questions:
- Could this be a bug ? Why is the “jesse.base.eth” name not showing up among the subnames of “base.eth” ?
- Why does “jesse.base.eth” resolve even though it does not appear in the main registry ?
- Why are transactions being processed on Base to register a “.base.eth” name, even though the ENS Registry exists on Ethereum ?
- How is data recorded and shared between Base and Ethereum ?
The answers to these questions lie in ENSIP-10 and EIP-3668.
ENSIP-10: Wildcard Resolution
ENSIP-10 defines a method for resolving subnames through their owner. For example, in resolving “jesse.base.eth”, the process is as follows:
- Query the ENS Registry on Ethereum for “jesse.base.eth” name.
- Since the name does not exist and is a subname, perform a wildcard resolution by querying the resolver of “base.eth”.
- Use the records information of “jesse.base.eth” but to be extracted from “base.eth” resolver.
EIP-3668: Offchain Resolvers
The records information from “base.eth” is used, but even this information is not tracked on Ethereum. The resolver for “base.eth” directs the query to an off-chain URL. This URL serves as an endpoint that returns the required data about subnames.
This mechanism is defined by EIP-3668, which allows resolvers to point to an external URL for data retrieval.
Structure on Base
On Base, the “.base.eth” name is recorded within a registry, using an architecture similar to that of ENS, where the same type of information is recorded in the registry, and the owner can modify records in the resolver. For example, “jesse.base.eth” is recorded on-chain on Base with a resolver holding the records information, such as the resolved address, content hash, etc ..
Thus, the actual name “jesse.base.eth” is owned on the Base Registry on Base, not on the ENS Registry on Ethereum.
The off-chain URL retrieved from Ethereum reads the data from the Base Registry through an off-chain lookup.
Architecture Summary
1- “jesse” registers “jesse.base.eth” on Base in the BaseRegistry.
2- The resolved address is set in the L2Resolver.
3- The client wants to send x ETH to “jesse.base.eth”.
4- The client queries “jesse.base.eth”.
5- The name does not exist on Ethereum, so the parent, “base.eth”, is queried.
6- “base.eth” resolves to an off-chain gateway.
7- The off-chain gateway reads from the L2Resolver on Base.
Potential Risks
There are important implications to consider with the current structure of “.base.eth” names, and there are two main issues.
Ownership of base.eth
When querying a name like “name.base.eth”, the query will always start with checking if the name exists on Ethereum. If the name does exist on Ethereum, no wildcard resolution will occur, meaning that any information from Base will not be used. For example, going back to the example of the actual 9 “.base.eth” subnames, “mint.base.eth” will be resolved on Ethereum and won’t be checked against Base, as it already exists on Ethereum. (Check WildCard Resolution section)
This raises the question of how a name gets registered on Ethereum. As mentioned earlier, the owner of “base.eth” — which is a smart contract — can seamlessly assign subdomains according to its logic.
The owner of “base.eth” is a Gnosis Safe, managed by 3 out of 11 executors. This setup means that it requires at least 3 signers to agree to assign “name.base.eth” to an address and to set its resolver to a different address than the one available on Base.
Offchain Gateway Control
Another point of concern is that, according to ERC-3668, the resolver on Ethereum uses a URL to trigger the resolution. This URL, which is embedded in the smart contract, is changeable.
This means the URL could potentially be changed to another one that does not point to the Base Registry on Base but instead to an internal database managed by the Base team. Additionally, even if the URL remains unchanged, the backend logic could be modified to point to this internal database. For example, all names could be made to resolve to the same address, without any transaction occurring on the blockchain.
Due to the use of a gateway service to generate responses, there is additional risk of unavailability: the gateway could be out of operation, or could choose to selectively refuse to answer (censor) certain queries.
Implications
Assuming the trust in the Base team, there still exists a potential threat if control over 3 of the 11 Gnosis Safe signers is compromised. In such a scenario, a malicious actor could wait for scheduled transactions based on “.base.eth” names and change the resolved address of the target “.base.eth” name to intercept funds, effectively redirecting them to an attacker-controlled address.
Moreover, in a scenario where the attacker changes the URL to point to a malicious database, the attacker could manipulate the resolution of multiple “.base.eth” names simultaneously.
Any insider with access could reproduce this scenario without needing to trigger an on-chain transaction. This raises several questions.
- What is to prevent someone from momentarily changing what the URL points to — switching it to an internal database that maps names to a specific address and then quickly switching it back ?
- How would users know if such an event occurred, especially if they were led to believe that any issues were due to their own actions rather than the manipulated URL ?
- What can be done to prevent such cases ?
- What if the gateway was out of service ?
Mitigations
There are no options to mitigate the possibilities of changes to the resolution based on the architecture used. Even if control over the “.base.eth” name is locked, the wildcard resolution using the URL owned by the Base team means that this URL can still be altered. The resolution process could be redirected offline from querying the registry to an internal database.
How is it different from .eth Names ?
Unlike the case of “.base.eth” names, the ownership of “.eth” names is managed by a smart contract known as the EthRegistrar, which has specific rules for assigning subnames (e.g., “name.eth”).
The owner of the RootRegistry has revoked access to the “.eth” name, meaning that even the Gnosis Safe of the ENS team cannot change ownership of “.eth” name, or seize ownership of “name.eth” from anyone. The most they can do is modify the logic for assigning and renewing names in the future.
Similar Cases: Uniswap uni.eth names
Before Base, Uniswap adopted a similar approach with “name.uni.eth” names. However, Uniswap decided to make these names completely free for users to claim in their app, and they are registered in an off-chain database not on the blockchain. The resolution is handled via a URL: https://gateway.uniswap.org/v2/unitags/ccip-read/{sender}/{data}.json
Are .base.eth and .uni.eth Names Beneficial for the Ecosystem ?
Whether “.base.eth” and “.uni.eth” names are beneficial for the ecosystem largely depends on individual perspectives. Each user has their own opinion on the trade-off between decentralization and ease of use when it comes to onboarding more people into the blockchain space.
Did this enhance the user experience (UX) ? Did it help onboard more people to the blockchain ? Certainly, yes. But do users truly own their names in the same way they would with “.eth” names ? The answer is no.
This brings up the core debate: sacrificing ownership to simplify onboarding is a complex issue and opinions vary widely among users. Some may value the convenience and accessibility, while others might be concerned about the lack of true decentralization and control. Ultimately, it is up to each user to decide whether this approach aligns with their values and expectations for the blockchain ecosystem.
Summary
The ownership of a “.base.eth” name on the Base registry on Base is secure, and there is no ability for this ownership to be seized. Users can set their own data, similar to how “.eth” names work on Ethereum, which is a valuable aspect of ownership.
However, the resolution that always happens on Ethereum — the critical factor in determining how names are mapped and used — is ultimately controlled by the Base team. This control can be exerted either on-chain by changing subdomain ownership or through the URL that facilitates the wildcard resolution pointing to names on Base.
In short:
- Do you own your .base.eth name ? Yes.
- Do you control the resolution ? No.
- Should you worry about it ? That depends on your level of trust in the security that the Base team implements.
This article aims to present a neutral perspective on .base.eth names, highlighting both their potential benefits and risks without casting aspersions on any entity.
End of the article.
Connect with me on Twitter, Github, and LinkedIn.
