We’ve launched NetiRails: infrastructure for stablecoin-based cross-border paymentsExplore NetiRails

How Neti built confidential stablecoin payments that a regulator can still audit

See how Neti built private stablecoin payments hidden from the market but readable by a regulator through a view key, and tested them with real money.

Shortly

A company that runs its own payment systems, and had issued its own stablecoin, wanted transfers of that token to stay private. Not anonymous: hidden from the market, readable by the company and its supervisor on demand. Neti ran a four-month research project to find out whether a private stablecoin payment could work that way, fast enough to be a real payment.

  • The requirement was confidentiality, not anonymity. Transfers invisible to the market, decryptable by an authorised party through a view key.
  • Neti evaluated three approaches, chose one with the client, and stripped it down to what the business needed.
  • The confidentiality step ran in roughly three seconds in a browser, inside the window a checkout can absorb.
  • Two mechanisms were built that had no off-the-shelf equivalent: payments without a persistent wallet, and transfers that wait on-chain until a bank payment settles.
  • Tested with real money on a live network. Every question the project set out to answer was answered.
  • The client then chose a different, simpler approach and carried Neti's findings into it. This case study says so.

Client: a company that operates its own payment systems. Neti built three things for it: a self-custody mobile wallet, a stablecoin issuance platform for the client's own token, and this research track on private transfers of that token.

Services: zero-knowledge proof and privacy engineering · shielded transactions · R&D and proof of concept

Industry: payments, stablecoins

The problem: a public blockchain publishes every payment

Move money through the banking system and the details stay between you, your counterparty and your regulator. Move the same money as a stablecoin on a public blockchain and the details are published: the amount, the receiving address, and the sender's remaining balance, permanently, to anyone who looks.

For a consumer sending twenty euros, that is a curiosity. For a payments business it is a commercial problem. Merchant payout volumes become public. Counterparty relationships become public. Treasury positions become public. Anyone can watch a competitor's flows in real time.

This client had already made the decisions that led here, and they were the right ones. It ran its own payment systems. It had issued its own stablecoin rather than use a public one, and it ran its own wallet product. What remained was the one thing a public blockchain refuses to give by default: discretion.

In September 2025 the client came to Neti with two requirements:

  1. When one party pays another, the recipient must not be able to see the payer's balance.
  2. The transfer must not reveal who sent it.

Private is not anonymous, and the difference is the whole project

There is an obvious way to hide a blockchain transaction, and it is unusable. Tools that provide blanket anonymity, generically called mixers, cut the link between sender and recipient for everybody, permanently, including the operator and the supervisor. A regulated business cannot go near them. Several have been sanctioned.

What a regulated business needs is the opposite arrangement: confidential to the market, readable to the authorised party. Every transfer is still recorded and still reconstructable, but encrypted. A designated holder, normally the compliance function, holds a view key that decrypts specific transactions on request. The market sees nothing. The supervisor sees what it asks for.

This is what makes private stablecoin payments compatible with stablecoin compliance, and it is the property that separates a privacy feature a regulator can accept from one that ends the conversation.

Whether a given disclosure mechanism satisfies a given supervisor in a given jurisdiction is a legal question, and this project did not answer it. What it established is that the mechanism exists, performs well enough, and can be built into a payment product. Your counsel decides the rest.

Weighing privacy for your own stablecoin flows? Talk to Neti about the architecture before you pick a privacy stack.

The engineering, in plain terms

Confidential transfers work by moving funds off the public record into a shielded layer on the same network. Putting money in is cheap. Taking it out is the expensive part, because at that moment the system has to prove that the person withdrawing is entitled to the funds, without revealing who they are or what they hold.

The tool that does this is a zero-knowledge proof: a piece of mathematics that shows a statement is true while revealing nothing else. In payments terms, it proves the transfer is valid and the party is entitled to the funds, without publishing names, amounts or balances.

Generating that proof takes real computation. The client wanted it to run in an ordinary web browser on the customer's own device. Existing implementations assumed a powerful computer and were slow enough that a transfer stopped feeling like a payment.

