Balancing Privacy and Compliance in DeFi: A Zero-Knowledge-Based Auditable Cross-Chain Framework

Balancing Privacy and Compliance in DeFi: A Zero-Knowledge-Based Auditable Cross-Chain Framework Li Huihenga,∗ , Feng Kainuob , Ding Jiahaob and Ma Ziqic a Department of Computer Science, University of Warwick, Coventry, CV4 7AL, UK b School of Public Finance and Taxation, Guangdong University of Finance and Economics, Guangzhou, China c Department of Philosophy, University College London, London, WC1E 6BT, UK

ABSTRACT

Keywords: Privacy Protection Regulatory Technology Cross-Chain Transaction Decentralized Finance Zero Knowledge Proof

With the rise of decentralized finance (DeFi), cross-chain transactions, transfers of assets across different blockchain networks, face a fundamental conflict between user privacy and regulatory compliance. Unlike single-chain systems, cross-chain environments must balance privacy and auditability across heterogeneous architectures. Existing solutions, from transparent ledgers to anonymous cryptocurrencies, fail to reconcile these two requirements, hindering regulatory adoption. This research proposes an auditable cross-chain framework that integrates three building blocks. First, zero-knowledge proofs (ZKPs) verify transaction compliance (e.g., amount non-negativity, signature validity) without revealing transaction details. Second, a lightclient mechanism enables trust-minimized cross-chain verification without relying on third-party relayers. Third, a threshold view-key mechanism based on distributed key generation (DKG) ensures that audit access is granted only to authorized entities under legal triggers such as the FATF Travel Rule and MiCA Regulation. For cross-border investigations, the framework adheres to national laws and the EU Directive on Mutual Legal Assistance. This work systematically combines ZKPs, threshold cryptography, and light-client verification into an auditable, privacypreserving cross-chain protocol. It contributes to Regulatory Technology (RegTech) and provides a viable path toward compliant, interoperable decentralized finance.

arXiv:2608.15276v1 [cs.CR] 15 Aug 2026

ARTICLE INFO

1. Introduction

Decentralized Finance (DeFi) and cross-chain transactions have experienced exponential growth over the past five years, the collective market capitalization of cryptocurrencies peaked at $2 trillion in April 2021 [1]. This expansion has fundamentally transformed financial infrastructure, enabling permissionless trading, lending, and asset transfers across blockchain networks. However, this growth has simultaneously created an acute conflict between two seemingly incompatible objectives: protecting user privacy and satisfying increasingly stringent regulatory requirements [2]. Traditional financial systems address this tension through centralized intermediaries that enforce know-your-customer (KYC) protocols and maintain audit trails. In contrast, decentralized systems must achieve regulatory compliance without sacrificing the privacy guarantees that users expect from blockchain technology. Current blockchain solutions represent two extremes [3]. Bitcoin and similar public ledgers prioritize transparency, recording all transactions on an immutable ledger accessible to any observer, a design that facilitates regulatory auditing but exposes sensitive financial information. Conversely, privacy-centric protocols such as Monero and Zcash employ advanced cryptographic techniques to shield transaction details, achieving strong privacy guarantees but rendering regulatory oversight nearly impossible. Neither approach provides a satisfactory middle ground: transparent systems leak private information, while privacy-preserving systems cannot selectively disclose transaction data when legally required. This incompatibility has hindered mainstream regulatory adoption of DeFi and cross-chain technologies, as financial authorities refuse to permit systems operating beyond their visibility. Recent academic work has explored the application of zero-knowledge (ZK) proofs to cross-chain protocols and privacy-preserving finance. However, existing research predominantly focuses on technical feasibility and performance optimization, overlooking a critical practical requirement: auditability under legal mandate. The literature lacks ∗ Corresponding author

Huiheng.Li@warwick.ac.uk (L. Huiheng); fkn0530@student.gdufe.edu.cn (F. Kainuo); 19252060028@student.gdufe.edu.cn (D. Jiahao); zctymad@ucl.ac.uk (M. Ziqi) ORCID (s): 0009-0004-3644-0451 (L. Huiheng); 0009-0005-7591-2463 (F. Kainuo); 0009-0005-1822-7662 (D. Jiahao); 0009-0002-8715-5576 (M. Ziqi)

Li et al.: Preprint submitted to Elsevier

Page 1 of 18

Balancing Privacy and Compliance

systematic frameworks that enable regulators to access encrypted transaction data only when presented with proper legal authorization (such as court orders or regulatory subpoenas), while maintaining strong privacy protections during normal operation [4]. This gap between academic theory and regulatory reality prevents the deployment of privacy-preserving DeFi systems in jurisdictions with active financial supervision. To bridge this gap, we propose a framework that combines three building blocks. First, we adopt light-clientbased cross-chain verification to achieve trust-minimized transaction validation, the target chain verifies source chain transactions via Merkle proofs without trusting any intermediary. Second, we integrate ZKPs to ensure transaction compliance (e.g., amount non-negativity, signature validity) without revealing transaction details. Third, we introduce a threshold view-key mechanism based on Shamir’s Secret Sharing, which splits the audit decryption key among 𝑛 regulators so that any 𝑡 of them can collaboratively decrypt the audit information only when the legal conditions are met. This design ensures that during normal operation, transaction privacy is fully preserved; under lawful authorization, regulators can access only the minimum necessary audit information. Our principal contributions are: 1. Unified Regulatory-Compliant Cross-Chain Architecture. We present an end-to-end system design that integrates zero-knowledge proofs (for privacy-preserving compliance verification), light-client verification (for trust-minimized cross-chain message passing), and threshold cryptography (for controlled audit access) into a single coherent framework. Unlike prior work that treats these components in isolation, our architecture jointly addresses privacy, auditability, and trust minimization as first-class design goals. 2. Practical Auditable Cross-Chain Workflow. We design and specify the full transaction lifecycle—from onchain ZK proof verification and encrypted audit tag generation on the source chain, through light-client-based cross-chain asset release, to threshold-secured regulatory decryption under legal trigger conditions (FATF Travel Rule, MiCA Regulation, mutual legal assistance treaties). The encrypted audit label scheme stores only the minimum necessary information required by regulators, ensuring that authorized access reveals precisely what is legally mandated and nothing more. 3. Prototype Implementation and Experimental Evaluation. We implement the core components of the framework (Groth16 ZK circuits in Circom/snarkjs, light-client Solidity contracts on the Ethereum Sepolia testnet, and a Python-based threshold decryption simulator) and conduct a comprehensive performance evaluation. Experimental results show that our framework introduces approximately 170 ms of additional latency and 70k Gas overhead per cross-chain transaction—figures comparable to standard ERC-20 token transfers and acceptable for real-world DeFi applications. The remainder of this paper is organized as follows: Section 2 reviews the related works. Section 3 presents the preliminaries and problem formalization. Section 4 details the system architecture and protocol design. Section 5 evaluates security properties. Section 6 assesses the experimental feasibility and performance. Section 7 discusses the current limitations. Section 8 concludes the research and proposes future research directions.

2. Related Works Prior research relevant to our work spans three active areas: cross-chain communication protocols, privacy-preserving mechanisms for blockchain transactions, and regulatory compliance technologies. We review each in turn and identify where existing solutions partially address—but do not fully reconcile—the tension between privacy and auditability.

2.1. Cross-Chain Communication Trustless cross-chain communication has been extensively studied, with solutions differing primarily in their trust assumptions [5]. At one end of the spectrum, relay- and oracle-based architectures achieve inter-chain message passing by relying on a network of third-party validators or oracle nodes. While these designs offer high throughput and ease of deployment, their security guarantees are conditional on the assumption that relay nodes do not collude maliciously [2]. At the other end, light-client-based protocols aim for trust minimization by verifying cross-chain events directly against the source chain’s consensus—typically through Merkle proofs validated against synchronized block headers. The Inter-Blockchain Communication (IBC) protocol exemplifies this approach, enabling cross-chain verification via on-chain light clients without centralized intermediaries [6]. Separately, the Axelar network employs threshold ECDSA signatures and validator voting to secure cross-chain asset transfers [7]. These protocols each address important dimensions of the cross-chain problem: IBC demonstrably reduces trust assumptions, while Axelar provides a practical generalized message-passing infrastructure. However, they were designed Li et al.: Preprint submitted to Elsevier

Page 2 of 18

Balancing Privacy and Compliance

