Evidence Dossier
A compact proof package for judges: what the hackathon requires, what AidShield actually proves, where the deployed Stellar contracts live, how the attacks fail, and what is intentionally synthetic.
Requirement Match
This is the shortest way to show that the submission meets the stated Stellar Hacks: Real-World ZK rules.
Public source includes frontend, Soroban contracts, circuit, Merkle tooling, tests, README, threat model, and submission docs.
A valid Groth16 proof is required before the disbursement contract can release escrow or vendor voucher funds.
Proof verification and payout controls run through deployed Stellar testnet Soroban contracts.
Mission, Admin, Claim, Threats, Auditor, and Edge pages form a 2-3 minute working walkthrough.
Claims Judges Can Verify
Beneficiary proves membership in an approved Merkle root without publishing name, ID, list index, secret, or witness.
A wallet-bound nullifier is stored after first settlement, so replay attempts fail on-chain.
Credential and proof bind claimant address into the leaf and nullifier, blocking stolen credential use from another wallet.
The same private proof can pay an approved vendor, while vendor approval and replay controls remain public.
Auditors can inspect roots, contracts, escrow, claim count, vendor status, and nullifiers without seeing the private list.
The crisis mission uses synthetic actors, but points to real testnet contracts, proof assets, QR delivery, and replay controls.
Verification Anchors
The crisis-aid names and actors are synthetic demo labels. The deployed contracts, proof statement, escrow flow, QR credential mechanics, replay protection, and public audit surfaces are the real testnet work.
Red-Team Demo Matrix
The project is stronger when judges see failure paths, not only a happy path.
| Attempt | Expected Result | How To Show It |
|---|---|---|
| Replay same credential | Blocked by persistent nullifier | Show the second claim attempt failing after the first success. |
| Use another wallet | Blocked before proving and again by contract signer checks | Switch Freighter account and load the old credential. |
| Use expired credential | Blocked by ledger-time expiry check | Credential expiry is part of the public proof statement. |
| Use revoked issuer | Blocked by on-chain issuer registry | Threat page documents issuer compromise playbook. |
| Redeem to unapproved vendor | Blocked by vendor registry | Voucher mode only pays approved vendor addresses. |
| Pause during incident | Claims stop while pause is active | Threat dashboard makes emergency posture visible. |
Strongest 2-3 Minute Walkthrough
This sequence keeps the video focused on working product evidence.
Open Mission and state that actors are synthetic testnet labels.
Open Admin and issue or show an encrypted QR credential for the beneficiary wallet.
Open Claim, load/decrypt the credential, generate the browser Groth16 proof, and submit with Freighter.
Open Stellar Explorer from the receipt to show settlement against the deployed contract.
Retry the same credential to show replay failure.
Open Auditor and Evidence to show aggregate accountability and exact verification anchors.