Update ERC-7730: Expand scope to machine consumption, enhance security considerations

Merged by EIP-Bot.

Author: arein

ERCS/erc-7730.md

@@ -2,7 +2,7 @@
 eip: 7730
 title: Structured Data Clear Signing Format
 description: JSON format describing how to clear-sign smart contract calls and typed messages.
-author: Laurent Castillo (@lcastillo-ledger)
+author: Laurent Castillo (@lcastillo-ledger), Derek Rein (@arein)
 discussions-to: https://ethereum-magicians.org/t/eip-7730-proposal-for-a-clear-signing-standard-format-for-wallets/20403
 status: Draft
 type: Standards Track
@@ -13,13 +13,13 @@ requires: 155, 712
 
 ## Abstract
 
-This specification defines a JSON format carrying additional information required to correctly display structured data to a human for review on a wallet screen, before signature by the wallet. 
+This specification defines a JSON format carrying additional information required to correctly display structured data for human verification on wallet screens or for machine consumption e.g. by transaction simulation engines.
 
-The [ERC-7730](./eip-7730.md) specification enriches type data contained in the ABIs and schemas of structured messages (structures like the calldata of an EVM transaction or an [EIP-712](./eip-712.md) message) with additional formatting information, so that wallets can construct a better UI when displaying the data before signature. For instance, a solidity field containing an amount, encoded as an uint256, can be converted to the right magnitude and appended with the correct ticker.
+The [ERC-7730](./eip-7730.md) specification enriches type data contained in the ABIs and schemas of structured messages (structures like the calldata of an EVM transaction or an [EIP-712](./eip-712.md) message) with additional formatting information, enabling both human-readable display and machine-interpretable data processing. For instance, a solidity field containing an amount, encoded as an uint256, can be converted to the right magnitude and appended with the correct ticker for display, or parsed programmatically for transaction simulation.
 
-Wallets will use (wallet-curated) ERC-7730 files alongside the raw data to sign in order to construct a display adapted to be reviewed by humans.
+Wallets and automated systems will use curated ERC-7730 files alongside the raw data to sign in order to construct appropriate interfaces for their respective use cases.
 
-At the time of writing (version 1 of this specification), the only structured data supported are smart contract calls (aka calldata) in EVM transactions and EIP-712 structured messages. 
+This enables significantly improved signing user experiences and lower end-user risk from frontend and phishing attacks. 
 
 ## Motivation
 
@@ -31,7 +31,7 @@ Properly validating a transaction on a hardware wallet's screen (also known as C
 
 This specification intends to provide a simple, open standard format to provide wallets with the additional information required to properly format a structured data to sign for review by users.
 
-Providing this additional formatting information requires deep knowledge of the way a smart contract or message is going to be used. It is expected that DApp developers will be the best placed to write such a file. The intent of an open standard is to only write this file once and have it work with most wallets supporting this standard.
+Providing this additional formatting information requires deep knowledge of the way a smart contract or message is going to be used. It is expected that app developers will be the best placed to write such a file. The intent of an open standard is to only write this file once and have it work with most wallets supporting this standard.
 
 
 ## Specification
@@ -1084,7 +1084,7 @@ Wallets MAY extend the specification with wallet specific layout instructions by
 It is expected that the main limitation to adoption of ERC-7730 will be the complexity of writing this interface description file compared to interest of writing it.
 
 This drove a few choices when introducing this ERC specification:
-* The form of an ERC itself will allow usage of these file by any wallets (Hardware or Software, without restrictions), and in turn drive up the benefits for dApps developers to provide their own ERC-7730 description
+* The form of an ERC itself will allow usage of these file by any wallets (Hardware or Software, without restrictions), and in turn drive up the benefits for app developers to provide their own ERC-7730 description
 * The specification is intended to be directly readable by developers, in order to facilitate direct edition by developers.
 * In addition, a set of edition tools will be created and open sourced to ease visualization of the results for end users
 
@@ -1103,46 +1103,29 @@ This consideration is driving a few choices done for ERC-7730:
 
 The full signature of a function call does not contain information about the types of complex parameters that might be used in the function call, only their names, while the ABI does carry this information. This is why the ABI is the reference and the function signature MUST match it. The full form of the function call is allowed in order to simplify writing and reading the ERC-7730 file. 
 
