FHE Goes Live: ERC-7984 and the Throughput Ceiling

Introduction

An ERC-20 transfer publishes the amount moved and the resulting balances of both parties to anyone with an RPC endpoint. For a payroll run, a treasury rebalance, or a block trade, that property is disqualifying, and the standard workaround has been to keep the transaction off-chain, settling only a netted result.

Zama’s Confidential Blockchain Protocol proposes a different arrangement. Per its litepaper, it is a cross-chain confidentiality layer that sits on top of existing public blockchains rather than a new L1 or L2, combining fully homomorphic encryption for computation on encrypted values, multi-party computation for threshold key management, and zero-knowledge proofs used narrowly to verify that user inputs were encrypted correctly. The stated roadmap put testnet live before the litepaper’s publication, Ethereum mainnet at end of 2025, other EVM chains in H1 2026, and Solana in H2 2026. Zama’s own explainer for ERC-7984, the confidential token standard, is dated 17 February 2026 and describes the standard as technology-agnostic, with the FHE implementation built jointly with OpenZeppelin.

Several numbers attached to this launch in market commentary do not appear in primary documentation: a current throughput of roughly 20 transactions per second, a 500 to 1,000 transaction-per-second target after GPU rollout, deployment volumes in confidential USDC, a named institutional OTC trade, the mechanics and date of a $ZAMA token event, and the audit status of the OpenZeppelin ERC-7984 implementation. We could not verify any of these against Zama’s litepaper, its ERC-7984 explainer, or the Fhenix and Inco documentation. They remain unconfirmed, and the analysis reasons from what the vendor documents state.

The cryptography is the mature part of this stack. Three seams carry the weight instead: the gap between what the onchain contract records and what an offchain coprocessor network computes, the asynchronous path by which an encrypted value becomes plaintext, and the committee of nodes that collectively holds the decryption key.

The cost of arithmetic nobody can see

Fully homomorphic encryption permits a party holding only ciphertexts to compute a function on them, producing a ciphertext of the result, without learning the inputs or the output. Applied to a token, an addition on two encrypted balances yields an encrypted new balance, and the machine performing that addition learns neither operand.

The overhead is structural. FHE ciphertexts in lattice-based schemes are far larger than the plaintexts they hide, and each homomorphic operation adds noise to the ciphertext. Past a threshold, noise destroys the value, so schemes periodically run a noise-reduction step that is itself the dominant cost of the computation. Zama claims its implementation is over 100x faster than five years ago and is post-quantum secure, the latter following from the lattice assumptions these schemes rest on. Both are vendor claims from a self-produced document without an independent benchmark.

The more consequential constraint for contract authors is control flow. A program cannot branch on an encrypted condition, because taking a branch reveals which branch was taken, and observers watching gas consumption or state access patterns would learn the comparison result the encryption was meant to hide. Conditionals therefore become arithmetic: both outcomes are evaluated and an encrypted selector bit multiplexes between them. A confidential transfer costs the same whether the sender has sufficient balance or not, and produces a state transition either way.

That single property propagates through the entire design. It determines how ERC-7984 handles a failed transfer, why liquidation logic is awkward to express, and why the gap between confidential and plaintext execution cost is a multiple rather than a margin. Fhenix’s CoFHE documentation exposes the same shape in its API surface, with encrypted types such as euint32 and ebool, operations such as FHE.add and FHE.sub, and explicit access-control calls such as FHE.allowThis and FHE.allowSender that govern who may later decrypt a value. Permission to decrypt is not ambient in these systems. It is an explicit grant that a contract must execute; omitting it leaves a value permanently unreadable.

Handles, coprocessors, and a gateway

Zama’s ERC-7984 explainer describes a four-part architecture, and the division of labor between the parts is where the engineering risk concentrates.

