Dapps over Apps - Dark Forest v0.6 on Aztec (Noir-native, end-to-end port)

[DappsoverApps]

Contact Details

• Email: team@dappsoverapps.com

  Summary

  We will deliver a functional, end-to-end port of Dark Forest v0.6 to Aztec by implementing the game’s state transition rules and ZK validation constraints as Noir-based Aztec smart contracts, preserving the v0.6 public footprint: discovered planetId → PlanetState, move records, and global configuration. Planet coordinates and undiscovered space remain offchain, consistent with Dark Forest’s exploration privacy model.

  The contract architecture is designed around Aztec’s private/public execution model: each gameplay action is a #[external("private")] entrypoint that validates plaintext claims (e.g., coordinates, move parameters, artifact identifiers) using Noir constraints equivalent to the original Circom checks. The private entrypoint then computes deterministic “apply arguments” (state deltas, commitments, indices) and enqueues #[external("public")] apply functions to mutate public state. All public apply functions are restricted with #[only_self] so they cannot be called externally, preventing bypass of private validation.

  Because private execution sees historical state, private proofs do not assume they read the latest owner/balances/queues. Instead, public apply functions re-check critical invariants (owner, balances, queue cursors, arrival ordering) against chain-head state at inclusion time and revert cleanly on staleness or conflicts.

  The key engineering risk is constraint parity drift (Noir accepting claims the v0.6 Circom circuits would reject or vice versa). We mitigate this via a parity harness with golden vectors, negative tests, and fuzz tests per module, enforced by CI gating. Performance is engineered around bounded public processing and hot-path constraint budgeting; we will instrument turn latency end-to-end (witness build → proving → tx assembly → dispatch) and enforce the RFPG’s <60s per turn requirement using proving-enabled benchmarks.

  We will ship a playable client that supports exploration, movement/capture, resources/upgrades, artifacts/foundries, spacetime rips, and minting Aztec-native NFTs from ripped artifacts, with robust tests and documentation.

  Start and End Date

  • Start: ASAP (immediately)

  • Functional version by: **March 22, 2026 **

  Team

Dapps over Apps is a delivery-focused builder collective with a track record of shipping developer tooling and protocol integrations across multiple ecosystems, including gaming-adjacent tooling (The Sandbox creator tooling), ZK-adjacent infrastructure (Zcash dev tooling), and smart contract ecosystems (Arbitrum/Polkadot). We have repeatedly delivered funded ecosystem tooling initiatives where correctness, reliability, and developer UX are the primary acceptance criteria.

Team Members

Abdulkareem Oyeneye — Project Lead
Experienced developer tooling engineer and project manager with a strong background in Web3 growth and technical product execution. Owns delivery planning, milestone gating, release coordination, and documentation quality; ensures scope control to hit the March 22 deadline.
Profile:

https://www.linkedin.com/in/abdulkareem-oyeneye-82a6aa277

Musa Abdulkareem — ZK Engineer (Nethermind)
Core ZK engineer at Nethermind, focused on rigorous constraint engineering and protocol-level correctness. Owns Circom→Noir parity implementation, fixed-point/perlin constraint work, proof-time profiling, and CI parity gating to prevent drift and exploitability.
Profile:

https://www.linkedin.com/in/wisemrmusa

Bolaji Ahmad — Full Stack Engineer
Full stack and infra-focused engineer with experience shipping foundational tooling across blockchain frameworks (including Polkadot ecosystem work). Owns the web client, state sync/indexing, tx pipeline instrumentation, and performance-focused UX integration.
Profile:

https://linkedin.com/in/bolajahmad

Gospel Ifeadi — Smart Contract Engineer
Proficient in Rust, C++, JavaScript, and Python. Owns Aztec contract implementation, public state schema design, bounded settlement logic, and contract-side integration tests; ensures contract architecture matches Aztec private→public execution constraints.
Profile:

https://x.com/gospel70800

Some Past Work

1. ZecKit (Zcash developer toolkit) — containerized Zcash/Zebra regtest workflows, health checks, smoke tests, and CI-oriented devnet tooling.

https://github.com/zecdev/ZecKit

