From fb2e853587e5e4537702048d3e67769f80dcb4e5 Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Thu, 23 May 2024 18:50:28 -0300 Subject: [PATCH 01/21] Add EIP: Box types for EIP-712 messages --- EIPS/eip-draft_box_types_712.md | 157 ++++++++++++++++++++++++++++++++ 1 file changed, 157 insertions(+) create mode 100644 EIPS/eip-draft_box_types_712.md diff --git a/EIPS/eip-draft_box_types_712.md b/EIPS/eip-draft_box_types_712.md new file mode 100644 index 00000000000000..7578f4644bdb25 --- /dev/null +++ b/EIPS/eip-draft_box_types_712.md @@ -0,0 +1,157 @@ +--- +title: Box types for EIP-712 messages +description: A mechanism for EIP-712 messages to contain parameters of arbitrary type +author: Francisco Giordano +discussions-to: +status: Draft +type: Standards Track +category: Interface +created: 2024-05-23 +requires: 712 +--- + +## Abstract + +A special type `box` is defined for EIP-712 messages. A `box` value is a value of an arbitrary struct type whose underlying type is encapsulated from the containing struct, but transparent and type-checkable by the wallet, and thus able to be fully inspected by the user prior to signing. A verifying contract can be made agnostic to the underlying type of a `box` value, but this type is not erased and can be verified on-chain if necessary. + +## Motivation + +[EIP-712](./eip-712.md) signatures have become a widely used primitive for users to express and authorize intents off-chain. Wide-ranging applications are able to define parameterized messages for users to sign in their wallet through a general-purpose interface that clearly surfaces the type, parameters, and domain of authorization. This crucially applies to hardware wallets as a last line of defense. + +The general-purpose nature of EIP-712 is key to its success, but in addition wallets are able to develop special-purpose interfaces and capabilities for specific types of messages as they become more widely used. For example, [ERC-2612](./eip-2612.md) Permits are a well-known EIP-712 message that wallets display to the user in a special way that clearly surfaces the known implications and risks of signing. + +Special-purpose interfaces improve usability and security for the user, but rely on standardized message types such as Permits. This EIP concerns the ability to standardize messages that contain within them parameters of arbitrary type. + +A recent example is found in ERC-7683, which defines a struct with the following member: +```solidity +/// @dev Arbitrary implementation-specific data +/// Can be used to define tokens, amounts, destination chains, fees, settlement parameters, +/// or any other order-type specific information +bytes orderData; +``` +Defining this parameter with type `bytes` enables the message to contain data of arbitrary type and is sufficient to bind the signature to implementation-specific data, but it amounts to type erasure. As a consequence, the user will be presented with an opaque bytestring in hexadecimal format in the wallet's signing interface. This negates the benefit of using EIP-712 signatures because the true contents of the parameter are invisible to the wallet's general-purpose interface. + +Another example is found in recent efforts to make [ERC-1271](./eip-1271.md) signatures secure against replay. Achieving this without making the message contents opaque to the signer requires embedding an application's EIP-712 message inside an outer message that binds it to a specific account. The type of the outer message depends on the type of the inner message, and making the type reproducible by the smart contract account on-chain for verification requires an inefficient scheme to communicate the string-encoded type of the inner message as a part of the signature. + +Both of these use cases would benefit from the ability to define EIP-712 struct parameters of arbitrary type in such a way that the verifying contract can be agnostic to the type of the parameter's value in a message while the wallet retains the ability to transparently display it to the user for inspection. + +## Specification + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. + +EIP-712 is extended as follows: + +### Typed structured data + +A struct type may contain a *boxed member* by declaring it with type `box`. Example: + +``` +struct Envelope { + address account; + box contents; +} +``` + +A boxed member has an underlying *unboxed type*, which is an arbitrary struct type and may be different in each message. + +### `encodeType` + +A boxed member is encoded as `"box " || name`. For example, the above `Envelope` struct is encoded as `Envelope(address account,box contents)`. + +### `encodeData` + +A boxed value is encoded as its underlying *unboxed value*, i.e., `hashStruct(value) = keccak256(typeHash, encodeData(value))` where `typeHash` corresponds to the unboxed type and `encodeData` is operating on a value of that type. + +### `signTypedData` schema + +A signature request for an EIP-712 message that involves a boxed member shall include the unboxed type as a part of the message object. A boxed value must be an object with properties `value`, `primaryType`, and `types`, with semantics similar to that of an EIP-712 message itself. The value shall be type-checked and encoded according to the values of `primaryType` and `types`. The `types` defined by the message outside of the boxed value shall not be in scope for the encoding of a boxed value. + +```js +{ + type: 'object', + properties: { + value: {type: 'object'}, + primaryType: {type: 'string'}, + types: { + type: 'object', + additionalProperties: { + type: 'array', + items: { + type: 'object', + properties: { + name: {type: 'string'}, + type: {type: 'string'} + }, + required: ['name', 'type'] + } + } + } + }, + required: ['value', 'primaryType', 'types'] +} +``` + +## Rationale + + + +TBD + +## Backwards Compatibility + + + +TBD + +## Test Cases + + + +## Reference Implementation + + + +## Security Considerations + + + +Needs discussion. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From 36e69347133aa803d6a11fa76539f7a22914746f Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Thu, 23 May 2024 19:02:42 -0300 Subject: [PATCH 02/21] add example --- EIPS/eip-draft_box_types_712.md | 33 ++++++++++++++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-draft_box_types_712.md b/EIPS/eip-draft_box_types_712.md index 7578f4644bdb25..606db3805aead4 100644 --- a/EIPS/eip-draft_box_types_712.md +++ b/EIPS/eip-draft_box_types_712.md @@ -64,7 +64,38 @@ A boxed value is encoded as its underlying *unboxed value*, i.e., `hashStruct(va ### `signTypedData` schema -A signature request for an EIP-712 message that involves a boxed member shall include the unboxed type as a part of the message object. A boxed value must be an object with properties `value`, `primaryType`, and `types`, with semantics similar to that of an EIP-712 message itself. The value shall be type-checked and encoded according to the values of `primaryType` and `types`. The `types` defined by the message outside of the boxed value shall not be in scope for the encoding of a boxed value. +A signature request for an EIP-712 message that involves a boxed member shall include the unboxed type as a part of the message object. A boxed value must be an object with properties `value`, `primaryType`, and `types`. The `value` shall be type-checked and encoded according to `primaryType` and `types`, analogously to an EIP-712 message (though without the `\x19` prefix). The `types` defined in the message outside of the boxed value shall not be in scope for the encoding of a boxed value. + +For example, a message for the `Envelope` type above may be represented as: + +```js +{ + domain: ..., + primaryType: 'Envelope', + types: { + Envelope: [ + { name: 'account', type: 'address' }, + { name: 'contents', type: 'box' } + ] + }, + message: { + account: '0x...', + contents: { + primaryType: 'Mail', + types: { + Mail: [ + { name: 'greeting', type: 'string' } + ] + }, + value: { + greeting: 'Hello world' + } + }, + } +} +``` + +#### JSON Schema of a boxed value ```js { From 86b198f960ccfafd254a94fdc58688cbfd9e1fe5 Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Thu, 23 May 2024 19:05:12 -0300 Subject: [PATCH 03/21] add discussions link --- EIPS/eip-draft_box_types_712.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-draft_box_types_712.md b/EIPS/eip-draft_box_types_712.md index 606db3805aead4..5387f1c392eb57 100644 --- a/EIPS/eip-draft_box_types_712.md +++ b/EIPS/eip-draft_box_types_712.md @@ -2,7 +2,7 @@ title: Box types for EIP-712 messages description: A mechanism for EIP-712 messages to contain parameters of arbitrary type author: Francisco Giordano -discussions-to: +discussions-to: https://ethereum-magicians.org/t/eip-box-types-for-eip-712-messages/20092 status: Draft type: Standards Track category: Interface From 7ce185f422c5210bf243ad2c7dc8d24993baeff5 Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Thu, 23 May 2024 19:05:33 -0300 Subject: [PATCH 04/21] use gh username --- EIPS/eip-draft_box_types_712.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-draft_box_types_712.md b/EIPS/eip-draft_box_types_712.md index 5387f1c392eb57..cff60cb90ab033 100644 --- a/EIPS/eip-draft_box_types_712.md +++ b/EIPS/eip-draft_box_types_712.md @@ -1,7 +1,7 @@ --- title: Box types for EIP-712 messages description: A mechanism for EIP-712 messages to contain parameters of arbitrary type -author: Francisco Giordano +author: Francisco Giordano <@frangio> discussions-to: https://ethereum-magicians.org/t/eip-box-types-for-eip-712-messages/20092 status: Draft type: Standards Track From c032b0f8ef20afec6b86e2f12357c65c8d6a9735 Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Thu, 23 May 2024 19:06:18 -0300 Subject: [PATCH 05/21] move link --- EIPS/eip-draft_box_types_712.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-draft_box_types_712.md b/EIPS/eip-draft_box_types_712.md index cff60cb90ab033..59a5cd1295ba1f 100644 --- a/EIPS/eip-draft_box_types_712.md +++ b/EIPS/eip-draft_box_types_712.md @@ -12,11 +12,11 @@ requires: 712 ## Abstract -A special type `box` is defined for EIP-712 messages. A `box` value is a value of an arbitrary struct type whose underlying type is encapsulated from the containing struct, but transparent and type-checkable by the wallet, and thus able to be fully inspected by the user prior to signing. A verifying contract can be made agnostic to the underlying type of a `box` value, but this type is not erased and can be verified on-chain if necessary. +A special type `box` is defined for [EIP-712](./eip-712.md) messages. A `box` value is a value of an arbitrary struct type whose underlying type is encapsulated from the containing struct, but transparent and type-checkable by the wallet, and thus able to be fully inspected by the user prior to signing. A verifying contract can be made agnostic to the underlying type of a `box` value, but this type is not erased and can be verified on-chain if necessary. ## Motivation -[EIP-712](./eip-712.md) signatures have become a widely used primitive for users to express and authorize intents off-chain. Wide-ranging applications are able to define parameterized messages for users to sign in their wallet through a general-purpose interface that clearly surfaces the type, parameters, and domain of authorization. This crucially applies to hardware wallets as a last line of defense. +EIP-712 signatures have become a widely used primitive for users to express and authorize intents off-chain. Wide-ranging applications are able to define parameterized messages for users to sign in their wallet through a general-purpose interface that clearly surfaces the type, parameters, and domain of authorization. This crucially applies to hardware wallets as a last line of defense. The general-purpose nature of EIP-712 is key to its success, but in addition wallets are able to develop special-purpose interfaces and capabilities for specific types of messages as they become more widely used. For example, [ERC-2612](./eip-2612.md) Permits are a well-known EIP-712 message that wallets display to the user in a special way that clearly surfaces the known implications and risks of signing. From 17c146ef201355967b38bc96c49098d9e51a6197 Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Thu, 23 May 2024 19:11:37 -0300 Subject: [PATCH 06/21] add 7683 link --- EIPS/eip-draft_box_types_712.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-draft_box_types_712.md b/EIPS/eip-draft_box_types_712.md index 59a5cd1295ba1f..163ec979a6eb36 100644 --- a/EIPS/eip-draft_box_types_712.md +++ b/EIPS/eip-draft_box_types_712.md @@ -22,7 +22,7 @@ The general-purpose nature of EIP-712 is key to its success, but in addition wal Special-purpose interfaces improve usability and security for the user, but rely on standardized message types such as Permits. This EIP concerns the ability to standardize messages that contain within them parameters of arbitrary type. -A recent example is found in ERC-7683, which defines a struct with the following member: +A recent example is found in [ERC-7683](https://ercs.ethereum.org/ERCS/erc-7683), which defines a struct with the following member: ```solidity /// @dev Arbitrary implementation-specific data /// Can be used to define tokens, amounts, destination chains, fees, settlement parameters, From a36283a3c92af6189783d87fc828ac3312a1760c Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Thu, 23 May 2024 19:14:15 -0300 Subject: [PATCH 07/21] add syntax highlighting --- EIPS/eip-draft_box_types_712.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-draft_box_types_712.md b/EIPS/eip-draft_box_types_712.md index 163ec979a6eb36..e53e4a90041173 100644 --- a/EIPS/eip-draft_box_types_712.md +++ b/EIPS/eip-draft_box_types_712.md @@ -45,7 +45,7 @@ EIP-712 is extended as follows: A struct type may contain a *boxed member* by declaring it with type `box`. Example: -``` +```solidity struct Envelope { address account; box contents; From 8c8fb2c915ffe3b705355fd4424dfb3b30a9d8c4 Mon Sep 17 00:00:00 2001 From: Francisco Date: Thu, 23 May 2024 20:59:31 -0300 Subject: [PATCH 08/21] Update EIPS/eip-draft_box_types_712.md Co-authored-by: xinbenlv --- EIPS/eip-draft_box_types_712.md | 1 + 1 file changed, 1 insertion(+) diff --git a/EIPS/eip-draft_box_types_712.md b/EIPS/eip-draft_box_types_712.md index e53e4a90041173..b7fb7f61c4f262 100644 --- a/EIPS/eip-draft_box_types_712.md +++ b/EIPS/eip-draft_box_types_712.md @@ -1,4 +1,5 @@ --- +eip: 7713 title: Box types for EIP-712 messages description: A mechanism for EIP-712 messages to contain parameters of arbitrary type author: Francisco Giordano <@frangio> From 54c1455929017d704b06764b05c605b67a1f72f7 Mon Sep 17 00:00:00 2001 From: Francisco Date: Thu, 23 May 2024 20:59:42 -0300 Subject: [PATCH 09/21] Update EIPS/eip-draft_box_types_712.md Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com> --- EIPS/eip-draft_box_types_712.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-draft_box_types_712.md b/EIPS/eip-draft_box_types_712.md index b7fb7f61c4f262..cdeb1861991a08 100644 --- a/EIPS/eip-draft_box_types_712.md +++ b/EIPS/eip-draft_box_types_712.md @@ -3,7 +3,7 @@ eip: 7713 title: Box types for EIP-712 messages description: A mechanism for EIP-712 messages to contain parameters of arbitrary type author: Francisco Giordano <@frangio> -discussions-to: https://ethereum-magicians.org/t/eip-box-types-for-eip-712-messages/20092 +discussions-to: https://ethereum-magicians.org/t/eip-7713-box-types-for-eip-712-messages/20092 status: Draft type: Standards Track category: Interface From 0faa98e6f3934c9ce1d7a752c0395b5efd2090ca Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Thu, 23 May 2024 21:00:50 -0300 Subject: [PATCH 10/21] rename --- EIPS/{eip-draft_box_types_712.md => eip-7713.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename EIPS/{eip-draft_box_types_712.md => eip-7713.md} (100%) diff --git a/EIPS/eip-draft_box_types_712.md b/EIPS/eip-7713.md similarity index 100% rename from EIPS/eip-draft_box_types_712.md rename to EIPS/eip-7713.md From 9330408b7ed096ccb7a7b57558cae55f68242c86 Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Thu, 23 May 2024 21:14:24 -0300 Subject: [PATCH 11/21] update title --- EIPS/eip-7713.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7713.md b/EIPS/eip-7713.md index cdeb1861991a08..fdccfa00f6e6b7 100644 --- a/EIPS/eip-7713.md +++ b/EIPS/eip-7713.md @@ -1,6 +1,6 @@ --- eip: 7713 -title: Box types for EIP-712 messages +title: Box type for EIP-712 messages description: A mechanism for EIP-712 messages to contain parameters of arbitrary type author: Francisco Giordano <@frangio> discussions-to: https://ethereum-magicians.org/t/eip-7713-box-types-for-eip-712-messages/20092 From d30a28e52f41fc6b15c143d0a5218e9c82a13266 Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Thu, 23 May 2024 21:22:01 -0300 Subject: [PATCH 12/21] reword abstract --- EIPS/eip-7713.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7713.md b/EIPS/eip-7713.md index fdccfa00f6e6b7..9e4ab979c81044 100644 --- a/EIPS/eip-7713.md +++ b/EIPS/eip-7713.md @@ -13,7 +13,7 @@ requires: 712 ## Abstract -A special type `box` is defined for [EIP-712](./eip-712.md) messages. A `box` value is a value of an arbitrary struct type whose underlying type is encapsulated from the containing struct, but transparent and type-checkable by the wallet, and thus able to be fully inspected by the user prior to signing. A verifying contract can be made agnostic to the underlying type of a `box` value, but this type is not erased and can be verified on-chain if necessary. +This EIP defines a new type `box` for use in [EIP-712](./eip-712.md) messages. A `box` value is a value of an arbitrary struct type whose underlying type is encapsulated from the containing struct, but transparent and type-checkable by the wallet, and thus able to be fully inspected by the user prior to signing. A verifying contract can be made agnostic to the underlying type of a `box` value, but this type is not erased and can be verified on-chain if necessary. ## Motivation From 5973a4e9e5d3c56051342561944e90f7422e61a1 Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Thu, 23 May 2024 21:28:28 -0300 Subject: [PATCH 13/21] wording --- EIPS/eip-7713.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7713.md b/EIPS/eip-7713.md index 9e4ab979c81044..7be44241d4ab85 100644 --- a/EIPS/eip-7713.md +++ b/EIPS/eip-7713.md @@ -13,7 +13,7 @@ requires: 712 ## Abstract -This EIP defines a new type `box` for use in [EIP-712](./eip-712.md) messages. A `box` value is a value of an arbitrary struct type whose underlying type is encapsulated from the containing struct, but transparent and type-checkable by the wallet, and thus able to be fully inspected by the user prior to signing. A verifying contract can be made agnostic to the underlying type of a `box` value, but this type is not erased and can be verified on-chain if necessary. +This EIP defines a new type `box` for use in [EIP-712](./eip-712.md) messages. A `box` value is a value of an arbitrary struct type whose underlying type is encapsulated from the outer struct but transparent and type-checkable by the wallet, and thus able to be fully inspected by the user prior to signing. A verifying contract can be made agnostic to the underlying type of a `box` value, but this type is not erased and can be verified on-chain if necessary. ## Motivation From e790c7b80d9b2f684f687eda00676830f16966f6 Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Thu, 23 May 2024 21:37:13 -0300 Subject: [PATCH 14/21] fix github username --- EIPS/eip-7713.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7713.md b/EIPS/eip-7713.md index 7be44241d4ab85..517afa9a1fa67e 100644 --- a/EIPS/eip-7713.md +++ b/EIPS/eip-7713.md @@ -2,7 +2,7 @@ eip: 7713 title: Box type for EIP-712 messages description: A mechanism for EIP-712 messages to contain parameters of arbitrary type -author: Francisco Giordano <@frangio> +author: Francisco Giordano (@frangio) discussions-to: https://ethereum-magicians.org/t/eip-7713-box-types-for-eip-712-messages/20092 status: Draft type: Standards Track From ba8c59219e6fec85ebf8e676a119df9a375e223d Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Thu, 23 May 2024 21:37:20 -0300 Subject: [PATCH 15/21] add whitespace around code block --- EIPS/eip-7713.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/EIPS/eip-7713.md b/EIPS/eip-7713.md index 517afa9a1fa67e..6b9dc72d88b2df 100644 --- a/EIPS/eip-7713.md +++ b/EIPS/eip-7713.md @@ -24,12 +24,14 @@ The general-purpose nature of EIP-712 is key to its success, but in addition wal Special-purpose interfaces improve usability and security for the user, but rely on standardized message types such as Permits. This EIP concerns the ability to standardize messages that contain within them parameters of arbitrary type. A recent example is found in [ERC-7683](https://ercs.ethereum.org/ERCS/erc-7683), which defines a struct with the following member: + ```solidity /// @dev Arbitrary implementation-specific data /// Can be used to define tokens, amounts, destination chains, fees, settlement parameters, /// or any other order-type specific information bytes orderData; ``` + Defining this parameter with type `bytes` enables the message to contain data of arbitrary type and is sufficient to bind the signature to implementation-specific data, but it amounts to type erasure. As a consequence, the user will be presented with an opaque bytestring in hexadecimal format in the wallet's signing interface. This negates the benefit of using EIP-712 signatures because the true contents of the parameter are invisible to the wallet's general-purpose interface. Another example is found in recent efforts to make [ERC-1271](./eip-1271.md) signatures secure against replay. Achieving this without making the message contents opaque to the signer requires embedding an application's EIP-712 message inside an outer message that binds it to a specific account. The type of the outer message depends on the type of the inner message, and making the type reproducible by the smart contract account on-chain for verification requires an inefficient scheme to communicate the string-encoded type of the inner message as a part of the signature. From 4f90d92ced2010614520092c39c44ac51b5e6fdc Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Thu, 23 May 2024 21:38:18 -0300 Subject: [PATCH 16/21] remove comments --- EIPS/eip-7713.md | 47 +---------------------------------------------- 1 file changed, 1 insertion(+), 46 deletions(-) diff --git a/EIPS/eip-7713.md b/EIPS/eip-7713.md index 6b9dc72d88b2df..3243c209207a9c 100644 --- a/EIPS/eip-7713.md +++ b/EIPS/eip-7713.md @@ -127,63 +127,18 @@ For example, a message for the `Envelope` type above may be represented as: ## Rationale - - TBD ## Backwards Compatibility - - TBD -## Test Cases - - - ## Reference Implementation - +TBD ## Security Considerations - - Needs discussion. ## Copyright From b2e9d27986a448d057e6d9d676f0551307fae5c5 Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Thu, 23 May 2024 21:40:30 -0300 Subject: [PATCH 17/21] review wording --- EIPS/eip-7713.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7713.md b/EIPS/eip-7713.md index 3243c209207a9c..49db41b4c714c4 100644 --- a/EIPS/eip-7713.md +++ b/EIPS/eip-7713.md @@ -13,7 +13,7 @@ requires: 712 ## Abstract -This EIP defines a new type `box` for use in [EIP-712](./eip-712.md) messages. A `box` value is a value of an arbitrary struct type whose underlying type is encapsulated from the outer struct but transparent and type-checkable by the wallet, and thus able to be fully inspected by the user prior to signing. A verifying contract can be made agnostic to the underlying type of a `box` value, but this type is not erased and can be verified on-chain if necessary. +This EIP defines a new type `box` for use in [EIP-712](./eip-712.md) messages. A `box` value is a value of an arbitrary struct type whose underlying type is encapsulated and hidden from the outer struct but transparent and type-checkable by the wallet, and thus able to be fully inspected by the user prior to signing. A verifying contract can be made agnostic to the underlying type of a `box` value, but this type is not erased and can be verified on-chain if necessary. ## Motivation From fca6056b07fa29770ee9b41abca689be75719c60 Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Mon, 27 May 2024 14:59:55 -0300 Subject: [PATCH 18/21] change 7683 link --- EIPS/eip-7713.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7713.md b/EIPS/eip-7713.md index 49db41b4c714c4..6a43ea18a17e19 100644 --- a/EIPS/eip-7713.md +++ b/EIPS/eip-7713.md @@ -23,7 +23,7 @@ The general-purpose nature of EIP-712 is key to its success, but in addition wal Special-purpose interfaces improve usability and security for the user, but rely on standardized message types such as Permits. This EIP concerns the ability to standardize messages that contain within them parameters of arbitrary type. -A recent example is found in [ERC-7683](https://ercs.ethereum.org/ERCS/erc-7683), which defines a struct with the following member: +A recent example is found in [ERC-7683](./eip-7683.md), which defines a struct with the following member: ```solidity /// @dev Arbitrary implementation-specific data From dd596a092f6e9a1b0aebfe9a1e213e3add5e1290 Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Sun, 16 Jun 2024 23:15:34 -0300 Subject: [PATCH 19/21] try erc link --- EIPS/eip-7713.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7713.md b/EIPS/eip-7713.md index 6a43ea18a17e19..0b76f148db5d52 100644 --- a/EIPS/eip-7713.md +++ b/EIPS/eip-7713.md @@ -23,7 +23,7 @@ The general-purpose nature of EIP-712 is key to its success, but in addition wal Special-purpose interfaces improve usability and security for the user, but rely on standardized message types such as Permits. This EIP concerns the ability to standardize messages that contain within them parameters of arbitrary type. -A recent example is found in [ERC-7683](./eip-7683.md), which defines a struct with the following member: +A recent example is found in [ERC-7683](./erc-7683.md), which defines a struct with the following member: ```solidity /// @dev Arbitrary implementation-specific data From ecfc20423f0476db96838877ffb3a38ea380b5be Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Sun, 16 Jun 2024 23:18:12 -0300 Subject: [PATCH 20/21] Revert "try erc link" This reverts commit dd596a092f6e9a1b0aebfe9a1e213e3add5e1290. --- EIPS/eip-7713.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7713.md b/EIPS/eip-7713.md index 0b76f148db5d52..6a43ea18a17e19 100644 --- a/EIPS/eip-7713.md +++ b/EIPS/eip-7713.md @@ -23,7 +23,7 @@ The general-purpose nature of EIP-712 is key to its success, but in addition wal Special-purpose interfaces improve usability and security for the user, but rely on standardized message types such as Permits. This EIP concerns the ability to standardize messages that contain within them parameters of arbitrary type. -A recent example is found in [ERC-7683](./erc-7683.md), which defines a struct with the following member: +A recent example is found in [ERC-7683](./eip-7683.md), which defines a struct with the following member: ```solidity /// @dev Arbitrary implementation-specific data From 27c129e9cebc3db1611297897da5fd17d295350b Mon Sep 17 00:00:00 2001 From: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> Date: Tue, 25 Jun 2024 10:57:09 -0400 Subject: [PATCH 21/21] Update eip-7713.md --- EIPS/eip-7713.md | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/EIPS/eip-7713.md b/EIPS/eip-7713.md index 6a43ea18a17e19..68a29c89181a50 100644 --- a/EIPS/eip-7713.md +++ b/EIPS/eip-7713.md @@ -127,19 +127,11 @@ For example, a message for the `Envelope` type above may be represented as: ## Rationale -TBD - -## Backwards Compatibility - -TBD - -## Reference Implementation - -TBD +TBD ## Security Considerations -Needs discussion. +Needs discussion. ## Copyright