From f15a7fb54ba53b2fc6a19c36c19fc6c816d2d40d Mon Sep 17 00:00:00 2001 From: Danyll <37103154+Danyylka@users.noreply.github.com> Date: Mon, 25 Nov 2024 20:56:15 +0100 Subject: [PATCH 1/5] typo fix 12.mdx I have fixed the issue by adding the missing hyphens, changing ERC721 to ERC-721 and ERC1155 to ERC-1155. --- docs/ensip/12.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/ensip/12.mdx b/docs/ensip/12.mdx index 0d2237cc..d3a35614 100644 --- a/docs/ensip/12.mdx +++ b/docs/ensip/12.mdx @@ -78,12 +78,12 @@ If a [data URL](https://datatracker.ietf.org/doc/html/rfc2397) is provided, it M A reference to an NFT may be used as an avatar URI, following the standards defined in [CAIP-22](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-22.md) and [CAIP-29](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-29.md). -Clients MUST support at least ERC721 and ERC1155 type NFTs, and MAY support additional types of NFT. +Clients MUST support at least ERC-721 and ERC-1155 type NFTs, and MAY support additional types of NFT. To resolve an NFT URI, a client follows this process: 1. Retrieve the metadata URI for the token specified in the `avatar` field URI. -2. Resolve the metadata URI, fetching the ERC721 or ERC1155 metadata. +2. Resolve the metadata URI, fetching the ERC-721 or ERC-1155 metadata. 3. Extract the image URL specified in the NFT metadata. 4. Resolve the image URL and use it as the avatar. From 25b81c58146b859396eb5fe45ad1b0f9f306d56c Mon Sep 17 00:00:00 2001 From: Danyll <37103154+Danyylka@users.noreply.github.com> Date: Mon, 25 Nov 2024 21:16:18 +0100 Subject: [PATCH 2/5] Typos fix 11.mdx "compatible" should be written with a hyphen as "EVM-compatible" because it is a compound adjective describing the type of chains. "non EVM" should be written with a hyphen as "non-EVM" because it is a compound adjective. --- docs/ensip/11.mdx | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/ensip/11.mdx b/docs/ensip/11.mdx index cd1edf7b..54aa9563 100644 --- a/docs/ensip/11.mdx +++ b/docs/ensip/11.mdx @@ -1,6 +1,6 @@ {/** @type {import('@/lib/mdxPageProps').MdxMetaProps} */} export const meta = { - description: 'Introduces coinType for EVM compatible chains (amending ENSIP9).', + description: 'Introduces coinType for EVM-compatible chains (amending ENSIP9).', contributors: [ // Makoto Inoue 'makoto' @@ -11,19 +11,19 @@ export const meta = { } }; -# ENSIP-11: EVM compatible Chain Address Resolution +# ENSIP-11: EVM-compatible Chain Address Resolution -Introduces coinType for EVM compatible chains (amending [ENSIP-9](./9)). +Introduces coinType for EVM-compatible chains (amending [ENSIP-9](./9)). ## Abstract -This ENSIP extends [ENSIP 9 (multichain address resolution)](./9), dedicates a range of coin types for EVM compatible chains, and specifies a way to derive EVM chain IDs to the designated coin types. +This ENSIP extends [ENSIP 9 (multichain address resolution)](./9), dedicates a range of coin types for EVM-compatible chains, and specifies a way to derive EVM chain IDs to the designated coin types. -The dedicated range uses over 0x80000000 (2147483648) which is reserved under ENSIP 9 so there will be no possibility of coin type collision with other non EVM coin types to be added in future. However, some of coin types previously allocated to EVM chain ids will be deprecated. +The dedicated range uses over 0x80000000 (2147483648) which is reserved under ENSIP 9 so there will be no possibility of coin type collision with other non-EVM coin types to be added in future. However, some of coin types previously allocated to EVM chain ids will be deprecated. ## Motivation -The existing ENSIP 9 relies on the existence of coin types on [SLIP44](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) which was designed to define address encoding type for deterministic wallets. As the majority of EVM compatible chains inherit the same encoding type as Ethereum, it is redundant to keep requesting the addition of EVM compatible chains into SLIP 44. This specification standardises a way to derive coinType based on [Chain ID](https://chainlist.org). +The existing ENSIP 9 relies on the existence of coin types on [SLIP44](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) which was designed to define address encoding type for deterministic wallets. As the majority of EVM-compatible chains inherit the same encoding type as Ethereum, it is redundant to keep requesting the addition of EVM-compatible chains into SLIP 44. This specification standardises a way to derive coinType based on [Chain ID](https://chainlist.org). ## Specification @@ -84,14 +84,14 @@ You can also use existing functions formatsByName and formatsByCoinType to deriv The following EVM chains are the exception to this standard. -* AVAX = AVAX has multiple chain address formats, and only c chain is EVM compatible +* AVAX = AVAX has multiple chain address formats, and only c chain is EVM-compatible * RSK = RSK has its own additional validation They will continue using coinType defined at SLIP44 ### Backwards Compatibility -The following EVM compatible cointypes existed before introducing this new standard. +The following EVM-compatible cointypes existed before introducing this new standard. * NRG * POA From ceb5adffec611e453c02e268498feecf8d65ccfd Mon Sep 17 00:00:00 2001 From: Danyll <37103154+Danyylka@users.noreply.github.com> Date: Mon, 25 Nov 2024 21:21:38 +0100 Subject: [PATCH 3/5] fix typo index.mdx I have corrected the spelling error by changing "soverign" to "sovereign." --- docs/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/index.mdx b/docs/index.mdx index 9a42b9d5..321e7bd9 100644 --- a/docs/index.mdx +++ b/docs/index.mdx @@ -13,7 +13,7 @@ export const meta = {

ENS Documentation

-

Build applications with decentralized self-soverign identity.

+

Build applications with decentralized self-sovereign identity.

From e28f8ca529528b73e89484cd5b32f74b067834ad Mon Sep 17 00:00:00 2001 From: Danyll <37103154+Danyylka@users.noreply.github.com> Date: Mon, 25 Nov 2024 21:23:59 +0100 Subject: [PATCH 4/5] fix typo faq.mdx --- docs/faq.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/faq.mdx b/docs/faq.mdx index f2c4ef8d..38375e7e 100644 --- a/docs/faq.mdx +++ b/docs/faq.mdx @@ -56,7 +56,7 @@ Currently, registration costs are set at the following prices: 3 and 4 character names have higher pricing to reflect the small number of these names available. -To read more about the pricing structure of .eth names [read more about pricing](/registry/eth) +To read more about the pricing structure of .eth names [read more about the pricing](/registry/eth) ### How long can I register a name for? From 2aa1ee0f50417f6653fa21b7c11c9da077184b5c Mon Sep 17 00:00:00 2001 From: Danyll <37103154+Danyylka@users.noreply.github.com> Date: Mon, 25 Nov 2024 21:28:21 +0100 Subject: [PATCH 5/5] fix typos CONTRIBUTING.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit "checkout" → "check out" In this context, "check out" should be written with a space, as it is a phrasal verb. "create a pull request" → "create a Pull Request" In documentation, it is common to capitalize the name of a process or specific action, such as Pull Request. --- CONTRIBUTING.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 4fac54fe..d893439d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -6,7 +6,7 @@ In this guide you will get an overview of the contribution workflow from opening ## Getting started -This guide will walk you through the process of contributing to the ENS docs. If you are new to GitHub, you can checkout this [GitHub tutorial](https://guides.github.com/activities/hello-world/) to get started. +This guide will walk you through the process of contributing to the ENS docs. If you are new to GitHub, you can check out this [GitHub tutorial](https://guides.github.com/activities/hello-world/) to get started. ### Issues @@ -38,14 +38,14 @@ Commit the changes once you are happy with them. Upon creating a Pull Request yo ### Pull Request -When you're finished with the changes, create a pull request, also known as a PR. +When you're finished with the changes, create a Pull Request, also known as a PR. - Fill the "Ready for review" template so that we can review your PR. This template helps reviewers understand your changes as well as the purpose of your pull request. - Don't forget to [link PR to issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) if you are solving one. - Enable the checkbox to [allow maintainer edits](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/allowing-changes-to-a-pull-request-branch-created-from-a-fork) so the branch can be updated for a merge. Once you submit your PR, a Docs team member will review your proposal. We may ask questions or request additional information. - We may ask for changes to be made before a PR can be merged, either using [suggested changes](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/incorporating-feedback-in-your-pull-request) or pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch. - As you update your PR and apply changes, mark each conversation as [resolved](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request#resolving-conversations). -- If you run into any merge issues, checkout this [git tutorial](https://github.com/skills/resolve-merge-conflicts) to help you resolve merge conflicts and other issues. +- If you run into any merge issues, check out this [git tutorial](https://github.com/skills/resolve-merge-conflicts) to help you resolve merge conflicts and other issues. ### Your PR is merged!