Add EIP: Non-Sellable Tokens #6774

RaphaelHardFork · 2023-03-24T14:25:07Z

An extension of EIP-721 to replace transfers methods by a barter mecanism to prevent speculation and create non-sellable token (NST).

eth-bot · 2023-03-24T14:25:44Z

🛑 eip-review-bot failed for an unknown reason. Please see logs for more details, and report this issue at the eip-review-bot repository.

abcoathup · 2023-03-24T22:10:52Z

EIPS/eip-draft_nst.md

@@ -0,0 +1,262 @@
+---
+eip: <to be assigned>


Suggested change

eip: <to be assigned>

eip: 6774

ERC numbers are generally the PR number

abcoathup · 2023-03-24T22:11:41Z

EIPS/eip-draft_nst.md

+---
+eip: <to be assigned>
+title: Non-Sellable Tokens
+description: Prevent speculation on NFTs by replacing transfers by a barter mecanism


typo

Suggested change

description: Prevent speculation on NFTs by replacing transfers by a barter mecanism

description: Prevent speculation on NFTs by replacing transfers by a barter mechanism

github-actions · 2023-03-25T10:13:39Z

The commit 8bac7d6 (as a parent of 3bf2e80) contains errors.
Please inspect the Run Summary for details.

EIPS/eip-6774.md

Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>

SamWilsn · 2023-05-02T15:39:39Z

EIPS/eip-6774.md

+
+## Abstract
+
+This EIP is an extension of [ERC-721](./eip-721.md) to create non-sellable tokens (NST). It proposes a strong restriction on transfers in order to prevent speculation on token price while maintaining the possibility of transfers, transfers are performed in a barter way (send to receive or receive to send) in an ecosystem controlled by the creator.


I'd appreciate a tiny bit of technical detail about how this proposal prevents selling.

SamWilsn · 2023-05-02T15:40:13Z

EIPS/eip-6774.md

+
+## Motivation
+
+Interest for soulbound tokens (SBT) in the Ethereum community still growing since the V. Buterin idea publication (Soulbound, 2022-01-26), highlighting the non-transferability (non-)features to prevent, _in fine_, speculation of the token. While a lot of propositions emerged for implementation of SBT, the non-transferability is often too restrictive and requires a certain level of centralization, especially when users want to transfer a SBT between two owned accounts. Thus SBTs are way more fitted for account-bounded properties such as reputation, voting rights, privileges, ...


Please remove external links (yes, references by title and date are still external references 😉)

SamWilsn · 2023-05-02T15:40:54Z

EIPS/eip-6774.md

+
+## Motivation
+
+Interest for soulbound tokens (SBT) in the Ethereum community still growing since the V. Buterin idea publication (Soulbound, 2022-01-26), highlighting the non-transferability (non-)features to prevent, _in fine_, speculation of the token. While a lot of propositions emerged for implementation of SBT, the non-transferability is often too restrictive and requires a certain level of centralization, especially when users want to transfer a SBT between two owned accounts. Thus SBTs are way more fitted for account-bounded properties such as reputation, voting rights, privileges, ...


Suggested change

Interest for soulbound tokens (SBT) in the Ethereum community still growing since the V. Buterin idea publication (Soulbound, 2022-01-26), highlighting the non-transferability (non-)features to prevent, _in fine_, speculation of the token. While a lot of propositions emerged for implementation of SBT, the non-transferability is often too restrictive and requires a certain level of centralization, especially when users want to transfer a SBT between two owned accounts. Thus SBTs are way more fitted for account-bounded properties such as reputation, voting rights, privileges, ...

Interest for soulbound tokens (SBT) in the Ethereum community still growing since the V. Buterin idea publication (Soulbound, 2022-01-26), highlighting the non-transferability (non-)features to prevent, _in fine_, speculation of the token. While a lot of propositions emerged for implementation of SBT, the non-transferability is often too restrictive and requires a certain level of centralization, especially when users want to transfer a SBT between two owned accounts. Thus SBTs are way more fitted for account-bounded properties such as reputation, voting rights, and privileges.

SamWilsn · 2023-05-02T15:41:39Z

EIPS/eip-6774.md

+
+Interest for soulbound tokens (SBT) in the Ethereum community still growing since the V. Buterin idea publication (Soulbound, 2022-01-26), highlighting the non-transferability (non-)features to prevent, _in fine_, speculation of the token. While a lot of propositions emerged for implementation of SBT, the non-transferability is often too restrictive and requires a certain level of centralization, especially when users want to transfer a SBT between two owned accounts. Thus SBTs are way more fitted for account-bounded properties such as reputation, voting rights, privileges, ...
+
+In case of transferable items which cannot be sellable, SBTs can fit, but they require a strong level of centralization as transfer are restricted by the token creator (or the community in case of DAO managed SBT). Here some examples of possibles NSTs:


