Paper deep dive
Fairly Compensated Distributed Information Retrieval and Augmentation for AI Agents
Yixiang Yao, Pasha Barahimi, Srivatsan Ravi
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 94%
Last extracted: 9/22/2026, 4:58:15 AM
Summary
This paper proposes a protocol for fairly compensated distributed information retrieval and augmentation in autonomous AI agent networks. It addresses the 'evaluation-disclosure paradox' in trustless environments where agents must evaluate data quality before purchase while providers must ensure compensation before revealing data. The solution utilizes Threshold Homomorphic Encryption (THE) for secure evaluation of encrypted documents, Zero-Knowledge Proofs (ZKPs) for integrity, and Hashed Timelock Contracts (HTLCs) on blockchain for atomic settlement, ensuring confidentiality, correctness, integrity, and fairness without centralized intermediaries.
Entities (8)
Relation Signals (6)
Fairly Compensated Protocol → solves → Evaluation-Disclosure Paradox
confidence 96% · Our framework resolves the evaluation-disclosure paradox by allowing agents to verify data against their specific query without compromising the provider’s underlying privacy.
Fairly Compensated Protocol → utilizes → Threshold Homomorphic Encryption
confidence 95% · Our framework enables retrieval agents to securely evaluate and rank candidate documents... using THE.
Fairly Compensated Protocol → utilizes → Zero-Knowledge Proofs
confidence 94% · We further analyze the security properties... leveraging Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge (zk-SNARKs)
Fairly Compensated Protocol → utilizes → Hashed Timelock Contract
confidence 93% · The protocol facilitates the exchange of information and value as an atomic transaction... using HTLCs.
Hashed Timelock Contract → deployedon → Ethereum
confidence 90% · Smart contracts on Ethereum are implemented in Solidity... A Hashed Timelock Contract (HTLC) is a type of smart contract...
Retrieval-Augmented Generation → relieson → Fairly Compensated Protocol
confidence 85% · Retrieval-Augmented Generation (RAG) has emerged as a foundational paradigm... The increasing reliance of autonomous AI agents on external and distributed knowledge sources...
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:The increasing reliance of autonomous AI agents on external and distributed knowledge sources introduces a fundamental challenge for decentralized information marketplaces: retrieval agents must evaluate the quality and relevance of data before purchase, while data providers must avoid revealing valuable information prior to guaranteed compensation. This paradox becomes particularly critical in trustless multi-agent environments, where no centralized intermediary can enforce fairness between parties. In this paper, we propose a fairly compensated protocol for distributed information retrieval and augmentation in autonomous agent networks. Our framework enables retrieval agents to securely evaluate and rank candidate documents without learning their plaintext contents, while ensuring that data providers are compensated only when valid information is successfully delivered. We further analyze the security properties of the protocol against malicious adversaries and evaluate its practical feasibility through implementations. Experimental results demonstrate that the proposed design is practical with current cryptographic infrastructures while preserving confidentiality, correctness, integrity, and fairness. We believe such mechanisms provide an important cryptographic foundation for trustworthy and economically sustainable decentralized knowledge marketplaces for future AI agent ecosystems.
Tags
Links
- Source: https://arxiv.org/abs/2609.22601v1
- Canonical: https://arxiv.org/abs/2609.22601v1
Trouble viewing inline? Open PDF directly →
Full Text
75,987 characters extracted from source content.
Expand or collapse full text
Fairly Compensated Distributed Information Retrieval and Augmentation for AI Agents Yixiang Yao Pasha Barahimi Srivatsan Ravi Affiliation: University of Southern California Affiliation: yixiangy, barahimi, srivatsr@usc.edu Abstract The increasing reliance of autonomous AI agents on external and distributed knowledge sources introduces a fundamental challenge for decentralized information marketplaces: retrieval agents must evaluate the quality and relevance of data before purchase, while data providers must avoid revealing valuable information prior to guaranteed compensation. This paradox becomes particularly critical in trustless multi-agent environments, where no centralized intermediary can enforce fairness between parties. In this paper, we propose a fairly compensated protocol for distributed information retrieval and augmentation in autonomous agent networks. Our framework enables retrieval agents to securely evaluate and rank candidate documents without learning their plaintext contents, while ensuring that data providers are compensated only when valid information is successfully delivered. We further analyze the security properties of the protocol against malicious adversaries and evaluate its practical feasibility through implementations. Experimental results demonstrate that the proposed design is practical with current cryptographic infrastructures while preserving confidentiality, correctness, integrity, and fairness. We believe such mechanisms provide an important cryptographic foundation for trustworthy and economically sustainable decentralized knowledge marketplaces for future AI agent ecosystems. 1 Introduction The emergence of Large Language Models (LLMs) OpenAI (2026); Google (2026); Anthropic (2026) and autonomous AI agents Hughes et al. (2025); Durante et al. (2024) has revolutionized complex reasoning and decision-making tasks. However, the efficacy of these agents is strictly bounded by the quality and timeliness of their underlying knowledge base. As an example, Retrieval-Augmented Generation (RAG) Arslan et al. (2024); Cuconasu et al. (2024); Zhang et al. (2024) has surfaced as the standard architectural pattern to ground these models. More generically, in a multi-agent network, the data flow is multi-directional: an agent may query a database node, or two agents may engage in a peer-to-peer exchange where one possesses the specific domain expertise or environmental state required by the other. In any of these scenarios, the “gold standard” of data (often domain-specific, inter-organizational, or privacy-sensitive) is rarely centralized. Instead, it is distributed across a heterogeneous network of data providers, ranging from institutional repositories to specialized edge-agent nodes Yao et al. (2026). Despite the critical need for distributed data, current monetization models are fundamentally misaligned with data value. Existing frameworks typically rely on either rigid subscription models or volume-based pricing (e.g., pay-per-query), which fail to account for the intrinsic quality of the retrieved information. This creates a two-sided market failure. On the one side, from the aspect of AI agents, there is a pervasive junk-data risk, where agents incur significant costs for low-value or irrelevant responses. On the other side, for data providers, particularly smaller and specialized ones, the current model favors data monopolies because trusted “big names” naturally equal low risk. Without a mechanism to prove data quality prior to the transaction, high-quality but small providers remain undercompensated, causing them struggle to maintain the infrastructure necessary to compete. Figure 1: Illustration of current methods and the proposed solution. Ideally, in a fully distributed agent network with zero trust, the agent only compensates the provider who provides suitable data. However, it is challenging to archive with the three fundamental technical hurdles. First, the evaluation-disclosure paradox prevents transparent valuation: an agent must verify data utility before committing funds, yet a provider cannot reveal its data without confirming the payment. Second, an agent may need to poll multiple candidate nodes but lacks a secure mechanism to identify and compensate only the most relevant providers without leaking value to the others. Finally, executing these transactions requires an atomic settlement layer that guarantees “delivery-versus-payment” (DvP) in a peer-to-peer manner, ensuring that neither the data nor the payment is released without the other, all while operating without a centralized trusted intermediary. In this paper, we propose a fairly compensated protocol specifically tailored for distributed information retrieval and augmentation in autonomous agent networks. Our framework resolves the evaluation-disclosure paradox by allowing agents to verify data against their specific query without compromising the provider’s underlying privacy. By enabling secure, pre-purchase comparisons across a distributed field of candidates, it empowers agents to select the most relevant information based on merit rather than brand reputation. Finally, the protocol facilitates the exchange of information and value as an atomic transaction to guarantee DVP without the involvement of a third party. By removing the requirement for prior trust or centralized intermediaries, our protocol establishes a privacy-preserving economic foundation for a truly decentralized knowledge marketplace. 2 Preliminaries 2.1 Problem Statement We formalize the problem as a multi-party protocol involving a set of n distributed data providers =s1,s2,…,snS=\s_1,s_2,…,s_n\ and a set of m autonomous agents =c1,c2,…,cmC=\c_1,c_2,…,c_m\. Retrieval An agent ci∈c_i initiates a query q∈0,1∗q∈\0,1\^* directed to a subset of providers ′⊆S . Each provider sj∈′s_j identifies a candidate response djd_j from their local knowledge base jK_j: dj=Retrieve(q,j)d_j=Retrieve(q,K_j) (1) Each sjs_j transforms djd_j into a form T(dj)T(d_j) that hides the plaintext content from the agent cic_i but is able to evaluate with. Qualification The agent cic_i can verify if djd_j is qualified for q without learning its plaintext with the function Q, that is, ∀sj∈′,ci verifies Q(T(dj),q)∈0,1.∀ s_j , c_i verifies Q(T(d_j),q)∈\0,1\. (2) Settlement Based on the results, cic_i selects a subset of “winning” documents ∗D^*, and prepare a set of payments ∗P^* to purchase. The transaction must execute an Atomic Information-Value Exchange between the agent cic_i and each selected provider sjs_j. For a payment pj∈∗p_j ^* and document dj∈∗d_j ^*, the final state transition must be: Statefinal=(ci←dj,sj←pj)if both parties are honest(ci←⟂,sj←⟂)if either party abortsState_final= cases(c_i← d_j,s_j← p_j)&if both parties are honest\\ (c_i← ,s_j← )&if either party aborts cases (3) This exchange is conducted without a trusted third party. This ensures that the agent cannot recover djd_j unless the payment pjp_j is committed to the provider, and the provider cannot claim pjp_j without revealing a djd_j. We say a transaction is fairly compensated if the retrieval agent can verify the qualification and relevance of a document prior to purchase, while the data provider is guaranteed to receive compensation if and only if the correct qualified document is delivered. Consequently, providers supplying higher-quality or more relevant documents are more likely to be selected and compensated than those providing lower-quality responses. 2.2 Homomorphic Encryption Homomorphic Encryption (HE) Acar et al. (2018); Fontaine and Galand (2007) is a cryptographic primitive that enables computations to be performed directly on encrypted data without requiring decryption. Formally, an HE scheme for a plaintext space ℳM and ciphertext space C allows the evaluation of an operator ⊕C _C on the underlying messages through a corresponding operator ⊕C _C on their ciphertexts. If ct1=Enc(m1)ct_1=Enc(m_1) and ct2=Enc(m2)ct_2=Enc(m_2), then: Dec(ct1⊕Cct2)=m1⊕Mm2Dec(ct_1 _Cct_2)=m_1 _Mm_2 (4) In concrete implementations, ⊕M _M typically represents fundamental arithmetic operations such as addition (++) or multiplication (×), or logical operations such as and (∧ ), or (∨ ) and not (¬ ). A typical HE scheme ϵε is defined by four operations: • .ϵ(1λ)→(pk,sk) HE.KeyGen_ε(1^λ)→(pk,sk): Given a security parameter λ, the algorithm generates a public key pkpk for encryption and evaluation, a secret key sksk for decryption. • .ϵ(pk,m)→ct HE.Enc_ε(pk,m)→ ct: Encrypts a plaintext message m into a ciphertext ctct using the public key. • .ϵ(sk,ct)→m HE.Dec_ε(sk,ct)→ m: Recovers the original message m from the ciphertext using the secret key. • .ϵ(pk,f,ct1,…,ctn)→cteval HE.Eval_ε(pk,f,\ct_1,…,ct_n\)→ ct_eval: Takes the public key pkpk, a function f (represented as a boolean or arithmetic circuit), and a set of ciphertexts, producing a ciphertext ctevalct_eval that encrypts the result of f applied to the underlying plaintexts. Modern HE research is primarily categorized by schemes optimized for specific data types. The BFV Fan and Vercauteren (2012) and BGV Brakerski et al. (2014) schemes are optimized for exact integer arithmetic, and the CKKS scheme Cheon et al. (2017) is designed for approximate arithmetic on real or complex numbers. To further enhance security in distributed environments, Threshold Homomorphic Encryption (THE) Desmedt (2011); Cramer et al. (2001) extends these schemes into a multi-party setting. In THE, the secret key sksk is not held by a single entity but is instead divided into n shares sk1,sk2,…,skn\sk_1,sk_2,…,sk_n\ distributed among multiple participants. Decryption requires a threshold of parties (t≤nt≤ n) to collaborate in a partial decryption process. This ensures that no single (or less than t) provider or agent can unilaterally decrypt the data, providing a robust defense against colluding nodes and centralized points of failure in the distributed network. Specifically, for a scheme ϵε, the distributed key generation and decryption are defined as below. • .ϵ(1λ,t,n)→(pk1,sk1) THE.KeyGenLead_ε(1^λ,t,n)→(pk_1,sk_1): The initial party P1P_1 generates a base key pair. • .ϵ(pkj−1,…)→(pkjoint,skj) THE.KeyGenMain_ε(pk_j-1,…)→(pk_joint,sk_j): Subsequent parties PjP_j generate their own secret shares skjsk_j and iteratively update the joint public key pkjointpk_joint. • .ϵ(sk1,ct)→ctp1 THE.DecryptLead_ε(sk_1,ct)→ ct_p1: The designated lead party initiates the decryption process by applying their secret share sk1sk_1 to the ciphertext ctct. This produces a partially decrypted ciphertext component ctp1ct_p1. • .ϵ(skj,ct)→ctpj THE.DecryptMain_ε(sk_j,ct)→ ct_pj: All other participating parties PjP_j independently compute their partial decryption shares ctpjct_pj using their respective secret shares skjsk_j. • .ϵ(ctp1,…,ctpt)→m THE.DecryptFusion_ε(\ct_p1,…,ct_pt\)→ m: The final aggregation step where the lead and main partial decryptions are combined. At least t parties need to be involved to execute a correct decryption. 2.3 Zero-Knowledge Proof Zero-Knowledge Proofs (ZKPs) Fiege et al. (1987) are cryptographic protocols that enable a party, the prover (P), to convince another party, the verifier (V), that a specific statement is true without revealing any information beyond the validity of the statement itself. Formally, for a NP-language ℒL associated with a polynomial-time decidable relation ℛR, a ZKP allows P to prove that for a public input x, they possess a private witness w such that (x,w)∈ℛ(x,w) . A robust ZKP system must satisfy three fundamental properties: • Completeness: If (x,w)∈ℛ(x,w) and both the prover and verifier follow the protocol, the verifier will be convinced with overwhelming probability: Pr[⟨P(w),V⟩(x)=accept]≥1−negl(λ) [ P(w),V (x)=accept]≥ 1-negl(λ). • Soundness: If (x,w)∉ℛ(x,w) , no malicious prover P∗P^* can convince the verifier that the statement is true, except with a negligible probability: Pr[⟨P∗,V⟩(x)=accept]≤negl(λ) [ P^*,V (x)=accept] (λ) • Zero-Knowledge: For every probabilistic polynomial-time verifier V∗V^*, there exists a polynomial-time Simulator Sim such that for all (x,w)∈ℛ(x,w) : ViewV∗[P(w)↔V∗(x)]≈Sim(x)View_V^*[P(w) V^*(x)] (x), where ≈ denotes computational indistinguishability. In this work, we specifically leverage Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge (zk-SNARKs) Bitansky et al. (2012); Parno et al. (2016). Unlike traditional interactive proofs, zk-SNARKs enable the prover to generate a single, non-interactive proof string π that can be verified publicly. These systems are “succinct” because the proof size |π||π| is typically O(1)O(1) or O(polylog|w|)O(poly |w|), and the verification time is significantly faster than executing the underlying computation. 2.4 Blockchain and Smart Contracts A blockchain Zheng et al. (2018) is a decentralized, distributed ledger that maintains a continuously growing list of records, called blocks, which are linked and secured using cryptography. It provides a transparent and immutable infrastructure for data storage, ensuring that once a transaction is recorded and confirmed by network consensus, it cannot be altered or deleted. Smart contracts Nofer et al. (2017) are self-executing programs stored on the blockchain that automatically facilitate, verify, or enforce the performance of an agreement. By encoding the terms of a transaction directly into immutable code, these contracts move beyond simple data storage to provide programmable logic. Ethereum Buterin and others (2013) is a widely-used, decentralized, open-source blockchain platform which provides a Turing-complete execution environment known as Ethereum Virtual Machine (EVM), purpose-built for deploying and executing smart contracts. Ethereum’s native currency, Ether (ETH), serves both as a medium of exchange and as “gas”, the fee paid to compensate for the computational resources required to execute operations on the network. Smart contracts on Ethereum are implemented in Solidity Dannen and others (2017), a statically typed, contract-oriented programming language that compiles to EVM bytecode. A Hashed Timelock Contract (HTLC) Herlihy (2018) is a type of smart contract used in cryptocurrencies to enable secure, trustless, and time-bound transactions. It forces the recipient to acknowledge receipt of payment by a deadline using a cryptographic secret (“hashlock”) or else the funds are refunded to the sender (“timelock”). For example, Alice locks funds in a digital vault that Bob can only open by revealing a specific secret code before a countdown timer expires, or else the money returns to Alice. 2.5 Related Works Retrieval-Augmented Generation and Autonomous Agents Retrieval-Augmented Generation (RAG) has emerged as a foundational paradigm for enhancing large language models with external and up-to-date knowledge. Early works such as RAG Lewis et al. (2020) combine parametric language models with non-parametric retrieval systems to improve factuality and knowledge coverage. More recently, autonomous agent frameworks including ReAct Yao et al. (2022), Toolformer Schick et al. (2023), and AutoGen Wu et al. (2023) demonstrate that modern AI systems increasingly rely on continuous interactions with external tools, APIs, and distributed information sources. These developments indicate a broader transition from standalone language models toward interconnected agent ecosystems where information retrieval becomes a core operational primitive. At the same time, recent works have recognized that retrieval itself incurs substantial computational and economic cost. Approaches such as Self-RAG Asai et al. (2024), CRAG Yan and others (2024), Adaptive-RAG Jeong and others (2024), and FrugalRAG Java et al. (2025) attempt to improve the efficiency and quality of retrieval by selectively invoking external knowledge sources or correcting low-quality retrieval outputs. These systems optimize the trade-off between retrieval cost and response quality, highlighting the growing importance of retrieval valuation in large-scale AI systems. However, existing RAG frameworks largely assume trusted and centralized retrieval infrastructures, and do not address how autonomous agents can securely evaluate and compensate distributed information providers in trustless environments. Distributed AI and Decentralized Data Marketplaces The emergence of decentralized AI infrastructures further amplifies the need for trustworthy information exchange protocols. Platforms such as Ocean Protocol 11 1 https://oceanprotocol.com/ and Fetch.ai 22 2 https://w.fetch.ai/ aim to establish decentralized marketplaces for data, computation, and AI services. These systems introduce tokenized incentive mechanisms and enable economic interactions between distributed agents and providers. In parallel, multi-agent systems such as CAMEL Li et al. (2023) and Generative Agents Park et al. (2023) envision persistent autonomous agents that continuously exchange information and coordinate actions in open environments. Fair Exchange and Trustless Settlement. The fair exchange problem has long been studied in distributed systems and cryptography, particularly in the context of exchanging digital assets between mutually untrusted parties. Recent works have further analyzed the practical security and incentive compatibility of HTLC-based systems. For example, He-HTLC Wadhwa and others (2023) revisits the incentive assumptions of classical HTLC protocols and proposes a more robust construction against strategic manipulation and bribery attacks. These approaches primarily focus on secure payment settlement or fair delivery after the data has already been selected. However, regardless of all these works, for the specific problem of fairly compensated distributed information retrieval for autonomous agents remains unexplored. In particular, prior research has not systematically investigated how retrieval agents can privately evaluate and compare candidate information from multiple distributed providers before purchase, while simultaneously ensuring that providers are compensated fairly and atomically only when valid information is successfully delivered. This gap becomes increasingly important as future AI ecosystems evolve toward decentralized and economically autonomous multi-agent environments. 3 Method In this section, we first present and examine the protocol in detail in Section 3.1, followed by a security analysis in Section 3.2. 3.1 Protocol Assume the retrieval agent is P0P_0, and there are two data providers P1P_1 and P2P_2. In practice, there could be more than two data providers. Phase 1: Ranking In Phase 1, P0P_0 issues a query to P1P_1 and P2P_2 to perform retrieval, and subsequently scores and ranks the returned documents without learning their plaintext contents. By the end, P0P_0 knows which document is worth the retrieval. The protocol is illustrated in Figure 2. In Step 1, P0P_0 initiates the distributed THE key generation protocol with P1P_1 and P2P_2. At the end of this step, each party holds its own private key, while P1P_1 and P2P_2 each establish a joint public key with P0P_0 (i.e., pkjoint1pk_joint1 and pkjoint2pk_joint2). In Step 2, P0P_0 sends the query q to both P1P_1 and P2P_2. In Step 3, P1P_1 and P2P_2 perform retrieval using q, obtain documents d1d_1 and d2d_2, encrypt them under their respective joint public keys, and return the ciphertexts ⟦d1⟧ d_1 and ⟦d2⟧ d_2 to P0P_0. In Step 4, P0P_0 evaluates the encrypted documents using THE. It computes relevance scores via a homomorphic scoring function S, and simultaneously generates document hashes using HashDoc for subsequent integrity verification. The resulting encrypted scores and hashes are then sent back to P1P_1 and P2P_2. In Step 5, P0P_0 performs partial decryption of the encrypted scores and hashes using its private key, and forwards the partially decrypted results to P1P_1 and P2P_2. In Step 6, P1P_1 and P2P_2 independently perform their own partial decryptions on the corresponding ciphertexts. In Step 7, P1P_1 and P2P_2 combine their own partial decryption results (from Step 6) with those received from P0P_0 (from Step 5) to recover the plaintext scores and hashes. This step ensures that P0P_0 does not learn any sensitive information during the evaluation of S and HashDoc. If no information leakage is detected, P1P_1 and P2P_2 send their partial decryption shares to P0P_0. In Step 8, P0P_0 combines its own partial decryption results (from Step 5) with those received from P1P_1 and P2P_2 (from Step 7) to obtain the final plaintext scores and hashes. Finally, in Step 9, P0P_0 compares the scores, selects the best document, and retains the corresponding hash value. If none of the retrieved documents are satisfactory (e.g., both scores are less than a minimum threshold), P0P_0 may terminate the protocol without proceeding to the subsequent phases. 1. P0P_0 generates (pk0,sk0)←.ϵ(1λ,2,2)(pk_0,sk_0)← THE.KeyGenLead_ε(1^λ,2,2). t and n are set to 2 to ensure decryption will be successful only when both (P0,P1)(P_0,P_1) or (P0,P2)(P_0,P_2) are involved. P0P_0 shares pk0pk_0 with P1P_1 and P2P_2. P1P_1 and P2P_2 then generate (pkjoint1,sk1)←.ϵ(pk0)(pk_joint1,sk_1)← THE.KeyGenMain_ε(pk_0) and (pkjoint2,sk2)←.ϵ(pk0)(pk_joint2,sk_2)← THE.KeyGenMain_ε(pk_0), and share pkjoint1pk_joint1 and pkjoint2pk_joint2 to P0P_0 respectively. 2. P0P_0 sends query q to P1P_1 and P2P_2. 3. P1P_1 and P2P_2 perform retrieval with q and retrieve documents d1d_1 and d2d_2. They also encrypt both documents to ⟦d1⟧←.ϵ(pkjoint1,d1) d_1 ← HE.Enc_ε(pk_joint1,d_1) and ⟦d2⟧←.ϵ(pkjoint2,d2) d_2 ← HE.Enc_ε(pk_joint2,d_2). They send ⟦d1⟧ d_1 and ⟦d2⟧ d_2 to P0P_0. 4. P0P_0 homomorphically executes a scorer S on ⟦d1⟧ d_1 and ⟦d2⟧ d_2 , ⟦s1⟧←.ϵ(pkjoint1,S,⟦d1⟧) s_1 ← THE.Eval_ε(pk_joint1,S, d_1 ) and ⟦s2⟧←.ϵ(pkjoint2,S,⟦d2⟧) s_2 ← HE.Eval_ε(pk_joint2,S, d_2 ), meanwhile homomorphically computes hashes ⟦h1⟧←.ϵ(pkjoint1,,⟦d1⟧) h_1 ← THE.Eval_ε(pk_joint1, HashDoc, d_1 ), ⟦h2⟧←.ϵ(pkjoint2,,⟦d2⟧) h_2 ← THE.Eval_ε(pk_joint2, HashDoc, d_2 ). P0P_0 sends (⟦s1⟧,⟦h1⟧)( s_1 , h_1 ) to P1P_1 and (⟦s2⟧,⟦h2⟧)( s_2 , h_2 ) to P2P_2. 5. P0P_0 performs independent partial decryption on scores and hashes: ⟦s1p0⟧←.ϵ(sk0,⟦s1⟧) s_1p0 ← THE.DecryptLead_ε(sk_0, s_1 ), ⟦h1p0⟧←.ϵ(sk0,⟦h1⟧) h_1p0 ← THE.DecryptLead_ε(sk_0, h_1 ), ⟦s2p0⟧←.ϵ(sk0,⟦s2⟧) s_2p0 ← THE.DecryptLead_ε(sk_0, s_2 ), ⟦h2p0⟧←.ϵ(sk0,⟦h2⟧) h_2p0 ← THE.DecryptLead_ε(sk_0, h_2 ). P0P_0 sends the partially decrypted results (⟦s1p0⟧,⟦h1p0⟧)( s_1p0 , h_1p0 ) to P1P_1 and (⟦s2p0⟧,⟦h2p0⟧)( s_2p0 , h_2p0 ) to P2P_2. 6. P1P_1 and P2P_2 perform independent partial decryption: ⟦s1p1⟧←.ϵ(sk1,⟦s1⟧) s_1p1 ← THE.DecryptMain_ε(sk_1, s_1 ), ⟦h1p1⟧←.ϵ(sk1,⟦h1⟧) h_1p1 ← THE.DecryptMain_ε(sk_1, h_1 ), ⟦s2p2⟧←.ϵ(sk2,⟦s2⟧) s_2p2 ← THE.DecryptMain_ε(sk_2, s_2 ), ⟦h2p2⟧←.ϵ(sk2,⟦h2⟧) h_2p2 ← THE.DecryptMain_ε(sk_2, h_2 ). P1P_1 and P2P_2 send their partially decrypted results to P0P_0. 7. P1P_1 collects the partial decrypted results and fuses for the final decryption: s1←.ϵ(⟦s1p0⟧,⟦s1p1⟧)s_1← THE.DecryptFusion_ε(\ s_1p0 , s_1p1 \), h1←.ϵ(⟦h1p0⟧,⟦h1p1⟧)h_1← THE.DecryptFusion_ε(\ h_1p0 , h_1p1 \). P2P_2 can perform the similar operations to get decrypted results: s2←.ϵ(⟦s2p0⟧,⟦s2p2⟧)s_2← THE.DecryptFusion_ε(\ s_2p0 , s_2p2 \), h2←.ϵ(⟦h2p0⟧,⟦h2p2⟧)h_2← THE.DecryptFusion_ε(\ h_2p0 , h_2p2 \). If the decryption results (s1,h1)(s_1,h_1) and (s2,h2)(s_2,h_2) are with no information leak, P1P_1 and P2P_2 send their partial decrypted results (⟦s1p1⟧,⟦h1p1⟧)( s_1p1 , h_1p1 ) and (⟦s2p2⟧,⟦h2p2⟧)( s_2p2 , h_2p2 ) to P0P_0. 8. P0P_0 collects the partial decrypted results and fuses for the final decryption: s1←.ϵ(⟦s1p0⟧,⟦s1p1⟧)s_1← THE.DecryptFusion_ε(\ s_1p0 , s_1p1 \), h1←.ϵ(⟦h1p0⟧,⟦h1p1⟧)h_1← THE.DecryptFusion_ε(\ h_1p0 , h_1p1 \), s2←.ϵ(⟦s2p0⟧,⟦s2p2⟧)s_2← THE.DecryptFusion_ε(\ s_2p0 , s_2p2 \), h2←.ϵ(⟦h2p0⟧,⟦h2p2⟧)h_2← THE.DecryptFusion_ε(\ h_2p0 , h_2p2 \). 9. P0P_0 compares the score, and picks the best one. P0P_0 also keeps the corresponding hash value in plaintext (either h1h_1 or h2h_2) of that document. Figure 2: Protocol - Ranking Phase 2: Verification Assume that d1d_1 is selected as the preferred document (e.g., s1>s2s_1>s_2). Thus, P0P_0 tend to acquire d1d_1 from P1P_1 via an atomic swap protocol, ensuring fairness without requiring any trusted third party. Prior to the actual transaction in the next phase, a verification step is performed to guarantee the correctness and integrity of the exchanged data. As illustrated in Figure 3, this phase combines symmetric encryption with a zero-knowledge proof. In Step 1, P1P_1 samples a random symmetric key k and encrypts the document d1d_1 to obtain the ciphertext c1c_1. It also computes a hash of the key as hkh_k. In Step 2, P1P_1 sends (c1,hk)(c_1,h_k) to P0P_0. At this point, P0P_0 possesses OPENc1,hk)c_1,h_k) along with h1h_1 obtained from Phase 1, where h1h_1 is the hash of the target document d1d_1. However, P0P_0 cannot yet verify whether the hidden key k corresponding to hkh_k correctly decrypts c1c_1 to the intended document d1d_1. To address this, in Step 3, P1P_1 generates a zk-SNARK proof π demonstrating knowledge of a key k such that k correctly decrypts c1c_1 to the document d1d_1 whose hash matches the value obtained by P0P_0 in Phase 1. In Step 4, P1P_1 sends π to P0P_0, who verifies the proof. If the verification succeeds, P0P_0 is assured that the ciphertext c1c_1 corresponds to the correct document and k will properly decrypt it. This guarantees the correctness of the forthcoming transaction. 1. With a symmetric encryption algorithm SYM, P1P_1 samples a random symmetric key k and encrypts d1d_1 to obtain c1=.k(d1)c_1= SYM.Enc_k(d_1). It also computes hk=(k)h_k= HashKey(k). 2. P1P_1 sends c1,hkc_1,h_k to P0P_0. 3. P1P_1 generates a zk-SNARK proof π: I know k such that (i) (k)=hk, and (i) (.k(c1))=h1I know $k$ such that \\ (i) HashKey(k)=h_k\\ , and \\ (i) HashDoc( SYM.Dec_k(c_1))=h_1 (5) 4. P1P_1 sends π to P0P_0. P0P_0 verifies this proof. If valid, P0P_0 is mathematically certain that the key hidden behind hkh_k is the correct one. Figure 3: Protocol - Verification Phase 3: Transaction At this stage, P0P_0 proceeds to pay P1P_1 in exchange for the selected document d1d_1. The transaction is carried out over a decentralized network without relying on any trusted third party. As illustrated in Figure 4, this is achieved using a smart contract, specifically a Hash Time-Locked Contract (HTLC), to ensure fairness and atomicity. In Step 1, P0P_0 locks the payment into a smart contract with the condition that the funds can only be claimed by revealing k. Additionally, a timeout parameter t is set, after which the funds are refunded to P0P_0 if unclaimed. In Step 2, upon observing the locked funds on the blockchain, P1P_1 submits the key k to the smart contract in order to redeem the payment. Once this transaction is confirmed, k is publicly recorded on the ledger. In Step 3, P0P_0 monitors the blockchain, retrieves k, and uses it to decrypt the ciphertext locally, recovering the plaintext document d1d_1. 1. P0P_0 deposits the compensation funds into a smart contract with the condition: "These funds can be claimed by anyone who provides a preimage k such that (k)=hk HashKey(k)=h_k." (Optionally, if the deposit is not claimed within time t, P0P_0 gets refunded.") 2. P1P_1 sees the funds are locked on the blockchain. To take the money, P1P_1 must submit k to the blockchain as the input to the transaction. Once the transaction is mined, k becomes public on the ledger. 3. P0P_0 observes the blockchain, reads k, and uses it to decrypt c1c_1 locally: d1=.k(c1)d_1= SYM.Dec_k(c_1). Figure 4: Protocol - Transaction 3.2 Security Analysis 3.2.1 Threat Model We consider a malicious adversary model, where parties may arbitrarily deviate from the prescribed protocol in an attempt to gain advantage, rather than merely following the protocol and trying to infer additional information. In particular, adversaries may generate malformed messages, provide inconsistent inputs, or strategically abort the protocol. We consider two types of adversaries: (i) a malicious retrieval agent P0P_0, modeled as aA_a, and (i) malicious data providers P1P_1 or P2P_2, modeled as dA_d. The adversary aA_a aims to obtain the plaintext content of documents (e.g., d1d_1 or d2d_2) without completing the payment, potentially by deviating from the protocol or exploiting intermediate computation results. Conversely, dA_d aims to receive payment without providing the correct document, for example by supplying malformed ciphertexts, incorrect decryption keys, or inconsistent data. We assume that there is no collusion between parties. Furthermore, all underlying cryptographic primitives (THE, symmetric encryption, hash functions, and zk-SNARKs) are assumed to be secure, and the blockchain correctly enforces the semantics of HTLCs. 3.2.2 Security Definition We say the protocol is secure if it satisfies the following properties against any probabilistic polynomial-time adversary: • Confidentiality: No adversary aA_a can learn any information about the plaintext document beyond what is revealed by the final output, unless the payment is completed. • Correctness: If the protocol completes successfully, the document obtained by P0P_0 is exactly the document that was evaluated and selected in Phase 1. • Fairness: Either (i) P0P_0 obtains the correct document and the data provider receives payment, or (i) neither party gains advantage (i.e., no document is revealed and the payment is refunded). • Integrity: The document delivered in the transaction phase must match the document committed during the ranking phase. 3.2.3 Security Analysis We analyze the security of the protocol against both adversaries across the three phases. Security against aA_a (malicious P0P_0). • Phase 1. All documents are protected under threshold homomorphic encryption as ciphertexts ⟦d1⟧ d_1 and ⟦d2⟧ d_2 . Due to the semantic security of THE, aA_a cannot learn any information about the plaintext documents. Moreover, although P0P_0 evaluates the scoring function S and HashDoc, the results remain encrypted and require cooperation from P1P_1 or P2P_2 for decryption. The threshold structure ensures that aA_a alone cannot recover any partial or full plaintext values, including scores or hashes. • Phase 2. The symmetric key k is never revealed to P0P_0 during this phase. Instead, P1P_1 provides a zk-SNARK proof π that attests to the correctness of k without revealing it. By the zero-knowledge property, aA_a learns nothing about k beyond its validity. Therefore, aA_a cannot decrypt c1=.k(d1)c_1= SYM.Enc_k(d_1). • Phase 3. To obtain k, aA_a must trigger the HTLC by locking sufficient funds. Without depositing the payment, aA_a cannot induce P1P_1 to reveal k. Hence, the protocol enforces fairness: P0P_0 obtains the decryption key if and only if payment is made. Security against dA_d (malicious P1P_1 or P2P_2). • Phase 1. The document hash h1h_1 (or h2h_2) is computed by P0P_0 via homomorphic evaluation, ensuring that it is bound to the encrypted document submitted by the data provider. This prevents dA_d from later substituting a different document without detection. • Phase 2. If dA_d attempts to provide an incorrect ciphertext c1′c_1 or a key k′k that does not correspond to the intended document, the zk-SNARK proof will fail. In particular, the proof enforces that: (.k(c1))=h1, HashDoc( SYM.Dec_k(c_1))=h_1, which binds the encrypted content to the previously agreed hash. Therefore, dA_d cannot convince P0P_0 of the validity of an incorrect document. • Phase 3. The HTLC requires revealing the preimage k satisfying (k)=hk HashKey(k)=h_k in order to claim the payment. Since k has already been validated in Phase 2, dA_d must reveal the correct key to obtain the funds. Upon revelation, P0P_0 can immediately decrypt c1c_1 to recover d1d_1. If dA_d refuses to reveal k, the timeout mechanism ensures that the funds are refunded to P0P_0. The protocol satisfies the security definition in Section 3.2.2 against malicious adversaries defined in Section 3.2.1. Confidentiality holds because documents remain encrypted under THE and symmetric encryption, and keys are protected by zero-knowledge proofs until payment is made. Correctness and integrity follow from the binding between ciphertexts and hashes enforced by HashDoc and the zk-SNARK proof, ensuring that the delivered document matches the one evaluated in Phase 1. Fairness is guaranteed by the HTLC mechanism, which enforces atomic exchange: the data provider can only obtain payment by revealing the valid key, and otherwise the payment is refunded. 4 Practical Challenges and Implementation Choices While the proposed protocol provides strong security and fairness guarantees at the theoretical level, translating these cryptographic components into a practical system introduces several non-trivial engineering and performance challenges. In this section, we discuss the major implementation choices and practical trade-offs encountered in realizing the protocol. 4.1 HE schemes THE provides flexibility for privacy-preserving computation, but the choice of the underlying homomorphic encryption scheme significantly affects both functionality and performance. Different HE schemes are optimized for different types of operations. For example, BGV is well suited for exact integer arithmetic, CKKS is designed for approximate floating-point computation, while FHEW/TFHE Ducas and Micciancio (2015); Chillotti et al. (2020) are optimized for Boolean and logical operations. However, using a single scheme to efficiently support all functionalities required by the protocol is non-trivial. Schemes such as FHEW can theoretically realize arbitrary computations through Boolean circuits, but they are inefficient for arithmetic-heavy workloads because additions and multiplications must be decomposed into large numbers of gate-level operations. In contrast, BGV and CKKS natively support arithmetic operations efficiently, but they do not directly support logical operations or comparisons. Modern neural retrieval or language models typically require non-linear activation functions, which are difficult to evaluate directly under HE. In CKKS-based systems, these functions are usually approximated with low-degree polynomials to reduce multiplicative depth and improve efficiency. Although this makes CKKS attractive for machine learning workloads, it introduces approximation errors and complicates compatibility with cryptographic primitives that rely on exact modular arithmetic. One possible solution is to combine multiple schemes and perform scheme switching during computation. However, scheme switching introduces substantial computational overhead and implementation complexity. An alternative approach is to run different schemes in parallel, which increases memory consumption but avoids repeated switching costs. In our implementation, we prioritize simplicity and compatibility across all protocol phases by using a single scheme throughout the system. Although CKKS would naturally fit similarity scoring due to its support for floating-point arithmetic, it is not well suited for implementing the Poseidon hash function, which relies heavily on exact modular arithmetic over finite fields. Consequently, we adopt the BGV scheme, which supports modular arithmetic directly and integrates more naturally with both Poseidon hashing and threshold decryption. It is important to note that THE is not universally supported for all HE schemes. In practice, threshold variants are available only for selected schemes in existing libraries. For example, some libraries do not provide threshold implementations for FHEW/TFHE. 4.2 Scoring The scoring function used in Phase 1 can, in principle, be any function implementable under homomorphic encryption. Existing research has demonstrated HE-compatible adaptations of modern machine learning models, including neural retrieval systems and transformer-based language models. However, these approaches often require sophisticated approximation techniques and incur substantial computational overhead. In this work, our primary objective is to evaluate the feasibility and system overhead of the proposed protocol rather than optimizing retrieval quality. Therefore, we adopt a lightweight scoring mechanism based on the dot product between vectors. The dot-product operation is directly supported by the BGV scheme and can be evaluated efficiently with low multiplicative depth. This choice enables us to isolate the cryptographic overhead introduced by THE and Poseidon hashing without introducing additional complexity from large neural models. More advanced scoring models can be integrated into the framework in future work as HE implementations continue to improve. 4.3 Hashing The role of hashing in the protocol is to ensure document integrity across different phases. In particular, the hash value computed during the ranking phase binds the selected ciphertext to the final document delivered in the transaction phase, preventing malicious providers from replacing or modifying the content after evaluation. Although SHA-family of Standards and Technology (2015) hash functions are widely used in conventional systems, they are not ideal for zero-knowledge proof systems because they are optimized for bitwise operations, which translate into expensive arithmetic circuits. In contrast, Poseidon Grassi et al. (2021); Grassi et al. (2023) is specifically designed for finite-field arithmetic, where its internal permutation consists mainly of modular additions, multiplications, and exponentiations. Compared to traditional hash functions such as SHA-family, Poseidon requires significantly fewer arithmetic constraints in zk-SNARK circuits, making proof generation and verification substantially more efficient for ZKP systems. Theoretically, Poseidon should also integrate naturally with HE because its internal operations are arithmetic-based rather than Boolean-based. Nevertheless, implementing Poseidon efficiently under HE introduces practical challenges. In many HE implementations, the maximum supported ciphertext modulus is limited bits. However, Poseidon typically relies on large prime fields to achieve the desired security level. To address this limitation, we employ the Chinese Remainder Theorem (CRT) Ding et al. (1996) technique. CRT decomposes computations over a large modulus into several smaller moduli that fit within the supported ciphertext space. In our implementation, large inputs are partitioned into multiple CRT components, each represented with a relatively small but HE compatible modulus. Although CRT increases the number of ciphertexts and homomorphic operations, it enables practical Poseidon evaluation under current HE constraints while preserving compatibility with the zk-SNARK verification phase. 4.4 Symmetric Encryption A natural approach for delivering document to P0P_0 would be to reuse the keys and ciphers of THE from Phase 1. For example, the data provider could partially decrypt the encrypted document and allow P0P_0 to complete the decryption collaboratively. However, such a design is impractical for two main reasons: First, public-key cryptographic systems, including HE schemes, incur significantly higher computational overhead than symmetric encryption. Using HE for full document transfer would therefore introduce unnecessary performance costs, especially for large documents. Second, implementing homomorphic encryption primitives directly inside zero-knowledge proof systems is highly inefficient and lacks mature tooling support. Existing zk-SNARK frameworks are much better optimized for symmetric cryptographic primitives than for lattice-based HE operations. Reproducing the correctness of HE decryption inside a ZKP circuit would substantially increase circuit complexity and proving time. For these reasons, we separate the confidential computation phase from the document transfer phase. After ranking and verification, the selected document is encrypted using a standard symmetric encryption scheme with a randomly generated key k. The correctness of this encryption is then verified through a zk-SNARK proof, while the key itself is released fairly through the HTLC mechanism. This design allows the protocol to leverage the strengths of both cryptographic paradigms: HE enables privacy-preserving ranking and evaluation, while symmetric encryption provides efficient large-scale data transfer and seamless integration with zero-knowledge proofs. 4.5 Transaction From a practical standpoint, the core problem this work addresses is the fair exchange of digital goods for payment: a client wishes to purchase an encrypted document from a provider, but neither party is willing to act first without a guarantee of reciprocation. If the client pays first, the provider may never deliver the decryption key. If the provider reveals the key first, the client may refuse to pay. This is a classical instance of the fair exchange problem, and traditional solutions require a trusted third party to act as an escrow, introducing a single point of failure and a trust assumption that is undesirable in a decentralized setting. The HTLC resolves this by replacing the trusted third party with cryptographic guarantees enforced directly by the blockchain. The client locks the agreed payment in the HTLC against the hashlock h=Poseidon(K)h=Poseidon(K), using the createLock function. The provider is then incentivized to call withdraw and reveal K on-chain to collect the payment. The moment withdraw is executed, K becomes publicly visible in the transaction data, allowing the client to retrieve it and decrypt the document. The two actions, payment release and key revelation, are thus collapsed into a single atomic transaction, making it impossible for one to occur without the other. If the provider fails to act before the timelock expires, the client reclaims their funds via refund, suffering no financial loss. The minLockDuration parameter defines the minimum amount of time that must elapse between the creation of a lock and its expiration. This lower bound ensures that the provider has sufficient time to submit the withdraw transaction after the lock is created, accounting for network latency and block inclusion delays. Without this constraint, a malicious client could create a lock with an expiration set only seconds in the future, making it practically impossible for the provider to reveal the preimage and collect payment before the timelock expires, effectively forcing a refund despite the provider having acted in good faith. The appropriate value for minLockDuration depends on the target network and its expected congestion, on a live network such as Ethereum mainnet, it should be set to a value large enough to comfortably accommodate worst-case block inclusion times. Despite the conceptual simplicity of the HTLC protocol, several practical challenges arise during implementation on Ethereum. The most notable is that the recipient does not receive the exact amount upon withdrawal. Since the withdraw transaction must be submitted and executed on-chain, the gas cost is deducted from the caller’s account, meaning the recipient receives the full locked amount in ETH, but their net balance increased is slightly less than expected due to the gas fee paid to execute the transaction. This is an inherent property of the EVM execution model and not a flaw in the contract logic. A second challenge is the time-sensitivity of the protocol: the recipient must submit the withdraw transaction before the lock expires, which can be problematic during periods of network congestion when transactions may be delayed or gas prices may spike, potentially forcing the recipient to pay a higher fee to ensure timely inclusion. Finally, the deployment of the Poseidon hash function itself presents a practical challenge, as Poseidon is not a native EVM opcode. Its Solidity implementation must be deployed as a separate library and linked to the contract at deployment time, adding complexity to the deployment process compared to contracts that rely solely on built-in hash functions such as SHA-256. 5 Evaluation 5.1 Settings The primary objective of the evaluation is to analyze the performance characteristics and computational overhead of the proposed protocol. To achieve a controlled and reproducible experimental environment, we use randomly generated data as protocol inputs. This approach enables systematic testing across different configurations while avoiding biases introduced by application-specific datasets. In Phase 1, THE is implemented using the Python interface of OpenFHE Al Badawi et al. (2022), which provides Python bindings for the core cryptographic functionalities of the OpenFHE C++ library. The protocol is implemented based on the BGV homomorphic encryption scheme operating in multi-party threshold mode. In Phase 2, the zero-knowledge proof (ZKP) component is implemented using Circom Bellés-Muñoz et al. (2022), a domain-specific language designed for constructing arithmetic circuits for zk-SNARK systems. Circom includes a compiler that generates Rank-1 Constraint System (R1CS) representations together with the corresponding circuit constraints and witness generation programs. For proof generation and verification, we adopt the Groth16 Groth (2016) zk-SNARK protocol due to its efficiency in proof size and verification cost. In Phase 3, we evaluate the proposed hash time-locked contract (HTLC) implementation based on the Poseidon hash function. The benchmark results are collected over 20 independent runs on both a local Hardhat network 33 3 https://w.hardhat.org/ and the Sepolia Ethereum testnet 44 4 https://github.com/eth-clients/sepolia. The local Hardhat environment is used to isolate and measure the computational overhead of smart contract execution under controlled conditions, eliminating the influence of network latency, block production intervals, and congestion. In contrast, the Sepolia testnet provides performance measurements under realistic deployment conditions on a live proof-of-stake Ethereum network. Unless otherwise specified, all experiments are conducted under the minimal deployment setting consisting of two data providers (P1P_1 and P2P_2) and one retrieval agent (P0P_0). Extending the protocol to additional participants does not introduce fundamental changes to the protocol workflow; instead, the resulting computational and communication overhead scales approximately linearly with the number of participating agents. 5.2 Phase 1 In the first phase of the protocol, we evaluate the impact of input size on the overall execution time. The input length ranges from 2 bytes to 32 bytes. For inputs smaller than the supported ciphertext capacity, the plaintext is padded to the nearest feasible size before encryption and evaluation. Due to the limitation that the homomorphic encryption scheme supports ciphertext moduli of at most 60 bits in OpenFHE, only the 2-byte and 4-byte inputs can be processed directly using a native Poseidon hash implementation under homomorphic encryption (HE). For larger inputs, namely 8B, 16B, and 32B, we adopt a CRT-based encoding strategy. In these settings, each CRT modulus is configured with a 32-bit decomposition size, resulting in CRT counts of 2, 4, and 8, respectively. To better understand the computational overhead introduced at each stage of the protocol, we measure the execution time of every individual step. As shown in Table 1, the Poseidon hash evaluation dominates the total runtime across all configurations. For smaller inputs (2B and 4B), the hash computation cost remains relatively close because both cases are processed directly without CRT decomposition. However, when the input size increases and CRT encoding is introduced, the evaluation time grows significantly. Despite this increase, the runtime scales approximately linearly with respect to both the input length and the number of CRT components. This observation also motivates the choice of a 32-bit CRT basis. Compared with a 16-bit CRT configuration, the 32-bit setting introduces only a marginal increase in computational overhead while reducing the required CRT count by half, thereby improving overall efficiency. Similar scaling behavior can also be observed in the key generation and encryption stages. For the scoring stage, we evaluate only a lightweight dot-product operation. Consequently, the computation time for scoring remains negligible across all input sizes. Likewise, the decryption phase, including both partial decryption and fusion operations, incurs only minimal overhead and remains consistently fast throughout the experiments. Table 1: Execution time of each step in Phase 1 of the protocol, measured in seconds. The table reports the runtime overhead for different input sizes ranging from 2B to 32B. Larger inputs are processed using CRT decomposition, which increases the number of ciphertext components and consequently the homomorphic evaluation cost. Poseidon hash evaluation is the dominant bottleneck, while scoring and decryption-related operations remain lightweight across all configurations. Steps 2B 4B 8B 16B 32B Key generation 1.49 1.52 4.16 8.01 15.92 Encryption 0.22 0.23 0.81 1.71 3.27 Evaluation - Scorer 0.02 0.03 0.04 0.04 0.04 Evaluation - Hash 6.59 7.10 22.10 44.96 86.72 P0P_0’s partial decrypt 0.04 0.05 0.05 0.05 0.11 P1/P2P_1/P_2’s partial decrypt 0.04 0.05 0.05 0.05 0.10 P0P_0’s fusion 0.01 0.01 0.01 0.01 0.01 P1/P2P_1/P_2’s fusion 0.01 0.01 0.01 0.01 0.01 5.3 Phase 2 Table 2: Relations between input sizes vs Power of Tau. AES input size (byte) 16 32 48 64 80 p (2p2^p) 16 16 17 17 18 ptau file size (MB) 73 73 145 145 289 Non-linear constraints 27856 45632 63408 81184 98960 Linear constraints 14275 19334 24393 29452 34511 Total constraints 42131 64996 87801 110636 133471 Public inputs (bits) 130 258 386 514 642 Private inputs (bits) 256 256 256 256 256 The Phase 2 verification circuit is implemented in Circom and instantiated using the Groth16 zk-SNARK protocol. The circuit takes four logical inputs: three public inputs and one private input. The public inputs consist of the hash of the symmetric key ((k) HashKey(k)), the hash of the document ((d1) HashDoc(d_1)), and the AES ciphertext c1c_1 of the document. The private input is the symmetric key k. Note that the ciphertext is encoded as multiple field elements, which can be adjusted according to the document size. Groth16 requires a trusted setup consisting of two phases. The first phase, known as the Powers of Tau, is circuit-independent and can be reused across different circuits. The output is a ptau file. The second phase is circuit-specific and depends on the compiled constraint system, i.e., R1CS in our settings. A key parameter in the setup is 2p2^p, which determines the maximum number of constraints supported in the circuit. For correctness, the total number of constraints in the circuit must be strictly less than 2p2^p. As shown in Table 2, larger document sizes lead to larger circuits, requiring higher values of p. As the AES input size increases, the number of constraints grows approximately linearly. This is expected, as both AES decryption and hash computation are applied over the entire input. Consequently, the required Power of Tau parameter increases stepwise (e.g., from 2162^16 to 2182^18), which in turn increases the size of the ptau file and proving keys. The most computationally expensive component is the generation of the ptau file. While this step takes only seconds for small p, it can take several hours for larger values. However, this cost is incurred only once and can be amortized across multiple circuits and deployments. In contrast, the circuit-specific Phase 2 setup and proof generation both complete within seconds in our experiments. The time cost of the verification of the proof is also negligible. The size of the private input remains constant across all configurations, as the AES key has a fixed length. In contrast, the number of public inputs scales with the ciphertext size, since the encrypted document is provided as part of the statement. Due to the use of AES in CTR mode within Circom, the input size must be a multiple of the block size (16 bytes). Documents that do not align with this requirement are padded to the nearest multiple. 5.4 Phase 3 To better quantify the practical overhead introduced by adopting Poseidon as the hash function, a comparison is drawn against a reference SHA-256-based HTLC implementation55 5 https://github.com/chatch/hashed-timelock-contract-ethereum. Since Poseidon is not a native EVM opcode and must be deployed as an external library 66 6 https://w.npmjs.com/package/poseidon-solidity , while SHA-256of Standards and Technology (2015) is directly supported as a precompile, this comparison establishes whether the ZK-friendliness of Poseidon comes at a meaningful cost in terms of gas consumption and execution latency, or whether it can be adopted without significant practical penalty. Gas Consumption Gas is the unit of measurement for the computational work required to execute operations on the Ethereum network. Every instruction executed by the EVM has an associated gas cost, and the total gas consumed by a transaction reflects the sum of all operations performed during its execution. Users specify a gas price, denominated in gwei, where 11 gwei =10−9=10^-9 ETH, that they are willing to pay per unit of gas, and the total transaction fee is computed as the product of gas consumed and the gas price. Since gas prices fluctuate with network demand, the same contract interaction can cost significantly different amounts in USD depending on current network conditions. For this reason, gas consumption is a more stable and implementation-specific metric than transaction fee, and is therefore used as the primary basis for comparing the two implementations in this work. Table 3 summarizes the gas consumption of each contract method for both implementations. To ensure a fair cost comparison, all USD values are recomputed using a unified gas price of 0.147540.14754 gwei and an ETH price of 2311.802311.80 USD/ETH. Table 3: Gas consumption comparison between Poseidon-based and SHA-256-based HTLC implementations. Method Avg Gas Avg Cost (USD) Poseidon SHA-256 Poseidon SHA-256 createLock 141,133 142,473 0.0481 0.0486 withdraw 75,230 86,896 0.0256 0.0296 refund 57,168 61,636 0.0194 0.0210 Deployment 721,122 725,895 0.2459 0.2476 The results reveal that the Poseidon-based implementation consumes slightly less gas than the SHA-256 counterpart for all transactional methods. Specifically, withdraw, the most cryptographically intensive operation, as it involves on-chain hash verification, consumes 75,230 gas under Poseidon compared to 86,896 gas under SHA-256, a reduction of approximately 13.4%. Similarly, createLock and refund show marginal gas savings of 0.9% and 7.2%, respectively. These savings are consistent with Poseidon’s design goal of being more efficient than traditional hash functions within arithmetic-circuit-friendly execution environments. The deployment cost of the Poseidon-based implementation is 721,122 gas compared to 725,895 gas for the SHA-256 baseline, a marginal difference of approximately 0.7% in favor of the Poseidon-based implementation. This slight reduction is attributable to the struct packing and storage layout optimizations introduced in the contract, which reduced the deployed bytecode size despite the additional overhead of linking the PoseidonT2 library at deployment time. It is important to note that the USD costs reported above are computed under fixed network conditions and serve as a reference point only. In practice, transaction fees on Ethereum are a function of two volatile quantities: the gas price, which fluctuates with network load and congestion, and the ETH/USD exchange rate. During periods of high network activity, gas prices can increase by several orders of magnitude, making even gas-efficient contracts significantly more expensive to interact with. Conversely, the gas consumption figures reported in Table 3 are deterministic and independent of market conditions, providing a stable basis for comparing the two implementations. Execution Latency on Local Network Table 4 reports the average execution latency of the two primary contract interactions measured over 20 runs on a local Hardhat network. Table 4: Execution latency on local Hardhat network (20 runs). Method Avg Latency (ms) Std Dev (ms) Poseidon SHA-256 Poseidon SHA-256 createLock 80.85 82.80 9.69 10.33 withdraw 91.25 83.05 8.31 9.21 refund 79.50 82.30 7.34 8.93 The Poseidon-based implementation exhibits comparable latency to the SHA-256 baseline on the local network, with results varying by method. createLock averages 80.85 ms compared to 82.80 ms under SHA-256, and refund averages 79.50 ms compared to 82.30 ms, both marginally faster than the baseline. withdraw is the only method where Poseidon exhibits slightly higher latency, averaging 91.25 ms compared to 83.05 ms under SHA-256, which is attributable to the additional computational overhead of the Poseidon permutation during hash verification and the external library call to PoseidonT2. Notably, the standard deviations of the Poseidon implementation are lower than those of the SHA-256 baseline across all methods, suggesting more consistent execution behavior. Overall, these results indicate that the overhead of adopting Poseidon over SHA-256 is negligible in a local execution environment, with the two implementations performing at comparable levels across all three contract methods. It should be noted that latency measurements on a local Hardhat network reflect only the computational cost of transaction execution, as block times are instantaneous and there is no network propagation delay, making this an accurate isolated measure of the hash function overhead itself. Execution Latency on Sepolia Testnet To obtain timing results reflective of real-world network conditions, the benchmark was additionally executed on the Sepolia Ethereum testnet. Table 5 presents the results. Table 5: Execution latency on Sepolia testnet (20 runs). Method Avg Latency (ms) Std Dev (ms) createLock 14,300.95 3,429.41 withdraw 10,675.15 3,044.74 refund 16,533.10 5,449.27 The Sepolia results are markedly different from the local measurements, with average latencies of 14.3 seconds for createLock, 10.7 seconds for withdraw, and 16.5 seconds for refund. This substantial increase is primarily explained by Ethereum’s block time: unlike the local Hardhat network, where transactions are mined instantly, Sepolia operates with a block time of approximately 12 seconds under the proof-of-stake consensus mechanism. A submitted transaction must wait to be included in the next block, meaning the observed latency is dominated by this waiting period rather than by the computational cost of executing the contract logic itself. The high standard deviations observed across all three methods further reflect the non-deterministic nature of block inclusion on a real network. Depending on when a transaction is submitted relative to the current block, the waiting time can vary between near-zero and a full block interval. Moreover, these figures represent average behavior under moderate network conditions, during periods of high congestion, latencies can increase substantially beyond what is reported here, as transactions offering lower gas prices may be deprioritized by block proposers in favor of more profitable ones. These results confirm that for time-sensitive applications built on top of this HTLC, the minimum lock duration parameter minLockDuration must be set with sufficient margin to account for realistic block inclusion delays and potential network congestion on the target network. 6 Conclusion In this paper, we proposed a fairly compensated protocol for distributed information retrieval and augmentation in autonomous agent networks. The protocol addresses the fundamental evaluation-disclosure paradox by enabling retrieval agents to evaluate and rank candidate documents without learning their plaintext contents, while simultaneously guaranteeing that data providers are compensated only when valid information is successfully delivered. To achieve this, we orchestrate threshold homomorphic encryption, zero-knowledge proofs, and blockchain-based hash time-locked contracts into a unified multi-phase framework, which provides confidentiality, correctness, integrity, and fairness against malicious adversaries. As autonomous agents increasingly depend on distributed external information sources, we believe such mechanisms will become essential for enabling trustworthy and economically sustainable data marketplaces. References Acar et al. (2018) A. Acar, H. Aksu, A. S. Uluagac, and M. Conti A survey on homomorphic encryption schemes: theory and implementation. ACM Computing Surveys (Csur) 51 (4), p. 1–35. Cited by: §2.2. Al Badawi et al. (2022) A. Al Badawi, J. Bates, F. Bergamaschi, D. B. Cousins, S. Erabelli, N. Genise, S. Halevi, H. Hunt, A. Kim, Y. Lee, et al. Openfhe: open-source fully homomorphic encryption library. In proceedings of the 10th workshop on encrypted computing & applied homomorphic cryptography, p. 53–63. Cited by: §5.1. Anthropic (2026) Anthropic Claude (version 3.5 sonnet). Note: https://claude.ai Cited by: §1. Arslan et al. (2024) M. Arslan, H. Ghanem, S. Munawar, and C. Cruz A survey on rag with llms. Procedia computer science 246, p. 3781–3790. Cited by: §1. Asai et al. (2024) A. Asai, Z. Wu, Y. Wang, A. Sil, and H. Hajishirzi Self-rag: learning to retrieve, generate, and critique through self-reflection. arXiv preprint arXiv:2310.11511. External Links: Link Cited by: §2.5. Bellés-Muñoz et al. (2022) M. Bellés-Muñoz, M. Isabel, J. L. Muñoz-Tapia, A. Rubio, and J. Baylina Circom: a circuit description language for building zero-knowledge applications. IEEE Transactions on Dependable and Secure Computing 20 (6), p. 4733–4751. Cited by: §5.1. Bitansky et al. (2012) N. Bitansky, R. Canetti, A. Chiesa, and E. Tromer From extractable collision resistance to succinct non-interactive arguments of knowledge, and back again. In Proceedings of the 3rd innovations in theoretical computer science conference, p. 326–349. Cited by: §2.3. Brakerski et al. (2014) Z. Brakerski, C. Gentry, and V. Vaikuntanathan (Leveled) fully homomorphic encryption without bootstrapping. ACM Transactions on Computation Theory (TOCT) 6 (3), p. 1–36. Cited by: §2.2. Buterin et al. (2013) V. Buterin et al. Ethereum white paper. GitHub repository 1 (22-23), p. 5–7. Cited by: §2.4. Cheon et al. (2017) J. H. Cheon, A. Kim, M. Kim, and Y. Song Homomorphic encryption for arithmetic of approximate numbers. In Advances in Cryptology–ASIACRYPT 2017: 23rd International Conference on the Theory and Applications of Cryptology and Information Security, Hong Kong, China, December 3-7, 2017, Proceedings, Part I 23, p. 409–437. Cited by: §2.2. Chillotti et al. (2020) I. Chillotti, N. Gama, M. Georgieva, and M. Izabachène TFHE: fast fully homomorphic encryption over the torus: i. chillotti et al.. Journal of Cryptology 33 (1), p. 34–91. Cited by: §4.1. Cramer et al. (2001) R. Cramer, I. Damgård, and J. B. Nielsen Multiparty computation from threshold homomorphic encryption. In International conference on the theory and applications of cryptographic techniques, p. 280–300. Cited by: §2.2. Cuconasu et al. (2024) F. Cuconasu, G. Trappolini, F. Siciliano, S. Filice, C. Campagnano, Y. Maarek, N. Tonellotto, and F. Silvestri The power of noise: redefining retrieval for rag systems. In Proceedings of the 47th International ACM SIGIR Conference on Research and Development in Information Retrieval, p. 719–729. Cited by: §1. Dannen et al. (2017) C. Dannen et al. Introducing ethereum and solidity. Vol. 1, Springer. Cited by: §2.4. Desmedt (2011) Y. Desmedt Threshold cryptography. In Encyclopedia of Cryptography and Security, H. C. A. van Tilborg and S. Jajodia (Eds.), p. 1288–1293. External Links: ISBN 978-1-4419-5906-5, Document, Link Cited by: §2.2. Ding et al. (1996) C. Ding, D. Pei, and A. Salomaa Chinese remainder theorem: applications in computing, coding, cryptography. World Scientific. Cited by: §4.3. Ducas and Micciancio (2015) L. Ducas and D. Micciancio FHEW: bootstrapping homomorphic encryption in less than a second. In Annual international conference on the theory and applications of cryptographic techniques, p. 617–640. Cited by: §4.1. Durante et al. (2024) Z. Durante, Q. Huang, N. Wake, R. Gong, J. S. Park, B. Sarkar, R. Taori, Y. Noda, D. Terzopoulos, Y. Choi, et al. Agent ai: surveying the horizons of multimodal interaction. arXiv preprint arXiv:2401.03568. Cited by: §1. Fan and Vercauteren (2012) J. Fan and F. Vercauteren Somewhat practical fully homomorphic encryption. Cryptology ePrint Archive. Cited by: §2.2. Fiege et al. (1987) U. Fiege, A. Fiat, and A. Shamir Zero knowledge proofs of identity. In Proceedings of the nineteenth annual ACM symposium on Theory of computing, p. 210–217. Cited by: §2.3. Fontaine and Galand (2007) C. Fontaine and F. Galand A survey of homomorphic encryption for nonspecialists. EURASIP Journal on Information Security 2007, p. 1–10. Cited by: §2.2. Google (2026) Google Gemini (version 1.5 pro). Note: https://gemini.google.com Cited by: §1. Grassi et al. (2021) L. Grassi, D. Khovratovich, C. Rechberger, A. Roy, and M. Schofnegger Poseidon: a new hash function for \zero-knowledge\ proof systems. In 30th USENIX Security Symposium (USENIX Security 21), p. 519–535. Cited by: §4.3. Grassi et al. (2023) L. Grassi, D. Khovratovich, and M. Schofnegger Poseidon2: a faster version of the poseidon hash function. In International Conference on Cryptology in Africa, p. 177–203. Cited by: §4.3. Groth (2016) J. Groth On the size of pairing-based non-interactive arguments. Note: Cryptology ePrint Archive, Paper 2016/260 External Links: Link Cited by: §5.1. Herlihy (2018) M. Herlihy Atomic cross-chain swaps. In Proceedings of the 2018 ACM symposium on principles of distributed computing, p. 245–254. Cited by: §2.4. Hughes et al. (2025) L. Hughes, Y. K. Dwivedi, T. Malik, M. Shawosh, M. A. Albashrawi, I. Jeon, V. Dutot, M. Appanderanda, T. Crick, R. De’, et al. AI agents and agentic systems: a multi-expert analysis. Journal of Computer Information Systems 65 (4), p. 489–517. Cited by: §1. Java et al. (2025) A. Java, S. Koundinyan, N. Natarajan, and A. Sharma FrugalRAG: learning to retrieve and reason for multi-hop qa. arXiv preprint arXiv:2507.07634. Cited by: §2.5. Jeong et al. (2024) S. Jeong et al. Adaptive-rag: learning to adapt retrieval-augmented large language models through question complexity. arXiv preprint arXiv:2403.14403. External Links: Link Cited by: §2.5. Lewis et al. (2020) P. Lewis, E. Perez, A. Piktus, F. Petroni, V. Karpukhin, N. Goyal, H. Küttler, M. Lewis, W. Yih, T. Rocktäschel, S. Riedel, and D. Kiela Retrieval-augmented generation for knowledge-intensive nlp tasks. In Advances in Neural Information Processing Systems (NeurIPS), External Links: Link Cited by: §2.5. Li et al. (2023) G. Li, H. A. A. K. Hammoud, H. Itani, D. Khizbullin, and B. Ghanem CAMEL: communicative agents for "mind" exploration of large language model society. arXiv preprint arXiv:2303.17760. External Links: Link Cited by: §2.5. Nofer et al. (2017) M. Nofer, P. Gomber, O. Hinz, and D. Schiereck Blockchain. Business & information systems engineering 59 (3), p. 183–187. Cited by: §2.4. of Standards and Technology (2015) N. I. of Standards and Technology FIPS 180-4: secure hash standard (SHS). Federal Information Processing Standards Publication Technical Report 180-4, National Institute of Standards and Technology. External Links: Document, Link Cited by: §4.3, §5.4. OpenAI (2026) OpenAI ChatGPT (version 4o). Note: https://chat.openai.com Cited by: §1. Park et al. (2023) J. S. Park, J. O’Brien, C. J. Cai, M. R. Morris, P. Liang, and M. S. Bernstein Generative agents: interactive simulacra of human behavior. In Proceedings of the 36th annual acm symposium on user interface software and technology, p. 1–22. Cited by: §2.5. Parno et al. (2016) B. Parno, J. Howell, C. Gentry, and M. Raykova Pinocchio: nearly practical verifiable computation. Communications of the ACM 59 (2), p. 103–112. Cited by: §2.3. Schick et al. (2023) T. Schick, J. Dwivedi-Yu, R. Dessì, R. Raileanu, M. Lomeli, E. Hambro, L. Zettlemoyer, N. Cancedda, and T. Scialom Toolformer: language models can teach themselves to use tools. arXiv preprint arXiv:2302.04761. External Links: Link Cited by: §2.5. Wadhwa et al. (2023) A. Wadhwa et al. He-htlc: revisiting incentives in hashed timelock contracts. In Network and Distributed System Security Symposium (NDSS), External Links: Link Cited by: §2.5. Wu et al. (2023) Q. Wu, G. Bansal, J. Zhang, Y. Wu, B. Li, E. Zhu, L. Jiang, X. Zhang, S. Zhang, J. Liu, A. H. Awadallah, R. W. White, D. Burger, and C. Wang AutoGen: enabling next-gen llm applications via multi-agent conversation. External Links: 2308.08155, Link Cited by: §2.5. Yan et al. (2024) S. Yan et al. CRAG: corrective retrieval augmented generation. arXiv preprint arXiv:2401.15884. External Links: Link Cited by: §2.5. Yao et al. (2022) S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao ReAct: synergizing reasoning and acting in language models. arXiv preprint arXiv:2210.03629. External Links: Link Cited by: §2.5. Yao et al. (2026) Y. Yao, Y. Yao, X. Fan, J. Gao, J. Wang, M. Zhang, S. Ravi, and C. Joe-Wong Trustworthy agent network: trust in agent networks must be baked in, not bolted on. In Proceedings of the 32nd ACM SIGKDD Conference on Knowledge Discovery and Data Mining V. 2, p. 13252–13258. Cited by: §1. Zhang et al. (2024) T. Zhang, S. G. Patil, N. Jain, S. Shen, M. Zaharia, I. Stoica, and J. E. Gonzalez Raft: adapting language model to domain specific rag. arXiv preprint arXiv:2403.10131. Cited by: §1. Zheng et al. (2018) Z. Zheng, S. Xie, H. Dai, X. Chen, and H. Wang Blockchain challenges and opportunities: a survey. International journal of web and grid services 14 (4), p. 352–375. Cited by: §2.4.