Update ERC-7730: Addind a trust assumptions section

ERCS/erc-7730.md

@@ -1430,6 +1430,42 @@ The binding `context` mitigates misuse by specifying exactly which structured da
 
 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.
 
+### External Data Resolution
+
+ERC-7730 formatting relies on resolving various external data sources to provide human-readable information. This resolution introduces trust assumptions that wallets must understand when showing ERC-7730 information:
+
+**Trust Assumptions:**
+
+The transition from transaction data to human readable data requires trust in external data sources to resolve some parts of the presentation layer. Without the resolution, it's not readable and missed the whole point of the ERC, with the resolution it adds a risk factor:
+- **Token metadata** (tickers, decimals) A token address translated to a token ticker and proper decimals applied to the `tokenAmount`.
+- **NFT collection names** and token metadata for the `nftName` format
+- **Address Resolution** when formatting `addressName` using ENS or similar tools
+
+Malicious or compromised data sources could:
+- Display incorrect token names, leading users to believe they are approving transactions for legitimate tokens when they are not
+- Display malicious addresses as if it is a trusted address name
+- Present fake NFT collection names to obscure the true nature of transactions
+- Provide misleading enumeration values that misrepresent transaction parameters
+- Supply modified ABIs that change how transaction data is interpreted
+
+**Mitigations:**
+
+Wallets SHOULD:
+- Maintain curated lists of well-known addresses (tokens, contracts, collections) and warn users when encountering unknown entities
+- Display full addresses alongside resolved names in some form
+- Clearly indicate the source and trust level of resolved names and metadata
+
+Wallets MUST:
+- Display clear warnings when external data cannot be resolved or verified (e.g., "Unknown token")
+- Never fallback to presenting untrusted information as if it was trusted and verified
+
+**Example Attack Scenarios:**
+
+1. **Token Name Spoofing**: A malicious ERC-7730 file references a fake token contract at address `0x1234...` that returns "USDT" as its ticker and 6 decimals, making a transaction appear to transfer legitimate USDT when it actually transfers a worthless token.
+
+2. **Address Name Substitution**: A compromised ENS resolver returns a malicious address naming resolution causing a send to an address not anticipated
+
+
 ### Interpolated Intent Security
 
 The `interpolatedIntent` feature introduces additional attack surfaces that wallets MUST mitigate: