diff --git a/EIPS/eip-7023.md b/EIPS/eip-7023.md new file mode 100644 index 00000000000000..f716b141dd00e3 --- /dev/null +++ b/EIPS/eip-7023.md @@ -0,0 +1,86 @@ +--- +eip: 7023 +title: Automatic Transaction Representation +description: Guidelines for automatically generating a human-readable representation of a transaction and its corresponding EIP-712 signature. +author: Gavin John (@Pandapip1) +discussions-to: https://ethereum-magicians.org/t/automatic-transaction-representation/14256 +status: Draft +type: Standards Track +category: ERC +created: 2023-05-12 +requires: 20, 712, 721, 1046, 1155 +--- + +## Abstract + +This EIP proposes an extendable standard to allow wallets to provide a rich representation of a transaction or signature request to the user. This representation is generated automatically from the transaction data and/or signature request. + +## Motivation + +While signing transactions is made much more secure by [EIP-712](./eip-712.md), most wallets end up displaying the raw JSON/YAML representation of the transaction to the user. This is not very user friendly and can lead to users being tricked into signing transactions that they did not intend to sign, as the average user is unable to read it. + +## 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. + +Only Final EIPs may be referenced in this EIP or future versions of 'Automatic Transaction Representation' EIPs. Wallets SHOULD refer to 'Automatic Transaction Representation' EIPs by their full title, including the version. 'Automatic Transaction Representation' EIPs SHOULD include the full list of rules, as well as indicating the changes made in the Rationale section. + +The following rules MUST be followed by compliant wallets: + +### General Rules + +- If a transaction would revert, the wallet MUST indicate this to the user and add a warning that the transaction will fail. +- If a transaction would consume more than 90% of the set gas limit, the wallet MUST indicate this to the user and add a warning that the transaction may fail. + - Wallets MAY choose to use a different default percentage, and the percentage SHOULD be user-configurable. +- If a request comes from a non-URI source (e.g. a QR code), the wallet MUST indicate the source of the request to the user. +- If a request comes from a URI source, the wallet MUST indicate the source of the request to the user, including the URI scheme, host, and port. If the transaction originates from an unsafe (as determined by the wallet) embedded frame (e.g. an iframe or webview), the wallet MUST indicate this to the user and add a warning that the request may not be trustworthy. + +### Contract Verification + +- Any method used to determine if a contract has verified source code, has been audited, or is known to be malicious MUST NOT substantially comprimise the anonymity or security of any user. +- If the wallet can determine if a contract has verified source code: + - For each contract referenced in a transaction: + - If the contract does not have verified source code, the wallet MUST indicate that the transaction references unverified contracts and add a warning that the request may not be trustworthy. A warning badge or similar indication SHOULD be displayed next to any such contract. A link to verify the source code of the contract MUST be provided, as well as a button or other UI element to allow the user to dismiss the verified source code warning. + - The verified source code of any referenced contracts with verified source code MUST be made available to the user. + - Users MUST be able to permanently dismiss verified source code warnings by address, chain ID, or address/chain ID pair, and a link to verify the source code of any contract MUST be provided. +- If the wallet can determine if a contract has been audited: + - For each contract referenced in a transaction: + - If the contract has not been audited, the wallet MUST indicate that the transaction references unaudited contracts and add a warning that the request may not be secure. A warning badge or similar indication SHOULD be displayed next to any such contract. A link to submit or request an audit for any given list of unaudited referenced contracts MUST be provided, as well as a button or other UI element to allow the user to dismiss the unaudied contract warning. + - The audits of any referenced contracts MUST be made available to the user. + - Users MUST be able to permanently dismiss audit missing warnings by address, chain ID, or address/chain ID pair, and a link to submit or request an audit MUST be made available to the user. +- If the wallet can determine if a contract is known to be malicious: + - For each contract referenced in a transaction: + - If a contract is known to be malicious, the wallet MUST indicate that the transaction references a malicious contract, add a warning that the request references a known malicious contract, and refuse to submit the transaction. A warning badge SHOULD be displayed next to any such contract. A link to submit an appeal MUST be provided, as well as a button or other UI element to allow the user to dismiss the malicious contract warning, and if all warnings have been dismissed, submit the transaction. + - Users MUST be able to permanently dismiss malicious contract warnings by address/chain ID pair, and a link to submit an appeal MUST be made available to the user. + +### Asset Transfer Rules + +- If a transfer of tokens (including support for, at a minimum, [ERC-20](./eip-20.md), [ERC-223](./eip-223.md), [ERC-721](./eip-721.md), [ERC-1155](./eip-1155.md), and [ERC-1046](./eip-1046.md)-compatible tokens) or a chain's native currency is included in the transaction, the wallet SHOULD display the amount of tokens being transferred, the token's symbol (if available), the token's name (if available), an image of the token (if available), the token's contract address, the recipient's address, and the sender's address. + - If the transaction format is known, and the transaction request doesn't explicitly disallow it, the wallet SHOULD allow the user to edit the amount of asset being transferred. If/when the user does, the wallet MUST update the transaction request accordingly. + - If more than one transfer of the same asset is included in the transaction, the wallet MAY display the net transfer amount instead of each individual transfer. + - If more than one transfer of different assets is included in the transaction, the wallet SHOULD display the transfers as a trade. + - If the maximum slippage can be determined, the wallet SHOULD display the maximum slippage. + - If the determined slippage is greater than some user-defined thresholds (with sensible defaults e.g. 1%, 5%, 10%), the wallet SHOULD display progressively more severe warnings to the user. +- If an appproval is included in a transaction, it must follow the same rules as a transfer, except that the approvals MUST NOT be represented as a trade. + +### Staking + +- If the transaction stakes native currency for validator rewards, the wallet SHOULD display the amount of native currency being staked (determined by the transaction value), the public key, and withdrawal credentials (fetched from the `DepositEvent` event). + +## Rationale + +An automatically-generated representation of a transaction is much more user-friendly and easier to understand than the raw JSON/YAML representation. Additionally, the wallet and user don't need to trust the website or contract to generate a correct representation. + +The 90% gas limit was set arbitrarily. Most wallets will probably choose their own percentage anyway. + +## Backwards Compatibility + +No backward compatibility issues found. + +## Security Considerations + +No security considerations found. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md).