-
Notifications
You must be signed in to change notification settings - Fork 5.4k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
57 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,57 @@ | ||
--- | ||
eip: <to be assigned> | ||
title: ENS as Token Holder | ||
description: An interface for holding tokens by ENS. | ||
author: Zainan Victor Zhou (@xinbenlv) | ||
discussions-to: <URL> | ||
status: Draft | ||
type: Standards Track | ||
category ERC | ||
created: 2022-07-12 | ||
requires: 137 | ||
--- | ||
|
||
## Abstract | ||
An interface for smart contract to become a holder of tokens by honoring ENS ownership. | ||
This specification supports ERC721 and ERC1155 and is expandable to future token standard or other standard. | ||
|
||
## Motivation | ||
Currently, if someone wants to receive token, they have to setup a wallet address, otherwise, | ||
the minter or transferer will not be able to transfer or mint for that token. | ||
|
||
By creating smart contract that conform to this interface specification, we can decouple | ||
the transfer of ownership from the existance of wallet addresses. | ||
|
||
|
||
## Specification | ||
|
||
1. Any conforming smart contract must conform to `ERC721Recever` in [EIP-721](./eip-721.md) and `ERC1155Receiver` in [EIP-1155](./eip-1155.md). | ||
|
||
|
||
```solidity | ||
interface IERC_ENS_AS_HOLDER is ERC721Receiver, ERC1155Receiver { | ||
} | ||
``` | ||
|
||
2. | ||
|
||
|
||
|
||
## Rationale | ||
The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. | ||
|
||
## Backwards Compatibility | ||
No backward compatibility aware of. | ||
|
||
|
||
## Test Cases | ||
Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. If the test suite is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`. | ||
|
||
## Reference Implementation | ||
An optional section that contains a reference/example implementation that people can use to assist in understanding or implementing this specification. If the implementation is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`. | ||
|
||
## Security Considerations | ||
All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers. | ||
|
||
## Copyright | ||
Copyright and related rights waived via [CC0](../LICENSE.md). |