ci: add CI workflow to check for grammar errors

.github/workflows/spellcheck.yaml

@@ -0,0 +1,28 @@
+# This workflow checks for common grammar and spelling mistake in markdown files.
+name: Spellcheck
+on: [pull_request]
+
+jobs:
+  build:
+    name: Check Grammar and Spelling errors
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout 🛎️
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - name: Install ⚙️
+        run: yarn install --frozen-lockfile
+
+      - name: Check spelling errors in code snippets 🔍
+        uses: codespell-project/actions-codespell@v2
+        with:
+          check_filenames: true
+          ignore_words_list: datas
+
+      - name: Output Spellcheck Results 📝
+        uses: actions/upload-artifact@v3
+        with:
+          name: Spellcheck Output
+          path: spellcheck-output.txt

CONTRIBUTING.md

@@ -27,7 +27,7 @@ The goal of this process is to iterate over the initial idea and refine:
 - what are the benefits of the LSP and what are the problems that it solves.
 - clarify limitations, security and areas of concerns related to the proposed standard.
 
-### 2. Creating an issue in the LIP reposity
+### 2. Creating an issue in the LIP repository
 
 **Before proposing an LSP on this repository via a PR, ideas MUST be thoroughly discussed through an issue.**
 
@@ -44,7 +44,7 @@ Once consensus is reached in the issue discussion, thoroughly review the LIP tem
 3.  Add your LIP to your fork of the repository. There is a [template LSP here](lsp-X.md).
 4.  Submit a Pull Request to LUKSO's [LSPs repository](https://github.com/lukso-network/LIPs).
 
-Your first PR should be a first draft of the final LSP. It must meet the following formatting criterias:
+Your first PR should be a first draft of the final LSP. It must meet the following formatting criteria:
 
 - Correct metadata in the header, as described in the [LSP template](lsp-x.md).
 - Make sure you include a `discussions-to` header with the URL to a discussion forum or open GitHub issue where people can discuss the LSP as a whole.

LSPs/LSP-0-ERC725Account.md

@@ -65,7 +65,7 @@ Adopting smart contract accounts over traditional EOAs streamlines blockchain in
 
 - **Dynamic Information Storage**: Unlike EOAs, smart contract accounts can record static information, making them self-explanatory entities that can assist in identity verification for off-chain entities, and enable the decentralized tracking of any information stored such as assets, followers, etc. The information stored can also be standardized, for example [LSP3-Profile-Metadata] for storing profile information, [LSP5-ReceivedAssets] for storing the addresses of received assets, and [LSP10-ReceivedVaults] for storing addresses of received vaults, etc ..
 
-- **Upgradeable Security**: Owners can use a simple EOA for owning the account having basic level of security, or opt for an owner having a multisignature setup, or permissions access control contracts providing advanced layer of security in contorlling the account.
+- **Upgradeable Security**: Owners can use a simple EOA for owning the account having basic level of security, or opt for an owner having a multisignature setup, or permissions access control contracts providing advanced layer of security in controlling the account.
 
 - **Inclusive Control**: Users can decide to own the account with a permission based access control contract (e.g: the [LSP6-KeyManager]) which allows owners to assign specific rights to different actors, like granting a party the right to update profile information without providing full transactional authority.
 
@@ -109,15 +109,15 @@ However, in alignment with the [LSP20-CallVerification] standard, these owner-ex
 
 For example, if the caller address is not the owner, the function will call the `lsp20VerifyCall(..)` on the owner address function to validate the transaction before execution passing the following arguments:
 
-- `requestor`: The address calling the function to be executed.
+- `requester`: The address calling the function to be executed.
 - `target`: The address of the account.
 - `caller`: The address calling the function to be executed.
 - `value`: The value sent by the caller to the function called on the account.
 - `receivedCalldata`: The calldata sent by the caller to the account.
 
 The expected outcome is for the `bytes4` returned value to match the first `bytes3` of the function selector of `lsp20VerifyCall` for the operation to proceed. Specifically, if the fourth byte of the call is `0x01`, the function MUST call `lsp20VerifyCallResult` after execution of the function passing the following arguments:
 
