MPC & WebAuthn

Custody-grade security with consumer-grade UX. Keys are split, signing is policy-gated, logins are phishing-resistant, and every transfer passes a real-time risk check.

2-of-2 MPC signing

Wallet keys never exist as a single secret. Each signature requires a 2-of-2 multi-party computation between the user's device share and Furlpay's server share. Neither party can move funds alone, and there is no full private key to leak.

• Device share — bound to the user's hardware, unlocked by a passkey.
• Server share — held under HSM policy, released only when policy passes.

Turnkey HSM policy

The server share lives behind a Turnkey HSM. A declarative policy engine enforces who can sign what, under which limits — evaluated inside the secure enclave before any co-signature is produced.

WebAuthn passkeys

Login uses WebAuthn / FIDO2 passkeys — fingerprint or Face ID, no passwords. The Relying Party ID is resolved from explicit server configuration (FURLPAY_RP_ID / Vercel deploy URL), never from the client-controlled Host header — the single most common WebAuthn deployment mistake, and the one that lets a reverse-proxy phishing origin bind credentials. Assertions verify against an allow-list of origins and RP IDs.

• Registration and assertion run through @simplewebauthn/server (origin, challenge, and signature-counter checks).
• Credentials are bound to the registrable eTLD+1, so they can never be replayed on another domain.

Signed sessions

A successful passkey ceremony mints a short-lived, HttpOnly session cookie — a signed JWT (jose, HS256) verified in edge middleware, so tampered or expired tokens are rejected before any handler runs. The signing secret is required in production; the app refuses to start with the weak development fallback.

Agentic payment security (x402)

Furlpay's x402 endpoints let AI agents pay per request — where the payment is the auth, so payment verification is the entire security boundary. Our verifier is hardened against the four attack classes documented in 2026 research (arXiv 2605.11781 / 2605.30998):

• Authorization — every field (amount, recipient, network) is checked server-side; the client's copy of the quote is never trusted.
• Binding — each quote carries an HMAC over (resource, method, amount, expiry), so a payment for one endpoint can't unlock another.
• Replay — quote IDs and EIP-3009 nonces are single-use with a short expiry window.
• Web-layer — the X-PAYMENT header is size-capped and strictly parsed; malformed input returns 400, never a free resource.

Real-time fraud — Sardine

Every transfer is scored by Sardine using device intelligence and biometric behavioural signals. High-risk actions trigger step-up MFA before the MPC co-signature is requested.

Gnosis Pay-class exploit prevention

Card and allowance flows are designed to prevent Gnosis Pay-style drain exploits: no unbounded approvals, per-authorization spend caps enforced at signing time, and settlement reconciled through the double-entry ledger so nothing moves without a matching entry.