with a focus on security and liveness, and neither incorporates privacy-preserving audit mechanisms as a first-class design goal. Axelar’s transparent ledger exposes full cross-chain interaction data to all observers; IBC inherits the privacy properties (or lack thereof) of the underlying chains and offers no built-in selective disclosure capabilities. This leaves a gap between cross-chain interoperability and the privacy requirements of regulated financial applications.

2.2. Privacy-Preserving Blockchain Transactions Zero-knowledge proofs (ZKPs) have been applied to blockchain privacy across two complementary directions. On the scalability side, zkRollups aggregate off-chain transaction batches and submit a single succinct validity proof to the base layer, achieving throughput improvements while preserving some degree of input privacy [8]. On the confidentiality side, protocols such as Zerocash employ zk-SNARKs to shield transaction amounts, sender, and recipient addresses, providing strong anonymity guarantees. These techniques have also been extended to cross-chain settings, where ZKPs can verify that a source-chain event occurred without revealing transaction details. Notwithstanding these advances, existing ZKP-based privacy solutions face a common limitation when deployed in regulated environments. zkRollups protect individual transaction inputs but leave aggregate patterns (e.g., trading volumes, fee structures) amenable to statistical analysis. Fully shielded protocols such as Zerocash provide cryptographicgrade anonymity that inherently conflicts with Anti-Money Laundering (AML) and Know-Your-Customer (KYC) obligations [9]. In both cases, the protocol lacks a mechanism for selective, legally authorized disclosure: either too much information is visible, or none at all. This binary trade-off has limited the adoption of ZKP-based privacy techniques in compliance-sensitive cross-chain applications.

2.3. Regulatory Compliance and Auditing On the regulatory side, the FATF’s revised guidance for Virtual Asset Service Providers (VASPs) mandates that customer identity information accompany fund transfers—the so-called Travel Rule [10]. Traditional blockchain analytics platforms, such as those developed by Chainalysis, address this need by constructing complete transaction graphs through address clustering and heuristic labeling to identify suspicious flows [11]. These tools have proven effective for post-hoc forensic investigation and risk scoring. Nevertheless, current compliance tools exhibit two structural tensions with privacy-preserving architectures. First, their effectiveness depends on access to unencrypted, complete transaction data, which is fundamentally incompatible with shielded or zero-knowledge-based transaction designs. Second, their centralized data collection model introduces a single point of information aggregation, creating risks of mass data leakage and unauthorized surveillance. Recent work has begun to explore privacy-preserving audit mechanisms, including encrypted audit receipts verified via ZKPs [3]; however, these proposals typically focus on single-chain settings and do not address the additional complexities of cross-chain environments, where audit information must traverse heterogeneous consensus domains and trust boundaries.

2.4. Research Gap and Motivation In summary, existing work has achieved significant progress within each of the three areas reviewed above: crosschain communication (trust-minimized verification), privacy-preserving finance (ZKPs for transaction confidentiality), and regulatory technology (blockchain analytics and compliance frameworks). However, these solutions generally operate in isolation—they address at most one or two of the three properties simultaneously. To the best of our knowledge, no existing framework jointly provides: (i) trust-minimized cross-chain verification, (ii) cryptographic transaction privacy via zero-knowledge proofs, and (iii) controllable auditability via threshold-secured selective disclosure. This paper proposes an integrated architecture that systematically combines these three building blocks, addressing a concrete gap between the technical capabilities of decentralized finance and the operational requirements of regulated financial supervision.

3. Preliminaries and Problem Formalization 3.1. Cryptographic Preliminaries 3.1.1. Zero-Knowledge Proofs Zero-Knowledge Proofs (ZKP) is a type of cryptographic protocol that allows prover to demonstrate the truth of a statement to a verifier without revealing any additional information. Formally, a ZKP scheme consists of three algorithm groups: • Setup(1𝜆 ) → 𝑝𝑝: Generate public parameters. Li et al.: Preprint submitted to Elsevier

Page 3 of 18

Balancing Privacy and Compliance

• Prove(𝑝𝑝, 𝑥, 𝑤) → 𝜋: Input a public statement 𝑥 and a private witness 𝑤, and generate proof 𝜋. • Verify(𝑝𝑝, 𝑥, 𝜋) → {0, 1}: Verify if 𝜋 is valid. ZKP has the following characteristics: • Completeness: If 𝑤 is correct, the validation passes. • Reliability: If 𝑤 is incorrect, the probability of validation failure is negligible. • Zero-knowledge: The validator cannot obtain any information about 𝑤 from 𝜋. This research adopts the Groth16 scheme. Users use ZKP to prove transaction compliance (such as a positive amount and a valid signature) without exposing specific transaction details.

3.1.2. Threshold Secret Sharing Threshold secret sharing schemes allow a secret 𝑠 to be split into 𝑛 fragments 𝑠1 , ..., 𝑠𝑛 , such that any 𝑡 fragments can be used to recover 𝑠, while any 𝑡 − 1 fragments cannot be used to obtain any information. For share generation stage, given a secret 𝑠, threshold 𝑡, and number of participants 𝑛, the dealer randomly generates ∑ 𝑗 a polynomial 𝑓 (𝑥) = 𝑠 + 𝑡−1 𝑗=1 𝑎𝑗 𝑥 of degree 𝑡 − 1. Each participant 𝑖 receives a fragment 𝑠𝑖 = 𝑓 (𝑖). For reconstruction, given any 𝑡 fragments (𝑖, 𝑠𝑖 )𝑡𝑖=1 , the secret is recovered via Lagrange interpolation: 𝑠=

𝑡 ∑ ∏ −𝑗 . ⋅ 𝑖−𝑗 𝑖=1 𝑗≠𝑖

(1)

This scheme ensures information-theoretic security: fewer than 𝑡 fragments provide zero information about 𝑠 . Our framework employs Shamir’s Secret Sharing as the underlying primitive for threshold key management.

3.1.3. Light Client and State Proofs Lightweight clients verify the existence of transactions using Merkle proofs without downloading the complete blockchain. Specifically: a) Each block header contains either a 𝑠𝑡𝑎𝑡𝑒𝑟𝑜𝑜𝑡 or a 𝑡𝑥𝑟𝑜𝑜𝑡 (the Merkle root of the transaction tree). b) A transaction 𝑡𝑥 and its position 𝑝𝑜𝑠 can be proven to belong to a block via the path 𝑝𝑎𝑡ℎ: MerkleVerify(txroot , tx, path, pos) → {0, 1}.

(2)

3.2. System Model The system consists of the following entities: • User: The individual or institution initiating the cross-chain transaction. The user holds a source chain account 𝑎𝑑𝑑𝑟𝑠 and a target chain account 𝑎𝑑𝑑𝑟𝑡 , and generates a ZK proof for the transaction. • Source Chain 𝐶𝑠 : The blockchain on which the user initiates the transaction. An audit contract 𝐴𝑢𝑑𝑖𝑡𝐶𝑜𝑛𝑡𝑟𝑎𝑐𝑡 is deployed on it, responsible for verifying the ZK proof and storing the cryptographic audit tag. • Target Chain 𝐶𝑡 : The blockchain receiving the asset. A light client contract 𝐿𝑖𝑔ℎ𝑡𝐶𝑙𝑖𝑒𝑛𝑡 (continuously verifies the source chain block header) and an execution contract 𝐸𝑥𝑒𝑐𝐶𝑜𝑛𝑡𝑟𝑎𝑐𝑡 (responsible for releasing the asset) are deployed on it. • Regulatory Set 𝑅 = 𝑅1 , ..., 𝑅𝑛 : A group of regulatory bodies that jointly hold the threshold view key. Any 𝑡 regulators can collaborate to decrypt audit information. • Relayer (Optional): Submits the source chain’s block header and Merkle proof to the target chain. In a trustless design, anyone can play this role, by participating through Gas incentives.

Li et al.: Preprint submitted to Elsevier

Page 4 of 18

Balancing Privacy and Compliance

