Privacy without an operator

“Private” is doing a lot of work in payments right now. It can mean that your bank keeps your statement away from strangers. It can mean a private ledger run by one company, where outsiders see nothing and the company sees everything. Or it can mean that no single party holds the full picture at all. These are different promises, and it is worth naming which one a product makes.

The operator model

Most private payment systems keep a trusted party in the middle. It runs the ledger or the sequencer, admits users, screens funds, and can pause activity. Outsiders learn nothing, which is a real improvement over a public chain. But the operator can read every balance and every payment, and keeps that view for as long as it keeps the data.

For some users this is the correct shape. A large company that already holds its contractors' records, has to reconcile every payment, and reports to regulators loses little by adding one more party with a view. The operator is part of a relationship it already has.

For everyone else it moves the problem rather than solving it. A person, a contractor, a small team or a software agent gains privacy from the public by giving a complete record to someone new. That record can be breached, subpoenaed in bulk, sold, or simply misused. Privacy that depends on one party behaving well is a policy, not a property.

What “no operator” means in UMBR

UMBR is a shielded pool: a contract on a public chain that holds everyone's private balances together. When you shield funds, the pool stores a commitment, a value that hides the amount and the owner but can be opened by whoever holds the secret. The secret is created on your device and stays there.

To spend, your device builds a zero-knowledge proof. It shows the contract that you own some unspent note in the pool and that the outputs balance, without saying which note is yours or what it holds. The contract publishes a marker so the same note cannot be spent twice, and new commitments for whoever you paid.

That leaves no seat for a party with a full view:

• The UMBR team never holds your note secrets, so we cannot read your balance or your payments.
• There is no admin function that moves pooled funds. The contract releases money only against a valid proof.
• There is no account to open with us. Anyone with a wallet can use the pool, and anyone can read the contract.

The relayer, precisely

There is one helper in the picture, and it is optional. If you submit a private payment from your own wallet, your address pays the network fee and appears as the sender of that transaction. A relayer avoids that: you hand it a finished proof and it submits the transaction from its own address. Because a relayer is the place where people most often assume an operator is hiding, here is exactly what it can and cannot do.

The honest summary: a relayer is a courier for a sealed envelope. It can see that an envelope exists, when you handed it over and from which network address, and it can refuse to carry it. It cannot open it or change where it goes. If one relayer refuses, use another or submit from your own wallet.

Where privacy stops

No design hides everything, and pretending otherwise is how people get hurt. In UMBR:

• The edges are public. Shielding shows the depositing address, the asset and the amount. Unshielding shows the receiving address, the asset and the amount. What stays hidden is the link between them, your balance, and who paid whom inside the pool.
• The crowd matters. If you shield 1,234.56 and withdraw 1,234.56 an hour later in a pool with few users, the link is easy to guess. Privacy improves as more people use the pool, and a new pool is a small crowd.
• Your device matters. Your notes live on it. Malware there can see what you can see.
• Issuers keep their powers. Stablecoin issuers can block addresses or freeze tokens under their own policies, at the edges of the pool and, in principle, the pool itself.

Proofs instead of a standing view

Removing the operator does not remove the need to show things. A landlord wants to know you can pay. An auditor needs to see that payroll matched the books. A counterparty wants evidence that an invoice was settled.

UMBR answers these one at a time. In Prove you build a disclosure for one fact, such as a payment you made or a balance above a threshold, addressed to one reader and with an expiry. The reader checks it at /verify without a wallet. They learn that fact and nothing else. The difference from an operator is direction: instead of someone holding a view of everyone and choosing what to reveal, you hold the facts and choose what to prove.

What this costs

Removing the operator has real costs. If you lose your notes and have no backup, nobody can restore them. Nobody can reverse a mistaken payment. Compliance cannot lean on one party reading everything, so it has to come from screening at the public edges, from issuers' policies, and from proofs that users choose to share. And the legal treatment of permissionless privacy tools is still being worked out in many places.

We think those costs are worth paying for people, small teams and agents, who should not need a vendor's permission to keep their finances to themselves. We also think they should be stated plainly, which is why the threat model lists what the UMBR team can and cannot do, and why this post spends as long on the edges as on the promise.