Unhackable: A Web3 Security Setup for $1,000 and 4 Hours

An unhackable environment

Unless you’re actively doing something degen on-chain, there usually isn’t a good reason to hold funds on-chain at all. If you don’t need to touch a smart contract, you’re not building, testing, deploying, or interacting with anything on-chain as part of your actual work then just buy the ETF little bro, or use managed custody. Outside of that, every hour spent guilt-tripping normal holders into becoming amateur cryptographers has a cost, and some fraction of those people get it wrong, which is somebody’s savings teleported to a threat actor.

But if you’re a developer or anyone for whom “just don’t self-custody” isn’t an option because touching contracts is the job. Then less than $1,000 in equipment you may already own arranged so that a single mistake costs you a few hours in key rotations and a DBAN, not your funds.

A majority of job offerings and messages for smart contract developers are potential attack vectors. A casual message that asks you to clone a repo and npm i or open it in your editor is enough to get fully pwned and threat actors use these methods specifically, because… it works?

A malicious postinstall script in an npm package runs the moment you npm install, instantly your browser’s saved wallet passwords, SSH keys, cloud credentials, and any hot seed phrases sitting in a text file is now sent to some c&c server.

A malicious VS Code workspace can do the same via a recommended extension or an auto-run task. You never have to knowingly execute anything. O3 Security caught exactly this in August 2026.

Installing a malicious npm package the normal way can similarly fuck you up through a supply chain attack. Not only fucking your device and funds up but will pwn your entire user base through the same mechanism. A piece of unrelated software on the same machine can be the entry point too. These are some of the ways you and your users end up compromised by opportunistic hackers and state-sponsored threat actors alike.

I see people getting drained for massive amounts of wealth constantly, larger accounts, smaller accounts, developers, anyone. Even one of my developer friends who is very privacy focused got fucked. It doesn’t matter how smart or threat-conscious you are, one slip-up can cost you.

If you plan on midcurving this advice then it’s not about if you get pwned, it’s when. Again I will reiterate, if you do not live on-chain, are not security conscious or are too lazy to spend the time to harden your setup then PLEASE just buy the ETF.

If you live on-chain, have one machine where you dev, game and do crypto transactions for, have a net worth that’s worth caring and protecting and can spend a little time learning then this post is for you! $1000 or less to have your funds completely protected and secured in 3 steps (or your money back! (jk?)).

1. Isolated devices

Firstly, I want to differentiate the terms I will use throughout. A hot wallet is a wallet that is on a device that is a normal EOA 1/1 signable wallet (default metamask, rabby, ambire etc), this is the most unsafe type of wallet, one bad blind sign and all of your shit will get permit2 swept up in the next block. A cold wallet is a hardware wallet that requires physical access to the key to be able to use, the mnemonic/private key is kept on the device and is not available to be viewed on the wallet extension this is much safer than a hot wallet. A isolated wallet is typically a hot wallet but used in a way whereby the device is completely isolated from external software outside of the default OS, this is safer than a hot wallet but weaker than a cold wallet. A vault is a safe wallet multisignature that requires multiple signatures to use.

Have a separate isolated stock OS computer, with nothing on it except a browser and the wallet extension of your choice. It can’t be truly air-gapped due to the need to be able to sign and broadcast transactions. Everything you can do to lock down the OS and applications you should do as this reduces what an attacker can reach if they ever do get code execution on it.

• no external software.
• no browser extensions (other than a wallet).
• no browsing or logging into accounts on it.

It does… nothing???

That’s the whole point of an isolated device. There are some technologies that extend this further so that the isolated device is truly airgapped by using QR codes to move signing payloads from the airgap to the broadcasting device, but that might be a bit too tinfoil for this guide, potentially consider this if you have 7 figure+ net worth.

You’ll also want a second isolated device. Asking you to have 3 computers might seem like a bit of an ask, but even a modern factory reset phone or tablet works well as a redundant signer that doesn’t share a failure mode with the first. Picking these up second hand can also reduce the amount of funds required, but similarly this needs to be out of reach of your family and stored safely.

The point of isolation is that the attack above (malicious repo, malicious npm package, compromised unrelated software) only works if it can run somewhere that matters. If your dev machine gets popped, it should have zero access or relation to your wallets. Your Facebook, Discord and Runescape account might get jacked but that is the extent of the damage, you keep all of your funds.

