LP-0023: LEZ Program Registry by fryorcraken · Pull Request #127 · logos-co/lambda-prize

fryorcraken · 2026-08-17T05:20:39Z

Drafts LP-0023, a LEZ program registry with source verification.

Number choice

LP-0023. LP-0000–0017 are merged; 0018–0020 are in open PRs (#90, #75, #71, #36, #83, #82); 0021–0022 are in #122.

Shape

Modelled on the existing prior art — jimmy-claw/spelbook (Rust core, on-chain SPEL program, CLI, FFI) and jimmy-claw/logos-lez-registry-module (Qt6 Logos Core module) — extended to cover what that prototype does not yet do.

Working in the prior art: register, author-gated update, lookup by program ID, IDL upload/download to Logos Storage, CLI, browse/detail/register GUI.

Not implemented there, and therefore where this prize puts the work:

Enumeration and search — lez_registry_list returns only a count, and get_by_name is a hardcoded stub; both are marked "requires an off-chain indexer in v1".
Claim authorisation — registration is currently first-come-first-claim, so anyone can claim a program ID they do not control and permanently own the entry wallets will display.
Source verification — absent entirely; no reproducible builds, no source pointer, no byte-code matching.
Real timestamps — registered_at is hardcoded to 0.
End-to-end tests — the e2e_tests crate is a placeholder.

The criteria have since been revised (during review) to specify product-level outcomes rather than implementation mechanisms — e.g. "clients must be able to tell a deployer entry from a third-party one" rather than prescribing a specific PDA seeding scheme. Source and IDL storage is now an explicit requirement (off-chain, on Logos Storage) rather than left open. Source verification also moved from a formal four-state on-chain status to a simpler local, self-attested model: a user rebuilds an entry's recorded source themselves and marks it "locally verified" for their own use, rather than the registry maintaining a canonical on-chain verification state. The Performance criterion now points at LEZ's own cycle_bench tool and cycle-count terminology, not a compute-unit or gas analogy borrowed from elsewhere in the stack.

Adoption criteria

Scaled down from the original LP-0021/LP-0022-modelled numbers to match this prize's current Small effort tier: 5 third-party integrations (each shipping as a Logos UI Module), 50 registered programs from ≥20 distinct authors, sustained ≥2 months at ≥10/month, 20 Discord + 20 Twitter/X testimonials. 20 entries carrying verified source claims is still counted separately — registering metadata is cheap, so the count that signals trustworthiness deserves its own line.

Open points for review

Prize pool set to $2000 / Small effort (previously $X / Large in the initial draft).
Relationship to the prior art. Written as a competitive prize that credits and may build on the existing repos. If it would be better treated as productionizing that specific work, the framing should change.
The remaining open questions (where verified source lives, whether there's a trusted-signer overlay) are deliberately left to the submitter in a Design Decisions section rather than pre-decided.
The original Risks and Dependencies note (reproducible builds as a hard dependency on the LEZ toolchain) has been removed from the prize doc as no longer needed; flag if that risk should be tracked elsewhere instead.

🤖 Generated with Claude Code

github-actions · 2026-08-17T05:20:48Z

✅ Validation passed

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

Automated check. See solution template and TERMS.

LP-0023 (Program Registry — Verified Builds for LEZ Programs, PR #127) is now open and follows the LP-0021/LP-0022 adoption pattern. Firm up the prior speculative "not yet written" placeholder into a real dependency: add LP-0023 to both files' dependencies: frontmatter, and change the approval-prompt criterion from optional ("MAY use... not required") to required ("must show the registry's verified source status") for programs registered in it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

weboko · 2026-08-26T21:57:54Z

+
+### Functionality
+
+- [ ] **On-chain registry**: entry metadata is stored on-chain as a LEZ program built with the [SPEL framework](https://github.com/logos-co/spel), with a published IDL. Source code and the entry's own IDL live off-chain on Logos Storage; on-chain storage is limited to metadata and pointers, mindful of gas cost.


do we have concept of gas cost to refer to on LEZ?

~~Checking with @davidrusu to confirm but I expect gas in 0.3. AFAIK the tokenomics are ready.~~

edit: will be delivered in 0.3

weboko · 2026-08-26T21:59:24Z

+
+### Performance
+
+- [ ] Document compute unit usage for each on-chain operation (register, update).


can we clarify what CU means here? since it is about registry maybe size limits is an option

additionally, my AI advices to refer to RISC0 cycle counts

~~Indeed, execution gas and storage gas seem to be the terminology used: https://lip.logos.co/blockchain/raw/analysis-gas-cost-determination.html~~

edit: indeed, "cycle count" is the right terminology: https://github.com/logos-blockchain/logos-execution-zone/tree/dev/tools

weboko · 2026-08-26T22:04:01Z

+
+### Adoption
+
+> These metrics measure traction attributable to a given submission for this prize.


do we need to refer to this quote in LPs now?

(edited) I don't think we "need" per se, but I think it is a good introduction to have.

weboko · 2026-08-26T22:06:41Z

+- [ ] README documents setup, the deployed program ID, and step-by-step usage via CLI and Logos Core Module.
+- [ ] SDK documentation covers resolving a program ID to metadata and IDL as a worked example, since that is the integration path most consumers will take.
+
+### Adoption


this is $1000 LP and there are 6 adoption criteria

are all 6 criteria needed for selection of a submission or only a sub set of them, say, 4 out of 6 needs to be met?

I did think when leaving my computer that $2000 would be more appropriate (chnaged).

Also, considering how gamable this could be, I think 6/6 is fair. Do you disagree?

ok to go with 6/6, we need to test at least something in the direction of adoption criteria

weboko · 2026-08-26T22:11:56Z

+
+## Risks and Dependencies
+
+Reproducible builds are a hard requirement on the LEZ compiler toolchain, not something this prize can bolt on from the outside. If the toolchain does not yet build LEZ programs deterministically, that must be resolved before this prize opens: otherwise the verification criteria are unsatisfiable through no fault of the submitter. This should be confirmed before moving the prize out of Draft, and may warrant a `dependencies:` entry once the owning work item is identified.


reading this it seems more a concern to us (owners of LP) rather than to implementers of it

weboko · 2026-08-26T22:13:23Z

+
+- The on-chain LEZ registry (register, update), built with SPEL.
+- IDL publishing to Logos Storage and resolution from the on-chain entry.
+- Reproducible builds for LEZ programs, and the source-verification tooling and on-chain fields backing it.


here I copy paste my AI's comment:

A submitter doing spel init → make build today gets host-dependent, non-reproducible image IDs.

It's in-scope work: generalise that pipeline into a reusable spel build --reproducible. That's a better prize, and it matters because a submitter reading the current Risks section may conclude the criterion is unsatisfiable. Worth pinning the container tag, --locked, and the packager step in the criteria — all three affect the image ID.

AI is incorrect, but scaffold needs to be fixed: logos-co/scaffold#259

I'll check that for scaffold but why it is not correct for spel?

because spel uses cargo risczero build with does deterministic builds

see logos-co/spel#265

edenbd1 · 2026-08-31T00:09:13Z

Hey @fryorcraken @weboko i've got some good ideas for LP-0023 and have already made solid progress, with a full implementation running on LEZ v0.2.4. Quick question on the testnet 0.3 requirement, is testnet 0.3 already live somewhere or when is it expected? And does our current deployment on testnet 0.2.4 count in the meantime since the code is ready?
Just want to clear up the ambiguity

fryorcraken · 2026-08-31T01:45:53Z

Hey @fryorcraken @weboko i've got some good ideas for LP-0023 and have already made solid progress, with a full implementation running on LEZ v0.2.4.

Hi @edenbd1, that's great to hear.

Quick question on the testnet 0.3 requirement, is testnet 0.3 already live somewhere or when is it expected?

Testnet 0.3 is planned for end of September.

And does our current deployment on testnet 0.2.4 count in the meantime since the code is ready?

The λ-Prize is not published yet. The existence of this PR is not a guarantee of it happening, proper review need to happen.

Deployment on testnet 0.2.4 does not count as we are likely to reset the chain from testnet 0.3.

I hope it helps and could luck with the prize!

mart1n-xyz · 2026-08-31T08:49:58Z

LGTM

Adds a draft prize for an on-chain LEZ program registry: register/update of program metadata with IDLs on Logos Storage, enumeration and search, a claim-authorisation model, and reproducible-build bytecode-to-source verification. Adoption criteria follow the LP-0021/LP-0022 wallet pattern, with a separate count for entries carrying verified source claims. Refs logos-co/ecosystem#196 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Compares against otter-verify, program-metadata, solana-verify and the Explorer's verification UI, and tightens the criteria accordingly: - Replace the open-ended claim model with the canonical/non-canonical PDA pattern from solana-program/program-metadata. - Four verification states rather than three, adding the "claim present but hash mismatched" case the Explorer treats separately. - Require an answer to the build.rs provenance attack, where a matching hash was produced from an attacker-controlled repository. - Require a documented staleness window and last-verified point. - Require the signer behind a claim to be surfaced, not a bare badge, and a "verified is not audited" caveat. Adds a prior-art comparison table and Solana references. Refs logos-co/ecosystem#196 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Rewrite Success Criteria to specify product-level requirements instead of prescribing implementation mechanisms (PDA derivation, singleton accounts, host-timestamp handling). Rename canonical/third-party split to deployer/third-party with a simpler authorization model. Make off-chain storage of source and IDL on Logos Storage an explicit requirement rather than a design choice left to the submitter. Trim FURPS bullets already covered by the Adoption bars, and tighten prose throughout (overstated claims, em-dash density, unrelated citations).

The registry points to both the IDL and source code; the Overview only named the IDL.

Replace prose em-dashes with commas/colons/periods per sentence context. Keep the [text](url) — description convention in reference lists, which reads as normal markdown-list style, not an AI tell. Revert an unnecessary "per the standard adoption evaluation policy" addition from the prior pass.

Restore blank lines before headers that were missing (### Reliability, ### Performance, ### Supportability, ## Resources, and before the "Solana prior art" paragraph), which were breaking rendering. Fix a dangling "see the comparison above" reference to a Solana comparison table that no longer exists in the doc. Resolve inconsistent tags references (Register dropped tags but Update/Discovery/Scope still mentioned it) and standardize "Basecamp app" vs "Core Module" naming on Logos Core Module throughout. Clean up unclear/ungrammatical wording in the Source verification and adoption-criteria bullets.

Each of the 5 third-party SDK integrations must ship as a Logos Core Module, not just any tool/library that happens to link the SDK.

A Core Module is backend/business-logic; the registry's app deliverable (browse, search, register) is a user-facing UI Module.

The registry itself ships as a Logos Core Module (backend/business logic, consumed via SDK). The 5 third-party adoption integrations must each be a Logos UI Module (user-facing app). The prior commit incorrectly collapsed both into "UI Module".

Logos Blockchain's gas model uses Execution Gas and Permanent Storage Gas, not "compute units" (that's Solana's term). Link the Gas Cost Determination doc from both the Performance criterion and Resources.

The gas-cost-determination doc is for the L1 blockchain layer, not LEZ. LEZ's own benchmarking tool (cycle_bench) measures cycle counts; point to that instead.

"Verified Builds" overstated what the prize now requires — source verification is a local, best-effort check, not the headline feature. Also fixes the README table row, which still said Large effort after the prize was scaled down to Small.

Co-authored-by: Cursor <cursoragent@cursor.com>

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…tion-first table README's prize index now splits into adoption-first vs legacy tables (merged separately); place LP-0023 under adoption-first. Also align the disclaimer block with the format landed in prizes/LP-0000.md (--- separator, bold Note lead-in, markdown link to TERMS.md).

LP-0023 (Program Registry — Verified Builds for LEZ Programs, PR #127) is now open and follows the LP-0021/LP-0022 adoption pattern. Firm up the prior speculative "not yet written" placeholder into a real dependency: add LP-0023 to both files' dependencies: frontmatter, and change the approval-prompt criterion from optional ("MAY use... not required") to required ("must show the registry's verified source status") for programs registered in it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

fryorcraken requested a review from vpavlin August 17, 2026 05:22

fryorcraken marked this pull request as ready for review August 26, 2026 07:14

fryorcraken requested review from mart1n-xyz and weboko August 26, 2026 07:14

fryorcraken force-pushed the lp-0023-program-registry branch from 7ab1875 to 790fb4e Compare August 26, 2026 07:15

mart1n-xyz approved these changes Aug 26, 2026

View reviewed changes

weboko reviewed Aug 26, 2026

View reviewed changes

weboko approved these changes Aug 27, 2026

View reviewed changes

fryorcraken mentioned this pull request Aug 28, 2026

LP-0018: OpenStreetMap integration — decentralized map data distribution #71

Merged

7 tasks

fryorcraken changed the title ~~LP-0023: Program Registry — Verified Builds for LEZ Programs~~ LP-0023: LEZ Program Registry Aug 28, 2026

This was referenced Aug 28, 2026

LP-0021, LP-0022: LEZ Wallet and Provider SDK, Combined Blockchain+Zone Wallet #122

Open

[LP] Program Registry: verified builds for LEZ programs logos-co/ecosystem#196

Open

weboko mentioned this pull request Sep 1, 2026

LP-0024: Basecamp Theming — theme engine, format, and community themes #135

Draft

fryorcraken and others added 7 commits September 3, 2026 14:26

LP-0023: mention source code alongside IDL in Overview

981ab2e

The registry points to both the IDL and source code; the Overview only named the IDL.

LP-0023: require the 5 adoption integrations to ship as Logos apps

e056aad

Each of the 5 third-party SDK integrations must ship as a Logos Core Module, not just any tool/library that happens to link the SDK.

fryorcraken and others added 11 commits September 3, 2026 14:26

LP-0023: correct "Logos Core Module" to "Logos UI Module"

c663bfa

A Core Module is backend/business-logic; the registry's app deliverable (browse, search, register) is a user-facing UI Module.

LP-0023: use Execution Gas terminology, not compute units

7207d93

Logos Blockchain's gas model uses Execution Gas and Permanent Storage Gas, not "compute units" (that's Solana's term). Link the Gas Cost Determination doc from both the Performance criterion and Resources.

LP-0023: bump prize pool to $2000

a979583

LP-0023: use LEZ cycle-count terminology, not L1 Execution Gas

63080d9

The gas-cost-determination doc is for the L1 blockchain layer, not LEZ. LEZ's own benchmarking tool (cycle_bench) measures cycle counts; point to that instead.

LP-0023: remove Risks and Dependencies section

723aaf0

LP-0023: replace "hash" with "byte code" in verification wording

5ed38f9

LP-0023: rename to "LEZ Program Registry"

c465125

"Verified Builds" overstated what the prize now requires — source verification is a local, best-effort check, not the headline feature. Also fixes the README table row, which still said Large effort after the prize was scaled down to Small.

LP-0023: mark prize as Open, no longer Draft

38b311a

Co-authored-by: Cursor <cursoragent@cursor.com>

Add legal note to prize specifications

a6147fc

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fryorcraken force-pushed the lp-0023-program-registry branch from d8501f8 to a091aa8 Compare September 3, 2026 04:30


		### Functionality

		- [ ] On-chain registry: entry metadata is stored on-chain as a LEZ program built with the [SPEL framework](https://github.com/logos-co/spel), with a published IDL. Source code and the entry's own IDL live off-chain on Logos Storage; on-chain storage is limited to metadata and pointers, mindful of gas cost.


		### Performance

		- [ ] Document compute unit usage for each on-chain operation (register, update).


		### Adoption

		> These metrics measure traction attributable to a given submission for this prize.


		## Risks and Dependencies

		Reproducible builds are a hard requirement on the LEZ compiler toolchain, not something this prize can bolt on from the outside. If the toolchain does not yet build LEZ programs deterministically, that must be resolved before this prize opens: otherwise the verification criteria are unsatisfiable through no fault of the submitter. This should be confirmed before moving the prize out of Draft, and may warrant a `dependencies:` entry once the owning work item is identified.

Uh oh!

Conversation

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

Uh oh!

Number choice

Shape

Adoption criteria

Open points for review

Uh oh!

github-actions Bot commented Aug 17, 2026

✅ Validation passed

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fryorcraken Aug 27, 2026 • 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!

Choose a reason for hiding this comment

Uh oh!

fryorcraken Aug 27, 2026 • 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!

Choose a reason for hiding this comment

Uh oh!

fryorcraken Aug 27, 2026 • 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

edenbd1 commented Aug 31, 2026

Uh oh!

fryorcraken commented Aug 31, 2026

Uh oh!

mart1n-xyz commented Aug 31, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

fryorcraken commented Aug 17, 2026 •

edited

Loading

fryorcraken Aug 27, 2026 •

edited

Loading

fryorcraken Aug 27, 2026 •

edited

Loading

fryorcraken Aug 27, 2026 •

edited

Loading