token hold attestation

prizes/LP-0005.md

@@ -0,0 +1,72 @@
+# LP-0005: Private Token Balance Attestation
+
+**`Logos Circle: N/A`**
+
+## Overview
+
+Many on-chain access-control mechanisms — governance participation thresholds, protocol fee tiers, allowlist eligibility — require a user to prove they hold at least N tokens of a given type. On a transparent chain this is trivial: anyone can inspect the balance. On Logos, balances are private by default, which breaks the naive approach but enables a much better one: a user can prove they meet a threshold without revealing their exact balance or linking the proof to their account.
+
+This prize funds a reusable private balance attestation primitive for LEZ: a Risc0 circuit and on-chain verifier that lets any holder of a shielded token account prove `balance >= N` for an arbitrary threshold N, without disclosing the actual balance or the account's identity.
+
+## Motivation
+
+Logos has a token program ([LEZ](https://github.com/logos-blockchain/lssa/)) that already structures private account balances as commitments of the form `SHA256(npk || program_owner || balance || nonce || SHA256(data))`, committed into an on-chain Merkle tree. The sequencer exposes `get_proof_for_commitment`, which returns a Merkle membership proof for any private account.
+
+The missing piece is a circuit that takes a private account, its Merkle membership proof, and a public threshold N, and produces a succinct on-chain-verifiable proof that the account's balance satisfies `balance >= N` — without revealing `npk`, `balance`, or any other private field. This is a natural extension of the existing infrastructure and a prerequisite for privacy-preserving governance, tiered access, and token-gated features throughout the Logos ecosystem.
+
+A competitive prize is the right mechanism because the proving strategy, nullifier scheme (to prevent reuse of the same proof across contexts), and integration pattern with the existing commitment format admit multiple valid approaches.
+
+## Success Criteria
+
+- [ ] A shielded token account holder can generate a client-side proof that their balance meets a public threshold N. threshold N in under 30 seconds on a standard laptop
+- [ ] The proof is verifiable on-chain without revealing the account's nullifier public key, exact balance, or account identity.
+- [ ] The proof is bound to a specific context (e.g., a contract address or application ID) to prevent replay across different gates.
+- [ ] The circuit correctly targets the existing LEZ private account commitment format: `SHA256(npk || program_owner || balance || nonce || SHA256(data))`.
+- [ ] A reference integration is delivered: a working demo of a threshold-gated on-chain action (e.g., governance vote eligibility check or tiered access grant) on LEZ testnet.
+- [ ] Full documentation and a clean public repository are delivered.
+
+## Scope
+
+### In Scope
+
+- A Risc0 circuit proving `balance >= N` over the existing LEZ private account commitment format, with Merkle membership verification and context binding.
+- A LEZ on-chain verifier contract (Rust) that accepts and verifies the proof.
+- A client-side SDK or CLI for generating proofs from a shielded token account, consuming the sequencer's `get_proof_for_commitment` output.
+- A reference integration on LEZ testnet.
+- Documentation covering: circuit design, commitment format used, context-binding scheme, privacy guarantees and limits, and integration guide.
+
+### Out of Scope
+
+- Changes to the existing token program or its commitment format — the circuit must work with the format as-is.
+- Proving exact balance equality (only threshold proofs are required).
+- A polished consumer UI — a working demo is sufficient.
+- Ongoing maintenance or security audits beyond initial delivery.
+
+## Prize Structure
+
+- **Total Prize:** $TBD
+- **Next Planned Revision Date:** TBD
+
+## Eligibility
+
+Open to any individual or team. Submissions must be original work. Teams must hold the rights to all submitted code and agree to license it under MIT or Apache-2.0.
+
+## Submission Requirements
+
+- Public repository with all circuit code, LEZ verifier contract, and client-side tooling under MIT or Apache-2.0.
+- Verifier contract deployed on LEZ testnet with a verified contract address.
+- End-to-end demo (video or live link) showing proof generation from a shielded account and on-chain verification against a threshold.
+- Write-up covering: circuit design, how the existing commitment format is targeted, context-binding approach, privacy guarantees (including what is and is not hidden), security assumptions, known limitations, and integration instructions.
+- Proof generation time and on-chain verification gas cost benchmarks.
+
+## Evaluation Process
+
+Submissions are evaluated first-come-first-served against the success criteria. The first submission that satisfies all criteria wins.
+
+## Resources
+
+- [Logos Execution Zone repo](https://github.com/logos-blockchain/lssa/)
+- [LEZ token program](https://github.com/logos-blockchain/lssa/) — reference for the private account commitment format and `get_proof_for_commitment` API
+- [Risc0 proving system](https://dev.risczero.com/)
+- [Range proofs in ZK circuits](https://docs.circom.io/more-circuits/more-basic-circuits/#range-proof) — background on proving `balance >= N`
+- [zk-kit — Merkle tree primitives](https://github.com/privacy-scaling-explorations/zk-kit)