💻 computer science

HFIPay: Privacy-Preserving, Cross-Chain Cryptocurrency Payments to Human-Friendly Identifiers

HFIPay is a privacy-preserving, non-custodial cross-chain payment protocol that enables transfers to human-friendly identifiers by combining off-chain relay resolution with zero-knowledge proofs to ensure sender-verifiable binding and recipient anonymity without exposing transaction histories.

Original authors: Jian Sheng Wang

Published 2026-03-31

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Jian Sheng Wang

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you want to send a gift to a friend, but instead of giving them a physical address, you just give them their email address. In the world of traditional banking, this is easy: you type "alice@email.com," and the bank knows exactly where to send the money.

But in the world of cryptocurrency, it's currently a nightmare. You have to copy a long, scary string of letters and numbers (like 0x4f3...a9b), make sure you picked the right network, and pay a fee just to send it. If you get it wrong, the money is gone forever.

HFIPay is a new system designed to fix this. It lets you send crypto to an email or phone number just like a bank transfer, but with a superpower: it keeps your financial life completely private.

Here is how it works, explained through a simple story.

The Problem: The "Glass House"

Right now, if you send crypto to a friend using a standard method, you are essentially writing their name on a glass house.

The Naïve Way: If you send money to alice@email.com, the system might turn that email into a public address. Anyone who knows Alice's email can look at the blockchain, see her address, and instantly know: "Oh, Alice has 50 Bitcoin, she bought a car last Tuesday, and she trades with Bob."
The Risk: This is dangerous. If a hacker knows your email, they can stalk your entire financial history.

The Solution: The "Secret Agent" System (HFIPay)

HFIPay introduces a middleman called a Relay (think of them as a highly trained, invisible courier service) and uses some magic math (Zero-Knowledge Proofs) to solve the privacy problem.

Here is the step-by-step process using a "Secret Package" analogy:

1. The Request (You)

You want to send $100 to your friend, Alice, using her email alice@example.com. You don't need to know her crypto address. You just tell the Relay: "Send $100 to Alice."

2. The Relay's Magic Trick (The Blinding)

The Relay knows Alice's secret crypto address, but it doesn't tell you. Instead, it does something clever:

It creates a unique, random box (called an Intent) for this specific transaction. Let's call it "Box #999".
It puts a sealed, opaque sticker on the box. This sticker says, "This box belongs to the person who owns the secret key for Alice's email," but the sticker itself reveals nothing about who Alice is.
The Relay puts this "Box #999" and the sticker on the public blockchain.
Crucial Point: To the rest of the world, "Box #999" looks like random noise. No one can tell it belongs to Alice. Even if they know Alice's email, they can't find her box.

3. The Safety Check (The Verified Quote)

Before you send your money, the Relay gives you a receipt (a "Quote").

In the "Verified" mode, this receipt is a mathematical proof. It proves: "I promise that Box #999 is definitely for Alice, and I haven't swapped her for a fake person."
You check this receipt. If it looks good, you send your $100 into Box #999.
The Relay cannot steal the money. The math proves that only the person who owns the secret key for Alice's email can open this box later.

4. The Claim (Alice Opens the Box)

Alice gets a notification (via email) that a box is waiting for her. She doesn't need to know the box number; her app handles it.

Alice uses her phone to generate a Zero-Knowledge Proof. Think of this as a magic spell that says: "I am the owner of the secret key for Alice's email, and I prove that I can open Box #999."
She shows this spell to the blockchain.
The blockchain checks the spell. It sees: "Yes, this spell matches the sealed sticker on Box #999."
The blockchain releases the $100 to Alice's wallet.

The Magic: Alice proved she owns the box without ever revealing her email address or her secret key to the public blockchain.

Why is this a big deal?

No More "Glass Houses": Before Alice claims the money, no one can link "Box #999" to Alice's email. Even if a hacker knows her email, they can't find her transactions.
No More "Address Copying": You just type an email. No more 0x... strings.
Cross-Chain Magic: The paper mentions this works across different blockchains (like sending Bitcoin to an Ethereum wallet). The Relay handles the complex switching, but the privacy rules stay the same.
The Relay Can't Steal: In the old days, if you used a "Send to Email" service, they held your money and could run away with it. In HFIPay, the Relay is just a messenger. Once the box is sealed on the blockchain, only Alice can open it. The Relay cannot redirect the funds to themselves.

