Add EIP-1238: Non-transferable Token Standard #5617

ra-phael · 2022-09-07T17:10:36Z

EIP for #1238

eth-bot · 2022-09-07T17:11:43Z

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

(fail) eip-1238.md

classification
`newEIPFile`

File with name EIPS/eip-1238.md is new and new files must be reviewed
This PR requires review from one of [@axic, @SamWilsn, @Pandapip1]

ra-phael · 2022-09-08T09:52:35Z

@Pandapip1 isn't it possible to keep the original EIP number? 🙏

It's not taken, would be simpler in terms of historical continuity, not to mention all the renaming in:

Pandapip1 · 2022-09-08T13:25:43Z

isn't it possible to keep the original EIP number? 🙏

If you wish to publish this as Withdrawn, then sure. Otherwise, no.

ra-phael · 2022-09-11T20:16:36Z

@Pandapip1 Why not?
The following comment suggests that this number can be kept with the approval of @nicola, the original author of the issue, which I have:
#4966 (comment)

Pandapip1 · 2022-09-15T13:38:09Z

Due to a recent incident (EIP-5000), "who gets EIP numbers" is currently a process in which editors are unlikely to make exceptions.

nicola · 2022-09-22T05:03:19Z

I approve the re-use of the original EIP number.

Pandapip1 · 2022-09-22T13:36:32Z

Again, EIP editors are responsible for assigning numbers. I will not assign EIP-1238, but I'll CC @SamWilsn @gcolvin @lightclient @axic in case they might.

SamWilsn · 2022-10-05T14:40:24Z

I am fine with resurrecting the original EIP number. This PR is taking the old format (issue) and turning it into a markdown file, and adding authors. I'd probably recommend adding @nicola's github username.

You'll still need to fix the eipw errors though.

ra-phael · 2022-10-14T09:34:15Z

Thank you @SamWilsn. I added Nicola's github username and fixed the EIP validation errors.

xinbenlv · 2022-10-15T18:57:22Z

EIPS/eip-1238.md

+- Statements: more broadly, any statement that is issued or signed by a contract, a dao, a single user that requires to be on-chain.
+- Subscription: badges can represent the validity of a paid subscription.
+
+Additionally, this standard could be used as a primitive for Soulbound tokens, whereby the recovery of a Soul would be done by obtaining signatures from co-owners of tokens with the same id.


Since there has been at least 4 attempts to propose a soul-bound / non-transferable NFT, I'd also suggest you add to your motivation and rationale on what this ERC has better merit than other competing ERCs e.g. https://eips.ethereum.org/EIPS/eip-5114
https://eips.ethereum.org/EIPS/eip-5633

Good point @xinbenlv! I'm familiar with the other EIPs, but they either build on previous standards like EIP-1155 as extensions which means unecessary transfer functions or propose different designs leading to a different set of features. I added more in motivation: a7f94be

SamWilsn · 2022-11-04T22:10:48Z

EIPS/eip-1238.md

+ /**
+ * @dev Emitted when `amount` tokens of token type `id` are minted to `to` by `minter`.
+ */
+ event MintSingle(address indexed minter, address indexed to, uint256 indexed id, uint256 amount);
+
+ /**
+ * @dev Equivalent to multiple {MintSingle} events, where `minter` and `to` is the same for all token types.
+ */
+ event MintBatch(address indexed minter, address indexed to, uint256[] ids, uint256[] amounts);


Why do you have both MintSingle and MintBatch? Couldn't MintBatch handle both cases?

If there's a reason, please add it to the EIP's rationale section.

Good point, I like how it makes the interface simpler. I also applied the same reasoning to the events related to burning.

EIPS/eip-1238.md

SamWilsn · 2022-11-04T22:15:09Z

EIPS/eip-1238.md

+```solidity
+interface IERC1238Holdable is IERC1238 {
+ /**
+ * @dev Event emitted when `from` entrusts `to` with `amount` of tokens with token `id`.
+ */
+ event Entrust(address from, address to, uint256 indexed id, uint256 amount);
+
+ /**
+ * @dev Event emitted when tokens are burnt and the holder fails to acknowledge the burn.
+ */
+ event BurnAcknowledgmentFailed(address holder, address burner, address from, uint256 indexed id, uint256 amount);
+
+ /**
+ * @dev Returns the balance of a token holder for a given `id`.
+ */
+ function heldBalance(address holder, uint256 id) external view returns (uint256);
+
+ /**
+ * @dev Lets sender entrusts `to` with `amount`
+ * of tokens which gets transferred between their respective balances
+ * of tokens held.
+ */
+ function entrust(
+ address to,
+ uint256 id,
+ uint256 amount
+ ) external;
+}
+```


