KOI Foundation

Client

The client builds technology for online games where votes can be cast and published within seconds. The project explored how cryptographic proofs could make the recorded voting dataset independently verifiable without exposing the entire underlying dataset.

The scope was deliberately narrow: prove properties of the committed data structure and demonstrate the research result in a working proof-of-concept. A Merkle proof does not, by itself, prove that a voter is human or that the source data was collected honestly.

Key Highlights

Challenge

The engineering problem was to make statements about a large, sparse voting dataset verifiable against a compact cryptographic commitment. The system needed proofs that could show whether a particular key/value entry is included in — or absent from — the committed tree, without giving the verifier the entire dataset.

• Separate concerns. Keep cryptographic integrity of committed data separate from broader anti-fraud judgments such as whether a voter is a bot or part of coordinated manipulation.
• Evaluate before building. Compare candidate constructions before implementation, since no reference solution existed to adapt directly.
• Scope the POC tightly. Keep the proof-of-concept small enough to demonstrate the core research without adding unrelated application architecture.
• Communicate honestly. Make the technical result understandable in a client/investor demo without overstating what the proof system establishes.

Solution

The final POC separates the cryptographic commitment/proof layer from the application-level evaluation logic built around the voting use case.

• Sparse Merkle Tree proof engine. Generates inclusion and non-inclusion proofs for entries in the committed tree.
• Root-based verification. A verifier can check a proof against an authentic root commitment without receiving the complete dataset.
• Application-level evaluation logic. Project-specific vote factors can be evaluated separately; the cryptographic proof verifies the committed data used by the logic rather than "honesty" as an undefined property.
• Minimal Rust API. Three endpoints and a compact codebase focused on the algorithmic core.
• Electron demo. Presents the verification flow and result visually so the research can be demonstrated without walking through the underlying mathematics.

Process

Most of the work was research and validation before coding.

1. Explore candidates. Worked through multiple candidate algorithms and reviewed the constructions with a mathematician.
2. Select the approach. Selected the Sparse Merkle Tree approach for inclusion/non-inclusion proofs over a sparse committed dataset.
3. Implement the core. Implemented the settled construction as a minimal Rust API rather than building a full production platform around it.
4. Build the demo. Built an Electron demo to show proof verification in a form suitable for stakeholder and investor presentations.

Result

• Implemented algorithmic core. The client received an implemented algorithmic core capable of generating and verifying the documented Sparse Merkle Tree proofs.
• Compact API surface. The proof-of-concept exposes the core through three API endpoints and a compact Rust implementation.
• Stakeholder-ready demo. The Electron demo gives the client a practical way to present the verification concept to non-technical stakeholders.
• Basis for productization. The POC provides a validated basis for further productization, threat modeling, security review, and performance testing if the concept moves toward production.