17 years after Bitcoin’s genesis block, sending cryptocurrency still feels like a developer task. You need to ask the recipient for a wallet address, copy a 42-character hex string, make sure you’re on the right network, and acquire a gas token just to pay the fee. Miss any step, and funds are lost forever. Meanwhile, sending a message to someone takes three seconds — you just type their email or phone number.
This UX gap is not a minor inconvenience — it is the single biggest barrier to crypto mass adoption. The obvious fix is to map those identifiers directly to blockchain addresses. But every naive attempt to do so trades away the one thing users increasingly care about: privacy. Anyone who knows your email can derive your address, and from there reconstruct your entire financial history on-chain.
This post discusses HFIPay — a protocol that closes this gap without the privacy tradeoff.
The Problem
Sending cryptocurrency still requires the sender to know a wallet address. Even with UX improvements, the flow is: ask for address → copy hex string → select correct network → acquire gas token → send.
Human-friendly identifiers — email addresses, phone numbers, social handles — are already how people identify each other online. The natural goal is:
send crypto to alice@example.com the same way you’d send a message.
The naïve approach maps the identifier to an address deterministically, e.g. keccak256(identifier) → address. This is simple but introduces a critical privacy flaw: anyone who knows Alice’s email can derive her on-chain address and inspect her full transaction history, token balances, and counterparty relationships — on every supported chain.
Solution: HFIPay and What It Does
HFIPay is a protocol — not an application — that any wallet or payment app can integrate. It enables the following properties at the protocol level:
- No wallet setup required for the recipient — funds can be sent before
the recipient has ever opened a crypto app - Enumeration resistance — on-chain data reveals nothing about which
intents belong to a known email, phone, or social handle - Pre-claim unlinkability — multiple payments to the same identifier
leave no reusable on-chain recipient tag - Non-custodial claim — the relay routes but cannot redirect funds;
only the recipient can authorize release via a ZK proof - Identifier-agnostic — works with any verifiable identifier: email,
phone, X handle, or others
ith the HFIPay protocol, anyone can:
- Send crypto to anyone — no need to know the recipient’s wallet address,
or even whether they have one. - Recipient claims funds upon notification — if they don’t have a wallet
yet, one can be created on the fly at claim time. - Auto-claim after first use — once a recipient has claimed once, future
payments can be claimed automatically without manual action. - Sender can cancel within a time window — if the recipient never claims,
the sender can retrieve the funds before the timeout. - Unclaimed transfers are refunded automatically — after the expiry
window, funds are returned to the sender without any manual intervention.
How Does This Compare to ENS?
ENS is the most mature naming system in the Ethereum ecosystem and solves a real problem: replacing opaque hex addresses with human-readable names. HFIPay is solving a different problem. Here is a neutral feature comparison:
| ENS | HFIPay | |
|---|---|---|
| Identifier type | .eth name (must register) |
Email / phone (already exists, no setup) |
| On-chain mapping | Public, enumerable | Not stored on-chain |
| Privacy model | Address is public by design | Chain sees only a per-intent blinded value |
| Recipient setup | Required before receiving | Optional (lazy onboarding possible) |
| Identifier enumeration | Anyone can query any name | Chain state reveals no identifier |
| Trust assumption | ENS contract (decentralized) | Relay (see trust modes below) |
ENS and HFIPay are not in competition. A HFIPay relay could internally resolve .eth names as one identifier type among others. The difference is in what information is committed on-chain and what privacy guarantees follow.
How Does This Compare to ERC-5564 (Stealth Addresses)?
ERC-5564 hides where funds land on-chain: the recipient’s address is ephemeral and unlinkable to their public key. HFIPay hides an earlier step:
how a human-friendly identifier maps to any on-chain destination at all.
Sender knows: alice@example.com
↓
[Relay: private resolution] ← HFIPay's scope
↓
On-chain: blinded intent
↓
[ZK claim by recipient]
↓
Destination address (could be a stealth address) ← ERC-5564's scope
The two mechanisms are complementary. HFIPay can route funds to a fresh stealth address on each payment, combining identifier-level and address-level privacy.
The HFIPay Mechanism (Informal)
The protocol separates three concerns:
1. Private routing (off-chain)
The sender specifies alice@example.com. A relay privately resolves this to a registered recipient record and samples a fresh intentId. It derives a one-time deposit address and commits only an intent-specific blinded binding ρᵢ together with the quoted asset and amount. The chain sees neither the identifier nor a reusable recipient tag.
2. Sender-side quote verification (optional)
In the verified-quote deployment, the relay returns an off-chain attestation linking ρᵢ to the intended recipient’s hidden binding-key commitment. The sender can verify this before funding — the relay cannot silently redirect funds to a different recipient.
3. On-chain claim authorization
To claim funds, the recipient proves in zero knowledge (via ZK-ACE) that the funded intent’s blinded binding matches a handle derived from their deterministic identity, authorizing release to a destination of their choice. The relay is involved in routing and availability — it cannot redirect funds after the intent is funded.
Sender Relay Chain
| | |
|-- pay alice@email --> | |
| | (private lookup) |
|<-- quote (ρᵢ, τᵢ) --- | |
| | |
|-- fund intent --------|---------------------> |
| | |
Recipient
|
|-- ZK claim proof ---> |
|<-- funds released --- |
Privacy Properties
The paper formalizes two properties:
Enumeration resistance: No on-chain data allows an observer to determine which funded intents belong to a known email address, phone number, or social handle — even if the observer knows the identifier and can read all chain state.
Pre-claim unlinkability: Multiple payments to the same identifier before any claim do not expose a reusable public recipient tag. Each intent uses an independent blinded binding. After a successful claim, the destination address and asset amount become visible on-chain (as with any transaction). The paper explicitly characterizes what becomes linkable post-claim.
Trust Modes
The protocol defines two deployment modes, distinguishing what trust is placed in the relay:
Baseline deployment: The relay is trusted to bind the correct recipient to each intent. Suitable for integrated wallets where the relay and the application share a trust boundary.
Verified-quote deployment: The relay issues a sender-verifiable attestation before funding. A separate binding layer independently verifies identifier ownership (e.g., via email OTP or OIDC), so the relay cannot substitute a different recipient without the sender detecting it. The binding is sender-verifiable without a public identifier registry. Full formal treatment is in Sections 2–6 of the paper.
Implementation
We are building an open implementation at hfi.network, including relay infrastructure and ZK claim circuits. Early exploration of relay decentralization is underway. Feedback on the protocol design and trust model is very welcome.
Full paper: arXiv:2603.26970
Happy to discuss the formal security definitions, the binding epoch rotation scheme, or the relationship to other identifier-based payment proposals.