Grant Proposal: Dark Forest on Aztec, Blanksquare team

Aztec
, ,
1

Dear all, on behalf of Blanksquare’s team, I have the pleasure to post this response to the Request for Grant Proposals to bring the Dark Forest game to Aztec.

We are a team currently working on privacy in the EVM ecosystem; however, all of us are very excited about Aztec, and for quite some time we have been thinking about a way to enter the Aztec ecosystem. This project is a perfect opportunity for us to start contributing to Aztec. We sincerely hope we can bring a lot of value both to the technical side of Aztec and to the broader user community. Below we provide all the necessary details to assess our proposal, and in particular, much more information about our team and our background.

Grant Form

Contact Information

Team Name: Blanksquare
Contact Person: Damian Straszak
Email: damian.straszak@cardinals.cc
Telegram: @DamianStraszak
Twitter: https://x.com/damian_straszak

Summary

We propose to bring the Dark Forest game to the Aztec network. The technical work consists of 1) rewriting the existing Circom circuits + Solidity contracts into Noir smart contracts, and 2) adapting the existing web client so that it can fetch historical and live state data from Aztec instead of EVM. Furthermore, we would like to organize the first exciting Dark Forest round for the Mainnet Launch of Aztec.

The main goals of this project are as follows:

  • Showcase the technical capabilities and efficiency of the Aztec Network by porting a complex zk-game that is known for being relatively expensive to run on EVM.
  • Build a valuable open-source, production-grade codebase that can be used as a reference for other developers on Aztec.
  • Stimulate the Aztec community and attract new users through an exciting gaming experience. We plan to work together with Aztec’s marketing team to attract as many players as possible via a proactive marketing campaign around the Mainnet Launch event. If the regulatory situation allows, we would also like to offer monetary prizes to top players to further incentivize participation.

Start and End Date:

Start Date: we have already started working on the project here. We can resume as soon as the grant is approved.

End Date: ready for mainnet launch by March 22, 2026.

About Us

We are the team behind Blanksquare, a project focused on bringing privacy to the EVM ecosystem. Our team consists of experienced developers and cryptographers, with a strong background in zero-knowledge proofs, smart contract and frontend development. Our product is based on the idea of shielded pools and thus heavily leans on zk-SNARKs. Our main repositories monorepo and WebApp are open-source and include, among others, components such as:

  • zk-circuits written in Halo2,
  • browser-based and mobile-based snark prover,
  • smart contracts for shielded pools,
  • frontend application for interacting with shielded pools.

Given that the Dark Forest repository contains exactly the same components (with Circom instead of Halo2), we believe that we are uniquely positioned to deliver this project successfully.

Roughly a month ago, we took interest in Noir and Aztec and started experimenting by rewriting all our zk-circuits from Halo2 to Noir here with the intention of gaining hands-on experience with Noir and benchmarking Barretenberg prover performance against Halo2 and the verification gas costs of the verifier contracts generated from Noir.

More showcases of our team’s work:

We plan for the following team members to work on this project, all with extensive 5+ years of experience in Web3:

  1. Damian – PhD in Computer Science, Developer and Cryptographer.
  2. Adam – PhD in Mathematics, Developer and Cryptographer.
  3. Jan – Full-stack Developer.
  4. Wojciech – Frontend Developer.
  5. Jakub – Frontend Developer and Marketing Specialist.

Technical Approach