Keep a VM ready for if when you want to run something goopy, not on your dev machine. Make a snapshot to make restoring to it easy after you’ve done your ‘dirty work’.

There is a tool that I’ve heard of but not really used called scanrepo.dev which supposedly looks at malicious intent in repos, but you should not rely on this and again, if you choose to run something that you are not sure of this should be done in isolation within a VM.

My final point on isolation is, occasionally we need to do things fast as fuck, but we do not want to compromise on our assets safety. This is simply a case of moving from funds from our safe to a hot wallet, doing our transactions and then moving our bounty back to the safe. Funds are still safe and we’ve managed to transact instantly. There’s obviously a tradeoff from having your funds not be instantly drained, but similarly we can just counter that by doing that business on a hot wallet, you’ll need to properly identify what things need to be done on a hot wallet vs using your safe.

2. Hard vs soft wallets security

Your isolated devices as an additional hardening property should be signing through a hardware wallet. Sometimes this is a harder property to achieve because you need multiple hardware wallets, but at least one of your isolated devices should be using a hardware wallet, the other two signers can get away with being isolated signers.

Moving onto our dev repo environments. We do not want to store private keys or mnemonics and we can achieve this easily with whatever Ethereum development framework we are using.

Do not put any of your mnemonics in a password manager (PWM) PLEASE GOD DO NOT DO IT. A PWM can be phished, breached, even an offline PWM puts your seed a single master password away from anyone who gets it that can be easily bruteforced. Write it on paper, stamp it in metal, whatever, just put that in the physical safe and leave it there. The same rule applies to anything else genuinely sensitive, never let it touch a disk.

A passphrase (the BIP-39 “25th word”) on your seed adds a layer that survives even a found-and-read seed phrase, as long as the passphrase itself lives somewhere separate - memorized, or split from the phrase physically. Some people have found that splitting a BIP-39 phrase into multiple locations is also a decent way to add a layer of security, but you must also be wary of potentially losing this key.

Foundry

Supports it natively, no plugin required. Drop --private-key entirely:

forge script script/Deploy.s.sol --rpc-url $RPC_URL --ledger --broadcast

Foundry prompts you to plug in the device, open the Ethereum app, and physically confirm on-screen. Foundry’s own best-practices guide recommends exactly this split.

Hardhat

Use the official @nomicfoundation/hardhat-ledger plugin. Instead of an accounts: [PRIVATE_KEY] array, point the network at the device’s public address.

networks: {
  mainnet: {
    url: process.env.RPC_URL,
    ledgerAccounts: [
      "0xYourHardwarePublicAddressGoesHere"
    ]
  }
}

3. Safe multisig / signers

Set up a Safe with a 2-of-3 (or similar) threshold, signed by your isolated PC, your isolated phone, and optionally one more hot device. It’s not recommended to put more than X hot devices on the signer list, but you can get away with it if your isolated signers alone already satisfy the threshold - e.g. a 2-of-3 where 2 of the 3 are fully isolated means a compromised third (hot) signer still can’t move anything on its own.

At this point if you have followed these 3 main steps, you are completely unhackable, as long as 2 of your devices are never compromised, a hacker will never be able to capture your funds. If one of your devices is compromised, you will rotate that key and carry on with your day. Only if 2 of your 3 signers are compromised at the exact same time before you can rotate keys will you be having an extremely bad day! As we said though, two devices are going to be isolated and one will be cold, so in theory this will never happen.

It may also be useful if you have an additional hardware wallet to keep this offsite somewhere where you can easily access it.

Safe has a testnet option, so I would recommend playing with this and testing your recovery flow before deploying a mainnet safe. Can you still get to your isolated devices, still sign with your hardware wallet, still meet your Safe’s threshold?

4. Wallet architecture

• Your Safe multisig - where your high-value assets actually live. It shouldn’t interact with anything directly; if you need to interact with a dApp, send funds to the hot wallet first. This address stays completely isolated from day-to-day use.

• Your isolated PC wallet signer - The first signer for the Safe. Holds no funds, does no activity of its own.

• Your isolated phone wallet signer - The second signer for the Safe. Same deal, holds nothing, does nothing.

• Your cold wallet signer on dev machine - The third signer for the Safe. If your dev machine got popped, malware might be able to intercept a transaction loading to change an address, or a potential clipboard changer to overwrite a valid address for a malicious one, but they would not have the mnemonic of your cold wallet.

