Update EIP-1015: Fix Typographical Errors (#9140)

* typos eip-101.md

* typos eip-1015.md

* typos eip-1186.md

* typos eip-1234.md

* typos eip-1240.md

* typos eip-1470.md

* Update eip-1240.md

* Update eip-101.md

* Update eip-1234.md

---------

Co-authored-by: Sam Wilson <[email protected]>

EIPS/eip-1015.md

@@ -54,9 +54,9 @@ It's not meant to be a general governance contract. The contract **should NOT be
 
 In order to reduce future abuse and uncertainty, **once issuance is reduced, it cannot be increased**. To prevent a single action reducing it to 0, the reduction is limited up to a percentage per time, so if the **decision assembly** is aggressively to reduce issuance to zero, it would take a known number of years.
 
-##### Results are locked for six months
+##### Results are locked for s
 
-Whenever a new decision on either reducing the issuance or changing the target is made, the effects will have a six month delay to it. Once a decision is made it is final, it will take place six months after that, but if it's shortly reversed, then that change will be short lived. The rationale behind is that it allows time to anyone disagreeing with the decision to:
+Whenever a new decision on either reducing the issuance or changing the target is made, the effects will have a six-month delay to it. Once a decision is made it is final, it will take place six months after that, but if it's shortly reversed, then that change will be short lived. The rationale behind is that it allows time to anyone disagreeing with the decision to:
 
 * Sell their coins so that if a bad actor takes over they will have a reduced reward
 * Attempt to revert the decision as soon as possible, to reduce the duration that the change will take place

EIPS/eip-1186.md

@@ -52,7 +52,7 @@ Returns the account- and storage-values of the specified account including the M
   - `nonce`: `QUANTITY`, - nonce of the account. See [`eth_getTransactionCount`](https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_gettransactioncount) 
   - `storageHash`: `DATA`, 32 Bytes - SHA3 of the StorageRoot. All storage will deliver a MerkleProof starting with this rootHash.
   - `accountProof`: `ARRAY` - Array of rlp-serialized MerkleTree-Nodes, starting with the stateRoot-Node, following the path of the SHA3 (address) as key. 
-  - `storageProof`: `ARRAY` - Array of storage-entries as requested. Each entry is a object with these properties:
+  - `storageProof`: `ARRAY` - Array of storage-entries as requested. Each entry is an object with these properties:
 
       - `key`: `QUANTITY` - the requested storage key
       - `value`: `QUANTITY` - the storage value

EIPS/eip-1470.md

@@ -40,7 +40,7 @@ Before discussing the SWC specification it is important to describe the terminol
 
 - Weakness: A software error or mistake that in the right conditions can by itself or coupled with other weaknesses lead to a vulnerability. 
 - Vulnerability: A weakness or multiple weaknesses which directly or indirectly lead to an undesirable state in a smart contract system. 
-- Variant: A specific weakness that is described in a very low detail specific to Ethereum smart contracts. Each variant is assigned an unique SWC ID.
+- Variant: A specific weakness that is described in a very low detail specific to Ethereum smart contracts. Each variant is assigned a unique SWC ID.
 - Relationships: CWE has a wide range of _Base_ and _Class_ types that group weaknesses on higher abstraction layers. The CWE uses _Relationships_ to link SWC smart contract weakness variants to existing _Base_ or _Class_ CWE types. _Relationships_ are  used to provide context on how SWCs are linked to the wider group of software security weaknesses and to be able to generate useful visualisations and insights through issue data sets. In its current revision it is proposed to link a SWC to its closest parent in the CWE. 
 - SWC ID: A numeric identifier linked to a variant (e.g. SWC-101).
 - Test Case: A test case constitutes a micro-sample or real-world smart contract that demonstrates concrete instances of one or multiple SWC variants. Test cases serve as the basis for meaningful weakness classification and are useful to security analysis tool developers.