update README.md

README.md

@@ -16,7 +16,7 @@ All L1 and L2 networks which are supported by Eternal Safe and The Graph network
 - Celo (`celo`): TODO
 - Avalanche (`avalanche`): TODO
 
-As of writing, the following networks are not supported by the [decentralized network](https://thegraph.com/docs/en/developing/supported-networks/):
+As of writing, the following networks supported by Eternal Safe are not supported by [The Graph's decentralized network](https://thegraph.com/docs/en/developing/supported-networks/):
 
 - Polygon zkEVM
 - zkSync Era
@@ -25,19 +25,19 @@ As of writing, the following networks are not supported by the [decentralized ne
 
 All of the network specific data source parameters are defined in the `networks.json` file.
 
-#### v1.1.1 Factory Note
+#### v1.1.1 Factory
 
-The v1.1.1 factory is not deployed correctly on all networks. For such networks, we have used the null address (0x0000000000000000000000000000000000000000) in the `networks.json`, so that the built `subgraph.yaml` will be valid for all networks.
+The v1.1.1 factory is not deployed correctly on all networks. For such networks, we have used the null address (`0x0000000000000000000000000000000000000000`) in the `networks.json`, so that the built `subgraph.yaml` will be valid for all networks.
 
-#### v1.3.0 Factory Note
+#### v1.3.0 Factory
 
-There are two commonly used deployements of the v1.3.0 factory. Both are indexed. One is known as the "canonical" deployment and the other as the ["eip155" deployment](https://github.com/safe-global/safe-deployments/blob/main/src/assets/v1.3.0/proxy_factory.json).
+There are two commonly used deployments of the v1.3.0 factory. Both are indexed. One is known as the "canonical" deployment and the other as the ["eip155" deployment](https://github.com/safe-global/safe-deployments/blob/main/src/assets/v1.3.0/proxy_factory.json).
 
 #### L2 Safes
 
-On any L2, there is the original (in a sense that it is the same as  the original contract deployed to L1) `Safe` contract and the [SafeL2](https://github.com/safe-global/safe-smart-account/blob/main/contracts/SafeL2.sol#L10) contract. This subgraph supports both contracts, via the same instance, but with two different data sources. This means you can query `Safe` and `SafeL2` wallets in the same way with the same GraphQL queries against one endpoint, even though they are indexed differently in _The Graph_.
+On any L2, it's possible that there is both the original (in a sense that it is the same as  the original contract deployed to L1) `Safe` contract and the [SafeL2](https://github.com/safe-global/safe-smart-account/blob/main/contracts/SafeL2.sol#L10) contract. This subgraph supports both contracts, via the same instance, but with two different data sources. This means you can query `Safe` and `SafeL2` wallets in the same way with the same GraphQL queries against one endpoint, even though they are indexed differently in _The Graph_.
 
-The data sources are defined in [subgraph.yaml](subgraph.yaml) as `templates` and are named accordingly `Safe` and `SafeL2`. The `SafeL2` data source is more efficient because it reads the data from events emitted from the corresponding contract, whereas `Safe` data source must rely on call handlers in lieu of the contract not emitting events. The subgraph will automatically detect whether the new safe is of `Safe` or `SafeL2` instance based on the known `SafeL2` singleton deployment address. Howver, if a new `SafeL2` singleton is deployed that this subgraph does not know about, the subgraph will fall back to using `Safe` data source and its call handler to ensure it reads all the information from the safe, no matter whether it emits events or not. This is not a problem as `SafeL2` safes can still be indexed via the call handler rather than the event handler, it's just less efficient.
+The data sources are defined in [subgraph.yaml](subgraph.yaml) as `templates` and are named accordingly `Safe` and `SafeL2`. The `SafeL2` data source is more efficient because it reads the data from events emitted from the corresponding contract, whereas the `Safe` data source must rely on call handlers in lieu of the contract not emitting events. The subgraph will automatically detect whether the new safe is of a `Safe` or `SafeL2` instance based on the known `SafeL2` singleton deployment address. However, if a new `SafeL2` singleton is deployed that this subgraph does not know about, the subgraph will fall back to using `Safe` data source and its call handler to ensure it reads all the information from the safe, no matter whether it emits events or not. This is not a problem as `SafeL2` safes can still be indexed via the call handler rather than the event handler, it's just less efficient.
 
 ## Prerequiste