3.3. Threat Model and Assumptions 3.3.1. Trust Assumptions In this work, we require specific trust assumptions: a) the consensus mechanism of the underlying blockchain is secure, meaning that confirmed blocks cannot be tampered with. b) Cryptographic primitives (including hash functions, elliptic curves, and ZKP) are computationally secure, without considering extreme cases of potential breaches or undiscovered vulnerabilities. c) The DKG protocol execution involves an honest majority of regulators (i.e., fewer than 𝑡 malicious participants), which is the standard security assumption for threshold cryptography. d) Regulatory nodes strictly adhere to threshold decryption protocols and related decryption procedures, the decryption communications are neither monitored nor tampered with, and that decrypted keys exist only on temporary storage devices and are promptly destroyed after the compliance process is completed. Under the current assumptions, this work aims to prevent the following threats: a) users attempting to submit illegitimate transactions or bypassing audit tag generation. b) External attackers attempting to infer transaction details from publicly available on-chain data (ZK proofs, cryptographic tags, etc.). c) A single regulator attempting to decrypt audit information without authorization, or a total of no more than 𝑡 regulators colluding. This work does not prevent more than 𝑡 regulators maliciously colluding to decrypt audit information without authorization, the breach of the underlying chain consensus, or the leakage of user private keys or supervisory private keys.

3.3.2. Adversary Model We formalize the capabilities and limitations of a probabilistic polynomial-time (PPT) adversary  against our framework: Capabilities. The adversary  can: 1. Observe all on-chain data, including ZK proofs 𝜋, encrypted audit tags 𝐶, block headers, and smart contract state on both the source and target chains. 2. Corrupt up to 𝑡 − 1 regulators, obtaining their key fragments 𝑠𝑘𝑖 and observing all their internal states and communications. 3. Interact with the protocol as a user, submitting arbitrary transactions to the source chain and relay requests to the target chain. 4. Act as a network-level adversary, eavesdropping, delaying, or dropping messages exchanged between honest regulators. Limitations. The adversary  cannot: 1. Break the computational soundness of the ZK proof system (Groth16). 2. Break the semantic security of the ECIES encryption scheme (i.e., cannot solve DDH). 3. Break the collision resistance of the underlying hash function. 4. Compromise the consensus security of the underlying blockchain (i.e., cannot forge or revert confirmed blocks). 5. Corrupt 𝑡 or more regulators simultaneously. This adversary model is standard for threshold-cryptographic systems and captures a powerful but computationally bounded attacker who may control a minority of regulators but cannot subvert the core cryptographic assumptions.

3.3.3. Security Goals Under the adversary model defined in subsubsection 3.3.2, our protocol Π aims to satisfy the following three security goals: Goal 1 (Transaction Privacy). For any two transactions tx0 , tx1 that satisfy the same compliance predicate 𝑃 , the adversary  cannot distinguish which transaction was executed based on the protocol’s public output. Formally: (3)

| Pr[(𝜋(tx0 ), 𝐶0 ) = 1] − Pr[(𝜋(tx1 ), 𝐶1 ) = 1]| ≤ 𝗇𝖾𝗀𝗅(𝜆), where 𝜋(tx) is the ZK proof and 𝐶 = 𝖤𝗇𝖼𝑝𝑘𝑅 (𝑀𝑚𝑖𝑛 (tx)) is the encrypted audit tag. Goal 2 (Controlled Auditability). The audit information 𝑀𝑚𝑖𝑛 (tx) can be recovered if and only if : 1. The legal trigger condition 𝐶 is met (e.g., judicial warrant, regulatory investigation per Table 3); AND 2. At least 𝑡 distinct regulators each compute a valid partial decryption share 𝑑𝑖 = 𝖣𝖾𝖼𝖲𝗁𝖺𝗋𝖾(𝑠𝑘𝑖 , 𝐶). Li et al.: Preprint submitted to Elsevier

Page 5 of 18

Balancing Privacy and Compliance Table 1 STRIDE Threat Analysis of the Proposed Framework STRIDE Category

Threat Scenario

Defense Mechanism

Spoofing (S)

Adversaries forge cross-chain transactions or impersonate legitimate users/relayers to submit invalid proofs.

Tampering (T)

Man-in-the-middle attacks altering transaction details or adversaries modifying encrypted audit labels on-chain.

Repudiation (R)

A user denies initiating a cross-chain transaction, or a regulator denies participating in a decryption process.

Information Disclosure (I)

External adversaries inferring transaction details from on-chain data, or fewer than t regulators colluding to decrypt audit information.

Denial of Service (D)

Targeted DDoS attacks on the network infrastructure of regulatory nodes, or prolonged offline status of regulators, preventing the assembly of t decryption shares.

Elevation of Privilege (E)

A standard user attempting to gain regulatory decryption privileges to access audit information.

Digital signatures verified within the ZK circuit ensure transaction origin authenticity. Light client contracts verify Merkle proofs to guarantee the validity of cross-chain messages. ZKP binding ensures proof integrity. The collision resistance of cryptographic hashes and encryption schemes protects audit labels from undetected modification. Non-interactive ZKPs with digital signatures provide user non-repudiation; the (t, n)threshold decryption protocol requires t regulators to provide verifiable key fragments, ensuring operational non-repudiation. ZKP’s zero-knowledge property hides transaction details from the public; the (𝑡, 𝑛)threshold scheme combined with ECIES encryption ensures that fewer than 𝑡 shares reveal negligible information. Audit unavailability is an accepted architectural trade-off: the (𝑡, 𝑛)-threshold scheme intentionally prevents unilateral decryption, meaning that if ≥ 𝑛 − 𝑡 + 1 regulators are incapacitated, audit liveness is sacrificed to preserve privacy. Inherently prevented. The mathematical structure of (t, n)-threshold cryptography ensures that users without a valid key share cannot escalate privileges through computation.

Any coalition of fewer than 𝑡 regulators (even if all are corrupted by ) obtains negligible information about 𝑀𝑚𝑖𝑛 (tx). Goal 3 (Collusion Resistance). A coalition of up to 𝑡 − 1 corrupted regulators cannot recover the audit plaintext 𝑀𝑚𝑖𝑛 (tx), even if they pool all their key fragments 𝑠𝑘𝑖 and all publicly available on-chain data. This follows directly from the information-theoretic security of Shamir’s Secret Sharing.

3.3.4. Threat Model Analysis To systematically identify the security boundaries and potential attack vectors of our architecture, we employ the STRIDE threat modeling framework. Table 1 maps each threat category to specific cross-chain audit scenarios and our corresponding defense mechanisms. As shown in Table 1, our framework inherently mitigates Spoofing, Tampering, Repudiation, and Elevation of Privilege through cryptographic assumptions, while specifically addressing Information Disclosure and balancing Denial of Service risks via the (t, n)-threshold scheme. To rigorously specify the security guarantees against the identified threats (particularly I and R), we formalize the adversary model and security goals in subsubsection 3.3.2–3.3.3 and provide formal security definitions in subsection 3.4. 3.3.5. KGC Compromise Analysis While our framework assumes a trusted initialization phase, we acknowledge that the KGC remains a single point of trust. To bound the damage of KGC compromise, we adopt a key erasure assumption: after distributing fragments to the 𝑛 regulators, the KGC permanently deletes all key material. A post-distribution compromise of the KGC therefore yields no useful information. Furthermore, even if an adversary compromises the KGC during initialization, they only Li et al.: Preprint submitted to Elsevier

Page 6 of 18

Balancing Privacy and Compliance Table 2 Minimum Auditing Necessary Information Info Type

Specific fields

Element Name

Transaction core identifier1

Transaction hash

txHashs

Time information2

Asset Information3

4

Trading direction

Account ID5

Compliance metadata

Transaction initiation timestamp

timestampi

Transaction confirmation timestamp

timestampc

Asset types (e.g., BTC, ETH) Amount

asset amount

Source VASP Name

VASPs

Source address Terminal VASP Name Terminal addree

addrs VASPt addrt

Source VASP Internal Account ID

internalIDs

Terminal VASP Internal Account ID

internalIDt

Travel rule information delivery status6 Suspicious Transaction Report number

status

Transit VASP name Transit address

Technical path7

STRid VASPtransit addrtransit

Legal basis FATF R.16 / MiCA § [12] 6AMLD / AML laws in various countries [13] [14]

FATF R.15-16 [15] [12] FATF R.16 (2021 Revised Guidelines) [12] MiCA §63 (5) AML Enforcement Rules in various countries [16]

FATF R.16 technical compliance [12] 6AMLD §25 [13] FATF Virtual Asset Guidance [17]

obtain the encrypted audit tag 𝐶 = 𝖤𝗇𝖼𝑝𝑘𝑅 (𝑀), which remain computationally secure under the DDH assumption. The adversary cannot decrypt historical transactions without also compromising ≥ 𝑡 regulators. This provides a graceful degradation of privacy: KGC compromise alone reveals no plaintext audit information.

