From 53ba7d80ba32405b19c80721e875e7a2c3aabfca Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Mon, 17 Aug 2026 15:20:02 +1000 Subject: [PATCH 01/22] =?UTF-8?q?LP-0023:=20Program=20Registry=20=E2=80=94?= =?UTF-8?q?=20verified=20builds=20for=20LEZ=20programs?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- README.md | 1 + prizes/LP-0023.md | 166 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 167 insertions(+) create mode 100644 prizes/LP-0023.md diff --git a/README.md b/README.md index 32ffc845..952be35b 100644 --- a/README.md +++ b/README.md @@ -31,6 +31,7 @@ Prizes are graded on a functionality gate **plus** adoption criteria (real third |------|-------------|------|--------| | [LP-0000](prizes/LP-0000.md) | Template — use this as the starting point for new prizes | — | — | | [LP-0018](prizes/LP-0018.md) | OpenStreetMap integration: decentralized map data distribution | Medium | Open | +| [LP-0023](prizes/LP-0023.md) | Program Registry: verified builds for LEZ programs | Large | Draft | ### Earlier prizes diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md new file mode 100644 index 00000000..b44edd84 --- /dev/null +++ b/prizes/LP-0023.md @@ -0,0 +1,166 @@ + + +--- +dependencies: [] +--- + +# LP-0023: Program Registry — Verified Builds for LEZ Programs [DRAFT] + +**`Logos Circle: N/A`** + +## Overview + +This prize is for an on-chain program registry for the Logos Execution Zone (LEZ): a LEZ program that lets developers publish their deployed program IDs together with human-readable metadata and a pointer to the program's IDL, plus the tooling to browse, search, and register through a CLI, an SDK, and a Logos Basecamp app. + +A LEZ program is identified on-chain by an opaque program ID. Nothing about that ID tells a user what the program does, who wrote it, what its interface looks like, or whether the bytecode matches any published source. The registry closes that gap: it turns an opaque program ID into a discoverable entry with a name, a version, an author, a description, tags, and a resolvable IDL, so that both humans and tooling can make sense of what they are about to interact with. + +## Motivation + +Every part of the LEZ developer experience currently assumes you already know which program you want and already have its IDL on disk. A wallet showing a transaction can only render raw calldata. A block explorer can only show a program ID. A developer looking for an existing token or governance program has no place to look. Each tool that needs this information ends up shipping its own hardcoded list, and those lists drift apart. + +Metadata alone, though, is only half the problem. Anyone can claim anything about a program they register, so a registry that records unverified assertions moves the trust problem rather than solving it. The part that carries real weight is proving that a deployed program's bytecode was built from published source: that is what lets a wallet show "verified, built from `github.com/x/y` at commit `abc`" next to a program a user is about to sign for, links an audit report to the artifact actually deployed, and lets integrators pin against verified code rather than an address someone handed them. This matters more on LEZ than on a transparent chain — privacy-preserving programs leave less on-chain state to inspect after the fact, so verifiability of the code itself carries more of the trust budget. The closest analogues are Solana's verified builds (`solana-verify` plus the OtterSec registry) and Etherscan source verification. + +A registry is exactly the kind of shared substrate that benefits from being built once, on-chain, and consumed by everything else — and exactly the kind of thing that fails if it launches empty. That is why this prize is weighted toward adoption: a registry with three entries is worse than no registry, because it teaches developers that looking things up there is a waste of time. The prize therefore requires both a working implementation and a genuine base of registered programs and integrating tools. + +The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anticipate this work: they allow, but do not require, a wallet to surface registry metadata when previewing a smart-contract interaction. Landing this registry makes that possible. + +## Success Criteria + +### Functionality + +- [ ] **On-chain registry program**: a LEZ program storing registry entries on-chain, built with the [SPEL framework](https://github.com/logos-co/spel), with a published IDL. +- [ ] **Register**: any account may register a deployed program ID it controls, supplying at minimum a **name**, **version**, **author** (the registering signer), **description**, **tags**, an **IDL pointer**, and a **registration timestamp**. Each entry is stored in its own PDA, derived deterministically from the program ID so that any client can compute an entry's address without an indexer. The timestamp must reflect real block time — a zkVM guest has no system clock, so it must be supplied by the host and validated on-chain, not hardcoded. +- [ ] **Claim authorisation**: registration must establish that the registrant is entitled to claim the program, rather than granting the author slot to whoever registers first. A naive first-come-first-claim registry is trivially front-run: an attacker registers a popular program ID under a plausible name before its real author does, and permanently owns the entry that wallets and explorers will display. The submission must define and implement a claim model that closes this — for example requiring a signature from the program's deploy authority, or making a verified source claim (below) a precondition for holding the entry. Whatever model is chosen must be documented, and the demo must show an unauthorised claim being rejected. +- [ ] **Update**: only the original registering author may update an existing entry (version, IDL pointer, description, tags). Authorship transfer is optional; if implemented, it must require signatures from both parties. +- [ ] **Global registry state**: a singleton PDA tracking registry-wide state, including the total number of registered programs. +- [ ] **IDL storage on Logos Storage**: the IDL JSON itself is stored on **Logos Storage**, with the on-chain entry holding only the content identifier. Registration tooling must upload the IDL and fill in the identifier in one step; clients must be able to resolve an identifier back to the IDL and validate that it parses. +- [ ] **Discovery**: query an entry by program ID (via PDA derivation, no indexer required), **enumerate the full set of registered entries**, and search by name, author, and tag. Enumeration and search are the criteria most likely to be stubbed out: returning a program count, or an error saying listing "requires an indexer", does not satisfy this. If either requires an indexer, the indexer must be part of the submission, runnable by anyone from the submitted repository against a stock sequencer, and documented; the registry must remain usable for registration, update, and lookup by program ID with the indexer unavailable. Whatever the design, a client must be able to obtain the complete list of entries using only the submitted software. +- [ ] **Reproducible builds**: a documented build toolchain for LEZ programs — pinned container image or equivalent, deterministic compilation — such that an independent third party building the same source at the same commit obtains a byte-identical artifact and a matching hash. Reproducibility is the foundation the rest of the verification story rests on; if builds are not deterministic, nothing above it means anything. +- [ ] **Source verification (bytecode-to-source)**: an entry additionally records a source repository URL, a commit hash, the toolchain version, and a build recipe sufficient to reproduce the deployed bytecode. A verifier — available from the CLI — takes a program ID, fetches the recorded source, rebuilds it, and reports whether the resulting artifact hash matches what is deployed, yielding one of three states: **verified**, **mismatched**, or **unverified** (no source claim recorded). A claim that fails to reproduce must surface as *mismatched*, never silently as *unverified*. +- [ ] **Verification is version-bound**: verification status attaches to a specific deployed artifact. If a program is upgraded or its entry's source claim changes, the prior verified status must be invalidated rather than carried over, so an entry can never show *verified* against code that is no longer what is deployed. +- [ ] **Testnet 0.3**: the registry operates end-to-end against the Logos LEZ zone on Logos testnet 0.3. + +### Usability + +- [ ] Provide a module/SDK usable by other Logos modules and third-party applications to register entries, resolve a program ID to its metadata and IDL, and run searches. This is the primary integration surface — wallets, explorers, and developer tools are the intended consumers. +- [ ] Provide a CLI covering register, update, lookup, search, and source verification. +- [ ] Provide a Logos Basecamp app GUI with local build instructions and loadable assets, supporting at minimum: browsing registered programs, searching, viewing an entry's full metadata and its resolved IDL, viewing verification status, and registering a new program. +- [ ] Logos Basecamp modules 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`. +- [ ] **Verification status is never misleading.** Wherever a UI displays an entry, unverified and mismatched entries must be visually distinguishable from verified ones. Registry metadata is self-asserted by whoever registered it: a name is a claim, not a fact. The UI must not present a self-asserted name in a way that implies the registry vouches for it. +- [ ] **UX quality.** The Basecamp app must be polished and usable by a non-expert: coherent navigation, readable IDL rendering, and clear error/pending states. This is judged against overall impression rather than a checklist; evaluators will use the app as a normal user would. + +### Reliability + +- [ ] An account that is not the recorded author cannot update an entry, and registering a program ID that already has an entry cannot silently overwrite it. +- [ ] Clients degrade gracefully when an IDL identifier is unresolvable or the stored IDL fails to parse: the entry's on-chain metadata still displays, with the IDL surfaced as unavailable rather than the view failing. +- [ ] **No mandatory external services.** Beyond the user's configured sequencer, Logos LEZ node, and Logos Storage, the registry and its tooling must not depend on any third-party web service to function. If one is used, it is disclosed, the user can disable it, and the registry remains fully functional with it disabled. Any analytics must be strictly opt-in. +- [ ] Source verification runs locally: rebuilding a program to check its bytecode hash must not require a hosted build service. + +### Performance + +- [ ] Document compute unit usage for each on-chain operation (register, update). +- [ ] Document lookup latency for resolution by program ID and for a search across a registry populated with at least 500 entries. + +### Supportability + +- [ ] Deployed and tested against Logos testnet 0.3 (the Logos LEZ zone), with the deployed program ID published in the README. +- [ ] The submission builds and runs end-to-end on both **macOS (Apple Silicon)** and **Linux (x86_64)**. The demo script must succeed without modification on both platforms from a clean clone. +- [ ] Logos Basecamp modules are built with [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) (`mkLogosModule`). +- [ ] Provide an IDL for the registry program itself, generated via the [SPEL framework](https://github.com/logos-co/spel) — the registry must be registered in itself. +- [ ] 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, the deployed program ID, and step-by-step usage via CLI and Basecamp app. +- [ ] 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. +- [ ] A reproducible end-to-end demo script works against a real local sequencer with `RISC0_DEV_MODE=0`. + +### Adoption + +> These metrics measure traction attributable to a given submission for this prize. +> +> **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. + +- [ ] **5 third-party tools or applications** integrate the registry SDK to resolve program metadata or IDLs — for example a wallet, an explorer, or a developer tool. Each 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. The 5 must be independent of each other and of the submitting team. +- [ ] **75 stars** on the registry repository. +- [ ] **100 registered programs** on the official Logos zone, registered by **at least 40 distinct author accounts** independent of the submitting team. Entries must point at genuinely deployed programs with resolvable, parseable IDLs; placeholder or duplicate entries pointing at the same underlying program do not count. Accounts with no prior unrelated testnet activity carry little weight. +- [ ] **20 entries carry a verified source claim** — a recorded source repository and commit that an evaluator can independently rebuild to a bytecode hash matching the deployed program ID. Registering metadata is cheap; proving the bytecode matches published source is the part that makes the registry trustworthy, so it is counted separately. +- [ ] **Sustained registration activity**: the 100 registrations must be spread over **at least 2 months**, with **at least 20 new registrations in each of those months**. A single burst of activity does not qualify, however large. Each entry is timestamped on-chain, so this is verified directly from chain data. +- [ ] **30 testimonials on Discord** vouching for the registry. Testimonials should describe what the person actually used the registry for; account history will be checked. +- [ ] **30 testimonials on Twitter/X** vouching for the registry, subject to the same standard and the same account-history check. Sharing screenshots of the registry in use is encouraged. + +## Design Decisions Left to the Submitter + +The following are deliberately not prescribed. A submission must pick a position on each, document it, and justify it — the reasoning is part of what is evaluated. + +- **Is verification permissionless or publisher-gated?** May anyone submit an attestation for any program (Solana's registry is effectively this, with a trusted-signer overlay), or only the entry's author? Permissionless verification is more useful and harder to censor; publisher-gating is simpler to reason about. +- **What lives on-chain?** Full attestations on-chain, or an on-chain hash with build metadata held off-chain on Logos Storage. This trades compute cost against self-containment. +- **Where does verified source live?** The registry proves a hash match, but something must host the code being matched against. A repository URL is a liveness dependency on a third party; mirroring source to Logos Storage avoids that but costs storage and raises the question of who pays. +- **How is a claim authenticated?** See the claim-authorisation criterion above — the mechanism is open, the property is not. + +## Scope + +### In Scope + +- The on-chain LEZ registry program (register, update, global state), built with SPEL. +- IDL storage on Logos Storage and resolution from on-chain content identifiers. +- The reproducible build toolchain for LEZ programs, and the bytecode-to-source verification tooling and on-chain fields backing it. +- A claim-authorisation model binding an entry to a party entitled to hold it. +- Discovery: PDA-derived lookup by program ID, plus search by name, author, and tag (including a self-hostable indexer if search requires one). +- SDK, CLI, and Logos Basecamp app GUI. + +### Out of Scope + +- **Curation, moderation, or a trust score.** The registry records what authors assert plus objectively checkable verification status. Deciding which programs are "good" or delisting entries is a governance question, not part of this prize. +- **Program deployment.** The registry describes already-deployed programs; deploying them is out of scope. +- Package management or dependency resolution between programs. +- Hosting a public indexer as a service — the indexer must be self-hostable, but running one as infrastructure is not part of the deliverable. +- Payment, licensing, or monetisation of registered programs. + +## Prize Structure + +- **Total Prize:** $X +- **Effort:** Large + +## 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. + +## Submission Requirements + +- Public repository with the registry program, SDK, CLI, and Basecamp app GUI under MIT or Apache-2.0. +- The registry's own IDL, and the deployed program ID on Logos testnet 0.3. +- Narrated video walkthrough demonstrating: registering a program end-to-end including IDL upload to Logos Storage, an unauthorised claim being rejected, updating an entry, an update being rejected for a non-author signer, lookup by program ID, full enumeration and search by name/author/tag, resolving and displaying an IDL in the Basecamp app, and a source-verification run showing all three outcomes (verified, mismatched, unverified) — including a rebuild reproducing a matching hash from a clean checkout. The recording must show terminal output including proof generation, to confirm `RISC0_DEV_MODE=0` was active. (A narrated demo is required for every prize: see [demo requirements](../README.md#evaluation-policies).) +- Evidence for each adoption criterion: links to the 5 third-party integrations and their repositories, the registry repository, the on-chain entries (with per-month counts so the sustained-activity criterion can be verified, and the subset carrying verified source claims), and the Discord and Twitter/X testimonials. +- FURPS self-assessment as part of the solution (see [solution template](../solutions/LP-0000.md)). + +## Evaluation Process + +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 will also independently rebuild a sample of the entries claiming verified source and confirm the bytecode hashes match. Evaluators may ask technical follow-up questions to verify authorship and understanding of the implementation. + +The following policies apply to all prizes (see [evaluation policies](../README.md#evaluation-policies)): + +- **Submissions:** each builder (or team) is allowed a maximum of **3 submissions** per prize, with at most **one submission/review per week**. +- **Feedback:** initial evaluation feedback is limited to a pass/fail indication against the success criteria. + +## Resources + +- [SPEL framework](https://github.com/logos-co/spel) — Anchor-inspired developer framework for LEZ programs, used for the program and its IDL +- [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/) +- [LEZ programs repo](https://github.com/logos-blockchain/lez-programs/) +- [`logos-modules-release-base`](https://github.com/logos-co/logos-modules-release-base) and [`logos-modules-release-action`](https://github.com/logos-co/logos-modules-release-action) — module catalog publishing +- [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) — `mkLogosModule` +- [LP-0011](LP-0011.md) — Program development tooling: Rust SDK +- [LP-0021](LP-0021.md) — LEZ Zone Wallet and SDK, a natural consumer of this registry for human-readable transaction previews +- Prior art: [`jimmy-claw/spelbook`](https://github.com/jimmy-claw/spelbook) (formerly `lez-registry` — Rust core, on-chain program, CLI, and the `lez-registry-ffi` workspace member) and [`jimmy-claw/logos-lez-registry-module`](https://github.com/jimmy-claw/logos-lez-registry-module) (Logos Core Qt6 module). Together these implement register, author-gated update, lookup by program ID, IDL upload/download against Logos Storage, a CLI, and a browse/detail/register GUI. They do **not** implement enumeration, name or tag search, claim authorisation, or any form of source verification — listing and name lookup are explicitly stubbed as "requires an off-chain indexer in v1", and `registered_at` is currently always zero. Submissions may build on this prior work subject to its licence, but must credit it clearly and cannot present it as original; the criteria above are written so that the unimplemented parts are where the work actually lies. + +## 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. + +## Potential for Subsequent λ Prizes + +This prize covers the **first adoption tranche** for the registry. A follow-up λPrize is expected with higher adoption thresholds, adapted to the phase the network is in at that time, and may extend the registry toward areas explicitly out of scope here — notably curation and trust signals, once there is enough registry content for those questions to be meaningful. + +This prize also targets Logos testnet 0.3. Should a future testnet version (e.g., V0.4) introduce breaking changes to program IDs, PDA derivation, or the SPEL IDL format, a subsequent λ Prize may be opened to cover adaptation. From 4fab34015dfafb45e2e9e256f4b5d5c536c6f076 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Mon, 17 Aug 2026 15:25:57 +1000 Subject: [PATCH 02/22] LP-0023: incorporate Solana verified-builds prior art 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 --- prizes/LP-0023.md | 51 ++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 42 insertions(+), 9 deletions(-) diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index b44edd84..f8df48ac 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -30,14 +30,15 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti - [ ] **On-chain registry program**: a LEZ program storing registry entries on-chain, built with the [SPEL framework](https://github.com/logos-co/spel), with a published IDL. - [ ] **Register**: any account may register a deployed program ID it controls, supplying at minimum a **name**, **version**, **author** (the registering signer), **description**, **tags**, an **IDL pointer**, and a **registration timestamp**. Each entry is stored in its own PDA, derived deterministically from the program ID so that any client can compute an entry's address without an indexer. The timestamp must reflect real block time — a zkVM guest has no system clock, so it must be supplied by the host and validated on-chain, not hardcoded. -- [ ] **Claim authorisation**: registration must establish that the registrant is entitled to claim the program, rather than granting the author slot to whoever registers first. A naive first-come-first-claim registry is trivially front-run: an attacker registers a popular program ID under a plausible name before its real author does, and permanently owns the entry that wallets and explorers will display. The submission must define and implement a claim model that closes this — for example requiring a signature from the program's deploy authority, or making a verified source claim (below) a precondition for holding the entry. Whatever model is chosen must be documented, and the demo must show an unauthorised claim being rejected. +- [ ] **Canonical vs third-party entries**: the registry must distinguish an entry published by the program's own deploy/upgrade authority from one published by anyone else, and clients must be able to tell which is which without trusting an off-chain service. A registry where the author slot simply goes to whoever registers first is trivially front-run: an attacker registers a popular program ID under a plausible name before its real author does, and permanently owns the entry that wallets and explorers will display. Solana's `program-metadata` solves this by seeding **canonical** accounts from `[program, seed]` — creatable only by the upgrade authority — and **non-canonical** accounts from `[program, authority, seed]`, so anyone may publish metadata about any program while the authority's entry stays unambiguously identifiable. An equivalent construction is required here: at most one canonical entry per program, unlimited third-party entries, and the distinction legible on-chain. Third-party entries must not be silently suppressed — the point is to label them, not to make the registry permissioned. The demo must show an unauthorised attempt to create a *canonical* entry being rejected. - [ ] **Update**: only the original registering author may update an existing entry (version, IDL pointer, description, tags). Authorship transfer is optional; if implemented, it must require signatures from both parties. - [ ] **Global registry state**: a singleton PDA tracking registry-wide state, including the total number of registered programs. - [ ] **IDL storage on Logos Storage**: the IDL JSON itself is stored on **Logos Storage**, with the on-chain entry holding only the content identifier. Registration tooling must upload the IDL and fill in the identifier in one step; clients must be able to resolve an identifier back to the IDL and validate that it parses. - [ ] **Discovery**: query an entry by program ID (via PDA derivation, no indexer required), **enumerate the full set of registered entries**, and search by name, author, and tag. Enumeration and search are the criteria most likely to be stubbed out: returning a program count, or an error saying listing "requires an indexer", does not satisfy this. If either requires an indexer, the indexer must be part of the submission, runnable by anyone from the submitted repository against a stock sequencer, and documented; the registry must remain usable for registration, update, and lookup by program ID with the indexer unavailable. Whatever the design, a client must be able to obtain the complete list of entries using only the submitted software. - [ ] **Reproducible builds**: a documented build toolchain for LEZ programs — pinned container image or equivalent, deterministic compilation — such that an independent third party building the same source at the same commit obtains a byte-identical artifact and a matching hash. Reproducibility is the foundation the rest of the verification story rests on; if builds are not deterministic, nothing above it means anything. -- [ ] **Source verification (bytecode-to-source)**: an entry additionally records a source repository URL, a commit hash, the toolchain version, and a build recipe sufficient to reproduce the deployed bytecode. A verifier — available from the CLI — takes a program ID, fetches the recorded source, rebuilds it, and reports whether the resulting artifact hash matches what is deployed, yielding one of three states: **verified**, **mismatched**, or **unverified** (no source claim recorded). A claim that fails to reproduce must surface as *mismatched*, never silently as *unverified*. -- [ ] **Verification is version-bound**: verification status attaches to a specific deployed artifact. If a program is upgraded or its entry's source claim changes, the prior verified status must be invalidated rather than carried over, so an entry can never show *verified* against code that is no longer what is deployed. +- [ ] **Source verification (bytecode-to-source)**: an entry additionally records a source repository URL, a commit hash, the toolchain version, and the build arguments used, sufficient to reproduce the deployed bytecode. A verifier — available from the CLI — takes a program ID, fetches the recorded source, rebuilds it, and compares the resulting artifact hash against what is deployed. It must report four distinct states, not three: **verified** (claim present, hash matches), **mismatched** (claim present, hash does *not* match), **unverified** (no claim recorded), and **claimed-but-unchecked** (a claim exists but has not yet been rebuilt). Collapsing *mismatched* or *claimed-but-unchecked* into *unverified* is a failure: Solana's explorer treats "PDA uploaded but hash mismatched" as its own state precisely because a claim that fails to reproduce is a stronger negative signal than no claim at all. +- [ ] **A hash match alone is not proof of provenance.** Solana's verified builds were subverted by a repository whose `build.rs` fetched the already-deployed binary at compile time and emitted it as the build output — the hashes matched perfectly, and the explorer showed "Program Source Verified" pointing at the attacker's repo. Any build system that executes arbitrary code during compilation (Rust included, via build scripts and procedural macros) is vulnerable to this. The submission must state how it addresses the attack — whether by binding *verified* status to the deploy authority's own claim, constraining or sandboxing the build, or another mechanism — and must not present a bare hash match from an arbitrary repository as proof that the source is genuine. +- [ ] **Verification is version-bound**: verification status attaches to a specific deployed artifact. If a program is upgraded or its entry's source claim changes, the prior verified status must be invalidated rather than carried over, so an entry can never show *verified* against code that is no longer what is deployed. Solana handles this by re-verifying every program on a 24-hour cycle and un-verifying on detected upgrade; a submission may re-check on read, on upgrade detection, or on a schedule, but must document the staleness window and expose the last-verified point to clients. - [ ] **Testnet 0.3**: the registry operates end-to-end against the Logos LEZ zone on Logos testnet 0.3. ### Usability @@ -46,7 +47,8 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti - [ ] Provide a CLI covering register, update, lookup, search, and source verification. - [ ] Provide a Logos Basecamp app GUI with local build instructions and loadable assets, supporting at minimum: browsing registered programs, searching, viewing an entry's full metadata and its resolved IDL, viewing verification status, and registering a new program. - [ ] Logos Basecamp modules 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`. -- [ ] **Verification status is never misleading.** Wherever a UI displays an entry, unverified and mismatched entries must be visually distinguishable from verified ones. Registry metadata is self-asserted by whoever registered it: a name is a claim, not a fact. The UI must not present a self-asserted name in a way that implies the registry vouches for it. +- [ ] **Verification status is never misleading.** Wherever a UI displays an entry, all four verification states must be visually distinguishable, and a canonical (authority-published) entry must be distinguishable from a third-party one. Registry metadata is self-asserted by whoever registered it: a name is a claim, not a fact. The UI must not present a self-asserted name in a way that implies the registry vouches for it, and must surface the signer behind a verification claim rather than showing a bare "verified" badge — that anonymous badge is exactly what made the Solana attack effective. +- [ ] **Verified does not mean safe.** Any UI or documentation presenting verification status must make clear that a verified build proves only that the deployed bytecode was produced from the stated source. It says nothing about whether that source is secure, audited, or benign. Wording that implies endorsement is a failure of this criterion. - [ ] **UX quality.** The Basecamp app must be polished and usable by a non-expert: coherent navigation, readable IDL rendering, and clear error/pending states. This is judged against overall impression rather than a checklist; evaluators will use the app as a normal user would. ### Reliability @@ -90,10 +92,10 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti The following are deliberately not prescribed. A submission must pick a position on each, document it, and justify it — the reasoning is part of what is evaluated. -- **Is verification permissionless or publisher-gated?** May anyone submit an attestation for any program (Solana's registry is effectively this, with a trusted-signer overlay), or only the entry's author? Permissionless verification is more useful and harder to censor; publisher-gating is simpler to reason about. -- **What lives on-chain?** Full attestations on-chain, or an on-chain hash with build metadata held off-chain on Logos Storage. This trades compute cost against self-containment. -- **Where does verified source live?** The registry proves a hash match, but something must host the code being matched against. A repository URL is a liveness dependency on a third party; mirroring source to Logos Storage avoids that but costs storage and raises the question of who pays. -- **How is a claim authenticated?** See the claim-authorisation criterion above — the mechanism is open, the property is not. +- **What lives on-chain?** Full attestations on-chain, or an on-chain hash with build metadata held off-chain on Logos Storage. Solana's `program-metadata` supports all three of inline (zlib-compressed) data, an external URL, and a pointer to another account; a submission may pick one, but should say why. This trades compute cost against self-containment. +- **Where does verified source live?** The registry proves a hash match, but something must host the code being matched against. A repository URL is a liveness dependency on a third party — Solana's registry inherits exactly this weakness, since a deleted GitHub repo makes re-verification impossible. Mirroring source to Logos Storage avoids that but costs storage and raises the question of who pays. +- **Is there a trusted-signer overlay?** Solana's explorer hardcodes a small list of trusted third-party verifiers (OtterSec, the Explorer itself) that rank above other non-authority signers. This is pragmatic but reintroduces a centralised trust root. A submission may implement something similar, omit it, or make the trusted set user-configurable — but if it ships one, the list must be user-inspectable and overridable. +- **Can entries be made immutable or closed?** Solana's metadata accounts support `set-immutable` and `close`; a closed or mutable-forever entry have different trust properties. Whether a LEZ entry can be frozen, deleted, or reclaimed by a later authority is open. ## Scope @@ -127,7 +129,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho - Public repository with the registry program, SDK, CLI, and Basecamp app GUI under MIT or Apache-2.0. - The registry's own IDL, and the deployed program ID on Logos testnet 0.3. -- Narrated video walkthrough demonstrating: registering a program end-to-end including IDL upload to Logos Storage, an unauthorised claim being rejected, updating an entry, an update being rejected for a non-author signer, lookup by program ID, full enumeration and search by name/author/tag, resolving and displaying an IDL in the Basecamp app, and a source-verification run showing all three outcomes (verified, mismatched, unverified) — including a rebuild reproducing a matching hash from a clean checkout. The recording must show terminal output including proof generation, to confirm `RISC0_DEV_MODE=0` was active. (A narrated demo is required for every prize: see [demo requirements](../README.md#evaluation-policies).) +- Narrated video walkthrough demonstrating: registering a program end-to-end including IDL upload to Logos Storage, an unauthorised claim being rejected, updating an entry, an update being rejected for a non-author signer, lookup by program ID, full enumeration and search by name/author/tag, resolving and displaying an IDL in the Basecamp app, a canonical entry alongside a third-party entry for the same program with the distinction visible in the UI, and a source-verification run showing all four outcomes (verified, mismatched, unverified, claimed-but-unchecked) — including a rebuild reproducing a matching hash from a clean checkout. The recording must show terminal output including proof generation, to confirm `RISC0_DEV_MODE=0` was active. (A narrated demo is required for every prize: see [demo requirements](../README.md#evaluation-policies).) - Evidence for each adoption criterion: links to the 5 third-party integrations and their repositories, the registry repository, the on-chain entries (with per-month counts so the sustained-activity criterion can be verified, and the subset carrying verified source claims), and the Discord and Twitter/X testimonials. - FURPS self-assessment as part of the solution (see [solution template](../solutions/LP-0000.md)). @@ -144,6 +146,25 @@ The following policies apply to all prizes (see [evaluation policies](../README. - **Submissions:** each builder (or team) is allowed a maximum of **3 submissions** per prize, with at most **one submission/review per week**. - **Feedback:** initial evaluation feedback is limited to a pass/fail indication against the success criteria. +## Prior Art in the Solana Ecosystem + +Solana has converged on **three separate systems** where this prize proposes one. That split is itself informative: metadata, verification attestations, and the verification service are distinct concerns with distinct trust models, and a submission that fuses them should be deliberate about it. + +| Concern | Solana | This prize | +|---|---|---| +| Program metadata & IDL | [`solana-program/program-metadata`](https://github.com/solana-program/program-metadata) — PDA per `[program, seed]`, seeds `idl` / `security`; zlib-compressed inline, external URL, or account pointer | One entry PDA per program, IDL on Logos Storage by content ID | +| Verification claims | [`otter-sec/otter-verify`](https://github.com/otter-sec/otter-verify) — on-chain program `verifycLy8…`, PDA per `[b"otter_verify", authority, program]` storing `git_url`, `commit`, `args`, `deploy_slot`, `version` | Same fields folded into the registry entry | +| Build & verify | [`solana-verify` CLI](https://github.com/solana-foundation/solana-verifiable-build), Docker-pinned deterministic builds; [OtterSec API](https://verify.osec.io) re-verifies every 24h | CLI verifier + documented reproducible toolchain | +| Consumer UI | Solana Explorer `VerifiedProgramBadge`: *Verified* / *PDA uploaded, hash mismatch* / *Not verified*, ranked by signer authority | Four states, canonical vs third-party distinction | + +Specific lessons carried into the criteria above: + +- **Seed the authority into the PDA to get permissionless-but-attributable claims.** `otter-verify` derives from `[seed, authority, program]`, so anyone can attest to any program without being able to overwrite anyone else's attestation. `program-metadata` refines this into the canonical/non-canonical split. This is a better answer than either "first-come-first-claim" or "authority-only", and is why that criterion above is now prescriptive. +- **A matching hash is not proof of provenance.** Accretion's [write-up](https://accretion.xyz/blog/verified-builds) showed a `build.rs` that downloads the deployed binary and emits it as the build artifact, producing a perfect hash match from an attacker-controlled repository. The fix was authorisation, not better hashing. +- **Verification decays.** Solana un-verifies on upgrade and re-verifies every 24 hours; verification is a maintained state, not a one-time event. +- **Explorers need a signer, not a badge.** Ranking by signer authority — and showing who signed — is what makes the badge meaningful. +- **The centralisation Solana did not avoid.** Docker images are hosted by the Solana Foundation, the verify program is upgradeable and not frozen, the API is OtterSec-operated, and the trusted-signer list is hardcoded in the explorer. Each is a point where "trustless verification" quietly becomes "trust these parties". A LEZ registry has an opportunity to do better here, and submissions should be judged partly on whether they do. + ## Resources - [SPEL framework](https://github.com/logos-co/spel) — Anchor-inspired developer framework for LEZ programs, used for the program and its IDL @@ -151,6 +172,18 @@ The following policies apply to all prizes (see [evaluation policies](../README. - [LEZ programs repo](https://github.com/logos-blockchain/lez-programs/) - [`logos-modules-release-base`](https://github.com/logos-co/logos-modules-release-base) and [`logos-modules-release-action`](https://github.com/logos-co/logos-modules-release-action) — module catalog publishing - [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) — `mkLogosModule` +Solana prior art (see the comparison above): + +- [Solana verified builds documentation](https://solana.com/docs/programs/verified-builds) and the [verification guide](https://solana.com/developers/guides/advanced/verified-builds) +- [`solana-foundation/solana-verifiable-build`](https://github.com/solana-foundation/solana-verifiable-build) — the `solana-verify` CLI +- [`otter-sec/otter-verify`](https://github.com/otter-sec/otter-verify) — on-chain verification program, and [`otter-sec/solana-verified-programs-api`](https://github.com/otter-sec/solana-verified-programs-api) — the verification service +- [`solana-program/program-metadata`](https://github.com/solana-program/program-metadata) — canonical/non-canonical metadata PDAs +- [`solana-foundation/idl-spec`](https://github.com/solana-foundation/idl-spec) — the standard IDL format +- ["How We Hacked Solana Verified Builds"](https://accretion.xyz/blog/verified-builds) — Accretion, on the `build.rs` provenance attack +- [Solana Explorer verification UI](https://deepwiki.com/solana-foundation/explorer/3.3-program-verification-system) + +Logos: + - [LP-0011](LP-0011.md) — Program development tooling: Rust SDK - [LP-0021](LP-0021.md) — LEZ Zone Wallet and SDK, a natural consumer of this registry for human-readable transaction previews - Prior art: [`jimmy-claw/spelbook`](https://github.com/jimmy-claw/spelbook) (formerly `lez-registry` — Rust core, on-chain program, CLI, and the `lez-registry-ffi` workspace member) and [`jimmy-claw/logos-lez-registry-module`](https://github.com/jimmy-claw/logos-lez-registry-module) (Logos Core Qt6 module). Together these implement register, author-gated update, lookup by program ID, IDL upload/download against Logos Storage, a CLI, and a browse/detail/register GUI. They do **not** implement enumeration, name or tag search, claim authorisation, or any form of source verification — listing and name lookup are explicitly stubbed as "requires an off-chain indexer in v1", and `registered_at` is currently always zero. Submissions may build on this prior work subject to its licence, but must credit it clearly and cannot present it as original; the criteria above are written so that the unimplemented parts are where the work actually lies. From 2d6cbbbd1ad02c119fb227a2bf85e92b288e334f Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Mon, 24 Aug 2026 15:22:42 +1000 Subject: [PATCH 03/22] LP-0023: shift criteria toward product outcomes over implementation 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). --- prizes/LP-0023.md | 63 +++++++++++++++++++++++------------------------ 1 file changed, 31 insertions(+), 32 deletions(-) diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index f8df48ac..57474afc 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -10,17 +10,17 @@ dependencies: [] ## Overview -This prize is for an on-chain program registry for the Logos Execution Zone (LEZ): a LEZ program that lets developers publish their deployed program IDs together with human-readable metadata and a pointer to the program's IDL, plus the tooling to browse, search, and register through a CLI, an SDK, and a Logos Basecamp app. +This prize is for a program registry for the Logos Execution Zone (LEZ): a product that lets developers publish their deployed programs together with human-readable metadata and a pointer to the program's IDL, and lets anyone browse, search, and verify those entries through a CLI, an SDK, and a Logos Basecamp app. A LEZ program is identified on-chain by an opaque program ID. Nothing about that ID tells a user what the program does, who wrote it, what its interface looks like, or whether the bytecode matches any published source. The registry closes that gap: it turns an opaque program ID into a discoverable entry with a name, a version, an author, a description, tags, and a resolvable IDL, so that both humans and tooling can make sense of what they are about to interact with. ## Motivation -Every part of the LEZ developer experience currently assumes you already know which program you want and already have its IDL on disk. A wallet showing a transaction can only render raw calldata. A block explorer can only show a program ID. A developer looking for an existing token or governance program has no place to look. Each tool that needs this information ends up shipping its own hardcoded list, and those lists drift apart. +Every part of the LEZ developer experience currently assumes you already know which program you want and already have its IDL on disk. A wallet showing a transaction can only render raw calldata. A block explorer can show a program ID and its raw bytecode, but nothing that makes either one meaningful to a human — no name, no author, no interface, no way to tell what source, if any, produced it. A developer looking for an existing token or governance program has no place to look. Each tool that needs this information ends up shipping its own hardcoded list, and those lists drift apart. -Metadata alone, though, is only half the problem. Anyone can claim anything about a program they register, so a registry that records unverified assertions moves the trust problem rather than solving it. The part that carries real weight is proving that a deployed program's bytecode was built from published source: that is what lets a wallet show "verified, built from `github.com/x/y` at commit `abc`" next to a program a user is about to sign for, links an audit report to the artifact actually deployed, and lets integrators pin against verified code rather than an address someone handed them. This matters more on LEZ than on a transparent chain — privacy-preserving programs leave less on-chain state to inspect after the fact, so verifiability of the code itself carries more of the trust budget. The closest analogues are Solana's verified builds (`solana-verify` plus the OtterSec registry) and Etherscan source verification. +Metadata alone is only half the problem. Anyone can claim anything about a program they register, so a registry that records unverified assertions moves the trust problem rather than solving it. What carries real weight is proving that a deployed program's bytecode was built from the source it claims: that is what lets a wallet show "verified, built from `github.com/x/y` at commit `abc`" next to a program a user is about to sign for, links an audit report to the artifact actually deployed, and lets integrators pin against verified code rather than an address someone handed them. The closest analogue is Solana's verified-builds ecosystem and Etherscan source verification. -A registry is exactly the kind of shared substrate that benefits from being built once, on-chain, and consumed by everything else — and exactly the kind of thing that fails if it launches empty. That is why this prize is weighted toward adoption: a registry with three entries is worse than no registry, because it teaches developers that looking things up there is a waste of time. The prize therefore requires both a working implementation and a genuine base of registered programs and integrating tools. +A registry is the kind of shared substrate that benefits from being built once and consumed by everything else. The prize therefore requires both a working product and a genuine base of registered programs and integrating tools, per the standard adoption evaluation policy for **λ**Prize submissions. The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anticipate this work: they allow, but do not require, a wallet to surface registry metadata when previewing a smart-contract interaction. Landing this registry makes that possible. @@ -28,17 +28,16 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti ### Functionality -- [ ] **On-chain registry program**: a LEZ program storing registry entries on-chain, built with the [SPEL framework](https://github.com/logos-co/spel), with a published IDL. -- [ ] **Register**: any account may register a deployed program ID it controls, supplying at minimum a **name**, **version**, **author** (the registering signer), **description**, **tags**, an **IDL pointer**, and a **registration timestamp**. Each entry is stored in its own PDA, derived deterministically from the program ID so that any client can compute an entry's address without an indexer. The timestamp must reflect real block time — a zkVM guest has no system clock, so it must be supplied by the host and validated on-chain, not hardcoded. -- [ ] **Canonical vs third-party entries**: the registry must distinguish an entry published by the program's own deploy/upgrade authority from one published by anyone else, and clients must be able to tell which is which without trusting an off-chain service. A registry where the author slot simply goes to whoever registers first is trivially front-run: an attacker registers a popular program ID under a plausible name before its real author does, and permanently owns the entry that wallets and explorers will display. Solana's `program-metadata` solves this by seeding **canonical** accounts from `[program, seed]` — creatable only by the upgrade authority — and **non-canonical** accounts from `[program, authority, seed]`, so anyone may publish metadata about any program while the authority's entry stays unambiguously identifiable. An equivalent construction is required here: at most one canonical entry per program, unlimited third-party entries, and the distinction legible on-chain. Third-party entries must not be silently suppressed — the point is to label them, not to make the registry permissioned. The demo must show an unauthorised attempt to create a *canonical* entry being rejected. +- [ ] **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. +- [ ] **Register**: any account may register a deployed program it controls, supplying at minimum a **name**, **version**, **author**, **description**, **tags**, an **IDL pointer**, and a **registration timestamp**. Lookup of an entry must not depend on an indexer. The timestamp must reflect real block time, not a value supplied unchecked by the client. +- [ ] **Deployer vs third-party entries**: the registry may hold both an entry from the program's own deployer and entries from third parties. The deployer's entry must be signed by the account that deployed the program, and clients must be able to tell it apart from a third-party entry without trusting an off-chain service. Either way, source verification (below) should be used to confirm the recorded claim actually matches the deployed program. The demo must show an unauthorised attempt to create a deployer entry being rejected. - [ ] **Update**: only the original registering author may update an existing entry (version, IDL pointer, description, tags). Authorship transfer is optional; if implemented, it must require signatures from both parties. -- [ ] **Global registry state**: a singleton PDA tracking registry-wide state, including the total number of registered programs. -- [ ] **IDL storage on Logos Storage**: the IDL JSON itself is stored on **Logos Storage**, with the on-chain entry holding only the content identifier. Registration tooling must upload the IDL and fill in the identifier in one step; clients must be able to resolve an identifier back to the IDL and validate that it parses. -- [ ] **Discovery**: query an entry by program ID (via PDA derivation, no indexer required), **enumerate the full set of registered entries**, and search by name, author, and tag. Enumeration and search are the criteria most likely to be stubbed out: returning a program count, or an error saying listing "requires an indexer", does not satisfy this. If either requires an indexer, the indexer must be part of the submission, runnable by anyone from the submitted repository against a stock sequencer, and documented; the registry must remain usable for registration, update, and lookup by program ID with the indexer unavailable. Whatever the design, a client must be able to obtain the complete list of entries using only the submitted software. -- [ ] **Reproducible builds**: a documented build toolchain for LEZ programs — pinned container image or equivalent, deterministic compilation — such that an independent third party building the same source at the same commit obtains a byte-identical artifact and a matching hash. Reproducibility is the foundation the rest of the verification story rests on; if builds are not deterministic, nothing above it means anything. -- [ ] **Source verification (bytecode-to-source)**: an entry additionally records a source repository URL, a commit hash, the toolchain version, and the build arguments used, sufficient to reproduce the deployed bytecode. A verifier — available from the CLI — takes a program ID, fetches the recorded source, rebuilds it, and compares the resulting artifact hash against what is deployed. It must report four distinct states, not three: **verified** (claim present, hash matches), **mismatched** (claim present, hash does *not* match), **unverified** (no claim recorded), and **claimed-but-unchecked** (a claim exists but has not yet been rebuilt). Collapsing *mismatched* or *claimed-but-unchecked* into *unverified* is a failure: Solana's explorer treats "PDA uploaded but hash mismatched" as its own state precisely because a claim that fails to reproduce is a stronger negative signal than no claim at all. -- [ ] **A hash match alone is not proof of provenance.** Solana's verified builds were subverted by a repository whose `build.rs` fetched the already-deployed binary at compile time and emitted it as the build output — the hashes matched perfectly, and the explorer showed "Program Source Verified" pointing at the attacker's repo. Any build system that executes arbitrary code during compilation (Rust included, via build scripts and procedural macros) is vulnerable to this. The submission must state how it addresses the attack — whether by binding *verified* status to the deploy authority's own claim, constraining or sandboxing the build, or another mechanism — and must not present a bare hash match from an arbitrary repository as proof that the source is genuine. -- [ ] **Verification is version-bound**: verification status attaches to a specific deployed artifact. If a program is upgraded or its entry's source claim changes, the prior verified status must be invalidated rather than carried over, so an entry can never show *verified* against code that is no longer what is deployed. Solana handles this by re-verifying every program on a 24-hour cycle and un-verifying on detected upgrade; a submission may re-check on read, on upgrade detection, or on a schedule, but must document the staleness window and expose the last-verified point to clients. +- [ ] **IDL publishing**: the IDL is stored on **Logos Storage**, with the on-chain entry holding a pointer to it, resolvable back to a parseable IDL. +- [ ] **Discovery**: look up an entry by program ID, enumerate the full set of registered entries, and search by name, author, and tag, using only the submitted software. Registration, update, and lookup by program ID must remain usable even if any indexing component is unavailable. +- [ ] **Reproducible builds**: a documented build process for LEZ programs such that an independent third party building the same source at the same commit obtains a byte-identical artifact and a matching hash. Reproducibility is the foundation the rest of the verification story rests on. +- [ ] **Source verification**: an entry can additionally record a pointer to source (code stays off-chain), a commit, and a build configuration sufficient to reproduce the deployed bytecode. A verifier, available from the CLI, takes a program ID, rebuilds the recorded source, and reports one of four states: **verified** (claim present, hash matches), **mismatched** (claim present, hash does not match), **unverified** (no claim recorded), and **claimed-but-unchecked** (a claim exists but has not yet been rebuilt). Collapsing *mismatched* or *claimed-but-unchecked* into *unverified* is a failure: a claim that fails to reproduce is a stronger negative signal than no claim at all. +- [ ] **A hash match alone is not proof of provenance.** A build process that can execute arbitrary code at build time can be made to simply emit the already-deployed binary, producing a hash match without the deployed bytecode actually coming from the stated source. The submission must state how it defends against this, and must not present a bare hash match from an arbitrary repository as proof that the source is genuine. +- [ ] **Verification is version-bound**: verification status attaches to a specific deployed artifact. If a program is upgraded or its entry's source claim changes, the prior verified status must be invalidated rather than carried over, so an entry can never show *verified* against code that is no longer what is deployed. The submission must document its staleness window and expose the last-verified point to clients. - [ ] **Testnet 0.3**: the registry operates end-to-end against the Logos LEZ zone on Logos testnet 0.3. ### Usability @@ -46,8 +45,7 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti - [ ] Provide a module/SDK usable by other Logos modules and third-party applications to register entries, resolve a program ID to its metadata and IDL, and run searches. This is the primary integration surface — wallets, explorers, and developer tools are the intended consumers. - [ ] Provide a CLI covering register, update, lookup, search, and source verification. - [ ] Provide a Logos Basecamp app GUI with local build instructions and loadable assets, supporting at minimum: browsing registered programs, searching, viewing an entry's full metadata and its resolved IDL, viewing verification status, and registering a new program. -- [ ] Logos Basecamp modules 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`. -- [ ] **Verification status is never misleading.** Wherever a UI displays an entry, all four verification states must be visually distinguishable, and a canonical (authority-published) entry must be distinguishable from a third-party one. Registry metadata is self-asserted by whoever registered it: a name is a claim, not a fact. The UI must not present a self-asserted name in a way that implies the registry vouches for it, and must surface the signer behind a verification claim rather than showing a bare "verified" badge — that anonymous badge is exactly what made the Solana attack effective. +- [ ] **Verification status is never misleading.** Wherever a UI displays an entry, all four verification states must be visually distinguishable, and a deployer-published entry must be distinguishable from a third-party one. Registry metadata is self-asserted by whoever registered it: a name is a claim, not a fact. The UI must not present a self-asserted name in a way that implies the registry vouches for it, and must surface the signer behind a verification claim rather than showing a bare "verified" badge. - [ ] **Verified does not mean safe.** Any UI or documentation presenting verification status must make clear that a verified build proves only that the deployed bytecode was produced from the stated source. It says nothing about whether that source is secure, audited, or benign. Wording that implies endorsement is a failure of this criterion. - [ ] **UX quality.** The Basecamp app must be polished and usable by a non-expert: coherent navigation, readable IDL rendering, and clear error/pending states. This is judged against overall impression rather than a checklist; evaluators will use the app as a normal user would. @@ -92,8 +90,8 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti The following are deliberately not prescribed. A submission must pick a position on each, document it, and justify it — the reasoning is part of what is evaluated. -- **What lives on-chain?** Full attestations on-chain, or an on-chain hash with build metadata held off-chain on Logos Storage. Solana's `program-metadata` supports all three of inline (zlib-compressed) data, an external URL, and a pointer to another account; a submission may pick one, but should say why. This trades compute cost against self-containment. -- **Where does verified source live?** The registry proves a hash match, but something must host the code being matched against. A repository URL is a liveness dependency on a third party — Solana's registry inherits exactly this weakness, since a deleted GitHub repo makes re-verification impossible. Mirroring source to Logos Storage avoids that but costs storage and raises the question of who pays. +- **What lives on-chain?** Source code and the IDL must live off-chain, on Logos Storage; the on-chain entry holds pointers, not the content itself. Beyond that minimum, a submission decides how much attestation data to keep on-chain versus off-chain, and should account for the gas cost of what it chooses to store on-chain. +- **How is verified source hosted?** The registry proves a hash match, but something must host the code being matched against. A submission may point at a third-party repository, mirror source to Logos Storage, or both, but should say why. A repository URL alone is a liveness dependency on a third party: a deleted GitHub repo makes re-verification impossible, which is a weakness Solana's registry inherits. - **Is there a trusted-signer overlay?** Solana's explorer hardcodes a small list of trusted third-party verifiers (OtterSec, the Explorer itself) that rank above other non-authority signers. This is pragmatic but reintroduces a centralised trust root. A submission may implement something similar, omit it, or make the trusted set user-configurable — but if it ships one, the list must be user-inspectable and overridable. - **Can entries be made immutable or closed?** Solana's metadata accounts support `set-immutable` and `close`; a closed or mutable-forever entry have different trust properties. Whether a LEZ entry can be frozen, deleted, or reclaimed by a later authority is open. @@ -101,11 +99,11 @@ The following are deliberately not prescribed. A submission must pick a position ### In Scope -- The on-chain LEZ registry program (register, update, global state), built with SPEL. -- IDL storage on Logos Storage and resolution from on-chain content identifiers. -- The reproducible build toolchain for LEZ programs, and the bytecode-to-source verification tooling and on-chain fields backing it. -- A claim-authorisation model binding an entry to a party entitled to hold it. -- Discovery: PDA-derived lookup by program ID, plus search by name, author, and tag (including a self-hostable indexer if search requires one). +- 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. +- A claim-authorisation model distinguishing a program's own deployer from third-party registrants. +- Discovery: lookup by program ID, plus search by name, author, and tag (including a self-hostable indexer if search requires one). - SDK, CLI, and Logos Basecamp app GUI. ### Out of Scope @@ -129,7 +127,8 @@ Open to any individual or team. Submissions must be original work. Teams must ho - Public repository with the registry program, SDK, CLI, and Basecamp app GUI under MIT or Apache-2.0. - The registry's own IDL, and the deployed program ID on Logos testnet 0.3. -- Narrated video walkthrough demonstrating: registering a program end-to-end including IDL upload to Logos Storage, an unauthorised claim being rejected, updating an entry, an update being rejected for a non-author signer, lookup by program ID, full enumeration and search by name/author/tag, resolving and displaying an IDL in the Basecamp app, a canonical entry alongside a third-party entry for the same program with the distinction visible in the UI, and a source-verification run showing all four outcomes (verified, mismatched, unverified, claimed-but-unchecked) — including a rebuild reproducing a matching hash from a clean checkout. The recording must show terminal output including proof generation, to confirm `RISC0_DEV_MODE=0` was active. (A narrated demo is required for every prize: see [demo requirements](../README.md#evaluation-policies).) +- The Basecamp app 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 so evaluators can install the module through the package-manager UI / `lgpd`. +- Narrated video walkthrough demonstrating: registering a program end-to-end including IDL upload to Logos Storage, an unauthorised claim being rejected, updating an entry, an update being rejected for a non-author signer, lookup by program ID, full enumeration and search by name/author/tag, resolving and displaying an IDL in the Basecamp app, a deployer entry alongside a third-party entry for the same program with the distinction visible in the UI, and a source-verification run showing all four outcomes (verified, mismatched, unverified, claimed-but-unchecked) — including a rebuild reproducing a matching hash from a clean checkout. The recording must show terminal output including proof generation, to confirm `RISC0_DEV_MODE=0` was active. (A narrated demo is required for every prize: see [demo requirements](../README.md#evaluation-policies).) - Evidence for each adoption criterion: links to the 5 third-party integrations and their repositories, the registry repository, the on-chain entries (with per-month counts so the sustained-activity criterion can be verified, and the subset carrying verified source claims), and the Discord and Twitter/X testimonials. - FURPS self-assessment as part of the solution (see [solution template](../solutions/LP-0000.md)). @@ -152,18 +151,18 @@ Solana has converged on **three separate systems** where this prize proposes one | Concern | Solana | This prize | |---|---|---| -| Program metadata & IDL | [`solana-program/program-metadata`](https://github.com/solana-program/program-metadata) — PDA per `[program, seed]`, seeds `idl` / `security`; zlib-compressed inline, external URL, or account pointer | One entry PDA per program, IDL on Logos Storage by content ID | -| Verification claims | [`otter-sec/otter-verify`](https://github.com/otter-sec/otter-verify) — on-chain program `verifycLy8…`, PDA per `[b"otter_verify", authority, program]` storing `git_url`, `commit`, `args`, `deploy_slot`, `version` | Same fields folded into the registry entry | -| Build & verify | [`solana-verify` CLI](https://github.com/solana-foundation/solana-verifiable-build), Docker-pinned deterministic builds; [OtterSec API](https://verify.osec.io) re-verifies every 24h | CLI verifier + documented reproducible toolchain | -| Consumer UI | Solana Explorer `VerifiedProgramBadge`: *Verified* / *PDA uploaded, hash mismatch* / *Not verified*, ranked by signer authority | Four states, canonical vs third-party distinction | +| Program metadata & IDL | [`solana-program/program-metadata`](https://github.com/solana-program/program-metadata): metadata account per program, supporting inline data, an external URL, or an account pointer | One entry per program, IDL on Logos Storage | +| Verification claims | [`otter-sec/otter-verify`](https://github.com/otter-sec/otter-verify): on-chain claims storing repository, commit, build args, and deploy slot | Same fields folded into the registry entry | +| Build & verify | [`solana-verify` CLI](https://github.com/solana-foundation/solana-verifiable-build), Docker-pinned deterministic builds; the [OtterSec API](https://verify.osec.io) re-verifies every 24h | CLI verifier and a documented reproducible build process | +| Consumer UI | Solana Explorer's badge: *Verified* / *PDA uploaded, hash mismatch* / *Not verified*, ranked by signer authority | Four states, deployer vs third-party distinction | Specific lessons carried into the criteria above: -- **Seed the authority into the PDA to get permissionless-but-attributable claims.** `otter-verify` derives from `[seed, authority, program]`, so anyone can attest to any program without being able to overwrite anyone else's attestation. `program-metadata` refines this into the canonical/non-canonical split. This is a better answer than either "first-come-first-claim" or "authority-only", and is why that criterion above is now prescriptive. -- **A matching hash is not proof of provenance.** Accretion's [write-up](https://accretion.xyz/blog/verified-builds) showed a `build.rs` that downloads the deployed binary and emits it as the build artifact, producing a perfect hash match from an attacker-controlled repository. The fix was authorisation, not better hashing. +- **Attribute claims to a signer without requiring exclusivity.** Solana's model lets anyone attest to any program while keeping the program's own authority unambiguously identifiable, rather than granting the author slot to whoever registers first. That is a better answer than either "first-come-first-claim" or "authority-only". +- **A matching hash is not proof of provenance.** Accretion's [write-up](https://accretion.xyz/blog/verified-builds) showed a build script that downloads the deployed binary and emits it as the build artifact, producing a perfect hash match from an attacker-controlled repository. The fix is authorisation, not better hashing. - **Verification decays.** Solana un-verifies on upgrade and re-verifies every 24 hours; verification is a maintained state, not a one-time event. -- **Explorers need a signer, not a badge.** Ranking by signer authority — and showing who signed — is what makes the badge meaningful. -- **The centralisation Solana did not avoid.** Docker images are hosted by the Solana Foundation, the verify program is upgradeable and not frozen, the API is OtterSec-operated, and the trusted-signer list is hardcoded in the explorer. Each is a point where "trustless verification" quietly becomes "trust these parties". A LEZ registry has an opportunity to do better here, and submissions should be judged partly on whether they do. +- **Explorers need a signer, not a badge.** Ranking by signer authority, and showing who signed, is what makes the badge meaningful. +- **The centralisation Solana did not avoid.** Docker images are hosted by the Solana Foundation, the verify program is upgradeable and not frozen, the API is OtterSec-operated, and the trusted-signer list is hardcoded in the explorer. Each is a point where "trustless verification" quietly becomes "trust these parties", and a LEZ registry has an opportunity to do better. ## Resources From 8ed082d27a4369668fe728f9ed8c8c227f66b896 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Mon, 24 Aug 2026 15:38:41 +1000 Subject: [PATCH 04/22] LP-0023: mention source code alongside IDL in Overview The registry points to both the IDL and source code; the Overview only named the IDL. --- prizes/LP-0023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index 57474afc..9d4558e0 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -10,7 +10,7 @@ dependencies: [] ## Overview -This prize is for a program registry for the Logos Execution Zone (LEZ): a product that lets developers publish their deployed programs together with human-readable metadata and a pointer to the program's IDL, and lets anyone browse, search, and verify those entries through a CLI, an SDK, and a Logos Basecamp app. +This prize is for a program registry for the Logos Execution Zone (LEZ): a product that lets developers publish their deployed programs together with human-readable metadata and a pointer to the program's IDL and source code, and lets anyone browse, search, and verify those entries through a CLI, an SDK, and a Logos Basecamp app. A LEZ program is identified on-chain by an opaque program ID. Nothing about that ID tells a user what the program does, who wrote it, what its interface looks like, or whether the bytecode matches any published source. The registry closes that gap: it turns an opaque program ID into a discoverable entry with a name, a version, an author, a description, tags, and a resolvable IDL, so that both humans and tooling can make sense of what they are about to interact with. From 3d3c1792a74f746f7a0bf8226d0d562357370c27 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Mon, 24 Aug 2026 15:40:08 +1000 Subject: [PATCH 05/22] LP-0023: humanize-prose pass, strip em-dash overuse MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --- prizes/LP-0023.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index 9d4558e0..cd82ec4b 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -16,11 +16,11 @@ A LEZ program is identified on-chain by an opaque program ID. Nothing about that ## Motivation -Every part of the LEZ developer experience currently assumes you already know which program you want and already have its IDL on disk. A wallet showing a transaction can only render raw calldata. A block explorer can show a program ID and its raw bytecode, but nothing that makes either one meaningful to a human — no name, no author, no interface, no way to tell what source, if any, produced it. A developer looking for an existing token or governance program has no place to look. Each tool that needs this information ends up shipping its own hardcoded list, and those lists drift apart. +Every part of the LEZ developer experience currently assumes you already know which program you want and already have its IDL on disk. A wallet showing a transaction can only render raw calldata. A block explorer can show a program ID and its raw bytecode, but nothing that makes either one meaningful to a human: no name, no author, no interface, no way to tell what source, if any, produced it. A developer looking for an existing token or governance program has no place to look. Each tool that needs this information ends up shipping its own hardcoded list, and those lists drift apart. Metadata alone is only half the problem. Anyone can claim anything about a program they register, so a registry that records unverified assertions moves the trust problem rather than solving it. What carries real weight is proving that a deployed program's bytecode was built from the source it claims: that is what lets a wallet show "verified, built from `github.com/x/y` at commit `abc`" next to a program a user is about to sign for, links an audit report to the artifact actually deployed, and lets integrators pin against verified code rather than an address someone handed them. The closest analogue is Solana's verified-builds ecosystem and Etherscan source verification. -A registry is the kind of shared substrate that benefits from being built once and consumed by everything else. The prize therefore requires both a working product and a genuine base of registered programs and integrating tools, per the standard adoption evaluation policy for **λ**Prize submissions. +A registry is the kind of shared substrate that benefits from being built once and consumed by everything else. The prize therefore requires both a working product and a genuine base of registered programs and integrating tools. The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anticipate this work: they allow, but do not require, a wallet to surface registry metadata when previewing a smart-contract interaction. Landing this registry makes that possible. @@ -42,7 +42,7 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti ### Usability -- [ ] Provide a module/SDK usable by other Logos modules and third-party applications to register entries, resolve a program ID to its metadata and IDL, and run searches. This is the primary integration surface — wallets, explorers, and developer tools are the intended consumers. +- [ ] Provide a module/SDK usable by other Logos modules and third-party applications to register entries, resolve a program ID to its metadata and IDL, and run searches. This is the primary integration surface: wallets, explorers, and developer tools are the intended consumers. - [ ] Provide a CLI covering register, update, lookup, search, and source verification. - [ ] Provide a Logos Basecamp app GUI with local build instructions and loadable assets, supporting at minimum: browsing registered programs, searching, viewing an entry's full metadata and its resolved IDL, viewing verification status, and registering a new program. - [ ] **Verification status is never misleading.** Wherever a UI displays an entry, all four verification states must be visually distinguishable, and a deployer-published entry must be distinguishable from a third-party one. Registry metadata is self-asserted by whoever registered it: a name is a claim, not a fact. The UI must not present a self-asserted name in a way that implies the registry vouches for it, and must surface the signer behind a verification claim rather than showing a bare "verified" badge. @@ -66,7 +66,7 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti - [ ] Deployed and tested against Logos testnet 0.3 (the Logos LEZ zone), with the deployed program ID published in the README. - [ ] The submission builds and runs end-to-end on both **macOS (Apple Silicon)** and **Linux (x86_64)**. The demo script must succeed without modification on both platforms from a clean clone. - [ ] Logos Basecamp modules are built with [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) (`mkLogosModule`). -- [ ] Provide an IDL for the registry program itself, generated via the [SPEL framework](https://github.com/logos-co/spel) — the registry must be registered in itself. +- [ ] Provide an IDL for the registry program itself, generated via the [SPEL framework](https://github.com/logos-co/spel): the registry must be registered in itself. - [ ] 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, the deployed program ID, and step-by-step usage via CLI and Basecamp app. - [ ] 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. @@ -78,21 +78,21 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti > > **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. -- [ ] **5 third-party tools or applications** integrate the registry SDK to resolve program metadata or IDLs — for example a wallet, an explorer, or a developer tool. Each 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. The 5 must be independent of each other and of the submitting team. +- [ ] **5 third-party tools or applications** integrate the registry SDK to resolve program metadata or IDLs, for example a wallet, an explorer, or a developer tool. Each 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. The 5 must be independent of each other and of the submitting team. - [ ] **75 stars** on the registry repository. - [ ] **100 registered programs** on the official Logos zone, registered by **at least 40 distinct author accounts** independent of the submitting team. Entries must point at genuinely deployed programs with resolvable, parseable IDLs; placeholder or duplicate entries pointing at the same underlying program do not count. Accounts with no prior unrelated testnet activity carry little weight. -- [ ] **20 entries carry a verified source claim** — a recorded source repository and commit that an evaluator can independently rebuild to a bytecode hash matching the deployed program ID. Registering metadata is cheap; proving the bytecode matches published source is the part that makes the registry trustworthy, so it is counted separately. +- [ ] **20 entries carry a verified source claim**: a recorded source repository and commit that an evaluator can independently rebuild to a bytecode hash matching the deployed program ID. Registering metadata is cheap; proving the bytecode matches published source is the part that makes the registry trustworthy, so it is counted separately. - [ ] **Sustained registration activity**: the 100 registrations must be spread over **at least 2 months**, with **at least 20 new registrations in each of those months**. A single burst of activity does not qualify, however large. Each entry is timestamped on-chain, so this is verified directly from chain data. - [ ] **30 testimonials on Discord** vouching for the registry. Testimonials should describe what the person actually used the registry for; account history will be checked. - [ ] **30 testimonials on Twitter/X** vouching for the registry, subject to the same standard and the same account-history check. Sharing screenshots of the registry in use is encouraged. ## Design Decisions Left to the Submitter -The following are deliberately not prescribed. A submission must pick a position on each, document it, and justify it — the reasoning is part of what is evaluated. +The following are deliberately not prescribed. A submission must pick a position on each, document it, and justify it: the reasoning is part of what is evaluated. - **What lives on-chain?** Source code and the IDL must live off-chain, on Logos Storage; the on-chain entry holds pointers, not the content itself. Beyond that minimum, a submission decides how much attestation data to keep on-chain versus off-chain, and should account for the gas cost of what it chooses to store on-chain. - **How is verified source hosted?** The registry proves a hash match, but something must host the code being matched against. A submission may point at a third-party repository, mirror source to Logos Storage, or both, but should say why. A repository URL alone is a liveness dependency on a third party: a deleted GitHub repo makes re-verification impossible, which is a weakness Solana's registry inherits. -- **Is there a trusted-signer overlay?** Solana's explorer hardcodes a small list of trusted third-party verifiers (OtterSec, the Explorer itself) that rank above other non-authority signers. This is pragmatic but reintroduces a centralised trust root. A submission may implement something similar, omit it, or make the trusted set user-configurable — but if it ships one, the list must be user-inspectable and overridable. +- **Is there a trusted-signer overlay?** Solana's explorer hardcodes a small list of trusted third-party verifiers (OtterSec, the Explorer itself) that rank above other non-authority signers. This is pragmatic but reintroduces a centralised trust root. A submission may implement something similar, omit it, or make the trusted set user-configurable, but if it ships one, the list must be user-inspectable and overridable. - **Can entries be made immutable or closed?** Solana's metadata accounts support `set-immutable` and `close`; a closed or mutable-forever entry have different trust properties. Whether a LEZ entry can be frozen, deleted, or reclaimed by a later authority is open. ## Scope @@ -111,7 +111,7 @@ The following are deliberately not prescribed. A submission must pick a position - **Curation, moderation, or a trust score.** The registry records what authors assert plus objectively checkable verification status. Deciding which programs are "good" or delisting entries is a governance question, not part of this prize. - **Program deployment.** The registry describes already-deployed programs; deploying them is out of scope. - Package management or dependency resolution between programs. -- Hosting a public indexer as a service — the indexer must be self-hostable, but running one as infrastructure is not part of the deliverable. +- Hosting a public indexer as a service. The indexer must be self-hostable, but running one as infrastructure is not part of the deliverable. - Payment, licensing, or monetisation of registered programs. ## Prize Structure @@ -128,7 +128,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho - Public repository with the registry program, SDK, CLI, and Basecamp app GUI under MIT or Apache-2.0. - The registry's own IDL, and the deployed program ID on Logos testnet 0.3. - The Basecamp app 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 so evaluators can install the module through the package-manager UI / `lgpd`. -- Narrated video walkthrough demonstrating: registering a program end-to-end including IDL upload to Logos Storage, an unauthorised claim being rejected, updating an entry, an update being rejected for a non-author signer, lookup by program ID, full enumeration and search by name/author/tag, resolving and displaying an IDL in the Basecamp app, a deployer entry alongside a third-party entry for the same program with the distinction visible in the UI, and a source-verification run showing all four outcomes (verified, mismatched, unverified, claimed-but-unchecked) — including a rebuild reproducing a matching hash from a clean checkout. The recording must show terminal output including proof generation, to confirm `RISC0_DEV_MODE=0` was active. (A narrated demo is required for every prize: see [demo requirements](../README.md#evaluation-policies).) +- Narrated video walkthrough demonstrating: registering a program end-to-end including IDL upload to Logos Storage, an unauthorised claim being rejected, updating an entry, an update being rejected for a non-author signer, lookup by program ID, full enumeration and search by name/author/tag, resolving and displaying an IDL in the Basecamp app, a deployer entry alongside a third-party entry for the same program with the distinction visible in the UI, and a source-verification run showing all four outcomes (verified, mismatched, unverified, claimed-but-unchecked), including a rebuild reproducing a matching hash from a clean checkout. The recording must show terminal output including proof generation, to confirm `RISC0_DEV_MODE=0` was active. (A narrated demo is required for every prize: see [demo requirements](../README.md#evaluation-policies).) - Evidence for each adoption criterion: links to the 5 third-party integrations and their repositories, the registry repository, the on-chain entries (with per-month counts so the sustained-activity criterion can be verified, and the subset carrying verified source claims), and the Discord and Twitter/X testimonials. - FURPS self-assessment as part of the solution (see [solution template](../solutions/LP-0000.md)). @@ -185,14 +185,14 @@ Logos: - [LP-0011](LP-0011.md) — Program development tooling: Rust SDK - [LP-0021](LP-0021.md) — LEZ Zone Wallet and SDK, a natural consumer of this registry for human-readable transaction previews -- Prior art: [`jimmy-claw/spelbook`](https://github.com/jimmy-claw/spelbook) (formerly `lez-registry` — Rust core, on-chain program, CLI, and the `lez-registry-ffi` workspace member) and [`jimmy-claw/logos-lez-registry-module`](https://github.com/jimmy-claw/logos-lez-registry-module) (Logos Core Qt6 module). Together these implement register, author-gated update, lookup by program ID, IDL upload/download against Logos Storage, a CLI, and a browse/detail/register GUI. They do **not** implement enumeration, name or tag search, claim authorisation, or any form of source verification — listing and name lookup are explicitly stubbed as "requires an off-chain indexer in v1", and `registered_at` is currently always zero. Submissions may build on this prior work subject to its licence, but must credit it clearly and cannot present it as original; the criteria above are written so that the unimplemented parts are where the work actually lies. +- Prior art: [`jimmy-claw/spelbook`](https://github.com/jimmy-claw/spelbook) (formerly `lez-registry` — Rust core, on-chain program, CLI, and the `lez-registry-ffi` workspace member) and [`jimmy-claw/logos-lez-registry-module`](https://github.com/jimmy-claw/logos-lez-registry-module) (Logos Core Qt6 module). Together these implement register, author-gated update, lookup by program ID, IDL upload/download against Logos Storage, a CLI, and a browse/detail/register GUI. They do **not** implement enumeration, name or tag search, claim authorisation, or any form of source verification. Listing and name lookup are explicitly stubbed as "requires an off-chain indexer in v1", and `registered_at` is currently always zero. Submissions may build on this prior work subject to its licence, but must credit it clearly and cannot present it as original; the criteria above are written so that the unimplemented parts are where the work actually lies. ## 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. +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. ## Potential for Subsequent λ Prizes -This prize covers the **first adoption tranche** for the registry. A follow-up λPrize is expected with higher adoption thresholds, adapted to the phase the network is in at that time, and may extend the registry toward areas explicitly out of scope here — notably curation and trust signals, once there is enough registry content for those questions to be meaningful. +This prize covers the **first adoption tranche** for the registry. A follow-up λPrize is expected with higher adoption thresholds, adapted to the phase the network is in at that time, and may extend the registry toward areas explicitly out of scope here: notably curation and trust signals, once there is enough registry content for those questions to be meaningful. This prize also targets Logos testnet 0.3. Should a future testnet version (e.g., V0.4) introduce breaking changes to program IDs, PDA derivation, or the SPEL IDL format, a subsequent λ Prize may be opened to cover adaptation. From 60bdf91a4900082e76f443eef11bb4e925419443 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 26 Aug 2026 17:12:54 +1000 Subject: [PATCH 06/22] LP-0023: fix markdown formatting and grammar after latest edits 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. --- prizes/LP-0023.md | 84 ++++++++++++++--------------------------------- 1 file changed, 25 insertions(+), 59 deletions(-) diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index cd82ec4b..d40ccbf8 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -10,7 +10,7 @@ dependencies: [] ## Overview -This prize is for a program registry for the Logos Execution Zone (LEZ): a product that lets developers publish their deployed programs together with human-readable metadata and a pointer to the program's IDL and source code, and lets anyone browse, search, and verify those entries through a CLI, an SDK, and a Logos Basecamp app. +This prize is for a program registry for the Logos Execution Zone (LEZ): a product that lets developers publish their deployed programs together with human-readable metadata and a pointer to the program's IDL and source code, and lets anyone browse, search, and verify those entries through a CLI, an SDK, and a Logos Core Module. A LEZ program is identified on-chain by an opaque program ID. Nothing about that ID tells a user what the program does, who wrote it, what its interface looks like, or whether the bytecode matches any published source. The registry closes that gap: it turns an opaque program ID into a discoverable entry with a name, a version, an author, a description, tags, and a resolvable IDL, so that both humans and tooling can make sense of what they are about to interact with. @@ -29,48 +29,37 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti ### 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. -- [ ] **Register**: any account may register a deployed program it controls, supplying at minimum a **name**, **version**, **author**, **description**, **tags**, an **IDL pointer**, and a **registration timestamp**. Lookup of an entry must not depend on an indexer. The timestamp must reflect real block time, not a value supplied unchecked by the client. +- [ ] **Register**: any account may register a program it deployed, supplying at minimum a **name**, **version**, **author**, **description**, an **IDL pointer**, a **code pointer**, and a **registration timestamp**. Lookup of an entry must not depend on a centralized indexer. - [ ] **Deployer vs third-party entries**: the registry may hold both an entry from the program's own deployer and entries from third parties. The deployer's entry must be signed by the account that deployed the program, and clients must be able to tell it apart from a third-party entry without trusting an off-chain service. Either way, source verification (below) should be used to confirm the recorded claim actually matches the deployed program. The demo must show an unauthorised attempt to create a deployer entry being rejected. -- [ ] **Update**: only the original registering author may update an existing entry (version, IDL pointer, description, tags). Authorship transfer is optional; if implemented, it must require signatures from both parties. -- [ ] **IDL publishing**: the IDL is stored on **Logos Storage**, with the on-chain entry holding a pointer to it, resolvable back to a parseable IDL. -- [ ] **Discovery**: look up an entry by program ID, enumerate the full set of registered entries, and search by name, author, and tag, using only the submitted software. Registration, update, and lookup by program ID must remain usable even if any indexing component is unavailable. -- [ ] **Reproducible builds**: a documented build process for LEZ programs such that an independent third party building the same source at the same commit obtains a byte-identical artifact and a matching hash. Reproducibility is the foundation the rest of the verification story rests on. -- [ ] **Source verification**: an entry can additionally record a pointer to source (code stays off-chain), a commit, and a build configuration sufficient to reproduce the deployed bytecode. A verifier, available from the CLI, takes a program ID, rebuilds the recorded source, and reports one of four states: **verified** (claim present, hash matches), **mismatched** (claim present, hash does not match), **unverified** (no claim recorded), and **claimed-but-unchecked** (a claim exists but has not yet been rebuilt). Collapsing *mismatched* or *claimed-but-unchecked* into *unverified* is a failure: a claim that fails to reproduce is a stronger negative signal than no claim at all. -- [ ] **A hash match alone is not proof of provenance.** A build process that can execute arbitrary code at build time can be made to simply emit the already-deployed binary, producing a hash match without the deployed bytecode actually coming from the stated source. The submission must state how it defends against this, and must not present a bare hash match from an arbitrary repository as proof that the source is genuine. -- [ ] **Verification is version-bound**: verification status attaches to a specific deployed artifact. If a program is upgraded or its entry's source claim changes, the prior verified status must be invalidated rather than carried over, so an entry can never show *verified* against code that is no longer what is deployed. The submission must document its staleness window and expose the last-verified point to clients. +- [ ] **Update**: only the original registering author may update an existing entry (version, IDL pointer, description). Authorship transfer is optional; if implemented, it must require signatures from both parties. +- [ ] **IDL publishing**: the IDL is stored on **Logos Storage**. +- [ ] **Discovery**: look up an entry by program ID, enumerate the full set of registered entries, and search by name and author, using only the submitted software. +- [ ] **Source verification**: an entry must additionally record a pointer to source (code stays off-chain), a commit, and a build configuration sufficient to reproduce the deployed bytecode. A user may choose to rebuild the recorded source locally (via CLI, GUI, or any other tooling); if the resulting hash matches, the user can mark that program as "locally verified" for themselves. Alternative adequate strategies for bytecode verification may be accepted. - [ ] **Testnet 0.3**: the registry operates end-to-end against the Logos LEZ zone on Logos testnet 0.3. ### Usability - [ ] Provide a module/SDK usable by other Logos modules and third-party applications to register entries, resolve a program ID to its metadata and IDL, and run searches. This is the primary integration surface: wallets, explorers, and developer tools are the intended consumers. - [ ] Provide a CLI covering register, update, lookup, search, and source verification. -- [ ] Provide a Logos Basecamp app GUI with local build instructions and loadable assets, supporting at minimum: browsing registered programs, searching, viewing an entry's full metadata and its resolved IDL, viewing verification status, and registering a new program. -- [ ] **Verification status is never misleading.** Wherever a UI displays an entry, all four verification states must be visually distinguishable, and a deployer-published entry must be distinguishable from a third-party one. Registry metadata is self-asserted by whoever registered it: a name is a claim, not a fact. The UI must not present a self-asserted name in a way that implies the registry vouches for it, and must surface the signer behind a verification claim rather than showing a bare "verified" badge. -- [ ] **Verified does not mean safe.** Any UI or documentation presenting verification status must make clear that a verified build proves only that the deployed bytecode was produced from the stated source. It says nothing about whether that source is secure, audited, or benign. Wording that implies endorsement is a failure of this criterion. -- [ ] **UX quality.** The Basecamp app must be polished and usable by a non-expert: coherent navigation, readable IDL rendering, and clear error/pending states. This is judged against overall impression rather than a checklist; evaluators will use the app as a normal user would. ### Reliability -- [ ] An account that is not the recorded author cannot update an entry, and registering a program ID that already has an entry cannot silently overwrite it. - [ ] Clients degrade gracefully when an IDL identifier is unresolvable or the stored IDL fails to parse: the entry's on-chain metadata still displays, with the IDL surfaced as unavailable rather than the view failing. -- [ ] **No mandatory external services.** Beyond the user's configured sequencer, Logos LEZ node, and Logos Storage, the registry and its tooling must not depend on any third-party web service to function. If one is used, it is disclosed, the user can disable it, and the registry remains fully functional with it disabled. Any analytics must be strictly opt-in. -- [ ] Source verification runs locally: rebuilding a program to check its bytecode hash must not require a hosted build service. +- [ ] **No mandatory centralised external services.** Beyond the user's configured sequencer, Logos LEZ node, and Logos Storage (or other Logos protocols), the registry and its tooling must not depend on any third-party web service to function. If one is used, it is disclosed, the user can disable it, and the registry remains fully functional with it disabled. Any analytics must be strictly opt-in. ### Performance - [ ] Document compute unit usage for each on-chain operation (register, update). -- [ ] Document lookup latency for resolution by program ID and for a search across a registry populated with at least 500 entries. ### Supportability -- [ ] Deployed and tested against Logos testnet 0.3 (the Logos LEZ zone), with the deployed program ID published in the README. -- [ ] The submission builds and runs end-to-end on both **macOS (Apple Silicon)** and **Linux (x86_64)**. The demo script must succeed without modification on both platforms from a clean clone. -- [ ] Logos Basecamp modules are built with [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) (`mkLogosModule`). +- [ ] Deployed and tested against Logos testnet 0.3 (the canonical Logos LEZ zone). +- [ ] The submission builds and runs end-to-end on both **macOS (Apple Silicon)** and **Linux (x86_64)**. +- [ ] Logos Core Modules are built with [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) (`mkLogosModule`). - [ ] Provide an IDL for the registry program itself, generated via the [SPEL framework](https://github.com/logos-co/spel): the registry must be registered in itself. - [ ] 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, the deployed program ID, and step-by-step usage via CLI and Basecamp app. +- [ ] 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. -- [ ] A reproducible end-to-end demo script works against a real local sequencer with `RISC0_DEV_MODE=0`. ### Adoption @@ -78,13 +67,12 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti > > **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. -- [ ] **5 third-party tools or applications** integrate the registry SDK to resolve program metadata or IDLs, for example a wallet, an explorer, or a developer tool. Each 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. The 5 must be independent of each other and of the submitting team. -- [ ] **75 stars** on the registry repository. -- [ ] **100 registered programs** on the official Logos zone, registered by **at least 40 distinct author accounts** independent of the submitting team. Entries must point at genuinely deployed programs with resolvable, parseable IDLs; placeholder or duplicate entries pointing at the same underlying program do not count. Accounts with no prior unrelated testnet activity carry little weight. +- [ ] **5 third-party tools or applications** integrate the registry SDK to resolve program metadata or IDLs, for example a wallet, an explorer, or a developer tool. Each 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. The 5 must be independent of each other and of the submitting team. The owning developer or organisation's history on the forge will be inspected; fresh accounts, among other red flags, will not count. +- [ ] **50 registered programs** on the official Logos zone, registered by **at least 20 distinct author accounts** independent of the submitting team. Entries must point at genuinely deployed programs with resolvable, parseable IDLs; placeholder or duplicate entries pointing at the same underlying program do not count. Accounts with no prior unrelated testnet activity carry little weight. - [ ] **20 entries carry a verified source claim**: a recorded source repository and commit that an evaluator can independently rebuild to a bytecode hash matching the deployed program ID. Registering metadata is cheap; proving the bytecode matches published source is the part that makes the registry trustworthy, so it is counted separately. -- [ ] **Sustained registration activity**: the 100 registrations must be spread over **at least 2 months**, with **at least 20 new registrations in each of those months**. A single burst of activity does not qualify, however large. Each entry is timestamped on-chain, so this is verified directly from chain data. -- [ ] **30 testimonials on Discord** vouching for the registry. Testimonials should describe what the person actually used the registry for; account history will be checked. -- [ ] **30 testimonials on Twitter/X** vouching for the registry, subject to the same standard and the same account-history check. Sharing screenshots of the registry in use is encouraged. +- [ ] **Sustained registration activity**: the 50 registrations must be spread over **at least 2 months**, with **at least 10 new registrations in each of those months**. A single burst of activity does not qualify, however large. Each entry is timestamped on-chain, so this is verified directly from chain data. +- [ ] **20 testimonials on Discord** vouching for the registry. Testimonials should describe what the person actually used the registry for; account history will be checked. +- [ ] **20 testimonials on Twitter/X** vouching for the registry, subject to the same standard and the same account-history check. Sharing screenshots of the registry in use is encouraged. ## Design Decisions Left to the Submitter @@ -93,7 +81,6 @@ The following are deliberately not prescribed. A submission must pick a position - **What lives on-chain?** Source code and the IDL must live off-chain, on Logos Storage; the on-chain entry holds pointers, not the content itself. Beyond that minimum, a submission decides how much attestation data to keep on-chain versus off-chain, and should account for the gas cost of what it chooses to store on-chain. - **How is verified source hosted?** The registry proves a hash match, but something must host the code being matched against. A submission may point at a third-party repository, mirror source to Logos Storage, or both, but should say why. A repository URL alone is a liveness dependency on a third party: a deleted GitHub repo makes re-verification impossible, which is a weakness Solana's registry inherits. - **Is there a trusted-signer overlay?** Solana's explorer hardcodes a small list of trusted third-party verifiers (OtterSec, the Explorer itself) that rank above other non-authority signers. This is pragmatic but reintroduces a centralised trust root. A submission may implement something similar, omit it, or make the trusted set user-configurable, but if it ships one, the list must be user-inspectable and overridable. -- **Can entries be made immutable or closed?** Solana's metadata accounts support `set-immutable` and `close`; a closed or mutable-forever entry have different trust properties. Whether a LEZ entry can be frozen, deleted, or reclaimed by a later authority is open. ## Scope @@ -103,21 +90,19 @@ The following are deliberately not prescribed. A submission must pick a position - 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. - A claim-authorisation model distinguishing a program's own deployer from third-party registrants. -- Discovery: lookup by program ID, plus search by name, author, and tag (including a self-hostable indexer if search requires one). -- SDK, CLI, and Logos Basecamp app GUI. +- Discovery: lookup by program ID, plus search by name and author (including a self-hostable indexer if search requires one). +- SDK, CLI, Logos Core Module. ### Out of Scope -- **Curation, moderation, or a trust score.** The registry records what authors assert plus objectively checkable verification status. Deciding which programs are "good" or delisting entries is a governance question, not part of this prize. -- **Program deployment.** The registry describes already-deployed programs; deploying them is out of scope. -- Package management or dependency resolution between programs. +- **Curation, moderation, or a trust score.** The registry records what authors assert plus objectively checkable verification status. Deciding which programs are "good" or delisting entries is a governance question, not needed for this prize. - Hosting a public indexer as a service. The indexer must be self-hostable, but running one as infrastructure is not part of the deliverable. - Payment, licensing, or monetisation of registered programs. ## Prize Structure -- **Total Prize:** $X -- **Effort:** Large +- **Total Prize:** $1000 +- **Effort:** Small ## Eligibility @@ -125,10 +110,9 @@ Open to any individual or team. Submissions must be original work. Teams must ho ## Submission Requirements -- Public repository with the registry program, SDK, CLI, and Basecamp app GUI under MIT or Apache-2.0. +- Public repository with the registry program, SDK, CLI, and Logos Core Module under MIT or Apache-2.0. - The registry's own IDL, and the deployed program ID on Logos testnet 0.3. -- The Basecamp app 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 so evaluators can install the module through the package-manager UI / `lgpd`. -- Narrated video walkthrough demonstrating: registering a program end-to-end including IDL upload to Logos Storage, an unauthorised claim being rejected, updating an entry, an update being rejected for a non-author signer, lookup by program ID, full enumeration and search by name/author/tag, resolving and displaying an IDL in the Basecamp app, a deployer entry alongside a third-party entry for the same program with the distinction visible in the UI, and a source-verification run showing all four outcomes (verified, mismatched, unverified, claimed-but-unchecked), including a rebuild reproducing a matching hash from a clean checkout. The recording must show terminal output including proof generation, to confirm `RISC0_DEV_MODE=0` was active. (A narrated demo is required for every prize: see [demo requirements](../README.md#evaluation-policies).) +- The Logos Core modules 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 so evaluators can install the module through the package-manager UI / `lgpd`. - Evidence for each adoption criterion: links to the 5 third-party integrations and their repositories, the registry repository, the on-chain entries (with per-month counts so the sustained-activity criterion can be verified, and the subset carrying verified source claims), and the Discord and Twitter/X testimonials. - FURPS self-assessment as part of the solution (see [solution template](../solutions/LP-0000.md)). @@ -145,25 +129,6 @@ The following policies apply to all prizes (see [evaluation policies](../README. - **Submissions:** each builder (or team) is allowed a maximum of **3 submissions** per prize, with at most **one submission/review per week**. - **Feedback:** initial evaluation feedback is limited to a pass/fail indication against the success criteria. -## Prior Art in the Solana Ecosystem - -Solana has converged on **three separate systems** where this prize proposes one. That split is itself informative: metadata, verification attestations, and the verification service are distinct concerns with distinct trust models, and a submission that fuses them should be deliberate about it. - -| Concern | Solana | This prize | -|---|---|---| -| Program metadata & IDL | [`solana-program/program-metadata`](https://github.com/solana-program/program-metadata): metadata account per program, supporting inline data, an external URL, or an account pointer | One entry per program, IDL on Logos Storage | -| Verification claims | [`otter-sec/otter-verify`](https://github.com/otter-sec/otter-verify): on-chain claims storing repository, commit, build args, and deploy slot | Same fields folded into the registry entry | -| Build & verify | [`solana-verify` CLI](https://github.com/solana-foundation/solana-verifiable-build), Docker-pinned deterministic builds; the [OtterSec API](https://verify.osec.io) re-verifies every 24h | CLI verifier and a documented reproducible build process | -| Consumer UI | Solana Explorer's badge: *Verified* / *PDA uploaded, hash mismatch* / *Not verified*, ranked by signer authority | Four states, deployer vs third-party distinction | - -Specific lessons carried into the criteria above: - -- **Attribute claims to a signer without requiring exclusivity.** Solana's model lets anyone attest to any program while keeping the program's own authority unambiguously identifiable, rather than granting the author slot to whoever registers first. That is a better answer than either "first-come-first-claim" or "authority-only". -- **A matching hash is not proof of provenance.** Accretion's [write-up](https://accretion.xyz/blog/verified-builds) showed a build script that downloads the deployed binary and emits it as the build artifact, producing a perfect hash match from an attacker-controlled repository. The fix is authorisation, not better hashing. -- **Verification decays.** Solana un-verifies on upgrade and re-verifies every 24 hours; verification is a maintained state, not a one-time event. -- **Explorers need a signer, not a badge.** Ranking by signer authority, and showing who signed, is what makes the badge meaningful. -- **The centralisation Solana did not avoid.** Docker images are hosted by the Solana Foundation, the verify program is upgradeable and not frozen, the API is OtterSec-operated, and the trusted-signer list is hardcoded in the explorer. Each is a point where "trustless verification" quietly becomes "trust these parties", and a LEZ registry has an opportunity to do better. - ## Resources - [SPEL framework](https://github.com/logos-co/spel) — Anchor-inspired developer framework for LEZ programs, used for the program and its IDL @@ -171,7 +136,8 @@ Specific lessons carried into the criteria above: - [LEZ programs repo](https://github.com/logos-blockchain/lez-programs/) - [`logos-modules-release-base`](https://github.com/logos-co/logos-modules-release-base) and [`logos-modules-release-action`](https://github.com/logos-co/logos-modules-release-action) — module catalog publishing - [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) — `mkLogosModule` -Solana prior art (see the comparison above): + +Solana prior art: - [Solana verified builds documentation](https://solana.com/docs/programs/verified-builds) and the [verification guide](https://solana.com/developers/guides/advanced/verified-builds) - [`solana-foundation/solana-verifiable-build`](https://github.com/solana-foundation/solana-verifiable-build) — the `solana-verify` CLI From e6cb336d443b4e9146407d68d72c7b82bd7001c6 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 26 Aug 2026 17:17:02 +1000 Subject: [PATCH 07/22] LP-0023: require the 5 adoption integrations to ship as Logos apps 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. --- prizes/LP-0023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index d40ccbf8..ffbaa46a 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -67,7 +67,7 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti > > **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. -- [ ] **5 third-party tools or applications** integrate the registry SDK to resolve program metadata or IDLs, for example a wallet, an explorer, or a developer tool. Each 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. The 5 must be independent of each other and of the submitting team. The owning developer or organisation's history on the forge will be inspected; fresh accounts, among other red flags, will not count. +- [ ] **5 third-party Logos apps** (Logos Core Modules) integrate the registry SDK to resolve program metadata or IDLs, for example a wallet, an explorer, or a developer tool. Each must ship as a Logos Core Module, 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. The 5 must be independent of each other and of the submitting team. The owning developer or organisation's history on the forge will be inspected; fresh accounts, among other red flags, will not count. - [ ] **50 registered programs** on the official Logos zone, registered by **at least 20 distinct author accounts** independent of the submitting team. Entries must point at genuinely deployed programs with resolvable, parseable IDLs; placeholder or duplicate entries pointing at the same underlying program do not count. Accounts with no prior unrelated testnet activity carry little weight. - [ ] **20 entries carry a verified source claim**: a recorded source repository and commit that an evaluator can independently rebuild to a bytecode hash matching the deployed program ID. Registering metadata is cheap; proving the bytecode matches published source is the part that makes the registry trustworthy, so it is counted separately. - [ ] **Sustained registration activity**: the 50 registrations must be spread over **at least 2 months**, with **at least 10 new registrations in each of those months**. A single burst of activity does not qualify, however large. Each entry is timestamped on-chain, so this is verified directly from chain data. From f61829249a3e2433cecf94a59434d0796d10a40a Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 26 Aug 2026 17:18:59 +1000 Subject: [PATCH 08/22] LP-0023: correct "Logos Core Module" to "Logos UI Module" A Core Module is backend/business-logic; the registry's app deliverable (browse, search, register) is a user-facing UI Module. --- prizes/LP-0023.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index ffbaa46a..91ec0b94 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -10,7 +10,7 @@ dependencies: [] ## Overview -This prize is for a program registry for the Logos Execution Zone (LEZ): a product that lets developers publish their deployed programs together with human-readable metadata and a pointer to the program's IDL and source code, and lets anyone browse, search, and verify those entries through a CLI, an SDK, and a Logos Core Module. +This prize is for a program registry for the Logos Execution Zone (LEZ): a product that lets developers publish their deployed programs together with human-readable metadata and a pointer to the program's IDL and source code, and lets anyone browse, search, and verify those entries through a CLI, an SDK, and a Logos UI Module. A LEZ program is identified on-chain by an opaque program ID. Nothing about that ID tells a user what the program does, who wrote it, what its interface looks like, or whether the bytecode matches any published source. The registry closes that gap: it turns an opaque program ID into a discoverable entry with a name, a version, an author, a description, tags, and a resolvable IDL, so that both humans and tooling can make sense of what they are about to interact with. @@ -55,10 +55,10 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti - [ ] Deployed and tested against Logos testnet 0.3 (the canonical Logos LEZ zone). - [ ] The submission builds and runs end-to-end on both **macOS (Apple Silicon)** and **Linux (x86_64)**. -- [ ] Logos Core Modules are built with [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) (`mkLogosModule`). +- [ ] Logos UI Modules are built with [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) (`mkLogosModule`). - [ ] Provide an IDL for the registry program itself, generated via the [SPEL framework](https://github.com/logos-co/spel): the registry must be registered in itself. - [ ] 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, the deployed program ID, and step-by-step usage via CLI and Logos Core Module. +- [ ] README documents setup, the deployed program ID, and step-by-step usage via CLI and Logos UI 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 @@ -67,7 +67,7 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti > > **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. -- [ ] **5 third-party Logos apps** (Logos Core Modules) integrate the registry SDK to resolve program metadata or IDLs, for example a wallet, an explorer, or a developer tool. Each must ship as a Logos Core Module, 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. The 5 must be independent of each other and of the submitting team. The owning developer or organisation's history on the forge will be inspected; fresh accounts, among other red flags, will not count. +- [ ] **5 third-party Logos apps** (Logos UI Modules) integrate the registry SDK to resolve program metadata or IDLs, for example a wallet, an explorer, or a developer tool. Each must ship as a Logos UI Module, 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. The 5 must be independent of each other and of the submitting team. The owning developer or organisation's history on the forge will be inspected; fresh accounts, among other red flags, will not count. - [ ] **50 registered programs** on the official Logos zone, registered by **at least 20 distinct author accounts** independent of the submitting team. Entries must point at genuinely deployed programs with resolvable, parseable IDLs; placeholder or duplicate entries pointing at the same underlying program do not count. Accounts with no prior unrelated testnet activity carry little weight. - [ ] **20 entries carry a verified source claim**: a recorded source repository and commit that an evaluator can independently rebuild to a bytecode hash matching the deployed program ID. Registering metadata is cheap; proving the bytecode matches published source is the part that makes the registry trustworthy, so it is counted separately. - [ ] **Sustained registration activity**: the 50 registrations must be spread over **at least 2 months**, with **at least 10 new registrations in each of those months**. A single burst of activity does not qualify, however large. Each entry is timestamped on-chain, so this is verified directly from chain data. @@ -91,7 +91,7 @@ The following are deliberately not prescribed. A submission must pick a position - Reproducible builds for LEZ programs, and the source-verification tooling and on-chain fields backing it. - A claim-authorisation model distinguishing a program's own deployer from third-party registrants. - Discovery: lookup by program ID, plus search by name and author (including a self-hostable indexer if search requires one). -- SDK, CLI, Logos Core Module. +- SDK, CLI, Logos UI Module. ### Out of Scope @@ -110,7 +110,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho ## Submission Requirements -- Public repository with the registry program, SDK, CLI, and Logos Core Module under MIT or Apache-2.0. +- Public repository with the registry program, SDK, CLI, and Logos UI Module under MIT or Apache-2.0. - The registry's own IDL, and the deployed program ID on Logos testnet 0.3. - The Logos Core modules 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 so evaluators can install the module through the package-manager UI / `lgpd`. - Evidence for each adoption criterion: links to the 5 third-party integrations and their repositories, the registry repository, the on-chain entries (with per-month counts so the sustained-activity criterion can be verified, and the subset carrying verified source claims), and the Discord and Twitter/X testimonials. From 25df7321ff94cbd7f9f708e5fead146b478cbc03 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 26 Aug 2026 17:20:16 +1000 Subject: [PATCH 09/22] LP-0023: split Core Module vs UI Module correctly 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". --- prizes/LP-0023.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index 91ec0b94..307eb3af 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -10,7 +10,7 @@ dependencies: [] ## Overview -This prize is for a program registry for the Logos Execution Zone (LEZ): a product that lets developers publish their deployed programs together with human-readable metadata and a pointer to the program's IDL and source code, and lets anyone browse, search, and verify those entries through a CLI, an SDK, and a Logos UI Module. +This prize is for a program registry for the Logos Execution Zone (LEZ): a product that lets developers publish their deployed programs together with human-readable metadata and a pointer to the program's IDL and source code, and lets anyone browse, search, and verify those entries through a CLI, an SDK, and a Logos Core Module. A LEZ program is identified on-chain by an opaque program ID. Nothing about that ID tells a user what the program does, who wrote it, what its interface looks like, or whether the bytecode matches any published source. The registry closes that gap: it turns an opaque program ID into a discoverable entry with a name, a version, an author, a description, tags, and a resolvable IDL, so that both humans and tooling can make sense of what they are about to interact with. @@ -55,10 +55,10 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti - [ ] Deployed and tested against Logos testnet 0.3 (the canonical Logos LEZ zone). - [ ] The submission builds and runs end-to-end on both **macOS (Apple Silicon)** and **Linux (x86_64)**. -- [ ] Logos UI Modules are built with [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) (`mkLogosModule`). +- [ ] The Logos Core Module is built with [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) (`mkLogosModule`). - [ ] Provide an IDL for the registry program itself, generated via the [SPEL framework](https://github.com/logos-co/spel): the registry must be registered in itself. - [ ] 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, the deployed program ID, and step-by-step usage via CLI and Logos UI Module. +- [ ] 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 @@ -91,7 +91,7 @@ The following are deliberately not prescribed. A submission must pick a position - Reproducible builds for LEZ programs, and the source-verification tooling and on-chain fields backing it. - A claim-authorisation model distinguishing a program's own deployer from third-party registrants. - Discovery: lookup by program ID, plus search by name and author (including a self-hostable indexer if search requires one). -- SDK, CLI, Logos UI Module. +- SDK, CLI, Logos Core Module. ### Out of Scope @@ -110,7 +110,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho ## Submission Requirements -- Public repository with the registry program, SDK, CLI, and Logos UI Module under MIT or Apache-2.0. +- Public repository with the registry program, SDK, CLI, and Logos Core Module under MIT or Apache-2.0. - The registry's own IDL, and the deployed program ID on Logos testnet 0.3. - The Logos Core modules 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 so evaluators can install the module through the package-manager UI / `lgpd`. - Evidence for each adoption criterion: links to the 5 third-party integrations and their repositories, the registry repository, the on-chain entries (with per-month counts so the sustained-activity criterion can be verified, and the subset carrying verified source claims), and the Discord and Twitter/X testimonials. From d299e28a42e9be74b17cd6f74070090499c3f598 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 27 Aug 2026 10:33:53 +1000 Subject: [PATCH 10/22] LP-0023: use Execution Gas terminology, not compute units 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. --- prizes/LP-0023.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index 307eb3af..371ef19c 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -49,7 +49,7 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti ### Performance -- [ ] Document compute unit usage for each on-chain operation (register, update). +- [ ] Document [Execution Gas](https://lip.logos.co/blockchain/raw/analysis-gas-cost-determination.html) usage for each on-chain operation (register, update). ### Supportability @@ -136,6 +136,7 @@ The following policies apply to all prizes (see [evaluation policies](../README. - [LEZ programs repo](https://github.com/logos-blockchain/lez-programs/) - [`logos-modules-release-base`](https://github.com/logos-co/logos-modules-release-base) and [`logos-modules-release-action`](https://github.com/logos-co/logos-modules-release-action) — module catalog publishing - [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) — `mkLogosModule` +- [Gas Cost Determination](https://lip.logos.co/blockchain/raw/analysis-gas-cost-determination.html) — Execution Gas and Permanent Storage Gas, the units to use when documenting compute cost Solana prior art: From 2aaeb48af456d4e918687a22f78f4d8564ca9512 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 27 Aug 2026 11:00:34 +1000 Subject: [PATCH 11/22] LP-0023: bump prize pool to $2000 --- prizes/LP-0023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index 371ef19c..7353a498 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -101,7 +101,7 @@ The following are deliberately not prescribed. A submission must pick a position ## Prize Structure -- **Total Prize:** $1000 +- **Total Prize:** $2000 - **Effort:** Small ## Eligibility From 31ee7216cdce384fcc86f1e3aea6410daa6826b5 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 27 Aug 2026 13:18:19 +1000 Subject: [PATCH 12/22] LP-0023: use LEZ cycle-count terminology, not L1 Execution Gas 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. --- prizes/LP-0023.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index 7353a498..29cb36c8 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -49,7 +49,7 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti ### Performance -- [ ] Document [Execution Gas](https://lip.logos.co/blockchain/raw/analysis-gas-cost-determination.html) usage for each on-chain operation (register, update). +- [ ] Document [cycle count](https://github.com/logos-blockchain/logos-execution-zone/tree/dev/tools/cycle_bench) usage for each on-chain operation (register, update). ### Supportability @@ -136,7 +136,7 @@ The following policies apply to all prizes (see [evaluation policies](../README. - [LEZ programs repo](https://github.com/logos-blockchain/lez-programs/) - [`logos-modules-release-base`](https://github.com/logos-co/logos-modules-release-base) and [`logos-modules-release-action`](https://github.com/logos-co/logos-modules-release-action) — module catalog publishing - [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) — `mkLogosModule` -- [Gas Cost Determination](https://lip.logos.co/blockchain/raw/analysis-gas-cost-determination.html) — Execution Gas and Permanent Storage Gas, the units to use when documenting compute cost +- [`cycle_bench`](https://github.com/logos-blockchain/logos-execution-zone/tree/dev/tools/cycle_bench) — LEZ's cycle-count benchmarking tool, the unit to use when documenting compute cost Solana prior art: From 322e62239262fe983a2c544a9619d9340f894e02 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 27 Aug 2026 13:30:06 +1000 Subject: [PATCH 13/22] LP-0023: remove Risks and Dependencies section --- prizes/LP-0023.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index 29cb36c8..8b3a0d9b 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -154,10 +154,6 @@ Logos: - [LP-0021](LP-0021.md) — LEZ Zone Wallet and SDK, a natural consumer of this registry for human-readable transaction previews - Prior art: [`jimmy-claw/spelbook`](https://github.com/jimmy-claw/spelbook) (formerly `lez-registry` — Rust core, on-chain program, CLI, and the `lez-registry-ffi` workspace member) and [`jimmy-claw/logos-lez-registry-module`](https://github.com/jimmy-claw/logos-lez-registry-module) (Logos Core Qt6 module). Together these implement register, author-gated update, lookup by program ID, IDL upload/download against Logos Storage, a CLI, and a browse/detail/register GUI. They do **not** implement enumeration, name or tag search, claim authorisation, or any form of source verification. Listing and name lookup are explicitly stubbed as "requires an off-chain indexer in v1", and `registered_at` is currently always zero. Submissions may build on this prior work subject to its licence, but must credit it clearly and cannot present it as original; the criteria above are written so that the unimplemented parts are where the work actually lies. -## 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. - ## Potential for Subsequent λ Prizes This prize covers the **first adoption tranche** for the registry. A follow-up λPrize is expected with higher adoption thresholds, adapted to the phase the network is in at that time, and may extend the registry toward areas explicitly out of scope here: notably curation and trust signals, once there is enough registry content for those questions to be meaningful. From e3ce7453b77916ea101237b3b2feb20082fb835c Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 27 Aug 2026 13:33:02 +1000 Subject: [PATCH 14/22] LP-0023: replace "hash" with "byte code" in verification wording --- prizes/LP-0023.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index 8b3a0d9b..c384b059 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -34,7 +34,7 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti - [ ] **Update**: only the original registering author may update an existing entry (version, IDL pointer, description). Authorship transfer is optional; if implemented, it must require signatures from both parties. - [ ] **IDL publishing**: the IDL is stored on **Logos Storage**. - [ ] **Discovery**: look up an entry by program ID, enumerate the full set of registered entries, and search by name and author, using only the submitted software. -- [ ] **Source verification**: an entry must additionally record a pointer to source (code stays off-chain), a commit, and a build configuration sufficient to reproduce the deployed bytecode. A user may choose to rebuild the recorded source locally (via CLI, GUI, or any other tooling); if the resulting hash matches, the user can mark that program as "locally verified" for themselves. Alternative adequate strategies for bytecode verification may be accepted. +- [ ] **Source verification**: an entry must additionally record a pointer to source (code stays off-chain), a commit, and a build configuration sufficient to reproduce the deployed bytecode. A user may choose to rebuild the recorded source locally (via CLI, GUI, or any other tooling); if the resulting byte code matches, the user can mark that program as "locally verified" for themselves. Alternative adequate strategies for bytecode verification may be accepted. - [ ] **Testnet 0.3**: the registry operates end-to-end against the Logos LEZ zone on Logos testnet 0.3. ### Usability @@ -69,7 +69,7 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti - [ ] **5 third-party Logos apps** (Logos UI Modules) integrate the registry SDK to resolve program metadata or IDLs, for example a wallet, an explorer, or a developer tool. Each must ship as a Logos UI Module, 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. The 5 must be independent of each other and of the submitting team. The owning developer or organisation's history on the forge will be inspected; fresh accounts, among other red flags, will not count. - [ ] **50 registered programs** on the official Logos zone, registered by **at least 20 distinct author accounts** independent of the submitting team. Entries must point at genuinely deployed programs with resolvable, parseable IDLs; placeholder or duplicate entries pointing at the same underlying program do not count. Accounts with no prior unrelated testnet activity carry little weight. -- [ ] **20 entries carry a verified source claim**: a recorded source repository and commit that an evaluator can independently rebuild to a bytecode hash matching the deployed program ID. Registering metadata is cheap; proving the bytecode matches published source is the part that makes the registry trustworthy, so it is counted separately. +- [ ] **20 entries carry a verified source claim**: a recorded source repository and commit that an evaluator can independently rebuild to byte code matching the deployed program ID. Registering metadata is cheap; proving the bytecode matches published source is the part that makes the registry trustworthy, so it is counted separately. - [ ] **Sustained registration activity**: the 50 registrations must be spread over **at least 2 months**, with **at least 10 new registrations in each of those months**. A single burst of activity does not qualify, however large. Each entry is timestamped on-chain, so this is verified directly from chain data. - [ ] **20 testimonials on Discord** vouching for the registry. Testimonials should describe what the person actually used the registry for; account history will be checked. - [ ] **20 testimonials on Twitter/X** vouching for the registry, subject to the same standard and the same account-history check. Sharing screenshots of the registry in use is encouraged. @@ -79,7 +79,7 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti The following are deliberately not prescribed. A submission must pick a position on each, document it, and justify it: the reasoning is part of what is evaluated. - **What lives on-chain?** Source code and the IDL must live off-chain, on Logos Storage; the on-chain entry holds pointers, not the content itself. Beyond that minimum, a submission decides how much attestation data to keep on-chain versus off-chain, and should account for the gas cost of what it chooses to store on-chain. -- **How is verified source hosted?** The registry proves a hash match, but something must host the code being matched against. A submission may point at a third-party repository, mirror source to Logos Storage, or both, but should say why. A repository URL alone is a liveness dependency on a third party: a deleted GitHub repo makes re-verification impossible, which is a weakness Solana's registry inherits. +- **How is verified source hosted?** The registry proves a byte code match, but something must host the code being matched against. A submission may point at a third-party repository, mirror source to Logos Storage, or both, but should say why. A repository URL alone is a liveness dependency on a third party: a deleted GitHub repo makes re-verification impossible, which is a weakness Solana's registry inherits. - **Is there a trusted-signer overlay?** Solana's explorer hardcodes a small list of trusted third-party verifiers (OtterSec, the Explorer itself) that rank above other non-authority signers. This is pragmatic but reintroduces a centralised trust root. A submission may implement something similar, omit it, or make the trusted set user-configurable, but if it ships one, the list must be user-inspectable and overridable. ## Scope From c6967bbd3a940fce3567d5fb8d5ada6fdc9ee1be Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 28 Aug 2026 12:55:39 +1000 Subject: [PATCH 15/22] LP-0023: rename to "LEZ Program Registry" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit "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. --- README.md | 2 +- prizes/LP-0023.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 952be35b..f88cabbe 100644 --- a/README.md +++ b/README.md @@ -31,7 +31,7 @@ Prizes are graded on a functionality gate **plus** adoption criteria (real third |------|-------------|------|--------| | [LP-0000](prizes/LP-0000.md) | Template — use this as the starting point for new prizes | — | — | | [LP-0018](prizes/LP-0018.md) | OpenStreetMap integration: decentralized map data distribution | Medium | Open | -| [LP-0023](prizes/LP-0023.md) | Program Registry: verified builds for LEZ programs | Large | Draft | +| [LP-0023](prizes/LP-0023.md) | LEZ Program Registry | Small | Open | ### Earlier prizes diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index c384b059..080adf51 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -4,7 +4,7 @@ dependencies: [] --- -# LP-0023: Program Registry — Verified Builds for LEZ Programs [DRAFT] +# LP-0023: LEZ Program Registry [DRAFT] **`Logos Circle: N/A`** From a4ff7ba704ea022aba006b99847e6cfe6c389ae9 Mon Sep 17 00:00:00 2001 From: mart1n <20109376+mart1n-xyz@users.noreply.github.com> Date: Fri, 28 Aug 2026 11:22:05 +0200 Subject: [PATCH 16/22] LP-0023: mark prize as Open, no longer Draft Co-authored-by: Cursor --- prizes/LP-0023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index 080adf51..a89d6b13 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -4,7 +4,7 @@ dependencies: [] --- -# LP-0023: LEZ Program Registry [DRAFT] +# LP-0023: LEZ Program Registry [OPEN] **`Logos Circle: N/A`** From 23a21dcdbe202313e5802fd6b96002bda64a28de Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 2 Sep 2026 14:51:36 +1000 Subject: [PATCH 17/22] Add legal note to prize specifications Co-Authored-By: Claude Opus 5 (1M context) --- prizes/LP-0023.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index a89d6b13..c1f2329c 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -159,3 +159,21 @@ Logos: This prize covers the **first adoption tranche** for the registry. A follow-up λPrize is expected with higher adoption thresholds, adapted to the phase the network is in at that time, and may extend the registry toward areas explicitly out of scope here: notably curation and trust signals, once there is enough registry content for those questions to be meaningful. This prize also targets Logos testnet 0.3. Should a future testnet version (e.g., V0.4) introduce breaking changes to program IDs, PDA derivation, or the SPEL IDL format, a subsequent λ Prize may be opened to cover adaptation. + +## Note + +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. From 10c58d90a5bd07cfad1ca8241eb4a3f2440d9c4d Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 3 Sep 2026 14:28:57 +1000 Subject: [PATCH 18/22] Match canonical Specification disclaimer format; move LP-0023 to adoption-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). --- prizes/LP-0023.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index c1f2329c..0b71867a 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -160,9 +160,9 @@ This prize covers the **first adoption tranche** for the registry. A follow-up This prize also targets Logos testnet 0.3. Should a future testnet version (e.g., V0.4) introduce breaking changes to program IDs, PDA derivation, or the SPEL IDL format, a subsequent λ Prize may be opened to cover adaptation. -## Note +--- -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. +**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. @@ -176,4 +176,4 @@ Artefacts developed by Participants in connection with the Program are published 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. +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 d6bfa44b436f6529a9c886d57be966e1b5d7c378 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 11 Sep 2026 10:43:56 +1000 Subject: [PATCH 19/22] LP-0023: apply feedback from legal Reframe the design-choices section as additional to the Success Criteria, and require dual licensing under both MIT and Apache-2.0. Co-Authored-By: Claude Opus 5 (1M context) --- prizes/LP-0023.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index 0b71867a..ea3ba855 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -74,9 +74,9 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti - [ ] **20 testimonials on Discord** vouching for the registry. Testimonials should describe what the person actually used the registry for; account history will be checked. - [ ] **20 testimonials on Twitter/X** vouching for the registry, subject to the same standard and the same account-history check. Sharing screenshots of the registry in use is encouraged. -## Design Decisions Left to the Submitter +## Additional Design Choices Left to the Submitter -The following are deliberately not prescribed. A submission must pick a position on each, document it, and justify it: the reasoning is part of what is evaluated. +The following are deliberately not set out in the Success Criteria, as they are additional design choices which the submitter should decide upon. A submission must pick a position on each, document it, and justify it: the reasoning is part of what is evaluated. - **What lives on-chain?** Source code and the IDL must live off-chain, on Logos Storage; the on-chain entry holds pointers, not the content itself. Beyond that minimum, a submission decides how much attestation data to keep on-chain versus off-chain, and should account for the gas cost of what it chooses to store on-chain. - **How is verified source hosted?** The registry proves a byte code match, but something must host the code being matched against. A submission may point at a third-party repository, mirror source to Logos Storage, or both, but should say why. A repository URL alone is a liveness dependency on a third party: a deleted GitHub repo makes re-verification impossible, which is a weakness Solana's registry inherits. @@ -106,11 +106,11 @@ The following are deliberately not prescribed. A submission must pick a position ## 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. Submissions must be original work. Teams must hold the rights to all submitted code and agree to license it under both MIT and Apache-2.0. ## Submission Requirements -- Public repository with the registry program, SDK, CLI, and Logos Core Module under MIT or Apache-2.0. +- Public repository with the registry program, SDK, CLI, and Logos Core Module dual-licensed under both MIT and Apache-2.0. - The registry's own IDL, and the deployed program ID on Logos testnet 0.3. - The Logos Core modules 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 so evaluators can install the module through the package-manager UI / `lgpd`. - Evidence for each adoption criterion: links to the 5 third-party integrations and their repositories, the registry repository, the on-chain entries (with per-month counts so the sustained-activity criterion can be verified, and the subset carrying verified source claims), and the Discord and Twitter/X testimonials. From 5054c69402096b79b26bc05e46e9a8171e78a699 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 17 Sep 2026 12:49:44 +1000 Subject: [PATCH 20/22] LP-0023: keep prize as Draft Revert the status flip to Open: the prize is not ready to open yet. Also carries the README row through the master rebase, where the prize index was restructured into adoption-first and earlier-prize tables. Co-Authored-By: Claude Opus 5 --- README.md | 2 +- prizes/LP-0023.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index f88cabbe..0cfacfb7 100644 --- a/README.md +++ b/README.md @@ -31,7 +31,7 @@ Prizes are graded on a functionality gate **plus** adoption criteria (real third |------|-------------|------|--------| | [LP-0000](prizes/LP-0000.md) | Template — use this as the starting point for new prizes | — | — | | [LP-0018](prizes/LP-0018.md) | OpenStreetMap integration: decentralized map data distribution | Medium | Open | -| [LP-0023](prizes/LP-0023.md) | LEZ Program Registry | Small | Open | +| [LP-0023](prizes/LP-0023.md) | LEZ Program Registry | Small | Draft | ### Earlier prizes diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index ea3ba855..d74a8743 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -4,7 +4,7 @@ dependencies: [] --- -# LP-0023: LEZ Program Registry [OPEN] +# LP-0023: LEZ Program Registry [DRAFT] **`Logos Circle: N/A`** From 12dc6a2ec146ef8e89a922588090e80146eb9b61 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 17 Sep 2026 13:08:05 +1000 Subject: [PATCH 21/22] LP-0023: legal feedback Adopt the legal-review changes landed on the wallet branch (PR #122) that apply to this prize: - Footer: add the adoption-criteria and prior-Prize-reference paragraphs, and replace the bare "no representation" sentence with the endorsement disclaimer. Footer now matches prizes/LP-0000.md verbatim. - Resources: add the informational-purposes disclaimer block. - Front matter: note that it is internal tooling metadata, not part of the Specification. - Reliability: add the data-protection rider to the analytics criterion. - Drop wording that points Participants at prior work or asserts a dependency: the spelbook prior-art bullet no longer tells submitters they may build on it subject to licence, the LP-0021 Resources entry drops "a natural consumer of this registry", and Motivation no longer says landing this registry is what makes the wallet previews possible. This mirrors the clause legal struck from LP-0021/LP-0022's own references to LP-0023. Boilerplate is copied verbatim from LP-0000, including legal's own grammatical slips ("a previous Prizes", "Logos further makes representation"), so the disclaimer stays byte-identical across prizes. Co-Authored-By: Claude Opus 5 --- prizes/LP-0023.md | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index d74a8743..32b2ebac 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -1,6 +1,8 @@ --- +# 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: [] --- @@ -22,7 +24,7 @@ Metadata alone is only half the problem. Anyone can claim anything about a progr A registry is the kind of shared substrate that benefits from being built once and consumed by everything else. The prize therefore requires both a working product and a genuine base of registered programs and integrating tools. -The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anticipate this work: they allow, but do not require, a wallet to surface registry metadata when previewing a smart-contract interaction. Landing this registry makes that possible. +The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) set out criteria under which a wallet may surface registry metadata when previewing a smart-contract interaction. A registry that meets or is similar to the criteria below is suitable for that purpose. ## Success Criteria @@ -45,7 +47,7 @@ The wallet prizes ([LP-0021](LP-0021.md), [LP-0022](LP-0022.md)) explicitly anti ### Reliability - [ ] Clients degrade gracefully when an IDL identifier is unresolvable or the stored IDL fails to parse: the entry's on-chain metadata still displays, with the IDL surfaced as unavailable rather than the view failing. -- [ ] **No mandatory centralised external services.** Beyond the user's configured sequencer, Logos LEZ node, and Logos Storage (or other Logos protocols), the registry and its tooling must not depend on any third-party web service to function. If one is used, it is disclosed, the user can disable it, and the registry remains fully functional with it disabled. Any analytics must be strictly opt-in. +- [ ] **No mandatory centralised external services.** Beyond the user's configured sequencer, Logos LEZ node, and Logos Storage (or other Logos protocols), the registry and its tooling must not depend on any third-party web service to function. If one is used, it is disclosed, the user can disable it, and the registry remains fully functional with it disabled. Any analytics must be strictly opt-in. Please note that there may be other data protection obligations applicable regarding any collection of analytics which the participant should determine and review for themselves. ### Performance @@ -151,8 +153,10 @@ Solana prior art: Logos: - [LP-0011](LP-0011.md) — Program development tooling: Rust SDK -- [LP-0021](LP-0021.md) — LEZ Zone Wallet and SDK, a natural consumer of this registry for human-readable transaction previews -- Prior art: [`jimmy-claw/spelbook`](https://github.com/jimmy-claw/spelbook) (formerly `lez-registry` — Rust core, on-chain program, CLI, and the `lez-registry-ffi` workspace member) and [`jimmy-claw/logos-lez-registry-module`](https://github.com/jimmy-claw/logos-lez-registry-module) (Logos Core Qt6 module). Together these implement register, author-gated update, lookup by program ID, IDL upload/download against Logos Storage, a CLI, and a browse/detail/register GUI. They do **not** implement enumeration, name or tag search, claim authorisation, or any form of source verification. Listing and name lookup are explicitly stubbed as "requires an off-chain indexer in v1", and `registered_at` is currently always zero. Submissions may build on this prior work subject to its licence, but must credit it clearly and cannot present it as original; the criteria above are written so that the unimplemented parts are where the work actually lies. +- [LP-0021](LP-0021.md) — LEZ Zone Wallet and SDK +- Prior art: [`jimmy-claw/spelbook`](https://github.com/jimmy-claw/spelbook) (formerly `lez-registry` — Rust core, on-chain program, CLI, and the `lez-registry-ffi` workspace member) and [`jimmy-claw/logos-lez-registry-module`](https://github.com/jimmy-claw/logos-lez-registry-module) (Logos Core Qt6 module). Together these implement register, author-gated update, lookup by program ID, IDL upload/download against Logos Storage, a CLI, and a browse/detail/register GUI. They do **not** implement enumeration, name or tag search, claim authorisation, or any form of source verification. Listing and name lookup are explicitly stubbed as "requires an off-chain indexer in v1", and `registered_at` is currently always zero. The criteria above are written so that the unimplemented parts are where the work lies. A Submission must satisfy those criteria in its own right; it does not need to use, extend or otherwise rely on this or any other prior work. + +> 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 @@ -164,7 +168,11 @@ This prize also targets Logos testnet 0.3. Should a future testnet version (e.g. **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 0ffe53d37581320b6da93815440f27ca0cf5cf9b Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 17 Sep 2026 13:22:34 +1000 Subject: [PATCH 22/22] LP-0023: drop the prior-art bullet Remove the Resources entry pointing at the jimmy-claw spelbook and logos-lez-registry-module repos. It named a third party's repositories and assessed what they did and did not implement, which is a representation about referenced material that the Specification does not make. Co-Authored-By: Claude Opus 5 --- prizes/LP-0023.md | 1 - 1 file changed, 1 deletion(-) diff --git a/prizes/LP-0023.md b/prizes/LP-0023.md index 32b2ebac..403b3286 100644 --- a/prizes/LP-0023.md +++ b/prizes/LP-0023.md @@ -154,7 +154,6 @@ Logos: - [LP-0011](LP-0011.md) — Program development tooling: Rust SDK - [LP-0021](LP-0021.md) — LEZ Zone Wallet and SDK -- Prior art: [`jimmy-claw/spelbook`](https://github.com/jimmy-claw/spelbook) (formerly `lez-registry` — Rust core, on-chain program, CLI, and the `lez-registry-ffi` workspace member) and [`jimmy-claw/logos-lez-registry-module`](https://github.com/jimmy-claw/logos-lez-registry-module) (Logos Core Qt6 module). Together these implement register, author-gated update, lookup by program ID, IDL upload/download against Logos Storage, a CLI, and a browse/detail/register GUI. They do **not** implement enumeration, name or tag search, claim authorisation, or any form of source verification. Listing and name lookup are explicitly stubbed as "requires an off-chain indexer in v1", and `registered_at` is currently always zero. The criteria above are written so that the unimplemented parts are where the work lies. A Submission must satisfy those criteria in its own right; it does not need to use, extend or otherwise rely on this or any other prior work. > 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.