Technical note · 29 July 2026

Where the Merkle/Poseidon prototype stops

A boundary audit of the public Rust repository: implemented path, missing proof system, placeholder parameters, and the work required before stronger cryptographic claims.

Author: David AnderleReading time: 6 minutesRelated artifact: merkle-poseidon v0.1.0

The repository’s useful core is narrow: it demonstrates how field-element commitments can be placed in a Merkle tree and how a membership path can be generated and verified. The project becomes misleading only when that narrow result is compressed into a broader phrase such as “zero-knowledge balance proof.”

Implemented path

  1. Represent values and randomness as ark_bls12_381::Fr.
  2. Hash each pair through a Poseidon sponge interface.
  3. Use the outputs as Merkle leaves.
  4. Iteratively hash pairs to a root.
  5. Generate sibling paths and verify membership.

This is a legitimate prototype of a commitment-and-membership pipeline.

Why the threshold check is not zero knowledge

The example program still retains the original values, sums them natively in Rust, and compares the sum with a threshold. No circuit constrains the relationship between committed leaves and the threshold statement. No proof object demonstrates that the committed values satisfy the predicate. The check is therefore ordinary program logic, not a zero-knowledge proof.

Why placeholder Poseidon parameters matter

A sponge interface is not secure merely because it is named Poseidon. Round constants, the MDS matrix, field choice, width, capacity, rate, and security target all matter. The repository explicitly labels its manually entered constants as demonstration values. That warning must remain visible wherever the project is described.

Field elements are not balances

A field element wraps modulo the field order. A real private-balance statement needs a bounded integer interpretation and range constraints. Without them, “sum greater than threshold” may not correspond to the intended arithmetic domain.

Authorship is part of technical correctness

The initial implementation in the public history came from a collaborator. Later commits under my account revised a few source files and expanded the limitations. That distinction belongs in the case study because provenance is not a branding detail; it determines what a reader can infer about implementation ability and independent contribution.

Minimum credible next version

  • Define the exact statement to be proved.
  • Represent values as bounded integers with range checks.
  • Build an R1CS circuit linking commitments, Merkle membership, and the threshold predicate.
  • Use reviewed parameters and document their generation.
  • Add positive and negative tests, benchmarks, and a threat model.
  • Record file-level contributions and collaborator approval.