• Your hot wallet on dev machine - Not a signer, used for actual safe transaction broadcasting, trading, website app interactions, permit signatures, and sign-in-with-Ethereum. Keep the balance on this one minimal makes it a decent canary, if it ever moves funds, you know your dev machine got popped before the loss is large.

• Optional offsite cold wallet signer - A potential extra signer that adds redundancy that’s ideally kept offsite.

Humans are bad at remembering hex addresses, so give each of these an ENS name - most wallets resolve top-level naming services automatically. Subdomains work well for this: safe.you.eth, vault.you.eth, signer1.you.eth, etc. Named addresses also make it much easier to catch address poisoning and probably stop bots from even targeting you since your ENS shows in block explorers as a priority over just the hex values.

5. Physical security

Not everyone has the capital for a proper safe, but in case of physical threats keep your seed phrase hard to obtain. Ideally that’s an embedded safe inside your property, at minimum, a lockbox with the box and the key stored in hidden separate places, way less secure, but far better than a seed phrase sitting in a drawer that can be accessed by a potential thief.

In my opinion, if you’re above roughly $100k in assets, it’s worth investing and researching further into physical security deterrents like:

• Better and additional locks on external doors.
• CCTV.
• Motion-activated lighting.
• Locking windows.
• Owning a large dog.
• If you live in freedom land, a gun.

I previously have looked into bank and external security company lockboxes but depending on where you live in the world, this may be either too risky, too expensive or you already have the hardening means (like a safe) to do this.

I enjoy listening to the physical security talks from DEFCONs like this, which is why I would recommend you thinking more about physical security in the case of a random robbery.

6. Security hardening for threat identification

Don’t mention your assets to anyone. If you have a partner, don’t tell them the numbers - DON’T TELL ANYONE ANYTHING ABOUT YOUR NET WORTH! Don’t advertise what you do, if you’re a Solidity developer or otherwise work in web3, it’s fine to downplay it as “generic software developer at [redacted]” to people who don’t need to know.

If you do choose to tell a partner, make sure they understand why it matters. A high net worth makes your whole family a ‘wrench attack target’, not just you, and they need to recognise the impact of casually sharing that information outward. Chainalysis puts the total stolen in violent crypto attacks at over $30 million so far in 2026 alone and it’s only the start of September.

Stay anonymous where you actually can. A wallet an attacker can trace back to your legal name via a doxxed ENS profile, a conference talk, a LinkedIn post, or a GitHub commit tied to a .eth address is a wallet they don’t have to guess at, they just have to look you up. Use a separate persona for anything on-chain that doesn’t need to be tied to your real name, keep your main vault’s ENS off anything publicly searchable, and think twice before posting screenshots, giveaway entries, or public repos that connect a real name to a real balance.

This is also where SIM-swap protection belongs. A surprising amount of “sophisticated” hacks start with a social-engineered SIM swap against a target’s mobile carrier, used to intercept SMS 2FA and reset exchange or email passwords. Move critical accounts off SMS 2FA entirely, use an authenticator app or a hardware key (YubiKey / passkeys) instead.

7. Editor and browser extension hygiene

Malicious extensions are the same supply-chain problem as malicious npm packages, just aimed at your editor. This is a bit of a tricky one because you have to trust a wallet extension you use to not completely fuck you over because one of their dependencies had a supply chain attack. You will need to audit and read the audit of your wallet of choice and see if they have mitigated this with the practices we speak about below.

For VS Code or Cursor:

# List every installed extension
code --list-extensions

# Cursor keeps its own extensions directory - check it directly too,
# and grep for anything that doesn't belong (e.g. a fake Solidity/
# contract-tooling extension riding on a real-sounding name)
ls ~/.cursor/extensions | grep -i contract

# Cursor/VS Code also track which publishers you've explicitly trusted -
# worth reviewing separately from what's just installed (macOS path
# shown; Linux is ~/.config/Cursor/..., Windows is %APPDATA%\Cursor\...)
sqlite3 ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb \
  "SELECT value FROM ItemTable WHERE key='extensions.trustedPublishers'"

For every extension that shows up, ask whether you actually still use it, and whether it needs the permissions it’s asking for.

