Live testnet contractsGroth16 · BLS12-381No PII on-chain

Private Aid Claims. Public Settlement Accountability.

ZK AidShield lets a beneficiary prove eligibility and claim once while Stellar releases aid from escrow without publishing their identity, private credential, or aid-list membership.

Proof size
384 bytes
Public inputs
6 field elements
Claim scope
1 payout per nullifier
Current capacity
256 slots per campaign

Architecture Flow

One path from private enrollment to public settlement.

End to end
01
Operator

Generates private campaign and keeps beneficiary list off-chain.

02
Merkle Root

Commits eligibility set to Soroban without exposing identities.

03
Credential

Wallet-bound secret, path, expiry, issuer key, and signature.

04
Browser Proof

Beneficiary generates Groth16 proof locally.

05
Soroban

Verifier, nullifier, expiry, issuer, and vendor checks run on-chain.

06
Settlement

Escrow pays beneficiary wallet or approved vendor.

Submission Demo Path

Follow this path to verify the product end to end in under three minutes.

1
Issue

Open Admin, issue a wallet-bound credential, set QR passphrase, and show encrypted QR.

2
Audit

Open the non-PII ledger: slot, wallet hash, credential hash, issuer key, delivery mode.

3
Claim

Open Claim, enter passphrase, import QR/payload, generate the browser Groth16 proof.

4
Settle

Approve Freighter, show Stellar transaction, claim receipt, then replay rejection.

What Is Real

Private eligibility

Beneficiary proves membership in an approved Merkle set without revealing name, ID, or list position.

Wallet-bound leaf

The leaf is Poseidon(secret, disbursement_id, claimant_address, expires_at, issuer_key_id), so stolen credentials cannot be reused from another wallet or extended past policy.

Replay resistance

Nullifier is Poseidon(secret, disbursement_id, claimant_address, 1) and is persisted on-chain after the first claim.

Real settlement

The contract transfers XLM from escrow through the Stellar Asset Contract after proof verification.

Voucher redemption

The same private proof can pay an approved vendor instead of the claimant wallet; the nullifier prevents spending both ways.

Why It Can Lead

  • End-to-end flow: operator issuance, local proof, wallet signature, Soroban verification, XLM payout.
  • Mobile QR credential delivery: field officers can issue an encrypted credential QR; beneficiaries decrypt it locally before the same signature and wallet checks run.
  • Restricted aid budgets: admins approve vendors on-chain, and beneficiaries can redeem privately authorized vouchers to those vendors.
  • Operational accountability: admin can export a non-PII issuance ledger with keyed wallet identifiers, credential hashes, issuer key, expiry, and delivery mode.
  • Beneficiary receipt: successful payout creates a local receipt with transaction hash, nullifier, amount, and campaign metadata.
  • Honest privacy boundary: eligibility data stays private, while payout wallet, timing, amount, and nullifier remain public settlement data.
  • Not only a demo circuit: deployed contracts, test coverage, audit page, stats page, and replay/wrong-wallet demos.
  • Stellar-native: uses Soroban and BLS12-381 pairing host functions instead of off-chain verification.

Privacy Boundary

The product is honest about what stays private and what remains public settlement data.

Threat-aware
Private / off-chain
names and IDs
beneficiary list membership
credential secret
Merkle path
local issuance records
Public / on-chain
Merkle root
nullifier
contract IDs
payout wallet
route
amount
timing
claim count
Direct cash

Proof pays the connected beneficiary wallet after Freighter signature.

Vendor voucher

The same proof can pay an approved vendor; the nullifier blocks using both routes.

Trust Boundary

The implementation separates credential delivery, local proof generation, and public settlement.

No overclaiming
Credential delivery

The issuer API reads the selected secret and Merkle witness server-side, then delivers them inside a signed credential to the beneficiary browser.

Local proving

During claim, the browser uses the credential to generate the proof; the secret and Merkle witness are not sent on-chain or to the verifier.

Public settlement

Stellar settlement remains visible: claimant wallet or approved vendor wallet, route, amount, timing, contract IDs, root, verifier key hash, and nullifier.

Verification Anchors

Disbursement contractCARYQO…5D3CZD
Groth16 verifierCAD7QR…DEJ2KG
Disbursement ID176bc0…d25922
Merkle root337334…d6d5ad
VK hashc243d169dcf3…77d4d128

Security Posture

Kept private

Names, IDs, beneficiary-list membership, credential secrets, Merkle witnesses, and local issuance records.

Public by design

Payout wallet, timing, amount, contract IDs, Merkle root, verifier key hash, and nullifier.

Abuse resistance

Operator APIs require an admin secret, issuer and vendor controls are enforced on-chain, ledger wallet identifiers use keyed HMACs, and replay is blocked on-chain.

Built vs Next

Built now
Groth16 BLS12-381 proof verified on Soroban
Real XLM escrow payout through Stellar SAC
Wallet-, expiry-, and issuer-bound credentials
Replay protection with persistent nullifiers
Encrypted QR credential delivery
Approved-vendor voucher redemption
Threshold governor controls for sensitive admin operations
Admin-protected local non-PII issuance ledger and export
Local beneficiary claim receipt
Admin-protected credential issuance and beneficiary-slot APIs
Admin, claim, stats, audit, and judge pages
Next after submission
01
Per-issuer operational limits

Cap issuance volume per field officer and alert on unusual credential activity.

02
Governor signing UX

Add a guided multi-party Soroban signing flow for threshold-2 operations in the browser.

03
Optional identity adapters

Use Human Passport or Self/OpenPassport during enrollment while keeping eligibility proofs private.

Run Claim DemoIssue CredentialOpen Auditor DashboardOpen AuditOpen Competitive EdgeOpen Mission DemoOpen Evidence DossierOpen Pilot Plan