3.4. Problem Formalisation 3.4.1. Definition of Cross-Chain Transaction A cross-chain transaction can be represented as a tuple: tx = (txHashs , timestampi , timestampc , asset, amount, VASPs , addrs , internalIDs , VASPt , addrt , internalIDt , status, STRid, VASPtransit , addrtransit ), in Table 2. The work focuses on compliance-sensitive transactions, which are the types of transactions that regulators need to audit under specific conditions.

3.4.2. Definition of Security Properties Building on the adversary model  and security goals formalized in subsubsection 3.3.2–3.3.3, we now present the formal security definitions that our protocol Π must satisfy. 1 Used for on-chain verification and tracking 2 Judging the timeliness of transactions 3 Assess risk level

4 Determine the responsible party

5 Anonymous identifiers are mapped to users only when required by law (and can be linked to KYC) 6 Verify compliance collaboration between VASPs 7 Used for tracing complex transaction chains

Li et al.: Preprint submitted to Elsevier

Page 7 of 18

Balancing Privacy and Compliance

Definition 1 (Transaction Privacy). Let  be any PPT adversary as defined in subsubsection 3.3.2. For any two transactions tx0 , tx1 that satisfy the same compliance predicate 𝑃 , the protocol’s public output (𝜋, 𝐶) must be computationally indistinguishable: (4)

| Pr[(𝜋0 , 𝐶0 ) = 1] − Pr[(𝜋1 , 𝐶1 ) = 1]| ≤ 𝗇𝖾𝗀𝗅(𝜆),

where 𝜋𝑏 = Π.𝖯𝗋𝗈𝗏𝖾(𝑝𝑝, 𝑥𝑏 , 𝑤𝑏 ) is the ZK proof, 𝐶𝑏 = 𝖤𝗇𝖼𝑝𝑘𝑅 (𝑀𝑚𝑖𝑛 (tx𝑏 )) is the encrypted audit tag, and 𝗇𝖾𝗀𝗅(𝜆) is a negligible function in the security parameter 𝜆. This definition captures the requirement that the adversary learns nothing beyond the fact that a compliant transaction occurred. Definition 2 (Controllable Auditability). For any transaction tx, let 𝑀𝑚𝑖𝑛 (tx) be its minimum audit information set. The protocol must satisfy: 1. Authorized Recovery: If the legal trigger condition 𝐶 (per Table 3) is satisfied and at least 𝑡 regulators each provide a valid partial decryption share 𝑑𝑖 = 𝖣𝖾𝖼𝖲𝗁𝖺𝗋𝖾(𝑠𝑘𝑖 , 𝐶), then 𝑀𝑚𝑖𝑛 (tx) is recovered: (5)

𝖢𝗈𝗆𝖻𝗂𝗇𝖾(𝑑1 , … , 𝑑𝑡 ) → 𝑀𝑚𝑖𝑛 (tx).

2. Unauthorized Secrecy: For any coalition  ⊂ {𝑅1 , … , 𝑅𝑛 } with || < 𝑡, even if all members of  are corrupted by , the advantage in recovering any information about 𝑀𝑚𝑖𝑛 (tx) is negligible in the security parameter 𝜆. Definition 3 (Trust-Minimized Cross-Chain Verification). The target chain 𝐶𝑡 verifies the inclusion of a source-chain transaction tx in block 𝐵 using only: 1. The block header 𝐻𝐵 of 𝐵 (validated against the consensus of 𝐶𝑠 ); 2. A Merkle proof 𝜋𝑀 proving that tx is included in 𝐻𝐵 .𝗍𝗑𝖱𝗈𝗈𝗍. The verification 𝖬𝖾𝗋𝗄𝗅𝖾𝖵𝖾𝗋𝗂𝖿 𝗒(𝐻𝐵 .𝗍𝗑𝖱𝗈𝗈𝗍, tx, 𝜋𝑀 , pos) relies on no trusted third party and no economic collateral; its correctness follows solely from the collision resistance of the underlying Merkle tree hash function.

3.4.3. Compliance Predicates and Audit Information Definitions The compliance predicate 𝑃 (tx) represents the legal conditions that a transaction must meet, including but not limited to a non-negative transaction amount, a valid transaction signature, and a transaction amount not exceeding the anti-money laundering threshold (which triggers requiring regulatory audit). The Minimum Auditing Necessary Information set 𝑀𝑚𝑖𝑛 (tx) is defined as: 𝑀𝑚𝑖𝑛 (tx) = {txHashs , timestampi , timestampc , asset, amount, ...}.

(6)

See Table 2 for specific fields. This set represents the minimum necessary information required for regulatory audits and complies with requirements such as the FATF Travel Rules.

3.4.4. Core Problem Statement In summary, the core problem addressed in this paper is to design a cross-chain transaction protocol such that: 1. Compliance can be publicly verified via ZK proofs, while transaction details remain private. 2. The Minimum Auditing Necessary Information of a transaction is recorded on-chain in encrypted form, decryptable only by a set of regulatory entities that meet legal triggering conditions. 3. The cross-chain verification process is fully trustless, and implemented using light -client state proofs.

4. System Architecture and Protocol Design 4.1. Overall Architecture Our work proposes a privacy-protected and auditable cross-chain transaction architecture.

Li et al.: Preprint submitted to Elsevier

Page 8 of 18

Balancing Privacy and Compliance

Figure 1: Transaction and Audit Workflow As Figure 1 shows, the system consists of three layers: • User Layer: The transaction initiator, responsible for constructing the transaction, generating zero-knowledge proofs, and cryptographic audit tags. • On-Chain Contract Layer: Includes the audit contract deployed on the source chain (verifying proofs and storing audit tags), the light client contract (verifying cross-chain messages), and the execution contract (releasing assets) deployed on the target chain. • Regulatory Layer: Composed of 𝑛 regulatory bodies, holding the critical (𝑡, 𝑛)-threshold decryption private key, collaborating only to decrypt audit information when legal triggering conditions are met. Its core workflow is as follows: 1. A user initiates a transaction on the source chain, locks assets, and generates a ZK proof and a cryptographic audit tag off-chain. 2. The user submits the proof and tag to the source chain audit contract. The contract verifies the validity of the proof and stores the tag. 3. The target chain’s light client verifies the existence of the transaction on the source chain using a Merkle proof. 4. Upon successful verification, the target chain executes the contract to release assets of equivalent value. 5. When legal triggering conditions are met, regulators collaborate to decrypt the audit tag and obtain compliance audit information.

4.2. Transaction Generation Process (Source Chain) ZK circuit framework employs zero-knowledge proofs to ensure transaction compliance without exposing transaction details. We design a ZK circuit , whose inputs include: Private Inputs (Known by the prover, not publicly disclosed): Sender’s private key signature, transaction amount, recipient’s address. Public Inputs (Stored on-chain): Transaction hash commitment, compliance predicate output value. The circuit verifies the following assertion: • Signature Validity: The transaction is signed by a legitimate sender. • Amount Validity: The transaction amount is non-negative and does not exceed the account balance. • Compliance Mark: When the transaction amount exceeds a threshold, it is marked as Audit Required. • Hash Consistency: Public transaction commitments match private inputs. Li et al.: Preprint submitted to Elsevier

Page 9 of 18

Balancing Privacy and Compliance

If all assertions are true, the circuit outputs 𝜋 = Prove(𝑝𝑝, 𝑥, 𝑤) ∈ {0, 1}, where 𝑥 is the public input and 𝑤 is the private witness. This paper uses the Groth16 proof system for its small proof size and fast verification. To support controlled auditing, each transaction must generate an encrypted audit tag 𝖳𝖺𝗀. Its plaintext contains the minimum audit information set 𝑀 as defined in Equation (6). The specific fields comply with FATF travel rules. The user encrypts 𝑀 using the regulatory public key 𝑝𝑘𝑅 : 𝐶 = 𝖤𝗇𝖼𝑝𝑘𝑅 (𝑀).

(7)

The encryption algorithm uses Elliptic Curve Integration Encryption (ECIES), outputting ciphertext 𝐶. The final audit tag structure is as follows: 1 2 3 4 5 6 7

