Hamsa Privacy Overview

How Hamsa Privacy Works

Hamsa Privacy is a privacy solution based on Zero-Knowledge Proofs (ZKP), designed for secure execution of Delivery Versus Payment (DVP) transactions on EVM-compatible blockchains, such as Hyperledger Besu.

Its architecture enables financial institutions to perform private DVPs with each other while preserving regulatory auditability and operational independence. The solution is structured around the following pillars:

Dedicated Layer 2 instances for each participating institution

Each participating institution operates its isolated EVM-compatible Layer 2 instance independently and autonomously. These instances can be orchestrated via Kubernetes or Docker Compose, and include the following internal components:

Sequencer – Selects transactions from the instance’s transaction pool.
Block Finalizer – Groups the selected transactions into a block.
Executor – Executes all transactions in the block.
Prover – Generates a Zero-Knowledge Proof (ZKP) that attests to the correct execution and integrity of the block.

Shared Layer 1 for settlement

All institutions interact with a common Layer 1, which is responsible for:

Receiving ZK-Proofs generated by each Layer 2
Verifying the validity of each proof
Finalizing cross-institution transactions
Emitting match events that indicate when a DVP can be completed

Infrastructure Smart Contracts

The solution includes a set of smart contracts that coordinate the interaction between Layer 1 and Layer 2. These contracts enable deposits, withdrawals, custody, and DVP settlement. The key contracts are:

DvpMatch (Layer 1)

Records DVP calls submitted from different Layer 2 instances.
When compatible calls from all DvP participants are received, it emits a match event, signaling that the DVP is ready to be finalized.

L1TMSC (Layer 1)

Manages token balances deposited by institutions in Layer 1.
Supports both ERC-20 and ERC-1155 standards, and updates balances after each DVP is completed.

L1Bridge (Layer 1)

Controls the flow of funds between Layer 1 and Layer 2 (for both deposits and withdrawals).
Notably, the destination account in Layer 2 can be different from the originating account in Layer 1 (and vice versa). The total value deposited by an institution on Layer 1 will always equal the total received in Layer 2.

DvpEscrow (Layer 2)

Temporarily holds funds during DVP execution. Assets remain in custody until the proof is verified and the transaction is finalized on Layer 1.

L2TMSC (Layer 2)

Manages token balances for each institution’s user accounts on Layer 2, supporting both ERC-20 and ERC-1155 tokens.

High-level architecture of the solution

It is illustrated below:

Key Operational Flows

The Hamsa Privacy architecture is based on two primary operational flows:

1.1. Fund deposit flow (Layer 1 → Layer 2)

a) The institution initiates a deposit through L1Bridge, specifying the token type and target Layer 2 address.

b) The funds are locked in Layer 1 and credited to the corresponding Layer 2 instance.

c) The L1TMSC contract updates the institution’s balance, and L2TMSC registers user account funds within the Layer 2 instance.

1.2. DVP flow with ZK registration (Layer 2 → Layer 1)

a) Each institution involved in the DVP submits a call to the DvpEscrow contract on its respective Layer 2 instance.

b) The transaction is registered, and once the block is finalized, the Prover generates a ZK-Proof.

c) The proof and related metadata are submitted to Layer 1 and processed by the DvpMatch contract.

d) When DvpMatch identifies compatible calls from a DvP transaction required parties, it emits an event on Layer 1 signaling that the DVP can be finalized.

e) Finalization occurs on Layer 1, and the institutions transfer funds according to the original instructions issued in Layer 2.

⸻

Conclusion

Hamsa Privacy provides a robust, auditable architecture for executing DVPs between financial institutions in permissioned networks. Its use of Zero-Knowledge Proofs guarantees both privacy and integrity, while maintaining compliance with regulatory requirements.

All transactions are deterministic, verifiable, and designed for compatibility with the technical and governance expectations of financial authorities and central banks.