ERC-8060: IERC721Value — Embedding native ETH inside ERC-721 tokens

ERCs
1

Hello everyone :waving_hand:

This is an early-stage concept I’ve been developing called TEN.IO, which proposes a way for ERC-721 tokens to embed native ETH value directly within their logic.

I’m sharing it here to open a technical discussion about its potential standardization and implications for Ethereum’s cultural and economic layers.

:brick: Overview

The idea extends the current ERC-721 standard by introducing an interface called IERC721Value.

Each NFT can hold a verifiable ETH balance within the contract itself, not through wrapping or delegation.
The embedded value is transparent, withdrawable (via burn()), and fully on-chain — linking artistic, cultural, or symbolic data with real ETH collateral.

This enables new forms of digital assets that act as reservoirs of ETH-backed culture, where each fragment of art or code carries intrinsic, measurable value.

:gear: Interface draft (simplified)

interface IERC721Value is IERC721 {
    function valueOf(uint256 tokenId) external view returns (uint256);
    function mint(address to) external payable returns (uint256 tokenId);
    function burn(uint256 tokenId) external returns (uint256 refunded);
}

:globe_with_meridians: Use cases

  • Art and media fragments that embed verifiable ETH reserves
  • NFTs representing cultural or educational works with intrinsic liquidity
  • Tokenized archives where each asset holds its own collateral
  • Long-term storage of symbolic value directly on-chain

:puzzle_piece: Key difference

Unlike ERC-20 or wrapped models, the ETH never leaves the NFT contract.
The token itself is the vault — an autonomous unit of value and meaning.

:brain: Motivation

This proposal aims to bridge Ethereum’s financial layer with its cultural layer, giving each creative output measurable economic weight without intermediaries.

:magnifying_glass_tilted_left: Next steps

I’d love to hear thoughts on:

  • Possible integration paths with ERC-721 extensions
  • Security considerations for ETH holding per token
  • Whether this could evolve into a formal ERC standard

:package: Full reference

Test implementation (Sepolia):
Deployed and verified as part of the TEN.IO system.

IPFS video demonstration:
:movie_camera: https://ipfs.io/ipfs/bafybeifyzmymkdjkovo25z4kglt6bglcmy5ajpjpw5qjvhctnkcquwi4la

:coin: Summary

ERC-721 tokens capable of holding native ETH —
transforming NFTs from representations of value into containers of value.

:eight_spoked_asterisk: Author

TEN.IO
@ten_io_meta on X
ENS: tenio.eth
Website: https://tenio.eth.limo

:white_check_mark: Category: Magicians › Primordial Soup
:white_check_mark: Tags: ERC721, ETH, NFT, protocol, value

2 Likes
2

Open for community feedback.
Looking forward to hearing thoughts from other ERC authors and protocol engineers.

3

I had an earlier proposal of taking this a step further and turn an NFT into a smart wallet

4

Thanks for the recent discussion about ERC-6551 and ERC-7978 — both are great references.

Just to clarify, ERC-8060 goes one step further: it allows native ETH to be embedded directly inside an ERC-721 token, so the NFT itself can hold and release real ETH value without needing a separate registry or external account abstraction.

In that sense, it turns the NFT into a self-contained smart wallet.

I’d really appreciate any feedback on interoperability with 6551 or 7978, or suggestions for maintaining ERC-721 compliance while embedding value.

5

Thanks for the reference — the concept of NFTs acting as smart wallets is indeed an interesting direction.

In fact, ERC-8060 starts exactly from that premise: by embedding native ETH directly inside the token, the NFT itself becomes the wallet, maintaining its own balance without relying on an external account or wrapper contract.

The goal is to simplify the abstraction layer — merging value (ETH) and identity (NFT) into a single on-chain entity.

1 Like
6

Update — Value clarification + live implementation

Quick clarification regarding value units inside the current implementation:

  • Fragment 0 (El Umbral) mints at 0.012 ETH
    and keeps 0.010 ETH embedded as native collateral.
  • Future fragments (songs / chapters) will follow the structure of
    mint 0.12 ETH → hold 0.10 ETH as collateral,
    but the current early fragment uses a lower value since it acts as the “entry threshold” of the system.

Website (ENS): https://tenio.eth.limo

The goal remains the same:

The NFT itself becomes the vault — a self-contained unit of value + meaning.

Happy to receive feedback on:

  • compatibility with existing ERC-721 extensions,
  • security trade-offs holding ETH per token,
  • whether embedding native ETH should evolve into a formal ERC.
7

Hi everyone :waving_hand:

