# LP-XXXX: [status] **`Status`**: - Draft: Not yet ready - Open: Ready for application - Completed: Submission accepted, prize completed **`Logos Circle: <City/Chapter or N/A>`** ## Overview > One or two paragraphs describing what this prize is for and why it matters to the Logos ecosystem. ## Motivation > Why does this need to exist? What gap does it fill? Why is a competitive prize the right mechanism rather than an RFP? ## Success Criteria > Concrete, measurable outcomes that determine a winner. Be specific — TVL thresholds, performance benchmarks, adoption metrics, etc. Each item should be a testable statement. > > Consider including criteria from each of the following areas (remove any that don't apply): > > **Functionality** — what the system must do. Note: applications must not depend on any centralised server or service. Use the Logos stack for communication: **Logos Delivery** (storage/data availability) for publishing data, and **Logos Chat** (messaging) for peer-to-peer coordination. > > **Usability** — standard requirements for Logos apps (adapt as needed): > - Provide a module/SDK that can be used to build Logos modules for interacting with the program. > - Provide a Logos Basecamp app GUI with local build instructions, downloadable assets, and loadable in Logos app (Basecamp). > - Provide an IDL for the LEZ program, using the [SPEL framework](https://github.com/logos-co/spel). > > **Reliability** — fault tolerance, consistency, graceful degradation, error handling. > > **Performance** — throughput, latency, resource usage. Document compute unit usage of each operation (LEZ's per-transaction compute budget may change during testnet). > > **Supportability** — standard requirements (adapt as needed): > - The program is deployed and tested on LEZ devnet/testnet. > - End-to-end integration tests run against a LEZ sequencer (standalone mode) and are included in CI. > - CI must be green on the default branch. > - A README documents end-to-end usage: deployment steps, program addresses, and step-by-step instructions for interacting with the program via CLI and Basecamp app. > - A reproducible end-to-end demo script is provided and works against a real local sequencer with `RISC0_DEV_MODE=0`. > - A recorded video demo of the end-to-end flow is included in the submission; the recording must show terminal output (including proof generation) to confirm `RISC0_DEV_MODE=0` was active. - [ ] Criterion 1 - [ ] Criterion 2 - [ ] Criterion 3 ## Scope ### In Scope > What the prize covers. ### Out of Scope > What the prize explicitly does not cover. ## Prize Structure - **Total Prize:** $X - **Effort:** XS / S / M / L / XL / Variable > Leave prize pool blank — this will be determined by the Logos team. Single winner by default. Detail here if otherwise. ## Eligibility > Who can participate? Any restrictions? ## Submission Requirements > What must be delivered? Repos, documentation, deployments, demos, etc. > > A narrated video walkthrough demo is always required (see [demo requirements](../README.md#evaluation-policies)). The demo should specifically showcase and discuss: > - End-to-end usage of the solution, from deployment (or setup) through interacting with the program/app/module in all major user scenarios. > - Successful execution of all core functionality, with relevant terminal and/or UI output visible (e.g., proof generation, state changes, error handling). > - Any required integration with the Logos stack (e.g., use of Logos Delivery, Logos Chat, or other modules). > - Any features addressing explicit evaluation or success criteria (e.g., handling of error cases, reliability under failure, compliance with FURPS requirements). > - Unique or innovative design choices, with a brief discussion or illustration during the demo. > - (If applicable) Performance metrics, support/deployment workflow, or anything relevant the evaluators should notice. > The demo must make it easy for evaluators to verify that the implementation meets the stated criteria. > > Submissions must include a FURPS self-assessment as part of the solution (see [solution template](../solutions/LP-0000.md)). ## Evaluation Process > By default, submissions are evaluated first-come-first-served against the success criteria. The first submission that meets all criteria wins. Describe any deviations from this default here. > > Evaluators will independently clone the repository and run the demo script from a clean environment; the script must succeed without modification. Evaluators may also 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 > Links to relevant specs, documentation, APIs, or prior work that participants should know about. ## Potential for Subsequent λPrizes > If this prize targets a specific testnet, codebase version, or external dependency that is expected to change, note here whether a follow-up prize may be opened to cover adaptation to future versions.