The onchain contract stores encrypted handles, which are pointers to encrypted values rather than the ciphertexts themselves. When a confidential token contract adds two encrypted balances, the Ethereum transaction does not perform lattice arithmetic. It records that an addition relating three handles is to be performed and returns the output handle immediately. The contract’s storage and the transaction’s gas cost reflect bookkeeping over handles, not the cost of the cryptography.

The actual FHE math happens offchain, in a network of coprocessors that consume the recorded operations and materialize the corresponding ciphertexts. A Gateway orchestrates those coprocessors, enforces access control over which address may read which handle, and routes decryption requests. Decryption itself is performed by a threshold key management system in which multiple independent nodes must cooperate, so that no single operator can unilaterally recover a user’s balance.

Two properties follow directly from this split. First, onchain settlement finalizes faster than the encrypted computation behind it. A transfer confirms when the handle bookkeeping is included in a block, but the ciphertext that handle points to exists only once a coprocessor has produced it. The natural failure mode under load is therefore a backlog: symbolic state advances at Ethereum’s pace while materialization falls behind, and the delay surfaces at the moment someone asks to read a value. Anything that needs a plaintext answer, including a user checking a balance or a contract awaiting a decryption callback, inherits that queue.

Second, the ZK component does far less work here than in a shielded pool. Zero-knowledge proofs are used to establish that a user-submitted input was encrypted correctly and is bound to the submitter, not to prove that any state transition was executed correctly. A malformed or adversarially crafted ciphertext accepted into the system could corrupt downstream computation or become a channel for probing the network key, so the proof functions as an input filter. In a zk-SNARK shielded pool, the proof carries the entire correctness argument and the encrypted state is never computed over by a third party. These are different security architectures that happen to share an acronym.

Zama states that existing chains require no protocol-level upgrade to support this arrangement. That claim is narrow and architecturally plausible: execution happens either in contract code or off-chain. It does not establish whether existing applications can consume the resulting state.

What ERC-7984 changes inside the contract

At the code level the standard is a type substitution with consequences. Where ERC-20 exposes uint256, transfer, and balanceOf, ERC-7984 exposes euint64, confidentialTransfer, and confidentialBalanceOf. The logical operations survive; the operands become encrypted handles that the contract itself cannot read.

The narrowing from 256 bits to 64 is not cosmetic. FHE cost scales with the bit width of the encrypted integer, so a confidential token pays directly for every unused bit of range. A 64-bit balance cannot represent an 18-decimal supply of any size, which forces confidential tokens toward fewer decimals and a smaller maximum supply than their transparent counterparts. Any wrapper bridging an existing 18-decimal ERC-20 into a confidential representation has to define a scaling convention and accept the rounding it introduces.

Insufficient-balance handling is the second structural change, and it follows from the no-branching constraint. A conventional ERC-20 reverts when a sender lacks funds, and the revert is public information. A confidential transfer cannot revert on an encrypted comparison without leaking the comparison result to observers. The design computes an encrypted transferred amount that equals the requested amount when funds suffice and zero when they do not, letting the transaction succeed either way. Callers learn what happened only by decrypting the returned value, if they hold permission to do so. Every integration that treats a successful transaction as proof of a completed transfer requires revision.

Selective disclosure as a contract feature

Zama’s implementation addresses compliance requirements through Observers, addresses such as auditors or regulators that can be granted decryption access to specified values, alongside optional extension modules for KYC and AML checks, balance freezing, and real-world-asset compliance rules. Disclosure operates as a permission grant rather than a default, enforced by the Gateway’s access control rather than operator discretion.

This design represents the core of the institutional proposal, and also the section with the least published detail. Whether an Observer grant is revocable, whether it applies prospectively or retroactively to handles created before the grant, and who may issue one on a user’s behalf are governance questions the available documentation does not settle. A freeze module in particular reintroduces a privileged actor into a system whose premise is that no privileged actor can see user state. Those two properties are compatible in principle, since freezing acts on handles without reading them, but the combination requires verification in contract code rather than feature specifications.

Where encrypted balances meet existing DeFi

