diff --git a/content/md/en/docs/learn/accounts-addresses-keys.md b/content/md/en/docs/learn/accounts-addresses-keys.md
index 6e32550b1..a7c538598 100644
--- a/content/md/en/docs/learn/accounts-addresses-keys.md
+++ b/content/md/en/docs/learn/accounts-addresses-keys.md
@@ -20,7 +20,7 @@ The secret seed phrase is important because it can be used to recover access to
 
 For most networks, the **public key** associated with an account is how that account is identified on the network and some form of it is used as the destination address for transactions.
 However, Substrate-based chains use the underlying public key to derive one or more **public addresses**.
-Instead of using the public key directly, Substrate allows you generate multiple addresses and address formats for an account.
+Instead of using the public key directly, Substrate allows you to generate multiple addresses and address formats for an account.
 
 ## Address encoding and chain-specific addresses
 
@@ -74,7 +74,7 @@ For more information about working with generic types, see [Rust for Substrate](
 
 ## Specialized accounts
 
-As a flexible and module framework for blockchain development, Substrate itself doesn't require you define or use any specific type of accounts.
+As a flexible and module framework for blockchain development, Substrate itself doesn't require you to define or use any specific type of accounts.
 However, different chains can implement different rules for how accounts and the keys that control them are used.
 For example, you might implement specialized accounts if your application requires:
 
diff --git a/content/md/en/docs/learn/transaction-lifecycle.md b/content/md/en/docs/learn/transaction-lifecycle.md
index 9f85e1c1b..fdb419855 100644
--- a/content/md/en/docs/learn/transaction-lifecycle.md
+++ b/content/md/en/docs/learn/transaction-lifecycle.md
@@ -81,8 +81,8 @@ If a transaction is invalid—for example, because it is too large or doesn't co
 A transaction might be rejected for any of the following reasons:
 
 - The transaction has already been included in a block so it is dropped from the verifying queue.
-- The transaction's signature is invalid, so it is immediately be rejected.
-- The transaction is too large to fit in the current block, so it is be put back in a queue for a new verification round.
+- The transaction's signature is invalid, so it is immediately rejected.
+- The transaction is too large to fit in the current block, so it is put back in a queue for a new verification round.
 
 ## Transactions ordered by priority
 
@@ -136,7 +136,7 @@ Before committing any state changes to storage, the runtime logic should perform
 
 Note that [events](/build/events-and-errors/) are also written to storage.
 Therefore, the runtime logic should not emit an event before performing the complementary actions.
-If a transaction fails after an event is emitted, the event is not be reverted.
+If a transaction fails after an event is emitted, the event is not reverted.
 
 ### Finalizing a block