ERC-4972: Name-Owned Account

Name-Owned Account for Social Identity

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.

Citation

Please cite this document as:

Shu Dong (@dongshu2013), Qi Zhou (@qizhou), Zihao Chen (@zihaoccc), "ERC-4972: Name-Owned Account [DRAFT]," Ethereum Improvement Proposals, no. 4972, April 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-4972.