ERC-8176: Integrity Verification for ERC-7730

llbartekll · March 6, 2026, 8:01am

Hey everyone, I’d love feedback on a new draft ERC-8176.

Summary

ERC-8176 defines an optional `integrity` field for ERC-7730 clear signing descriptor files. It allows trusted parties — wallet vendors, auditors, registry operators — to independently attest to a descriptor’s correctness using EIP-191 (EOA) or ERC-1271 (contract) signatures, keyed by CAIP-10 account identifiers.

Problem

ERC-7730 descriptors tell wallets how to display human-readable transaction details. These files may be sourced from registries, bundled by wallet vendors, or fetched from third-party APIs. Regardless of distribution method, there is currently no mechanism to verify **who reviewed and approved** a given descriptor. A wallet receiving a descriptor has no way to distinguish a carefully audited file from one that was tampered with or never properly reviewed. A subtly misleading descriptor — e.g., one that hides a token approval amount — could trick end users while appearing technically valid.

Existing protections fall short:

- ERC-7730 context binding validates contract targeting but not display correctness

- HTTPS protects transport, not content authenticity

- Git signatures don’t survive once files are served via API or downloaded standalone

Approach

The `integrity` field is a JSON map where each key is a CAIP-10 account ID and each value contains a `signerType` (`“EOA”` or `“contract”`) and a `signature`. The signed message covers a Keccak-256 hash of the RFC 8785 (JCS) canonicalized descriptor content, excluding the `integrity` field itself.

Multi-Signer Model

Multiple parties can sign the same descriptor independently without affecting each other’s signatures. Adding a new signer doesn’t invalidate existing ones since the `integrity` field is excluded from hash computation. Each signature is verified independently — one failure doesn’t affect others.

Trust policy (which signers to accept, how many to require) is deliberately left to individual wallets.

Looking forward to your thoughts and feedback.

PatrickAlphaC · March 6, 2026, 1:07pm

I like the intent, but what if we just had the EIP-7730 file on chain? I guess they might be too big…

PatrickAlphaC · May 11, 2026, 6:01pm

Ok, I’ve decided I don’t like 8176 unless this lands:

github.com/ethereum/ERCs

Update ERC-7730: added intent mutability specification

master ← PatrickAlphaC:add-intent-mutability

opened 03:40PM - 11 May 26 UTC

PatrickAlphaC

+312 -8

