Update prize adoption criteria

prizes/LP-0001.md

@@ -23,7 +23,7 @@ A competitive prize is the right mechanism here because the problem is well-spec
 - [ ] The proof can be verified on LEZ without revealing the token ID or the holder's wallet address to the verifier.
 - [ ] The system is resistant to proof reuse across contexts — a nullifier or domain-separation mechanism prevents the same proof from being replayed in a different gating context.
 - [ ] A reference integration is delivered: a working demo of at least one token-gated action (e.g., allowlist registration or an on-chain vote) using the proof system.
-- [ ] At least 5 independent NFT collections are deployed on LEZ testnet with the proof system integrated, each by a distinct team or community outside the submitting team.
+- [ ] At least 5 independent NFT collections are deployed on LEZ testnet with the proof system integrated; the deployments must be reproducible and evidence must be provided.
 - [ ] Full documentation and a clean public repository are delivered.
 
 ### Usability
@@ -80,6 +80,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho
 - Public repository containing all circuit code, LEZ program code, and client-side tooling, licensed under MIT or Apache-2.0.
 - Deployment of the verifier program on LEZ testnet, with a verified program ID.
 - End-to-end demo video in which the builder narrates what they built and why, walks through the architecture and key implementation decisions, and demonstrates proof generation and on-chain verification for at least one token-gating use case. A silent screencast is not sufficient (see [demo requirements](../README.md#evaluation-policies)).
+- Reproducible deployment steps and evidence for at least 5 NFT collection deployments on LEZ testnet with the proof system integrated.
 - A write-up covering: cryptographic approach, proving system used, Merkle tree construction, nullifier/domain-separation scheme, security assumptions, known limitations, and integration instructions.
 - Gas cost benchmarks for on-chain verification.
 - GitHub issues open for any problem encountered with Logos technology.

prizes/LP-0002.md

@@ -25,7 +25,7 @@ A competitive prize is the right mechanism because the design space is large: ch
 - [ ] A completed execution is unlinkable to any individual member's shielded account.
 - [ ] Proof generation runs client-side on a standard laptop.
 - [ ] A reference integration is delivered: a working demo of a threshold-gated action (e.g., treasury transfer or parameter change) on LEZ testnet using shielded member accounts.
-- [ ] At least 5 distinct multisig instances are created on LEZ testnet by parties outside the submitting team, with at least one proposal submitted, approved by threshold, and executed in each.
+- [ ] At least 1 multisig instance is created on LEZ testnet, with at least one proposal submitted, approved by threshold, and executed; the deployment must be reproducible and evidence must be provided.
 - [ ] Full documentation and a clean public repository are delivered.
 
 ### Usability
@@ -84,6 +84,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho
 - Public repository with all circuit code, LEZ program code, and client-side tooling under MIT or Apache-2.0.
 - Verifier program deployed on LEZ testnet with a verified program ID.
 - End-to-end demo video in which the builder narrates what they built and why, walks through the architecture and key implementation decisions, and demonstrates M-of-N approval and execution using shielded member accounts. A silent screencast is not sufficient (see [demo requirements](../README.md#evaluation-policies)).
+- Reproducible deployment steps and evidence for at least 1 multisig instance on LEZ testnet, with at least one proposal submitted, approved by threshold, and executed.
 - Write-up covering: threshold proof scheme, nullifier design, LEZ account model compatibility (specifically how the nonce and `program_owner` constraints are handled), security assumptions, known limitations, and integration instructions.
 - Proof generation time and on-chain verification gas cost benchmarks.
 

prizes/LP-0003.md

@@ -27,7 +27,7 @@ Logos' shielded account model offers a richer design surface than standard EVM e
 - [ ] An on-chain observer cannot link a completed claim to any specific address in the eligibility set.
 - [ ] The submission documents its full privacy model: what on-chain observers learn, what the distributor learns, at which points in the claim flow identity information is revealed or withheld, and where trade-offs or residual leakage remain. Claims of privacy must be precise — "unlinkable" must be defined relative to a stated threat model.
 - [ ] A reference integration is delivered: a working demo of a private airdrop or allowlist gate on LEZ testnet.
-- [ ] At least 3 distinct distributions are deployed on LEZ testnet by parties outside the submitting team, with a combined total of at least 30 unique claims completed across them.
+- [ ] At least 2 distinct distributions are deployed on LEZ testnet, with a combined total of at least 20 unique claims completed across them; the distributions must be reproducible and evidence must be provided.
 - [ ] Full documentation and a clean public repository are delivered.
 
 ### Usability
@@ -85,6 +85,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho
 - Public repository with all circuit code, LEZ program code, and client-side tooling under MIT or Apache-2.0.
 - Program deployed on LEZ testnet with a verified program ID.
 - End-to-end demo video in which the builder narrates what they built and why, walks through the architecture and key implementation decisions, and demonstrates a private claim from a shielded account. A silent screencast is not sufficient (see [demo requirements](../README.md#evaluation-policies)).
+- Reproducible deployment steps and evidence for at least 2 distinct distributions on LEZ testnet, with a combined total of at least 20 unique claims completed across them.
 - Write-up covering: commitment scheme, claim-uniqueness mechanism, privacy model (what on-chain observers and the distributor learn at each stage, stated threat model, and any residual leakage or limitations), LEZ account model compatibility, security assumptions, known limitations, and integration instructions.
 - Proof generation time and on-chain verification compute unit benchmarks.
 - GitHub issues open for any problem encountered with Logos technology.

prizes/LP-0004.md

@@ -25,7 +25,7 @@ A competitive prize is the right mechanism because the design space is large: au
 - [ ] Losing bidders receive full refunds to their shielded accounts without the refund amount being linkable to their original bid.
 - [ ] At no point during or after the auction can a passive observer determine any losing bidder's maximum offer.
 - [ ] A reference integration is delivered: a working demo of a complete auction lifecycle (open → bid → close → winner determined → refunds issued) on LEZ testnet.
-- [ ] At least 5 complete auction cycles are run on LEZ testnet, each with a minimum of 3 distinct bidders, at least 3 of those auctions organised by parties outside the submitting team.
+- [ ] At least 5 complete auction cycles are run on LEZ testnet, each with a minimum of 3 distinct bidders; the cycles must be reproducible and evidence must be provided.
 - [ ] Full documentation and a clean public repository are delivered.
 
 ### Usability
@@ -85,6 +85,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho
 - Public repository with LEZ program code and client-side tooling under MIT or Apache-2.0.
 - Program deployed on LEZ testnet with a verified program ID.
 - End-to-end demo video in which the builder narrates what they built and why, walks through the architecture and key implementation decisions, and demonstrates a full auction lifecycle with at least three bidders using shielded accounts. A silent screencast is not sufficient (see [demo requirements](../README.md#evaluation-policies)).
+- Reproducible steps and evidence for at least 5 complete auction cycles on LEZ testnet, each with a minimum of 3 distinct bidders.
 - Write-up covering: auction format and rationale, how shielded balances are used for escrow, winner determination and refund mechanics, security assumptions (e.g. miner/sequencer front-running), known limitations, and integration instructions.
 - Gas cost benchmarks for bid submission, winner determination, and refund issuance.
 

prizes/LP-0005.md

@@ -31,7 +31,7 @@ A competitive prize is the right mechanism because the proving strategy, nullifi
 - [ ] The circuit correctly targets the existing LEZ private account commitment format: `SHA256(npk || program_owner || balance || nonce || SHA256(data))`.
 - [ ] **On-chain path**: A LEZ verifier program accepts and verifies the proof, gating at least one on-chain action.
 - [ ] **Off-chain path**: The proof can be transmitted over Logos Messaging and verified locally by a recipient, demonstrated by a token-gated access flow (e.g., admission to a chat group).
-- [ ] At least 3 distinct applications integrate the attestation primitive on LEZ testnet (e.g., a governance gate, a token-gated Logos Messaging group, and a third use case), with at least one built by a party outside the submitting team.
+- [ ] A standalone consumer integration demo is included in the submission repository. Any demonstrated, testable path that exercises the attestation primitive is acceptable (e.g., on-chain gating, off-chain verification via Logos Messaging, or another integration the submitter can run and verify).
 - [ ] Full documentation and a clean public repository are delivered.
 
 ### Usability
@@ -96,6 +96,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho
 - Public repository with all circuit code, LEZ verifier program, off-chain verifier library, and client-side tooling under MIT or Apache-2.0.
 - Verifier program deployed on LEZ testnet with a verified program ID.
 - End-to-end demo video in which the builder narrates what they built and why, walks through the architecture and key implementation decisions, and demonstrates both verification paths. The demo must cover the on-chain path (proof generation and on-chain verification against a threshold) and the off-chain path (proof transmitted over Logos Messaging and verified locally to gate access, e.g., chat group admission). A silent screencast is not sufficient (see [demo requirements](../README.md#evaluation-policies)).
+- Standalone consumer integration demo with instructions to run and test the integration.
 - Write-up covering: circuit design, commitment format targeting, context-binding approach, both verification paths, 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.
 

prizes/LP-0006.md

@@ -68,7 +68,7 @@ The following assumptions underpin the security and reliability of the atomic sw
 - [ ] **Maker/taker model**: The maker operates as a liquidity provider. The maker software allows configuration of supported trading pairs and prices. The maker advertises available pairs and prices over **Logos Delivery** (the Logos storage/data availability layer). Maker-taker negotiation and swap coordination messages are exchanged over **Logos Chat** (the Logos messaging layer).
 - [ ] **Maker pricing**: The maker software supports two pricing modes: (1) **local configuration** (static prices set via config file or CLI, useful for testing) and (2) **external price feed** (fetching prices from an external service, e.g., a REST API). The specific external integration is left to the developer, but the architecture must support pluggable price sources.
 - [ ] The **maker** is deployable as a **headless service** with all necessary functionality (pair/price configuration, external price feed, liquidity management, swap execution, monitoring) — no GUI required for operation.
-- [ ] At least 5 complete swaps are executed per chain on testnets, involving at least 3 distinct counterparty pairs outside the submitting team.
+- [ ] At least 5 complete swaps are executed per chain on testnets, involving at least 3 distinct counterparty pairs.
 
 ### Usability
 

prizes/LP-0008.md

@@ -98,7 +98,7 @@ Submissions are not required to implement all of these, but the default skills a
 - [ ] Agent-to-agent coordination is A2A-compatible: Agent Cards follow the A2A schema, task interactions follow the A2A task lifecycle, and the implementation is documented as an A2A transport binding over Logos Messaging.
 - [ ] Two or more agents can discover each other via Agent Cards, execute a task following the A2A lifecycle, and transfer LEZ payment autonomously, without owner intervention.
 - [ ] At least 3 of the illustrative use cases above are demonstrated end-to-end on LEZ testnet.
-- [ ] At least 5 agents are deployed on LEZ testnet by parties outside the submitting team, each demonstrating at least one skill autonomously.
+- [ ] Three separate agents are deployed on LEZ testnet — one per default skill category (Storage, Messaging, and Blockchain) — each with a demonstrated, reproducible deployment and evidence provided.
 - [ ] Full documentation — including the skill interface spec, deployment guide, and owner interaction guide — and a clean public repository are delivered.
 
 ### Usability
@@ -156,7 +156,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho
 - Public repository with the Logos Core module, CLI, and all default skill implementations under MIT or Apache-2.0.
 - Module loadable on LEZ testnet with a documented deployment procedure.
 - End-to-end demo video(s) for at least 3 of the illustrative use cases, in which the builder narrates what they built and why, walks through the architecture and key implementation decisions, and demonstrates the full flow. A silent screencast is not sufficient (see [demo requirements](../README.md#evaluation-policies)).
-- Evidence of at least 5 third-party agent deployments on LEZ testnet (e.g., linked public activity, attestations, or on-chain records).
+- Reproducible deployment steps and evidence for three separate agent deployments on LEZ testnet — one agent per default skill category (Storage, Messaging, and Blockchain).
 - Write-up covering: module architecture, skill interface design, spending threshold mechanism, agent-to-agent coordination protocol, security model (what the agent can and cannot do without owner approval), known limitations, and integration instructions.
 
 ## Evaluation Process