Infrastructure

How Embedded Wallets Work

When a user logs in through your app, NERO creates a non-custodial wallet using threshold cryptography. The private key is split into two shares at generation time:

• Device share — held on the user's browser, encrypted with a device-specific key
• Server share — held by the NERO MPC Auth backend, protected by HSM and distributed across nodes

Both shares must cooperate to produce a signature. The full private key sk = sk_A × sk_B (mod q) is never reconstructed during normal signing operations. The MtA (Multiplicative-to-Additive) protocol allows each party to compute partial signatures independently, which are then combined into a standard ECDSA signature.

Key Distribution Model

Security relies on three independent factors:

Lost share recovery: If the device share is lost but NERO is online, the user re-authenticates and the SDK restores the share from the backend. If NERO goes permanently offline, the recovery factor enables full offline key reconstruction.

Threshold guarantee: Compromising any single factor is insufficient to forge signatures. An attacker needs the device share AND the server share simultaneously to sign transactions.

Server-Side Architecture

The NERO MPC Auth backend is a production-grade Express.js service implementing the server side of MPC protocols.

Request Processing Pipeline

Every API request passes through an 11-layer middleware chain:

Data Layer

Key Storage

Server key shares are stored encrypted at rest:

Server share (plaintext, in memory only during signing)
    │
    ▼
AES-256-GCM encryption (MPC_ENCRYPTION_KEY)
    │
    ▼
HSM key wrapping (AWS KMS / GCP Cloud KMS)
    │
    ▼
PostgreSQL (mpc_party_states table)
    │
    ▼
Optional: Shamir sub-shares distributed across N nodes

The mpc_party_states table stores:

• Encrypted state blob
• Encryption salt and IV
• GCM authentication tag
• State commitment hash (for integrity verification)

Distributed Deployment

For high availability, the server share can be split into N sub-shares using Shamir's Secret Sharing:

• Sub-shares distributed across nodes in different regions
• M-of-N threshold required for reconstruction
• Each sub-share has its own per-share encryption
• Inter-node authentication uses HMAC-SHA256 (node ID + timestamp + signature)
• Coordinator node collects M sub-shares, reconstructs the share in memory, signs, then zeros the memory

Node roles:

• Standalone — single server (development/small deployments)
• Coordinator — orchestrates signing, collects sub-shares from workers
• Worker — stores sub-shares, responds to coordinator queries

Security Measures

Dual Protocol Architecture

The backend implements two independent MPC protocols:

Authentication Infrastructure

The backend supports 9 OAuth providers with full server-side implementation:

Plus passwordless methods: email OTP (via Resend), SMS OTP (via Twilio), and custom JWT verification.

Session management:

• JWT-based (access token + refresh token)
• Access token: 15 minutes default (configurable 1–60 min)
• Refresh token: 7 days
• Automatic token refresh at 60-second threshold
• Device-bound sessions with fingerprint verification

Privacy

• The only required stored identifier is an anonymized OAuth subject ID
• No user email or name is stored by default (configurable per project)
• Device keys are generated locally on the user's browser and never transmitted
• Share exchange during key generation uses ephemeral ECDH keys (discarded after protocol completion)

Billing & Metering

Usage is metered per Monthly Active Wallet (MAW):

Metered events: wallet creation, signing operations, key material exports. See the Dashboard for plan management.