chore(approach|use-case): update private payments with learnings from poc implementation by rymnc · Pull Request #105 · ethereum/iptf-map

rymnc · 2026-03-09T11:18:42Z

What are you adding?

Vendor/Protocol
Enterprise Use Case
Update to existing content
Other

Description

Phase 5 of the playbook, limited learnings, but the big one is operator liveness for plasma approaches

Checklist

I've checked this doesn't duplicate existing content
All links work
Info is accurate

… poc implementation

Meyanis95 · 2026-03-09T11:43:33Z

use-cases/private-payments.md

-See [private-stablecoins.md](private-stablecoins.md) for stablecoin-based privacy patterns. Additional considerations:
+See [Approach: Private Payments](../approaches/approach-private-payments.md) for detailed solution architecture covering L1 shielded pools, Plasma/Intmax2 stateless rollups, privacy L2s, TEE, and MPC approaches with quantitative comparison from PoC validation.
+
+**PoC Implementation:** [Private Payment PoC](https://github.com/ethereum/iptf-pocs/tree/master/pocs/private-payment). Two approaches validated: L1 Shielded Pool and Plasma/Intmax2.


We can remove mention of PoC here and just redirect to the approach page, then the reader can check recommended solutions there.

addressed in bca42a0

Meyanis95 · 2026-03-09T11:47:10Z

use-cases/private-payments.md

 ## 6) Open Questions

- Where is the line between payment privacy and AML/CFT obligations?
+- Where is the line between payment privacy and AML/CFT obligations? PoC approach: attestation-gated entry (ZK proof of KYC) demonstrates privacy-preserving compliance gating.


Not sure if we should answer the question here. Maybe it just needs a rephrase.

addressed in bca42a0

Meyanis95 · 2026-03-09T11:49:17Z

approaches/approach-private-payments.md

+
+2. **Liquidity Fragmentation:** Multi-token transfers require same-token constraints in circuits, confirming per-token shielded pools. Remaining: cross-pool atomic swaps and multi-asset circuit designs.
+
+3. **Operational Recovery:** Dual-key architecture (spending + viewing) provides viewing-key-based balance inspection for recovery scenarios. Remaining: full business continuity workflows and key rotation under shielding.


Not sure to understand. Is Operational Recovery about audit?

addressed in bca42a0

approaches/approach-private-payments.md

Meyanis95 · 2026-03-09T11:50:07Z

approaches/approach-private-payments.md

+6. **Verification Gas Viability:** At ~2.6M gas per on-chain verification for shielded pools, what payment volume threshold makes L2 amortization necessary?

-5. **Operational Recovery:** Key recovery and business continuity for institutional payment operations?
+7. **Network Timing Correlation:** Some approaches leak timing metadata. What is the acceptable latency overhead for [network anonymity](../patterns/pattern-network-anonymity.md) mitigations?


Isn't this mitigated by size of AS?

not really, if someone joins the AS, and immediately a similar amount of tokens flows out, its possible to correlate

Yeah, you'd need to round up notes. Fine to keep it as it is.

Meyanis95 · 2026-03-09T11:51:19Z

approaches/approach-private-payments.md

+| **Proof gen (operator)** | N/A | 42-49s |
+| **Operator required** | No | Yes |
+
+#### Cross-Cutting Findings


We should mention the issue with withdrawals, the fact that you need a fresh address with no gas, and therefore a relayer to pay for your gas. Add a CR level to the full shielding picture.

addressed in bca42a0

oskarth · 2026-03-10T02:39:02Z

approaches/approach-private-payments.md

+
+| Dimension | Shielded Pool (L1) | Plasma/Intmax2 (L2) |
+|---|---|---|
+| **Proving system** | UltraHonk | Plonky2 |


Can we add a link to Ultrahonk and Plonky2 in ref or as links to more details somewhere

addressed in a1c0a38

oskarth

A few more questions:

Plasma "Gas: withdraw" says "Via withdrawal server" — do we know the actual on-chain gas when the withdrawal lands on L1? Even if the server pays, the cost exists somewhere
"MAX_ATTESTATION_TREE_DEPTH=20, supporting ~1M participants" — worth noting this is configurable? Otherwise readers might read it as a fundamental ceiling
The old L1 section had "battle-tested infrastructure" which got removed — worth keeping that qualifier somewhere? The comparison table covers gas but not the maturity signal

rymnc · 2026-03-10T06:21:46Z

A few more questions:

* Plasma "Gas: withdraw" says "Via withdrawal server" — do we know the actual on-chain gas when the withdrawal lands on L1? Even if the server pays, the cost exists somewhere

* "MAX_ATTESTATION_TREE_DEPTH=20, supporting ~1M participants" — worth noting this is configurable? Otherwise readers might read it as a fundamental ceiling

* The old L1 section had "battle-tested infrastructure" which got removed — worth keeping that qualifier somewhere? The comparison table covers gas but not the maturity signal

addressed in a1c0a38

battle-tested infrastructure sounds way too superlative, removed it.

Meyanis95 · 2026-03-10T09:56:47Z

approaches/approach-private-payments.md

+- **Dual-key architecture** (spending + viewing) works in both models, confirming selective disclosure is practical without granting transfer authority
+- **Attestation-gated entry** via ZK proof of Merkle tree inclusion is feasible (MAX_ATTESTATION_TREE_DEPTH=20, supporting ~1M participants, configurable for larger participtants, but increases proving time)
+- **Network timing correlation** is unmitigated in both approaches; see [Network-Level Anonymity](../patterns/pattern-network-anonymity.md) for mitigation patterns
+- **Withdrawal to fresh addresses** requires a gas relayer since the recipient address has no ETH for gas; this adds a counterparty-risk dependency to the shielding model


I don't think it's a counterparty risk here; i.e., you can always deanonymize yourself and withdraw funds by sending direct tx to the contract.
It's a more the privacy feature of feeding a fresh address with gas through the relayer that could be censored, the relayer could refuse to transmit your tx.

addressed in d316eaa

Meyanis95 · 2026-03-10T09:57:52Z

approaches/approach-private-payments.md


+**Operator Complexity:**
+
+- **Shielded Pool:** No operator needed; users interact directly with L1 contracts


Is the realyer considered an operator? Is the person in charge of upgrading the contracts considered as an operator?

not exactly, it can be a third party vendor here too

addressed in d316eaa

Yes, but my question is, does having the power to upgrade contracts, even though detained by a third party, make this third party an operator of the system?

Also, this might be tracked in another issue; i.e., pattern shielded pool from CROPS pov, where we address this in CR section. cf. #104.

upgradeable contracts are a building block used across many patterns, with varying upgrading authorities (multisigs, single entities, etc.). rather than defining the trust level of upgradeable contracts in isolation, it's better handled at the vendor card level, since those reflect real-world deployments.

Agree!
But this setting should also live at the pattern level, specifying a different architecture path to avoid assumptions that are linked to a pattern name.

Meyanis95

Overall look good, modulu latest comments.

chore(approach|use-case): update private payments with learnings from…

4a1c6b1

… poc implementation

rymnc requested review from Meyanis95 and oskarth March 9, 2026 11:18

rymnc self-assigned this Mar 9, 2026

rymnc linked an issue Mar 9, 2026 that may be closed by this pull request

feat: Private payments approaches learnings #96

Closed

Meyanis95 reviewed Mar 9, 2026

View reviewed changes

approaches/approach-private-payments.md Show resolved Hide resolved

Meyanis95 reviewed Mar 9, 2026

View reviewed changes

chore: address comments

bca42a0

rymnc force-pushed the chore/update-private-payments branch from 1ee96b9 to bca42a0 Compare March 9, 2026 19:34

oskarth reviewed Mar 10, 2026

View reviewed changes

chore: address reviews

a1c0a38

rymnc requested review from Meyanis95 and oskarth March 10, 2026 06:22

Meyanis95 reviewed Mar 10, 2026

View reviewed changes

Meyanis95 approved these changes Mar 10, 2026

View reviewed changes

chore: address comments

d316eaa

oskarth approved these changes Mar 11, 2026

View reviewed changes

rymnc merged commit ab2de87 into master Mar 11, 2026
6 checks passed

rymnc deleted the chore/update-private-payments branch March 11, 2026 08:41


		2. Liquidity Fragmentation: Multi-token transfers require same-token constraints in circuits, confirming per-token shielded pools. Remaining: cross-pool atomic swaps and multi-asset circuit designs.

		3. Operational Recovery: Dual-key architecture (spending + viewing) provides viewing-key-based balance inspection for recovery scenarios. Remaining: full business continuity workflows and key rotation under shielding.


		Operator Complexity:

		- Shielded Pool: No operator needed; users interact directly with L1 contracts

Conversation

rymnc commented Mar 9, 2026

What are you adding?

Description

Checklist

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

oskarth Mar 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

oskarth left a comment

Choose a reason for hiding this comment

Uh oh!

rymnc commented Mar 10, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rymnc Mar 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Meyanis95 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

oskarth Mar 10, 2026 •

edited

Loading

rymnc Mar 10, 2026 •

edited

Loading