USDT WALLET DESKTOP BUILD

Docs · Security Model

Trust the keys, not the software.

This page describes the security model of the desktop wallet: what we assume about your device, what the app is responsible for, how network components are isolated, and which attacks we explicitly treat as out of scope.

Security model · Oct 14, 2025 Local keys · Multisig · Offline flows
SECURITY MODEL STRUCTURE

1. Overview & goals

The app is designed so that compromising our infrastructure alone is not enough to move your funds or recover your keys.

The security model aims to:

  • Keep seeds and private keys under your control, on devices you own.
  • Limit the blast radius of any single compromise (device, node, relay, or account).
  • Support high-security workflows such as offline signing, multisig approvals, and split storage.
  • Remain understandable enough for humans to reason about, not just auditors.

This document is about how the app is built to behave. For what data we process and on which legal basis, see the Privacy Policy.

2. Threat model & assumptions

Every design makes assumptions. This section states the main ones explicitly.

2.1 What we assume

  • Your OS and hardware are reasonably up to date and not already fully compromised.
  • You download the app from official channels and verify installers where possible.
  • You keep your seed phrase and backups physically separate from day-to-day devices.
  • If you use multisig, cosigners keep their keys on separate devices or accounts where possible.
  • You understand that anyone with long-term access to an unlocked device can cause damage.

2.2 What we do not assume

  • We do not assume our own infrastructure is perfectly trustworthy forever.
  • We do not assume the network path between you and our servers cannot be observed.
  • We do not assume single-factor authentication (a device password) is enough for high-value vaults.

3. Device & OS layer

The application does not ship its own kernel or hypervisor. It relies on your OS to enforce process isolation and basic access controls.

  • On desktop platforms, vault data is stored in OS-specific application data directories.
  • Where available, OS keychains / secure enclaves are used to protect encryption keys.
  • Clipboard access is limited to explicit actions (copying addresses, not seeds by default).
  • No background services are installed that continue running after app shutdown.

If your device is compromised by malware with full user privileges, any local wallet software can be at risk. For high values, use offline or split-device setups.

4. Vault, keys & encryption

Keys and seeds are generated, stored, and used locally, including for multisig wallets. There is no custodial wallet, and we cannot recover a lost seed for you.

4.1 Vault design

  • Each vault contains one or more wallets, plus metadata (labels, policies, history hints).
  • The vault is encrypted at rest using a key derived from your passphrase via Argon2id.
  • Where possible, a wrapping key from the OS keychain protects the derived key.

4.2 Key usage

  • Seeds and private keys never leave the process boundary unencrypted.
  • Transactions are assembled locally and signed in-memory; only signed payloads are sent out.
  • For offline signing, only unsigned payloads and signatures cross the air-gap.

4.3 Multisig wallets

  • Multisig wallets are defined as M-of-N sets of cosigners with independent keys.
  • The app tracks which keys are required and which have already signed a given transaction.
  • Signatures are combined locally; there is no server-side aggregation service that can sign on your behalf.
  • For high-value setups, cosigners should be distributed across devices and, ideally, operators.

For a practical step-by-step walkthrough of setting up an M-of-N vault, see the multisig guide.

For step-by-step backup and recovery instructions, see Keys, backups & recovery in the main documentation.

5. Application layer protections

The UI and internal APIs are designed to make risky actions explicit and reversible where possible.

  • High-risk actions (export keys, disable security checks) require explicit confirmation.
  • Send flows show human-readable summaries of recipients, amounts, and network fees.
  • Multisig approval flows show which cosigners have signed and which are still required before broadcast.
  • Advanced options (custom gas, endpoints, raw transaction hex) are opt-in and hidden by default.
  • Settings are grouped by risk; some changes require restarting the app to take effect.

UI safety checks are there to help, but they cannot defend against a fully compromised operating system or malicious hardware.

6. Network & backend boundaries

Network components can see metadata about your requests, but they are not able to move funds on their own.

  • Blockchain nodes / indexers see the same type of data as any node your wallet talks to.
  • FREE Gas relays see routed transactions, but only after you have locally signed them.
  • Update endpoints know the app version and (optionally) OS family, not your seed or balances.

Trust boundaries

Local app Holds keys and seeds. Signs transactions. Should be treated as high-value.
Nodes / indexers Provide chain data, may log IPs and request metadata, cannot sign on your behalf.
Relays Can see and forward signed payloads; cannot alter signatures without detection.
Update service Knows versions and platform; used to distribute metadata about new builds.

For endpoint URLs, protocols, and configuration examples, see Networking & endpoints.

7. Supply chain & builds

Compromised build or update infrastructure can be catastrophic. We treat this as a separate risk to manage explicitly.

  • Reproducible builds are a goal; where practical, we publish instructions and reference hashes.
  • Release artifacts are signed; the app can verify update metadata before suggesting an upgrade.
  • Dependencies are pinned and periodically reviewed; critical ones may be vendored and audited.
  • Build and signing keys are stored separately from general infrastructure credentials.

8. Hardening checklist

The following items are recommended for users managing significant funds or operating in high-risk environments.

Suggested practices

  • Use a dedicated device (or at least a dedicated OS account) for wallet operations.
  • Keep OS and firmware reasonably up to date; apply security patches promptly.
  • Use full-disk encryption with a strong passphrase or hardware-backed auth.
  • Separate “cold” and “hot” funds across different vaults or devices.
  • For large balances, consider M-of-N multisig with independent devices and/or people.
  • Consider offline / air-gapped workflows for very large balances.
  • Periodically test your recovery process with small amounts on a separate vault.

9. Incidents & reporting

If you suspect a security issue with the app, we want to hear from you in a way that keeps both of us safe.

  • Do not share your seed phrase, private keys, or full backups in any support channel.
  • Describe the issue, platform, and version; include reproduction steps where possible.
  • If you believe you discovered a vulnerability, use a private, encrypted channel if available.

Contact details are listed on the Privacy page and in the main docs. Response times may vary, but we do read and triage reports carefully.

10. Out of scope

No software can protect against everything. These risks are important but explicitly out of scope for the app to solve on its own.

  • Physical attacks, coercion, and legal compulsion in your jurisdiction.
  • Compromised hardware (malicious firmware, implants, random number generators).
  • Broader ecosystem risks such as chain-level reorgs or protocol failures.
  • Phishing and social engineering unrelated to the app itself.

The goal of this model is not to eliminate all risk, but to make the remaining risks explicit so you can plan around them.