[Proposal setup] Proposal title

Please provide your proposal title

Proof 21 — Age Check for Commerce (Midnight Reference DApp)

[Proposal Summary] Time

Please specify how many months you expect your project to last

3

[Proposal Summary] Translation Information

Please indicate if your proposal has been auto-translated

No

Original Language

en

[Proposal Summary] Problem Statement

What is the problem you want to solve?

Merchents that need to confirm “21+” without collecting names, birthdays, or storing ID photos. Today they either skip checks or hold risky personal data. That slows checkout and increases liability.

[Proposal Summary] Project Dependencies

Does your project have any dependencies on other organizations, technical or otherwise?

Yes

Describe any dependencies or write 'No dependencies'

The only hard dependency is Midnight preprod + a supported wallet for proofs. Everything else is optional and has a documented fallback so milestones remain deliverable.

[Proposal Summary] Project Open Source

Will your project's outputs be fully open source?

Yes

Please provide here more information on the open source status of your project outputs

All code will be open under Apache-2.0 (free to use, modify, and ship, with a patent license). Our data schemas are public-domain (CC0) so others can adopt them. Docs can be reused with credit (CC BY). The name and logo remain protected.

[Theme Selection] Theme

Please choose the most relevant theme and tag related to the outcomes of your proposal

E-commerce

[Campaign Category] Category Questions

What is useful about your DApp within one of the specified industry or enterprise verticals?

What’s useful about this DApp (by industry)

Proof 21 solves a common pain in age-restricted commerce: prove “21+” without collecting or storing personal data. It gives retailers, e-commerce sites, delivery apps, and venues a fast, private, and auditable gate for sales—online and in-person.

Who benefits

• Retail (cannabis, alcohol, vape): quick counter checks, less PII risk, cleaner audits.
• E-commerce & delivery: remote age checks without running a full KYC stack.
• Events & venues: reusable “21+ pass” for door checks and bar service.
• Marketplaces & multi-brand groups: one simple verifier SDK across many sellers.

Why it’s useful

1) Compliance without holding PII

Most stores either save birthdays/ID photos (risky) or skip real checks (non-compliant). Proof 21 issues a private age pass on Midnight and verifies it with a yes/no proof. Merchants never store names, photos, or DOB—cutting legal, security, and insurance exposure.

2) Fast, repeatable checkout

Once a pass exists, returning customers prove “21+” at checkout (web or POS) in seconds. A short session token avoids multiple prompts during the same visit.

3) Works in-store, online—and with DIDs

We support three issuance paths, all verified by the same SDK:

• Merchant-as-Issuer (in person): staff checks a physical ID and creates a short-lived pass (e.g., 30–90 days) to the shopper’s wallet.
• KYC-as-Issuer (online): plug a vendor (e.g., Veriff/Onfido) for a longer-lived pass (e.g., 6–12 months).
• DID/VC-as-Issuer (future-friendly): accept a verifiable credential signed by a trusted issuer DID stating “age_over_21 = true.” The adapter can verify the VC directly or wrap it as a Midnight pass. An allow-list of issuer DIDs controls trust; credential expiry/revocation maps to pass expiry/revocation.

4) Auditable without doxxing

Optionally write a tiny Cardano receipt (metadata or micro-NFT) after a successful proof: “age check happened, time T, merchant M.” It’s public and non-PII—useful for internal QA, regulator talks, or third-party audits.

5) Low cost, predictable ops

• Issuance: one Midnight tx (and another if revoked).
• At purchase: no on-chain fee—proof is off-chain math.
• KYC costs: only if you choose a vendor for remote issuance; that’s pass-through. Longer expiries mean fewer checks.

Fit by vertical

Cannabis retail & delivery:

• must-have age checks at counter and online.
• Benefit: verify without storing IDs; protect staff/brand; receipts for QA/recalls.

Alcohol, vape, adult products:

• web cart gate + event door checks.
• Benefit: one kit for both channels; reusable passes; fewer false declines.

Events & venues:

• fast entry with a 24-hour event pass.
• Benefit: less wristband fraud; shorter lines at doors and bars.

Marketplaces/multi-brand:

• shared verifier SDK; standard receipts.
• Benefit: consistent policy, simple integration, easier compliance reporting.

Why blockchain here (Midnight + Cardano)

• Midnight enables selective disclosure: prove “over 21” without exposing identity.
• Cardano gives an optional public audit trail for “age check happened,” without revealing who the buyer is.

Together, you get a privacy-first, verifiable compliance flow traditional stacks struggle to balance.

What enterprises can expect

Security & risk

• No PII at rest for age checks.
• Instant revocation (kill a pass immediately).
• A simple threat model and a no-PII checklist in docs.

Integration

• Drop-in Verifier SDK (verifyAgeProof()) for web/POS.
• Simple Issuer API with three modes (Merchant, KYC, DID/VC).
• Docker compose for quick trials; Apache-2.0 license.

Operations

• Track issuances, revocations, proof success rate, checkout time saved, receipt count.
• Policy hooks: issuer DID allow-list, expiry by SKU/category, per-merchant config.

Example flows

In-store

1. Staff checks ID (normal process).
2. Tap “Issue pass” → Midnight pass (30–90 days).
3. Next visits: customer proves “21+” with wallet; store can write an optional Cardano receipt.

Website

1. Click “Verify 21+” → KYC vendor flow or present a DID/VC.
2. If approved/valid, create pass (6–12 months).
3. At checkout, wallet returns a yes/no proof; optional Cardano receipt after payment.

Why this is a good reference DApp

• Teaches issue → proof → revocation → (optional) receipt in one small repo.
• Pluggable issuer (Merchant, any KYC vendor, or DID/VC).
• A tiny Verifier SDK any dev can drop in.
• Clean Midnight → Cardano interop pattern for non-PII audit trails.
• Minimal, well-documented code—easy to fork for retail, events, or other eligibility gates (student status, residency, membership).

Expected outcomes (useful fast)

• A working demo stores can try the same day (POS + web).
• A reusable SDK other Cardano/Midnight teams can adopt.
• Clear docs & a short video so non-crypto engineers can implement quickly.
• Early pilots see faster checkouts, less PII risk, and cleaner audits—what compliance teams and managers care about most.

Proof 21 turns age checks into a small, safe, reusable building block. It fits real retail and e-commerce workflows, keeps customers private, reduces merchant risk, and leaves a trustworthy audit footprint—while staying simple enough for any team to integrate.

What exactly will you build? List the Compact contract(s) and key functions/proofs, the demo UI flow, Lace (Midnight) wallet integration, and your basic test plan.

What exactly we will build

A) On-chain pieces (Midnight + Cardano)

Midnight (no custom Compact code in v1):

• We use Midnight’s credential + ZK proof flow to issue a private AgePass and later verify it (yes/no) without exposing PII.

AgePass record (private):

• type=age_over_21, fields: issuerDid, subjectKey, issuedAt, expiresAt, revoked, version.

Revocation:

• flip revoked=true (or mark in a tiny revocation map) so future proofs fail.

Cardano (optional audit receipt):

• After a successful verify, write a non-PII metadata receipt on Cardano preprod:
• { proofRefHash, merchantId, ts } (or an optional micro-NFT example for the demo).

v1 keeps Compact/contract work minimal; if needed, we can add a small policy/check module later without changing the public API.

B) Key functions & proofs

Issuer API (Node)

• POST /issue { subjectKey, ttlDays } → create AgePass on Midnight → { passId, txId, expiresAt }
• POST /revoke { passId } → mark revoked on Midnight → { txId }
• GET /status/:subjectKey → { exists, expiresAt, revoked, issuerDid }

Issuer modes:

1. Merchant-as-Issuer (in-person ID check)
2. KYC-as-Issuer (vendor adapter, e.g., Veriff/Onfido)
3. DID/VC-as-Issuer (accept a signed verifiable credential; verify VC directly or wrap as an AgePass).

Trust is enforced by an allow-list of issuer DIDs; VC expiry/revocation maps to pass expiry/revocation.

Verifier SDK (TypeScript)

