Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update ERC-6734: Move to Review #601

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

Update ERC-6734: Move to Review #601

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
44f77ce
Move ERC 6734 to Status: Review
Therecanbeonlyone1969 Aug 22, 2024
c0695f3
Updates based on feedbacl
Therecanbeonlyone1969 Sep 3, 2024
700bc78
Merge remote-tracking branch 'upstream/master' into patch-1-6734-ther…
Therecanbeonlyone1969 Sep 3, 2024
84fc299
updated requires section to remove 3220
Therecanbeonlyone1969 Sep 17, 2024
03b3f40
Merge branch 'master' into patch-1-6734-therecanbeonlyone1969
Therecanbeonlyone1969 Sep 17, 2024
15c10e7
Merge branch 'master' into patch-1-6734-therecanbeonlyone1969
Therecanbeonlyone1969 Sep 17, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 5 additions & 10 deletions ERCS/erc-6734.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,11 +4,11 @@
description: Token List that ensures the correct identification of tokens from different Layer 1, Layer 2, or Sidechains.
author: Kelvin Fichter (@smartcontracts), Andreas Freund (@Therecanbeonlyone1969), Pavel Sinelnikov (@psinelnikov)
discussions-to: https://ethereum-magicians.org/t/canonical-token-list-standard-from-the-eea-oasis-community-projects-l2-standards-working-group/13091
status: Draft
status: Review
type: Standards Track
category: ERC
created: 2023-03-20
requires: 155, 3220
requires: 155
---

## Abstract
Expand Down Expand Up @@ -133,12 +133,7 @@

Namely, transaction replay protection on the network that is identified by the chainId property value. Note, that for replay protection to be guaranteed, the chainId should be unique. Ensuring a unique chainId is beyond the scope of this document.

[[R4]](#r4) testability: EIP-155 requires that a transaction hash is derived from the keccak256 hash of the following nine RLP encoded elements `(nonce, gasprice, startgas, to, value, data, chainid, 0, 0)` which can be tested easily with existing cryptographic libraries. EIP-155 further requires that the `v` value of the secp256k1 signature must be set to `{0,1} + CHAIN_ID * 2 + 35` where `{0,1}` is the parity of the `y` value of the curve point for which the signature `r`-value is the `x`-value in the secp256k1 signing process. This requirement is testable with available open-source secp256k1 digital signature suites. Therefore, [[R4]](#r4) is testable.

<a name="d2"> **[D2]** </a>
The `chainId` property SHOULD follow [EIP-3220](./eip-3220.md) draft standard.

[[D2]](#d2) testability: The [EIP-3220](./eip-3220.md) draft standard can be tested because the crosschain id is specified as a concatenation of well-defined strings, and using open source tooling can be used to parse and split a crosschain id, the obtained string segments can be compared against expected string lengths, and context dependent, the values for the strings specified in the standard. Consequently, [[D2]](#d2) is testable.
[[R4]](#r4) testability: EIP-155 requires that a transaction hash is derived from the keccak256 hash of the following nine RLP encoded elements `(nonce, gasprice, startgas, to, value, data, chainid, 0, 0)` which can be tested easily with existing cryptographic libraries. EIP-155 further requires that the `v` value of the secp256k1 signature must be set to `{0,1} + CHAIN_ID * 2 + 35` where `{0,1}` is the parity of the `y` value of the curve point for which the signature `r`-value is the `x`-value in the secp256k1 signing process. This requirement is testable with available open-source secp256k1 digital signature suites. Therefore, [[R4]](#r4) is testable.

<a name="o1"> **[O1]** </a>
The `humanReadableTokenSymbol` property MAY be used.
Expand Down Expand Up @@ -491,10 +486,10 @@
* **Level 2:** All MUST and SHOULD requirements are fulfilled by a specific implementation as proven by a test report that proves in an easily understandable manner the implementation's conformance with each requirement based on implementation-specific test-fixtures with implementation-specific test-fixture inputs.
* **Level 3:** All MUST, SHOULD, and MAY requirements with conditional MUST or SHOULD requirements are fulfilled by a specific implementation as proven by a test report that proves in an easily understandable manner the implementation's conformance with each requirement based on implementation-specific test-fixtures with implementation-specific test-fixture inputs.

<a name="d3"> **[D3]** </a>
<a name="d2"> **[D2]** </a>
A claim that a canonical token list implementation conforms to this specification SHOULD describe a testing procedure carried out for each requirement to which conformance is claimed, that justifies the claim with respect to that requirement.

[[D3]](#d3) testability: Since each of the non-conformance-target requirements in this documents is testable, so must be the totality of the requirements in this document. Therefore, conformance tests for all requirements can exist, and can be described as required in [[D3]](#d3).
[[D2]](#d2) testability: Since each of the non-conformance-target requirements in this documents is testable, so must be the totality of the requirements in this document. Therefore, conformance tests for all requirements can exist, and can be described as required in [[D2]](#d2).

<a name="r5"> **[R5]** </a>
A claim that a canonical token list implementation conforms to this specification at **Level 2** or higher MUST describe the testing procedure carried out for each requirement at **Level 2** or higher, that justifies the claim to that requirement.
Expand All @@ -510,7 +505,7 @@

## Security Considerations

There are no additional security requirements apart from the warnings that URIs utilized in implementations of this standard might be direct to malicious resources such as websites, and that implementers should ensure that data utilized for a canonical token list is secure and correct. Since this standard is focused on a data schema and its data properties there are no additional security considerations from for example homoglyph attacks (see [CVE-2021-42574 (2021-10-25T12:38:28)](https://nvd.nist.gov/vuln/detail/CVE-2021-42574)).

Check failure on line 508 in ERCS/erc-6734.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image 

error[markdown-rel-links]: non-relative link or image
   --> ERCS/erc-6734.md
    |
508 | There are no additional security requirements apart from the warnings that URIs utilized in implementations of this standard might be direct to malicious resources such as websites, and that implementers should ensure that data utilized for a canonical token list is secure and correct. Since this standard is focused on a data schema and its data properties there are no additional security considerations from for example homoglyph attacks (see [CVE-2021-42574 (2021-10-25T12:38:28)](https://nvd.nist.gov/vuln/detail/CVE-2021-42574)).
    |
    = help: see https://ethereum.github.io/eipw/markdown-rel-links/

### Security Considerations: Data Privacy

Expand Down
Loading