The original Dark Forest project consists of 3 main elements: circuits, contract and client. Porting to Aztec actually allows us to simplify it, and only two components will be required: contracts (with the zk-logic implemented within private functions) and client. It is also worth estimating which parts require how much work:

  1. Circuits: the circuits in Dark Forest v0.6 are actually trivial. The reason they look complicated at first sight is that Circom is very verbose and requires a lot of boilerplate, and things like range proofs had to be implemented manually (notably with the famous bug). Finally, non-malleability had to be enforced manually as well by introducing dummy constraints. In Noir, all this becomes trivial:

    • Hashing coordinates – we will use Poseidon2 instead of MiMC. Poseidon was not an option in the past because Dark Forest came prior to modern zk-friendly hashes being developed.
    • Using i32 variables for coordinates, which automatically enforces range constraints, instead of manually implementing range proofs.
    • Perlin noise generation – this part is fun, we have a POC ready.
    • Non-malleability – In Noir/Barretenberg, whenever we introduce a public variable, it is committed to the proof, even when it is not explicitly included in any constraint.

    The request for proposals mentions as a requirement that the execution of a player turn should be at most 60s. This time is dominated by client-side proof generation and thus we can already confirm that this constraint is easily met, with our initial benchmarks showing proof generation times of no more than ~5s in-browser for the most complex (yet still trivial: a few hashes and a bunch of simple arithmetic constraints) Dark Forest circuits.

  2. Contracts: this is the part that requires the most work. All the game logic that executes publicly needs to be reimplemented in Noir. Luckily, we can drop the complex “Diamond Pattern” used in the original Dark Forest contract, which was forced by EVM smart contract size limitations. We can implement everything in a single Noir contract. Porting the logic and writing tests will take some time but is straightforward.

  3. Client: the existing client is a bit outdated and must be adapted to interact with Aztec instead of EVM. The current architecture should allow us to efficiently rewrite contract reads and live state updates. Almost all communication happens through ContractAPI, followed by the packages/network/* layer. We plan on rewriting network layer (most notably EthConnection) and ContractAPI internals, while keeping state loading and event emitters mostly intact. Contract writes are less isolated, and although they mostly go through ContractAPI class, changes to the GameManager, Admin-Controls, CreateLobby and TransactionLogPane are unavoidable. There are some libraries that are now outdated and need to be replaced or upgraded (see below):

    • Replace missing concat-stream library
    • Upgrade Node.js version and outdated libraries
    • Inspect and address security vulnerabilities

    We also plan to overhaul the AccountManager to eliminate the insecure “burner wallet” pattern (private keys in local storage) in the plugin system. Instead, we will implement Aztec AuthWit to create scoped session keys. This leverages Aztec’s native account abstraction to generate revocable, time-bound permissions that allow plugins to automate moves without ever exposing the user’s master key.

  4. Indexer: as much as we want to ship the client as a standalone, static web app, we cannot rule out the need for a lightweight indexing service that would allow efficient querying of historical game state. Whether this is needed will be assessed during the first 2 weeks of the project. For the EVM version of Dark Forest, an indexer was not strictly necessary but was handy for displaying interesting stats in the client. We cannot be sure about the performance of state reads on Aztec without a working prototype. If needed—either for the client, a simple web-based leaderboard, or a stats dashboard—we will implement and open-source a lightweight indexer in Rust that would sync Aztec blocks and store relevant game state in a Postgres database.

Grant Milestones and Roadmap

  1. Milestone 0 (1 week - already DONE): Project setup, rewriting Circom circuits in Noir and initial benchmarks.
  2. Milestone 1 (2 weeks): Designing the contract storage and creating a contract skeleton with high-level logic and mocks. All the mocks will be then methodically implemented in the next two Milestones. Updating outdated libraries in the client and rewriting state synchronization logic to work with Aztec.
  3. Milestone 2 (3 weeks): Implementing all game mechanics within the contract skeleton from Milestone 1, porting functionality from 11 Solidity facets into unified Noir contracts. Core components: player initialization and planet management with Perlin noise generation; movement system with arrival queues and spaceship mechanics; planet upgrades across Defense/Range/Speed branches; capture zone invasion system; administrative controls, whitelist. Includes porting shared libraries (LibPlanet, LibGameUtils, LibArtifactUtils) and comprehensive unit testing of each subsystem. On the client side, implement the corresponding state reading and transaction submission logic (wallet integration).
  4. Milestone 3 (1 week): Support for minting Aztec-native NFTs (contract-side and client). Writing e2e tests with full multiplayer scenarios.
  5. Milestone 4 (2 weeks): Extensive testing, both internally and with volunteers from the Aztec community if possible. Preparing player tutorials and documentation.
  6. Milestone 5 (~4 weeks): Running the first Dark Forest round on Aztec Mainnet Launch. This includes posting announcements on relevant social media, working with Aztec’s marketing team to promote the event, and providing support to players during the event. Finally, distributing prizes to top players.

Stretch Goals

  1. Porting the 1-2 most popular plugins from the original Dark Forest.
  2. Implementing an extension of the game that makes use of private state (see the Vision section).

Grant Amount Requested

$69,800 for the entire project
$3,000 for player incentives in the initial game round.

Grant Budget Rationale

According to our milestones and estimates, we will need the following workforce:

  1. Full-stack developers
    • 3 developers full-time for 6 weeks (milestones 1, 2, 3)
    • 1 developer full-time for 2 weeks of testing period (milestone 4)
    • 1 developer at 50% time for 4 weeks for maintenance and support during the Mainnet Launch event (milestone 5)
  2. Frontend developers
    • 2 developers full-time for 6 weeks (milestones 1, 2, 3)
    • 1 developer 50% time for 2 weeks of testing period (milestone 4)
    • 1 developer at 25% time for 4 weeks for maintenance and support during the Mainnet Launch event (milestone 5)
  3. Community and marketing support
    • 1/3 time for 6 weeks during the testing (pre-launch) and launch period to help with player onboarding, support, marketing activities, and coordination.

This totals to:

  • Full-stack developers: 3 * 6 + 1 * 2 + 0.5 * 4 = 22 developer-weeks
  • Frontend developers: 2 * 6 + 0.5 * 2 + 0.25 * 4 = 14 developer-weeks
  • Marketing and Community: 1/3 * 6 = 2 developer-weeks

Assuming the following rates:

  • $2,000 per week for full-stack developers
  • $1,650 per week for frontend developers
  • $1,350 per week for marketing and community support

This gives us the following budget: $69,800

Note: our commercial consulting rates would generally be higher, but we are willing to make this investment because:

  1. We view this as a long-term entry point into the Aztec ecosystem.
  2. We are passionate about the technical challenge of porting Dark Forest.

Finally, we would like to allocate $3,000 for player incentives during the first Dark Forest round on Aztec Mainnet Launch. This amount would be used to reward the top players with monetary prizes, provided that the regulatory situation allows it. We believe that offering such incentives will significantly boost player participation and engagement, making the event more exciting and successful.

Deliverables

  1. Open-source Noir contracts implementing the Dark Forest game logic.
  2. Open-source web client adapted to interact with Aztec.
  3. Documentation and tutorials for players.
  4. Coordinating the first Dark Forest round on Aztec Mainnet Launch.

Future Work and Vision

While the initial scope of this project focuses on porting the existing Dark Forest game to Aztec, we see significant potential for future enhancements that leverage Aztec’s privacy features. More specifically, the current Dark Forest game does not utilize private storage (notes), and the “fog of war” is very limited. Indeed, with enough computational power, the fog of war can be completely lifted by observing all public transactions on-chain. This is a significant limitation of the current design, and we believe that we can do much better with Aztec. One possible direction for future work would be to implement a “stealth” mechanic that moves beyond the binary “hidden vs. revealed” state of current ZK games. This can be achieved by utilizing Aztec’s native hybrid state architecture to efficiently compute private inputs against public state.

  1. The “Spy vs. Radar” logic: We propose a mechanic where attacking fleet visibility is partial. This leverages the PXE’s native ability to read public storage from a private context. The user’s local PXE fetches the defender’s global public Radar_Tech and compares it against their own private Spy_Tech note. Instead of binary hiding, the circuit enqueues a public function call to register a Visible_Amount using the formula: Visible = Actual×0.8^(Spy−Radar)

    The network verifies this proof against the public state without ever revealing the private inputs. This makes defense strategic rather than impossible, as defenders see something but cannot trust if it is the full force.

  2. Solving State Leakage (The “Outer Orbit” Model): A major privacy leak in current systems is that observing a drop in a user’s public balance reveals the size of a “private” attack. To solve this, we propose a model of planets with two storage zones:

    • Inner Orbit (Public): Ships count toward defense and are visible.
    • Outer Orbit (Private Staging): Ships here are “prepared for flight” and invisible. Attacks strictly mobilize from the Outer Orbit. Since these assets are already shielded, the attack transaction triggers no change in the public state tree, preserving the element of surprise.

Our initial experiments can be found in this repository.

These ideas are just initial thoughts, and we would be excited to explore them further in collaboration with the Aztec team and community after successfully completing the initial porting project.

Request for Grant Proposals: Dark Forest on Aztec | Up to $75,000