struct AuditTag { bytes ciphertext; bytes32 txHash; bytes32 zkProofHash; uint8 threshold; bytes32[] regulatorIds; } The user submits the ZK proof 𝜋 and the audit tag 𝖳𝖺𝗀 to the source chain audit contract 𝖠𝗎𝖽𝗂𝗍𝖢𝗈𝗇𝗍𝗋𝖺𝖼𝗍. Contract execution: 1. Verify 𝖵𝖾𝗋𝗂𝖿 𝗒(𝑝𝑝, 𝑥, 𝜋), rolling back if it fails. 2. If verification passes, store 𝖳𝖺𝗀 in the on-chain state. 3. Trigger the event 𝖠𝗎𝖽𝗂𝗍𝖳𝖺𝗀𝖲𝗍𝗈𝗋𝖾𝖽(𝖳𝖺𝗀.𝗍𝗑𝖧𝖺𝗌𝗁) for the target chain to listen for. This design ensures that only compliant transactions are recorded on the chain, and that audit information is permanently stored in encrypted form.

4.3. Cross-Chain Verification Phase (Light Client) To maintain block header synchronization, the target chain deploys a light client contract, 𝖫𝗂𝗀𝗁𝗍𝖢𝗅𝗂𝖾𝗇𝗍, from the source chain to continuously synchronize the source chain’s block headers. The light client verifies the validity of the PoW/PoS consensus for each block header and maintains a verifiable block header. This mechanism does not require trust in any third-party relay. Once a user’s transaction tx on the source chain is confirmed, anyone (the relayer) can submit a verification request to the target chain, including the block header 𝐻 of the transaction, the Merkle path path of the transaction in the block, and the transaction index pos. Light client contract verification: a) Whether 𝐻 is already in the synchronized block header chain. b) Whether 𝖬𝖾𝗋𝗄𝗅𝖾𝖵𝖾𝗋𝗂𝖿 𝗒(H.txRoot, tx, path, pos) is true. If the verification passes, it proves that the tx indeed exists on the source chain. After successful verification, the light client contract invokes the execution contract 𝖤𝗑𝖾𝖼𝖢𝗈𝗇𝗍𝗋𝖺𝖼𝗍, releasing equivalent assets to the user’s address on the target chain. Simultaneously, the audit tag 𝖳𝖺𝗀 is copied to the target chain’s storage, ensuring that audit information remains attached regardless of which chain the transaction flows to. Data Availability and Relay Incentives. Light-client verification introduces a data availability requirement: block headers and Merkle proofs must be explicitly submitted by a relayer for the target chain to verify a cross-chain transaction. This differs from relay-chain architectures (e.g., Feng et al. [3]), which maintain continuous data feeds but require trust in the relay network. Our framework mitigates the data availability issue through an economic incentive mechanism: any user or third party can serve as a relayer and receive gas compensation from the execution contract upon successful proof submission. As long as the cross-chain transaction value exceeds the gas cost of proof submission, rational relayers are incentivized to act. This preserves the trust-minimization property of light-client verification without sacrificing liveness in practice.

4.4. Controllable Audit Designs (Regulatory Layer) 4.4.1. Distributed Key Generation The work assumes a regulatory set  = {𝑅1 , 𝑅2 , ..., 𝑅𝑛 }, consisting of the following regulatory bodies: Financial Intelligence Unit (FIU), Financial Supervisory Authority (FSA), Industry Self-Regulatory Organization (ISRO), Li et al.: Preprint submitted to Elsevier

Page 10 of 18

Balancing Privacy and Compliance Table 3 Triggering Scenarios Scenario

Main Responsible Bodies

Triggering Conditions

Information Scope

Regulatory proactive investigation FSA Review

FIU

STR triggers

FSA

VASP Internal Risk Alert

VASP Compliance Department Foreign regulatory agencies

Regular compliance inspections or spot checks VASP proactively reports suspicious behavior. Foreign regulatory agencies through mutual legal assistance Criminal investigation (with a judicial warrant)

Minimal audit information (excluding user identity) Minimal audit information + VASP compliance record Transaction metadata + VASP information Minimum necessary information + legal basis statement Minimal audit information + user identity information

Cross-border collaboration request Law enforcement agencies require

Police/Prosecutor’s Office

Foreign Regulatory Agencies (through mutual legal assistance treaties/ memoranda) and Judicial Department (including Police and Prosecutors Offices, involving criminal offenses). To eliminate the trusted initialization assumption, we replace the centralized KGC with a DKG protocol among the 𝑛 regulators. Specifically, we adopt the Pedersen DKG protocol, which allows the regulators to jointly generate a public key 𝑝𝑘𝑅 and secret shares 𝑠𝑘1 , ..., 𝑠𝑘𝑛 without any party ever learning the full private key 𝑠𝑘𝑅 . The DKG is executed once during system initialization; no further interaction among regulators is required for key management thereafter. The protocol proceeds as follows: 1. Each regulator 𝑅𝑖 broadcasts a commitment to a random polynomial 𝑓𝑖 (𝑥) of degree 𝑡 − 1. 2. After all commitments are received, each 𝑅𝑖 sends a share 𝑓𝑖 (𝑗) to every other 𝑅𝑗 . 3. Each 𝑅𝑗 verifies received shares against the broadcast commitments. ∏ ∑ 4. The final public key is 𝑝𝑘𝑅 = 𝑖 𝑔 𝑓𝑖 (0) , and regulator 𝑅𝑗 ’s secret share is 𝑠𝑘𝑗 = 𝑖 𝑓𝑖 (𝑗). This DKG protocol ensures that no single entity ever possesses the full decryption key, eliminating the KGC as a single point of trust. The security of this protocol holds under the Discrete Logarithm assumption, with up to 𝑡 − 1 malicious regulators tolerated during generation.

4.4.2. Audit Trigger Scenarios According to regulatory policies and the legal framework, the declassification of audit information is only triggered in the scenarios listed in Table 3. The relevant audit triggering and execution details are: Based on STR or intelligence analysis and after internal approval, the FIU issues intelligence requests to the VASP. Prior to the operation, it is necessary to confirm that the scope of the request is directly related to legal duties, such as suspected money laundering and terrorist financing [18]. After the FSA provides the VASP with compliance background and preliminary risk assessment, the audit process is witnessed by the ISRO to ensure the completeness of the data extraction and the due process. The FSA may initiate an audit based on on-site inspections, off-site monitoring, or whistleblowing, subject to approval from its internal law enforcement department [19] [20]. Intelligence support is provided by the FIU to confirm the presence of suspicious activity, and the ISRO provides an independent opinion and cooperates with the investigation. VASP’s compliance department identifies suspicious transactions or high-risk behaviors through its transactionmonitoring system [21]. VASP’s internal risk control system triggers an alert, automatically generating a risk report and submitting it through the regulatory-designated system [22]. If the suspicion is confirmed, a tripartite assessment of the alert level determines whether to initiate an audit. VASP’s compliance department does not hold the security key. It can only submit risk reports. If the current situation triggers a suspicious investigation, an audit will be jointly initiated by the ISRO, FIU, and FSA. If a cross-border joint investigation is involved, a formal request from the foreign regulatory agency is required, along with a statement of legal basis [23]. If a Mutual Legal Assistance Treaty (MLAT) exists, cross-border audit applications can be submitted through the Ministry of Foreign Affairs to the Supreme Court/Supreme Procuratorate and then to the corresponding foreign agency, in the form of criminal judicial assistance [24]. In another way, the exchange Li et al.: Preprint submitted to Elsevier

Page 11 of 18

Balancing Privacy and Compliance

of regulatory information is limited to non-criminal matters and handled by the domestic financial regulatory authority in accordance with the Multilateral Memorandum of Understanding (MMoU) when it receives foreign regulatory requests [25]. This request must be translated into a formal document from a competent domestic authority (such as a financial regulatory body or court) before it can be obtained from the VASP [24]. The legality and reciprocity of the request are reviewed by the domestic judicial authorities, and the FIU assesses the request’s compatibility with domestic law [26]. When initiating criminal cases involving suspected money laundering, illegal business operations, or fraud, judicial personnel, armed with a Notice of Evidence Collection and their work identification, request audit [27]. When collecting evidence, judicial authorities need to verify fulfillment of VASP compliance obligations, thereby requiring the FSA to conduct its work [28]. The FIU’s investigative leads also need to cooperate with the audit.