The "Trust" Balance

The paper distinguishes between two ways to use this:

Basic Mode: You trust the Relay to tell the truth about who Alice is.
Verified Mode: The Relay gives you a mathematical receipt that proves they aren't lying. You don't have to trust them; you just have to trust the math.

Summary

HFIPay is like sending a letter via a secure, anonymous courier.

Old Way: You write the recipient's name on the outside of the envelope. Everyone sees it.
HFIPay: You give the courier the name. The courier puts the letter in a locked, unmarked box and puts it on a public shelf. The box has a unique serial number.
Only the person with the secret key (Alice) can prove to the shelf-keeper that the box is hers and open it.
The rest of the world sees a bunch of random boxes on a shelf, with no idea who they belong to.

It makes crypto as easy to use as email, but keeps your financial secrets safe from prying eyes.

1. Problem Statement

The adoption of cryptocurrency is hindered by poor user experience (UX), specifically the requirement for users to manage opaque hexadecimal addresses, select correct networks, and hold native tokens for gas fees. While "human-friendly identifiers" (emails, phone numbers, social handles) offer a solution, naïve implementations that map these identifiers directly to blockchain addresses (e.g., address = Hash(email)) create critical privacy vulnerabilities:

Lack of Enumeration Resistance: Any third party knowing a user's identifier can derive their on-chain address and inspect their entire transaction history, balances, and counterparty relationships.
Lack of Unlinkability: Multiple payments to the same identifier using a deterministic mapping create a reusable public tag, allowing observers to link all transactions to a single user.
Trust vs. Privacy Trade-off: Existing "send to email" solutions often rely on centralized custodians, which introduces counterparty risk and lacks on-chain verifiability.

2. Methodology: The HFIPay Protocol

HFIPay proposes a relay-assisted, non-custodial architecture that decouples identifier routing, recipient binding, sender verification, and claim authorization. It relies on three core components: ZK-ACE (Zero-Knowledge Authorization for Chain Execution) for claim proofs, Va-Dar for private identity recovery, and a Relay Service for off-chain resolution.

Core Mechanism

The protocol operates in five phases:

Recipient Setup & Binding:
- The recipient generates a deterministic identity root ($REVB$) and derives an identity commitment ($IDcomB$).
- They derive a binding handle ( $u_{B,e}$ ) and a binding-key commitment ( $K_{B,e}$ ) for a specific time epoch ( $e$ ).
- A private directory (Relay) maps the normalized identifier (e.g., email) to these commitments. In the Verified-Quote mode, a Binding Layer issues an attestation ( $\tau_B$ ) proving the link between the identifier and $K_{B,e}$ .
Quote Generation & Intent Creation:
- The sender requests a payment to an identifier.
- The Relay generates a random intentId and a one-time deposit address ( $\alpha$ ).
- The Relay computes a blinded binding ( $\rho_i$ ) using a hash of the recipient's hidden handle and the intentId: $\rho_i = H("hfipay:bind" \parallel u_{B,e} \parallel intentId)$ .
- Verified-Quote Mode: The Relay provides a sender-verifiable off-chain proof ( $\pi_{quote}$ ) linking $\rho_i$ to the attested $K_{B,e}$ . This allows the sender to verify that the blinded binding corresponds to the intended recipient before sending funds, preventing recipient substitution.
Funding:
- The sender verifies the quote (in verified mode) and the on-chain intent registration.
- The sender transfers assets to the deterministic address $\alpha$ . The on-chain contract stores the tuple $(\rho_i, asset, amount, epoch)$ .
Claim Authorization (Zero-Knowledge):
- The recipient retrieves the intentId and epoch.
- Using their private identity root, they re-derive the handle $u_{B,e}$ and generate a ZK-ACE proof ( $\pi_i$ ).
- The proof demonstrates:
  - Possession of the identity root corresponding to $IDcomB$.
  - That $u_{B,e}$ generates the specific blinded binding $\rho_i$ stored on-chain.
  - Authorization to release funds to a chosen destination $\beta$ .
