Private aid eligibility.
Public settlement accountability.
ZK AidShield lets crisis-aid beneficiaries prove they are approved, claim once, and receive Stellar testnet aid without exposing their aid-list membership. Donors still get public escrow, settlement, nullifier, and aggregate audit evidence.
Judge Demo Console
The main review path is now one clean lifecycle: fund escrow, issue a wallet-bound credential, claim privately with a Groth16 proof, show the receipt, then prove credential reuse fails.
Show real Stellar testnet XLM available before the beneficiary claim.
Bind a private eligibility witness to the beneficiary wallet.
Generate the ZK proof locally and release XLM from escrow.
Retry the credential and show nullifier replay protection.
Why this is stronger than a normal ZK demo
The submission is packaged as a crisis-aid mission, but the winning claim is technical: private eligibility proof is directly connected to Stellar settlement and public donor accountability.
The proof gates settlement. Without a valid Groth16 proof, the disbursement contract cannot release funds.
Soroban verifies the proof path and releases XLM from escrow through the Stellar Asset Contract.
Aid-list membership, credential secrets, and witnesses stay private; payout wallet, timing, amount, and nullifier stay public for accountability.
Replay, wrong wallet, revoked issuer, unauthorized vendor, underfunded escrow, and emergency pause are visible failure paths.
Why traditional aid systems fail
Privacy breaches in humanitarian databases endanger the very people they serve.
- ✗Beneficiary names and IDs stored in databases that get leaked or seized
- ✗Aid workers can see who received what — enabling targeting in conflict zones
- ✗Duplicate claims go undetected across siloed systems
- ✗Proof of receipt requires revealing identity to a third party
- ✓Zero PII on-chain — no names, IDs, or biometrics ever stored
- ✓Cryptographic proof of eligibility without disclosing aid-list membership
- ✓One-time nullifier prevents any duplicate claim, on-chain forever
- ✓Wallet-bound proof: only the intended recipient can claim
How it works
Three steps. No identity revealed at any stage.
Coordinator commits
Aid coordinator generates unique secrets for each approved beneficiary and commits a Poseidon Merkle root to the Soroban contract. No names, IDs, or personal data ever touch the chain.
Beneficiary proves
Beneficiary loads their private claim file. A Groth16 BLS12-381 circuit runs in their browser via WASM — proving Merkle membership and computing a wallet-bound nullifier without sending the witness on-chain.
Stellar settles
The 384-byte Groth16 proof is verified on-chain with a native BLS12-381 pairing check. Nullifier is recorded permanently. XLM releases from escrow in the same transaction.
Privacy guarantees
Each guarantee is enforced cryptographically — not by policy or trust.
Technical architecture
End-to-end Groth16 BLS12-381 — the same elliptic curve used by Ethereum 2.0.
- ›Poseidon Merkle membership proof — depth 8, 256 slots
- ›Nullifier: Poseidon(secret, disburse_id, wallet, 1)
- ›Groth16 proof — 384 bytes, generated in browser via WASM
- ›Proving key: Groth16 VK initialized on Soroban
- ›Native BLS12-381 pairing_check — no off-chain verifier
- ›Persistent nullifier registry — replay attacks impossible
- ›Admin-controlled Merkle root — add beneficiaries without redeploy
- ›XLM SAC escrow — atomic proof + payout in one transaction
See a Groth16 proof land on Stellar
Run the judge console from escrow funding to credential issuance, private proof claim, public receipt, and replay rejection. The advanced pages stay available as evidence, but the live review path is intentionally focused.
Open Judge Console →