# ERC-7627: Secure Messaging Protocol

Source: https://www.eipsfordesigners.com/standards/ERC-7627
Agent brief: https://www.eipsfordesigners.com/standards/ERC-7627/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-7627
Last reviewed: 2026-04-05
Last updated: 2026-04-05

| Field | Value |
| --- | --- |
| Status | Draft |
| Chain | both |
| Category | Identity & Privacy |
| Journey stages | Specialized Interactions |
| Detailed guide | Yes |
| Official specification | https://eips.ethereum.org/EIPS/eip-7627 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-7627 |

## UX Impact

End-to-end encrypted messaging between wallet addresses — private on-chain communication with session support. Design implications: show encryption status indicator, display message history by session, add public key registration flow. Design decisions: key management UX — how to handle key rotation, session organization, balance security (key expiry) with convenience (persistent conversations).

## Summary

ERC-7627 defines a secure messaging protocol for on-chain communication between wallet addresses. Messages are end-to-end encrypted, stored on-chain, and only readable by the intended recipient. It enables private DMs between wallets without relying on centralized messaging services.

## For Designers

- You can design UI that delivers message 0xABC directly, cryptographically verified.
- You can design UI that delivers encrypted messages only decryptable by recipient.
- You can design UI that delivers messages stored on-chain, censorship-resistant.

## Applicability

### When to Use

- Your product addresses: no standard way to message a wallet address.
- Your product addresses: on-chain messages are public and readable by anyone.
- The flow should deliver: message 0xABC directly, cryptographically verified.
- Connect flows must list wallets with names, icons, and explicit user choice.

### When to Avoid

- Always encrypt before storing on-chain.
- Decrypt client-side only, never send plaintext to server.
- Implement filtering, blocking, and allow-lists.
- The product has no sign-in, attestation, or identity verification step.

## Problems It Solves

### No standard way to message a wallet address

Impact: critical

Old way: Find their Twitter/Discord, hope it's the right person, no verification

New way: Message 0xABC directly, cryptographically verified

### On-chain messages are public and readable by anyone

Impact: critical

Old way: Send a transaction with data field = your message (visible to all)

New way: Encrypted messages only decryptable by recipient

### Centralized messaging platforms control communication

Impact: high

Old way: Discord/Twitter can ban, delete messages, read content

New way: Messages stored on-chain, censorship-resistant

### NFT buyers can't negotiate with sellers privately

Impact: medium

Old way: Public comments, DM through social platforms

New way: Private offer negotiation directly wallet-to-wallet

## Anti-Patterns

### Sending messages unencrypted

Severity: critical

Defeats the purpose, messages readable by anyone

Instead: Always encrypt before storing on-chain

### Storing decrypted messages on server

Severity: critical

Breaks end-to-end encryption promise

Instead: Decrypt client-side only, never send plaintext to server

### No spam protection

Severity: high

Inbox flooded with unwanted messages, unusable

Instead: Implement filtering, blocking, and allow-lists

### No indication of encryption status

Severity: high

Users don't know if message is private

Instead: Show clear 🔒 indicator when encrypted

## UI Components

### EncryptedMessageComposer

Text input that encrypts before sending
States: composing, encrypting, sending, sent, error
Props: recipient, onSend, maxLength

### DecryptedMessageViewer

Displays decrypted message content
States: decrypting, decrypted, decrypt-error
Props: encryptedData, sender, timestamp

### InboxList

List of received messages with previews
States: loading, loaded, empty, filtered
Props: messages[], filter, onSelect

### EncryptionBadge

Visual indicator that message is encrypted
States: encrypted, decrypting, decrypted
Props: status

## On Monad

### Message Delivery

Ethereum: Message takes 15+ seconds to be "sent"

Monad: Sub-second delivery, feels like regular chat

Design implication: Can build real-time-feeling chat experience

### Cost Per Message

Ethereum: Each message costs $1-5+ in gas

Monad: Negligible cost enables casual conversation

Design implication: Can encourage back-and-forth communication

### Message History

Ethereum: Fetching history is slow/expensive

Monad: Fast reads enable real-time inbox refresh

Design implication: Can show "last seen" and real-time typing indicators

### Throughput

Ethereum: Limited messages per block

Monad: High throughput enables busy messaging apps

Design implication: Can support group chats and high-volume communication

## Key Takeaways

- End-to-end encryption is mandatory - message only readable by recipient
- Decrypt client-side only, never on server
- Show clear encryption indicators (🔒)
- Implement spam filtering - allow-lists, blocking, filters
- On Monad: cheap + fast enables actual chat-like experience

## UX Patterns

### Wallet-to-Wallet Messaging

Send encrypted message to any wallet address

User flow:

- Enter recipient address or ENS
- Compose message
- Message encrypted client-side
- Sign transaction to send
- Message stored on-chain encrypted
- Only recipient can decrypt

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

### Inbox Interface

View and manage encrypted messages

User flow:

- User opens inbox
- Messages fetched from chain
- Decrypted locally with wallet key
- Display previews and timestamps
- Click to read full message

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

### Message Thread View

Conversation view with reply functionality

User flow:

- Click on message to open thread
- See full conversation history
- Compose reply
- Each message is separate transaction
- Option to block sender

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

### Spam Filtering

Filter unwanted messages

User flow:

- User configures message filters
- Select who can send messages
- Manage blocked addresses
- Settings stored on-chain or locally
- Filter applied to incoming messages

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

## Technical Notes

ERC-7627 uses asymmetric encryption where the sender encrypts with recipient's public key. Messages are stored on-chain as encrypted bytes. The recipient's wallet decrypts using their private key. The standard defines message format, key derivation, and inbox querying. Integration with ENS allows addressing by name instead of address.