Zama Bounty Program Season 9: Build a privacy-preserving DCA bot

July 25, 2025

—

The Zama Team

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

Each season, we introduce a new bounty that addresses real-world onchain privacy challenges. With this initiative, we invite developers to collaborate with us in advancing the FHE ecosystem.

For Season 9, the challenge is to build a privacy-preserving DCA bot with transaction batching using the Zama Protocol, with a price pool of €10,000.

Important dates

Season 9 starting date: July 25, 2025
Season 9 submission deadline: August 25, 2025(23:59, Anywhere On Earth)

Overview

In finance, Dollar-Cost Averaging (DCA) is an investment strategy where a market participant invests a fixed amount of money into a particular asset at regular intervals, regardless of price, to reduce the impact of volatility and lower the average cost per share over time.

This strategy is also popular in DeFi, where bots can be programmed to execute automated DCA purchases of a token as long as there are funds available in the wallet.

For example, Balmy and Sushi are well-known DCA bots that are publicly available for DeFi users. These bots execute automated strategies in liquidity pools across several decentralized exchanges (DEXes).

Unfortunately, DEXes are not private:

Anyone can see the investment strategy of every DCA bot simply by looking at a block explorer.
This reveals sensitive data about assets, wealth, and connected addresses of the owner of the DCA bot.

Ideally, the Zama protocol could improve this experience by hiding the trading strategies of DCA bots operating on liquidity pools. One promising approach is to add a transaction batching mechanism on top of the DCA bot.

Objective

The goal of this bounty is to build a privacy-preserving DCA bot with transaction batching using the Zama Confidential Blockchain Protocol. This bot will execute automated strategies while maintaining user privacy through a novel batching mechanism.

Why is batching essential

Traditional DCA bots reveal individual transaction patterns, making users vulnerable to:

Front-running and Maximal Extractable Value (MEV) attacks
Portfolio tracking by competitors
Wealth profiling and targeted attacks

Furthermore, the obvious approach—wrapping tokens into confidential ERC-20s—does not solve the problem. While confidential tokens hide balances and transfers within their own contract, the act of wrapping itself is visible on-chain. Anyone can see how much is being wrapped and when, leaking the user’s DCA strategy in real time. Without further protection, each wrap and unwrap action exposes the exact amounts the user intends to trade, defeating the purpose of confidentiality.

Batching solves these issues by aggregating multiple users' DCA orders into a single on-chain transaction, providing k-anonymity (where k is a fix number of users). When the batch executes, individual strategies remain hidden within the group, ensuring that:

No single user's purchase amount is revealed
Trading patterns are obfuscated
The actual swap on the DEX only shows aggregated amounts

Core requirements

1. Batching mechanism

Your solution MUST implement a batching system that:

Collects encrypted DCA intents from multiple users (target: 10 users per batch)
Aggregates encrypted amounts using FHE operations without revealing individual contributions
Executes a single decrypted swap on a DEX (e.g., Uniswap on Sepolia) for the total batch amount. For the sake of simplicity, batching of swaps should only happen in one direction (USDC → ETH), not bidirectional (USDC→ETH & ETH → USDC).
Distributes purchased tokens back to users proportionally using encrypted calculations
Batch execution triggers:
- Primary: Participants should decide on an appropriate batch size for users that submit intents for the same trading pair.
- Fallback: Participants should decide if batches will take place after a specific amount of time, regardless of how many users submit intents. (eg. 1 block, 5 seconds, etc)

2. Private DCA strategy features

Users should be able to encrypt parameters such as:

Budget: Total USDC amount to invest (e.g., 5000 USDC)
Purchase amounts: How much to buy per interval
Timeframe: Total duration for the DCA strategy (eg. 24 hrs, 1 week, 1 year)s
Frequency: assets purchases at fix time intervals
[Optional] Add Dynamic conditions: e.g., "buy the dip: if ETH drops 3%, double the purchase amount for next 5 buys"

All these parameters must remain encrypted and only be processed within the FHE environment.

What we expect

A complete application with a clean, clear user experience
Correct usage of FHEVM implemented in the smart contract, effectively protecting private data on the blockchain.
A detailed documentation explaining the code design and a user guide.
Tests proving that your solution works as intended
Real usage examples and benchmarks when deployed on the testnet

Judging criteria

Submissions will be evaluated across several dimensions:

Quality of the code (frontend, contracts, backend)
Privacy (how much user information remains confidential)
Efficiency & scalability
Coverage of the tests
User experience (clarity and smoothness)
Decentralization:
- Is your bot fully decentralized?
- Are you relying on decentralized services (e.g., Chainlink Automation) to trigger executions?
DEX integration:
- Is your solution using a decentralized exchange (e.g., Uniswap) to perform swaps?
- What, if anything, can an observer see on-chain?
Strategy confidentiality:
- What information about the user’s strategy is hidden?
- Is the privacy configuration flexible?

Resources and references

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.

How to participate?

Connect your wallet to the Zama Guild and register from here.

Additional Links

Zama Bounty Program on Guild
Zama Community Forum for developer support.
Zama Discord server.‍
Zama on X.
Zama on Telegram

Latest Blog Posts

Zama Bounty Program Season 9: Build a privacy-preserving DCA bot

Announcements

Calling all developers to build a privacy-preserving DCA bot with transaction batching using the Zama Protocol.

Zama Partners with OpenZeppelin to Bring Confidential Smart Contracts to DeFi and Digital Assets

Announcements

Today, we're taking a decisive step toward the future of confidential blockchain, and it involves our new partners at OpenZeppelin

TFHE-rs v1.3: Faster Division on CPU, Key Upgrader & Memory Tracking on GPU

TFHE-rs

TFHE-rs v1.3 brings several major improvements and new features across CPU, GPU, and HPU backends.

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