# Add `intentMutability` field for upgrade and state-mutability detection ## …Summary Adds a new optional top-level `intentMutability` field to ERC-7730 descriptors. The field declares the storage slots whose values bound the descriptor's correctness, with values witnessed at authoring time. Wallets verify `(slot, expectedValue)` against live state before signing; on mismatch they downgrade to opaque signing or warn the user. Discussion thread: https://ethereum-magicians.org/t/eip-7730-proposal-for-a-clear-signing-standard-format-for-wallets/20403 ## Motivation A descriptor's `intent` and `fields` describe a function as it exists at authoring time. The executed behavior can diverge from the displayed intent in ways the descriptor's formatting alone cannot detect: - **Implementation upgrade** — a proxy's implementation slot is replaced; selector and parameters unchanged, executed bytecode entirely different. - **State-dependent branch** — a function reads a mutable storage variable and chooses between code paths. Flipping the variable changes which path runs without any bytecode change. - **Admin-controlled parameter** — a fee, pause, allowlist, or routing address is changed by the owner or governance, altering what the function does for a given input. - **External dependency** — the function calls a contract whose address is stored in mutable state, or relies on an oracle whose value or endpoint can be rotated. None of these is detectable from the descriptor today. Wallets that clear-sign against a stale descriptor display an intent that the contract no longer honors. `intentMutability` makes these vectors explicit and verifiable. ## Design summary `intentMutability` lives at the top level of the descriptor with two sub-keys: - `contract` — mutability declaration that applies to every entry in `display.formats` unless overridden - `functions` — per-function overrides, keyed by the same signature strings used in `display.formats` Each mutability entry has: - `stable` (bool) — when `true`, asserts that nothing can change the displayed intent - `stateRefs` (array of `StateRef`) — storage slots whose values bound the descriptor's correctness - `notes` (string) — free-form description of vectors that can't be reduced to a single storage slot (off-chain oracles, deployment-time library linkage, etc.) Each `StateRef` has `slot`, `expectedValue`, `description`, and optional `chainId`/`address` for cross-contract refs. `expectedValue` is required whenever `slot` is present, making the descriptor self-verifying. Wallets implementing this version of the spec read each declared slot's live value and compare it to `expectedValue` before applying the descriptor's formatting. On mismatch, they refuse to apply the formatting and downgrade to opaque signing or warn the user. When `intentMutability` is absent entirely, wallets warn or downgrade — absence is treated as "unknown," not as "stable." Full design rationale (descriptor-side vs auditor-report-side placement, why `expectedValue` is required, why absence defaults to warn, why `notes` exists as an escape hatch) is documented inline in the EIP's Rationale section. ## What changed **`ERCS/erc-7730.md`** - New `IntentMutability` section under Specification with six examples (immutable, EIP-1967 proxy, state-dependent branch, mixed contract/function, pre-computed mapping slot, off-chain notes-only) - New `Intent mutability declaration` subsection under Rationale - New `Intent mutability` subsection under Security Considerations - `Proxy support` extended with EIP-1967 slot guidance - Simple example updated to WETH9 (mainnet) + OP Stack predeploy WETH with `stable: true` declared **`assets/erc-7730/erc7730-v2.schema.json`** - New optional `intentMutability` top-level property - New `$intentMutability` block with `main`, `entry`, `stateRef` sub-schemas - Conditional schema enforces the validation rules (`stable: true` ⇒ no `stateRefs`/`notes`; otherwise ⇒ at least one of `stateRefs`/`notes` required) The change is additive. Existing descriptors without `intentMutability` still validate against the schema; they will trigger the wallet "mutability not specified" warning once wallets adopt the new spec. ## Out of scope - The on-chain attestation schema (ERC-8176) ## Reviewer ask Particularly interested in feedback on: - Whether `expectedValue` should be required vs. optional. We went required for self-verification; the cost is re-publication on every legitimate state change. - Whether absence should default to "warn" vs. "trust." We went warn; the alternative silently grants existing descriptors a trust label they weren't authored to bear. - The `notes` escape hatch — is it clear enough when to use it vs. when to insist on a slot?

The rationale:
As it currently stands, when an auditor/wallet vendor/etc publishes an attestation of a JSON spec, the attestation is point-in-time. However, contracts can change/upgrade and the intent of a function can change. An auditor who wants to make sure their attestations are good would have to set up a monitoring infrastructure to revoke attestations in the case of an intent change, which I don’t think is fair.

If we include the intent mutability in the 7730 spec, we are able to then publish an attestation as described in 8176, knowing that if the intent changes, our attestation covers that case.

What do you think?

Otherwise, if my PR does not land, we should update this ERC to include a way for someone to revoke an attestation, or they can additionally hash some intentMutability data as part of this ERC. What do you think ?

kuzdogan · May 12, 2026, 10:47am

Agreed. But I think it’s already easy to revoke attestations in EAS

llbartekll · May 12, 2026, 11:06am

An auditor who wants to make sure their attestations are good would have to set up a monitoring infrastructure to revoke attestations in the case of an intent change,

Ok, so with intentMutability, it’s not auditor’s responsibility but wallet needs to set up it’s infractructure to check the mutable slot instead, correct?

PatrickAlphaC · May 12, 2026, 3:40pm

The “descriptor auditor” should check the intentMutability of the spec is correct. Then, it’s the wallet’s job to check the slot. I think for airgapped wallets, this is where the wire protocol becomes more important. It should be easy enough for a wallet to get verified data that a slot is changed from like a light client or something? I’m a little hazy on the wire protocol stuff. But for non-airgapped wallets this should be pretty easy to implement.