requestAgeProof({ wallet, issuerDid }): Promise<Proof>
verifyAgeProof(proof, { issuerDid, requireNotExpired: true, requireNotRevoked: true }):
  Promise<{ ok: boolean; reason?: "EXPIRED"|"REVOKED"|"ISSUER_MISMATCH"|"INVALID_PROOF"; exp?: number }>

• Internals: validate the ZK proof via Midnight libs; check issuer DID, expiry, revocation.

Cardano Receipt Adapter (Lucid)

writeReceipt({ proofRefHash, merchantId, ts }): Promise<{ cardanoTxHash }>
buildReceiptMetadata(..): CIP-20 style payload

• Guardrail: receipt is only allowed immediately after a fresh OK verify.

Proof statement (at checkout)

“I control a wallet with a valid AgePass from issuerDid, not expired, not revoked.”

Returns a ZK yes/no proof (no DOB, no name).

C) Demo UI flow

Admin (Issuer) screen

1. Staff (or KYC callback) supplies/captures subjectKey.
2. Click Issue Pass → Midnight tx; show { passId, expiresAt }.
3. Revoke tab: search → Revoke → Midnight tx.

POS / Web Checkout

1. User clicks Verify 21+.
2. Wallet prompt: “Prove you have a valid 21+ pass from issuerDid.”
3. App calls verifyAgeProof() → Yes/No.
4. On Yes: start a short session cache (e.g., 30 min) to avoid re-prompts; optionally writeReceipt(..) on Cardano; proceed to payment.

D) Lace (Midnight) wallet integration

Use the Midnight DApp connector to:

• Read subjectKey (public key)
• Request proof/sign for AgePass verification

Browser support:

• Direct connect if Lace/Midnight wallet is installed
• QR deep-link fallback for mobile

If a wallet lacks the proof method, the demo shows a web fallback (for pilot only).

E) Basic test plan

Unit tests

• Schemas: AgePass fields, TTL math, issuerDid format.
• Verifier logic: only accepts the configured issuer; rejects expired and revoked.
• Receipt builder: stable metadata; tolerate small clock skew.

Integration (Midnight, preprod)

• Issue → Verify = OK
• Expired: short TTL → after TTL, verify fails (EXPIRED)
• Revoked: issue, revoke → verify fails (REVOKED)
• Wrong issuer: verify fails (ISSUER_MISMATCH)

Integration (Cardano, preprod)

• After an OK verify, writeReceipt(..) succeeds; parse metadata back.
• Negative: try receipt without verify → adapter refuses (guardrail works).

End-to-end (demo UI)

• Happy path (web + wallet): Verify 21+ → Yes → receipt written → checkout enabled.
• Session reuse: Verify once → browse cart → no re-prompt within session.
• Revoke regression: Revoke → verify now blocked.

CI & artifacts

• GitHub Actions: lint/type/unit/integration on each push; coverage report.
• Save preprod tx links (issue/revoke/receipts) as build artifacts.
• Tags: v0.1 (schemas/spec), v0.2 (issuer+verify), v1.0 (receipt + docs).

F) Deliverables summary

• Repos: /issuer-api, /verifier-sdk, /demo-pos, /cardano-receipt, /docs
• Wallet: Lace (Midnight) connector + QR fallback
• Contracts/chain: Midnight credential + ZK verify (no custom Compact in v1); Cardano metadata receipt writer
• Proofs: “age_over_21” yes/no with issuer, expiry, revocation checks
• Tests: Unit + Midnight/Cardano integration + full E2E with recorded preprod tx links

Goal: keep v1 tight, teachable, and runnable—a clean reference DApp other teams can copy for age gates (and similar eligibility checks) across retail, events, and e-commerce.

How will other developers learn from and reuse your repo? Describe repo structure, README contents, docs/tutorials, test instructions, and extension points. Which developer personas benefit, and how will you gauge impact (forks, stars, issues, remixes)?

How others will learn from and reuse the repo

Repo structure

• packages/issuer-api/ – REST API (/issue, /revoke, /status) + adapter seam
• packages/verifier-sdk/ – TS SDK: requestAgeProof(), verifyAgeProof()
• packages/cardano-receipt/ – optional non-PII receipt writer (metadata; micro-NFT example)
• packages/types/ – shared types/schemas
• apps/demo-pos/ – web/POS demo (wallet connect, verify, optional receipt)
• apps/docs/ – docs site (tutorials, guides, API refs)

