diff --git a/prizes/LP-0003.md b/prizes/LP-0003.md
index 46564e5..26207b5 100644
--- a/prizes/LP-0003.md
+++ b/prizes/LP-0003.md
@@ -1,17 +1,23 @@
-# LP-0003: Private Allowlist / Airdrop Distributor
+# LP-0003: Private Allowlist / Airdrop Distributor (WIP)
 
 **`Logos Circle: N/A`**
 
+TODO: Not ready
 ## Overview
 
 Token airdrops and allowlist distributions today require recipients to expose their wallet address — and, by extension, their full on-chain history — at the moment of claim. The distributor must either publish the full eligibility list publicly or run a centralised gating service. Neither is acceptable for a privacy-first ecosystem.
 
-This prize funds a private airdrop and allowlist primitive for LEZ: a contract where the distributor commits to a hidden set of eligible addresses, recipients can claim without revealing they were on the list, and no on-chain observer can link a claim to a specific eligible address.
+This prize funds a private airdrop and allowlist primitive for LEZ: a contract where the distributor commits to a hidden set of eligible accounts, recipients can claim without revealing they were on the list, and no on-chain observer can link a claim to a specific eligible address.
 
 ## Motivation
 
 Airdrops are a primary token distribution mechanism for new protocols. Allowlists gate access to launches, NFT mints, and governance participation. In both cases the current pattern — publish a Merkle root, let users submit inclusion proofs — reveals eligibility and links pseudonymous identities to participation. For a community built around freedom and censorship-resistance, this creates real risks: eligible addresses can be targeted, excluded, or front-run.
 
+**Privacy trade-offs of the Merkle approach**: The standard Merkle airdrop pattern has two important limitations that any submission must acknowledge and address:
+
+1. **The distributor knows all recipients upfront.** To construct the Merkle tree, the token minter or distributor must possess the full list of eligible account IDs at setup time. This is an inherent assumption of the approach — it is not a flaw, but it must be documented clearly.
+2. **Claiming reveals the claimer's account ID.** Submitting a Merkle inclusion proof on-chain exposes which account is claiming, potentially breaking the anonymity of that account's broader on-chain history. One mitigation: recipients use a single-use account ID for the claim, then redirect the allocation to a separate private account. Submissions must document this trade-off and, where possible, provide a claim flow that preserves recipient anonymity through such indirection.
+
 Logos' shielded account model enables a better primitive: one where the eligibility set is committed on-chain but the mapping from claims to identities remains private. A competitive prize is the right mechanism because the design space — commitment scheme, nullifier construction, recipient UX, and integration with shielded token transfers — admits multiple valid approaches.
 
 ## Success Criteria
@@ -19,7 +25,7 @@ Logos' shielded account model enables a better primitive: one where the eligibil
 - [ ] A distributor can commit to an eligibility set on-chain without revealing individual addresses.
 - [ ] An eligible recipient can claim their allocation without revealing which address in the set they hold.
 - [ ] A recipient cannot claim more than once (double-claim prevention via nullifiers or equivalent).
-- [ ] An on-chain observer cannot link a completed claim to any specific address in the eligibility set.
+- [ ] An on-chain observer cannot link a completed claim to any specific address in the eligibility set. If the chosen approach (e.g. Merkle inclusion proof) inherently reveals the claimer's account ID, the submission must provide and document a privacy-preserving claim flow — for example, claiming from a single-use account and redirecting the allocation to a separate private account.
 - [ ] 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.
@@ -57,7 +63,7 @@ Open to any individual or team. Submissions must be original work. Teams must ho
 - Public repository with all circuit code, LEZ program code, and client-side tooling under MIT or Apache-2.0.
 - Program deployed on LEZ testnet with a verified program ID.
 - End-to-end demo (video or live link) showing a private claim from a shielded account.
-- Write-up covering: commitment scheme, nullifier design, privacy guarantees and their limits, LEZ account model compatibility, security assumptions, known limitations, and integration instructions.
+- Write-up covering: commitment scheme, nullifier design, privacy guarantees and their limits (including explicit treatment of distributor knowledge assumptions and claim-time account ID exposure), LEZ account model compatibility, security assumptions, known limitations, and integration instructions.
 - Proof generation time and on-chain verification gas cost benchmarks.
 
 ## Evaluation Process