ERC-7730 quick reference

A practical reference for the ERC-7730 fields and formats you use with Ledger’s tools. For the authoritative, complete specification, see the ERC-7730 EIP and clearsigning.org .

Ledger’s tools and the registry currently target ERC-7730 v1. Version 2 is in draft — track it at clearsigning.org . This page reflects v1; the EIP is the source of truth.

File structure

An ERC-7730 descriptor has three sections:


{
  "$schema": "https://eips.ethereum.org/assets/eip-7730/erc7730-v1.schema.json",
  "context":  { /* what the descriptor binds to: contract + chain, or an EIP-712 schema */ },
  "metadata": { /* owner, plus reusable enums and constants */ },
  "display":  { /* how each function or message is formatted for the signer */ }
}

Context section

Binds the descriptor to what is being signed.

Contract calls: contract.abi (URL or inline) and contract.deployments (chain ID + address pairs). Optional contract.addressMatcher and contract.factory for proxy and factory patterns.
EIP-712 messages: eip712.schemas (type definitions), with optional eip712.domain and eip712.deployments.

Metadata section

owner — protocol name (required)
info — url, legalName, deploymentDate (optional)
enums — value-to-label mappings
constants — reusable values
token — ticker, name, decimals (token contracts only)

Display section

display.formats keys each function or message to an intent (a short verb phrase) and a list of fields. Each field has a path, a label, a format, and optional params. Every parameter must appear in fields or excluded.

Key each entry by Solidity declaration, canonical signature, or 4-byte selector:


"transfer(address _to,uint256 _value)": { },   // Solidity declaration
"transfer(address,uint256)": { },              // Canonical signature
"0xa9059cbb": { }                              // 4-byte selector

Format types

Format	Params	Use for
`raw`	—	IDs, counts, generic integers
`amount`	—	Native currency (ETH, BNB)
`tokenAmount`	`tokenPath` or `token`* (opt. `threshold`, `message`)	ERC-20 amounts and approvals
`nftName`	`collectionPath` or `collection`*	NFT collection and token ID
`date`	`encoding` (`timestamp` or `blockheight`)	Deadlines, expirations
`duration`	—	Lock periods, timeouts (HH:MM:SS)
`addressOrName`	`type` (optional)	Recipients, contracts (ENS-resolved)
`enum`	`$ref` to `$.metadata.enums.NAME`	Status codes, modes
`unit`	`unit`	Percentages, rates, custom units

*One of the two is required.


{
  "path": "amount",
  "label": "Amount",
  "format": "tokenAmount",
  "params": { "tokenPath": "token", "threshold": "0xFFFFFFFF", "message": "Unlimited" }
}

Path system

Field paths reference data with three roots:

Root	Refers to	Example
`#`	The structured data being signed — decoded calldata parameters or EIP-712 fields	`#.amount`
`$`	Values in the merged ERC-7730 file	`$.metadata.enums.interestRateMode`
`@`	Container fields from the transaction envelope	`@.to`, `@.value`

Omitting the root makes a path relative to the structure being described — equivalent to starting with #.. This is why most field paths are written bare (_to, amount) rather than #._to.

Arrays and byte slices:


"tokens[]"        // all array elements
"tokens[0]"       // first element
"data[4:]"        // skip the first 4 bytes
"data[:32]"       // first 32 bytes

Validation checklist

Include the $schema field
Define a contract or eip712 context
Add display formats for every user-facing function
Use the correct path roots (#, $, @), or bare paths for calldata
Match format types to the field’s data type
Validate against the schema before submitting

Resources

ERC-7730 EIP — the authoritative specification
clearsigning.org — the standard, registry, and v2 work
JSON schema — validate programmatically
Registry examples — real descriptors from major protocols