Skip to content

LP-0023: Program Registry — Verified Builds for LEZ Programs - #127

Draft
fryorcraken wants to merge 2 commits into
masterfrom
lp-0023-program-registry
Draft

LP-0023: Program Registry — Verified Builds for LEZ Programs#127
fryorcraken wants to merge 2 commits into
masterfrom
lp-0023-program-registry

Conversation

@fryorcraken

Copy link
Copy Markdown
Collaborator

Drafts LP-0023, an on-chain program registry for LEZ with verified builds.

Fixes logos-co/ecosystem#196

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 searchlez_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 URL, no hash matching.
  • Real timestampsregistered_at is hardcoded to 0 (zkVM guests have no clock).
  • End-to-end tests — the e2e_tests crate is a placeholder.

Adoption criteria

Follow the LP-0021/LP-0022 pattern (#122): 5 third-party integrations, 75 stars, 100 registered programs from ≥40 distinct authors, sustained ≥2 months at ≥20/month, 30 Discord + 30 Twitter/X testimonials, same anti-Sybil framing. 20 entries carrying verified source claims is counted separately — registering metadata is cheap, so the count that signals trustworthiness deserves its own line.

Open points for review

  • Prize pool left as $X per template.
  • Reproducible builds are a hard dependency on the LEZ toolchain. If LEZ program builds are not yet deterministic, the verification criteria are unsatisfiable through no fault of a submitter. Flagged in a Risks and Dependencies section; should be confirmed before this leaves Draft, and may warrant a dependencies: entry. dependencies: is currently [].
  • 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 issue's open questions (permissionless vs publisher-gated verification, on-chain vs off-chain attestations, where verified source lives) are deliberately left to the submitter in a Design Decisions section rather than pre-decided.

🤖 Generated with Claude Code

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>
@github-actions

Copy link
Copy Markdown

✅ Validation passed

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


Automated check. See solution template and TERMS.

@fryorcraken
fryorcraken requested a review from vpavlin August 17, 2026 05:22
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[LP] Program Registry: verified builds for LEZ programs

1 participant