From 56a206d63955c9f1fe5486a2b10788be6d0e91b7 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Mon, 14 Sep 2026 15:50:37 +1000 Subject: [PATCH 01/15] LP-0001: rewrite as an NFT extension of LP-0021 with adoption criteria LP-0021 scoped NFTs out so the wallet could ship fungible-asset support quickly. Recast LP-0001 as the prize that fills that gap, following the same extension pattern LP-0022 uses: it builds on the LP-0021 feature set (wallet, Wallet Provider SDK, approval flow) rather than a specific codebase, so the LP-0021 winner, another team, or a fork can all bid. Leads with basic NFT features (own, transfer, collection-grouped display, SDK enumeration and transfer proposals); the private collection-membership proof becomes one criterion among several rather than the whole prize, surfaced through the SDK and a token-gating reference mini app. Adds an Adoption section mirroring LP-0022's structure, including the same-team-vs-fork inheritance rule, and moves the prize to the adoption-first table in README. Prize set at $5,000 / Medium. Co-Authored-By: Claude Opus 5 (1M context) --- README.md | 1 + prizes/LP-0001.md | 156 +++++++++++++++++++++++++++++++++------------- 2 files changed, 114 insertions(+), 43 deletions(-) diff --git a/README.md b/README.md index f88783e7..9e89f0db 100644 --- a/README.md +++ b/README.md @@ -30,6 +30,7 @@ Prizes are graded on a functionality gate **plus** adoption criteria (real third | File | Description | Size | Status | |------|-------------|------|--------| | [LP-0000](prizes/LP-0000.md) | Template — use this as the starting point for new prizes | — | — | +| [LP-0001](prizes/LP-0001.md) | NFT Wallet Support and Private Ownership Proof | Medium | Draft | | [LP-0018](prizes/LP-0018.md) | OpenStreetMap integration: decentralized map data distribution | Medium | Open | | [LP-0021](prizes/LP-0021.md) | LEZ Wallet and Provider SDK | X-Large | Draft | | [LP-0022](prizes/LP-0022.md) | Combined Blockchain and Zone Wallet | Large | Draft | diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index 6c2b819d..aca25a46 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -1,97 +1,141 @@ + + --- -dependencies: [] +dependencies: + - id: LP-0021 + reason: extends the LEZ wallet and Wallet Provider SDK feature set to non-fungible assets and private ownership proofs + - id: LP-0023 + reason: wallet approval flow requires the program registry to show verified source for called programs --- -# LP-0001: Private NFT Ownership Proof [DRAFT] +# LP-0001: NFT Wallet Support and Private Ownership Proof [DRAFT] -**`Status: draft - pending NFT Program readiness`** **`Logos Circle: N/A`** ## Overview -Token-gating is everywhere — allowlists, governance votes, exclusive channels — but today it requires revealing exactly which token you hold. This prize is for a ZK-based membership proof system that lets a user prove they own *some* NFT from a collection without disclosing *which one*. +This prize extends the LEZ wallet and Wallet Provider SDK from [LP-0021](LP-0021.md) to **non-fungible assets**: owning, transferring, and displaying NFTs from the token program, exposing them to third-party dApps through the Wallet Provider SDK, and adding a privacy-preserving way to prove collection membership: proving you hold *some* NFT from a collection without disclosing *which one*. -The result is a reusable primitive: a Logos Execution Zone (LEZ) contract and a client-side proving workflow that any dApp can integrate to offer privacy-preserving token-gated access. +LP-0021 deliberately left NFTs out of scope so a winning team could ship a fungible-asset wallet quickly. This prize fills that gap and turns it into a token-gating primitive that any Logos dApp can consume. ## Motivation -Current token-gating solutions force users to sign messages that expose their wallet address and the specific token they hold. This leaks on-chain identity, enables correlation attacks, and undermines the pseudonymity that many users rely on. A ZK membership proof — where the proof attests "I own a token in this collection" without revealing which one — is a natural fit for Logos' shielded execution model and closes this gap cleanly. +Token-gating is everywhere (allowlists, governance votes, exclusive channels), but on most chains it requires revealing exactly which token you hold. Users sign messages that expose their wallet address and the specific token, which leaks on-chain identity, enables correlation attacks, and undermines the pseudonymity many users rely on. + +Logos' shielded execution model closes that gap naturally, but only if a wallet actually exposes it. A proof primitive nobody can reach from a wallet does not get adopted, and NFT support that cannot prove anything privately is just a picture gallery. Shipping both together, on top of the wallet and SDK that LP-0021 established, is what makes private token-gating something a dApp developer can integrate in an afternoon rather than a research project. -A competitive prize is the right mechanism here because the problem is well-specified but the implementation space is large: circuit design, nullifier schemes, Merkle tree construction, and gas cost trade-offs all admit multiple valid approaches. Competition surfaces the best solution. +Submissions to this λPrize are welcome from the LP-0021 winning team, from a different team building a new codebase, or from a fork of a merged LP-0021 solution; submissions must be MIT or Apache-2.0 licensed either way (see [Eligibility](#eligibility)). ## Success Criteria ### Functionality -- [ ] A user holding any NFT in a given collection can generate a client-side ZK proof of ownership on a standard laptop. -- [ ] 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; the deployments must be reproducible and evidence must be provided. -- [ ] Full documentation and a clean public repository are delivered. +- [ ] **NFT ownership**: own, send, and receive non-fungible token-program assets on a LEZ zone, from both public and private accounts. +- [ ] **NFT display**: the wallet lists the NFTs held by each account, grouped by collection, showing at minimum the collection, the token identifier, and any metadata the token program exposes. Assets with missing or unresolvable metadata are shown as such rather than hidden or silently rendered as valid. +- [ ] **Collection view**: a user can see which collections an account holds assets in, and how many from each. +- [ ] **Wallet Provider SDK NFT APIs**: third-party dApps can enumerate an account's NFTs, query collection membership, and propose NFT transfers through the SDK, subject to the same approval flow as fungible transfers. +- [ ] **Private ownership proof**: a user holding any NFT in a given collection can generate a proof of collection membership that a verifier can check **without learning which token the user holds or which account holds it**. +- [ ] **On-chain verification**: the proof can be verified on LEZ, so a program can gate an action on collection membership. +- [ ] **Replay resistance**: the same proof cannot be reused across gating contexts. A proof accepted for one context must not be accepted for a different one. +- [ ] **Proof via the SDK**: a third-party dApp can request a membership proof through the Wallet Provider SDK, and the user is shown an approval prompt identifying the requesting dApp, the collection being proven, and what the proof discloses, before any proof is generated. +- [ ] **Token-gating mini app**: a reference application, built on the SDK, that gates an action on private collection membership, going through the full connect → account selection → approval → proof → on-chain verification flow. Each gated action carries a unique identifier for the given LP submission, so that activity can be attributed to the submission that produced it. It serves as the canonical integration example for third-party developers and is the tool used to produce the on-chain gated actions counted in the adoption criteria below. +- [ ] **Testnet 0.3**: the wallet operates end-to-end against the canonical Logos LEZ zone on Logos testnet 0.3. If the LP-0021 foundation this prize builds on has already moved to a later testnet, that target takes precedence. ### Usability -- [ ] Provide a module/SDK that can be used to build Logos modules for interacting with the program. -- [ ] Provide a Logos Basecamp app GUI with local build instructions, downloadable assets, and loadable in Logos app (Basecamp). -- [ ] Provide an IDL for the LEZ program, using the [SPEL framework](https://github.com/logos-co/spel). +- [ ] The wallet and Wallet Provider SDK continue to satisfy the LP-0021 criteria for fungible assets, multi-account management, and the approval flow; NFT support is additive, not a replacement. +- [ ] The Basecamp app GUI and CLI are extended to cover NFT holdings, NFT transfers, and membership-proof generation. +- [ ] The extended Logos Basecamp module (core and ui types) is published to a module catalog: a fork of [`logos-modules-release-base`](https://github.com/logos-co/logos-modules-release-base), publishing releases via [`logos-modules-release-action`](https://github.com/logos-co/logos-modules-release-action). The catalog's `logos-repo.json` URL must be included in the submission so evaluators can install the module through the package-manager UI / `lgpd`. +- [ ] Approval prompts for NFT transfers clearly identify the requesting dApp, the target account, the collection, and the specific asset leaving the account. Collection-wide approvals, if supported, must be distinguishable from single-asset approvals in the prompt, so a user does not grant a whole collection while believing they granted one token. +- [ ] Approval prompts for proof requests state what the proof reveals and what it does not, in terms a non-expert can act on. +- [ ] **Program source verification.** The approval prompt must show the user the program's source-verification status for the program being called. [LP-0023](LP-0023.md)'s program registry is the recommended source for this. +- [ ] **UX quality.** NFT browsing, transfer, and proof generation must be polished and usable by a non-expert: coherent navigation, comprehensible previews, and clear error/pending states. This is judged against overall impression rather than a checklist: evaluators will use the wallet as a normal user would. +- [ ] **Integration guide.** Documentation covers how a third-party dApp adds private token-gating: the SDK calls, the on-chain verification, and what a program author must do to gate on collection membership. ### Reliability -- [ ] The system handles proof generation failures gracefully and surfaces a clear error to the user. -- [ ] The verifier program returns deterministic, documented error codes for all invalid-proof scenarios. +- [ ] Proof generation failures surface a clear, actionable error to the user rather than an opaque failure or a silently unproven state. +- [ ] The on-chain verifier returns deterministic, documented outcomes for invalid-proof scenarios, so an integrating program can distinguish "not a member" from "malformed proof". +- [ ] A dApp cannot generate a membership proof, or enumerate a private account's NFTs, without an explicit user approval for that account. +- [ ] The privacy property holds against the verifier and against an observer of the chain: neither learns the specific token or the holding account from a valid proof. The submission must state its security assumptions and any trusted setup explicitly. +- [ ] The LP-0021 reliability criteria continue to hold: wallet state survives restarts, no mandatory external services, and any remote persistence uses Logos Storage with client-side encryption. ### Performance -- [ ] Document the compute unit (CU) cost of each on-chain operation on LEZ devnet/testnet. Note: LEZ's per-transaction compute budget may change during testnet. +- [ ] Proof generation completes on a standard laptop, without specialised hardware. Document the time taken and the machine it was measured on. +- [ ] Document the compute unit (CU) cost of on-chain verification on LEZ testnet. Note: LEZ's per-transaction compute budget may change during testnet. ### Supportability -- [ ] The program is deployed and tested on LEZ devnet/testnet. -- [ ] End-to-end integration tests run against a LEZ sequencer (standalone mode) and are included in CI. -- [ ] CI must be green on the default branch. -- [ ] A README documents end-to-end usage: deployment steps, program addresses, and step-by-step instructions for interacting with the program via CLI and Basecamp app. -- [ ] A reproducible end-to-end demo script is provided and works against a real local sequencer with `RISC0_DEV_MODE=0`. -- [ ] A recorded video demo of the end-to-end flow is included in the submission; the recording must show terminal output (including proof generation) to confirm `RISC0_DEV_MODE=0` was active. +- [ ] Deployed and tested against Logos testnet 0.3 (the Logos LEZ zone). +- [ ] Logos Basecamp modules are built with [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) (`mkLogosModule`) and can be installed on both Linux and MacOS desktop platforms. +- [ ] End-to-end integration tests run against a real sequencer (standalone mode) and are included in CI; CI is green on the default branch. +- [ ] README documents setup, NFT management, proof generation, and step-by-step usage via CLI and Basecamp app. +- [ ] A reproducible end-to-end demo script works against a real local sequencer, with proving enabled rather than a development/mock proving mode. +- [ ] Wallet Provider SDK documentation covers the token-gating mini app as a worked example of connect → account selection → approval → proof → verification. + +### Adoption + +> These metrics measure traction attributable to a given submission for this prize, incremental to whatever the underlying LP-0021 wallet already accrued. Re-citing LP-0021's numbers does not satisfy this section. +> +> **All of the following are required in addition to the FURPS criteria above.** We publish the dimensions we look at, but hitting a raw number is not by itself sufficient (see [Terms & Conditions](../TERMS.md) for the evaluation policy that applies to all prizes). Evaluators will inspect commit histories and the posting history of vouching accounts. Volume that is clearly manufactured (fresh accounts, purchased engagement) does not count, regardless of the headline number. +> +> **Forked submissions.** The criteria below are incremental to LP-0021's numbers only when the submitting entity is **the same team, continuing the same LP-0021 wallet/SDK codebase**. Any other case — a different team, or the same team shipping a rewritten wallet/SDK not descended from their own merged LP-0021 solution — does not inherit LP-0021's traction, and must clear the baseline wallet bar below through their own submission. + +- [ ] **Baseline wallet adoption (forked submissions only).** If the submitting team is the same team that won LP-0021 and this submission continues that codebase, this criterion is already satisfied by LP-0021's own numbers and does not need to be re-demonstrated. Otherwise: **50 on-chain testimonials** on the LEZ zone via the LP-0021 testimonial mini app, from **at least 50 distinct accounts**, same anti-Sybil standard as LP-0021. +- [ ] **5 NFT collections** deployed on LEZ testnet by parties independent of the submitting team, held and displayed correctly in the wallet. Collections deployed by the submitting team to demonstrate the feature do not count toward this number. +- [ ] **3 third-party developers**, independent of each other and of the submitting team, have each shipped a functional Logos Basecamp app (a **ui type** Logos module, per the module-catalog requirement above) that uses the NFT or membership-proof additions from this prize's SDK extension, not merely the LP-0021 fungible SDK. Apps that only use the SDK outside a Basecamp app do not count. Each app must be publicly hosted on a mainstream forge (GitHub, GitLab, Codeberg, etc.) with a clear, genuine commit history: development spread over time by a real contributor, not a single bulk import. +- [ ] **100 on-chain gated actions** performed through the token-gating mini app, each verifying a private membership proof on the official Logos zone, from **at least 100 distinct accounts**. Accounts with no prior unrelated testnet activity carry little weight. The official testnet zone is `https://testnet.lez.logos.co` (explorer: `https://explorer.testnet.lez.logos.co/`); the exact endpoint will be confirmed when this prize opens. +- [ ] **Sustained gating activity**: the 100 gated actions must be spread over **at least 2 months**, with **at least 20 in each of those months**. A single burst of activity does not qualify, however large. Each gated action carries the submission's unique identifier and is timestamped on-chain, so this is verified directly from chain data. +- [ ] **20 testimonials on Discord** and **20 on Twitter/X** specifically describing use of the NFT or private token-gating features. Testimonials should describe what the person actually did with them; account history will be checked. Sharing screenshots of the wallet in use is encouraged. ## Scope ### In Scope -- ZK circuit(s) implementing the membership proof over an NFT collection's ownership set, targeting the Risc0 proving stack. -- A LEZ verifier program (Rust) that accepts and verifies proofs on-chain. -- A client-side SDK or CLI tool for proof generation. -- A reference integration demonstrating at least one token-gating use case (allowlist, voting, or access control) on LEZ testnet. -- Documentation covering the cryptographic approach, any trusted setup requirements, and an integration guide. +- Extending the LP-0021 wallet to non-fungible token-program assets: ownership, transfer, display, and collection grouping, for public and private accounts. +- Extending the LP-0021 Wallet Provider SDK with NFT enumeration, collection queries, transfer proposals, and membership-proof requests. +- A membership-proof scheme over an NFT collection's ownership set, with client-side proof generation. +- A LEZ verifier that programs can call to gate an action on collection membership. +- A token-gating reference mini app built on the SDK. +- Extending the CLI and Basecamp app GUI to the above. +- Documentation covering the cryptographic approach, security assumptions, any trusted setup, and an integration guide. ### Out of Scope +- The base LEZ wallet, Wallet Provider SDK, and approval flow — covered by [LP-0021](LP-0021.md); this prize assumes that feature set exists and builds on it. +- The Logos blockchain wallet, staking, bridging, and multi-zone configuration — covered by [LP-0022](LP-0022.md). +- Designing or implementing the token program itself — the wallet integrates with the existing/reference implementation. +- NFT minting flows, marketplaces, listings, or royalties. - Multi-chain or cross-chain ownership proofs. -- A polished consumer-facing UI — a working demo is sufficient. -- Ongoing maintenance or security audits beyond initial delivery. +- Hardware wallet integration. +- Portfolio analytics, price feeds, or fiat on/off-ramps. ## Prize Structure -- **Total Prize:** $TBD +- **Total Prize:** $5,000 - **Effort:** Medium ## 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. +Open to any individual or team. A submission must build on the LP-0021 feature set — the wallet, Wallet Provider SDK, and approval flow — but need not reuse a merged LP-0021 codebase, and need not come from the team that won LP-0021. 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 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. +- Public repository with the wallet module, Wallet Provider SDK, CLI, token-gating mini app, LEZ verifier, and Basecamp app GUI under MIT or Apache-2.0. +- Deployment of the verifier on LEZ testnet, with a verified program ID. +- Narrated video walkthrough demonstrating: receiving and displaying NFTs across collections, an NFT transfer from a private account, and the token-gating mini app performing connect → account selection → approval → proof generation → on-chain verification via the SDK. The recording must show terminal output confirming that proving ran for real rather than in a development/mock mode. (A narrated demo is required for every prize: see [demo requirements](../README.md#evaluation-policies).) +- A write-up covering the proving approach, how collection membership is represented, the replay-resistance mechanism, security assumptions, and known limitations. +- Proof generation timings and on-chain verification cost benchmarks. +- Evidence for each adoption criterion: links to the 5 independent NFT collections, the 3 third-party SDK apps and their repositories, the wallet repository, the on-chain gated actions (with the submission identifier and per-month counts so the sustained-activity criterion can be verified), and the Discord and Twitter/X testimonials. +- FURPS self-assessment as part of the solution (see [solution template](../solutions/LP-0000.md)). - GitHub issues open for any problem encountered with Logos technology. ## Evaluation Process -Submissions are evaluated first-come-first-served against the success criteria. The first submission that satisfies all criteria wins. +Submissions are evaluated first-come-first-served against the success criteria. The first submission that meets all criteria wins. + +Because the adoption criteria require sustained activity over at least two months, a submission cannot qualify until that window has elapsed. Builders are encouraged to ship early and start accruing adoption while continuing to develop, rather than treating the build and the adoption push as sequential. Evaluators will independently clone the repository and run the demo script from a clean environment; the script must succeed without modification. Evaluators may also ask technical follow-up questions to verify authorship and understanding of the implementation. @@ -102,8 +146,34 @@ The following policies apply to all prizes (see [evaluation policies](../README. ## Resources -- [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone) +- [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/) +- [LEZ programs repo](https://github.com/logos-blockchain/lez-programs/) — includes the token program +- [LP-0021](LP-0021.md) — LEZ Wallet and Provider SDK (feature-set prerequisite) +- [LP-0022](LP-0022.md) — Combined Blockchain and Zone Wallet +- [LP-0013](LP-0013.md) — Token program improvements (authorities) +- [LP-0014](LP-0014.md) — Token program improvements (ATAs + wallet tooling) +- [LP-0023](LP-0023.md) — Program registry with verified builds for LEZ programs (bytecode-to-source). Recommended as the source-verification registry backing the approval-flow requirement above. ## Potential for Subsequent λ Prizes -TBD \ No newline at end of file +This prize covers the **first adoption tranche** for NFT support and private token-gating. A follow-up λPrize is expected with higher adoption thresholds, adapted to the phase the network is in at that time, and potentially extending private membership proofs across multiple zones once [LP-0022](LP-0022.md)'s multi-zone wallet exists. + +This prize targets Logos testnet 0.3. Should a future testnet version introduce breaking changes to the token program or the proving stack, a subsequent λ Prize may be opened to cover adaptation. + +--- + +**Note:** The Specification in this Prize describes an outcome that Logos intends to benefit the Logos ecosystem. It sets out criteria and certain requirements a Participant should fulfill in order to potentially be eligible to be awarded a Prize amount, and is not intended to be an instruction or to direct a Participant's initiative or approach. They are guided by existing approaches and implementations in other mature blockchain systems and their ecosystems, as well as by functional requirements particular to the Logos technology stack or perceived usefulness to such stack or the wider community building on it. + +Logos makes no representation as to the legal or regulatory treatment of this Specification or any implementation of it in any jurisdiction. + +Participants act independently, voluntarily and at their own initiative in connection with their Submissions and are solely responsible for: + +1. assessing the risks and implications of their Participation in the Program and of any Artefacts that form part of their Submission; +2. determining whether to obtain independent professional advice; +3. complying with all applicable laws to them and in connection with the Program, including, where relevant, any licensing, registration, sanctions or anti-money laundering obligations that may arise from operating any software-as-a-service or business. + +Artefacts developed by Participants in connection with the Program are published and maintained by Participants and not by Logos or its Affiliates. Logos and its Affiliates do not build, host, maintain, deploy, operate, use or control any Artefacts arising out of any Submission. + +Participants or other persons who choose to build upon, host, maintain, deploy, operate, use or publicly promote any Artefacts, do so at their own risk and as a principal and in their own name. Any such persons are further solely responsible for complying with any legal or regulatory requirements that apply to them with such use. Logos does not make any representation, provide any advice or assume any responsibility regarding the use of such Artefacts, or any determination of compliance with applicable law or regulation. + +For further details of the above and what terms and conditions apply to a Participant, please refer to the [λPrize Program – Terms & Conditions](../TERMS.md). From 289c9a1e291a5f42204882e37f3e9be022caf0ff Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 16 Sep 2026 16:40:40 +1000 Subject: [PATCH 02/15] LP-0001: legal feedback --- prizes/LP-0001.md | 56 +++++++++++++++++++++++------------------------ 1 file changed, 27 insertions(+), 29 deletions(-) diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index aca25a46..aee5301f 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -1,30 +1,22 @@ ---- -dependencies: - - id: LP-0021 - reason: extends the LEZ wallet and Wallet Provider SDK feature set to non-fungible assets and private ownership proofs - - id: LP-0023 - reason: wallet approval flow requires the program registry to show verified source for called programs ---- - # LP-0001: NFT Wallet Support and Private Ownership Proof [DRAFT] **`Logos Circle: N/A`** ## Overview -This prize extends the LEZ wallet and Wallet Provider SDK from [LP-0021](LP-0021.md) to **non-fungible assets**: owning, transferring, and displaying NFTs from the token program, exposing them to third-party dApps through the Wallet Provider SDK, and adding a privacy-preserving way to prove collection membership: proving you hold *some* NFT from a collection without disclosing *which one*. +This prize extends a LEZ wallet and Wallet Provider SDK that aligns with criteria from [LP-0021](LP-0021.md) to **non-fungible assets**: owning, transferring, and displaying NFTs from the token program, exposing them to third-party dApps through the Wallet Provider SDK, and adding a privacy-preserving way to prove collection membership: proving you hold *some* NFT from a collection without disclosing *which one*. -LP-0021 deliberately left NFTs out of scope so a winning team could ship a fungible-asset wallet quickly. This prize fills that gap and turns it into a token-gating primitive that any Logos dApp can consume. +LP-0021 deliberately left NFTs out of its criteria so a winning team could ship a fungible-asset wallet quickly. This prize sets out criteria that fill that gap and turn it into a token-gating primitive that any Logos dApp can consume. ## Motivation Token-gating is everywhere (allowlists, governance votes, exclusive channels), but on most chains it requires revealing exactly which token you hold. Users sign messages that expose their wallet address and the specific token, which leaks on-chain identity, enables correlation attacks, and undermines the pseudonymity many users rely on. -Logos' shielded execution model closes that gap naturally, but only if a wallet actually exposes it. A proof primitive nobody can reach from a wallet does not get adopted, and NFT support that cannot prove anything privately is just a picture gallery. Shipping both together, on top of the wallet and SDK that LP-0021 established, is what makes private token-gating something a dApp developer can integrate in an afternoon rather than a research project. +Logos' shielded execution model closes that gap naturally, but only if a wallet actually exposes it. A proof primitive nobody can reach from a wallet does not get adopted, and NFT support that cannot prove anything privately is just a picture gallery. Shipping both together, on top of a wallet and SDK matching the criteria LP-0021 established, is what makes private token-gating something a dApp developer can integrate in an afternoon rather than a research project. -Submissions to this λPrize are welcome from the LP-0021 winning team, from a different team building a new codebase, or from a fork of a merged LP-0021 solution; submissions must be MIT or Apache-2.0 licensed either way (see [Eligibility](#eligibility)). +Submissions to this λPrize are welcome from the LP-0021 winning team or from a different team building a new codebase or however a team may wish to approach it. Submissions must be MIT and Apache-2.0 licensed either way (see [Eligibility](#eligibility)). ## Success Criteria @@ -38,8 +30,8 @@ Submissions to this λPrize are welcome from the LP-0021 winning team, from a di - [ ] **On-chain verification**: the proof can be verified on LEZ, so a program can gate an action on collection membership. - [ ] **Replay resistance**: the same proof cannot be reused across gating contexts. A proof accepted for one context must not be accepted for a different one. - [ ] **Proof via the SDK**: a third-party dApp can request a membership proof through the Wallet Provider SDK, and the user is shown an approval prompt identifying the requesting dApp, the collection being proven, and what the proof discloses, before any proof is generated. -- [ ] **Token-gating mini app**: a reference application, built on the SDK, that gates an action on private collection membership, going through the full connect → account selection → approval → proof → on-chain verification flow. Each gated action carries a unique identifier for the given LP submission, so that activity can be attributed to the submission that produced it. It serves as the canonical integration example for third-party developers and is the tool used to produce the on-chain gated actions counted in the adoption criteria below. -- [ ] **Testnet 0.3**: the wallet operates end-to-end against the canonical Logos LEZ zone on Logos testnet 0.3. If the LP-0021 foundation this prize builds on has already moved to a later testnet, that target takes precedence. +- [ ] **Token-gating mini-app**: a reference application, built on the SDK, that gates an action on private collection membership, going through the full connect → account selection → approval → proof → on-chain verification flow. Each gated action carries a unique identifier for the given LP submission, so that activity can be attributed to the submission that produced it. It serves as the canonical integration example for third-party developers and is the tool used to produce the on-chain gated actions counted in the adoption criteria below. +- [ ] **Testnet 0.3**: the wallet operates end-to-end against the canonical Logos LEZ zone on Logos testnet 0.3. If the foundation this prize builds on has already moved to a later testnet, that target takes precedence. ### Usability @@ -48,7 +40,7 @@ Submissions to this λPrize are welcome from the LP-0021 winning team, from a di - [ ] The extended Logos Basecamp module (core and ui types) is published to a module catalog: a fork of [`logos-modules-release-base`](https://github.com/logos-co/logos-modules-release-base), publishing releases via [`logos-modules-release-action`](https://github.com/logos-co/logos-modules-release-action). The catalog's `logos-repo.json` URL must be included in the submission so evaluators can install the module through the package-manager UI / `lgpd`. - [ ] Approval prompts for NFT transfers clearly identify the requesting dApp, the target account, the collection, and the specific asset leaving the account. Collection-wide approvals, if supported, must be distinguishable from single-asset approvals in the prompt, so a user does not grant a whole collection while believing they granted one token. - [ ] Approval prompts for proof requests state what the proof reveals and what it does not, in terms a non-expert can act on. -- [ ] **Program source verification.** The approval prompt must show the user the program's source-verification status for the program being called. [LP-0023](LP-0023.md)'s program registry is the recommended source for this. +- [ ] **Program source verification.** The approval prompt must show the user the program's source-verification status for the program being called. A program registry that meets or is similar to the specifications of [LP-0023](LP-0023.md) will be suitable. - [ ] **UX quality.** NFT browsing, transfer, and proof generation must be polished and usable by a non-expert: coherent navigation, comprehensible previews, and clear error/pending states. This is judged against overall impression rather than a checklist: evaluators will use the wallet as a normal user would. - [ ] **Integration guide.** Documentation covers how a third-party dApp adds private token-gating: the SDK calls, the on-chain verification, and what a program author must do to gate on collection membership. @@ -72,7 +64,7 @@ Submissions to this λPrize are welcome from the LP-0021 winning team, from a di - [ ] End-to-end integration tests run against a real sequencer (standalone mode) and are included in CI; CI is green on the default branch. - [ ] README documents setup, NFT management, proof generation, and step-by-step usage via CLI and Basecamp app. - [ ] A reproducible end-to-end demo script works against a real local sequencer, with proving enabled rather than a development/mock proving mode. -- [ ] Wallet Provider SDK documentation covers the token-gating mini app as a worked example of connect → account selection → approval → proof → verification. +- [ ] Wallet Provider SDK documentation covers the token-gating mini-app as a worked example of connect → account selection → approval → proof → verification. ### Adoption @@ -82,10 +74,10 @@ Submissions to this λPrize are welcome from the LP-0021 winning team, from a di > > **Forked submissions.** The criteria below are incremental to LP-0021's numbers only when the submitting entity is **the same team, continuing the same LP-0021 wallet/SDK codebase**. Any other case — a different team, or the same team shipping a rewritten wallet/SDK not descended from their own merged LP-0021 solution — does not inherit LP-0021's traction, and must clear the baseline wallet bar below through their own submission. -- [ ] **Baseline wallet adoption (forked submissions only).** If the submitting team is the same team that won LP-0021 and this submission continues that codebase, this criterion is already satisfied by LP-0021's own numbers and does not need to be re-demonstrated. Otherwise: **50 on-chain testimonials** on the LEZ zone via the LP-0021 testimonial mini app, from **at least 50 distinct accounts**, same anti-Sybil standard as LP-0021. +- [ ] **Baseline wallet adoption (forked submissions only).** If the submitting team is the same team that won LP-0021 and this submission continues that codebase, this criterion is already satisfied by LP-0021's own numbers and does not need to be re-demonstrated. Otherwise: **50 on-chain testimonials** on the LEZ zone via the LP-0021 testimonial mini-app, from **at least 50 distinct accounts**, same anti-Sybil standard as LP-0021. - [ ] **5 NFT collections** deployed on LEZ testnet by parties independent of the submitting team, held and displayed correctly in the wallet. Collections deployed by the submitting team to demonstrate the feature do not count toward this number. - [ ] **3 third-party developers**, independent of each other and of the submitting team, have each shipped a functional Logos Basecamp app (a **ui type** Logos module, per the module-catalog requirement above) that uses the NFT or membership-proof additions from this prize's SDK extension, not merely the LP-0021 fungible SDK. Apps that only use the SDK outside a Basecamp app do not count. Each app must be publicly hosted on a mainstream forge (GitHub, GitLab, Codeberg, etc.) with a clear, genuine commit history: development spread over time by a real contributor, not a single bulk import. -- [ ] **100 on-chain gated actions** performed through the token-gating mini app, each verifying a private membership proof on the official Logos zone, from **at least 100 distinct accounts**. Accounts with no prior unrelated testnet activity carry little weight. The official testnet zone is `https://testnet.lez.logos.co` (explorer: `https://explorer.testnet.lez.logos.co/`); the exact endpoint will be confirmed when this prize opens. +- [ ] **100 on-chain gated actions** performed through the token-gating mini-app, each verifying a private membership proof on the official Logos zone, from **at least 100 distinct accounts**. Accounts with no prior unrelated testnet activity carry little weight. The official testnet zone is `https://testnet.lez.logos.co` (explorer: `https://explorer.testnet.lez.logos.co/`); the exact endpoint will be confirmed when this prize opens. - [ ] **Sustained gating activity**: the 100 gated actions must be spread over **at least 2 months**, with **at least 20 in each of those months**. A single burst of activity does not qualify, however large. Each gated action carries the submission's unique identifier and is timestamped on-chain, so this is verified directly from chain data. - [ ] **20 testimonials on Discord** and **20 on Twitter/X** specifically describing use of the NFT or private token-gating features. Testimonials should describe what the person actually did with them; account history will be checked. Sharing screenshots of the wallet in use is encouraged. @@ -93,17 +85,17 @@ Submissions to this λPrize are welcome from the LP-0021 winning team, from a di ### In Scope -- Extending the LP-0021 wallet to non-fungible token-program assets: ownership, transfer, display, and collection grouping, for public and private accounts. -- Extending the LP-0021 Wallet Provider SDK with NFT enumeration, collection queries, transfer proposals, and membership-proof requests. +- Extending a wallet module matching criteria in LP-0021 to non-fungible token-program assets: ownership, transfer, display, and collection grouping, for public and private accounts. +- Extending a Wallet Provider SDK matching the criteria in LP-0021 with NFT enumeration, collection queries, transfer proposals, and membership-proof requests. - A membership-proof scheme over an NFT collection's ownership set, with client-side proof generation. - A LEZ verifier that programs can call to gate an action on collection membership. -- A token-gating reference mini app built on the SDK. +- A token-gating reference mini-app built on the SDK. - Extending the CLI and Basecamp app GUI to the above. - Documentation covering the cryptographic approach, security assumptions, any trusted setup, and an integration guide. ### Out of Scope -- The base LEZ wallet, Wallet Provider SDK, and approval flow — covered by [LP-0021](LP-0021.md); this prize assumes that feature set exists and builds on it. +- The base LEZ wallet, Wallet Provider SDK, and approval flow — covered by the criteria in [LP-0021](LP-0021.md); this prize assumes a wallet meeting those criteria exists and builds on it. - The Logos blockchain wallet, staking, bridging, and multi-zone configuration — covered by [LP-0022](LP-0022.md). - Designing or implementing the token program itself — the wallet integrates with the existing/reference implementation. - NFT minting flows, marketplaces, listings, or royalties. @@ -118,13 +110,13 @@ Submissions to this λPrize are welcome from the LP-0021 winning team, from a di ## Eligibility -Open to any individual or team. A submission must build on the LP-0021 feature set — the wallet, Wallet Provider SDK, and approval flow — but need not reuse a merged LP-0021 codebase, and need not come from the team that won LP-0021. 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. +Open to any individual or team. A submission must build on a wallet, Wallet Provider SDK, and approval flow with criteria that match those set out in LP-0021. Teams who have provided a Submission to LP-0021 may build on their Submissions as part of the Submissions for LP-0001. Submissions must be original work. Teams must hold the rights to all submitted code and agree to license it under MIT and Apache-2.0. ## Submission Requirements -- Public repository with the wallet module, Wallet Provider SDK, CLI, token-gating mini app, LEZ verifier, and Basecamp app GUI under MIT or Apache-2.0. +- Public repository with the wallet module, Wallet Provider SDK, CLI, token-gating mini-app, LEZ verifier, and Basecamp app GUI under MIT and Apache-2.0. - Deployment of the verifier on LEZ testnet, with a verified program ID. -- Narrated video walkthrough demonstrating: receiving and displaying NFTs across collections, an NFT transfer from a private account, and the token-gating mini app performing connect → account selection → approval → proof generation → on-chain verification via the SDK. The recording must show terminal output confirming that proving ran for real rather than in a development/mock mode. (A narrated demo is required for every prize: see [demo requirements](../README.md#evaluation-policies).) +- Narrated video walkthrough demonstrating: receiving and displaying NFTs across collections, an NFT transfer from a private account, and the token-gating mini-app performing connect → account selection → approval → proof generation → on-chain verification via the SDK. The recording must show terminal output confirming that proving ran for real rather than in a development/mock mode. (A narrated demo is required for every prize: see [demo requirements](../README.md#evaluation-policies).) - A write-up covering the proving approach, how collection membership is represented, the replay-resistance mechanism, security assumptions, and known limitations. - Proof generation timings and on-chain verification cost benchmarks. - Evidence for each adoption criterion: links to the 5 independent NFT collections, the 3 third-party SDK apps and their repositories, the wallet repository, the on-chain gated actions (with the submission identifier and per-month counts so the sustained-activity criterion can be verified), and the Discord and Twitter/X testimonials. @@ -148,15 +140,17 @@ The following policies apply to all prizes (see [evaluation policies](../README. - [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/) - [LEZ programs repo](https://github.com/logos-blockchain/lez-programs/) — includes the token program -- [LP-0021](LP-0021.md) — LEZ Wallet and Provider SDK (feature-set prerequisite) +- [LP-0021](LP-0021.md) — LEZ Wallet and Provider SDK - [LP-0022](LP-0022.md) — Combined Blockchain and Zone Wallet - [LP-0013](LP-0013.md) — Token program improvements (authorities) - [LP-0014](LP-0014.md) — Token program improvements (ATAs + wallet tooling) -- [LP-0023](LP-0023.md) — Program registry with verified builds for LEZ programs (bytecode-to-source). Recommended as the source-verification registry backing the approval-flow requirement above. +- [LP-0023](LP-0023.md) — Program registry with verified builds for LEZ programs (bytecode-to-source). + +> The Resources referred to are for informational purposes only and are intended solely as guidance regarding tools or other artefacts that may be relevant to preparing a Submission for a Prize. The Resources may include, or may refer to, earlier published Prizes or Specifications, some of which may have received Submissions. Logos does not endorse or approve, and makes no representation regarding any Submission or referenced material. Ultimately, it is the Participant's responsibility to determine whether, and how, if at all, to use any Resource. ## Potential for Subsequent λ Prizes -This prize covers the **first adoption tranche** for NFT support and private token-gating. A follow-up λPrize is expected with higher adoption thresholds, adapted to the phase the network is in at that time, and potentially extending private membership proofs across multiple zones once [LP-0022](LP-0022.md)'s multi-zone wallet exists. +This prize covers the **first adoption tranche** for NFT support and private token-gating. A follow-up λPrize is expected with higher adoption thresholds, adapted to the phase the network is in at that time, and potentially extending private membership proofs across multiple zones once a wallet matching the Specifications of [LP-0022](LP-0022.md) exists. This prize targets Logos testnet 0.3. Should a future testnet version introduce breaking changes to the token program or the proving stack, a subsequent λ Prize may be opened to cover adaptation. @@ -164,7 +158,11 @@ This prize targets Logos testnet 0.3. Should a future testnet version introduce **Note:** The Specification in this Prize describes an outcome that Logos intends to benefit the Logos ecosystem. It sets out criteria and certain requirements a Participant should fulfill in order to potentially be eligible to be awarded a Prize amount, and is not intended to be an instruction or to direct a Participant's initiative or approach. They are guided by existing approaches and implementations in other mature blockchain systems and their ecosystems, as well as by functional requirements particular to the Logos technology stack or perceived usefulness to such stack or the wider community building on it. -Logos makes no representation as to the legal or regulatory treatment of this Specification or any implementation of it in any jurisdiction. +Prizes may contain adoption criteria which are intended to demonstrate real world-interest and the extent to which others are building on, testing, or experimenting with a submission. It may further indicate a submission's potential usefulness to the Logos technology stack and the community around that. + +A Prize may also refer to the criteria specified in a previous Prizes solely for the purposes of identifying criteria applicable to an Artefact or other component of a Submission for the current Prize. Such references do not require a Participant to use, extend, modify or otherwise rely on any previous code, implementation or Submission associated with a previous Prize. A Participant must develop and submit a Submission that satisfies the requirements of the current Prize, including any criteria from or identified by reference to the previous Prize. + +Logos does not endorse, approve any Submission and does not guarantee that they are safe, reliable, or fit for any particular purpose. Logos further makes representation as to the legal or regulatory treatment of this Specification or any implementation of it in any jurisdiction. Anyone interacting with Submissions should do so cautiously and at their own risk and should treat them as unverified code. Participants act independently, voluntarily and at their own initiative in connection with their Submissions and are solely responsible for: From cb7a065e91daf0d47248c9215aae97bea1aa03e5 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 17 Sep 2026 11:36:59 +1000 Subject: [PATCH 03/15] LP-0001: clarify baseline adoption waiver; avoid implying a codebase to build on State the baseline wallet adoption rule in one direction: waived for the LP-0021 winning team continuing that codebase, required of every other submission. The previous phrasing stated the rule twice, in inverted order. Reword the Motivation so it does not read as a recommendation to build on another team's codebase, and drop the Out of Scope bullet that repeated it. Co-Authored-By: Claude Opus 5 (1M context) --- prizes/LP-0001.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index aee5301f..799d88d5 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -14,7 +14,7 @@ LP-0021 deliberately left NFTs out of its criteria so a winning team could ship Token-gating is everywhere (allowlists, governance votes, exclusive channels), but on most chains it requires revealing exactly which token you hold. Users sign messages that expose their wallet address and the specific token, which leaks on-chain identity, enables correlation attacks, and undermines the pseudonymity many users rely on. -Logos' shielded execution model closes that gap naturally, but only if a wallet actually exposes it. A proof primitive nobody can reach from a wallet does not get adopted, and NFT support that cannot prove anything privately is just a picture gallery. Shipping both together, on top of a wallet and SDK matching the criteria LP-0021 established, is what makes private token-gating something a dApp developer can integrate in an afternoon rather than a research project. +Logos' shielded execution model closes that gap naturally, but only if a wallet actually exposes it. A proof primitive nobody can reach from a wallet does not get adopted, and NFT support that cannot prove anything privately is just a picture gallery. LP-0021 established the criteria for the wallet, Wallet Provider SDK, and approval flow these build on; this prize treats that as given rather than re-specifying it. Shipping both together is what makes private token-gating something a dApp developer can integrate in an afternoon rather than a research project. Submissions to this λPrize are welcome from the LP-0021 winning team or from a different team building a new codebase or however a team may wish to approach it. Submissions must be MIT and Apache-2.0 licensed either way (see [Eligibility](#eligibility)). @@ -72,9 +72,9 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a > > **All of the following are required in addition to the FURPS criteria above.** We publish the dimensions we look at, but hitting a raw number is not by itself sufficient (see [Terms & Conditions](../TERMS.md) for the evaluation policy that applies to all prizes). Evaluators will inspect commit histories and the posting history of vouching accounts. Volume that is clearly manufactured (fresh accounts, purchased engagement) does not count, regardless of the headline number. > -> **Forked submissions.** The criteria below are incremental to LP-0021's numbers only when the submitting entity is **the same team, continuing the same LP-0021 wallet/SDK codebase**. Any other case — a different team, or the same team shipping a rewritten wallet/SDK not descended from their own merged LP-0021 solution — does not inherit LP-0021's traction, and must clear the baseline wallet bar below through their own submission. +> **Who the baseline wallet criterion applies to.** A submission from the **team that won LP-0021, continuing that same wallet/SDK codebase**, has already demonstrated baseline wallet adoption: the baseline criterion below is **waived**. Every other submission **must meet it** through its own submission. That covers a different team, and the LP-0021 winning team shipping a wallet/SDK not descended from their own merged LP-0021 solution. All other criteria below apply to every submission. -- [ ] **Baseline wallet adoption (forked submissions only).** If the submitting team is the same team that won LP-0021 and this submission continues that codebase, this criterion is already satisfied by LP-0021's own numbers and does not need to be re-demonstrated. Otherwise: **50 on-chain testimonials** on the LEZ zone via the LP-0021 testimonial mini-app, from **at least 50 distinct accounts**, same anti-Sybil standard as LP-0021. +- [ ] **Baseline wallet adoption.** Waived for the LP-0021 winning team continuing that codebase (see above). Otherwise: **50 on-chain testimonials** on the LEZ zone via the LP-0021 testimonial mini-app, from **at least 50 distinct accounts**, same anti-Sybil standard as LP-0021. - [ ] **5 NFT collections** deployed on LEZ testnet by parties independent of the submitting team, held and displayed correctly in the wallet. Collections deployed by the submitting team to demonstrate the feature do not count toward this number. - [ ] **3 third-party developers**, independent of each other and of the submitting team, have each shipped a functional Logos Basecamp app (a **ui type** Logos module, per the module-catalog requirement above) that uses the NFT or membership-proof additions from this prize's SDK extension, not merely the LP-0021 fungible SDK. Apps that only use the SDK outside a Basecamp app do not count. Each app must be publicly hosted on a mainstream forge (GitHub, GitLab, Codeberg, etc.) with a clear, genuine commit history: development spread over time by a real contributor, not a single bulk import. - [ ] **100 on-chain gated actions** performed through the token-gating mini-app, each verifying a private membership proof on the official Logos zone, from **at least 100 distinct accounts**. Accounts with no prior unrelated testnet activity carry little weight. The official testnet zone is `https://testnet.lez.logos.co` (explorer: `https://explorer.testnet.lez.logos.co/`); the exact endpoint will be confirmed when this prize opens. @@ -95,7 +95,6 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a ### Out of Scope -- The base LEZ wallet, Wallet Provider SDK, and approval flow — covered by the criteria in [LP-0021](LP-0021.md); this prize assumes a wallet meeting those criteria exists and builds on it. - The Logos blockchain wallet, staking, bridging, and multi-zone configuration — covered by [LP-0022](LP-0022.md). - Designing or implementing the token program itself — the wallet integrates with the existing/reference implementation. - NFT minting flows, marketplaces, listings, or royalties. From d8742cebdf0068a218ef1566af36b0833f6cec5b Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 17 Sep 2026 12:11:24 +1000 Subject: [PATCH 04/15] LP-0001: reword to avoid implying an existing codebase Drop "continue to" and "Extending" phrasing that presumed a build carried over from LP-0021; state what a submission must do instead, reusing LP-0021's own wording where the criterion is the same. Also remove em dashes. Co-Authored-By: Claude Opus 5 (1M context) --- prizes/LP-0001.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index 799d88d5..8b97031f 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -35,9 +35,9 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a ### Usability -- [ ] The wallet and Wallet Provider SDK continue to satisfy the LP-0021 criteria for fungible assets, multi-account management, and the approval flow; NFT support is additive, not a replacement. -- [ ] The Basecamp app GUI and CLI are extended to cover NFT holdings, NFT transfers, and membership-proof generation. -- [ ] The extended Logos Basecamp module (core and ui types) is published to a module catalog: a fork of [`logos-modules-release-base`](https://github.com/logos-co/logos-modules-release-base), publishing releases via [`logos-modules-release-action`](https://github.com/logos-co/logos-modules-release-action). The catalog's `logos-repo.json` URL must be included in the submission so evaluators can install the module through the package-manager UI / `lgpd`. +- [ ] Provide a module/Wallet Provider SDK usable by other Logos modules and third-party dApps to query balances, request account access, and request transfers and smart contract interactions, covering non-fungible assets in addition to the functionality set out in [LP-0021](LP-0021.md). NFT support is additive, not a replacement. +- [ ] The Basecamp app GUI and CLI cover NFT holdings, NFT transfers, and membership-proof generation, in addition to the functionality set out in [LP-0021](LP-0021.md). +- [ ] Logos Basecamp modules (core and ui types) are published to a module catalog: a fork of [`logos-modules-release-base`](https://github.com/logos-co/logos-modules-release-base), publishing releases via [`logos-modules-release-action`](https://github.com/logos-co/logos-modules-release-action). The catalog's `logos-repo.json` URL must be included in the submission so evaluators can install the module through the package-manager UI / `lgpd`. - [ ] Approval prompts for NFT transfers clearly identify the requesting dApp, the target account, the collection, and the specific asset leaving the account. Collection-wide approvals, if supported, must be distinguishable from single-asset approvals in the prompt, so a user does not grant a whole collection while believing they granted one token. - [ ] Approval prompts for proof requests state what the proof reveals and what it does not, in terms a non-expert can act on. - [ ] **Program source verification.** The approval prompt must show the user the program's source-verification status for the program being called. A program registry that meets or is similar to the specifications of [LP-0023](LP-0023.md) will be suitable. @@ -50,7 +50,7 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a - [ ] The on-chain verifier returns deterministic, documented outcomes for invalid-proof scenarios, so an integrating program can distinguish "not a member" from "malformed proof". - [ ] A dApp cannot generate a membership proof, or enumerate a private account's NFTs, without an explicit user approval for that account. - [ ] The privacy property holds against the verifier and against an observer of the chain: neither learns the specific token or the holding account from a valid proof. The submission must state its security assumptions and any trusted setup explicitly. -- [ ] The LP-0021 reliability criteria continue to hold: wallet state survives restarts, no mandatory external services, and any remote persistence uses Logos Storage with client-side encryption. +- [ ] The reliability criteria set out in [LP-0021](LP-0021.md) are met: wallet state survives restarts, no mandatory external services, and any remote persistence uses Logos Storage with client-side encryption. ### Performance @@ -85,18 +85,18 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a ### In Scope -- Extending a wallet module matching criteria in LP-0021 to non-fungible token-program assets: ownership, transfer, display, and collection grouping, for public and private accounts. -- Extending a Wallet Provider SDK matching the criteria in LP-0021 with NFT enumeration, collection queries, transfer proposals, and membership-proof requests. +- A wallet module matching the criteria in LP-0021, covering non-fungible token-program assets: ownership, transfer, display, and collection grouping, for public and private accounts. +- A Wallet Provider SDK matching the criteria in LP-0021, covering NFT enumeration, collection queries, transfer proposals, and membership-proof requests. - A membership-proof scheme over an NFT collection's ownership set, with client-side proof generation. - A LEZ verifier that programs can call to gate an action on collection membership. - A token-gating reference mini-app built on the SDK. -- Extending the CLI and Basecamp app GUI to the above. +- A CLI and Basecamp app GUI covering the above. - Documentation covering the cryptographic approach, security assumptions, any trusted setup, and an integration guide. ### Out of Scope -- The Logos blockchain wallet, staking, bridging, and multi-zone configuration — covered by [LP-0022](LP-0022.md). -- Designing or implementing the token program itself — the wallet integrates with the existing/reference implementation. +- The Logos blockchain wallet, staking, bridging, and multi-zone configuration, covered by [LP-0022](LP-0022.md). +- Designing or implementing the token program itself. The wallet integrates with the existing/reference implementation. - NFT minting flows, marketplaces, listings, or royalties. - Multi-chain or cross-chain ownership proofs. - Hardware wallet integration. @@ -138,12 +138,12 @@ The following policies apply to all prizes (see [evaluation policies](../README. ## Resources - [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/) -- [LEZ programs repo](https://github.com/logos-blockchain/lez-programs/) — includes the token program -- [LP-0021](LP-0021.md) — LEZ Wallet and Provider SDK -- [LP-0022](LP-0022.md) — Combined Blockchain and Zone Wallet -- [LP-0013](LP-0013.md) — Token program improvements (authorities) -- [LP-0014](LP-0014.md) — Token program improvements (ATAs + wallet tooling) -- [LP-0023](LP-0023.md) — Program registry with verified builds for LEZ programs (bytecode-to-source). +- [LEZ programs repo](https://github.com/logos-blockchain/lez-programs/): includes the token program +- [LP-0021](LP-0021.md): LEZ Wallet and Provider SDK +- [LP-0022](LP-0022.md): Combined Blockchain and Zone Wallet +- [LP-0013](LP-0013.md): Token program improvements (authorities) +- [LP-0014](LP-0014.md): Token program improvements (ATAs + wallet tooling) +- [LP-0023](LP-0023.md): Program registry with verified builds for LEZ programs (bytecode-to-source). > The Resources referred to are for informational purposes only and are intended solely as guidance regarding tools or other artefacts that may be relevant to preparing a Submission for a Prize. The Resources may include, or may refer to, earlier published Prizes or Specifications, some of which may have received Submissions. Logos does not endorse or approve, and makes no representation regarding any Submission or referenced material. Ultimately, it is the Participant's responsibility to determine whether, and how, if at all, to use any Resource. From 9fd555feaabf5d4e30fb5b73eb56cc6bd32a0acc Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 17 Sep 2026 12:48:23 +1000 Subject: [PATCH 05/15] LP-0001: drop "extends" from the Overview "This prize extends a LEZ wallet..." reads as modifying an existing build. State what the prize is for instead, matching the "matching the criteria in LP-0021, covering X" construction used in Scope. Co-Authored-By: Claude Opus 5 (1M context) --- prizes/LP-0001.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index 8b97031f..06be09dd 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -6,7 +6,7 @@ ## Overview -This prize extends a LEZ wallet and Wallet Provider SDK that aligns with criteria from [LP-0021](LP-0021.md) to **non-fungible assets**: owning, transferring, and displaying NFTs from the token program, exposing them to third-party dApps through the Wallet Provider SDK, and adding a privacy-preserving way to prove collection membership: proving you hold *some* NFT from a collection without disclosing *which one*. +This prize is for a LEZ wallet and Wallet Provider SDK matching the criteria in [LP-0021](LP-0021.md), covering **non-fungible assets**: owning, transferring, and displaying NFTs from the token program, exposing them to third-party dApps through the Wallet Provider SDK, and a privacy-preserving way to prove collection membership: proving you hold *some* NFT from a collection without disclosing *which one*. LP-0021 deliberately left NFTs out of its criteria so a winning team could ship a fungible-asset wallet quickly. This prize sets out criteria that fill that gap and turn it into a token-gating primitive that any Logos dApp can consume. @@ -76,7 +76,7 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a - [ ] **Baseline wallet adoption.** Waived for the LP-0021 winning team continuing that codebase (see above). Otherwise: **50 on-chain testimonials** on the LEZ zone via the LP-0021 testimonial mini-app, from **at least 50 distinct accounts**, same anti-Sybil standard as LP-0021. - [ ] **5 NFT collections** deployed on LEZ testnet by parties independent of the submitting team, held and displayed correctly in the wallet. Collections deployed by the submitting team to demonstrate the feature do not count toward this number. -- [ ] **3 third-party developers**, independent of each other and of the submitting team, have each shipped a functional Logos Basecamp app (a **ui type** Logos module, per the module-catalog requirement above) that uses the NFT or membership-proof additions from this prize's SDK extension, not merely the LP-0021 fungible SDK. Apps that only use the SDK outside a Basecamp app do not count. Each app must be publicly hosted on a mainstream forge (GitHub, GitLab, Codeberg, etc.) with a clear, genuine commit history: development spread over time by a real contributor, not a single bulk import. +- [ ] **3 third-party developers**, independent of each other and of the submitting team, have each shipped a functional Logos Basecamp app (a **ui type** Logos module, per the module-catalog requirement above) that uses the NFT or membership-proof capabilities from this prize's SDK, not merely the fungible-asset SDK set out in LP-0021. Apps that only use the SDK outside a Basecamp app do not count. Each app must be publicly hosted on a mainstream forge (GitHub, GitLab, Codeberg, etc.) with a clear, genuine commit history: development spread over time by a real contributor, not a single bulk import. - [ ] **100 on-chain gated actions** performed through the token-gating mini-app, each verifying a private membership proof on the official Logos zone, from **at least 100 distinct accounts**. Accounts with no prior unrelated testnet activity carry little weight. The official testnet zone is `https://testnet.lez.logos.co` (explorer: `https://explorer.testnet.lez.logos.co/`); the exact endpoint will be confirmed when this prize opens. - [ ] **Sustained gating activity**: the 100 gated actions must be spread over **at least 2 months**, with **at least 20 in each of those months**. A single burst of activity does not qualify, however large. Each gated action carries the submission's unique identifier and is timestamped on-chain, so this is verified directly from chain data. - [ ] **20 testimonials on Discord** and **20 on Twitter/X** specifically describing use of the NFT or private token-gating features. Testimonials should describe what the person actually did with them; account history will be checked. Sharing screenshots of the wallet in use is encouraged. From ac5b1417daf36c017ac258a9acca3bf754e5a6e3 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 17 Sep 2026 12:53:32 +1000 Subject: [PATCH 06/15] LP-0001: separate proof requests from account access Nothing stopped a wallet from requiring account access before producing a membership proof, which would defeat the privacy the proof provides. Make proof requests their own SDK capability: a dApp granted only a proof request learns no address, balances, holdings, or the proving token, and a wallet may not demand account access to produce a proof. Require the proof-request prompt to be visibly distinct from an account-access prompt and approved separately, so a user cannot inadvertently share an account address while sharing proof of ownership, and require granted capabilities to be individually visible and revocable. Drop "account selection" from the token-gating flow throughout, since that flow must now work without it. Co-Authored-By: Claude Opus 5 (1M context) --- prizes/LP-0001.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index 06be09dd..07bb4182 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -30,7 +30,8 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a - [ ] **On-chain verification**: the proof can be verified on LEZ, so a program can gate an action on collection membership. - [ ] **Replay resistance**: the same proof cannot be reused across gating contexts. A proof accepted for one context must not be accepted for a different one. - [ ] **Proof via the SDK**: a third-party dApp can request a membership proof through the Wallet Provider SDK, and the user is shown an approval prompt identifying the requesting dApp, the collection being proven, and what the proof discloses, before any proof is generated. -- [ ] **Token-gating mini-app**: a reference application, built on the SDK, that gates an action on private collection membership, going through the full connect → account selection → approval → proof → on-chain verification flow. Each gated action carries a unique identifier for the given LP submission, so that activity can be attributed to the submission that produced it. It serves as the canonical integration example for third-party developers and is the tool used to produce the on-chain gated actions counted in the adoption criteria below. +- [ ] **Proof requests stand alone**: requesting a membership proof is its own SDK capability, independent of account access. A dApp that has been granted only a proof request must not thereby learn the account address, the account's balances, its NFT holdings, or the specific token proving membership, and must not be able to enumerate accounts or propose transactions. A wallet must not require the user to grant account access in order to produce a proof. +- [ ] **Token-gating mini-app**: a reference application, built on the SDK, that gates an action on private collection membership, going through the full connect → approval → proof → on-chain verification flow without requesting account access. Each gated action carries a unique identifier for the given LP submission, so that activity can be attributed to the submission that produced it. It serves as the canonical integration example for third-party developers and is the tool used to produce the on-chain gated actions counted in the adoption criteria below. - [ ] **Testnet 0.3**: the wallet operates end-to-end against the canonical Logos LEZ zone on Logos testnet 0.3. If the foundation this prize builds on has already moved to a later testnet, that target takes precedence. ### Usability @@ -39,17 +40,18 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a - [ ] The Basecamp app GUI and CLI cover NFT holdings, NFT transfers, and membership-proof generation, in addition to the functionality set out in [LP-0021](LP-0021.md). - [ ] Logos Basecamp modules (core and ui types) are published to a module catalog: a fork of [`logos-modules-release-base`](https://github.com/logos-co/logos-modules-release-base), publishing releases via [`logos-modules-release-action`](https://github.com/logos-co/logos-modules-release-action). The catalog's `logos-repo.json` URL must be included in the submission so evaluators can install the module through the package-manager UI / `lgpd`. - [ ] Approval prompts for NFT transfers clearly identify the requesting dApp, the target account, the collection, and the specific asset leaving the account. Collection-wide approvals, if supported, must be distinguishable from single-asset approvals in the prompt, so a user does not grant a whole collection while believing they granted one token. -- [ ] Approval prompts for proof requests state what the proof reveals and what it does not, in terms a non-expert can act on. +- [ ] Approval prompts for proof requests state what the proof reveals and what it does not, in terms a non-expert can act on. A proof-request prompt must be visibly distinct from an account-access prompt, and must not grant account access as a side effect of approving a proof: where a dApp asks for both, the user can approve the proof and decline the account access, and each is approved separately rather than as one bundled permission. +- [ ] **Permissions are legible and revocable.** The user can see, per dApp, which capabilities have been granted (proof requests, account access, NFT enumeration, transaction proposals) and revoke any of them individually. A granted capability must be identifiable by what it discloses, not only by an API name. - [ ] **Program source verification.** The approval prompt must show the user the program's source-verification status for the program being called. A program registry that meets or is similar to the specifications of [LP-0023](LP-0023.md) will be suitable. - [ ] **UX quality.** NFT browsing, transfer, and proof generation must be polished and usable by a non-expert: coherent navigation, comprehensible previews, and clear error/pending states. This is judged against overall impression rather than a checklist: evaluators will use the wallet as a normal user would. -- [ ] **Integration guide.** Documentation covers how a third-party dApp adds private token-gating: the SDK calls, the on-chain verification, and what a program author must do to gate on collection membership. +- [ ] **Integration guide.** Documentation covers how a third-party dApp adds private token-gating: the SDK calls, the on-chain verification, what a program author must do to gate on collection membership, and how to request a proof without requesting account access. ### Reliability - [ ] Proof generation failures surface a clear, actionable error to the user rather than an opaque failure or a silently unproven state. - [ ] The on-chain verifier returns deterministic, documented outcomes for invalid-proof scenarios, so an integrating program can distinguish "not a member" from "malformed proof". -- [ ] A dApp cannot generate a membership proof, or enumerate a private account's NFTs, without an explicit user approval for that account. -- [ ] The privacy property holds against the verifier and against an observer of the chain: neither learns the specific token or the holding account from a valid proof. The submission must state its security assumptions and any trusted setup explicitly. +- [ ] A dApp cannot generate a membership proof without an explicit user approval for that request, and cannot enumerate a private account's NFTs without an explicit user approval for that account. +- [ ] The privacy property holds against the verifier, against an observer of the chain, and against the requesting dApp: none learns the specific token or the holding account from a valid proof. The submission must state its security assumptions and any trusted setup explicitly. - [ ] The reliability criteria set out in [LP-0021](LP-0021.md) are met: wallet state survives restarts, no mandatory external services, and any remote persistence uses Logos Storage with client-side encryption. ### Performance @@ -64,7 +66,7 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a - [ ] End-to-end integration tests run against a real sequencer (standalone mode) and are included in CI; CI is green on the default branch. - [ ] README documents setup, NFT management, proof generation, and step-by-step usage via CLI and Basecamp app. - [ ] A reproducible end-to-end demo script works against a real local sequencer, with proving enabled rather than a development/mock proving mode. -- [ ] Wallet Provider SDK documentation covers the token-gating mini-app as a worked example of connect → account selection → approval → proof → verification. +- [ ] Wallet Provider SDK documentation covers the token-gating mini-app as a worked example of connect → approval → proof → verification, and documents which capability each SDK call requires and what it discloses. ### Adoption @@ -115,7 +117,7 @@ Open to any individual or team. A submission must build on a wallet, Wallet Prov - Public repository with the wallet module, Wallet Provider SDK, CLI, token-gating mini-app, LEZ verifier, and Basecamp app GUI under MIT and Apache-2.0. - Deployment of the verifier on LEZ testnet, with a verified program ID. -- Narrated video walkthrough demonstrating: receiving and displaying NFTs across collections, an NFT transfer from a private account, and the token-gating mini-app performing connect → account selection → approval → proof generation → on-chain verification via the SDK. The recording must show terminal output confirming that proving ran for real rather than in a development/mock mode. (A narrated demo is required for every prize: see [demo requirements](../README.md#evaluation-policies).) +- Narrated video walkthrough demonstrating: receiving and displaying NFTs across collections, an NFT transfer from a private account, and the token-gating mini-app performing connect → approval → proof generation → on-chain verification via the SDK without the user granting account access, including the approval prompt as the user sees it. The recording must show terminal output confirming that proving ran for real rather than in a development/mock mode. (A narrated demo is required for every prize: see [demo requirements](../README.md#evaluation-policies).) - A write-up covering the proving approach, how collection membership is represented, the replay-resistance mechanism, security assumptions, and known limitations. - Proof generation timings and on-chain verification cost benchmarks. - Evidence for each adoption criterion: links to the 5 independent NFT collections, the 3 third-party SDK apps and their repositories, the wallet repository, the on-chain gated actions (with the submission identifier and per-month counts so the sustained-activity criterion can be verified), and the Discord and Twitter/X testimonials. From 9b95ee48384ed0203947a3cda3c7287763ba250a Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 17 Sep 2026 12:57:38 +1000 Subject: [PATCH 07/15] LP-0001: media storage, disableable fetching, criteria as a minimum NFT metadata and media are the one case where a wallet genuinely wants a remote resource, which LP-0021's generic external-services rule does not cover. Require any non-Logos-Storage media fetching to be disclosed, disableable, and non-leaking of which account holds an asset, with the wallet still usable when it is off. Require upload and download of image-sized metadata and media via Logos Storage. State that the criteria are a minimum: submissions may go further wherever a team judges it necessary for adoption, and Out of Scope means not required rather than forbidden. Co-Authored-By: Claude Opus 5 (1M context) --- prizes/LP-0001.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index 07bb4182..2a241fe3 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -20,6 +20,8 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a ## Success Criteria +> The criteria below are a **minimum**, not a specification of the finished product. A submission is welcome to go beyond them wherever a team judges it necessary to win adoption: further features, a different structure, or a broader scope than this prize describes. Additional work neither substitutes for the criteria below nor counts against a submission. The [Adoption](#adoption) criteria are what the prize ultimately turns on, and teams are the better judge of what real users will need. + ### Functionality - [ ] **NFT ownership**: own, send, and receive non-fungible token-program assets on a LEZ zone, from both public and private accounts. @@ -53,6 +55,8 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a - [ ] A dApp cannot generate a membership proof without an explicit user approval for that request, and cannot enumerate a private account's NFTs without an explicit user approval for that account. - [ ] The privacy property holds against the verifier, against an observer of the chain, and against the requesting dApp: none learns the specific token or the holding account from a valid proof. The submission must state its security assumptions and any trusted setup explicitly. - [ ] The reliability criteria set out in [LP-0021](LP-0021.md) are met: wallet state survives restarts, no mandatory external services, and any remote persistence uses Logos Storage with client-side encryption. +- [ ] **Media fetching is optional and disableable.** NFT metadata and media (images, video, audio) often live off-chain. If the wallet fetches them from any source other than Logos Storage or the user's configured LEZ node, that fetching must be disclosed, must be disableable by the user, and the wallet must remain fully functional with it disabled, listing the affected assets by collection and token identifier rather than failing or hiding them. Fetching must not leak which account holds an asset to the host serving it: the user is told what a fetch discloses, and third-party media hosts are never contacted for a private account without the user turning it on. +- [ ] **Large metadata and media on Logos Storage.** The wallet can upload and download NFT metadata and media of a size typical for image assets to and from **Logos Storage**, so a collection can be published and displayed without depending on a centralised host. Document any size limits observed and how the wallet behaves when an asset exceeds them. ### Performance @@ -64,7 +68,7 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a - [ ] Deployed and tested against Logos testnet 0.3 (the Logos LEZ zone). - [ ] Logos Basecamp modules are built with [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) (`mkLogosModule`) and can be installed on both Linux and MacOS desktop platforms. - [ ] End-to-end integration tests run against a real sequencer (standalone mode) and are included in CI; CI is green on the default branch. -- [ ] README documents setup, NFT management, proof generation, and step-by-step usage via CLI and Basecamp app. +- [ ] README documents setup, NFT management, proof generation, media storage and any external fetching the wallet performs, and step-by-step usage via CLI and Basecamp app. - [ ] A reproducible end-to-end demo script works against a real local sequencer, with proving enabled rather than a development/mock proving mode. - [ ] Wallet Provider SDK documentation covers the token-gating mini-app as a worked example of connect → approval → proof → verification, and documents which capability each SDK call requires and what it discloses. @@ -89,6 +93,7 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a - A wallet module matching the criteria in LP-0021, covering non-fungible token-program assets: ownership, transfer, display, and collection grouping, for public and private accounts. - A Wallet Provider SDK matching the criteria in LP-0021, covering NFT enumeration, collection queries, transfer proposals, and membership-proof requests. +- Upload and download of NFT metadata and media via Logos Storage, with any other media fetching disclosed and disableable. - A membership-proof scheme over an NFT collection's ownership set, with client-side proof generation. - A LEZ verifier that programs can call to gate an action on collection membership. - A token-gating reference mini-app built on the SDK. @@ -97,6 +102,8 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a ### Out of Scope +> Not evaluated and not required, rather than forbidden. A submission may include any of the following if a team judges it useful for adoption; it will not earn or lose points for them. + - The Logos blockchain wallet, staking, bridging, and multi-zone configuration, covered by [LP-0022](LP-0022.md). - Designing or implementing the token program itself. The wallet integrates with the existing/reference implementation. - NFT minting flows, marketplaces, listings, or royalties. From d03c31a75e735da1d44534da4dff02cbc25ca076 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 17 Sep 2026 12:58:21 +1000 Subject: [PATCH 08/15] LP-0001: scope the media-fetching rule to centralised services The criterion covered any source other than Logos Storage, which would have swept in decentralised networks it was never aimed at. Name centralised services instead (HTTP hosts, gateways, CDNs, hosted pinning or indexing APIs) and say explicitly that fetching over a decentralised network the user participates in is not subject to it. Co-Authored-By: Claude Opus 5 (1M context) --- prizes/LP-0001.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index 2a241fe3..4d3dd6f0 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -55,7 +55,7 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a - [ ] A dApp cannot generate a membership proof without an explicit user approval for that request, and cannot enumerate a private account's NFTs without an explicit user approval for that account. - [ ] The privacy property holds against the verifier, against an observer of the chain, and against the requesting dApp: none learns the specific token or the holding account from a valid proof. The submission must state its security assumptions and any trusted setup explicitly. - [ ] The reliability criteria set out in [LP-0021](LP-0021.md) are met: wallet state survives restarts, no mandatory external services, and any remote persistence uses Logos Storage with client-side encryption. -- [ ] **Media fetching is optional and disableable.** NFT metadata and media (images, video, audio) often live off-chain. If the wallet fetches them from any source other than Logos Storage or the user's configured LEZ node, that fetching must be disclosed, must be disableable by the user, and the wallet must remain fully functional with it disabled, listing the affected assets by collection and token identifier rather than failing or hiding them. Fetching must not leak which account holds an asset to the host serving it: the user is told what a fetch discloses, and third-party media hosts are never contacted for a private account without the user turning it on. +- [ ] **Fetching media from centralised services is optional and disableable.** NFT metadata and media (images, video, audio) often live off-chain. If the wallet fetches them from a centralised service (an HTTP host, a gateway, a CDN, a hosted pinning or indexing API), that fetching must be disclosed, must be disableable by the user, and the wallet must remain fully functional with it disabled, listing the affected assets by collection and token identifier rather than failing or hiding them. Fetching must not leak which account holds an asset to the operator of that service: the user is told what a fetch discloses, and centralised media services are never contacted for a private account without the user turning it on. Fetching over a decentralised network the user participates in, such as Logos Storage, is not subject to this criterion. - [ ] **Large metadata and media on Logos Storage.** The wallet can upload and download NFT metadata and media of a size typical for image assets to and from **Logos Storage**, so a collection can be published and displayed without depending on a centralised host. Document any size limits observed and how the wallet behaves when an asset exceeds them. ### Performance @@ -68,7 +68,7 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a - [ ] Deployed and tested against Logos testnet 0.3 (the Logos LEZ zone). - [ ] Logos Basecamp modules are built with [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) (`mkLogosModule`) and can be installed on both Linux and MacOS desktop platforms. - [ ] End-to-end integration tests run against a real sequencer (standalone mode) and are included in CI; CI is green on the default branch. -- [ ] README documents setup, NFT management, proof generation, media storage and any external fetching the wallet performs, and step-by-step usage via CLI and Basecamp app. +- [ ] README documents setup, NFT management, proof generation, media storage and any fetching from centralised services the wallet performs, and step-by-step usage via CLI and Basecamp app. - [ ] A reproducible end-to-end demo script works against a real local sequencer, with proving enabled rather than a development/mock proving mode. - [ ] Wallet Provider SDK documentation covers the token-gating mini-app as a worked example of connect → approval → proof → verification, and documents which capability each SDK call requires and what it discloses. @@ -93,7 +93,7 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a - A wallet module matching the criteria in LP-0021, covering non-fungible token-program assets: ownership, transfer, display, and collection grouping, for public and private accounts. - A Wallet Provider SDK matching the criteria in LP-0021, covering NFT enumeration, collection queries, transfer proposals, and membership-proof requests. -- Upload and download of NFT metadata and media via Logos Storage, with any other media fetching disclosed and disableable. +- Upload and download of NFT metadata and media via Logos Storage, with any fetching from centralised services disclosed and disableable. - A membership-proof scheme over an NFT collection's ownership set, with client-side proof generation. - A LEZ verifier that programs can call to gate an action on collection membership. - A token-gating reference mini-app built on the SDK. From 44b24ea2d9ffde069b860e523a7f75614f3a5052 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 17 Sep 2026 13:00:48 +1000 Subject: [PATCH 09/15] LP-0001: exclude Logos core contributors from adoption counts The adoption criteria repeatedly call for independent or third parties without saying whether people already building the stack qualify. State it once in the preamble: core contributors are welcome to use the wallet, but do not count toward the numbers. Co-Authored-By: Claude Opus 5 (1M context) --- prizes/LP-0001.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index 4d3dd6f0..4ad1b819 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -78,6 +78,8 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a > > **All of the following are required in addition to the FURPS criteria above.** We publish the dimensions we look at, but hitting a raw number is not by itself sufficient (see [Terms & Conditions](../TERMS.md) for the evaluation policy that applies to all prizes). Evaluators will inspect commit histories and the posting history of vouching accounts. Volume that is clearly manufactured (fresh accounts, purchased engagement) does not count, regardless of the headline number. > +> **Logos core contributors do not count.** Everywhere a criterion below calls for an independent or third party, that excludes Logos core contributors, and anyone acting on their behalf. Their apps, collections, testimonials and on-chain activity are welcome, but do not count toward these numbers: the point is traction outside the people already building the stack. +> > **Who the baseline wallet criterion applies to.** A submission from the **team that won LP-0021, continuing that same wallet/SDK codebase**, has already demonstrated baseline wallet adoption: the baseline criterion below is **waived**. Every other submission **must meet it** through its own submission. That covers a different team, and the LP-0021 winning team shipping a wallet/SDK not descended from their own merged LP-0021 solution. All other criteria below apply to every submission. - [ ] **Baseline wallet adoption.** Waived for the LP-0021 winning team continuing that codebase (see above). Otherwise: **50 on-chain testimonials** on the LEZ zone via the LP-0021 testimonial mini-app, from **at least 50 distinct accounts**, same anti-Sybil standard as LP-0021. From e045665f5f5e99fff344194b696a09588a33db09 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 17 Sep 2026 13:02:44 +1000 Subject: [PATCH 10/15] Revert "LP-0001: exclude Logos core contributors from adoption counts" This reverts commit 44b24ea. Awaiting phrasing from legal. Co-Authored-By: Claude Opus 5 (1M context) --- prizes/LP-0001.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index 4ad1b819..4d3dd6f0 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -78,8 +78,6 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a > > **All of the following are required in addition to the FURPS criteria above.** We publish the dimensions we look at, but hitting a raw number is not by itself sufficient (see [Terms & Conditions](../TERMS.md) for the evaluation policy that applies to all prizes). Evaluators will inspect commit histories and the posting history of vouching accounts. Volume that is clearly manufactured (fresh accounts, purchased engagement) does not count, regardless of the headline number. > -> **Logos core contributors do not count.** Everywhere a criterion below calls for an independent or third party, that excludes Logos core contributors, and anyone acting on their behalf. Their apps, collections, testimonials and on-chain activity are welcome, but do not count toward these numbers: the point is traction outside the people already building the stack. -> > **Who the baseline wallet criterion applies to.** A submission from the **team that won LP-0021, continuing that same wallet/SDK codebase**, has already demonstrated baseline wallet adoption: the baseline criterion below is **waived**. Every other submission **must meet it** through its own submission. That covers a different team, and the LP-0021 winning team shipping a wallet/SDK not descended from their own merged LP-0021 solution. All other criteria below apply to every submission. - [ ] **Baseline wallet adoption.** Waived for the LP-0021 winning team continuing that codebase (see above). Otherwise: **50 on-chain testimonials** on the LEZ zone via the LP-0021 testimonial mini-app, from **at least 50 distinct accounts**, same anti-Sybil standard as LP-0021. From 780573c1ebeedcd091f87a5393ef18f756f3ed73 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 17 Sep 2026 13:06:49 +1000 Subject: [PATCH 11/15] LP-0001: require the mini-app to demonstrate on-chain and off-chain verification A proof is only useful if the thing receiving it can check it, and most consumers are not LEZ programs. Require the reference mini-app to show both paths: the proof passed as input to a reference LEZ program that gates an action on the result, and the mini-app verifying the proof in its own code and showing the user what it establishes. Add off-chain verification as its own criterion with a library and the inputs a verifier needs, and require the on-chain verifier and the library to agree on accept/reject outcomes. The on-chain flow remains the one that feeds the adoption criteria. Co-Authored-By: Claude Opus 5 (1M context) --- prizes/LP-0001.md | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index 4d3dd6f0..7c07fb71 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -30,10 +30,15 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a - [ ] **Wallet Provider SDK NFT APIs**: third-party dApps can enumerate an account's NFTs, query collection membership, and propose NFT transfers through the SDK, subject to the same approval flow as fungible transfers. - [ ] **Private ownership proof**: a user holding any NFT in a given collection can generate a proof of collection membership that a verifier can check **without learning which token the user holds or which account holds it**. - [ ] **On-chain verification**: the proof can be verified on LEZ, so a program can gate an action on collection membership. +- [ ] **Off-chain verification**: the same proof can be verified in application code, without submitting a transaction, so anything that receives a proof can check it for itself. Provide a library that performs the check and document what a verifier needs: the proof, the collection it is over, any public parameters, and whatever chain state must be read to establish the collection's ownership set. - [ ] **Replay resistance**: the same proof cannot be reused across gating contexts. A proof accepted for one context must not be accepted for a different one. - [ ] **Proof via the SDK**: a third-party dApp can request a membership proof through the Wallet Provider SDK, and the user is shown an approval prompt identifying the requesting dApp, the collection being proven, and what the proof discloses, before any proof is generated. - [ ] **Proof requests stand alone**: requesting a membership proof is its own SDK capability, independent of account access. A dApp that has been granted only a proof request must not thereby learn the account address, the account's balances, its NFT holdings, or the specific token proving membership, and must not be able to enumerate accounts or propose transactions. A wallet must not require the user to grant account access in order to produce a proof. -- [ ] **Token-gating mini-app**: a reference application, built on the SDK, that gates an action on private collection membership, going through the full connect → approval → proof → on-chain verification flow without requesting account access. Each gated action carries a unique identifier for the given LP submission, so that activity can be attributed to the submission that produced it. It serves as the canonical integration example for third-party developers and is the tool used to produce the on-chain gated actions counted in the adoption criteria below. +- [ ] **Token-gating mini-app**: a reference application, built on the SDK, that gates an action on private collection membership, going through the full connect → approval → proof flow without requesting account access. It must demonstrate **both** ways a proof gets consumed: + - **On-chain**: the proof is passed as input to a reference LEZ program, which verifies it and gates an action on the result. Each gated action carries a unique identifier for the given LP submission, so that activity can be attributed to the submission that produced it. This is the flow that produces the on-chain gated actions counted in the adoption criteria below. + - **Off-chain**: the mini-app verifies the proof it received from the Wallet Provider SDK in its own code, with no transaction and no server in the path, and shows the user the outcome: whether the proof is valid, and what it establishes (the collection proven) as distinct from what it does not reveal. This is the worked example a developer copies to verify a proof wherever they receive one. + + It serves as the canonical integration example for third-party developers. - [ ] **Testnet 0.3**: the wallet operates end-to-end against the canonical Logos LEZ zone on Logos testnet 0.3. If the foundation this prize builds on has already moved to a later testnet, that target takes precedence. ### Usability @@ -46,12 +51,12 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a - [ ] **Permissions are legible and revocable.** The user can see, per dApp, which capabilities have been granted (proof requests, account access, NFT enumeration, transaction proposals) and revoke any of them individually. A granted capability must be identifiable by what it discloses, not only by an API name. - [ ] **Program source verification.** The approval prompt must show the user the program's source-verification status for the program being called. A program registry that meets or is similar to the specifications of [LP-0023](LP-0023.md) will be suitable. - [ ] **UX quality.** NFT browsing, transfer, and proof generation must be polished and usable by a non-expert: coherent navigation, comprehensible previews, and clear error/pending states. This is judged against overall impression rather than a checklist: evaluators will use the wallet as a normal user would. -- [ ] **Integration guide.** Documentation covers how a third-party dApp adds private token-gating: the SDK calls, the on-chain verification, what a program author must do to gate on collection membership, and how to request a proof without requesting account access. +- [ ] **Integration guide.** Documentation covers how a third-party dApp adds private token-gating: the SDK calls, verifying a proof on-chain and in application code, what a program author must do to gate on collection membership, and how to request a proof without requesting account access. ### Reliability - [ ] Proof generation failures surface a clear, actionable error to the user rather than an opaque failure or a silently unproven state. -- [ ] The on-chain verifier returns deterministic, documented outcomes for invalid-proof scenarios, so an integrating program can distinguish "not a member" from "malformed proof". +- [ ] Verification returns deterministic, documented outcomes for invalid-proof scenarios, so an integrator can distinguish "not a member" from "malformed proof". The on-chain verifier and the off-chain library agree: a proof accepted by one is accepted by the other, and both reject the same proofs for the same documented reason. - [ ] A dApp cannot generate a membership proof without an explicit user approval for that request, and cannot enumerate a private account's NFTs without an explicit user approval for that account. - [ ] The privacy property holds against the verifier, against an observer of the chain, and against the requesting dApp: none learns the specific token or the holding account from a valid proof. The submission must state its security assumptions and any trusted setup explicitly. - [ ] The reliability criteria set out in [LP-0021](LP-0021.md) are met: wallet state survives restarts, no mandatory external services, and any remote persistence uses Logos Storage with client-side encryption. @@ -70,7 +75,7 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a - [ ] End-to-end integration tests run against a real sequencer (standalone mode) and are included in CI; CI is green on the default branch. - [ ] README documents setup, NFT management, proof generation, media storage and any fetching from centralised services the wallet performs, and step-by-step usage via CLI and Basecamp app. - [ ] A reproducible end-to-end demo script works against a real local sequencer, with proving enabled rather than a development/mock proving mode. -- [ ] Wallet Provider SDK documentation covers the token-gating mini-app as a worked example of connect → approval → proof → verification, and documents which capability each SDK call requires and what it discloses. +- [ ] Wallet Provider SDK documentation covers the token-gating mini-app as a worked example of connect → approval → proof → verification, on-chain and in application code, and documents which capability each SDK call requires and what it discloses. ### Adoption @@ -95,7 +100,7 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a - A Wallet Provider SDK matching the criteria in LP-0021, covering NFT enumeration, collection queries, transfer proposals, and membership-proof requests. - Upload and download of NFT metadata and media via Logos Storage, with any fetching from centralised services disclosed and disableable. - A membership-proof scheme over an NFT collection's ownership set, with client-side proof generation. -- A LEZ verifier that programs can call to gate an action on collection membership. +- A LEZ verifier that programs can call to gate an action on collection membership, and a library that verifies the same proof in application code. - A token-gating reference mini-app built on the SDK. - A CLI and Basecamp app GUI covering the above. - Documentation covering the cryptographic approach, security assumptions, any trusted setup, and an integration guide. @@ -122,9 +127,9 @@ Open to any individual or team. A submission must build on a wallet, Wallet Prov ## Submission Requirements -- Public repository with the wallet module, Wallet Provider SDK, CLI, token-gating mini-app, LEZ verifier, and Basecamp app GUI under MIT and Apache-2.0. +- Public repository with the wallet module, Wallet Provider SDK, CLI, token-gating mini-app, LEZ verifier, off-chain verification library, and Basecamp app GUI under MIT and Apache-2.0. - Deployment of the verifier on LEZ testnet, with a verified program ID. -- Narrated video walkthrough demonstrating: receiving and displaying NFTs across collections, an NFT transfer from a private account, and the token-gating mini-app performing connect → approval → proof generation → on-chain verification via the SDK without the user granting account access, including the approval prompt as the user sees it. The recording must show terminal output confirming that proving ran for real rather than in a development/mock mode. (A narrated demo is required for every prize: see [demo requirements](../README.md#evaluation-policies).) +- Narrated video walkthrough demonstrating: receiving and displaying NFTs across collections, an NFT transfer from a private account, and the token-gating mini-app performing connect → approval → proof generation via the SDK without the user granting account access, including the approval prompt as the user sees it, then both consuming the proof on-chain and verifying it in the mini-app's own code with the outcome shown to the user. The recording must show terminal output confirming that proving ran for real rather than in a development/mock mode. (A narrated demo is required for every prize: see [demo requirements](../README.md#evaluation-policies).) - A write-up covering the proving approach, how collection membership is represented, the replay-resistance mechanism, security assumptions, and known limitations. - Proof generation timings and on-chain verification cost benchmarks. - Evidence for each adoption criterion: links to the 5 independent NFT collections, the 3 third-party SDK apps and their repositories, the wallet repository, the on-chain gated actions (with the submission identifier and per-month counts so the sustained-activity criterion can be verified), and the Discord and Twitter/X testimonials. From 56cfd129c84c5483532c0ad841da9798b603f688 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 17 Sep 2026 13:08:51 +1000 Subject: [PATCH 12/15] LP-0001: drop the narrated video requirement The adoption criteria cover usability: a wallet that 3 third-party developers build on and 100 accounts use through the mini-app has demonstrated it works better than a recording could. Fold the one requirement the video carried, evidence that proving ran for real rather than in mock mode, into the demo-script criterion the evaluation process already relies on, and extend that script to cover the full proof flow. Co-Authored-By: Claude Opus 5 (1M context) --- prizes/LP-0001.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index 7c07fb71..3eb6c983 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -74,7 +74,7 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a - [ ] Logos Basecamp modules are built with [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) (`mkLogosModule`) and can be installed on both Linux and MacOS desktop platforms. - [ ] End-to-end integration tests run against a real sequencer (standalone mode) and are included in CI; CI is green on the default branch. - [ ] README documents setup, NFT management, proof generation, media storage and any fetching from centralised services the wallet performs, and step-by-step usage via CLI and Basecamp app. -- [ ] A reproducible end-to-end demo script works against a real local sequencer, with proving enabled rather than a development/mock proving mode. +- [ ] A reproducible end-to-end demo script works against a real local sequencer, with proving enabled rather than a development/mock proving mode, and covers the full flow: proof generation via the SDK without account access, consumption on-chain, and verification in application code. Its output must make clear that proving ran for real. - [ ] Wallet Provider SDK documentation covers the token-gating mini-app as a worked example of connect → approval → proof → verification, on-chain and in application code, and documents which capability each SDK call requires and what it discloses. ### Adoption @@ -129,7 +129,6 @@ Open to any individual or team. A submission must build on a wallet, Wallet Prov - Public repository with the wallet module, Wallet Provider SDK, CLI, token-gating mini-app, LEZ verifier, off-chain verification library, and Basecamp app GUI under MIT and Apache-2.0. - Deployment of the verifier on LEZ testnet, with a verified program ID. -- Narrated video walkthrough demonstrating: receiving and displaying NFTs across collections, an NFT transfer from a private account, and the token-gating mini-app performing connect → approval → proof generation via the SDK without the user granting account access, including the approval prompt as the user sees it, then both consuming the proof on-chain and verifying it in the mini-app's own code with the outcome shown to the user. The recording must show terminal output confirming that proving ran for real rather than in a development/mock mode. (A narrated demo is required for every prize: see [demo requirements](../README.md#evaluation-policies).) - A write-up covering the proving approach, how collection membership is represented, the replay-resistance mechanism, security assumptions, and known limitations. - Proof generation timings and on-chain verification cost benchmarks. - Evidence for each adoption criterion: links to the 5 independent NFT collections, the 3 third-party SDK apps and their repositories, the wallet repository, the on-chain gated actions (with the submission identifier and per-month counts so the sustained-activity criterion can be verified), and the Discord and Twitter/X testimonials. From eafa93ecd67ab9a46f6fed6cb4100dc2a4f1ddcf Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 17 Sep 2026 13:10:24 +1000 Subject: [PATCH 13/15] LP-0001: add dependency front matter, drop the README reminder comment Restore the LP-0021 and LP-0023 dependencies with legal's note that the front matter is internal reference and tooling only, matching LP-0022. The README row is already in place, so the reminder comment has served its purpose. Co-Authored-By: Claude Opus 5 (1M context) --- prizes/LP-0001.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index 3eb6c983..619256c4 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -1,4 +1,12 @@ - +--- +# This front matter is for internal reference and tooling only. It does not +# form part of the Specification and is not directed at Participants. +dependencies: + - id: LP-0021 + reason: NFT support and private ownership proofs for a wallet and Wallet Provider SDK matching the criteria in LP-0021 + - id: LP-0023 + reason: wallet approval flow requires the program registry to show verified source for called programs +--- # LP-0001: NFT Wallet Support and Private Ownership Proof [DRAFT] From 86eba79cecd539d51783a7134c8f892740b53165 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 17 Sep 2026 13:11:11 +1000 Subject: [PATCH 14/15] LP-0001: drop the LP-0023 dependency The criterion asks for source-verification status and says a registry meeting or similar to LP-0023's specifications will be suitable. That is a pointer, not a dependency. LP-0023 stays in Resources. Co-Authored-By: Claude Opus 5 (1M context) --- prizes/LP-0001.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index 619256c4..d08ea396 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -4,8 +4,6 @@ dependencies: - id: LP-0021 reason: NFT support and private ownership proofs for a wallet and Wallet Provider SDK matching the criteria in LP-0021 - - id: LP-0023 - reason: wallet approval flow requires the program registry to show verified source for called programs --- # LP-0001: NFT Wallet Support and Private Ownership Proof [DRAFT] From 1a68f4a6aac2d0781414ae6dc4337a7e4f57c42a Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 22 Sep 2026 12:46:05 +1000 Subject: [PATCH 15/15] Address review feedback: unlinkable transfers, proof freshness, scope Adds reliability criteria for unlinkable private-to-private transfers and time-bound proof freshness with per-token proof supersession, and clarifies that the membership proof is collection-level, not selective disclosure of a specific asset. Co-Authored-By: Claude Sonnet 5 --- prizes/LP-0001.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index 27635355..96fa5888 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -65,6 +65,8 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a - [ ] Verification returns deterministic, documented outcomes for invalid-proof scenarios, so an integrator can distinguish "not a member" from "malformed proof". The on-chain verifier and the off-chain library agree: a proof accepted by one is accepted by the other, and both reject the same proofs for the same documented reason. - [ ] A dApp cannot generate a membership proof without an explicit user approval for that request, and cannot enumerate a private account's NFTs without an explicit user approval for that account. - [ ] The privacy property holds against the verifier, against an observer of the chain, and against the requesting dApp: none learns the specific token or the holding account from a valid proof. The submission must state its security assumptions and any trusted setup explicitly. +- [ ] **Private transfers are unlinkable.** A private-to-private NFT transfer does not reveal a sender→recipient edge to a chain observer: the on-chain record exposes no public owner and no link between the sending and receiving accounts, consistent with the shielded execution model in [LP-0021](LP-0021.md). +- [ ] **Proof freshness.** Because a private transfer is not observable on-chain, a membership proof must be time-bound rather than valid indefinitely: it expires after a documented validity window rather than remaining acceptable forever. Generating a new proof for a given token invalidates any previously issued proof for that same token, whether or not ownership actually changed, so a verifier is never relying on a proof older than the holder's most recent one. - [ ] The reliability criteria set out in [LP-0021](LP-0021.md) are met: wallet state survives restarts, no mandatory external services, and any remote persistence uses Logos Storage with client-side encryption. - [ ] **Fetching media from centralised services is optional and disableable.** NFT metadata and media (images, video, audio) often live off-chain. If the wallet fetches them from a centralised service (an HTTP host, a gateway, a CDN, a hosted pinning or indexing API), that fetching must be disclosed, must be disableable by the user, and the wallet must remain fully functional with it disabled, listing the affected assets by collection and token identifier rather than failing or hiding them. Fetching must not leak which account holds an asset to the operator of that service: the user is told what a fetch discloses, and centralised media services are never contacted for a private account without the user turning it on. Fetching over a decentralised network the user participates in, such as Logos Storage, is not subject to this criterion. - [ ] **Large metadata and media on Logos Storage.** The wallet can upload and download NFT metadata and media of a size typical for image assets to and from **Logos Storage**, so a collection can be published and displayed without depending on a centralised host. Document any size limits observed and how the wallet behaves when an asset exceeds them. @@ -105,7 +107,7 @@ Submissions to this λPrize are welcome from the LP-0021 winning team or from a - A wallet module matching the criteria in LP-0021, covering non-fungible token-program assets: ownership, transfer, display, and collection grouping, for public and private accounts. - A Wallet Provider SDK matching the criteria in LP-0021, covering NFT enumeration, collection queries, transfer proposals, and membership-proof requests. - Upload and download of NFT metadata and media via Logos Storage, with any fetching from centralised services disclosed and disableable. -- A membership-proof scheme over an NFT collection's ownership set, with client-side proof generation. +- A membership-proof scheme over an NFT collection's ownership set, with client-side proof generation. This is a proof of *collection* membership, not selective disclosure of a specific asset: the proof does not reveal, and is not required to attest to, any attribute of the particular token held. - A LEZ verifier that programs can call to gate an action on collection membership, and a library that verifies the same proof in application code. - A token-gating reference mini-app built on the SDK. - A CLI and Basecamp app GUI covering the above.