arXiv CSopen access

bioETH-Beacon: A Confidential On-Chain Genomic Beacon with Encrypted Counts, Filters, and Bounded Noise over a Fully Homomorphic EVM

bioETH-Beacon: A Confidential On-Chain Genomic Beacon with Encrypted Counts, Filters, and Bounded Noise over a Fully Homomorphic EVM Christos Galanopoulos1 , Kimon Antonios Provatas1,* Ilias Georgakopoulos-Soares1,*

arXiv:2606.20315v1 [q-bio.GN] 18 Jun 2026

1

Division of Pharmacology and Toxicology, College of Pharmacy, The University of Texas at Austin, Dell Pediatric Research Institute, Austin, TX, USA *

Corresponding authors: [email protected]; [email protected] Confidential Genomic Querying · GA4GH Beacon · FHE · Smart Contracts Anti-Probing Noise · Membership-Inference Mitigation

Abstract

Key Points

The Global Alliance for Genomics and Health (GA4GH) Beacon protocol lets researchers ask whether a genomic variant has been observed in a participating cohort and, when supported, receive aggregate variant-level counts. As Beacon networks grow, two privacy risks remain: host institutions can see plaintext queries, and repeated rarevariant queries can support membership-inference attacks. We present bioETH-Beacon, a smart-contract prototype that runs the Beacon “aggregate count” query over encrypted data on a fully homomorphic Ethereum Virtual Machine (fhEVM). Hospitals upload encrypted markercount entries, authorized researchers submit encrypted marker queries, and the contract returns an encrypted answer that is released, via the off-chain key-management service, only to the requester named in the contract’s on-chain ACL. The design is organized as a 3 × 4 tierby-query-family grid spanning genotype, sex, age, and phenotype queries, with tiers that trade stronger confidentiality for lower query cost. It also includes a G1 multi-filter contract for one encrypted four-way query. For genotype and G1 paths, the prototype can add bounded on-chain noise to make probing attacks harder; singlefilter sex, age, and phenotype queries currently return exact encrypted counts. This noise is an anti-probing feature, not a formal differential-privacy guarantee. Experiments on synthetic panels derived from a Polygenic Score (PGS) catalog show the expected scaling behavior, clarify practical chunk-size limits, and demonstrate that pre-aggregation can substantially reduce query gas when public marker presence is an acceptable trade-off. The paper also states tier-qualified security invariants for the implemented contract suite. Overall, bioETH-Beacon is a research prototype for confidential Beacon-style genomic querying, not a production-ready clinical deployment.

• bioETH-Beacon implements the GA4GH Beacon “aggregate count” query directly on fhEVM: marker identifiers, counts, and result handles remain encrypted, and only authorized requesters can retrieve the plaintext answer through the off-chain key-management service. • A 3×4 tier-by-query-family grid, three execution tiers crossed with four query families, presents the design space in a readable form, from fully encrypted evaluation to faster pre-aggregated lookup and encrypted multi-filter queries. • Bounded on-chain query-noise is implemented on 4 of the 13 deployed contract paths (genotype T3/T4/T5 and the G1 multi-filter); the 9 single-axis sex, age, and phenotype filter contracts currently return exact encrypted counts and require governed requester access. On the supported paths the noise sample is drawn inside the FHE coprocessor, so coordinator-chosen zeronoise injection is prevented by construction; natural zero-noise draws still occur with probability 1/𝐵. • Benchmarks clarify the practical tradeoff: smaller chunks stay within fhEVM depth limits, while preaggregation substantially lowers query gas by revealing only public marker presence. • Tier-qualified security invariants are checked across the prototype’s unit, integration, scaling, filter, noiseinjection, and G1 test suites.

1

Introduction

The Global Alliance for Genomics and Health (GA4GH) Beacon protocol [Fiume et al., 2019] is a deliberately simple primitive for federated genomic discovery: it determines whether a particular sequence variant has been observed in a participating institution’s cohort, with optional allele-frequency metadata in Beacon v1 and richer variant-level quantitative summaries such as matching 1

Figure 1: Graphical Abstract. bioETH-Beacon executes a Beacon-style aggregate-count primitive entirely in the encrypted domain on a fully homomorphic EVM. Hospitals upload encrypted marker-count entries; an authorized researcher submits a single encrypted marker query; the contract returns an encrypted aggregate without exposing raw genomic data, contributor counts, or the queried marker. Optional bounded noise on genotype and G1 query paths increases anti-probing cost but is not a differential-privacy guarantee. Across a 3×4 tier-by-query-family grid, measured local Hardhat EVM query gas in the fixed-𝑀 =20 tier-comparison benchmark at 𝑁 =500 entries ranges from 24.9M (reference encrypted scan) to 1.45M (pre-aggregated, −94%). All gas figures in this paper are local EVM-gas only; on a live fhEVM coprocessor the HCU adder is comparable to or larger than the EVM floor.

variant count, call count, and sample count in later Beacon models [Rambla et al., 2022]. Beacon networks span biobanks, hospital networks, and research consortia, and the protocol has expanded from genomic-variant discovery to a richer phenotype-clinical model that combines variant presence and count-style responses with filters over patient attributes such as reported sex, age band, or phenotype ontology terms. The double-disclosure problem. Despite its popularity, deployed Beacons leave two privacy gaps largely unaddressed. First, the host institution observes every query in plaintext: which researcher submitted it, which variant it concerns, and how many carriers were returned. Second, the researcher receives the count in plaintext, and repeated queries against rare variants enable a membershipinference attack [Shringarpure and Bustamante, 2015] that can confirm the presence of a target individual in the cohort. Both gaps can be partially mitigated organizationally by trusting the host, by access governance, by rate limiting, but neither is closed by the protocol itself. The opportunity. Fully homomorphic encryption (FHE), and in particular the bounded-integer TFHE scheme [Chillotti et al., 2020] as deployed by the Zama fhEVM coprocessor [Zama, 2024a], allows arithmetic over encrypted operands without decryption. Combined with a programmable blockchain, this opens a path where

the Beacon “count” primitive runs inside an immutable smart contract that neither the host nor the requester needs to trust as a designated compute evaluator: the host and chain see public requester, dataset, event-timing, and metadata information plus encrypted query contents. Result decryption itself is still delegated to an off-chain key-management service (KMS) that holds the thresholdshared decryption key (Section 7 discusses this trust assumption explicitly), and only the requester named in the contract’s FHE.allow call can retrieve the plaintext aggregate through that service. Our contribution. We present bioETH-Beacon, an open-source confidential Beacon protocol that implements the GA4GH aggregate-count query directly on fhEVM. The contributions are: 1. A two-layer contract architecture comprising a public BeaconRegistry that holds policy, contributor approvals, and rate limits, and an encrypted ConfidentialBeacon family that holds all genomic state and performs the encrypted scan. No plaintext genomic counts appear on-chain, and T3/T4 also hide marker and filter values; T5 intentionally exposes marker presence as a documented trade-off (Section 3). 2. A 3 × 4 tier-by-query-family grid that crosses three execution tiers (T3 reference, T4 width-optimized, T5 pre-aggregated) with four query families (genotype, 2

reported sex group, age band, phenotype term), plus a multi-filter contract evaluating a four-way conjunctive predicate in a single encrypted query (Section 4). 3. An encrypted scan kernel that runs an oblivious FHE.eq + FHE.select + FHE.add chain over every entry without early exit, with chunksize advisory pinned by an empirically measured HCUTransactionDepthLimitExceeded ceiling (Section 5). 4. An on-chain bounded uniform noise injection that adds width-matched FHE.randEuintT noise inside the FHE coprocessor before result release (𝑇 =64 for T3/G1 and 𝑇 =32 for T4/T5). Unlike off-chain noise schemes, the realized noise value is hidden from the coordinator until the block is mined, preventing coordinator-chosen zero-noise injection (Section 6). 5. An empirical evaluation on synthetic panels derived from the PGS Catalog [Lambert et al., 2021], spanning 27 to 1,500 uploaded entries and panel sizes from 16 to 100,000 markers, with measured gas, transaction-count, wall-time, and HCU-per-query-entry profiles across the evaluated tiers (Section 8). 6. A security analysis built around eleven explicit invariants (Section 7) across the implemented prototype contract suite. The system is implemented as a Solidity contract suite with Hardhat tests, Sepolia-only pending T4 ceiling probes, and benchmark profiles. The measured numbers reported here are sourced from the artifacts generated by the accompanying benchmark pipeline.

2

Methods

2.1

GA4GH Beacon Protocol

