Fix typos in docs

docs-v1/random-beacon/delegation-notes.adoc

@@ -533,7 +533,7 @@ reduce costs compared to including them in each delegation agreement.
 If the new contract is found compromised, the recourse is for the _owner_ or
 _operator_ to unstake or for the _panic button_ to be used to halt all
 operations on the compromised contract. Once authorized, a contract is
-technically capable of completely burning or transfering any staked tokens, even
+technically capable of completely burning or transferring any staked tokens, even
 if unstaking has been ordered. If this were not the case it would be possible to
 avoid legitimate penalties.
 

docs-v1/random-beacon/group-expiration/index.adoc

@@ -202,7 +202,7 @@ removed from the pool for any later outputs).
 If expiration is applied before selection:
 
 - At _T_, _G~i~_ doesn't expire, and is thus eligible for _V~j~_
-- At _T'_, _G~i~_ has expired and is not eligible for _V~j~_. Mallory's goal is achived.
+- At _T'_, _G~i~_ has expired and is not eligible for _V~j~_. Mallory's goal is achieved.
 
 If expiration is applied after selection:
 

docs-v1/run-random-beacon.adoc

@@ -8,7 +8,7 @@ toc::[]
 
 == System Considerations
 
-The Keep Network expects certain capabilites for each node running on the network.  To help attain
+The Keep Network expects certain capabilities for each node running on the network.  To help attain
 these capabilities consider the following criteria:
 
 - It is paramount that Keep nodes remain available to the Keep Network. We strongly encourage a
@@ -21,7 +21,7 @@ these capabilities consider the following criteria:
 - Recommended machine types by provider:
 
 Your operating environment will ultimately dictate what machine type to go with.  This is
-particulary relevant if you're running a containerized solution where multiple applications
+particularly relevant if you're running a containerized solution where multiple applications
 are sharing VM resources.  The below types are sufficient for running at least one instance of the
 Keep Random Beacon client.
 
@@ -238,7 +238,7 @@ Application configurations are stored in a `.toml` file and passed to the applic
 |Yes
 
 |`AnnouncedAddresses`
-|Multiaddr formatted hostnames or addresses annouced to the
+|Multiaddr formatted hostnames or addresses announced to the
 Keep Network. More on multiaddr format
 https://docs.libp2p.io/reference/glossary/#multiaddr[in the libp2p
 reference].

docs/rfc/rfc-19-random-beacon-v2.adoc

@@ -74,7 +74,7 @@ Once the group submits the result to the chain, a challenge period starts.
 During the challenge period, anyone can notify that the submitted DKG result
 contains group members not selected by the pool. This leads to slashing all
 members who signed the result and the notifier receives 5% from the slashed amount.
-The malicious result is immediatelly discarded.
+The malicious result is immediately discarded.
 The length of the challenge period and slashing amount are governable parameters.
 
 Once the challenge period passes, anyone can unlock the sortition pool and mark
@@ -226,7 +226,7 @@ interface IRandomBeaconConsumer {
 We should extend the timeout for submitting relay entry to give operators more
 time to react. We should extend the time for a single member to become eligible
 from 6 blocks to 10 blocks and make it a governable parameter. 
-After the initial timeout passes (group size multipled by the number of blocks
+After the initial timeout passes (group size multiplied by the number of blocks
 for a member to become eligible to submit relay entry), if no entry was
 provided, all operators in the group should start bleeding and losing their
 stake. The bleeding should increase linearly from 0 to the governable slashing