ERC-6538: Stealth Meta-Address Registry

A canonical contract for entities to register stealth meta-addresses directly or through a third party using signatures.

Metadata

Status: FinalStandards Track: ERCCreated: 2023-01-24

Authors

Matt Solomon (@mds1), Toni Wahrstätter (@nerolation), Ben DiFrancesco (@apbendi), Vitalik Buterin (@vbuterin), Gary Ghayrat (@garyghayrat)

Requires

EIP-712, EIP-1271, EIP-5564

Links

GitHub page Discussion on Ethereum Magicians

Abstract

This specification defines a standardized way of storing and retrieving an entity's stealth meta-address, by extending ERC-5564. An entity may register their stealth meta-address directly. A third party can also register on behalf of an entity using a valid EIP-712 or EIP-1271 signature. Once registered, the stealth meta-address for the entity can be retrieved by any smart contract or user. One can use the stealth meta-address with generateStealthAddress specified in ERC-5564 to send assets to the generated stealth address without revealing the entity's address.

Motivation

The standardization of stealth address generation holds the potential to greatly enhance the privacy capabilities of Ethereum by enabling the recipient of a transfer to remain anonymous when receiving an asset. By introducing a central smart contract for users to store their stealth meta-addresses, EOAs and contracts can programmatically engage in stealth interactions using a variety of stealth address schemes.

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.

This contract defines an ERC6538Registry that stores the stealth meta-address for entities. These entities may be identified by an address, ENS name, or other identifier. This MUST be a singleton contract, with one instance per chain.

The contract is specified below. A one byte integer is used to identify the stealth address scheme. This integer is used to differentiate between different stealth address schemes. This ERC outlines schemeId 1 as the SECP256k1 curve cryptographic scheme with view tags, as specified in ERC-5564.

The interface for this contract is defined below:

Deployment Method

The ERC6538Registry contract is deployed at 0x6538E6bf4B0eBd30A8Ea093027Ac2422ce5d6538 using CREATE2 via the deterministic deployer at 0x4e59b44847b379578588920ca78fbf26c0b4956c with a salt of 0x7cac4e512b1768c627c9e711c7a013f1ad0766ef5125c59fb7161dade58da078.

Rationale

Having a central smart contract for registering stealth meta-addresses has several benefits:

It guarantees interoperability with other smart contracts, as they can easily retrieve and utilize the registered stealth meta-addresses. This enables applications such as ENS or Gnosis Safe to use that information and integrate stealth addresses into their services.
It ensures that users are not dependent on off-chain sources to retrieve a user's stealth meta-address.
Registration of a stealth meta-address in this contract provides a standard way for users to communicate that they're ready to participate in stealth interactions.
By deploying the registry as a singleton contract, multiple projects can access the same set of stealth meta-addresses, contributing to improved standardization.

Backwards Compatibility

This EIP is fully backward compatible.

Reference Implementation

You can find an implementation of the ERC6538Registry contract here and the interface IERC6538Registry.sol here.

Security Considerations

In the event of a compromised private key, the registrant should promptly un-register from the stealth key registry to prevent loss of future funds sent to the compromised account.