The GA4GH initiative [Global Alliance for Genomics and Health, 2016] launched Beacon as part of a broader federated ecosystem. The Beacon protocol [Fiume et al., 2019, Rambla et al., 2022] exposes a small set of queries over a hidden cohort: a v1 Beacon is centered on genomic variant requests with yes/no responses and optional allelefrequency metadata, whereas later Beacon models expose richer quantitative fields such as matching variant count, call count, and sample count [Rambla et al., 2022]. Beacon v2 generalizes the model with structured results and richer filtering support (filteringTerms) over patient attributes such as ontology terms or demographic categories. The protocol is intentionally narrow in semantics, there is no record-level disclosure, only aggregates, but the threat model is delegated entirely to the host’s operational practice. Two attacks documented in the literature shape the rest of this paper. Shringarpure and Bustamante [Shringarpure and Bustamante, 2015] demonstrated that an adversary querying a Beacon over rare variants from a target genome can use a likelihood-ratio test to infer membership in the cohort after repeated queries. McLaren et al. [McLaren et al., 2016] demonstrated a clinical model

using homomorphic encryption and secure two-party protocols. In this framework, the storage and processing unit (SPU) receives encrypted marker requests, while the client can include dummy variants so that request size does not directly reveal the nature of the test. 2.2

TFHE on a Programmable Blockchain

The fhEVM [Zama, 2024a] extends the Ethereum Virtual Machine with a TFHE [Chillotti et al., 2020] coprocessor that operates over encrypted unsigned integers up to 256 bits. Solidity authors manipulate opaque handles (euint32, euint64, etc.) via library calls such as FHE.eq, FHE.select, FHE.add, and width-specific random samplers such as FHE.randEuint32 and FHE.randEuint64. The coprocessor charges a Homomorphic Computation Unit (HCU) cost adder on top of EVM gas. In the documented testnet configuration used for this evaluation, two binding limits apply per transaction: a global HCU budget of 20M units and a sequential-depth budget of 5M units, which constrains the longest chain of dependent FHE operations (e.g., a chain of 29 dependent FHE.add(euint64) operations consumes 29 × 133,000 = 3,857,000 of the 5,000,000-unit depth budget) [Zama, 2024b]. Access control on each encrypted handle is mediated by an on-chain ACL: a handle is persisted for a contract via FHE.allowThis, granted to a specific address via FHE.allow(handle, addr), or made world-readable via FHE.makePubliclyDecryptable (e.g., per-entry counts stay at allowThis forever; only the final aggregate transitions to allow(handle, requester); makePubliclyDecryptable is never invoked anywhere in the protocol). Decryption itself is delegated to an offchain key-management service (KMS) using an EIP-712 (Ethereum Improvement Proposal 712) signed user request. Three properties of this stack shape the bioETH-Beacon design. First, fhEVM integer arithmetic is exact over unsigned integers, with no floating-point approximation — well suited to the count semantics of Beacon queries. Second, the sequential-depth limit binds before the global HCU limit for any operation that accumulates into a single ciphertext, dictating chunk-size choices for our encrypted scan. Third, the ACL is the only barrier between an encrypted handle and its plaintext: the discipline of never calling makePubliclyDecryptable on an aggregate count is the single most important security property in the entire protocol. 2.3

Membership Inference and Output Minimization

Two complementary mitigations against the Shringarpure– Bustamante attack are used in the supported parts of the design. The first is output minimization: the aggregate count is never released as a plaintext value or to any party other than the originating requester; the chain itself stores only opaque ciphertext handles. The second is bounded noise on genotype and G1 query paths: the released 3

Figure 2: System architecture. Approved hospitals encrypt marker–count pairs off-chain using fhevmjs and submit them with an input proof. The public BeaconRegistry gates uploads and queries; the encrypted ConfidentialBeacon family stores and scans encrypted state and emits a requesterprivate result handle decrypted via the off-chain KMS.

first four bytes are interpreted as an unsigned big-endian integer. The consortium manifest workflow should reject dictionaries that produce duplicate markerId values before deployment. This narrows the encrypted comparison from euint64 to euint32 and halves the per-entry FHE.eq HCU; in exchange, the birthday-bound collision probability becomes non-trivial above ∼ 104 distinct markers (≈ 1.2% at 10,000) and reaches ≈ 39% at 216 . The operating regime is therefore deterministic reject-and-remap below ∼ 104 markers, reject-with-explicit-collision-table up to ∼ 6.5×104 markers (where remapping becomes impractical), and migration to the wider euint128 encoding above that. Section 9 discusses the population-scale mitigation path. The dictionary itself is never read on-chain; integrity is anchored off-chain through the manifest URI and digest registered at createDatasetShell time. 3.3

count is perturbed by an integer drawn uniformly from {0, . . . , 𝐵 − 1}, where 𝐵 is a power-of-two committed onchain at dataset creation. Section 6 gives the mechanism, expected upward bias (𝐵 − 1)/2, and calibration guidance.

3

System Design

3.1

Architecture

bioETH-Beacon splits cleanly into a public policy layer and an encrypted compute layer. Figure 2 sketches the data flow. The public layer (BeaconRegistry) holds dataset metadata, the manifest URI and integrity commitment of the shared marker dictionary, contributor approval state, the per-(dataset, requester) rate-limit policy, and a retirement flag, and contains no encrypted state. The encrypted layer (ConfidentialBeacon{T3, T4, T5} and the filter and multi-filter variants) holds the encrypted marker–count arrays per dataset, runs the encrypted scan kernel, and on finalizeQuery calls FHE.allow(handle, requester) so the requester can recover the plaintext count via an EIP-712 user-decrypt request to the offchain KMS. Both layers are deployed as ordinary Solidity contracts on fhEVM; the registry is consulted from the compute layer through pure view calls, which reduces the cross-contract reentrancy surface. 3.2

Marker Canonicalization

Variant strings are normalized to opaque 32-bit identifiers off-chain. Each contributor and querier agree on a shared dictionary anchored by the manifest URI and integrity commitment in BeaconRegistry. The on-chain identifier of a variant 𝑣 is (︀ markerId(𝑣) = sha256 genomeBuild ‖ dictVersion ‖ )︀ (1) norm ‖ 𝑣 0:32 , where the subscript 0:32 denotes the leading 32 bits of the SHA-256 digest over the canonical concatenation. The

State Machines

Two state machines run independently. The dataset lifecycle (Figure 3, top) advances from ShellRegistered (e.g., dataset 0x4a... is registered with entryCount = 1500 and dictionary commitment 0x2c... before any encrypted data is uploaded) via StorageInitialized (e.g., the owner calls createDatasetStorage so subsequent uploads have allocated encrypted arrays to write into) and Uploading to RosterLocked (e.g., after lockContributors, no further institutions may join this dataset epoch) and finally Finalized; a coordinator may transition a finalized dataset to Retired, after which no new queries are accepted. Datasets are immutable once finalized; new epochs require a fresh shell registration with a new datasetId (e.g., the 2026 Q1 and 2026 Q2 cohorts are separate epochs, each bound to its own shell and roster). The query lifecycle (Figure 3, bottom) advances from Created through one or more processQueryChunk transactions to a fully scanned state, then through optional injectQueryNoise before finalizeQuery grants the aggregate handle to the requester. Stale queries can be cancelled permissionlessly after a 50,400-block (≈ 7day) timeout, ensuring that abandoned queries cannot grief storage indefinitely (e.g., a query abandoned after two scan chunks can be reclaimed by any address calling cancelStaleQuery once 50,400 blocks have elapsed). 3.4

Roles, Authorization, and Rate Limits

Three roles are recognized: a coordinator owns a dataset and controls contributor approval, rate-limit policy, and retirement (e.g., the consortium steering committee that approves member hospitals and sets the per-requester ratelimit policy); a contributor is an approved institution that uploads encrypted marker–count chunks (e.g., North Regional Hospital, after being added to the roster, uploads eight encrypted marker–count pairs across two chunks); and a requester submits queries and is the only party able to decrypt results (e.g., a researcher at address 0x9f... who submits an encrypted marker query and later decrypts the returned aggregate handle through the KMS). A re-

4

𝑀 = number of T5 unique-marker slots scanned per query (a fixed-at-deployment parameter, 𝑀 ≪ 𝑁 in the regime where T5 is worthwhile). The P16 worked example has 𝑃 =16 and 𝑁 =31; 𝑀 is not defined for T3/T4. Table 1 summarizes the tier semantics; Figure 4 overlays the measured cost deltas at 𝑁 =500 and 𝑀 =20 from Section 8. 4.1

Figure 3: Dataset and query lifecycles. Datasets become immutable at finalization and can only be replaced by registering a new shell. Queries are monotone: processQueryChunk only advances nextEntryIndex, so permissionless relayers cannot stall a query.

