From 6c5d648511c61ac233dc01f65122356778624694 Mon Sep 17 00:00:00 2001 From: bristinWild Date: Mon, 18 May 2026 12:21:49 +0530 Subject: [PATCH 01/28] =?UTF-8?q?Solution:=20LP-0013=20=E2=80=94=20Token?= =?UTF-8?q?=20Program=20Improvements:=20Authorities?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- solutions/LP-0013.md | 117 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 117 insertions(+) create mode 100644 solutions/LP-0013.md diff --git a/solutions/LP-0013.md b/solutions/LP-0013.md new file mode 100644 index 0000000..c15e6a1 --- /dev/null +++ b/solutions/LP-0013.md @@ -0,0 +1,117 @@ +# Solution: LP-0013 — Token Program Improvements: Authorities + +**Submitted by:** bristinWild + +## Summary + +This submission implements a complete mint authority model for the LEZ Token program. Fungible tokens can now be created with a designated mint authority that can mint additional supply, rotate control to a new key, or permanently revoke minting to fix the supply. A standalone `lez-authority` crate provides the reusable authority primitive as defined in RFP-001. + +## Repository + +- **Repo:** https://github.com/bristinWild/logos-execution-zone +- **Branch:** `main` +- **Key files:** + - `lez-authority/src/lib.rs` — agnostic `AuthoritySlot` library (RFP-001) + - `programs/token/core/src/lib.rs` — `TokenDefinition::Fungible` with `mint_authority` field, `SetAuthority` and `NewFungibleDefinitionWithAuthority` instructions + - `programs/token/src/mint.rs` — authority-gated `Mint` handler + - `programs/token/src/set_authority.rs` — `SetAuthority` handler (rotation + revocation) + - `programs/token/src/new_definition.rs` — `NewFungibleDefinitionWithAuthority` handler + - `program_methods/guest/src/bin/token.rs` — guest binary dispatch for all new instructions + - `wallet/src/program_facades/token.rs` — `send_set_authority`, `send_new_definition_with_authority` SDK methods + - `integration_tests/tests/token.rs` — 2 integration tests for authority lifecycle + - `scripts/demo-full-flow.sh` — end-to-end demo script + - `scripts/examples/fixed_supply_token.sh` — fixed supply example + - `scripts/examples/variable_supply_token.sh` — variable supply + rotation example + - `docs/LP-0013-README.md` — architecture, usage, and design docs + +## Approach + +### Authority Model + +`mint_authority: Option<[u8; 32]>` is added to `TokenDefinition::Fungible`: +- `Some(key)` — the key holder controls minting and can rotate/revoke +- `None` — supply is permanently fixed; minting is rejected deterministically + +### `lez-authority` Crate (RFP-001) + +A standalone crate with zero dependency on any specific program or `nssa_core`. Provides `AuthoritySlot` with `check()`, `set()` (rotate/revoke), and `is_revoked()`. All logic is unit-tested independently. + +### New Instructions + +| Instruction | Description | +|---|---| +| `NewFungibleDefinitionWithAuthority` | Create token with mint authority from day one | +| `Mint` (updated) | Now authority-gated — rejects if `mint_authority` is `None` | +| `SetAuthority` | Rotate to new key or revoke permanently (pass `None`) | + +### Atomicity + +`SetAuthority` only mutates `mint_authority` after all authorization checks pass. An unauthorized call returns an error before any write occurs — the prior authority is preserved. This is enforced structurally in `AuthoritySlot::set()`. + +### SDK / Module + +`wallet/src/program_facades/token.rs` exposes `send_set_authority` and `send_new_definition_with_authority` — typed async methods following the same pattern as all existing token facade methods. + +## Success Criteria Checklist + +- [x] **Variable-size tokens via mint authority** — `NewFungibleDefinitionWithAuthority` sets authority at init; `Mint` checks it +- [x] **Minting by the authority** — `Mint` handler validates `definition_account.is_authorized` + `mint_authority.is_some()` +- [x] **Authority rotation and revocation** — `SetAuthority` with `Some(new_key)` rotates; with `None` revokes permanently +- [x] **Two example integrations** — `scripts/examples/fixed_supply_token.sh` and `scripts/examples/variable_supply_token.sh` +- [x] **Self-sufficient agnostic authority library (RFP-001)** — `lez-authority` crate, zero deps on token program or nssa +- [x] **SDK/module** — `wallet/src/program_facades/token.rs` typed facade methods +- [x] **IDL** — token program uses `serde`-based instruction encoding (existing LEZ pattern); SPEL IDL generation available via `lgs spel -- generate-idl` +- [x] **Atomicity** — structural guarantee in `AuthoritySlot::set()`, verified by unit tests +- [x] **Deterministic rejection** — `"Mint authority has been revoked; this token has a fixed supply"` on every revoked-authority mint attempt +- [x] **CI green** — all 7 CI steps pass including `lez-authority` (7 tests) and `token_program` (42 tests) +- [x] **Integration tests** — 2 tests in `integration_tests/tests/token.rs` against live sequencer +- [x] **README** — `docs/LP-0013-README.md` with deployment steps, CLI instructions, architecture, error codes +- [x] **Demo script** — `scripts/demo-full-flow.sh` +- [ ] **CU costs** — TBD after devnet deployment +- [ ] **Recorded video demo** — TBD + +## FURPS Self-Assessment + +### Functionality +- `NewFungibleDefinitionWithAuthority`: creates fungible token with `mint_authority: Some(key)` +- `Mint`: checks `mint_authority.is_some()` before minting; deterministically panics if `None` +- `SetAuthority`: rotates to `Some(new_key)` or revokes to `None`; `is_authorized` check on definition account enforces caller identity +- Existing `NewFungibleDefinition` creates tokens with `mint_authority: None` (fixed supply by default — backward compatible) +- All existing 34 token tests continue to pass unchanged + +### Usability +- Single new field on `TokenDefinition::Fungible` — minimal diff, easy to audit +- `lez-authority` crate is importable by any LEZ program without token program dependency +- Wallet facade methods follow existing async pattern exactly +- `docs/LP-0013-README.md` documents all flows with CLI examples + +### Reliability +- Atomicity: `AuthoritySlot::set()` returns `Err` before mutating — no partial writes possible +- 8 dedicated authority unit tests cover: mint success, mint with wrong authority, mint after revocation, rotation, revocation permanence, double-revoke, unauthorized rotation, state-unchanged-on-error +- All 42 `token_program` tests pass; all 7 `lez-authority` tests pass + +### Performance +- Authority check in `Mint`: single `Option` match — negligible CU overhead +- `SetAuthority`: single account read + write — same CU profile as existing `Burn` +- CU costs will be documented after devnet deployment + +### Supportability +- CI updated with dedicated LP-0013 test steps — green on every push +- `scripts/demo-full-flow.sh` reproducible against local sequencer +- `docs/LP-0013-README.md` documents deployment, CLI usage, architecture, error codes +- Rebased onto upstream HEAD (4079b0c9) — fully current with LEZ codebase + +## Supporting Materials + +- **Architecture docs:** [`docs/LP-0013-README.md`](https://github.com/bristinWild/logos-execution-zone/blob/main/docs/LP-0013-README.md) +- **Authority library:** [`lez-authority/src/lib.rs`](https://github.com/bristinWild/logos-execution-zone/blob/main/lez-authority/src/lib.rs) +- **SetAuthority handler:** [`programs/token/src/set_authority.rs`](https://github.com/bristinWild/logos-execution-zone/blob/main/programs/token/src/set_authority.rs) +- **Mint handler (updated):** [`programs/token/src/mint.rs`](https://github.com/bristinWild/logos-execution-zone/blob/main/programs/token/src/mint.rs) +- **Token core (updated):** [`programs/token/core/src/lib.rs`](https://github.com/bristinWild/logos-execution-zone/blob/main/programs/token/core/src/lib.rs) +- **Demo script:** [`scripts/demo-full-flow.sh`](https://github.com/bristinWild/logos-execution-zone/blob/main/scripts/demo-full-flow.sh) +- **Example scripts:** [`scripts/examples/`](https://github.com/bristinWild/logos-execution-zone/tree/main/scripts/examples) +- **CI:** https://github.com/bristinWild/logos-execution-zone/actions + +## Terms & Conditions + +By submitting this solution, I confirm that I have read and agree to the [Terms & Conditions](../TERMS.md). From 1b1f5920dfead4f4b381478774c7d3af29ac706e Mon Sep 17 00:00:00 2001 From: bristinWild Date: Tue, 19 May 2026 00:31:55 +0530 Subject: [PATCH 02/28] fix: add commit hash and point to demo.sh + IDL --- solutions/LP-0013.md | 1 + 1 file changed, 1 insertion(+) diff --git a/solutions/LP-0013.md b/solutions/LP-0013.md index c15e6a1..6693e71 100644 --- a/solutions/LP-0013.md +++ b/solutions/LP-0013.md @@ -10,6 +10,7 @@ This submission implements a complete mint authority model for the LEZ Token pro - **Repo:** https://github.com/bristinWild/logos-execution-zone - **Branch:** `main` +- **Commit:** `da61c4fb` - **Key files:** - `lez-authority/src/lib.rs` — agnostic `AuthoritySlot` library (RFP-001) - `programs/token/core/src/lib.rs` — `TokenDefinition::Fungible` with `mint_authority` field, `SetAuthority` and `NewFungibleDefinitionWithAuthority` instructions From 08bdf15542f22a88bba7ed7505084b95ca06c76b Mon Sep 17 00:00:00 2001 From: bristinWild Date: Tue, 19 May 2026 14:14:14 +0530 Subject: [PATCH 03/28] feat: add video demo link to LP-0013 solution --- solutions/LP-0013.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/solutions/LP-0013.md b/solutions/LP-0013.md index 6693e71..67e1d4f 100644 --- a/solutions/LP-0013.md +++ b/solutions/LP-0013.md @@ -6,6 +6,9 @@ This submission implements a complete mint authority model for the LEZ Token program. Fungible tokens can now be created with a designated mint authority that can mint additional supply, rotate control to a new key, or permanently revoke minting to fix the supply. A standalone `lez-authority` crate provides the reusable authority primitive as defined in RFP-001. +## Demo Video +Link - https://www.youtube.com/watch?v=fJWbhobNIFM + ## Repository - **Repo:** https://github.com/bristinWild/logos-execution-zone From 5b0c7adc9e201f6aade30836a6c27ad4cee40311 Mon Sep 17 00:00:00 2001 From: mart1n <20109376+mart1n-xyz@users.noreply.github.com> Date: Mon, 25 May 2026 10:14:20 +0200 Subject: [PATCH 04/28] Update prize adoption criteria across open and draft prizes. Remove third-party deployment bars and require reproducible evidence where applicable; adjust LP-0005 and LP-0008 requirements accordingly. Co-authored-by: Cursor --- prizes/LP-0001.md | 3 ++- prizes/LP-0002.md | 3 ++- prizes/LP-0003.md | 3 ++- prizes/LP-0004.md | 3 ++- prizes/LP-0005.md | 3 ++- prizes/LP-0006.md | 2 +- prizes/LP-0008.md | 4 ++-- 7 files changed, 13 insertions(+), 8 deletions(-) diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index d7a228f..1a87c51 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -23,7 +23,7 @@ A competitive prize is the right mechanism here because the problem is well-spec - [ ] The proof can be verified on LEZ without revealing the token ID or the holder's wallet address to the verifier. - [ ] The system is resistant to proof reuse across contexts — a nullifier or domain-separation mechanism prevents the same proof from being replayed in a different gating context. - [ ] A reference integration is delivered: a working demo of at least one token-gated action (e.g., allowlist registration or an on-chain vote) using the proof system. -- [ ] At least 5 independent NFT collections are deployed on LEZ testnet with the proof system integrated, each by a distinct team or community outside the submitting team. +- [ ] At least 5 independent NFT collections are deployed on LEZ testnet with the proof system integrated; the deployments must be reproducible and evidence must be provided. - [ ] Full documentation and a clean public repository are delivered. ### Usability @@ -80,6 +80,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. - 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)). +- Reproducible deployment steps and evidence for at least 5 NFT collection deployments on LEZ testnet with the proof system integrated. - 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. diff --git a/prizes/LP-0002.md b/prizes/LP-0002.md index 4816a0b..3fd7ce7 100644 --- a/prizes/LP-0002.md +++ b/prizes/LP-0002.md @@ -25,7 +25,7 @@ A competitive prize is the right mechanism because the design space is large: ch - [ ] A completed execution is unlinkable to any individual member's shielded account. - [ ] Proof generation runs client-side on a standard laptop. - [ ] A reference integration is delivered: a working demo of a threshold-gated action (e.g., treasury transfer or parameter change) on LEZ testnet using shielded member accounts. -- [ ] At least 5 distinct multisig instances are created on LEZ testnet by parties outside the submitting team, with at least one proposal submitted, approved by threshold, and executed in each. +- [ ] At least 1 multisig instance is created on LEZ testnet, with at least one proposal submitted, approved by threshold, and executed; the deployment must be reproducible and evidence must be provided. - [ ] Full documentation and a clean public repository are delivered. ### Usability @@ -84,6 +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. - Verifier program deployed on LEZ testnet with a verified program ID. - 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)). +- Reproducible deployment steps and evidence for at least 1 multisig instance on LEZ testnet, with at least one proposal submitted, approved by threshold, and executed. - 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. diff --git a/prizes/LP-0003.md b/prizes/LP-0003.md index 481436a..bf1f855 100644 --- a/prizes/LP-0003.md +++ b/prizes/LP-0003.md @@ -27,7 +27,7 @@ Logos' shielded account model offers a richer design surface than standard EVM e - [ ] An on-chain observer cannot link a completed claim to any specific address in the eligibility set. - [ ] The submission documents its full privacy model: what on-chain observers learn, what the distributor learns, at which points in the claim flow identity information is revealed or withheld, and where trade-offs or residual leakage remain. Claims of privacy must be precise — "unlinkable" must be defined relative to a stated threat model. - [ ] A reference integration is delivered: a working demo of a private airdrop or allowlist gate on LEZ testnet. -- [ ] At least 3 distinct distributions are deployed on LEZ testnet by parties outside the submitting team, with a combined total of at least 30 unique claims completed across them. +- [ ] At least 2 distinct distributions are deployed on LEZ testnet, with a combined total of at least 20 unique claims completed across them; the distributions must be reproducible and evidence must be provided. - [ ] Full documentation and a clean public repository are delivered. ### Usability @@ -85,6 +85,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 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)). +- Reproducible deployment steps and evidence for at least 2 distinct distributions on LEZ testnet, with a combined total of at least 20 unique claims completed across them. - 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. diff --git a/prizes/LP-0004.md b/prizes/LP-0004.md index ba4bf30..8af24f5 100644 --- a/prizes/LP-0004.md +++ b/prizes/LP-0004.md @@ -25,7 +25,7 @@ A competitive prize is the right mechanism because the design space is large: au - [ ] Losing bidders receive full refunds to their shielded accounts without the refund amount being linkable to their original bid. - [ ] At no point during or after the auction can a passive observer determine any losing bidder's maximum offer. - [ ] A reference integration is delivered: a working demo of a complete auction lifecycle (open → bid → close → winner determined → refunds issued) on LEZ testnet. -- [ ] At least 5 complete auction cycles are run on LEZ testnet, each with a minimum of 3 distinct bidders, at least 3 of those auctions organised by parties outside the submitting team. +- [ ] At least 5 complete auction cycles are run on LEZ testnet, each with a minimum of 3 distinct bidders; the cycles must be reproducible and evidence must be provided. - [ ] Full documentation and a clean public repository are delivered. ### Usability @@ -85,6 +85,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 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)). +- Reproducible steps and evidence for at least 5 complete auction cycles on LEZ testnet, each with a minimum of 3 distinct bidders. - 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. diff --git a/prizes/LP-0005.md b/prizes/LP-0005.md index a010e54..b294196 100644 --- a/prizes/LP-0005.md +++ b/prizes/LP-0005.md @@ -31,7 +31,7 @@ A competitive prize is the right mechanism because the proving strategy, nullifi - [ ] The circuit correctly targets the existing LEZ private account commitment format: `SHA256(npk || program_owner || balance || nonce || SHA256(data))`. - [ ] **On-chain path**: A LEZ verifier program accepts and verifies the proof, gating at least one on-chain action. - [ ] **Off-chain path**: The proof can be transmitted over Logos Messaging and verified locally by a recipient, demonstrated by a token-gated access flow (e.g., admission to a chat group). -- [ ] At least 3 distinct applications integrate the attestation primitive on LEZ testnet (e.g., a governance gate, a token-gated Logos Messaging group, and a third use case), with at least one built by a party outside the submitting team. +- [ ] A standalone consumer integration demo is included in the submission repository. Any demonstrated, testable path that exercises the attestation primitive is acceptable (e.g., on-chain gating, off-chain verification via Logos Messaging, or another integration the submitter can run and verify). - [ ] Full documentation and a clean public repository are delivered. ### Usability @@ -96,6 +96,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 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)). +- Standalone consumer integration demo with instructions to run and test the integration. - 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. diff --git a/prizes/LP-0006.md b/prizes/LP-0006.md index 6d740f7..a45022f 100644 --- a/prizes/LP-0006.md +++ b/prizes/LP-0006.md @@ -68,7 +68,7 @@ The following assumptions underpin the security and reliability of the atomic sw - [ ] **Maker/taker model**: The maker operates as a liquidity provider. The maker software allows configuration of supported trading pairs and prices. The maker advertises available pairs and prices over **Logos Delivery** (the Logos storage/data availability layer). Maker-taker negotiation and swap coordination messages are exchanged over **Logos Chat** (the Logos messaging layer). - [ ] **Maker pricing**: The maker software supports two pricing modes: (1) **local configuration** (static prices set via config file or CLI, useful for testing) and (2) **external price feed** (fetching prices from an external service, e.g., a REST API). The specific external integration is left to the developer, but the architecture must support pluggable price sources. - [ ] The **maker** is deployable as a **headless service** with all necessary functionality (pair/price configuration, external price feed, liquidity management, swap execution, monitoring) — no GUI required for operation. -- [ ] At least 5 complete swaps are executed per chain on testnets, involving at least 3 distinct counterparty pairs outside the submitting team. +- [ ] At least 5 complete swaps are executed per chain on testnets, involving at least 3 distinct counterparty pairs. ### Usability diff --git a/prizes/LP-0008.md b/prizes/LP-0008.md index 4d1d880..32c778c 100644 --- a/prizes/LP-0008.md +++ b/prizes/LP-0008.md @@ -98,7 +98,7 @@ Submissions are not required to implement all of these, but the default skills a - [ ] Agent-to-agent coordination is A2A-compatible: Agent Cards follow the A2A schema, task interactions follow the A2A task lifecycle, and the implementation is documented as an A2A transport binding over Logos Messaging. - [ ] Two or more agents can discover each other via Agent Cards, execute a task following the A2A lifecycle, and transfer LEZ payment autonomously, without owner intervention. - [ ] At least 3 of the illustrative use cases above are demonstrated end-to-end on LEZ testnet. -- [ ] At least 5 agents are deployed on LEZ testnet by parties outside the submitting team, each demonstrating at least one skill autonomously. +- [ ] Three separate agents are deployed on LEZ testnet — one per default skill category (Storage, Messaging, and Blockchain) — each with a demonstrated, reproducible deployment and evidence provided. - [ ] Full documentation — including the skill interface spec, deployment guide, and owner interaction guide — and a clean public repository are delivered. ### Usability @@ -156,7 +156,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 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). +- Reproducible deployment steps and evidence for three separate agent deployments on LEZ testnet — one agent per default skill category (Storage, Messaging, and Blockchain). - 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. ## Evaluation Process From 0d646b77686639fe418aa857aa1c57acdf4402c8 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 28 May 2026 11:20:22 +1000 Subject: [PATCH 05/28] Add standardized Dependencies section to L-Prize template and existing LPs Introduces a `## Dependencies` section in the LP template (LP-0000.md) and adds the same section to every existing prize in `prizes/`. The section lists other L-Prizes, RFPs, R&D items, or sample apps that must complete or exist before each Lambda Prize can be announced or claimed, using canonical IDs (LP-XXXX, RFP-XXX, ...). This is non-breaking: only structure is added or normalized. Existing dependency information previously expressed in status banners or prose (LP-0001, LP-0004, LP-0006, LP-0013) is now also captured in the new section. LPs whose related-LP cross-references are non-blocking (LP-0008, LP-0016, LP-0017) declare `(none)` and clarify the related links in Resources. The goal is to give downstream tooling (e.g. flywheels.logos.co) a single machine-readable place to discover LP dependencies. --- prizes/LP-0000.md | 11 +++++++++++ prizes/LP-0001.md | 7 +++++++ prizes/LP-0002.md | 7 +++++++ prizes/LP-0003.md | 7 +++++++ prizes/LP-0004.md | 7 +++++++ prizes/LP-0005.md | 7 +++++++ prizes/LP-0006.md | 11 +++++++++++ prizes/LP-0008.md | 9 +++++++++ prizes/LP-0009.md | 7 +++++++ prizes/LP-0010.md | 7 +++++++ prizes/LP-0011.md | 9 +++++++++ prizes/LP-0012.md | 7 +++++++ prizes/LP-0013.md | 7 +++++++ prizes/LP-0014.md | 7 +++++++ prizes/LP-0015.md | 7 +++++++ prizes/LP-0016.md | 9 +++++++++ prizes/LP-0017.md | 9 +++++++++ 17 files changed, 135 insertions(+) diff --git a/prizes/LP-0000.md b/prizes/LP-0000.md index 7293d7e..391d8d1 100644 --- a/prizes/LP-0000.md +++ b/prizes/LP-0000.md @@ -92,6 +92,17 @@ 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. +## Dependencies + +> Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist +> before this Lambda Prize can be announced or claimed. Use the canonical IDs. +> +> - LP-XXXX — short reason +> - RFP-XXX — short reason +> - (none, if standalone) + +- (none) + ## Resources > Links to relevant specs, documentation, APIs, or prior work that participants should know about. diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index 1a87c51..2f044fd 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -96,6 +96,13 @@ 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. +## Dependencies + +Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist +before this Lambda Prize can be announced or claimed. + +- LEZ NFT Program — the underlying NFT program on LEZ must be ready before this prize can open (see status banner above). + ## Resources - [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone) diff --git a/prizes/LP-0002.md b/prizes/LP-0002.md index 3fd7ce7..e764ac5 100644 --- a/prizes/LP-0002.md +++ b/prizes/LP-0002.md @@ -99,6 +99,13 @@ 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. +## Dependencies + +Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist +before this Lambda Prize can be announced or claimed. + +- (none) + ## Resources - [lez-multisig](https://github.com/jimmy-claw/lez-multisig) — public multisig PoC; architecture notes describe why private accounts are incompatible diff --git a/prizes/LP-0003.md b/prizes/LP-0003.md index bf1f855..c2d6a9a 100644 --- a/prizes/LP-0003.md +++ b/prizes/LP-0003.md @@ -102,6 +102,13 @@ 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. +## Dependencies + +Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist +before this Lambda Prize can be announced or claimed. + +- (none) + ## Resources - [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/) diff --git a/prizes/LP-0004.md b/prizes/LP-0004.md index 8af24f5..5b008c0 100644 --- a/prizes/LP-0004.md +++ b/prizes/LP-0004.md @@ -100,6 +100,13 @@ 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. +## Dependencies + +Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist +before this Lambda Prize can be announced or claimed. + +- LEZ timelock feature — on-chain timelock support on LEZ is required for the bid-reveal window and refund mechanics (see status banner above). + ## Resources - [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/) diff --git a/prizes/LP-0005.md b/prizes/LP-0005.md index b294196..e483da5 100644 --- a/prizes/LP-0005.md +++ b/prizes/LP-0005.md @@ -111,6 +111,13 @@ 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. +## Dependencies + +Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist +before this Lambda Prize can be announced or claimed. + +- (none) + ## Resources - [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/) diff --git a/prizes/LP-0006.md b/prizes/LP-0006.md index a45022f..a1a964a 100644 --- a/prizes/LP-0006.md +++ b/prizes/LP-0006.md @@ -173,6 +173,17 @@ 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. +## Dependencies + +Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist +before this Lambda Prize can be announced or claimed. + +- LEZ timelock feature — on-chain timelock support on LEZ is required for swap refund mechanics (see status banner above). +- Logos Delivery module — required for makers to advertise prices and trading pairs (see status banner above). +- Logos Chat module — required for maker-taker negotiation and swap coordination (see status banner above). + +Note: see `## Infrastructure & Dependencies` above for per-chain runtime infrastructure (Bitcoin/Monero/Ethereum nodes) participants must run. + ## Resources ### General diff --git a/prizes/LP-0008.md b/prizes/LP-0008.md index 32c778c..cfaec17 100644 --- a/prizes/LP-0008.md +++ b/prizes/LP-0008.md @@ -170,6 +170,15 @@ 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. +## Dependencies + +Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist +before this Lambda Prize can be announced or claimed. + +- (none) + +Note: LP-0002 and LP-0005 are listed under Resources as related references, not hard dependencies for this prize. + ## Resources - [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/) diff --git a/prizes/LP-0009.md b/prizes/LP-0009.md index f31400d..863a307 100644 --- a/prizes/LP-0009.md +++ b/prizes/LP-0009.md @@ -50,6 +50,13 @@ Open to any individual or team. Submissions must be original work. Teams must ho Submissions are evaluated first-come-first-served against the success criteria. The first submission that satisfies all criteria wins. +## Dependencies + +Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist +before this Lambda Prize can be announced or claimed. + +- (none) + ## Resources - [NIP-46: Nostr Connect](https://github.com/nostr-protocol/nips/blob/master/46.md) diff --git a/prizes/LP-0010.md b/prizes/LP-0010.md index 4e361b1..59cc16c 100644 --- a/prizes/LP-0010.md +++ b/prizes/LP-0010.md @@ -68,6 +68,13 @@ Submissions are evaluated first-come-first-served against the success criteria. Evaluators will independently clone the repository and run the application from a clean environment. Evaluators may also ask technical follow-up questions to verify authorship and understanding of the implementation. +## Dependencies + +Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist +before this Lambda Prize can be announced or claimed. + +- (none) + ## Resources - [ERC-4527: QR Code Based Air-Gapped Signer Interface](https://eips.ethereum.org/EIPS/eip-4527) — the standard for QR-based communication between airgapped signers and watch-only wallets, built on UR (Uniform Resources). Keystone pioneered this standard and provides mature SDKs implementing it. diff --git a/prizes/LP-0011.md b/prizes/LP-0011.md index 86e0e18..92b618c 100644 --- a/prizes/LP-0011.md +++ b/prizes/LP-0011.md @@ -128,6 +128,15 @@ 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. +## Dependencies + +Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist +before this Lambda Prize can be announced or claimed. + +- (none) + +Note: the status banner flags overlap with the LEZ framework — see the banner for the current review status — but no concrete L-Prize, RFP, or R&D item is identified as a blocker. + ## Resources - [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone) diff --git a/prizes/LP-0012.md b/prizes/LP-0012.md index 92cb6e6..2d14f6f 100644 --- a/prizes/LP-0012.md +++ b/prizes/LP-0012.md @@ -130,6 +130,13 @@ 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. +## Dependencies + +Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist +before this Lambda Prize can be announced or claimed. + +- (none) + ## Resources - [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone) diff --git a/prizes/LP-0013.md b/prizes/LP-0013.md index f6a7198..6085288 100644 --- a/prizes/LP-0013.md +++ b/prizes/LP-0013.md @@ -87,6 +87,13 @@ 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. +## Dependencies + +Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist +before this Lambda Prize can be announced or claimed. + +- [RFP-001](https://github.com/logos-co/rfp/blob/master/RFPs/RFP-001-admin-authority-lib.md) — admin authority library (referenced in Success Criteria; the deliverable must reuse the approval pattern defined here). + ## Resources - [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone) diff --git a/prizes/LP-0014.md b/prizes/LP-0014.md index 08557e6..4526589 100644 --- a/prizes/LP-0014.md +++ b/prizes/LP-0014.md @@ -67,6 +67,13 @@ Open to any individual or team. Submissions must be original work. Teams must ho By default, submissions are evaluated first-come-first-served against the success criteria. The first submission that meets **all** criteria wins. +## Dependencies + +Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist +before this Lambda Prize can be announced or claimed. + +- (none) + ## Resources - [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone) diff --git a/prizes/LP-0015.md b/prizes/LP-0015.md index 50f31f5..e92ff2e 100644 --- a/prizes/LP-0015.md +++ b/prizes/LP-0015.md @@ -109,6 +109,13 @@ Open to any individual or team. Submissions must be original work. Teams must ho The success criteria and submission requirements above are **retained as the original specification** of the intended work for historical reference. +## Dependencies + +Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist +before this Lambda Prize can be announced or claimed. + +- (none) + ## Resources - [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone) diff --git a/prizes/LP-0016.md b/prizes/LP-0016.md index eb860fb..abf1511 100644 --- a/prizes/LP-0016.md +++ b/prizes/LP-0016.md @@ -140,6 +140,15 @@ 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. +## Dependencies + +Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist +before this Lambda Prize can be announced or claimed. + +- (none) + +Note: LP-0001 and LP-0003 are listed under Resources as related references (ZK membership proof and nullifier scheme patterns), not hard dependencies for this prize. + ## Resources - [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone) diff --git a/prizes/LP-0017.md b/prizes/LP-0017.md index ca7eee5..f69e2d7 100644 --- a/prizes/LP-0017.md +++ b/prizes/LP-0017.md @@ -120,6 +120,15 @@ 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. +## Dependencies + +Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist +before this Lambda Prize can be announced or claimed. + +- (none) + +Note: LP-0008 and LP-0012 are listed under Resources as related references (module architecture and on-chain event emission patterns), not hard dependencies for this prize. + ## Resources - [logos-co/ecosystem#88](https://github.com/logos-co/ecosystem/issues/88) — Whistleblower sample app scope issue From ae23a4ae2d8b0262c30ea7d9b2d07a07fdea1884 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 28 May 2026 11:26:16 +1000 Subject: [PATCH 06/28] Drop empty Dependencies sections; keep only on LPs with real hard deps Per maintainer feedback on PR #69, LPs without hard dependencies should not carry an empty `## Dependencies` section. Removes the section from LPs that previously declared `(none)` (LP-0002, LP-0003, LP-0005, LP-0008, LP-0009, LP-0010, LP-0011, LP-0012, LP-0014, LP-0015, LP-0016, LP-0017). LP-0001, LP-0004, LP-0006, LP-0013 retain the section because they have real hard dependencies. The template (LP-0000.md) still describes the section, but the body now instructs authors to add it ONLY when there are real deps and to omit the entire section otherwise. Co-Authored-By: Claude Opus 4.7 (1M context) --- prizes/LP-0000.md | 8 +++----- prizes/LP-0002.md | 7 ------- prizes/LP-0003.md | 7 ------- prizes/LP-0005.md | 7 ------- prizes/LP-0008.md | 9 --------- prizes/LP-0009.md | 7 ------- prizes/LP-0010.md | 7 ------- prizes/LP-0011.md | 9 --------- prizes/LP-0012.md | 7 ------- prizes/LP-0014.md | 7 ------- prizes/LP-0015.md | 7 ------- prizes/LP-0016.md | 9 --------- prizes/LP-0017.md | 9 --------- 13 files changed, 3 insertions(+), 97 deletions(-) diff --git a/prizes/LP-0000.md b/prizes/LP-0000.md index 391d8d1..e486405 100644 --- a/prizes/LP-0000.md +++ b/prizes/LP-0000.md @@ -94,14 +94,12 @@ The following policies apply to all prizes (see [evaluation policies](../README. ## Dependencies -> Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist -> before this Lambda Prize can be announced or claimed. Use the canonical IDs. +> Add this section ONLY if this prize has hard dependencies on other +> L-Prizes, RFPs, R&D items, or sample apps. Omit the entire section +> if there are no hard deps. Format: > > - LP-XXXX — short reason > - RFP-XXX — short reason -> - (none, if standalone) - -- (none) ## Resources diff --git a/prizes/LP-0002.md b/prizes/LP-0002.md index e764ac5..3fd7ce7 100644 --- a/prizes/LP-0002.md +++ b/prizes/LP-0002.md @@ -99,13 +99,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. -## Dependencies - -Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist -before this Lambda Prize can be announced or claimed. - -- (none) - ## Resources - [lez-multisig](https://github.com/jimmy-claw/lez-multisig) — public multisig PoC; architecture notes describe why private accounts are incompatible diff --git a/prizes/LP-0003.md b/prizes/LP-0003.md index c2d6a9a..bf1f855 100644 --- a/prizes/LP-0003.md +++ b/prizes/LP-0003.md @@ -102,13 +102,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. -## Dependencies - -Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist -before this Lambda Prize can be announced or claimed. - -- (none) - ## Resources - [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/) diff --git a/prizes/LP-0005.md b/prizes/LP-0005.md index e483da5..b294196 100644 --- a/prizes/LP-0005.md +++ b/prizes/LP-0005.md @@ -111,13 +111,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. -## Dependencies - -Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist -before this Lambda Prize can be announced or claimed. - -- (none) - ## Resources - [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/) diff --git a/prizes/LP-0008.md b/prizes/LP-0008.md index cfaec17..32c778c 100644 --- a/prizes/LP-0008.md +++ b/prizes/LP-0008.md @@ -170,15 +170,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. -## Dependencies - -Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist -before this Lambda Prize can be announced or claimed. - -- (none) - -Note: LP-0002 and LP-0005 are listed under Resources as related references, not hard dependencies for this prize. - ## Resources - [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/) diff --git a/prizes/LP-0009.md b/prizes/LP-0009.md index 863a307..f31400d 100644 --- a/prizes/LP-0009.md +++ b/prizes/LP-0009.md @@ -50,13 +50,6 @@ Open to any individual or team. Submissions must be original work. Teams must ho Submissions are evaluated first-come-first-served against the success criteria. The first submission that satisfies all criteria wins. -## Dependencies - -Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist -before this Lambda Prize can be announced or claimed. - -- (none) - ## Resources - [NIP-46: Nostr Connect](https://github.com/nostr-protocol/nips/blob/master/46.md) diff --git a/prizes/LP-0010.md b/prizes/LP-0010.md index 59cc16c..4e361b1 100644 --- a/prizes/LP-0010.md +++ b/prizes/LP-0010.md @@ -68,13 +68,6 @@ Submissions are evaluated first-come-first-served against the success criteria. Evaluators will independently clone the repository and run the application from a clean environment. Evaluators may also ask technical follow-up questions to verify authorship and understanding of the implementation. -## Dependencies - -Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist -before this Lambda Prize can be announced or claimed. - -- (none) - ## Resources - [ERC-4527: QR Code Based Air-Gapped Signer Interface](https://eips.ethereum.org/EIPS/eip-4527) — the standard for QR-based communication between airgapped signers and watch-only wallets, built on UR (Uniform Resources). Keystone pioneered this standard and provides mature SDKs implementing it. diff --git a/prizes/LP-0011.md b/prizes/LP-0011.md index 92b618c..86e0e18 100644 --- a/prizes/LP-0011.md +++ b/prizes/LP-0011.md @@ -128,15 +128,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. -## Dependencies - -Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist -before this Lambda Prize can be announced or claimed. - -- (none) - -Note: the status banner flags overlap with the LEZ framework — see the banner for the current review status — but no concrete L-Prize, RFP, or R&D item is identified as a blocker. - ## Resources - [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone) diff --git a/prizes/LP-0012.md b/prizes/LP-0012.md index 2d14f6f..92cb6e6 100644 --- a/prizes/LP-0012.md +++ b/prizes/LP-0012.md @@ -130,13 +130,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. -## Dependencies - -Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist -before this Lambda Prize can be announced or claimed. - -- (none) - ## Resources - [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone) diff --git a/prizes/LP-0014.md b/prizes/LP-0014.md index 4526589..08557e6 100644 --- a/prizes/LP-0014.md +++ b/prizes/LP-0014.md @@ -67,13 +67,6 @@ Open to any individual or team. Submissions must be original work. Teams must ho By default, submissions are evaluated first-come-first-served against the success criteria. The first submission that meets **all** criteria wins. -## Dependencies - -Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist -before this Lambda Prize can be announced or claimed. - -- (none) - ## Resources - [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone) diff --git a/prizes/LP-0015.md b/prizes/LP-0015.md index e92ff2e..50f31f5 100644 --- a/prizes/LP-0015.md +++ b/prizes/LP-0015.md @@ -109,13 +109,6 @@ Open to any individual or team. Submissions must be original work. Teams must ho The success criteria and submission requirements above are **retained as the original specification** of the intended work for historical reference. -## Dependencies - -Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist -before this Lambda Prize can be announced or claimed. - -- (none) - ## Resources - [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone) diff --git a/prizes/LP-0016.md b/prizes/LP-0016.md index abf1511..eb860fb 100644 --- a/prizes/LP-0016.md +++ b/prizes/LP-0016.md @@ -140,15 +140,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. -## Dependencies - -Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist -before this Lambda Prize can be announced or claimed. - -- (none) - -Note: LP-0001 and LP-0003 are listed under Resources as related references (ZK membership proof and nullifier scheme patterns), not hard dependencies for this prize. - ## Resources - [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone) diff --git a/prizes/LP-0017.md b/prizes/LP-0017.md index f69e2d7..ca7eee5 100644 --- a/prizes/LP-0017.md +++ b/prizes/LP-0017.md @@ -120,15 +120,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. -## Dependencies - -Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist -before this Lambda Prize can be announced or claimed. - -- (none) - -Note: LP-0008 and LP-0012 are listed under Resources as related references (module architecture and on-chain event emission patterns), not hard dependencies for this prize. - ## Resources - [logos-co/ecosystem#88](https://github.com/logos-co/ecosystem/issues/88) — Whistleblower sample app scope issue From 5746b7bc5776cb4cf3b90700478a88b23f5f309b Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 28 May 2026 11:30:41 +1000 Subject: [PATCH 07/28] Convert Dependencies to YAML frontmatter to match RFP convention MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Aligns the L-Prize repo with logos-co/rfp PR #64, which standardised dependency declarations as a structured `dependencies:` field in YAML frontmatter (a list of `{ id, reason }` objects). - LP-0013: adds frontmatter with the RFP-001 dependency; removes the markdown `## Dependencies` section. - LP-0001, LP-0004, LP-0006: drop the markdown `## Dependencies` section. Their hard deps are platform features (LEZ NFT Program, LEZ timelock, Logos Delivery, Logos Chat) with no canonical RFP-/LP- ID, so no frontmatter entry is added — matching the RFP-003 precedent in logos-co/rfp PR #64. The dependency information is already captured in each file's status banner. - LP-0000.md (template): replaces the markdown `## Dependencies` section with a frontmatter example in an HTML comment, noting that the field is included only when there are real hard deps with canonical IDs and is otherwise omitted entirely (no `[]`), per the L-Prize convention. Co-Authored-By: Claude Opus 4.7 (1M context) --- prizes/LP-0000.md | 26 +++++++++++++++++--------- prizes/LP-0001.md | 7 ------- prizes/LP-0004.md | 7 ------- prizes/LP-0006.md | 11 ----------- prizes/LP-0013.md | 14 +++++++------- 5 files changed, 24 insertions(+), 41 deletions(-) diff --git a/prizes/LP-0000.md b/prizes/LP-0000.md index e486405..cf79c76 100644 --- a/prizes/LP-0000.md +++ b/prizes/LP-0000.md @@ -1,5 +1,22 @@ + + # LP-XXXX: [status] **`Status`**: @@ -92,15 +109,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. -## Dependencies - -> Add this section ONLY if this prize has hard dependencies on other -> L-Prizes, RFPs, R&D items, or sample apps. Omit the entire section -> if there are no hard deps. Format: -> -> - LP-XXXX — short reason -> - RFP-XXX — short reason - ## Resources > Links to relevant specs, documentation, APIs, or prior work that participants should know about. diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index 2f044fd..1a87c51 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -96,13 +96,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. -## Dependencies - -Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist -before this Lambda Prize can be announced or claimed. - -- LEZ NFT Program — the underlying NFT program on LEZ must be ready before this prize can open (see status banner above). - ## Resources - [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone) diff --git a/prizes/LP-0004.md b/prizes/LP-0004.md index 5b008c0..8af24f5 100644 --- a/prizes/LP-0004.md +++ b/prizes/LP-0004.md @@ -100,13 +100,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. -## Dependencies - -Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist -before this Lambda Prize can be announced or claimed. - -- LEZ timelock feature — on-chain timelock support on LEZ is required for the bid-reveal window and refund mechanics (see status banner above). - ## Resources - [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/) diff --git a/prizes/LP-0006.md b/prizes/LP-0006.md index a1a964a..a45022f 100644 --- a/prizes/LP-0006.md +++ b/prizes/LP-0006.md @@ -173,17 +173,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. -## Dependencies - -Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist -before this Lambda Prize can be announced or claimed. - -- LEZ timelock feature — on-chain timelock support on LEZ is required for swap refund mechanics (see status banner above). -- Logos Delivery module — required for makers to advertise prices and trading pairs (see status banner above). -- Logos Chat module — required for maker-taker negotiation and swap coordination (see status banner above). - -Note: see `## Infrastructure & Dependencies` above for per-chain runtime infrastructure (Bitcoin/Monero/Ethereum nodes) participants must run. - ## Resources ### General diff --git a/prizes/LP-0013.md b/prizes/LP-0013.md index 6085288..7321485 100644 --- a/prizes/LP-0013.md +++ b/prizes/LP-0013.md @@ -1,3 +1,10 @@ +--- +dependencies: + - id: RFP-001 + reason: Provides the standardised admin authority library that the + mint authority approval pattern must reuse, per Success Criteria. +--- + # LP-0013: Token program improvements: authorities [OPEN] **`Logos Circle: N/A`** @@ -87,13 +94,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. -## Dependencies - -Other L-Prizes, RFPs, R&D, or sample apps that must complete or exist -before this Lambda Prize can be announced or claimed. - -- [RFP-001](https://github.com/logos-co/rfp/blob/master/RFPs/RFP-001-admin-authority-lib.md) — admin authority library (referenced in Success Criteria; the deliverable must reuse the approval pattern defined here). - ## Resources - [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone) From c45ea08349d9531c5757b9b17ed10281970f17c2 Mon Sep 17 00:00:00 2001 From: fryorcraken <commits@fryorcraken.xyz> Date: Thu, 28 May 2026 11:33:11 +1000 Subject: [PATCH 08/28] Always declare `dependencies:` in LP frontmatter (use `[]` if none) Previous convention omitted the `dependencies:` field entirely when an LP had no hard deps. This change makes the field mandatory on every LP: use `dependencies: []` for standalone LPs. A missing field now signals the author hasn't considered deps yet (lintable); `[]` signals considered and none. This aligns with the convention in logos-co/rfp PR #64. - LP-0000.md (template): replace the conditional frontmatter example with `dependencies: []` and a comment explaining the new convention. - LP-0001..LP-0017 (excluding LP-0007 which does not exist and LP-0013 which already declares an RFP-001 hard dep): add `dependencies: []` YAML frontmatter at the top of each file. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --- prizes/LP-0000.md | 28 ++++++++++++++-------------- prizes/LP-0001.md | 4 ++++ prizes/LP-0002.md | 4 ++++ prizes/LP-0003.md | 4 ++++ prizes/LP-0004.md | 4 ++++ prizes/LP-0005.md | 4 ++++ prizes/LP-0006.md | 4 ++++ prizes/LP-0008.md | 4 ++++ prizes/LP-0009.md | 4 ++++ prizes/LP-0010.md | 4 ++++ prizes/LP-0011.md | 4 ++++ prizes/LP-0012.md | 4 ++++ prizes/LP-0014.md | 4 ++++ prizes/LP-0015.md | 4 ++++ prizes/LP-0016.md | 4 ++++ prizes/LP-0017.md | 4 ++++ 16 files changed, 74 insertions(+), 14 deletions(-) diff --git a/prizes/LP-0000.md b/prizes/LP-0000.md index cf79c76..c9ce4c9 100644 --- a/prizes/LP-0000.md +++ b/prizes/LP-0000.md @@ -1,21 +1,21 @@ <!-- Don't forget to add/update this prize in the table in README.md --> -<!-- -Optional YAML frontmatter for prizes that have hard dependencies on -other L-Prizes, RFPs, R&D items, or sample apps. Include the -`dependencies:` field ONLY when there are real hard deps with -canonical IDs (LP-XXXX, RFP-XXX). Omit the entire frontmatter block -if this prize has no hard deps — do not use `dependencies: []`. This -field is parsed by downstream tooling (e.g. flywheels.logos.co). - --- -dependencies: - - id: LP-XXXX - reason: short reason this prize depends on it - - id: RFP-XXX - reason: short reason this prize depends on it +# Always declare `dependencies:` — use `[]` if there are none. +# A missing field signals the author has not considered deps yet +# (lintable); `[]` signals considered and none. Replace `[]` with +# a list of `{ id, reason }` objects for prizes with hard deps on +# other L-Prizes, RFPs, R&D items, or sample apps, using canonical +# IDs (LP-XXXX, RFP-XXX). This field is parsed by downstream tooling +# (e.g. flywheels.logos.co). Example: +# +# dependencies: +# - id: LP-XXXX +# reason: short reason this prize depends on it +# - id: RFP-XXX +# reason: short reason this prize depends on it +dependencies: [] --- ---> # LP-XXXX: <Title> [status] diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index 1a87c51..8d2c5a4 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -1,3 +1,7 @@ +--- +dependencies: [] +--- + # LP-0001: Private NFT Ownership Proof [DRAFT] **`Status: draft - pending NFT Program readiness`** diff --git a/prizes/LP-0002.md b/prizes/LP-0002.md index 3fd7ce7..42311f4 100644 --- a/prizes/LP-0002.md +++ b/prizes/LP-0002.md @@ -1,3 +1,7 @@ +--- +dependencies: [] +--- + # LP-0002: Private M-of-N Multisig [OPEN] **`Logos Circle: N/A`** diff --git a/prizes/LP-0003.md b/prizes/LP-0003.md index bf1f855..62f0be3 100644 --- a/prizes/LP-0003.md +++ b/prizes/LP-0003.md @@ -1,3 +1,7 @@ +--- +dependencies: [] +--- + # LP-0003: Private Allowlist / Airdrop Distributor [OPEN] **`Status: Open`** diff --git a/prizes/LP-0004.md b/prizes/LP-0004.md index 8af24f5..37f955e 100644 --- a/prizes/LP-0004.md +++ b/prizes/LP-0004.md @@ -1,3 +1,7 @@ +--- +dependencies: [] +--- + # LP-0004: Sealed-Bid Auction Using Shielded Balances [DRAFT] **`Status: Draft - pending LEZ timelock feature`** diff --git a/prizes/LP-0005.md b/prizes/LP-0005.md index b294196..67cf8d0 100644 --- a/prizes/LP-0005.md +++ b/prizes/LP-0005.md @@ -1,3 +1,7 @@ +--- +dependencies: [] +--- + # LP-0005: Private Token Balance Attestation [OPEN] **`Logos Circle: N/A`** diff --git a/prizes/LP-0006.md b/prizes/LP-0006.md index a45022f..a697fce 100644 --- a/prizes/LP-0006.md +++ b/prizes/LP-0006.md @@ -1,3 +1,7 @@ +--- +dependencies: [] +--- + <!-- Don't forget to add/update this prize in the table in README.md --> # LP-0006: Atomic Swap with LEZ [DRAFT] diff --git a/prizes/LP-0008.md b/prizes/LP-0008.md index 32c778c..cc9456e 100644 --- a/prizes/LP-0008.md +++ b/prizes/LP-0008.md @@ -1,3 +1,7 @@ +--- +dependencies: [] +--- + # LP-0008: Autonomous AI Module with Wallet, Storage, and Messaging [OPEN] **`Logos Circle: N/A`** diff --git a/prizes/LP-0009.md b/prizes/LP-0009.md index f31400d..6c593c2 100644 --- a/prizes/LP-0009.md +++ b/prizes/LP-0009.md @@ -1,3 +1,7 @@ +--- +dependencies: [] +--- + # LP-0009: Keycard NIP-46 Nostr Signer Proxy [CLOSED] **`Logos Circle: N/A`** diff --git a/prizes/LP-0010.md b/prizes/LP-0010.md index 4e361b1..708e8ca 100644 --- a/prizes/LP-0010.md +++ b/prizes/LP-0010.md @@ -1,3 +1,7 @@ +--- +dependencies: [] +--- + # LP-0010: Shell dApp Integration Proof of Concept [CLOSED] **`Logos Circle: N/A`** diff --git a/prizes/LP-0011.md b/prizes/LP-0011.md index 86e0e18..95f8285 100644 --- a/prizes/LP-0011.md +++ b/prizes/LP-0011.md @@ -1,3 +1,7 @@ +--- +dependencies: [] +--- + # LP-0011: Program development tooling: minimal Rust SDK for programs + CPI [DRAFT] **`Status: Draft - To review with overlap with LEZ framework`** diff --git a/prizes/LP-0012.md b/prizes/LP-0012.md index 92cb6e6..07c5da1 100644 --- a/prizes/LP-0012.md +++ b/prizes/LP-0012.md @@ -1,3 +1,7 @@ +--- +dependencies: [] +--- + # LP-0012: Event/Log mechanism: Structured events for LEZ program execution [CLOSED] **`Logos Circle: N/A`** diff --git a/prizes/LP-0014.md b/prizes/LP-0014.md index 08557e6..2f27350 100644 --- a/prizes/LP-0014.md +++ b/prizes/LP-0014.md @@ -1,3 +1,7 @@ +--- +dependencies: [] +--- + # LP-0014: Token program improvements: Associated Token Accounts (ATAs) + wallet tooling [CLOSED] **`Logos Circle: N/A`** diff --git a/prizes/LP-0015.md b/prizes/LP-0015.md index 50f31f5..a747e67 100644 --- a/prizes/LP-0015.md +++ b/prizes/LP-0015.md @@ -1,3 +1,7 @@ +--- +dependencies: [] +--- + # LP-0015: General cross-program calls via tail calls: external vs internal entrypoints + tooling [CLOSED] **`Status: Closed`** diff --git a/prizes/LP-0016.md b/prizes/LP-0016.md index eb860fb..78249a5 100644 --- a/prizes/LP-0016.md +++ b/prizes/LP-0016.md @@ -1,3 +1,7 @@ +--- +dependencies: [] +--- + # LP-0016: Anonymous Forum with Threshold Moderation and Membership Revocation [OPEN] **`Status: Open`** diff --git a/prizes/LP-0017.md b/prizes/LP-0017.md index ca7eee5..49341d9 100644 --- a/prizes/LP-0017.md +++ b/prizes/LP-0017.md @@ -1,3 +1,7 @@ +--- +dependencies: [] +--- + # LP-0017: Whistleblower — censorship-resistant document upload and indexing Basecamp app [OPEN] **`Status: Open`** From 73a95bb4a646df9eea0170c713f1b23c60f5cc99 Mon Sep 17 00:00:00 2001 From: James Zaki <james.zaki@proton.me> Date: Fri, 29 May 2026 11:47:40 +0100 Subject: [PATCH 09/28] =?UTF-8?q?Fix=20=CE=BB=20prize=20text=20(#72)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Fix titles * Fix text --- TERMS.md | 14 +++++++------- prizes/LP-0000.md | 2 +- prizes/LP-0001.md | 2 +- prizes/LP-0002.md | 4 ++-- prizes/LP-0003.md | 2 +- prizes/LP-0004.md | 2 +- prizes/LP-0005.md | 4 ++-- prizes/LP-0006.md | 4 ++-- prizes/LP-0008.md | 4 ++-- prizes/LP-0009.md | 2 +- prizes/LP-0010.md | 2 +- prizes/LP-0011.md | 2 +- prizes/LP-0012.md | 4 ++-- prizes/LP-0013.md | 4 ++-- prizes/LP-0014.md | 4 ++-- prizes/LP-0015.md | 8 ++++---- prizes/LP-0017.md | 4 ++-- 17 files changed, 34 insertions(+), 34 deletions(-) diff --git a/TERMS.md b/TERMS.md index 4573a87..9133ee6 100644 --- a/TERMS.md +++ b/TERMS.md @@ -2,17 +2,17 @@ *Last updated: 2 March 2026* -These Terms and Conditions ("Terms") are entered into by and between Logos Collective Association, Baarerstrasse 10, 6300 Zug, Switzerland ("Logos", "we", "us") and any individual or legal entity participating in the λPrize Program, including by submitting any solution or pull request ("Submission") to the λPrize GitHub repository ("you", "Participant") (each a "Party" and together the "Parties"). +These Terms and Conditions ("Terms") are entered into by and between Logos Collective Association, Baarerstrasse 10, 6300 Zug, Switzerland ("Logos", "we", "us") and any individual or legal entity participating in the λ Prize Program, including by submitting any solution or pull request ("Submission") to the λ Prize GitHub repository ("you", "Participant") (each a "Party" and together the "Parties"). -By making a Submission to λPrize through the relevant λPrize GitHub repositories or relevant platform (and for the purposes of these Terms, it'll be referred to as λPrize Github repository), you acknowledge that you have read, understood, and agree to be bound by these Terms and any applicable Prize specifications. +By making a Submission to λ Prize through the relevant λ Prize GitHub repositories or relevant platform (and for the purposes of these Terms, it'll be referred to as λ Prize Github repository), you acknowledge that you have read, understood, and agree to be bound by these Terms and any applicable Prize specifications. You can contact us about these Terms in case you have any questions: [legal@free.technology](mailto:legal@free.technology). ## 1. Lambda Prize Overview -Logos supports the development and adoption of decentralised technologies and applications around the Logos technology stack and related ecosystem components through the λPrize Program ("Program" or "λPrize"). +Logos supports the development and adoption of decentralised technologies and applications around the Logos technology stack and related ecosystem components through the λ Prize Program ("Program" or "λ Prize"). -The Program comprises multiple prizes (each a "Prize"), including but not limited to prizes described in the λPrize GitHub repository. Each Prize is governed by a separate prize specification, which sets out the scope, requirements, success criteria, and prize amount applicable to that Prize. +The Program comprises multiple prizes (each a "Prize"), including but not limited to prizes described in the λ Prize GitHub repository. Each Prize is governed by a separate prize specification, which sets out the scope, requirements, success criteria, and prize amount applicable to that Prize. The Program is discretionary in nature. Logos retains sole and absolute discretion over the design of the Program, the content and nature of any prize specifications, the evaluation of submissions, the selection (or non‑selection) of winners, and the award or non‑award of any Prize. No Participant will have any entitlement to receive a Prize. @@ -60,7 +60,7 @@ Each Submission shall target only one Prize as defined in the relevant Prize spe ### 5.2 Manner of submissions and deadline -Submissions must be made through λPrize GitHub repository workflow, as indicated in the applicable Prize specification or an alternative platform as communicated by Logos. +Submissions must be made through λ Prize GitHub repository workflow, as indicated in the applicable Prize specification or an alternative platform as communicated by Logos. Unless stated otherwise, Submissions for the Parallel Society event must be received before the deadline specified in the relevant platform (e.g. Saturday 7 March 2026, 23:59 UTC). Late Submissions will not be considered. @@ -127,7 +127,7 @@ Winners are solely responsible for any tax obligations, reporting, or filings ar ## 9. Post-Event continuation -Following the conclusion of any associated hackathon or live event (including the Parallel Society Congress), the λPrize GitHub repository may remain open or be opened for further Submissions from a specified date. +Following the conclusion of any associated hackathon or live event (including the Parallel Society Congress), the λ Prize GitHub repository may remain open or be opened for further Submissions from a specified date. Unless otherwise specified: @@ -164,7 +164,7 @@ Logos reserves the right, at any time and in its sole discretion, to: 4. cancel individual Prizes; or 5. cancel, suspend, or modify the Program or any associated event in whole or in part. -Logos will communicate material changes to the Program through the λPrize GitHub repository, or other official channels designated by Logos. Your continued participation in the Program after publication of updated Terms or rules constitutes your acceptance of such updates. +Logos will communicate material changes to the Program through the λ Prize GitHub repository, or other official channels designated by Logos. Your continued participation in the Program after publication of updated Terms or rules constitutes your acceptance of such updates. All decisions by Logos regarding eligibility, evaluation, and winner selection are final and binding. diff --git a/prizes/LP-0000.md b/prizes/LP-0000.md index c9ce4c9..5604c7d 100644 --- a/prizes/LP-0000.md +++ b/prizes/LP-0000.md @@ -113,6 +113,6 @@ The following policies apply to all prizes (see [evaluation policies](../README. > Links to relevant specs, documentation, APIs, or prior work that participants should know about. -## Potential for Subsequent λPrizes +## 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. diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index 8d2c5a4..6c2b819 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -104,6 +104,6 @@ The following policies apply to all prizes (see [evaluation policies](../README. - [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone) -## Potential for Subsequent λPrizes +## Potential for Subsequent λ Prizes TBD \ No newline at end of file diff --git a/prizes/LP-0002.md b/prizes/LP-0002.md index 42311f4..45d3bd4 100644 --- a/prizes/LP-0002.md +++ b/prizes/LP-0002.md @@ -112,6 +112,6 @@ The following policies apply to all prizes (see [evaluation policies](../README. - [MACI — Minimum Anti-Collusion Infrastructure](https://privacy-scaling-explorations.github.io/maci/) - [Threshold signature schemes (FROST)](https://eprint.iacr.org/2020/852) -## Potential for Subsequent λPrizes +## Potential for Subsequent λ Prizes -This prize targets the current LEZ testnet. Should a future testnet version introduce breaking changes, a subsequent λPrize may be opened to cover the necessary adaptation and redeployment. +This prize targets the current LEZ testnet. Should a future testnet version introduce breaking changes, a subsequent λ Prize may be opened to cover the necessary adaptation and redeployment. diff --git a/prizes/LP-0003.md b/prizes/LP-0003.md index 62f0be3..c4e6cec 100644 --- a/prizes/LP-0003.md +++ b/prizes/LP-0003.md @@ -114,6 +114,6 @@ The following policies apply to all prizes (see [evaluation policies](../README. - [Merkle airdrop reference (public baseline)](https://github.com/Uniswap/merkle-distributor) - [zk-kit — Merkle tree and nullifier primitives](https://github.com/privacy-scaling-explorations/zk-kit) -## Potential for Subsequent λPrizes +## Potential for Subsequent λ Prizes Testnet 0.3/0.4 compatibility, mainnet deployment and adoption. diff --git a/prizes/LP-0004.md b/prizes/LP-0004.md index 37f955e..3c0a3ec 100644 --- a/prizes/LP-0004.md +++ b/prizes/LP-0004.md @@ -112,6 +112,6 @@ The following policies apply to all prizes (see [evaluation policies](../README. - [Sealed-bid auctions on blockchains — survey](https://eprint.iacr.org/2021/1113) - [Penumbra DEX — sealed-bid batch auction design](https://protocol.penumbra.zone/main/dex.html) -## Potential for Subsequent λPrizes +## Potential for Subsequent λ Prizes TBD diff --git a/prizes/LP-0005.md b/prizes/LP-0005.md index 67cf8d0..829a2b2 100644 --- a/prizes/LP-0005.md +++ b/prizes/LP-0005.md @@ -124,6 +124,6 @@ The following policies apply to all prizes (see [evaluation policies](../README. - [Range proofs in ZK circuits](https://docs.circom.io/more-circuits/more-basic-circuits/#range-proof) — background on proving `balance >= N` - [zk-kit — Merkle tree primitives](https://github.com/privacy-scaling-explorations/zk-kit) -## Potential for Subsequent λPrizes +## Potential for Subsequent λ Prizes -This prize targets the current LEZ testnet. Should a future testnet version introduce breaking changes, a subsequent λPrize may be opened to cover the necessary adaptation and redeployment. +This prize targets the current LEZ testnet. Should a future testnet version introduce breaking changes, a subsequent λ Prize may be opened to cover the necessary adaptation and redeployment. diff --git a/prizes/LP-0006.md b/prizes/LP-0006.md index a697fce..f1b6c5e 100644 --- a/prizes/LP-0006.md +++ b/prizes/LP-0006.md @@ -118,7 +118,7 @@ The following assumptions underpin the security and reliability of the atomic sw ### Out of Scope - Lightning Network integration or multi-hop/routed swaps. -- Ongoing maintenance or security audits beyond initial delivery. Follow-up prizes may cover testnet 0.3 compatibility, mainnet deployment, and ongoing maintenance — see [Potential for Subsequent λPrizes](#potential-for-subsequent-λprizes). +- Ongoing maintenance or security audits beyond initial delivery. Follow-up prizes may cover testnet 0.3 compatibility, mainnet deployment, and ongoing maintenance — see [Potential for Subsequent λ Prizes](#potential-for-subsequent-λ-prizes). ## Infrastructure & Dependencies @@ -200,7 +200,7 @@ The following policies apply to all prizes (see [evaluation policies](../README. - [curve25519-dalek](https://github.com/dalek-cryptography/curve25519-dalek) - [secp256kFUN!](https://github.com/LLFourn/secp256kfun) -## Potential for Subsequent λPrizes +## Potential for Subsequent λ Prizes - **Testnet 0.3 compatibility**: If LEZ testnet 0.3 introduces breaking changes, a follow-up prize may be opened to update the atomic swap implementation for compatibility. - **Mainnet deployment**: A subsequent prize may target mainnet deployment of the atomic swap application, with adoption-related success criteria (e.g., volume, number of unique users, liquidity thresholds). diff --git a/prizes/LP-0008.md b/prizes/LP-0008.md index cc9456e..664af93 100644 --- a/prizes/LP-0008.md +++ b/prizes/LP-0008.md @@ -183,6 +183,6 @@ The following policies apply to all prizes (see [evaluation policies](../README. - [LP-0002](LP-0002.md) — Private M-of-N Multisig (relevant for above-threshold approval flows) - [LP-0005](LP-0005.md) — Private Token Balance Attestation (relevant for token-gated group access by agents) -## Potential for Subsequent λPrizes +## Potential for Subsequent λ Prizes -This prize targets the current LEZ testnet. Should a future testnet version introduce breaking changes, a subsequent λPrize may be opened to cover the necessary adaptation and redeployment. +This prize targets the current LEZ testnet. Should a future testnet version introduce breaking changes, a subsequent λ Prize may be opened to cover the necessary adaptation and redeployment. diff --git a/prizes/LP-0009.md b/prizes/LP-0009.md index 6c593c2..cb6adab 100644 --- a/prizes/LP-0009.md +++ b/prizes/LP-0009.md @@ -65,6 +65,6 @@ Submissions are evaluated first-come-first-served against the success criteria. - [nexum-keycard](https://github.com/aspect-build/nexum-keycard) — Rust SDK and CLI - [keycard-cli](https://github.com/status-im/keycard-cli) — Go CLI (useful as implementation reference) -## Potential for Subsequent λPrizes +## Potential for Subsequent λ Prizes No follow-up prize is anticipated at this time. diff --git a/prizes/LP-0010.md b/prizes/LP-0010.md index 708e8ca..05cd746 100644 --- a/prizes/LP-0010.md +++ b/prizes/LP-0010.md @@ -85,6 +85,6 @@ Evaluators will independently clone the repository and run the application from - [BIP-49: Derivation scheme for P2WPKH-nested-in-P2SH](https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki) - [BIP-84: Derivation scheme for P2WPKH](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki) -## Potential for Subsequent λPrizes +## Potential for Subsequent λ Prizes No follow-up prize is anticipated at this time. \ No newline at end of file diff --git a/prizes/LP-0011.md b/prizes/LP-0011.md index 95f8285..6ef89b2 100644 --- a/prizes/LP-0011.md +++ b/prizes/LP-0011.md @@ -136,6 +136,6 @@ The following policies apply to all prizes (see [evaluation policies](../README. - [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone) -## Potential for Subsequent λPrizes +## Potential for Subsequent λ Prizes TBD diff --git a/prizes/LP-0012.md b/prizes/LP-0012.md index 07c5da1..5125683 100644 --- a/prizes/LP-0012.md +++ b/prizes/LP-0012.md @@ -138,6 +138,6 @@ The following policies apply to all prizes (see [evaluation policies](../README. - [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone) -## Potential for Subsequent λPrizes +## Potential for Subsequent λ Prizes -This prize targets the current LEZ testnet. Should a future testnet version introduce breaking changes, a subsequent λPrize may be opened to cover the necessary adaptation and redeployment. +This prize targets the current LEZ testnet. Should a future testnet version introduce breaking changes, a subsequent λ Prize may be opened to cover the necessary adaptation and redeployment. diff --git a/prizes/LP-0013.md b/prizes/LP-0013.md index 7321485..37c180e 100644 --- a/prizes/LP-0013.md +++ b/prizes/LP-0013.md @@ -101,6 +101,6 @@ The following policies apply to all prizes (see [evaluation policies](../README. - [Solana - Token Extensions](https://solana.com/docs/tokens/extensions) - [Solana - Set Authority](https://solana.com/docs/tokens/basics/set-authority) -## Potential for Subsequent λPrizes +## Potential for Subsequent λ Prizes -This prize targets the current LEZ testnet. Should a future testnet version introduce breaking changes, a subsequent λPrize may be opened to cover the necessary adaptation and redeployment. +This prize targets the current LEZ testnet. Should a future testnet version introduce breaking changes, a subsequent λ Prize may be opened to cover the necessary adaptation and redeployment. diff --git a/prizes/LP-0014.md b/prizes/LP-0014.md index 2f27350..1877f43 100644 --- a/prizes/LP-0014.md +++ b/prizes/LP-0014.md @@ -78,6 +78,6 @@ By default, submissions are evaluated first-come-first-served against the succes - [Solana - Token Extensions](https://solana.com/docs/tokens/extensions) - [Solana - ATA](https://github.com/solana-labs/solana-program-library/blob/master/docs/src/associated-token-account.md) -## Potential for Subsequent λPrizes +## Potential for Subsequent λ Prizes -This prize targets the current LEZ testnet. Should a future testnet version introduce breaking changes, a subsequent λPrize may be opened to cover the necessary adaptation and redeployment. +This prize targets the current LEZ testnet. Should a future testnet version introduce breaking changes, a subsequent λ Prize may be opened to cover the necessary adaptation and redeployment. diff --git a/prizes/LP-0015.md b/prizes/LP-0015.md index a747e67..749ebe6 100644 --- a/prizes/LP-0015.md +++ b/prizes/LP-0015.md @@ -7,7 +7,7 @@ dependencies: [] **`Status: Closed`** **`Logos Circle: N/A`** -This prize is closed **without an external λPrize submission**. The work was **delivered by the Logos Execution Zone (LEZ) team** as part of the core runtime and tooling rather than awarded through this competition. +This prize is closed **without an external λ Prize submission**. The work was **delivered by the Logos Execution Zone (LEZ) team** as part of the core runtime and tooling rather than awarded through this competition. ## Overview This prize is for designing and implementing *general cross-program calls* (call mid-execution, then continue) while keeping *tail calls as the only execution primitive*. The system should let a program tail-call another program, have control return later via another tail call, and then continue execution in an *internal-only function* that cannot be invoked directly by users. @@ -109,7 +109,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho ## Evaluation Process -**Closed.** This prize is not accepting submissions. The capability was implemented by the **LEZ team**; there is **no external λPrize winner** or `solutions/LP-0015.md` entry. +**Closed.** This prize is not accepting submissions. The capability was implemented by the **LEZ team**; there is **no external λ Prize winner** or `solutions/LP-0015.md` entry. The success criteria and submission requirements above are **retained as the original specification** of the intended work for historical reference. @@ -119,6 +119,6 @@ The success criteria and submission requirements above are **retained as the ori - [Cross Program Invocation](https://solana.com/docs/core/cpi) - [Tail calls](https://github.com/WebAssembly/tail-call/blob/main/proposals/tail-call/Overview.md) -## Potential for Subsequent λPrizes +## Potential for Subsequent λ Prizes -This prize targets the current LEZ testnet. Should a future testnet version introduce breaking changes, a subsequent λPrize may be opened to cover the necessary adaptation and redeployment. +This prize targets the current LEZ testnet. Should a future testnet version introduce breaking changes, a subsequent λ Prize may be opened to cover the necessary adaptation and redeployment. diff --git a/prizes/LP-0017.md b/prizes/LP-0017.md index 49341d9..d1fd873 100644 --- a/prizes/LP-0017.md +++ b/prizes/LP-0017.md @@ -132,6 +132,6 @@ The following policies apply to all prizes (see [evaluation policies](../README. - [LP-0008](./LP-0008.md) — Autonomous AI Module (reference for Logos Core module architecture and storage/delivery patterns) - [LP-0012](./LP-0012.md) — Event/Log mechanism (relevant for on-chain event emission from the registry program) -## Potential for Subsequent λPrizes +## Potential for Subsequent λ Prizes -This prize targets the current LEZ testnet. Should a future testnet version introduce breaking changes, a subsequent λPrize may be opened to cover the necessary adaptation and redeployment. A follow-up prize may extend the app with search and discoverability features built on top of the document-indexing module. +This prize targets the current LEZ testnet. Should a future testnet version introduce breaking changes, a subsequent λ Prize may be opened to cover the necessary adaptation and redeployment. A follow-up prize may extend the app with search and discoverability features built on top of the document-indexing module. From 6390f1f498edff912e8896dcc6b9732562852552 Mon Sep 17 00:00:00 2001 From: Davit Maisuradze <denton.gaibo@gmail.com> Date: Wed, 10 Jun 2026 11:26:46 +0400 Subject: [PATCH 10/28] =?UTF-8?q?Solution:=20LP-0016=20=E2=80=94=20Anonymo?= =?UTF-8?q?us=20Forum=20with=20Threshold=20Moderation=20and=20Membership?= =?UTF-8?q?=20Revocation?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- solutions/LP-0016.md | 323 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 323 insertions(+) create mode 100644 solutions/LP-0016.md diff --git a/solutions/LP-0016.md b/solutions/LP-0016.md new file mode 100644 index 0000000..348c7c9 --- /dev/null +++ b/solutions/LP-0016.md @@ -0,0 +1,323 @@ +# Solution: LP-0016 — Anonymous Forum with Threshold Moderation and Membership Revocation + +**Submitted by:** Davit Maisuradze ([@jeefxM](https://github.com/jeefxM)) + +## Summary + +A complete LP-0016 implementation: a forum-agnostic moderation SDK plus a +reference Logos Basecamp module that drives the full lifecycle (registration +with stake, anonymous posting, N-of-M moderation, K-strike slashing, +retroactive deanonymization). Membership registration and slashing are +**on-chain** on the public LEZ testnet; posting and moderation are **off-chain** +over Waku, the way the protocol is designed (free common path, paid revocation). + +- **Anonymous posting** with a Groth16 membership proof (≈5 s per post, + generated and verified off-chain by the local proof-daemon via snarkjs). +- **N-of-M moderation certificates** aggregated off-chain over Waku, with the + daemon enforcing the N threshold before a certificate is emitted. +- **K-strike slashing** via Shamir reconstruction of the member's nullifier + secret; one on-chain tx per slash; the slashed commitment enters the on-chain + revocation set and the published secret lets any verifier reject the member's + future posts. +- **Two parameterized forum instances live on LEZ testnet** under one program ID + (different K and N-of-M), each with register-with-stake on chain. +- **Reference Qt6 GUI** (standalone `ForumApp`; Logos Basecamp module packaging + in progress) built on the SDK's public, forum-agnostic API. + Non-CLI, click-driven: connect → create identity → create forum → register → + post → strike → slash, with a persistent MEMBER REVOKED banner, per-post + ✓ valid / ✗ author revoked badges, a Shamir evidence panel that fills in + share-by-share as strikes land, and a chain-evidence panel showing the + registry account, tree root, and on-chain register/slash tx hashes. + +## Repository + +- **Repo:** https://github.com/jeefxM/LP-0016-Anonymous-forum-with-moderation +- **Branch:** `main` +- **Video Demo:** https://www.youtube.com/watch?v=Q6fMpLB_850 + +## Approach + +Built on top of the Logos stack: + +- **LEZ membership_registry program** (`programs/registry-spel/`, SPEL IDL at + `programs/registry-spel/registry-spel.idl.json`) holds the on-chain membership + tree, the revoked commitment set, and a slash verifier that runs inside the + RISC0 zkVM (ark-bn254 `poly_eval` + Ed25519 signature checks). Deployed once; + forum instances are seed-derived `ForumState` PDAs that carry their own + `ForumConfig` (K and N-of-M) — see `docs/deployments.md`. +- **Forum-agnostic SDK** (`sdk/`, `@logos-forum/moderation-sdk`) wraps a local + proof-daemon (Groth16 prover + chain submitter) and a Waku transport + (`@waku/sdk`). The SDK operates on abstract content identifiers and makes no + assumptions about forum structure, satisfying the bounty's + "forum-agnostic library" requirement. +- **ZK membership proof** is a Groth16 circuit (`circuits/`, ADR-010). The + circom + rapidsnark path was chosen over RISC0 for the per-post proof + because membership proof generation needed to fit under the bounty's 10 s + budget on a standard laptop (rapidsnark proves the circuit in ~5 s vs ~55 s + for an equivalent RISC0 STARK — the RISC0 number is measured by + `bench_post_proof` at `RISC0_DEV_MODE=0`, see `docs/cu-costs.md`). +- **Slash via Shamir**: each post envelope embeds a Shamir share of the + member's nullifier secret (degree-(K-1) polynomial, secret evaluates at + x = 0). Moderation certificates bind shares to content identifiers. Once K + certificates exist for a member's nullifier, anyone can reconstruct the + secret and submit a single on-chain slash tx (`/v1/slash/recover` → + `submitSlash`). Below K, no information about the secret leaks — the + reconstruction is information-theoretically secure. +- **Basecamp module** (`basecamp/`) is a Qt6 UI module. QML is in + `basecamp/qml/Main.qml`; the C++ backend in `basecamp/src/ForumBackend.cpp` + drives a Node sidecar (`basecamp/sidecar/forum-sidecar.mjs`) via `QProcess`. + The sidecar consumes the same TS SDK that `sdk/tests/lifecycle.mjs` runs, so + the GUI's behaviour follows the proven path. The Basecamp module is built + entirely on the SDK's public, forum-agnostic API and adds no forum-specific + code to the library. + +**Why Logos**: censorship resistance for the off-chain moderation record +(Waku is the only viable transport for moderator certificates that cannot be +silently deleted), and trustless enforcement at the point of revocation +(LEZ verifies the cert evidence cryptographically; no centralized +authority can selectively enforce or veto a slash). A centralized +alternative would either trust a server with the moderation record (defeats +auditability) or skip the revocation enforcement (defeats the threshold +moderation guarantee). + +**Why not on-chain moderation per-strike**: every strike going on-chain +would impose a per-cert gas cost on moderators. Keeping certificates on +Waku and only the final slash on-chain (one tx per revocation) preserves +the protocol's economic invariant: free common path, paid revocation. + +**Where each step runs**: + +- **On-chain (LEZ testnet, `testnet.lez.logos.co`)**: forum initialize, + fund-escrow, register-with-stake, and slash. The testnet sequencer EXECUTES + these transactions; it does not produce an inline STARK per tx. The two live + parameterized instances carry on-chain state, register-with-stake, and slash. + The testnet wallet at `~/wallet-testnet` ships preconfigured genesis-funded + accounts (`6iArKUXx…` = 10 000, `7wHg9sb…` = 20 000, + authenticated-transfer-owned → spendable) which fund the escrow via + `auth-transfer 1000 → escrow` per ADR-011. +- **Off-chain (Waku + local proof-daemon)**: anonymous posting (Groth16 prove + + verify via snarkjs), moderation vote signing and certificate aggregation, and + the post-rejection check for revoked members. None of these touch the + sequencer. +- **Real RISC0 STARK**: the only real STARK in this submission is the membership + post-proof guest, benchmarked by `bench_post_proof` at `RISC0_DEV_MODE=0` + (~55 s, prove + verify OK) — see `docs/cu-costs.md` and ADR-002. +- **Local on-chain-logic test**: `crates/lez-runner/tests/staking_lifecycle.rs` + exercises register → post → K certs → slash → revoke through the in-process + V03State engine (it executes the program logic; it does not generate a STARK). + This is the canonical local end-to-end because the LEZ standalone-mode chain + has no runtime funding path (ADR-011 §"The faucet is genesis-only"), so + register-with-stake against a live local sequencer is not possible by design; + the funded path runs on testnet. + +**Disclosures (deliberate scope decisions)**: + +- **Posting is demonstrated at K = 3 only.** The membership circuit is + parameterized by K (`circuits/membership.circom`, `template Membership(TREE_DEPTH, K)`), + but only one instance is compiled and trusted-set-up: `Membership(16, 3)` + → `membership_0.zkey`, and the live daemon runs `CIRCUIT_K=3`. + Each distinct K needs its own circuit compile + trusted setup, so Instance A + (K = 3) demos the full lifecycle including posting + slash, while Instance B + (K = 2) exercises the registry's parameterizability **on-chain** live + (different K and N-of-M, register-with-stake on testnet — see Program ID + + PDAs below) but its **posting** path is not exercised, because the running + daemon's circuit is K = 3. The bounty's two-instance requirement is about + instance *parameters* (`ForumConfig` K and N-of-M, which are fully general + on-chain), not a second compiled circuit. Supporting K = 2 posting is a + recompile + `snarkjs groth16 setup` away, but no K = 2 zkey is shipped today. +- The Basecamp module's moderator coordination is collapsed for the + single-operator demo: the backend holds all N moderator secrets locally + and signs N votes per Strike click. In a real deployment those N keys + live on N different machines and each moderator submits a vote + independently over Waku; the SDK's `aggregateCertificate` accepts + whichever ≥ N-threshold votes arrive first. Code path at + `basecamp/src/ForumBackend.cpp:moderate()` and + `basecamp/sidecar/forum-sidecar.mjs:case "moderate"`. + +## Success Criteria Checklist + +- [x] **Member can register with a stake and publish anonymous posts; + posts from the same member are unlinkable below the slash threshold.** + Register-with-stake runs on testnet (escrow funded via `auth-transfer`, + per ADR-011); posting runs off-chain with a Groth16 proof carrying an + epoch-derived nullifier (same per (member, epoch), distinct across members), + and each post embeds an independent Shamir share whose x-coordinate is the + strike index — the share alone reveals nothing under K. Exercised by + `sdk/tests/lifecycle.mjs` and the Basecamp GUI. See `docs/protocol.md §3`. + +- [x] **Slash retroactively deanonymizes the slashed member's prior posts; + no other member is affected; documented in `docs/protocol.md`.** + See `docs/protocol.md §4` ("Retroactive deanonymization on slash"). The + reconstruction recovers exactly one member's secret; everyone else's + shares remain below K. + +- [x] **N-of-M moderators can jointly produce a certificate; fewer cannot.** + The daemon's `/v1/moderation/aggregate` endpoint refuses to emit a + certificate when fewer than N valid votes are supplied. Enforced + client-side in `sdk/src/index.ts:aggregateCertificate`, and re-verified + by the on-chain slash verifier. + +- [x] **K certs → slash → revocation, single on-chain tx.** + Demonstrated live on LEZ testnet by the full-lifecycle runner + (`programs/registry-spel/examples/src/bin/testnet_lifecycle.rs`): + 3 posts × 3 certs with distinct content IDs → Shamir reconstruction → + one on-chain slash tx → the commitment enters the on-chain revocation set + (verified by reading the state PDA back). Tx hashes in `docs/deployments.md`. + The same flow is exercised locally (no funding required) by + `crates/lez-runner/tests/staking_lifecycle.rs` through the in-process + V03State engine. + +- [x] **Slashed commitment is added to the revocation list; subsequent + posts from it are rejected.** + On slash, the reconstructed secret is published on-chain and the commitment + enters the revocation set. Post-rejection is enforced off-chain by the + proof-daemon: `verify_post` calls `post_proof_core::is_revoked_post` + (`crates/proof-daemon/src/proving.rs:252`), which recomputes the published + secret's nullifier `H("null" || secret || epoch)` for the proven epoch and + rejects any post whose nullifier matches — across epochs, so the member + cannot evade by changing epoch. Asserted by the unit test + `post_proof_core` (revoked-member-posts-rejected-across-epochs) and + end-to-end by `sdk/tests/lifecycle.mjs` (re-verifying the same post envelope + after slash returns `valid: false` with a `/revok/i` reason). At the GUI + layer the post sidecar runs `verifyPostProof` before publishing; a revoked + author gets a red ✗ badge and the `Post` button switches to a disabled + "Revoked" state once the GUI detects its own commitment in the revoked set. + +- [x] **Parameterizable K and N-of-M per forum instance.** + Two live instances under one program ID — Instance A (K=3, 2-of-3) and + Instance B (K=2, 3-of-4) — share the SPEL `membership_registry` program + but carry distinct `ForumConfig` in their PDAs. + See `docs/deployments.md`. + +- [x] **Forum-agnostic moderation library, public API, no forum + assumptions, uses Logos stack off-chain.** + `@logos-forum/moderation-sdk` exports `createIdentity`, + `createForumInstance`, `register`, `createPostProof`, `publishPost`, + `subscribePosts`, `listPosts`, `signModerationVote`, `aggregateCertificate`, + `publishCertificate`, `listCertificatesByNullifier`, + `tryReconstructSlashEvidence`, `submitSlash`, `verifyPostProof`, + `isRevoked`. Operates on `ContentId = Hex32`; the SDK never names a + body or content type. + +- [x] **Working Logos Basecamp app built on the library, usable by a + non-technical user.** + `basecamp/` builds a Logos Basecamp UI module (`libforum_plugin.so`, + implementing the `IComponent` interface, IID `com.logos.component.IComponent`, + + `metadata.json`/`manifest.json`). It is **verified loadable into + LogosBasecamp v0.1.2** via the AppImage's `ui-host` loader (the loader emits + `READY`; load log captured — see the release artifacts). The same QML/backend + also runs standalone as `ForumApp` for builders without Basecamp installed. + The module is built entirely on the SDK's public, forum-agnostic API. The user + sets the moderator count and N-of-M/K thresholds in the UI; the backend + provisions distinct real moderator keypairs (no hardcoded secrets) and shows + their public keys. Every lifecycle action is click-driven; the user never + crafts a tx or runs a CLI command. + +- [x] **End-to-end demonstration on LEZ testnet with at least two + independent forum instances using different K and N-of-M.** + Both instances are live on `testnet.lez.logos.co` under a single + `membership_registry` deployment. The state PDAs decode to non-empty + `ForumState` with advanced `tree_root`, distinct `(K, N-of-M)` config, + and an escrow holding the staked balance (independently verifiable via + `wallet account get` against the testnet sequencer): + + | | Instance A | Instance B | + |---|---|---| + | (K, N-of-M) | (3, 2-of-3) | (2, 3-of-4) | + | state PDA | `9zHLZn5qpMwaWurrs7DQgYDyF4XnF6EwE4HJfqkrDJ37` | `3gN9jzTbTL6WgxpqMMA5anUM8wavGdMk4isPY6HmX8p1` | + | escrow PDA | `8yiWGFYQ3vAatQfJdpyT6mUBGpTzqRfikF2yDwzNf7B1` | `5XbV2TAjonag397C5PQNuUBU5yd3f9n6SkprqM7LpYxw` | + | lifecycle on chain | register-with-stake → 3 posts → 3 N-of-M certs → **slash** | register-with-stake | + | `tree_root` after register | `ee499d794328661f…` | `c562c3f806c58ab7…` | + | escrow balance | `0` — stake **claimed by the slasher** when the slash executed | `1000` (staked, live) | + | slash | tx `22d391be447aa12c…`; commitment `0ba57a0c92e84302…` is in the on-chain revocation set | not run (the live daemon's circuit is K=3, so Instance B exercises parameterization on chain but not posting/slash) | + + Program ID (both): + `4766fcc24cac757ab4c504b3844c354468f4d7fbb7b630957573513c6eb9a30d`, + guest ImageID + `69373bb59ef0468f8f8748229d79f7cf54ca08b954bef983c641dcedd6d91d47`. + Instance A's full on-chain lifecycle (initialize → fund-escrow → register → + moderate → slash → revoke) is demonstrated live on testnet through the Basecamp + sidecar; the drained escrow is the on-chain proof that the slash claimed the + stake. Tx hashes and state read-back are in `docs/deployments.md`. + +## FURPS Self-Assessment + +### Functionality + +Full LP-0016 protocol — register-with-stake (on-chain, testnet), anonymous +posting with Groth16 proofs (off-chain), N-of-M moderation with off-chain +certificates over Waku, K-strike Shamir reconstruction, and on-chain slash that +revokes membership and claims stake. The Basecamp module surfaces the entire +flow as click-driven actions. Two parameterized instances confirmed on chain. + +### Usability + +- The Basecamp app is the only thing a forum user needs. No CLI, no tx + crafting. Each lifecycle action is a single click; the GUI shows + busy state, success toasts, and a persistent error line below the + feed. +- Per-post visual state surfaces protocol semantics: green ✓ valid pill + for posts that verify, red ✗ author revoked pill for posts whose + author has been slashed. +- A Shamir-evidence panel fills in one share-pill per strike, so the + cryptographic story (K shares accumulate → secret recoverable) is + visible without reading code. +- A chain-evidence panel exposes the on-chain registry account, tree + root, and most recent register / slash tx hashes for independent + verification. + +### Reliability + +- Proof generation failures bubble as typed `ForumError` from the SDK; + the GUI shows the daemon's error message verbatim and re-enables the + button so the user can retry without consuming the nullifier (the + nullifier is deterministic from `(secret, epoch)`, so retry is safe). +- The SDK's `aggregateCertificate` enforces the N threshold client-side + before any on-chain submission — a partial certificate cannot reach + the chain. +- A durable outbox retries failed Waku publishes with exponential backoff. A + publish that fails is persisted to disk (not dropped); the `flush-outbox` + sidecar command retries pending items and removes each on success. Retries are + idempotent because the nullifier and content id are deterministic (a duplicate + publish is a protocol no-op). See `basecamp/sidecar/forum-sidecar.mjs` + (`durablePublish` / `flush-outbox`). + +### Performance + +- Groth16 membership proof generation ≈ 5 s on the dev box + (target: < 10 s). See `docs/cu-costs.md`. +- On-chain register CU cost and slash CU cost documented in + `docs/cu-costs.md`. + +### Supportability + +- `docs/protocol.md` covers system model, primitives, unlinkability + + anonymity set, retroactive deanonymization on slash, revocation + mechanism, moderator trust model, threat model, known limitations. +- `docs/deployments.md` documents the live stack (Hetzner build host + with `RISC0_DEV_MODE=0` sequencer + nwaku + proof-daemon), the + deployed program ID, both instance PDAs, and tx hashes for each + lifecycle step. +- `docs/cu-costs.md` measures CU cost for every on-chain operation and + the real RISC0 STARK timing (`bench_post_proof`, `RISC0_DEV_MODE=0`). +- `docs/adr/` ADRs capture key implementation decisions (Groth16 vs + RISC0 for membership; share-binding scheme; SPEL port; ATA model). +- CI (`.github/workflows/ci.yml`) runs `cargo fmt`/`clippy`/`test` on the + LEZ-independent crates plus the SDK build and unit tests. The full + Waku + sequencer end-to-end (`sdk/tests/lifecycle.mjs`) needs a live + LEZ sequencer + nwaku and runs on the build host, not in GitHub-hosted CI. +- `basecamp/README.md` documents how to build the `.lgx` and load it + into Basecamp, plus how to run the standalone `ForumApp` preview. + +## Supporting Materials + +- **Video demo (narrated, full lifecycle, both instances)**: https://www.youtube.com/watch?v=Q6fMpLB_850 +- **Live deployment** (Hetzner): see `docs/deployments.md`. +- **Architecture decisions**: `docs/adr/`. +- **Test suite**: `sdk/tests/lifecycle.mjs` (full protocol, build host) and the + crate unit tests run in CI. + +## Terms & Conditions + +By submitting this solution, I confirm that I have read and agree to +the [Terms & Conditions](../TERMS.md). From 84dbfe9323f985b7701c4be3465472543599c86d Mon Sep 17 00:00:00 2001 From: fryorcraken <commits@fryorcraken.xyz> Date: Thu, 18 Jun 2026 19:21:38 +1000 Subject: [PATCH 11/28] Remove LP-0006: Atomic Swap with LEZ Delete the LP-0006 prize and its row in the README table. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --- README.md | 1 - prizes/LP-0006.md | 206 ---------------------------------------------- 2 files changed, 207 deletions(-) delete mode 100644 prizes/LP-0006.md diff --git a/README.md b/README.md index 39f9913..d529efd 100644 --- a/README.md +++ b/README.md @@ -30,7 +30,6 @@ All prizes live in the `[prizes/](prizes/)` directory. Each prize is a markdown | [LP-0003](prizes/LP-0003.md) | Private Allowlist / Airdrop Distributor | Medium | Open | | [LP-0004](prizes/LP-0004.md) | Sealed-Bid Auction Using Shielded Balances | Large | Draft | | [LP-0005](prizes/LP-0005.md) | Private Token Balance Attestation | Large | Open | -| [LP-0006](prizes/LP-0006.md) | Atomic Swap with LEZ (BTC, XMR, ETH) | XL | Draft | | [LP-0008](prizes/LP-0008.md) | Autonomous AI Module with Wallet, Storage, and Messaging | Large | Open | | [LP-0009](prizes/LP-0009.md) | Keycard NIP-46 Nostr Signer Proxy | Small | Closed | | [LP-0010](prizes/LP-0010.md) | Shell dApp Integration Proof of Concept | Small | Closed | diff --git a/prizes/LP-0006.md b/prizes/LP-0006.md deleted file mode 100644 index f1b6c5e..0000000 --- a/prizes/LP-0006.md +++ /dev/null @@ -1,206 +0,0 @@ ---- -dependencies: [] ---- - -<!-- Don't forget to add/update this prize in the table in README.md --> - -# LP-0006: Atomic Swap with LEZ [DRAFT] - -**`Status: Draft - pending LEZ timelock feature, Logos Delivery module, and Logos Chat module`** -**`Logos Circle: N/A`** -## Overview - -The Logos ecosystem already has a working ETH–LEZ atomic swap using Hash Time-Locked Contracts ([eth-lez-atomic-swaps](https://github.com/logos-blockchain/eth-lez-atomic-swaps)). This prize is for a unified atomic swap application that supports trustless swaps between LEZ and **all three** of the following chains: - -- **Bitcoin** — using Schnorr adaptor signatures and Taproot key-path spends (no custom scripts, swap indistinguishable from a normal payment). -- **Monero** — using Ed25519 adaptor signatures with cross-curve Discrete Log Equality (DLEQ) proofs (the h4sh3d/COMIT protocol, proven on Bitcoin–Monero mainnet). -- **Ethereum** — using HTLCs or adaptor signatures against an Ethereum RPC endpoint. - -The LEZ side is implemented as a Risc0 guest program (Rust) that locks funds contingent on revealing a secret (adaptor secret, hash preimage, or DLEQ proof, depending on the protocol). - -The application follows a **maker/taker model**: the maker acts as a liquidity provider, configuring which trading pairs and prices they support. The maker advertises prices over **Logos Delivery**, and maker-taker negotiation happens over **Logos Chat** — no central infrastructure is used. The maker software must support pricing from both a local configuration (e.g., static prices for testing) and an external source (e.g., a REST API), with the specific external integration left to the developer. - -> **Note:** This prize is currently in **Draft** status because the following dependencies are not yet available: -> - **LEZ timelock**: LEZ does not yet support on-chain timelocks. -> - **Logos Delivery module**: Required for makers to advertise prices and trading pairs. -> - **Logos Chat module**: Required for maker-taker negotiation and swap coordination. -> -> The prize will open once all three are available. - -## Motivation - -Enabling trustless swaps between LEZ and widely-held digital assets — without custodians, bridges, or wrapped tokens — is a prerequisite for meaningful DeFi liquidity in the Logos ecosystem. Different chains present different cryptographic challenges: - -- **Bitcoin**: HTLCs work but have drawbacks (non-standard script, on-chain preimage links the swap legs, identifiable as an atomic swap). Adaptor signatures solve all three — the Bitcoin transaction is a plain Taproot spend, no preimage appears on-chain, and the two legs are cryptographically unlinked. -- **Monero**: No scripting system, so neither HTLCs nor standard adaptor signatures apply directly. The established solution combines Ed25519 adaptor signatures with cross-curve DLEQ proofs to atomically transfer a Monero spend key share. -- **Ethereum**: The existing ETH–LEZ HTLC swap provides a reference, but participants may propose improved approaches (e.g., adaptor signatures, more efficient gas usage). - -A competitive prize is the right mechanism because the protocol design, LEZ escrow construction, and cross-chain coordination all admit multiple valid approaches with meaningful trade-offs. - -## Security & Reliability Assumptions - -The following assumptions underpin the security and reliability of the atomic swap protocol. Submissions must clearly document how their implementation relies on each assumption and what happens if an assumption is violated. - -### Security Assumptions - -- **Trustlessness**: Neither party trusts the other. The protocol must guarantee that a rational adversary cannot steal funds — either both legs of the swap complete, or both are refunded. -- **No centralised intermediaries**: No trusted third party, relay, or centralised service is involved in swap execution, price discovery, or coordination. All communication uses Logos Delivery and Logos Chat. -- **Cryptographic hardness**: The security of adaptor signatures (Bitcoin), cross-curve DLEQ proofs (Monero), and hash-lock constructions (Ethereum) relies on the hardness of the discrete logarithm problem on secp256k1 and Ed25519. Submissions must state which cryptographic assumptions they depend on. -- **On-chain finality**: Each chain's finality model is assumed to hold. Submissions must document the number of confirmations required on each chain before a swap leg is considered final, and the risk of chain reorganisations. -- **Timelock safety margin**: Timelocks must be set with sufficient margin to account for block time variance, network congestion, and clock drift. Submissions must document their timelock parameter choices and the rationale. -- **Key management**: Private keys and adaptor secrets are assumed to be stored securely on each party's local machine. The protocol's security does not extend to compromised keys. - -### Reliability Assumptions - -- **Network availability**: Both parties must be online during the active swap window. Submissions must document what happens if a party goes offline mid-swap (expected behaviour: the counterparty can reclaim funds after the timelock expires). -- **Node liveness**: Each party is assumed to have access to a functioning node for each relevant chain (Bitcoin, Monero, Ethereum, LEZ). Submissions must document graceful degradation if a node becomes temporarily unreachable (e.g., retry logic, swap state persistence). -- **Swap state persistence**: The swap coordinator must persist swap state locally so that incomplete swaps can be resumed after a crash or restart. Loss of swap state before the timelock expires must not lead to loss of funds. -- **Concurrent swap isolation**: Multiple in-flight swaps must not interfere with each other. Each swap must maintain independent state, escrow, and timelock tracking. -- **Logos Delivery & Chat availability**: Price advertisements and negotiation messages depend on the Logos Delivery and Logos Chat modules being available. Submissions must document behaviour when these services are temporarily unreachable (e.g., retry, buffering, degraded mode). - -## Success Criteria - -### Functionality - -- [ ] **No central infrastructure**: The application must not depend on any centralised server or service to operate. All communication between maker and taker uses the Logos stack (see below). -- [ ] Trustless swaps between LEZ and **all three chains** (Bitcoin, Monero, Ethereum) can be completed without custodians, bridges, or wrapped tokens. The Ethereum side must use the **Logos Ethereum module** for Ethereum interactions. -- [ ] The swap protocol is appropriate for each chain's capabilities (adaptor signatures for Bitcoin/Taproot, DLEQ proofs for Monero, HTLCs or adaptor signatures for Ethereum). -- [ ] The LEZ escrow program correctly enforces release of funds upon the required proof (adaptor secret, DLEQ proof, or hash preimage) and supports refund after timelock expiry (see [Security & Reliability Assumptions](#security--reliability-assumptions) for timelock details). -- [ ] The two legs of each swap are atomic: either both complete or both refund. There is no state where one party receives funds and the other does not. -- [ ] **Token support on LEZ**: Swaps support both the native LEZ token and custom tokens issued via the LEZ token program, using Associated Token Accounts (ATAs). -- [ ] **Token support on Ethereum**: Swaps support both native ETH and ERC-20 tokens. -- [ ] **Maker/taker model**: The maker operates as a liquidity provider. The maker software allows configuration of supported trading pairs and prices. The maker advertises available pairs and prices over **Logos Delivery** (the Logos storage/data availability layer). Maker-taker negotiation and swap coordination messages are exchanged over **Logos Chat** (the Logos messaging layer). -- [ ] **Maker pricing**: The maker software supports two pricing modes: (1) **local configuration** (static prices set via config file or CLI, useful for testing) and (2) **external price feed** (fetching prices from an external service, e.g., a REST API). The specific external integration is left to the developer, but the architecture must support pluggable price sources. -- [ ] The **maker** is deployable as a **headless service** with all necessary functionality (pair/price configuration, external price feed, liquidity management, swap execution, monitoring) — no GUI required for operation. -- [ ] At least 5 complete swaps are executed per chain on testnets, involving at least 3 distinct counterparty pairs. - -### 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 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). - -### Reliability - -- [ ] **Graceful degradation**: If a chain-specific dependency is unavailable (e.g., no Monero node running, no Ethereum RPC configured), the application must still start and enable functionality for the remaining chains. Unavailable chains are clearly reported to the user. -- [ ] Swap state is persisted locally so that incomplete swaps can be resumed after a crash or restart without loss of funds. -- [ ] Multiple in-flight swaps do not interfere with each other — each swap maintains independent state, escrow, and timelock tracking. - -### Performance - -- [ ] Document the compute unit (CU) cost of each LEZ escrow operation (lock, release, refund) on LEZ devnet/testnet. Note: LEZ's per-transaction compute budget may change during testnet. - -### Supportability - -- [ ] The program is deployed and tested on LEZ testnet 0.2. -- [ ] 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 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. - -## Scope - -### In Scope - -- Bitcoin-side implementation: adaptor signatures using Schnorr/BIP-340 and Taproot key-path spends, including pre-signing and signature completion logic. -- Monero-side implementation: key share generation, XMR locking to a combined address, spend key reconstruction, wallet sweep, and cross-curve DLEQ proof construction. -- Ethereum-side implementation: HTLC or adaptor signature contracts for ETH↔LEZ and ERC-20↔LEZ swaps, using the **Logos Ethereum module** for Ethereum interactions. -- LEZ escrow program(s) (Rust, Risc0) that lock funds (native token or custom tokens via ATA) contingent on the appropriate cryptographic proof for each chain, with timelock-based refund. -- Maker software: headless-deployable service with pair/price configuration, external price feed integration, liquidity advertisement, and full swap execution. -- Taker software: discovery of maker offers, swap initiation, monitoring, and claim/refund. -- CLI (full functionality for maker, may be limited for taker), GUI (both roles), and module/SDK for programmatic integration. -- Reference integrations on Bitcoin testnet, Monero stagenet, Ethereum Sepolia, and LEZ testnet 0.2, demonstrating complete swaps. -- Documentation covering: protocol design for each chain, LEZ escrow design, cross-chain atomicity argument, timelock handling, security assumptions, and known limitations. - -### Out of Scope - -- Lightning Network integration or multi-hop/routed swaps. -- Ongoing maintenance or security audits beyond initial delivery. Follow-up prizes may cover testnet 0.3 compatibility, mainnet deployment, and ongoing maintenance — see [Potential for Subsequent λ Prizes](#potential-for-subsequent-λ-prizes). - -## Infrastructure & Dependencies - -Participants must run or have access to the following infrastructure for all three target chains: - -### Bitcoin -- A **Bitcoin Core** full node or access to a Bitcoin testnet node (e.g., running `bitcoind` locally with `testnet=1`). -- A Bitcoin wallet capable of creating and signing Taproot (P2TR) transactions (e.g., Bitcoin Core 22+, or a library like `rust-bitcoin` with Taproot support). -- Familiarity with BIP-340 (Schnorr) and BIP-341 (Taproot). - -### Monero -- A **Monero** full node running on stagenet (`monerod --stagenet`), or access to a public stagenet node. -- A **Monero wallet RPC** instance (`monero-wallet-rpc --stagenet`) for programmatic wallet operations. -- Stagenet XMR (available from Monero stagenet faucets). -- Familiarity with Monero's key structure (spend key, view key) and transaction construction. - -### Ethereum -- Access to an **Ethereum RPC endpoint** (e.g., a local node via `geth` or `reth`, or a provider such as Infura, Alchemy, or a public Sepolia RPC). -- Sepolia ETH for testnet deployment (available from Sepolia faucets). -- Familiarity with Solidity smart contracts and tooling (Foundry, Hardhat, or similar). - -### LEZ (all targets) -- The application must work with **LEZ testnet 0.2**. -- Access to the LEZ testnet and LEZ CLI tooling. -- Rust toolchain and [Risc0](https://dev.risczero.com/) development environment for building LEZ programs. -- Familiarity with the [Logos Execution Zone](https://github.com/logos-blockchain/logos-execution-zone/) architecture and the [eth-lez-atomic-swaps](https://github.com/logos-blockchain/eth-lez-atomic-swaps) reference implementation. - -## Prize Structure - -- **Total Prize:** $TBD -- **Effort:** XL - -## Eligibility - -Open to any individual or team. Submissions must be original work. Teams must hold the rights to all submitted code and agree to license it under MIT and Apache-2.0. - -## Submission Requirements - -- 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 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. -- Write-up covering: protocol design for each chain, LEZ escrow design, cross-chain atomicity argument, timelock handling, security assumptions, known limitations, and integration instructions. -- **FURPS self-assessment** as part of the solution (see [solution template](../solutions/LP-0000.md)). - -## Evaluation Process - -Submissions are evaluated first-come-first-served against the success criteria. The first submission that satisfies 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 - -### General -- [eth-lez-atomic-swaps](https://github.com/logos-blockchain/eth-lez-atomic-swaps) — ETH–LEZ HTLC-based swap (reference implementation and LEZ program structure) -- [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/) -- [Risc0 proving system](https://dev.risczero.com/) - -### Bitcoin -- [BIP-340: Schnorr signatures for secp256k1](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) -- [BIP-341: Taproot](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) -- [Adaptor signatures — Lloyd Fournier](https://github.com/LLFourn/one-time-vrf/blob/master/main.pdf) -- [Scriptless Scripts — Andrew Poelstra](https://github.com/apoelstra/scriptless-scripts) -- [rust-bitcoin](https://github.com/rust-bitcoin/rust-bitcoin) -- [secp256k1-zkp (adaptor sig support)](https://github.com/BlockstreamResearch/secp256k1-zkp) - -### Monero -- [Bitcoin–Monero Cross-chain Atomic Swap — h4sh3d paper](https://eprint.iacr.org/2020/1126.pdf) -- [comit-network/xmr-btc-swap](https://github.com/comit-network/xmr-btc-swap) — production Monero-Bitcoin implementation -- [comit-network/cross-curve-dleq](https://github.com/comit-network/cross-curve-dleq) — cross-group DLEQ proof library (secp256k1 ↔ Ed25519) -- [Monero-Starknet atomic swap PoC](https://github.com/omarespejel/monero-starknet-atomic-swap) — adapting the protocol to a non-Bitcoin chain -- [curve25519-dalek](https://github.com/dalek-cryptography/curve25519-dalek) -- [secp256kFUN!](https://github.com/LLFourn/secp256kfun) - -## Potential for Subsequent λ Prizes - -- **Testnet 0.3 compatibility**: If LEZ testnet 0.3 introduces breaking changes, a follow-up prize may be opened to update the atomic swap implementation for compatibility. -- **Mainnet deployment**: A subsequent prize may target mainnet deployment of the atomic swap application, with adoption-related success criteria (e.g., volume, number of unique users, liquidity thresholds). From 4d9a72048d35527ab86cfbf64606364df81eec1f Mon Sep 17 00:00:00 2001 From: mart1n <20109376+mart1n-xyz@users.noreply.github.com> Date: Thu, 25 Jun 2026 09:39:12 +0200 Subject: [PATCH 12/28] add links --- README.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index d529efd..446b3f6 100644 --- a/README.md +++ b/README.md @@ -31,15 +31,15 @@ All prizes live in the `[prizes/](prizes/)` directory. Each prize is a markdown | [LP-0004](prizes/LP-0004.md) | Sealed-Bid Auction Using Shielded Balances | Large | Draft | | [LP-0005](prizes/LP-0005.md) | Private Token Balance Attestation | Large | Open | | [LP-0008](prizes/LP-0008.md) | Autonomous AI Module with Wallet, Storage, and Messaging | Large | Open | -| [LP-0009](prizes/LP-0009.md) | Keycard NIP-46 Nostr Signer Proxy | Small | Closed | -| [LP-0010](prizes/LP-0010.md) | Shell dApp Integration Proof of Concept | Small | Closed | +| [LP-0009](prizes/LP-0009.md) | Keycard NIP-46 Nostr Signer Proxy | Small | Closed ([Solution](solutions/LP-0009.md)) | +| [LP-0010](prizes/LP-0010.md) | Shell dApp Integration Proof of Concept | Small | Closed ([Solution](solutions/LP-0010.md)) | | [LP-0011](prizes/LP-0011.md) | Program development tooling: Rust SDK | Medium | Draft | -| [LP-0012](prizes/LP-0012.md) | Event/Log mechanism | Large | Closed | -| [LP-0013](prizes/LP-0013.md) | Token program improvements (authorities) | Medium | Open | -| [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 | Closed | -| [LP-0016](prizes/LP-0016.md) | Anonymous Forum with Threshold Moderation | Large | Open | -| [LP-0017](prizes/LP-0017.md) | Whistleblower: document upload and indexing Basecamp app | Medium | Open | +| [LP-0012](prizes/LP-0012.md) | Event/Log mechanism | Large | Closed ([Solution](solutions/LP-0012.md)) | +| [LP-0013](prizes/LP-0013.md) | Token program improvements (authorities) | Medium | Open | +| [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 | Closed | +| [LP-0016](prizes/LP-0016.md) | Anonymous Forum with Threshold Moderation | Large | Open | +| [LP-0017](prizes/LP-0017.md) | Whistleblower: document upload and indexing Basecamp app | Medium | Open | ### Proposing a New Prize From 9810ae0f1b8f583faa86b7b4e08d3ebcbc9e2a9a Mon Sep 17 00:00:00 2001 From: bristinWild <bristin@mysocialmotion.org> Date: Thu, 25 Jun 2026 22:24:51 +0530 Subject: [PATCH 13/28] =?UTF-8?q?fix(lp-0013):=20update=20solution=20doc?= =?UTF-8?q?=20=E2=80=94=20lez-programs=20impl,=20new=20video,=20CU=20costs?= =?UTF-8?q?,=20all=20criteria=20met?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- solutions/LP-0013.md | 135 +++++++++++++++++++++++-------------------- 1 file changed, 73 insertions(+), 62 deletions(-) diff --git a/solutions/LP-0013.md b/solutions/LP-0013.md index 67e1d4f..924a98d 100644 --- a/solutions/LP-0013.md +++ b/solutions/LP-0013.md @@ -7,114 +7,125 @@ This submission implements a complete mint authority model for the LEZ Token program. Fungible tokens can now be created with a designated mint authority that can mint additional supply, rotate control to a new key, or permanently revoke minting to fix the supply. A standalone `lez-authority` crate provides the reusable authority primitive as defined in RFP-001. ## Demo Video -Link - https://www.youtube.com/watch?v=fJWbhobNIFM + +Link - https://www.youtube.com/watch?v=Q_uAv7xRD-c ## Repository -- **Repo:** https://github.com/bristinWild/logos-execution-zone -- **Branch:** `main` -- **Commit:** `da61c4fb` +- **Repo:** https://github.com/logos-blockchain/lez-programs (PR: https://github.com/logos-blockchain/lez-programs/pull/125) +- **Fork:** https://github.com/bristinWild/lez-programs +- **Branch:** `solution/lp-0013-authorities` +- **Commit:** `c2d259e` - **Key files:** - - `lez-authority/src/lib.rs` — agnostic `AuthoritySlot` library (RFP-001) - - `programs/token/core/src/lib.rs` — `TokenDefinition::Fungible` with `mint_authority` field, `SetAuthority` and `NewFungibleDefinitionWithAuthority` instructions - - `programs/token/src/mint.rs` — authority-gated `Mint` handler + - `lez-authority/src/lib.rs` — `Authority` type + `Ownable` trait (RFP-001) + - `programs/token/core/src/lib.rs` — `TokenDefinition::Fungible` with `authority: Authority` field + - `programs/token/src/mint.rs` — authority-gated `Mint` handler (self/external authority) - `programs/token/src/set_authority.rs` — `SetAuthority` handler (rotation + revocation) - - `programs/token/src/new_definition.rs` — `NewFungibleDefinitionWithAuthority` handler - - `program_methods/guest/src/bin/token.rs` — guest binary dispatch for all new instructions - - `wallet/src/program_facades/token.rs` — `send_set_authority`, `send_new_definition_with_authority` SDK methods - - `integration_tests/tests/token.rs` — 2 integration tests for authority lifecycle + - `programs/token/src/new_definition.rs` — `NewFungibleDefinition` with `mint_authority: Option<AccountId>` + - `programs/token/methods/guest/src/bin/token.rs` — guest binary dispatch for all instructions + - `programs/integration_tests/tests/token.rs` — 17 integration tests including full rotation flow - `scripts/demo-full-flow.sh` — end-to-end demo script - `scripts/examples/fixed_supply_token.sh` — fixed supply example - `scripts/examples/variable_supply_token.sh` — variable supply + rotation example - - `docs/LP-0013-README.md` — architecture, usage, and design docs + - `docs/LP-0013-README.md` — architecture, CU costs, CLI usage, design docs + - `artifacts/token-idl.json` — regenerated IDL via SPEL framework ## Approach ### Authority Model -`mint_authority: Option<[u8; 32]>` is added to `TokenDefinition::Fungible`: -- `Some(key)` — the key holder controls minting and can rotate/revoke -- `None` — supply is permanently fixed; minting is rejected deterministically +`authority: Authority` is embedded directly in `TokenDefinition::Fungible` via the `lez-authority` crate: +- `Authority(Some(key))` — the key holder controls minting and can rotate/revoke +- `Authority(None)` — supply is permanently fixed; minting is rejected deterministically ### `lez-authority` Crate (RFP-001) -A standalone crate with zero dependency on any specific program or `nssa_core`. Provides `AuthoritySlot` with `check()`, `set()` (rotate/revoke), and `is_revoked()`. All logic is unit-tested independently. +A standalone crate with zero dependency on any specific program or `nssa_core`. Provides: +- `Authority(Option<[u8; 32]>)` newtype with `authority()`, `require()`, `rotate()` +- `Ownable` trait with `require_owner`, `transfer_ownership`, `renounce_ownership` -### New Instructions +All logic is unit-tested independently (8 tests). + +### Instructions | Instruction | Description | |---|---| -| `NewFungibleDefinitionWithAuthority` | Create token with mint authority from day one | -| `Mint` (updated) | Now authority-gated — rejects if `mint_authority` is `None` | -| `SetAuthority` | Rotate to new key or revoke permanently (pass `None`) | +| `NewFungibleDefinition` | Create token with optional mint authority (`mint_authority: Option<AccountId>`) | +| `Mint` (updated) | Authority-gated — self-authority (empty rest accounts) or external rotated authority (rest account) | +| `SetAuthority` | Rotate to new key (`Some(key)`) or revoke permanently (`None`) | + +### Authority Transfer (RFP-001) + +The `Mint` and `SetAuthority` instructions support both self/PDA authority and external rotated authority passed as a rest account. After rotation, the new key can actually mint — proven by the `token_rotate_authority_then_new_authority_can_mint` integration test. ### Atomicity -`SetAuthority` only mutates `mint_authority` after all authorization checks pass. An unauthorized call returns an error before any write occurs — the prior authority is preserved. This is enforced structurally in `AuthoritySlot::set()`. - -### SDK / Module - -`wallet/src/program_facades/token.rs` exposes `send_set_authority` and `send_new_definition_with_authority` — typed async methods following the same pattern as all existing token facade methods. +`SetAuthority` only mutates `authority` after all authorization checks pass. Unauthorized calls return before any write — prior authority is preserved. Structural guarantee via `Authority::rotate()`. ## Success Criteria Checklist -- [x] **Variable-size tokens via mint authority** — `NewFungibleDefinitionWithAuthority` sets authority at init; `Mint` checks it -- [x] **Minting by the authority** — `Mint` handler validates `definition_account.is_authorized` + `mint_authority.is_some()` +- [x] **Variable-size tokens via mint authority** — `NewFungibleDefinition` sets authority at init; `Mint` checks it +- [x] **Minting by the authority** — self-authority and external rotated-authority paths both supported and tested - [x] **Authority rotation and revocation** — `SetAuthority` with `Some(new_key)` rotates; with `None` revokes permanently - [x] **Two example integrations** — `scripts/examples/fixed_supply_token.sh` and `scripts/examples/variable_supply_token.sh` - [x] **Self-sufficient agnostic authority library (RFP-001)** — `lez-authority` crate, zero deps on token program or nssa -- [x] **SDK/module** — `wallet/src/program_facades/token.rs` typed facade methods -- [x] **IDL** — token program uses `serde`-based instruction encoding (existing LEZ pattern); SPEL IDL generation available via `lgs spel -- generate-idl` -- [x] **Atomicity** — structural guarantee in `AuthoritySlot::set()`, verified by unit tests -- [x] **Deterministic rejection** — `"Mint authority has been revoked; this token has a fixed supply"` on every revoked-authority mint attempt -- [x] **CI green** — all 7 CI steps pass including `lez-authority` (7 tests) and `token_program` (42 tests) -- [x] **Integration tests** — 2 tests in `integration_tests/tests/token.rs` against live sequencer +- [x] **SDK/module** — SPEL IDL + CLI integration; guest binary wired for all instructions +- [x] **IDL** — `artifacts/token-idl.json` regenerated via SPEL framework +- [x] **Atomicity** — structural guarantee in `Authority::rotate()`, verified by unit tests +- [x] **Deterministic rejection** — `"Mint authority check failed: Revoked"` on every revoked-authority mint attempt +- [x] **CU costs** — measured from LEZ sequencer execution logs on localnet: + `NewFungibleDefinition` ~11ms, `Mint` ~10ms, `SetAuthority` ~8ms (execution time + inside zkVM, measured via sequencer logs with `RISC0_DEV_MODE=1`; this reflects + actual program execution cost independent of proof generation). Full ZK proof + generation takes 3–10 minutes per tx with `RISC0_DEV_MODE=0` on Apple M-series + hardware. LEZ devnet/testnet deployment pending public sequencer availability. +- [x] **Integration tests** — 17 tests in `programs/integration_tests/tests/token.rs` against live sequencer (standalone mode), including full RFP-001 rotation flow +- [x] **CI green** — 60 unit tests + 17 integration tests passing - [x] **README** — `docs/LP-0013-README.md` with deployment steps, CLI instructions, architecture, error codes -- [x] **Demo script** — `scripts/demo-full-flow.sh` -- [ ] **CU costs** — TBD after devnet deployment -- [ ] **Recorded video demo** — TBD +- [x] **Demo script** — `scripts/demo-full-flow.sh` — reproducible against local LEZ sequencer with `RISC0_DEV_MODE=0` +- [x] **Recorded video demo** — https://www.youtube.com/watch?v=Q_uAv7xRD-c (narrated, `RISC0_DEV_MODE=0` terminal output visible) ## FURPS Self-Assessment ### Functionality -- `NewFungibleDefinitionWithAuthority`: creates fungible token with `mint_authority: Some(key)` -- `Mint`: checks `mint_authority.is_some()` before minting; deterministically panics if `None` -- `SetAuthority`: rotates to `Some(new_key)` or revokes to `None`; `is_authorized` check on definition account enforces caller identity -- Existing `NewFungibleDefinition` creates tokens with `mint_authority: None` (fixed supply by default — backward compatible) -- All existing 34 token tests continue to pass unchanged +- `NewFungibleDefinition`: creates fungible token with `mint_authority: Option<AccountId>` — `Some` = mintable, `None` = fixed supply +- `Mint`: self-authority (definition account is its own authority) or external rotated authority (rest account) +- `SetAuthority`: rotates to `Some(new_key)` or revokes to `None`; authorization check enforces caller identity +- Metadata fungibles carry a real `mint_authority` — intentional and tested +- AMM LP token authority correctly wired to pool PDA — all AMM tests pass unchanged ### Usability -- Single new field on `TokenDefinition::Fungible` — minimal diff, easy to audit -- `lez-authority` crate is importable by any LEZ program without token program dependency -- Wallet facade methods follow existing async pattern exactly -- `docs/LP-0013-README.md` documents all flows with CLI examples +- Single embedded `authority: Authority` field — minimal diff, easy to audit +- `lez-authority` importable by any LEZ program without token program dependency +- `artifacts/token-idl.json` enables full SPEL CLI interaction +- `docs/LP-0013-README.md` documents all flows with CLI examples and CU costs ### Reliability -- Atomicity: `AuthoritySlot::set()` returns `Err` before mutating — no partial writes possible -- 8 dedicated authority unit tests cover: mint success, mint with wrong authority, mint after revocation, rotation, revocation permanence, double-revoke, unauthorized rotation, state-unchanged-on-error -- All 42 `token_program` tests pass; all 7 `lez-authority` tests pass +- Atomicity: `Authority::rotate()` returns `Err` before mutating — no partial writes possible +- 13 dedicated authority unit tests cover all lifecycle cases +- 17 integration tests including full rotation flow at executor level +- All 60 unit tests + 17 integration tests pass ### Performance -- Authority check in `Mint`: single `Option` match — negligible CU overhead -- `SetAuthority`: single account read + write — same CU profile as existing `Burn` -- CU costs will be documented after devnet deployment +- Authority check in `Mint`: single `Option` match — negligible overhead +- `SetAuthority`: single account read + write +- CU costs (LEZ localnet, `RISC0_DEV_MODE=1`): `NewFungibleDefinition` ~11ms, `Mint` ~10ms, `SetAuthority` ~8ms ### Supportability -- CI updated with dedicated LP-0013 test steps — green on every push -- `scripts/demo-full-flow.sh` reproducible against local sequencer +- Demo script reproducible against local sequencer with `RISC0_DEV_MODE=0` - `docs/LP-0013-README.md` documents deployment, CLI usage, architecture, error codes -- Rebased onto upstream HEAD (4079b0c9) — fully current with LEZ codebase +- PR #125 on `logos-blockchain/lez-programs` — rebased onto upstream main ## Supporting Materials -- **Architecture docs:** [`docs/LP-0013-README.md`](https://github.com/bristinWild/logos-execution-zone/blob/main/docs/LP-0013-README.md) -- **Authority library:** [`lez-authority/src/lib.rs`](https://github.com/bristinWild/logos-execution-zone/blob/main/lez-authority/src/lib.rs) -- **SetAuthority handler:** [`programs/token/src/set_authority.rs`](https://github.com/bristinWild/logos-execution-zone/blob/main/programs/token/src/set_authority.rs) -- **Mint handler (updated):** [`programs/token/src/mint.rs`](https://github.com/bristinWild/logos-execution-zone/blob/main/programs/token/src/mint.rs) -- **Token core (updated):** [`programs/token/core/src/lib.rs`](https://github.com/bristinWild/logos-execution-zone/blob/main/programs/token/core/src/lib.rs) -- **Demo script:** [`scripts/demo-full-flow.sh`](https://github.com/bristinWild/logos-execution-zone/blob/main/scripts/demo-full-flow.sh) -- **Example scripts:** [`scripts/examples/`](https://github.com/bristinWild/logos-execution-zone/tree/main/scripts/examples) -- **CI:** https://github.com/bristinWild/logos-execution-zone/actions +- **PR:** https://github.com/logos-blockchain/lez-programs/pull/125 +- **Architecture docs:** `docs/LP-0013-README.md` +- **Authority library:** `lez-authority/src/lib.rs` +- **SetAuthority handler:** `programs/token/src/set_authority.rs` +- **Mint handler:** `programs/token/src/mint.rs` +- **Demo script:** `scripts/demo-full-flow.sh` +- **Example scripts:** `scripts/examples/` +- **Demo video:** https://www.youtube.com/watch?v=Q_uAv7xRD-c ## Terms & Conditions From 2a75aa4a8d9e61bd5a9575a63e1643f47d22e016 Mon Sep 17 00:00:00 2001 From: bristinWild <bristin@mysocialmotion.org> Date: Fri, 26 Jun 2026 03:22:18 +0530 Subject: [PATCH 14/28] fix(validator): point repo URL to bristinWild fork for validator checks --- solutions/LP-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/solutions/LP-0013.md b/solutions/LP-0013.md index 924a98d..0921894 100644 --- a/solutions/LP-0013.md +++ b/solutions/LP-0013.md @@ -12,7 +12,7 @@ Link - https://www.youtube.com/watch?v=Q_uAv7xRD-c ## Repository -- **Repo:** https://github.com/logos-blockchain/lez-programs (PR: https://github.com/logos-blockchain/lez-programs/pull/125) +- **Repo:** https://github.com/bristinWild/lez-programs (PR: https://github.com/logos-blockchain/lez-programs/pull/125) - **Fork:** https://github.com/bristinWild/lez-programs - **Branch:** `solution/lp-0013-authorities` - **Commit:** `c2d259e` From 95c6c53efcd8aca7bbf8b48f0850a8e79779a0f7 Mon Sep 17 00:00:00 2001 From: bristinWild <bristin@mysocialmotion.org> Date: Fri, 26 Jun 2026 03:57:28 +0530 Subject: [PATCH 15/28] trigger validator re-run after fixing default branch From e519f68ba0a7f69902fc0556f9ab94048ff02e99 Mon Sep 17 00:00:00 2001 From: alameen <alaminabubakarshehu5@gmail.com> Date: Wed, 1 Jul 2026 22:07:21 +0100 Subject: [PATCH 16/28] =?UTF-8?q?Solution:=20LP-0017=20=E2=80=94=20Whistle?= =?UTF-8?q?blower?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- solutions/LP-0017.md | 203 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 203 insertions(+) create mode 100644 solutions/LP-0017.md diff --git a/solutions/LP-0017.md b/solutions/LP-0017.md new file mode 100644 index 0000000..a1db7d5 --- /dev/null +++ b/solutions/LP-0017.md @@ -0,0 +1,203 @@ +# Solution: LP-0017 — Whistleblower: censorship-resistant document upload and indexing + +**Submitted by:** aegonmyy + +## Summary + +Whistleblower is a complete censorship-resistant document publishing pipeline on +the Logos stack, delivered as **two Logos Basecamp modules** plus a +**permissionless batch-anchor daemon**. A user picks a file; the app uploads it to +**Logos Storage** (obtaining a CID), broadcasts a metadata envelope over **Logos +Delivery** so the document is immediately discoverable, and can optionally anchor +the CID on-chain. Long-term anchoring is decoupled from publication: a standalone +CLI lets any altruistic third party gather broadcast CIDs and commit up to 50 per +transaction to a **LEZ SPEL registry program** — no coordination with the original +publisher, and the anchorer can be an anonymous `Private/` account so the index is +public while the publisher's identity is not. The upload → broadcast → anchor logic +is extracted into a reusable `logos-chronicle` module with a documented API. + +## Repository + +- **Repo:** https://github.com/aegonmyy/logoz +- **Branch / commit:** `main` @ `69bba7b` +- **v0.2.0 port branch:** [`port/v0.2.0`](https://github.com/aegonmyy/logoz/tree/port/v0.2.0) +- **Key paths:** + - `logos-chronicle/` — reusable Logos module: upload, broadcast, anchor, publish pipeline (the extracted document-indexing module) + - `logos-whistleblower/` — Logos Basecamp view plugin: QML desktop UI (file picker, publish status, history, anchor config) + - `chronicle-registry/` — SPEL registry program (`chronicle_registry_core` shared types, `methods/guest` RISC0 guest, `ffi/` C-ABI shim, `idl/` IDL) + - `batch-anchor/` — permissionless Waku-listener → dedup → batch-anchor CLI/daemon + - `scripts/demo.sh` — reproducible end-to-end demo against a real local sequencer at `RISC0_DEV_MODE=0` + - `scripts/bench-cu.sh` — CU benchmark harness (fresh-registry, dev-mode-off) + - `.github/workflows/ci.yml` — CI (fmt / build+test / publish smoke / on-chain anchor e2e) + +## Approach + +### Pipeline & module extraction + +The core `upload → broadcast → anchor` logic lives in **`logos-chronicle`**, a +self-contained Logos module with a documented JSON API (`uploadFileJson`, +`uploadStatusJson`, `publishFileJson`, broadcast + anchor calls). The Whistleblower +Basecamp app (`logos-whistleblower`) is a thin QML view plugin on top of it, so any +other Logos app can reuse the pipeline without depending on the Whistleblower UI — +which is exactly what the prize's "standalone document-indexing module" asks for. + +### On-chain registry — LEZ SPEL program (chosen approach) + +We chose a **LEZ program via the SPEL framework** over direct zone-SDK consensus +inscription. Justification: the zone SDK path currently requires a single +designated actor to perform consensus inscription (decentralised zone sequencers +are not yet shipped), which reintroduces a trust bottleneck — the exact +centralisation Whistleblower exists to avoid. A LEZ program keeps anchoring +permissionless and verifiable by anyone. The registry stores +`(cid, metadata_hash, anchor_timestamp, anchored_by, version)` per document, is +queryable by CID, and `index_batch` accepts up to **50 CIDs per transaction** +(`MAX_BATCH = 50`, ≥ the required 10). An IDL is provided. + +### Privacy-preserving anchoring + +Because the anchorer can be a `Private/` account, the `index_batch` transaction +routes through the LEZ proving path and the on-chain `anchored_by` is an anonymous +key — the document index stays publicly verifiable while the whistleblower's +identity is not revealed. + +### Metadata hash & envelope + +`metadata_hash = v1:<sha-256-hex>` over alphabetically-sorted canonical JSON of the +envelope fields, stored on-chain and embedded in every Waku envelope +(`v`, `cid`, `title`, `description`, `content_type`, `size_bytes`, `timestamp`, +`tags`, `metadata_hash`) on topic `/chronicle/1/document-index/json`, so any node +can verify document integrity without fetching from Storage. + +### Why the Logos stack + +Whistleblower needs exactly what a centralised alternative cannot provide: +**Logos Storage** stores bytes durably without identifying the uploader; **Logos +Delivery** propagates the CID peer-to-peer so a document is findable the instant +it is published, with no index server to seize or block; and **LEZ** provides +trustless, permissionless on-chain anchoring with first-class private state so +anchoring never doxxes the publisher. On a centralised host, any one of the host, +the index, or the payment rail is a single point of censorship — the whole reason +the app exists. + +### What was tried and did not work (documented as upstream issues) + +- `spel program-id` requires a pre-built R0BF `ProgramBinary`, not a raw ELF, and + the format is undocumented — worked around with `tools/mk_program_binary.rs` + ([spel#240](https://github.com/logos-co/spel/issues/240)). +- `lgs localnet start` hardcodes a pre-reorg LEZ config path and cannot start a + sequencer for recent `lez` pins; `scripts/demo.sh` applies a config-path bridge + automatically ([scaffold#230](https://github.com/logos-co/scaffold/issues/230)). +- Funding a fresh localnet account (`auth-transfer init` → + `ClaimedUnauthorizedAccount` for non-genesis accounts) is undocumented + ([scaffold#232](https://github.com/logos-co/scaffold/issues/232)). +- Also filed: [spel#241](https://github.com/logos-co/spel/issues/241), + [scaffold#231](https://github.com/logos-co/scaffold/issues/231). + +## Success Criteria Checklist + +### Functionality + +- [x] **Upload** — app uploads a selected file to Logos Storage and obtains a CID (`logos-chronicle` → Codex). Verified by `nix run .#smoke-storage`. +- [x] **Broadcast** — a metadata envelope (`cid`, `title`, `description`, `content_type`, `size_bytes`, `timestamp`, `tags`, plus `metadata_hash`) is published to `/chronicle/1/document-index/json` immediately after upload. Verified by `nix run .#smoke-broadcast`. +- [x] **On-chain anchoring** — an explicit "anchor on-chain" action distinct from the basic upload flow, invocable at any time after upload. +- [x] **Batch anchor tool** — `batch-anchor` subscribes to the Delivery topic, accumulates `(CID, metadata_hash)` tuples, submits them in a single batch tx, is permissionless (no publisher coordination), and is idempotent (re-submitting an already-registered CID does not fail). +- [x] **On-chain registry** — LEZ SPEL program (approach chosen + justified above); stores `(cid, metadata_hash, anchor_timestamp)` (plus `anchored_by`, `version`), queryable by CID, accepts batches up to 50 CIDs/tx. +- [x] **Document-indexing module** — `logos-chronicle`, self-contained with a documented API, reusable independently of the Whistleblower app. + +### Usability + +- [x] **Basecamp GUI** — `logos-whistleblower` QML app with local build instructions and a prebuilt `.lgx` asset, loadable in Logos Basecamp. +- [x] **Module as library/SDK** — `logos-chronicle` shipped with a README covering its API and integration steps. +- [x] **IDL for the LEZ program** — provided (SPEL framework). + +### Reliability + +- [x] **Upload retries** on transient Storage failures with exponential back-off, surfacing a clear error after exhausting retries. +- [x] **Broadcast dedup** — re-broadcasting the same CID does not create duplicate entries for subscribers (dedup by `(CID, metadata_hash)`). +- [x] **Batch-anchor resume** — on start the tool catches up from the Waku store and skips already-registered CIDs, so it resumes after a network interruption without re-processing. Publish and anchor ledgers persist across daemon restarts (verified by `nix run .#smoke-publish`). + +### Performance + +- [x] **CU benchmarks** measured on a real local rc5 sequencer at `RISC0_DEV_MODE=0` (full Groth16), fresh registry per batch via `scripts/bench-cu.sh`: + + | Operation | Batch size | CU (R0VM cycles) | + |-----------|-----------|------------------| + | `init_registry` | — | 414 | + | `index_batch` | 1 CID | 2,816 | + | `index_batch` | 50 CIDs (`MAX_BATCH`) | 213,348 | + +### Supportability + +- [x] **Registry deployed & tested on LEZ testnet** — deployed and exercised on the public **rc5** testnet (`https://testnet.lez.logos.co`, LEZ pin `27360cb7`) with a live privacy-preserving `index_batch` (tx `f14e39c9…`). See "Testnet note" below: rc5 was wiped for Testnet v0.2.0 during the submission window; the program ID is reproducible from the repo (`make build`) and a clean v0.2.0 port is provided on `port/v0.2.0`. +- [x] **E2E integration tests in CI** — upload → broadcast → batch anchor run against a LEZ sequencer in standalone mode in CI (`publish` + `anchor` jobs). +- [x] **CI green on default branch** — `main` CI run for `69bba7b` completed successfully (fmt, build+test, publish smoke, on-chain anchor e2e). +- [x] **README** — covers build steps, deployment addresses, running the Basecamp app, running the batch anchor tool, and querying the registry. +- [x] **Reproducible demo at `RISC0_DEV_MODE=0`** — `scripts/demo.sh` runs the full pipeline against a real local sequencer with real Groth16 proofs; verified end-to-end on a clean run. +- [x] **Narrated video demo** showing terminal output incl. proof generation at `RISC0_DEV_MODE=0` — https://youtu.be/e0rzVVsw-w4 + +> **Testnet note (honest scope).** The on-chain evidence above was captured live on +> the **rc5** testnet, which was **wiped and replaced by Testnet v0.2.0** during +> this submission window, so those specific records are no longer queryable on the +> current network. The application code ports to v0.2.0 cleanly (`port/v0.2.0`: bump +> the LEZ pin + five `Program::new(x.into())` call-sites; both CLI and guest build +> clean). Re-anchoring on v0.2.0 is currently **blocked upstream, not in this +> repo**: released `lgs` tooling does not yet support v0.2.0's on-disk layout +> ([scaffold#230](https://github.com/logos-co/scaffold/issues/230)). This is the +> situation the prize's "Potential for Subsequent λ Prizes" section anticipates; +> the submission is scoped to the rc5 testnet it was verified against, with the +> v0.2.0 port ready for when the tooling lands. + +## FURPS Self-Assessment + +### Functionality +Full upload → broadcast → anchor pipeline; explicit optional on-chain anchor; +permissionless idempotent batch-anchor CLI (dedup, Waku store catch-up, resume); +LEZ SPEL registry (`init_registry`, `index_batch` up to 50 CIDs/tx) queryable by +CID; privacy-preserving anchoring via `Private/` anchorer; reusable +`logos-chronicle` module. Enforced limits: 100 MB max file size, envelope size +cap, source filename never reaches Storage (title-derived staging). + +### Usability +QML Basecamp app with file picker, publish status, history, and anchor-config +dialog; prebuilt `.lgx` plus local build instructions. `logos-chronicle` exposes a +small JSON API and ships as a reusable module with a README. IDL provided for the +SPEL program. `scripts/setup.sh` one-shot bootstrap and `scripts/run-app.sh` launch. + +### Reliability +Exponential-backoff upload retries with a clear terminal error; broadcast dedup by +`(CID, metadata_hash)`; batch-anchor catches up from the Waku store and skips +already-registered CIDs on restart; publish and anchor ledgers persist across +daemon restarts (verified by a restart assertion in `smoke-publish`). 16/16 +batch-anchor unit tests pass. + +### Performance +`init_registry` = 414 CU; `index_batch` n=1 = 2,816 CU; n=50 = 213,348 CU +(fresh registry, `RISC0_DEV_MODE=0`). CU is the guest execution-cycle delta logged +at execution time, independent of dev-mode. Because the guest borsh-serialises the +whole registry per call, per-call CU grows with stored entries — documented, with a +fresh-registry harness (`bench-cu.sh`) to isolate the batch cost. + +### Reliability / Supportability +CI runs four jobs (fmt; build + 16 tests; `publish` smoke against a live nwaku +node; `anchor` on-chain `index_batch` e2e against a local sequencer) and is green +on `main`. `RISC0_DEV_MODE=0` real-proof runs are shown via `scripts/demo.sh` +locally and in the demo video (dev-mode is used only on the hosted CI runner for +speed; CU is identical either way). Four isolated smoke tests +(`storage`/`broadcast`/`publish`/`anchor`) cover each pipeline stage. Codebase is +split into independently testable crates/modules; five upstream issues filed for +tooling gaps encountered. + +## Supporting Materials + +- **Narrated demo video (RISC0_DEV_MODE=0):** https://youtu.be/e0rzVVsw-w4 +- **Reproducible demo script:** [`scripts/demo.sh`](https://github.com/aegonmyy/logoz/blob/main/scripts/demo.sh) +- **CU benchmark harness:** [`scripts/bench-cu.sh`](https://github.com/aegonmyy/logoz/blob/main/scripts/bench-cu.sh) +- **Reusable module:** [`logos-chronicle/`](https://github.com/aegonmyy/logoz/tree/main/logos-chronicle) +- **Batch anchor CLI:** [`batch-anchor/`](https://github.com/aegonmyy/logoz/tree/main/batch-anchor) +- **SPEL registry program + IDL:** [`chronicle-registry/`](https://github.com/aegonmyy/logoz/tree/main/chronicle-registry) +- **v0.2.0 port branch:** [`port/v0.2.0`](https://github.com/aegonmyy/logoz/tree/port/v0.2.0) +- **Upstream issues filed:** spel [#240](https://github.com/logos-co/spel/issues/240) · [#241](https://github.com/logos-co/spel/issues/241) · scaffold [#230](https://github.com/logos-co/scaffold/issues/230) · [#231](https://github.com/logos-co/scaffold/issues/231) · [#232](https://github.com/logos-co/scaffold/issues/232) + +## Terms & Conditions + +By submitting this solution, I confirm that I have read and agree to the [Terms & Conditions](../TERMS.md). From 59d212c750b1541b0e0fab27d2c66df1caa532e3 Mon Sep 17 00:00:00 2001 From: alameen <alaminabubakarshehu5@gmail.com> Date: Thu, 2 Jul 2026 01:22:40 +0100 Subject: [PATCH 17/28] docs(LP-0017): bump repo pin to d35981c (IDL rename for validator) --- solutions/LP-0017.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/solutions/LP-0017.md b/solutions/LP-0017.md index a1db7d5..efd035f 100644 --- a/solutions/LP-0017.md +++ b/solutions/LP-0017.md @@ -19,7 +19,7 @@ is extracted into a reusable `logos-chronicle` module with a documented API. ## Repository - **Repo:** https://github.com/aegonmyy/logoz -- **Branch / commit:** `main` @ `69bba7b` +- **Branch / commit:** `main` @ `d35981c` - **v0.2.0 port branch:** [`port/v0.2.0`](https://github.com/aegonmyy/logoz/tree/port/v0.2.0) - **Key paths:** - `logos-chronicle/` — reusable Logos module: upload, broadcast, anchor, publish pipeline (the extracted document-indexing module) @@ -130,7 +130,7 @@ the app exists. - [x] **Registry deployed & tested on LEZ testnet** — deployed and exercised on the public **rc5** testnet (`https://testnet.lez.logos.co`, LEZ pin `27360cb7`) with a live privacy-preserving `index_batch` (tx `f14e39c9…`). See "Testnet note" below: rc5 was wiped for Testnet v0.2.0 during the submission window; the program ID is reproducible from the repo (`make build`) and a clean v0.2.0 port is provided on `port/v0.2.0`. - [x] **E2E integration tests in CI** — upload → broadcast → batch anchor run against a LEZ sequencer in standalone mode in CI (`publish` + `anchor` jobs). -- [x] **CI green on default branch** — `main` CI run for `69bba7b` completed successfully (fmt, build+test, publish smoke, on-chain anchor e2e). +- [x] **CI green on default branch** — `main` CI run for `d35981c` completed successfully (fmt, build+test, publish smoke, on-chain anchor e2e). - [x] **README** — covers build steps, deployment addresses, running the Basecamp app, running the batch anchor tool, and querying the registry. - [x] **Reproducible demo at `RISC0_DEV_MODE=0`** — `scripts/demo.sh` runs the full pipeline against a real local sequencer with real Groth16 proofs; verified end-to-end on a clean run. - [x] **Narrated video demo** showing terminal output incl. proof generation at `RISC0_DEV_MODE=0` — https://youtu.be/e0rzVVsw-w4 From 74601b73bc850487cce5fe2c055bb01d58adfe8d Mon Sep 17 00:00:00 2001 From: alameen <alaminabubakarshehu5@gmail.com> Date: Thu, 2 Jul 2026 06:20:30 +0100 Subject: [PATCH 18/28] docs(LP-0017): bump pin to 365273d; registry re-deployed + re-anchored on live v0.2.0 testnet --- solutions/LP-0017.md | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/solutions/LP-0017.md b/solutions/LP-0017.md index efd035f..aa4e1fb 100644 --- a/solutions/LP-0017.md +++ b/solutions/LP-0017.md @@ -19,7 +19,7 @@ is extracted into a reusable `logos-chronicle` module with a documented API. ## Repository - **Repo:** https://github.com/aegonmyy/logoz -- **Branch / commit:** `main` @ `d35981c` +- **Branch / commit:** `main` @ `365273d` - **v0.2.0 port branch:** [`port/v0.2.0`](https://github.com/aegonmyy/logoz/tree/port/v0.2.0) - **Key paths:** - `logos-chronicle/` — reusable Logos module: upload, broadcast, anchor, publish pipeline (the extracted document-indexing module) @@ -128,24 +128,25 @@ the app exists. ### Supportability -- [x] **Registry deployed & tested on LEZ testnet** — deployed and exercised on the public **rc5** testnet (`https://testnet.lez.logos.co`, LEZ pin `27360cb7`) with a live privacy-preserving `index_batch` (tx `f14e39c9…`). See "Testnet note" below: rc5 was wiped for Testnet v0.2.0 during the submission window; the program ID is reproducible from the repo (`make build`) and a clean v0.2.0 port is provided on `port/v0.2.0`. +- [x] **Registry deployed & tested on LEZ testnet** — deployed and exercised end-to-end on the live **Testnet v0.2.0** (`https://testnet.lez.logos.co`, LEZ `v0.2.0` / commit `a58fbce2`) at `RISC0_DEV_MODE=0`: program `96ad78fe…`, registry PDA `HvCtoPL6…` (reproducing the documented IDs exactly), a CID anchored via a **real Groth16 proof** (`index_batch` tx `02d8781403…`, confirmed on-chain and independently verified via `wallet chain-info transaction`), and `lookup` confirms it (a bogus CID is not-registered). Full evidence + reproduction steps: [`docs/testnet-v020-live-evidence-20260702.md`](https://github.com/aegonmyy/logoz/blob/main/docs/testnet-v020-live-evidence-20260702.md). - [x] **E2E integration tests in CI** — upload → broadcast → batch anchor run against a LEZ sequencer in standalone mode in CI (`publish` + `anchor` jobs). -- [x] **CI green on default branch** — `main` CI run for `d35981c` completed successfully (fmt, build+test, publish smoke, on-chain anchor e2e). +- [x] **CI green on default branch** — `main` CI completed successfully on the code baseline (fmt, build+test, publish smoke, on-chain anchor e2e); `365273d` changes only docs (README + testnet evidence), no code or workflow files. - [x] **README** — covers build steps, deployment addresses, running the Basecamp app, running the batch anchor tool, and querying the registry. - [x] **Reproducible demo at `RISC0_DEV_MODE=0`** — `scripts/demo.sh` runs the full pipeline against a real local sequencer with real Groth16 proofs; verified end-to-end on a clean run. - [x] **Narrated video demo** showing terminal output incl. proof generation at `RISC0_DEV_MODE=0` — https://youtu.be/e0rzVVsw-w4 -> **Testnet note (honest scope).** The on-chain evidence above was captured live on -> the **rc5** testnet, which was **wiped and replaced by Testnet v0.2.0** during -> this submission window, so those specific records are no longer queryable on the -> current network. The application code ports to v0.2.0 cleanly (`port/v0.2.0`: bump -> the LEZ pin + five `Program::new(x.into())` call-sites; both CLI and guest build -> clean). Re-anchoring on v0.2.0 is currently **blocked upstream, not in this -> repo**: released `lgs` tooling does not yet support v0.2.0's on-disk layout -> ([scaffold#230](https://github.com/logos-co/scaffold/issues/230)). This is the -> situation the prize's "Potential for Subsequent λ Prizes" section anticipates; -> the submission is scoped to the rc5 testnet it was verified against, with the -> v0.2.0 port ready for when the tooling lands. +> **Testnet note.** On-chain evidence was originally captured on the **rc5** testnet, +> which was wiped and replaced by **Testnet v0.2.0** mid-submission. The hosted +> testnet is **now live again at the `v0.2.0` tag**, and the registry has been +> **re-deployed and re-anchored there** (see the Supportability evidence above): the +> program ID `96ad78fe…` and PDA `HvCtoPL6…` reproduce the documented values exactly, +> and a CID was anchored with a real Groth16 proof (`index_batch` tx `02d8781403…`, +> confirmed on-chain). This was done by talking to the hosted sequencer directly with +> a `v0.2.0`-final wallet plus the `batch-anchor` CLI — the released `lgs` *localnet* +> tooling still lags v0.2.0's on-disk layout ([scaffold#230](https://github.com/logos-co/scaffold/issues/230)), but that only affects local bring-up, not testnet +> interaction. The earlier rc5 records (tx `f14e39c9…`) are no longer queryable on the +> current network but are retained as the original run record; the program is +> reproducible from source (`make build`), and a clean code port is on `port/v0.2.0`. ## FURPS Self-Assessment From 67b50f9321c84889b8e872c821ade09ab4150722 Mon Sep 17 00:00:00 2001 From: alameen <alaminabubakarshehu5@gmail.com> Date: Thu, 2 Jul 2026 10:08:08 +0100 Subject: [PATCH 19/28] LP-0017: swap silent screencast for narrated demo video (JY-joCR_2ag) --- solutions/LP-0017.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/solutions/LP-0017.md b/solutions/LP-0017.md index aa4e1fb..5b25cbc 100644 --- a/solutions/LP-0017.md +++ b/solutions/LP-0017.md @@ -133,7 +133,7 @@ the app exists. - [x] **CI green on default branch** — `main` CI completed successfully on the code baseline (fmt, build+test, publish smoke, on-chain anchor e2e); `365273d` changes only docs (README + testnet evidence), no code or workflow files. - [x] **README** — covers build steps, deployment addresses, running the Basecamp app, running the batch anchor tool, and querying the registry. - [x] **Reproducible demo at `RISC0_DEV_MODE=0`** — `scripts/demo.sh` runs the full pipeline against a real local sequencer with real Groth16 proofs; verified end-to-end on a clean run. -- [x] **Narrated video demo** showing terminal output incl. proof generation at `RISC0_DEV_MODE=0` — https://youtu.be/e0rzVVsw-w4 +- [x] **Narrated video demo** showing terminal output incl. proof generation at `RISC0_DEV_MODE=0` — https://youtu.be/JY-joCR_2ag > **Testnet note.** On-chain evidence was originally captured on the **rc5** testnet, > which was wiped and replaced by **Testnet v0.2.0** mid-submission. The hosted @@ -190,7 +190,7 @@ tooling gaps encountered. ## Supporting Materials -- **Narrated demo video (RISC0_DEV_MODE=0):** https://youtu.be/e0rzVVsw-w4 +- **Narrated demo video (RISC0_DEV_MODE=0):** https://youtu.be/JY-joCR_2ag - **Reproducible demo script:** [`scripts/demo.sh`](https://github.com/aegonmyy/logoz/blob/main/scripts/demo.sh) - **CU benchmark harness:** [`scripts/bench-cu.sh`](https://github.com/aegonmyy/logoz/blob/main/scripts/bench-cu.sh) - **Reusable module:** [`logos-chronicle/`](https://github.com/aegonmyy/logoz/tree/main/logos-chronicle) From 038b6d8f8249636120d84021d65fc5d2436b289a Mon Sep 17 00:00:00 2001 From: Sasha <oleksandr@status.im> Date: Fri, 17 Jul 2026 00:35:02 +0200 Subject: [PATCH 20/28] chore: add video clause to terms --- TERMS.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/TERMS.md b/TERMS.md index 9133ee6..b6ab8b2 100644 --- a/TERMS.md +++ b/TERMS.md @@ -1,6 +1,6 @@ # Logos Lambda Prize Program – Terms & Conditions -*Last updated: 2 March 2026* +*Last updated: 17 July 2026* These Terms and Conditions ("Terms") are entered into by and between Logos Collective Association, Baarerstrasse 10, 6300 Zug, Switzerland ("Logos", "we", "us") and any individual or legal entity participating in the λ Prize Program, including by submitting any solution or pull request ("Submission") to the λ Prize GitHub repository ("you", "Participant") (each a "Party" and together the "Parties"). @@ -70,8 +70,9 @@ A valid Submission must satisfy all of Logos' requirements set out in the releva 1. source code hosted in a public repository; 2. a working demo or deployable artefact; -3. adequate technical documentation and any other specified documentation indicated; and -4. any other requirements indicated by Logos. +3. a recorded demo or walkthrough video of the Submission; +4. adequate technical documentation and any other specified documentation indicated; and +5. any other requirements indicated by Logos. Logos reserves the right to not review any incomplete or partial Submissions or Submissions which do not meet all mandatory requirements in the applicable Prize specification. @@ -93,6 +94,8 @@ Subject to the licences granted below, Participants retain ownership of the inte By making a Submission, Participants grant Logos and its Affiliates a worldwide, perpetual, irrevocable, non‑exclusive, royalty‑free licence (with the right to sublicense) to use, reproduce, display, perform, distribute, adapt, modify, and create derivative works from Participant's Submission and related materials for purposes connected with the Program, the Logos technology stack, and the broader Logos ecosystem, including without limitation for testing, evaluation, promotion, documentation, and demonstration. +Submissions include videos and related audiovisual materials. By making a Submission, Participants grant Logos and its Affiliates the right to use, reproduce, display, perform, distribute, and publish those materials, including on Logos' and its Affiliates' websites, social media channels, and other promotional channels, for purposes connected with the Program and the broader Logos ecosystem. Participants warrant that they have all rights necessary to grant this permission, including in respect of any likeness, voice, or third‑party content appearing in such materials. + ## 7. Evaluation and judging ### 7.1 Eligibility for evaluation From bebb487d3d3cece31878727c79d9392455ca763c Mon Sep 17 00:00:00 2001 From: mart1n <20109376+mart1n-xyz@users.noreply.github.com> Date: Fri, 17 Jul 2026 13:41:28 +0200 Subject: [PATCH 21/28] lp13 update --- README.md | 2 +- prizes/LP-0013.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 446b3f6..923f3cf 100644 --- a/README.md +++ b/README.md @@ -35,7 +35,7 @@ All prizes live in the `[prizes/](prizes/)` directory. Each prize is a markdown | [LP-0010](prizes/LP-0010.md) | Shell dApp Integration Proof of Concept | Small | Closed ([Solution](solutions/LP-0010.md)) | | [LP-0011](prizes/LP-0011.md) | Program development tooling: Rust SDK | Medium | Draft | | [LP-0012](prizes/LP-0012.md) | Event/Log mechanism | Large | Closed ([Solution](solutions/LP-0012.md)) | -| [LP-0013](prizes/LP-0013.md) | Token program improvements (authorities) | Medium | Open | +| [LP-0013](prizes/LP-0013.md) | Token program improvements (authorities) | Medium | Closed ([Solution](solutions/LP-0013.md)) | | [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 | Closed | | [LP-0016](prizes/LP-0016.md) | Anonymous Forum with Threshold Moderation | Large | Open | diff --git a/prizes/LP-0013.md b/prizes/LP-0013.md index 37c180e..8f975e7 100644 --- a/prizes/LP-0013.md +++ b/prizes/LP-0013.md @@ -5,7 +5,7 @@ dependencies: mint authority approval pattern must reuse, per Success Criteria. --- -# LP-0013: Token program improvements: authorities [OPEN] +# LP-0013: Token program improvements: authorities [CLOSED] **`Logos Circle: N/A`** ## Overview From 045e5412cf53218dc12c7576dd54375e547e3f67 Mon Sep 17 00:00:00 2001 From: Sasha <118575614+weboko@users.noreply.github.com> Date: Sun, 19 Jul 2026 23:31:57 +0200 Subject: [PATCH 22/28] Update LP-0016 status to Closed with solution link --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 923f3cf..c51664f 100644 --- a/README.md +++ b/README.md @@ -38,7 +38,7 @@ All prizes live in the `[prizes/](prizes/)` directory. Each prize is a markdown | [LP-0013](prizes/LP-0013.md) | Token program improvements (authorities) | Medium | Closed ([Solution](solutions/LP-0013.md)) | | [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 | Closed | -| [LP-0016](prizes/LP-0016.md) | Anonymous Forum with Threshold Moderation | Large | Open | +| [LP-0016](prizes/LP-0016.md) | Anonymous Forum with Threshold Moderation | Large | Closed ([Solution](solutions/LP-0016.md)) | | [LP-0017](prizes/LP-0017.md) | Whistleblower: document upload and indexing Basecamp app | Medium | Open | ### Proposing a New Prize From fa2fb7b41cb23ec898e5ffffbc00bfca0829df32 Mon Sep 17 00:00:00 2001 From: Sasha <118575614+weboko@users.noreply.github.com> Date: Sun, 19 Jul 2026 23:34:12 +0200 Subject: [PATCH 23/28] Update licensing terms for participant submissions Clarified licensing terms for submissions, including audiovisual materials and publication rights. --- TERMS.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/TERMS.md b/TERMS.md index b6ab8b2..0ce01ff 100644 --- a/TERMS.md +++ b/TERMS.md @@ -92,9 +92,7 @@ Subject to the licences granted below, Participants retain ownership of the inte ### 6.2 Licence to Logos -By making a Submission, Participants grant Logos and its Affiliates a worldwide, perpetual, irrevocable, non‑exclusive, royalty‑free licence (with the right to sublicense) to use, reproduce, display, perform, distribute, adapt, modify, and create derivative works from Participant's Submission and related materials for purposes connected with the Program, the Logos technology stack, and the broader Logos ecosystem, including without limitation for testing, evaluation, promotion, documentation, and demonstration. - -Submissions include videos and related audiovisual materials. By making a Submission, Participants grant Logos and its Affiliates the right to use, reproduce, display, perform, distribute, and publish those materials, including on Logos' and its Affiliates' websites, social media channels, and other promotional channels, for purposes connected with the Program and the broader Logos ecosystem. Participants warrant that they have all rights necessary to grant this permission, including in respect of any likeness, voice, or third‑party content appearing in such materials. +By making a Submission, Participants grant Logos and its Affiliates a worldwide, perpetual, irrevocable, non‑exclusive, royalty‑free licence (with the right to sublicense) to use, reproduce, display, perform, distribute, adapt, modify, and create derivative works from Participant's Submission and related materials (including any video and audiovisual materials) for purposes connected with the Program, the Logos technology stack, and the broader Logos ecosystem, including without limitation for testing, evaluation, promotion, documentation, demonstration and as the case may be, publishing on any of Logos' or Affiliates' websites, social media profiles or other public channels. ## 7. Evaluation and judging From 888d482fb881ae38a5408aac2a69575995a70d3b Mon Sep 17 00:00:00 2001 From: mart1n <20109376+mart1n-xyz@users.noreply.github.com> Date: Wed, 22 Jul 2026 09:39:17 +0200 Subject: [PATCH 24/28] sync status --- prizes/LP-0016.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/prizes/LP-0016.md b/prizes/LP-0016.md index 78249a5..b840472 100644 --- a/prizes/LP-0016.md +++ b/prizes/LP-0016.md @@ -2,9 +2,9 @@ dependencies: [] --- -# LP-0016: Anonymous Forum with Threshold Moderation and Membership Revocation [OPEN] +# LP-0016: Anonymous Forum with Threshold Moderation and Membership Revocation [CLOSED] -**`Status: Open`** +**`Status: Closed`** **`Logos Circle: N/A`** ## Overview From c2522c7443950088e68296290f816c824a8de9de Mon Sep 17 00:00:00 2001 From: Sasha <118575614+weboko@users.noreply.github.com> Date: Wed, 22 Jul 2026 12:18:40 +0200 Subject: [PATCH 25/28] Update LP-0017 status to Closed in README --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index c51664f..ce7e995 100644 --- a/README.md +++ b/README.md @@ -39,7 +39,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 | Closed | | [LP-0016](prizes/LP-0016.md) | Anonymous Forum with Threshold Moderation | Large | Closed ([Solution](solutions/LP-0016.md)) | -| [LP-0017](prizes/LP-0017.md) | Whistleblower: document upload and indexing Basecamp app | Medium | Open | +| [LP-0017](prizes/LP-0017.md) | Whistleblower: document upload and indexing Basecamp app | Medium | Closed ([Solution](solutions/LP-0017.md) | ### Proposing a New Prize From ee52707d6eac8d52530d3f658c13b5e4370cd0d7 Mon Sep 17 00:00:00 2001 From: Sasha <118575614+weboko@users.noreply.github.com> Date: Wed, 22 Jul 2026 12:20:01 +0200 Subject: [PATCH 26/28] Change status of LP-0017 to 'Closed' Updated the status of LP-0017 from 'Open' to 'Closed'. --- prizes/LP-0017.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/prizes/LP-0017.md b/prizes/LP-0017.md index d1fd873..e4f1eee 100644 --- a/prizes/LP-0017.md +++ b/prizes/LP-0017.md @@ -2,9 +2,9 @@ dependencies: [] --- -# LP-0017: Whistleblower — censorship-resistant document upload and indexing Basecamp app [OPEN] +# LP-0017: Whistleblower — censorship-resistant document upload and indexing Basecamp app [CLOSED] -**`Status: Open`** +**`Status: Closed`** **`Logos Circle: N/A`** ## Overview From 75a1474bcd44141cabb49a03addff337625f32bb Mon Sep 17 00:00:00 2001 From: mart1n <20109376+mart1n-xyz@users.noreply.github.com> Date: Wed, 22 Jul 2026 12:43:16 +0200 Subject: [PATCH 27/28] minor fix --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index ce7e995..aca4cf3 100644 --- a/README.md +++ b/README.md @@ -39,7 +39,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 | Closed | | [LP-0016](prizes/LP-0016.md) | Anonymous Forum with Threshold Moderation | Large | Closed ([Solution](solutions/LP-0016.md)) | -| [LP-0017](prizes/LP-0017.md) | Whistleblower: document upload and indexing Basecamp app | Medium | Closed ([Solution](solutions/LP-0017.md) | +| [LP-0017](prizes/LP-0017.md) | Whistleblower: document upload and indexing Basecamp app | Medium | Closed ([Solution](solutions/LP-0017.md)) | ### Proposing a New Prize From 6227b861e1347bb078b497db5e777ae94ca70d53 Mon Sep 17 00:00:00 2001 From: weboko <118575614+weboko@users.noreply.github.com> Date: Fri, 31 Jul 2026 19:09:33 +0000 Subject: [PATCH 28/28] ci: fetch submission files instead of checking out the fork actions/checkout v4.4.0 refuses to check out fork PR code from a pull_request_target workflow, so every submission PR from a fork now dies at the checkout step and the validator never runs. Rather than opt back in with allow-unsafe-pr-checkout, drop the fork checkout entirely. The validator reads exactly one thing from the PR -- the submission markdown -- so those blobs are fetched by path from the contents API instead. The fork's working tree never lands on the runner, which removes the pwn-request exposure the guard exists for rather than declaring it acceptable, and leaves nothing to re-audit when this job grows a build or lint step later. Also: - Read the prize spec from base/ rather than the PR. It is repo-owned, so the base branch's copy is authoritative; the fork's is a stale snapshot from whenever it branched, which also made the closed/draft check read outdated status. - persist-credentials: false on the base checkout. Nothing here pushes. - Bound the submitter-supplied external clone and the one full-content scan of it with timeouts, no submodules, and no auth prompts. --- .github/scripts/validate-submission.sh | 22 ++++++++++--- .github/workflows/validate-submission.yml | 38 +++++++++++++++++------ 2 files changed, 46 insertions(+), 14 deletions(-) diff --git a/.github/scripts/validate-submission.sh b/.github/scripts/validate-submission.sh index a744fa6..aeb128b 100755 --- a/.github/scripts/validate-submission.sh +++ b/.github/scripts/validate-submission.sh @@ -4,8 +4,11 @@ # # Runtime contract (from validate-submission.yml): # - Runs on ubuntu-latest (GNU grep / sed / coreutils assumed). -# - `base/` contains the trusted base-branch checkout. -# - `pr/` contains the PR-head checkout, treated as untrusted data only. +# - `base/` contains the trusted base-branch checkout, and is the only +# source for repo-owned files such as the prize specs. +# - `pr/solutions/` contains just the submission markdown the PR changed, +# fetched by path from the API and treated as untrusted data only. The +# fork's working tree is never checked out. # - Env: PR_TITLE, PR_REPO, BASE_REPO, CHANGED_FILES. set -euo pipefail @@ -230,7 +233,9 @@ if $IS_SOLUTION; then # ------------------------------------------------------------------------- # 3h. Prize exists and is open # ------------------------------------------------------------------------- - PRIZE_FILE="pr/prizes/${PRIZE_ID}.md" + # Read from base/: the prize spec is repo-owned, so the authoritative copy + # is the base branch's, not whatever stale revision the fork branched from. + PRIZE_FILE="base/prizes/${PRIZE_ID}.md" if [[ ! -f "$PRIZE_FILE" ]]; then err "Prize \`${PRIZE_ID}\` not found in \`prizes/\`. Check the ID." else @@ -261,7 +266,12 @@ if $IS_SOLUTION; then CLONE_DIR="/tmp/submission-repo" rm -rf "$CLONE_DIR" - if git clone --depth=1 "$REPO_URL" "$CLONE_DIR" 2>/dev/null; then + # `REPO_URL` is submitter-controlled, so the clone is bounded: no auth + # prompts, no submodules, one shallow branch, and a wall-clock ceiling so + # an oversized or slow repo cannot consume the whole job. + if GIT_TERMINAL_PROMPT=0 timeout "${LP_CLONE_TIMEOUT:-300}" \ + git clone --depth=1 --single-branch --no-tags \ + --no-recurse-submodules "$REPO_URL" "$CLONE_DIR" 2>/dev/null; then # 4a. AI workspace artifacts in the external repo AI_ARTIFACTS=() @@ -336,7 +346,9 @@ if $IS_SOLUTION; then # Logos Messaging / Waku integration if echo "$PRIZE_CONTENT" | grep -qi 'Logos Messaging\|Logos Chat\|Waku'; then - waku_ref=$(grep -ril 'waku\|logos.messaging\|logos.chat' "$CLONE_DIR" \ + # Time-bounded: this is the one full-content scan of the clone. + waku_ref=$(timeout "${LP_SCAN_TIMEOUT:-60}" \ + grep -ril 'waku\|logos.messaging\|logos.chat' "$CLONE_DIR" \ --include='*.rs' --include='*.go' --include='*.ts' --include='*.js' \ --include='*.toml' --include='*.json' 2>/dev/null | head -1 || true) if [[ -z "$waku_ref" ]]; then diff --git a/.github/workflows/validate-submission.yml b/.github/workflows/validate-submission.yml index 5c93604..6633dda 100644 --- a/.github/workflows/validate-submission.yml +++ b/.github/workflows/validate-submission.yml @@ -2,8 +2,8 @@ name: Validate Submission # `pull_request_target` is used so the workflow can comment on PRs from forks # (which is how solutions are submitted). It runs on the base branch with -# write perms; the PR-head checkout is treated as untrusted data only and -# never executed. +# write perms, so the fork's tree is never checked out here: the only +# submission content the validator reads is fetched by path as data. on: pull_request_target: types: [opened, synchronize, reopened, edited] @@ -26,13 +26,8 @@ jobs: with: ref: ${{ github.event.pull_request.base.sha }} path: base - - - name: Checkout PR head (untrusted data, never executed) - uses: actions/checkout@v4 - with: - ref: ${{ github.event.pull_request.head.sha }} - repository: ${{ github.event.pull_request.head.repo.full_name }} - path: pr + # Nothing in this job pushes, so the token has no reason to sit in + # base/.git/config for the life of the run. persist-credentials: false - name: Get changed files @@ -52,6 +47,31 @@ jobs: echo "__LP_EOF__" } >> "$GITHUB_OUTPUT" + - name: Fetch changed solution files (untrusted data, never executed) + env: + GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} + REPO: ${{ github.repository }} + HEAD_SHA: ${{ github.event.pull_request.head.sha }} + CHANGED_FILES: ${{ steps.changed.outputs.files }} + run: | + # The validator reads exactly one thing from the PR: the submission + # markdown. Fetching those blobs by path keeps the fork's working + # tree off the runner entirely, so there is nothing here to execute + # and no `allow-unsafe-pr-checkout` opt-in to carry. Paths come from + # the PR files API and are constrained to a single markdown file + # directly under `solutions/`. + mkdir -p pr/solutions + solution_files=$(printf '%s\n' "$CHANGED_FILES" \ + | grep -E '^solutions/[A-Za-z0-9._-]+\.md$' || true) + # Unquoted on purpose: the pattern above admits no spaces or globs. + for f in $solution_files; do + if ! gh api -H "Accept: application/vnd.github.raw" \ + "/repos/${REPO}/contents/${f}?ref=${HEAD_SHA}" > "pr/${f}"; then + rm -f "pr/${f}" + echo "::warning::Could not fetch ${f} at ${HEAD_SHA}." + fi + done + - name: Run validation id: validate env: