# Discussion of Soulbound Token Standard

**URL:** https://gov.near.org/t/discussion-of-soulbound-token-standard/31223
**Category:** Standards
**Tags:** proposals, development
**Created:** [November 17, 2022, 1:51pm UTC](https://gov.near.org/t/discussion-of-soulbound-token-standard/31223 "2022-11-17T13:51:30Z")
**Posts on this page:** 10
**Page:** 1

<div class="post-metadata">

### Author: ![JasperTimm](https://dub1.discourse-cdn.com/flex005/user_avatar/gov.near.org/jaspertimm/32/24553_2.png) [@JasperTimm](https://gov.near.org/u/JasperTimm)
#### Post date: [November 17, 2022, 1:51pm UTC](https://gov.near.org/t/discussion-of-soulbound-token-standard/31223/1 "2022-11-17T13:51:30Z")

</div>

Hi all,

Creating this topic to coordinate efforts on a NEP for Soulbound Tokens (previously non-transferable NFTs). Hoping to form a (rough) consensus here on some key decisions before continuing with the NEP itself.

Here are some important links for those unfamiliar to catch up on the history:

- Old NEAR Gov post on non-transferable NFTS: [Non-Transferable NFT Standard](http://gov.near.org/t/non-transferable-nft-standard/18227)
- NEP-359 for non-transferable NFTS which was rejected: [https://github.com/near/NEPs/pull/359](https://github.com/near/NEPs/pull/359)
- Recording of meeting for NEP-359 with outcomes: [Contract Standards Working Group Meeting (August 22, 2022) - YouTube](https://youtu.be/6Tok9_iwtYk)

Importantly I should note there is an outstanding NEP for SBTs, but it hasn’t seen a lot of activity yet: [feat: adding soulbound token by robert-zaremba · Pull Request #393 · near/NEPs · GitHub](https://github.com/near/NEPs/pull/393)

I’m not trying to limit discussion, but in an effort to expedite this entire process I have a proposal that I’m hoping we could focus on first:

Given that the biggest concern with the previous NEP (359) was the confusion for indexers with standard NFTs, we would rename anything ‘nft’ with ‘sbt’. All else in the previous NEP-359 would remain the same.

@frol @nategeier - feel free to tag others that you think should be part of the discussion.

---

<div class="post-metadata">

### Author: ![Alpar\_NEAR](https://dub1.discourse-cdn.com/flex005/user_avatar/gov.near.org/alpar_near/32/43440_2.png) [@Alpar\_NEAR](https://gov.near.org/u/Alpar_NEAR)
#### Post date: [November 17, 2022, 2:51pm UTC](https://gov.near.org/t/discussion-of-soulbound-token-standard/31223/2 "2022-11-17T14:51:27Z")

</div>

Hey,

I can’t really contribute to the discussion, but I wanted to voice my appreciation for the effort of reviving the conversation around this, and thank you for providing links for context!

---

<div class="post-metadata">

### Author: ![minorityprogrammers](https://dub1.discourse-cdn.com/flex005/user_avatar/gov.near.org/minorityprogrammers/32/23837_2.png) [@minorityprogrammers](https://gov.near.org/u/minorityprogrammers)
#### Post date: [November 18, 2022, 3:54am UTC](https://gov.near.org/t/discussion-of-soulbound-token-standard/31223/3 "2022-11-18T03:54:11Z")

</div>

> [@JasperTimm](#):
>
> Non-Transferable NFT Standard

**Recap of past discussions and comments made there**

Why last implementation was rejected as a NEP

- 
  - the reference implementation does not solve non transferability

- there is no point in implementing non transferability if it cannot hold this property
- will break prior ecosystem implementation, need to define availability of transfer, mint and burn standards (functions named the same)
- discoverability issue, difficult to tell apart from NEP 171
- burning not defined, so could be a SPAM NFT
- burn method shouldn’t be defined by this standard and should be defined elsewhere

Additionally in order to prevent spam NFTs, there should be some type of accept/approval function, and a way to discard such a NFT. There is still the issue of transfering the wallets. Maybe there can be a clause discarding the NFT in the event of adding a full access key.

@starpause also mentioned about using DAO’s to facilitate recovery mechanisms for SBTs.

Also think this is a topic the new ZK community group could get involved in.

---

<div class="post-metadata">

### Author: ![nategeier](https://dub1.discourse-cdn.com/flex005/user_avatar/gov.near.org/nategeier/32/182_2.png) [@nategeier](https://gov.near.org/u/nategeier)
#### Post date: [November 22, 2022, 11:02am UTC](https://gov.near.org/t/discussion-of-soulbound-token-standard/31223/4 "2022-11-22T11:02:19Z")

</div>

Great, also could take a hint from ETH where they have a locked and unlock method for SBT.

Could see a contract where the contract owners have the authority to lock the NFT or unlock it if say the user wanted to transfer it to another personal account or soul bound it for a particular period of time [EIP-5192: Minimal Soulbound NFTs](https://eips.ethereum.org/EIPS/eip-5192)

---

<div class="post-metadata">

### Author: ![robert](https://dub1.discourse-cdn.com/flex005/user_avatar/gov.near.org/robert/32/73_2.png) [@robert](https://gov.near.org/u/robert)
#### Post date: [November 24, 2022, 2:50am UTC](https://gov.near.org/t/discussion-of-soulbound-token-standard/31223/5 "2022-11-24T02:50:38Z")

</div>

@JasperTimm Thanks for creating the thread. We created few proof of concept related to [feat: adding soulbound token by robert-zaremba · Pull Request #393 · near/NEPs · GitHub](https://github.com/near/NEPs/pull/393)

The idea of my work in NEP-393 is to create a robust standard for SBT. It covers concepts of: recoverability, account transferrability (which involves blocking / blacklisting the account from which we transfer the Soul) and algebraic operations on SBT sets. All of that is described in our hackathon submission, where we use SBTs to design a proof of humanity protocol: [i-am-human.app | Devpost](https://devpost.com/software/i-am-human-app)

We are integrating this concept into NDC Governance proposal, which requires the proof of humanity and builds up on the concept of web3 Soul (“Decentralized Society: Finding Web3’s Soul”).

---

<div class="post-metadata">

### Author: ![minorityprogrammers](https://dub1.discourse-cdn.com/flex005/user_avatar/gov.near.org/minorityprogrammers/32/23837_2.png) [@minorityprogrammers](https://gov.near.org/u/minorityprogrammers)
#### Post date: [November 25, 2022, 8:58am UTC](https://gov.near.org/t/discussion-of-soulbound-token-standard/31223/6 "2022-11-25T08:58:20Z")

</div>

In the DAO builder group, @starpause suggested the idea of Community Bound Tokens. Soul bound tokens that are based on an issuer since we are trusting an authority to issue such badges. Such an authority rather than an individual should be a DAO. He mentioned that Illia and Vitalik that a recovery mechanism is needed and such a recovery mechanism would be suitable for a DAO to manage. Additionally a burn mechanism where an individual or a DAO can revoke such a nft would be a way for an individual to not get stuck w a badge or for any bad actors that a community has deemed unworthy of such nft. I think this combined with nft seats from DAOs and groups in DAOs gives opportunity for granular permissioning through NFTs for DAOs. There is still the issue of a full access key being transferred in order to transfer a NFT, however this problem persists with giving a wallet private key with a sbt inside. However rotating keys on NEAR makes this issue more prevalent

---

<div class="post-metadata">

### Author: ![robert](https://dub1.discourse-cdn.com/flex005/user_avatar/gov.near.org/robert/32/73_2.png) [@robert](https://gov.near.org/u/robert)
#### Post date: [November 28, 2022, 7:53pm UTC](https://gov.near.org/t/discussion-of-soulbound-token-standard/31223/7 "2022-11-28T19:53:48Z")

</div>

We can’t enforce that DAO must be issuer of a SBT. The standard must be flexible.

However, in the proposal we created we also suggest, that a [DAO or a smart contract is a good option](https://github.com/near/NEPs/pull/393/files#diff-a2d22b08974dd22107a037e2351d1e191758ec4abec3ddb7c8df27a259cf1821R29).

---

<div class="post-metadata">

### Author: ![minorityprogrammers](https://dub1.discourse-cdn.com/flex005/user_avatar/gov.near.org/minorityprogrammers/32/23837_2.png) [@minorityprogrammers](https://gov.near.org/u/minorityprogrammers)
#### Post date: [December 14, 2022, 3:27pm UTC](https://gov.near.org/t/discussion-of-soulbound-token-standard/31223/8 "2022-12-14T15:27:01Z")

</div>

What are your thoughts on EIP-5484, Consensual Soul Bound Tokens where the issuers and receiver need to agree on who can burn a token? [EIP-5484: Consensual Soulbound Tokens](https://eips.ethereum.org/EIPS/eip-5484)

---

<div class="post-metadata">

### Author: ![robert](https://dub1.discourse-cdn.com/flex005/user_avatar/gov.near.org/robert/32/73_2.png) [@robert](https://gov.near.org/u/robert)
#### Post date: [December 14, 2022, 10:44pm UTC](https://gov.near.org/t/discussion-of-soulbound-token-standard/31223/9 "2022-12-14T22:44:58Z")

</div>

In my proposal, this is not part of the standard. Burning mechanism, and the function interface / arguments, must be decided by the particular SBT implementation, based on what makes the best sense.

---

<div class="post-metadata">

### Author: ![frado](https://dub1.discourse-cdn.com/flex005/user_avatar/gov.near.org/frado/32/8167_2.png) [@frado](https://gov.near.org/u/frado)
#### Post date: [February 6, 2023, 3:30pm UTC](https://gov.near.org/t/discussion-of-soulbound-token-standard/31223/10 "2023-02-06T15:30:38Z")

</div>

Hello @Illuminati ,

This great Topic, remember our conversation.

Have a Nice day
