NickHat: Anonymous Token Transfer

• NickHat is a permissioned token-exchange system that uses Nicknames for Group Signatures to support recipient-specific anonymity with auditability.
• It employs type-3 pairing groups, Fiat–Shamir SPKs, and flexible public keys to ensure secure, traceable, and unlinkable cryptographic operations.
• The prototype integrates on-chain smart contracts with off-chain cryptographic proofs to manage registration, deposit/transfer, and audit functions efficiently.

Searching arXiv for the NickHat/NGS paper and closely related work. NickHat is a permissioned, Ethereum-based token-exchange prototype that implements Nicknames for Group Signatures (NGS), a signature framework extending classical Group Signatures (GS) with Signatures with Flexible Public Keys (SFPK). Its defining objective is to support anonymous yet auditable token transfers: anyone can derive a recipient-specific nickname from a registered member’s master public key, the nickname hides the recipient’s identity from the public and from other users, only the intended recipient and the designated opener can link that nickname to the member, and an external auditor can verify a proof of correct opening without collapsing the general anonymity of the system (Quispe et al., 4 Aug 2025).

1. Conceptual basis in Nicknames for Group Signatures

NGS combines two primitives with distinct roles. Via GS, each member of a group can sign messages on behalf of the group without revealing his identity, except to a designated auditor. Via SFPK, public keys are partitioned into equivalence classes induced by a relation $\mathcal{R}$, so that anyone can transform a public key into another representative of the same class without the private key. NickHat instantiates this composition as a token-exchange system in which a recipient is addressed not by a stable public identifier but by a publicly derivable nickname that remains auditable (Quispe et al., 4 Aug 2025).

The formal equivalence relation used for nicknames is defined over triples in $\mathbb{G}_1^3$, with $l=3$ and $G=\mathbb{G}_1$ a cyclic group of prime order $p$:

$$\mathcal{R}=\{(pk_1,pk_2)\in(\mathbb{G}_1^*)^2\mid\exists s\in\mathbb{Z}_p^*,~pk_1=pk_2^s\},$$

where exponentiation on tuples is element-wise. If $\mathbf{mpk}$ is a user’s master public key, then a nickname is generated by exponentiating the entire tuple:

$nk=\mathbf{mpk}^r,$

for random $r\in\mathbb{Z}_p$. In the concrete construction this becomes

$Nick(mpk,r)\to nk=(u^r,v^r,w^r).$

This design separates addressing from public identity. The issuer publishes master public keys $\mathbb{G}_1^3$0 and users’ DS public keys $\mathbb{G}_1^3$1, while registration information $\mathbb{G}_1^3$2 includes an encrypted trapdoor. The intended recipient can use the trapdoor to test whether a nickname belongs to his equivalence class, and the opener can recover the same relation from the registration record. A plausible implication is that NickHat is best understood not as a generic anonymous payment mechanism, but as a selective-deanonymization system whose privacy model is anchored in recipient-only tracing and externally verifiable opening.

2. Cryptographic construction and protocol logic

The NGS construction underlying NickHat is built in type-3 pairing groups $\mathbb{G}_1^3$3 with generators $\mathbb{G}_1^3$4 and $\mathbb{G}_1^3$5. The issuer generates

$\mathbb{G}_1^3$6

and the opener generates

$\mathbb{G}_1^3$7

Users generate DS keys via $\mathbb{G}_1^3$8 (Quispe et al., 4 Aug 2025).

Registration proceeds through the Join/Iss interaction. On the user side, $\mathbb{G}_1^3$9~\mathbb{Z}p^2l=3l=30f=g^\alphal=3l=31u=H(f)l=3l=32w=u^\alphal=3l=33\tau=\hat{g}^\alphal=3l=34l=3l=35l=3l=36$l=3$7l=3l=38l=3l=39G=G1G=\mathbb{G}_10fG=G1G=\mathbb{G}_11\pi_JG=G1G=\mathbb{G}_12\sigma{DS}$G=\mathbb{G}_1$3v=u^x\cdot w^yG=G1G=\mathbb{G}_14G=G1G=\mathbb{G}_15G=G1G=\mathbb{G}_16mG=G1G=\mathbb{G}_17G=G1G=\mathbb{G}_18G=G1G=\mathbb{G}_19\mathrm{UVf}pp0(u,w)pp1mpp2\sigma%%%%4G=G1G=\mathbb{G}_14pp4%%%%5\mathrm{GVf}pp6\mathrm{UVf}pp7w=u^\alpha.</sup></sup></p><p>Recipient−onlytracingusesthetrapdoor:</p><p>.</sup></sup></p> <p>Recipient-only tracing uses the trapdoor:</p> <p>p$8

