Bounty Track December 2025: Build The FHEVM Example Hub

December 2, 2025

—

The Zama Team

The Zama Bounty Program aims to inspire and incentivize the developer community to contribute to the Zama Confidential Blockchain Protocol.

Each season, we introduce a new bounty that addresses a specific challenge. With this initiative, we invite developers to collaborate with us in advancing the FHE ecosystem.

For this season, the challenge is to build a set of standalone, Hardhat-based FHEVM example repositories, each demonstrating one clear concept (e.g., access control, public decryption, user decryption), with clean tests, automated scaffolding, and self-contained documentation. The prize pool for this challenge is $10,000.

Important dates

Start date: December 1, 2025
Submission deadline: December 31, 2025 (23:59, Anywhere On Earth)

Overview

The goal of this bounty is to create a comprehensive repository including standalone FHEVM examples that help developers learn and implement privacy-preserving smart contracts using Fully Homomorphic Encryption.

A starter example implementation of this bounty can be found here.

This repository demonstrates:

Automated scaffolding tools for generating example repositories
Documentation generation from code annotations
Category-based project generation
Complete implementation of the bounty requirements

How to participate

Participants should create a repository containing:

Automation scripts - TypeScript-based CLI tools for generating example repositories
Example contracts - Well-documented Solidity contracts demonstrating FHEVM concepts
Comprehensive tests - Test suites showing both correct usage and common pitfalls
Documentation generator - Tool to create GitBook-compatible documentation
Base template - Using our Hardhat template which can be cloned and slightly customized

Check out the example implementation to see:

How to structure your automation scripts
Example contract and test patterns
Documentation generation workflow
Category-based project generation

Requirements

1. Project structure & simplicity

Use only Hardhat for all examples
One repo per example, no monorepo
Keep each repo minimal: contracts/, test/, hardhat.config.ts, etc.
Use a shared base-template that can be cloned/scaffolded
Generate documentation like seen in /example relates to page.

2. Scaffolding / Automation

Create a CLI or script ([.c-inline-code]create-fhevm-example[.c-inline-code]) to:

Clone and slightly customize the base Hardhat template
Insert a specific Solidity contract into [.c-inline-code]contracts/[.c-inline-code]
Generate matching tests
Auto-generate documentation from annotations in code

Example implementation: See the example project for working [.c-inline-code]create-fhevm-example.ts[.c-inline-code] and [.c-inline-code]create-fhevm-category.ts[.c-inline-code] scripts written in TypeScript.

3. Types of examples to include (each of these becomes a standalone repo):

Examples that we already have

Basic:

Simple FHE counter
Arithmetic (FHE.add, FHE.sub)
Equality comparison (FHE.eq)

Encryption:

Encrypt single value
Encrypt multiple values

User decryption:

User decrypt single value
User decrypt multiple values

Public decryption:

Single value public decrypt
Multi value public decrypt

Additional example items to include

Access control

What is access control
FHE.allow, FHE.allowTransient

Input proof explanation

What are input proofs and why they're needed
How to use them correctly

Anti-patterns

View functions with encrypted values (not allowed)
Missing FHE.allowThis() permissions
Other common mistakes

Understanding handles

How handles are generated
Symbolic execution
Handle lifecycle

OpenZeppelin confidential contracts: (this can be found in previous versions, which needs an upgrade and import of this library)

ERC7984 example
ERC7984 to ERC20 Wrapper
Swap ERC7984 to ERC20
Swap ERC7984 to ERC7984
Vesting Wallet
...

Advanced examples:

Blind auction

Or anything else that you can think of.

4. Documentation strategy

Use JSDoc/TSDoc-style comments in TS tests
Auto-generate markdown README per repo
Tag key examples into docs: "chapter: access-control", "chapter: relayer", etc.
Generate GitBook-compatible documentation

Example implementation: See [.c-inline-code]generate-docs.ts[.c-inline-code] in the example project for automated documentation generation in TypeScript.

Bonus points:

Creative examples - Implementing additional examples beyond the requirements
Advanced patterns - Demonstrating complex FHEVM patterns and use cases
Clean automation - Particularly elegant and maintainable automation scripts
Comprehensive documentation - Exceptional documentation with detailed explanations
Testing coverage - Extensive test coverage including edge cases
Error handling - Examples demonstrating common pitfalls and how to avoid them
Category organization - Well-organized categories for different example types
Maintenance tools - Tools for updating examples when dependencies change

Judging criteria

All submissions must include a demonstration video as a mandatory requirement. The video should clearly showcase your project's setup, key features, example execution, and automation scripts in action.

Judging will be based on:

Code quality
Automation completeness
Example quality
Documentation
Ease of maintenance on new version changes
Innovation

Deliverables

Your submission must include:

base-template/ - Complete Hardhat template with [.c-inline-code]@fhevm/solidity[.c-inline-code]
Automation scripts - [.c-inline-code]create-fhevm-example[.c-inline-code] and related tools in TypeScript
Example repositories - Multiple fully working example repos (or category-based projects)
Documentation - Auto-generated documentation per example
Developer guide - Guide for adding new examples and updating dependencies
Automation tools - Complete set of tools for scaffolding and documentation generation

