ethereum · axic · Nov 22, 2019 · Nov 12, 2019 · Nov 12, 2019
@@ -56,7 +56,7 @@ In addition to making sure your idea is original, it will be your role as the au
 
 For Core EIPs, given that they require client implementations to be considered **Final** (see "EIPs Process" below), you will need to either provide an implementation for clients or convince clients to implement your EIP. 
 
-The best way to get client implementers to review your EIP is to present it on an AllCoreDevs call. You can request to do so by posting a comment linking your EIP on an [AllCoreDevs agenda Github Issue]. 
+The best way to get client implementers to review your EIP is to present it on an AllCoreDevs call. You can request to do so by posting a comment linking your EIP on an [AllCoreDevs agenda GitHub Issue]. 
 
 The AllCoreDevs call serve as a way for client implementers to do three things. First, to discuss the technical merits of EIPs. Second, to gauge what other clients will be implementing. Third, to coordinate EIP implementation for network upgrades.
 
@@ -249,7 +249,7 @@ For each new EIP that comes in, an editor does the following:
 
 - Read the EIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status.
 - The title should accurately describe the content.
-- Check the EIP for language (spelling, grammar, sentence structure, etc.), markup (Github flavored Markdown), code style
+- Check the EIP for language (spelling, grammar, sentence structure, etc.), markup (GitHub flavored Markdown), code style
 
 If the EIP isn't ready, the editor will send it back to the author for revision, with specific instructions.
 