-### Deployment model
- 
-Making the ERC-7730 available for wallets is a key factor of adoption. We have a few options:
-- In each dApps GitHub repository or website: good for autonomy but can be problematic for discoverability by wallets of new ERC-7730 files
-- Foundation operated repository, like ethereum chainID list: good alternative between decentralization and discoverability.
-- Ledger repository: as a short term solution, Ledger is providing a central repository (See Ledger GitHub repository)
-
 ### Extensibility to other Structured Data formats
 
-In the future, this specification could be extended to structured data like Meta Transaction in [EIP-2771](./eip-2771.md) or User Operations in [EIP-4337](./eip-4337.md).
+In the future, this specification could be extended to structured data like Meta Transaction in [EIP-2771](./eip-2771.md), User Operations in [EIP-4337](./eip-4337.md), and batch transaction payloads in [EIP-5792](./eip-5792.md).
 
 ## Test Cases
 
 More examples can be found in the asset folder [here](../assets/eip-7730/example-main.json) and [here](../assets/eip-7730/example-include.json).
 
 ## Security Considerations
 
-The main security concern introduced by ERC-7730 is to avoid attacks that would use the ERC-7730 formatting mechanism to trick users into signing something wrong.
-
-Two main attack vectors that needs to be mitigated:
-* Avoid using a well-formed, trusted ERC-7730 file on data that should not be formatted using it
-* Avoid badly formed, incorrect ERC-7730 files that would hide critical parameters or create misinterpretations through bed formatting
+ERC-7730 creates a risk surface where malicious actors could abuse formatting to make unsafe transactions appear benign. In addition to misapplied or malformed files, implementers should anticipate phishing techniques such as (a) parameter injection using legitimate, high-profile contract formats, (b) registry poisoning with well-formed but misleading entries, and (c) front-end/CDN compromise that prompts signatures for unexpected contracts or parameters.
 
 ### Binding context
 
-The binding `context` is the way we mitigate the first attack, by specifying in the ERC-7730 file itself, **what kind** of structured data should be formatted by said file.
-
-dApps developers must make sure that constraints in the binding context are restrictive enough to apply only to relevant data.
-
-Wallets must ensure that all constraints are met before formatting any data for review by the end user. 
-
-It is also expected that the way the formatting is applied to the data is not vulnerable to MITM or tampering attack from an attacker in control of communication means. Constraints have been design simple, so that a strong cryptographic binding to the data can be created even on resource constrained Hardware Wallets.
+The binding `context` mitigates misuse by specifying exactly which structured data a given ERC-7730 file may format. app developers MUST set restrictive constraints; wallets MUST verify all constraints and ensure formatting is cryptographically bound to the reviewed data and not tamperable in transit (including on resource-constrained hardware wallets).
 
-### Curation model
+### Registry Poisoning
 
-The second attack is not directly mitigated by the specification (beyond providing recommendations). It is rather expected that wallets will use a two-step curation process, and NOT trust ERC-7730 files coming directly from the public repository. 
+Curation and registry of ERC-7730 files are out of scope for this specification, but any external registry or wallet ecosystem MUST assume it will be targeted. A secure registry should (a) require cryptographically verifiable provenance and attestations for each ERC-7730 file and its maintainer, (b) keep a public, tamper-evident history of submissions, approvals, and revocations, (c) implement a mechanism to credibly link contract ownership or authority to the submitted file, and (d) adopt a clear governance model with multi-party sign-off and automated monitoring to detect anomalies or mass poisoning attempts. These measures mitigate attacks on ERC-7730 files in transit and make registry compromise significantly harder without constraining this ERC itself.
 
-Rather wallets SHOULD do some additional verifications on the ERC-7730 file itself and corresponding dApps before trusting the file to build their user's UI.
+Future Work
 
-![Curation Model](../assets/eip-7730/curation-model.svg)
+Future improvements could bind frontends to verified contract manifests so that a compromised UI cannot silently substitute a different contract. Clear, auditable registry governance (multi-party signoff, monitoring, and revocation) can further raise the cost of phishing, parameter injection, and front-end compromise attacks.
 
 ## Copyright