Search…
Introduction
What you can do with CAPE and how it works
Espresso Systems has developed the Configurable Asset Privacy (CAP) protocol, which enables digital assets to have customized privacy properties.
The first application of CAP is CAPE (Configurable Asset Privacy for Ethereum). CAPE is a smart contract application that asset creators can use to bring new assets with custom privacy into existence and to generate CAPE versions of existing Ethereum assets, endowing ERC-20s and eventually ERC-721s with privacy properties. While CAPE can be run on any EVM blockchain, we will be deploying it soon as a demo on the Ethereum Goerli testnet with ultimate plans to migrate the application to Espresso Systems' infrastructure and enable interaction with Ethereum assets via a token bridge.
Asset creators can create new assets on CAPE that have never existed before and are not tied to any Ethereum token: these are called domestic CAPE assets.
Additionally, asset creators can use CAPE to offer end users versions of existing Ethereum tokens that have custom privacy guarantees. For end users, this function of moving tokens from Ethereum into CAPE is called wrapping: when users wrap Ethereum tokens with CAPE, they lock those tokens and mint them 1:1 within the CAPE system. CAPE assets can then be unwrapped back into Ethereum tokens with no more privacy guarantees.
Every asset within CAPE has a viewing policy associated with it that designates who can see select transaction data. Other types of policies are also possible.
In CAPE, users own asset records which specify the asset type, the amount, and the owner’s address. The system publishes short, hidden representations of these records called commitments. A transaction is composed of:
  • a list of nullifiers which mark the inputs as spent without revealing their content
  • new output record commitments to be published, and
  • a zero-knowledge proof that ensures the nullifiers and the new records are correctly computed, and also that the privacy policies for those records are satisfied.
Rather than submitting CAPE transactions directly to the CAPE Ethereum smart contract, users instead submit transactions to a relayer. The relayer then forwards CAPE transaction data to the CAPE smart contract to be validated. An observer of the system would not be able to see any of the details of the transaction unless they possessed a designated viewing key. Also, since the relayer submits CAPE transactions to the CAPE smart contract and pays the accompanying Ethereum gas fee, the Ethereum transaction fee is not linkable to the original user on the blockchain.
Copy link