layer role is implicit (e.g., a consortium-funded service that watches QueryCreated events and pays gas to drive processQueryChunk calls to completion on the requester’s behalf ): processQueryChunk is permissionless because it can only advance a query monotonically, so any gas-paying party can help a query complete without affecting correctness. Rate limits are enforced (datasetId, requester)wise in BeaconRegistry using block.number windows rather than wall-clock time, making the limiter robust to the ±15-second timestamp drift that block proposers can introduce (e.g., a 10-query budget over a 7,200-block window — ≈ 24 hours at 12-second blocks — caps a single requester to at most ten successful createQuery calls before the window slides). Open-access exact-count querying is intended only for low-sensitivity datasets: address-based quotas are operational throttles, not identity-level privacy controls, and sensitive genomic cohorts should require governed requester approval rather than open exact-count access.

4

The 3×4 tier-by-query-family grid

The bioETH-Beacon contract suite is organized as a 3×4 tier-by-query-family grid. Three execution tiers parameterise the cost/privacy trade-off of the encrypted scan, and four query families select the filter axes recognized by the Beacon v2 schema (e.g., the sex family exposes five plaintext-cardinality buckets — unknown, female, male, other, withheld — and contributors upload an encrypted bucket id alongside each marker). A separate multi-filter contract (G1, “first-generation multi-axis”), described below, collapses the four families into a single encrypted four-way conjunctive query and is the thirteenth deployed contract. The T3/T4/T5 numbering is historical: T1 and T2 were internal optimization milestones, and T3/T4/T5 are the maintained contract families. Size symbols used throughout. 𝑃 = panel/dictionary marker count (𝑃 =16, 100, 1,000, etc.); 𝑁 = number of uploaded sparse non-zero entries scanned by T3/T4 (a function of the per-hospital density and the panel size);

Execution Tiers

T3 — reference encrypted scan. The base tier stores encrypted 32-bit marker IDs and encrypted 64-bit counts and evaluates the scan kernel eq → select → add on every entry. Marker IDs, filter values, and counts are all encrypted. Query cost is Θ(𝑁 ) in the number of uploaded entries. T4 — ciphertext-width optimization. T4 narrows the count and accumulator from euint64 to euint32. Privacy is unchanged (everything is still encrypted), but deployments must ensure that every true aggregate plus the maximum optional noise (𝐵−1) fits in uint32. Under that precondition, FHE.add drops from 133k to 95k sequential-depth HCU per step, lifting the chunk-size ceiling from 37 to 52 entries on a live coprocessor. Local Hardhat receipts do not include the HCU adder, so T4’s gain is visible only on a live network; we report the HCU model analytically in Section 8. T5 — pre-aggregated slot mode. T5 changes the storage layout entirely: the coordinator declares a fixed set of 𝑀 marker slots at createDatasetStorage, and contributors upload (slotIndex, encCount) pairs that accumulate into the slot’s encrypted counter (e.g., a T5 dataset with 𝑀 = 20 slots exposes slotMarkerIds[0..19] in plaintext; contributors upload (slotIndex, encCount) pairs that the contract adds homomorphically into slotCounts[slotIndex]). Queries scan 𝑀 slots rather than 𝑁 rows, yielding Θ(𝑀 ) query cost regardless of how many entries have been uploaded. The trade-off is explicit: slot indices are plaintext, revealing which markers each contributor covers (though counts remain encrypted). The query marker remains encrypted in the current T5 scan implementation, but the public slot list and contributor slot indices reveal dataset and contributor marker presence. T5 is intended for dense, query-heavy workloads where that marker-presence pattern is not sensitive. 4.2

Query Families

The four families add a categorical filter dimension to the encrypted scan kernel. In each case the per-entry kernel becomes 𝑚𝑖 = FHE.eq(markerIds[𝑖], 𝑞.queryMarker ), 𝑓𝑖 = FHE.eq(filterIds[𝑖], 𝑞.queryFilter ), isMatch𝑖 = FHE.and(𝑚𝑖 , 𝑓𝑖 ), adding two operations and lifting the global per-entry HCU from 277k to ∼ 342k for T3 filter variants. The

5

Table 1: Execution-tier semantics. Privacy axes describe what is hidden from an on-chain observer. Cost class is asymptotic query cost. Tier

Marker Count priv. priv.

Cost class

When to use

T3

Yes

Yes

Θ(𝑁 )

T4

Yes

Yes

Θ(𝑁 )

T5

No

Yes

Θ(𝑀 )

Full privacy; use for any dataset Full privacy; lower cost on live networks; safe unless per-marker count exceeds ∼4 billion Fastest; marker IDs are public; best for dense panels with many queries

sequential-depth ceiling remains dominated by the accumulator chain, but global HCU headroom falls by ∼ 23% relative to the base T3 path. Genotype (no extra filter). The base family; T3, T4, T5 genotype contracts answer “how many carriers of marker 𝑚?” Reported sex group (5 buckets: unknown, female, male, other, withheld). The lowest-cardinality filter, used to demonstrate the filter extension pattern with minimal overhead. Age band (7 buckets: unknown, 0–17, 18–29, 30–39, 40– 49, 50–59, 60+). Identical kernel structure to sex; bucket boundaries match common epidemiological strata. Phenotype (configurable, 1–1000 Human Phenotype Ontology (HPO) or NCI Thesaurus (NCIT) terms). The highest-cardinality filter, intended for ontology-anchored disease queries. Cardinality is fixed at contract construction so deployments can match the relevant ontology slice without recompilation. Multi-filter conjunctive query (G1, “firstgeneration multi-axis”). A separate contract (ConfidentialBeaconMultiFilterT3) accepts four encrypted predicates — marker, sex, age, phenotype — in a single query and returns a single encrypted aggregate that satisfies all four simultaneously (e.g., a single G1 query for marker ∧ sex = female ∧ age = 40–49 ∧ phenotype = HP:0002664 returns one encrypted aggregate without ever computing intermediate single-axis counts). The per-entry kernel adds 4×FHE.eq + 3×FHE.and for a total of ∼ 472k HCU per entry, +70% over the base T3 cost. The contract is strictly stronger, from a privacy standpoint, than issuing four sequential single-dimension queries: no intermediate count is ever computed or disclosed. 4.3

Path-Property Reference

Table 2 consolidates the privacy axes, cost class, and bounded-noise support of all 13 deployed contracts. It is the canonical reference for which paths carry anti-probing noise (the 4 shaded rows) and which paths currently return exact encrypted counts (the 9 remaining rows).

Figure 4: The 3×4 tier-by-query-family grid. Twelve contracts cover the cross-product of tiers and query families; a thirteenth (G1) collapses the four families into a single encrypted four-way conjunctive query. Table 2: Deployed contract paths and properties. “Marker priv.” and “Count priv.” indicate whether the marker identifier and the per-entry count remain encrypted on-chain (T5 exposes marker slot indices as a documented trade-off). “Noise” indicates whether bounded on-chain query-noise (Section 6) is implemented on that path. Contract

Tier

Family

T3 T4 T5 SexT3 SexT4 SexT5 AgeT3 AgeT4 AgeT5 PhenotypeT3 PhenotypeT4 PhenotypeT5 MultiFilterT3

T3 T4 T5 T3 T4 T5 T3 T4 T5 T3 T4 T5 T3

genotype genotype genotype sex sex sex age age age phenotype phenotype phenotype G1 (4-way)

Marker Count Noise priv. priv. Yes Yes No Yes Yes No Yes Yes No Yes Yes No Yes

Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

Yes Yes Yes No No No No No No No No No Yes

All contracts share the ConfidentialBeacon prefix (e.g., ConfidentialBeaconSexT3). Cost class: Θ(𝑁 ) for all T3 and T4 rows, Θ(𝑀 ) for all T5 rows, Θ(𝑁 ) for the G1 multi-filter row.

5

Encrypted Scan Kernel

5.1

Per-Entry Kernel

The reference T3 scan kernel is a four-line oblivious computation: isMatch = FHE.eq(markerIds[𝑖], queryMarker), zero = FHE.asEuintT(0), addend = FHE.select(isMatch, counts[𝑖], zero), acc = FHE.add(acc, addend). Both branches of the FHE.select are evaluated regardless of the encrypted condition. The kernel is explicitly free of early-exit branches: this is security Invariant 3 in Section 7. Figure 5 renders the per-entry data flow and shows where the 133k-HCU FHE.add step binds the sequential-depth budget. 5.2

Chunking and the Depth Ceiling

A single transaction cannot process arbitrarily many entries because FHE.add forms a sequential chain into 6

Algorithm 1 Chunked encrypted scan (T3/T4)

Figure 5: Per-entry FHE scan flow. HCU figures refer to the euint32 eq + euint64 add reference path (T3). The accumulator add dominates sequential depth and sets the chunk-size ceiling.