README (top-level)

• What is Proof 21 (1 paragraph, who it helps)
• Diagram: Issuer → Wallet proof → Verifier → (optional) Cardano receipt
• Quick start (5 min): pnpm i → docker compose up → open demo
• “How it works” one-pager (no PII, expiry, revocation, receipts)
• Pick your path: In-store (Merchant-as-Issuer) / Website (KYC adapter stub) / DID/VC acceptance
• Links: docs, API refs, SDK, examples, license

Docs & tutorials (apps/docs)

• T1: Run locally (10 min): connect wallet, issue pass, verify, write receipt
• T2: Add to your site (30 min): npm i @proof21/verifier-sdk, gate checkout, optional receipt
• T3: Merchant-as-Issuer: simple admin screen; TTL; revoke flow
• T4: Plug a KYC/DID issuer: where to POST /issue, handle approvals/denials
• Concept guides: privacy/no-PII, expiry/revocation, Midnight→Cardano “receipt” handoff
• API refs: Issuer API; Verifier SDK errors; Receipt metadata schema

Tests & CI

• Unit: pnpm test:unit (schemas, SDK, receipt builder)
• Integration (preprod): set MIDNIGHT_RPC, ISSUER_DID, CARDANO_RPC → pnpm test:int (issue/verify/revoke + receipts)
• E2E (demo): pnpm test:e2e scripted happy path + revoke regression
• CI: lint/type/unit/integration on PR; artifacts include preprod tx links + coverage

Extension points (clean seams)

