Senior Full-Stack Engineer (NestJS + Next.js) — Tokenization & Registry Module (Regulated Fintech)

Invite-only, fixed-price engagement. We have a live, well-tested multi-tenant NestJS + Prisma + PostgreSQL platform with a Next.js tokenization UI already built, and need a senior engineer to harden the backend and wire it end-to-end with the existing frontend so the feature-flagged tokenization/registry flow works front to back. Brownfield, full-stack, financial-grade correctness, long-term. OVERVIEW OpenReal is a production private-markets registry platform - a Next.js frontend on a NestJS + Prisma + PostgreSQL API. The database is the legal system of record for investor holdings. We're adding a tokenization module (digital registry of units, with an optional on-chain mirror) that ships behind feature flags and compliance controls. This is brownfield work on a mature, professionally built codebase - you'll extend it, not rebuild it. What's already in place: - ~37 modules (controller/service per domain), 77 validated DTOs, 34 DB migrations, Swagger/OpenAPI. - Global guard chain: JWT auth, multi-tenant scoping, RBAC, rate limiting, feature flags, maintenance kill-switch. - Multi-tenant isolation (Prisma extensions + Postgres RLS scaffolding), field-level PII encryption, KYC (Sumsub) with webhooks, DocuSign e-sign, S3, BullMQ/Redis jobs. - CI/CD (GitHub Actions), Docker, 88 unit + 23 integration tests. - Frontend already built: a Next.js 6-step tokenization wizard (issuer flow) is complete and already calls the API - it submits a structured tokenizationConfig, uploads documents, and persists drafts. It needs the backend contract hardened and the two wired end-to-end and per-tenant gated - not a rebuild. The tokenization primitives are already scaffolded in the schema (a shadow/mirror token record state model, plus order/trade/settlement tables) and the frontend wizard already defines the config contract, so the work is wiring, hardening, gating, and finishing the end-to-end path - not inventing from scratch. WHAT COMPLETE MEANS HERE The engineer builds out the tokenization module, connects it to the already-built Next.js frontend, and makes it work with the current registry flow - delivered as one complete, working product, not a disconnected backend. Concretely, at the end of the engagement: - The existing Next.js tokenization wizard creates/edits a tokenized opportunity, and the NestJS backend persists and round-trips it as first-class typed data (create, save draft, resume, submit works front to back). - The registry stays the source of truth: tokenization runs on top of and alongside the existing non-tokenized registry / SPV-subscription flow without breaking it. The current registry flow keeps working exactly as it does today; holdings, subscriptions, and the ledger stay consistent whether or not an asset is tokenized. In particular, the shadow-mirror (token-record) write must be strictly non-throwing / out-of-band - it must never be able to roll back a real registry transaction. - The ledger and eligibility gate enforce correctness across both flows, and a platform operator can switch tokenization on per tenant (after license/legal sign-off), with the frontend surfacing it only when that per-tenant flag is on. - Any glue or missing wiring needed to make these flows work end-to-end - and to keep them working together - is included in the milestone it belongs to. This does not mean smart-contract audits, key-custody infrastructure, or legal/regulatory sign-off - those are explicitly out of scope (see below). SCOPE OF WORK Phase 1 - Registry and tokenization core (start here) 1. Tokenization config persistence (end-to-end). Add a typed model + migration + validation and round-trip it through the issuer opportunity API (ticker, unit supply, unit price, decimals, token standard, custody model, settlement model, eligibility, jurisdictions, hold period, market state). Today the issuer endpoint silently drops this payload - the DTO omits it and the global validation pipe strips it, so it is persisted nowhere; make it first-class. The Next.js wizard already sends this structured tokenizationConfig - match that contract and confirm the full round-trip works in the existing UI (create, save draft, resume, submit). 2. Registry ledger hardening. Enum-ify event types, enforce the balance invariant (a holding's balance must always equal the sum of its ledger entries) via a reconciliation job, and add idempotency to every ownership/money operation. 3. Eligibility/compliance gate. A configurable rules engine that records an eligibility decision (KYC status, investor classification, jurisdiction, restricted countries, hold period, investor cap) before any subscription, order, or transfer is allowed to proceed. 4. Per-tenant tokenization gating (front to back). Add a tokenization feature flag to the existing per-tenant flag system so a platform operator (super-admin) can switch tokenization on for one licensed tenant - not globally, and never by the tenant admin themselves. Guard the tokenization endpoints with it, and replace the frontend's env-var gate so the Next.js UI surfaces tokenization only when that per-tenant flag is on. Phase 2 - Rollout hardening and advanced 5. On-chain sync layer behind an adapter interface + feature flag (ERC-3643 or ERC-1400 security token, custodial; registry stays the source of truth). No raw private keys in the app - MPC/HSM only. 6. Realtime valuation stream (SSE) for a tokenized asset's value chart, wired into the existing frontend chart. 7. Platform hardening: complete DB-level RLS enforcement, resolve dependency audit findings, add fail-fast env-schema validation, fix 2 known failing unit tests. MUST-HAVE SKILLS - 5+ yrs backend; expert NestJS (modules, DI, guards, interceptors, pipes). - Prisma + PostgreSQL in production: migrations, transactions, indexing, and ideally Row-Level Security. - Financial-grade correctness: idempotency, append-only ledgers, decimal money handling, state machines, concurrency control. - BullMQ/Redis jobs, webhooks, disciplined testing (Vitest/Jest, integration tests) - you keep the suite green. - Next.js / React (TypeScript) - enough to wire an already-built UI to your backend and fix gating. You won't design new UI, but you own the end-to-end path. - Clear written English; you read a spec, reconcile it against the code, and push back when they disagree. MILESTONES AND FIXED PRICES Fixed-price, milestone-based - no hourly. Each milestone is separately funded; we release on acceptance. - M0 - Paid trial: Tokenization-config persistence + round-trip verified end-to-end in the existing Next.js wizard, with tests - 150 USD - M0.5 - Hardening and gating: Fix 2 failing unit tests, dependency-audit triage, env-schema validation, per-tenant tokenization flag + frontend gating - 150 USD - M1 - Ledger: Event-type enums + balance-invariant reconciliation job + idempotency on ownership/money ops - 300 USD - M2 - Compliance gate: Eligibility decision engine wired end-to-end into subscription + transfer flows - 400 USD - Phase 2: On-chain sync adapter, SSE valuation stream, full RLS enforcement - 500 USD Complete engagement total, M0 through Phase 2: 1,500 USD fixed. Each milestone is funded and released separately on acceptance. Prices are firm. Every milestone - including Phase 2 - is delivered to a production-grade standard (see Definition of done): complete, tested, safe to run in production behind the flag - not a proof-of-concept. Outside any engineering milestone (planned separately): a live regulated launch also needs an independent smart-contract security audit, MPC/HSM key-custody, an external pen test / security review, and legal/regulatory sign-off - none are software deliverables. The code ships production-grade and gated off; those separate gates flip it on. TERMS - NDA required before repository or architecture-doc access. - Full IP assignment of all work product to us. - Work happens in our repos on a feature branch, via reviewed PRs. - Start: immediately on agreeing M0. - Timeline: 30 days. DEFINITION OF DONE (every milestone - production-grade bar) - PR merged with lint + build + unit + integration tests passing and no regressions to existing endpoints or the current registry/subscription flow. - The flow demonstrated working end-to-end - backend + existing Next.js frontend - not just an API returning JSON. - No stubs, TODOs, dead code, or any escape hatches in the delivered path. - Financial-grade correctness proven, not asserted: money/ownership ops demonstrably idempotent and safe under concurrent writes and retries, with tests that exercise the race/retry. Migrations reversible and backfill existing data. - Explicit failure handling; the tokenization shadow layer can never roll back a registry transaction. - Structured logging/audit on state changes; no secrets or PII in logs. - Unit and integration tests with meaningful assertions. - Short design note on approach, concurrency/idempotency strategy, and trade-offs. TO APPLY, INCLUDE - A NestJS + Prisma production project you built - ideally with multi-tenancy, ledgers, or financial data. - One or two sentences: how do you guarantee a holding's balance can never drift from its ledger entries under concurrent writes and retries? - Your security-token / regulated-fintech experience (an honest none is fine). - Availability, timezone, and confirmation you accept the complete fixed budget of 1,500 USD. SCREENING QUESTIONS 1. In a paragraph: how do you make create subscription + update balance idempotent and safe under retries in NestJS/Prisma? 2. Have you implemented Postgres Row-Level Security (or equivalent hard tenant isolation)? How did you scope tenant context per request? 3. Rate your security-token / tokenized-asset experience 0-5, one line of context. 4. The spec says no matching engine, yet the schema contains order/trade/settlement tables. Reconcile that: does a matching engine actually exist, or not - and what do you do?