logos-co/lambda-prize
1
0
Fork 0
mirror of https://github.com/logos-co/lambda-prize.git synced 2026-08-27 17:41:17 +00:00
Code Issues Packages Projects Releases Wiki Activity

LP-0023: fix markdown formatting and grammar after latest edits

Browse Source 
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.
This commit is contained in:
fryorcraken
2026-08-26 17:15:33 +10:00
parent 41ed2c3f50
commit 790fb4e68c
1 changed files with 25 additions and 59 deletions
Download Patch File Download Diff File Expand all files Collapse all files
prizes/LP-0023.md
+25 -59
View File
@@ -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