HomeEIPs
EIPsERC-4972
ERC-4972

Name-Owned Account

Name-Owned Account for Social Identity
DraftStandards Track: ERC
Created: 2022-04-04
Requires: EIP-137
Shu Dong (@dongshu2013), Qi Zhou (@qizhou), Zihao Chen (@zihaoccc)
DiscussionsOriginal linkEdit
1 min read

The ERC-4972 proposal 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. This smart contract account is called a Name-Owned Account (NOA) and has a human-readable name defined by ERC-137, an owned account whose address is derived from the name, and owner(s) of the name that can deploy and manipulate the owned account. The NOA allows for holding 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 proposal also includes an interface for wallet implementers to construct a custom Sign-In With Ethereum user interface and supporting internationalization. The rationale behind the proposal is 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. The design goals of the proposal are human-friendly, simple to implement, secure, machine-readable, and extensible. The technical decisions include using ERC-191 (Signed Data Standard) over EIP-712 (Ethereum typed structured data hashing and signing).

Video
Anyone may contribute to propose contents.
Go propose
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 and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose
Adopted by projects
Anyone may contribute to propose contents.
Go propose

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
Serve Ethereum Builders, Scale the Community.
Resources
GitHub
Supported by