Merge pull request #28 from omahs/patch-1

fix: typos

specs/experimental/fault-proof/fault-dispute-game.md

@@ -317,7 +317,7 @@ proposal in the `PreimageOracle`. This involves:
 
 The challenger then submits this data to the `PreimageOracle`, where the post state leaf's claimed input is absored into
 the pre state leaf's state matrix and the SHA3 permutation is executed on-chain. After that, the resulting state matrix
-is hashed and and compared with the proposer's claim in the post state leaf. If the hash does not match, the proposal
+is hashed and compared with the proposer's claim in the post state leaf. If the hash does not match, the proposal
 is marked as challenged, and it may not be finalized. If, after the challenge period is concluded, a proposal has no
 challenges, it may be finalized and the preimage part may be placed into the authorized mappings for the FPVM to read.
 
@@ -337,7 +337,7 @@ Uncontested claims are likely to result in a loss, as explained later under [Res
 Every claim in the game has a Clock. A claim inherits the clock of its grandparent claim in the
 DAG (and so on). Akin to a chess clock, it keeps track of the total time each team takes to make
 moves, preventing delays.
-Making a move resumes the clock for the disputed claim and puases it for the newly added one.
+Making a move resumes the clock for the disputed claim and pauses it for the newly added one.
 
 A move against a particular claim is no longer possible once the parent of the disputed claim's Clock
 has exceeded half of the `GAME_DURATION`. By which point, the claim's clock has _expired_.

specs/glossary.md

@@ -648,7 +648,7 @@ head][safe-l2-head] a block forward, so that the oldest [unsafe L2 block][unsafe
 In order to perform consolidation, the node verifies that the [payload attributes][payload-attr] derived from the L1
 chain match the oldest unsafe L2 block exactly.
 
-See the [Engine Queue section][engine-queue] of the L2 chain derivatiaon spec for more information.
+See the [Engine Queue section][engine-queue] of the L2 chain derivation spec for more information.
 
 [engine-queue]: ./protocol/derivation.md#engine-queue
 

specs/plasma.md

@@ -35,7 +35,7 @@ chain derivation must be reset, omitting the input data when rederiving therefor
 ## DA Storage
 
 Input data is uploaded to the storage layer via plain HTTP calls to the DA storage service.
-This service is horizontally scalable and concerned with replicating the data across prefered storage layers
+This service is horizontally scalable and concerned with replicating the data across preferred storage layers
 such as IPFS or any S3 compatible storage. Input data is content addressed by its hash in the request url
 so responses are easily cachable.
 
@@ -231,6 +231,6 @@ the challenge.
 In addition, the reward is not net positive for the [fisherman](https://arxiv.org/abs/1809.09044)
 who forced the release of data by challenging thus preventing money pump vulnerability
 while still making challenging affordable to altruistic fishermen and users who desire to pay
-to guarrantee data availability on L1.
+to guarantee data availability on L1.
 Lastly, if needed a `resolver_refund_factor` can be dialed up such as `resolver_refund_factor * resolving_cost`
 is refunded to the resolver (where `0 <= refund_factor <= 1`) while the rest of the bond is burnt.

specs/root.md

@@ -48,7 +48,7 @@ Specifications of new features in active development.
 Our aim is to design a protocol specification that is:
 
 - **Fast:** When users send transactions, they get reliable confirmations with low-latency.
-  For example when swapping on Uniswap you should see that your transaction succeed in less than 2
+  For example when swapping on Uniswap you should see that your transaction succeeds in less than 2
   seconds.
 - **Scalable:** It should be possible to handle an enormous number of transactions
   per second which will enable the system to charge low fees.