ERC-8060: Native ETH embedding in NFTs

Abstract

This proposal introduces IERC721Value, an extension to ERC-721 that enables each non-fungible token to expose a redeemable amount of native ETH.

Unlike approaches that rely on external vaults, wrapped assets, or delegated custody, the redeemable value is defined by the NFT contract's own accounting model and can only be recovered by burning the token.

This standard defines a minimal interface for querying and redeeming per-token ETH value while preserving full compatibility with ERC-721.

Motivation

ERC-721 defines ownership of non-fungible assets but does not provide a standardized way to associate native ETH value with a token in a non-custodial and irreversible manner.

Today, value-bearing NFT designs often rely on external vault contracts, wrapped assets, or off-chain accounting assumptions. These approaches introduce fragmentation, additional trust assumptions, and inconsistent integration patterns across wallets, marketplaces, indexers, and applications.

This proposal introduces a reusable primitive where each NFT carries a redeemable ETH value that is:

• accounted for within the token contract,
• inseparable from the token's identity,
• externally queryable through a standard interface,
• and recoverable only through an explicit burn operation by the token owner.

This enables a wide range of applications, including:

• non-fungible assets with a guaranteed intrinsic value floor independent of secondary markets,
• rights, licenses, or permits whose economic collateral is inseparable from the non-fungible identity that defines them,
• non-custodial escrows or guarantees represented as transferable NFTs,
• and long-term value containers where liquidity is intentionally constrained and recovery requires explicit state destruction.

Potential actors interested in this primitive include creators and publishers of value-backed digital or physical assets, systems issuing licenses or certifications with economic guarantees, and applications requiring simple non-custodial value escrow tied to unique identifiers.

Standardizing this pattern allows wallets, indexers, marketplaces, and applications to uniformly detect, display, and interact with NFTs that carry intrinsic redeemable ETH value.

Specification

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Compliant contracts MUST implement ERC-721 and ERC-165 interface detection for this interface.

interface IERC721Value {
    function valueOf(uint256 tokenId) external view returns (uint256);
    function burn(uint256 tokenId) external;
}

valueOf

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

Returns the amount of native ETH redeemable for tokenId.

The returned value MUST reflect the amount of native ETH that the current owner is entitled to receive if the token is burned at the time of the call.

Calls for nonexistent tokens MUST revert.

burn

function burn(uint256 tokenId) external;

Burns tokenId and redeems its associated native ETH value.

Requirements:

• MUST revert unless msg.sender is the current owner of tokenId.
• MUST permanently destroy tokenId.
• MUST transfer the redeemable ETH value associated with tokenId to the current owner.
• MUST ensure that the redeemed value cannot be claimed again.
• MUST emit the standard ERC-721 Transfer event to the zero address as required for burns.

Value Assignment

Implementations MUST define how ETH value is assigned to each token.

The value MAY be:

• uniform across all tokens,
• variable per token,
• or determined by custom minting logic.

The value assigned to a token MUST be consistently reported by valueOf(tokenId) and MUST be redeemable at burn time.

Accounting Model

Implementations MAY use different internal accounting strategies, including:

• per-token value storage,
• pooled reserve models,
• or deterministic value assignment.

However:

• the redeemable value MUST be clearly defined per token,
• valueOf(tokenId) MUST report the redeemable value for that specific token,
• and the implementation MUST ensure that all reported values are backed and redeemable under its accounting model.

ETH Balance Considerations

The total ETH balance of the contract MAY exceed or differ from the sum of redeemable values due to:

• direct ETH transfers to the contract,
• surplus accumulation,
• donations,
• or implementation-specific accounting.

Therefore, valueOf(tokenId) MUST NOT be inferred from the contract's raw ETH balance.

Rationale

This design focuses on defining a minimal implementation-agnostic primitive for associating redeemable native ETH value with ERC-721 tokens.

The standard does not prescribe how value is stored internally, allowing flexibility across different implementations, including fixed-value collections, variable-value tokens, pooled reserves, or deterministic value models.

Redemption of embedded ETH is performed exclusively through token burn, ensuring that value recovery is inseparable from the destruction of the non-fungible state. This eliminates ambiguity around partial withdrawals, shared claims, or independent collateral extraction, and keeps the lifecycle of value explicit and deterministic.

Burning permanently terminates the lifecycle of the redeemed token instance and ensures that its associated redeemable ETH value cannot be claimed again. This guarantee applies to the redeemed token instance and the accounting associated with it. This proposal does not prescribe whether implementations may later recreate the same numeric token identifier under an independent lifecycle or accounting model.

Redemption is restricted to the current owner because burning a token with redeemable ETH is an irreversible economic action. Unlike ordinary ERC-721 transfer approvals, redemption destroys the non-fungible asset and releases its associated value. Restricting redemption to the owner avoids ambiguity and reduces the risk of unintended value extraction by third parties.

The introduction of valueOf(tokenId) provides a uniform interface for external systems to query redeemable value without relying on contract-specific logic or raw ETH balance assumptions.

The proposal preserves full ERC-721 compatibility to ensure interoperability with existing tooling, wallets, and marketplaces while extending the standard with minimal additional surface area.

By constraining value redemption to a single explicit lifecycle transition, the design prioritizes clarity, safety, and predictability over composability or financial flexibility.

Backwards Compatibility

This ERC is fully backwards compatible with ERC-721.

Existing ERC-721 contracts are not affected. Contracts that implement this extension remain valid ERC-721 contracts and can continue to interoperate with wallets, marketplaces, and applications that only understand ERC-721.

Applications that support this extension can additionally query valueOf(tokenId) to display redeemable ETH value and identify tokens that expose intrinsic native ETH redemption.

Security Considerations

Incorrect authorization, accounting, or redemption logic may result in insolvency, unintended loss of funds, or unauthorized value extraction.

Implementations are expected to ensure that only the current token owner can initiate a burn that results in ETH redemption.

Implementations should protect against reentrancy when transferring ETH during burn operations. Checks-effects-interactions or equivalent safeguards are recommended.

Implementations should correctly account for per-token redeemable values to avoid inconsistencies between token state, reported value, and redeemable ETH.

Implementations should ensure that redeemed value cannot be claimed more than once.

Implementations should carefully consider how direct ETH transfers to the contract are handled.

Implementations should define how surplus ETH is handled when the contract balance exceeds total redeemable obligations.

Copyright

Copyright and related rights waived via CC0.