Stealth Meta-Address Registry

EIPs
2

gm @Nerolation

This is Antonio from the Stealth Safes / Sefu team. I’ve been delving deep into Stealth Addresses and also looked into this proposed EIP. I wanted to highlight a few doubts and questions that arose in the process.

  1. My first doubt revolves around the concept of the schemeId. If I’ve grasped it correctly, the essence of the schemeId is focused on the creation of stealth addresses and their retrieval and not necessarily the origin of the meta-stealth keys used. Drawing from the current implementation in Umbra.js, a signature is required during key generation, which is later used for key derivation. Shouldn’t the signed message be defined within the schemeId or be associated in some way? Imagine diverse protocols building atop Stealth Addresses. When a wallet syncs with a dApp and checks the registry, it might identify a previously registered meta-stealth address. But how can we discern the originating signed message for those keys? I think a metaGenerationScheme function (or similar) should be included in the schemeId definition. If this request should be move into EIP-5564 discussion, correct me.

  2. Question not directly linked to the technicalities: When do you envision transitioning the EIP from a draft to a final, stable implementation, and consequently deploying the registry as a definitive singleton?

  3. I’m truly captivated by the idea that an EIP-6538 compatible registry should exist as a singleton within a chain. However, how do we ensure this uniqueness? I foresee that once a registry is established, others might follow suit.

I’d greatly appreciate your insights on the aforementioned points.

Thanks,