From 864d99c5d17ac5a3a9b78dc8f5d4c48bf8a88aef Mon Sep 17 00:00:00 2001
From: Noisy <125606576+donatik27@users.noreply.github.com>
Date: Sat, 16 Nov 2024 15:15:27 +0100
Subject: [PATCH 1/3] Update README.md

---
 README.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.md b/README.md
index bfa0377f4..bc0e5a899 100755
--- a/README.md
+++ b/README.md
@@ -54,9 +54,9 @@ Here is a simple checklist to look at when reviewing a PR for a new strategy:
 
 #### Code
 
-- Strategies should always use a `snapshot` to calculate user's voting power. As a result the voting power should not change throughout the proposal duration.
+- Strategies should always use a `snapshot` to calculate users voting power. As a result the voting power should not change throughout the proposal duration.
 - There should be a maximum of 5 requests, a request can use "fetch" a "subgraphRequest" or "multicall".
-- The strategy should not send a request for each voters, this doesn't scale.
+- The strategy should not send a request for each voter, this doesn't scale.
 - The strategy PR should not add any new dependency.
 - The score returned by the strategy should use the same casing for address as on the input, or should return checksum addresses.
 - Make sure that voting power of one address does not depend on other addresses.

From fabd3dcb4c645809b0e643cbeada022402daeec8 Mon Sep 17 00:00:00 2001
From: Noisy <125606576+donatik27@users.noreply.github.com>
Date: Sat, 16 Nov 2024 15:24:20 +0100
Subject: [PATCH 2/3] Update README.md

---
 src/strategies/api-v2/README.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/strategies/api-v2/README.md b/src/strategies/api-v2/README.md
index 6ad459a73..a211f7c40 100644
--- a/src/strategies/api-v2/README.md
+++ b/src/strategies/api-v2/README.md
@@ -13,7 +13,7 @@ Voting strategy using a REST API endpoint. Number of votes depends on the return
 | `type` | `string` | Type of the API endpoint ( `api-get` or `api-post` or `ipfs` or `json` ) | `api-get` |
 | `additionalParams` | `string` | Additional parameters for the API endpoint (optional) | `` |
 
-If you are passing a IPFS url use following format:
+If you are passing an IPFS url use following format:
 
 ```JSON
 {
@@ -40,7 +40,7 @@ If you are passing a API url use following format: (all voter addresses will be
 }
 ```
 
-If you are passing a API url with POST method use following format:
+If you are passing an API url with POST method use following format:
 
 ```JSON
 {

From ad2206b722951dda4fd4eed72f0cefa1fb2a30e6 Mon Sep 17 00:00:00 2001
From: Noisy <125606576+donatik27@users.noreply.github.com>
Date: Sat, 16 Nov 2024 15:32:45 +0100
Subject: [PATCH 3/3] Update README.md

---
 src/strategies/streamr/README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/strategies/streamr/README.md b/src/strategies/streamr/README.md
index ba2ebc7f3..0ff9e0b4d 100644
--- a/src/strategies/streamr/README.md
+++ b/src/strategies/streamr/README.md
@@ -2,7 +2,7 @@
 
 The Streamr Network is a peer-to-peer network for publishing and subscribing to data in real-time. Applications use it for decentralized messaging, for example sharing data across applications or broadcasting real-time state changes to large audiences. The decentralized nature of the system makes the data transport scalable, robust, secure, tamper proof, and censorship resistant.
 
-Operators are the node running "miners" in the Streamr Network. They run Streamr nodes, subscribe to streams, and stake DATA in the Sponsorship contract(s) of those streams. When they subscribe, they help making that stream more robust. In return, they receive DATA tokens from the Sponsorship contract, in proportion to their stake.
+Operators are the node running "miners" in the Streamr Network. They run Streamr nodes, subscribe to streams, and stake DATA in the Sponsorship contract(s) of those streams. When they subscribe, they help make that stream more robust. In return, they receive DATA tokens from the Sponsorship contract, in proportion to their stake.
 
 This is why part of the Operators' DATA tokens are staked in Sponsorships (through an Operator contract that they control). Only a small portion of DATA is expected to be in the Streamr Network participants' wallets, the rest is staked or delegated into the Streamr Network.