The claim that Ethereum needs no upgrade is distinct from the claim that Uniswap or Aave can hold ERC-7984 tokens. The second claim is more difficult, driven by the mechanisms detailed above.

A constant-product AMM prices a swap from public reserves. If reserves are encrypted, the pool cannot publish a price, arbitrageurs cannot compute one, and the invariant check that protects the pool from mispriced trades must be evaluated homomorphically on every swap. A lending market has a sharper problem: liquidation requires that third parties verify a position is underwater, which means either the health factor is public, defeating confidentiality, or liquidators must request decryption and act on the result, turning an atomic transaction into a multi-block request-and-callback sequence with an adversary free to move collateral in between.

Asynchrony is the general obstacle. Any composition that requires a plaintext value mid-execution cannot complete within one transaction, because the decryption path runs through the Gateway and the threshold committee. Protocols designed around atomic settlement inside a single call frame do not adapt to this via simple parameterization; they require redesign.

This leaves a near-term composability surface centered on applications where confidentiality is the primary requirement and latency tolerance is inherent: payroll, where the payer knows every amount and third parties do not price assets; institutional settlement between counterparties sharing information bilaterally; and sealed-bid auctions, where the mechanism depends on values remaining hidden until a scheduled reveal, and where waiting for threshold decryption at the close is structural. Inco’s marketing for its Lightning product lists a similar set, including blind auctions, money markets, delivery-versus-payment escrow, and token vesting, claiming confidential ERC20 and SPL support “without breaking composability.” That claim requires the same standard of evaluation: not whether the base chain accepts the token, but whether an unmodified third-party protocol can price and liquidate against it.

The throughput ceiling and what it excludes

Zama’s litepaper frames scaling in three stages. Current performance runs on general-purpose processors. GPUs are described as enabling a move toward “100+ transactions/s.” Dedicated accelerators, FPGAs and ASICs, are projected to reach “thousands of transactions per second” at an unspecified future date. These are forward-looking vendor targets without a published baseline measurement.

The specific figures circulating around this launch, roughly 20 transactions per second today and a 500 to 1,000 range with GPUs, do not appear in the litepaper and could not be verified. The higher estimate exceeds Zama’s published GPU language by a factor of five to ten. What the vendor’s numbers imply is that the GPU milestone places confidential execution at a throughput comparable to a single mid-sized L2 doing plaintext work, shared across every application on the layer.

That ceiling sorts DeFi workloads cleanly. Payroll, vesting, and periodic institutional settlement generate transaction counts measured in hundreds or thousands per day, where confirmation latency of seconds to minutes is operationally manageable. Sealed-bid auctions and OTC settlement operate as batch processes. None of these are throughput-constrained on the published roadmap.

Continuous markets face different constraints. Spot AMM trading, perpetuals funding updates, oracle-driven liquidations, and intra-block execution strategies require both throughput and bounded latency, with latency being the binding constraint. Even at higher throughputs, a system in which reading a value requires a threshold decryption round cannot support competitive liquidation. If FHE-based confidentiality serves those markets, it will do so by concealing specific fields, such as order sizes or collateral composition, inside systems with public price formation. That is a narrower product than general confidential DeFi.

There is also an unaddressed cost dynamic. Onchain gas for handle bookkeeping is low; FHE computation occurs on coprocessors that require compensation. How that cost is metered, who bears it, and whether the pricing model withstands demand spikes are economics not established in available documentation. A system whose primary computational cost sits outside the settlement layer’s fee market must establish a secondary fee market where congestion will concentrate. Fhenix’s documentation offers a relevant note: its local mock environment simulates FHE by storing plaintext onchain, and the documentation notes that mock gas costs differ from production. Pre-mainnet benchmarks from these stacks should be evaluated with that gap in mind.

Who holds the key shares

The threshold key management system is the component of this architecture that most resembles a conventional trust assumption, and the available sources provide the least specification for it.

