mirror of
https://github.com/logos-co/lambda-prize.git
synced 2026-08-31 03:21:07 +00:00
Merge pull request #33 from logos-co/evaluation-policies
Add evaluation policies: submission limits, feedback model, demo walk…
This commit is contained in:
mart1:n
@@ -40,7 +40,7 @@ All prizes live in the `[prizes/](prizes/)` directory. Each prize is a markdown
|
||||
| [LP-0014](prizes/LP-0014.md) | Token program improvements (ATAs + wallet tooling) | Medium | Closed |
|
||||
| [LP-0015](prizes/LP-0015.md) | General cross-program calls via tail calls | Large | Open |
|
||||
| [LP-0016](prizes/LP-0016.md) | Anonymous Forum with Threshold Moderation | Large | Open |
|
||||
| [LP-0017](prizes/LP-0017.md) | Whistleblower: document upload and indexing mini-app | Medium | Open |
|
||||
| [LP-0017](prizes/LP-0017.md) | Whistleblower: document upload and indexing Basecamp app | Medium | Open |
|
||||
|
||||
### Proposing a New Prize
|
||||
|
||||
@@ -69,6 +69,16 @@ If multiple solutions target the same prize, the first submission that satisfies
|
||||
>
|
||||
> Submissions through this repository are now open and follow the standard first-come-first-served process. However, Parallel Society submissions that are still being evaluated take precedence.
|
||||
|
||||
### Evaluation Policies
|
||||
|
||||
The following policies apply to **all** prizes unless a specific prize states otherwise.
|
||||
|
||||
**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 simple pass/fail result based on the success criteria. For more detailed guidance or technical discussion, builders are encouraged to participate in the community Discord. The #builder-hub channel is the best place to ask questions and engage with evaluators or other builders.
|
||||
|
||||
**Demo requirements.** Every submission that requires a demo must include a narrated video walkthrough in which the builder explains what they built and why, walks through the architecture and key implementation decisions, and demonstrates the full end-to-end flow. A silent screencast without explanation is not sufficient. Prize-specific demo content is listed in each prize's **Submission Requirements**.
|
||||
|
||||
## Terms & Conditions
|
||||
|
||||
All participants are bound by the [Terms & Conditions](TERMS.md). Key points:
|
||||
|
||||
+16
-2
@@ -27,7 +27,7 @@
|
||||
>
|
||||
> **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 mini-app GUI with local build instructions, downloadable assets, and loadable in Logos app (Basecamp) via git repo.
|
||||
> - 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.
|
||||
@@ -38,7 +38,7 @@
|
||||
> - 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 mini-app.
|
||||
> - 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.
|
||||
|
||||
@@ -70,6 +70,15 @@
|
||||
|
||||
> 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
|
||||
@@ -78,6 +87,11 @@
|
||||
>
|
||||
> 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.
|
||||
|
||||
+8
-3
@@ -29,7 +29,7 @@ A competitive prize is the right mechanism here because the problem is well-spec
|
||||
### Usability
|
||||
|
||||
- [ ] Provide a module/SDK that can be used to build Logos modules for interacting with the program.
|
||||
- [ ] Provide a Logos mini-app GUI with local build instructions, downloadable assets, and loadable in Logos app (Basecamp) via git repo.
|
||||
- [ ] 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
|
||||
@@ -46,7 +46,7 @@ A competitive prize is the right mechanism here because the problem is well-spec
|
||||
- [ ] 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 mini-app.
|
||||
- [ ] 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.
|
||||
|
||||
@@ -79,7 +79,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho
|
||||
|
||||
- Public repository containing all circuit code, LEZ program code, and client-side tooling, licensed under MIT or Apache-2.0.
|
||||
- Deployment of the verifier program on LEZ testnet, with a verified program ID.
|
||||
- A working end-to-end demo (video or live link) showing proof generation and on-chain verification for at least one token-gating use case.
|
||||
- End-to-end demo video in which the builder narrates what they built and why, walks through the architecture and key implementation decisions, and demonstrates proof generation and on-chain verification for at least one token-gating use case. A silent screencast is not sufficient (see [demo requirements](../README.md#evaluation-policies)).
|
||||
- A write-up covering: cryptographic approach, proving system used, Merkle tree construction, nullifier/domain-separation scheme, security assumptions, known limitations, and integration instructions.
|
||||
- Gas cost benchmarks for on-chain verification.
|
||||
- GitHub issues open for any problem encountered with Logos technology.
|
||||
@@ -90,6 +90,11 @@ Submissions are evaluated first-come-first-served against the success criteria.
|
||||
|
||||
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
|
||||
|
||||
- [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone)
|
||||
|
||||
+8
-3
@@ -31,7 +31,7 @@ A competitive prize is the right mechanism because the design space is large: ch
|
||||
### Usability
|
||||
|
||||
- [ ] Provide a module/SDK that can be used to build Logos modules for interacting with the program.
|
||||
- [ ] Provide a Logos mini-app GUI with local build instructions, downloadable assets, and loadable in Logos app (Basecamp) via git repo.
|
||||
- [ ] 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
|
||||
@@ -49,7 +49,7 @@ A competitive prize is the right mechanism because the design space is large: ch
|
||||
- [ ] 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 mini-app.
|
||||
- [ ] 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.
|
||||
|
||||
@@ -83,7 +83,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho
|
||||
|
||||
- Public repository with all circuit code, LEZ program code, and client-side tooling under MIT or Apache-2.0.
|
||||
- Verifier program deployed on LEZ testnet with a verified program ID.
|
||||
- End-to-end demo (video or live link) showing M-of-N approval and execution using shielded member accounts.
|
||||
- End-to-end demo video in which the builder narrates what they built and why, walks through the architecture and key implementation decisions, and demonstrates M-of-N approval and execution using shielded member accounts. A silent screencast is not sufficient (see [demo requirements](../README.md#evaluation-policies)).
|
||||
- Write-up covering: threshold proof scheme, nullifier design, LEZ account model compatibility (specifically how the nonce and `program_owner` constraints are handled), security assumptions, known limitations, and integration instructions.
|
||||
- Proof generation time and on-chain verification gas cost benchmarks.
|
||||
|
||||
@@ -93,6 +93,11 @@ Submissions are evaluated first-come-first-served against the success criteria.
|
||||
|
||||
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
|
||||
|
||||
- [lez-multisig](https://github.com/jimmy-claw/lez-multisig) — public multisig PoC; architecture notes describe why private accounts are incompatible
|
||||
|
||||
+8
-3
@@ -33,7 +33,7 @@ Logos' shielded account model offers a richer design surface than standard EVM e
|
||||
### Usability
|
||||
|
||||
- [ ] Provide a module/SDK that can be used to build Logos modules for interacting with the program.
|
||||
- [ ] Provide a Logos mini-app GUI with local build instructions, downloadable assets, and loadable in Logos app (Basecamp) via git repo.
|
||||
- [ ] 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
|
||||
@@ -51,7 +51,7 @@ Logos' shielded account model offers a richer design surface than standard EVM e
|
||||
- [ ] 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 mini-app.
|
||||
- [ ] 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.
|
||||
|
||||
@@ -84,7 +84,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho
|
||||
|
||||
- Public repository with all circuit code, LEZ program code, and client-side tooling under MIT or Apache-2.0.
|
||||
- Program deployed on LEZ testnet with a verified program ID.
|
||||
- End-to-end demo (video or live link) showing a private claim from a shielded account.
|
||||
- End-to-end demo video in which the builder narrates what they built and why, walks through the architecture and key implementation decisions, and demonstrates a private claim from a shielded account. A silent screencast is not sufficient (see [demo requirements](../README.md#evaluation-policies)).
|
||||
- Write-up covering: commitment scheme, claim-uniqueness mechanism, privacy model (what on-chain observers and the distributor learn at each stage, stated threat model, and any residual leakage or limitations), LEZ account model compatibility, security assumptions, known limitations, and integration instructions.
|
||||
- Proof generation time and on-chain verification compute unit benchmarks.
|
||||
- GitHub issues open for any problem encountered with Logos technology.
|
||||
@@ -96,6 +96,11 @@ Submissions are evaluated first-come-first-served against the success criteria.
|
||||
|
||||
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
|
||||
|
||||
- [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/)
|
||||
|
||||
+8
-3
@@ -31,7 +31,7 @@ A competitive prize is the right mechanism because the design space is large: au
|
||||
### Usability
|
||||
|
||||
- [ ] Provide a module/SDK that can be used to build Logos modules for interacting with the program.
|
||||
- [ ] Provide a Logos mini-app GUI with local build instructions, downloadable assets, and loadable in Logos app (Basecamp) via git repo.
|
||||
- [ ] 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
|
||||
@@ -49,7 +49,7 @@ A competitive prize is the right mechanism because the design space is large: au
|
||||
- [ ] 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 mini-app.
|
||||
- [ ] 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.
|
||||
|
||||
@@ -84,7 +84,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho
|
||||
|
||||
- Public repository with LEZ program code and client-side tooling under MIT or Apache-2.0.
|
||||
- Program deployed on LEZ testnet with a verified program ID.
|
||||
- End-to-end demo (video or live link) showing a full auction lifecycle with at least three bidders using shielded accounts.
|
||||
- End-to-end demo video in which the builder narrates what they built and why, walks through the architecture and key implementation decisions, and demonstrates a full auction lifecycle with at least three bidders using shielded accounts. A silent screencast is not sufficient (see [demo requirements](../README.md#evaluation-policies)).
|
||||
- Write-up covering: auction format and rationale, how shielded balances are used for escrow, winner determination and refund mechanics, security assumptions (e.g. miner/sequencer front-running), known limitations, and integration instructions.
|
||||
- Gas cost benchmarks for bid submission, winner determination, and refund issuance.
|
||||
|
||||
@@ -94,6 +94,11 @@ Submissions are evaluated first-come-first-served against the success criteria.
|
||||
|
||||
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
|
||||
|
||||
- [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/)
|
||||
|
||||
+8
-4
@@ -37,7 +37,7 @@ A competitive prize is the right mechanism because the proving strategy, nullifi
|
||||
### Usability
|
||||
|
||||
- [ ] Provide a module/SDK that can be used to build Logos modules for interacting with the program.
|
||||
- [ ] Provide a Logos mini-app GUI with local build instructions, downloadable assets, and loadable in Logos app (Basecamp) via git repo.
|
||||
- [ ] 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
|
||||
@@ -55,7 +55,7 @@ A competitive prize is the right mechanism because the proving strategy, nullifi
|
||||
- [ ] 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 mini-app (for both on-chain and off-chain verification paths).
|
||||
- [ ] 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 (for both on-chain and off-chain verification paths).
|
||||
- [ ] 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.
|
||||
|
||||
@@ -95,8 +95,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho
|
||||
|
||||
- Public repository with all circuit code, LEZ verifier program, off-chain verifier library, and client-side tooling under MIT or Apache-2.0.
|
||||
- Verifier program deployed on LEZ testnet with a verified program ID.
|
||||
- End-to-end demo (video or live link) for the on-chain path: proof generation and on-chain verification against a threshold.
|
||||
- End-to-end demo (video or live link) for the off-chain path: proof transmitted over Logos Messaging and verified locally to gate access (e.g., chat group admission).
|
||||
- End-to-end demo video in which the builder narrates what they built and why, walks through the architecture and key implementation decisions, and demonstrates both verification paths. The demo must cover the on-chain path (proof generation and on-chain verification against a threshold) and the off-chain path (proof transmitted over Logos Messaging and verified locally to gate access, e.g., chat group admission). A silent screencast is not sufficient (see [demo requirements](../README.md#evaluation-policies)).
|
||||
- Write-up covering: circuit design, commitment format targeting, context-binding approach, both verification paths, privacy guarantees (including what is and is not hidden), security assumptions, known limitations, and integration instructions.
|
||||
- Proof generation time and on-chain verification gas cost benchmarks.
|
||||
|
||||
@@ -106,6 +105,11 @@ Submissions are evaluated first-come-first-served against the success criteria.
|
||||
|
||||
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
|
||||
|
||||
- [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/)
|
||||
|
||||
+8
-3
@@ -73,7 +73,7 @@ The following assumptions underpin the security and reliability of the atomic sw
|
||||
### Usability
|
||||
|
||||
- [ ] A **CLI** is provided for both maker and taker roles. The maker CLI covers the full swap lifecycle. The taker CLI may have limited functionality if a GUI is the primary taker interface.
|
||||
- [ ] A **GUI** (Logos mini-app) is provided for both maker and taker roles, with local build instructions, downloadable assets, and loadable in Logos app (Basecamp) via git repo.
|
||||
- [ ] A **GUI** (Logos Basecamp app) is provided for both maker and taker roles, with local build instructions, downloadable assets, and loadable in Logos app (Basecamp).
|
||||
- [ ] A **module/SDK** is provided that can be used to build Logos modules for interacting with the swap system.
|
||||
- [ ] An **IDL** is provided for the LEZ escrow program(s), using the [SPEL framework](https://github.com/logos-co/spel).
|
||||
|
||||
@@ -93,7 +93,7 @@ The following assumptions underpin the security and reliability of the atomic sw
|
||||
- [ ] 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 reference integration is delivered for each chain: working demos of complete swaps on Bitcoin testnet, Monero stagenet, Ethereum Sepolia, and LEZ testnet 0.2.
|
||||
- [ ] Full documentation and a clean public repository are delivered, including deployment steps, program addresses, and step-by-step instructions for interacting with the program via CLI and mini-app. Documentation must include clear **prerequisites for each chain** (e.g., Bitcoin Core node URL, Monero node + wallet RPC URLs, Ethereum Web3 RPC URL, LEZ testnet access) and step-by-step setup instructions for both maker and taker sides.
|
||||
- [ ] Full documentation and a clean public repository are delivered, including deployment steps, program addresses, and step-by-step instructions for interacting with the program via CLI and Basecamp app. Documentation must include clear **prerequisites for each chain** (e.g., Bitcoin Core node URL, Monero node + wallet RPC URLs, Ethereum Web3 RPC URL, LEZ testnet access) and step-by-step setup instructions for both maker and taker sides.
|
||||
- [ ] A reproducible end-to-end demo script is provided for each supported chain and works against a real local sequencer with `RISC0_DEV_MODE=0`.
|
||||
- [ ] Recorded video demos are included in the submission; each recording must show terminal output (including proof generation) to confirm `RISC0_DEV_MODE=0` was active.
|
||||
|
||||
@@ -155,7 +155,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho
|
||||
|
||||
- Public repository with Bitcoin, Monero, and Ethereum swap implementations, LEZ escrow program(s), and coordination tooling under MIT or Apache-2.0.
|
||||
- LEZ escrow program deployed on LEZ testnet 0.2 with a verified program ID.
|
||||
- **Demo videos** — for **each supported chain** (Bitcoin, Monero, Ethereum), three separate recorded demos showing a complete end-to-end swap with LEZ:
|
||||
- **Demo videos** — for **each supported chain** (Bitcoin, Monero, Ethereum), three separate narrated recordings in which the builder explains what they built and why, walks through the architecture and key implementation decisions, and demonstrates a complete end-to-end swap with LEZ. A silent screencast is not sufficient (see [demo requirements](../README.md#evaluation-policies)). Each chain must show:
|
||||
1. A **happy path** swap: both parties complete the protocol successfully.
|
||||
2. A **refund/timeout path** swap: one party abandons the protocol and the other recovers their funds via the timelock refund.
|
||||
3. A **concurrent swap** demo: two or more swaps executing in parallel, demonstrating that the system handles multiple in-flight swaps correctly.
|
||||
@@ -168,6 +168,11 @@ Submissions are evaluated first-come-first-served against the success criteria.
|
||||
|
||||
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
|
||||
|
||||
### General
|
||||
|
||||
+6
-1
@@ -155,7 +155,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho
|
||||
|
||||
- Public repository with the Logos Core module, CLI, and all default skill implementations under MIT or Apache-2.0.
|
||||
- Module loadable on LEZ testnet with a documented deployment procedure.
|
||||
- End-to-end demos (video or live links) for at least 3 of the illustrative use cases.
|
||||
- End-to-end demo video(s) for at least 3 of the illustrative use cases, in which the builder narrates what they built and why, walks through the architecture and key implementation decisions, and demonstrates the full flow. A silent screencast is not sufficient (see [demo requirements](../README.md#evaluation-policies)).
|
||||
- Evidence of at least 5 third-party agent deployments on LEZ testnet (e.g., linked public activity, attestations, or on-chain records).
|
||||
- Write-up covering: module architecture, skill interface design, spending threshold mechanism, agent-to-agent coordination protocol, security model (what the agent can and cannot do without owner approval), known limitations, and integration instructions.
|
||||
|
||||
@@ -165,6 +165,11 @@ Submissions are evaluated first-come-first-served against the success criteria.
|
||||
|
||||
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
|
||||
|
||||
- [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/)
|
||||
|
||||
@@ -115,12 +115,19 @@ Open to any individual or team. Submissions must be original work. Teams must ho
|
||||
- tests (CI runnable via `cargo test`).
|
||||
- Clear versioning and a minimal changelog.
|
||||
- If any macros are used, include a section documenting what each macro expands into and why it is necessary (Rust procedural macros execute at compile time and should be treated with the same care as build scripts)
|
||||
- A narrated video walkthrough in which the builder explains what they built and why, walks through the architecture and key implementation decisions, and demonstrates the full end-to-end flow. A silent screencast is not sufficient (see [demo requirements](../README.md#evaluation-policies)).
|
||||
|
||||
## Evaluation Process
|
||||
|
||||
By default, submissions are evaluated first-come-first-served against the success criteria. The first submission that meets **all** criteria wins.
|
||||
|
||||
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
|
||||
|
||||
- [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone)
|
||||
|
||||
@@ -117,6 +117,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho
|
||||
- success-path events,
|
||||
- failure-path events (emit then fail),
|
||||
- reference indexer example (can be minimal).
|
||||
- A narrated video walkthrough in which the builder explains what they built and why, walks through the architecture and key implementation decisions, and demonstrates the full end-to-end flow. A silent screencast is not sufficient (see [demo requirements](../README.md#evaluation-policies)).
|
||||
|
||||
## Evaluation Process
|
||||
|
||||
@@ -124,6 +125,11 @@ By default, submissions are evaluated first-come-first-served against the succes
|
||||
|
||||
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
|
||||
|
||||
- [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone)
|
||||
|
||||
@@ -74,6 +74,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho
|
||||
- code changes to the token program,
|
||||
- `README` + design docs (authority model and lifecycle),
|
||||
- tests and example programmes/scripts.
|
||||
- A narrated video walkthrough in which the builder explains what they built and why, walks through the architecture and key implementation decisions, and demonstrates the full end-to-end flow. A silent screencast is not sufficient (see [demo requirements](../README.md#evaluation-policies)).
|
||||
|
||||
## Evaluation Process
|
||||
|
||||
@@ -81,6 +82,11 @@ By default, submissions are evaluated first-come-first-served against the succes
|
||||
|
||||
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
|
||||
|
||||
- [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone)
|
||||
|
||||
+6
-1
@@ -95,7 +95,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho
|
||||
- specification document (`docs/general-calls-via-tail-c-calls.md`),
|
||||
- example programs (A and B) + scripts to run the demo,
|
||||
- tests runnable in CI.
|
||||
- A short walkthrough (README or video) showing:
|
||||
- A narrated video walkthrough in which the builder explains what they built and why, walks through the architecture and key implementation decisions, and demonstrates (see [demo requirements](../README.md#evaluation-policies)):
|
||||
- the developer-facing API for general calls,
|
||||
- the tail-call chain produced at runtime,
|
||||
- failure when a user attempts to invoke an internal function directly.
|
||||
@@ -106,6 +106,11 @@ By default, submissions are evaluated first-come-first-served against the succes
|
||||
|
||||
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
|
||||
|
||||
- [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone)
|
||||
|
||||
+13
-8
@@ -9,7 +9,7 @@ This prize is for a protocol for anonymous, moderated forums. Members post witho
|
||||
|
||||
All forum activity and moderation happens off-chain using the Logos stack — nothing goes on-chain until a member reaches the revocation threshold and a slash is submitted. This keeps the common path free of transaction costs while preserving trustless enforcement at the point of revocation.
|
||||
|
||||
The deliverable has two required parts: a **forum-agnostic moderation library** (a standalone SDK for threshold moderation and cryptographic membership revocation, making no assumptions about forum content or structure) and an **end application** (a working Logos mini-app of any forum shape built on top of the library).
|
||||
The deliverable has two required parts: a **forum-agnostic moderation library** (a standalone SDK for threshold moderation and cryptographic membership revocation, making no assumptions about forum content or structure) and an **end application** (a working Logos Basecamp app of any forum shape built on top of the library).
|
||||
|
||||
## Motivation
|
||||
|
||||
@@ -60,7 +60,7 @@ Each forum is an independent instance with its own membership registry, moderato
|
||||
- [ ] A slashed commitment is added to the revocation list. Subsequent posts with a membership proof tied to that commitment are rejected.
|
||||
- [ ] The protocol is parameterisable: forum instances can independently set K (revocation threshold) and N-of-M.
|
||||
- [ ] A standalone, forum-agnostic moderation library exposing well-documented APIs for: membership registration, encrypted proof generation and verification, moderation certificate construction, and slash submission. The library operates on abstract content identifiers, makes no assumptions about forum content structure, and uses the Logos stack for all off-chain activity.
|
||||
- [ ] A working Logos mini-app (runnable inside the Logos app), built using the library without modifying it. The app allows anyone to create a new forum instance, post, moderate it, and set moderators. The specific forum functionality (text posts, image board, comments, reactions, etc.) is at the applicant's discretion. The app demonstrates the full moderation lifecycle: instance creation, registration, publishing content, moderation, and revocation. The app must be usable by a non-technical user: core actions (posting, moderating, viewing moderation history) must complete within a reasonable time frame and without requiring CLI interaction or manual transaction crafting.
|
||||
- [ ] A working Logos Basecamp app, built using the library without modifying it. The app allows anyone to create a new forum instance, post, moderate it, and set moderators. The specific forum functionality (text posts, image board, comments, reactions, etc.) is at the applicant's discretion. The app demonstrates the full moderation lifecycle: instance creation, registration, publishing content, moderation, and revocation. The app must be usable by a non-technical user: core actions (posting, moderating, viewing moderation history) must complete within a reasonable time frame and without requiring CLI interaction or manual transaction crafting.
|
||||
- [ ] End-to-end demonstration on LEZ testnet with at least two independent forum instances using different K and N-of-M parameters.
|
||||
|
||||
### Usability
|
||||
@@ -84,9 +84,9 @@ Each forum is an independent instance with its own membership registry, moderato
|
||||
- [ ] The membership registry 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 creating a forum instance, registering, posting, moderating, and triggering a slash via the mini-app.
|
||||
- [ ] A README documents end-to-end usage: deployment steps, program addresses, and step-by-step instructions for creating a forum instance, registering, posting, moderating, and triggering a slash via the 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.
|
||||
- [ ] A recorded video demo is included in the submission. The builder must narrate and walk through the architecture, key implementation decisions, and the full end-to-end flow — not merely screen-record a silent run. The recording must show terminal output (including proof generation) to confirm `RISC0_DEV_MODE=0` was active.
|
||||
|
||||
## Scope
|
||||
|
||||
@@ -96,7 +96,7 @@ Each forum is an independent instance with its own membership registry, moderato
|
||||
- **ZK membership proof circuit**: proves commitment is in the registry and not revoked, without revealing which commitment. It takes less than 10 seconds to generate a message proof.
|
||||
- **Moderation library**: a standalone, forum-agnostic SDK for threshold moderation and cryptographic membership revocation. It operates on abstract content identifiers, makes no assumptions about the shape of forum content, and uses the Logos stack for all off-chain activity. It handles threshold decryption coordination, certificate construction, share aggregation, and slash transaction submission. Must be importable by any application regardless of forum type.
|
||||
- **Slash verifier**: verifies accumulated off-chain certificates and submits a valid on-chain slash transaction.
|
||||
- **End application**: a Logos mini-app, runnable inside the Logos app, built using the moderation library. The app must allow users to create new forum instances. Forum content and moderation are handled off-chain via the Logos stack. The specific forum functionality — content types, interaction model, layout — is left entirely to the applicant. The application must not require changes to the library to function.
|
||||
- **End application**: a Logos Basecamp app built using the moderation library. The app must allow users to create new forum instances. Forum content and moderation are handled off-chain via the Logos stack. The specific forum functionality — content types, interaction model, layout — is left entirely to the applicant. The application must not require changes to the library to function.
|
||||
- Documentation covering: library API reference, integration guide, unlinkability analysis (including anonymity set size and the retroactive deanonymization property upon slash), moderator trust model, and threat model.
|
||||
|
||||
### Out of Scope
|
||||
@@ -105,7 +105,7 @@ Each forum is an independent instance with its own membership registry, moderato
|
||||
- Reputation tiers or rate limits on posting frequency.
|
||||
- Multi-forum identity linking or cross-forum revocation.
|
||||
- End-to-end encryption of forum content — applicants may implement it but it is not required.
|
||||
- Hosted infrastructure beyond what is required to run the Logos mini-app.
|
||||
- Hosted infrastructure beyond what is required to run the Logos Basecamp app.
|
||||
|
||||
## Prize Structure
|
||||
|
||||
@@ -123,10 +123,10 @@ Open to any individual or team. Submissions must be original work. Teams must ho
|
||||
- ZK membership proof circuit,
|
||||
- **moderation library** (forum-agnostic, standalone package) with public API, documentation, and usage examples,
|
||||
- slash verifier,
|
||||
- **Logos mini-app** (runnable in the Logos app) built on the library without modifying it — forum functionality at applicant's discretion,
|
||||
- **Logos Basecamp app** built on the library without modifying it — forum functionality at applicant's discretion,
|
||||
- tests covering: valid registration, valid post proof, moderation certificate construction and verification, strike accumulation, slash submission, post rejection after revocation.
|
||||
- Protocol specification (`docs/protocol.md`) covering: unlinkability argument, moderator trust assumptions, revocation mechanism, and threat model.
|
||||
- End-to-end demo (video or live link) showing: registration, posting, N-of-M moderation, strike accumulation, slash, and post rejection.
|
||||
- End-to-end demo video walkthrough in which the builder explains what they built and why, walks through the architecture and key implementation decisions, and demonstrates the full lifecycle: registration, posting, N-of-M moderation, strike accumulation, slash, and post rejection. A screencast without narration or explanation is not sufficient.
|
||||
- Two live forum instances on LEZ testnet with different K and N-of-M parameters and verified program IDs.
|
||||
|
||||
## Evaluation Process
|
||||
@@ -135,6 +135,11 @@ By default, submissions are evaluated first-come-first-served against the succes
|
||||
|
||||
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
|
||||
|
||||
- [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone)
|
||||
|
||||
+13
-8
@@ -1,11 +1,11 @@
|
||||
# LP-0017: Whistleblower — censorship-resistant document upload and indexing mini-app [OPEN]
|
||||
# LP-0017: Whistleblower — censorship-resistant document upload and indexing Basecamp app [OPEN]
|
||||
|
||||
**`Status: Open`**
|
||||
**`Logos Circle: N/A`**
|
||||
|
||||
## Overview
|
||||
|
||||
This prize funds **Whistleblower**, a Logos mini-app that lets anyone upload a document and make it permanently discoverable — without relying on any centralised server, without requiring the publisher to hold tokens, and without a single point of censorship.
|
||||
This prize funds **Whistleblower**, a Logos Basecamp app that lets anyone upload a document and make it permanently discoverable — without relying on any centralised server, without requiring the publisher to hold tokens, and without a single point of censorship.
|
||||
|
||||
A user selects a file, adds optional metadata, and submits. The app uploads the file to Logos Storage, broadcasts the resulting content identifier (CID) and metadata over Logos Delivery so the document is immediately discoverable, and optionally anchors the CID on-chain for long-term indexing. Long-term anchoring can also happen independently: a permissionless batch tool lets any altruistic actor or original uploader gather broadcasted CIDs and commit them to a LEZ program or the consensus layer in a single transaction — no coordination with the original publisher required.
|
||||
|
||||
@@ -39,11 +39,11 @@ No sample app in the Logos ecosystem yet demonstrates this full pipeline end-to-
|
||||
- store `(CID, metadata_hash, anchor_timestamp)` per document,
|
||||
- be queryable by CID,
|
||||
- accept batch submissions of at least 10 CIDs per transaction.
|
||||
- [ ] **Document-indexing module**: extract the upload → broadcast → anchor logic into a self-contained module with a documented API, reusable by other Logos apps without depending on the Whistleblower mini-app itself.
|
||||
- [ ] **Document-indexing module**: extract the upload → broadcast → anchor logic into a self-contained module with a documented API, reusable by other Logos apps without depending on the Whistleblower Basecamp app itself.
|
||||
|
||||
### Usability
|
||||
|
||||
- [ ] Provide a Logos mini-app GUI with local build instructions, downloadable assets, and loadable in Logos app (Basecamp) via git repo.
|
||||
- [ ] Provide a Logos Basecamp app GUI with local build instructions, downloadable assets, and loadable in Logos app (Basecamp).
|
||||
- [ ] Provide the document-indexing module as a library/SDK with a README covering its API and integration steps.
|
||||
- [ ] Provide an IDL for the LEZ program (if the LEZ program approach is chosen), using the [SPEL framework](https://github.com/logos-co/spel).
|
||||
|
||||
@@ -62,7 +62,7 @@ No sample app in the Logos ecosystem yet demonstrates this full pipeline end-to-
|
||||
- [ ] The on-chain registry is deployed and tested on LEZ devnet/testnet.
|
||||
- [ ] End-to-end integration tests covering upload → broadcast → batch anchor run against a LEZ sequencer in standalone mode and are included in CI.
|
||||
- [ ] CI is green on the default branch.
|
||||
- [ ] A README covers: build steps, deployment addresses, running the mini-app, running the batch anchor tool, and querying the on-chain registry.
|
||||
- [ ] A README covers: build steps, deployment addresses, running the Basecamp app, running the batch anchor tool, and querying the on-chain registry.
|
||||
- [ ] 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.
|
||||
|
||||
@@ -70,7 +70,7 @@ No sample app in the Logos ecosystem yet demonstrates this full pipeline end-to-
|
||||
|
||||
### In Scope
|
||||
|
||||
- Whistleblower mini-app (Logos mini-app, loadable in Basecamp).
|
||||
- Whistleblower Logos Basecamp app.
|
||||
- Document-indexing module extracted from the app, with documented API.
|
||||
- On-chain CID registry: LEZ program or zone SDK (submitter chooses and justifies).
|
||||
- Permissionless batch anchor CLI tool.
|
||||
@@ -96,13 +96,13 @@ Open to any individual or team. Submissions must be original work. Teams must ho
|
||||
## Submission Requirements
|
||||
|
||||
- Public repository (MIT and Apache-2.0) containing:
|
||||
- the Whistleblower mini-app,
|
||||
- the Whistleblower Basecamp app,
|
||||
- the document-indexing module with API documentation,
|
||||
- the on-chain registry program or zone SDK integration,
|
||||
- the batch anchor CLI tool,
|
||||
- integration tests runnable in CI.
|
||||
- Deployed registry on LEZ devnet/testnet with documented program address.
|
||||
- A walkthrough (README section or video) showing:
|
||||
- A narrated video walkthrough in which the builder explains what they built and why, walks through the architecture and key implementation decisions, and demonstrates (see [demo requirements](../README.md#evaluation-policies)):
|
||||
- a file uploaded and immediately findable via the Logos Delivery topic,
|
||||
- the batch anchor tool picking up the broadcast CID and anchoring it on-chain,
|
||||
- the on-chain registry confirming the CID registration.
|
||||
@@ -115,6 +115,11 @@ By default, submissions are evaluated first-come-first-served against the succes
|
||||
|
||||
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
|
||||
|
||||
- [logos-co/ecosystem#88](https://github.com/logos-co/ecosystem/issues/88) — Whistleblower sample app scope issue
|
||||
|
||||
Reference in New Issue
Block a user