Thu, September 08, 2022

Configurable Asset Privacy Case Studies: Payments

By
Espresso Systems

Espresso Systems | 6 min read

When designing the Configurable Asset Privacy (CAP) protocol and its implementation on Ethereum (CAPE), we had a few use cases in mind, like providing a mix of privacy and risk management for payments. We prioritized features, including viewing and freezing policies, that would be pertinent to those use cases. We also knew, however, that applications of the protocol would emerge amongst users that we hadn’t dreamt up ahead of time. And we’ve already seen this with DAOs and NFT creators and beyond!

As we start designing what future versions of configurable privacy will look like -- and as we make more possibilities efficient and practical with breakthroughs like VERI-ZEXE -- we want to start sharing some case studies for how you as developers, companies, asset creators, and end users might be thinking about what CAPE can offer. We will be posting a series of case studies covering how control over the visibility of on-chain data will prove powerful in unlocking long-promised use cases like payments, and will revolutionize how we approach everything from decentralized exchange and lending, governance and on-chain organization, and Web3 media.

Follow our Twitter or join our Discord to follow along with this series. We will post about applications in DeFi: like how configurable privacy might be implemented in lending protocols to prevent adversarial liquidation hunters from targeting big positions. We’ll talk about the demand we have seen from DAOs to be able to pay their contributors with greater privacy guarantees for the individuals and explore how configurable privacy might have prevented ConstitutionDAO from being outbid! We will get into what the future of Web3 social media might look like and how users might be able to show different views of their on-chain activity (like their NFT collections) to different subsets of their followers -- like a “close friends only” option!

In this series, we will also cover timely topics like how blocklists might be used to build permissioned privacy products that can serve as alternatives for those who are uncomfortable with the risks of products like Tornado Cash.

We are excited to dig into these topics and to hear from you to learn what you are interested in.

To warm up with some of the most straightforward (and, we think, most compelling) use cases for configurable privacy, let’s start with the topic of payments! All of the following case studies are based on functionality that is possible within CAPE as it is designed today.

Payments case study 1: private ERC-20 stablecoin for payments with risk monitoring for the provider

An issuer of an ERC-20 stablecoin on Ethereum wants to provide privacy for users from the general public in order to encourage use for merchant payments, payroll, and beyond. The stablecoin provider creates a wrapper on CAPE for a privacy-preserving version of their ERC-20 token. The stablecoin provider retains viewing capabilities and, in partnership with an on-chain risk analysis firm, can monitor the risk profiles of the wallets using this asset. The stablecoin provider also retains freezing capabilities, as is customary for most centralized stablecoin issuers. Users can easily wrap and unwrap the ERC-20 stablecoin into CAPE using their Ethereum wallets and the CAPE application.

  • Policies: viewing policy (the stablecoin provider can view sender, receiver, and amounts for all transactions of this asset type; the provider may share this data with a chain analysis company); freezing policy (the stablecoin provider can freeze units of this wrapped asset)

  • Players: stablecoin provider; chain analysis company

  • Privacy: The public will be able to see transactions that are wrapping into and unwrapping from CAPE since those will be public on Ethereum. Within CAPE, the public will only be able to see that a valid CAPE transaction occurred (no details). The stablecoin provider will be able to see full transactional details.

Payments case study 2: private stablecoin with KYC credentials

Working with a credential issuer, a stablecoin provider defines and mints a new stablecoin directly within the CAPE environment. In addition to viewing and freezing policies, this new asset programmatically requires all holders or recipients to have a KYC credential. The viewing policy for the asset enables the stablecoin provider to see transaction details and enables the stablecoin provider to see the credentials of each sender / recipient. Meanwhile, transactions do not reveal any information to other users.

  • Policies: credential policy (all transactions must include signed credential information); viewing policy (stablecoin provider can view sender, receiver, and amounts for all transactions of this asset type); freezing policy (the stablecoin provider can freeze units of this asset)

  • Players: stablecoin provider; credential issuer(s)

  • Privacy: The public will only be able to see that a valid CAPE transaction occurred. The stablecoin provider can see transactional details and credentials.

Payments case study 3: private ERC-20 stablecoin with ban list policy.

A stablecoin provider creates a CAPE wrapper for their ERC-20 stablecoin with a ban list policy. This policy does not enable the stablecoin provider to see all transaction details, but programmatically ensures that banned Ethereum address cannot wrap their ERC-20s into CAPE or receive stablecoins unwrapped from CAPE’s system. The stablecoin provider dynamically maintains the ban list themselves based on inputs such as the OFAC SDN list and any other business risk mitigation considerations, such as affiliated addresses identified by chain monitoring providers through their APIs.

  • Policies: ban list policy (addresses on a ban list cannot wrap into CAPE or be recipients from unwrapping actions from the CAPE smart contract)

  • Players: stablecoin provider; chain analysis company

  • Privacy: The public will be able to see transactions that are wrapping into and unwrapping from CAPE since those will be public on Ethereum. Once within CAPE, no users will be able to see that a valid CAPE transaction occurred.

Payments case study 4: private ERC-20 stablecoin with programmatic “Travel Rule”

To streamline and automate working within “Travel Rule” guidance while maximizing user privacy, a stablecoin provider introduces a custom CAPE wrapper for users of their stablecoin on Ethereum. This wrapper has a policy that allows transactions over a threshold amount of (e.g.) 3,000 USD to be viewable by a third party aggregator that routes the appropriate information to exchanges and other regulated Virtual Asset Service Providers (but no one else). Transactions below that threshold are private to all (including the third party and the VASPs). The policy also designates that transactions over that threshold can only happen among wallet addresses that contain KYC credentials.

  • Policies: credential policy (all transactions must include signed credential information); viewing policy (stablecoin provider can view sender, receiver, and amounts for all transactions of this asset type); freezing policy (the stablecoin provider can freeze units of this asset)

  • Players: stablecoin provider; credential issuer(s); Travel Rule data aggregator; exchanges / VASPs

  • Privacy: The public will be able to see transactions that are wrapping into and unwrapping from CAPE since those will be public on Ethereum. Within CAPE, the public will only be able to see that a valid CAPE transaction occurred (no details). The third party aggregator and VASPs will be able to see full transactional details and credentials, but only for transactions over the threshold amount.


Articles you may be interested in

Sign up to get invited to our product releases