Z Wallet is a fully client-side, non-custodial cryptocurrency wallet designed for the secure storage and transfer of USDT (Tether) on the TRON (TRC20) blockchain. The system operates entirely within the user's browser — no private key material, mnemonic phrases, or sensitive data is ever transmitted to any external server at any time.

The wallet employs a layered cryptographic architecture: AES-256-GCM for authenticated symmetric encryption of wallet data at rest; PBKDF2-SHA256 with 600,000 iterations for memory-hard key derivation; HMAC-SHA256 for domain-separated password verification without exposing the encryption key; the W3C SubtleCrypto API as the underlying cryptographic engine — providing hardware-accelerated, non-extractable key objects and OS-level entropy; and a constant-time comparison function to eliminate timing side-channels on authentication.

Private keys are never stored. Instead, a BIP-39 compliant mnemonic seed phrase is encrypted and stored locally. The wallet address is derived deterministically from the seed on every unlock — it is never persisted to disk — eliminating the need to store sensitive material beyond the single encrypted vault blob.

Z Wallet supports four interface languages: English, Kurdish (Sorani), Arabic, and Persian (Farsi) — with full RTL layout support for right-to-left scripts. The application is a single self-contained HTML file with zero external runtime dependencies, making it auditable, portable, and censorship-resistant.

The cryptocurrency ecosystem has seen explosive adoption of USDT on the TRON network, which offers sub-cent transaction fees and near-instant settlement. By 2024, TRON carried more USDT volume than any other blockchain — over $50 billion in daily transfer volume. Yet the majority of users rely on custodial wallets: exchanges and web services that hold private keys on behalf of users.

This creates systemic risk. Exchange hacks (Mt. Gox: $450M; FTX: $8B; Binance 2019: $40M), regulatory seizures, and platform insolvency have collectively caused hundreds of billions of dollars in user losses. The fundamental problem is one of key sovereignty: when a third party holds your private key, they hold your assets.

Existing browser-based wallets often introduce security anti-patterns: storing keys in plaintext localStorage, using weak or absent encryption, transmitting key material to remote services for "cloud backup," or relying on unaudited third-party JavaScript libraries that introduce supply-chain risk. Z Wallet is architected from first principles to eliminate each of these attack surfaces.

Z Wallet follows a single-page application (SPA) architecture with zero external runtime dependencies. All cryptographic operations use the browser's native W3C Web Crypto API (SubtleCrypto interface), which provides hardware-accelerated algorithm implementations with non-extractable CryptoKey objects — keys that exist in the browser's secure key store and cannot be read by JavaScript code.

Layered Architecture:

Storage Layer — Vault Schema (localStorage):

Binary Layout of Encrypted Blob:

The cryptographic stack is composed of four independent, composable layers — each addressing a distinct security property:

Layer 1 — Key Derivation: PBKDF2-SHA256 (RFC 8018 / NIST SP 800-132)

User passwords are never used directly as encryption keys. PBKDF2 transforms the password into a 256-bit AES key using a 256-bit cryptographically random salt and 600,000 iterations. The 2023 NIST SP 800-132 recommendation for interactive authentication is 600,000 iterations of SHA-256. This iteration count means that an attacker with a GPU cluster performing 10 billion PBKDF2 operations per second would require approximately 17 hours to exhaust a 6-character password space — and years for a strong 12-character password.

Layer 2 — Authenticated Encryption: AES-256-GCM (FIPS 197 / NIST SP 800-38D)

AES in Galois/Counter Mode provides both confidentiality (no plaintext revealed) and authenticity (any modification to ciphertext is detected). The 128-bit GCM authentication tag ensures integrity. A 96-bit IV is generated freshly for every encryption operation — IV reuse with the same key is the primary failure mode of GCM, so fresh random IVs are mandatory. Additional Authenticated Data (AAD) — composed of the version byte and salt — binds the ciphertext to its metadata, preventing version-downgrade splicing attacks.

Layer 3 — HMAC Verifier: HMAC-SHA256 (RFC 2104 / FIPS 198)

A HMAC-SHA256 signature is derived using a separate PBKDF2 key (iteration count offset by +1 for cryptographic domain separation). This verifier is used for fast password verification before full decryption, preventing unnecessary KDF computation and providing a semantically distinct authentication signal from the encryption layer.

Layer 4 — Timing Safety: Constant-Time Comparison

All cryptographic equality comparisons use a byte-by-byte XOR accumulation function that processes all bytes regardless of early mismatch position. This eliminates timing side-channels that would otherwise allow an attacker to measure password correctness one character at a time.

Z Wallet implements a deterministic key model. The root of trust is the mnemonic seed phrase — a sequence of 12 words drawn from the BIP-39 English wordlist (2,048 words). The phrase is generated using crypto.getRandomValues(), the browser's CSPRNG interface backed by OS entropy.

Entropy Analysis:

Word Selection Implementation: Each of the 12 words is selected by generating a 32-bit uniformly random integer via crypto.getRandomValues(new Uint32Array(12)) and computing word = BIP39_WORDLIST[value mod 2048]. The modulo bias for a 2,048-word list with 32-bit integers is negligible: 2³²/2,048 = 2,097,152 exact multiples with zero remainder.

Verification Protocol: After generation, the user is asked to confirm two randomly chosen words from the phrase before the wallet is created. This prevents accidental creation of wallets where the user did not actually record the phrase.

