Update ERC-6358: Fix links (#124)

* Update erc-7092.md

* Update erc-6358.md

* Update erc-7439.md

* Update erc-7066.md

ERCS/erc-6358.md

@@ -16,7 +16,7 @@ This ERC standardizes an interface for contract-layer consensus-agnostic verifia
 
 ### Figure.1 Architecture
 
-![img](../assets/erc-6358/img/o-dlt.png)    
+![img](../assets/eip-6358/img/o-dlt.png)    
 
 With this ERC, we can create a global token protocol, that leverages smart contracts or similar mechanisms on existing blockchains to record the token states synchronously. The synchronization could be made by trustless off-chain synchronizers.
 

ERCS/erc-7066.md

@@ -14,17 +14,17 @@ requires: 165, 721
 
 ## Abstract
 
-An extension of [ERC-721](./erc-721.md), this standard incorporates `locking` features into NFTs, allowing for various uses while preventing sale or transfer. The token's `owner` can `lock` it, setting up locker address (either an EOA or a contract) that exclusively holds the power to unlock the token. Owner can also provide approval for `tokenId`, enabling ability to lock asset while address holds the token approval. Token can also be locked by `approved`, assigning locker to itself. Upon token transfer, these rights get purged.
+An extension of [ERC-721](./eip-721.md), this standard incorporates `locking` features into NFTs, allowing for various uses while preventing sale or transfer. The token's `owner` can `lock` it, setting up locker address (either an EOA or a contract) that exclusively holds the power to unlock the token. Owner can also provide approval for `tokenId`, enabling ability to lock asset while address holds the token approval. Token can also be locked by `approved`, assigning locker to itself. Upon token transfer, these rights get purged.
 
 ## Motivation
 
-[ERC-721](./erc-721.md) has sparked an unprecedented surge in demand for NFTs. However, despite this tremendous success, the NFT economy suffers from secondary liquidity where it remains illiquid in owner’s wallet. There are projects which aim to address the liquidity challenge, but they entail the below mentioned inconveniences and risks for owners as they necessitate transferring the participating NFTs to the projects' contracts.
+[ERC-721](./eip-721.md) has sparked an unprecedented surge in demand for NFTs. However, despite this tremendous success, the NFT economy suffers from secondary liquidity where it remains illiquid in owner’s wallet. There are projects which aim to address the liquidity challenge, but they entail the below mentioned inconveniences and risks for owners as they necessitate transferring the participating NFTs to the projects' contracts.
 
 - Loss of utility: The utility value of NFTs diminishes when they are transferred to an escrow account, no longer remaining under the direct custody of the owners.
 - Lack of composability: The market could benefit from increased liquidity if NFT owners had access to multiple financial tools, such as leveraging loans and renting out their assets for maximum returns. Composability serves as the missing piece in creating a more efficient market.
 - Smart contract vulnerabilities: NFTs are susceptible to loss or theft due to potential bugs or vulnerabilities present in the smart contracts they rely on.
 
-The aforementioned issues contribute to a poor user experience (UX), and we propose enhancing the [ERC-721](./erc-721.md) standard by implementing a native locking mechanism: 
+The aforementioned issues contribute to a poor user experience (UX), and we propose enhancing the [ERC-721](./eip-721.md) standard by implementing a native locking mechanism: 
 Rather than being transferred to a smart contract, an NFT remains securely stored in self-custody but is locked. 
 During the lock period, the NFT's transfer is restricted while its other properties remain unchanged. 
 NFT Owner retains the ability to use or distribute it’s utility.
@@ -48,15 +48,15 @@ This proposal is different from other locking proposals in number of ways:
 - This implementation proposes a separation of rights between locker and approver. Token can be locked with approval and approved can unlock and withdraw tokens (opening up opportunities like renting, lending, BNPL etc), and token can be locked lacking the rights to revoke token, yet can unlock if required (opening up opportunities like account-bound NFTs).
 - Our proposal implement ability to `transferAndLock` which can be used to transfer, lock and optionally approve token. Enabling the possibility of revocation after transfer.
 
-By extending the [ERC-721](./erc-721.md) standard, the proposed standard enables secure and convenient management of underlying NFT assets. It natively supports prevalent NFTFi use cases such as staking, lending, and renting. We anticipate that this proposed standard will foster increased engagement of NFT owners in NFTFi projects, thereby enhancing the overall vitality of the NFT ecosystem.
+By extending the [ERC-721](./eip-721.md) standard, the proposed standard enables secure and convenient management of underlying NFT assets. It natively supports prevalent NFTFi use cases such as staking, lending, and renting. We anticipate that this proposed standard will foster increased engagement of NFT owners in NFTFi projects, thereby enhancing the overall vitality of the NFT ecosystem.
 
 ## Specification
 
 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 and RFC 8174.
 
 ### Overview
 
-[ERC-721](./erc-721.md) compliant contracts MAY implement this EIP to provide standard methods of locking and unlocking the token at its current owner address. 
+[ERC-721](./eip-721.md) compliant contracts MAY implement this EIP to provide standard methods of locking and unlocking the token at its current owner address. 
 
 Token owner MAY `lock` the token and assign `locker` to some `address` using `lock(uint256 tokenId, address _locker)` function, this MUST set `locker` to `_locker`. Token owner or approved MAY `lock` the token using `lock(uint256 tokenId)` function, this MUST set `locker` to `msg.sender`. Token MAY be `unlocked` by `locker` using `unlock` function. `unlock` function MUST delete `locker` mapping and default to `address(0)`.
 
@@ -127,23 +127,23 @@ This proposal exposes `transferAndLock(uint256 tokenId, address from, address to
 
 ## Backwards Compatibility
 
-This standard is compatible with [ERC-721](./erc-721.md) standards.
+This standard is compatible with [ERC-721](./eip-721.md) standards.
 
-Existing Upgradedable [ERC-721](./erc-721.md) can upgrade to this standard, enabling locking capability inherently and unlock underlying liquidity features.
+Existing Upgradedable [ERC-721](./eip-721.md) can upgrade to this standard, enabling locking capability inherently and unlock underlying liquidity features.
 
 ## Test Cases
 
-Test cases can be found [here](../assets/erc-7066/test/test.js).
+Test cases can be found [here](../assets/eip-7066/test/test.js).
 
 ## Reference Implementation
 
-Reference Interface can be found [here](../assets/erc-7066/IERC7066.sol).
+Reference Interface can be found [here](../assets/eip-7066/IERC7066.sol).
 
-Reference Implementation can be found [here](../assets/erc-7066/ERC7066.sol).
+Reference Implementation can be found [here](../assets/eip-7066/ERC7066.sol).
 
 ## Security Considerations
 
-There are no security considerations related directly to the implementation of this standard for the contract that manages [ERC-721](./erc-721.md).
+There are no security considerations related directly to the implementation of this standard for the contract that manages [ERC-721](./eip-721.md).
 
 ### Considerations for the contracts that work with lockable tokens
 

ERCS/erc-7092.md

@@ -17,13 +17,13 @@ This proposal introduces fixed-income financial bonds with key characteristics d
 
 ## Motivation
 
-Fixed-income instruments are a widely utilized asset class for corporations and other entities raising funds. However, transitioning to tokenized bonds is challenging due to existing standards like [ERC-3475](./erc-3475.md), which introduces unfamiliar concepts and leads to unnecessary gas consumption. Additionally, the lack of named variables like coupon, maturity date, and principal, makes it difficult to implement ERC-3475 since developers need to remember which metadata is assigned to each parameter.
+Fixed-income instruments are a widely utilized asset class for corporations and other entities raising funds. However, transitioning to tokenized bonds is challenging due to existing standards like [ERC-3475](./eip-3475.md), which introduces unfamiliar concepts and leads to unnecessary gas consumption. Additionally, the lack of named variables like coupon, maturity date, and principal, makes it difficult to implement ERC-3475 since developers need to remember which metadata is assigned to each parameter.
 
 ## Specification
 
 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 and RFC 8174.
 
-**Every contract compliant with this ERC MUST implement the following Token Interface as well as the [ERC-165](./erc-165.md) interface:**
+**Every contract compliant with this ERC MUST implement the following Token Interface as well as the [ERC-165](./eip-165.md) interface:**
 
 ```solidity
 // SPDX-License-Identifier: CC0-1.0
@@ -410,14 +410,14 @@ The `totalSupply` and `balanceOf` functions are not defined as they can be deriv
 
 ## Backwards Compatibility
 
-This ERC is not backwards compatible with existing standards like [ERC-20](./erc-20.md) or [ERC-1155](./erc-1155.md) due to the absence of certain functions like `totalSupply` or `balanceOf`. A pure implementation of this standard is RECOMMENDED for issuing tokenized bonds, as any hybrid solution with other mentioned standards SHOULD fail.
+This ERC is not backwards compatible with existing standards like [ERC-20](./eip-20.md) or [ERC-1155](./eip-1155.md) due to the absence of certain functions like `totalSupply` or `balanceOf`. A pure implementation of this standard is RECOMMENDED for issuing tokenized bonds, as any hybrid solution with other mentioned standards SHOULD fail.
 
 
 ## Reference Implementation
 
-The complete Reference Implementation can be found [here](../assets/erc-7092/ERC7092.sol).
+The complete Reference Implementation can be found [here](../assets/eip-7092/ERC7092.sol).
 
-Bonds with embedded options like callable, puttable, or convertible bonds can be created by inheriting from the reference [`ERC7092.sol`](../assets/erc-7092/ERC7092.sol) that integrates the proposed interface.
+Bonds with embedded options like callable, puttable, or convertible bonds can be created by inheriting from the reference [`ERC7092.sol`](../assets/eip-7092/ERC7092.sol) that integrates the proposed interface.
 
 ### CALLABLE BONDS:
 

ERCS/erc-7439.md

@@ -124,13 +124,13 @@ Designing the proposal, we considered the following questions:
    * Easy to redeem. Before the show, the ticket agency can verify the ticket by the signature to confirm if the audience is genuine. `TokenStatus` needs to be equal to `sold`, and `expireTime` can distinguish whether the audience has arrived at the correct session. After verification is passed, the ticket agency can change the `TokenStatus` to `Redeemed`.
 
    * Normal Flow
-        ![Alt text](../assets/erc-7439/normal.png)
+        ![Alt text](../assets/eip-7439/normal.png)
 
    * Void Flow
-        ![Alt text](../assets/erc-7439/void.png)
+        ![Alt text](../assets/eip-7439/void.png)
 
    * Resell Flow
-        ![Alt text](../assets/erc-7439/resell.png)
+        ![Alt text](../assets/eip-7439/resell.png)
 
 ## Backwards Compatibility