Opening uses the encrypted registration data. The opener decrypts

$p$9

checks

$\mathcal{R}=\{(pk_1,pk_2)\in(\mathbb{G}_1^*)^2\mid\exists s\in\mathbb{Z}_p^*,~pk_1=pk_2^s\},$0

and produces

$\mathcal{R}=\{(pk_1,pk_2)\in(\mathbb{G}_1^*)^2\mid\exists s\in\mathbb{Z}_p^*,~pk_1=pk_2^s\},$1

with $\mathcal{R}=\{(pk_1,pk_2)\in(\mathbb{G}_1^*)^2\mid\exists s\in\mathbb{Z}_p^*,~pk_1=pk_2^s\},$2. The judge then verifies $\mathcal{R}=\{(pk_1,pk_2)\in(\mathbb{G}_1^*)^2\mid\exists s\in\mathbb{Z}_p^*,~pk_1=pk_2^s\},$3, the DS signature on $\mathcal{R}=\{(pk_1,pk_2)\in(\mathbb{G}_1^*)^2\mid\exists s\in\mathbb{Z}_p^*,~pk_1=pk_2^s\},$4 under $\mathcal{R}=\{(pk_1,pk_2)\in(\mathbb{G}_1^*)^2\mid\exists s\in\mathbb{Z}_p^*,~pk_1=pk_2^s\},$5, and $\mathcal{R}=\{(pk_1,pk_2)\in(\mathbb{G}_1^*)^2\mid\exists s\in\mathbb{Z}_p^*,~pk_1=pk_2^s\},$6.

Fiat–Shamir is used to turn the underlying $\mathcal{R}=\{(pk_1,pk_2)\in(\mathbb{G}_1^*)^2\mid\exists s\in\mathbb{Z}_p^*,~pk_1=pk_2^s\},$7-protocols into non-interactive SPKs by setting

$\mathcal{R}=\{(pk_1,pk_2)\in(\mathbb{G}_1^*)^2\mid\exists s\in\mathbb{Z}_p^*,~pk_1=pk_2^s\},$8

This places the entire system in the Random Oracle Model and explains the paper’s emphasis on SPK soundness and zero-knowledge as primary proof obligations.

3. Ethereum architecture and transaction workflow

NickHat distributes functionality between on-chain contracts and off-chain cryptographic operations. The Verifier contract performs on-chain pairing checks for $\mathcal{R}=\{(pk_1,pk_2)\in(\mathbb{G}_1^*)^2\mid\exists s\in\mathbb{Z}_p^*,~pk_1=pk_2^s\},$9 and SPK verification for $\mathbf{mpk}$0, using Ethereum’s BN254 pairing precompile. The Key-Registry contract publishes and stores master public keys. The NickHat contract manages escrow and balances for private nicknames through deposit, transfer, and withdraw, and emits Announcement events containing nicknames. The Forwarder contract, implemented as an ERC-2771 forwarder, accepts meta-transactions from relayers, verifies NGS signatures via the Verifier, and forwards valid requests to NickHat (Quispe et al., 4 Aug 2025).

Component	Role	Named functions or checks
Verifier	On-chain verification	GVf(ipk,nk), UVf(nk,m,σ)
Key-Registry	Publication of registered keys	Insert(mpk)
NickHat	Escrow and balance bookkeeping	deposit, transfer, withdraw
Forwarder	Meta-transaction execution	execute(metaTx)

