Create a confidential variant of ERC-3643 security token standard using Zama's fhEVM

[zaccherinij]

Overview

The goal of this bounty is to explore and implement how the specific capabilities of Zama's fhEVM can enhance and improve the functionality of the ERC-3643 security token standard for security tokens. Participants will leverage the encrypted types and FHE operations supported by the fhEVM to create a confidential variant of this security token standard.

What we expect

First, the bounty participants should get familiar with the ERC-3643 standard as well as its current official implementation. Notice that this standard also relies on a decentralized identity standard such as ERC 735 via the OnchainID implementation, which could also be adapted to the fhEVM by adding confidentiality.

Judging criteria

• Smart Contract: The smart contracts need to be written in Solidity running on the fhEVM. The code should be cleanly commented, with adherence (as close as possible) to the standard is important.
• Testing: Testing smart contracts using hardhat is also highly recommended.
• Deployment: The smart contract should be compatible with Zama's fhEVM devnet.
• Use of fhEVM: The contract should employ hidden information, showcasing the capabilities of the fhEVM. Care should be taken by the bounty hunter to decide which state variables to encrypt and which should stay unencrypted. Suggestions (non-exhaustive) of state variables to encrypt: transfer amounts, allowances, number of frozen tokens, identities such as country codes, etc.
• Bonus points: Implement an additional contract to showcase a concrete scenario for security settlements, leveraging the confidential security token. For instance, DVP (Delivery Vs Payment) or DVD (Delivery Vs Delivery), and so on. (Here are some examples from an old hackathon on DVP using a different security token standard for inspiration)

Reward

🥇Best submission: up to €5,000.

To be considered best submission, a solution must be efficient, effective and demonstrate a deep understanding of the core problem. Alongside the technical correctness, it should also be submitted with a clean code, clear explanations and a complete documentation.

🥈Second-best submission: up to €3,000.

For a solution to be considered the second best submission, it should be both efficient and effective. The code should be neat and readable, while its documentation might not be as exhaustive as the best submission, it should cover the key aspects of the solution.

🥉Third-best submission: up to €2,000.

The third best submission is one that presents a solution that effectively tackles the challenge at hand, even if it may have certain areas of improvement in terms of efficiency or depth of understanding. Documentation should be present, covering the essential components of the solution.

Reward amounts are decided based on code quality, model accuracy scores and speed performance on a m6i.metal AWS server. When multiple solutions of comparable scope are submitted they are compared based on the accuracy metrics and computation times.

Related links and references

• Confidential variant of ERC 20 for fhEVM specific sources.
• Compliant ERC20 with confidential decentralized identities and its corresponding blog post.
• Zama's fhEVM documentation

👉 Register

Step 1: Registration

Click here to register for the fhEVM Bounty. Fill out the registration form with your information. Once you fill out the form, you will receive a confirmation email with a link to the submission portal for when you are ready to submit your code.

Note

Check your spam folder in case you don't receive the confirmation email. If you haven't received it within 24 hour, please contact us by email at bounty@zama.ai.

Step 2: Work on the Challenge

Read through the Bounty details and requirements carefully. Use the provided resources and create your own GitHub repository to store your code.
If you have any questions during your work, feel free to comment directly in the Bounty issue and our team will be happy to assist you.

Step 3: Submission

Once you have completed your work, upload your completed work to the submission portal using the link provided in the confirmation email.

Note

The deadline for submission is September, 8th 2024 (Midnight, Anywhere On Earth). Late submissions will not be considered.

We wish you the best of luck with the challenge!

✅ Support

• Comment on this issue with any questions regarding this bounty.
• Email for private questions: bounty@zama.ai
• Join the Zama community channels here.

[0xalexbel]

As pointed out in the bounty description, the ERC3643 standard relies on an on-chain Identity verification mechanism. Would it be ok to take advantage of the fhevm internal coprocessor feature to. perfom the following:

• store sensitive encrypted data on-chain
• implement an adapted version of the identity isClaimValid(...) function (the identity contract would store the input handles, the claim issuer would keep the inputProof) ?
• In case it is possible, what about the gas cost of calling verifyCiphertext ?

// Here is the copressor verifyCiphertext() function 
IFHEVMCoprocessor(fhevmCoprocessorAdd).verifyCiphertext(
            inputHandle,
            msg.sender,
            inputProof,
            bytes1(toType)
        );

// Here is the original IIdentity.sol claim verification function profile
function isClaimValid(
        IIdentity _identity,
        uint256 claimTopic,
        bytes calldata sig,
        bytes calldata data)

[immortal-tofu]

We don't view inputs as data to store on-chain, so we wouldn't recommend this approach for various reasons. Specifically, the ZKPoK is meant to be verified by a specific contract with a specific user (msg.sender). Note that, currently, ZKPoKs are not implemented, but we have already implemented the API in the fhevmjs/fhevm libraries.

That said, a good approach would likely be to store an identity contract on-chain where all sensitive data is accessible only to the contract and the user. The identity contract could, with user consent, allow a specific contract to access certain data or attestations.

We can see an identity contract similar to a token contract, where you need to "approve" access before another contract can use your tokens. However, in this case, it's your personal information being accessed.
An other solution would be to handle this "access" through a signature done by the user. This signature for example would the concatenation of the contract address, the user address, the topic and an identifier for example.

[0xalexbel]

It seems to me that the current Tokeny Solutions implementation works like this:

• all claims are public
• there is no access restrictions to claim
• however claim data are supposed to be hashed and accessible via a given URI.
• actual claim sensitive data (such as name address etc.) are managed off-chain.
• detailed claim format used by Tokeny are listed here: https://github.com/onchain-id/claim-topics/blob/master/src/claim_topics.json

If I understand correctly, you are expecting the bounty solution to include a full Identity mechanism that would actually store critical data ON CHAIN (as opposed to the Tokeny off-chain approach, that full-on-chain Identity would have to manage data access + data management + data verification etc. Am I right ?

• Storing encrypted data onchain may be costly ? An probably limited in size.

[immortal-tofu]

As mentioned in the bounty description:

The contract should employ hidden information, showcasing the capabilities of the fhEVM. Care should be taken by the bounty hunter to decide which state variables to encrypt and which should stay unencrypted. Suggestions (non-exhaustive) of state variables to encrypt: transfer amounts, allowances, number of frozen tokens, identities such as country codes, etc.

So, it's up to you. Since fhEVM allows the storage of encrypted data on-chain, storing sensitive data on-chain makes sense instead of using an off-chain mechanism. I was describing one good approach, but there may be other good methods as well.
If you want to store a string, we introduced ebytes256 in fhEVM 0.5.0. It's not documented yet, but it works like the eaddress type, with only the TFHE.eq and TFHE.ne operators available.
Regarding gas costs, we aim to have a gas-efficient solution, meaning the contract should avoid any unnecessary operations, especially on encrypted types.

Overall, the idea is to provide a contract using fhEVM capabilities and explain the reasoning behind the choices made.

[0xalexbel]

Hi Zama Team! 3 questions before submitting my repo for the bounty program:

1- I'm trying to access the zama-dev node to test my contracts prior to submission by following the doc instructions (i created a metamask wallet and followed the instructions). On the faucet page a copy pasted my metamask wallet address and i keep reading "You exceeded ... wait for 11h" What shall I do ? (right now my metamask address '0xfEc8E606485Fe01369BC4D01beaf1DBE3221B638' still has 0 zama).

2- for the bounty i need several wallets for several roles, how can I acheive this on the zama-dev node ? Thank you for your help!

3- In case, I can't connect, is it considered as valid if my repo is fully running on a local dev node ?

Thanks for you help!