Do the same for Chrome (chrome://extensions, Developer Mode on for the detail view). Pay particular attention to anything that can “read and change all your data on all websites”. A popular extension gets sold, or its developer’s account gets phished, and then everyone’s fucked with the latest update that Chrome decides it wants to automatically update, oh yeah, turn that shit off too.

8. Supply chain attacks

You can lock down npm/pnpm per-repo or globally, though, a misconfigured global setting overriding a repo-level one is an easy way to quietly lose the protection.

For npm, in .npmrc:

# .npmrc

# Pin exact versions instead of ^/~ ranges - no surprise minor/patch bumps
# landing silently on your next install
save-exact=true

# Don't run install/postinstall/preinstall scripts. This is the single
# biggest one: it's how most malicious packages actually execute code on
# your machine the moment you run `npm install`, no further action needed.
# Trade-off: some legitimate packages (native builds, browser downloads)
# need their install script - rerun it explicitly with `npm rebuild <pkg>`
# once you've verified it.
ignore-scripts=true

# Refuse to install anything that declares it doesn't support your
# Node.js version, instead of installing it anyway and hoping.
engine-strict=true

# npm already defaults to this since v7 - set it explicitly so nothing
# downstream silently flips it back to the pre-v7 behaviour.
legacy-peer-deps=false

audit-level is different - it only changes the exit code of npm audit, it doesn’t block a plain npm install. Wire it into CI instead:

npm audit --audit-level=high

If you’re on pnpm, there’s a much stronger option: minimumReleaseAge, set in pnpm-workspace.yaml. It refuses to install any version published more recently than a set window, most malicious releases get caught and pulled from the registry within an hour of publishing, so this alone kills a large chunk of supply-chain attacks.

# pnpm-workspace.yaml

# Refuse to install a package version published less than 24h ago
minimumReleaseAge: 1440 # minutes

# Fail the install outright rather than silently falling back to a
# too-new version if nothing in range clears that window
minimumReleaseAgeStrict: true

pnpm has shipped a default minimumReleaseAge of 1440 minutes (one day) since v11, so recent pnpm installs already have a baseline version of this protection whether you configure it or not, but I would extend this to 30 days (in minutes).

9. Approval hygiene / notification

Use revoke.cash to review your hot wallet’s active approvals and revoke anything you’re not currently using. Do this periodically, not once - approvals from a dApp you used six months ago are exactly what an exploited contract or a rug reaches for.

I also like to use etherscans notification feature which you can watch addresses and get sent an email when in/out native/token/nfts transactions happen against the wallet. You can attempt to react when something bad happens instead of returning to find you’ve been drained. You could also look into other resources for notifications like tenderly alerts or blocknatives mempool alert.

Summary

1. Isolate signing devices from anything that touches the internet.
2. Put a hardware wallet and a Safe multisig between any single compromise and your funds.
3. Keep your seed offline and off any disk and keep decent physical security practices.
4. Stay quiet and pseudonymous about what you hold.
5. Audit the supply chain, your dependencies, your editor extensions, your browser, your approvals.
6. Practice key rotations.

Time taken

• Reading Safe documentation: 20 mins
• Safe wallet creation: 10 mins
• Safe wallet key rotation recovery test: 1 hour
• Setting up your hardware wallets: 30 mins
• Locking down an isolated device’s OS: 30 mins per device
• npm/pnpm settings: 10 mins
• VM setup with snapshot: 1 hour
• Registering an ENS name + subdomains: 20 mins
• Editor and browser extension audit: 15 mins
• Approval hygiene pass on revoke.cash: 10 mins, repeat monthly

Call it under 4 hours end to end, and almost all of it is a once-off cost.

Mandatory costs

• 1 new or refurbished isolated computer: $300-600
• 1 new or refurbished isolated phone/tablet: $150-400
• 1 hardware wallet: $80-150
• 1 YubiKey: $25-70
• 1 ENS name + subdomains: $5-20/yr for the name, plus a few dollars of gas to set the subdomain records

You may already own spare devices that cover half of this. Worst case, it’s a $1,000 one-off cost.

Additional costs

• 1 Safe deployment: a few dollars of gas on an L2, more on mainnet depending on gas prices at the time
• 1 ENS domain, a few dollars a year.
• Physical security devices: a basic lockbox starts around $30-100; an embedded safe is more like $500-1,000+ depending on size and fire rating, CCTV and motion-activated lighting add another $100-500.

Final thought

For 4 hours and potentially less than $1000, you become resistant to malware on a singular device. If you don’t care, then just put the ETF in the bag little bro.