The operational workflow is sequential. In setup, the operator deploys Verifier, Key-Registry, NickHat, and Forwarder, and the issuer and supervisor publish $\mathbf{mpk}$1 and $\mathbf{mpk}$2. In registration, the user and issuer execute Join/Iss, the issuer stores $\mathbf{mpk}$3, and publishes $\mathbf{mpk}$4 via Insert. In deposit, a sender reads $\mathbf{mpk}$5 from Key-Registry, computes $\mathbf{mpk}$$6, and calls <code>deposit(nk, token, v)</code> after approving the NickHat contract to transfer ERC20 tokens. NickHat escrows the tokens under the nickname and emits <code>Announcement(nk)</code>.</p> <p>Detection is off-chain. Members monitor <code>Announcement</code> events, and the intended recipient tests the nickname with <code>Trace(ipk,\tau_j,nk)</code>. Transfer from one private nickname to another is also meta-transactional: the sender derives a new recipient nickname$$\mathbf{mpk}$7, prepares a request $\mathbf{mpk}$8, signs $\mathbf{mpk}$9 with

$nk=\mathbf{mpk}^r,$0

and a relayer submits the request to Forwarder.execute(ρ,σ). The Verifier checks $nk=\mathbf{mpk}^r,$1 and the pairing equation

$nk=\mathbf{mpk}^r,$2

after which NickHat updates the balance mapping and emits a new Announcement. Withdrawal replaces the destination nickname with a transparent address $nk=\mathbf{mpk}^r,$3, but the authorization path is the same: the owner signs $nk=\mathbf{mpk}^r,$4, the relayer submits the request, the Verifier checks the SPK, and NickHat transfers ERC20 tokens to $nk=\mathbf{mpk}^r,$5.

Audit is off-chain but publicly checkable. The supervisor takes a nickname, runs Open(osk,nk), decrypts $nk=\mathbf{mpk}^r,$6 from the registration record, constructs $nk=\mathbf{mpk}^r,$7, and returns $nk=\mathbf{mpk}^r,$8. The external auditor runs Judge(nk,i,ipk,Π) and accepts iff $nk=\mathbf{mpk}^r,$9, $r\in\mathbb{Z}_p$0, and $r\in\mathbb{Z}_p$1 all verify. This architecture preserves on-chain enforceability of membership and authorization while keeping identity recovery under a separate auditing interface.

4. Security model and formal guarantees

The security model extends GS experiments with NGS-specific nicknames and oracle access. Correctness is defined by the experiment