1: procedure processQueryChunk(𝑞𝑢𝑒𝑟𝑦𝐼𝑑) 2: 𝑞 ← queries[𝑞𝑢𝑒𝑟𝑦𝐼𝑑] 3: 𝑠𝑡𝑎𝑟𝑡 ← 𝑞.nextEntryIndex 4: 𝑒𝑛𝑑 ← min(𝑠𝑡𝑎𝑟𝑡 + queryChunkSize, 𝑁 ) 5: 𝑎𝑐𝑐 ← 𝑞.aggregatedCount 6: for 𝑖 ← 𝑠𝑡𝑎𝑟𝑡 to 𝑒𝑛𝑑−1 do 7: 𝑚 ← FHE.eq(markerIds[𝑖], 𝑞.queryMarker ) 8: 𝛿 ← FHE.select(𝑚, counts[𝑖], FHE.asEuintT(0)) 9: 𝑎𝑐𝑐 ← FHE.add(𝑎𝑐𝑐, 𝛿) 10: end for 11: FHE.allowThis(𝑎𝑐𝑐) 12: 𝑞.aggregatedCount ← 𝑎𝑐𝑐; 𝑞.nextEntryIndex ← 𝑒𝑛𝑑 13: end procedure

Algorithm 2 Pre-aggregated slot evaluation (T5) the accumulator. At 133,000 sequential-depth HCU per step and a 5,000,000 per-transaction budget, the theoretical ceiling is ⌊5 × 106 /133,000⌋ = 37 entries per chunk. We tested this empirically with Hardhat; chunk sizes 5, 10, 20, 29 all pass, while 37 already fails with HCUTransactionDepthLimitExceeded. The repository therefore uses three distinct chunk-size figures: 29 is the largest tested passing value for euint64 accumulators and is the configuration used by the profile, benchmark, and worked-example runs in Section 8; 23 is the deploymentmanifest recommendation (≈ 80% of 29, a 20% safety margin); and 37 is the analytic add-chain ceiling from ⌊5 × 106 /133,000⌋, which the probe shows fails in practice. Tests in the range 30–36 have not been run, so the true empirical ceiling lies somewhere in that interval; the 23/29/37 triad is used consistently throughout this paper and is enforced by Invariant 10 and the pre-deployment advisor (scripts/chunk-size-advisor.ts). For T4’s narrower euint32 accumulator the depth cost per step drops to 95k HCU, lifting the analytic ceiling to ⌊5,000,000/95,000⌋ = 52 and the recommended 80% chunk to 41. The local Hardhat environment enforces the same depth across types, so the T4 advantage is not visible in local profiling — only on a live network. 5.3

Algorithms

The chunked encrypted scan (T3/T4) and the preaggregated slot evaluation (T5) are stated in Algorithms 1 and 2.

6

Bounded Query-Noise Injection

6.1

Mechanism

The base protocol returns the exact encrypted aggregate. Although the ciphertext is requester-private, an adversarial requester can issue many queries against rare variants and reconstruct cohort membership through a likelihood-ratio test [Shringarpure and Bustamante, 2015]. Rate limits delay but do not close this channel. bioETHBeacon adds an optional on-chain bounded uniform anti-

1: procedure processQueryChunk(𝑞𝑢𝑒𝑟𝑦𝐼𝑑) ◁ 𝑀 slots,

𝑀 ≪ 𝑁 assumed 2: 𝑞 ← queries[𝑞𝑢𝑒𝑟𝑦𝐼𝑑] 3: 𝑠𝑡𝑎𝑟𝑡 ← 𝑞.nextSlotIndex 4: 𝑒𝑛𝑑 ← min(𝑠𝑡𝑎𝑟𝑡 + queryChunkSize, 𝑀 ) 5: 𝑎𝑐𝑐 ← 𝑞.aggregatedCount 6: 𝑧𝑒𝑟𝑜 ← FHE.asEuintT(0) 7: for 𝑗 ← 𝑠𝑡𝑎𝑟𝑡 to 𝑒𝑛𝑑−1 do 8: 𝑚 ← FHE.eq(slotMarkerIds[𝑗], 𝑞.queryMarker ) 9: 𝛿 ← FHE.select(𝑚, slotCounts[𝑗], 𝑧𝑒𝑟𝑜) 10: 𝑎𝑐𝑐 ← FHE.add(𝑎𝑐𝑐, 𝛿) 11: end for 12: FHE.allowThis(𝑎𝑐𝑐) 13: 𝑞.aggregatedCount ← 𝑎𝑐𝑐; 𝑞.nextSlotIndex ← 𝑒𝑛𝑑 14: end procedure

probing noise injection on supported query paths (genotype T3/T4/T5 and G1 in the current implementation): ̃︀ 𝑐 = 𝑐 + 𝜈,

𝜈 ∼ 𝒰{0, 1, . . . , 𝐵 − 1},

(2)

where 𝐵 is a power-of-two noise bound committed onchain when the dataset first opts into noise, 𝑐 is the true encrypted aggregate, and 𝜈 is sampled by the FHE coprocessor via a width-matched FHE.randEuintT(B) inside the injectQueryNoise call, with 𝑇 =64 for T3/G1 and 𝑇 =32 for T4/T5 (e.g., a dataset opting in with 𝐵 = 8 releases counts perturbed by integer noise in {0, ..., 7} with expectation (𝐵−1)/2 = 3.5). After injection, the released handle ̃︀ 𝑐 is the only value the requester ever decrypts; the true 𝑐 and the realized noise 𝜈 are both unrecoverable from on-chain state. The mechanism is not a differential-privacy guarantee: because the noise is one-sided and Pr[𝜈 = 0] = 1/𝐵, deployments must combine it with per-key rate limits, query deduplication or cached noisy answers, or a composition-aware mechanism if formal privacy is required. Figure 6 shows the lifecycle position of the injection. In the current implementation, query-noise injection is implemented for the genotype tier lineage and the G1 multi-filter contract; single-dimension sex, age, and phenotype filter contracts currently return exact encrypted counts and require the same hardening as future work.

7

Table 3: Min-attack collapse probability. Pr[𝜈min = 0 | 𝑘] = 1 − (1 − 1/𝐵)𝑘 as a function of bound 𝐵 and number of identical repeated queries 𝑘. Rate-limit policy must keep 𝑘 small enough that this probability remains acceptable.

Figure 6: Bounded on-chain noise injection. Left: Overhead gas decreases as a fraction of total query gas as 𝑁 grows. Right: The noise sample 𝜈 is generated inside the FHE coprocessor and never exists in plaintext; the coordinator triggers the injection but cannot observe or substitute the sampled value before the block mines.

6.2

Trust Model

The coordinator triggers injectQueryNoise(queryId) with no noise parameter; the contract internally calls the width-matched FHE.randEuintT. The realized 𝜈 cannot be observed or influenced by the coordinator before the block is mined. Coordinator-chosen zero-noise injection — the central weakness of any off-chain noise scheme where a malicious coordinator could choose 𝜈 = 0 — is therefore prevented by construction. Natural zero-noise draws still occur with probability 1/𝐵. The remaining failure mode is liveness rather than confidentiality: a withheld injectQueryNoise call leaves the query stuck, but the cohort is still protected. Two further hardening guards are in place: 𝐵 must be a positive power of two (a coprocessor requirement that also enforces a discrete log-scale parameter), and 𝐵 becomes immutable after the first noise-enable call (an implementation hardening described in Section 7). 6.3

Calibration

The discrete uniform noise on {0, 1, . . . , 𝐵 − 1} has expected value (𝐵 −1)/2, so released counts carry an upward bias. Repeated-query collapse. Because the noise is one-sided and zero is in the support, an adversary who issues the same query 𝑘 times and keeps the minimum recovers the true count whenever any draw is zero. The probability of at least one zero draw across 𝑘 identical queries is (︀ )︀𝑘 Pr[𝜈min = 0 | 𝑘] = 1 − 1 − 𝐵1 ,

(3)

which already exceeds 12 at 𝑘 ≈ 𝐵 ln 2 ≈ 0.69 𝐵 repeated queries. Table 3 tabulates a few practical points: even at 𝐵=16 a 20-query budget already gives a 72% chance of collapsing the protection. Bounded noise therefore must be combined with per-key rate limits, cached noisy answers for duplicate query keys, or a composition-aware mechanism if formal repeated-query privacy is required; on its own it is an anti-probing cost increment, not a closed channel. Practical operating choices for 𝐵 are

𝐵

𝑘=1

𝑘=3

𝑘=10

𝑘=20

4 8 16 32

25.0% 12.5% 6.25% 3.13%