Import Validation: When importing, Z Wallet validates every word against the full BIP-39 list. Invalid words are identified individually, preventing import of corrupted phrases that would silently derive a different address than intended.

Recovery Flow:

Z Wallet employs a defense-in-depth model — no single mitigation is considered sufficient. Multiple independent controls are layered so that defeating one does not compromise the system. The following table enumerates the complete threat model:

Z Wallet implements a local transaction ledger stored separately from the encrypted vault in localStorage. This ledger contains only transaction metadata — no cryptographic key material is ever present.

TRC20 Address Validation: All recipient addresses are validated using the TRC20 Base58Check format before any transaction can proceed. Validation rules: (1) must begin with the character T; (2) must be exactly 34 characters in length; (3) must use only Base58 characters (excluding ambiguous characters 0, O, I, l); (4) checked via regex /^T[1-9A-HJ-NP-Za-km-z]{33}$/.

Amount Validation Rules:

Transaction Record Schema:

Z Wallet is designed with privacy by default and privacy by design principles as defined in ISO/IEC 29101. The application transmits no data to any server during normal wallet operations. No telemetry, no analytics, no remote logging — the application is behaviorally equivalent to a local native application.

Data Minimization: Only the minimum data required for wallet function is stored locally. The vault contains only the encrypted seed phrase and wallet name. The transaction ledger contains only the data shown to the user in the history view. No IP addresses, browser fingerprints, device identifiers, or behavioral data are collected or retained.

Local-Only Storage: All data resides in browser localStorage — scoped to the page origin, inaccessible to other origins, and never transmitted over any network. The application works entirely offline after initial load.

Z Wallet v2.0 has been designed and self-reviewed against the following security standards and compliance frameworks. An independent third-party security audit is scheduled for v2.1 prior to public production release.

Implemented Controls by Standard:

In-Application Audit Log: Z Wallet maintains an in-memory (non-persistent) audit log of security-sensitive events: password changes, phrase reveals, wallet recovery, and send operations. This log is available in the Settings → Security panel during the active session and is cleared on lock or page close.

A core tension in cryptographic system design is the conflict between security cost and user experience. Higher PBKDF2 iteration counts make brute-force harder — but also make every legitimate unlock slower. Z Wallet resolves this with a two-phase authentication protocol:

Phase 1 — Fast HMAC Verification: Before performing the computationally expensive full AES-GCM decryption, the application computes a HMAC-SHA256 verifier using the same PBKDF2-derived key family. An incorrect password fails at this stage in the same time as a correct one (constant-time), providing an early rejection signal without leaking timing information.

Phase 2 — Full Decryption (on correct password): Full AES-256-GCM decryption of the vault is performed only after the HMAC verifier passes. The decrypted payload is held in memory for the session duration.

Measured Performance (2024 mid-range hardware):

UX Design Principles:

The interface is designed around three principles: (1) Clarity — every security-relevant action (send, phrase reveal) requires a confirmation step; (2) Feedback — password strength is shown in real-time, lockout countdowns are displayed; (3) Accessibility — full RTL layout support for Arabic, Kurdish, and Persian users; minimum touch target size of 42px; high-contrast color system with a minimum 4.5:1 contrast ratio.

Z Wallet v2.0 introduces full internationalization (i18n) support for four languages, selected to serve the primary user communities in the Middle East, Central Asia, and globally:

Technical Implementation:

The i18n system uses a data attribute pattern: HTML elements are annotated with data-i18n="key" attributes. The setLang(code) function performs a DOM traversal, updating the textContent of all annotated elements from the active translation dictionary. RTL languages automatically set document.dir = 'rtl' and html.lang = code, triggering CSS layout mirroring for all flex/grid containers.

RTL Layout Considerations: All sidebar navigation, topbar elements, form fields, and modal dialogs use CSS logical properties and flex-direction reversals under the [dir="rtl"] selector. Font stacks for Arabic-script languages default to system fonts (Segoe UI Arabic, Arial Unicode) when Google Fonts are unavailable, ensuring correct rendering offline.

Language Persistence: The selected language is stored in localStorage under a separate key and restored on next load, providing a persistent preference across sessions.

Translation Coverage:

Open Source Commitment: Z Wallet will be published as open-source software under the MIT License. The single-file architecture is intentionally designed for auditability: the complete application — all HTML, CSS, JavaScript, and cryptographic logic — fits in a single file that any developer can read, verify, and run locally without a build system.

Z Wallet is provided as an open-source software tool for personal use. It is not a financial institution, exchange, money services business, or custodial service. It does not hold, custody, control, or transmit user funds at any time.

Users are solely responsible for: (1) the security and integrity of their device and browser environment; (2) safeguarding their mnemonic recovery phrase — loss of the phrase means permanent, unrecoverable loss of access to all associated funds; (3) compliance with applicable laws, regulations, and tax obligations in their jurisdiction; (4) the accuracy of recipient addresses — cryptocurrency transactions on the TRON network are cryptographically irreversible once confirmed.

No Warranty: This software is provided "as is" without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose, and non-infringement. In no event shall the authors be liable for any loss of funds, data, profits, or other damages arising from the use or inability to use this software.

Blockchain Irreversibility: Cryptocurrency transactions cannot be reversed, cancelled, or recalled after broadcast. Z Wallet implements a mandatory confirmation step before any send operation, but users remain solely responsible for verifying recipient addresses independently of any application-layer display.