$r\in\mathbb{Z}_p$$2</p> <p>which requires that <code>Open</code> returns the correct member, <code>GVf</code> and <code>UVf</code> accept, <code>Judge(i,\Pi)</code> accepts, and <code>Trace(ipk,\tau,nk)</code> holds. This is a strong end-to-end notion because it jointly constrains signing, tracing, opening, and audit verification rather than treating them as separate interfaces (<a href="/papers/2508.02543" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">Quispe et al., 4 Aug 2025</a>).</p> <p>Traceability addresses forged nicknames or signatures that verify but cannot be opened correctly. The adversary has access to <code>AddU</code>, <code>CrptU</code>, <code>SndToI</code>, <code>USK</code>, <code>RReg</code>, and <code>osk</code>; the issuer remains honest. The stated theorem gives traceability in the Random Oracle Model under the Modified <a href="https://www.emergentmind.com/topics/geometrical-pareto-selection-gps" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">GPS</a> assumption and simulation soundness of$$r\in\mathbb{Z}_p$3. Non-frameability, also called exculpability, treats the stronger case in which the adversary controls issuer and opener and still must not be able to frame an honest user; the theorem relies on EUF-CMA of DS, SDL, and simulation soundness of $r\in\mathbb{Z}_p$4 in the Random Oracle Model.

Optimal opening soundness requires that no adversary can produce a nickname together with two distinct openings both accepted by the judge. Opening coherence is a new property: even if the opener is malicious, a nickname that an honest user can trace must not also be openable to a different user with a judge-accepted proof. Both are proved from simulation soundness assumptions on $r\in\mathbb{Z}_p$5 and $r\in\mathbb{Z}_p$6.

Anonymity is defined through a challenge oracle and restricted access to Trace, Sig, and user secrets. The advantage is

$r\in\mathbb{Z}_p$7

The theorem establishes anonymity in the Random Oracle Model under SXDH, zero-knowledge of SPKs, and non-frameability. Taken together, these properties show that NickHat does not treat privacy as a by-product of opaque addresses alone; it is formally tied to group membership verification, trapdoor-based ownership testing, and judge-verifiable selective opening.

5. Implementation profile and measured costs

The implementation uses the BN254 pairing curve and Ethereum’s pairing precompile, with the NGS core implemented in Rust. The hash function $r\in\mathbb{Z}_p$8 maps $r\in\mathbb{Z}_p$9 elements to $Nick(mpk,r)\to nk=(u^r,v^r,w^r).$0 and is modeled as a random oracle in the proofs. Off-chain sender work per transfer consists of nickname randomization, requiring 3 exponentiations in $Nick(mpk,r)\to nk=(u^r,v^r,w^r).$1, together with the SPK signature, requiring 1 exponentiation in $Nick(mpk,r)\to nk=(u^r,v^r,w^r).$2, for a total of approximately 4 exponentiations in $Nick(mpk,r)\to nk=(u^r,v^r,w^r).$3 (Quispe et al., 4 Aug 2025).

On-chain verification is dominated by pairing-based checks. Group verification requires 3 pairings, while user verification of the SPK requires 2 exponentiations in $Nick(mpk,r)\to nk=(u^r,v^r,w^r).$4. The paper also notes a batching optimization: a small exponent test can reduce many $Nick(mpk,r)\to nk=(u^r,v^r,w^r).$5 checks to 3 pairings for $Nick(mpk,r)\to nk=(u^r,v^r,w^r).$6 nicknames. This suggests that the principal performance pressure lies in repeated membership verification rather than in nickname derivation itself.

Operation	Gas
Insert mpk	39,230
Deposit	263,610
Transfer	292,480
Approve (DVP-related)	86,450
Lock (DVP-related)	248,980
Claim (DVP-related)	369,830
Refund (DVP-related)	308,570

These measurements place the on-chain cost primarily in escrow mutation and verification rather than registration. The appendix characterizes the listed ETH/USD costs as reasonable overheads relative to token values; this suggests that the prototype is intended as a practical proof of deployability rather than as a minimal-gas construction.

6. Position within anonymous-signature systems, limitations, and scope

Relative to standard GS, NickHat inherits anonymous group signing with an opener but adds flexible public keys, public nickname derivation, a public master-key registry, and the Trace and Nick functions. Relative to linkable GS, NGS aims for unlinkability across nicknames except for self-trace and opening, and no public linkability tags are emitted. Relative to prior SFPK, the construction adds an issuer-managed group, an opener and judge, and binding to registered identities via DS signatures and proofs. The specific novelty claimed for NickHat is recipient-specific nicknames derived publicly while only the intended recipient and opener can trace $Nick(mpk,r)\to nk=(u^r,v^r,w^r).$7 to the user, together with auditable anonymity implemented on Ethereum through ERC20 transfers, pairing verification, off-chain opening proofs, and Announcement-based detection (Quispe et al., 4 Aug 2025).

Several limitations are explicit. Security is proved in the Random Oracle Model via Fiat–Shamir. Trust in the supervisor and auditor remains part of the system assumption, and decentralization or threshold opening is identified as future work. Revocation is not included, with Libert–Peters–Yung-style revocation suggested as a future direction. Stronger anonymity against malformed nicknames such as $Nick(mpk,r)\to nk=(u^r,v^r,w^r).$8 could be obtained by adding randomization proofs to $Nick(mpk,r)\to nk=(u^r,v^r,w^r).$9. Current opening scans the registration table linearly, and more efficient identification is left open.

A common misconception is to treat NickHat itself as the cryptographic primitive. More precisely, NGS is the signature scheme and security framework, while NickHat is the blockchain-based prototype system built on top of it. Another common misconception is to equate NickHat with a public-linkability mechanism; in fact, its model is the opposite: unlinkability across nicknames is preserved except for recipient self-tracing and supervisor-mediated opening. This places NickHat in the narrower design space of auditable anonymity rather than generic anonymous transfer.