From 4b91b4aa000cb6726ca9e01328b76fc42742a683 Mon Sep 17 00:00:00 2001 From: rustrover Date: Sat, 9 Mar 2024 15:07:42 +0800 Subject: [PATCH] fix some typos Signed-off-by: rustrover --- ERCS/erc-2135.md | 2 +- ERCS/erc-2615.md | 2 +- ERCS/erc-4527.md | 2 +- ERCS/erc-5023.md | 6 +++--- ERCS/erc-5252.md | 2 +- ERCS/erc-5521.md | 2 +- ERCS/erc-6105.md | 4 ++-- ERCS/erc-6120.md | 2 +- 8 files changed, 11 insertions(+), 11 deletions(-) diff --git a/ERCS/erc-2135.md b/ERCS/erc-2135.md index 75820e7731..0a7a9e0ac2 100644 --- a/ERCS/erc-2135.md +++ b/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. diff --git a/ERCS/erc-2615.md b/ERCS/erc-2615.md index 9191c801c6..75b65e2eff 100644 --- a/ERCS/erc-2615.md +++ b/ERCS/erc-2615.md @@ -229,7 +229,7 @@ Powered by Truffle and Openzeppelin test helper. ## Implementation -[Github Reposotory](https://github.com/kohshiba/ERC-X). +[Github Repository](https://github.com/kohshiba/ERC-X). ## Security Considerations diff --git a/ERCS/erc-4527.md b/ERCS/erc-4527.md index bd99e2dfce..ae9291d594 100644 --- a/ERCS/erc-4527.md +++ b/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 diff --git a/ERCS/erc-5023.md b/ERCS/erc-5023.md index c3e36b57e2..d7b71cfd9e 100644 --- a/ERCS/erc-5023.md +++ b/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. diff --git a/ERCS/erc-5252.md b/ERCS/erc-5252.md index a948f908c3..95ef2451e3 100644 --- a/ERCS/erc-5252.md +++ b/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. diff --git a/ERCS/erc-5521.md b/ERCS/erc-5521.md index d0839a8b50..200df9ca7c 100644 --- a/ERCS/erc-5521.md +++ b/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. diff --git a/ERCS/erc-6105.md b/ERCS/erc-6105.md index 5c30480c1c..7e63bf7554 100644 --- a/ERCS/erc-6105.md +++ b/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. diff --git a/ERCS/erc-6120.md b/ERCS/erc-6120.md index 7161c151c9..88c40a9aaa 100644 --- a/ERCS/erc-6120.md +++ b/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 {