Apply suggestions from code review

Co-authored-by: Aleksandr Petrosyan <a-p-petrosyan@yandex.ru>

docs/source/references/api_spec.md

@@ -98,15 +98,15 @@ Server sends `Event` and expects `EventReceived` after each, before sending the
 
 **Notes**:
 
-Most usually the client would want to wait for Transaction events. 
+Usually, the client  waits for Transaction events. 
 
-Transaction events statuses are: `Validating`, `Committed` or `Rejected`.
+Transaction event statuses can be either `Validating`, `Committed` or `Rejected`.
 
-Transactions status sequence for submitted transaction is: `Validating` -> `Committed` | `Rejected`
+Transaction statuses proceed from `Validating` to either  `Committed` or `Rejected`. 
 However, due to the distributed nature of the network, some peers might receive events out of order (e.g. `Committed` before `Validating`).
 
-There might be cases where some peers in the network might be offline for validation round and if the clients connects to them they might not send `Validating` status.
-But if this peer gets up online it will synchronize the blocks and is guaranteed to send `Committed` or `Rejected` status depending on the information it finds in the block.
+It's possible that some peers in the network are offline for the validation round. If the client connects to them while they are offline, the peers might not respond with the `Validating` status.
+But when the offline peers come back online they will synchronize the blocks. They are then guaranteed to respond with the `Committed` (or `Rejected`) status depending on the information found in the block.
 
 ### Configuration