From 49bf92b3ea9bed2b562888bfca141ec6e911f147 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 26 Feb 2026 20:49:19 +1100 Subject: [PATCH] adoption criterias --- prizes/LP-0001.md | 1 + prizes/LP-0002.md | 1 + prizes/LP-0003.md | 1 + prizes/LP-0004.md | 1 + prizes/LP-0006.md | 1 + prizes/LP-0007.md | 1 + 6 files changed, 6 insertions(+) diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index bb6d0eb..1ccc894 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -20,6 +20,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. - [ ] Full documentation and a clean public repository are delivered. ## Scope diff --git a/prizes/LP-0002.md b/prizes/LP-0002.md index eb38ca6..6949920 100644 --- a/prizes/LP-0002.md +++ b/prizes/LP-0002.md @@ -24,6 +24,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. - [ ] Full documentation and a clean public repository are delivered. ## Scope diff --git a/prizes/LP-0003.md b/prizes/LP-0003.md index 9bce216..4dba086 100644 --- a/prizes/LP-0003.md +++ b/prizes/LP-0003.md @@ -22,6 +22,7 @@ Logos' shielded account model enables a better primitive: one where the eligibil - [ ] An on-chain observer cannot link a completed claim to any specific address in the eligibility set. - [ ] The distributor can verify post-distribution that the correct number of claims occurred, without learning who claimed. - [ ] 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. - [ ] Full documentation and a clean public repository are delivered. ## Scope diff --git a/prizes/LP-0004.md b/prizes/LP-0004.md index 11d7b4a..f01dc49 100644 --- a/prizes/LP-0004.md +++ b/prizes/LP-0004.md @@ -23,6 +23,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. - [ ] Full documentation and a clean public repository are delivered. ## Scope diff --git a/prizes/LP-0006.md b/prizes/LP-0006.md index a6bc1dd..8b8d339 100644 --- a/prizes/LP-0006.md +++ b/prizes/LP-0006.md @@ -35,6 +35,7 @@ The swap proceeds as follows (Alice holds BTC, Bob holds LEZ): - [ ] The LEZ escrow program correctly enforces release of funds upon proof of knowledge of the adaptor secret `t`, and supports refund after timelock expiry. Note: LEZ does not yet have on-chain block time, so the LEZ-side timelock is enforced client-side (the same approach used in [eth-lez-atomic-swaps](https://github.com/logos-blockchain/eth-lez-atomic-swaps)). - [ ] The two legs of the swap are atomic: either both complete or both refund. There is no state where one party receives funds and the other does not. - [ ] A reference integration is delivered: a working demo of a complete BTC↔LEZ swap on Bitcoin testnet and LEZ testnet. +- [ ] At least 5 complete BTC↔LEZ swaps are executed on Bitcoin testnet and LEZ testnet, involving at least 3 distinct counterparty pairs outside the submitting team. - [ ] Full documentation and a clean public repository are delivered. ## Scope diff --git a/prizes/LP-0007.md b/prizes/LP-0007.md index 720a123..3accee6 100644 --- a/prizes/LP-0007.md +++ b/prizes/LP-0007.md @@ -35,6 +35,7 @@ The swap proceeds as follows (Alice holds XMR, Bob holds LEZ): - [ ] The LEZ-side timelock refund is implemented. Note: LEZ does not yet have on-chain block time, so the LEZ-side timelock is enforced client-side (the same approach used in [eth-lez-atomic-swaps](https://github.com/logos-blockchain/eth-lez-atomic-swaps)). - [ ] The two legs of the swap are atomic: either both complete or both refund. There is no state in which one party receives funds and the other does not. - [ ] A reference integration is delivered: a working demo of a complete XMR↔LEZ swap on Monero stagenet and LEZ testnet. +- [ ] At least 5 complete XMR↔LEZ swaps are executed on Monero stagenet and LEZ testnet, involving at least 3 distinct counterparty pairs outside the submitting team. - [ ] Full documentation and a clean public repository are delivered. ## Scope