Just a quick follow-up — the ERC-8060 PR (#1315) has passed all checks and is now waiting for editorial assignment.
The reference implementation is already live on Sepolia and Mainnet, following the same structure used in https://tenio.eth.limo (mint 0.012 ETH → holds 0.010 ETH as native collateral).

Would appreciate any thoughts or feedback on how native ETH embedding compares to related discussions like ERC-6551 or ERC-6909.
Thanks for keeping the standards process alive and open :folded_hands:

8

Hi everyone

I just wanted to add a brief clarification for context, since ERC-8060 is sometimes discussed alongside proposals that define supply behavior.

ERC-8060 is intentionally scoped to value localization, not supply semantics. Its only invariant is that value lives in a single, self-contained ERC-721 state — the token itself acts as the vault.

ERC-8060 does not define how supply behaves over time. It does not specify minting rules, burn finality, caps, or whether total supply can ever increase after a burn. Those concerns are explicitly out of scope for this proposal.

Supply semantics are addressed separately in ERC-8098, which defines a strictly non-increasing total supply invariant for fungible assets.

In TEN.IO, both ERCs are used together but remain orthogonal:

• ERC-8060 answers where value lives
• ERC-8098 answers how value can cease to exist at the protocol level

I’m sharing this only to avoid semantic overlap — not to couple the proposals. Each ERC stands independently and can be evaluated on its own merits.

Thanks for taking the time to review.

9

Updated the proposal to address initial feedback:

  • clarified burn authorization (owner-only / ERC-721 approvals)
  • introduced valueOf(tokenId)
  • expanded Motivation and Security sections
  • aligned formatting with EIP template

PR: Add ERC: Native ETH embedding in NFTs by ten-io-meta · Pull Request #1315 · ethereum/ERCs · GitHub

Feedback welcome.

10

While working on ERC-8060, I started wondering whether the underlying primitive may be broader than native ETH redemption itself.

ERC-8060 remains focused on a specific use case: a non-fungible token exposing redeemable native ETH value through a standardized interface.

However, the same pattern could potentially apply to other forms of measurable value associated with ERC-721 identities, such as collateral scores, reputation metrics, contribution points, guarantees, credits, or other contract-defined values.

In that sense, ERC-8060 may be viewed as one concrete implementation of a more general concept:

A non-fungible identity exposing standardized value through a common interface.

To be clear, I am not proposing changes to ERC-8060, nor suggesting a new ERC at this stage. The current proposal remains focused exclusively on native ETH redemption.

I am simply curious whether others see merit in exploring this broader abstraction in the future, once the ETH-backed use case is better understood.

Interested in hearing thoughts from the community.

11

ERC-8060 Reference Implementation Update

Since the original post, the proposal has evolved from a conceptual discussion into a tested reference implementation.

Current status:

  • PR #1315 submitted

  • Solidity 0.8.20

  • OpenZeppelin 4.9.6

  • Hardhat 2.22.19

  • 50 passing tests

  • ERC165 support

  • IERC721Value interface detection

  • Reentrancy protection

  • Event coverage

  • Centralized burn accounting

  • Solvency and redemption invariants tested

Reference repository:

https://github.com/ten-io-meta/erc8060-native-eth-value

Current release:

v0.4-reference-50-tests

Core invariants currently verified:

  1. address(this).balance >= totalRedeemableValue

  2. totalRedeemableValue == Σ valueOf(tokenId) for all live tokens

  3. No double redemption

  4. No redemption without ownership

  5. No withdrawal of redeemable collateral as surplus

  6. Correct ERC165 / IERC721Value detection

  7. Events match state transitions

Additional review of the accounting model is welcome.

1 Like
12

This is a nice ERC!

Quick feedback/idea:

  1. Use the latest version of OpenZeppelin for the implementation example. See Release v5.6.1 · OpenZeppelin/openzeppelin-contracts · GitHub

  2. I am not sure if it is really useful to put the mint and burn functions in the interface. It could be more relevant to only keep valueOf(uint256 tokenId)

ERC-721 and ERC-20 does not include mint and burn in their interface. This give more flexibility to the token issuer while keeping the compatibility with the interface.

Eventually, the mint adds the value keyword, but burn is pretty standard so it does not bring much value to the standard while limiting the issuer to implement other way of burning/redeeming tokens.

I am not totally sure, but keeping only valueOf could potentially allows to use the interface with ERC-1155 tokens?

Best

1 Like
13

Thank you for the thoughtful feedback.

I agree that keeping the interface minimal improves flexibility and better matches the philosophy of ERC-20 and ERC-721.

I’ve updated the reference implementation so that IERC721Value now exposes only:

function valueOf(uint256 tokenId) external view returns (uint256);

The burn() function remains part of the reference implementation, but it is no longer required by the interface, allowing different implementations to expose redemption or burning mechanisms as appropriate while remaining compatible through valueOf().

Thanks again for the suggestion—it made the proposal cleaner.

1 Like
14

Hi everyone,

A small implementation update.

Since the initial draft, three public reference repositories are now available to accompany the proposal:

• ERC-8060 Native ETH Value Reference
https://github.com/ten-io-meta/erc8060-native-eth-value
50 passing validation tests — archived on Zenodo.

• ERC-8060 Reservable
https://github.com/ten-io-meta/erc8060-reservable
61 passing validation tests — archived on Zenodo.

• Agent Reservable Composition
https://github.com/ten-io-meta/agent-reservable-composition
251 passing validation tests — archived on Zenodo.

These repositories provide executable reference implementations and validation suites accompanying the proposal. They are intended as supporting implementation material rather than changes to the specification itself.

Feedback is always welcome.