Update ERC-1077: Remove repetitive words

ERCS/erc-1077.md

@@ -11,7 +11,7 @@
 ---
 
 
 ## Simple Summary
 
 A standard interface for gas abstraction in top of smart contracts. 
 
@@ -46,7 +46,7 @@
 function executeGasRelayMsg(uint256 _nonce, bytes memory _execData, uint256 _gasPrice, uint256 _gasLimit, address _gasToken, address _gasRelayer) public pure returns (bytes memory);
 ```
 
 #### executeGasRelayERC191Msg
 
 Returns the [EIP-191] of `executeGasRelayMsg` used for signing messages and for verifying the execution.
 
@@ -83,7 +83,7 @@
 
 The fields **MUST** be constructed as this method:
 
 The first and second fields are to make it [EIP-191] compliant. Starting a transaction with `byte(0x19)` ensure the signed data from being a [valid ethereum transaction](https://github.com/ethereum/wiki/wiki/RLP). The second argument is a version control byte. The third being the validator address (the account contract address) according to version 0 of [EIP-191]. The remaining arguments being the application specific data for the gas relay: chainID as per [EIP-1344], execution nonce, execution data, agreed gas Price, gas limit of gas relayed call, gas token to pay back and gas relayer authorized to receive reward.
 
 The [EIP-191] message must be constructed as following:
 ```solidity
@@ -147,7 +147,7 @@
 - `call(address to, uint256 value, bytes data)`:  allow any type of ethereum call be performed; 
 - `create(uint256 value, bytes deployData)`: allows create contract 
 - `create2(uint256 value, bytes32 salt, bytes deployData)`: allows create contract with deterministic address 
 - `approveAndCall(address token, address to, uint256 value, bytes data)`: allows safe approve and call of an ERC20 token.
 - `delegatecall(address codeBase, bytes data)`: allows executing code stored on other contract
 - `changeOwner(address newOwner)`: Some account contracts might allow change of owner
 - `foo(bytes bar)`: Some account contracts might have custom methods of any format.
@@ -174,7 +174,7 @@
 This scheme opens up a great deal of possibilities on interaction as well as different experiments on business models:
 
 * Apps can create individual identities contract for their users which holds the actual funds and then create a different private key for each device they log into. Other apps can use the same identity and just ask to add permissioned public keys to manage the device, so that if one individual key is lost, no ether is lost.
-* An app can create its own token and only charge their users in its internal currency for any ethereum transaction. The currency units can be rounded so it looks more similar to to actual amount of transactions: a standard transaction always costs 1 token, a very complex transaction costs exactly 2, etc. Since the app is the issuer of the transactions, they can do their own Sybil verifications and give a free amount of currency units to new users to get them started.
+* An app can create its own token and only charge their users in its internal currency for any ethereum transaction. The currency units can be rounded so it looks more similar to actual amount of transactions: a standard transaction always costs 1 token, a very complex transaction costs exactly 2, etc. Since the app is the issuer of the transactions, they can do their own Sybil verifications and give a free amount of currency units to new users to get them started.
 * A game company creates games with a traditional monthly subscription, either by credit card or platform-specific microtransactions. Private keys never leave the device and keep no ether and only the public accounts are sent to the company. The game then signs transactions on the device with gas price 0, sends them to the game company which checks who is an active subscriber and batches all transactions and pays the ether themselves. If the company goes bankrupt, the gamers themselves can set up similar subscription systems or just increase the gas price. End result is a **ethereum based game in which gamers can play by spending apple, google or xbox credits**.
 * A standard token is created that doesn’t require its users to have ether, and instead allows tokens to be transferred by paying in tokens. A wallet is created that signs messages and send them via whisper to the network, where other nodes can compete to download the available transactions, check the current gas price, and select those who are paying enough tokens to cover the cost. **The result is a token that the end users never need to keep any ether and can pay fees in the token itself.**
 * A DAO is created with a list of accounts of their employees. Employees never need to own ether, instead they sign messages, send them to whisper to a decentralized list of relayers which then deploy the transactions. The DAO contract then checks if the transaction is valid and sends ether to the deployers. Employees have an incentive not to use too many of the companies resources because they’re identifiable.  The result is that the users of the DAO don't need to keep ether, and **the contract ends up paying for it's own gas usage**.
