Add ERC: Non-Transferable Token by Vantana1995 · Pull Request #1479 · ethereum/ERCs

Vantana1995 · 2026-01-20T06:29:16Z

Summary

This PR proposes EIP-8129: Non-Transferable Token Standard - a minimal standard for tokens that are permanently bound to an address.

Description

Introduces a dedicated interface for non-transferable (Soulbound) tokens that eliminates transfer functionality by design, rather than extending ERC-721 and blocking transfers. The standard:

Defines tokens as non-transferable through interface design (no transfer functions)
Reduces bytecode bloat by ~80% compared to ERC-721 extensions
Provides semantic clarity - tokens that cannot be transferred vs tokens that block transfers
Includes only essential operations: mint(), burn(), ownerOf()
Requires ERC-721 Metadata interface for wallet/indexer compatibility

This approach addresses architectural mismatches in existing Soulbound implementations (ERC-5192, ERC-4973, ERC-5484) that inherit unused transfer infrastructure.

eip-review-bot · 2026-01-20T06:29:41Z

File `ERCS/erc-8129.md`

Requires 1 more review from Editors: @g11tech, @jochem-brouwer, @samwilsn, @xinbenlv

abcoathup · 2026-01-21T01:24:20Z

@@ -0,0 +1,313 @@
+---
+eip: <to be assigned>
+title: Non-Transferable Token Standard


Suggested change

title: Non-Transferable Token Standard

title: Non-Transferable Token

Standard is superfluous in an ERC title

abcoathup · 2026-01-21T01:25:07Z

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


Suggested change

eip: <to be assigned>

eip: 8129

Assigning next sequential EIP/ERC/RIP number.
Numbers are assigned by editors & associates.

Please also update the filename.

abcoathup · 2026-01-21T01:27:08Z

+title: Non-Transferable Token Standard
+description: A minimal standard for tokens that are permanently bound to an address
+author: Ivan Zemko (@Vantana1995)
+discussions-to: https://ethereum-magicians.org/t/soulbound-nft-as-separate-standard/27407


Suggested change

discussions-to: https://ethereum-magicians.org/t/soulbound-nft-as-separate-standard/27407

discussions-to: https://ethereum-magicians.org/t/erc-8129-non-transferable-token/27407

Updated Eth Magicians with assigned number & title

Vantana1995 · 2026-02-12T18:58:33Z

@abcoathup what is the next steps, how to merge it to the main >?

Vantana1995

Review

SamWilsn · 2026-07-20T14:21:32Z

+---
+eip: 8129
+title: Non-Transferable Token
+description: A minimal interface for tokens that are permanently bound to an address


[...] minimal [..]

Minimal is a very subjective term and doesn't add much information to your description. It isn't a requirement, but I'd recommend trying to use terms that differentiate your proposal more clearly.

SamWilsn · 2026-07-20T14:22:49Z

+
+## Abstract
+
+This EIP proposes a minimal standard for non-transferable tokens (commonly known as "Soulbound tokens"). Unlike existing approaches that extend [ERC-721](./eip-721.md) and disable transfer functionality, this standard defines tokens that are non-transferable by design, eliminating transfer-related functions entirely from the interface.


Your abstract is relying too heavily on other soulbound token standards that the audience may not have read yet. Imagine if your proposal became the non-transferable token standard, but it didn't actually explain what a non-transferable token is or what it's for.

SamWilsn · 2026-07-20T14:25:38Z

+
+4. **Not Truly Non-Transferable**: Existing implementations either block transfers through restrictions or allow consensual movement between addresses. In both cases, the token is not fundamentally bound to a single address - it's restricted from free transfer or requires consent to move.
+
+Non-transferable tokens represent credentials, achievements, certifications, memberships, and identity attestations - assets that by their nature should be permanently bound to their owner. These use cases deserve a dedicated standard that explicitly communicates non-transferability through the absence of transfer functions, not their restriction.


This paragraph is, in my opinion, more important than the comparisons to other soulbound standards. You need to sell the reader on the idea of soulbound tokens at all before you convince them to use this particular version of them.

