# Agent instructions

You are advising on UX and product design for **ERC-191: Signed Data Standard**.
This document is editorial design guidance from EIPs for Designers. Official specifications control protocol facts.

- Treat **MUST NOT** items as editorial guardrails. Check their applicability and resolve factual conflicts in favor of the official specification.
- Use the **Vocabulary** section for UI copy; do not use avoided terms.
- Cite the canonical source URL when giving recommendations.
- Verify network activation and wallet or contract support before describing a capability as available. Specification status alone does not establish deployment.

---

# ERC-191: Signed Data Standard

Source: https://www.eipsfordesigners.com/standards/ERC-191
Agent brief: https://www.eipsfordesigners.com/standards/ERC-191/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-191
Last reviewed: 2026-09-18
Last updated: 2026-09-18

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | both |
| Category | Security & Trust |
| Journey stages | Authentication & Identity |
| Detailed guide | Yes |
| Official specification | https://ercs.ethereum.org/ERCS/erc-191 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-191 |

## UX Impact

ERC-191 prefixes signed data with version-specific envelopes to prevent legacy-transaction parsing. It does not provide general replay or authorization safety; bind domain/intent and use nonce/consumption checks in the application, with visual separation from permits and typed data.

## Summary

ERC-191 defines an envelope for signed data with a version byte and version-specific payload. It prevents a signed message from being parsed as a legacy transaction, but replay resistance and authorization safety still require domain/intent binding and application checks.

## For Designers

- Show the message purpose, origin, and version-specific payload before signing.
- Use nonce validation or one-time consumption to reject replay. A deadline limits validity but does not stop reuse before it expires.
- Keep personal messages, typed structured data, and token permits visually distinct.

## Applicability

### When to Use

- Your product addresses: signed messages could be replayed as transactions.
- Your product addresses: no standard format for signed data.
- The 0x19 envelope helps keep signed data from being parsed as a legacy transaction; replay and authorization still need application checks.
- You are designing a personal message signing experience with visible states and recovery paths.

### When to Avoid

- The signature authorizes a transaction, token spend, or structured action that needs a typed-data or transaction-specific review.
- The app cannot bind the message to a domain, intent, nonce, or consumption policy.
- The wallet cannot render the requested message in a form the user can review.

## Problems It Solves

### Signed messages could be replayed as transactions

Impact: critical

Old way: Sign a message, attacker replays it as a transaction draining funds

New way: The 0x19 envelope prevents the signed data from being interpreted as a legacy transaction; the app still controls replay policy

### No standard format for signed data

Impact: high

Old way: Each app invented own signing format, security varied wildly

New way: Standard prefix + version byte = consistent, auditable signing

### Can't verify what type of signature it is

Impact: high

Old way: Raw signature could be anything, hard to validate

New way: Version byte indicates: personal message, typed data, or validator

### Signing requests look the same regardless of purpose

Impact: medium

Old way: User signs hex blob, no idea if it's login or permission grant

New way: Different prefixes enable different wallet UI treatments

### Cross-protocol signature collision

Impact: medium

Old way: Signature for App A might be valid for unrelated use in App B

New way: Version 0x00 binds data to a validator address; version 0x45 is personal_sign and version 0x01 is structured data

## MUST NOT (Anti-Patterns)

- **Asking users to sign raw hex data** (critical)
  - Why: Users can't verify what they're signing, easy to trick them
  - Instead: Always show human-readable message with clear purpose

- **Relying on expiry alone for replay protection** (critical)
  - Why: An unconsumed signature can be reused until expiry, and some authorizations need a one-time-use check.
  - Instead: Bind the message to its domain and intent, include a nonce or unique identifier, and record consumption where the application requires it.

- **Signing messages that look like transaction data** (critical)
  - Why: Could be tricking user into signing malicious permit/approval
  - Instead: Wallet should warn if message looks like encoded function call

- **Not explaining what signing does vs doesn't do** (high)
  - Why: Users fear any signature might drain their wallet
  - Instead: Clearly state "This will NOT approve transactions or spend funds"

- **Using one visual treatment for login, personal messages, and permits** (high)
  - Why: ERC-191 envelopes do not make a personal signature a token allowance or transaction authorization.
  - Instead: Use a neutral message treatment for ERC-191 personal signing and a distinct typed-data or permit treatment for spending authorization.

- **Not showing the requesting origin** (high)
  - Why: Phishing sites can pretend to be legitimate
  - Instead: Always show full URL of requesting site prominently

## UX Patterns

### Personal Message Signing

Standard wallet UI for human-readable message signing

User flow:

- dApp calls personal_sign with message
- Wallet shows readable message content
- User reads and understands what they're signing
- User clicks Sign
- Wallet prepends ERC-191 prefix and signs
- Signature returned to dApp

Mockup registry key: `concept/verify-safety` (React UI on the live standard page).

### Login Signature

Sign-in authentication flow

User flow:

- User clicks "Connect" or "Sign In"
- Wallet explains what signature does and doesn't do
- User understands this is just authentication
- User signs
- Backend verifies signature, creates session

Mockup registry key: `concept/siwe-sign-in` (React UI on the live standard page).

### Proof of Ownership

Verify wallet ownership for external systems

User flow:

- External service needs wallet verification
- Presents message with context (what, why)
- User understands linking purpose
- User signs message
- Service verifies signature, grants access

Mockup registry key: `concept/verify-safety` (React UI on the live standard page).

### Dangerous Signature Warning

Wallet warns about suspicious signing requests

User flow:

- Suspicious site requests signature
- Wallet detects non-readable content
- Shows warning about potential attack
- User encouraged to reject
- If user proceeds, extra confirmation required

Mockup registry key: `concept/verify-safety` (React UI on the live standard page).

## UI Components

### MessageDisplay

Render signed message content
States: readable, hex, mixed, suspicious
Props: message, encoding, maxLength, expanded

### SignatureTypeIndicator

Show what type of signature this is
States: personal, typed, login, unknown
Props: type, version, tooltip

### OriginBadge

Show requesting site with trust level
States: trusted, unknown, suspicious, known-malicious
Props: origin, trustLevel, previousInteractions

### ScopeExplainer

Explain what signature grants and doesn't grant
States: collapsed, expanded
Props: grants[], doesNotGrant[], expiresAt

### NonceDisplay

Show the nonce or unique ID and any application timestamp/expiry used for replay handling.
States: valid, expired, consumed, missing
Props: nonce, uniqueId, timestamp, expiresAt, consumed

## Key Takeaways

- The ERC-191 envelope distinguishes signed data from legacy transaction encoding.
- Show human-readable message content and the requesting origin.
- Use domain binding, a nonce or unique ID, and consumed-signature checks where replay matters.
- Clearly explain what a personal signature does and does not authorize.
- Keep personal messages, typed data, and token permits visually distinct.

## Technical Notes

ERC-191 encodes 0x19 followed by a version byte and version-specific data. Version 0x00 includes a validator address, 0x01 is structured data as used by EIP-712, and 0x45 is personal_sign with the Ethereum Signed Message prefix. The envelope prevents transaction parsing confusion; applications still need domain binding, nonces, expiration, and consumed-signature checks where replay matters.

## Official specification (reference only)

https://ercs.ethereum.org/ERCS/erc-191