Fairly Compensated Distributed Information Retrieval and Augmentation for AI Agents
arXiv:2609.22601v1 [cs.ET] 18 Sep 2026
Yixiang Yao Pasha Barahimi Srivatsan Ravi University of Southern California {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) [34, 22, 3] and autonomous AI agents [27, 18] 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) [4, 13, 43] 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 privacysensitive) is rarely centralized. Instead, it is distributed across a heterogeneous network of data providers, ranging from institutional repositories to specialized edge-agent nodes [42]. 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. Preprint. Under review.
Trust the agent?
Current Methods and Issues
Not paid
Fee
Query
Trusted Data Provider
Document
Trust the data provider?
Agent
Irrelevant document / Junk
Trusted Third Party
Distributed Non-Verified Data Providers
Monopolies
Trust Issues
Proposed Solution
No need of me :-( Say goodbye to unnecessary fees
No worries of data leak but no payment Secure Protocol
Rank from multiple sources first, then select the best. No junk anymore.
Fairly Compensated, and Fully Distributed
Figure 1: Illustration of current methods and the proposed solution. 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. 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 “deliveryversus-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 evaluationdisclosure 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 S = {s1 , s2 , . . . , sn } and a set of m autonomous agents C = {c1 , c2 , . . . , cm }. Retrieval An agent ci ∈ C initiates a query q ∈ {0, 1}∗ directed to a subset of providers S ′ ⊆ S. Each provider sj ∈ S ′ identifies a candidate response dj from their local knowledge base Kj : dj = Retrieve(q, Kj ) 2
(1)
Each sj transforms dj into a form T (dj ) that hides the plaintext content from the agent ci but is able to evaluate with. Qualification The agent ci can verify if dj is qualified for q without learning its plaintext with the function Q, that is, ∀sj ∈ S ′ , ci verifies Q(T (dj ), q) ∈ {0, 1}. (2) Settlement Based on the results, ci 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 ci and each selected provider sj . For a payment pj ∈ P ∗ and document dj ∈ D∗ , the final state transition must be: (ci ← dj , sj ← pj ) if both parties are honest Statefinal = (3) (ci ←⊥, sj ←⊥) if either party aborts This exchange is conducted without a trusted third party. This ensures that the agent cannot recover dj unless the payment pj is committed to the provider, and the provider cannot claim pj without revealing a dj . 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) [1, 21] 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 on the underlying messages through a corresponding operator ⊕C on their ciphertexts. If ct1 = Enc(m1 ) and ct2 = Enc(m2 ), then: Dec(ct1 ⊕C ct2 ) = m1 ⊕M m2 (4) In concrete implementations, ⊕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: • HE.KeyGenϵ (1λ ) → (pk, sk): Given a security parameter λ, the algorithm generates a public key pk for encryption and evaluation, a secret key sk for decryption. • HE.Encϵ (pk, m) → ct: Encrypts a plaintext message m into a ciphertext ct using the public key. • HE.Decϵ (sk, ct) → m: Recovers the original message m from the ciphertext using the secret key. • HE.Evalϵ (pk, f, {ct1 , . . . , ctn }) → cteval : Takes the public key pk, a function f (represented as a boolean or arithmetic circuit), and a set of ciphertexts, producing a ciphertext cteval 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 [19] and BGV [8] schemes are optimized for exact integer arithmetic, and the CKKS scheme [10] is designed for approximate arithmetic on real or complex numbers. To further enhance security in distributed environments, Threshold Homomorphic Encryption (THE) [15, 12] extends these schemes into a multi-party setting. In THE, the secret key sk is not held by a single entity but is instead divided into n shares {sk1 , sk2 , . . . , skn } distributed among multiple participants. Decryption requires a threshold of parties (t ≤ 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. • THE.KeyGenLeadϵ (1λ , t, n) → (pk1 , sk1 ): The initial party P1 generates a base key pair. 3
• THE.KeyGenMainϵ (pkj−1 , . . . ) → (pkjoint , skj ): Subsequent parties Pj generate their own secret shares skj and iteratively update the joint public key pkjoint . • THE.DecryptLeadϵ (sk1 , ct) → ctp1 : The designated lead party initiates the decryption process by applying their secret share sk1 to the ciphertext ct. This produces a partially decrypted ciphertext component ctp1 . • THE.DecryptMainϵ (skj , ct) → ctpj : All other participating parties Pj independently compute their partial decryption shares ctpj using their respective secret shares skj . • THE.DecryptFusionϵ ({ctp1 , . . . , ctpt }) → 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) [20] 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) ∈ R. A robust ZKP system must satisfy three fundamental properties: • Completeness: If (x, w) ∈ R 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(λ). / R, no malicious prover P ∗ can convince the verifier that the statement is • Soundness: If (x, w) ∈ true, except with a negligible probability: Pr[⟨P ∗ , V ⟩(x) = accept] ≤ negl(λ) • Zero-Knowledge: For every probabilistic polynomial-time verifier V ∗ , there exists a polynomialtime Simulator Sim such that for all (x, w) ∈ R: ViewV ∗ [P (w) ↔ V ∗ (x)] ≈ Sim(x), where ≈ denotes computational indistinguishability. In this work, we specifically leverage Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge (zk-SNARKs) [7, 36]. 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) or O(poly log |w|), and the verification time is significantly faster than executing the underlying computation. 2.4
Blockchain and Smart Contracts
A blockchain [44] 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 [32] 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 [9] 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 [14], a statically typed, contract-oriented programming language that compiles to EVM bytecode. A Hashed Timelock Contract (HTLC) [26] 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. 4
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 [30] combine parametric language models with non-parametric retrieval systems to improve factuality and knowledge coverage. More recently, autonomous agent frameworks including ReAct [41], Toolformer [37], and AutoGen [39] 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 [5], CRAG [40], Adaptive-RAG [29], and FrugalRAG [28] 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 1 and Fetch.ai 2 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 [31] and Generative Agents [35] 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 [38] 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 P0 , and there are two data providers P1 and P2 . In practice, there could be more than two data providers. Phase 1: Ranking 1 2
https://oceanprotocol.com/ https://www.fetch.ai/
5
In Phase 1, P0 issues a query to P1 and P2 to perform retrieval, and subsequently scores and ranks the returned documents without learning their plaintext contents. By the end, P0 knows which document is worth the retrieval. The protocol is illustrated in Figure 2. In Step 1, P0 initiates the distributed THE key generation protocol with P1 and P2 . At the end of this step, each party holds its own private key, while P1 and P2 each establish a joint public key with P0 (i.e., pkjoint1 and pkjoint2 ). In Step 2, P0 sends the query q to both P1 and P2 . In Step 3, P1 and P2 perform retrieval using q, obtain documents d1 and d2 , encrypt them under their respective joint public keys, and return the ciphertexts Jd1 K and Jd2 K to P0 . In Step 4, P0 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 P1 and P2 .
In Step 5, P0 performs partial decryption of the encrypted scores and hashes using its private key, and forwards the partially decrypted results to P1 and P2 . In Step 6, P1 and P2 independently perform their own partial decryptions on the corresponding ciphertexts. In Step 7, P1 and P2 combine their own partial decryption results (from Step 6) with those received from P0 (from Step 5) to recover the plaintext scores and hashes. This step ensures that P0 does not learn any sensitive information during the evaluation of S and HashDoc. If no information leakage is detected, P1 and P2 send their partial decryption shares to P0 . In Step 8, P0 combines its own partial decryption results (from Step 5) with those received from P1 and P2 (from Step 7) to obtain the final plaintext scores and hashes. Finally, in Step 9, P0 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), P0 may terminate the protocol without proceeding to the subsequent phases. Phase 2: Verification Assume that d1 is selected as the preferred document (e.g., s1 > s2 ). Thus, P0 tend to acquire d1 from P1 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, P1 samples a random symmetric key k and encrypts the document d1 to obtain the ciphertext c1 . It also computes a hash of the key as hk . In Step 2, P1 sends (c1 , hk ) to P0 . At this point, P0 possesses c1 , hk ) along with h1 obtained from Phase 1, where h1 is the hash of the target document d1 . However, P0 cannot yet verify whether the hidden key k corresponding to hk correctly decrypts c1 to the intended document d1 . To address this, in Step 3, P1 generates a zk-SNARK proof π demonstrating knowledge of a key k such that k correctly decrypts c1 to the document d1 whose hash matches the value obtained by P0 in Phase 1. In Step 4, P1 sends π to P0 , who verifies the proof. If the verification succeeds, P0 is assured that the ciphertext c1 corresponds to the correct document and k will properly decrypt it. This guarantees the correctness of the forthcoming transaction. Phase 3: Transaction At this stage, P0 proceeds to pay P1 in exchange for the selected document d1 . 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, P0 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 P0 if unclaimed.
6
1. P0 generates (pk0 , sk0 ) ← THE.KeyGenLeadϵ (1λ , 2, 2). t and n are set to 2 to ensure decryption will be successful only when both (P0 , P1 ) or (P0 , P2 ) are involved. P0 shares pk0 with P1 and P2 . P1 and P2 then generate (pkjoint1 , sk1 ) ← THE.KeyGenMainϵ (pk0 ) and (pkjoint2 , sk2 ) ← THE.KeyGenMainϵ (pk0 ), and share pkjoint1 and pkjoint2 to P0 respectively. 2. P0 sends query q to P1 and P2 . 3. P1 and P2 perform retrieval with q and retrieve documents d1 and d2 . They also encrypt both documents to Jd1 K ← HE.Encϵ (pkjoint1 , d1 ) and Jd2 K ← HE.Encϵ (pkjoint2 , d2 ). They send Jd1 K and Jd2 K to P0 . 4. P0 homomorphically executes a scorer S on Jd1 K and Jd2 K, Js1 K ← THE.Evalϵ (pkjoint1 , S, Jd1 K) and Js2 K ← HE.Evalϵ (pkjoint2 , S, Jd2 K), meanwhile homomorphically computes hashes Jh1 K ← THE.Evalϵ (pkjoint1 , HashDoc, Jd1 K), Jh2 K ← THE.Evalϵ (pkjoint2 , HashDoc, Jd2 K). P0 sends (Js1 K, Jh1 K) to P1 and (Js2 K, Jh2 K) to P2 . 5. P0 performs independent partial decryption on scores and hashes: Js1p0 K ← THE.DecryptLeadϵ (sk0 , Js1 K), Jh1p0 K ← THE.DecryptLeadϵ (sk0 , Jh1 K), Js2p0 K ← THE.DecryptLeadϵ (sk0 , Js2 K), Jh2p0 K ← THE.DecryptLeadϵ (sk0 , Jh2 K). P0 sends the partially decrypted results (Js1p0 K, Jh1p0 K) to P1 and (Js2p0 K, Jh2p0 K) to P2 . 6. P1 and P2 perform independent partial decryption: Js1p1 K ← THE.DecryptMainϵ (sk1 , Js1 K), Jh1p1 K ← THE.DecryptMainϵ (sk1 , Jh1 K), Js2p2 K ← THE.DecryptMainϵ (sk2 , Js2 K), Jh2p2 K ← THE.DecryptMainϵ (sk2 , Jh2 K). P1 and P2 send their partially decrypted results to P0 . 7. P1 collects the partial decrypted results and fuses for the final decryption: s1 ← THE.DecryptFusionϵ ({Js1p0 K, Js1p1 K}), h1 ← THE.DecryptFusionϵ ({Jh1p0 K, Jh1p1 K}). P2 can perform the similar operations to get decrypted results: s2 ← THE.DecryptFusionϵ ({Js2p0 K, Js2p2 K}), h2 ← THE.DecryptFusionϵ ({Jh2p0 K, Jh2p2 K}). If the decryption results (s1 , h1 ) and (s2 , h2 ) are with no information leak, P1 and P2 send their partial decrypted results (Js1p1 K, Jh1p1 K) and (Js2p2 K, Jh2p2 K) to P0 . 8. P0 collects the partial decrypted results and fuses for the final decryption: s1 ← THE.DecryptFusionϵ ({Js1p0 K, Js1p1 K}), h1 ← THE.DecryptFusionϵ ({Jh1p0 K, Jh1p1 K}), s2 ← THE.DecryptFusionϵ ({Js2p0 K, Js2p2 K}), h2 ← THE.DecryptFusionϵ ({Jh2p0 K, Jh2p2 K}). 9. P0 compares the score, and picks the best one. P0 also keeps the corresponding hash value in plaintext (either h1 or h2 ) of that document. Figure 2: Protocol - Ranking
In Step 2, upon observing the locked funds on the blockchain, P1 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, P0 monitors the blockchain, retrieves k, and uses it to decrypt the ciphertext locally, recovering the plaintext document d1 . 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 P0 , modeled as Aa , and (ii) malicious data providers P1 or P2 , modeled as Ad . 7
1. With a symmetric encryption algorithm SYM, P1 samples a random symmetric key k and encrypts d1 to obtain c1 = SYM.Enck (d1 ). It also computes hk = HashKey(k). 2. P1 sends c1 , hk to P0 . 3. P1 generates a zk-SNARK proof π: I know k such that (i) HashKey(k) = hk , and (ii) HashDoc(SYM.Deck (c1 )) = h1
(5)
4. P1 sends π to P0 . P0 verifies this proof. If valid, P0 is mathematically certain that the key hidden behind hk is the correct one. Figure 3: Protocol - Verification 1. P0 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 HashKey(k) = hk ." (Optionally, if the deposit is not claimed within time t, P0 gets refunded.") 2. P1 sees the funds are locked on the blockchain. To take the money, P1 must submit k to the blockchain as the input to the transaction. Once the transaction is mined, k becomes public on the ledger. 3. P0 observes the blockchain, reads k, and uses it to decrypt c1 locally: d1 = SYM.Deck (c1 ). Figure 4: Protocol - Transaction The adversary Aa aims to obtain the plaintext content of documents (e.g., d1 or d2 ) without completing the payment, potentially by deviating from the protocol or exploiting intermediate computation results. Conversely, Ad 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 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 P0 is exactly the document that was evaluated and selected in Phase 1. • Fairness: Either (i) P0 obtains the correct document and the data provider receives payment, or (ii) 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 (malicious P0 ). • Phase 1. All documents are protected under threshold homomorphic encryption as ciphertexts Jd1 K and Jd2 K. Due to the semantic security of THE, Aa cannot learn any information about the plaintext documents. Moreover, although P0 evaluates the scoring function S and HashDoc, the results remain encrypted and require cooperation from P1 or P2 for decryption. The threshold 8
structure ensures that Aa alone cannot recover any partial or full plaintext values, including scores or hashes. • Phase 2. The symmetric key k is never revealed to P0 during this phase. Instead, P1 provides a zk-SNARK proof π that attests to the correctness of k without revealing it. By the zeroknowledge property, Aa learns nothing about k beyond its validity. Therefore, Aa cannot decrypt c1 = SYM.Enck (d1 ). • Phase 3. To obtain k, Aa must trigger the HTLC by locking sufficient funds. Without depositing the payment, Aa cannot induce P1 to reveal k. Hence, the protocol enforces fairness: P0 obtains the decryption key if and only if payment is made. Security against Ad (malicious P1 or P2 ). • Phase 1. The document hash h1 (or h2 ) is computed by P0 via homomorphic evaluation, ensuring that it is bound to the encrypted document submitted by the data provider. This prevents Ad from later substituting a different document without detection. • Phase 2. If Ad attempts to provide an incorrect ciphertext c′1 or a key k ′ that does not correspond to the intended document, the zk-SNARK proof will fail. In particular, the proof enforces that: HashDoc(SYM.Deck (c1 )) = h1 , which binds the encrypted content to the previously agreed hash. Therefore, Ad cannot convince P0 of the validity of an incorrect document. • Phase 3. The HTLC requires revealing the preimage k satisfying HashKey(k) = hk in order to claim the payment. Since k has already been validated in Phase 2, Ad must reveal the correct key to obtain the funds. Upon revelation, P0 can immediately decrypt c1 to recover d1 . If Ad refuses to reveal k, the timeout mechanism ensures that the funds are refunded to P0 . 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 [17, 11] 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 9
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 [33] 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 [23, 24] 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) [16] 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 10
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 P0 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 P0 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), 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. 11
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 [2], 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 [6], a domainspecific 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 [25] 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 3 and the Sepolia Ethereum testnet 4 . 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 (P1 and P2 ) and one retrieval agent (P0 ). 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. 3 4
https://www.hardhat.org/ https://github.com/eth-clients/sepolia
12
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 Encryption Evaluation - Scorer Evaluation - Hash P0 ’s partial decrypt P1 /P2 ’s partial decrypt P0 ’s fusion P1 /P2 ’s fusion
1.49 0.22 0.02 6.59 0.04 0.04 0.01 0.01
1.52 0.23 0.03 7.10 0.05 0.05 0.01 0.01
4.16 0.81 0.04 22.10 0.05 0.05 0.01 0.01
8.01 1.71 0.04 44.96 0.05 0.05 0.01 0.01
15.92 3.27 0.04 86.72 0.11 0.10 0.01 0.01
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. 5.3
Phase 2
Table 2: Relations between input sizes vs Power of Tau. AES input size (byte) p
p (2 ) ptau file size (MB) Non-linear constraints Linear constraints Total constraints Public inputs (bits) Private inputs (bits)
16
32
48
64
80
16 73 27856 14275 42131 130 256
16 73 45632 19334 64996 258 256
17 145 63408 24393 87801 386 256
17 145 81184 29452 110636 514 256
18 289 98960 34511 133471 642 256
The Phase 2 verification circuit is implemented in Circom and instantiated using the Groth16 zkSNARK 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 (HashKey(k)), the hash of the document (HashDoc(d1 )), and the AES ciphertext c1 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 13
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 2p , 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 2p . 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 216 to 218 ), 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 implementation5 . Since Poseidon is not a native EVM opcode and must be deployed as an external library 6 , while SHA-256[33] 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 1 gwei = 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.14754 gwei and an ETH price of 2311.80 USD/ETH. Table 3: Gas consumption comparison between Poseidon-based and SHA-256-based HTLC implementations. Method
5 6
Avg Gas
Avg Cost (USD)
Poseidon
SHA-256
Poseidon
SHA-256
createLock withdraw refund
141,133 75,230 57,168
142,473 86,896 61,636
0.0481 0.0256 0.0194
0.0486 0.0296 0.0210
Deployment
721,122
725,895
0.2459
0.2476
https://github.com/chatch/hashed-timelock-contract-ethereum https://www.npmjs.com/package/poseidon-solidity
14
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 createLock withdraw refund
Avg Latency (ms)
Std Dev (ms)
Poseidon
SHA-256
Poseidon
SHA-256
80.85 91.25 79.50
82.80 83.05 82.30
9.69 8.31 7.34
10.33 9.21 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. 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. 15
Table 5: Execution latency on Sepolia testnet (20 runs). Method createLock withdraw refund
Avg Latency (ms)
Std Dev (ms)
14,300.95 10,675.15 16,533.10
3,429.41 3,044.74 5,449.27
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 evaluationdisclosure 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 [1] Abbas Acar, Hidayet Aksu, A Selcuk Uluagac, and Mauro Conti. A survey on homomorphic encryption schemes: Theory and implementation. ACM Computing Surveys (Csur), 51(4):1–35, 2018. [2] Ahmad Al Badawi, Jack Bates, Flavio Bergamaschi, David Bruce Cousins, Saroja Erabelli, Nicholas Genise, Shai Halevi, Hamish Hunt, Andrey Kim, Yongwoo Lee, et al. Openfhe: Open-source fully homomorphic encryption library. In proceedings of the 10th workshop on encrypted computing & applied homomorphic cryptography, pages 53–63, 2022. [3] Anthropic. Claude (version 3.5 sonnet). https://claude.ai, 2026. [4] Muhammad Arslan, Hussam Ghanem, Saba Munawar, and Christophe Cruz. A survey on rag with llms. Procedia computer science, 246:3781–3790, 2024. [5] Akari Asai, Zeqiu Wu, Yizhong Wang, Avi Sil, and Hannaneh Hajishirzi. Self-rag: Learning to retrieve, generate, and critique through self-reflection. arXiv preprint arXiv:2310.11511, 2024. [6] Marta Bellés-Muñoz, Miguel Isabel, Jose Luis Muñoz-Tapia, Albert Rubio, and Jordi Baylina. Circom: A circuit description language for building zero-knowledge applications. IEEE Transactions on Dependable and Secure Computing, 20(6):4733–4751, 2022. [7] Nir Bitansky, Ran Canetti, Alessandro Chiesa, and Eran 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, pages 326–349, 2012. 16
[8] Zvika Brakerski, Craig Gentry, and Vinod Vaikuntanathan. (leveled) fully homomorphic encryption without bootstrapping. ACM Transactions on Computation Theory (TOCT), 6(3):1– 36, 2014. [9] Vitalik Buterin et al. Ethereum white paper. GitHub repository, 1(22-23):5–7, 2013. [10] Jung Hee Cheon, Andrey Kim, Miran Kim, and Yongsoo 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, pages 409–437. Springer, 2017. [11] Ilaria Chillotti, Nicolas Gama, Mariya Georgieva, and Malika Izabachène. Tfhe: Fast fully homomorphic encryption over the torus: I. chillotti et al. Journal of Cryptology, 33(1):34–91, 2020. [12] Ronald Cramer, Ivan Damgård, and Jesper B Nielsen. Multiparty computation from threshold homomorphic encryption. In International conference on the theory and applications of cryptographic techniques, pages 280–300. Springer, 2001. [13] Florin Cuconasu, Giovanni Trappolini, Federico Siciliano, Simone Filice, Cesare Campagnano, Yoelle Maarek, Nicola Tonellotto, and Fabrizio 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, pages 719–729, 2024. [14] Chris Dannen et al. Introducing Ethereum and solidity, volume 1. Springer, 2017. [15] Yvo Desmedt. Threshold Cryptography, pages 1288–1293. Springer US, Boston, MA, 2011. [16] Cunsheng Ding, Dingyi Pei, and Arto Salomaa. Chinese remainder theorem: applications in computing, coding, cryptography. World Scientific, 1996. [17] Léo Ducas and Daniele Micciancio. Fhew: bootstrapping homomorphic encryption in less than a second. In Annual international conference on the theory and applications of cryptographic techniques, pages 617–640. Springer, 2015. [18] Zane Durante, Qiuyuan Huang, Naoki Wake, Ran Gong, Jae Sung Park, Bidipta Sarkar, Rohan Taori, Yusuke Noda, Demetri Terzopoulos, Yejin Choi, et al. Agent ai: Surveying the horizons of multimodal interaction. arXiv preprint arXiv:2401.03568, 2024. [19] Junfeng Fan and Frederik Vercauteren. Somewhat practical fully homomorphic encryption. Cryptology ePrint Archive, 2012. [20] Uriel Fiege, Amos Fiat, and Adi Shamir. Zero knowledge proofs of identity. In Proceedings of the nineteenth annual ACM symposium on Theory of computing, pages 210–217, 1987. [21] Caroline Fontaine and Fabien Galand. A survey of homomorphic encryption for nonspecialists. EURASIP Journal on Information Security, 2007:1–10, 2007. [22] Google. Gemini (version 1.5 pro). https://gemini.google.com, 2026. [23] Lorenzo Grassi, Dmitry Khovratovich, Christian Rechberger, Arnab Roy, and Markus Schofnegger. Poseidon: A new hash function for {Zero-Knowledge} proof systems. In 30th USENIX Security Symposium (USENIX Security 21), pages 519–535, 2021. [24] Lorenzo Grassi, Dmitry Khovratovich, and Markus Schofnegger. Poseidon2: A faster version of the poseidon hash function. In International Conference on Cryptology in Africa, pages 177–203. Springer, 2023. [25] Jens Groth. On the size of pairing-based non-interactive arguments. Cryptology ePrint Archive, Paper 2016/260, 2016. [26] Maurice Herlihy. Atomic cross-chain swaps. In Proceedings of the 2018 ACM symposium on principles of distributed computing, pages 245–254, 2018. 17
[27] Laurie Hughes, Yogesh K Dwivedi, Tegwen Malik, Mazen Shawosh, Mousa Ahmed Albashrawi, Il Jeon, Vincent Dutot, Mandanna Appanderanda, Tom Crick, Rahul De’, et al. Ai agents and agentic systems: A multi-expert analysis. Journal of Computer Information Systems, 65(4):489– 517, 2025. [28] Abhinav Java, Srivathsan Koundinyan, Nagarajan Natarajan, and Amit Sharma. Frugalrag: Learning to retrieve and reason for multi-hop qa. arXiv preprint arXiv:2507.07634, 2025. [29] Soyeong Jeong et al. Adaptive-rag: Learning to adapt retrieval-augmented large language models through question complexity. arXiv preprint arXiv:2403.14403, 2024. [30] Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, Sebastian Riedel, and Douwe Kiela. Retrieval-augmented generation for knowledge-intensive nlp tasks. In Advances in Neural Information Processing Systems (NeurIPS), 2020. [31] Guohao Li, Hasan Abed Al Kader Hammoud, Hani Itani, Dmitrii Khizbullin, and Bernard Ghanem. Camel: Communicative agents for "mind" exploration of large language model society. arXiv preprint arXiv:2303.17760, 2023. [32] Michael Nofer, Peter Gomber, Oliver Hinz, and Dirk Schiereck. Blockchain. Business & information systems engineering, 59(3):183–187, 2017. [33] National Institute of Standards and Technology. FIPS 180-4: Secure hash standard (SHS). Federal Information Processing Standards Publication 180-4, National Institute of Standards and Technology, August 2015. [34] OpenAI. Chatgpt (version 4o). https://chat.openai.com, 2026. [35] Joon Sung Park, Joseph O’Brien, Carrie Jun Cai, Meredith Ringel Morris, Percy Liang, and Michael S Bernstein. Generative agents: Interactive simulacra of human behavior. In Proceedings of the 36th annual acm symposium on user interface software and technology, pages 1–22, 2023. [36] Bryan Parno, Jon Howell, Craig Gentry, and Mariana Raykova. Pinocchio: Nearly practical verifiable computation. Communications of the ACM, 59(2):103–112, 2016. [37] Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Eric Hambro, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. Toolformer: Language models can teach themselves to use tools. arXiv preprint arXiv:2302.04761, 2023. [38] Ankit Wadhwa et al. He-htlc: Revisiting incentives in hashed timelock contracts. In Network and Distributed System Security Symposium (NDSS), 2023. [39] Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, Ahmed Hassan Awadallah, Ryen W White, Doug Burger, and Chi Wang. Autogen: Enabling next-gen llm applications via multi-agent conversation, 2023. [40] Shenghao Yan et al. Crag: Corrective retrieval augmented generation. arXiv preprint arXiv:2401.15884, 2024. [41] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. React: Synergizing reasoning and acting in language models. arXiv preprint arXiv:2210.03629, 2022. [42] Yixiang Yao, Yuhang Yao, Xinyi Fan, Jiechao Gao, Jie Wang, Minjia Zhang, Srivatsan Ravi, and Carlee 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, pages 13252–13258, 2026. [43] Tianjun Zhang, Shishir G Patil, Naman Jain, Sheng Shen, Matei Zaharia, Ion Stoica, and Joseph E Gonzalez. Raft: Adapting language model to domain specific rag. arXiv preprint arXiv:2403.10131, 2024. [44] Zibin Zheng, Shaoan Xie, Hong-Ning Dai, Xiangping Chen, and Huaimin Wang. Blockchain challenges and opportunities: A survey. International journal of web and grid services, 14(4):352–375, 2018. 18