Mainnet validation is in progress. Payments and new API keys are disabled.View readiness

Security

Security controls and open gates.

This page separates controls implemented in code from deployment checks and work that is still pending. It was reviewed on 2026-08-23 and does not claim an independent audit.

Implemented security design

Hashed API keys

Keys are stored as bcrypt hashes. We cannot recover a plaintext key — even with full database access. Lost a key? Revoke and rotate.

HMAC-signed webhooks

Every webhook payload is signed with HMAC-SHA256. Verify the signature before fulfilling an order. Verification examples are provided in the integration documentation.

Layered request throttling

The API applies a 100-request-per-minute baseline and stricter limits on sensitive authentication and wallet routes. Per-key isolation is not yet claimed.

Service exposure gate

PostgreSQL, Redis, wallet RPC, and worker interfaces are designed for local or private binding. The release runbook requires operators to verify those bindings before launch.

Encrypted wallet material

Wallet recovery material is AES-256-GCM encrypted at rest. Separating its encryption key from JWT signing remains a required custody milestone before funded launch.

Revocable API keys

Merchant API keys can be created, listed by prefix, revoked, and monitored by last-used time. Read-only key scopes are not available yet.

Current control status

Payment availability, custody readiness, and market information are separate release boundaries.

API secrets
Implemented · bcrypt-hashed and shown only when created
Webhooks
Implemented · timestamped HMAC-SHA256 signatures
Sessions
Implemented locally · HttpOnly, SameSite=Strict cookies
Wallet encryption
Partial · encrypted at rest; separate key still pending
Payments
Release locked · funded chain canaries not complete
Exchange execution
Disabled · legal, liquidity, and custody gates pending

Review boundary

Verified locally

API-key hashing, webhook signing, tested personal-wallet and merchant-dashboard tenant paths, cookie isolation, migration checks, and disabled execution gates have automated evidence.

Operator verification required

TLS, private service bindings, backups, restore rehearsal, worker liveness, and rollback retention must be confirmed in staging and production.

Independent review pending

No independent security or custody review is claimed. Funded payment and exchange capabilities remain disabled until critical and high findings are closed.

Known release blockers include child-address custody reconciliation, per-output deposit identity, deterministic withdrawal recovery, descriptor-range coverage, wallet-key separation, and worker-health deployment gates.

Responsible disclosure

Found a vulnerability? Report it to security@xmrgate.com. We do not pursue good-faith researchers who follow the boundaries below.

  • Use a secure, throwaway email for the report
  • Include a clear proof of concept where possible
  • Allow 90 days for remediation before public disclosure
  • Do not access merchant data beyond what is needed to demonstrate the issue

Out of scope

  • · Volumetric DDoS, brute force, or rate-limit testing
  • · Reports about missing security headers without impact
  • · Self-XSS in third-party password managers
  • · Findings in dependencies without a working exploit

Our target is to acknowledge reports within 72 hours.

Have a question about our setup?

Enterprise customers get a written security overview on request.

Get in touch