▶ Demo video and project overview: devpost.com/software/stealthmatch
StealthMatch is a privacy-preserving startup-support discovery prototype. It helps founders research investors, accelerators, grants, and ecosystem programs without submitting confidential operating constraints or conflict concerns to a matching service in plaintext.
Public discovery filters—such as vertical, company stage, and opportunity type—narrow the catalog. The encrypted mandate then refines the shortlist using details that can genuinely be sensitive before an NDA: fundraising constraints, operating runway, timing, readiness, ownership/control ranges, and names of companies, investors, or strategic buyers to avoid.
- The browser collects public filters and a private mandate.
- A local bridge encodes and encrypts the mandate with CKKS FHE.
- The scoring service evaluates the ciphertext across the public opportunity catalog, using one opportunity per SIMD slot. It has no secret key.
- The client decrypts the returned total and component scores, ranks results locally, and presents concise explanations.
The encrypted feature vector has 62 values:
- six numeric mandate fields: availability window, raise target, maximum dilution, capital raised, revenue, and technology readiness;
- 54 private conflict flags resolved against a public registry; and
- two eligibility review flags for institutional ownership and voting control.
The server returns only encrypted totals and four encrypted components: timing, capital/readiness, conflict penalty, and eligibility penalty. Raw vectors, CKKS precision errors, and distance values remain diagnostics rather than user-facing product output.
The founder holds the FHE secret key. The scoring side receives ciphertexts and public/evaluation keys only; it does not receive the founder's plaintext mandate, conflict names, or decrypted component values.
This MVP does not conceal metadata such as request timing or count, nor does it guarantee investment, admission, or complete conflict coverage. The opportunity catalog is intentionally public in the first version. See the product specification and private-mandate schema for the full boundary.
StealthMatch builds against niobium-client, an external prerequisite that provides the nbc DSL compiler, the instrumented OpenFHE, and the FHETCH record/replay runtime. Build that checkout once (its own make release), then point NIOBIUM_CLIENT_ROOT at it. You also need a C++17 compiler, CMake 3.16 or later, and Python 3.
git clone https://github.com/sw-zzz/openai-build-week-fhe.git
cd openai-build-week-fhe
NIOBIUM_CLIENT_ROOT=/path/to/niobium-client make testOverride the toolchain when the defaults are wrong for your platform. On macOS / Apple Silicon, use Homebrew's cmake and python (the system ones may be x86_64):
NIOBIUM_CLIENT_ROOT=/path/to/niobium-client \
CMAKE=/opt/homebrew/bin/cmake PYTHON=/opt/homebrew/bin/python3 make testmake testRuns the encrypted scoring example and confirms its decrypted results match the plaintext reference.
It prepares the demo catalog, generates keys, encrypts a private mandate, performs blind scoring, decrypts the total and component scores, and checks the ranking and numeric error against the plaintext calculation.
make compareRuns three paired-founder scenarios: each pair has the same public filters but different private mandates. It shows how confidential conflicts or operating constraints change the locally ranked opportunities, then confirms that the encrypted and plaintext rankings agree.
The blind-scoring stage is annotated @hardware, so nbc records it as a FHETCH
trace that can be replayed on the local functional simulator or, unchanged, on
Niobium FPGA hardware through Fog. Both use the full profile (N=65536,
HEStd_128_classic), the same parameters the hardware requires.
make sim # record, then replay on the local simulator, and verify
make fog # record, then replay on the FPGA via `fog submit`make sim is the offline path and needs no hardware or network. make fog
needs the fog CLI and credentials. See FOG.md for the full flow,
prerequisites, and current status.
To use the UI:
make prepare
python3 app/server.pyOpen the local URL printed by the server. The browser communicates only with the 127.0.0.1 bridge in this prototype.
The initial catalog is curated from public provider pages. Its sources and limitations are documented in data/SOURCES.md. When a public source does not support a numeric scoring input, the corresponding public mask is zeroed rather than guessed.
This project was built during OpenAI Build Week with Codex running GPT-5.6. The split of work below is deliberate: product judgment and final verification stayed human; design reasoning and implementation speed came from the collaboration.
The founder problem, the privacy boundary, and the evaluation standard were set before any code: public discovery facts (vertical, stage, opportunity type) stay public; concrete operating constraints and conflict names remain a founder-local, encrypted mandate; the secret key and raw values never leave the device; and the output had to be an actionable research shortlist with reasons and cautions — not a cryptography dashboard. "Working" was defined up front as paired scenarios in which identical public filters produce different research orders from private inputs alone.
GPT-5.6 was used to reason through design choices before implementation: how to lay out the 62-value encrypted feature vector and pack one opportunity per CKKS SIMD slot; how to decompose scoring into an encrypted total plus four encrypted components (timing, capital/readiness, conflict penalty, eligibility penalty) so explanations stay useful without leaking diagnostics; where the privacy boundary should sit for the fuzzy conflict lookup; and how to construct the paired-founder evaluation cases that make compare now runs.
- FHE pipeline — the Niobium DSL programs (
fhe/*.niob) and the supported DSL → generated CMake → client/server/decrypt workflow, replacing an earlier hand-rolled path. - Local bridge and UI — the founder-side bridge (
app/server.py) that encodes, encrypts, and decrypts locally, and the founder-facing app (app/). - Portability — building against an external niobium-client checkout via
NIOBIUM_CLIENT_ROOT, and removing machine-specific paths and fixed ARM compiler settings. - Verification harness and docs — the plaintext reference and comparison harness (
harness/verify_scores.py,harness/compare_examples.py,harness/validate_catalog.py) and iteration on tests and documentation.
The final claims were checked without relying on the assistant: encrypted-versus-plaintext ranking agreement within CKKS's expected approximation (make test), three fixed-public paired scenarios (make compare), and a fresh-clone build on a clean machine. The Codex /feedback session ID covering core functionality is included in the Devpost submission.
make validate-data # validate catalog records and source-backed scoring inputs
make evaluate # run data validation and the paired-founder comparison
make compare-build # rebuild generated FHE binaries, then run the comparisonThe score profiles are a transparent demonstration rubric, not provider endorsements or eligibility decisions. The match-quality protocol and comparison examples explain the claims the prototype can support.
0 comments
log in to comment.