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.
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.
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.
An NOA has
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 │
└───────────────┘ └───────────┘ └───────────────┘
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);
}
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.
The name registry interface is compatible with ERC-137.
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.
No security considerations were found.
Copyright and related rights waived via CC0.