Reference repositories

Use the following repositories as references:

Examples and text: https://docs.zama.org/protocol/examples
Base template: https://github.com/zama-ai/fhevm-hardhat-template
dApps and hardhat examples (outdated): https://github.com/zama-ai/dapps
OpenZeppelin's confidential contracts repo: https://github.com/OpenZeppelin/openzeppelin-confidential-contracts
Example implementation: https://github.com/poppyseedDev/zama-bounty-11-example-project

Rewards

🥇 1st place: $5,000
🥈 2nd place: $3,000
🥉 3rd place: $2,000

How to participate?

Connect your wallet to the Zama Guild and submit your project from here.

Additional links

Zama Developer Program on Guild
Zama Community Forum for developer support
Zama Discord server
Zama on X
Zama on Telegram

‍

Latest Blog Posts

Developer Program December 2025 - Join the Pre-Mainnet Builder Cohort

Announcements

Your chance to join the last pre-mainnet cohort of developers building on the Zama Protocol via the Developer Program.

Creator Program Season 5 - The Last Chance To Be the First

Announcements

Season 5 reserves the final 1,000 OG spots for creators. It's your last chance to be the first!

Bounty Track December 2025: Build The FHEVM Example Hub

Announcements

Build a set of standalone, Hardhat-based FHEVM example repositories, each demonstrating one clear concept.

Read more →

Back to blog

Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn't want the whole world to know, but a secret matter is something one doesn't want anybody to know. Privacy is the power to selectively reveal oneself to the world.If two parties have some sort of dealings, then each has a memory of their interaction. Each party can speak about their own memory of this; how could anyone prevent it? One could pass laws against it, but the freedom of speech, even more than privacy, is fundamental to an open society; we seek not to restrict any speech at all. If many parties speak together in the same forum, each can speak to all the others and aggregate together knowledge about individuals and other parties. The power of electronic communications has enabled such group speech, and it will not go away merely because we might want it to.Since we desire privacy, we must ensure that each party to a transaction have knowledge only of that which is directly necessary for that transaction. Since any information can be spoken of, we must ensure that we reveal as little as possible. In most cases personal identity is not salient. When I purchase a magazine at a store and hand cash to the clerk, there is no need to know who I am. When I ask my electronic mail provider to send and receive messages, my provider need not know to whom I am speaking or what I am saying or what others are saying to me; my provider only need know how to get the message there and how much I owe them in fees. When my identity is revealed by the underlying mechanism of the transaction, I have no privacy. I cannot here selectively reveal myself; I must always reveal myself.Therefore, privacy in an open society requires anonymous transaction systems. Until now, cash has been the primary such system. An anonymous transaction system is not a secret transaction system. An anonymous system empowers individuals to reveal their identity when desired and only when desired; this is the essence of privacy.Privacy in an open society also requires cryptography. If I say something, I want it heard only by those for whom I intend it. If the content of my speech is available to the world, I have no privacy. To encrypt is to indicate the desire for privacy, and to encrypt with weak cryptography is to indicate not too much desire for privacy. Furthermore, to reveal one's identity with assurance when the default is anonymity requires the cryptographic signature.We cannot expect governments, corporations, or other large, faceless organizations to grant us privacy out of their beneficence. It is to their advantage to speak of us, and we should expect that they will speak. To try to prevent their speech is to fight against the realities of information. Information does not just want to be free, it longs to be free. Information expands to fill the available storage space. Information is Rumor's younger, stronger cousin; Information is fleeter of foot, has more eyes, knows more, and understands less than Rumor.We must defend our own privacy if we expect to have any. We must come together and create systems which allow anonymous transactions to take place. People have been defending their own privacy for centuries with whispers, darkness, envelopes, closed doors, secret handshakes, and couriers. The technologies of the past did not allow for strong privacy, but electronic technologies do.We the Cypherpunks are dedicated to building anonymous systems. We are defending our privacy with cryptography, with anonymous mail forwarding systems, with digital signatures, and with electronic money.Cypherpunks write code. We know that someone has to write software to defend privacy, and since we can't get privacy unless we all do, we're going to write it. We publish our code so that our fellow Cypherpunks may practice and play with it. Our code is free for all to use, worldwide. We don't much care if you don't approve of the software we write. We know that software can't be destroyed and that a widely dispersed system can't be shut down.Cypherpunks deplore regulations on cryptography, for encryption is fundamentally a private act. The act of encryption, in fact, removes information from the public realm. Even laws against cryptography reach only so far as a nation's border and the arm of its violence. Cryptography will ineluctably spread over the whole globe, and with it the anonymous transactions systems that it makes possible.For privacy to be widespread it must be part of a social contract. People must come and together deploy these systems for the common good. Privacy only extends so far as the cooperation of one's fellows in society. We the Cypherpunks seek your questions and your concerns and hope we may engage you so that we do not deceive ourselves. We will not, however, be moved out of our course because some may disagree with our goals.The Cypherpunks are actively engaged in making the networks safer for privacy. Let us proceed together apace.Onward.Eric Hughes9 March 1993