Source-linked AI summary
Relaxed Sender Anonymity for CBDC Interbank Settlement: A Zero-Knowledge Approach on Permissioned EVM
Pietro Tiberi, Gabriele Marcelli, Vitangelo Lasorella
TL;DR
DLT transparency exposes commercially sensitive bilateral CBDC settlement flows, creating a need to verify transfers without revealing receivers or amounts. The paper proposes a relaxed-sender-anonymity protocol with zero-knowledge proofs and on-chain encrypted note custody, and reports practical proof-of-concept settlement while identifying transparent-boundary value-binding limitations.
Problem
DLT settlement transparency reveals bilateral transaction information, although regulated institutions require verification with receiver and amount confidentiality.
Method
The protocol combines relaxed sender anonymity, Groth16 proofs, Poseidon commitments in an incremental Merkle tree, multi-recipient encryption, and an on-chain NoteRegistry.
Results
The proof-of-concept establishes protocol-level receiver confidentiality and demonstrates confidential settlement using the proposed cryptographic and ledger components.
Takeaways & Limitations
Sender accountability is retained while encrypted notes can be distributed from the ledger without a trusted custody intermediary.
Takeaways & Limitations
The transparent shield and unshield boundaries do not bind token amounts to proofs, allowing confidential value creation or over-withdrawal within the vault balance.
Abstract
from arXiv · showhide
Central Bank Digital Currency (CBDC) interbank settlement systems operating on Distributed Ledger Technology (DLT) face a fundamental trade-off: blockchain transparency enables trustless verification but exposes commercially sensitive bilateral transaction flows to all network participants. We propose a confidential interbank settlement protocol for permissioned Ethereum-compatible networks that resolves this tension through a relaxed sender anonymity model tailored to regulatory AML/CFT requirements. In this model, the initiating institution remains publicly identifiable on-chain for accountability and compliance, while the receiving institution, transfer amount, and business payload are cryptographically obfuscated. We realize the protocol on Hyperledger Besu using QBFT consensus, combining Groth16 zero-knowledge proofs over BN254, Poseidon hash commitments in an incremental Merkle tree, multi-recipient ECIES payload encryption, and an on-chain NoteRegistry contract that stores encrypted notes as an append-only ledger log, eliminating trusted off-chain custody servers. The protocol supports shield, confidential transfer, and unshield state transitions. Experimental evaluation across a five-node network (three commercial banks, a central bank operator, and a securities depository) demonstrates end-to-end settlement in 8-16 s, proof verification overhead of about 1 ms (around 220k gas) via EVM precompiles, and client proof generation in 4-12 s on commodity ARM hardware. While receiver confidentiality is established at the protocol level, the current proof-of-concept NoteRegistry uses owner-indexed events, a trade-off addressable in production via uniform event broadcasting.
I. INTRODUCTION
The paper addresses the conflict between DLT transparency and bilateral confidentiality in regulated interbank settlement. It proposes relaxed sender anonymity and a confidential protocol using zero-knowledge proofs and on-chain encrypted note handling.
- Standard token transfers expose sender, receiver, and amount, revealing commercially sensitive liquidity positions, trading strategies, and client relationships.
- Zero-knowledge proofs verify authorization, non-creation of value, and non-double-spending without revealing receiver identity or transfer amount.
- Relaxed sender anonymity keeps the initiating institution publicly identifiable while hiding receiver identity and amount from third parties.
- The protocol comprises shield, confidential transfer, and unshield operations implemented as EVM-compatible contracts on Hyperledger Besu.
- The NoteRegistry stores encrypted note secrets on-chain without recipient identifiers, while multi-recipient encryption supports central-bank auditing and bilateral confidentiality.
- The construction builds on Zerocash, Tornado Cash, and Aztec while targeting permissioned interbank settlement and addressing on-chain note custody.
C. Permissioned EVM and Hyperledger Besu
The system uses permissioned Ethereum infrastructure and circuit-oriented cryptographic primitives to support regulated confidential settlement. Its participant model assigns distinct operational and supervisory roles across banks, the central bank, the CSD, and validators.
- Hyperledger Besu supports QBFT deterministic finality and deploys standard Solidity contracts, including snarkjs-generated Groth16 verifiers, without modification.
- Groth16 produces succinct three-group-element proofs verified with three pairings, but requires a circuit-specific trusted setup.
- Poseidon is designed for prime-field arithmetic circuits and requires approximately 220 constraints per hash call.
- ECIES provides public-key encryption for single-recipient note encryption and multi-recipient disclosure key wrapping.
- Participants: The central bank issues and revokes tokens and holds an audit key, while banks use Ethereum signing keys and independent ECIES key pairs.
- Participants: The CSD participates as a regular member, and consortium-operated QBFT validators see on-chain data without being assumed to collude with banks.
B. Threat Model
The threat model distinguishes confidentiality against honest-but-curious network participants from integrity against malicious provers. Relaxed sender anonymity exposes sender accountability while protecting receiver and amount confidentiality under stated assumptions.
- Threat assumptions: The adversary is honest-but-curious, may include validators, and attempts to infer confidential information from traffic and on-chain data.
- Excluded attacks: The analysis excludes compromised private keys, network-layer timing and traffic analysis, and trusted-setup subversion.
- Security properties: Integrity against malicious provers covers double-spend prevention, confidential-transfer value conservation, and sender accountability through Groth16 knowledge soundness.
- Relaxed Sender Anonymity: Relaxed sender anonymity makes the sender publicly identifiable while rendering receiver identity and amount computationally indistinguishable from random to unauthorized observers.
- Relaxed Sender Anonymity: The model supports AML/CFT accountability, protects commercial relationships, and permits supervisory access through a central-bank audit key.
- Note model: Notes use value, spending and viewing keys, a unique nonce, and a blinding factor; commitments are public while nullifiers appear only upon spending.
IV. SYSTEM ARCHITECTURE
The architecture separates bank-side cryptographic processing from on-chain settlement state and verification. Four contracts provide transparent token custody, confidential state management, encrypted note storage, and proof verification.
- Off-chain layer: The off-chain ZK Service generates notes, reconstructs Merkle trees, creates proofs, and performs ECIES encryption and decryption.
- On-chain layer: The on-chain Besu layer stores Merkle trees, nullifiers, and encrypted notes, verifies proofs, and holds ERC-20 tokens.
- Contracts: EuroToken provides the transparent ERC-20 settlement layer with ECB-only minting and burning and participant registration.
- Contracts: ConfidentialEuroToken maintains the Poseidon Merkle tree, nullifier set, recent roots, and atomic calls to verification and note storage.
- Contracts: NoteRegistry stores ECIES ciphertexts in an append-only list without owner indexing, allowing recipients to recover notes by trial decryption.
- Contracts: Groth16Verifier is generated by snarkjs and uses BN254 EVM precompiles for proof verification.
C. The NoteRegistry Pattern
The NoteRegistry stores encrypted note secrets on-chain without recipient indexing, allowing banks to recover notes independently while preserving receiver confidentiality in the target design. Confidential transfers combine encrypted note delivery, zero-knowledge verification, and multi-recipient payload encryption.
- Prior note-transmission approaches rely on encrypted memos, off-chain channels, or custody servers, adding trust assumptions or infrastructure.
- The NoteRegistry uses one append-only list of ECIES ciphertexts without owner indexing, preventing ledger metadata from revealing recipients.
- Banks recover notes by scanning appended blobs, trial-decrypting them, and validating openings against commitments in the Merkle tree.Scanning is linear in network-wide appended notes and was sub-second at the reported volumes.
- The target confidential-transfer design verifies only root, nullifier, output commitment, and sender address publicly, while hiding value, receiver identity, and nonce.The current implementation still passes the recipient explicitly, so this describes the specified target design.
- Confidential transfers encrypt output notes for the receiver and publish payload ciphertext through an on-chain event.The transfer also verifies the proof, updates the nullifier set and Merkle tree, and stores the encrypted output note.
C. Unshield: ZK Note to Transparent Token
Unshield converts a zero-knowledge note back into transparent EuroToken while preserving value through proof verification and vault transfer. The payload-encryption design binds authorized disclosures to the verified output commitment.
- Unshield scans and decrypts the NoteRegistry, reconstructs the Merkle tree, proves note ownership, and transfers v EuroToken to the bank.
- The dummy output commitment is required because the circuit enforces vin = vout, but it is not inserted into the Merkle tree.The note value returns to the transparent layer rather than being stored as a new output note.
- Each confidential transfer publishes a multi-recipient encrypted payload whose authenticated data includes the destination commitment cmout.
- Authorized readers accept the payload only when its decrypted note opening recomputes to cmout, binding encryption to the verified transfer.
- Only Bank i, Bank j, and the central bank receive wrapped keys, while other participants cannot recover the symmetric payload key.The ciphertext uses 256-bit symmetric security.
VI. ZK CIRCUIT DESIGN
The circuit enforces note validity, ownership, nullifier correctness, output commitment correctness, and value conservation using Poseidon hashing and Merkle proofs. Its fixed public-input interface keeps verification cost independent of internal circuit size.
- A. Constraint System: The ConfidentialTransfer circuit enforces five constraint classes: key derivation, input commitment validity, nullifier correctness, output commitment correctness, and value conservation.
- A. Constraint System: The circuit has 11,003 wires and exposes [root, nfpub, cmpub, addrsender] as public inputs.The sender address ensures only the note owner can initiate the transfer.
- A. Constraint System: Groth16 verification depends only on the number of public inputs, making on-chain verification insensitive to the circuit’s internal size.
- B. Poseidon Zeros: The empty depth-8 Merkle tree is initialized with Poseidon-iterated zero values, whose constants are hardcoded in both circuit and contract.
- C. Incremental Merkle Tree: Incremental insertion requires exactly d = 8 Poseidon hashes, while a 30-root rolling window keeps concurrently generated proofs valid after intervening insertions.
VII. IMPLEMENTATION AND EVALUATION
The permissioned Besu proof of concept demonstrates practical settlement timing and low verification overhead on commodity ARM infrastructure. Software proof generation dominates latency, while the target de-indexed registry introduces linear scanning.
- VII. Implementation: The proof of concept runs four Hyperledger Besu QBFT validator nodes in Docker on an Ampere Altra ARM instance with 4 OCPUs and 24 GB RAM.
- VII. Implementation: Three Next.js portals and a separate Node.js ZK service provide participant interfaces and handle proof generation and cryptographic operations.
- B. On-Chain Gas Costs: ≈220k gas is required for Groth16 verification, while zero base fee makes gas cost non-barrier in the permissioned setting.
- C. Proof Generation Performance: 8 s, 16 s, and 16 s are the end-to-end times for shield, confidentialTransfer, and unshield on the PoC hardware.ZK proof generation remains the dominant cost.
- C. Proof Generation Performance: The de-indexed registry would require trial decryption linear in the network-wide note count, unlike the owner-keyed registry measured in the current implementation.
D. NoteRegistry Storage Overhead
The NoteRegistry stores encrypted notes on-chain while concealing recipient identity, and its storage footprint is small enough for the evaluated enterprise workload.
- ≈60 KB/day: projected note-storage growth for 10 banks executing 100 confidential transfers daily with tree depth d = 32.Each encrypted note blob is approximately 600 bytes, and one storeNote call costs ≈45,000 gas.
- The specified design stores encrypted note blobs without recipient identifiers, preserving receiver confidentiality while allowing note recovery from ledger data.The note commitment and nullifier support confidential value handling, while the encrypted blob carries the note secret.
- Sender accountability is retained because the sender address is checked against msg.sender and tied to the spender’s secret key.A bank cannot generate a valid proof claiming a different sender without knowledge of that sender’s derived spending key.
E. Soundness
Groth16 soundness protects confidential transfers against false proofs and supports value conservation, but the current transparent boundaries and prototype implementation leave important production gaps.
- Groth16 knowledge soundness prevents spending absent or unauthorized notes and prevents altering confidential transfer values.The proof enforces commitment-tree inclusion, nullifier correctness, and the value constraint v = v′.
- The current circuit transfers the full input value, so partial transfers require a two-output circuit with a change note returned to the sender.This standard UTXO extension would approximately double the constraint count.
- The prototype tree depth d = 8 supports only 256 commitments, while d = 32 raises insertion and circuit costs without changing proof size or verification cost.The Merkle inclusion sub-circuit grows linearly with tree depth.
- The shield and unshield boundaries do not prove that deposited or withdrawn amounts equal the confidential values, leaving value conservation dependent on the permissioning model.Production remedies include exposing v for unshield and proving the commitment opening or using homomorphic commitments for shield.
- The current NoteRegistry implementation uses owner-indexed storage and events, so receiver confidentiality is not achieved despite the protocol specification.De-indexing is required to restore the specified receiver-confidentiality property.
E. Trusted Setup
The prototype relies on centralized services and setup choices that must be decentralized or hardened for production, while the broader protocol remains practically feasible on commodity hardware.
- A single contributor generated the Groth16 proving key, whereas production requires a multi-party ceremony to avoid single-party trust.The paper compares this requirement with the Zcash Powers of Tau ceremony.
- The current audit model requires transaction-by-transaction decryption, while viewing keys could enable efficient batch scanning.This is identified as a production improvement for supervisory auditing.
- Traffic analysis may reveal information through timing, ciphertext sizes, and block cooccurrence, motivating delays, dummy transactions, and padding.These mitigations are standard countermeasures identified for future deployment.
- The prototype’s shared ZK service holds all participant key material, but production requires isolated per-bank services.The NoteRegistry is intended to let banks recover note secrets from the chain without cross-service communication.
- 4–12 s: software proof generation is the primary prototype bottleneck, but the deployment demonstrates practical feasibility on commodity hardware.The paper identifies hardware acceleration as a route to lower end-to-end latency.
- Future work includes partial-transfer circuits, multi-party setup, efficient viewing keys, and cross-network interoperability.These extensions define the main path from prototype toward broader production capability.