Solution: LP-0003 Private Allowlist / Airdrop Distributor - #126
Open
edenbd1 wants to merge 1 commit into
Open
Conversation
✅ Validation passedA reviewer will assess against the prize criteria. Automated check. See solution template and TERMS. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A distributor commits an eligibility set on chain. An eligible recipient claims
their allocation without revealing which entry is theirs — not to observers, and
not to the distributor.
solutions/LP-0003.mdWhat is verified on chain
A claim travels on LEZ's privacy-preserving path, carrying a real STARK receipt
the sequencer checks against the node-pinned
PRIVACY_PRESERVING_CIRCUIT_ID.What lands is a single marker account whose address is
SHA256(prefix ‖ distribution_id ‖ nullifier), where the nullifier is derivedfrom the recipient's secret. An observer who knows every candidate address still
cannot compute the nullifier, so no marker maps back to a recipient.
Evidence, on the current public testnet
4a8dab271c2ac4f3b19c38b45e3f05fa4f413a0ac84a7b28030abebc8c5fdf5990f615d4045db10c2e42c44d15bf80f36a7a72e31df51e3bda6c46e4a22defe7d9236824835c9f6a986c3bc687c04e2c722ad0984009fb0a936767d3c584e13bThe two program hashes are
SHA256(borsh(bytecode))of the binaries committed inthe repository, so they can be recomputed without trusting this table.
./scripts/verify-onchain-claim.shruns five checks against the live chain,ending at "the marker PDA is owned by the verifier program" — which no
transaction lookup can fake.
The video shows a fresh claim being proved and submitted during the recording,
with
RISC0_DEV_MODE=0visible before any proving starts, and the same fivechecks passing against it afterwards.
Beyond the unit tests
docs/onchain-audit.mdrecords three adversarial demonstrations run against thelive deployed programs rather than against a local harness: a claim that does
not genuinely prove membership, one that redirects its allocation, and one that
replays a spent nullifier. All three are rejected on chain.
Against the criteria
29 tests, CI green, including a workflow that runs the whole lifecycle against a
real standalone LEZ sequencer with
RISC0_DEV_MODE=0. CU costs are measured perinstruction. The Basecamp module ships as a
.lgxwith darwin-arm64 andlinux-amd64 variants;
scripts/package-lgx.py --verifyrecomputes every manifesthash from the archive's own contents, and the video shows that check passing.
Happy to address anything in review.