Fhenix Bounty Program
The Fhenix bounty program goal is to incentivize developers to explore the power of confidential computation using Fully Homomorphic Encryption.
For more information about the process, please click here.
All Bounties
Bounty 1: FHE SC Template
We want to create smart contract templates using the Fhenix FHE library. These templates are meant to serve as examples that developers can use to build their contract bases from. We want to aim to add familiar contract formats that developers are already familiar with so that they don’t need to start from scratch and can have a familiar point of reference in addition to the new logic changes that are required when working with FHE.
Spec
FHE SC Template Spec
General description:
We want to create smart contract templates using the Fhenix FHE library. These templates are meant to serve as examples that developers can use to build their contract bases from. We want to aim to add familiar contract formats that developers are already familiar with so that they don’t need to start from scratch and can have a familiar point of reference in addition to the new logic changes that are required when working with FHE.
Requirements:
- Complete Smart Contract – Must
- Verified Contract on Testnet – Must
- Contract Test Suite – Should
Architecture:
- Contract deployment on Testnet
- Link to GitHub Repository with Readme
- Link to testnet deployment
Templates/Logic:
- ERC-721
- Description: We are looking to build an erc-721 NFTs showcase contract. This can include obfuscating key fields such as the ownership mappings and ids. Additional options include encrypting aspects of the URI as well as including private fields in the state of the contract itself. Additional permissions based on the ownership of specific NFTs can be included.
- Can include private ownership of tokens
- Private Metadata (and/or URI)
- Have part of JSON object encrypted via ownership of NFT – Nice
- Schema fields involving ciphertext
- Password as an NFT
- Dynamic controls for access
- IPFS unlock
- Aes256 iirc
- Integration with eAddress data type for mappings as values
- Vesting Defi – import “@openzeppelin/contracts/finance/VestingWallet.sol”;
- Description: We are looking to create a new simple defi primitive that can be used for multiple different types of staking applications. Ideally users should have the option to stake their tokens for a reward over time, while maintaining privacy. Basically we want to hide certain features, specifically how much is being staked, how long is it being staked, and what is the reward.
- Can include private ownership of tokens
- Useful primitive
- FHE can be used here to hide a few fields
- How much is being Staked
- How Long it needs to be staked for
- Who is staking – Nice
- Eaddress integration for designation – Nice
- fhERC-20 integration – Should
- Social Messaging Template
- Description: We are looking to create a template that can be used for social networking applications on Fhenix. One of the primary issues when dealing with web3 social applications is a lack of privacy. Ideally we would like to leverage FHE in order to allow users to connect privately, block certain users from using these features, and restrict view permission to those with certain assets.
- Similar to our voting template, walks through conditional access
- Can write a specific message for a feed
- IPFS unlock
- Aes256 iirc – Nice
- IPFS unlock
- Some sort of rating on Images
- Can view average ratings after 10 ratings
- Private rating system/rankings
Out of scope:
- Complete applications using these templates are out of scope for these bounties.
- Larger File encryption (social media)
- Scalable messaging (social media)
- restaking/rehypothecation (defi primitive)
Effort estimation: 2 Weeks
Prize: $1000 for each contract
- In equivalent amount in crypto tokens
Internal Notes:
- Controlled access for media is similar to this project
Bounty 2: FHE 2FA (Showcase)
A 2FA demonstration application allows users to generate random temporary passwords that are kept confidential, accessible only to the owner (i.e., the user who connects their wallet). The application should be completely decentralized, ensuring that no one else has access to the generated passwords. The purpose of this bounty is to showcase the creation of a fully decentralized and private 2FA tool.
Spec
FHE 2FA Spec (Showcase)
General description:
A 2FA demonstration application allows users to generate random temporary passwords that are kept confidential, accessible only to the owner (i.e., the user who connects their wallet). The application should be completely decentralized, ensuring that no one else has access to the generated passwords. The purpose of this bounty is to showcase the creation of a fully decentralized and private 2FA tool.
Requirements:
- Complete 2FA Log In Contract – Must
- Client Integration – Must
- Include Required Approval From Second Source – Must
- Rotating Time Based Access – Must
- Contract Test Suites in HardHat – Should
- Application Test Suite – Nice
- Live hosted Url – Bonus
Architecture:
- Contract deployment on Testnet
- ABI integration with Fhenix.js
- Fully Hosted Application Url
- This should show the last request time
- Link to GitHub Repository with Readme
Logic:
- User connects their current address to the application
- User assigns another address to be the second signer
- Use a struct that contains necessary fields
- Blocktime of last request
- Time interval
- Mapping from original Address
- Ebool for second signature approval
- Blocktime of the last Approval from second address
- Primary Address will write to contract that it wants to give another address the ability to act as the second signature
- Use a struct that contains necessary fields
- Able to mint Asset after triggering correct condition for a certain amount of time – “Bonus”
- Have some sort of encrypted field that can be viewed if the user has successfully logged in.
- This can also be access to do something such as minting etc
- Asset decryption access – Bonus
- Have some sort of encrypted field that can be viewed if the user has successfully logged in.
- Change Second Signature Address – Bonus
Out of scope:
- Recovery for Lost Address
- External API Verification
- Rotational Approvals (second signer changes over time)
- View rotation for decrypting media
Effort estimation: 2 Weeks
Prize: $2000
- In equivalent amount in crypto tokens
Internal Notes:
- N/A
Bounty 3: FHE DID (Sample APP)
The goal of the Decentralized Identity (DID) bounty is to develop a smart contract that serves as a demonstration for creating a straightforward DID initiation. This identity consists of both public and private attributes. The private attributes remain confidential and can only be accessed by the owner through a permit. Should include a simple UI that demonstrates the process of creating a DID.
Spec
FHE DID Spec (Sample APP)
General description:
The goal of the DID bounty is to develop a smart contract that serves as a demonstration for creating a straightforward Decentralized Identity. This identity consists of both public and private attributes. The private attributes remain confidential and can only be accessed by the owner through a permit. Should include a simple UI that demonstrates the process of creating a DID.
Requirements:
- Complete DID Smart Contract with Private Identifiers – Must
- Client/UI Integration – Must
- Include schemas containing Private + Public Fields – Must
- Contract Test Suites in HardHat – Should
- Application Test Suite – Nice
- Live hosted Url – Bonus
- Conditional Permissions Based on Address and/or Field – Should
- Admin Control – Nice
Architecture:
- Contract deployment on Testnet
- ABI integration with Fhenix.js
- Link to GitHub Repository with Readme
Logic:
- Contain some sort of mapping to FHE private fields
- Ideally include public read/write endpoints as well
- Must include conditional read endpoint
- Frontend needs have fhenix.js integration
- Users need to be able to pass ciphertexts into the contract (post)
- Update endpoints for necessary fields (patch)
- View functions for conditional sealed outputs (read)
- Clients should show the user’s profile and give them the option to make certain fields publicly available or not. (Optional)
- Ideally, have a filter for specific encrypted fields. An encrypted query.
- We want to show off why use FHE vs something like ZK
- Perhaps do a type of short, or ciphertext drilling
- Conditional Permissions – Bonus
- Allow users to set conditions for other users to see specific fields
- Ex: Only allow known addresses view Social Security
- EX Only allow users who have the same field type to decrypt
- Allow users to set conditions for other users to see specific fields
- ERC-721 Base (Optional)
- Can potentially be used as a Soulbound token to remove transfer
Out of Scope:
- Creation process – Less naive approach
- Access control – how to elaborate private attributes with external sources
- Recovery process
- Existing Application Integration
Effort estimation: 2-2.5 Weeks
Fhenix Team Suggestions:
- Dating Profiles
- Matching profiles based on hidden filters
- People may want to keep somethings private
- STDs
- Body Count
- Fertility
- Medical Information
- Financial Credit
- Social Account
Prize: $2000
- In equivalent amount in crypto tokens
- $500 Bonus of Livehosting
Internal Notes:
Bounty 4: MetaMask Snap for Confidential ERC-20 Token Support
This bounty aims to incentivize the development of a MetaMask snap that enables the support for Fhenix’s confidential ERC-20 tokens. The snap should ensure that these tokens are visible in the MetaMask wallet UI, including accurate balance display and detailed transaction history.
Spec
MetaMask Snap for Confidential ERC-20 Token Support
General:
This bounty aims to incentivize the development of a MetaMask snap that enables the support for Fhenix’s confidential ERC-20 tokens. The snap should ensure that these tokens are visible in the MetaMask wallet UI, including accurate balance display and detailed transaction history.
Bounty Details:
Objective:
Goal of the MetaMask snap: Enable support for confidential ERC-20 tokens in the MetaMask UI, including displaying balances and transaction history.
Technical Requirements:
- Compatibility: Ensure the snap works seamlessly with the Fhenix network (EVM-compatible).
- Token Visibility: Display confidential ERC-20 tokens in the MetaMask UI.
- Balance Display: Accurately show token balances in the MetaMask wallet.
- Transaction History: Provide a clear and detailed history of transactions involving confidential ERC-20 tokens.
- Security: Maintain the confidentiality and integrity of transactions and balances.
- User Experience: Ensure the snap is user-friendly and doesn’t require complex configurations.
Development Considerations:
- Integration with MetaMask’s existing API and Ethereum Provider API.
- Handling of confidential transaction data and privacy preservation.
- Testing and debugging on the Fhenix testnet.
Developers are invited to build and submit a MetaMask snap that meets the outlined technical requirements. The successful submission will significantly enhance the user experience on the Fhenix network by integrating confidential token support directly into MetaMask, one of the most popular Ethereum wallets.
Reward Structure:
- First Place: [$1,500] for the best-performing snap that fully meets all requirements and passes all testing phases.
- Runner-Up: [$1,000] for submissions that meet the majority of the requirements and show significant potential.
- Honorable Mentions: [$500] for innovative approaches or partial implementations that could inspire future development.
Evaluation Criteria:
- Functionality: The snap must fully integrate with MetaMask and support confidential ERC-20 tokens as described.
- User Experience: The snap should be intuitive and easy to use, with minimal configuration required from the user.
- Security: The implementation must preserve the confidentiality of transactions and token balances.
- Performance: The snap should be efficient, with minimal impact on MetaMask’s overall performance.
- Code Quality: Clean, well-documented, and maintainable code is expected.
Submission Guidelines:
- Provide a link to the GitHub repository containing the code.
- Include detailed instructions for installation and usage.
- Provide a demo video or screenshots demonstrating the snap’s functionality.
- Ensure that the submission is open-source and complies with Fhenix Labs’ licensing requirements.
Deadline:
All submissions must be received by 22th of September. Winners will be announced within two weeks after the submission deadline.
Support:
Developers can access Fhenix Labs’ documentation and MetaMask’s developer resources to aid in the snap’s development. A dedicated support channel will be available for participants to ask questions and receive guidance.
Bounty 5: BlackJack Showcase
The BlackJack bounty aims to create a simple blackjack platform that enables on-chain blackjack using FHE capabilities. In this game, players compete against the dealer, and the deck of cards is generated randomly. This project will demonstrate the potential to develop on-chain casino gaming on Fhenix.
Bounty 6:
In your application, be sure to clarify how your project creates a public good for the Fhenix network, typically through furthering decentralization, open sourcing code, or helping to secure the Fhenix network a public good for the Fhenix network, typically through furthering decentralization, open sourcing code, or helping to secure the Fhenix network a public good for the Fhenix network, typically through furthering decentralization, open sourcing code, or helping to secure the Fhenix network.