Docs Open Console

Security

Non-custodial by architecture, hardened at every layer - here is exactly how U.CASH Pay protects money that never touches us.

Non-custodial architecture#

  • Funds go straight to your wallets. Payments are detected on-chain against addresses you control; the platform holds no balance and no key, on any tier
  • No platform-signed withdrawals, ever - payouts, teller payouts, and sweeps come from your own treasury; the platform only records and notifies
  • Even the relayer stays honest: on x402 settlements the relayer signs only a gas-paying wrapper around a buyer-authored message it cannot alter

Account security#

  • Two-factor and passkeys - 2FA from Account settings; WebAuthn passkey support is built in and rolling out (see Console Security)
  • Bank-style sessions - 30-minute idle timeout with warning, 12-hour absolute cap, single logout across the app family
  • Role-based access - every action permission-checked server-side (see Roles & Permissions); an audit log records staff actions
  • Secrets encrypted per tenant - processor keys, node macaroons, and exchange keys are encrypted at rest with a per-account key; webhook signatures never derive from it

Web hardening#

  • CSP with Trusted Types enforced on every page - DOM-XSS sinks reject unsanitized strings outright; violations are reported centrally
  • HSTS, nosniff, strict referrer policy, and frame protections across all surfaces
  • Sandboxed uploads - uploaded and legacy HTML is served in a strict CSP sandbox, isolated from sessions
  • SSRF-safe egress - webhook URLs must be public HTTPS hosts; internal, loopback, and metadata addresses are rejected before any request is made

Payment integrity#

  • Every incoming payment is verified on-chain - amounts, confirmations per chain, and sender match (for refunds) before completion
  • Underpayment rules are deterministic (see Underpayments) - nothing auto-completes short without your explicit policy
  • Signed webhooks with HMAC-SHA256 and event ids for replay protection (see Webhooks)
  • Hash replay guard - a transaction hash can never be submitted twice across your account
  • Sanctions screening list maintained on receiving addresses
  • Structured API errors and constant-time key comparison on authentication

Your part#

  • Turn on 2FA from Account settings; use a unique, strong password
  • Keep processor and wallet permissions to the smallest set of staff
  • Verify webhook signatures (it is two lines) and deduplicate on event id
  • Use testnets for integration work, not tiny mainnet sends