57.8% 33.0% 17.6% 9.1%

94.4% 73.7% 47.4% 27.2%

99.7% 93.1% 72.3% 47.0%

Table 4: Practical noise-bound choices. Heuristic operating points; for G1 queries use 𝐵 ≥ 8 because 4-way subgroup counts can be small even when marginals are large. 𝐵

E[𝜈]

Heuristic use

4

1.5

8

3.5

16

7.5

32

15.5

Very rare variants (𝑐 ≤ 5) Rare variants; G1 (subgroup ≤ 10) General use; G1 (subgroup ≤ 50) High-count markers (𝑐 > 100)

listed in Table 4; for multi-filter (G1) queries the minimum subgroup count may be small even when marginal counts are large, so 𝐵 ≥ 8 is recommended there. 6.4

Cost

The injection adds one width-matched FHE.randEuintT and one FHE.add per query. On the T3/G1 euint64 path this costs ≈ 215,000 EVM gas and ≈ 162,000 HCU. Relative to the per-query scan cost, the overhead drops from 10.8% at 𝑁 =31 to < 1% at 𝑁 =500. The gas overhead is small relative to the scan cost, but the privacy value still depends on rate-limit and deduplication policy.

7

Security Model

7.1

Threat Model

We assume eight classes of adversary, drawn from the project’s design document. A curious requester is authorized but tries to extract more than the aggregate they were promised; the mitigation is that no per-contributor handle is ever granted via FHE.allow to anyone but the aggregator. Mutually distrustful contributors share the compute layer; per-contributor handles never leave the contract’s own ACL. An external chain observer sees all transactions and ciphertext handles but cannot decrypt without the KMS-held key. A rate-limit attacker attempts to count-difference across many queries; the per-(dataset, requester) windowed quota and, where implemented, the bounded noise of Section 6 raise the cost of the attack, but do not provide formal privacy under unrestricted repetition. Note that bounded query-noise is only applied on 4

8

7.2

Invariants

Eleven invariants are stated explicitly in the codebase’s implementation security checklist and enforced contract by contract. Each is short enough to state directly. Invariant 1. For T3/T4, no plaintext genomic marker IDs, filter values, or counts appear in contract storage or events. For T5, counts remain encrypted but marker-slot indices and presence are intentionally public.

Figure 7: Threat model (seven on-chain adversaries). Each on-chain leakage channel is mapped to its on-chain mitigation; out-of-scope channels (upload integrity, population-scale collisions, schema harmonization, KMS compromise) are documented as limitations rather than silently glossed. KMS compromise — the eighth adversary in the threat model — is an off-chain trust assumption (see Section 7) and is not represented in this diagram.

of the 13 implemented query paths (genotype T3/T4/T5 and the G1 multi-filter); the 9 single-axis sex, age, and phenotype filter contracts return exact encrypted counts and rely entirely on rate limits and governed requester approval against this adversary. A coordinator controls policy and approvals but cannot read encrypted state or substitute noise values. A storage griefer can create queries and never finalize them; cancelStaleQuery reclaims them after the time-to-live (TTL) window. Malicious contributors can submit garbage encrypted counts; upload integrity is out of scope for v1 (Section 9). Finally, the KMS / decryption gateway is an explicit trust assumption: result decryption is delegated to an off-chain key-management service that holds the threshold-shared decryption key (the Zama threshold KMS in the reference fhEVM deployment). This service is trusted not to release the encrypted aggregate to any address other than the one named in FHE.allow(handle, addr); a malicious or compromised KMS can expose result handles, and bioETH-Beacon does not eliminate this trust assumption. What the system explicitly does not protect: (i) sitelevel participation visibility through upload events; (ii) marker-ID collisions at population scale (> 216 distinct markers); (iii) schema harmonization errors across contributors that produce silently incorrect aggregates; (iv) T5 slot-index visibility revealing which markers each contributor tracks; (v) arbitrary 𝑁 -way conjunctive queries beyond the four-predicate G1 model; and (vi) KMS compromise or collusion at the off-chain decryption gateway. Figure 7 maps the seven on-chain leakage channels to their on-chain mitigations. The eighth adversary class introduced above — KMS / decryption-gateway compromise — is an off-chain trust assumption rather than an on-chain leakage channel and is therefore documented in the text and the out-of-scope list (item vi) rather than in the figure.

Invariant 2. Query results remain requester-private; aggregate counts are never made publicly decryptable. Invariant 3. Query execution scans the full configured entry geometry; the inner loop has no encrypted-conditional early exit. Invariant 4. createQuery enforces registry authorization, retirement status, and local rate limits before any FHE state is created. Invariant 5. appendContributorChunk requires explicit registry approval of the caller before reaching the compute layer. Invariant 6. Every encrypted handle persisted in storage calls FHE.allowThis. Invariant 7. finalizeQuery grants result access only to the requester. Invariant 8. The contributor roster is locked before dataset finalization. Invariant 9. Dataset epochs are append-free after finalization; new data requires a new shell registration. Invariant 10. queryChunkSize does not exceed the empirically validated safe value. The current profile/benchmark value is 29 for the euint64 accumulator path; deployment manifests use 23 as a ≈ 80% safety margin unless a fresh HCU probe justifies a higher value. The analytic add-chain ceiling is 37, but 37 fails in the current probe; values in 30–36 have not been tested. Invariant 11. Datasets with minContributors > 0 cannot be finalized until that many distinct institutions have uploaded. Invariants 1–9 and 11 are enforced in contract code; Invariant 10 is governance-enforced via the pre-deployment advisor and surfaces on-chain as the failure mode HCUTransactionDepthLimitExceeded when violated at runtime.

8

Empirical Evaluation

8.1

Methodology

All reported gas figures in this paper are local Hardhat EVM-gas, not live-network total cost. Hardhat does not include the HCU adder, which on a 9

live fhEVM coprocessor is comparable to or larger than the EVM floor; live total per-query cost is therefore expected to be materially higher than the figures reported here, while tier-relative deltas (T3/T4/T5) and asymptotic shape (linear in 𝑁 , flat in 𝑀 for T5) are expected to carry over. All measurements come from Hardhat tests, which provide reproducible local EVM-gas and sequentialdepth measurements for the evaluated contracts; live network execution may impose additional accounting and deployment-specific configuration. We therefore report EVM gas measured and HCU analytic, with the HCU model calibrated against the per-operation costs published in Zama’s HCU table [Zama, 2024b] and confirmed against the empirical depth probe. The synthetic count generator draws marker presence from a Bernoulli model across hospitals at densities 𝐷 ∈ {0.2%, 1%, 5%, 10%} with negative-binomial counts; marker panels are derived deterministically from the PGS Catalog [Lambert et al., 2021]. Five panel sizes are reported: P16 (the handcurated worked example), P100, P1K, P10K, P100K.

Table 5: Worked P16 upload footprint. Dense hospital rows remain off-chain; only non-zero encrypted marker-count entries are uploaded.

8.2

eq→select→add FHE chain, plus the SSTORE of the updated handle. In local Hardhat tests, the dominant cost is EVM gas; on a live network the HCU adder is comparable to or larger than the EVM floor (Section 8.6).

Worked Consortium Example

To make the benchmark concrete, the P16 panel is instantiated as a four-hospital consortium with a shared dictionary of 16 canonical single-nucleotide variants and 31 sparse non-zero encrypted uploads. Throughout this worked example we illustrate the data-flow at uploadChunkSize=4 and queryChunkSize=5 for narrative clarity; all measured gas reported in this paper, including in this subsection, uses the operational defaults uploadChunkSize=16 and queryChunkSize=29 (the largest tested passing value; deployment manifests use 23 as a safety margin). The example uses genome build GRCh38, dictionary version marker-matrix-v2026-05, and the normalization rule SNV_CANON_V1; each hospital keeps its dense local row offchain and uploads only encrypted non-zero marker–count pairs. Table 5 summarizes the sparse upload footprint: all four institutions share the same dictionary, but each submits only its non-zero marker counts. This mirrors the deployed contract path, where upload privacy is provided by encrypted handles rather than by hiding transaction counts. With the illustrative queryChunkSize=5 a full T3 query scans all 31 encrypted entries in seven chunks; at the operational queryChunkSize=29 the same workload completes in a single chunk. Only the authorized requester can retrieve the plaintext final aggregate, through the off-chain KMS-mediated decryption path. 8.3

Per-Step EVM Gas

Table 7 summarizes EVM gas for the T3 reference path at three synthetic working points. Upload cost is dominated by FHE.fromExternal verification and SSTORE of two encrypted handles per entry: per-entry upload costs ∼ 205k gas across all measured 𝑁 , and gas scales linearly with entry count. Query cost is the eq → select → add chain accumulated chunk-by-chunk; the per-chunk receipt absorbs 29 scan iterations, each containing the

