Privacy has a price: the honest math behind confidential settlement at scale

Every privacy claim in blockchain infrastructure should be tested against a simple question: does it tell you what the trade-off is, or does it tell you there isn't one?

Anyone claiming you can have the privacy of a fully shielded transaction with the throughput of an unencrypted public chain is making one of two errors. They are either misrepresenting what their system actually does, or they are measuring against a workload that does not stress the system the way real institutional volume would. In neither case is the claim something an institution should base a procurement decision on.

There is a cryptographic cost to privacy. This is not a marketing inconvenience that better engineering will eventually eliminate. It is a mathematical fact about how confidentiality is constructed in a verifiable system. Understanding where the cost comes from, where it can be reduced, and where it cannot, is essential for any institution evaluating privacy infrastructure for real workflows.

This post is about the honest math. We will explain where the overhead lives, what can be tuned, and what is fundamentally bounded by the cryptography itself. We will also explain why, for the workflows Enygma was built for, the honest answer about performance turns out to be a competitive one.

Why a confidential transaction costs more than a transparent one

Imagine the simplest possible transaction on a transparent public blockchain. The sender's balance is a public number. The recipient's balance is a public number. The amount is a public number. The transaction itself is a single signed message that asserts "subtract this amount from balance A, add this amount to balance B." The network verifies the signature, checks that balance A is sufficient, and updates the two balances. That is the whole computational story.

Now consider the same transaction with privacy. The sender's balance must not be visible. The recipient's balance must not be visible. The amount must not be visible. But the network must still be able to verify that the sender had sufficient balance, that the amount being deducted equals the amount being credited, that no balances were inflated out of thin air, and that the sender was actually authorised to spend the funds.

The network has to verify all of this without seeing any of the underlying numbers.

This is what a zero-knowledge proof does. The sender constructs a proof asserting that all of the verification conditions hold for the hidden values. The network checks the proof and updates the (hidden) balances accordingly. The privacy is preserved. The correctness is verified. But the proof has to be generated, and proof generation is not free.

The total cost of a confidential transaction breaks down into three categories.

Proof generation. For each confidential transaction, the sending party must construct a zero-knowledge proof that satisfies the verification constraints of the system. Proof generation is computationally intensive. In practical terms, a single proof for a basic confidential transfer can take from several hundred milliseconds to several seconds on commodity hardware, depending on the circuit complexity. This is typically the dominant cost in a confidential transaction.

Commitment construction and balance updates. Confidential balances are stored as cryptographic commitments rather than as plain numbers. A Pedersen Commitment, the scheme used in Enygma, encodes a value as a point on an elliptic curve. For typical institutional volumes, the cost per commitment is manageable, but the total cost scales linearly with the number of operations.

Network propagation and verification. A confidential transaction carries more data than an unencrypted one. The proof must then be verified by the network, which for usually involves a small fixed number of pairing operations: cheap relative to generation, but not zero.

Across the three categories, the dominant cost is proof generation. Verification is fast. Storage is moderate, until there is a clear purging strategy. Bandwidth is moderately higher than for an unencrypted transaction. Generation is where the time goes.

What can be optimised

The cost can be reduced. It cannot be eliminated. Understanding the distinction matters because most performance improvements in privacy systems sit at the boundary between these two facts.

Several optimisation strategies have proven effective in production systems.

Batching and aggregation. Multiple proofs can be aggregated into a single verification step.  Aggregation reduces verification cost dramatically and can reduce per-transaction proof size.

Hardware acceleration. Proof generation is amenable to parallelisation and to specialised hardware.  Hardware acceleration does not change the asymptotic cost, but it changes the wall-clock latency by an order of magnitude, which is often enough to move a use case from impractical to viable.

Recursive proof composition. A proof can attest to the validity of another proof. This makes it possible to compress long histories into short proofs, and to verify entire batches of transactions with a single proof at the top of the recursion.

More efficient proving systems. Groth16 is well-suited for the institutional setting because of its small proof size and fast verification, but it requires a trusted setup ceremony and is not trivially upgradeable. The choice of proving system is itself an optimisation lever, and the right choice depends on the workload.

