Private eligibility. Public Stellar settlement. No double claims.
This is the focused route for judging ZK AidShield. Follow the flow in order: escrow is funded, a wallet-bound credential is issued, the beneficiary proves eligibility privately, Stellar settles the payout, and credential reuse fails.
Live Anchors
What This Proves
The browser proof must verify before escrow releases XLM.
Name, ID, secret, and Merkle path never go on-chain.
Transaction, amount, contract, verifier, and nullifier are auditable.
The same credential cannot claim twice because the nullifier is already spent.
Open the donor portal, connect Freighter on Stellar testnet, and fund the campaign escrow.
Real XLM is available before any beneficiary claim is attempted.
Use the admin console to issue a wallet-bound beneficiary credential for a registered campaign slot.
Eligibility is represented as a signed private credential, not a public identity record.
Load the credential, generate the Groth16 proof in-browser, approve with Freighter, and settle on Stellar.
The ZK proof is load-bearing: without it, the escrow contract cannot pay.
Inspect the claim receipt: transaction hash, nullifier, amount, contract, verifier, and Merkle root.
Donors and auditors get public accountability without beneficiary PII.
Load the same credential again and attempt another claim.
The on-chain nullifier blocks replay and prevents double claiming.
Secondary Evidence
These pages stay available for deeper review, but the live demo should lead with the five-step console above.
Off-chain Circom proof, on-chain Soroban verification, XLM settlement.
Requirement map, contract anchors, video beats, and failure-path proof.
Trust boundaries, public settlement fields, and privacy limitations.
Escrow, paid claims, remaining capacity, and privacy counters.