Add ERC: PermaLink Asset Bound Token Standard #999

NarcisCRO · 2025-04-01T12:17:10Z

Create erc-x.md

Added the template

Title change
author update erc-x.md
description erc-x.md
abstract erc-x.md
motivation + security considerations erc-x.md
title erc-x.md

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

The PR edits only existing draft PRs.
The build passes.
Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
If matching on email address, the email address is the one publicly listed on your GitHub profile.

* Create erc-x.md Added the template * Title change * author update erc-x.md * description erc-x.md * abstract erc-x.md * motivation + security considerations erc-x.md * title erc-x.md --------- Co-authored-by: NickZCZ <[email protected]>

eip-review-bot · 2025-04-01T12:17:31Z

File `ERCS/erc-x.md`

Requires 1 more reviewers from @g11tech, @SamWilsn, @xinbenlv

bomanaps · 2025-04-07T06:05:05Z

ERCS/erc-x.md

+title: Non-Fungible PermaLink Asset Bound Token Standard
+description: An interface for Non-Fungible PermaLink Asset Bound Tokens, also known as a NFABT.
+author: Mihai Onila (@MihaiORO), Nick Zeman (@NickZCZ), Narcis Cotaie (@NarcisCRO)
+discussions-to: <[URL](https://ethereum-magicians.org/t/non-fungible-asset-bound-token/23175)>


Suggested change

discussions-to: <[URL](https://ethereum-magicians.org/t/non-fungible-asset-bound-token/23175)>

discussions-to: https://ethereum-magicians.org/t/non-fungible-asset-bound-token/23175

bomanaps · 2025-04-07T06:07:17Z

ERCS/erc-x.md

+discussions-to: <[URL](https://ethereum-magicians.org/t/non-fungible-asset-bound-token/23175)>
+status: Draft
+type: Standards Track
+category: <Core, Networking, Interface, or ERC> # Only required for Standards Track. Otherwise, remove this field.


Suggested change

category: <Core, Networking, Interface, or ERC> # Only required for Standards Track. Otherwise, remove this field.

category: ERC

bomanaps · 2025-04-07T06:10:07Z

ERCS/erc-x.md

+status: Draft
+type: Standards Track
+category: <Core, Networking, Interface, or ERC> # Only required for Standards Track. Otherwise, remove this field.
+created: <date created on, in ISO 8601 (yyyy-mm-dd) format>


Please include the date this EIP proposal was first created.

bomanaps · 2025-04-07T06:11:56Z

ERCS/erc-x.md

+<!--
+  READ EIP-1 (https://eips.ethereum.org/EIPS/eip-1) BEFORE USING THIS TEMPLATE!
+
+  This is the suggested template for new EIPs. After you have filled in the requisite fields, please delete these comments.
+
+  Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`.
+
+  The title should be 44 characters or less. It should not repeat the EIP number in title, irrespective of the category.
+
+  TODO: Remove this comment before submitting
+-->


And all of this should go away.

Suggested change

bomanaps · 2025-04-07T06:20:50Z

ERCS/erc-x.md

+## Abstract
+
+A standard interface for Non-Fungible PermaLink Asset Bound Tokens (PermaLink-ABT/s), a subset of the more general Asset Bound Tokens (ABT/s).
+
+The following standard allows for the implementation of a standard API for tokens within smart contracts and provides mirrored information of a specific smart contract through the ‘assetBoundContract’ function. Mirrored information consists of ‘ownerOf’, ‘tokenID’, ‘totalSupply’, as well as ‘balanceOf’. This in conjunction with blocking the ability to use basic transfer and approve functionality makes 2 tokens from different smart contracts interlocked. As the asset cannot be transferred in the traditional sense, being bound to a specific asset within a specific contract and maintaining corresponding information and movements creates an ABT. 
+
+As the asset is bound to another asset having specified mirrored information, a ‘reveal’ function replaces the mint function commonly seen. The total supply of all the tokens from the ABT smart contract already exists.
+
+We considered ABTs being used by every individual who wishes to link an additional non-fungible asset to an already existing non-fungible asset. ABTs allow an infinite amount of tokens to be bound together, allowing them to work symbiotically rather than splintering and separating. Remaining interlocked and asset bound removes the idea that 2 smart contracts released by the same or different creators at the same or different times are competing with one another.


Your abstract contains both technical specifications and rationale, which should be separated into appropriate sections. The technical details should go in the Specification section, and the reasoning behind design choices should go in the Rationale section.

Hopefully fixed :)

bomanaps · 2025-04-07T06:21:56Z

ERCS/erc-x.md

+<!--
+  The Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does.
+
+  TODO: Remove this comment before submitting
+-->


Suggested change

bomanaps · 2025-04-07T06:25:35Z

ERCS/erc-x.md

+4. **Addressing NFT Fragmentation:** NFTs have traditionally been associated with digital collectibles and art. However, many projects deploy secondary smart contracts to evolve their collections, inadvertently causing liquidity fragmentation. Owners often sell assets from the original collection to acquire newer ones, leading to value dilution and lower overall market confidence.
+ABTs solve this by allowing secondary collections to complement rather than compete with the original. Bound assets enhance the primary asset’s value without necessitating a separate, competing ecosystem. This structure retains liquidity within the original collection and sustains its market metrics, benefiting both creators and collectors.
+
+5. **New Opprutunites for Creators:** ABTs empower both asset owners and creators by enabling an open secondary market for existing tokens. Artists, for instance, can create and bind assets to existing NFTs without requiring permission from the original contract owner. This facilitates new revenue streams, such as artists being paid on consignment for augmenting or adding onto existing assets. Owners benefit as well, as additional assets increase the inherent value of their holdings, especially in instances of collaboration between established projects or reputable artists.


Suggested change

5. **New Opprutunites for Creators:** ABTs empower both asset owners and creators by enabling an open secondary market for existing tokens. Artists, for instance, can create and bind assets to existing NFTs without requiring permission from the original contract owner. This facilitates new revenue streams, such as artists being paid on consignment for augmenting or adding onto existing assets. Owners benefit as well, as additional assets increase the inherent value of their holdings, especially in instances of collaboration between established projects or reputable artists.

5. **New Opportunities for Creators:** ABTs empower both asset owners and creators by enabling an open secondary market for existing tokens. Artists, for instance, can create and bind assets to existing NFTs without requiring permission from the original contract owner. This facilitates new revenue streams, such as artists being paid on consignment for augmenting or adding onto existing assets. Owners benefit as well, as additional assets increase the inherent value of their holdings, especially in instances of collaboration between established projects or reputable artists.

bomanaps · 2025-04-07T06:26:55Z

ERCS/erc-x.md

+<!--
+  This section is optional.
+
+  The motivation section should include a description of any nontrivial problems the EIP solves. It should not describe how the EIP solves those problems, unless it is not immediately obvious. It should not describe why the EIP should be made into a standard, unless it is not immediately obvious.
+
+  With a few exceptions, external links are not allowed. If you feel that a particular resource would demonstrate a compelling case for your EIP, then save it as a printer-friendly PDF, put it in the assets folder, and link to that copy.
+
+  TODO: Remove this comment before submitting
+-->


Remove the template comment.

* name change test erc-x.md * info section * abstract.md * Motivation-x.md * Security Consider-x.md * 5th example.md * Update erc-x.md * safefallback function.md * Added ERC required * remove dash.md * Added interface and contract for IABT and ABT * Added ERC required * rationale.md * Added interface specifications --------- Co-authored-by: NickZCZ <[email protected]>

SamWilsn · 2025-04-15T16:03:47Z

ERCS/erc-x.md

+type: Standards Track
+category: ERC
+created: 2025-04-01
+requires: 721, 721Enumerable


Suggested change

requires: 721, 721Enumerable

requires: 721

Please find the EIP number for EIP721Enumerable and use that here.

SamWilsn · 2025-04-15T16:04:12Z

ERCS/erc-x.md

+
+### Abstract
+
+This standard introduces a subclass of tokens known as **PermaLink Asset Bound Tokens (PermaLink-ABTs)** a specific implementation of the broader **Asset Bound Token (ABT)** concept. ABTs establish a novel ownership paradigm where **an asset can own another asset**, enabling composable, nested, and portfolio-like token structures that evolve together over time.


Suggested change

This standard introduces a subclass of tokens known as **PermaLink Asset Bound Tokens (PermaLink-ABTs)** a specific implementation of the broader **Asset Bound Token (ABT)** concept. ABTs establish a novel ownership paradigm where **an asset can own another asset**, enabling composable, nested, and portfolio-like token structures that evolve together over time.

This standard introduces a subclass of tokens known as **PermaLink Asset Bound Tokens (PermaLink-ABTs)**. They are a specific implementation of the broader **Asset Bound Token (ABT)** concept. ABTs establish a novel ownership paradigm where **an asset can own another asset**, enabling composable, nested, and portfolio-like token structures that evolve together over time.

SamWilsn · 2025-04-15T16:08:02Z

ERCS/erc-x.md

+This standard proposes **Asset Bound Tokens (ABTs)** as a solution to this challenge. ABTs allow one token to be permanently bound to another across contracts, creating a dynamic, flexible, and composable ownership model. By enabling tokens to move and evolve together, ABTs pave the way for new possibilities in the on-chain economy. The following use cases illustrate why ABTs are needed:
+
+1. **On-Chain Identity Systems**  
+ Governments and institutions worldwide are piloting or implementing blockchain-based identity systems—digital passports, national IDs, and verifiable credentials such as with the EBSI initiative. These systems often require credentials to be linked across multiple registries (e.g., healthcare, banking, voting). ABTs enable the binding of identity-linked tokens into a cohesive unit, so they move together instead of requiring manual coordination and transfers. This ensures that identity-linked assets remain interconnected and dynamic, making it easier to manage and update linked data as users interact with various systems.


EBSI initiative

Could you expand this abbreviation?

SamWilsn · 2025-04-15T16:09:15Z

ERCS/erc-x.md

+
+In essence, ABTs introduce a framework where tokens are linked rather than owned. This allows for dynamic and evolving asset systems, where assets move together in harmony. If a binding token moves, all associated ABTs move with it, ensuring seamless updates and reducing the need for manual transfers. This innovation transforms traditional smart contracts from static repositories into living, evolving systems capable of adapting to changing use cases, technologies, and business models.
+
+The **PermaLink-ABTs** implementation takes the ABT model further by enforcing a permanent binding between one token and another—whether it’s another ABT, NFT or NFKBT. This permanent binding ensures that tokens can be transferred as a single unit, reducing complexity and gas fees. Instead of relying on traditional minting, PermaLink-ABTs use a `reveal` mechanism, activating tokens from a predefined supply. This reduces gas costs and encourages efficient linking of assets, enabling greater composability across multiple sectors.


Suggested change

The **PermaLink-ABTs** implementation takes the ABT model further by enforcing a permanent binding between one token and another—whether it’s another ABT, NFT or NFKBT. This permanent binding ensures that tokens can be transferred as a single unit, reducing complexity and gas fees. Instead of relying on traditional minting, PermaLink-ABTs use a `reveal` mechanism, activating tokens from a predefined supply. This reduces gas costs and encourages efficient linking of assets, enabling greater composability across multiple sectors.

The **PermaLink-ABTs** implementation takes the ABT model further by enforcing a permanent binding between one token and another—whether it's another ABT, NFT or NFKBT. This permanent binding ensures that tokens can be transferred as a single unit, reducing complexity and gas fees. Instead of relying on traditional minting, PermaLink-ABTs use a `reveal` mechanism, activating tokens from a predefined supply. This reduces gas costs and encourages efficient linking of assets, enabling greater composability across multiple sectors.

SamWilsn · 2025-04-15T16:10:38Z

ERCS/erc-x.md

+}
+```
+
+### `ABT` (Token Contract)


Implementations of the standard should be in the Reference Implementation section, not in the specification itself.

SamWilsn · 2025-04-15T16:18:24Z

ERCS/erc-x.md

+<!--
+
+  This section is optional.
+
+  All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.
+
+  The current placeholder is acceptable for a draft.
+
+  TODO: Remove this comment before submitting
+-->
+


Suggested change

SamWilsn · 2025-04-15T16:18:35Z

ERCS/erc-x.md

+## Test Cases
+
+<!--
+  This section is optional for non-Core EIPs.
+
+  The Test Cases section should include expected input/output pairs, but may include a succinct set of executable tests. It should not include project build files. No new requirements may be introduced here (meaning an implementation following only the Specification section should pass all tests here.)
+  If the test suite is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`. External links will not be allowed
+
+  TODO: Remove this comment before submitting
+-->
+


Suggested change

## Test Cases

SamWilsn · 2025-04-15T16:18:48Z

ERCS/erc-x.md

+<!--
+  This section is optional.
+
+  The Reference Implementation section should include a minimal implementation that assists in understanding or implementing this specification. It should not include project build files. The reference implementation is not a replacement for the Specification section, and the proposal should still be understandable without it.
+  If the reference implementation is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`. External links will not be allowed.
+
+  TODO: Remove this comment before submitting
+-->


Replace this with your implementation above.

SamWilsn · 2025-04-15T16:19:22Z

ERCS/erc-x.md

+
+PermaLink-ABTs are linked to another non-fungible token. If an individual loses access to this token—what we call the **binding token**—they also lose access to all PermaLink-ABTs that have been bound to it. This introduces a critical security consideration: the entire value of bound assets depends on the integrity and availability of the binding token.
+
+To mitigate this risk, we strongly recommend the use of standards like [ERC-6809](https://eips.ethereum.org/EIPS/eip-6809), a **Non-Fungible Key Bound Token**, which introduces on-chain two-factor authentication (2FA). ERC-6809 allows a user to bind sensitive tokens (like PermaLink-ABTs) to a secured identity layer, complete with recovery mechanisms. In the event that a user loses access to their original wallet or interacts with a malicious contract, ERC-6809 provides a safeFallback function to re-establish control.


Suggested change

To mitigate this risk, we strongly recommend the use of standards like [ERC-6809](https://eips.ethereum.org/EIPS/eip-6809), a **Non-Fungible Key Bound Token**, which introduces on-chain two-factor authentication (2FA). ERC-6809 allows a user to bind sensitive tokens (like PermaLink-ABTs) to a secured identity layer, complete with recovery mechanisms. In the event that a user loses access to their original wallet or interacts with a malicious contract, ERC-6809 provides a safeFallback function to re-establish control.

To mitigate this risk, we strongly recommend the use of standards like [ERC-6809](./eip-6809.md), a **Non-Fungible Key Bound Token**, which introduces on-chain two-factor authentication (2FA). ERC-6809 allows a user to bind sensitive tokens (like PermaLink-ABTs) to a secured identity layer, complete with recovery mechanisms. In the event that a user loses access to their original wallet or interacts with a malicious contract, ERC-6809 provides a `safeFallback` function to re-establish control.

SamWilsn · 2025-04-15T16:19:29Z

ERCS/erc-x.md

+
+
+
+Needs discussion.


Suggested change

Needs discussion.

SamWilsn · 2025-04-15T18:15:13Z

ERCS/erc-x.md

@@ -0,0 +1,238 @@
+---


Suggested change

---

---

eip: 7929

Please update the file name too!

github-actions · 2025-04-23T17:26:21Z

The commit c69de8d (as a parent of 3850a7a) contains errors.
Please inspect the Run Summary for details.

ABTs (#1)

f56c2ce

* Create erc-x.md Added the template * Title change * author update erc-x.md * description erc-x.md * abstract erc-x.md * motivation + security considerations erc-x.md * title erc-x.md --------- Co-authored-by: NickZCZ <[email protected]>

NarcisCRO requested a review from eip-review-bot as a code owner April 1, 2025 12:17

github-actions bot added c-new s-draft labels Apr 1, 2025

github-actions bot added the w-ci label Apr 1, 2025

Merge branch 'ethereum:master' into master

ae944ec

bomanaps reviewed Apr 7, 2025

View reviewed changes

github-actions bot added t-erc and removed w-ci labels Apr 15, 2025

eip-review-bot added e-consensus e-review labels Apr 15, 2025

eip-review-bot changed the title ~~ABTs Asset Bound Tokens~~ Add ERC: PermaLink Asset Bound Token Standard Apr 15, 2025

Merge branch 'master' into master

225862e

SamWilsn reviewed Apr 15, 2025

View reviewed changes

ERCS/erc-x.md

@@ -0,0 +1,238 @@

---

Copy link

Contributor

SamWilsn Apr 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

---

---

eip: 7929

Please update the file name too!

Merge branch 'ethereum:master' into master

c69de8d

github-actions bot added the w-ci label Apr 23, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add ERC: PermaLink Asset Bound Token Standard #999

Add ERC: PermaLink Asset Bound Token Standard #999

NarcisCRO commented Apr 1, 2025

eip-review-bot commented Apr 1, 2025 •

edited

Loading

bomanaps Apr 7, 2025

NarcisCRO Apr 15, 2025

bomanaps Apr 7, 2025

NarcisCRO Apr 15, 2025

bomanaps Apr 7, 2025

NarcisCRO Apr 15, 2025

bomanaps Apr 7, 2025

NarcisCRO Apr 15, 2025

bomanaps Apr 7, 2025

NarcisCRO Apr 15, 2025

bomanaps Apr 7, 2025

bomanaps Apr 7, 2025

NarcisCRO Apr 15, 2025

bomanaps Apr 7, 2025

SamWilsn Apr 15, 2025

SamWilsn Apr 15, 2025

SamWilsn Apr 15, 2025

SamWilsn Apr 15, 2025

SamWilsn Apr 15, 2025

SamWilsn Apr 15, 2025

SamWilsn Apr 15, 2025

SamWilsn Apr 15, 2025

SamWilsn Apr 15, 2025

SamWilsn Apr 15, 2025

SamWilsn Apr 15, 2025

github-actions bot commented Apr 23, 2025

	discussions-to: <[URL](https://ethereum-magicians.org/t/non-fungible-asset-bound-token/23175)>
	discussions-to: https://ethereum-magicians.org/t/non-fungible-asset-bound-token/23175

	category: <Core, Networking, Interface, or ERC> # Only required for Standards Track. Otherwise, remove this field.
	category: ERC


		### Abstract

		This standard introduces a subclass of tokens known as PermaLink Asset Bound Tokens (PermaLink-ABTs) a specific implementation of the broader Asset Bound Token (ABT) concept. ABTs establish a novel ownership paradigm where an asset can own another asset, enabling composable, nested, and portfolio-like token structures that evolve together over time.


		In essence, ABTs introduce a framework where tokens are linked rather than owned. This allows for dynamic and evolving asset systems, where assets move together in harmony. If a binding token moves, all associated ABTs move with it, ensuring seamless updates and reducing the need for manual transfers. This innovation transforms traditional smart contracts from static repositories into living, evolving systems capable of adapting to changing use cases, technologies, and business models.

		The PermaLink-ABTs implementation takes the ABT model further by enforcing a permanent binding between one token and another—whether it’s another ABT, NFT or NFKBT. This permanent binding ensures that tokens can be transferred as a single unit, reducing complexity and gas fees. Instead of relying on traditional minting, PermaLink-ABTs use a `reveal` mechanism, activating tokens from a predefined supply. This reduces gas costs and encourages efficient linking of assets, enabling greater composability across multiple sectors.


		PermaLink-ABTs are linked to another non-fungible token. If an individual loses access to this token—what we call the binding token—they also lose access to all PermaLink-ABTs that have been bound to it. This introduces a critical security consideration: the entire value of bound assets depends on the integrity and availability of the binding token.

		To mitigate this risk, we strongly recommend the use of standards like [ERC-6809](https://eips.ethereum.org/EIPS/eip-6809), a Non-Fungible Key Bound Token, which introduces on-chain two-factor authentication (2FA). ERC-6809 allows a user to bind sensitive tokens (like PermaLink-ABTs) to a secured identity layer, complete with recovery mechanisms. In the event that a user loses access to their original wallet or interacts with a malicious contract, ERC-6809 provides a safeFallback function to re-establish control.

Add ERC: PermaLink Asset Bound Token Standard #999

Are you sure you want to change the base?

Add ERC: PermaLink Asset Bound Token Standard #999

Conversation

NarcisCRO commented Apr 1, 2025

eip-review-bot commented Apr 1, 2025 • edited Loading

File ERCS/erc-x.md

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

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

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 Apr 23, 2025

eip-review-bot commented Apr 1, 2025 •

edited

Loading

File `ERCS/erc-x.md`