Proposing an update to README.md

Author: fbaldassarri

README.md

@@ -8,33 +8,33 @@
 
 ### The Basis
 
-DFO is a new concept that reshapes the way to build Decentralized Applications, enabling the creation of __extendible, improvable and fixable Systems__, using an approach called __Smart Contract as Microservice__ which avoids the slow and dangerous monolythic Smart Contract development procedures.
+DFO is a new concept that reshapes the way to build Decentralized Applications (DApps), enabling the creation of __extendible, improvable and fixable Systems__, using an approach called __Smart Contract as Microservice__ which avoids the slow and dangerous monolythic Smart Contract development procedures.
 
 > Because of __everything is completely deployed and running on the Ethereum blockchain__, the need of Centralized or Distributed Servers is finally bypassed.
 
-In DFO, every Dapp's Functionality is a __Smart Contract acting like a Microservice__, which can also be __stateless__ and therefore __reusable__ in different applications.
+In DFO, every DApp functionality is a __Smart Contract acting like a Microservice__, which can also be __stateless__ and therefore __reusable__ in different applications.
 
-Instead of directly use Smart Contract's functions, calling its specific address, in DFO you will interact with the __Proxy__ which will keep track of the latest correct versions of all Microservices (located in different addresses) composing your Dapp.
+Instead of directly using Smart Contracts functions, calling their specific address, in DFO you will interact with the __Proxy__ which will keep track of the latest correct versions of all Microservices (located in different addresses) composing your DApp.
 
 ![alt text](https://raw.githubusercontent.com/b-u-i-d-l/dfo-hub/master/assets/img/wall1.png "The Smart Contract as Microservice Approach in DFO")
 
-> No matter how many Microservices you will attach, detach or replace to a DFO since its creation. __The address of your Dapp will be always the same, forever__.
+> No matter how many Microservices will you attach, detach or replace to a DFO since its creation. __The address of your Dapp will be always the same, forever__.
 
-DFO is completely __Community Driven__. This means that every strategic decision about the Dapp's Functionalities and their future is taken by its Token Holders.
-In fact, to add/replace/remove a Microservice, the proposer must interact with the Proxy to start a __Survey__ which can be voted by the ones holding the __ERC20 Voting Tokens__ linked to that DFO, staking them to accept or refuse the proposal. The governance rules that establish the success or the failure of a Survey are, in turn, Functionalities of the DFO, located in Microservices that can be also updated... through Proposals!
+DFO is completely __Community Driven__. This means that every strategic decision about the DApp Functionalities and their future is taken by its Token Holders.
+In fact, to add/replace/remove a Microservice, the proposer must interact with the Proxy to start a __Survey__ which can be voted by the ones holding the __ERC20 Voting Tokens__ linked to that DFO, staking them to accept or refuse the proposal. The governance rules (that establish the success or the failure of a Survey) are, in turn, Functionalities of the DFO itself  located within Microservices that can be updated too... through Proposals!
 
 The Proxy, the Voting Token, the Proposals, the Governance Rules and some other Smart Contracts are all the components that make up every single DFO.
 
 Every DFO is a bunch of Smart Contracts cooperating each other to let users:
 
-- Use Functionalities in both Read and Write Mode
-- Propose to add/remove/replace these Functionalities through Surveys
-- Vote to Accept/Refuse them through Voting Tokens
+- using Functionalities in both Read and Write Mode;
+- proposing to add/remove/replace these Functionalities through Surveys;
+- voting to Accept/Refuse them through Voting Tokens.
 
-Even the Smart Contracts of a DFO can be updated to correct bugs or to expand the potential of the protocol just making a Proposal to the Token Holders Community.
+Even the Smart Contracts of a DFO can be updated to address bug fixes or to expand the potential of the protocol just making a Proposal to the Token Holders Community.
 
-To let people create and use DFOs, we built __DFOHub__, our R&D community-driven project that aims to improve the DFO protocol itself by managing its progress through a DFO maintained by its token holders, that can propose and vote for improvements and bug fixes in an anonymous, decentralized and very easy way.
-DFOHub extremely facilitates the deployment procedures of a new DFO, you can exploit it in two ways:
+To let people create and use DFOs, we built __DFOHub__, our R&D community-driven project that aims to improve the DFO protocol itself by managing its progress through a DFO maintained by its own token holders, who can propose or vote for improvements and bug fixes with anonymous, decentralized and very easy steps.
+DFOHub extremely facilitates the deployment processes for a new DFO, you can exploit it in two ways:
 
-1. Use the easy steps of the wizard we built on [DFOHub](https://b-u-i-d-l.github.io/dfo-hub/);
-2. [__COMING SOON__] Use the integration SDK which lets you easily integrate DFO protocol capabilities in your Dapp.
+1. using the easy steps of the wizard we coded on [DFOHub](https://b-u-i-d-l.github.io/dfo-hub/);
+2. [__COMING SOON__] using the integration SDK which lets you easily integrate DFO protocol capabilities in your DApp.