Security

NHBC membership is represented by Unlock Protocol keys on Base mainnet. Each member connects a wallet, and the application checks that wallet against NHBC's configured Unlock locks before granting member-only access.

NHBC maintains five membership locks that map to bylaw membership classes. A wallet with a current, unexpired key in any configured lock is treated as an active member for gated member experiences.

Membership verification reads public lock state, including key ownership and expiration. The app checks locks server-side, stops at the first valid active key, and caches successful results briefly to reduce RPC load without changing the on-chain source of truth.

NHBC uses Privy for wallet-based authentication. Members authenticate by proving control of their wallet, then the server resolves that wallet against active Unlock membership before private pages or APIs return member data.

The middleware layer only confirms that a session token exists. Member and board routes perform their own canonical authorization checks so a logged-in wallet is not automatically treated as a member or administrator.

Session handling is scoped to the NHBC application and avoids exposing wallet authentication details in public pages or public transparency outputs.

Governance and membership state changes are recorded in an append-only audit_events table. Each event includes the actor role, action, resource, before and after state snapshots when applicable, reason, policy version, IP metadata, and user agent metadata.

Every row stores a previousHash and a computed hash over a canonical event payload. The first row links to a genesis hash; each later row links to the row before it, making deletions or edits detectable during verification.

Audit events are written through the governance audit helper so the domain change and its audit link are created together, preserving an accountable trail for important state transitions.

Public endpoints such as contact, application, subscription, and meeting-token forms apply per-client rate limits before doing expensive work or sending outbound automation.

Production rate limits are backed by Redis when configured, with standard X-RateLimit response headers where appropriate. A process-local memory fallback keeps protection in place during development or temporary Redis outages.

NHBC also uses Vercel BotID on protected public surfaces. Verified good bots are allowed, malicious bot classifications are blocked, and infrastructure errors fail open only after the ordinary rate-limit and same-origin defenses remain in place.

State-changing API requests are protected against cross-site POSTs. The app prefers browser Sec-Fetch-Site same-origin signals, then falls back to Origin or Referer comparisons against the current request host.

Requests without a trustworthy Origin or Referer are rejected, and intentionally cross-origin callers must be explicitly allowlisted. Webhook and cron paths are exempt only because they use their own signatures or secrets.

NHBC applies security headers across the web app, including HSTS, nosniff, X-Frame-Options DENY, strict-origin-when-cross-origin referrer policy, a restrictive permissions policy, and Cross-Origin-Opener-Policy.

The Content Security Policy starts from default-src 'self', blocks object embedding, restricts form submissions to NHBC, and only permits the external script, frame, and connection origins needed for Privy, Unlock, Vercel, Alchemy, Daily, Resend, Neon, and Telegram integrations.