[Open Question] Privacy vs. composability — confidential amounts with on-transfer rule evaluation

[oa-sarvesh]

Context

Confidential amounts conflict with transfer hooks/aggregations on some rails: on Solana, confidential transfers and transfer hooks are mutually exclusive because a hook that reads the amount is incompatible with an encrypted amount (Whitepaper §4.3). Regulated deployments will require both confidentiality and rule enforcement (§6.5).

The question

What is the recommended pattern when both confidentiality and on-transfer rule evaluation are required?

How to contribute

• Survey approaches: ZK-proofs of rule compliance over encrypted amounts, selective disclosure to designated verifiers/auditors, threshold decryption, off-chain pre-trade checks with on-chain proofs.
• Assess each against the three execution models the standard must abstract over (account/balance, object, UTXO).
• Propose which pattern(s) the standard should recommend vs. merely permit.

Reference: Whitepaper §4.3, §5.1 (principles 5–6), §6.5.

[vishnugovind10]

https://github.com/vishnugovind10/otas-probe

[MukulKolpe]

This is really great work @vishnugovind10, thank you for building it and for sharing it in this thread in particular; it turns out to be a wonderfully concrete lens on exactly the privacy/composability question we've been circling.

I spent some time with it and really enjoyed digging in. The part that stood out most here is the distinction it draws between OBSERVED and undetermined. Against an ERC-3643 example, it confirms the base type and Restricted as OBSERVED, but leaves a long list undetermined (ForceTransferable, Freezable, Mintable, Burnable, and so on), not because the token lacks them, but because they simply aren't resolvable from observable chain state. That gap is precisely what this thread is about, and it's lovely to see it made measurable rather than just argued about.

The insight I took from it: privacy features don't just hide data from users or regulators; they collapse the observable conformance surface. A confidential-amount token can't have its behaviors verified from the outside, so anything composing against it, a settlement coordinator, a compliance check, another protocol, has to fall back from "verify" to "trust an assertion." So maybe the sharpest way to frame the tension is that the composability cost of privacy is that observation-based interop gives way to attestation-based interop. Basically, where you can't observe, you have to attest.

A couple of questions it sparked for me:

• Should the capability manifest carry observability/confidence as a first-class field, so a consumer knows whether a behavior is OBSERVED versus merely ASSERTED, rather than treating "present" and "claimed" as the same thing? otas-probe already makes that distinction, which feels like a genuinely useful signal the standard itself could adopt.
• The incompatible-extension-combination case (e.g., confidential transfer + transfer hook) is a really nice concrete finding. Should the model explicitly document which behavior combinations are mutually exclusive per environment? That feels like a bounded and genuinely valuable thing to pin down.

Thanks again for this; it's a great contribution to the discussion.

[vishnugovind10]

Thanks @MukulKolpe. This is a much sharper way of looking at the privacy/composability tradeoff than how I’d been thinking about it.

The observation to attestation distinction really clicked for me!

One thing I was trying to capture with 'otas-probe' was that UNDETERMINED doesn't mean a capability is absent : it means we simply can't establish it from the observable chain state. Looking at the results through that lens, it feels like there’s an important difference between what a token can do, what we can prove it can do, and what someone is telling us it can do.

That seems particularly important for anything consuming an OTAS manifest. If a settlement system or another protocol is making a decision based on a capability, it probably shouldn't treat an observed capability and an issuer assertion as equivalent. The evidence behind the capability is part of the interoperability story.

I also like the idea of making observability/confidence explicit in the manifest. It would give the consumer a much clearer picture of what is actually known versus what still requires trust or an external attestation. In that sense, the manifest could describe not just the capability itself, but the evidence available for that capability which in turn builds trust.

The incompatible-extension point is interesting for a similar reason. The probe started surfacing cases where looking at capabilities individually isn't enough : two things can each be valid on their own but become problematic when combined in a particular environment. So there seems to be another layer between "what capabilities does this asset have?" and "can I safely compose with it?" That's where the compatibility/composition question comes in.

I hadn't initially thought of the probe as exposing quite this much of the distinction between observation, assertion, and composition, so your framing is really useful.

Happy to share the findings and examples that otas-probe currently surfaces if they're useful for the OTAS work.

[MukulKolpe]

This is a really productive thread, thank you @vishnugovind10. That three-way layering is a clean way to put it: what a token can do, what we can prove it can do, and what someone tells us it can do are three different things, and collapsing them is the trap a consumer of a manifest can fall into.

Building on the observation-to-attestation framing, the key line is that the evidence behind a capability is part of the interoperability story, and it generalizes beyond privacy. A settlement coordinator referencing an AtomicLeg, a compliance check reading Restricted, another protocol composing against a behavior, none should treat an OBSERVED capability and an ASSERTED one as equivalent. So an evidence/confidence tier on the manifest is load-bearing, not a nice-to-have.

Composition as its own layer is a good point to draw out: there's a real gap between "what capabilities does this asset have?" and "can I safely compose with it?", and the incompatible-extension cases show the second isn't reducible to the first.

And yes, please, we'd genuinely value seeing the additional findings and examples otas-probe surfaces. The incompatible-combination cases especially would be useful, both as input to the privacy/composability question here and, I think, as motivation for a couple of concrete additions to the next whitepaper revision: an observability/confidence field on the manifest, and some treatment of capability composition.

Thanks again, genuinely useful exchange.