Evaluation and Discussion

This chapter evaluates the implementation described in Chapter 4 along the three axes defined for the work (computational cost, latency and privacy), plus a robustness analysis, and discusses the trade-offs, the limitations and the threats to validity. It presents the evaluation methodology (§5.1), the computational cost (§5.2), the latency (§5.3), the quantitative analysis of privacy and leakage (§5.4), robustness (§5.5) and, finally, the consolidated discussion (§5.6).

As a reading map, Table 12 relates each part of hypothesis H (§1.4) to the evidence this chapter presents in support of it.

Table 12: Mapping between the parts of the hypothesis and the evidence presented.

5.1 Evaluation methodology

The evaluation was conducted over synthetic populations of participants in three sizes, N ∈ {3, 5, 10}, with at least five repetitions per configuration, totalling 240 measurements on the mock and 345 on the public testnet. On the mock, the 240 measurements correspond to 60 measurements of single-instance operations per auction (across 15 runs: three sizes of N times five repetitions) and 180 measurements of per-participant operations (bid and withdrawal, one measurement per bidder in each run); the testnet replicates those 240 on-chain gas measurements and adds 105 off-chain latency measurements (client-side encryption and decryption via the TSN), reaching 345. The choice of N covers the range from the mechanism's minimum viable size (MIN_BIDDERS = 3, as per §4.2.5) up to the scale of small to medium institutional auctions assumed by the work's hypothesis. The repetitions make it possible to observe the dispersion of the measurements, above all on the testnet, where network factors introduce variation between runs. In this chapter's figures, that dispersion appears as error bars of ±1 standard deviation; on the mock, whose operations are almost deterministic, the bars are imperceptible.

The measurements were taken in two complementary environments, described in Table 13. Each answers a different question: the mock isolates the algorithmic cost (without the layer 1 data fee, the cost that a layer 2 network such as Arbitrum pays to record its data on the base blockchain, in line with the rollup notion of §3.2, nor the decryption network), whereas the testnet measures the real cost and latency on a public blockchain.

Table 13: Evaluation environments and what each one measures.

Four metrics were collected: the gas per operation (createAuction, bid, requestSettlement, finalizeSettlement, withdraw), the total end-to-end gas of a complete cycle, the calldata size of each transaction, and the latency (wall time) of each phase, including the off-chain steps of client-side encryption and decryption via the TSN. Those off-chain steps were executed and measured on the client machine that orchestrated the experiments (a MacBook with an Apple M2 processor and 8 GB of RAM), by the benchmark script in Node.js (version 20 or higher), using the same TFHE library compiled to WebAssembly that the graphical interface employs in the browser. The raw data collected (one CSV file for the mock and another for the testnet) and the script that processes them to generate this chapter's charts are available in the project's public repository (§4.4.1), so that all measurements and figures can be reproduced.

5.2 Computational cost

Table 14 presents the average gas per operation on the Arbitrum Sepolia testnet, broken down by N. The bid operation is by far the most expensive, since it concentrates the homomorphic arithmetic of the work (the cap plus the top-2 update, described in §4.2.3 and §4.2.5); Figure 11 makes that difference in magnitude between operations visible. The other operations are substantially cheaper, because they handle only ACL authorisations, proof verifications or ETH transfers.

Table 14: Average gas per operation on Arbitrum Sepolia, by number of participants.

A hasty reading of Table 14 would suggest that the cost grows with N, which would put pressure on the claim of constant cost per operation (NFR-05, §4.2.3). The point, however, is that the testnet mixes the algorithmic cost with Arbitrum's layer 1 data fee, which varies between runs, and with an initialisation effect discussed below. To isolate the algorithmic cost, one turns to the mock, which has no L1 fee. Table 15 shows the gas on the mock, and the result is clear: for requestSettlement, finalizeSettlement and the two withdraw operations, the gas is practically identical across N = 3, N = 5 and N = 10 (deviations of a few gas units), and bid varies by less than two per cent. The cost per operation is therefore constant in N, as the incremental top-2 pattern predicts, and Figure 12 shows that constancy in the form of approximately horizontal lines.

