typos

ethereum · Aug 4, 2022 · 999a28e · 999a28e
1 parent cb5dbb5
commit 999a28e
Showing 1 changed file with 5 additions and 5 deletions.
diff --git a/EIPS/eip-eip-1155-ownerof.md b/EIPS/eip-eip-1155-ownerof.md
@@ -1,7 +1,7 @@
 ---
 eip: xxxx
-title: EIP-1155 Non Fungible Token extension
-description: Allow EIP-1155 to represent Non Fungible Tokens (token who have a unique owner)
+title: EIP-1155 Non-Fungible Token extension
+description: Allow EIP-1155 to represent Non-Fungible Tokens (tokens who have a unique owner)
 author: Ronan Sandford (@wighawag)
 discussions-to: https://ethereum-magicians.org/t/eip-1155-ownerof
 status: Draft
@@ -17,9 +17,9 @@ This standard is an extension of [EIP-1155](./eip-1155.md). It proposes an addit
 
 ## Motivation
 
-Currently, EIP-1155 do not allow an external caller to detect whether a token is truly unique (can have only one owner) or fungible. This is because EIP-1155 do not expose a mechanism to detect whether a token will have its supply remain to be "1". Furthermore, it does not let an external caller retrieve the owner directly on-chain.
+Currently, EIP-1155 does not allow an external caller to detect whether a token is truly unique (can have only one owner) or fungible. This is because EIP-1155 do not expose a mechanism to detect whether a token will have its supply remain to be "1". Furthermore, it does not let an external caller retrieve the owner directly on-chain.
 
-The EIP-1155 spec does mention the use of splitted id to represent non fungible tokens but this require a pre-established convention which is not part of the standard. Plus it would not be as fully featured as the `ownerOf` function also present in the EIP-721 standard.
+The EIP-1155 spec does mention the use of split id to represent non-fungible tokens, but this requires a pre-established convention that is not part of the standard. Plus it would not be as fully featured as the `ownerOf` function also present in the EIP-721 standard.
 
 The ability to get the owner of a token offer great benefit, including the ability for the owner to associate data to it.
 
@@ -46,7 +46,7 @@ The `supportsInterface` method MUST return `true` when called with `0x6352211e`.
 
 ## Rationale
 
-Having the ability to fetch the owner for EIP-1155 token that have one, allow to use them in most of the EIP-721 ecosystem, without the need to implement the whole EIP-721 spec which comes with inefficiencies.
+Having the ability to fetch the owner for EIP-1155 tokens that have one, allows us to use them in most of the EIP-721 ecosystem, without the need to implement the whole EIP-721 spec which comes with inefficiencies.
 
 `ownerOf` do not throw when a token does not exist (or does not have an owner). This simplifies the handling of such a case. And since it would be a security risk to assume all ERC721 implementation would throw, it should not break compatibility with contract handling ERC721 when dealing with this ERC1155 extension.