SamWilsn · 2026-07-20T14:27:13Z

+Current Soulbound token implementations take different approaches but all retain some form of token movement between addresses:
+
+- [ERC-5192](./eip-5192.md) and [ERC-5484](./eip-5484.md) extend [ERC-721](./eip-721.md), inheriting its complete transfer infrastructure and then blocking these capabilities
+- [ERC-4973](./eip-4973.md) avoids implementing ERC-721's transfer interface but includes `give()` and `take()` functions that allow token movement between addresses with signature consent


Not necessarily a bad thing, but you should note that referencing this proposal creates an implicit dependency. You won't be able to advance ERC-8129 beyond ERC-4973's status (currently review).

SamWilsn · 2026-07-20T14:29:59Z

+Compliant contracts MUST implement the ERC-721 metadata interface for human-readable token information:
+
+```solidity
+/// @title ERC-721 Metadata Interface (from EIP-721)
+/// @dev This is a REQUIRED part of the standard
+interface IERC721Metadata {
+    /// @notice A descriptive name for the token collection
+    function name() external view returns (string memory);
+
+    /// @notice An abbreviated name for the token collection
+    function symbol() external view returns (string memory);
+
+    /// @notice A URI pointing to metadata for a specific token
+    /// @dev MUST revert if tokenId does not exist
+    /// @param tokenId The identifier of the token
+    /// @return The URI string
+    function tokenURI(uint256 tokenId) external view returns (string memory);
+}
+```
+
+See [ERC-721](./eip-721.md) for a definition of its metadata JSON Schema.


Instead of duplicating the definition here, just link to the section in ERC-721. Something like:

Suggested change

Compliant contracts MUST implement the ERC-721 metadata interface for human-readable token information:

```solidity

/// @title ERC-721 Metadata Interface (from EIP-721)

/// @dev This is a REQUIRED part of the standard

interface IERC721Metadata {

/// @notice A descriptive name for the token collection

function name() external view returns (string memory);

/// @notice An abbreviated name for the token collection

function symbol() external view returns (string memory);

/// @notice A URI pointing to metadata for a specific token

/// @dev MUST revert if tokenId does not exist

/// @param tokenId The identifier of the token

/// @return The URI string

function tokenURI(uint256 tokenId) external view returns (string memory);

}

```

See [ERC-721](./eip-721.md) for a definition of its metadata JSON Schema.

Compliant contracts MUST implement ERC-721's [`ERC721Metadata`](./eip-721.md#specification:~:text=interface%20ERC721Metadata) interface for human-readable token information.

See [ERC-721](./eip-721.md) for a definition of its metadata JSON Schema.

SamWilsn · 2026-07-20T14:31:19Z

+
+1. **Minting**:
+   - Tokens MUST be minted to a specified address via the `to` parameter
+   - The minting function MUST emit the `Mint` event


You should probably add a section for requirements on events. For example, if a token is created through a function other than the minting function, is the event emitted?

SamWilsn · 2026-07-20T14:31:57Z

+
+### Why Not Extend ERC-721 or Use Consensual Transfer?
+
+**ERC-721 Extensions (ERC-5192, ERC-5484):**


Use subheadings instead of bold text. We have h1-h6, might as well use them.

Suggested change

**ERC-721 Extensions (ERC-5192, ERC-5484):**

#### ERC-721 Extensions (ERC-5192, ERC-5484)

SamWilsn · 2026-07-20T14:32:48Z