Table 15: Average gas per operation on the mock, by number of participants. The constancy across columns evidences the O(1) cost in N.

Two cost phenomena deserve explanation. The first is that the mock is more expensive than the testnet in the bid operation (around 1.65 million against 611 thousand gas, averaged across the three populations). This follows from the CoFHE architecture: on the testnet, part of the homomorphic computation is delegated to the off-chain coprocessor (§4.2.1), so that the on-chain gas reflects mainly the symbolic management of handles; on the mock, the FHE operations are fully simulated on-chain, which inflates the gas accounted for. The mock figures therefore serve to compare operations with one another and to verify invariance in N, but the real production cost is the testnet one. The second phenomenon is the first-bid effect: the bid at index 0 of each auction is noticeably cheaper (around 1.51 million gas on the mock, against around 1.68 million for the subsequent bids), because it initialises the encrypted top-2 state for the first time, whereas the subsequent bids execute the full homomorphic comparison. That effect, and not a dependence on N, is what makes the average for bid rise slightly in larger auctions.

Although the cost per operation is constant in N, the total cost of an auction grows approximately linearly, simply because an auction with N participants contains N bid transactions and N withdraw transactions. Table 16 and Figure 13 quantify that end-to-end total.

Table 16: Total gas of a complete auction cycle (creation, N bids, settlement and N+1 withdrawals).

As for calldata size, only the bid operation carries a non-trivial payload: 324 bytes, corresponding to the InEuint64 structure (the encrypted bid plus the proof metadata). The other transactions have minimal calldata, since they receive only identifiers and addresses. The 324 bytes of the encrypted bid are about an order of magnitude larger than the 32 bytes of a plaintext bid, which illustrates the transmission cost of confidentiality. Finally, regarding the homomorphic cap introduced in §4.2.5: it adds three FHE operations per bid (one FHE.asEuint64, one FHE.gt and one FHE.select); since bid already executes six FHE operations on the top-2 path, the cap represents a modest addition to an operation that is, in any case, the most expensive in the contract.

Cost in currency. The gas figures become concrete when converted into currency, even though the conversion is a dated snapshot: both the gas price and the exchange rate fluctuate. Taking the gas cost measured on the testnet as an approximation of the cost on Arbitrum's main network (Arbitrum One, which uses the same charging architecture), the gas price of 0.02 gwei queried on 18 July 2026 from the network's official public RPC¹ and the ETH quotation on the same day (US$1,841 and R$9,440, cf. COINGECKO, 2026), the bid operation, at around 611 thousand gas units, costs approximately 0.000012 ETH, that is, about US$0.02 (R$0.12); and a complete auction cycle costs from US$0.10 (R$0.52) with three participants to US$0.31 (R$1.58) with ten, adding up all transactions from all roles. As a scale reference, the smallest possible transaction on an EVM-compatible network, a simple ETH transfer, has an intrinsic cost of 21 thousand gas units, a constant defined by the Ethereum protocol (WOOD, 2014) and inherited by Arbitrum as an execution floor; the encrypted bid consumes around 29 times that floor. The comparison with a plaintext bid remains qualitative, as discussed in §5.6. In absolute terms, the cost of confidentiality is on the order of cents of a dollar per participant under current Arbitrum One conditions, which reinforces the mechanism's compatibility with auctions of high unit value.

5.3 Latency

Latency was measured on the testnet across three distinct natures: the on-chain confirmations, client-side encryption and the decryption round trip with the TSN. Table 17 and Figure 14 summarise the average times per phase.

Table 17: Average latency per phase on Arbitrum Sepolia.

The most relevant finding is that client-side encryption (around 6.8 seconds on average, with observations between 6.1 and 11.3 seconds) is the single largest component of user-perceived latency, exceeding any on-chain transaction. This is consistent with the nature of TFHE (§2.3.1): encrypting a value and generating the well-formedness proof in WebAssembly is computationally heavy, whether in the browser or in Node.js. The on-chain confirmations all fall in the 2.3 to 2.7 second range, reflecting Arbitrum's block time. The TSN round trip, in the reveal phase, costs around 2.9 seconds, with low dispersion (between 2.8 and 3.1 seconds), which indicates that the decryption network responded stably during the experiments.

