WETYR Corporation / April 2026
POY Verify is a privacy-first human verification platform. It proves users are real humans online without collecting or storing personal data. Think of it as a universal "verified human" badge that works across every platform on the internet.
Current state: MVP live at poyverify.com with 10,000+ pages, 38 API endpoints, 37 serverless functions, 11 database tables, working biometric verification flow, content stamping system, and admin dashboard.
Where it needs to go: Native mobile apps, enterprise SDK, hardware Secure Enclave integration, voice biometrics, real-time APIs, browser extension, Coercion Resistance Protocol (CRP) for defense/enterprise, consent-based age verification, and scale to millions of users across every industry.
POY Verify includes a 5-layer Coercion Resistance Protocol (CRP) - the only biometric platform with explicit anti-coercion architecture. This is a defensible moat in defense MRO, CMMC 2.0, and enterprise zero-trust procurement contexts.
| Layer | Technology | Details |
|---|---|---|
| Frontend | Vanilla HTML/CSS/JS | 10,000+ static pages, no framework |
| Hosting | Netlify | Static site + 37 serverless functions |
| Backend | Netlify Functions (Node.js) | Serverless, ~5,000 lines of backend code |
| Database | Supabase (PostgreSQL) | 11 tables, REST API access |
| Biometrics | MediaPipe FaceLandmarker | Client-side, 468-point facial landmarks |
| Cryptography | Web Crypto API + Node crypto | SHA-256, HMAC-SHA256, ECDSA P-256, WebAuthn |
| Payments | Whop.com | Webhook-based subscription billing |
| Resend | Transactional emails and notifications | |
| Auth | API keys + WebAuthn/FIDO2 passkeys | Tiered access (free/creator/platform/enterprise) |
| Threat Intel | HIBP, NVD, RSS feeds | 7 external data sources aggregated |
| SEO | Programmatic generation | seo-template.js generates thousands of pages |
The dev team does not need to worry about these areas - Mark handles them directly:
This is POY Verify's defensible moat. No other biometric platform has explicit coercion resistance. The dev team must understand and build a system that detects when a legitimate user is being forced to authenticate under duress.
POY Verify will offer consent-based age threshold verification - NOT age guessing/estimation. This distinction is legally critical.
The dev team should have informed opinions on these questions:
Should we build native iOS/Android or use React Native/Flutter? Secure Enclave access is critical - can cross-platform frameworks access it reliably?
Current stack is Netlify Functions. At what scale do we migrate to a dedicated backend (ECS, Kubernetes, Railway)? What triggers that decision?
Supabase PostgreSQL works now. At what user count do we need connection pooling, read replicas, or a different database architecture?
MediaPipe runs client-side. Should we build custom liveness models? Where do we host inference - on-device only, or hybrid with server-side validation?
Users in the EU need data processed in the EU. How do we architect multi-region without duplicating infrastructure?
We need SDKs in JavaScript, Python, Go, Swift, Kotlin, and Rust. Build from scratch or auto-generate from an OpenAPI spec?
Currently computed at query time. At scale, should trust scores be pre-computed and cached? What invalidation strategy?
Currently in Supabase. At millions of stamps, do we need a purpose-built content-addressable store or blockchain-anchored timestamps?
rPPG heart rate estimation from webcam has inherent noise. What confidence threshold do we need before acting on a stress signal? How do we handle false positives (user had coffee, just exercised, is naturally anxious)?
Shadow environments need plausible fake data. Do we generate synthetic data at deployment time, maintain it manually, or use an AI pipeline to keep decoy records realistic?
Not every customer needs 5 layers. How do we architect CRP as modular layers that can be enabled/disabled per deployment without forking the codebase?
Document-based (ID scan) vs database verification vs biometric-adjacent signals. Which methods do we support, and how do we handle jurisdictions where ID scanning triggers biometric privacy laws?
Defense contracts require specific non-repudiation evidence formats. Do we build a generic audit export or target CMMC 2.0 specifically from the start?
| Category | Weight | Score (1-5) | Notes |
|---|---|---|---|
| Biometric engineering | 20% | ||
| CRP / physiological signal processing | 15% | ||
| Cryptography & security | 15% | ||
| Mobile development (iOS/Android) | 15% | ||
| Backend/API architecture | 10% | ||
| Privacy/compliance/age verification | 10% | ||
| ML model development (WASM/on-device) | 5% | ||
| SDK/developer experience | 5% | ||
| Communication & documentation | 5% | ||
| Weighted Total | 100% |
Build a minimal liveness detection flow:
Evaluate: code quality, security awareness, error handling, documentation.
No other platform has this. This is what wins defense contracts.
| Capability | Face ID | Worldcoin | Veriff | POYVerify CRP |
|---|---|---|---|---|
| Hardware-free auth | NO | NO | YES | YES |
| No biometric data transmitted | PARTIAL | NO | NO | YES |
| Physiological stress detection | NO | NO | NO | YES |
| Silent duress trigger | NO | NO | NO | YES |
| Honeypot session routing | NO | NO | NO | YES |
| Multi-party authorization | NO | NO | NO | YES |
| Context anomaly scoring | NO | NO | PARTIAL | YES |
| Dead man's switch re-verification | NO | NO | NO | YES |
| CMMC 2.0 non-repudiation | NO | NO | PARTIAL | YES |
| Consent-based age verification | NO | NO | PARTIAL | YES |
event_id, user_id, timestamp, baseline_hr, live_hr, hr_delta,
stress_flag, alert_tier (none/watch/alert/honeypot), context_hash
event_id, user_id, timestamp, trigger_type (duress_gesture/auto_css/multi_flag),
device_id, location_lat, location_lng, session_type (honeypot/live),
alert_sent_to, css_score