{"id":"ERC-7627","name":"Secure Messaging Protocol","status":"Final","chain":"both","category":{"id":"identity","name":"Identity & Privacy","description":"Who you are on-chain, and what you choose to reveal"},"journeyStages":[{"id":"specialized","name":"Specialized Interactions","description":"Physical items, AI, social, gaming"}],"uxImpact":"ERC-7627 defines encrypted on-chain messaging with public-key registration, algorithm metadata, session IDs, and message events. It provides updatePublicKey, sendMessage, and getUserPublicKey; key derivation, private-key recovery, inbox enumeration, and event indexing remain integration responsibilities.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-7627","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-7627","summary":"ERC-7627 defines encrypted on-chain messaging with public-key registration, algorithm metadata, session IDs, and message events. It provides updatePublicKey, sendMessage, and getUserPublicKey; key derivation, private-key recovery, inbox enumeration, and event indexing remain integration responsibilities.","applicability":{"whenToUse":["Users need encrypted message bytes registered and emitted on-chain.","The implementation provides public-key registration and the app can choose a key lifecycle and algorithm policy.","An event indexer supplies inbox discovery and the product can explain recovery, rotation, and spam controls."],"whenToAvoid":["The app cannot encrypt and decrypt with a supported key lifecycle.","Plaintext must be searchable by a server or stored without recipient-key protection.","The product lacks event indexing and spam controls for message discovery."]},"designerTakeaways":["You can show the recipient address, selected public-key algorithm, and key index before sending.","You can design encrypted messages that the chosen key lifecycle makes decryptable by the intended recipient.","You can use event indexing and app policy for inbox discovery, spam filtering, and recovery."],"problemsSolved":[{"problem":"Apps need a shared interface for wallet-addressed keys and messages","oldWay":"Integrate separate key registries and message formats for each messaging service","newWay":"A dApp can address encrypted message bytes to a wallet with a compatible registered public key, while key registration and identity policy remain explicit","impact":"critical"},{"problem":"On-chain messages are public and readable by anyone","oldWay":"Send a transaction with data field = your message (visible to all)","newWay":"Encrypted message bytes can be emitted to the recipient address, while the chosen key lifecycle determines how the recipient decrypts them","impact":"critical"},{"problem":"Centralized messaging platforms control communication","oldWay":"Discord/Twitter can ban, delete messages, read content","newWay":"Messages can be emitted on-chain for indexing, while confidentiality and censorship properties depend on encryption, key management, and the deployment","impact":"high"},{"problem":"Offer negotiation may require a separate account or communication channel","oldWay":"Contact the seller through a separate social or messaging service","newWay":"A compatible app can publish encrypted wallet-addressed offers using registered recipient keys; transaction metadata remains public","impact":"medium"}],"uxPatterns":[{"name":"Wallet-to-Wallet Messaging","description":"Send encrypted message to a wallet with a compatible registered public key and supported key lifecycle","userFlow":["Enter recipient address or resolve ENS separately","Require a compatible registered public key and check its valid_before metadata","Use the app’s encryption scheme compatible with the registered public-key type and selected key lifecycle","Sign sendMessage","Index MessageSent events to show on-chain publication, not proof of delivery, decryption, or reading"]},{"name":"Inbox Interface","description":"View and manage encrypted messages","userFlow":["User opens an app-provided inbox","Indexer reads MessageSent events for the address","App fetches the relevant public-key metadata","Decrypts locally using the app's key lifecycle","Shows session and message state"]},{"name":"Message Thread View","description":"Group messages by the custom sessionId; conversation discovery comes from event indexing.","userFlow":["Click on message to open thread","See full conversation history","Compose reply","Track publication of each sendMessage call; any batching depends on the application and wallet","Option to block sender"]},{"name":"Spam Filtering","description":"Apply spam and block controls in the app or indexer; the base interface does not define inbox filters.","userFlow":["User configures inbox filters","Chooses which senders appear in the app","Manages hidden or blocked addresses","Stores settings under the app’s documented policy","Filters the displayed inbox; this does not prevent others from publishing messages on-chain"]}],"uiComponents":[{"name":"EncryptedMessageComposer","description":"Validate a supported recipient key and encrypt locally before submitting ciphertext.","states":["composing","key-unavailable","encrypting","publishing","published","error"],"props":["recipient","onSend","maxLength"]},{"name":"DecryptedMessageViewer","description":"Displays decrypted message content","states":["decrypting","decrypted","decrypt-error"],"props":["encryptedData","sender","timestamp"]},{"name":"InboxList","description":"List messages discovered by an app indexer; show plaintext previews only after authorized local decryption.","states":["loading","loaded","empty","filtered"],"props":["messages[]","filter","onSelect"]},{"name":"EncryptionBadge","description":"Visual indicator that message is encrypted","states":["encrypted","decrypting","decrypted"],"props":["status"]}],"antiPatterns":[{"pattern":"Sending messages unencrypted","why":"Defeats the purpose, messages readable by anyone","instead":"Always encrypt before storing on-chain","severity":"critical"},{"pattern":"No spam protection","why":"Inbox flooded with unwanted messages, unusable","instead":"Use event indexing and an app-level filtering policy; the interface has no inbox enumeration or spam-control method.","severity":"high"},{"pattern":"Storing decrypted messages on server","why":"Breaks end-to-end encryption promise","instead":"Decrypt locally according to the chosen key lifecycle and explain recovery/rotation limits; do not imply that the standard derives keys for the wallet.","severity":"critical"},{"pattern":"No indication of encryption status","why":"Users don't know if message is private","instead":"Show clear 🔒 indicator when encrypted","severity":"high"},{"pattern":"Treating encrypted content as anonymous communication","why":"MessageSent publicly exposes sender, recipient, key index and session ID even when the payload is encrypted.","instead":"Disclose public message metadata and distinguish on-chain publication from recipient decryption or reading.","severity":"high"}],"keyTakeaways":["ERC-7627 registers public keys and emits encrypted messages on-chain.","Use updatePublicKey, sendMessage, and getUserPublicKey with the exact key index and sessionId.","Choose and disclose the key lifecycle, recovery, rotation, and algorithm support.","Use an event indexer for inbox discovery and conversation history.","Keep encrypted bytes and plaintext strictly separate.","Encrypted payloads do not hide public message metadata or prove that the recipient has read a message."],"technicalNotes":"ERC-7627 defines PublicKeyAlgorithm { ECDSA, ED25519, X25519 }, PublicKey { public_key, valid_before, algorithm }, MessageSent and PublicKeyUpdated events, updatePublicKey(bytes32, PublicKey), sendMessage(address, bytes32, bytes32, bytes), and getUserPublicKey(address, bytes32). It does not specify wallet key derivation, private-key recovery, or inbox enumeration; event indexing and key management are application responsibilities. The public-key type labels do not specify a complete client encryption scheme. MessageSent exposes public sender, recipient, key index and session metadata and proves publication, not decryption or reading.","specConstraints":[{"id":"encryption-algorithm-lifecycle","constraint":"Applications should choose currently recommended encryption algorithms, avoid known vulnerabilities, and update them as threats evolve.","appliesTo":"application","normativity":"security-considerations","specQuote":"When selecting encryption algorithms, it is essential to stay informed about the latest security news and recommendations. Avoid using asymmetric encryption algorithms with known vulnerabilities or those not recommended to ensure the confidentiality and integrity of messages. Regularly update encryption algorithms to address evolving security threats.","specSection":"Security Considerations / Utilization of Latest Secure Encryption Algorithms","specUrl":"https://ercs.ethereum.org/ERCS/erc-7627#utilization-of-latest-secure-encryption-algorithms","designImplication":"Make algorithm support and deprecation visible, reject known-weak configurations, and provide a migration path when a message scheme is no longer recommended."},{"id":"recipient-key-encryption","constraint":"Message content should be encrypted with the recipient's public key during transmission and storage.","appliesTo":"application","normativity":"security-considerations","specQuote":"To maintain message confidentiality, the content of sent messages must be strictly encrypted using the recipient's public key. Any plaintext information transmitted could lead to information leakage and security risks. Encrypt message content at all times during transmission and storage to prevent unauthorized access to sensitive information.","specSection":"Security Considerations / Strict Encryption Using Public Keys for Message Content","specUrl":"https://ercs.ethereum.org/ERCS/erc-7627#strict-encryption-using-public-keys-for-message-content","designImplication":"Keep plaintext out of on-chain payloads, transport logs, and local persistence; distinguish encrypted publication from successful decryption or message reading."},{"id":"key-management","constraint":"Public and private keys need secure storage and transmission, with rotation, multi-factor protection, and regular process review.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"Robust key management and protection measures are necessary for both user public and private keys. Ensure secure storage and transmission of keys to prevent leakage and tampering. Employ multi-factor authentication and key rotation strategies to enhance key security and regularly assess key management processes to mitigate potential security risks.","specSection":"Security Considerations / Key Management and Protection","specUrl":"https://ercs.ethereum.org/ERCS/erc-7627#key-management-and-protection","designImplication":"Explain key custody, rotation, recovery, and MFA boundaries in wallet or messaging flows; do not imply that the public-key interface itself supplies private-key backup or recovery."}],"lastUpdated":"2026-09-18","sources":[{"label":"ERC-7627 official specification","url":"https://ercs.ethereum.org/ERCS/erc-7627","type":"official-spec"}],"lastReviewed":"2026-09-18"},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-7627","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-7627","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-7627","markdown":"https://www.eipsfordesigners.com/standards/ERC-7627/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-7627/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-7627","official":"https://ercs.ethereum.org/ERCS/erc-7627","discussion":"https://ethereum-magicians.org/search?q=ERC-7627"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}