Update EIP-5792: Fixing Typos and Errors in Markdown Documentation

EIPS/eip-5792.md

@@ -43,7 +43,7 @@ These fields are set inside this capability's entry in the `capabilities` object
 Each entity in the `calls` field may contain an optional `capabilities` object.
 This object allows the applications to attach a capability-specific metadata to individual calls.
 
-Unless these requirements are explicitly overriden by a certain `capability`, the wallet must adhere to the following rules.
+Unless these requirements are explicitly overridden by a certain `capability`, the wallet must adhere to the following rules.
 Note that such a `capability` is not in the scope of this EIP and should be defined in its own ERC.
 
 The wallet:

EIPS/eip-7745.md

@@ -32,7 +32,7 @@
 - _log index_: values are globally mapped to a linear index space, with a monotonically increasing _log index_ assigned to each added _log value_. The _log values_ are added in the order of EVM execution (_address value_ first, then the _topic values_) so the logs generated in each block and in each transaction of the block occupy a continuous range in the index space. A _block delimiter_ is also added between blocks which has its own _log index_ and is added to the Merkle tree of _log entries_ but not to the _filter maps_.
 - _log entry_: an SSZ encoded log event with position metadata (a `LogEntry` container) is added to the `log_entries` Merkle tree at the first _log index_ assigned to the event (the one assigned to the _address value_). The entries at indices assigned to _topic values_ are left empty (a `LogEntry` with all zero fields).
 - _block delimiter_: uses the same encoding as regular `LogEntry` containers but is always distinguishable. It is added to the `log_entries` tree before each block and has its own _log index_ assigned.
-- _filter map_: a `MAP_WIDTH` by `MAP_HEIGHT` sized sparse map intended to help searching for _log values_ in a fixed `VALUES_PER_MAP` length section of the _log index_ space. Each _log value_ is marked on the map at a row and column that depends on the _log index_ and the _log value_ itself. Rows are sparsely encoded as a list of marked column indices (in the order of occurence, duplicates not filtered out for simplicity). Each map contains at most `VALUES_PER_MAP` marks and therefore the chance of false positives is kept at a constant low level.
+- _filter map_: a `MAP_WIDTH` by `MAP_HEIGHT` sized sparse map intended to help searching for _log values_ in a fixed `VALUES_PER_MAP` length section of the _log index_ space. Each _log value_ is marked on the map at a row and column that depends on the _log index_ and the _log value_ itself. Rows are sparsely encoded as a list of marked column indices (in the order of occurrence, duplicates not filtered out for simplicity). Each map contains at most `VALUES_PER_MAP` marks and therefore the chance of false positives is kept at a constant low level.
 - _filter epoch_: a `MAPS_PER_EPOCH` sized group of consecutive filter maps stored in the hash tree in a way so that multiple rows of adjacent _filter maps_ with the same _row index_ can be efficiently retrieved in a single Merkle multiproof. The _log value_ to _row index_ mapping is constant during a single epoch but changes between epochs.
 
 ### Consensus data format
@@ -292,7 +292,7 @@
 
 ## Test Cases
 
 <!-- TODO -->
 
 ## Reference Implementation
 

EIPS/eip-7768.md

@@ -34,7 +34,7 @@
    4. The first, then the second, ... then the Nth transaction, which is not the last in her series of transactions; or
    5. All her transactions, in order.
 4. Alice sends this series of transactions to a service that communicates with block proposers.
-   1. Currently mempools in baseline clients would not propogate such transactoins.
+   1. Currently mempools in baseline clients would not propagate such transactoins.
 
 For example, if consideration is sent to the free-for-all address, this would typically be the last in her series of transactions.
 
@@ -89,11 +89,11 @@
 * Create a new transaction type that encapsulates another signed transaction.
 * Create a new opcode to get the coinbase of the next block.
 
 ##  Backwards Compatibility
 
 ... <!-- TODO -->
 
 ##  Security Considerations
 
 ... <!-- TODO -->
 

EIPS/eip-7788.md

@@ -21,7 +21,7 @@
 
 With static targeting the target may be higher than the actual demand, causing the protocol to undercharge for blobspace. This decreases the amount of fees burned, negatively affecting the price of ETH and total network security.
 
-As an example, consider what would happen if there was a large increase in max blob count due to DAS implementation but the target remained at 50%. It is unlikely that demand would immediately jump to anywhere near the target, and so for months or years the protocol would effectively charge nothing for L2 transactions. With a dynamic target, the target blob count would drop until the cost of blobspace for an L2 transaction approximated some affordable constant value. In this way, some fees are still burned by the protocol, but new L2s are not discouraged from using Ethereum blobspace, knowing that the target will increase in response to an increase in demand and blob fees will remain reasonably consisent.
+As an example, consider what would happen if there was a large increase in max blob count due to DAS implementation but the target remained at 50%. It is unlikely that demand would immediately jump to anywhere near the target, and so for months or years the protocol would effectively charge nothing for L2 transactions. With a dynamic target, the target blob count would drop until the cost of blobspace for an L2 transaction approximated some affordable constant value. In this way, some fees are still burned by the protocol, but new L2s are not discouraged from using Ethereum blobspace, knowing that the target will increase in response to an increase in demand and blob fees will remain reasonably consistent.
 
 While the max blob count and max target are hard constraints based on resource utilisation limits, setting the target itself is far more subjective. A dynamic target can optimise for constant and affordable L2 transaction costs without requiring regular intervention by core developers to make tweaks based on changes in demand.
 
@@ -96,7 +96,7 @@
 
 ## Security Considerations
 
 <!-- TODO -->
 Needs discussion.
 
 ## Copyright