Update ERC-2135: fix some typos

ERCS/erc-2135.md

@@ -157,7 +157,7 @@ Compliant contracts should pay attention to the balance change when a token is c
 When the contract is being paused, or the user is being restricted from transferring a token,
 the consumeability should be consistent with the transferral restriction.
 
-Compliant contracts should also carefully define access control, particularlly whether any EOA or contract account may or may not initiate a `consume` method in their own use case.
+Compliant contracts should also carefully define access control, particularly whether any EOA or contract account may or may not initiate a `consume` method in their own use case.
 
 Security audits and tests should be used to verify that the access control to the `consume`
 function behaves as expected.

ERCS/erc-2615.md

@@ -10,30 +10,30 @@
 requires: 165, 721
 ---
 
 ## Simple Summary
 
 This standard proposes an extension to ERC721 Non-Fungible Tokens (NFTs) to support rental and mortgage functions. These functions are necessary for NFTs to emulate real property, just like those in the real world.
 
 ## Abstract
 
 This standard is an extension of ERC721. It proposes additional roles, the right of tenants to enable rentals, and the right of lien.
 
 With ERC2615, NFT owners will be able to rent out their NFTs and take out a mortgage by collateralizing their NFTs. For example, this standard can apply to:
 
 - Virtual items (in-game assets, virtual artwork, etc.)
 - Physical items (houses, automobiles, etc.)
 - Intellectual property rights
 - DAO membership tokens
 
 NFT developers are also able to easily integrate ERC2615 since it is fully backwards-compatible with the ERC721 standard.
 
 One notable point is that the person who has the right to use an application is not the owner but the user (i.e. tenant). Application developers must implement this specification into their applications.
 
 ## Motivation
 
 It has been challenging to implement rental and mortgage functions with the ERC721 standard because it only has one role defined (which is the Owner).
 
 Currently, a security deposit is needed for trustless renting with ERC721, and ownership lockup within a contract is necessary whenever one chooses to mortgage their ERC721 property. The tracking and facilitation of these relationships must be done separately from the ERC721 standard.
 
 This proposal eliminates these requirements by integrating basic rights of tenantship and liens. By standardizing these functions, developers can more easily integrate rental and mortgage functions for their applications.
 
@@ -54,7 +54,7 @@
 - A **User** has the right to:
   1. Transfer the **User** role
 
 ### ERC-2615 Interface
 
 ```solidity
 event TransferUser(address indexed from, address indexed to, uint256 indexed itemId, address operator);
@@ -97,13 +97,13 @@
 function revokeTenantRight(uint256 itemId) public;
 ```
 
 ### ERC-2615 Receiver
 
 ```solidity
 function onERCXReceived(address operator, address from, uint256 itemId, uint256 layer, bytes memory data) public returns(bytes4);
 ```
 
 ### ERC-2615 Extensions
 
 Extensions here are provided to help developers build with this standard.
 
@@ -229,7 +229,7 @@
 
 ## Implementation
 