Institution

Entries

Upload chunks

8 8 8

2 2 2

7

2

North Regional Hospital East Oncology Centre River Children’s Genomics Unit Metro Precision Medicine Lab

Table 6: Worked P16 consortium queries. Expected counts are computed from the four-hospital marker matrix; decrypted counts are produced by the Hardhat end-to-end validation path. Query

Canonical variant

EG-1 EG-2 EG-3

chr7:117199644:C>T chrX:153296891:A>G chr22:19952036:C>T

8.4

Expected

Decrypted

43 26 14

43 26 14

Tier Comparison at 𝑁 =500

Table 8 compares the three tiers at the common working point 𝑁 =500. T3→T4 leaves EVM gas effectively unchanged in local Hardhat tests (−0.08% upload, −0.20% query) but reduces HCU per entry by 24% on the analytic model (Section 8.6). T3→T5 yields the fixed𝑀 =20 headline result: query EVM gas drops by 94% (from 24,912,395 to 1,449,177) and upload EVM gas by 53% (from 102,469,955 to 47,739,867). The one-time createDatasetStorage cost rises from 82,881 to 937,602 gas to initialise the 𝑀 =20 encrypted slots; the per-query saving is substantial, but only worthwhile when queries outnumber dataset epochs and the trust model permits public slot indices. 8.5

Scaling to PGS Catalog Panels

Table 9 reports the cross-product of panel size × hospital count × density × tier on the synthetic benchmarks. The key findings: (i) per-entry upload gas stays in the 204k205k band across every configuration, confirming linear scaling through P100K; (ii) P10K with 16 hospitals at 1% density (𝑁 =1,500) completes correctness verification in ∼ 6s of wall time in local Hardhat tests and consumes 73.8M query gas across 54 chunks; (iii) in the current 32bit on-chain marker-ID truncation used by the benchmark path, P100K shows exactly one observed collision among 100,000 benchmark markers (0.001% of IDs), illustrating why production manifests must reject colliding dictionaries or migrate to wider marker types such as euint128; (iv) T5 crosses over with T3 between 𝑁 =246 and 𝑁 =484 on

10

Table 7: Per-step EVM gas (T3 reference path). Configuration: uploadChunkSize = 16, queryChunkSize = 29 (largest tested passing value; deployment manifests use 23), euint32 markers, euint64 counts. createQuery is structurally independent of 𝑁 ; the ≤ 12-gas spread across columns is measurement jitter. Source: data/reports/gas-profile-hardhat.json. 𝑁 =31

𝑁 =100

𝑁 =500

147,577 82,881 73,061 6,370,566 32,447 44,526 50,443 317,939 1,608,175 76,570

147,601 82,881 73,061 20,503,156 32,447 44,526 50,443 317,927 4,942,565 76,570

147,613 82,881 73,061 102,387,074 32,447 44,526 50,443 317,939 24,517,886 76,570

Step createDatasetShell createDatasetStorage approveContributor appendContributorChunk×𝐾 lockContributors finalizeDataset grantQueryAccess createQuery processQueryChunk×𝐶 finalizeQuery

Table 8: Tier comparison at 𝑁 =500. T5 figures use 𝑀 =20 slots. Upload gas aggregates createDatasetStorage + appendContributorChunk; Query gas aggregates createQuery + processQueryChunk + finalizeQuery. Source: fixed-𝑀 =20 optimization/profile run summarized in reports/optimization-report.md.

Upload gas Query gas Query tx count HCU unit Δ𝑇 3 upload Δ𝑇 3 query

T3

T4

T5 (𝑀 =20)

102,469,955 24,912,395 18 277k/entry — —

102,393,043 24,861,752 18 211k/entry −0.08% −0.20%

47,739,867 1,449,177 1 211k/slot −53.4% −94.2%

the P1K panel — below the crossover, T3 is cheaper; above it, T5 wins by a widening margin. Figure 8B renders the cross-tier comparison as a function of 𝑁 . 8.6

HCU Cost Model

The per-entry HCU adder is dominated by the accumulator step. For T3: FHE.eq(euint32) = 60k, FHE.select(euint64) = 55k, FHE.add(euint64) = 162k, totalling 277k HCU per scanned entry. T4’s narrower accumulator reduces this to 211k (−24%). T5 evaluates the same kernel but only 𝑀 times regardless of 𝑁 , so per-entry HCU is reported as 211k per slot and amortized over 𝑀 slots per epoch. The FHE.add operation contributes 162k to the global HCU budget but 133k to the sequential-depth budget in Zama’s two-limit model; the depth budget binds first. The analytic add-chain ceiling is ⌊5×106 /133,000⌋ = 37, but the current probe fails at queryChunkSize = 37; the largest tested passing value is 29, which is used by every measurement in this section. Deployment manifests use 23 as a ≈ 80% safety margin unless a fresh HCU probe justifies higher. Values in the range 30–36 remain untested, so the true empirical ceiling lies in that interval; the gap between the analytic 37 and the empirical ≤ 36 reflects fixed per-chunk overhead in the depth accounting beyond the bare add-chain estimate.

Figure 8: Tier-level gas tradeoffs and scaling behavior (local Hardhat EVM-gas). (A) Fixed-𝑁 =500, 𝑀 =20 comparison of upload and query local EVM gas across T3, T4, and T5. T4 is EVM-gas-equivalent to T3 in local Hardhat tests, while T5 reduces query gas by 94% and upload gas by 53% relative to T3. (B) Local EVM query gas as a function of uploaded entries 𝑁 . T3 and T4 scale linearly with 𝑁 , whereas T5 remains approximately flat at fixed 𝑀 =20 until 𝑀 itself grows. Live per-query cost includes an HCU adder not reflected here.

8.7

Noise-Injection Overhead

The bounded-noise injection (Section 6) adds ≈ 215,000 EVM gas and ≈ 162,000 HCU per query. As a fraction of total query cost: 10.8% at 𝑁 =31, 4.0% at 𝑁 =100, and 0.9% at 𝑁 =500. At realistic consortium scales the gas overhead of noise injection is small relative to the scan cost; its privacy value still depends on rate-limit and deduplication policy. 8.8

Multi-filter (G1)

The conjunctive G1 contract performs 4×FHE.eq + 3× FHE.and per entry on top of the base select/add pair. Mock-measured EVM gas is essentially identical to T3 (∆ < 0.001% per upload entry; 0% per query chunk at 𝑁 =500); the additional cost is entirely in the HCU adder, which rises from 277k to ∼ 472k per entry (+70%). Two constraints converge at the multi-filter chunk ceiling: sequential depth limits chunks to ∼ 37 entries, and the global HCU budget limits them to ∼ 42. Sequential depth binds first (37 < 42); we therefore adopt 23 as the conservative G1 deployment-manifest ceiling and use 29 (the largest tested passing value, inherited from the T3 profile) for the measurements reported here. The same pattern is 11

Table 9: Measured scaling across PGS Catalog panels. Tier T3 with queryChunkSize = 29. Source: measured Hardhat panel benchmark run summarized in reports/benchmark-scaling.md from data/reports/panel-benchmark.json and data/reports/panel_benchmark.csv. Panel

Markers

Hosp.

𝑁

Upload gas

Query gas

Query tx

Wall time

P100, 𝐷=5% P100, 𝐷=10% P1K, 𝐷=5% P10K, 𝐷=1% P1K, 𝐷=5% P100K, 𝐷=0.2% P10K, 𝐷=1% P100K, 𝐷=0.2% P10K, 𝐷=1%

100 100 1,000 10,000 1,000 100,000 10,000 100,000 10,000

4 8 4 4 8 4 8 8 16

27 98 246 379 484 594 751 1,188 1,500

5,361,001 19,836,557 50,331,922 77,633,597 98,805,844 121,585,680 153,712,561 243,137,208 306,732,738

1,742,352 5,269,524 12,494,011 19,038,003 24,107,664 29,506,183 37,138,985 58,494,919 73,771,830

3 6 11 16 19 23 28 43 54

161ms 420ms 958ms 1,483ms 1,918ms 2,323ms 2,953ms 4,855ms 6,046ms

summarized by the filter-family benchmarks. 8.9

Correctness and Tests