This holdable extension needs a lot more explanation. You should define the concepts, the expected flow, etc.

I added more explanations in a17e69d

github-actions · 2022-11-24T00:20:39Z

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

ra-phael · 2022-12-05T16:00:39Z

@SamWilsn Thank you for your feedback! And sorry for the delay in addressing it. It's ready for re-review.

SamWilsn

How would you feel about slimming this EIP down a bit, and moving the extensions into their own proposals?

SamWilsn · 2022-12-09T15:07:59Z

EIPS/eip-1238.md

+
+## Abstract
+
+A _badge_ or non-transferable token (_NTT_) is a token that cannot be transferred once assigned. Badges can be accumulated through time and put at stake. Simply speaking, badges are statements about a public key: they can be quantitative (e.g. reputation, experience) or qualitative (badges, titles).


Badges can be accumulated through time and put at stake.

I am not sure what "put at stake" means here. Is this some kind of staking mechanism, or are you talking about the badge issuer's reputation, or something else entirely?

SamWilsn · 2022-12-09T15:10:33Z

EIPS/eip-1238.md

+
+A _badge_ or non-transferable token (_NTT_) is a token that cannot be transferred once assigned. Badges can be accumulated through time and put at stake. Simply speaking, badges are statements about a public key: they can be quantitative (e.g. reputation, experience) or qualitative (badges, titles).
+
+The Non-Transferable Token standard defines a set of standard APIs allowing the identification of statements (called badges) attributed to a public key, such that different dapps and smart contract can use to filter users or to provide user with different badges different experiences. More importantly, this standard defines a way for which users can put their badges at stake. Badges cannot be transferred but can be lost (after staking) or can expire.


Couple grammar and stylistic changes:

Suggested change

The Non-Transferable Token standard defines a set of standard APIs allowing the identification of statements (called badges) attributed to a public key, such that different dapps and smart contract can use to filter users or to provide user with different badges different experiences. More importantly, this standard defines a way for which users can put their badges at stake. Badges cannot be transferred but can be lost (after staking) or can expire.

The Non-Transferable Token standard defines a set of APIs that identify statements (called badges) attributed to a public key, such that different dapps and smart contracts can filter users or tailor experiences based on what badges a user has. More importantly, this standard defines a way for users to put their badges at stake. Badges cannot be transferred but can be lost (after staking) or can expire.

SamWilsn · 2022-12-09T15:12:02Z

EIPS/eip-1238.md

+
+## Motivation
+
+The idea is to have tokens that once assigned cannot be transferred (like reputation) and that can be used by websites, or contracts to make users perform some actions. For example, if a user accumulates paper submissions at conferences, then they can use their paper badges to request grants. It's important that they can never share these badges.


I don't think a badge can force a user to do something :P

Suggested change

The idea is to have tokens that once assigned cannot be transferred (like reputation) and that can be used by websites, or contracts to make users perform some actions. For example, if a user accumulates paper submissions at conferences, then they can use their paper badges to request grants. It's important that they can never share these badges.

The idea is to have tokens that once assigned cannot be transferred (like reputation) and that can be used by websites, or contracts to allow users to perform some actions. For example, if a user accumulates paper submissions at conferences, then they can use their paper badges to request grants. It's important that they can never share these badges.

SamWilsn · 2022-12-09T15:17:29Z

EIPS/eip-1238.md

+
+The idea is to have tokens that once assigned cannot be transferred (like reputation) and that can be used by websites, or contracts to make users perform some actions. For example, if a user accumulates paper submissions at conferences, then they can use their paper badges to request grants. It's important that they can never share these badges.
+
+This is the equivalent of a variety of other use cases


Suggested change

This is the equivalent of a variety of other use cases

This is the equivalent of a variety of other use cases:

SamWilsn · 2022-12-09T15:20:08Z

EIPS/eip-1238.md

