From c7e58487c8e078ee1da105bf310c23d290d544b7 Mon Sep 17 00:00:00 2001
From: Soulcollector <63009461+SoulcoIIector@users.noreply.github.com>
Date: Sat, 4 Jan 2025 22:10:27 +0300
Subject: [PATCH] FIx typos README.md

---
 tests/fuzzers/README.md | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/tests/fuzzers/README.md b/tests/fuzzers/README.md
index 7611c53698..eeb2222692 100644
--- a/tests/fuzzers/README.md
+++ b/tests/fuzzers/README.md
@@ -31,11 +31,10 @@ go-fuzz -bin ./rlp/rlp-fuzz.zip
 
 ### Notes
 
-Once a 'crasher' is found, the fuzzer tries to avoid reporting the same vector twice, so stores the fault in the `suppressions` folder. Thus, if you 
-e.g. make changes to fix a bug, you should _remove_ all data from the `suppressions`-folder, to verify that the issue is indeed resolved. 
+Once a 'crasher' is found, the fuzzer tries to avoid reporting the same vector twice, so it stores the fault in the `suppressions` folder. Thus, if you, for example, make changes to fix a bug, you should _remove_ all data from the `suppressions`-folder, to verify that the issue is indeed resolved. 
 
-Also, if you have only one and the same exit-point for multiple different types of test, the suppression can make the fuzzer hide different types of errors. So make
-sure that each type of failure is unique (for an example, see the rlp fuzzer, where a counter `i` is used to differentiate between failures: 
+Also, if you have only one and the same exit point for multiple different types of test, the suppression can make the fuzzer hide different types of errors. So make
+sure that each type of failure is unique (for example, see the RLP fuzzer, where a counter `i` is used to differentiate between failures: 
 
 ```golang
 		if !bytes.Equal(input, output) {