diff --git a/README.md b/README.md
index c5c5809b2b..02f98e933b 100644
--- a/README.md
+++ b/README.md
@@ -16,7 +16,7 @@ by existing clients.
 This readme is split into two major sections:
 
 - [Lighthouse Client](#lighthouse-client): information about this
-  implemenation.
+  implementation.
 - [What is Ethereum 2.0](#what-is-ethereum-20): an introduction to Ethereum 2.0.
 
 If you'd like some background on Sigma Prime, please see the [Lighthouse Update
@@ -54,8 +54,13 @@ reject invalid blocks even quicker. See the
 [issue](https://github.com/ethereum/beacon_chain/issues/103) on
 [ethereum/beacon_chain](https://github.com/ethereum/beacon_chain)
 .
+<<<<<<< HEAD
 - **P2P networking**: Eth 2.0 will likely use the [libp2p
   framework](https://libp2p.io/). Lighthouse aims to work alongside
+=======
+- **P2P networking**: Eth 2.0 is likely to use the [libp2p
+  framework](https://libp2p.io/), lighthouse hopes to work alongside
+>>>>>>> f765f4e08d84346a936e77859b2cb91110a9c007
 [Parity](https://www.parity.io/) to get
 [libp2p-rust](https://github.com/libp2p/rust-libp2p) fit-for-purpose.
 - **Validator duties** : the project involves the development of "validator"
@@ -72,6 +77,7 @@ on serialization formats.
 - **Casper FFG fork-choice**: the [Casper
   FFG](https://arxiv.org/abs/1710.09437) fork-choice rules allow the chain to
 select a canonical chain in the case of a fork.
+<<<<<<< HEAD
 - **Efficient state transition logic**: "state transition" logic governs
   updates to the validator set as validators log in/out, penalises/rewards
 validators, rotates validators across shards, and implements other core tasks.
@@ -80,6 +86,16 @@ environments with CI work-flows to provide automated security analysis..
 
 In addition to these components we're also working on database schemas, RPC
 frameworks, specification development, database optimizations (e.g.,
+=======
+- **Efficient state transition logic**: "state transition" logic deals with
+  updating the validator set as validators log in/out, penalising/rewarding
+validators, rotating validators across shards, and many other core tasks.
+- **Fuzzing and testing environments**: we are preparing to implement lab
+  environments with CI work-flows to provide automated security analysis.
+
+On top of these components we're also working on database schemas,
+RPC frameworks, specification development, database optimizations (e.g.,
+>>>>>>> f765f4e08d84346a936e77859b2cb91110a9c007
 bloom-filters) and tons of other interesting stuff (at least we think so).
 
 ### Contributing
@@ -150,7 +166,7 @@ write-access to the repository). This helps to detect bugs, improve consistency
 and relieves any one individual of the responsibility of an error.
 
 Discussion should be respectful and intellectual. Have fun, make jokes but
-respect other peoples limits.
+respect other people's limits.
 
 ### Directory Structure
 
@@ -190,7 +206,7 @@ Major services provided by the beacon chain to its shards include the following:
 
 - A source of entropy, likely using a [RANDAO + VDF
   scheme](https://ethresear.ch/t/minimal-vdf-randomness-beacon/3566).
-- Valdidator management, including:
+- Validator management, including:
     - Inducting and ejecting validators.
     - Delegating randomly-shuffled subsets of validators to validate shards.
     - Penalising and rewarding validators.
@@ -235,6 +251,6 @@ the gaps. There is active discussion about the spec in the
 proof-of-concept implementation in Python is available at
 [ethereum/beacon_chain](https://github.com/ethereum/beacon_chain).
 
-Presently, the spec almost exclusively defines the Beacon Chain, which is the
-focus of present development efforts. Progress on shard chain specification
-will soon follow.
+Presently, the spec almost exclusively defines the Beacon Chain as it
+is the focus of present development efforts. Progress on shard chain
+specification will soon follow.