2. VoxBridge (VoxEdit → Unity/Roblox converter) — asset conversion workflow supporting creator pipelines in The Sandbox ecosystem (gaming protocol tooling).

https://github.com/Supercoolkayy/voxbridge

3. Ox-rollup (local dev compatibility patch + docs) — developer workflow tooling and compatibility work for local testing.

https://ox-rollup.com/
https://github.com/Supercoolkayy/Ox-rollup

4. RetrievalTester (Filecoin retrieval benchmarking app) — CID retrieval performance measurement across gateways.

https://retrievaltester.com/

Technical Approach

1) Toolchain discipline and environments

We will pin the Aztec toolchain used for development (Aztec CLI + Aztec.js + Aztec.nr versions) and keep a single locked version across CI and dev machines to prevent “moving target” breakages. Two execution environments are used throughout the project:

• Local network for rapid iteration (fast feedback loops)

• Proving-enabled local benchmarking for performance gating (the source of truth for the <60s “turn” requirement)

• Devnet deployment for final integration validation and the showcase deliverable

We will treat “proving-enabled performance” as a first-class acceptance requirement (not a late-stage activity), with instrumentation from week 1.

2) Contract architecture

2.1 Contracts

• DarkForestGame — canonical game state machine (planets, moves, config, artifacts/rips eligibility).

• ArtifactNFT — Aztec-native NFT minting for “ripped” artifacts with mint authorization restricted to DarkForestGame.

2.2 Execution flow (per action)

Private entrypoint (proof-bearing)

• #[external("private")] fn action_*(...)

  • Inputs: plaintext claims (coords/params) + witnesses

  • Compute: planetId, moveId, commitments, bounded indices

  • Validate: Noir constraints (parity to v0.6 Circom)

  • Output: deterministic “apply arguments”

  • Enqueue: #[external("public")] #[only_self] fn apply_*(...)

Public apply (chain-head correctness + bounded processing)

• #[external("public")] #[only_self] fn apply_*(...)

  • Re-checks invariants against chain-head public state

  • Applies bounded state transitions

  • Reverts transaction if stale/conflicting (ensures correctness under races)

2.3 Security properties

• No bypass: public state mutation is only possible via #[only_self] apply functions, reachable only through a valid private proof flow.

• Race-safe: private is historical; public apply re-validates assumptions.

• Replay-safe: apply functions verify indices/cursors and “already-applied” constraints (move IDs, minted flags, etc.).

3) Public state model

3.1 Public storage schema

Planets

• planets[planetId] -> PlanetStatePublic

  • owner

  • energy

  • silver

  • upgrades

  • lastUpdatedTick

  • artifactSlots (MVP: fixed-size array) or artifactsRoot (compact commitment)

Moves

• moves[moveId] -> MoveRecordPublic

  • srcPlanetId, dstPlanetId

  • arrivalTick

  • energy

  • optional artifact transfer fields

Config

• config -> GameConfigPublic

  • universeSeed

  • worldRadius

  • tick parameters and constants needed for deterministic checks

3.2 Bounded settlement

Public settlement will never scan an unbounded global list. We will implement incremental processing:

• per-planet arrival queue indices/cursors

• public apply functions process up to K arrivals per call

• additional arrivals are processed on subsequent interactions (amortized settlement)

This keeps public cost predictable and prevents “too-many-moves-to-settle” failure modes.

4) Circom → Noir port plan

4.1 Circuit parity matrix (deliverable and CI contract)

We will maintain a versioned parity matrix mapping v0.6 circuits/modules to Noir modules and contract actions, with a strict Definition of Done per module:

Module inventory (MVP)

• init_verify.nr → player init constraints

• reveal_verify.nr → planetId = H(x,y) preimage and reveal/discovery constraints

• move_verify.nr → movement legality, decay/arrival, capture constraints

• perlin_fixed.nr → deterministic fixed-point perlin evaluation (no floats; explicit scaling + bounds)

• biomebase_verify.nr → planet-type predicates (foundry/rip classification gates)

• range_proofs.nr → bit/range constraints used throughout

