Discussion: IERC8060Reservable — A Minimal Reservation Accounting Extension for ERC-8060

ERCs
, , , ,
1

Discussion: IERC8060Reservable — A Minimal Reservation Accounting Extension for ERC-8060

We have published a draft reference implementation of IERC8060Reservable, a minimal optional extension for ERC-8060 value-bearing NFTs.

Repository and reference implementation:
https://github.com/ten-io-meta/erc8060-reservable

Motivation

Many workflows require temporarily locking part of an NFT’s embedded value without transferring ownership or moving funds out of the token.

Common examples include:

  • Escrows

  • Collateral arrangements

  • Lending systems

  • Agent coordination

  • Conditional payments

IERC8060Reservable provides a minimal accounting layer for these patterns while remaining agnostic to settlement logic, reputation systems, disputes, or business rules.

Scope

The extension standardizes only:

  • reserveAllowance(tokenId, spender, asset)

  • reserveValue(tokenId, asset, amount)

  • releaseValue(tokenId, asset, amount)

  • lockedValue(tokenId, asset)

  • availableValue(tokenId, asset)

Reservations and locked value are bound to the tokenId and travel with the NFT upon transfer.

reserveAllowance represents revocable authorization rather than a binding commitment.

Design Philosophy

IERC8060Reservable is strictly a reservation accounting primitive.

Its purpose is to prevent reserved value from being withdrawn or double-spent while remaining completely agnostic to settlement semantics.

It deliberately excludes:

  • Settlement or consumption functions

  • Liquidation and dispute logic

  • Deadlines or expiration mechanisms

  • Reputation systems

  • Transfer restrictions

  • Business-specific execution rules

During review, proposals such as aggregated allowance tracking (allocatedValue) and standardized settlement primitives were considered and rejected because they move the design from accounting into application-layer execution.

Architectural Layers

Layer Responsibility
ERC-8060 Value custody
IERC8060Reservable Reservation accounting
Escrows / Applications Execution and settlement
Reputation Systems (e.g. ERC-8004) Identity and trust
Risk Engines Interpretation and underwriting

Core Invariants

A correct implementation must enforce:

  1. lockedValue(tokenId, asset) <= totalValue(tokenId, asset)

  2. availableValue(tokenId, asset) == totalValue(tokenId, asset) - lockedValue(tokenId, asset)

  3. Any reduction of custodied value (withdraw, burn, etc.) MUST revert if:

    amount > availableValue(tokenId, asset)

  4. reserveValue() MUST revert unless both conditions hold:

    • amount <= reserveAllowance(tokenId, msg.sender, asset)

    • amount <= availableValue(tokenId, asset)

  5. releaseValue() cannot release more than the caller currently has locked.

  6. Active reservations travel with the tokenId upon transfer.

Feedback Requested

After several rounds of adversarial review, we have not identified a missing primitive or an irreducible failure within the accounting model itself.

We welcome feedback on:

  • Whether the accounting/execution boundary is appropriate

  • Whether any essential primitive is missing

  • Whether token-bound reservations are the appropriate default behavior

  • Any production scenario where the current invariants create a failure that cannot reasonably be reduced to escrow design, risk modeling, marketplace behavior, reputation systems, or other application-layer decisions

All feedback is welcome.

Repository:
https://github.com/ten-io-meta/erc8060-reservable

1 Like