+ *
+ * Requirements:
+ *
+ * - `account` cannot be the zero address.


Coming back to this, I think you should be more specific about what behaviour you expect. Perhaps:

Suggested change

* - `account` cannot be the zero address.

* - `balanceOf(address(0x0))` MUST revert.

SamWilsn · 2022-12-09T15:21:55Z

EIPS/eip-1238.md

+
+ /**
+ * @dev Returns the balance of `account` for a batch of token `ids`.
+ *


You might want to repeat the non-zero requirement here.

SamWilsn · 2022-12-09T15:36:50Z

EIPS/eip-1238.md

+}
+```
+
+When burning tokens, implementers MUST try to call the `onBurn` function if the holder is a smart contract. This allows smart contract token holders to get notified when tokens that they hold are being burnt and gives them a chance to react and handle the situation as they see fit.


I would suggest expanding on what "try to call" means in this context. If onBurn reverts, is the token contract permitted to continue burning? If onBurn returns false?

SamWilsn · 2022-12-09T15:39:27Z

EIPS/eip-1238.md

+ * @dev This function is called when tokens with id `id` are burnt.
+ * Returns `true` as a sign that the burn was acknowledged and processed.
+ */
+ function onBurn(uint256 id, uint256 amount) external returns (bool);


Is there an argument for making this payable?

SamWilsn · 2022-12-09T15:41:45Z

EIPS/eip-1238.md

