mirror of
https://github.com/logos-co/lambda-prize.git
synced 2026-08-31 03:21:07 +00:00
mart1n
61986e4bd3
Introduce programme-wide evaluation policies to raise the bar for submissions: - Max 3 submissions per prize per builder, one submission/review per week - Pass/fail feedback only; detailed guidance via Discord - Demos must be narrated video walkthroughs covering architecture, decisions, and full end-to-end flow — silent screencasts rejected Policies are defined in README (Evaluation Policies section) and replicated in every non-closed LP's Evaluation Process for self-contained readability. Demo specifics are tailored per prize in each LP's Submission Requirements. Also renames "Logos mini-app" → "Logos Basecamp app" throughout all prizes and the template. Made-with: Cursor
102 lines
5.3 KiB
Markdown
102 lines
5.3 KiB
Markdown
<!-- Don't forget to add/update this prize in the table in README.md -->
|
|
|
|
# LP-XXXX: <Title> [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.
|