• Issuer adapters: packages/issuer-api/src/adapters/*
• merchant.ts (in-person) • kyc.ts (template) • did.ts (VC verify/wrap)
• Wallet/providers: packages/verifier-sdk/src/providers/* (Lace Midnight now; add others later)
• Receipts: packages/cardano-receipt/src/backends/* (metadata.ts default, nft.ts example)
• Config: apps/demo-pos/src/config.ts (issuer DID, TTL, receipts on/off)

Developer personas

• Web/POS engineers (no crypto): drop-in SDK + demo button; copy/paste under 30 lines
• Full-stack dApp devs: learn the pattern (issue → ZK verify → revoke → receipt) and reuse adapters
• Compliance/IT leads: see no-PII design, revocation control, public non-PII receipts
• Students/hackers: small repo, Docker up, reproducible tests, easy remixes

How we’ll gauge impact

• GitHub: stars, forks, issues, PRs, release downloads; “Adopters” section with links
• NPM: downloads of @proof21/verifier-sdk
• Telemetry (opt-in demo): count successful verifies/receipts (no PII)
• Chain refs (preprod): number of receipts written with a tagged metadata key

Developer ergonomics

• Copy/paste snippets in every tutorial (≤30 lines)
• Postman/Bruno collection for Issuer API
• .env.example + Docker compose for one-command boot
• Typed SDK errors: EXPIRED, REVOKED, ISSUER_MISMATCH, INVALID_PROOF, WALLET_UNSUPPORTED
• Release tags: v0.1 (schemas/spec) • v0.2 (issuer+verify) • v1.0 (receipt+docs)
• License: Apache-2.0; CONTRIBUTING.md; “good first issue” labels; public roadmap

This makes Proof 21 teachable in an afternoon and reusable the same week—exactly what Compact DApps reviewers want.

[Your Project and Solution] Solution

Please describe your proposed solution and how it addresses the problem

Solution

Proof 21 is a small, open-source reference DApp that lets any store or website confirm “21+” without collecting or storing personal data. It replaces today’s bad choices—skip checks or hold risky PII—with a private yes/no proof on Midnight and an optional, non-PII Cardano receipt for audits.

How it works (simple)

1) Issue once, prove many times

An issuer creates a private Age Pass on Midnight for the customer’s wallet (age_over_21 = true with expiry and revocation).

Supported issuer paths (pick one per use case):

• Merchant-as-Issuer (in-person): staff checks a physical ID and issues a short-lived pass (e.g., 30–90 days)
• KYC-as-Issuer (online): plug a vendor (e.g., Veriff/Onfido) for a longer-lived pass (e.g., 6–12 months).
• DID/VC-as-Issuer (future-friendly): accept a standards-based verifiable credential from an allow-listed issuer DID; verify the VC directly or wrap it as an Age Pass. Expiry/revocation on the VC maps to the pass.

2) Verify at checkout

The site or POS asks the wallet to produce a zero-knowledge proof that a valid pass exists (right issuer, not expired, not revoked).

The app receives only yes/no—no name, DOB, or photos.

For smoother UX, a short session prevents re-prompts during the order.

3) (Optional) Cardano receipt

After a valid proof, write a tiny non-PII receipt on Cardano (e.g., { proofRefHash, merchantId, timestamp }). This gives an audit trail that “an age check happened” without revealing who the buyer is.

Why this solves the problem

• Compliance without liability: merchants confirm legal age without storing PII, reducing breach risk and policy overhead.
• Fast, repeatable checkout: returning customers prove eligibility in seconds; staff avoid repeated manual checks.
• Works online and in-store: one small verifier flow for web carts, delivery, counters, and events.
• Auditable but private: optional Cardano receipts show checks occurred while identities remain private.
• Reusable by others: clean APIs, a tiny SDK, and a runnable demo make adoption easy across many verticals.

What we ship

• Issuer API (/issue, /revoke, /status) with adapter seams for Merchant, KYC, and DID/VC.
• Verifier SDK (TypeScript): verifyAgeProof() returns yes/no with reasons on failure (expired, revoked, issuer mismatch).
• Demo POS/Web: “Verify 21+” button, short session flow, optional receipt write.
• Cardano Receipt Adapter (optional): non-PII metadata (or micro-NFT example) for audit breadcrumbs.

Result: Proof 21 gives businesses a plug-and-play, privacy-first age gate that’s easy to install, safe to operate, and clear enough for other developers to learn from and reuse across retail, alcohol, vape, events, and other age-restricted markets.

[Your Project and Solution] Impact

Please define the positive impact your project will have on Midnight ecosystem

Impact on the Midnight ecosystem

1) Copy-paste reference for private eligibility

• Small repo that demonstrates the core Midnight loop: issue → ZK verify (yes/no) → expire/revoke.
• Shrinks “hello world” from weeks to hours for new builders.

2) Teaches privacy by default

• Shows how to satisfy 21+ without storing DOB, names, or images.
• Clear revocation pattern most apps can reuse (membership, coupons, access badges).

3) Drop-in Verifier SDK

• One call: verifyAgeProof() with typed errors (EXPIRED, REVOKED, ISSUER_MISMATCH).
• Lowers friction for web/POS teams; encourages more apps to adopt Midnight proofs.

4) Interop: Midnight → Cardano

• Optional non-PII receipt adapter models safe handoff from private proof to a public audit breadcrumb.
• Teachable pattern other domains can copy (tickets, discounts, compliance checks).

5) Strong developer experience

• Monorepo + Docker compose, .env.example, Postman/Bruno collection, CI with preprod tests.
• 10-minute quick start and short videos raise the quality bar for future Midnight repos.

6) Extensible by design

• Issuer adapters: start with Merchant-as-Issuer, plug in any KYC vendor, or accept DID/VC.
• Receipt backends: metadata by default; micro-NFT example included.
• Clear seams invite community plugins.

7) Public, measurable signals

• OSS: stars, forks, issues/PRs, SDK downloads.
• Chain (preprod): issuance/revocation counts; optional Cardano receipt totals.
• Adopters list: track external demos/forks to show ecosystem growth.

8) Education & outreach

• Simple diagrams, no-PII checklist, and “when to use Merchant vs KYC vs DID” guidance.
• Reduces confusion for teams planning real deployments.

9) Catalyst-fit footprint

• Compact scope, fast delivery, Apache-2.0 license.
• A practical PoC that grows Midnight’s builder base and normalizes privacy-first patterns.

Proof 21 gives Midnight a polished exemplar of private attestations with revocation and a ready-to-use Verifier SDK. It shortens the path from idea to working prototype for retail, events, memberships, and coupons—accelerating real adoption of Midnight.

[Your Project and Solution] Capabilities & Feasibility

What is your capability to deliver your project with high levels of trust and accountability? How do you intend to validate if your approach is feasible?

Capabilities & Feasibility

Team & stack fit

• Lead: Allen Willenbrock — full-stack Cardano builder (Lucid/Aiken/React/Deno). Ships end-to-end dApps, SDKs, and payment flows.
• Scope match: v1 = issue a private age pass on Midnight → verify ZK yes/no at checkout → (optional) Cardano non-PII receipt.

Trust & accountability (how we run the project)

• Open from day 1: public repo, Apache-2.0 license.
• Clear gates: milestones with acceptance criteria already defined (schemas → issuer API → verifier SDK + demo → receipt + release).
• CI/CD: lint + typecheck + unit/integration tests on every PR; signed tags: v0.1 … v1.0.
• Public artifacts: preprod tx links (issue/revoke/receipts), coverage report, live demo URL, 2–3-min walkthrough video.
• Transparent tracking: GitHub Projects board (Backlog → In progress → Review → Done), weekly notes.
• Telemetry: demo-only, opt-in, no PII.

Security & privacy hygiene

• No PII design: only “age_over_21=true”, issuer DID, expiry, revoked flag.
• Docs: threat model + “no-PII checklist”.
• Keys: .env templates, least-privilege issuer keys, rotation guidance.
• Revocation paths tested: expired, revoked, wrong-issuer.

How we validate feasibility

1) Technical (Midnight) — prove the 4 core cases on preprod

• OK path: Issue → Verify = pass
• Expired: short TTL → Verify = fail: EXPIRED
• Revoked: Issue → Revoke → Verify = fail: REVOKED
• Wrong issuer: Verify = fail: ISSUER_MISMATCH

Artifacts: preprod tx links + proof logs saved by CI; linked in README.

2) User flow (demo UI)

• POS/Web demo: Verify 21+ → short session cache → checkout.
• Measure verify time and drop-off; goal: sub-second repeat verifies.
• Quick usability pass with 2–3 external testers; fix friction spots.

3) Interop (Cardano receipt)

• After a valid verify, write non-PII receipt on Cardano preprod; parse back in tests.
• Guardrail: refuse receipts unless a fresh OK verify just occurred.

4) Reuse by other devs

• Ship a typed Verifier SDK with copy-paste snippets (≤30 LOC).
• Ask 2 external devs to follow Tutorial 1 and confirm they can:
  • run the demo, issue/revoke, verify, and (optionally) write a receipt.
• Capture feedback and adjust docs.

Contingencies & scope control

• Wallet differences: provider-adapter layer; keep Lace (Midnight) primary.
• KYC delay: ship Merchant-as-Issuer first; KYC/DID adapters are stubs with interfaces.
• Receipt format changes: metadata writer is modular (metadata default, micro-NFT optional).

What reviewers will see during delivery

• Tags: v0.1 (schemas/spec), v0.2 (issuer+revoke), v0.3 (verifier+demo), v1.0 (receipt+docs).
• Preprod links: issuance, revocation, and receipt txs in release notes.
• Video: 2–3-minute end-to-end walkthrough.
• Docs: API spec, SDK reference, tutorials, threat model, no-PII checklist.
• Early adoption: ≥2 forks/PRs from outside devs before the final milestone.

Small scope, open processes, tested critical paths, and visible artifacts make this delivery trustworthy and verifiable—and the approach feasible on Midnight today.

[Final Pitch] Budget & Costs

Please provide a cost breakdown of the proposed work and resources

Budget & Costs (total 10,000 USDM)

Summary by milestone

• Milestone 1 – Public repo + Issue/Revoke (20%): 2,000 USDM
  • Dev time: 1,800 (≈60 h @ $30/h)
  • Infra/CI & testnet setup: 200 (RPC credits, CI minutes, storage)
• Milestone 2 – Verifier SDK + Demo UI (30%): 3,000 USDM
  • Dev time: 2,700 (≈90 h @ $30/h)
  • Docs & short demo video: 300
• Milestone 3 – Cardano receipt + Full PoC & close-out (50%): 5,000 USDM
  • Dev time: 4,500 (≈150 h @ $30/h)
  • Cardano adapter/testing, release/hosting, small tester stipends/tools: 500

Totals: Dev hours ≈ 300 h (9,000 USDM) + Ops/Docs/Testing 1,000 USDM = 10,000 USDM

Category view (what the money pays for)

• Development (≈300 h @ $30/h) — 9,000
  • M1: Issuer API (/issue, /revoke, /status), schemas, preprod wiring
  • M2: Verifier SDK + demo UI, integration tests, basic docs
  • M3: Cardano receipt adapter, E2E tests, polish & release
• Ops / Infra / CI — 400
  • CI minutes, artifact storage, RPC credits, domain/hosting for demo
• Documentation & Video — 300
  • “How it works,” API refs, quick-start, 2–3 min walkthrough
• Testing & Tools — 200
  • Small tester stipends or devices, Postman/Bruno collections
• Release & Support — 100
  • Packaging, tags, issue templates, contribution guide

Why this is value for money

• Focuses funds on build hours and verifiable outputs (code, tests, demo, tx links).
• Uses testnets, so no mainnet fees are required; ops kept lean.
• Delivers a teachable reference DApp (issue → ZK verify → revoke → optional Cardano receipt) other Midnight builders can copy immediately.

[Final Pitch] Value for Money

How does the cost of the project represent value for the Midnight ecosystem?

Value for Money

Small budget, complete reference app (10,000 USDM):

Delivers a full, copy-pastable pattern—issue → ZK verify (yes/no) → revoke → (optional) Cardano receipt—that many Midnight builders can reuse on day one. You’re funding a template others can slot into retail, events, memberships, and coupons.

Most funds go to build hours, not overhead:

~300 dev hours (≈9,000 USDM) produce real code, tests, and a runnable demo; only ~10% covers CI/RPC/docs/video. No mainnet spend required.

Accelerates ecosystem time-to-first-app:

The repo reduces “hello world with proofs + revocation” from weeks to hours through a monorepo, Docker up, and a 10-minute quick start. Lower friction → more experiments → more Midnight apps.

High reuse per dollar (SDK + adapters):

A tiny Verifier SDK and clean adapter seams (Merchant, KYC, DID/VC; metadata vs micro-NFT receipts) let teams adopt just the parts they need. One funded codebase supports many verticals.

Privacy by default, teachable by design:

Clear no-PII implementation and revocation patterns raise the bar for future Midnight projects—improving security posture across the ecosystem at minimal cost.

Interoperability included:

Optional Cardano receipt shows a safe, non-PII bridge from private proofs to public audit breadcrumbs—an inexpensive way to document compliance flows other teams can mirror.

Open, auditable delivery:

Apache-2.0 license, public repo from day one, CI with unit/integration/E2E tests, preprod tx links, short demo video, and tagged releases (v0.1 → v1.0) ensure transparency and durable value.

Measurable outcomes, not vanity:

We will track open-source signals (stars, forks, SDK downloads), preprod issuance/revocation counts, and adopter links—so reviewers can see real reuse beyond the grant window.

For 10k USDM, the Midnight community gets a polished, open-source reference DApp that shortens the path from concept to working proof-based apps, teaches best-practice privacy, and provides components (SDK + adapters) that other teams can adopt immediately.

[Self-Assessment] Self-Assessment Checklist

I confirm that the proposal clearly provides a basic prototype reference application for one of the areas of interest.

Yes

I confirm that the proposal clearly defines which part of the developer journey it improves and how it makes building on Midnight easier and more productive.

Yes

I confirm that the proposal explicitly states the chosen permissive open-source license (e.g., MIT, Apache 2.0) and commits to a public code repository.

Yes

I confirm that the team provides evidence of their technical ability and experience in creating developer tools or high-quality technical content (e.g., GitHub, portfolio).

Yes

I confirm that a plan for creating and maintaining clear, comprehensive documentation is a core part of the proposal's scope.

Yes

I confirm that the budget and timeline (3 months) are realistic for delivering the proposed tool or resource.

Yes

[Required Acknowledgements] Consent & Confirmation

I Agree

Yes