Recipient-Derived Receive Addresses

Generate Ethereum receive addresses deterministically from a long-lived recipient secret plus per-event context (e.g., event identifier, contract address, sequence number), such that an observer without the secret cannot predict, recognize, or link the addresses, while the recipient (with their secret) can re-derive the corresponding private key and spend the funds.

This is not EIP-5564 stealth addressing. EIP-5564 derives destinations through ECDH between sender ephemeral and recipient view keys; recipients scan the chain to detect inbound funds; senders need the recipient's published view pubkey. The recipient-derived pattern is the recipient's own deterministic key-derivation scheme, optimized for constrained recipient devices that cannot evaluate ECDH in-the-loop and that have no published view-pubkey infrastructure.

• Long-lived recipient secret: 32 bytes provisioned at enrollment; held on a constrained device.
• PRF: HMAC-SHA256 (universal in conservative crypto APIs). Any PRF with 256-bit output suffices.
• Curve operation: secp256k1 scalar multiplication. Performed by the recipient or by an auxiliary device that learns nothing else; need not happen on the constrained device itself if it lacks the cycles.
• Address hash: keccak256, producing the 20-byte Ethereum address from the public key.

• Unlinkability against external observers: HMAC-SHA256 is a PRF. Without the recipient secret, two destinations look uniformly random and uncorrelated. Address-space collisions are bounded by birthday probability over 160-bit addresses (about 2^-80 per pair).
• Spendability: the recipient (with the secret and the public context) re-derives derivedPrivkey exactly. No chain scanning, no published view key.
• Non-interactivity: the sender does not need a view pubkey, ephemeral keypair, or per-recipient state.
• Threat model: adversary observes the chain and may compromise non-recipient parties. Out of scope: device seizure (long-lived secret residual); post-quantum adversary (recoverable curve).

• No view / spend split. Whoever holds the recipient secret both generates and spends. EIP-5564 supports a view-only auditor; this pattern does not. Audit access requires sharing the secret (full spend authority) or a separate disclosure mechanism.
• Long-lived recipient secret. Held on the device for its full lifetime. Device seizure exposes all past and future destinations. Mitigations are operational (frequent re-enrollment).
• No detection of unsolicited inbound transfers. Unlike EIP-5564 chain-scanning, the recipient knows about transfers only to destinations they themselves derived.
• Constrained-device limitations. The curve operation and keccak256 are not always available on conservative crypto APIs. Some deployments offload steps 3 and 4 to a companion device.
• Sloppy notation in spec writeups. The shorthand destination = truncate(HMAC(secret, context)) is broken if read literally: a 20-byte truncation produces an unspendable address. The four-step construction above is required for spendability. Audit production code for the full path.

A privacy-preserving payroll system. Each employee's wallet holds a long-lived recipient secret. For each monthly payroll cycle, the wallet derives a fresh receive address via HMAC-SHA256 over (recipientSecret, monthIdentifier, employerId), then computes the secp256k1 public key and the keccak256 address. The employee provides this address to the employer's payroll system; the employer disburses salary to the address. Observers see a fresh address each month with no public linkage between an employee's monthly receipts. The wallet later re-derives the private key from the same secret and month identifier to spend.