Refactor links to erc-* filenames

ERCS/erc-6956.md

@@ -13,7 +13,7 @@ requires: 165, 721
 
 ## Abstract
 
-This standard allows integrating physical and digital ASSETS without signing capabilities into dApps/web3 by extending [ERC-721](eip-721.md).
+This standard allows integrating physical and digital ASSETS without signing capabilities into dApps/web3 by extending [ERC-721](erc-721.md).
 
 An ASSET, for example a physical object, is marked with a uniquely identifiable ANCHOR. The ANCHOR is bound in a secure and inseparable manner 1:1 to an NFT on-chain - over the complete life cylce of the ASSET. 
 
@@ -23,11 +23,11 @@ The proposed ATTESTATION-authorized operations such as `transferAnchor(attestati
 
 Figure 1 shows the data flow of an ASSET-BOUND NFT transfer. The simplified system is utilizing a smartphone as user-device to interact with a physical ASSET and specify the `to`-address.
 
-![Figure 1: Sample system](../assets/eip-6956/img/erc6956_concept.svg)
+![Figure 1: Sample system](../assets/erc-6956/img/erc6956_concept.svg)
 
 ## Motivation
 
-The well-known [ERC-721](eip-721.md) establishes that NFTs may represent "ownership over physical properties [...] as well as digital collectables and even more abstract things such as responsibilities" - in a broader sense, we will refer to all those things as ASSETS, which typically have value to people.
+The well-known [ERC-721](erc-721.md) establishes that NFTs may represent "ownership over physical properties [...] as well as digital collectables and even more abstract things such as responsibilities" - in a broader sense, we will refer to all those things as ASSETS, which typically have value to people.
 
 ### The Problem
 
@@ -54,7 +54,7 @@ In this standard we propose to
 As 2. and 3. indicate, the control/ownership/possession of the ASSET should be the single source of truth, *not* the possession of an NFT. Hence, we propose an ASSET-BOUND NFT, where off-chain CONTROL over the ASSET enforces on-chain CONTROL over the anchored NFT.
 Also the proposed ASSET-BOUND NFTs allow to anchor digital metadata inseperably to the ASSET. When the ASSET is a physical asset, this allows to design "phygitals" in their purest form, namely creating a "phygital" asset with a physical and digital component that are inseparable. Note that metadata itself can still change, for instance for "Evolvable NFT".
 
-We propose to complement the existing transfer control mechanisms of a token according to [ERC-721](eip-721.md) by another mechanism; ATTESTATION. An ATTESTATION is signed off-chain by the ORACLE and must only be issued when the ORACLE verified that whoever specifies the `to` address or beneficiary address has simultaneously been in control over the ASSET. The `to` address of an attestation may be used for Transfers as well as for approvals and other authorizations.
+We propose to complement the existing transfer control mechanisms of a token according to [ERC-721](erc-721.md) by another mechanism; ATTESTATION. An ATTESTATION is signed off-chain by the ORACLE and must only be issued when the ORACLE verified that whoever specifies the `to` address or beneficiary address has simultaneously been in control over the ASSET. The `to` address of an attestation may be used for Transfers as well as for approvals and other authorizations.
 
 Transactions authorized via ATTESTATION shall not require signature or approval from neither the `from` (donor, owner, sender) nor `to` (beneficiary, receiver) account, namely making transfers permissionless. Ideally, transaction are signed independent from the ORACLE as well, allowing different scenarios in terms of gas-fees.
 
@@ -90,7 +90,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 
 ### Base Interface
 
-Every contract compliant to this standard MUST implement the [the proposed standard interface](../assets/eip-6956/contracts/IERC6956.sol), [ERC-721](eip-721.md) and [ERC-165](eip-165.md) interfaces and is subject to [Caveats](#caveats-for-base-interface) below:
+Every contract compliant to this standard MUST implement the [the proposed standard interface](../assets/erc-6956/contracts/IERC6956.sol), [ERC-721](erc-721.md) and [ERC-165](erc-165.md) interfaces and is subject to [Caveats](#caveats-for-base-interface) below:
 
 ```solidity
 // SPDX-License-Identifier: MIT OR CC0-1.0
