Private Stablecoin on Ethereum

Privacy
1

The full paper: Private-StableCoin-On-Ethereum/private-stablecoin-on-ethereum-en.pdf at 636c0e72bbc4e14cdc59d4b88bf9f563847e5c9f · PLabs4/Private-StableCoin-On-Ethereum · GitHub

Ethereum’s programmability makes it possible to issue stablecoins with built-in privacy backed by USDC/USDT. A privacy stablecoin protocol on Ethereum can offer:

  1. Trustless issuance: minting and redemption are enforced by smart contracts rather than by an intermediary.
  2. Permissionless issuance: anyone can mint and redeem under transparent, on-chain rules, with no gatekeeper.
  3. DeFi composability: the asset plugs directly into the existing ecosystem of lending, trading, and other on-chain protocols.
  4. Private or anonymous transactions: transaction data stays confidential or unlinkable to identities.
  5. Native private DeFi applications: developers can build applications on top of the asset with privacy designed in from the start, rather than bolted on afterward.

Taken together, these properties give privacy stablecoins the potential to become, like stablecoins today, a core building block of the on-chain financial system.

They also open up a new design space for on-chain finance:

  1. Confidential trading strategies: participants can execute strategies without exposing them to copycats, front-runners, or adversarial observers.
  2. Selective disclosure: users can prove specific facts about their transactions or holdings (for example, to a counterparty, auditor, or regulator) without revealing everything.
  3. A new model of social trading: building on selective disclosure, traders can verifiably share their performance or positions with chosen audiences, enabling copy trading and reputation systems without full public exposure.
  4. Private prediction markets: participants can express views and take positions without revealing their identities or intentions, among other emerging use cases.

image
image1552×1036 199 KB

3 Likes
2

In the buy protocol (Section 4.4), the transition from uncirculated protocol inventory (pa_P) to a circulating user note (cmx_out) relies on off-chain coordination between the ramp and the operator before the relayer submits the atomic transaction to ReserveVault.

Could you confirm if my understanding of this flow is accurate: the user provides pa_U to the ramp, the ramp generates cmx_out and signs BuyAuth, the operator spends the inventory note using ask_P and pairs the dummy note, and finally the relayer submits the bundle?

Related to this coordination, I have two technical questions:

  1. Since the ramp generates cmx_out (with rho = nf_D) and signs BuyAuth, while the operator holds ask_P to spend the inventory note, can multiple independent ramps interact with a single operator instance concurrently? If so, how does the protocol prevent inventory note contention where two purchase bundles attempt to spend the same uncirculated protocol note in the same block?

  2. If the operator becomes temporarily unavailable to counter-sign the inventory spend after the ramp has already signed BuyAuth and handed the note plaintext to the user, the user’s on-chain credit is delayed until BuyAuth expires. Is there a mechanism for the ramp to pre-custody signed inventory batches, or must every buy transaction require live interactive signing from the operator?