From 72a3fca141f8c6939756bdf98cb7b3343fc94fa8 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Mon, 17 Aug 2026 15:20:02 +1000 Subject: [PATCH 01/18] =?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 fad8bd34..0f082530 100644 --- a/README.md +++ b/README.md @@ -52,6 +52,7 @@ All prizes live in the `[prizes/](prizes/)` directory. Each prize is a markdown | [LP-0015](prizes/LP-0015.md) | General cross-program calls via tail calls | Large | Closed | | [LP-0016](prizes/LP-0016.md) | Anonymous Forum with Threshold Moderation | Large | Closed ([Solution](solutions/LP-0016.md)) | | [LP-0017](prizes/LP-0017.md) | Whistleblower: document upload and indexing Basecamp app | Medium | Closed ([Solution](solutions/LP-0017.md)) | +| [LP-0023](prizes/LP-0023.md) | Program Registry: verified builds for LEZ programs | Large | Draft | > [!IMPORTANT] > **Legacy scheme wind-down.** To make room for adoption-first prizes, **LP-0002**, **LP-0003**, and **LP-0008** close on **11 September 2026 at 23:59 CEST**. No new submissions will be accepted after that time. If you have already submitted a solution, yours will be reviewed first. In-flight submissions received before the deadline will still be evaluated. Prizes already marked *Closed* are unaffected. 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 b0cb928c179a67b8b251742723e38493d93a378a Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Mon, 17 Aug 2026 15:25:57 +1000 Subject: [PATCH 02/18] 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 180fdcb4017b9f76bd832d4dcfbd2d75108e41a4 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Mon, 24 Aug 2026 15:22:42 +1000 Subject: [PATCH 03/18] 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 981ab2e95fcd538047d1f9a422ae1e66fe90008e Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Mon, 24 Aug 2026 15:38:41 +1000 Subject: [PATCH 04/18] 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 843d44787f7804566c24133a02dc384cc3ebaaa3 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Mon, 24 Aug 2026 15:40:08 +1000 Subject: [PATCH 05/18] 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 94b9f815eb816ef78a5a48759f7dc47442f7e3a4 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 26 Aug 2026 17:12:54 +1000 Subject: [PATCH 06/18] 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 e056aadefa043eea3dafed0b5d304aa125ede4b4 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 26 Aug 2026 17:17:02 +1000 Subject: [PATCH 07/18] 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 c663bfa653a91c9f95984e914b9bca21e06cca9e Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 26 Aug 2026 17:18:59 +1000 Subject: [PATCH 08/18] 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 9f2a4db14728cb5f3acc1b3a3b6b9e681ec3cf4e Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 26 Aug 2026 17:20:16 +1000 Subject: [PATCH 09/18] 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 7207d930bc68e566fe9cd41b482c932391ce505d Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 27 Aug 2026 10:33:53 +1000 Subject: [PATCH 10/18] 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 a979583af74f143d528a2198d74882322b77474b Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 27 Aug 2026 11:00:34 +1000 Subject: [PATCH 11/18] 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 63080d9dfd5a4b4d1aa27cc7be32f02fc5d8f63b Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 27 Aug 2026 13:18:19 +1000 Subject: [PATCH 12/18] 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 723aaf0be62287e41e5d5d2b4a3b5b7876659171 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 27 Aug 2026 13:30:06 +1000 Subject: [PATCH 13/18] 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 5ed38f93ac826daecf0cda1853d5210bbc2a1cd9 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 27 Aug 2026 13:33:02 +1000 Subject: [PATCH 14/18] 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 c4651256f4218a7ab22ed2cda0d00d3a8dc93655 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 28 Aug 2026 12:55:39 +1000 Subject: [PATCH 15/18] 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 0f082530..61bea5a7 100644 --- a/README.md +++ b/README.md @@ -52,7 +52,7 @@ All prizes live in the `[prizes/](prizes/)` directory. Each prize is a markdown | [LP-0015](prizes/LP-0015.md) | General cross-program calls via tail calls | Large | Closed | | [LP-0016](prizes/LP-0016.md) | Anonymous Forum with Threshold Moderation | Large | Closed ([Solution](solutions/LP-0016.md)) | | [LP-0017](prizes/LP-0017.md) | Whistleblower: document upload and indexing Basecamp app | Medium | Closed ([Solution](solutions/LP-0017.md)) | -| [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 | Draft | > [!IMPORTANT] > **Legacy scheme wind-down.** To make room for adoption-first prizes, **LP-0002**, **LP-0003**, and **LP-0008** close on **11 September 2026 at 23:59 CEST**. No new submissions will be accepted after that time. If you have already submitted a solution, yours will be reviewed first. In-flight submissions received before the deadline will still be evaluated. Prizes already marked *Closed* are unaffected. 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 38b311a2e7d67a1f92a32aa44a010ea8cc5a17ee 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/18] LP-0023: mark prize as Open, no longer Draft Co-authored-by: Cursor --- README.md | 2 +- prizes/LP-0023.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 61bea5a7..db62ed03 100644 --- a/README.md +++ b/README.md @@ -52,7 +52,7 @@ All prizes live in the `[prizes/](prizes/)` directory. Each prize is a markdown | [LP-0015](prizes/LP-0015.md) | General cross-program calls via tail calls | Large | Closed | | [LP-0016](prizes/LP-0016.md) | Anonymous Forum with Threshold Moderation | Large | Closed ([Solution](solutions/LP-0016.md)) | | [LP-0017](prizes/LP-0017.md) | Whistleblower: document upload and indexing Basecamp app | Medium | Closed ([Solution](solutions/LP-0017.md)) | -| [LP-0023](prizes/LP-0023.md) | LEZ Program Registry | Small | Draft | +| [LP-0023](prizes/LP-0023.md) | LEZ Program Registry | Small | Open | > [!IMPORTANT] > **Legacy scheme wind-down.** To make room for adoption-first prizes, **LP-0002**, **LP-0003**, and **LP-0008** close on **11 September 2026 at 23:59 CEST**. No new submissions will be accepted after that time. If you have already submitted a solution, yours will be reviewed first. In-flight submissions received before the deadline will still be evaluated. Prizes already marked *Closed* are unaffected. 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 a6147fc899d12a4b7afa45e14bdfe00ad04e4921 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 2 Sep 2026 14:51:36 +1000 Subject: [PATCH 17/18] 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 a091aa8a2191eb4220da5dcb4ba595ef79f8b2a7 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 3 Sep 2026 14:28:57 +1000 Subject: [PATCH 18/18] 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). --- README.md | 2 +- prizes/LP-0023.md | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index db62ed03..e9fa3e76 100644 --- a/README.md +++ b/README.md @@ -31,6 +31,7 @@ All prizes live in the `[prizes/](prizes/)` directory. Each prize is a markdown | File | Description | Size | Status | |------|-------------|------|--------| | [LP-0000](prizes/LP-0000.md) | Template — use this as the starting point for new prizes | — | — | +| [LP-0023](prizes/LP-0023.md) | LEZ Program Registry | Small | Open | ### Legacy prizes (original scheme) @@ -52,7 +53,6 @@ All prizes live in the `[prizes/](prizes/)` directory. Each prize is a markdown | [LP-0015](prizes/LP-0015.md) | General cross-program calls via tail calls | Large | Closed | | [LP-0016](prizes/LP-0016.md) | Anonymous Forum with Threshold Moderation | Large | Closed ([Solution](solutions/LP-0016.md)) | | [LP-0017](prizes/LP-0017.md) | Whistleblower: document upload and indexing Basecamp app | Medium | Closed ([Solution](solutions/LP-0017.md)) | -| [LP-0023](prizes/LP-0023.md) | LEZ Program Registry | Small | Open | > [!IMPORTANT] > **Legacy scheme wind-down.** To make room for adoption-first prizes, **LP-0002**, **LP-0003**, and **LP-0008** close on **11 September 2026 at 23:59 CEST**. No new submissions will be accepted after that time. If you have already submitted a solution, yours will be reviewed first. In-flight submissions received before the deadline will still be evaluated. Prizes already marked *Closed* are unaffected. 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).