Design Rationale

Key design decisions and technical constraints that shaped the ERC-7730 standard.

Three priorities drove the standard: keeping transaction data human-readable, accounting for signer hardware constraints, and lowering the barrier for developers to adopt the format.

Core principles

Balancing developer ergonomics with end-user comprehension
Accommodating technical limitations of secure devices
Reducing implementation barriers for developers

Human readability

Developer-friendly format

The specification uses a syntax and structure designed for direct readability:

  • Implementation patterns documented alongside the specification
  • Clear examples for common use cases
  • Intuitive JSON structure

JSON data format

ERC-7730 uses JSON as its primary data format. The choice reflects two sets of criteria:

Developer benefits
  • • Widespread familiarity
  • • Extensive library support
Technical benefits
  • • Native parsing capabilities
  • • Human-readable debugging

Adoption incentives

The standard includes direct incentives for metadata file creation:

  • Broad wallet support for compliant implementations
  • Improved user experience as a direct result of implementation

Signer constraints

Signer hardware constraints shaped several key decisions in the specification.

Display limitations

ConstraintDesign response
Limited screen sizeFields are flattened to a single nesting level to avoid overflow on small screens
UI rendering capabilitiesComplex constructs such as layouts and grouping are optional, enabling progressive enhancement for more capable wallets
Memory constraintsData structures are optimized to reduce parsing overhead on constrained devices

Field structure decisions

Flattened field structure

Complex UI constructs like layouts and grouping are optional. Primary data fields are prioritized for constrained displays, with progressive enhancement for more capable wallets.

Message structure flattening

Complex nested structures are discouraged. The recommended approach converts nested objects to flattened field lists, improving display compatibility across signer types.

Recursive processing limitations

Formatters that require recursive processing (for example, calldata) have documented limitations. Alternative patterns and graceful degradation paths are provided for signer implementations.

See also

Ledger
Copyright © Ledger SAS. All rights reserved. Ledger, Ledger Stax, Ledger Flex, Ledger Nano, Ledger Nano S, Ledger OS, Ledger Wallet, [LEDGER] (logo), [L] (logo) are trademarks owned by Ledger SAS.