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
2

As a follow-up to the discussion, I have added a minimal escrow example and accompanying tests to the reference repository.

The goal was to validate whether escrow-style workflows can be implemented using the current reservation accounting surface alone, without introducing settlement semantics into the standard itself.

The example uses only the existing primitives:

  • reserveAllowance

  • reserveValue

  • releaseValue

  • lockedValue

  • availableValue

while keeping settlement logic entirely external to IERC8060Reservable.

At least for this escrow scenario, no additional accounting primitive was required. The implementation and tests appear to support the intended separation of concerns:

  • ERC-8060 → value custody

  • IERC8060Reservable → reservation accounting

  • Escrow/application layer → execution and settlement

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