@@ -189,18 +189,18 @@
 
 ## Implementation
 
 One initial implementation of such a contract can be found at [Status.im account-contracts repository](https://github.com/status-im/account-contracts/blob/develop/contracts/account/AccountGasAbstract.sol)
 
 Other version is implemented as Gnosis Safe variant in: https://github.com/status-im/safe-contracts
 
 ### Similar implementations
 
 The idea of using signed messages as executable intent has been around for a while and many other projects are taking similar approaches, which makes it a great candidate for a standard that guarantees interoperability:
 
 * [EIP-877](https://github.com/ethereum/EIPs/pull/877) An attempt of doing the same but with a change in the protocol
 * [Status](https://github.com/status-im/ideas/issues/73)
 * [Aragon](https://github.com/aragonlabs/pay-protocol) (this might not be the best link to show their work in this area)
 * [Token Standard Functions for Preauthorized Actions](https://github.com/ethereum/EIPs/issues/662)
 * [Token Standard Extension 865](https://github.com/ethereum/EIPs/issues/865)
 * [Iuri Matias: Transaction Relay](https://github.com/iurimatias/TransactionRelay)
 * [uPort: Meta transactions](https://github.com/uport-project/uport-identity#send-a-meta-tx)

ERCS/erc-2309.md

@@ -1,8 +1,8 @@
 ---
 eip: 2309
 title: ERC-721 Consecutive Transfer Extension
 author: Sean Papanikolas (@pizzarob)
 discussions-to: https://github.com/ethereum/EIPs/issues/2309
 status: Final
 type: Standards Track
 category: ERC
@@ -10,13 +10,13 @@
 requires: 721
 ---
 
 ## Simple Summary
 
 A standardized event emitted when creating/transferring one, or many non-fungible tokens using consecutive token identifiers.
 
 ## Abstract
 
 The optional ERC-721 Consecutive Transfer Extension provides a standardized event which could be emitted during the creation/transfer of one, or many non-fungible tokens. This standard does not set the expectation of how you might create/transfer many tokens it is only concerned with the event emitted after the creation, or transfer of ownership of these tokens. This extension assumes that token identifiers are in consecutive order.
 
 ## Motivation
 
@@ -88,11 +88,11 @@
 
 Take this example. I sell magical fruit and have a farm with 10,000 magical fruit trees each with different fruit and 1,000 new trees every few years. I want to turn each tree into a non-fungible token that people can own. Each person that owns one of my non-fungible tree tokens will receive a quarterly percentage of each harvest from that tree. The problem is that I would need to create and transfer each of these tokens individually - which will cost me a lot of time and money and frankly would keep me from doing this.
 
-With this extension I would be able to to mint my initial 10,000  tree tokens in one transaction. I would be able to quickly and cheaply mint my additional 1,000  tree tokens when a new batch is planted. I would then be able to transfer all of the 10,000+ tree tokens to a special smart contract that keeps track of the selling and distribution of funds in one transaction all while adhering to a specified standard.
+With this extension I would be able to mint my initial 10,000  tree tokens in one transaction. I would be able to quickly and cheaply mint my additional 1,000  tree tokens when a new batch is planted. I would then be able to transfer all of the 10,000+ tree tokens to a special smart contract that keeps track of the selling and distribution of funds in one transaction all while adhering to a specified standard.
 
 **Rationale to have a single event that covers minting, burning, and transferring**
 
 The `ConsecutiveTransfer` event can be used to cover minting, burning, and transferring events. While there may have been confusion in the beginning adhering to transfer to/from "0" pattern this is mitigated by checking for the `ConsecutiveTransfer` topic and verifying the emitting contract supports the ERC-721 interface by using the ERC-165 standard. 
 
 **Indexed event parameters**
 

ERCS/erc-3448.md

@@ -1,6 +1,6 @@
 ---
 eip: 3448
 title: MetaProxy Standard
 description: A minimal bytecode implementation for creating proxy contracts with immutable metadata attached to the bytecode
 author: pinkiebell (@pinkiebell)
 discussions-to: https://ethereum-magicians.org/t/erc-3448-metaproxy-factory/5834
@@ -182,7 +182,7 @@
 ```solidity
 /// @notice Returns the metadata of this (MetaProxy) contract.
 /// Only relevant with contracts created via the MetaProxy standard.
-/// @dev This function is aimed to to be invoked via a call.
+/// @dev This function is aimed to be invoked via a call.
 function getMetadataViaCall () public pure returns (
   address a,
   uint256 b,