Name-Owned Account
Video
Original
Abstract
The ERC suggests expanding the capabilities of the name service, such as ENS, by enabling each human-readable identity to be linked to a single smart contract account that can be controlled by the owner of the name identity.
Motivation
Name itself cannot hold any context. We want to build an extension of name service to give name rich context by offering each name owner an extra ready to use smart contract account, which may help the general smart contract account adoption. With NOA, it is possible to hold assets and information for its name node, opening up new use cases such as name node transfers, which involve transferring ownership of the name node as well as the NOA, including any assets and information it holds.
Specification
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Name-Owned Account
An NOA has
- a human readable name defined by ERC-137; and
- an owned account(NOA), which is an smart contract account whose address is derived from the name; and
- owner(s) of the name that can deploy and manipulate the owned account.
The following diagram illustrates the relationship between NOA, name node, and name owner, with the ownership being guaranteed by the name service.
┌───────────────┐ ┌───────────┐ ┌───────────────┐
│ Owned Account ◄──own───┤ Name Node ◄───own───┤ Name Owner │
└───────────────┘ └───────────┘ └───────────────┘
Interface
The core interface required for a name service to have is:
interface INameServiceRegistry {
/// @notice get account address owned by the name node
/// @params node represents a name node
/// @return the address of an account
function ownedAccount(
bytes32 node
) external view returns(address);
}
The core interface required for the name owned account is:
interface INameOwnedAccount {
/// @notice get the name node is mapped to this account address
/// @return return a name node
function name() external view returns(bytes32);
/// @notice get the name service contract address where
/// the name is registered
/// @return return the name service the name registered at
function nameService() external view returns(address);
}
Rationale
To achieve a one-to-one mapping from the name to the NOA, where each NOA's address is derived from the name node, we must include the name node information in each NOA to reflect its name node ownership. The "name()" function can be used to retrieve this property of each NOA and enable reverse tracking to its name node. The "nameService()" function can get the name service contract address where the name is registered, to perform behaviors such as validation checks. Through these two methods, the NOA has the ability to track back to its actual owner who owns the name node.
Backwards Compatibility
The name registry interface is compatible with ERC-137.
Reference Implementation
Name Owned Account Creation
The NOA creation is done by a “factory” contract. The factory could be the name service itself and is expected to use CREATE2 (not CREATE) to create the NOA. NOAs should have identical initcode and factory contract in order to achieve deterministic preservation of address. The name node can be used as the salt to guarantee the bijection from name to its owned account.
Security Considerations
No security considerations were found.
Copyright
Copyright and related rights waived via CC0.
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all