In terms of end-to-end experience, a participant submitting a bid typically waits the sum of the encryption and the confirmation, that is, around nine to ten seconds. Finalising the auction, orchestrated by the client (§2.3.5), involves the query to the TSN followed by the finalizeSettlement transaction, adding up to around five to six seconds. These times are compatible with an interactive flow, even though WASM encryption is the bottleneck to watch in future optimisations.

5.4 Privacy and information leakage

This section quantifies what the adversary defined in §4.1.2 can infer about the bids after the auction closes. The table of capabilities per state was already presented in §4.1.5; here the focus is the residual uncertainty about the bid values in the terminal Settled state, derived in closed form.

Let C be the uniform collateral (the public cap on bids, as per §4.2.5) and p the second-highest bid, which is revealed at the end. After finalisation, the adversary knows the identity of the winner and the value p, and nothing more about the individual values. From that, the set of values still compatible with what was observed, for each category of bid, is the following:

• The winner's bid: lies in [p, C]. It is greater than or equal to p (since it is the highest bid) and less than or equal to C (by the homomorphic cap). The residual uncertainty is the width C − p.
• The second-highest bid: is exactly p. Residual uncertainty zero (it is the only value revealed).
• Each of the remaining N − 2 bids: lies in [0, p], since it is less than or equal to the second-highest. The residual uncertainty of each one is the width p.

Modelling the adversary's belief as a uniform distribution over each compatible interval, and measuring the widths in the discrete domain of representable values (integers of type euint64, bounded by the cap C), the residual uncertainty of a uniform value over w compatible values is the Shannon entropy, that is, the formal measure of how much uncertainty remains, equal to log₂(w) bits, always non-negative (in the limiting case of a single compatible value, w = 1, it is zero). In the illustration below, the values in ETH express proportions of the domain; for the bit count, the widths are converted to the underlying discrete domain, in wei. The total residual entropy over the vector of bids is then approximately:

H_residual ≈ log₂(C − p)  +  (N − 2) · log₂(p)

where the first term is the uncertainty about the winner's bid and the second is the sum of the uncertainties about the N − 2 lower-valued losing bids.

Two premises sustain this measure and must be made explicit. The first, already adopted above, is the uniform belief: the adversary's uncertainty over each compatible interval is modelled by a uniform distribution, which is the maximum-entropy one over a bounded support. The second is the independence between bids: the total entropy is taken as the sum of the per-bid entropies. Since the joint entropy never exceeds the sum of the marginal entropies, and since the uniform maximises the entropy over each interval, the values reported are an upper bound on the residual uncertainty: an adversary with informative beliefs, or one who exploits the ordering dependence among the losing bids (all less than or equal to p), would face equal or lower uncertainty.

Table 18 summarises these categories.

Table 18: The adversary's residual uncertainty about the bids, in the Settled state.

By way of illustration, consider the demonstration auction whose result panel appears in Figure 10: collateral C = 0.01 ETH, three participants and a revealed second price p = 0.0002 ETH. The winner's bid remains confined to the interval [0.0002, 0.01] ETH, a band covering 98% of the amplitude of the bid domain; and the remaining losing bid stays in [0, 0.0002] ETH, a band of 2% of the amplitude. Instantiating the entropy equation in the discrete domain in which the bids are represented (euint64, values in wei, with C = 10¹⁶ wei), the prior uncertainty about each bid is log₂(10¹⁶) ≈ 53.2 bits. After settlement, the uncertainty about the winner's bid is log₂(C − p) = log₂(9.8×10¹⁵) ≈ 53.1 bits, and that about the remaining loser is log₂(p) = log₂(2×10¹⁴) ≈ 47.5 bits; the total residual entropy is H_residual ≈ 53.1 + 47.5 ≈ 100.6 bits, out of a prior maximum of 2 × 53.2 ≈ 106.3 bits over the two unrevealed bids, that is, around 95% of the original uncertainty survives. Note that even the proportionally narrow interval of the loser (2% of the amplitude) still contains around 2×10¹⁴ possible values: a small proportion does not mean small uncertainty. In a fully public auction, by contrast, all those entropies would be zero: each bid would be known exactly. It is that distance, between around one hundred residual bits and zero, that the measure quantifies: the revelation required by the Vickrey rule collapses exactly one value to a point (the second price) and the identity of the winner, consuming few bits of all the rest, which empirically supports the privacy objectives stated in §4.1.3 and, consequently, the truthfulness property (§2.5.5).