+## Reference Implementation
+
+```solidity
+// SPDX-License-Identifier: MIT


Code within the document itself must be CC0-1.0 licensed. You can include MIT code in your assets directory if you like.

SamWilsn · 2026-07-20T14:33:35Z

+
+### Interface Detection
+
+External contracts MUST NOT assume transfer capabilities based solely on the presence of metadata functions. Always check [ERC-165](./eip-165.md#how-to-detect-if-a-contract-implements-any-given-interface) interface support.


Avoid creating requirements (defined with UPPERCASE keywords) outside of the specification section. They're too easy for implementers to miss. Instead, put the requirements in Specification, and discuss their relevance to security here.

github-actions · 2026-07-27T04:03:55Z

The commit bfde567 (as a parent of 22d4998) contains errors.
Please inspect the Run Summary for details.

Vantana1995 requested a review from eip-review-bot as a code owner January 20, 2026 06:29

github-actions Bot added c-new s-draft t-erc labels Jan 20, 2026

eip-review-bot added e-consensus e-review labels Jan 20, 2026

eip-review-bot changed the title ~~EIP-XXXX: Non-transferable Token Standard(Soulbound)~~ Add ERC: Non-Transferable Token Standard Jan 20, 2026

github-actions Bot added the w-ci label Jan 20, 2026

abcoathup reviewed Jan 21, 2026

View reviewed changes

eip-review-bot changed the title ~~Add ERC: Non-Transferable Token Standard~~ Add ERC: Non-Transferable Token Jan 21, 2026

github-actions Bot added w-ci and removed w-ci labels Jan 21, 2026

Vantana1995 mentioned this pull request Jan 21, 2026

Add EIP: Non-Transferable Token Standard ethereum/EIPs#11105

Closed

github-actions Bot removed the w-ci label Jan 22, 2026

Vantana1995 added 6 commits February 16, 2026 08:53

Add EIP-XXXX: Non-transferable Token Standard

7410c57

Change filename to erc-8129.md

7351443

Update indentifier for interface detection via erc-165

b62562e

Typos update to fix github flow actions errors

3c733c1

Typos update to fix github flow actions errors

16d6746

Change erc links to eip

7f30b97

Vantana1995 force-pushed the erc-nontransferable-tokens branch from fe68cee to 7f30b97 Compare February 16, 2026 07:53

Vantana1995 commented Mar 22, 2026

View reviewed changes

SamWilsn reviewed Jul 20, 2026

View reviewed changes

updates in spec docs

1e7cff7

github-actions Bot added the w-ci label Jul 27, 2026

update

bfde567

Fix ERC-721 metadata link anchor

4a62c4a

github-actions Bot removed the w-ci label Oct 2, 2026

	title: Non-Transferable Token Standard
	title: Non-Transferable Token

	discussions-to: https://ethereum-magicians.org/t/soulbound-nft-as-separate-standard/27407
	discussions-to: https://ethereum-magicians.org/t/erc-8129-non-transferable-token/27407


		## Abstract

		This EIP proposes a minimal standard for non-transferable tokens (commonly known as "Soulbound tokens"). Unlike existing approaches that extend [ERC-721](./eip-721.md) and disable transfer functionality, this standard defines tokens that are non-transferable by design, eliminating transfer-related functions entirely from the interface.


		4. Not Truly Non-Transferable: Existing implementations either block transfers through restrictions or allow consensual movement between addresses. In both cases, the token is not fundamentally bound to a single address - it's restricted from free transfer or requires consent to move.

		Non-transferable tokens represent credentials, achievements, certifications, memberships, and identity attestations - assets that by their nature should be permanently bound to their owner. These use cases deserve a dedicated standard that explicitly communicates non-transferability through the absence of transfer functions, not their restriction.


		### Why Not Extend ERC-721 or Use Consensual Transfer?

		ERC-721 Extensions (ERC-5192, ERC-5484):

	ERC-721 Extensions (ERC-5192, ERC-5484):
	#### ERC-721 Extensions (ERC-5192, ERC-5484)


		### Interface Detection

		External contracts MUST NOT assume transfer capabilities based solely on the presence of metadata functions. Always check [ERC-165](./eip-165.md#how-to-detect-if-a-contract-implements-any-given-interface) interface support.

Conversation

Vantana1995 commented Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Description

Uh oh!

eip-review-bot commented Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

File ERCS/erc-8129.md

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Vantana1995 commented Feb 12, 2026

Uh oh!

Vantana1995 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Jul 27, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Vantana1995 commented Jan 20, 2026 •

edited

Loading

eip-review-bot commented Jan 20, 2026 •

edited

Loading

File `ERCS/erc-8129.md`