Stealth Address Donations

We let users (donors) create stealth addresses for others (receivers) and send arbitrary assets to them. Receivers can be.registered projects or individuals that want to allow others to transfer funds on independently created stealth addresses. This can be useful to send a POAP to a user without establishing an immediate connection, similarly for organizations to receive donations. Senders can transfer to these stealth addresses, knowing that only the recipient can generate the private key to them. This project started from an EIP by one of our team members. In EIP-5564 he proposes standardizing functions for stealth addresses in smart contract wallets. Stealth addresses have been used in other protocols, such as Bitcoin, for a long time. They would be an additional and lightweight option for obfuscation of recipients. These stealth addresses could be used to send any arbitrary token to, potentially including some funds to cover gas for spending the token further. A sender could thus generate a stealth address from a signature of a recipient, and, without interaction, transfer a POAP, ERC-20, ERC-721 etc. A similar implementation of stealth addresses can be found from the Umbra project, who have implemented stealth addresses in a similar manner. We implement another version with the aim to standardize further for the EIP. For this project, we enable frontend stealth address generation in JavaScript, create a registry contract storing view and spend public keys, and a pass-through contract that emits events, which we parse allowing users to spend funds on any stealth addresses belonging to them. Notably, these stealth addresses do not hide a connection to the origin of the funds. If the receiving funds are spent further, that connection is visible. Instead, these stealth addresses provide further obfuscation at little cost. Additionally, if users send SBT or other assets that provide benefit without further transactions, stealth addresses provide a great alternative to more complex methods. Through standardization, this method can provide another layer of obfuscation and be used in a variety of ways.

We generate stealth addresses from a user’s secret key and a receiver’s spend and view public keys in JavaScript. We then create a transaction to our donation contract with the stealth address and shared secret Q. Our announcement contract emits an announcement containing these shared secrets and the receiver’s stealth address. By creating private keys with all shared secrets and deriving addresses, the user can compare them to the respective stealth addresses. If any match, they know that they have received assets to that stealth address and can store the respective private key. The entire process requires no interaction between the sender and receiver and is done locally. Receivers can register a project, organization or just themselves by sending us a name, description and their view and spend public keys. We store the name and description on IPFS and the keys in our registry contract, which allows senders to retrieve the correct key from an immutable contract and avoids having to trust us to provide the correct key or to handle receivers private keys.