• whitelist_verify.nr → included only if required by the v0.6 flow you target

DoD for each module

• Golden vectors pass

• Negative tests (bit flips / bounds violations) fail deterministically

• Fuzz parity over constrained domains passes

• Integrated contract action passes E2E tests

4.2 Parity harness (CI-gated)

We will build a dedicated parity harness with three tiers:

1. Golden vectors: curated inputs from known valid v0.6 scenarios

2. Negative tests: one-bit perturbations and boundary violations to ensure rejection behavior

3. Fuzz tests: constrained random generation within valid domains to detect drift

Any mismatch blocks merges. This is our primary “no-exploit drift” mechanism.

4.3 Leveraging existing Noir DF circuit work

We will actively evaluate any existing Noir Dark Forest circuit implementations that were previously funded for compatibility and license safety. If compatible, we integrate as audited dependencies; if not, we proceed clean-room. This is a schedule de-risker, not a dependency assumption.

5) Correctness under historical reads

Private execution will treat public state dependencies as assumptions, not guarantees. For any action that depends on owner, energy, silver, upgrade flags, or settlement cursors:

• Private proof includes the assumed values (or commitments to them) as witnesses

• Public apply re-checks those assumed values at chain head

• Conflicts trigger a revert (no inconsistent partial updates)

This ensures safety under concurrent moves/captures and prevents “stale-owner move” acceptance.

6) Mechanics implementation scope (MVP)

6.1 Player init

• Private: validates init constraints and creates minimal player state

• Public apply: registers minimal required participation state

6.2 Planet discovery / reveal

• Private: computes planetId = H(x,y) and validates worldgen predicates for a valid planet; applies range constraints

• Public apply: creates planet record if undiscovered and initializes public state

6.3 Movement, arrival, capture

• Private: validates move constraints; computes deterministic arrival tick and energy impact; enqueues apply

• Public apply:

  • settles up to K arrivals for destination

  • applies new move record

  • updates source energy/silver

  • applies capture at settlement time

6.4 Resources and upgrades

• deterministic accrual using lastUpdatedTick

• upgrades via explicit cost checks and packed flags

6.5 Foundries and artifacts

• Private: validates foundry classification (biomebase/perlin predicates), eligibility, deterministic artifact derivation

• Public apply: stores artifact ownership/state references

6.6 Spacetime rips

• Private: validates rip classification and artifact routing; produces eligibility for mint

• Public apply: records ripped artifact eligibility

6.7 Aztec-native NFT minting

• DarkForestGame proves eligibility in private and triggers mint in ArtifactNFT

• ArtifactNFT keeps a compact minted registry to prevent double-mint and support UI sync

• Mint authorization restricted to DarkForestGame

7) Frontend architecture and integration strategy

7.1 Strategy: adapter-first, minimal surface area

To reduce risk and preserve a “true Dark Forest” experience, we will mirror the v0.6 client architecture and implement an Aztec adapter layer that replaces the Ethereum contract interaction module with Aztec transaction flows:

• GameStateSource (Aztec) — reads public state (planets/moves/config) and updates the client store

• GameActions (Aztec) — builds proofs and sends private actions (discover, move, craft, rip, mint)

• local persistence (IndexedDB) for explored map and mined candidates

If license constraints prevent direct reuse of specific upstream UI modules under a permissive license, we will reimplement the same interaction surfaces with a minimal, compatible UI while preserving the adapter approach and state model.

7.2 Turn-time instrumentation (end-to-end)

We will instrument and log:

• witness build time

• proving time

• tx assembly time

• dispatch time

These metrics are recorded per action and aggregated in CI for regression detection.

8) Performance plan (<60s per “turn”)

We will treat the <60s requirement as a hard constraint and engineer the hot path around it.

8.1 Proof-time budgets

• Move/capture (hot path): target ≤45s proving time + ≤15s build/dispatch buffer

• Discovery/reveal: target ≤60s

• Artifact craft / rip actions: target ≤60s

• Mint: target ≤30s

8.2 Early performance gate

By the end of the “move/capture” milestone, we will have:

• proving-enabled benchmarks running

