Security & custody

Who controls the funds

Nexus Pay is a custodial collection service. Each payment gets a unique deposit address whose key is held by our signing service. Funds remain there until the settlement policy permits a transfer to the payout wallet you configured. During that window we control the funds.

During the pilot, signing keys are held in software on our own server, under a separate service account isolated from the public API and dashboard. They are not held in a hardware security module (HSM) or by a multi-party computation (MPC) custody provider.

Settlement wallets are versioned, changing one requires two-factor authentication, every owner is emailed, and a policy delay can be enforced before a new wallet takes effect. In-flight settlements keep the destination they were created with.

Keys

• The public API and dashboard never hold signing keys; they only hold receive-only extended public keys.
• Signing runs in a separate service, under its own service account and with no public network surface. It records the transaction hash before broadcasting and never issues a second transaction for the same instruction.
• Test and live environments use separate key hierarchies.
• Deposit addresses that unexpectedly carry code are refused funding and sent to human review.

Implemented protections

• Passwords hashed with Argon2id; sessions are server-side, revocable, and bound to an httpOnly cookie.
• Authenticator-app MFA with single-use recovery codes; required for platform administrators and for changing payout wallets.
• Login, MFA, and recovery routes are rate-limited; password reset with MFA enabled also requires a code and burns the link after repeated failures.
• Webhooks are HMAC-SHA256 signed over the exact bytes with a timestamp; endpoint URLs cannot point at private or metadata addresses and are re-checked at send time.
• Every sensitive action is written to an audit log with actor, time, target, and reason.
• Payments are credited only from chain evidence after network finality, exactly once; a double-entry ledger is reconciled against on-chain balances continuously.
• MFA and webhook secrets support authenticated encryption at rest, with encryption configuration required outside development and test environments.
• Changes to credited chain history place affected payments on hold. Recovery requires the original transfer to pass scanner verification again.
• Operational pauses exist for new invoices, credit decisions, and settlement, separately.

Supported tokens

On BNB Smart Chain, the USDT and USDC accepted are the Binance-Peg USDT and Binance-Peg USDC tokens: representations issued on BNB Smart Chain by Binance, not tokens issued there by Tether or Circle themselves. On Ethereum, USDT and USDC are the issuers' own contracts. Checkout always names the exact token and network to use.

Reviews and commitments

• Security review: an internal security review of the platform was completed in October 2026. An independent, third-party review is planned but has not yet taken place.
• Audits and certifications: none are claimed.
• Uptime commitments: none are made; see the status page.