4.4.3. Dynamic Blacklist Management with Merkle Tree A critical challenge is that compliance predicates (e.g., VASP blacklists) evolve over time. A naive ZK circuit that hardcodes the blacklist would invalidate all previous proofs upon each update. To address this, we treat the blacklist as a Merkle tree whose root 𝑟𝑜𝑜𝑡𝐵𝐿 is maintained on-chain by a designated authority (e.g., FIU). The ZK circuit verifies membership or non-membership by checking a Merkle proof against the current 𝑟𝑜𝑜𝑡𝐵𝐿 . The circuit input includes: • Private input: The VASP identifier 𝑖𝑑 being checked. • Public input: The current blacklist root 𝑟𝑜𝑜𝑡𝐵𝐿 and a Merkle proof 𝜋𝐵𝐿 . The circuit verifies MerkleVerify(𝑟𝑜𝑜𝑡𝐵𝐿 , 𝜋𝐵𝐿 ) to determine if id is in the blacklist. Because 𝑟𝑜𝑜𝑡𝐵𝐿 is a public input, it can change between transactions without affecting previously generated proofs, since that each proof is bound to the 𝑟𝑜𝑜𝑡𝐵𝐿 at the time of transaction submission. This design ensures: • Forward compatibility: New blacklist entries do not retroactively invalidate old proofs (the compliance check is against the blacklist state at transaction time, which is the correct semantic). • Light client sync: The target chain’s light client can synchronize the latest 𝑟𝑜𝑜𝑡𝐵𝐿 by reading the source chain’s state root, ensuring cross-chain consistency.

4.4.4. Threshold Decryption and Key Fragment Management When the triggering conditions are met, a corresponding number of regulators collaborate to perform decryption: 1. Each regulator 𝑅𝑖 reads the encrypted audit tag 𝐶 from the blockchain and computes a partial decryption share 𝑑𝑖 = 𝖣𝖾𝖼𝖲𝗁𝖺𝗋𝖾(𝑠𝑘𝑖 , 𝐶) using its private key fragment 𝑠𝑘𝑖 . 2. The partial decryption shares 𝑑𝑖 are exchanged via a secure channel (TLS + mutual authentication). 3. Once at least 𝑡 valid partial decryption shares are collected, the plaintext 𝑀 is recovered by combining the shares through Lagrange interpolation: 𝑀 = 𝖢𝗈𝗆𝖻𝗂𝗇𝖾(𝑑1 , … , 𝑑𝑡 ). The full private key 𝑠𝑘𝑅 is never reconstructed during this process. Each regulator’s key fragments are stored in a Hardware Security Module (HSM), requiring dual authentication for access. During decryption, partial decryption shares must reside only on the runtime temporary storage device and must be securely deleted after the audit and forensics process concludes. No decryption-related material may persist in any device in any form. All decryption operations are recorded in the on-chain audit log, achieving "audit of audits" and preventing abuse of power.

5. Security Analysis In this section, we provide formal security arguments for our protocol Π with respect to the adversary model  and security goals defined in subsubsection 3.3.2–3.3.3. We structure the analysis as a series of theorems, each accompanied by a proof sketch.

Li et al.: Preprint submitted to Elsevier

Page 12 of 18

Balancing Privacy and Compliance

5.1. Transaction Privacy Theorem 1 (Transaction Privacy). Under the assumptions that (i) the Groth16 ZK proof system satisfies computational zero-knowledge, and (ii) the ECIES encryption scheme provides semantic security under the DDH assumption, for any PPT adversary  as defined in subsubsection 3.3.2 and any two transactions tx0 , tx1 satisfying the same compliance predicate 𝑃 : (8)

| Pr[(𝜋0 , 𝐶0 ) = 1] − Pr[(𝜋1 , 𝐶1 ) = 1]| ≤ 𝗇𝖾𝗀𝗅(𝜆). Proof Sketch. We proceed via a hybrid argument.

1. ZK Hybrid: By the computational zero-knowledge property of Groth16, there exists a simulator  that produces simulated proofs 𝜋 𝗌𝗂𝗆 computationally indistinguishable from real proofs. Replacing 𝜋(tx0 ) with 𝜋 𝗌𝗂𝗆 changes ’s advantage by at most 𝗇𝖾𝗀𝗅1 (𝜆). 2. Encryption Hybrid: By the semantic security of ECIES under DDH, 𝐶0 = 𝖤𝗇𝖼𝑝𝑘𝑅 (𝑀0 ) and 𝐶1 = 𝖤𝗇𝖼𝑝𝑘𝑅 (𝑀1 ) are computationally indistinguishable. Replacing 𝐶0 with 𝐶1 changes ’s advantage by at most 𝗇𝖾𝗀𝗅2 (𝜆). 3. Since the ZK proof and the ciphertext are the only public outputs of the protocol visible to  (the audit tag is encrypted, and on-chain contract state reveals only proof verification results), the total distinguishing advantage is bounded by 𝗇𝖾𝗀𝗅(𝜆) = 𝗇𝖾𝗀𝗅1 (𝜆) + 𝗇𝖾𝗀𝗅2 (𝜆). □

5.2. Controlled Auditability Theorem 2 (Controlled Auditability). Under the (𝑡, 𝑛)-threshold decryption scheme based on Shamir’s Secret Sharing, and assuming the legal trigger conditions in Table 3 are enforced through off-chain authorization: 1. Completeness: Any coalition of ≥ 𝑡 honest regulators can recover 𝑀𝑚𝑖𝑛 (tx) from 𝐶 = 𝖤𝗇𝖼𝑝𝑘𝑅 (𝑀𝑚𝑖𝑛 (tx)). 2. Soundness: Any coalition of < 𝑡 regulators (even if all are corrupted by ) obtains negligible information about 𝑀𝑚𝑖𝑛 (tx). Proof Sketch. 1. Completeness: Given 𝑡 valid partial decryption shares 𝑑𝑖 = 𝖣𝖾𝖼𝖲𝗁𝖺𝗋𝖾(𝑠𝑘𝑖 , 𝐶), the 𝖢𝗈𝗆𝖻𝗂𝗇𝖾 algorithm applied to {(𝑖, 𝑑𝑖 )}𝑡𝑖=1 recovers the plaintext 𝑀. Correctness follows directly from the completeness property of the underlying (𝑡, 𝑛)-threshold decryption scheme. 2. Soundness: Given 𝑡 − 1 partial decryption shares {(𝑖, 𝑑𝑖 )}𝑡−1 and the ciphertext 𝐶 = 𝖤𝗇𝖼𝑝𝑘𝑅 (𝑀), the adversary 𝑖=1 faces two barriers: (i) the semantic security of ECIES (DDH assumption) prevents extracting 𝑀 from 𝐶 alone, and (ii) the (𝑡, 𝑛)-threshold scheme ensures that fewer than 𝑡 shares provide negligible information about 𝑀. The adversary’s overall advantage is therefore bounded by 𝗇𝖾𝗀𝗅(𝜆) = 𝜀DDH + 𝜀threshold , both negligible in the security parameter 𝜆. In addition, the protocol does not automatically grant decryption capability upon satisfaction of the threshold. Decryption is conditioned on explicit legal triggers: • Regulatory Investigation: Requires STR submission and internal approval from FIU. • Law Enforcement: Requires a judicial warrant with on-chain hash verification. • Cross-Border Request: Requires MLAT/MMoU documentation verified by domestic judicial authorities. These conditions are enforced through off-chain authorization protocols before partial decryption share exchange, ensuring that decryption occurs only within the bounds of legal authority.

5.3. Collusion Resistance Theorem 3 (Collusion Resistance). Let  ⊂ {𝑅1 , … , 𝑅𝑛 } be a coalition of corrupted regulators with || ≤ 𝑡 − 1. Even if all members of  pool their key fragments 𝑠𝑘𝑖 and all publicly available on-chain data, their advantage in recovering 𝑀𝑚𝑖𝑛 (tx) is negligible in the security parameter 𝜆.

Li et al.: Preprint submitted to Elsevier

Page 13 of 18

Balancing Privacy and Compliance Table 4 Comparison between Solutions Property Transaction Privacy Regulatory Auditability Trust-Minimized Verification ZK-Based Compliance Collusion Resistance Decryption Accountability

Transparent Bridges

IBC

Axelar

Privacy Coins

Our Framework

× ✓ × × N/A always

× × ✓ × N/A N/A

× × × × N/A N/A

✓ × N/A × N/A ×

✓ ✓ ✓ ✓ (𝑡, 𝑛) threshold conditional