-- `callHash`: The `keccak256` hash of the parameters of `lsp20VerifyCall(address,address,address,uint256,bytes)` parameters packed-encoded (concatened).
+- `callHash`: The `keccak256` hash of the parameters of `lsp20VerifyCall(address,address,address,uint256,bytes)` parameters packed-encoded (concatenated).
 
 - `callResult`: the result of the function being called on the account.
   - if the function being called returns some data, the `callResult` MUST be the value returned by the function being called as abi-encoded `bytes`.
@@ -131,7 +131,7 @@ The function designated to be called by the pending owner is:
 
 - `acceptOwnership()`
 
-The same logic applies to `acceptOwnership` function, expcet that it should be either called by the pending owner or an address allowed by the pending owner. In case the caller is not the pending owner, the verification should happen according to the [LSP20-CallVerification] on the address of the pending owner.
+The same logic applies to `acceptOwnership` function, except that it should be either called by the pending owner or an address allowed by the pending owner. In case the caller is not the pending owner, the verification should happen according to the [LSP20-CallVerification] on the address of the pending owner.
 
 > Read more about the [Rational behind using LSP20-CallVerifiaction](#lsp20-callverification-usage) in the LSP0-ERC725Account standard.
 

LSPs/LSP-1-UniversalReceiver.md

@@ -78,7 +78,7 @@ _Returns:_ `bytes` which can be used to encode response values.
 event UniversalReceiver(address indexed from, uint256 indexed value, bytes32 indexed typeId, bytes receivedData, bytes returnedValue);
 ```
 
-This event MUST be emitted when the `universalReceiver` function is succesfully executed.
+This event MUST be emitted when the `universalReceiver` function is successfully executed.
 
 _Values:_
 
@@ -100,10 +100,10 @@ UniversalReceiver delegation allows to forward the `universalReceiver(..)` call
 
 The ability to react to upcoming actions with a logic hardcoded within the `universalReceiver(..)` function comes with limitations, as only a fixed functionality can be coded or the [`UniversalReceiver`](#universalreceiver-1) event be fired.
 
-This section explains a way to forward the call to the `universalReceiver(..)` function to an external smart contract to extend and change funcitonality over time.
+This section explains a way to forward the call to the `universalReceiver(..)` function to an external smart contract to extend and change functionality over time.
 
 The delegation works by simply forwarding a call to the `universalReceiver(..)` function to a delegated smart contract calling the `universalReceiverDelegate(..)` function on the external smart contract.
-As the external smart contract doesn't know about the inital `msg.sender` and the `msg.value`, this specification proposes to add these values as arguments. This allows the external contract to know the full context of the initial `universalReceiver` call and react accordingly.
+As the external smart contract doesn't know about the initial `msg.sender` and the `msg.value`, this specification proposes to add these values as arguments. This allows the external contract to know the full context of the initial `universalReceiver` call and react accordingly.
 
 ### Specification
 
@@ -181,7 +181,7 @@ An implementation can be found in the [lukso-network/lsp-smart-contracts] reposi
 
 ### UniversalReceiver Example:
 
-After transfering token from `TokenABC` to `MyWallet`, the owner of `MyWallet` contract can know, by looking at the emitted UniversalReceiver event, that the `typeId` is `_TOKEN_RECEIVING_HASH`.
+After transferring token from `TokenABC` to `MyWallet`, the owner of `MyWallet` contract can know, by looking at the emitted UniversalReceiver event, that the `typeId` is `_TOKEN_RECEIVING_HASH`.
 
 Enabling the owner to know the token sender address and the amount sent by looking into the `data`.
 
@@ -300,8 +300,8 @@ contract UniversalReceiverDelegate is ERC165, ILSP1 {
 
     function universalReceiverDelegate(address caller, uint256 value, bytes32 typeId, bytes memory data) public returns (bytes memory) {
         // Any logic could be written here:
-        // - Interfact with DeFi protocol contract to sell the new tokens received automatically.
-        // - Register the token received on other registery contract.
+        // - Interact with DeFi protocol contract to sell the new tokens received automatically.
+        // - Register the token received on other registry contract.
         // - Allow only tokens with `_TOKEN_RECEIVING_HASH` hash and reject the others.
         // - revert; so in this way the wallet will have the option to reject any token.
     }

LSPs/LSP-11-BasicSocialRecovery.md

@@ -182,7 +182,7 @@ _Requirements:_
 function selectNewController(address addressSelected) external
 ```
 
-Select an address to be a potentiel controller address if he reaches the guardian threshold and provide the correct plainSecret. MUST fire the [SelectedNewController](#selectednewcontroller) event.
+Select an address to be a potential controller address if he reaches the guardian threshold and provide the correct plainSecret. MUST fire the [SelectedNewController](#selectednewcontroller) event.
 
 _Parameters:_
 
@@ -252,7 +252,7 @@ MUST be emitted when changing the secret hash.
 event SelectedNewController(uint256 indexed currentRecoveryCounter, address indexed guardian, address indexed addressSelected);
 ```
 
-MUST be emitted when a guardian select a new potentiel controller address for the linked target.
+MUST be emitted when a guardian select a new potential controller address for the linked target.
 
 #### RecoveryProcessSuccessful
 

LSPs/LSP-12-IssuedAssets.md

@@ -1,7 +1,7 @@
 ---
 lip: 12
 title: Issued Assets
-author: Fabian Vogelsteller <fabian@lukso.network> 
+author: Fabian Vogelsteller <fabian@lukso.network>
 discussions-to: https://discord.gg/E2rJPP4
 status: Draft
 type: LSP
@@ -10,21 +10,23 @@ requires: LSP2
 ---
 
 ## Simple Summary
+
 This standard describes a set of [ERC725Y](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-725.md) data key values to store addresses of issued assets by an [ERC725X](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-725.md) smart contract.
 
 ## Abstract
-This data key value standard describes a set of data keys that can be added to an [ERC725Y](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-725.md) smart contract to describe issued assets:
 
+This data key value standard describes a set of data keys that can be added to an [ERC725Y](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-725.md) smart contract to describe issued assets:
 
 - `LSP12IssuedAssets[]` is an [LSP2 array](./LSP-2-ERC725YJSONSchema.md) of addresses.
 - `LSP12IssuedAssetsMap` is a dynamic address mapping, which contains:
   - an [ERC165 interface ID](https://eips.ethereum.org/EIPS/eip-165) to easily identify the standard used by the mapped asset smart contract
   - and the index in the `LSP12IssuedAssets[]` array.
 
-The data key `LSP12IssuedAssetsMap` exists so that smart contracts can detect if an address is present in the array (e.g. as done in the  [LSP1-UniversalReceiverDelegate](./LSP-1-UniversalReceiver.md)).
+The data key `LSP12IssuedAssetsMap` exists so that smart contracts can detect if an address is present in the array (e.g. as done in the [LSP1-UniversalReceiverDelegate](./LSP-1-UniversalReceiver.md)).
 
 ## Motivation
-This standard allows any smart contract to state that it issued a certain asset. The asset itself MUST reference the issuer smart contract as well, for it be verifable issued. This allows other smart contracts to link the authenticity of an asset to a specific issuer. See also [LSP4 - DigitalAsset Metadata](./LSP-4-DigitalAsset-Metadata.md) for the `owner` and `LSP4Creators[]`.
+
+This standard allows any smart contract to state that it issued a certain asset. The asset itself MUST reference the issuer smart contract as well, for it be verifiable issued. This allows other smart contracts to link the authenticity of an asset to a specific issuer. See also [LSP4 - DigitalAsset Metadata](./LSP-4-DigitalAsset-Metadata.md) for the `owner` and `LSP4Creators[]`.
 
 A full verification flow for an asset should contain a check on the asset and the issuer smart contract. If we use an asset using [LSP4 - DigitalAsset Metadata](./LSP-4-DigitalAsset-Metadata.md) and a [LSP0 - ERC725Account](./LSP-0-ERC725Account.md) as the issuer. The flow should looks as follows:
 
@@ -37,19 +39,17 @@ Every contract that supports the ERC725Account SHOULD have the following data ke
 
 ### ERC725Y Data Keys
 
-
 #### LSP12IssuedAssets[]
 
 An array of issued smart contract assets, like tokens (_e.g.: [LSP7 Digital Assets](./LSP-7-DigitalAsset)_) and NFTs (_e.g.: [LSP8 Identifiable Digital Assets](./LSP-8-IdentifiableDigitalAsset)_).
 
-
 ```json
 {
-    "name": "LSP12IssuedAssets[]",
-    "key": "0x7c8c3416d6cda87cd42c71ea1843df28ac4850354f988d55ee2eaa47b6dc05cd",
-    "keyType": "Array",
-    "valueType": "address",
-    "valueContent": "Address"
+  "name": "LSP12IssuedAssets[]",
+  "key": "0x7c8c3416d6cda87cd42c71ea1843df28ac4850354f988d55ee2eaa47b6dc05cd",
+  "keyType": "Array",
+  "valueType": "address",
+  "valueContent": "Address"
 }
 ```
 
@@ -60,18 +60,19 @@ For more info about how to access each index of the `LSP12IssuedAssets[]` array,
 References issued smart contract assets, like tokens (_e.g.: [LSP7 Digital Assets](./LSP-7-DigitalAsset)_) and NFTs (_e.g.: [LSP8 Identifiable Digital Assets](./LSP-8-IdentifiableDigitalAsset)_). This data key exists so that smart contracts can detect whether the address of an asset is present in the `LSP12IssuedAssets[]` array without looping all over it on-chain. Moreover, it helps to identify at which index in the `LSP12IssuedAssets[]` the asset address is located for easy access and to change or remove this specific asset from the array. Finally, it also allows the detection of the interface supported by the asset.
 
 The data value MUST be constructed as follows: `bytes4(standardInterfaceId) + uint128(indexNumber)`. Where:
+
 - `standardInterfaceId` = the [ERC165 interface ID](https://eips.ethereum.org/EIPS/eip-165) of the standard that the token or asset smart contract implements (if the ERC165 interface ID is unknown, `standardInterfaceId = 0xffffffff`).
 - `indexNumber` = the index in the [`LSP12IssuedAssets[]` Array](#LSP12Issuedassets)
 
 Value example: `0x5fcaac27000000000000000c` (interfaceId: `0x5fcaac27` for a [LSP7](./LSP-7-DigitalAsset.md) token, index position `0x000000000000000c = 12`).
 
 ```json
 {
-    "name": "LSP12IssuedAssetsMap:<address>",
-    "key": "0x74ac2555c10b9349e78f0000<address>",
-    "keyType": "Mapping",
-    "valueType": "(bytes4,uint128)",
-    "valueContent": "(Bytes4,Number)"
+  "name": "LSP12IssuedAssetsMap:<address>",
+  "key": "0x74ac2555c10b9349e78f0000<address>",
+  "keyType": "Mapping",
+  "valueType": "(bytes4,uint128)",
+  "valueContent": "(Bytes4,Number)"
 }
 ```
 
@@ -80,24 +81,26 @@ Value example: `0x5fcaac27000000000000000c` (interfaceId: `0x5fcaac27` for a [LS
 ## Implementation
 
 ERC725Y JSON Schema `LSP12IssuedAssets`:
+
 ```json
 [
-    {
-        "name": "LSP12IssuedAssets[]",
-        "key": "0x7c8c3416d6cda87cd42c71ea1843df28ac4850354f988d55ee2eaa47b6dc05cd",
-        "keyType": "Array",
-        "valueType": "address",
-        "valueContent": "Address"
-    },
-    {
-        "name": "LSP12IssuedAssetsMap:<address>",
-        "key": "0x74ac2555c10b9349e78f0000<address>",
-        "keyType": "Mapping",
-        "valueType": "(bytes4,uint128)",
-        "valueContent": "(Bytes4,Number)"
-    }
+  {
+    "name": "LSP12IssuedAssets[]",
+    "key": "0x7c8c3416d6cda87cd42c71ea1843df28ac4850354f988d55ee2eaa47b6dc05cd",
+    "keyType": "Array",
+    "valueType": "address",
+    "valueContent": "Address"
+  },
+  {
+    "name": "LSP12IssuedAssetsMap:<address>",
+    "key": "0x74ac2555c10b9349e78f0000<address>",
+    "keyType": "Mapping",
+    "valueType": "(bytes4,uint128)",
+    "valueContent": "(Bytes4,Number)"
+  }
 ]
 ```
 
 ## Copyright
+
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

LSPs/LSP-14-Ownable2Step.md

@@ -93,7 +93,7 @@ MUST emit a [`OwnershipTransferredStarted`](#ownershiptransferstarted) event onc
   - `typeId`: `keccak256('LSP14OwnershipTransferStarted')` > `0xee9a7c0924f740a2ca33d59b7f0c2929821ea9837ce043ce91c1823e9c4e52c0`
   - `data`: The data sent SHOULD be abi encoded and contain the [current owner](#owner) (`address`) and the [pending owner](#pendingowner) (`address`) respectively.
 
-The Type ID associated with this hook COULD be altered in a contract that inherits from LSP14. This allows for more straightforward identification of the contract whose ownership is being transferred. Example where the LSP14 type ID is overriden can be found in [LSP0](LSP-0-ERC725Account.md#transferownership) and [LSP9](LSP-9-Vault.md#transferownership) standards.
+The Type ID associated with this hook COULD be altered in a contract that inherits from LSP14. This allows for more straightforward identification of the contract whose ownership is being transferred. Example where the LSP14 type ID is overridden can be found in [LSP0](LSP-0-ERC725Account.md#transferownership) and [LSP9](LSP-9-Vault.md#transferownership) standards.
 
 #### acceptOwnership
 
@@ -123,7 +123,7 @@ MUST emit a [`OwnershipTransferred`](https://eips.ethereum.org/EIPS/eip-173#spec
   - `typeId`: `keccak256('LSP14OwnershipTransferred_RecipientNotification')` > `0xe32c7debcb817925ba4883fdbfc52797187f28f73f860641dab1a68d9b32902c`
   - `data`: The data sent SHOULD be abi encoded and contain the [previous owner](#owner) (`address`) and the new owner (`address`) respectively.
 
-The Type IDs associated with these hooks can be altered in a contract that inherits from LSP14. This allows for more straightforward identification of the contract whose ownership is being transferred. Examples where the LSP14 type IDs are overriden can be found in the [LSP0](LSP-0-ERC725Account.md#acceptownerhsip) and [LSP9](LSP-9-Vault.md#acceptownership) standards.
+The Type IDs associated with these hooks can be altered in a contract that inherits from LSP14. This allows for more straightforward identification of the contract whose ownership is being transferred. Examples where the LSP14 type IDs are overridden can be found in the [LSP0](LSP-0-ERC725Account.md#acceptownerhsip) and [LSP9](LSP-9-Vault.md#acceptownership) standards.
 
 #### renounceOwnership
 
@@ -142,7 +142,7 @@ MUST emit [`OwnershipTransferred`](https://eips.ethereum.org/EIPS/eip-173#specif
 
 - MUST be called only by the `owner()` only.
 - The second call MUST happen AFTER the delay of 100 blocks and within the next 100 blocks from the first `renounceOwnership(..)` call.
-- If 200 blocks have passed, the `renounceOwnership(..)` call phase SHOULD reset the process, and a new one will be initated.
+- If 200 blocks have passed, the `renounceOwnership(..)` call phase SHOULD reset the process, and a new one will be initiated.
 
 **LSP1 Hooks:**