5.5 Robustness

The robustness of the system is analysed under four vectors, in line with the limitations declared in §4.1.6.

Censorship at the mempool level. FHE protects the content of the transaction, not its inclusion. A validator can still observe that an address sent a bid transaction (even without knowing the value) and refuse to include it, or delay it. That vector is not eliminated by confidentiality; mitigations such as private mempools (Flashbots Protect, §1.2.2) reduce the exposure, but complete defence against consensus-level censorship is out of scope. The model assumes reasonable liveness of the underlying network.

Unavailability of the TSN. Since the revelation depends on the cooperation of a quorum of TSN operators (§4.1.4), an outage of the decryption network would leave the auction stuck in the SettlementRequested state, unable to transition to Settled. It is important to note that, even in that scenario, confidentiality is preserved: the handles do not become decryptable by any other means. Possible mitigations include retries and a configurable timeout; a permanent shutdown of the TSN would make the handles undecryptable forever, preserving secrecy at the cost of finalisation. There is also a direct financial consequence, verified in the contract: since withdraw requires the Settled or Cancelled states and cancelAuction requires Active, an auction stuck in SettlementRequested keeps the collateral locked. An escape route by timeout, in which the elapsing of a deadline without finalisation enables the full return of the collateral without revealing any result, is a natural extension of the contract.

Infrastructure dependence, continuity and costs. The platform dependence deserves to be separated into two layers. The contract itself is standard Solidity and resides on the blockchain; what depends on Fhenix are the CoFHE coprocessor, which executes the operations over the encrypted types and stores the ciphertexts, and the TSN, which collectively holds the decryption key (§2.3.4). A permanent shutdown of those layers does not affect the validity of already settled auctions, whose result is public blockchain state, but it would interrupt auctions in progress: without the coprocessor there is no way to process new bids, and without the TSN there is no way to reveal results, in the scenario discussed above. Nor is there a migration path for the encrypted data: since decrypting it requires the TSN's key, the ciphertexts cannot be re-encrypted for another infrastructure, and portability is restricted to the logic of the mechanism, conceptually applicable to equivalent FHE platforms, such as Zama's fhEVM (§2.3.4), at the cost of adapting the system and the decryption model. Finally, there is a cost dimension beyond gas: the operation of the coprocessor and of the TSN is maintained by Fhenix itself, with no charge to the user beyond the gas measured, and, since the platform was still in a testnet phase at the time of this work, no pricing model for those layers existed for production. The costs measured in this chapter therefore reflect only the on-chain component; a commercial deployment will also need to budget for the FHE infrastructure once it reaches the main network. These dependencies are the architectural price of outsourcing the encrypted computation, and making them explicit is part of the methodological commitment of the work.

Non-cooperating winner. A classic risk in sealed-bid auctions is that of the winner who, on discovering that they have won, refuses to complete the transaction. Here that risk is structurally neutralised: both requestSettlement and finalizeSettlement are permissionless (§4.3.4), so that any participant can close and finalise the auction after the deadline, without depending on the winner's cooperation. Nor can the winner stall the settlement for the others, since the payment model is pull-based (§4.2.5): each participant withdraws independently.

The shill bidding incident. During the smoke tests on the testnet, a vector that had not appeared on the mock was observed: the seller submitted, by mistake, a bid to their own auction. Since the mechanism accepts bids from any address, the bid was processed, and the seller's collateral became accounted for and stuck in the contract, with no withdrawal path consistent with the roles foreseen in the withdraw function. The episode motivated two defensive fixes, both described in §4.2.5: the explicit prohibition on the seller bidding (SellerCannotBid) and the reinforcement of the homomorphic cap. The case is instructive because it illustrates the value of testing on a public testnet, and not only on the mock: certain failure vectors only manifest under real conditions of use, with multiple wallets and distinct roles interacting.

