Update ERC-8325: Move to Last Call

ERCS/erc-8325.md

@@ -4,7 +4,8 @@ title: Asset Anchor Registry
 description: A registry interface for registry-scoped token-to-anchor bindings for off-chain asset claims
 author: Chris Turner <c.turner@kula.com>, David Hay (@david-hay), Reagan Simpson (@krumg111), Collins Musyimi (@Musyimi97)
 discussions-to: https://ethereum-magicians.org/t/erc-8325-asset-anchor-registry/28934
-status: Review
+status: Last Call
+last-call-deadline: 2026-10-05
 type: Standards Track
 category: ERC
 created: 2026-07-04
@@ -13,8 +14,9 @@ requires: 165
 
 ## Abstract
 
-This ERC defines interfaces for registries that bind token contracts or token
-IDs to anchor records representing claims about off-chain assets. Each anchor
+This Ethereum Request for Comments (ERC) defines interfaces for registries that
+bind token contracts or token IDs to anchor records representing claims about
+off-chain assets. Each anchor
 contains separate commitments to a claimed legal basis and supporting evidence.
 Bindings distinguish whole-contract scope from token-ID scope, enforce
 registry-scoped exclusivity, and preserve immutable binding history.
@@ -68,7 +70,7 @@ registries they trust.
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
 "OPTIONAL" in this document are to be interpreted as described in
-[RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) and
+[Request for Comments (RFC) 2119](https://www.rfc-editor.org/rfc/rfc2119) and
 [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174).
 
 ### Definitions
@@ -111,7 +113,8 @@ For `BINDING_SCOPE_TOKEN_ID`, every `uint256` value is valid, including token ID
 
 ### Metadata Encoding
 
-Registration metadata MUST be ABI encoded as the following ordered tuple:
+Registration metadata MUST be application binary interface (ABI) encoded as
+the following ordered tuple:
 
 ```solidity
 struct AnchorMetadata {
@@ -145,16 +148,19 @@ be earlier than `block.timestamp` at registration. `uri` MUST NOT be empty.
 
 `assetClass` SHOULD be a domain-separated identifier from a documented
 taxonomy. When an anchor has one primary country jurisdiction, `jurisdiction`
-SHOULD be a domain-separated identifier derived from its uppercase ISO 3166-1
+SHOULD be a domain-separated identifier derived from its uppercase
+International Organization for Standardization (ISO) 3166-1
 alpha-2 code.
 
-The URI identifies where a consumer can retrieve material corresponding to the
-anchor commitments. This ERC does not require a particular URI scheme or
-guarantee availability.
+The Uniform Resource Identifier (URI) identifies where a consumer can retrieve
+material corresponding to the anchor commitments. This ERC does not require a
+particular URI scheme or guarantee availability.
 
 ### Registry Interface
 
 ```solidity
+pragma solidity ^0.8.20;
+
 interface IAssetAnchorRegistry {
     struct AnchorRecord {
         bytes32 anchorId;
@@ -292,6 +298,8 @@ Every compliant registry MUST implement the lifecycle interface because anchor
 activity and expiry are part of the common verification model:
 
 ```solidity
+pragma solidity ^0.8.20;
+
 interface IAssetAnchorRegistryLifecycle {
     function getMetadata(bytes32 anchorId)
         external
@@ -345,6 +353,8 @@ Binding recovery is OPTIONAL. A registry that permits disputed bindings to be
 invalidated MUST implement:
 
 ```solidity
+pragma solidity ^0.8.20;
+
 interface IAssetAnchorRegistryRecovery {
     event TokenBindingInvalidated(
         bytes32 indexed anchorId,
@@ -390,6 +400,8 @@ been invalidated. It MUST revert for an unknown anchor.
 Whole-contract bindings use:
 
 ```solidity
+pragma solidity ^0.8.20;
+
 interface IAssetBoundToken is IERC165 {
     function anchorId() external view returns (bytes32);
     function anchorRegistry() external view returns (address);
@@ -400,6 +412,8 @@ interface IAssetBoundToken is IERC165 {
 Token-ID bindings use:
 
 ```solidity
+pragma solidity ^0.8.20;
+
 interface IAssetBoundTokenId is IERC165 {
     function anchorIdOf(uint256 tokenId)
         external
@@ -520,8 +534,8 @@ of the minimum registry interface.
 Allocation constraints, such as ensuring that fractional token supply does not
 represent more than a defined share of an asset, depend on the economic and
 legal structure of the instrument. They are meaningful for some fungible
-fractional claims but not for a single NFT representing one object or for a
-registry record that does not express ownership percentages.
+fractional claims but not for a single non-fungible token (NFT) representing one
+object or for a registry record that does not express ownership percentages.
 
 The registry therefore standardizes binding identity rather than issuance or
 allocation rules. Tokens and application-specific contracts remain responsible
@@ -531,7 +545,8 @@ for enforcing any supply, fraction, or entitlement constraints.
 
 Different deployments require different trust models. A registry may be
 operated by one accountable issuer, a regulated registrar, a multisignature, a
-DAO, or a permissionless protocol. Requiring one governance model would exclude
+decentralized autonomous organization (DAO), or a permissionless protocol.
+Requiring one governance model would exclude
 otherwise interoperable implementations without making their off-chain claims
 more truthful.
 
@@ -556,20 +571,6 @@ global one-token-to-one-asset uniqueness.
 
 ### Prior Art
 
-[ERC-6956](./eip-6956.md) defines ERC-721 tokens bound one-to-one to physical
-or digital assets, with operations authorized by oracle attestations of control.
-This ERC is token-standard-neutral and standardizes a registry record binding,
-not proof-of-control authorization.
-
-The PermaLink Asset Bound Token proposal permanently binds one on-chain token
-to another and mirrors ownership behavior. This ERC binds token contracts or
-token IDs to records representing off-chain claims and does not define
-token-to-token ownership hierarchies.
-
-[ERC-6065](./eip-6065.md) defines an ERC-721 extension for tokenized real estate
-with property identifiers and operating-agreement data. This ERC is not limited
-to real estate or ERC-721 and does not prescribe asset-specific operations.
-
 [ERC-3643](./eip-3643.md) and [ERC-7943](./eip-7943.md) define token behavior and
 compliance-related interfaces. They do not define the registry-scoped
 token-to-anchor relationship specified here. Tokens implementing either can
@@ -656,7 +657,8 @@ governance, timelock, or equivalent controls. Consumers should monitor
 
 Releasing an invalidated tuple does not change an immutable token-side anchor
 declaration. A replacement can be mutually declared only when the token already
-declares the replacement anchor or does not expose a token-side interface.
+declares the replacement anchor. A replacement binding recorded for a token that
+does not expose a token-side interface is registry-side only.
 
 ### Document Canonicalization