Two Questions That Decide Whether a Payment Is Private

Two days in a room in London, at the LFDT privacy workshop, with market infrastructures, a couple of central banks, and the builders there to explain their approaches. Everyone seemed to want the same thing: private transactions, privacy-preserving settlement, confidential this and private that. Somewhere on the first day it became clear that the room was nodding along to a word none of us was using the same way.

In short

• For a payment, “private” means little until you answer two questions: private about what, and verifiable to whom.
• The amount is the least sensitive part. Who paid whom, the transaction graph, is the real exposure, and most confidential payments hide the figure while leaving the graph in plain sight.
• Privacy runs on a spectrum, from confidential to fully graph-private, trading throughput for concealment. The settings worth having stay auditable to a regulator while private to everyone else, which is what gets a system past a compliance officer and a CISO.

Two questions

It was one of the more useful points to come out of the two days, so it is where we start. “Private” is underspecified. For a payment it is close to meaningless until you answer two questions.

Private about what? A payment is not one fact but several: the amount, the parties, whether it happened at all, the pattern of who pays whom over time. Hiding one of these is not hiding the others, and they are not equally sensitive.

Verifiable to whom? Something is now concealed, and someone still has to be sure the sums are right and the rules were followed. Whether that someone is a single operator you are asked to trust, a regulator with cause, or anyone holding a proof, will decide the fate of the system you’re trying to build.

Answering those two differently leads to very different outcomes, and those differences make up an entire industry.

What a payment gives away

Let’s start with what a payment actually discloses. If it were just a number, we’d have long been done with the banking industry. Payments record that value moved, how much, and between whom. Of the three, the amount is usually the least sensitive. What tends to matter is the rest: that a payment happened at all, and who stood at each end of it. A fund does not mind you knowing it traded. It minds you seeing that it is building a position through the same two brokers before it has finished. A company working through a difficult stretch does not fear the size of an invoice. It fears someone noticing a run of payments to restructuring counsel. The amount is discreet, but the relationship, and the fact that a transaction happened at all, is often the most sensitive.

Most of what gets called private finance today conceals the amount and stops there. That is known as a confidential payment, and it is the least of what privacy can mean here. It leaves the counterparties, and the fact of the transaction, in plain view. It is also, on its own, unverifiable: the figures are hidden and everyone is asked to trust a black box that things still add up, which is not how finance prefers to be reassured.

Five settings, one payment

The demo that follows is an illustrative example, but it’s worth noting that it describes an existing system. The identity version of it, proving that someone is one real person without learning who they are, already runs in production for more than 18 million people.

It is easier to show than to describe. Below is a single payment, shown a few ways, at increasing degrees of privacy with a description below. Click through them.

• Public.
  Everything is in plain sight. The amount, the account addresses, and the fact that they transacted are all written to a public ledger, for anyone to read and verify onchain. This is the default on a transparent chain, and the starting point everything below is trying to improve on.

• Confidential.
  The amount is concealed and nothing else is. You can still read who paid whom, how often, and in what pattern. The arithmetic is taken on trust, or on hefty verification processes, because nothing is proven. It is useful, and it is where most solutions stop. Anything that later needs oversight is disclosed through the usual channels anyway, which rather hands back what was being protected in the first place.

• Confidential, with a proof.
  The amount stays concealed, but the transaction now settles with a proof that the computation was valid and that the balances reconcile, a coSNARK, which anyone can check without seeing the underlying data. Nothing more is hidden than before. What changes is that no one has to be trusted. This is the line between a private computation and one with integrity.

• Private.
  Now the counterparties are concealed too, and state changes stay verifiable. The public record shows that something valid happened, and settles it, without who or how much. One precise point: to compute at all, the network still resolves who is transacting internally. What it does not do is write that to a public ledger for the rest of time.

• Graph-private.
  The last thing to conceal is the relationship itself, the transaction graph, so that not even the parties running the system can see which accounts a transaction touched. This is the hard problem. It is where most of our research sits, and while it is slower than the rest, it is the version almost no one else is offering. It is also the one the room kept returning to, because it is the only version that protects the thing that finance moving onchain is most exposed on.

The pieces

These settings can be realised by a system tasked to hide different kinds of information, built from a handful of cryptographic primitives.