5.6 Discussion: trade-offs, limitations and threats to validity

The previous results make it possible to discuss the central trade-offs of the work, its limitations and the threats to the validity of the conclusions.

Trade-offs. The cost of confidentiality is measurable and concentrated. In gas, it manifests above all in the bid operation, around an order of magnitude more expensive than a plaintext bid, and in the calldata, also around ten times larger. In latency, it manifests in WASM encryption on the client, the largest component of perceived time. In return, the system delivers a property that no conventional on-chain auction offers: the permanent secrecy of every bid except the second price, with truthfulness preserved and without a trusted auctioneer. For the use cases that motivate the work, in which strategy leakage has a real economic cost (§1.2), that is a favourable trade-off. It should be recorded that this assessment of favourability is qualitative: the references to a plaintext bid or to a commit-reveal scheme are order-of-magnitude comparison points, not baselines implemented and measured side by side under the same methodology. The controlled measurement of those baselines remains as future work (§6.3).

Limitations. Six limitations must be made explicit. First, the evaluation covers N ≤ 10; auctions with hundreds of participants were not measured, and the total cost grows linearly with N. Second, the work implements the single-unit case; the multi-unit extension remains as future work (Chapter 6). Third, the gas figures of the mock and of the testnet differ by construction (the mock simulates FHE on-chain), so that only the testnet values represent production cost. Fourth, the identity of the participants and the public cap C remain visible, as already acknowledged in §4.1.6. Fifth, the truthfulness of the mechanism is conditional on the assumption that each participant's true value does not exceed the public collateral required (v ≤ C). The homomorphic cap (§4.2.5) truncates to the collateral any bid above C, so that a participant with v > C has their effective bid reduced to C and cannot reveal v, in the classical pattern of a budget-constrained participant. For every participant with v ≤ C, the dominant strategy of declaring the true value remains preserved; the cap is the price paid for the guarantee that the winner can always honour the payment (§4.2.5). Sixth, the collateral model is full and in native ETH: each participant locks up the maximum value C throughout the auction, even if they intend to bid less, and does so in a volatile asset. The choice is deliberate, since collateral proportional to the bid would leak the bid itself through the public deposit, and uniform collateral is precisely what prevents that inference (§4.2.5); but it creates a practical barrier to entry (whoever does not have the collateral does not take part) and an opportunity cost on the capital locked up, both relevant to the adoption of the mechanism in real scenarios. Alternatives are discussed as future work (§6.3).

Threats to validity. The main threat to internal validity is the variation of Arbitrum's L1 data fee between runs, which introduces noise into the testnet gas figures; it was mitigated by repeating the measurements and by using the mock as an algorithmic reference. The main threat to external validity is the small number of repetitions (five per configuration) and the synthetic nature of the bid populations, conscious choices in the face of gas cost on a testnet; the results should be read as representative orders of magnitude, not as high-precision statistical estimates. Finally, the evaluation takes place on a single platform (Fhenix CoFHE over Arbitrum Sepolia), which limits generalisation to other on-chain FHE infrastructures.

Adherence to the success criteria. Comparing the results with the criteria defined in the scope (§1.6): the system was validated end to end on a public testnet, through the graphical interface, in demonstrations operating from the minimum required by the contract (MIN_BIDDERS = 3, cf. §4.4.4), and, through the benchmark, in the populations of 3, 5 and 10 participants defined in the scope (§1.6); the suite of twenty tests covers the critical scenarios enumerated (§4.4.5); the leakage analysis was formally structured, with an adversary model (§4.1), a capability table (§4.1.5) and a residual-uncertainty metric (§5.4); and the documentation was made available for third-party reproduction (§4.4.1). The four criteria were therefore met. The following chapter concludes the work and discusses the directions of extension opened up by these results.