@@ -314,7 +314,7 @@ See [the revision history for further details](https://github.com/ethereum/EIPs/
 [Bitcoin's BIP-0001]: https://github.com/bitcoin/bips
 [Python's PEP-0001]: https://www.python.org/dev/peps/
 [the Ethereum Magicians forum]: https://ethereum-magicians.org/
-[AllCoreDevs agenda Github Issue]: https://github.com/ethereum/pm/issues
+[AllCoreDevs agenda GitHub Issue]: https://github.com/ethereum/pm/issues
 
 ## Copyright
 

@@ -700,7 +700,7 @@ Another simple way to represent non-fungibles is to allow a maximum value of 1 f
 - [The Sandbox - Dual ERC-1155/721 Contract](https://github.com/pixowl/thesandbox-contracts/tree/master/src/Asset)
 
 **Articles & Discussions**
-- [Github - Original Discussion Thread](https://github.com/ethereum/EIPs/issues/1155)
+- [GitHub - Original Discussion Thread](https://github.com/ethereum/EIPs/issues/1155)
 - [ERC-1155 - The Crypto Item Standard](https://blog.enjincoin.io/erc-1155-the-crypto-item-standard-ac9cf1c5a226)
 - [Here Be Dragons - Going Beyond ERC-20 and ERC-721 To Reduce Gas Cost by ~80%](https://medium.com/horizongames/going-beyond-erc20-and-erc721-9acebd4ff6ef)
 - [Blockonomi - Ethereum ERC-1155 Token Perfect for Online Games, Possibly More](https://blockonomi.com/erc1155-gaming-token/)

@@ -295,9 +295,9 @@ One can think of the set of MVTs as identifying a user, and you cannot split the
 
 The assign and revoke functions' documentation only specify conditions when the transaction MUST throw. Your implementation MAY also throw in other situations. This allows implementations to achieve interesting results:
 
-- **Disallow additional memberships after a condition is met** — Sample contract available on Github
-- **Blacklist certain address from receiving MV tokens** — Sample contract available on Github
-- **Disallow additional memberships after a certain time is reached** — Sample contract available on Github
+- **Disallow additional memberships after a condition is met** — Sample contract available on GitHub
+- **Blacklist certain address from receiving MV tokens** — Sample contract available on GitHub
+- **Disallow additional memberships after a certain time is reached** — Sample contract available on GitHub
 - **Charge a fee to user of a transaction** — require payment when calling `assign` and `revoke` so that condition checks from external sources can be made
 
 **ERC-173 Interface**

@@ -170,7 +170,7 @@ Registries may offer more complex `read` APIs that manage requests for packages
 No existing standard exists for package registries. The package registry currently deployed by EthPM would not comply with the standard since it implements only one of the method signatures described in the specification.
 
 ## Implementation
-A reference implementation of this proposal is in active development at the EthPM organization on Github [here](https://github.com/ethpm/escape-truffle).
+A reference implementation of this proposal is in active development at the EthPM organization on GitHub [here](https://github.com/ethpm/escape-truffle).
 
 ## Copyright
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
@@ -104,7 +104,7 @@ properties:
 ## Implementation
 <!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
 
-The Smart Contract Weakness Classification registry located in this [Github repository](https://github.com/SmartContractSecurity/SWC-registry) uses the SWC scheme proposed in this EIP. A Github Pages rendered version is also available [here](https://smartcontractsecurity.github.io/SWC-registry/).
+The Smart Contract Weakness Classification registry located in this [GitHub repository](https://github.com/SmartContractSecurity/SWC-registry) uses the SWC scheme proposed in this EIP. A GitHub Pages rendered version is also available [here](https://smartcontractsecurity.github.io/SWC-registry/).
 
 ## Copyright
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
@@ -168,8 +168,8 @@ The Scope Metadata JSON Schema was added in order to support human-readable scop
 - [Enjin Coin](https://enjincoin.io) ([github](https://github.com/enjin))
 
 **Articles & Discussions**
-- [Github - Original Discussion Thread](https://github.com/ethereum/EIPs/issues/1761)
-- [Github - ERC-1155 Discussion Thread](https://github.com/ethereum/EIPs/issues/1155)
+- [GitHub - Original Discussion Thread](https://github.com/ethereum/EIPs/issues/1761)
+- [GitHub - ERC-1155 Discussion Thread](https://github.com/ethereum/EIPs/issues/1155)
 
 ## Copyright
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
@@ -64,11 +64,11 @@ This interface is designed to be compatible with ERC-721.
 
 A reference implementation accompany with tests of **ERC-721 based ticket** contract is built and you can found it [here](https://github.com/xinbenlv/eip-2135/blob/master/impl/contracts/Ticket721.sol).
 
-See [Github/xinbenlv/eip-2135/impl](https://github.com/xinbenlv/eip-2135/tree/master/impl)
+See [GitHub/xinbenlv/eip-2135/impl](https://github.com/xinbenlv/eip-2135/tree/master/impl)
 
 ## Test Cases
 
-See [Github/xinbenlv/eip-2135/impl/test](https://github.com/xinbenlv/eip-2135/tree/master/impl/test)
+See [GitHub/xinbenlv/eip-2135/impl/test](https://github.com/xinbenlv/eip-2135/tree/master/impl/test)
 
 ## Reference
 

@@ -26,7 +26,7 @@ Web3 Wallets are built around the responsibility of mediating the interactions b
 
 Today web3 browsers like MetaMask always prompt on a per-action basis. This provides security at the cost of substantial user friction. We believe that a single permissions request can achieve the same level of security with vastly improved UX.
 
-The pattern of permissions requests is common around the web, from login with Facebook, Twitter, Github, and even Apple, making it a very familiar pattern.
+The pattern of permissions requests is common around the web, from login with Facebook, Twitter, GitHub, and even Apple, making it a very familiar pattern.
 
 ![facebook permissions](https://proxy.duckduckgo.com/iu/?u=https%3A%2F%2Fi.stack.imgur.com%2FG7dRV.png&f=1)
 

@@ -52,7 +52,7 @@ The Meta EIP representing the hard fork should move in to the `Accepted` state o
 
 ## Template
 
-A template for the [Istanbul Hardfork Meta 1679](https://eips.ethereum.org/EIPS/eip-1679) is included below ([source file on Github](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1679.md)):
+A template for the [Istanbul Hardfork Meta 1679](https://eips.ethereum.org/EIPS/eip-1679) is included below ([source file on GitHub](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1679.md)):
 
 ```
 {% raw %}

@@ -4,5 +4,5 @@ We have a GitHub bot that automatically merges some PRs. It will merge yours imm
 
  - The PR edits only existing draft PRs.
  - The build passes.
- - Your Github username or email address is listed in the 'author' header of all affected PRs, inside <triangular brackets>.
+ - Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside <triangular brackets>.
  - If matching on email address, the email address is the one publicly listed on your GitHub profile.
@@ -17,7 +17,7 @@ Your first PR should be a first draft of the final EIP. It must meet the formatt
 
 If your EIP requires images, the image files should be included in a subdirectory of the `assets` folder for that EIP as follows: `assets/eip-N` (where **N** is to be replaced with the EIP number). When linking to an image in the EIP, use relative links such as `../assets/eip-1/image.png`.
 
-Once your first PR is merged, we have a bot that helps out by automatically merging PRs to draft EIPs. For this to work, it has to be able to tell that you own the draft being edited. Make sure that the 'author' line of your EIP contains either your Github username or your email address inside <triangular brackets>. If you use your email address, that address must be the one publicly shown on [your GitHub profile](https://github.com/settings/profile).
+Once your first PR is merged, we have a bot that helps out by automatically merging PRs to draft EIPs. For this to work, it has to be able to tell that you own the draft being edited. Make sure that the 'author' line of your EIP contains either your GitHub username or your email address inside <triangular brackets>. If you use your email address, that address must be the one publicly shown on [your GitHub profile](https://github.com/settings/profile).
 
 When you believe your EIP is mature and ready to progress past the draft phase, you should do one of two things:
 
@@ -48,7 +48,7 @@ eip_validator <INPUT_FILES>
 
 # Automerger
 
-The EIP repository contains an "auto merge" feature to ease the workload for EIP editors. If a change is made via a PR to a draft EIP, then the authors of the EIP can Github approve the change to have it auto-merged by the [eip-automerger](https://github.com/eip-automerger/automerger) bot.
+The EIP repository contains an "auto merge" feature to ease the workload for EIP editors. If a change is made via a PR to a draft EIP, then the authors of the EIP can GitHub approve the change to have it auto-merged by the [eip-automerger](https://github.com/eip-automerger/automerger) bot.
 
 # Local development
 
@@ -86,4 +86,4 @@ $ bundle exec jekyll serve
 
 2. Preview your local Jekyll site in your web browser at `http://localhost:4000`.
 
-More information on Jekyll and Github pages [here](https://help.github.com/en/enterprise/2.14/user/articles/setting-up-your-github-pages-site-locally-with-jekyll).
+More information on Jekyll and GitHub pages [here](https://help.github.com/en/enterprise/2.14/user/articles/setting-up-your-github-pages-site-locally-with-jekyll).