ERC-8176: Integrity Verification for ERC-7730

ERCs
1

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.

2

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

3

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

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 ?

1 Like
4

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

1 Like
5

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?

1 Like
6

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.

7

I’m going through the proposed registry + attestation flow, and I’m thinking about trustless-ness from the wallet/implementation side.

From what I understand, if a new builder deploys a contract without a formal audit and wants clear signing, they can publish and self-attest a descriptor. But the wallet then needs to decide whether to trust that self-attestation, or otherwise define a policy for how self-attestations are treated.

From Walletbeat’s experience, wallets don’t usually act on implementations unless there’s a strong need to..

I discussed this with @polymutex, a fellow Walletbeat contributor, and it might make sense to have a standardized onchain read function that points to, or commits to, the descriptor itself. This could give wallets a more permissionless way to establish descriptor provenance, which they could present with a lower trust level if it hasn’t been attested by a trusted attestor

Attestations could then remain an additional trust layer for independent verification

1 Like
8

Looking at this from the wallet implementation side, I think the proposal may benefit from defining a small, standardized trust-status model that wallets can present consistently.

For example, a descriptor could be:

  • self-published but unattested;

  • attested by one or more recognized parties;

  • attested but later revoked;

  • disputed because trusted attestors signed conflicting descriptor contents.

The signature mechanism establishes provenance, but wallets still need to translate that into a safe user-facing decision. In particular, it would help to clarify:

  1. Whether self-attestation should be distinguishable from independent attestation at the protocol level.

  2. How revocation or conflicting attestations should be discovered.

  3. Whether wallets should be expected to evaluate mutable on-chain state before displaying a descriptor.

  4. What minimum status a wallet can safely show without implying that the descriptor has been audited.

A permissionless on-chain pointer or commitment could be useful as a provenance signal, provided it is clearly separated from independent verification. A wallet might then present it as “published by the contract/project” rather than “verified.”

Keeping provenance and verification as separate concepts seems important here. Would that distinction fit the intended trust model?