• Multiparty computation is the core of it. The state is split into secret shares held by a set of mutually distrusting parties, who cryptographically compute on those shares without any of them ever seeing the underlying values. It is what conceals the amounts, and because several parties can compute over the same shared state, it is also what lets more than one account transact against the same book, which is exactly what is lost when every user is off hiding their own balance alone.
• Collaborative SNARKs, or coSNARKs, are how that computation proves itself. The network produces a zero-knowledge proof that a transaction was valid and that the balances still reconcile, checkable by anyone without seeing a single input. This is what separates a private computation from a trustworthy one.
• Private shared state is the arrangement that makes it a ledger rather than a one-off computation. The balances stay secret-shared on the network; what goes onchain is a commitment and a proof, rather than the balances themselves. Transactions update the shared state off-chain and settle against that commitment in public.
• The oblivious map is what you add when hiding the amounts and the balances is no longer enough. Reads and writes touch the state without revealing which entry moved, so the pattern of access, which account paid which, stays hidden even from the parties running the network.

Beyond payments

Because the state is private, shared, and provable, the same machinery can do more than move money. It runs compliance, where a transaction can be privately checked and specific details can be disclosed to an authorised auditor after it settles. It supports private multiparty custody, where no single party ever holds the whole key or sees the whole balance. It does identity verification, proving that someone is eligible, or simply that they are one real person, which is the piece already in production. It runs x402, the pay-per-call rail for agent and machine payments, which needs precisely this kind of cheap, confidential settlement. And it runs private yield, earning in vaults and lending markets without advertising the position. Payments are where an institution starts on private shared state, but they are not where it ends.

What it costs

How far down the settings you go is a question of how much you ask the system to conceal, and how much throughput you are willing to sacrifice doing it. The amounts come cheap. The relationships are expensive, because hiding them means every access has to look like every other, and that is the oblivious map doing the heavy lifting.

Here is what each setting costs, measured rather than promised.

The drop from thousands to roughly ten transactions per second is the price of hiding the graph. It is also, as far as we know, the only cryptography-based approach that delivers private shared state and transaction graph privacy at once. Most flows live near the top and always will; the ones that genuinely need the bottom row can pay for it, and our goal is to get the private row to ten thousand as the primitives and hardware improve. These are mid-2026 numbers.

It is worth asking where traditional finance already sits on this scale. It gets its privacy the old way, by keeping the ledger off the public record entirely: the amounts, the parties and the relationships are all hidden from the public, but only because they sit in full view of the operator and its regulators, on trust. Nothing is publicly verifiable, and composability is difficult because each institution maintains its own book. That is private about almost everything and verifiable to almost no one, a different trade from any setting above.

The checklist is the checklist is the checklist

As much as we are here for the tech, none of this reaches the institutions and enterprises on cryptography alone. Another important conversation in that room was not about primitives. It was about the two people who can end a project before it starts: the compliance officer and the CISO. Win them and the rest follows. Fail to, and the cleverest privacy in the world stays on a testnet.

The compliance officer sees “private” and reads “unauditable”, reasonably, because for years ‘private’ meant exactly that. The answer is that this kind of privacy is not opacity. A transaction can be privately checked, and disclosed, in specific detail, to the people entitled to see it once it settles. The regulator gets what it is owed, and everyone else gets a proof that the rules were followed and nothing more. That is a stronger position than the arrangement in place today, where compliance requires handing over everything and trusting it is looked after.

The CISO hears “move it onto a public chain” and reads “new attack surface”, and again, reasonably. The honest answer is the trust model, stated plainly. No single party holds the balances or the keys, it takes collusion across independent operators to see anything at all, and the network cannot touch client funds without a request placed on the public record first, which is also the way out. Correctness is proven rather than asserted, and the core is post-quantum secure today. A single database is one breach away from everything; this is not. Put that way, moving onchain stops being the reckless option and can become the more defensible one.

That argument is won in the language of controls and blast radius, not elliptic curves.

If we think back to the fund building its position, or the company paying its counsel, neither is asking to disappear, but each is asking two things. Private about what? The fact that would undo them, never the amount. Verifiable to whom? A regulator, the moment it has cause, and no one else. Private onchain finance needs both answers at once. Now you can give them confidently.

Many thanks to LFDT, and to Howden for hosting us, and to everyone who spent two days discussing with us in good faith.