Proof Sketch. By Theorem 2 (Soundness), any adversary controlling fewer than 𝑡 shares obtains negligible information about 𝑀𝑚𝑖𝑛 (tx). The coalition  possesses at most 𝑡 − 1 shares, hence its advantage in recovering the audit plaintext is bounded by 𝗇𝖾𝗀𝗅(𝜆). □ The system only becomes vulnerable when 𝑡 or more regulators collude — a scenario requiring coordinated action across multiple independent regulatory authorities (FIU, FSA, ISRO, judicial bodies, and/or foreign agencies), which is intentionally difficult to achieve without legal oversight and would itself constitute a prosecutable offense in most jurisdictions.

5.4. Replay Attack Prevention Each audit tag includes a unique transaction hash 𝗍𝗑𝖧𝖺𝗌𝗁𝑠 and the encrypted ciphertext 𝐶. The decryption process is bound to a specific transaction identifier. Replaying a previously decrypted set of partial shares against a different transaction fails because the decrypted plaintext would not match the target transaction’s 𝗍𝗑𝖧𝖺𝗌𝗁𝑠 . The on-chain audit log records all decryption operations, enabling the detection of repeated decryption attempts.

5.5. Comparative Analysis Table 4 compares our framework with existing solutions across key security and compliance properties. Transparent bridges, IBC, and Axelar each excel in different dimensions—cross-chain message passing (IBC), generalized relaying (Axelar), or audit transparency—but none provide built-in transaction privacy. Privacy coins achieve strong confidentiality but forego regulatory access. Our framework is the only design that simultaneously provides transaction privacy, conditional regulatory auditability, and trust-minimized cross-chain verification.

6. Experimental Evaluation This section presents a comprehensive experimental evaluation of our proposing framework. We evaluate three core components: a) the zero-knowledge proof system, b) the cross-chain verification mechanism, and c) the threshold decryption module. All experiments are conducted in realistic blockchain environments with detailed performance measurements.

6.1. Experimental Setup Hardware Environment: All experiments were conducted on a machine equipped with an Intel Ultra 5 125H CPU (14 cores, 1.20 GHz) and 32 GB RAM, running Windows 11 Pro. Software Stacks: The zero-knowledge proof system was implemented using Circom 0.5.46 and snarkjs 0.7.6, with Groth16 as the underlying proof system. Smart contracts were developed in Solidity and deployed on the Ethereum Sepolia testnet using Hardhat 3.3.0. The threshold decryption module was implemented in Python 3.9.11 using the Shamir library and Flask to simulate the regulator nodes. Test Data: We generated synthetic transactions of varying levels of complexity. The compliance predicates evaluated include a) amount non-negativity, b) signature validity, and c) AML threshold checking.

6.2. Zero-Knowledge Proof Performance Our work evaluated the ZK proof system across circuits with three levels of complexity. The simple circuit (36 constraints) verifies the basic amount and signature validity. The medium circuit (133 constraints) additionally checks whether the transaction amount exceeds an AML reporting threshold. The complex circuit (297 constraints) incorporates Li et al.: Preprint submitted to Elsevier

Page 14 of 18

Balancing Privacy and Compliance Table 5 Zero-Knowledge Proof Performance Metrics Metric

Simple Circuit

Medium Circuit

Complex Circuit

Number of Constraints Witness Generation Time (ms) Proof Generation Time (ms) Verification Gas Cost Proof Size (bytes)

36 44.43 503.95 214,390 806

133 44.00 475.70 214,426 806

297 45.60 497.60 228,744 804

Table 6 Cross-Chain Verification Performance Component

Gas Cost

Time (ms)

Audit Tag Storage (Source Chain) Light Client Verification Total Gas Consumption Block Header Synchronization Merkle Proof Verification Relayer Transmission Total Cross-Chain Delay

46,374 24,037 70,411 22,790 24,040 -

184 333 171.30

Table 7 Block Confirmation Latency Confirmation Depth

Actual Time (ms)

6 Blocks 12 Blocks

5,081 11,144

VASP blacklist verification. Here are some key observations found in this experiment: a) Proof generation time remains stable at approximately 475–505 ms across all circuit sizes, demonstrating Groth16’s efficiency for moderately complex circuits. b) Witness generation contributes negligible overhead (< 50 ms), indicating that input preparation does not become a bottleneck. c) Verification gas cost increases modestly from 214k to 229k as constraints grow, representing a 6.7% increase for 8 times more constraints. d) Proof size is constant at approximately 800 bytes, which is optimal for on-chain storage.

6.3. Cross-Chain Verification Performance We evaluated the light-client-based cross-chain verification mechanism on the Ethereum Sepolia testnet. The experiment measured three components: audit tag storage on the source chain, cross-chain proof submission, and Merkle proof verification on the target chain. About Cross-Chain Verification Performance shown in Table 6, we observed that: a) The total gas cost per cross-chain transaction is approximately 70,411 Gas, which is comparable to standard ERC-20 token transfers. b) Cross-chain verification introduces approximately 171 ms of additional latency beyond block confirmation time. c) Merkle proof verification using the OpenZeppelin library consumes 26,050 Gas, while our simplified verification consumes 24,040 Gas, a 7.7% optimization. As shown in Table 7, block confirmation time dominates the overall transaction latency. This aligns with baseline blockchain performance and is independent of our framework’s additional overhead.

6.4. Threshold Decryption Performance The work also evaluated the threshold decryption mechanism with 𝑛 = 5 regulators and 𝑡 = 3 as the decryption threshold. The experiment measured the key distribution overhead and the collaborative decryption latency across 30 independent trials. Through this experiment’s result shown in Table 8, indicating that: a) Key distribution is a one-time initialization cost of approximately 547 ms, which is acceptable for system deployment. b) Collaborative decryption Li et al.: Preprint submitted to Elsevier

Page 15 of 18

Balancing Privacy and Compliance Table 8 Threshold Decryption Performance (30 Trials) Metric

Value

Key Distribution Time Average Fragment Exchange Time Average Full Decryption Time Decryption Success Rate

547.36 ms 188.29 ± 20.04 ms 190.31 ± 19.53 ms 100% (30/30)

Table 9 Qualitative Comparison with Existing Solutions Solution

Privacy

Auditability

Cross-Chain Delay

Gas Cost

Transparent Bridges (e.g., Axelar) Privacy Coins (e.g., Monero) Our Framework

×

✓

∼3-5 seconds [29]

✓ ✓

× ✓

∼2-3 seconds [30] [31] ∼170 ms + block time

Comparable to standard token transfers [30] N/A ∼70k Gas

completes in under 200 ms on average, with fragment exchange dominating the latency. c) Decryption success rate is 100% when the threshold 𝑡 is satisfied, validating the correctness of the Shamir reconstruction. d) The standard deviation (≈20 ms) reflects network variability, which is typical for distributed systems.

6.5. Performance Comparison with Baseline Solutions We compared our framework against existing cross-chain solutions to contextualize performance characteristics. Since the direct implementation of alternative solutions is beyond the scope of this work, we reference published performance data. In Table 9, compared to transparent bridges, our framework adds privacy protection and controllable auditability with comparable gas costs and marginally higher latency (the additional 170 ms is dominated by block confirmation time). Compared to privacy coins, our framework provides regulated audit access, addressing a critical gap for financial compliance. The performance overhead of privacy and auditability features is approximately 170 ms per transaction, which is a cost that is acceptable for most DeFi applications.

7. Discussion and Future Work 7.1. Regulatory Compatibility Our framework aligns with key regulatory requirements. The encrypted audit tag contains only the minimum information required by the FATF Travel Rule and MiCA, ensuring compliance without unnecessary data exposure. The threshold-based audit mechanism respects legal due process, since decryption requires both a judicial warrant (for law enforcement scenarios) and collaboration from at least 𝑡 regulators. This dual control prevents unilateral surveillance while enabling lawful oversight. However, real-world deployment faces policy challenges. Cross-border regulatory coordination requires harmonized legal frameworks for key fragment management. We envision that international bodies such as the Financial Action Task Force could establish standards for key regulatory ceremonies, similar to those in existing mutual legal assistance treaties.

