LP-0001: rewrite as an NFT extension of LP-0021 and open it by fryorcraken · Pull Request #152 · logos-co/lambda-prize

fryorcraken · 2026-09-14T06:23:22Z

What this does

Recasts LP-0001 from a standalone ZK bounty into LP-0001: NFT Wallet Support and Private Ownership Proof, an extension of LP-0021 following the same pattern LP-0022 uses, and opens it.

LP-0021 deliberately left NFTs out of its criteria to keep its scope to a fungible-asset wallet. This prize fills that gap and turns it into a token-gating primitive dApps can consume.

Key decisions

Extension on the feature set, not the codebase. Depends on LP-0021's wallet, Wallet Provider SDK, and approval flow criteria, but does not require reusing a merged LP-0021 codebase. The LP-0021 winner, a different team, or a fork can all submit, same as LP-0022.
NFT-first, ZK as one feature. Functionality leads with own/send/receive NFTs across public and private accounts, collection-grouped display, and SDK NFT enumeration/transfer proposals. The private collection-membership proof, on-chain and off-chain verification, and replay resistance follow as further criteria rather than being the whole prize.
Token-gating mini-app is the adoption instrument, carrying a per-submission identifier the way LP-0021's testimonial app does.
$5,000 / Medium, testnet 0.3 (deferring to the LP-0021 foundation's target if it has already moved on).
Proof-generation benchmarks are left open: desktop benchmarks required, mobile welcome but not required (mobile not expected before testnet 0.4).

Adoption criteria

Mirrors LP-0022's structure, including the same-team-vs-fork inheritance rule:

50 baseline on-chain testimonials (forked submissions only)
5 NFT collections deployed by independent parties
3 third-party Basecamp apps using the NFT/proof SDK additions specifically
100 on-chain gated actions from 100+ distinct accounts, sustained over 2 months (20+/month)
20 Discord + 20 Twitter/X testimonials

Opening the prize

Title marked [OPEN] and Status: Open added, matching LP-0021.
README table status set to Open.
Testnet 0.3 endpoint confirmed (https://testnet.lez.logos.co), replacing "will be confirmed when this prize opens".

Worth a look during review

Risc0 is no longer mandated. The original hardcoded Risc0 and RISC0_DEV_MODE=0. Per the house rule that prize docs specify product requirements rather than implementation, this is now "proving enabled rather than a development/mock mode": the anti-cheat intent survives without naming a stack.
README: LP-0001 moves from the legacy table to the adoption-first one.
The standard spec disclaimer is appended.

🤖 Generated with Claude Code

github-actions · 2026-09-14T06:23:33Z

✅ Validation passed

A reviewer will assess against the prize criteria.
ℹ️ Prize proposal for LP-0001.

Automated check. See solution template and TERMS.

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) <noreply@anthropic.com>

…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) <noreply@anthropic.com>

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) <noreply@anthropic.com>

"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) <noreply@anthropic.com>

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) <noreply@anthropic.com>

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) <noreply@anthropic.com>

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) <noreply@anthropic.com>

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) <noreply@anthropic.com>

This reverts commit 44b24ea. Awaiting phrasing from legal. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…erification 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) <noreply@anthropic.com>

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) <noreply@anthropic.com>

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) <noreply@anthropic.com>

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) <noreply@anthropic.com>

xAlisher

Reviewed against the private-NFT work I did (ownership + unlinkable transfer + viewing-key disclosure, with a passing POC on the real token program). Solid spec, honest framing. Three notes:

ADD - unlinkable private transfers. Criteria require send/receive from private accounts but never that a private NFT transfer is unlinkable to a chain observer (no sender->recipient edge). That is the core shielded property, and I verified it holds on Logos in my POC (private->private transfer records only commitments, no public owner, no edge). Worth a reliability criterion so "private account support" cannot pass while transfers stay linkable.

QUESTION - proof freshness. Replay resistance is per-context, not per-state. Does a membership proof bind to CURRENT ownership, so someone who transferred the NFT out can no longer gate? For token-gating that matters. Open design point (I have not solved it either), not a copy-this note.

SCOPE - one line stating this is collection-membership proof, not selective disclosure of a specific asset, would stop submitters conflating them.

Otherwise no removals; scope boundaries are good.

# Conflicts: # prizes/LP-0001.md

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 <noreply@anthropic.com>

weboko · 2026-09-23T15:46:46Z

+- [ ] **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.


that is really good

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

fryorcraken force-pushed the lp-0001-nft branch 4 times, most recently from a6185bc to 3f78af4 Compare September 17, 2026 02:39

fryorcraken and others added 5 commits September 17, 2026 12:47

LP-0001: legal feedback

289c9a1

fryorcraken force-pushed the lp-0001-nft branch from 3f78af4 to 9fd555f Compare September 17, 2026 02:48

fryorcraken and others added 9 commits September 17, 2026 12:53

Revert "LP-0001: exclude Logos core contributors from adoption counts"

e045665

This reverts commit 44b24ea. Awaiting phrasing from legal. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fryorcraken marked this pull request as ready for review September 17, 2026 03:13

fryorcraken requested review from mart1n-xyz and xAlisher September 17, 2026 03:13

xAlisher reviewed Sep 17, 2026

View reviewed changes

Base automatically changed from wallet to master September 22, 2026 02:25

fryorcraken and others added 3 commits September 22, 2026 12:32

Merge remote-tracking branch 'origin/master' into lp-0001-nft

2b015d4

# Conflicts: # prizes/LP-0001.md

Merge remote-tracking branch 'origin/master' into lp-0001-nft

7322bb2

weboko reviewed Sep 23, 2026

View reviewed changes

Comment thread prizes/LP-0001.md

weboko reviewed Sep 23, 2026

View reviewed changes

Comment thread prizes/LP-0001.md Outdated

weboko reviewed Sep 23, 2026

View reviewed changes

weboko approved these changes Sep 23, 2026

View reviewed changes

mart1n-xyz linked an issue Sep 29, 2026 that may be closed by this pull request

[LP] NFT Wallet Support and Private Ownership Proof logos-co/ecosystem#233

Closed

3 tasks

fryorcraken and others added 2 commits October 1, 2026 14:08

LP-0001: legal feedback

189c16b

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

LP-0001: open up proof-generation benchmarks to desktop and mobile

9ed4043

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

fryorcraken mentioned this pull request Oct 1, 2026

Prize specs: 'release early' instead of 'ship early' #170

Open

Open LP-0001 and confirm the testnet 0.3 endpoint.

f8989bd

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

fryorcraken changed the title ~~LP-0001: rewrite as an NFT extension of LP-0021 with adoption criteria~~ LP-0001: rewrite as an NFT extension of LP-0021 and open it Oct 1, 2026

fryorcraken merged commit 283075e into master Oct 1, 2026
1 of 2 checks passed

Navigation Menu

LP-0001: rewrite as an NFT extension of LP-0021 and open it - #152

LP-0001: rewrite as an NFT extension of LP-0021 and open it#152
fryorcraken merged 20 commits into
masterfrom
lp-0001-nft

fryorcraken commented Sep 14, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Sep 14, 2026

Uh oh!

xAlisher left a comment •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

weboko Sep 23, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

fryorcraken commented Sep 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What this does

Key decisions

Adoption criteria

Opening the prize

Worth a look during review

Uh oh!

github-actions Bot commented Sep 14, 2026

✅ Validation passed

Uh oh!

xAlisher left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

weboko Sep 23, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

fryorcraken commented Sep 14, 2026 •

edited

Loading

xAlisher left a comment •

edited

Loading