Synthetic testnet missionFlood relief scenarioNo real PII

Crisis Aid Mission Demo

A judge-ready story for ZK AidShield: a flood-relief NGO issues an encrypted credential, an approved household claims privately, an approved medical vendor can receive voucher payment, replay fails, and donors audit aggregate settlement without seeing beneficiary identity.

Mission type
Flood relief
Actors
3 roles
Claim route
Cash or voucher
Truth status
Synthetic demo
Honesty Boundary

This mission uses synthetic beneficiaries, a simulated field officer, and a representative approved vendor. The proof system, Stellar testnet contracts, escrow accounting, QR credential flow, vendor controls, and replay rejection are real demo mechanics. The scenario is not a claim of a live NGO deployment.

Crisis Mission Impact Dashboard

Demo-facing impact numbers that keep the story concrete without claiming a real deployment.

Judge visible
Escrow funded
50 XLM
Payout size
1 XLM
Eligible slots
256
PII exposed
0
Claim routes
Cash + voucher
Replay design
Single-use nullifier
NGO operator

Relief coordinator

Issues encrypted QR credentials and manages issuer, vendor, pause, and escrow controls.

Privacy boundary: Beneficiary names, IDs, and eligibility list stay off-chain.
Beneficiary

Approved household wallet

Decrypts credential locally, generates a Groth16 proof, signs with Freighter, and claims once.

Privacy boundary: Secret and Merkle witness are used locally during claim; aid-list membership is not sent on-chain or to the verifier.
Approved vendor

Medical supply point

Receives voucher payout only if the beneficiary authorizes a valid private eligibility proof.

Privacy boundary: Vendor sees settlement, not the private eligibility witness or full beneficiary list.

Mission Flow

The full demo path from field issuance to donor accountability.

End to end
01
Create campaign

Operator commits the synthetic flood-relief eligibility set as a Merkle root on Soroban.

02
Issue QR credential

Field officer gives the beneficiary an encrypted QR credential bound to that wallet, expiry, issuer, and campaign.

03
Private claim

Beneficiary decrypts locally, generates a 384-byte Groth16 proof, and submits it with a Freighter signature.

04
Choose payout route

The same proof can release direct cash or pay an approved medical vendor; the nullifier prevents using both.

05
Replay fails

A second attempt with the same credential is blocked because the nullifier is already stored on-chain.

06
Donor audit

Auditors inspect escrow, claim count, vendor status, contract IDs, and nullifiers without seeing PII.

Real vs Synthetic

Real

Stellar testnet escrow, deployed Soroban contracts, Groth16 verifier, wallet-bound proof, nullifier replay block.

Real

Admin-protected credential issuance, encrypted QR payloads, approved vendor registry, non-PII issuance ledger.

Synthetic

Flood-relief campaign name, field officer, household, and vendor labels are demo personas for judging clarity.

Not claimed

No real NGO partnership, real beneficiary identity, or real-world aid distribution is represented by this demo.

Evidence Judges Can Verify

Eligibility privacy

No beneficiary name, ID, raw credential secret, or Merkle path is published on-chain.

Accountability

Campaign root, verifier, disbursement contract, escrow, claim count, and settlement hashes are public.

Threat resistance

Wrong wallet, replay, revoked issuer, unauthorized vendor, and emergency pause are demonstrable failure paths.

Field readiness

Encrypted QR delivery supports phone-first or paper handoff without changing the proof statement.

Contract Anchors

The mission story points at the same deployed testnet stack used by the rest of AidShield.

Open Edge BoardOpen Evidence
Disbursement contractCARYQO…5D3CZD
Groth16 verifierCAD7QR…DEJ2KG
Disbursement ID176bc0…d25922
Merkle root337334…d6d5ad
VK hashc243d169dcf3...77d4d128

Recording Beats

01

Open this Mission page and state that it is a synthetic testnet flood-relief scenario.

02

Open Admin and issue an encrypted QR credential to the beneficiary test wallet.

03

Open Claim, decrypt/load the credential, generate the proof, and choose cash or vendor voucher.

04

Approve Freighter and show the Stellar Explorer transaction.

05

Retry the same credential and show the replay rejection.

06

Open Auditor, Threats, and Edge to show aggregate accountability without beneficiary exposure.

Issue CredentialClaim PrivatelyShow Donor AuditShow Failed AttacksShow Evidence DossierJudge Mode