I posted a UCP link in August and said nothing. Here's what I was thinking

On August 19 I posted a link to Google’s Universal Commerce Protocol in the ZShieldHer thread and then said nothing else about it.
I’ve been sitting with it since.
This post is not about ZShieldHer. That project continues as it is - the education site, the modules, the Advocates page.
What follows is something seperate that came out of the same conversation, and I think it might be bigger.

Going back through that thread

@hanh asked the hard question: how do you spend privately when your accounts are watched?
I answered by trying to skip the off-ramp entirely - put the instruction in the memo, let someone else make the purchase.
@dismad then removed the human from it. Why a DAO, he asked, when an agent could just receive and send per the memo instructions.
@gorusys said he’d take the agent question to a friend who works on them.
And then I found UCP, posted the link, and stopped because I’d realised the thread had walked into something much more general than the problem we started with.

The general thing

A shielded memo is the only payment channel where the instruction, the authorisation, and the money are a single atomic encrypted object.
Everything else splits them apart. You pay over here, you instruct over there, and the seam between the two is where all the metadata lives.
I keep coming back to how strange it is that this property exists and almost nobody is using it for anything.

What UCP made me see

UCP, AP2 and x402 all launched inside the last year. The direction is obvious within a couple of years a real share of business spending will be executed by agents. Procurement. Ad buying. Inference routing. Logistics.
All of them settle on transparent rails.
Here is the part I haven’t seen anyone say out loud:
Transparent-chain agentic commerce publishes a company’s operations in real time, at machine resolution, to it’s competitors.
Not in theory. An agent’s settlement history is the vendor list. The burn rate. The seasonal demand curve. The unit volumes. The model-provider mix.

Right now it’s noise, because the volumes are tiny. At scale it’s a competitive intelligence feed that companies will be paying to broadcast about themselves.
And every available answer is bad. Mixers are regulatory poison - no finance team goes near them. Privace add-ons on an L2 break the atomicity: you shield the payment, but the order still travels over a separate authenticated channel, so you’ve only relocated the metadata. And “Just use a payament processor” puts back the intermediary the whole thing was meant to remove.

The idea: Obvelo

The name is Latin - obvēlō, “I veil over”, First person, deliberately.
The sender does the veiling. in the same act that sends the money. That’s the whole design in one word.
One shielded transaction carries the purchase order, the terms, the payment and the
receipt. The counterparty agent decrypts it, fulfils it, and settles back with a signed
receipt in the reply memo.

No account. No session. No API key. No order sitting in anyone’s database.

Four message types, that’s the whole protocol:

OFFER → ORDER (carries the payment) → RECEIPT (reply memo) → DISPUTE

An order is a payment. The state machine is the transaction graph.

512 bytes obviously won’t hold a purchase order. So the memo carries an envelope —
version, counterparty, content hash, symmetric key — and the order blob lives in any
untrusted store. The blob is useless without the key, and the key only ever exists inside
a shielded transaction.

Which means the storage can be fully compromised and it leaks nothing.

It isn’t a UCP competitor. It’s UCP’s confidential settlement option. Agents negotiate
over UCP exactly as they do now, and settle over Obvelo.

The part I think actually matters

Viewing keys.

You get both halves at the same time:

Opaque to competitors, to chain analysts, to the public.

And fully transparent to your auditor, your regulator, your board — a viewing key scoped
to one agent, one counterparty, one date range. Cryptographically verifiable.

No mixer can offer that. No transparent chain can offer the first half.

The pitch to a finance department isn’t “privacy.” It’s: your agents stop leaking, and
your audit gets better.

Why this only works on Zcash

I want to be careful here, because “only Zcash can do this” gets said a lot and usually
isn’t true. In this case I think it is:

  • The encrypted memo is atomic with the value transfer. The order can’t be separated from
    the payment, replayed, or reordered.
  • Amounts are shielded. A confidential purchase order is worthless if the price is public.
  • Viewing keys are native. Selective disclosure isn’t a gadget bolted on afterwards.
  • The shielded pool is mature and in production, not a promise.

That’s not a preference list. That’s the minimum feature set, and Zcash is the only chain
that has all four today.

What I think kills it

I’d rather list these myself.

Volatility and liquidity. Nobody settles business invoices in an asset that moves 8%
overnight, and ZEC order books aren’t deep enough for serious volume. This is the number
one blocker, ahead of anything technical. Converting instantly at both edges puts back a
doxxing point you then have to design around. I don’t have a clean answer.

Timing and volume. Shielded amounts don’t hide when, or how often. Cadence and
scale are still inferable by anyone who knows an agent’s address. Batching and cover
traffic would need to be in the design from day one, not bolted on at v3.

Keys for autonomous agents. An agent holding spend authority with no human in the loop
is an unsolved problem industry-wide. Caps, time-locked authority, revocable delegation —
but it needs real work.

Two-sided adoption. A confidential payment protocol with one participant is just a
wallet.

Where I’d start

v0 is a wire spec and a reference SDK. Two agents on one laptop, a working ORDER/RECEIPT
round trip, and a viewing-key audit export. Small and concrete. Either it’s compelling in
that form or it isn’t.

v1 would be one vertical where both sides already want confidentiality. My instinct is AI
inference procurement — an agent buying tokens across model providers. The routing mix and
the volumes are commercially sensitive, the spend is high-frequency, and the counterparties
are already crypto-literate.

This is an idea, not a product

Same as last time. I’m posting it here because this is where these things should start.

What I’d like to know:

  • Is anyone already building confidential settlement for agent commerce? I looked and
    found nothing, which usually means I looked badly.
  • Is volatility fatal at v1, or is a narrow ZEC-denominated vertical enough to prove the
    primitive works?
  • Are there memo-size or memo-bundle changes in flight that would change the envelope
    design?

@hanh @dismad @pitmutt @gorusys @jenkin — this came straight out of your replies in the
other thread, so I’d value your read especially.

And the credit belongs where it belongs: @dismad’s “why not an agent instead of a DAO”
is the hinge the entire thing turns on. I just followed it somewhere he probably wasn’t
aiming.

2 Likes
  • Is anyone already building confidential settlement for agent commerce? I looked and
    found nothing, which usually means I looked badly.

I can’t prove it, but I think many are because this is a highly competitive idea

  • Is volatility fatal at v1, or is a narrow ZEC-denominated vertical enough to prove the
    primitive works?

I think it would depending on the use case. Some things that come to mind are micro txids, perhaps for spam prevention, or anything that has the potential to be triggered a lot, like some kind of action in a game that costs ZEC but the exact amount is less important than the txid confirming your intent is real. In this type of enviroment the amount could actually be random within some given interval.

  • Are there memo-size or memo-bundle changes in flight that would change the envelope
    design?

Thankyou, all three of these are useful.
ZIP231 changes the design.
One question, how does memo pruning interact with auditability?
Regarding on the volatility, your reframe is better than my question, and I think it removes two blockers rather than one. If the amount is a bond proving intent rather than a price, volatility stops mattering, liquidity stops mattering, and this is the part you didn’t say the legal exposure drops too.

@dismad, the agent idea was yours in the last thread and the bond idea is yours in this one. The good half of this design keeps coming from you.