ERC-8332: Physical Reserve Registry

ERCs
,
1

Summary

Hi everyone. I would like to propose a new ERC for a Physical Reserve Registry: a standard interface for representing physical reserves on-chain so they can be allocated as backing for reserve-backed tokens and other RWA instruments.

Motivation

Many reserve-backed RWA tokens rely on bank records, audit reports, or regulatory attestations. However, these records are usually not exposed through a common on-chain interface. This makes it difficult for wallets, explorers, and DeFi protocols to query reserve identity, reserve quantity, allocation, and endorsements in a standardized way.

This proposal does not attempt to replace banks, custodians, auditors, legal documents, or regulatory processes. Instead, it defines a regulation-agnostic reserve accounting interface that can mirror or reference those systems while remaining usable by smart contracts.

Specification

The core idea is:

  • a reserveId identifies a physical reserve or custody/inventory entry;

  • an assetId identifies the physical asset type;

  • each reserve exposes a common accounting view: total quantity, available quantity, consumed quantity, and state;

  • the reserve states include PENDING, ACTIVE, SUSPENDED, CONSUMED, and CANCELLED reserves

  • reserve quantity can be allocated to an instrument, such as a reserve-backed ERC-20 token, without implying that tokens have already been minted;

  • allocation, release, and consumption are represented as separate accounting actions;

  • optional extensions support endorsement records, metadata/document references, and ERC-721 reserve receipt mappings.

The main intended use case is reserve-backed fungible token issuance, where a later ERC-20 extension or token contract can enforce that its outstanding supply does not exceed the reserve quantity allocated to that token contract.

This proposal is intentionally not a full tokenization workflow. It does not define how reserves must be deposited, audited, legally held, redeemed, or regulated. Those processes are implementation-specific. The proposal only standardizes the observable reserve registry and allocation layer.

Questions for review

I would especially appreciate feedback on:

  1. Whether the separation between reserve registry, token issuance, and asset redemption is clear.

  2. Whether optional extensions should remain optional or be required for all compliant registries.

  3. Whether the reserve state model is appropriate: PENDING, ACTIVE, SUSPENDED, CONSUMED, and CANCELLED.

Status

1 Like