fix: update Twitter URL to x.com and improve ERC documentation grammar

.github/ISSUE_TEMPLATE.md

@@ -4,7 +4,7 @@ If you are considering a proposal but would like to get some feedback on the ide
 
 Keep in mind the following guidelines from [EIP-1](https://eips.ethereum.org/EIPS/eip-1):
 
-> Each ERC must have a champion - someone who writes the ERC using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The EIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is ERC-able. Posting to the the Protocol Discussion forum or opening an Issue is the best way to go about this.
+> Each ERC must have a champion - someone who writes the ERC using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The EIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is ERC-able. Posting to the Protocol Discussion forum or opening an Issue is the best way to go about this.
 
 > Vetting an idea publicly before going as far as writing a ERC is meant to save the potential author time. Asking the Ethereum community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Ethereum is used.
 

ERCS/erc-1438.md

@@ -39,7 +39,7 @@ The avatar's information & assets are stored in the event log part of the block
 - avatar information data is json (compressed with msgpack)
 
 ![avatar](../assets/eip-1438/avatar.png)
-** The avatar assets from [Avataaars](https://github.com/fangpenlin/avataaars) developed by [Fang-Pen Lin](https://twitter.com/fangpenlin), the original avatar is designed by [Pablo Stanley](https://twitter.com/pablostanley).
+** The avatar assets from [Avataaars](https://github.com/fangpenlin/avataaars) developed by [Fang-Pen Lin](https://x.com/fangpenlin), the original avatar is designed by [Pablo Stanley](https://x.com/pablostanley).
 
 ### 2. Universal Wallet
 ![wallet](../assets/eip-1438/wallet.png)

ERCS/erc-1620.md

@@ -285,12 +285,12 @@ There could be a way to avoid running two different streams in parallel. That is
 - [Chronos Protocol White Paper](http://chronosprotocol.org/chronos-white-paper.pdf)
 - [Flipper: Streaming Salaries @ CryptoLife Hackathon](https://devpost.com/software/flipper-3gvl4b)
 - [SICOs or Streamed ICOs](https://ethresear.ch/t/chronos-a-quirky-application-proposal-for-plasma/2928/14?u=paulrberg)
-- [RICOs or Reversible ICOs](https://twitter.com/feindura/status/1058057076306518017)
+- [RICOs or Reversible ICOs](https://x.com/feindura/status/1058057076306518017)
 - [Andreas Antonopoulos' Keynote on Bitcoin, Lightning and Money Streaming](https://www.youtube.com/watch?v=gF_ZQ_eijPs)
 
 ## Final Notes
 
-Many thanks to @mmilton41 for countless brainstorming sessions. We have been doing research on the topic of money streaming for quite a while within the context of @ChronosProtocol. In August this year, we published the first version of our white paper describing a Plasma approach. However, in the meantime, we realised that it would be much more [fun](https://twitter.com/PaulRBerg/status/1056595919116910592) and easier to start small on Ethereum itself and sidechains like [xDai](https://blockscout.com/poa/dai).
+Many thanks to @mmilton41 for countless brainstorming sessions. We have been doing research on the topic of money streaming for quite a while within the context of @ChronosProtocol. In August this year, we published the first version of our white paper describing a Plasma approach. However, in the meantime, we realised that it would be much more [fun](https://x.com/PaulRBerg/status/1056595919116910592) and easier to start small on Ethereum itself and sidechains like [xDai](https://blockscout.com/poa/dai).
 
 ## Copyright
 Copyright and related rights waived via [CC0](../LICENSE.md).

LICENSE.md

@@ -82,7 +82,7 @@ be judged legally invalid or ineffective under applicable law, then the
 Waiver shall be preserved to the maximum extent permitted taking into
 account Affirmer's express Statement of Purpose. In addition, to the
 extent the Waiver is so judged Affirmer hereby grants to each affected
-person a royalty-free, non transferable, non sublicensable, non exclusive,
+person a royalty-free, non-transferable, non-sublicensable, non-exclusive,
 irrevocable and unconditional license to exercise Affirmer's Copyright and
 Related Rights in the Work (i) in all territories worldwide, (ii) for the
 maximum duration provided by applicable law or treaty (including future
@@ -108,7 +108,7 @@ express Statement of Purpose.
     statutory or otherwise, including without limitation warranties of
     title, merchantability, fitness for a particular purpose, non
     infringement, or the absence of latent or other defects, accuracy, or
-    the present or absence of errors, whether or not discoverable, all to
+    the presence or absence of errors, whether or not discoverable, all to
     the greatest extent permissible under applicable law.
  c. Affirmer disclaims responsibility for clearing rights of other persons
     that may apply to the Work or any use thereof, including without

README.md

@@ -2,20 +2,20 @@
 
 *Please note that ERCs were recently separated from the [EIPs](https://github.com/ethereum/eips) repo.*
 
-The goal of ERCs is to standardize and provide high-quality documentation for the Ethereum application layer. This repository tracks past and ongoing improvements application standards in the form of ERCs. [EIP-1](https://eips.ethereum.org/EIPS/eip-1) governs how EIPs and ERCs are published.
+The goal of ERCs is to standardize and provide high-quality documentation for the Ethereum application layer. This repository tracks past and ongoing improvements in application standards in the form of ERCs. [EIP-1](https://eips.ethereum.org/EIPS/eip-1) governs how EIPs and ERCs are published.
 
 The [status page](https://eips.ethereum.org/) tracks and lists both EIPs and ERCs, which can be divided into the following categories:
 
 - [Core EIPs](https://eips.ethereum.org/core) are improvements to the Ethereum consensus protocol.
 - [Networking EIPs](https://eips.ethereum.org/networking) specify the peer-to-peer networking layer of Ethereum.
-- [Interface EIPs](https://eips.ethereum.org/interface) standardize interfaces to Ethereum, which determine how users and applications interact with the blockchain.
+- [Interface EIPs](https://eips.ethereum.org/interface) standardize interfaces to Ethereum, which define how users and applications interact with the blockchain.
 - [ERCs](https://eips.ethereum.org/erc) specify application layer standards, which determine how applications running on Ethereum can interact with each other.
 - [Meta EIPs](https://eips.ethereum.org/meta) are miscellaneous improvements that nonetheless require some sort of consensus.
 - [Informational EIPs](https://eips.ethereum.org/informational) are non-standard improvements that do not require any form of consensus.
 
 **Before you write an ERC, ideas MUST be thoroughly discussed on [Ethereum Magicians](https://ethereum-magicians.org/) or [Ethereum Research](https://ethresear.ch/t/read-this-before-posting/8). Once consensus is reached, thoroughly read and review [EIP-1](https://eips.ethereum.org/EIPS/eip-1), which describes the EIP/ERC process.**
 
-Please note that this repository is for documenting standards and not for help implementing them. These types of inquiries should be directed to the [Ethereum Stack Exchange](https://ethereum.stackexchange.com). For specific questions and concerns regarding ERCs, it's best to comment on the relevant discussion thread of the ERC denoted by the `discussions-to` tag in the ERC's preamble.
+Please note that this repository is for documenting standards and not for help implementing them. Such inquiries should be directed to the [Ethereum Stack Exchange](https://ethereum.stackexchange.com). For specific questions and concerns regarding ERCs, it's best to comment on the relevant discussion thread of the ERC denoted by the `discussions-to` tag in the ERC's preamble.
 
 If you would like to become an EIP Editor, please read [EIP-5069](https://eips.ethereum.org/EIPS/eip-5069).
 

_includes/social.html

@@ -7,7 +7,7 @@
   {%- if site.linkedin_username -%}<li><a href="https://www.linkedin.com/in/{{ site.linkedin_username| cgi_escape | escape }}"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#linkedin' | relative_url }}"></use></svg> <span class="username">{{ site.linkedin_username| escape }}</span></a></li>{%- endif -%}
   {%- if site.pinterest_username -%}<li><a href="https://www.pinterest.com/{{ site.pinterest_username| cgi_escape | escape }}"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#pinterest' | relative_url }}"></use></svg> <span class="username">{{ site.pinterest_username| escape }}</span></a></li>{%- endif -%}
   {%- for mst in site.mastodon -%}{%- if mst.username and mst.instance -%}<li><a href="https://{{ mst.instance| cgi_escape | escape}}/@{{mst.username}}"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#mastodon' | relative_url }}"></use></svg> <span class="username">{{ mst.username|escape }}</span></a></li>{%- endif -%}{%- endfor -%}
-  {%- if site.twitter_username -%}<li><a href="https://twitter.com/{{ site.twitter_username| cgi_escape | escape }}"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#twitter' | relative_url }}"></use></svg> <span class="username">{{ site.twitter_username| escape }}</span></a></li>{%- endif -%}
+  {%- if site.twitter_username -%}<li><a href="https://x.com/{{ site.twitter_username| cgi_escape | escape }}"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#twitter' | relative_url }}"></use></svg> <span class="username">{{ site.twitter_username| escape }}</span></a></li>{%- endif -%}
   {%- if site.youtube_username -%}<li><a href="https://youtube.com/{{ site.youtube_username| cgi_escape | escape }}"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#youtube' | relative_url }}"></use></svg> <span class="username">{{ site.youtube_username| escape }}</span></a></li>{%- endif -%}
   {%- if site.googleplus_username -%}<li><a href="https://plus.google.com/{{ site.googleplus_username| escape }}"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#googleplus' | relative_url }}"></use></svg> <span class="username">{{ site.googleplus_username| escape }}</span></a></li>{%- endif -%}
   {%- if site.rss -%}<li><a href="{{ 'feed.xml' | relative_url }}"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#rss' | relative_url }}"></use></svg> <span>{{ site.rss | escape }}</span></a></li>{%- endif -%}

erc-template.md

@@ -47,7 +47,7 @@ requires: <EIP number(s)> # Only required when you reference an EIP in the `Spec
 <!--
   The Specification section should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (besu, erigon, ethereumjs, go-ethereum, nethermind, or others).
 
-  It is recommended to follow RFC 2119 and RFC 8170. Do not remove the key word definitions if RFC 2119 and RFC 8170 are followed.
+  It is recommended to follow RFC 2119 and RFC 8174. Do not remove the key word definitions if RFC 2119 and RFC 8174 are followed.
 
   TODO: Remove this comment before submitting
 -->
@@ -79,14 +79,14 @@ TBD
   TODO: Remove this comment before submitting
 -->
 
-No backward compatibility issues found.
+No known backward compatibility issues.
 
 ## Test Cases
 
 <!--
   This section is optional for non-Core EIPs.
 
-  The Test Cases section should include expected input/output pairs, but may include a succinct set of executable tests. It should not include project build files. No new requirements may be be introduced here (meaning an implementation following only the Specification section should pass all tests here.)
+  The Test Cases section should include expected input/output pairs, but may include a succinct set of executable tests. It should not include project build files. No new requirements may be introduced here (meaning an implementation following only the Specification section should pass all tests here.)
   If the test suite is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`. External links will not be allowed
 
   TODO: Remove this comment before submitting