diff --git a/EIPS/eip-2069.md b/EIPS/eip-2069.md
index 14d8d52f587860..193f98e920a68a 100644
--- a/EIPS/eip-2069.md
+++ b/EIPS/eip-2069.md
@@ -15,7 +15,8 @@ Recommendation for including contract ABI descriptions in EIPs and ERCs as YAML.
 ## Motivation
 
 In the past, most ERCs/EIPs included an ABI description purely as a Solidity contract and/or interface. This has several drawbacks:
-- Prefers a single language over others and could hinder the development of new languages.
+
+- Prefers a single language over others and could hinder the development of new languages. 
 - Locks the specification to a certain version of the Solidity language.
 - Allows the use of syntactical elements and features of the Solidity language, which may not be well representable in the ABI. This puts other languages at even more disadvantage.
 
@@ -25,7 +26,7 @@ This proposal aims to solve all these issues.
 
 The [Standard Contract ABI] is usually represented as a JSON object.  This works well and several tools – including compilers and clients – support it to handle data encoding.
 
-One shortcoming of the JSON description is its inability to contain comments.  To counter this, we suggest the use of YAML for providing user readable specifications.  Given YAML was designed to be compatible with JSON, several tools exists to convert between the two formats.
+One shortcoming of the JSON description is its inability to contain comments.  To counter this, we suggest the use of YAML for providing user readable specifications.  Given YAML was designed to be compatible with JSON, several tools exist to convert between the two formats.
 
 The following example contains a single function, `transfer` with one input and one output in YAML:
 
@@ -83,7 +84,7 @@ The same in JSON:
 
 ## Rationale
 
-The aim was to chose a representation which is well supported by tools and supports comments. While inventing a more concise description language seems like a good idea, it felt as an unnecessary layer of complexity.
+The aim was to choose a representation which is well supported by tools and supports comments. While inventing a more concise description language seems like a good idea, it felt as an unnecessary layer of complexity.
 
 ## Backwards Compatibility