- The on-chain contract verifies the proof and releases funds. The relay never sees the private key or the full identity root.
Cross-Chain Settlement (n-Vm):
- By integrating with an n-Vm runtime (a unified identity layer across multiple VMs), the same claim mechanism allows funds to be deposited on Chain A and claimed on Chain B. The claim proof authorizes the release of wrapped assets on the destination chain without needing a separate bridge trust model for the recipient.

Privacy Goals

Enumeration Resistance: Observers cannot link an on-chain intent to a specific email/phone number without compromising the private relay directory.
Pre-Claim Unlinkability: Multiple payments to the same user appear as unrelated, random intents on-chain because they use unique intentIds and blinded bindings.
Post-Claim Linkability: Linkability only occurs after a claim if the recipient reuses the same public destination address or identity commitment.

3. Key Contributions

Protocol Design: A novel architecture separating off-chain identifier resolution from on-chain claim authorization, utilizing blinded bindings and sender-verifiable quotes to prevent relay manipulation.
Authorization Composition: Integration of ZK-ACE for recipient-side claim authorization and Va-Dar for private, cross-device identity recovery without a public registry.
Formal Privacy Analysis: Formal definitions and proofs for Enumeration Resistance and Pre-Claim Unlinkability, demonstrating that on-chain data reveals no information about the recipient's identity or the link between multiple intents.
Trust Model Differentiation:
- Baseline Mode: Relay is trusted for correct binding.
- Verified-Quote Mode: Sender verifies the binding via off-chain proofs, removing the relay's ability to substitute the recipient before funding.
Cross-Chain Extension: A mechanism to extend identifier-based payments across different blockchains (e.g., BTC to ETH) using a unified identity layer (n-Vm) without compromising the privacy model.

4. Results and Analysis

Privacy: The system successfully hides the link between human identifiers and on-chain transactions. An observer with knowledge of an email address cannot determine which on-chain intents belong to that email, nor can they link two separate pre-claim intents to the same user.
Security: The protocol is resistant to recipient substitution attacks in the Verified-Quote mode. Once a sender verifies the quote and funds the intent, the relay cannot redirect funds to a different address without breaking the cryptographic binding or the ZK proof system.
Threat Model: The system assumes the relay's private directory could be compromised. In such a scenario, the adversary could reconstruct the email-to-intent graph. However, the protocol mitigates this by:
- Rotating binding epochs.
- Ensuring the relay cannot unilaterally redirect funds after on-chain commitment.
- Relying on ZK-proofs for the final claim, meaning a compromised relay cannot claim funds on behalf of the user without the user's private identity root.
Implementation: The paper outlines feasible implementations on EVM (using CREATE2 for deterministic addresses) and Solana (using Program Derived Addresses), showing compatibility with standard chain capabilities.

5. Significance

HFIPay represents a significant step toward making cryptocurrency accessible to non-technical users while maintaining strong privacy guarantees.

UX Revolution: It enables "Send to Email" functionality that feels like a traditional bank transfer, removing the need for users to manage addresses or gas tokens.
Privacy Preservation: Unlike ENS (which is public) or naïve hash-mappings, HFIPay ensures that knowing a user's identifier does not compromise their financial privacy.
Non-Custodial Trust: It bridges the gap between centralized "send-to-email" apps (which are custodial) and decentralized DeFi. By moving the authorization check to on-chain zero-knowledge proofs, it minimizes the relay's power, ensuring that even if the relay is malicious, it cannot steal funds once the intent is funded.
Cross-Chain Interoperability: It provides a privacy-preserving framework for cross-chain payments, solving a major fragmentation issue in the crypto ecosystem without relying on opaque bridges.

In summary, HFIPay offers a robust, privacy-preserving routing layer that decouples human identity from blockchain activity, enabling secure, user-friendly, and cross-chain cryptocurrency payments.