Suggested change

In case of transferable items which cannot be sellable, SBTs can fit, but they require a strong level of centralization as transfer are restricted by the token creator (or the community in case of DAO managed SBT). Here some examples of possibles NSTs:

In case of transferable items which cannot be sold, SBTs can fit, but they require a strong level of centralization as transfer are restricted by the token creator (or the community in case of DAO managed SBT). Here some examples of possible NSTs:

SamWilsn · 2023-05-02T15:42:25Z

EIPS/eip-6774.md

+1. UserA signs a message taking up the terms of the barter
+2. UserB accepts and concludes the barter by calling the `barter` function
+
+```mermaid


I can't promise this will render into anything useful. If it doesn't, please replace it with a rendered diagram (preferably SVG.)

SamWilsn · 2023-05-02T15:45:06Z

EIPS/eip-6774.md

+
+The value equivalence is so maintained by tokens creators as a whitelist, keeping these authorisations at the contract level is important and would help create a network of barterable NSTs.
+
+Based on value equivalence we leverage the game theory to enforce the non-sellability instead of stronger restrictions or centralization which would lead to higher code complexity and poor interoperability. Indeed, the strong counterpart at the transfer made NSTs highly illiquid to be subject to a sale on a marketplace or by OTC agreement.


Abbreviations should be expanded the first time they are used.

SamWilsn · 2023-05-02T15:45:55Z

EIPS/eip-6774.md

+
+## Reference Implementation
+
+[Implementations examples](../assets/eip-6774/) have been designed for this proposal.


Unfortunately our renderer doesn't like linking to directories, so you'll need to link to a specific file. One option that works fairly well for big reference implementations is creating a README.md and linking to that.

SamWilsn · 2023-05-02T15:46:19Z

assets/eip-6774/README.md

+
+## Tests
+
+Tests are written using [Foundry](https://book.getfoundry.sh/getting-started/installation), here is the list of tests:


Please remove external links.

SamWilsn · 2023-05-02T15:46:57Z

assets/eip-6774/test/ERC6774.t.sol

@@ -0,0 +1,391 @@
+// SPDX-License-Identifier: UNLICENSED


Please replace with an open source license, preferably CC0-1.0

SamWilsn · 2023-05-02T15:47:09Z

assets/eip-6774/test/Utils.t.sol

@@ -0,0 +1,172 @@
+// SPDX-License-Identifier: UNLICENSED


github-actions · 2023-09-14T00:16:27Z

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.

SamWilsn · 2023-10-25T22:06:15Z

I am closing this pull request because we are in the process of separating EIPs and ERCs into distinct repositories. Unfortunately, as far as we are aware, GitHub does not provide any tools to ease this migration, so every pull request will need to be re-opened manually.

As this is a PR to create / modify an ERC, I will kindly ask you to redirect this to the new repository at ethereum/ERCs. We have prepared a guide to help with the process.

If there is relevant history here, please link to this PR from the new pull request.

On behalf of the EIP Editors, I apologize for this inconvenience.

Add EIP: non-sellable tokens

8e54310

RaphaelHardFork requested a review from eth-bot as a code owner March 24, 2023 14:25

eth-bot changed the title ~~Add EIP: non-sellable tokens~~ Add EIP: Non-Sellable Tokens Mar 24, 2023

eth-bot added e-consensus Waiting on editor consensus e-review Waiting on editor to review labels Mar 24, 2023

github-actions bot added c-new Creates a brand new proposal s-draft This EIP is a Draft t-erc w-ci Waiting on CI to pass labels Mar 24, 2023

RaphaelHardFork added 2 commits March 24, 2023 15:53

fix rels-links, EIP references

29ca8d5

fix eip number and authors

089efb0

abcoathup reviewed Mar 24, 2023

View reviewed changes

file name, eip nb, disscussion link, ERC prefix

3e3e918

RaphaelHardFork changed the title ~~Add EIP: Non-Sellable Tokens~~ Add EIP-6774: Non-Sellable Tokens Mar 25, 2023

assets directory name changed

d3c7797

eth-bot changed the title ~~Add EIP-6774: Non-Sellable Tokens~~ Add EIP: Non-Sellable Tokens Mar 25, 2023

github-actions bot added w-ci Waiting on CI to pass and removed w-ci Waiting on CI to pass labels Mar 25, 2023

assets directory name changed

8bac7d6

DONALDSULLENDER previously approved these changes Mar 25, 2023

View reviewed changes

spelling mistakes

15ba91e

RaphaelHardFork dismissed DONALDSULLENDER’s stale review via 15ba91e April 5, 2023 07:58

github-actions bot removed the w-ci Waiting on CI to pass label Apr 5, 2023

lightclient requested changes Apr 14, 2023

View reviewed changes

EIPS/eip-6774.md Outdated Show resolved Hide resolved

EIPS/eip-6774.md Outdated Show resolved Hide resolved

EIPS/eip-6774.md Outdated Show resolved Hide resolved

RaphaelHardFork and others added 3 commits April 17, 2023 16:03

suggested rewording

210a83c

Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>

suggested rewording

19f6ef0

Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>

suggested rewording

b4567e7

Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>

poojaranjan mentioned this pull request Apr 18, 2023

EIP Editing Office Hour Meeting 15 ethcatherders/EIPIP#225

Closed

23 tasks

RaphaelHardFork mentioned this pull request May 2, 2023

EIP Editing Office Hour Meeting 16 ethcatherders/EIPIP#228

Closed

20 tasks

SamWilsn reviewed May 2, 2023

View reviewed changes

github-actions bot added the w-stale Waiting on activity label Sep 14, 2023

SamWilsn closed this Oct 25, 2023

RaphaelHardFork mentioned this pull request Jan 30, 2024

Add ERC: Non-Sellable Tokens ethereum/ERCs#226

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add EIP: Non-Sellable Tokens #6774

Add EIP: Non-Sellable Tokens #6774

RaphaelHardFork commented Mar 24, 2023

eth-bot commented Mar 24, 2023 •

edited

abcoathup Mar 24, 2023

abcoathup Mar 24, 2023

github-actions bot commented Mar 25, 2023

SamWilsn May 2, 2023

SamWilsn May 2, 2023

SamWilsn May 2, 2023

SamWilsn May 2, 2023

SamWilsn May 2, 2023

SamWilsn May 2, 2023

SamWilsn May 2, 2023

SamWilsn May 2, 2023

SamWilsn May 2, 2023

SamWilsn May 2, 2023

github-actions bot commented Sep 14, 2023

SamWilsn commented Oct 25, 2023

	description: Prevent speculation on NFTs by replacing transfers by a barter mecanism
	description: Prevent speculation on NFTs by replacing transfers by a barter mechanism


		## Abstract

		This EIP is an extension of [ERC-721](./eip-721.md) to create non-sellable tokens (NST). It proposes a strong restriction on transfers in order to prevent speculation on token price while maintaining the possibility of transfers, transfers are performed in a barter way (send to receive or receive to send) in an ecosystem controlled by the creator.


		## Motivation

		Interest for soulbound tokens (SBT) in the Ethereum community still growing since the V. Buterin idea publication (Soulbound, 2022-01-26), highlighting the non-transferability (non-)features to prevent, _in fine_, speculation of the token. While a lot of propositions emerged for implementation of SBT, the non-transferability is often too restrictive and requires a certain level of centralization, especially when users want to transfer a SBT between two owned accounts. Thus SBTs are way more fitted for account-bounded properties such as reputation, voting rights, privileges, ...


		Interest for soulbound tokens (SBT) in the Ethereum community still growing since the V. Buterin idea publication (Soulbound, 2022-01-26), highlighting the non-transferability (non-)features to prevent, _in fine_, speculation of the token. While a lot of propositions emerged for implementation of SBT, the non-transferability is often too restrictive and requires a certain level of centralization, especially when users want to transfer a SBT between two owned accounts. Thus SBTs are way more fitted for account-bounded properties such as reputation, voting rights, privileges, ...

		In case of transferable items which cannot be sellable, SBTs can fit, but they require a strong level of centralization as transfer are restricted by the token creator (or the community in case of DAO managed SBT). Here some examples of possibles NSTs:


		The value equivalence is so maintained by tokens creators as a whitelist, keeping these authorisations at the contract level is important and would help create a network of barterable NSTs.

		Based on value equivalence we leverage the game theory to enforce the non-sellability instead of stronger restrictions or centralization which would lead to higher code complexity and poor interoperability. Indeed, the strong counterpart at the transfer made NSTs highly illiquid to be subject to a sale on a marketplace or by OTC agreement.


		## Reference Implementation

		[Implementations examples](../assets/eip-6774/) have been designed for this proposal.


		## Tests

		Tests are written using [Foundry](https://book.getfoundry.sh/getting-started/installation), here is the list of tests:

Add EIP: Non-Sellable Tokens #6774

Add EIP: Non-Sellable Tokens #6774

Conversation

RaphaelHardFork commented Mar 24, 2023

eth-bot commented Mar 24, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Mar 25, 2023

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 Sep 14, 2023

SamWilsn commented Oct 25, 2023

eth-bot commented Mar 24, 2023 •

edited