Neti spent about two weeks reworking the proving path for the browser. The result was roughly three seconds per proof. Not a record, and Neti's own view was that it could go lower. But three seconds fits inside a checkout. Below that line this is a payment product. Above it, it is a demo.

What Neti built

Choosing the foundation, and what to remove

The solution had to run on an EVM network. Neti surveyed the options, brought three candidates to the client with an explanation of how each worked, and the choice was made together: Railgun, an open-source privacy system. It won for two plain reasons. It was open source, and it was already widely used. A privacy system nobody else runs is one whose flaws you discover yourself.

Adopting it was not installing it. Two components came out.

A duplicate screening step. Railgun's Proof of Innocence screens every entry into the shielded layer against risk lists. That is right for an open system anyone can join. Here it was redundant: the client had already run full KYC on every user before they could reach the payment flow. Removing it did not weaken compliance, because the control it duplicated was stronger and sat earlier.

A fee. Railgun charges per transaction. The client did not want to.

There was also an assumption to change. Railgun expected the recipient's key to exist at the moment a transfer was built. The client needed transfers to recipients whose key did not exist yet, and Neti reworked that part so it did not have to.

This is what open source is good for in a regulated product: you take the cryptography and leave someone else's business model behind.

Payments without a persistent wallet

The client wanted a customer to be able to pay without holding a blockchain wallet at all. Neti built a one-time wallet: the customer opens a page, an address is generated, funded, used once and abandoned. No key is kept, and nothing links the address back to the customer afterwards.

This is not a convenience feature. A reused address is itself an identifier, and reusing one quietly undoes the confidentiality everything else provides.

Transfers that wait for the bank

The second requirement came from payments reality, not cryptography. A customer buys ten of the client's stablecoins, pays by instant bank transfer (BLIK), and the tokens should arrive privately at a merchant. The bank leg takes time to settle, but only the payer can build the confidential transfer, and the payer is about to walk away.

Neti built a frozen transaction. The payer builds and signs the transfer, which is held in a smart contract instead of executing. When the bank payment settles, the platform releases it. The payer never has to wait, keep a wallet or come back.

For a payments reader this is the most transferable mechanism in the project. It bridges a settlement timeline the bank controls and a transfer only the customer can authorise.

What was proven

Testing ran on a live network with real money, moving funds between the Neti team and the client rather than in a sandbox. The client saw results every week, on a fixed weekly call.

Question

Answer

Can confidential transfers run inside an existing wallet product?

Yes

Are they fast enough to feel like a payment?

Yes, roughly three seconds per proof in a browser

Is the transfer hidden from the market?

Yes, payer balance and identity are not exposed

Can a supervisor get readable access on demand?

Yes, through a view key that decrypts the transaction data

What the client did next

While this work ran, the client evaluated another approach in parallel. It chose that one: simpler, lighter and better at scale. It carried results from several phases of Neti's research into it.

That is the correct outcome of a well-run research project. In four months the client bought answers that no vendor deck could give: which systems survive a real regulatory constraint, what one costs once stripped to what the business needs, whether confidentiality fits inside a checkout, and what payments without a persistent wallet require. It then made a better decision in December than anyone could have made in September.

A supplier who only shows you projects that ended in a deployment is choosing which evidence you get to see.

One token, three layers

This research is one of three pieces Neti built for the same client.

  1. The token and its supply. A stablecoin issuance platform that mints and burns the client's own stablecoin against a 1:1 fiat reserve, with multisig on every change in supply.
  2. The wallet. A self-custody app built to let users hold and pay with that token.
  3. Privacy. The research described here: private transfers of that token, readable by a supervisor through a view key.

Issuance answers who controls the money. The wallet answers how it reaches users. Privacy answers what the rest of the market gets to see.

What this means if you run a payments business

Decide the disclosure question before the privacy question. The technology follows from what your supervisor needs to see. Teams that pick a privacy stack first often find it has no disclosure path and start again.

Confidentiality has a latency budget, and it is short. A privacy step sits on the payment path. If it does not fit your checkout, it is not a payment feature, however sound the cryptography.

Your existing KYC is an asset. Because this client verified users before they reached the payment flow, a whole duplicate screening layer could go.