Correctness is verified end-to-end at three scales. The hand-curated 𝑁 =31 worked example decrypts to expected counts on three reference queries (43, 26, 14). The scaling test suite verifies decrypted = expected across seven synthetic configurations from P100 to P10K, including queries against guaranteed-zero markers. The Hardhat test suite covers unit, integration, scaling, single-filter (sex/age/phenotype × T3/T4/T5), multi-filter (G1), and noise-injection cases. In the version of the suite reported here, 181 tests pass and 2 are pending: both pending cases are live-coprocessor T4 chunk-ceiling probes that require a funded Sepolia deployment and could not be executed in local Hardhat. The graphical abstract additionally cites “0 critical findings” from the internal security review documented in reports/security-review.md, which audits the eleven invariants of Section 7 against the implemented contract suite; that internal review is not a substitute for independent third-party audit.

9

Discussion and Limitations

9.1

When to Pick Which Tier

In the fixed-𝑀 =20 benchmark, T3 remains the default privacy-preserving choice below roughly 500 uploaded entries when full marker-presence privacy is required; operators should recompute the crossover for their 𝑀 , query volume, and live HCU pricing. T3 pays a modest gas cost in exchange for full encryption of marker IDs, filter values, and counts. T4 is appropriate when the maximum true aggregate plus optional noise fits in uint32 and the operator targets a live coprocessor where the 24% HCU saving is visible. T5 is the right choice when (i) the set of markers each contributor tracks is not sensitive, (ii) queries dominate uploads (𝑄/𝑈 ≫ 1), and (iii) the panel is dense enough that 𝑀 ≪ 𝑁 . At 𝑁 = 500 and 𝑀 = 20, T5 cuts query gas by 94%; at 𝑀 ≈ 𝑁 the advantage vanishes. Two distinct comparisons appear in the evaluation and should not be conflated: the 94% figure is query-gas

only at fixed 𝑀 =20, whereas the 𝑁 ≈ 246–484 crossover reported in Section 8.5 is total lifecycle gas (upload + query) and shifts with 𝑀 , the query/upload volume ratio, and live HCU pricing. 9.2

What the System Does Not Cover

Upload integrity. A malicious contributor can submit any encrypted value. FHE provides confidentiality, not authenticity; the contract cannot verify that the submitted counts match the contributor’s real electronic health record (EHR). ZK proofs binding uploads to off-chain attestations are roadmap work. Marker collisions at population scale. The euint32 encoding has non-negligible birthday risk as dictionaries grow: for a uniform 32-bit prefix, the probability of at least one collision is about 1.2% at 10,000 markers and about 39% at 65,536 markers, reaching effective certainty long before 107 . Three operating regimes therefore apply. Below ∼ 104 markers, the consortium manifest must perform an off-chain collision check and reject any colliding dictionary outright (deterministic reject-and-remap). Between ∼ 104 and ∼ 6.5×104 markers, reject-and-remap remains feasible but increasingly costly, and an explicit collision table mapping colliding canonical variants to disambiguated markerId values is required. Above ∼ 105 markers, reject-and-remap becomes impractical and migration to the wider euint128 encoding is mandatory (at ∼ 3× HCU per eq). A 107 -marker threshold describes only a catastrophic-collision regime; the operating threshold for the euint128 migration is closer to 105 . Schema harmonization. If contributors apply inconsistent variant normalizations, the aggregate can be silently incorrect. The dictionary URI and commitment in BeaconRegistry provide an off-chain integrity anchor but the contract itself cannot enforce normalization. Event-timing leakage. QueryCreated and QueryFinalized reveal the requester address, dataset, query timing, chunk progress, and finalization timing, without exposing the marker or the count. This metadata leakage is an accepted gap. Cross-contract differencing on the same cohort. If a cohort is exposed simultaneously through a single-filter 12

optional quantitative variant-level responses; Rambla et al. [Rambla et al., 2022] introduced Beacon v2 as a broader biomedical-discovery model with structured result sets and richer filtering terms. Shringarpure and Bustamante [Shringarpure and Bustamante, 2015] first demonstrated membership inference against Beacons, and Raisaro et al. [Raisaro et al., 2017] proposed budget-based defenses. Both threat models assume a benign Beacon host; bioETHBeacon relaxes that assumption by protecting query and count contents from on-chain observers.

Figure 9: Scaling behavior and lifecycle crossover across benchmark panels (local Hardhat EVM-gas). (A) Total local EVM query gas grows linearly with uploaded entries 𝑁 across PGS Catalog-derived panel sizes. (B) Perentry upload gas remains approximately constant at ≈ 205k across configurations, confirming that upload cost depends mainly on the number of non-zero entries rather than panel size. (C) T3 vs. T5 total lifecycle gas crossover on P1K. T3 total gas is lower below 𝑁 ≈ 246, while T5 wins above 𝑁 ≈ 484 because its lower upload cost offsets the fixed-slot query model. Crossover thresholds shift with live HCU pricing.

T3 and the G1 multi-filter, an attacker authorized on both can reconstruct multi-dimensional marginals without exhausting either rate-limit window. Operational guidance is to restrict G1 access to a strictly smaller requester set than T3, or to share rate-limit accounting across related datasets in a registry extension. 9.3

Roadmap

Documented future items include encrypted indexed lookup (an 𝑂(log 𝑀 ) FHE binary trie replacing the linear scan), dataset versioning with explicit deprecation, time-locked or multisig coordinator governance, and an euint128 migration for population-scale catalogs. None of these are required for the current evaluation; each is a separable extension that does not invalidate the present design.

10

Related Work

The Beacon protocol and its privacy. Fiume et al. [Fiume et al., 2019] formalized the Beacon Network as a federated genomic discovery layer with existence and

Adjacent secure-genomics and confidentialcomputation constructions. Prior work has explored multiparty computation for secure GWAS [Cho et al., 2018], trusted execution environments for privacypreserving genomic analysis [Asvadishirehjini et al., 2020], and decentralized private computation models [Bowe et al., 2020]. These systems are not direct Beacon count implementations, but they illustrate the broader design space for moving genomic or application-specific computation away from plaintext centralized processing. The fhEVM approach is closest in spirit to TEE-based designs because computation is delegated to a single substrate, but it replaces hardware trust with cryptographic trust in TFHE/Ring Learning with Errors (RLWE) and public blockchain consensus. Homomorphic encryption for genomics. Kim and Lauter [Kim and Lauter, 2015] applied HE to GWAS statistics; Blatt et al. [Blatt et al., 2020] scaled the HE pipeline to 25,000 samples; McLaren et al. [McLaren et al., 2016] demonstrated an HE-based HIV clinical test; Raisaro et al. [Raisaro et al., 2019] built MedCo, a privacy-preserving distributed exploration system. iDASH competition entries [Wang et al., 2017] catalog the design space. These systems target richer queries than Beacon’s count primitive but assume one or more centralized compute parties; bioETH-Beacon recovers the simplest useful query — the Beacon count — without a designated evaluator. FHE on a programmable chain. The fhEVM [Zama, 2024a,b] provides an FHE coprocessor for Ethereumcompatible smart contracts. Earlier blockchain-privacy and verifiability work focused on anonymous payments [Ben-Sasson et al., 2014], decentralized private computation [Bowe et al., 2020], or scalable transparent computational integrity [Ben-Sasson et al., 2018]. bioETHBeacon explores a complementary point in this design space: application-specific encrypted count computation over a programmable FHE-enabled contract substrate. Positioning. Relative to MedCo [Raisaro et al., 2019], Cho’s MPC-GWAS [Cho et al., 2018], TEE-based genomic services [Asvadishirehjini et al., 2020], and McLaren et al.’s HE clinical pipeline [McLaren et al., 2016], bioETHBeacon targets the simplest GA4GH primitive — the aggregate count — and removes the designated compute evaluator entirely: the contract performs the encrypted scan on a public blockchain rather than at a designated compute party or inside a TEE. The trade-off is narrower expressiveness (aggregate count and four-way conjunction, not GWAS or record-level queries) in exchange for a smaller compute-side trust footprint: the only off-chain 13

trusted component is the threshold KMS, not a compute coordinator. A precise latency/cost comparison against these systems is out of scope here because their published numbers cover different query shapes; a side-by-side benchmark on a shared workload is roadmap work.

11

Conclusion

