NickPay, an Auditable, Privacy-Preserving, Nickname-Based Payment System

TL;DR

NickPay presents a privacy-preserving yet auditable payment system built on Ethereum, leveraging Nicknames for Group Signatures (NGS) to provide user anonymity while enabling regulator-accessible auditability. By deriving nicknames from master public keys and enforcing group-verification and owner-signature checks, NickPay achieves unlinkable payments across transfers and traceable accountability via a trusted supervisor. The paper details the design, security properties, and a Solidity/Rust-based prototype with on-chain mint/transfer and off-chain tracing, demonstrating the practicality of auditable privacy on public ledgers. This work advances privacy-by-design in blockchain payments and offers a concrete path toward regulation-compliant, auditable distributed payment systems on DLTs.

Abstract

In this paper, we describe the motivation, design, security properties, and a prototype implementation of NickPay, a new privacy-preserving yet auditable payment system built on top of the Ethereum blockchain platform. NickPay offers a strong level of privacy to participants and prevents successive payment transfers from being linked to their actual owners. It is providing the transparency that blockchains ensure and at the same time, preserving the possibility for a trusted authority to access sensitive information, e.g., for audit purposes or compliance with financial regulations. NickPay builds upon the Nicknames for Group Signatures (NGS) scheme, a new signing system based on dynamic ``nicknames'' for signers that extends the schemes of group signatures and signatures with flexible public keys. NGS enables identified group members to expose their flexible public keys, thus allowing direct and natural applications such as auditable private payment systems, NickPay being a blockchain-based prototype of these.

Figures (5)

• Figure 1: Join synchronization process: this sequence diagram illustrates how a user $i$ interacts with the NGS library and the issuer to join (request accepted, in this case) the group.
• Figure 2: Join protocol: the issuer grants the user $i$ an equivalence class by defining $\textbf{mpk}[i] = mpk_i$. On his side, the user $i$ can identify any public key in his equivalence class by using his trapdoor $\tau_i$. Note that $\textbf{mpk}[i]$ is itself in the equivalence class of user $i$, as it is just an arbitrary element inside it.
• Figure 3: Nick protocol: Alice can create, using the $\textit{Nick}$ algorithm on Bob's $mpk$, a new nickname, e.g., $nk_{83}$, for Bob and use it to post some signed message on the blockchain. Bob can then check if he can unlock the last posted message, here addressed to nickname $nk_{83}$, with the $\textit{Trace}$ function.
• Figure 4: Sign protocol: Bob can sign (using a signature $\sigma$) a message $m$ of his choice, proving he controls the nickname $nk_{83}.$ The verifier can then check that this nickname belongs to the group and the validity of $\sigma$.
• Figure 5: Open protocol: The supervisor decrypts users' trapdoors in $\textbf{reg}$ and try each trapdoor $\tau$ to open the nickname $nk$ asked by the auditor.

Theorems & Definitions (4)

• Definition 1: NGS Roles
• Definition 2: NGS Types
• Definition 3: NGS Global Variables
• Definition 4: NGS Scheme