ICONex Wallet · Security & Recovery

Security & recovery for ICONex

How ICONex treats keys, what can realistically go wrong, and how to design recovery habits that survive real-world failures.

This page is intentionally technical: threat model, key lifecycle, common attack surfaces, and incident-response playbooks for self-custody on the ICON network. There is no “forgot my password” here. For policy details, see the terms of use and privacy posture.

Download & install Docs

Section 1 · Overview

How ICONex thinks about security & recovery

ICONex is a self-custody wallet: there are no logins, no server-side accounts, and no password reset. There are only keys, signatures, and your ability to recover them when something breaks.

Design constraints:

  • Keys never leave your device unencrypted. There is no backend that can “give your wallet back” if everything is lost.
  • Signing is local and human-readable. The app focuses on intent screens instead of raw hex blobs.
  • Recovery is a workflow. The 12-word phrase is treated as a long-lived secret with its own lifecycle and failure modes.

Security posture in one sentence:

If an attacker gets your encrypted wallet file, they still need your password. If they get your recovery phrase, they do not need anything else.

Assumptions you should share:

  • Your OS is reasonably up to date and not obviously compromised.
  • You can physically protect at least one offline copy of the recovery phrase.
  • You are willing to move funds to a new wallet if you suspect compromise.
If you lose both your device and all copies of your recovery phrase, your funds are effectively gone. ICONex cannot regenerate your keys from an email or username.

Section 2 · Threat model

What ICONex is trying to protect you from

A wallet cannot defend against everything. This section defines which classes of attacks are in scope, and when the only safe answer is to assume compromise and migrate.

Main attacker types:

  • Remote / dApp attackers. Control a website, smart contract, or RPC endpoint, but not your device.
  • Local malware. Have code execution on your computer: keyloggers, clipboard hijackers, screen-recorders.
  • Operational mistakes. Nobody is attacking you; you just lose, expose, or never verify your backups.

Remote / protocol layer

Malicious dApps, fake frontends, or RPC nodes can try to trick you into signing something different from what you intended. ICONex responds by emphasizing readable intent: asset, amount, recipient, and contract action.

Local compromise

If an attacker can read your screen and keystrokes, they can usually steal the recovery phrase or password when you use them. No desktop wallet can fully fix a rooted OS.

Out of scope (honest limitations):

  • A fully compromised OS with persistent malware and remote control.
  • Physical coercion or social scenarios where you are forced to reveal the phrase.
  • Irrecoverable loss of all backups of the recovery phrase.
For high-value setups, treat security as layered: hardened OS, minimal dedicated machine, good backup hygiene, and clear runbooks for what to do if something feels off.

Section 3 · Keys & storage

Key lifecycle: from entropy to backups

ICONex treats keys and the 12-word recovery phrase as long-lived secrets. Understanding their lifecycle helps you see where attacks and mistakes can land.

What happens to your keys:

  1. Generation. The wallet requests secure randomness from the OS and derives a seed. From the seed, an HD wallet is formed (one seed, many addresses).
  2. Encoding. The seed is encoded as a 12-word human-readable mnemonic: your recovery phrase.
  3. Encryption at rest. Private keys are stored encrypted on disk. The encryption key is derived from your wallet password using a salted key-derivation function (KDF) with multiple iterations to slow down brute-force attempts.
  4. Decryption in memory. When you sign a transaction, keys are decrypted in RAM, used to produce a signature, and then released.

Phrase vs password vs device:

  • Recovery phrase — can recreate your wallet on any compatible client. Anyone who has it has full control.
  • Wallet password — protects the encrypted keys on this machine only.
  • Device / OS — if compromised, can leak both phrase and password the moment you use them.
If an attacker steals only the encrypted wallet file, they still need your password. If they ever see the recovery phrase, encryption and passwords no longer matter — the phrase is the root of everything.

Section 4 · Attack surface

How people actually get drained in practice

Most real losses are not cryptographic failures. They’re phishing, malware, and backup mistakes. Here are the patterns that repeat.

Phishing dApps & fake support

Scammers clone UI from real services and then:

  • Ask for your 12-word phrase in a web form.
  • Ask for a private key “to verify ownership” or “unlock airdrops”.
  • Ask you to install remote-access tools so they can “fix” the wallet.

No legitimate support or dApp ever needs your full recovery phrase or private key. Treat any such request as a guaranteed scam.

Clipboard & keylogging malware

Once running on your machine, malware can:

  • Replace pasted recipient addresses with its own.
  • Record your wallet password as you type it.
  • Capture the recovery phrase via keylogging or screenshots.

Keep OS and browser patched, avoid pirated software, and always verify the address inside ICONex before signing.

Tampered builds / supply chain

Attacker swaps the official download with a build that:

  • Exfiltrates keys after wallet creation.
  • Displays fake balances or history.
  • Alters transaction details silently.

Always verify checksums and download only from official links. For high-value setups, prefer building from source and verifying signatures where available.

Broken or non-existent backups

The most common “attack” is simply not having a working backup:

  • Phrase written once in a notebook and later lost.
  • Only copy is a screenshot synced to multiple cloud accounts.
  • Phrase never tested with a real restore.

