Each account has a server-side custodial wallet. Secret keys are encrypted with a per-wallet data key derived through HKDF from a master key-encryption key that is held in the server environment, never in the database and never in the browser. Decryption and signing happen inside a single authenticated server function; the plaintext key exists only for the duration of that call and is never returned to a client.

Funds are separated into hot (operational float for settlement), warm (multisig-approved reserves), and cold (offline, out of reach of application code). Only the hot tier is reachable by automation, and it is sized to the settlement window rather than total balances. The warm tier graduates to an on-chain multisig before mainnet.

Balances are derived from an append-only double-entry journal rather than a mutable number. Every reservation, capture, refund, deposit, and withdrawal writes paired entries, so any drift between the ledger and on-chain state is detectable by reconciliation rather than hidden by an overwrite.

• Row-level security on every user-facing table, with role checks in a dedicated roles table — never on the profile record.
• Privileged operations run only in server functions behind an authenticated middleware; the browser never holds a service credential.
• HMAC-SHA256 verification on every public webhook and cron endpoint before any side effect.
• Rate limits on authentication, waitlist, rent, and withdrawal flows, keyed per identity and per address.
• Audit rows for signing events, administrative actions, and rental state transitions.
• Input validation at the server boundary on every mutation, independent of client-side checks.

Renter workloads run in provider-isolated containers or virtual machines. Providers are contractually barred from inspecting workloads, and connection credentials are issued per rental with a bounded lifetime so they expire when the rental ends.

A platform killswitch can pause rentals, withdrawals, or the whole marketplace within minutes. If an incident affects user funds or personal data we notify affected accounts and publish a post-incident summary on the status page once the immediate risk is contained.

Report vulnerabilities to security@gpu-network.xyz. Please include reproduction steps, affected endpoints, and impact. We acknowledge within one business day and aim to triage within five. Test only against accounts and funds you control, avoid denial-of-service and social engineering, do not access or modify other users' data, and give us reasonable time to remediate before publishing. Researchers who follow this policy will not face legal action from us. A funded bug-bounty programme with published reward tiers launches alongside mainnet.

The network is pre-mainnet. Third-party smart-contract and infrastructure audits are scheduled before mainnet settlement is enabled, and their reports will be linked here. Until then, treat balances on the platform as testnet-grade and keep long-term reserves in wallets you control. This page was last updated on August 2, 2026.