Zama states that decryption requires multiple independent nodes to cooperate, preventing any single party from decrypting user data unilaterally. The documentation does not disclose the total node count, the reconstruction threshold, the selection and removal mechanics for operators, operator jurisdictions, or whether the key can be resharded without a plaintext reconstruction step. Each variable directly affects system-level balance security.

Direct comparison clarifies the trust trade-offs. On a plain public L1 there is no decryption step, leaving no committee to compromise or compel; the trade-off is complete transparency. In a hardware-enclave design, confidentiality depends on the processor vendor’s secure execution environment and the absence of side-channel vulnerabilities, concentrating trust in the hardware supply chain. In a threshold scheme, confidentiality holds as long as fewer than the threshold number of node operators collude or are compelled, distributing trust across operators without eliminating custody assumptions entirely.

Two failure modes require distinct evaluation. Confidentiality fails if a threshold-sized coalition reconstructs the key, which depends on jurisdictional distribution. Liveness fails if the committee declines to process decryption requests. A user whose balance remains encrypted but who cannot obtain a decryption cannot prove ownership or exit through contracts requiring plaintext values. Censorship in a confidential system takes the form of unfulfilled decryption requests rather than rejected transactions.

Zama’s litepaper includes a comparison table scoring its protocol as simultaneously secure, decentralized, verifiable, composable, scalable, and easy to use, while classifying TEE-based approaches as lacking security and verifiability, and other FHE, MPC, and ZK systems as deficient in scalability or usability. That comparison represents vendor positioning. The underlying technical trade-off remains concrete: hardware trust and threshold trust present distinct failure modes.

Matching the mechanism to the adversary

The current state of implementations remains varied across providers. Zama’s litepaper lists Ethereum mainnet as an end-of-2025 target, with an ERC-7984 explainer published in February 2026 discussing use cases. Fhenix’s CoFHE documentation specifies support for Ethereum Sepolia, Arbitrum Sepolia, and Base Sepolia, with production mainnet support pending. Inco markets Lightning as a library import offering native chain speed with no new VM, while claiming post-quantum security without naming the underlying mechanism. Near-native latency is inconsistent with standard FHE overhead profiles, leading to assumptions that hardware enclaves are used, though primary documentation does not confirm this.

Selecting an approach depends on the threat model rather than feature lists. Where an application must compute over data the user cannot withhold, and where latency on the order of seconds is acceptable, FHE with threshold decryption provides strong cryptographic isolation within low-frequency throughput limits. Where native base-chain latency is required, enclave-based execution is the active alternative, accepting hardware-level trust assumptions. Where the goal is proving valid execution without state computation by third parties, zero-knowledge proofs offer a lower-overhead construction.

Confidential payroll and bilateral settlement fit threshold FHE architectures. Order-flow privacy in continuous markets does not, as implementing it under current constraints introduces trusted operators or structural latency.

Where the thesis can break

The primary open questions are operational rather than cryptographic. Documenting the composition and governance of the threshold committee will establish whether decryption relies on operators across multiple legal jurisdictions or a concentrated group. Independent mainnet benchmarks measuring latency from transaction submission to readable output will clarify practical throughput. An audit report for the OpenZeppelin ERC-7984 implementation would confirm whether clamped-transfer and access-control semantics hold under adversarial sequencing.

Economic factors require equal scrutiny. Coprocessor computation represents the scarce resource and is priced outside the base settlement market. Until fee mechanisms are formalized, congestion dynamics remain uncharacterized. A confidentiality layer where decryption latency spikes under load risks making account balances temporarily unreadable.

Adoption metrics should be evaluated by protocol integrations rather than isolated transfer volumes. Confidential transfers between known counterparties demonstrate the standard’s basic execution path rather than general composability. The critical milestone to monitor is an unmodified third-party protocol, such as a lending market or AMM developed without ERC-7984 integration, pricing and settling against an encrypted balance in production. Until that integration is demonstrated, encrypted balances operate primarily within bounded multi-party workflows rather than open DeFi architectures.