UMBR on mainnet: what changes

Why this matters at all

A public chain is a shared ledger that anyone can audit, and that is its great strength. The cost is that a payment behaves less like a bank transfer and more like a postcard. Whoever learns one of your addresses can read your balance, your income, and the people you pay, going back to the first transaction.

That is tolerable when the money is speculative. It stops being tolerable when the money is a salary, an invoice, a supplier payment or a treasury. It becomes a real problem for software agents that pay for data and tools many times a minute, because every payment leaks a little of their owner's strategy.

The fix is not to give up public settlement. It is to stop publishing amounts, balances and counterparties by default, and to let people prove the specific facts someone is entitled to see.

How UMBR works, briefly

On each chain UMBR has one shielded pool, a contract that holds everyone's private balances together. When you shield funds, the pool records a commitment that only you can open. To spend, your device produces a zero-knowledge proof that you own an unspent note in the pool, without revealing which note or how much it holds. The contract checks the proof and moves value accordingly.

Inside the pool, payments, payment links and payroll runs all work the same way. When someone needs to see a detail, you produce a disclosure proof for that reader alone and they check it at /verify. Private by default, provable on demand.

What has to happen first

We will not configure a mainnet pool until each of these is done and published:

• A public setup ceremony for the proving keys, replacing the development keys the testnets use, with a transcript anyone can check.
• An independent security review of the contracts and circuits, with its findings and fixes published. It has not taken place yet, and we will not describe UMBR as reviewed until it has.
• Clear limits and controls. We expect to start with deposit caps, and we will publish exactly what the deployer can and cannot change, including that there is no function to take pooled funds.
• Screening at the edges. Deposits and withdrawals touch public addresses, and token issuers' own policies keep applying there.

What changes, and what does not

The most important row is the one that does not change. UMBR is self-custodial on testnet and will be on mainnet. Your notes and the secrets that open them stay on your device. There is no operator account with a view of everyone's balances, and that includes the UMBR team.

What to expect on day one

Mainnet will start small on purpose. Expect a short list of stablecoins per chain, caps on deposits while the pool is young, and an optional relayer you can bypass. Expect the privacy of a new pool to be weaker than it will be later, because privacy in a shielded pool comes from the crowd, and a new crowd is thin. We will say all of this again, with numbers, in the post that announces the actual launch.

What you can do now

Everything described above already works with test funds. Open the app, pick a testnet, and shield, send, pay with a link or run a small payroll. If you build, the SDK page shows how @umbr/sdk will look; the package is not published yet. The mainnet page is where configured pools will appear first.