Bound the research. This ran with a weekly cycle and an explicit willingness to call a path dead. That is what kept it from becoming an open-ended bill.

Facing a similar decision?

This case is relevant if you are:

  • A payments company or EMI whose stablecoin flows are visible to competitors
  • Working out what your supervisor would need to see before you could offer private transfers
  • Weighing an existing privacy system against building your own
  • Unsure whether a confidentiality step fits inside your checkout latency
  • Running a research track and unsure how to bound it

Related reading: How Neti designed and built a stablecoin issuance platform with 1:1 proof of reserve and multisig-governed minting · How Neti put a client's own stablecoin in users' hands without building a wallet from scratch · Confidential yet compliant: how zero-knowledge proofs redefine financial infrastructure

About Neti

Neti builds payment infrastructure for payments companies, EMIs and fintechs: shielded transactions and selective disclosure, stablecoin payments and settlement, issuance and treasury systems, payment orchestration and reconciliation. We work architecture-first. Before features, we define who is allowed to do what and who has to be able to see it afterwards. We run research as research, bounded and weekly, and we tell you which paths turned out to be dead.

Book a 45-minute architecture review. We will map your confidentiality requirement against the available approaches, name the ones your regulatory position rules out and why, and tell you what a scoped proof of concept would need to establish before you commit budget.

Discuss your confidentiality architecture with Neti.

FAQs

Selective disclosure is an arrangement where transaction details are hidden from the public but readable by an authorised party on demand. Transfers are recorded and encrypted rather than published, and a designated holder, normally compliance, holds a view key that decrypts specific transactions for review. It is what separates confidentiality a regulator can accept from blanket anonymity, which regulated businesses cannot use.

Yes, if privacy is built with a disclosure path. Transfers can hide amounts, balances and counterparties from the market while a view key lets compliance or a supervisor decrypt specific transactions. Blanket anonymity with no disclosure route fails that test. Whether a specific design satisfies a specific regulator is a legal question for counsel.

Only those that keep a disclosure path. A system is workable when transaction data is hidden from the market but recoverable by an authorised party, typically through a view key. Mixers, which offer blanket anonymity with no disclosure route, fail this test whatever their technical merits.

They operate at different layers. KYC identifies the customer before they reach the payment flow and is unchanged by confidentiality. Selective disclosure governs what is visible afterwards. In this project the separation was clean enough that a duplicate per-transaction screening step built into the underlying privacy system could be removed.

Partly. A proof can show that a condition holds, for example that a party is approved to transact, without exposing the data behind it. What proofs cannot do is support investigation after the fact: when a supervisor asks what happened in a specific transfer, somebody has to decrypt it. That is why a view key is not optional in a regulated deployment.

Three layers. Control of the token itself, which means an issuance platform governing supply against reserves. A confidentiality layer that handles encrypted transfers and the proofs that validate them. And a disclosure layer that decides who holds the view key and under what authority. The third is the hardest to retrofit, because the data a supervisor will ask for has to be captured in recoverable form from the first transaction.

Anonymity cuts the link between a payment and the people behind it for everyone, including the operator and the supervisor. Privacy hides payment details from the public while keeping them recoverable by an authorised party, usually through a view key. Regulated payments businesses can use privacy. They cannot use anonymity.

The audit trail is not lost, it is encrypted. Every transfer stays recorded and reconstructable by the view key holder, while amounts, balances and counterparties stay off the public record. In this project two mechanisms made it work as a payment: a one-time wallet, so the payer needs no persistent blockchain identity, and a frozen transaction, so the private transfer can wait for the bank payment to settle.

A frozen transaction is a transfer that the payer has fully authorised but that is held rather than executed, and released when a condition is met. Here the condition was settlement of a bank payment. It solves a payments timing problem: only the payer can authorise the confidential transfer, but the money they pay with arrives on the bank's schedule.

This project ran four months, September to December 2025, starting with one engineer and growing to three. That covered surveying the options, selecting and adapting one, reworking the proving path for the browser, building the two payment-specific mechanisms and testing on a live network with real money. It did not include production hardening, a security audit or a supervisory review.