@@ -216,7 +216,7 @@ interface IERC6956 {
      *  - Throws when attestation.to == ownerOf(tokenByAnchor(attestation.anchor))
      *  - Emits AnchorTransfer  
      *  
-     * @param attestation Attestation, refer EIP-6956 for details
+     * @param attestation Attestation, refer ERC-6956 for details
      * @param data Additional data, may be used for additional transfer-conditions, may be sent partly or in full in a call to safeTransferFrom
      * 
      */
@@ -236,7 +236,7 @@ interface IERC6956 {
      *  - Matches the behavior of ERC-721.approve(attestation.to, tokenByAnchor(attestation.anchor)).
      *  - Throws when ASSET is not authorized to approve.
      * 
-     * @param attestation Attestation, refer EIP-6956 for details 
+     * @param attestation Attestation, refer ERC-6956 for details 
      */
     function approveAnchor(bytes memory attestation, bytes memory data) external;
 
@@ -253,7 +253,7 @@ interface IERC6956 {
      *  - When using a centralized "gas-payer" recommended to implement IERC6956AttestationLimited.
      *  - Throws when ASSET is not authorized to burn
      * 
-     * @param attestation Attestation, refer EIP-6956 for details
+     * @param attestation Attestation, refer ERC-6956 for details
      */
     function burnAnchor(bytes memory attestation, bytes memory data) external;
 }
@@ -337,7 +337,7 @@ export async function minimalAttestationSample() {
 
 ### AttestationLimited-Interface
 
-Every contract compliant to this standard MAY implement the [proposed AttestationLimited interface](../assets/eip-6956/contracts/IERC6956AttestationLimited.sol) and is subject to [Caveats](#caveats-for-attestationlimited-interface) below:
+Every contract compliant to this standard MAY implement the [proposed AttestationLimited interface](../assets/erc-6956/contracts/IERC6956AttestationLimited.sol) and is subject to [Caveats](#caveats-for-attestationlimited-interface) below:
 
 ```solidity
 // SPDX-License-Identifier: MIT OR CC0-1.0
@@ -393,7 +393,7 @@ interface IERC6956AttestationLimited is IERC6956 {
 
 ### Floatable-Interface
 
-Every contract compliant to this extension MAY implement the proposed [Floatable interface](../assets/eip-6956/contracts/IERC6956Floatable.sol) and is subject to [Caveats](#caveats-for-floatable-interface) below:
+Every contract compliant to this extension MAY implement the proposed [Floatable interface](../assets/erc-6956/contracts/IERC6956Floatable.sol) and is subject to [Caveats](#caveats-for-floatable-interface) below:
 
 ```solidity
 // SPDX-License-Identifier: MIT OR CC0-1.0
@@ -447,7 +447,7 @@ If `floating(anchor)` returns true, the token identified by `tokenByAnchor(ancho
 
 ### ValidAnchors-Interface
 
-Every contract compliant to this extension MAY implement the proposed [ValidAnchors interface](../assets/eip-6956/contracts/IERC6956ValidAnchors.sol) and is subject to [Caveats](#caveats-for-validanchors-interface) below:
+Every contract compliant to this extension MAY implement the proposed [ValidAnchors interface](../assets/erc-6956/contracts/IERC6956ValidAnchors.sol) and is subject to [Caveats](#caveats-for-validanchors-interface) below:
 
 ```solidity
 // SPDX-License-Identifier: MIT OR CC0-1.0
@@ -498,15 +498,15 @@ Even if a (physical) ASSET is mass produced with fungible characteristics, each
 **Why is there a burnAnchor() and approveAnchor()?**
 Due to the permissionless nature ASSET-BOUND NFTs can even be transferred to or from any address. This includes arbitrary and randomly generated accounts (where the private key is unknown) and smart-contracts which would traditionally not support ERC-721 NFTs. Following that owning the ASSET must be equivalent to owning the NFT, this means that we also need to support ERC-721 operations like approval and burning in such instances through authorizing the operations with an attestation.
 
-**Implementation alternatives considered** Soulbound burn+mint combination, for example through Consensual Soulbound Tokens ([ERC-5484](eip-5484.md)). Disregarded because appearance is highly dubious, when the same asset is represented through multiple tokens over time. An predecessor of this EIP has used this approach and can be found deployed to Mumbai Testnet under address `0xd04c443913f9ddcfea72c38fed2d128a3ecd719e`.
+**Implementation alternatives considered** Soulbound burn+mint combination, for example through Consensual Soulbound Tokens ([ERC-5484](erc-5484.md)). Disregarded because appearance is highly dubious, when the same asset is represented through multiple tokens over time. An predecessor of this EIP has used this approach and can be found deployed to Mumbai Testnet under address `0xd04c443913f9ddcfea72c38fed2d128a3ecd719e`.
 
 **When should I implement AttestationLimited-Interface**
 Naturally, when your use-case requires each ASSET being transferable only a limited number of times. But also for security reasons, see [Security Considerations](#security-considerations)
 
 **Why is there the `IERC6956Floatable.FloatState` enum?** In order to allow gas-efficient implementation of floatAll(), which can be overruled by anchor-based floatability in all combinations. (See rationale for tokenId=0 above).
 
 **Why is there no `floating(tokenId)` function?**
-This would behave identically to an `isTransferable(tokenId,...)` mechanism proposed in many other EIPs (refer e.g. [ERC-6454](eip-6454.md)). Further, the proposed `floating(anchorByToken(tokenId))` can be used.
+This would behave identically to an `isTransferable(tokenId,...)` mechanism proposed in many other EIPs (refer e.g. [ERC-6454](erc-6454.md)). Further, the proposed `floating(anchorByToken(tokenId))` can be used.
 
 **Why are there different FloatingAuthorizations for start and stop?**
 Depending on the use-case, different roles should be able to start or stop floating. Note that for many applications the ISSUER may want to have control over the floatability of the collection.
@@ -536,7 +536,7 @@ Possession based use cases are covered by the standard interface `IERC6956`: The
 
 The use case matrix below shows which extensions and settings must (additionally to `IERC6956`!) be implemented for the example use-cases together with relevant configurations.
 
-Note that for `Lockable` listed in the table below, the proposed EIP can be extended with any Lock- or Lien-Mechanism known to extend for ERC-721, for example [ERC-5192](eip-5192.md) or [ERC-6982](eip-6982.md). We recommend to verify whether a token is locked in the `_beforeTokenTransfer()`-hook, as this is called from `safeTransferFrom()` as well as `transferAnchor()`, hence suitable to block "standard" ERC-721 transfers as well as the proposed attestation-based transfers.
+Note that for `Lockable` listed in the table below, the proposed EIP can be extended with any Lock- or Lien-Mechanism known to extend for ERC-721, for example [ERC-5192](erc-5192.md) or [ERC-6982](erc-6982.md). We recommend to verify whether a token is locked in the `_beforeTokenTransfer()`-hook, as this is called from `safeTransferFrom()` as well as `transferAnchor()`, hence suitable to block "standard" ERC-721 transfers as well as the proposed attestation-based transfers.
 
 | Use Case | approveAuthorization | burnAuthorization | `IERC6956Floatable` | `IERC6956AttestationLimited` | Lockable |
 |---------------|---|---|---|---|---|
@@ -564,7 +564,7 @@ No backward compatibility issues found.
 
 This EIP is fully compatible with ERC-721 and (when extended with the `IERC6956Floatable`-interface) corresponds to the well-known ERC-721 behavior with an additional authorization-mechanism via attestations. Therefore we recommend - especially for physical assets - to use the present EIP instead of ERC-721 and amend it with extensions designed for ERC-721.
 
-However, it is RECOMMENDED to extend implementations of the proposed standard with an interface indicating transferability of NFTs for market places. Examples include [ERC-6454](eip-6454.md) and [ERC-5484](eip-5484.md).
+However, it is RECOMMENDED to extend implementations of the proposed standard with an interface indicating transferability of NFTs for market places. Examples include [ERC-6454](erc-6454.md) and [ERC-5484](erc-5484.md).
 
 Many ERC-721 extensions suggest to add additional throw-conditions to transfer methods. This standard is fully compatible, as
 
@@ -575,13 +575,13 @@ Many ERC-721 extensions suggest to add additional throw-conditions to transfer m
 
 Test cases are available:
 
-- For only implementing [the proposed standard interface](../assets/eip-6956/contracts/IERC6956.sol) can be found [here](../assets/eip-6956/test/ERC6956.ts)
-- For implementing [the proposed standard interface](../assets/eip-6956/contracts/IERC6956.sol), [the Floatable extension](../assets/eip-6956/contracts/IERC6956Floatable.sol), [the ValidAnchors extension](../assets/eip-6956/contracts/IERC6956ValidAnchors.sol) and [the AttestationLimited extension](../assets/eip-6956/contracts/IERC6956AttestationLimited.sol) can be found [here](../assets/eip-6956/test/ERC6956Full.ts)
+- For only implementing [the proposed standard interface](../assets/erc-6956/contracts/IERC6956.sol) can be found [here](../assets/erc-6956/test/ERC6956.ts)
+- For implementing [the proposed standard interface](../assets/erc-6956/contracts/IERC6956.sol), [the Floatable extension](../assets/erc-6956/contracts/IERC6956Floatable.sol), [the ValidAnchors extension](../assets/erc-6956/contracts/IERC6956ValidAnchors.sol) and [the AttestationLimited extension](../assets/erc-6956/contracts/IERC6956AttestationLimited.sol) can be found [here](../assets/erc-6956/test/ERC6956Full.ts)
 
 ## Reference Implementation
 
-- Minimal implementation, only supporting [the proposed standard interface](../assets/eip-6956/contracts/IERC6956.sol) can be found [here](../assets/eip-6956/contracts/ERC6956.sol)
-- Full implementation, with support for [the proposed standard interface](../assets/eip-6956/contracts/IERC6956.sol), [the Floatable extension](../assets/eip-6956/contracts/IERC6956Floatable.sol), [the ValidAnchors extension](../assets/eip-6956/contracts/IERC6956ValidAnchors.sol) and [the AttestationLimited extension](../assets/eip-6956/contracts/IERC6956AttestationLimited.sol) can be found [here](../assets/eip-6956/contracts/ERC6956Full.sol)
+- Minimal implementation, only supporting [the proposed standard interface](../assets/erc-6956/contracts/IERC6956.sol) can be found [here](../assets/erc-6956/contracts/ERC6956.sol)
+- Full implementation, with support for [the proposed standard interface](../assets/erc-6956/contracts/IERC6956.sol), [the Floatable extension](../assets/erc-6956/contracts/IERC6956Floatable.sol), [the ValidAnchors extension](../assets/erc-6956/contracts/IERC6956ValidAnchors.sol) and [the AttestationLimited extension](../assets/erc-6956/contracts/IERC6956AttestationLimited.sol) can be found [here](../assets/erc-6956/contracts/ERC6956Full.sol)
 
 ## Security Considerations