We have presented bioETH-Beacon, a confidential implementation of the GA4GH Beacon “aggregate count” query on a fully homomorphic EVM. Approved hospitals upload encrypted marker-count entries; an authorized researcher submits an encrypted marker; the contract scans the encrypted dataset with an oblivious equality–select– add kernel and returns an encrypted aggregate whose plaintext can be retrieved only by the requester, via the off-chain KMS-mediated decryption path. A 3 × 4 tierby-query-family grid spans the privacy/cost frontier, and a multi-filter contract collapses the four families into a single encrypted four-way conjunctive query. Bounded query-noise covers 4 of the 13 implemented contract paths (genotype T3/T4/T5 and the G1 multi-filter); on those paths an on-chain bounded uniform noise mechanism sampled inside the FHE coprocessor increases anti-probing cost without reintroducing a trusted curator. The remaining 9 single-axis sex, age, and phenotype filter contracts currently return exact encrypted counts to the authorized requester, so sensitive cohorts must rely on governed requester access and rate-limit policy; formal repeated-query privacy requires rate limiting, deduplication, or a stronger composition-aware mechanism. Empirical evaluation on PGS Catalog-derived panels confirms linear gas scaling through P100K, distinguishes the analytic add-chain ceiling of 37 from the largest tested passing queryChunkSize of 29 and the deploymentmanifest setting of 23, and shows that pre-aggregation cuts query gas by 94% in the fixed-𝑀 =20 tier-comparison benchmark. Eleven security invariants are stated across the implemented contract suite and checked with Hardhat tests, with two Sepolia-only pending T4 ceiling probes. The protocol provides a practical building block for confidential genomic data sharing in consortia where neither the host nor the requester can be assumed to be fully trusted, and it establishes a starting point for richer Beacon-style queries that move further into the encrypted domain.

Biographical Note Christos Galanopoulos, Kimon Antonios Provatas, and Ilias Georgakopoulos-Soares are researchers at The University of Texas at Austin studying pharmacology, genomics, and privacy-preserving biomedical computation at the Dell Pediatric Research Institute.

Ethics Statement This study did not involve recruitment of human participants, intervention on human subjects, or analysis of identifiable human participant data. The empirical evaluation used synthetic benchmark panels derived from public PGS Catalog metadata and generated artifacts, so institutional review board approval and informed consent were not required for the reported experiments.

Data Availability Statement No new human participant datasets were generated or analyzed in this study. Synthetic PGS-derived benchmark panels and measurement artifacts were generated for the empirical evaluation by the benchmark pipeline via npm run benchmark:panels, npm run profile:gas, and Hardhat tests. The reported tables should be compared against the bundled measured-run reports and generated artifacts rather than read as a byte-for-byte guarantee for future reruns under different dependency versions.

Code Availability Statement The source code, smart contracts, tests, benchmark scripts, generated JSON artifacts, reports, and figure sources supporting this manuscript are available at https://github.com/Georgakopoulos-Soares-lab/ bioETH-Beacon. The repository represents a research prototype and should be independently reviewed, configured, and governed before any production or clinical use.

References A. Asvadishirehjini, M. Kantarcioglu, and B. A. Malin. A framework for privacy-preserving genomic data analysis using trusted execution environments. In 2020 Second IEEE International Conference on Trust, Privacy and Security in Intelligent Systems and Applications (TPS-ISA), pages 138–147. IEEE, 2020. doi: 10.1109/TPS-ISA50397.2020.00028. E. Ben-Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer, and M. Virza. Zerocash: Decentralized anonymous payments from Bitcoin. In 2014 IEEE Symposium on Security and Privacy, pages 459–474, 2014. doi: 10.1109/SP.2014.36. E. Ben-Sasson, I. Bentov, Y. Horesh, and M. Riabzev. Scalable, transparent, and post-quantum secure computational integrity. IACR Cryptology ePrint Archive, Report 2018/046, 2018. URL https://eprint.iacr. org/2018/046. M. Blatt, A. Gusev, Y. Polyakov, and S. Goldwasser. Secure large-scale genome-wide association studies using 14

homomorphic encryption. Proceedings of the National Academy of Sciences, 117(21):11608–11613, 2020. doi: 10.1073/pnas.1918257117. S. Bowe, A. Chiesa, M. Green, I. Miers, P. Mishra, and H. Wu. Zexe: Enabling decentralized private computation. In 2020 IEEE Symposium on Security and Privacy, pages 947–964, 2020. doi: 10.1109/SP40000.2020.00050. I. Chillotti, N. Gama, M. Georgieva, and M. Izabachène. TFHE: Fast fully homomorphic encryption over the torus. Journal of Cryptology, 33:34–91, 2020. doi: 10.1007/s00145-019-09319-x. H. Cho, D. J. Wu, and B. Berger. Secure genome-wide association analysis using multiparty computation. Nature Biotechnology, 36:547–551, 2018. doi: 10.1038/nbt.4108. M. Fiume, M. Cupak, S. Keenan, J. Rambla, S. de la Torre, S. O. M. Dyke, A. J. Brookes, K. Carey, D. Lloyd, P. Goodhand, M. Haeussler, M. Baudis, H. Stockinger, L. Dolman, I. Lappalainen, J. Törnroos, M. Linden, J. D. Spalding, S. Ur-Rehman, A. Page, P. Flicek, S. Sherry, D. Haussler, S. Varma, G. Saunders, and S. Scollen. Federated discovery and sharing of genomic data using Beacons. Nature Biotechnology, 37:220–224, 2019. doi: 10.1038/s41587-019-0046-x. Global Alliance for Genomics and Health. A federated ecosystem for sharing genomic, clinical data. Science, 352(6291):1278–1280, 2016. doi: 10.1126/science. aaf6162. M. Kim and K. Lauter. Private genome analysis through homomorphic encryption. BMC Medical Informatics and Decision Making, 15(Suppl 5):S3, 2015. doi: 10. 1186/1472-6947-15-S5-S3. S. A. Lambert, L. Gil, S. Jupp, S. C. Ritchie, Y. Xu, A. Buniello, A. McMahon, G. Abraham, M. Chapman, H. Parkinson, J. Danesh, J. A. C. MacArthur, and M. Inouye. The Polygenic Score Catalog as an open database for reproducibility and systematic evaluation. Nature Genetics, 53:420–425, 2021. doi: 10.1038/s41588-021-00783-5.

J. L. Raisaro, J. R. Troncoso-Pastoriza, M. Misbach, J. A. S. Sousa, S. Pradervand, E. Missiaglia, O. Michielin, B. Ford, and J.-P. Hubaux. MedCo: Enabling secure and privacy-preserving exploration of distributed clinical and genomic data. IEEE/ACM Transactions on Computational Biology and Bioinformatics, 16(4):1328–1341, 2019. doi: 10.1109/TCBB. 2018.2854776. J. Rambla, M. Baudis, R. Ariosa, T. Beck, L. A. Fromont, A. Navarro, R. Paloots, M. Rueda, G. Saunders, B. Singh, J. D. Spalding, J. Törnroos, C. Vasallo, C. D. Veal, and A. J. Brookes. Beacon v2 and Beacon networks: A “Lingua Franca” for federated data discovery in biomedical genomics, and beyond. Human Mutation, 43(6):791–799, 2022. doi: 10.1002/humu.24369. S. S. Shringarpure and C. D. Bustamante. Privacy risks from genomic data-sharing beacons. American Journal of Human Genetics, 97(5):631–646, 2015. doi: 10.1016/ j.ajhg.2015.09.010. S. Wang, X. Jiang, H. Tang, X. Wang, D. Bu, K. Carey, S. O. M. Dyke, D. Fox, C. Jiang, K. Lauter, B. Malin, H. Sofia, A. Telenti, L. Wang, W. Wang, and L. OhnoMachado. A community effort to protect genomic data sharing, collaboration and outsourcing. npj Genomic Medicine, 2:33, 2017. doi: 10.1038/s41525-017-0036-1. Zama. fhEVM: Confidential EVM smart contracts using fully homomorphic encryption. White paper, 2024a. URL https://github.com/zama-ai/fhevm. Accessed: May 2026. Zama. Zama Protocol Solidity developer documentation. Online documentation, 2024b. URL https://docs. zama.ai/protocol/solidity-guides. Accessed: May 2026.

P. J. McLaren, J. L. Raisaro, M. Aouri, M. Rotger, E. Ayday, I. Bartha, M. B. Delgado, Y. Vallet, H. F. Günthard, M. Cavassini, H. Furrer, T. Doco-Lecompte, C. Marzolini, P. Schmid, C. D. Benedetto, L. A. Decosterd, J. Fellay, J.-P. Hubaux, and A. Telenti, on behalf of the Swiss HIV Cohort Study. Privacy-preserving genomic testing in the clinic: A model using HIV treatment. Genetics in Medicine, 18:814–822, 2016. doi: 10.1038/gim.2015.167. J. L. Raisaro, F. Tramer, Z. Ji, D. Bu, Y. Zhao, K. Carey, D. Lloyd, H. Sofia, D. Baker, P. Flicek, S. Shringarpure, C. Bustamante, S. Wang, X. Jiang, L. Ohno-Machado, H. Tang, X. Wang, and J.-P. Hubaux. Addressing beacon re-identification attacks: Quantification and mitigation of privacy risks. Journal of the American Medical Informatics Association, 24(4):799–805, 2017. doi: 10.1093/jamia/ocw167. 15