+}
+```
+
+Smart contracts holding tokens MUST implement the following interface:


This standard really can't place requirements on smart contracts that don't claim to implement it. I'd reword this to something like:

Smart contracts that are intended to hold NTTs SHOULD implement the following interface to receive burn notifications:

SamWilsn · 2022-12-09T15:43:49Z

EIPS/eip-1238.md

+
+- When minting tokens to Alice's address A, address A is the token owner but also the initial token holder. Alice can then call the `entrust` function to entrust address B with her tokens. Address B becomes the token holder while Alice remains the token owner.
+- Only one address can hold specific tokens at a time.
+- A token holder can transfer tokens to another holder. Still, the important point is that this does not change ownership of the tokens.


Should this be:

Suggested change

- A token holder can transfer tokens to another holder. Still, the important point is that this does not change ownership of the tokens.

- A token holder can entrust tokens to another holder. Still, the important point is that this does not change ownership of the tokens.

?

github-actions · 2022-12-24T00:14:41Z

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

github-actions · 2023-02-04T00:18:15Z

This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.

ra-phael added 2 commits September 7, 2022 16:26

add draft for EIP-1238

21604ad

fix category

e19df61

ra-phael requested a review from eth-bot as a code owner September 7, 2022 17:10

github-actions bot added c-new Creates a brand new proposal s-draft This EIP is a Draft t-erc labels Sep 7, 2022

ra-phael and others added 2 commits September 7, 2022 18:16

fix EIP references

cfea1fd

Fix a few major issues

144dede

Pandapip1 changed the title ~~Add EIP-1238: Non-transferable Token Standard~~ Add EIP-5617: Non-transferable Token Standard Sep 7, 2022

poojaranjan mentioned this pull request Oct 4, 2022

EIPIP Meeting 66 Agenda ethcatherders/EIPIP#181

Closed

10 tasks

ra-phael added 4 commits October 14, 2022 09:57

Merge branch 'ethereum:master' into eip-1238

31d37d3

fix eip validation errors

6932730

Revert to 1238 eip number

f550072

add link for EIP-712

2c6b810

xinbenlv reviewed Oct 15, 2022

View reviewed changes

Add unique value proposition

a7f94be

SamWilsn reviewed Nov 4, 2022

View reviewed changes

github-actions bot added the w-stale Waiting on activity label Nov 24, 2022

nicola previously approved these changes Nov 25, 2022

View reviewed changes

github-actions bot removed the w-stale Waiting on activity label Nov 27, 2022

address feedback

a17e69d

ra-phael dismissed nicola’s stale review via a17e69d December 5, 2022 15:48

formatting

8904cbd

SamWilsn changed the title ~~Add EIP-5617: Non-transferable Token Standard~~ Add EIP-1238: Non-transferable Token Standard Dec 9, 2022

SamWilsn reviewed Dec 9, 2022

View reviewed changes

github-actions bot added the w-stale Waiting on activity label Dec 24, 2022

github-actions bot closed this Feb 4, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add EIP-1238: Non-transferable Token Standard #5617

Add EIP-1238: Non-transferable Token Standard #5617

ra-phael commented Sep 7, 2022 •

edited

Loading

eth-bot commented Sep 7, 2022 •

edited

Loading

ra-phael commented Sep 8, 2022 •

edited

Loading

Pandapip1 commented Sep 8, 2022

ra-phael commented Sep 11, 2022

Pandapip1 commented Sep 15, 2022

nicola commented Sep 22, 2022

Pandapip1 commented Sep 22, 2022

SamWilsn commented Oct 5, 2022

ra-phael commented Oct 14, 2022

xinbenlv Oct 15, 2022

ra-phael Oct 20, 2022

SamWilsn Nov 4, 2022

ra-phael Dec 5, 2022

SamWilsn Nov 4, 2022

ra-phael Dec 5, 2022

github-actions bot commented Nov 24, 2022

ra-phael commented Dec 5, 2022

SamWilsn left a comment

SamWilsn Dec 9, 2022

SamWilsn Dec 9, 2022

SamWilsn Dec 9, 2022

SamWilsn Dec 9, 2022

SamWilsn Dec 9, 2022

SamWilsn Dec 9, 2022

SamWilsn Dec 9, 2022

SamWilsn Dec 9, 2022

SamWilsn Dec 9, 2022

SamWilsn Dec 9, 2022

github-actions bot commented Dec 24, 2022

github-actions bot commented Feb 4, 2023


		## Abstract

		A _badge_ or non-transferable token (_NTT_) is a token that cannot be transferred once assigned. Badges can be accumulated through time and put at stake. Simply speaking, badges are statements about a public key: they can be quantitative (e.g. reputation, experience) or qualitative (badges, titles).


		A _badge_ or non-transferable token (_NTT_) is a token that cannot be transferred once assigned. Badges can be accumulated through time and put at stake. Simply speaking, badges are statements about a public key: they can be quantitative (e.g. reputation, experience) or qualitative (badges, titles).

		The Non-Transferable Token standard defines a set of standard APIs allowing the identification of statements (called badges) attributed to a public key, such that different dapps and smart contract can use to filter users or to provide user with different badges different experiences. More importantly, this standard defines a way for which users can put their badges at stake. Badges cannot be transferred but can be lost (after staking) or can expire.


		## Motivation

		The idea is to have tokens that once assigned cannot be transferred (like reputation) and that can be used by websites, or contracts to make users perform some actions. For example, if a user accumulates paper submissions at conferences, then they can use their paper badges to request grants. It's important that they can never share these badges.


		The idea is to have tokens that once assigned cannot be transferred (like reputation) and that can be used by websites, or contracts to make users perform some actions. For example, if a user accumulates paper submissions at conferences, then they can use their paper badges to request grants. It's important that they can never share these badges.

		This is the equivalent of a variety of other use cases

	* - `account` cannot be the zero address.
	* - `balanceOf(address(0x0))` MUST revert.

	- A token holder can transfer tokens to another holder. Still, the important point is that this does not change ownership of the tokens.
	- A token holder can entrust tokens to another holder. Still, the important point is that this does not change ownership of the tokens.

Add EIP-1238: Non-transferable Token Standard #5617

Add EIP-1238: Non-transferable Token Standard #5617

Conversation

ra-phael commented Sep 7, 2022 • edited Loading

eth-bot commented Sep 7, 2022 • edited Loading

(fail) eip-1238.md

ra-phael commented Sep 8, 2022 • edited Loading

Pandapip1 commented Sep 8, 2022

ra-phael commented Sep 11, 2022

Pandapip1 commented Sep 15, 2022

nicola commented Sep 22, 2022

Pandapip1 commented Sep 22, 2022

SamWilsn commented Oct 5, 2022

ra-phael commented Oct 14, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Nov 24, 2022

ra-phael commented Dec 5, 2022

SamWilsn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Dec 24, 2022

github-actions bot commented Feb 4, 2023

ra-phael commented Sep 7, 2022 •

edited

Loading

eth-bot commented Sep 7, 2022 •

edited

Loading

ra-phael commented Sep 8, 2022 •

edited

Loading