NIXWALLET

Privacy Starts At The Wallet

Fhenix makes it possible to run wallet logic on encrypted balances, but someone still had to ship the wallet experience: onboarding, keys, wrap/unwrap, confidential transactions, dApp approvals, WalletConnect, etc.

• Gap — Standard wallets only move plaintext ERC-20s; every amount is a billboard on a public chain.
• Goal — A wallet flow that feels like a normal EVM wallet while speaking FHERC20 and coFHE.
• Principle — Self-custodial, local-first, no wallet backend — only your RPC and the chain.

Public Chains, Public Amounts

On L1, addresses and tx metadata are visible like any EVM transaction. For normal ERC-20s, transfer amounts and balances are easy to read from logs and explorers.

• NixWallet does not promise full anonymity — it targets amount / balance confidentiality for the confidential token leg.
• Users still need a clear story: what is encrypted vs what stays public.

FHE & FHERC20

Fully Homomorphic Encryption lets contracts update token state from ciphertext — observers do not see confidential balances and transfer amounts the same way as on a classic ERC-20.

• Wrap — Lock an underlying ERC-20 and hold balance as encrypted FHERC20 (e.g. USDC → cUSDC).
• coFHE — Client encrypts inputs; decryptForView for UI; decryptForTx for proofs the contract accepts.

Shield → Use → Unwrap

Everything in the product maps to three pillars users can demo end-to-end on testnet.

• Shield — Approve the wrapper, call shield, receive confidential balance.
• Use — confidentialTransfer with an encrypted amount; reveal balance in UI when you choose.
• Unwrap — unshield, then claimUnshielded / claimUnshieldedBatch to recover underlying ERC-20.

Wrapper Registry

FHERC20WrapperRegistry is an on-chain factory: the first user to wrap a new ERC-20 pays deployment gas for that token’s wrapper; everyone else reuses the same contract.

• No manual “deploy my confidential token” step for each user.
• Hardhat-deployed Solidity in-repo — same version control as the extension.

Chrome Extension

Built for side panel constraints: fast UI, encrypted vault at rest, background worker for auto-lock, RPC proxy, permissions, and approval queue.

• Vault — AES-GCM + PBKDF2; keys in memory only while unlocked.
• dApps — EIP-1193 / EIP-6963 injection; connect, sign, typed data, transaction, and network switch requests appear inside NixWallet.
• Product — Send/receive, activity, token management, address book, batch unwrap UX, and WalletConnect request handling.

Tech & Networks

Ships across Ethereum Sepolia, Base Sepolia, and Arbitrum Sepolia with network-aware RPC, registry addresses, and chain switching.

Requests Stay In NixWallet

The companion dApp is a live showcase for any external site integrating NixWallet: it initiates connect, transfer, approve, wrap, reveal, confidential transfer, unwrap, and claim — but never holds keys or trusted approvals.

• Injected + WalletConnect — EIP-6963 discovery, eth_* RPC, and Reown sessions; NixWallet owns the confirmation surface.
• Unlock gate — requests can be visible while locked, but approval is blocked until unlock.
• Activity — injected dApp and WalletConnect submissions recorded alongside wallet-native history.

Thank You

Repo, demo, and contact.