-[Github Reposotory](https://github.com/kohshiba/ERC-X).
+[Github Repository](https://github.com/kohshiba/ERC-X).
 
 ## Security Considerations
 

ERCS/erc-4527.md

@@ -127,7 +127,7 @@ chain-code-bytes = bytes .size 32
 
 If the chain-code is provided, then it can be used to derive child keys but if it isn’t provided, it is simply a solo key and the origin can be provided to indicate the derivation key path.
 
-If the signer would like to provide muliple public keys instead of the extended public key for any reason, the signer can use `crypto-account` for that.
+If the signer would like to provide multiple public keys instead of the extended public key for any reason, the signer can use `crypto-account` for that.
 
 ### Sending the unsigned data from the watch-only wallet to the offline signer
 

ERCS/erc-5023.md

@@ -28,7 +28,7 @@ Typical NFT standards such as EIP-721 and EIP-1155 do not define a sharing modal
 
 Sharing is an interesting concept as it can be thought and perceived in different ways. For example, when we talk about sharing we can think about it is as digital copying, giving a copy of a digital resource while retaining a version by ourselves. Sharing can also be fractional or sharing could be about giving rights to use a certain resource. The concept of shareability and the context of shareability can take different forms and one might use different types of implementatins for instances of shareable tokens. Hence we haven't restricted that the interface should require any specific token type.
 
-Shareable tokens can be made non-transferable at the contract implementaiton level. Doing so, makes them shareable non-transferable tokens. In the reference implementation we have distilled a general case from our use cases that defines a shareable non-transferable NFTs using the shareable NFT interface.
+Shareable tokens can be made non-transferable at the contract implementation level. Doing so, makes them shareable non-transferable tokens. In the reference implementation we have distilled a general case from our use cases that defines a shareable non-transferable NFTs using the shareable NFT interface.
 
 We believe that the wider audience should benefit from an abstraction level higher definition for shareability, such as this interface implementation, that defines minimum amount of functions that would be implemented to satisfy the concept of shareability.
 
@@ -49,11 +49,11 @@ interface IERC5023 is IERC165 {
 } 
 ```
 
-The Share event is expected to be emitted when function method share is succesfully called and a new token on basis of a given token id is minted and transferred to a recipient.
+The Share event is expected to be emitted when function method share is successfully called and a new token on basis of a given token id is minted and transferred to a recipient.
 
 ## Rationale
 
-Current NFT standards define transferable non-fungible tokens, but not shareable non-fungible tokens. To be able to create shareable NFTs we see that existing NFT contracts could be extended with an interface which defines the basic principles of sharing, namely the Event of sharing and the function method of sharing. Definition of how transferability of tokens should be handled is left to the contract implementor. In case transfering is left enable shareable tokens behave similarily to the existing tokens, except when they are shared, a version of token is retained. In case transfering is disabled, shareable tokens become shareable non-transferable tokens, where they can be minted and given or shared to other people, but they cannot be transferred away.
+Current NFT standards define transferable non-fungible tokens, but not shareable non-fungible tokens. To be able to create shareable NFTs we see that existing NFT contracts could be extended with an interface which defines the basic principles of sharing, namely the Event of sharing and the function method of sharing. Definition of how transferability of tokens should be handled is left to the contract implementor. In case transferring is left enable shareable tokens behave similarly to the existing tokens, except when they are shared, a version of token is retained. In case transfering is disabled, shareable tokens become shareable non-transferable tokens, where they can be minted and given or shared to other people, but they cannot be transferred away.
 
 Imagine that Bob works together with Alice on a project. Bob earns an unique NFT indicating that he has made effort to the project, but Bob feels that his accomplishments are not only out of his own accord. Bob wants to share his token with Alice to indicate that also Alice deserves recognition of having put effort on their project. Bob initiates token sharing by calling `Share` method on the contract which has his token and indicates which one of his tokens he wishes to share and to whom by passing address and token id parameters. A new token is minted for Alice and a `Share` event is initiated to communicate that it was Bob whom shared his token to Alice by logging addresses who shared a token id to whose address and which token id was this new token derived from.
 

ERCS/erc-5252.md

@@ -13,7 +13,7 @@ requires: 20, 721, 1155, 5114
 
 ## Abstract
 
-This EIP proposes a form of smart contract design pattern and a new type of account abstraction on how one's finance should be managed, ensuring transparency of managing investments and protection with self-sovereignty even from its financial operators. This EIP enables greater self-sovereignty of one's assets using a personal finance contract for each individual. The seperation between an investor's funds and the operation fee is clearly specified in the personal smart contract, so investors can ensure safety from arbitrary loss of funds by the operating team's control.
+This EIP proposes a form of smart contract design pattern and a new type of account abstraction on how one's finance should be managed, ensuring transparency of managing investments and protection with self-sovereignty even from its financial operators. This EIP enables greater self-sovereignty of one's assets using a personal finance contract for each individual. The separation between an investor's funds and the operation fee is clearly specified in the personal smart contract, so investors can ensure safety from arbitrary loss of funds by the operating team's control.
 
 This EIP extends [ERC-5114](./eip-5114.md) to further enable transferring fund to other accounts for mobility between managing multiple wallets.
 

ERCS/erc-5521.md

@@ -69,7 +69,7 @@ interface IERC_5521 is IERC165 {
     /// - the size of `addresses` **MUST** be the same as that of `tokenIds`;
     /// - once the size of `tokenIds` is non-zero, the inner size **MUST** also be non-zero;
     /// - the `tokenId` **MUST** be unique within the same contract;
-    /// - the `tokenId` **MUST NOT** be the same as `tokenIds[i][j]` if `addresses[i]` is essentailly `address(this)`.
+    /// - the `tokenId` **MUST NOT** be the same as `tokenIds[i][j]` if `addresses[i]` is essentially `address(this)`.
     function setNode(uint256 tokenId, address[] memory addresses, uint256[][] memory tokenIds) external;
 
     /// @notice get the referring list of an rNFT.

ERCS/erc-6105.md

@@ -150,7 +150,7 @@ interface IERC6105 {
 }
 ```
 
-### Optional collection offer extention
+### Optional collection offer extension
 
 ```solidity
 /// The collection offer extension is OPTIONAL for ERC-6105 smart contracts. This allows smart contract to support collection offer functionality.
@@ -225,7 +225,7 @@ interface IERC6105CollectionOffer {
 }
 ```
 
-### Optional item offer extention
+### Optional item offer extension
 
 ```solidity
 /// The item offer extension is OPTIONAL for ERC-6105 smart contracts. This allows smart contract to support item offer functionality.

ERCS/erc-6120.md

@@ -584,7 +584,7 @@ contract UniversalTokenRouter is ERC165, IUniversalTokenRouter {
     }
 
     /// Discard a part of a pending payment. Can be called from the input.action
-    /// to verify the payment without transfering any token.
+    /// to verify the payment without transferring any token.
     /// @param payment encoded payment data
     /// @param amount token amount to pay with payment
     function discard(bytes memory payment, uint256 amount) public virtual override {