Nyx

The next generation of bank connectivity isn’t “share everything”, it’s share exactly what you choose. Nyx is the privacy-first gateway built for that world, powered by the Midnight network.

Comment

Inspiration

We were halfway through the hackathon with no idea locked in when the headline hit: ChatGPT is partnering with Plaid so people can hook their real bank accounts straight into a chatbot. Twelve thousand institutions, one connection.

Everyone called it “secure.” We read it differently: another pipe that moves your whole financial life into someone else’s product and the fine print is trust us.

That’s the part that stuck. Not AI hype. Access. One approval, and downstream apps and platforms get what the integration was built to pull. Users don’t see a clean menu: you can have amount and category, but not merchant, not account number, not my full history. They see a connect button and a promise.

Then you look at what centralized gateways have actually been through—breaches, leaks, over-collection, the kind of headlines where people find out their data lived in more places than they thought. The pattern is always the same: collect wide, apologize later. Apps say they only need a slice; the plumbing still runs through systems built to move everything.

We didn’t want to build a nicer version of that. We wanted to flip it.

What if connecting your bank didn’t mean “share it all”? What if every export was only what you chose and there was proof, not marketing copy, that nothing extra slipped through?

That’s Nyx. A gateway that puts selective disclosure back in your hands and makes “we only used what you allowed” something you can verify, not just believe.

What it does

Nyx is a privacy-first financial data gateway. Users connect third-party apps to their bank (our demo uses mock data) and set a permission policy per app—which transaction fields that app may receive.

After permissions are saved, the app’s backend requests an export and gets:

  • Filtered data — only allowed fields (e.g. a budget app: amount + category, not merchant or account).
  • A compliance proof — a Midnight zero-knowledge proof (with the full stack running) that the export matches that policy, without putting full bank records on chain. A proof verifier lets anyone paste the API response and confirm the data wasn’t tampered with and matches the proof—less “trust our servers,” more “check this yourself.

How we built it

Demo UI (HTML/CSS/JS) served by an Express gateway with three panels:

  • User dashboard — full bank view + per-app permission toggles
  • Third-party app — connect flow + simulated app API export
  • Proof verifier — paste JSON, verify The backend filters transactions, hashes the permission set + full + filtered datasets (canonical SHA-256), and calls the Midnight prover via backend/services/midnight.js.

Midnight layer:

  • Compact contract (proveExportCompliance) — binds policy hash, input commitment, output hash
  • Docker — local node, indexer, proof-server (undeployed devnet)
  • TypeScript prover — wallet sync, ZK generation, on-chain submit; returns midnight-zk bundle + transaction id If Midnight isn’t running, the API falls back to hash-binding proofs so the demo still works end-to-end.

Challenges we ran into

  • Midnight SDK on local undeployed — wallet sync bugs required patches (patch-wallet-sync.ts) before deploy/prove were reliable
  • Multi-service setup — Docker, deploy, prover, and API must be up in order; easy to hit “fallback only” by accident
  • Node 22+ — engine mismatches on older Node added friction
  • Making ZK legible — three UI roles (user, app, auditor) so judges get the story without reading a whitepaper
  • Proof latency — real ZK + on-chain submit takes time; we had to design the demo so waiting feels intentional

Accomplishments that we're proud of

  • End-to-end narrative — connect → consent → export → verify, not a static mock
  • Real Midnight ZK proofs on a Compact contract, not a fake “verified” badge
  • Field-level selective disclosure with a clear permission policy per app
  • Tamper-evident verifier — edit the JSON, verification fails
  • Resilient demo — full ZK path when infra is up, honest fallback when it isn’t

What we learned

  • Privacy in fintech is scope: what leaves, who asked, and whether that can be proved
  • ZK fits compliance (“export matched policy X”) better than “we filtered it server-side, trust us”
  • Midnight’s split between public commitments and private witnesses maps cleanly to bank exports
  • Cutting-edge ZK dev still has rough edges—local stability and docs matter as much as the circuit
  • People understand the product faster with three visible roles than one API page

What's next for Nyx

Phase 1 — Prove the model (0–6 months)

  • Developer sandbox: API keys, webhooks, polished docs
  • Richer policies (time windows, account subsets, more field types)
  • Deploy beyond local undeployed to public testnet
  • Security pass on permissions and export pipeline

Phase 2 — Pilot with builders (6–12 months)

  • SDK for apps: connect, scoped export, client-side proof verification
  • Pilots with fintech or AI-finance teams that need minimum necessary data
  • Production consent dashboard with real bank connectivity (regulated aggregators / open banking)
  • Auditor-friendly proof artifacts for compliance teams

Phase 3 — Trust layer (12–24 months)

  • Nyx as the policy + proof layer integrations plug into
  • Standard permission templates (tax, budgeting, lending, AI agents)
  • Optional on-chain registry for apps that honor proof-verified exports
  • Enterprise: SLAs, dedicated prover infra, jurisdiction-specific circuits

Long-term vision Nyx becomes the default for “share less, prove more.” Users manage bank access like app permissions on a phone. Apps receive provable minimum data. In a world racing to connect AI to money, selective disclosure with ZK isn’t optional infrastructure, it’s how you ship without betting your users’ entire financial lives on a connect button.

Built With

Share this project:

Updates