Workload partitioning. Not every operation in a financial workflow needs the same level of privacy. The Enygma architecture distinguishes between intra-bank operations (occurring within a single institution's Privacy Node) and inter-bank operations (occurring between institutions across the Rayls public chain). Intra-bank operations do not require the full machinery of Enygma's inter-bank protocol, because the data is already within the institution's sovereign boundary.

The honest performance story for Enygma is two-tiered: high throughput for intra-bank activity, where the cryptographic cost is bypassed because the privacy boundary is the institution itself, and a different throughput regime for inter-bank settlement, where Enygma's full cryptographic machinery is in play. Most discussions of "blockchain TPS" implicitly assume a single, uniform workload. Real institutional settlement does not look like that.

What cannot be optimised

The fundamental limit is set by the cryptography itself. Some costs do not go below a floor determined by the mathematical operations involved.

A ZK proof requires a fixed number of pairing operations to verify. Each pairing operation has an irreducible cost on a given hardware platform. No software optimisation can drive this below the cost of executing the pairing.

This is why the honest framing of privacy performance is in terms of a trade-off curve rather than a single number. You can move along the curve by trading proof size against generation time, or by trading prover cost against verifier cost, or by trading trusted setup requirements against asymptotic efficiency. You cannot move the entire curve to the position of an unencrypted system. The cryptography does not allow it.

The privacy trilemma in this space is usually stated as: confidentiality, scalability, and decentralisation, of which you can have any two but not all three at the maximum level simultaneously. For institutional finance, the trilemma is often more practically stated as: confidentiality, throughput, and auditability. Enygma's design choice is to hold confidentiality and auditability at the maximum, and to optimise throughput against that constraint. A different design that abandoned auditability could deliver higher throughput at the same confidentiality level. A different design that abandoned confidentiality could deliver much higher throughput. Both are real systems. Neither is the right system for regulated institutional settlement.

The institutional question, properly framed

For an institution evaluating privacy infrastructure, the relevant question is not "what is the TPS?" The relevant question is "what is the throughput at the level of privacy and auditability my use case actually requires?"

The answer differs significantly across institutional workflows.

For interbank settlement, the relevant volumes are comparatively low. A large correspondent banking relationship may involve a few thousand transactions per day. A central bank operating an RTGS-equivalent service on tokenised infrastructure may handle a few tens of thousands of large-value transfers per day. These volumes are well within the throughput envelope of a confidential settlement system, even before considering optimisations like batching and aggregation. The performance question is not whether the system can handle the volume, but whether it can handle the volume while preserving every other property the institution requires.

For tokenised treasury and intra-group operations, the volumes are higher but the privacy boundary is internal to the institution. Throughput within a single Privacy Node is bounded by the institution's own compute, not by Enygma's cryptographic overhead. The performance question is one of infrastructure provisioning, not protocol design.

For cross-border payments, throughput is rarely the binding constraint. Finality, atomicity, and the ability to settle in the time it takes for two parties to agree are the binding constraints. A confidential cross-border transfer that settles in seconds, even at "low" headline TPS, dramatically outperforms a correspondent banking equivalent that takes days. The comparison the institution should be making is to the system being replaced, not to an idealised public-chain benchmark.

For retail payments, the throughput question is genuinely binding. Confidential retail payment volumes at the scale of national payment systems are beyond what current confidential transaction systems can deliver in a fully shielded model. This is an honest acknowledgment of where the technology stands today, not a critique specific to Enygma. The institutions evaluating privacy infrastructure for retail payment volumes should expect to make architectural trade-offs: tiered privacy models, selective shielding, off-chain confidentiality for high-frequency segments. The cryptography is not yet at the point where full shielding at retail volumes is a realistic specification.

The right way to evaluate a privacy infrastructure is not to ask for the headline TPS number. It is to ask for the throughput at the specific privacy and auditability level the use case requires, on workloads that resemble the institution's actual workflow. Vendors that can engage at that level of specificity are vendors whose performance claims can be relied upon when production volumes hit the system.

How Enygma balances the trade-off

Enygma's design occupies a specific point on the trade-off curve, and that point is the result of deliberate decisions.

The cryptographic confidentiality is maximised: full shielding of amounts, counterparties, and balances, with mathematically enforced selective disclosure for regulators and auditors. There is no compromise on this dimension.

The auditability is maximised: every transaction is provably correct, viewing keys are scoped and revocable, the audit trail is durable. There is no compromise on this dimension either.

The throughput is optimised against those two constraints. Intra-bank operations bypass Enygma's full machinery, because the privacy boundary is the institution itself, and throughput within a Privacy Node scales with the institution's own compute. Inter-bank operations use Enygma's full cryptographic stack, with proof generation as the dominant cost, and with batching, aggregation, and hardware acceleration as the levers for optimising that cost.

The decentralisation question is handled by the architecture: the Privacy Node model gives each institution sovereignty over its own infrastructure, the Rayls public chain provides the inter-institutional settlement layer, and the two are connected by the protocols described in earlier posts in this series.

The result is a system that is honestly performant for the workflows it was designed to support, and honestly limited for the workflows it was not. That is the right framing for institutional infrastructure. The wrong framing, the one we have deliberately avoided, is the one that promises every property at the maximum level simultaneously and quietly hopes the procurement team will not ask the question that exposes the trade-off.

Enygma's performance is real performance, not headline performance. The architecture is designed to optimise the trade-off intelligently, not to disguise it. The trade-off is presented honestly because, at the volumes and use cases Enygma was designed for, the honest answer is also a competitive one. Institutions that compare like for like, against the workflows they actually need to run, find the system delivers what they require with the cryptographic guarantees they cannot afford to give up.

That is the only kind of performance claim that survives contact with production.