Make at least two offline copies and prove they work in a low-stress test restore before you trust them.

Operational signals something is wrong:

  • Outgoing transactions or approvals you don’t remember initiating.
  • Explorer shows movements not reflected in your mental model.
  • Wallet UI suddenly looks or behaves differently right after an “update” you didn’t expect.
If you suspect compromise, stop doing anything from the affected machine. Move remaining funds from a different, clean device using the recovery phrase, and treat the old wallet as permanently untrusted.

Section 5 · Recovery

Recovery and incident-response playbook

Recovery is not “type 12 words and pray”. Treat it as a repeatable, testable process you rehearse while things are calm.

Baseline restore (no compromise assumed):

  1. On a machine you trust, download ICONex from official links and verify its checksum.
  2. Choose Restore wallet and carefully enter the 12-word phrase in the correct order.
  3. Set a new, strong password you don’t re-use elsewhere.
  4. Compare at least one known address against a previous record or explorer entry.
  5. Send a small test transaction to confirm you can still move funds.
Doing at least one dry-run restore — with a small balance — is the best way to prove your backup works before you ever rely on it during an incident.

When compromise is suspected:

  1. Assume the compromised machine can read everything you type or see.
  2. On a separate, clean device, install ICONex and restore the wallet using the recovery phrase.
  3. Create a new wallet with a fresh phrase.
  4. Move all remaining funds from the old wallet to the new one. Treat this as urgent — the attacker may already be trying to do the same.
  5. Destroy any copies of the old phrase that may still be lying around. Only the new phrase remains valid.
If the recovery phrase is exposed, the wallet is compromised by definition. There is no password change that can fix this; only migration to a new wallet is safe.

Section 6 · Hardening

Hardening checklist for everyday and high-value users

You don’t need perfect opsec. Small improvements in where and how you run ICONex can drastically reduce your risk.

Baseline hygiene (everyone):

  • Keep OS and browser reasonably up to date.
  • Download ICONex only from official links and verify checksums.
  • Use a long, unique wallet password (password manager is fine for the password; not for the phrase).
  • Write the 12-word phrase on paper or metal; keep at least two copies in separate locations.
  • Never store the phrase in screenshots, cloud notes, or email.

For many users, just doing the above already puts you ahead of most of the ecosystem in terms of risk.

Additional steps for high-value setups:

  • Use a dedicated OS user or even a dedicated machine for crypto activity.
  • Keep a “hot” wallet for day-to-day use and a separate “cold-ish” wallet for long-term holdings.
  • Store recovery phrases on durable media (e.g., steel) rather than just paper.
  • Keep written instructions for what to do if compromise is suspected, including which devices to use and which addresses are “safe”.
  • Consider multi-person processes for accessing the phrase (e.g., two trusted people present when reconstructing).
Think of security as a spectrum: it should match the value you’re protecting. As balances grow, revisit your setup and consciously re-evaluate your threat model.

Section 7 · FAQ

Security & recovery: quick answers

These are the questions that usually appear right after someone moves real funds into self-custody for the first time.

  • Can ICONex support recover my wallet if I lose the phrase? No. ICONex is non-custodial: the team never sees or stores your keys or phrase. Without a recovery phrase, private key, or keystore backup that you created, the funds are not recoverable.
  • Is a screenshot of the phrase an acceptable backup? Strongly discouraged. Screenshots usually end up in cloud photo backups and multiple devices, expanding the attack surface dramatically. Prefer offline physical storage (paper or metal) in locations you control.
  • What if the computer with ICONex installed is stolen? If the phrase never lived on that device, the main risk is that the thief can try to brute-force the local encrypted wallet using your password. Restore from the phrase on a clean machine, move funds to a new wallet, and consider the old one compromised.
  • Is it safe to import my phrase into multiple wallets/clients? Every additional client that sees the phrase increases risk. For most users, use a single primary wallet and treat imports into others as temporary, migration-only steps, not long-term multi-client usage.
  • I think I signed something malicious. What should I do now? Disconnect from the suspicious site, from a clean device restore the wallet using the phrase, move all remaining funds to a new wallet with a new phrase, and keep transaction hashes for later review. Consider the old wallet permanently tainted.

Section 8 · Community & reports

Where to discuss security and report issues

Development, support, and security-related notes live in public channels. Always verify you are in an official space before acting on any advice.

For questions and “is this normal?” moments:

  • Email: support@iconex.io for private or account-specific issues.
  • GitHub: issues for bugs and security-relevant behavior.
  • Community chat: get second opinions before signing or migrating large balances.
When sharing screenshots, remove or blur balances, full addresses, and phrases. Never paste recovery phrases or private keys into chats — even if someone claims to be “official support”.

Staying aligned with current risk:

  • Follow release notes for security-relevant changes (signing, staking, network parameters).
  • Update ICONex only from official links, not from pop-ups or ads that claim you are “out of date”.
  • Bookmark explorer, docs, and download URLs yourself to avoid look-alike domains.

If the app ever behaves in a way that contradicts this page or the official docs, slow down, verify the build, and ask a public channel for confirmation before proceeding.