Skip to content

Update EIP-712: typo fix #9699

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

Merged
merged 2 commits into from
May 27, 2025
Merged

Update EIP-712: typo fix #9699

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ff946f2
Update EIP-7691: typo fix
wmjae Apr 28, 2025
a36cec5
Update eip-7691.md
SamWilsn May 27, 2025
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
4 changes: 2 additions & 2 deletions EIPS/eip-712.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,13 +15,13 @@

This is a standard for hashing and signing of typed structured data as opposed to just bytestrings. It includes a

* theoretical framework for correctness of encoding functions,

Check failure on line 18 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3] 

EIPS/eip-712.md:18:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]
* specification of structured data similar to and compatible with Solidity structs,

Check failure on line 19 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3] 

EIPS/eip-712.md:19:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]
* safe hashing algorithm for instances of those structures,

Check failure on line 20 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3] 

EIPS/eip-712.md:20:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]
* safe inclusion of those instances in the set of signable messages,

Check failure on line 21 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3] 

EIPS/eip-712.md:21:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]
* an extensible mechanism for domain separation,

Check failure on line 22 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3] 

EIPS/eip-712.md:22:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]
* new RPC call `eth_signTypedData`, and

Check failure on line 23 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3] 

EIPS/eip-712.md:23:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]
* an optimized implementation of the hashing algorithm in EVM.

Check failure on line 24 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3] 

EIPS/eip-712.md:24:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]

It does not include replay protection.

Expand All @@ -42,13 +42,13 @@
## Specification

The set of signable messages is extended from transactions and bytestrings `𝕋 ∪ 𝔹⁸ⁿ` to also include structured data `𝕊`. The new set of signable messages is thus `𝕋 ∪ 𝔹⁸ⁿ ∪ 𝕊`. They are encoded to bytestrings suitable for hashing and signing as follows:
* `encode(transaction : 𝕋) = RLP_encode(transaction)`

Check failure on line 45 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3] 

EIPS/eip-712.md:45:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]

Check failure on line 45 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Lists should be surrounded by blank lines [Context: "* `encode(transaction : 𝕋) ..."] 

EIPS/eip-712.md:45 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "*   `encode(transaction : 𝕋) ..."]
* `encode(message : 𝔹⁸ⁿ) = "\x19Ethereum Signed Message:\n" ‖ len(message) ‖ message` where `len(message)` is the _non-zero-padded_ ascii-decimal encoding of the number of bytes in `message`.

Check failure on line 46 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Spaces after list markers [Expected: 1; Actual: 3] 

EIPS/eip-712.md:46:1 MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 3]
* `encode(domainSeparator : 𝔹²⁵⁶, message : 𝕊) = "\x19\x01" ‖ domainSeparator ‖ hashStruct(message)` where `domainSeparator` and `hashStruct(message)` are defined below.

This encoding is deterministic because the individual components are. The encoding is injective because the three cases always differ in first byte. (`RLP_encode(transaction)` does not start with `\x19`.)

The encoding is compliant with [EIP-191][EIP-191]. The 'version byte' is fixed to `0x01`, the 'version specific data' is the 32-byte domain separator `domainSeparator` and the 'data to sign' is the 32-byte `hashStruct(message)`.

Check failure on line 51 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

references to proposals with a `category` of `ERC` must use a prefix of `ERC` 

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC`
  --> EIPS/eip-712.md
   |
51 | The encoding is compliant with [EIP-191][EIP-191]. The 'version byte' is fixed to `0x01`, the 'version specific data' is the 32-byte...
   |
   = help: see https://ethereum.github.io/eipw/markdown-refs/

[EIP-191]: ./eip-191.md

Expand Down Expand Up @@ -115,7 +115,7 @@
* `string version` the current major version of the signing domain. Signatures from different versions are not compatible.
* `uint256 chainId` the [EIP-155][EIP-155] chain id. The user-agent *should* refuse signing if it does not match the currently active chain.
* `address verifyingContract` the address of the contract that will verify the signature. The user-agent *may* do contract specific phishing prevention.
* `bytes32 salt` an disambiguating salt for the protocol. This can be used as a domain separator of last resort.
* `bytes32 salt` a disambiguating salt for the protocol. This can be used as a domain separator of last resort.

[EIP-155]: ./eip-155.md

Expand Down Expand Up @@ -267,7 +267,7 @@

**Alternative 2**: Use ABIv2 function signatures. `bytes4` is not enough to be collision resistant. Unlike function signatures, there is negligible runtime cost incurred by using longer hashes.

**Alternative 3**: ABIv2 function signatures modified to be 256-bit. While this captures type info, it does not capture any of the semantics other than the function. This is already causing a practical collision between [EIP-20]'s and [EIP-721]'s `transfer(address,uint256)`, where in the former the `uint256` refers to an amount and the latter to a unique id. In general ABIv2 favors compatibility where a hashing standard should prefer incompatibility.

Check failure on line 270 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

references to proposals with a `category` of `ERC` must use a prefix of `ERC` 

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC`
   --> EIPS/eip-712.md
    |
270 | **Alternative 3**: ABIv2 function signatures modified to be 256-bit. While this captures type info, it does not capture any of the ...
    |

Check failure on line 270 in EIPS/eip-712.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

references to proposals with a `category` of `ERC` must use a prefix of `ERC` 

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC`
   --> EIPS/eip-712.md
    |
270 | **Alternative 3**: ABIv2 function signatures modified to be 256-bit. While this captures type info, it does not capture any of the ...
    |

[EIP-20]: ./eip-20.md
[EIP-721]: ./eip-721.md
Expand Down Expand Up @@ -321,7 +321,7 @@

The in-place implementation makes strong but reasonable assumptions on the memory layout of structs in memory. Specifically it assumes structs are not allocated below address 32, that members are stored in order, that all values are padded to 32-byte boundaries, and that dynamic and reference types are stored as a 32-byte pointers.

**Alternative 6**: Tight packing. This is the default behaviour in Soldity when calling `keccak256` with multiple arguments. It minimizes the number of bytes to be hashed but requires complicated packing instructions in EVM to do so. It does not allow in-place computation.
**Alternative 6**: Tight packing. This is the default behaviour in Solidity when calling `keccak256` with multiple arguments. It minimizes the number of bytes to be hashed but requires complicated packing instructions in EVM to do so. It does not allow in-place computation.

**Alternative 7**: ABIv2 encoding. Especially with the upcoming `abi.encode` it should be easy to use `abi.encode` as the `encodeData` function. The ABIv2 standard by itself fails the determinism security criteria. There are several valid ABIv2 encodings of the same data. ABIv2 does not allow in-place computation.

Expand Down
Loading