{"id":"ERC-7730","name":"Clear Signing Metadata","status":"Draft","chain":"both","category":{"id":"comprehension","name":"Comprehension & Display","description":"Making blockchain data readable to humans"},"journeyStages":[{"id":"reading","name":"Reading & Understanding","description":"Interpreting what you're being asked to do"},{"id":"approving","name":"Approving & Permissioning","description":"Granting permissions for actions"}],"uxImpact":"ERC-7730 defines JSON descriptors and context rules that compatible clients can use to format calldata, EIP-712 messages, and UserOperations into readable summaries. Descriptor distribution, registry curation, client support, and source trust remain separate; a descriptor match does not prove that an action or publisher is safe.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-7730","lastReviewed":"2026-09-23","lastUpdated":"2026-09-23","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-7730","sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-7730","type":"official-spec"}],"lastReviewed":"2026-09-23","lastUpdated":"2026-09-23","summary":"ERC-7730 defines JSON descriptors and context rules that compatible clients can use to format calldata, EIP-712 messages, and UserOperations into readable summaries. Descriptor distribution, registry curation, client support, and source trust remain separate; a descriptor match does not prove that an action or publisher is safe.","partialDeployment":{"body":"ERC-7730 is Draft. Treat descriptor discovery, context matching, registry sources, and readable wallet rendering as conditional on the selected client and integration; retain raw-payload review when metadata is missing or unsupported."},"designerTakeaways":["Show a readable transaction summary before the wallet prompt when a supported descriptor matches the payload.","Warn when descriptor data is missing, unsupported, stale, or untrusted, and preserve a raw-payload fallback.","Use source and context indicators as review aids, not as proof that the action or publisher is safe."],"applicability":{"whenToUse":["Users sign complex contract interactions.","Blind signing is a support and security risk.","Your app or contract integration can distribute a descriptor and the selected client supports it."],"whenToAvoid":["Simple native token sends need no metadata layer.","Target contracts lack clear-signing registration.","You cannot provide a safe fallback when descriptors are missing, unsupported, stale, or untrusted."]},"specConstraints":[{"id":"context-match-before-formatting","constraint":"Wallets must verify descriptor context before applying its formatting to signed data.","appliesTo":"wallet","normativity":"normative","specQuote":"The `context` key is used to provide binding context information for this file. It can be seen as a set of *constraints* on the structured data being reviewed, indicating whether the ERC-7730 file is valid for this data. A wallet MUST ensure these constraints are met before ERC-7730 formatting information is applied to the data being signed.","specSection":"Specification — Simple example","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730","designImplication":"Treat a chain, contract, container, or payload mismatch as a pre-signing fallback state. Do not show descriptor-derived intent as if the descriptor matched."},{"id":"context-binding-integrity","constraint":"Wallets must verify context constraints and keep descriptor formatting cryptographically bound to the reviewed data.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"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).","specSection":"Security Considerations — Binding context","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730","designImplication":"Keep the descriptor-derived summary tied to the exact transaction or message being signed, including on hardware wallets. If the binding cannot be verified, show the raw payload or a clear unsupported state."},{"id":"restrictive-descriptor-context","constraint":"Applications that publish descriptors must set restrictive context constraints.","appliesTo":"application","normativity":"security-considerations","specQuote":"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).","specSection":"Security Considerations — Binding context","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730","designImplication":"When your app distributes a descriptor, bind it narrowly to the intended chain, contract, container, and payload shape. Do not rely on the wallet to repair an overbroad descriptor after distribution."},{"id":"descriptor-version-compatibility","constraint":"Wallets must reject unsupported major descriptor versions while continuing compatible processing for newer minor or patch versions.","appliesTo":"wallet","normativity":"normative","specQuote":"A wallet MUST consider a descriptor invalid if the MAJOR version identified by its `$schema` key is not one the wallet implements, since a MAJOR version bump signals a breaking change to the schema. If the MAJOR version matches but the descriptor declares a MINOR or PATCH version newer than what the wallet implements, the wallet MUST continue processing the descriptor using its implementation for the appropriate MAJOR version, since MINOR versions are backward-compatible additions and PATCH versions are non-breaking fixes or editorial changes, per Semantic Versioning.","specSection":"Specification — Versioning","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730","designImplication":"Design explicit unsupported-major and compatible-newer-minor states. Do not silently render a descriptor from an unknown major version, and do not turn a newer minor or patch version into an unnecessary dead end. If descriptor provenance is shown, distinguish an alias that follows the latest release of its major line from a pin to an exact version."},{"id":"eip712-domain-match","constraint":"Wallets must match the descriptor's EIP-712 domain constraints before formatting a typed message.","appliesTo":"wallet","normativity":"normative","specQuote":"A wallet MUST verify that each key-value pair in this `domain` binding matches the values of the `domain` key-value pairs of the message. Note that the message can have more keys in its `domain` than those listed in the ERC-7730 file. An EIP-712 domain is a free-form list of keys, but those are very common to include:","specSection":"Specification — Context section — EIP-712 messages binding context (denoted 'messages')","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730","designImplication":"Show the matched domain context separately from the human-readable summary and fall back when the required domain values, deployment, or domain separator do not match."},{"id":"safe-display-fallback","constraint":"When no format matches a calldata selector, wallets should show a safe raw-argument fallback and must not apply unrelated formatting.","appliesTo":"wallet","normativity":"normative","specQuote":"If no key matches the calldata selector, wallets SHOULD display a safe fallback (for example, \"Unknown function\" alongside raw arguments) and MUST NOT attempt to apply any unrelated format specifications.","specSection":"Specification — Display section — Unknown selectors","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730","designImplication":"Make an unknown-function or raw-argument state legible and reviewable. Never fill a missing selector match with a visually plausible summary from another function."},{"id":"clear-signing-display","constraint":"Wallets must present either an interpolated intent or a field-by-field review with matching formatting.","appliesTo":"wallet","normativity":"normative","specQuote":"Wallets MUST display either `interpolatedIntent` strings or screens generated from `intent` and individual `fields`.\n\nWallets MAY display both fields, with `interpolatedIntent` as the primary description.\n\nInterpolated paths MUST reference fields that have corresponding format specifications in the `fields` array. The formatting applied during interpolation MUST match the formatting that would be applied if the field were displayed separately.","specSection":"Specification — Display section — Structured data format specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730","designImplication":"Make the user-facing review complete in either presentation: the headline intent must agree with the separately inspectable fields, and required fields must not disappear behind a concise sentence."},{"id":"interpolation-visible-paths","constraint":"Interpolated intent must use paths whose fields are always visible in the review.","appliesTo":"wallet","normativity":"normative","specQuote":"Interpolated intents MUST only refer to paths that are noted as always visible (i.e. `visible` key in the field formatter is `always` or not present).","specSection":"Specification — Common concepts — Value interpolation","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730","designImplication":"Do not put a conditionally hidden value into the primary intent sentence. Keep the source field available in the review whenever the headline includes it."},{"id":"interpolation-path-validation","constraint":"Wallets must validate interpolated paths against the signed data and their field format specifications.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"Wallets MUST validate that all paths in interpolation expressions:\n1. Follow the [path reference rules](#path-references)\n2. Reference fields that exist in the structured data being signed\n3. Have corresponding field format specifications in the `fields` array\n4. Do not create circular references or unbounded recursion","specSection":"Security Considerations — Interpolated intent security — Path validation","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730","designImplication":"Treat an invalid, missing, circular, or unbounded path as a review failure. Keep the fallback deterministic instead of partially rendering a misleading headline."},{"id":"interpolation-failure-fallback","constraint":"When interpolation fails, wallets must fall back to static intent and separately formatted fields without partial processing.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"If interpolation fails for any reason (invalid path, formatting error, missing field specification, validation failure), wallets MUST:\n1. Fall back to displaying the static `intent` field\n2. Display all fields separately according to their field format specifications\n3. NOT attempt to partially process the interpolated intent\n4. Optionally warn the user that the dynamic description could not be generated","specSection":"Security Considerations — Interpolated intent security — Fallback behavior","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730","designImplication":"Keep a complete field-by-field review available when a dynamic sentence cannot be trusted. Do not show a truncated or half-interpolated description as if it were a valid summary."},{"id":"verified-address-labels","constraint":"Wallets must verify ENS names and other address labels before using them in interpolated intent.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"Wallets MUST validate that ENS names and other address labels are verified before interpolation","specSection":"Security Considerations — Interpolated intent security — Injection attacks","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730","designImplication":"Keep the resolved label's verification state visible and retain the address needed to review the destination. An attractive name is not enough to make an interpolated recipient trustworthy."},{"id":"address-source-restriction","constraint":"When a descriptor specifies address-name sources, wallets must use only those sources and verify the address type when able.","appliesTo":"wallet","normativity":"normative","specQuote":"When specified a wallet MUST only use specified sources to resolve address names. Wallet MUST verify the type of the address if able to.","specSection":"Specification — Field formats — Address types and sources","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730","designImplication":"Make source restrictions and address-type checks part of the trust disclosure. Do not silently substitute a different resolver or label an address as a wallet, token, or contract without the available verification."},{"id":"external-data-trust","constraint":"Wallets must warn when external display data cannot be verified and must not present untrusted data as verified.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"Wallets MUST:\n- Display clear warnings when external data cannot be resolved or verified (e.g., \"Unknown token\")\n- Never fallback to presenting untrusted information as if it was trusted and verified","specSection":"Security Considerations — External data resolution — Mitigations","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730","designImplication":"Separate readable labels from their source and trust state. Keep the raw address or value reviewable, and make unresolved or unverified metadata an explicit warning rather than a polished default."},{"id":"registry-poisoning-awareness","constraint":"External registries and wallet ecosystems must treat ERC-7730 files as a registry-poisoning target.","appliesTo":"infrastructure","normativity":"security-considerations","specQuote":"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.","specSection":"Security Considerations — Registry poisoning","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730","designImplication":"Do not turn registry inclusion into a safety badge. Show descriptor provenance and trust separately from context matching, and preserve a way to inspect the underlying payload."},{"id":"metadata-recipient-details","constraint":"Wallets may use recipient metadata to provide additional details about the recipient.","appliesTo":"wallet","normativity":"normative","specQuote":"In this example, the metadata section contains only the recipient information, in the form of a displayable name (`owner` key), contract displayable name (`contractName` key) and additional information (`info` key) that MAY be used by wallets to provide details about the recipient.","specSection":"Specification — Simple example","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#simple-example","designImplication":"Treat recipient metadata as an optional detail layer. Show its source and keep the underlying address available for review."},{"id":"simple-parameter-display","constraint":"Wallets should display the to address and value amount in the simple transfer example.","appliesTo":"wallet","normativity":"normative","specQuote":"In this example, the `to` parameter and the `value` parameter SHOULD both be displayed, one as an address replaceable by a trusted name (ENS or others), the other as an amount formatted using metadata of the target ERC-20 contract.","specSection":"Specification — Simple example","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#simple-example","designImplication":"Keep the recipient and amount visible in the signing review. A trusted name may replace the displayed address, but provide easy access to the underlying address for review."},{"id":"deprecated-version-support","constraint":"Wallets and tooling should support every non-deprecated descriptor version listed as released.","appliesTo":"wallet","normativity":"normative","specQuote":"This standard may deprecate a version of the schema explicitly. Wallets and tooling SHOULD maintain support for all non-deprecated versions of the schema declared in the [Released versions](#released-versions) section.","specSection":"Specification — Versioning — Released versions","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#released-versions","designImplication":"Do not make a supported non-deprecated descriptor unusable merely because a newer version exists. Show an explicit unsupported state only for versions the client cannot process."},{"id":"metadata-target-details","constraint":"Wallets may use metadata.owner to display the target of the reviewed interaction.","appliesTo":"wallet","normativity":"normative","specQuote":"Wallet MAY use this value to display the target of the interaction being reviewed.","specSection":"Specification — Metadata section — metadata.owner","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#metadata-section","designImplication":"Show the owner label as optional target context and keep the resolved address inspectable."},{"id":"metadata-contract-name","constraint":"Wallets may use metadata.contractName to display the target contract or verifying contract.","appliesTo":"wallet","normativity":"normative","specQuote":"Wallet MAY use this value to display the target of the interaction being reviewed.","specSection":"Specification — Metadata section — metadata.contractName","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#metadata-section","designImplication":"Show the contract label as optional target context and keep the resolved contract address inspectable."},{"id":"metadata-contract-details","constraint":"Wallets may use metadata.info to display additional details about the targeted contract.","appliesTo":"wallet","normativity":"normative","specQuote":"A wallet MAY use this information to display additional details about the targeted contract.","specSection":"Specification — Metadata section — metadata.info","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#metadata-section","designImplication":"Keep contract metadata as optional context with a visible source and an address fallback."},{"id":"optional-field-display","constraint":"Wallets may display a field marked optional when doing so is possible or sensible.","appliesTo":"wallet","normativity":"normative","specQuote":"`optional`: Wallets MAY display this field if possible or sensible.","specSection":"Specification — Display section — Field format specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#field-format-specification","designImplication":"Treat optional fields as an explicit display choice. Do not imply that omission means the field was hidden for security or that every wallet will show it."},{"id":"field-order-display","constraint":"Wallets should display grouped fields in the order defined by the group.","appliesTo":"wallet","normativity":"normative","specQuote":"Wallets SHOULD display fields in the order in which they appear in the group defintion.","specSection":"Specification — Display section — Group format specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#group-format-specification","designImplication":"Preserve authored field order in the signing review so related values follow the descriptor's intended reading sequence."},{"id":"embedded-calldata-fallback","constraint":"Wallets may show a hash of embedded calldata when no descriptor matches or embedded calldata is unsupported.","appliesTo":"wallet","normativity":"normative","specQuote":"If no matching ERC-7730 descriptor is found or if the wallet does not support embedded calldata, it MAY display a hash of the embedded calldata instead, with target `calleePath` resolved to a trusted name if possible.","specSection":"Specification — Display section — Embedded Calldata","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#embedded-calldata","designImplication":"Provide an explicit embedded-call fallback with the target and hash visible. Do not render an unsupported nested call as a complete readable summary."},{"id":"eip712-container-context","constraint":"Wallets should reject ERC-7730 EIP-712 clear signing when the verifying contract or chain is unknown.","appliesTo":"wallet","normativity":"normative","specQuote":"| @.to | The verifying contract address, when known. If not known a wallet SHOULD reject using the ERC-7730 file to clear sign the message | | @.chainId | The chainId of the verifying contract, when known. If not known a wallet SHOULD reject using the ERC-7730 file to clear sign the message. |","specSection":"Specification — Reference — Container structure values — EIP-712 container","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#eip-712-container","designImplication":"Keep verifying contract and chain context visible before signing. Fall back when the descriptor cannot bind the typed message to a known target."},{"id":"token-amount-fallback","constraint":"Wallets should show the raw token amount with an Unknown token warning when token metadata is unavailable.","appliesTo":"wallet","normativity":"normative","specQuote":"If ticker is not found or `tokenPath`/`token` is not set, the wallet SHOULD display the raw value instead with an \"Unknown token\" warning","specSection":"Specification — Reference — Field formats — Integer formats — tokenAmount","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#integer-formats","designImplication":"Keep the raw value visible and label the missing token metadata. Never replace an unresolved amount with a guessed ticker."},{"id":"token-chain-metadata","constraint":"Wallets should resolve token ticker and decimal metadata on the specified chain when present.","appliesTo":"wallet","normativity":"normative","specQuote":"When present, the wallet SHOULD resolve token metadata (ticker, decimals) for this chain.","specSection":"Specification — Reference — Field formats — Integer formats — tokenAmount","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#integer-formats","designImplication":"Bind token formatting to the declared chain and show an unresolved state when chain-specific metadata is unavailable."},{"id":"date-format-recommendation","constraint":"Date display is recommended to use RFC 3339.","appliesTo":"wallet","normativity":"normative","specQuote":"Date display RECOMMENDED use of RFC 3339","specSection":"Specification — Reference — Field formats — Integer formats — date","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#integer-formats","designImplication":"Use an RFC 3339 date representation when formatting descriptor dates, while preserving the source value for inspection."},{"id":"interoperable-address-display","constraint":"Wallets should parse an interoperable address and display its target address, chain, and checksum form.","appliesTo":"wallet","normativity":"normative","specQuote":"The wallet SHOULD parse the binary format, extract the target address and chain, and display it in the standard `<address> @ <chain> # <checksum>` format.","specSection":"Specification — Reference — Field formats — Interoperable addresses","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#interoperable-addresses","designImplication":"Make the decoded address and target chain visible together, with checksum status and a raw-value fallback when parsing fails."},{"id":"address-source-default","constraint":"When no address-name source is specified, a wallet may use any source to resolve an address.","appliesTo":"wallet","normativity":"normative","specQuote":"When omitted, a wallet MAY use any source to resolve an address.","specSection":"Specification — Reference — Field formats — Address types and sources","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#address-types-and-sources","designImplication":"Show which source supplied a resolved label when the descriptor leaves sources open, and keep the raw address available."},{"id":"wallet-address-control-check","constraint":"A wallet may verify that a wallet address is controlled by that wallet and reject signing when it is not.","appliesTo":"wallet","normativity":"normative","specQuote":"A wallet MAY verify that a `wallet` address is in fact controlled by the wallet, and reject signing if not the case.","specSection":"Specification — Reference — Field formats — Address types and sources","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#address-types-and-sources","designImplication":"Give wallet-identity checks a distinct failure state before signing instead of presenting a label as proof of control."},{"id":"address-source-label-options","constraint":"Wallets may replace an address with a trusted local name or an associated ENS domain.","appliesTo":"wallet","normativity":"normative","specQuote":"| local | Address MAY be replaced with a local name trusted by user. Wallets MAY consider that `local` setting for `sources` is always valid | | ens | Address MAY be replaced with an associated ENS domain |","specSection":"Specification — Reference — Field formats — Address types and sources","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#address-types-and-sources","designImplication":"Treat local and ENS labels as optional source choices, keep their trust states distinct, and retain the underlying address in the review."},{"id":"batch-intent-summary","constraint":"Wallets should present a batch as one readable summary or as clearly separated intent screens.","appliesTo":"wallet","normativity":"rationale","specQuote":"When displaying batch transactions as defined in [EIP-5792](./eip-5792.md), wallets SHOULD either:\n* Concatenate the `interpolatedIntent` strings of individual operations using \" and \" as a separator to create a single, human-readable description of the entire batch.\n* Concatenate screens generated using `intent` and required `fields`, clearly separating individual transactions","specSection":"Rationale — Batch transactions (EIP-5792)","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#batch-transactions-eip-5792","designImplication":"Give the user one coherent batch summary while keeping each operation distinguishable and inspectable."},{"id":"batch-detail-fallback","constraint":"Wallets implementing batch display should process each operation, combine its intent, and provide individual details with an intent fallback.","appliesTo":"wallet","normativity":"rationale","specQuote":"Wallets implementing batch transaction display SHOULD:\n1. Process each transaction in the batch to generate its `interpolatedIntent`\n2. Join the resulting intent strings with \" and \" (note the spaces)\n3. Display the combined string as a single transaction summary\n4. Provide a way for users to view individual transaction details if needed\n5. Fall back to displaying individual `intent` fields if any `interpolatedIntent` processing fails","specSection":"Rationale — Batch transactions (EIP-5792)","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#batch-transactions-eip-5792","designImplication":"Keep the combined summary readable but preserve per-operation inspection and a deterministic fallback when one interpolation fails."},{"id":"batch-display-options","constraint":"Wallets may format, truncate with expansion, or group related operations in a batch summary.","appliesTo":"wallet","normativity":"rationale","specQuote":"Wallets MAY:\n- Apply additional formatting (e.g., capitalizing the first letter, adding a period at the end)\n- Truncate very long combined intents and provide expansion UI\n- Group related operations visually while still showing the combined intent","specSection":"Rationale — Batch transactions (EIP-5792)","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#batch-transactions-eip-5792","designImplication":"Use truncation or grouping only as presentation choices, and keep an expansion path to the complete combined intent."},{"id":"external-data-disclosure","constraint":"Wallets should warn about unknown entities, show full addresses alongside names, and identify the source and trust level of resolved metadata.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"Wallets SHOULD:\n- Maintain curated lists of well-known addresses (tokens, contracts, collections) and warn users when encountering unknown entities\n- Display full addresses alongside resolved names in some form\n- Clearly indicate the source and trust level of resolved names and metadata","specSection":"Security Considerations — External data resolution","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#external-data-resolution","designImplication":"Keep names, raw addresses, source, and trust state together in the review. Unknown or unverified metadata must be visibly different from a trusted label."},{"id":"proxy-descriptor-binding","constraint":"For an upgradeable proxy, the descriptor should bind to the stable proxy address users interact with.","appliesTo":"application","normativity":"security-considerations","specQuote":"For these contracts, the ERC-7730 file SHOULD be bound to the *proxy* address, since this is the stable address users interact with.","specSection":"Security Considerations — Proxy support — Upgradeable proxy contracts","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#proxy-support","designImplication":"Bind descriptor context and review labels to the proxy address shown to users, and treat an implementation-only match as an explicit trust or compatibility warning."},{"id":"interpolated-field-detail-access","constraint":"Wallets should show field values separately or provide easy access to a detailed field view alongside interpolated intent.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"Wallets SHOULD display field values separately in addition to the interpolated intent, or provide easy access to detailed field view","specSection":"Security Considerations — Interpolated intent security","specUrl":"https://ercs.ethereum.org/ERCS/erc-7730#interpolated-intent-security","designImplication":"Keep the values behind the summary one tap away at most, so users can inspect the exact fields before signing."}],"prototypeFirst":[{"screen":"Supported descriptor summary","why":"Show a readable summary only when the client supports the descriptor and its context matches the payload.","covers":["Descriptor match","Clear outcome copy"],"include":["Summary fields","Source/trust disclosure","Raw payload fallback"]},{"screen":"Missing or unsupported descriptor","why":"A clear-signing summary is optional and must not become a silent blind-sign path.","covers":["Unsupported client","Context mismatch"],"include":["Plain-language reason","Fallback action"]},{"screen":"Descriptor or execution failure","why":"A descriptor can be unavailable or misleading even when the underlying transaction is valid.","covers":["Descriptor fetch failure","Transaction revert"],"include":["Retry path","Support context"]},{"screen":"Payload and source disclosure","why":"Users need access to the actual payload and descriptor context when the summary is incomplete.","covers":["Contract and chain context","Descriptor source","Raw calldata or typed data"],"include":["Expandable section","Copy buttons","Explorer link"]}],"mentalModel":[{"label":"Contract intent","description":"The smart contract defines what the transaction will do. Without a matching descriptor, a client may show a safe raw-argument or unknown-function fallback; ERC-7730 does not mandate calldata hex."},{"label":"Descriptor source","description":"A compatible client obtains a JSON descriptor from a source it has chosen and vetted. The standard defines the descriptor format, not a mandatory registry or its curation."},{"label":"Wallet fetch","description":"Before the sign prompt, the client may load a descriptor for the target contract and function. Missing metadata is a supported fallback state, not proof that the transaction is unsafe or invalid."},{"label":"Plain-language preview","description":"Your app and wallet may show a summary such as Send 100 USDC to a named address, but display depends on descriptor and client support."},{"label":"Verification","description":"Check that the descriptor context matches the actual chain, contract and payload. A match does not authenticate the publisher or prove safety. Apply a separate source-trust policy and show a warning or fallback when a supported, trusted descriptor is unavailable."}],"statesToDesign":[{"state":"Descriptor matched","trigger":"The client has a supported descriptor whose context matches the actual chain, contract, and payload.","userNeed":"Understand the action before signing.","designResponse":"Show the readable summary, descriptor source, context, and raw payload fallback."},{"state":"Descriptor unavailable","trigger":"The client cannot obtain or match a supported descriptor.","userNeed":"Decide whether to cancel or review the raw payload.","designResponse":"Warn clearly, preserve raw calldata or typed data, and do not imply that missing metadata proves the action is unsafe."},{"state":"Descriptor source untrusted","trigger":"The context matches but the source or registry does not satisfy the client's trust policy.","userNeed":"Know whether to continue with limited confidence.","designResponse":"Show the source warning, keep the raw payload available, and let the user cancel or continue under the product's policy."},{"state":"Submitted","trigger":"The user signs and the selected client submits the action.","userNeed":"Separate signing, inclusion, and execution from descriptor display.","designResponse":"Show the transaction status and retain the descriptor and raw-payload context."},{"state":"Execution failed","trigger":"The signed action reverts or the client rejects the payload.","userNeed":"Know whether the descriptor or action caused the failure.","designResponse":"Separate descriptor, signing, submission, and execution errors and offer a bounded retry or cancel path."}],"designDecisions":[{"question":"What does a descriptor change in review?","recommendation":"Lead with the action outcome and keep descriptor source, context, and raw payload behind review.","rationale":"ERC-7730 formats an action but does not authenticate its publisher or prove its safety."},{"question":"What happens when clear signing is unavailable?","recommendation":"Warn and preserve raw-payload review, cancel, or another supported path.","rationale":"Descriptor support is optional and a missing summary is a distinct state from an invalid transaction."},{"question":"How do you label descriptor trust?","recommendation":"Show context match and source trust separately from the readable summary.","rationale":"A matching descriptor can still come from an untrusted or misleading source."}],"problemsSolved":[{"problem":"Complex payloads are difficult to summarize consistently","oldWay":"Each client invents its own field labels and formatting","newWay":"A compatible client can apply a descriptor's formatting and context rules","impact":"high"},{"problem":"Users may face a blind-sign fallback","oldWay":"The client has no supported descriptor or cannot match its context","newWay":"The UI explains missing or unsupported metadata and preserves the actual payload for review","impact":"high"},{"problem":"Descriptor mismatch and execution errors are easy to conflate","oldWay":"A generic signing or transaction error hides whether the summary or action failed","newWay":"Mapped descriptor, signing, submission, and execution states explain what to do next","impact":"medium"}],"uxPatterns":[{"name":"Human Transaction Summary","description":"Plain-language preview of every parameter.","components":["SummaryCard","ParameterList","DomainBadge"],"userFlow":["User initiates action","Client obtains a descriptor from a supported source","Context matches and summary renders","User reviews summary, source, and raw payload fallback"]},{"name":"Missing Metadata Gate","description":"Block or warn when clear signing unavailable.","components":["WarningBanner","AdvancedToggle"],"userFlow":["Metadata missing","UI warns user","Offers cancel or advanced view","Never silent blind sign"]}],"antiPatterns":[{"pattern":"Treating a descriptor as proof of safety","why":"ERC-7730 formats a payload but does not authenticate its publisher or prove its outcome","instead":"Show descriptor source, context match, raw payload, and an independent trust policy","severity":"critical"},{"pattern":"Hiding the raw payload when a descriptor is missing","why":"Users and reviewers cannot inspect what the client is actually asking them to sign","instead":"Use outcome language with an explicit unsupported or raw-payload fallback","severity":"high"},{"pattern":"No fallback when the client lacks descriptor support","why":"A missing optional summary becomes a dead-end or a silent blind-sign path","instead":"Explain the limitation and offer a safe raw-payload review, cancel, or other supported path","severity":"high"}],"vocabulary":[{"use":"Readable transaction summary","avoid":"Verified transaction","why":"A descriptor can improve formatting without proving that the transaction or publisher is safe."},{"use":"Summary unavailable","avoid":"Metadata failed","why":"Name the user-visible fallback without implying that the underlying transaction has already failed."},{"use":"Review and confirm","avoid":"Trust this metadata","why":"Users should approve the actual action after reviewing its summary and source context."}],"technicalNotes":"ERC-7730 defines JSON descriptors for formatting calldata, EIP-712 messages and UserOperations. Descriptor distribution and registry curation are outside its scope. Clients must check context and apply independent source-trust and integrity policies; misleading descriptors can produce misleading summaries. Clear signing depends on wallet and descriptor support and does not itself verify a domain on-chain or prove an action safe.","relatedStandards":[{"id":"EIP-712","relationship":"Typed data foundation for clear signing"},{"id":"ERC-6093","relationship":"Standardized error messages complement previews"}]},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-7730","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-7730","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-7730","markdown":"https://www.eipsfordesigners.com/standards/ERC-7730/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-7730/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-7730","official":"https://ercs.ethereum.org/ERCS/erc-7730","discussion":"https://ethereum-magicians.org/search?q=ERC-7730"},"freshness":{"lastReviewed":"2026-09-23","lastUpdated":"2026-09-23"}}