Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFP: Sapphire Confidential Fungible Token Standard #8

Open
nhynes opened this issue Oct 12, 2022 · 1 comment
Open

RFP: Sapphire Confidential Fungible Token Standard #8

nhynes opened this issue Oct 12, 2022 · 1 comment

Comments

@nhynes
Copy link
Contributor

nhynes commented Oct 12, 2022

RFP: Sapphire Confidential Fungible Token Standard

This is a request for community proposals for the Sapphire ParaTime confidential fungible token (CFT) standard (in ADR-17 format).

Please offer feedback on this RFP and also proposals!

Motivation

A confidential fungible token (CFT) that hides at least one of {sender, recipient,amount} can offer a more complete privacy solution to both dapps and users. A CFT standard will encourage interoperability among dapps, improved tooling for developers, and more convenience for end users.

Example Use-Cases

  • A Web3 gaming company wants to to offer in-game purchases, but doesn't want competitors to identify its most valuable customers.
  • a DAO wants to purchase a physical good but wants to prevent other potential buyers from one upping their offer
  • incentive-compatible (sealed-bid second-price) NFT auctions
  • improved DeFi: MEV-resistent DEX, privacy for users of KYC'd lending protocols

Requirements

  • ERC-20 ABI compatible
  • supports variants hiding any/all of {sender, recipient,amount} from entities who are not the sender or recipient
  • variants able to be generated using a wizard
  • conducive to side-channel resistant implementations
  • minimal runtime overhead for ERC-20 methods when compiler optimizations are enabled

Each variant (if multiple) can be in one ADR but have its own name, if desired (e.g., "ADR-18 Semi-Private").

Desirable Features

These features are highly useful, but may be added in future standards application or platform. If not solved in the proposal, these features must not be precluded by the proposal.

  • receiver can be efficiently notified of an inbound transfer.
  • supports the sender or receiver proving the (non-)existence of transactions to third parties.
  • supports exporting transactions for accounting and tax purposes.
  • there exists way for receivers to block particular addresses, and also for other receivers to efficiently reuse block lists.

Optional Features

These are features that may be of interest to the community, but are not obviously so. These may be addressed by the proposal, but may also be ignored.

  • Additional methods that allow a sender or receiver to choose whether publicize the transaction via EVM logs.
@izkillaz
Copy link

CFT is the game changer in carrying out privacy in NFTs. It will be the standard in NFTs and setting the bar in this line of technology!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants