Implement ERC-7730

Make your protocol's transactions readable across every wallet that supports clear signing.

Anatomy of a descriptor

A descriptor tells a wallet three things: where it applies, what public details it can show about the target, and how each supported action should appear to the signer.

Context

The match rule. It points to the contract deployments, chain and address, or typed-data messages this descriptor covers, so wallets only use it in the right place.

Metadata

Public details about the target, such as the project name, contract name, deployment date, and official links, plus reusable values that display rules can reference.

Display rules

The signer-facing part. For each supported function or message, it defines the action label, which fields the user sees, and how each value is formatted.

How to submit

The common path combines protocol authorship, automated checks, maintainer coordination, and room for independent review.

  1. 01

    Write a descriptor

    Create a JSON file following the ERC-7730 schema for your contract or message type.

  2. 02

    Open a pull request

    Submit your descriptor to the registry GitHub repository with a brief description and examples of how the metadata renders in a wallet.

  3. 03

    Automated checks

    CI validates your descriptor before human review begins: schema conformance, linting for common errors, ABI or selector consistency, contract deployment verification, and transaction-data validation.

  4. 04

    Maintainer review

    Maintainers coordinate the shared review path and check intent descriptions, labels, and cross-wallet consistency before publication on the common path.

  5. 05

    Reviewer and auditor signals

    Additional organizations review or audit the change and publish their findings. Wallets decide which review signals they trust alongside the metadata source they consume.

  6. 06

    Signed and deployed

    Once published, the descriptor is available to wallets that support ERC-7730. Teams can use the common path or operate their own pipeline with their own keys and review model.

Implementation resources

References, examples, and tooling for implementing ERC-7730.

Learn

ERC-7730 Specification ERC-7730 JSON Schema Example Descriptor Files Ethereum.org Clear Signing Tutorial Coming soon

Build & test

Sourcify clear-signing preview available Sourcify TypeScript library in development Lucid Umbrella Rust library in development

Publish & discuss

ERC-7730 registry Ledger Developer Portal Ethereum Magicians Discussion

For wallet developers

How to consume ERC-7730 metadata and display clear signing screens.

Consume registry metadata

At signing time, wallets fetch the ERC-7730 descriptor matching the target contract and chain. The descriptor provides display formats, field-level formatting rules, and intent labels that transform raw calldata into a readable confirmation screen.

Enforce your trust policy

Resolve attestation and review signals before rendering a descriptor, decide which signals your wallet will accept, and define fallback behavior when metadata is missing or untrusted. The registry can contain low-quality or malicious entries by design; your wallet decides what reaches the signing screen.

Get started

Integration documentation and SDK resources are available through the Ledger Developer Portal. For questions, join the Ethereum Magicians discussion.

What's new in v2

The main changes proposed for the next version of the standard, with public discussion continuing on Ethereum Magicians.

Compatibility note: Advanced ERC-7730 v2 features, including maps, bundled fields, and interoperable addresses, may not be supported by all hardware wallets. If broad compatibility matters, avoid relying on these features unless you have verified support in your target wallets.

01

Cross-chain token formatters

Token display accepts a chain ID parameter, enabling correct rendering across networks.

02

Encryption specifications

Descriptors can annotate encrypted fields with decryption context.

03

Registry trust model

v2 clarifies what wallets and integrators trust when using an external metadata registry, so those assumptions can be made visible to users.

04

InterpolatedIntent

Dynamic intent strings and batch transaction compatibility.

05

Function signatures as schema keys

Embedded ABIs replaced with function signatures, making descriptors lighter and more maintainable.

06

Broader scope

Aligning for machine consumption, not just human-readable display, supporting future compatibility with emerging signature types.

Future directions

  • Batched and multi-action transaction support
  • ERC-8021 support
  • Onchain registry

Follow the public v2 discussion on Ethereum Magicians.