feat(approach): enshrined private transfers

[RogerPodacter]

What are you adding?

• Vendor/Protocol
• Enterprise Use Case
• Update to existing content
• Other

Description

New approach doc: enshrined private transfers. Describes an intent-transaction standard for wallet-authorized private transfers, a Privacy RPC server-side proving bridge, and an L1 system contract upgradeable only by hard fork. Includes optional compliance layers (proof of innocence, issuer viewing keys). Based on this article, with a live demo and draft spec.

Checklist

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

[Meyanis95]

Thanks for this. The spec and live demo links are a great find.

A couple of things before we can merge:

• What you've described (native shielded UTXO pool, intent-transaction standard) is really a pattern; in the current taxonomy, it's a building block, not a full approach to a ./use-case. We have patterns/pattern-shielding.md as a stub; this content would fit well there.
• Also, shielding is already on the strawmap.org roadmap, and the standardisation is happening at the protocol layer, not the app layer. Worth reflecting on in the framing.

I suggest reverting the approach and adding the native shielding to the current ./patterns/pattern-shielding.md, or creating a new pattern for native shielding.

[RogerPodacter]

Thanks for the review, @Meyanis95! A few thoughts:

I think this is an approach, not a pattern. Per the repo's taxonomy (approaches/README.md): "Patterns are reusable building blocks; approaches explain how to combine them for specific scenarios with detailed recommendations and trade-off analysis."

This doc combines four building blocks — an intent-transaction wallet authorization standard, a Privacy RPC server-side proving bridge, a system-contract enshrinement model, and a compliance layer (proof of innocence + issuer viewing keys) — into a phased strategy for achieving native private transfers on the L1.

pattern-shielding.md covers shielded ERC-20 transfers as a general technique (deposit, notes, ZK proofs, withdraw). This doc is specifically about how to enshrine that capability at the protocol level, which patterns to compose, and how to bridge adoption before wallet integration exists.

On the roadmap point — this is a proposal for protocol-layer standardization, not app-layer. The roadmap says "Private L1 / shielded transfers" but doesn't specify how. This is an approach to implementing that roadmap item.

Thanks!

[RogerPodacter]

Checking in here, @Meyanis95! Would love to get this merged! Thanks!

[Meyanis95]

Thanks for the thoughtful reply, @RogerPodacter!

I agree the content is valuable! The intent-transaction standard, Privacy RPC bridge, and enshrinement model are all worth documenting. The question is about where it fits in the taxonomy.

"Enshrined private transfers" isn't targeting a specific use case; it's an infrastructure strategy. Our existing approaches target specific institutional scenarios (private payments, private trade settlement) and explain how to combine patterns to solve them. This doc is holistic: it proposes a protocol-level deployment path that would serve all of those use cases, but doesn't target any one specifically.

That's not a problem with the content; it just means the taxonomy fit is off. As an approach, it would sit alongside docs that answer "how do I do X privately today?" with a doc that answers "how should Ethereum enshrine privacy at L1?" — which risks confusing readers into thinking this is something already achievable, rather than a proposal.

What I'd suggest instead:

1. Extract the building blocks as patterns. The intent-transaction standard, the Privacy RPC bridge concept, and the system-contract enshrinement model are each reusable primitives. Documenting them as patterns makes them composable; they could appear in future approaches beyond just payments.
2. Enrich existing approaches. The enshrinement path and compliance layer (proof of innocence, issuer viewing keys) would strengthen approach-private-payments.md and approach-private-trade-settlement.md as a forward-looking option within each.

This way, the substance gets in, readers discover it in the right context, and the building blocks are available for other combinations down the line. Happy to help with the restructuring if useful.

[RogerPodacter]

Agreed, @Meyanis95!

I've reworked this PR. The approach doc is gone; this now adds two standalone patterns extracted from EIP-8182:

• Permissionless Spend Auth — outer/inner circuit split that lets users choose their own auth method without fragmenting the anonymity set
• Safe Proof Delegation — intent-based delegation so a prover can generate proofs without fund custody (prover sees plaintext but can't forge, redirect, or overspend)

Both are reusable building blocks that stand on their own independent of the enshrinement argument. They can plug into existing approaches (private payments, private trade settlement) later.

Would love your feedback, thanks!

[Meyanis95]

How would you define the owner field of a note? Where it's usually a public key.

[Meyanis95]

Thanks @RogerPodacter!
Overall looks good.
Since your initial commit, we have changed the template for the pattern card, especially the frontmatter, which now includes a short CROPS analysis of the pattern.
It'd be a great addition to your current patterns.

[RogerPodacter]

Thanks, @Meyanis95! I added the front matter and updated patterns/pattern-permissionless-spend-auth.md to respond to your question.

To also respond directly here:

Notes commit to a hash of an ownership secret (nullifierKeyHash), not a public key. The ownership secret is independent of any auth credential. To spend a note, you prove knowledge of that secret (checked by the outer circuit) AND valid authorization (checked by the inner circuit). See the updated "Layer 1: Ownership / auth split" section for the full rationale.

Thanks!

[Meyanis95]

What prevents the prover from censoring your request? From reading the pattern, this would be low.

[RogerPodacter]

Agreed! I updated the score to low.

[Meyanis95]

Do you need a realyer to send tx on-chain? If yes, this might need to be mitigated.

[RogerPodacter]

I'd push back a little here because the pattern itself doesn’t require a relayer: registry updates are permissionless and on-chain.

Someone building a privacy protocol might combine this pattern with other patterns that do require relayers (for example my own proof delegation pattern), but this should be reflected in the CR score of those other patterns, not the score for the auth layer.

Thoughts?

[Meyanis95]

It's all good, we can keep it this way.
For reference, we have this section for architectural tradeoffs

iptf-map/patterns/pattern-shielding.md

Line 58 in d68037e

- **CROPS context (both)**: CR reaches `high` on L1 shielded pools (Railgun) where users can deposit/withdraw permissionlessly. Drops to `low` on permissioned L2s with operator-controlled exit. Relies on relayer and paymaster for transaction submission, both of which can censor. In I2U, the exit path guarantee is critical — without forced withdrawal, CR is effectively `low`.

[Meyanis95]

Overall LGTM!
I'll let you fix the CI/CD checks, as well as revise the CR fields in crops_profile.
Thank you for your contribution @RogerPodacter

[RogerPodacter]

Thanks, @Meyanis95! I pushed a commit that I believe fixes all issues except one, where I replied with my pushback. Let me know if this makes sense!