Recipient privacy for public blockchains

Abstract

Public blockchains make transaction history easy to inspect. Reusing a wallet address lets observers connect incoming payments, balances, counterparties, and later spending activity. VEIL uses stealth addresses to give each payment a new destination while preserving control for the intended recipient.

The first VEIL release focuses on recipient privacy for EVM transfers. It does not hide amounts, timing, sender addresses, gas usage, or later links created by the recipient. It is not a mixer and does not pool assets.

Problem

A person or business often needs a stable address that others can save. A stable address is convenient, but every payment sent to it becomes part of one public profile. Creating new wallets manually shifts the burden to the recipient and still requires a private method for distributing those addresses.

Design goals

• No custody. VEIL contracts do not hold user funds.
• Recipient control. Only the recipient can derive the spending key for a valid stealth payment.
• One public identity. A recipient can publish one meta-address and receive through many destinations.
• Open implementation. The protocol uses standard EVM contracts and public cryptographic specifications.
• Honest claims. The interface states which transaction fields remain public.
• Disclosed pricing. The exact protocol fee and sender total are shown before signing.

System architecture

Payment flow

1. 01
   Resolve recipient

   The sender receives a VEIL meta-address directly or reads it from the registry.

2. 02
   Generate ephemeral key

   The sender creates a fresh ephemeral keypair for this transfer.

3. 03
   Derive destination

   Elliptic-curve operations combine the ephemeral private key with the recipient viewing public key. The result contributes to a one-time spending public key.

4. 04
   Route, charge, and announce

   The sender signs one router transaction. The router delivers the entered amount, collects the disclosed VEIL fee, and publishes the announcement atomically.

5. 05
   Detect and spend

   The recipient scans, verifies ownership, derives the private key, and later moves the funds.

Privacy model

VEIL improves privacy only when users avoid obvious linkability mistakes. Sweeping many stealth addresses into one known wallet can reveal common control. Fixed payment amounts, repeated timing patterns, exchange deposits, browser compromise, and off-chain identity leaks can also reduce privacy.

Security boundaries

• The browser and device must be trusted while an identity is unlocked.
• The encrypted backup is only as strong as its password and the user's storage practices.
• Contract addresses and RPC responses must be verified before live use.
• Third-party wallet software can expose metadata outside VEIL's control.
• Beta software must not be treated as audited production infrastructure.

Contract surface

ERC5564Announcer emits standardized announcements. It is not a vault and does not retain transferred assets.

ERC6538Registry stores public meta-addresses by registrant and scheme identifier. Registration does not grant control of funds.

VeilRouter accepts native ETH, transfers the entered amount to the one-time address, sends the disclosed protocol fee to the configured treasury, and calls the announcer in the same transaction.

The first release uses scheme identifier 1 for secp256k1 stealth addresses. Additional schemes require separate review and explicit support.

Protocol fee model

Native ETH private transfers use a transparent bounded fee. The sender pays the fee in addition to the amount entered for the recipient.

The fee is calculated as clamp(amount × 0.25%, 0.0001 ETH, 0.01 ETH). The interface displays the exact quote and sender total before the wallet request.

Non-goals

• Hiding transaction amounts.
• Hiding sender addresses.
• Providing guaranteed anonymity.
• Mixing or pooling user assets.
• Replacing legal, compliance, or operational controls required by an application.