• move/capture under the 60s cap on the documented baseline machine

• constraint count profiling and hotspot identification for the move circuit path

8.3 Fallback if move path exceeds budget

If we breach budget, we will reduce hot-path constraints by:

• ensuring any perlin-heavy classification occurs only at discovery time (not move)

• caching discovery-validated planet attributes required for move legality into public planet state

• minimizing enqueued calls/output writes per action

• tightening bounded settlement K and amortizing settlement across interactions

Testing and Documentation Plan

1) Testing

A) Parity harness (Noir modules)

• golden vectors

• negative tests

• fuzz tests

• CI gating on mismatch

B) Contract unit tests

• apply function access control (#[only_self])

• stale assumption reverts

• bounded settlement invariants

• replay protection (moveId / minted flags / cursor monotonicity)

C) End-to-end integration tests

• init → discover → move/capture → craft → rip → mint

• race scenarios (stale state) and revert recovery

• proving-enabled performance test suite

2) Documentation

• local runbook (dev + proving-enabled benchmarking)

• deploy runbook (devnet)

• architecture doc (call graph, state schema, bounded settlement)

• parity harness guide (how to add vectors, how to debug drift)

• performance measurement guide (baseline machine spec, regression thresholds)

Milestones and Roadmap

Milestone 1 (Week 1): Toolchain + skeleton + first private→public state update

DoD:

• DarkForestGame + ArtifactNFT deployed

• one private action enqueues #[only_self] public apply and updates public state

• CI running unit tests + basic integration tx

Milestone 2 (Weeks 2–3): Parity harness + discovery/reveal playable loop

DoD:

• parity harness in CI

• discovery/reveal constraints integrated

• client can discover and render planets

• proving-enabled benchmark report for discovery flow

Milestone 3 (Weeks 3–6): Move/capture + bounded settlement + performance gate

DoD:

• move verifier parity integrated

• bounded settlement implemented and tested

• client has playable move/capture loop

• proving-enabled move/capture meets <60s target on baseline

Milestone 4 (Weeks 6–8): Resources/upgrades + foundries + artifacts

DoD:

• energy/silver accrual + upgrades live

• foundry classification + artifact creation integrated

• artifact inventory visible in client

Milestone 5 (Weeks 8–10): Spacetime rips + NFT minting + final integration polish

DoD:

• rip mechanics live

• NFT mint end-to-end from ripped artifacts

• full integration test suite passes

• documentation complete and reproducible

Stretch Goals (2–3)

1. Plugin hooks / extension points (documented, safe)

2. UX improvements without changing mechanics

3. Public developer guide: “Parity-gated Circom→Noir porting pattern for Aztec dApps”

Grant Amount Requested

$75,000

Grant Budget Rationale

• Abdulkareem Oyeneye (Project Lead): delivery planning, milestone gating, release coordination, documentation ownership

• Gospel Ifeadi (Smart Contract Engineer): Aztec contracts, state schema, bounded settlement, integration tests

• Musa Abdulkareem (ZK Engineer, Nethermind): constraint parity modules, fixed-point/perlin work, proof-time profiling, CI parity gating

• Bolaji Ahmad (Full Stack Engineer): client, state sync/cache, tx pipeline instrumentation, UX polish

Budget allocation:

• Contracts + ZK parity engineering: $45,000

• Frontend + integration: $22,000

• QA/CI/docs + performance harness: $8,000
  Total: $75,000

Licensing

All new code will be released under a permissive license (MIT or similar). If we evaluate existing Dark Forest-related code or prior circuit work, we will only reuse components that are explicitly compatible with permissive licensing; otherwise we implement clean-room equivalents to keep the deliverable permissive and maximally reusable.

Questions (blockers / clarifications)

1. Is there a preferred Aztec toolchain version range you want teams to pin to for maximum compatibility with the March 2026 showcase?

2. For “Aztec-native NFT minting,” is MVP satisfied by mint + ownership display inside the DF client, or is full transfer functionality expected in the initial delivery?

3. For the <60s turn requirement, do you want a specified baseline hardware class for measurement, or is a documented steady-state benchmark methodology acceptable?