7.2. Limitations and Future Directions While our ZK circuits achieve proof generation under 500 ms, further optimization is possible. The current circuits support basic compliance checks (amount range, signature, blacklist). More complex predicates, such as historical transaction analysis, would increase constraint count and proof time. Our prototype uses light clients for EVM-compatible chains. Extending to non-EVM chains (e.g., Bitcoin, Solana) requires chain-specific light client implementations, which vary in complexity. We leave this generalization as future work. Our framework currently assumes an honest majority during DKG execution (i.e., fewer than 𝑡 malicious regulators during key generation). While this is strictly weaker than trusting a single KGC, future work could explore publicly verifiable DKG protocols that provide security even under a dishonest majority, at the cost of additional communication rounds. The minimum audit information set, while Li et al.: Preprint submitted to Elsevier

Page 16 of 18

Balancing Privacy and Compliance

privacy-preserving, may still reveal more than necessary for certain investigations. Future work could explore differential privacy techniques to add controlled noise to audit data, providing an additional layer of privacy protection for routine compliance monitoring. For blacklist liveness, the Merkle root approach requires that the blacklist authority (e.g., FIU) update the on-chain root promptly. A malicious authority could delay updates, allowing blacklisted VASPs to continue transacting. This is a governance, not cryptographic, limitation. In practice, the authority’s update schedule could be enforced via smart contract timelocks or multi-signature thresholds. Future work could explore decentralized blacklist management using on-chain governance or oracle-based attestations.

8. Conclusion This work presented a privacy-preserving and auditable cross-chain transaction framework that reconciles the fundamental tension between user privacy and regulatory compliance. By integrating zero-knowledge proofs, threshold cryptography, and light-client verification, our design enables transaction details to remain confidential during normal operation, with only ZK proofs publicly verifiable. The regulatory bodies’ access to audit information requires both legal authorization and collaborative decryption by at least 𝑡 regulators. Asset transfers are validated via cryptographic proofs without reliance on centralized bridges. Experimental evaluation demonstrates the framework’s practicality. ZK proof generation completes in under 500 ms. Cross-chain verification adds approximately 170 ms of latency and consumes 70k Gas, while threshold decryption finishes in under 200 ms. These performance characteristics are acceptable for real-world DeFi applications, where block confirmation times dominate overall transaction latency.

Acknowledgement The authors would like to express their sincere gratitude to the following professors for their valuable contributions to this work. We are especially grateful to Prof. Mingzhe Li (Great Bay University) for his detailed and professional suggestions during the revision process, which significantly improved the quality of this paper. We also thank Prof. Jing Liu (Guangdong University of Finance and Economics) for reviewing the manuscript and providing insightful feedback. We further extend our thanks to all colleagues and friends who supported this research.

Declaration of generative AI and AI-assisted technologies in the manuscript preparation process During the preparation of this work, the authors used ChatGPT for clarity improvement. The authors reviewed and edited the output as needed and take full responsibility for the content of the published article.

CRediT authorship contribution statement Li Huiheng: Conceptualization, Methodology, Project administration, Software, Writing - original draft. Feng Kainuo: Conceptualization, Formal analysis, Investigation, Methodology, Writing - Original draft. Ding Jiahao: Conceptualization, Formal analysis, Investigation, Methodology, Writing - Original draft. Ma Ziqi: Validation, Writing - review & editing.

References [1] I. Lee, Crypto market cap doubles to $2 trillion as rally surges, 2021. [2] H. Deng, Z. Wang, Y. Wang, L. Wang, L. Zhu, C. Zhang, A secure cross-account audit scheme for cross-chain transactions, in: International Conference on Algorithms and Architectures for Parallel Processing, volume 15253, Lecture Notes in Computer Science, Springer Nature Singapore, 2025, pp. 334–350. [3] L. Feng, P. Wu, K. Hu, S. Yao, Secure cross-chain interactions: a relay chain framework with privacy and auditability solutions, Cluster Computing 28 (2025). [4] Z. Chen, Z. Lu, J. Chen, Cross-chain trusted information match scheme with privacy-preserving and auditability, in: Blockchain Technology and Emerging Applications, volume 577, Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, Springer Nature Switzerland, 2024, pp. 94–114. [5] N. Li, M. Qi, Z. Xu, X. Zhu, W. Zhou, S. Wen, Y. Xiang, Blockchain cross-chain bridge security: Challenges, solutions, and future outlook, Distributed Ledger Technologies: Research and Practice 4 (2024).

Li et al.: Preprint submitted to Elsevier

Page 17 of 18

Balancing Privacy and Compliance [6] A. Zamyatin, M. Al-Bassam, D. Zindros, E. Kokoris-Kogias, P. Moreno-Sanchez, A. Kiayias, W. J. Knottenbelt, Sok: Communication across distributed ledgers, Financial Cryptography and Data Security (2021) 3–36. [7] O. Nikolaeva, Axelar network: Connecting applications with blockchain ecosystems, 2022. [8] E. B. Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer, M. Virza, Zerocash: Decentralized anonymous payments from bitcoin, in: 2014 IEEE Symposium on Security and Privacy, IEEE Computer Society, 2014, pp. 459–474. [9] A. Network, What is know your customer in anti-money laundering? - aml network, 2025. [10] FATF, Updated guidance for a risk-based approach to virtual assets and virtual asset service providers, 2021. [11] Chainalysis, Blockchain intelligence - chainalysis, 2024. [12] FATF, Fatf updates standards on recommendation 16 on payment transparency, 2025. [13] I. U. Limited, 6amld: 6th anti money laundering directive, 2020. [14] R. Deane, A complete guide to aml regulations around the world, 2025. [15] Chainalysis, Fatf’s report on recommendation 15: What it means, 2024. [16] A. Network, What are the global anti-money laundering laws?, 2025. [17] FATF, Fatf urges stronger global action to address illicit finance risks in virtual assets, 2025. [18] B. Schwind-Wagner, Fatf | r.29 financial intelligence units, 2025. [19] FATF/OECD, International standards on combating money laundering and the financing of terrorism & proliferation, 2012. [20] E. Parliament, C. of the European Union, Regulation (eu) 2023/1114 of the european parliament and of the council of 31 may 2023 on markets in crypto-assets, and amending regulations (eu) no 1093/2010 and (eu) no 1095/2010 and directives 2013/36/eu and (eu) 2019/1937, 2023. [21] E. Parliament, T. C. of the European Union, Directive (eu) 2018/1673 of the european parliament and of the council of 23 october 2018 on combating money laundering by criminal law, 2018. [22] T. E. Commission, Commission implementing regulation (eu) 2023/1111 of 6 june 2023 amending regulation (ec) no 474/2006 as regards the list of air carriers banned from operating or subject to operational restrictions within the union, 2023. [23] E. Parliament, T. C. of the European Union, Directive 2014/62/eu of the european parliament and of the council of 15 may 2014 on the protection of the euro and other currencies against counterfeiting by criminal law, and replacing council framework decision 2000/383/jha, 2014. [24] O. of International Affairs Criminal Division U.S. Department of Justice, Mutual legal assistance treaties of the united states, 2022. [25] I. O. of Securities Commissions, 2013 list of non-signatories to the mmou, 2016. [26] T. C. of The European Communities, 2000/800/ec: Commission decision of 7 december 2000 authorising the member states to permit temporarily the marketing of vine propagating material not satisfying the requirements of council directive 68/193/eec, 2000. [27] H. Office, 005/2024: Economic crime and corporate transparency act - cryptoasset forfeiture provisions chapters 3c to 3f, 2024. [28] F. Services, the Treasury Bureau of the Hong Kong Special Administrative Region Government, Anti-money laundering and counter-terrorist financing ordinance, 2018. [29] G. Wiki, How does axelar compare to layerzero and wormhole in cross-chain interoperability performance and market share?, 2026. [30] G. Wiki, What are the key differences between dash (dash) and its main competitors in the privacy coin market?, 2025. [31] Crypto.com, Bitcoin vs monero: Comparing two well-established pow protocols, 2025.

Li et al.: Preprint submitted to Elsevier

Page 18 of 18

Related documents

• Balancing Privacy and Compliance in DeFi: A Zero-Knowledge-Based Auditable Cross-Chain Framework#615251
• Balancing Privacy and Compliance in DeFi: A Zero-Knowledge-Based Auditable Cross-Chain Framework#614284
• Persona-Execution Separation: An Architecture Pattern for Evolving LLM Agents under Execution Audit#1084343
• AgentTrails: Towards Trust and Reuse for Agentic Tasks#386977
• Machine Understandable Policies and GDPR Compliance Checking#1092014