---
title: Design Rationale
category: reference
---

# 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

[Human readability](#human-readability)
Balancing developer ergonomics with end-user comprehension

[Hardware support](#signer-constraints)
Accommodating technical limitations of secure devices

[Developer adoption](#adoption-incentives)
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



Technical benefits



### 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

Constraint
Design response

Limited screen size
Fields are flattened to a single nesting level to avoid overflow on small screens

UI rendering capabilities
Complex constructs such as layouts and grouping are optional, enabling progressive enhancement for more capable wallets

Memory constraints
Data 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

- [ERC-7730 Specifications](./specifications) — full specification reference
- [External Resources](./external-resources) — ERC-7730 EIP, JSON schema, and registry links
- [Get Started with Clear Signing](../for-dapps/get-started) — implementation guide for dapp developers
- [Clear Signing for Wallets](../for-wallets) — implementation guide for wallet developers