Security 101 for Web3 Startups

Whether you’re building, investing, trading, or just keeping an eye on the crypto space, chances are you’ve heard of a major hack, like “$1.5B stolen from Bybit” or “$534M drained from Coincheck.” Shocking, but somehow not surprising in the Web3 world.

Security has always been critical in Web3. The financial layer of the internet is constantly under attack, and web3 startups are often the easiest targets. Notably, Web3 attackers have moved beyond exploiting bugs to actively stealing keys. 

• In 2024, stolen funds rose to $2.2B (up ~21% YoY), and reached $3.1B in just the first half of 2025.
• 43.8% of total crypto hacks came from private key exposure. 

Web3 startups often operate with fast-paced deployment cycles, small teams, and limited security infrastructure. That makes them prime targets for crypto exploits. 

Why Security Should Be a Priority from Day One

Security often takes a back seat in early-stage companies. But in Web3, delaying security planning can be a costly mistake.

• You're Target #1: Web3 startups often face pressure to move fast and ship products quickly, sometimes at the expense of comprehensive security measures, making them easier to exploit.
• Security Builds Credibility: In a trustless environment, users and partners need to trust you. Gaps in security processes raise red flags with investors, auditors, and regulators.
• Product-Market Fit Doesn’t Matter if You’re Hacked: A strong product won’t survive a catastrophic exploit. If user funds disappear or your protocol becomes untrusted, recovery is rarely possible.

And yes, attackers are even getting smarter and faster with AI. With AI tools becoming widely accessible, attackers are using them to scale their operations. For example:

• Phishing: AI can generate emails or messages that mimic internal team communication or investor language, increasing the odds of success.
• Malware: Generative tools help attackers write more efficient, obfuscated malware with fewer traces.
• Code inspection: AI models assist in reviewing large codebases quickly to detect exploitable patterns or leftover secrets.

This means the barrier to launching sophisticated attacks has dropped significantly, and it’s worth making security part of your plan early on.

Common Attack Vectors in Web3 Startups

Attacks in Web3 don’t follow a single playbook. Web3 threat vectors come from multiple directions - technical, social, and operational. Below are the most common entry points hackers target:

• Human: Phishing, impersonation, insider threats.
• Software Supply Chain: Compromised dependencies, malicious package uploads, exposed secrets in repos.
• Infrastructure: Cloud misconfigurations, weak credential storage, poor key management.
• Code: Smart contract bugs, overflow logic, bridge design flaws.
• Device: Stolen hardware wallets, SIM swaps, keyloggers.

Each of these vectors has caused multi-million-dollar losses. In the next sections, we’ll walk through real-world examples to illustrate how these vulnerabilities play out and how to defend against them.

Human Vector: Social Engineering

Social engineering is one of the most common and effective attack methods in Web3. It doesn’t target systems. It targets people.

Here’s how a real-world attack typically happens:

1. A threat actor poses as someone the victim is likely to trust, such as a prospective client, partner, investor, or employer.
2. They manage to arrange an online meeting with the victim.
3. During the call or follow-up, they share a GitHub link or a file that looks like a test assignment, demo app, proof-of-concept, etc.
4. The victim downloads and installs it, unknowingly running a malicious software package.
5. That package installs a backdoor malware.
6. The malware establishes a connection with the attacker’s remote C2 (command-and-control) server, enabling data exfiltration from the victim’s device and allowing the attacker to deploy additional malicious payloads.

Once the attacker is inside, they can scan for seed phrases, session tokens, SSH keys, or wallet credentials.

Example: TapiocaDAO Hack

In 2024, a hacker tricked an engineer of TapiocaDAO using this exact method. They suffered a private key compromise and lost over $4 million. The attacker used phishing, social engineering, and malware to compromise the victim’s wallet. It started with a fake job offer and doesn’t need a smart contract bug or infrastructure flaw. Read more about it here.

This kind of attack can happen to anyone on your team, especially founders and developers. The best defense is keeping everyone aware. Security training, clear policies on downloading files or packages, and good habits like using work-only devices and password managers. It doesn’t have to be complicated, but it does need to be consistent.

Human Vector: Insider Job

Not all threats come from outside. Sometimes, the biggest risk is someone already inside your company.

Insider attacks can happen in many ways:

• Someone intentionally leaks private keys or credentials
• An ex-employee retains access they should no longer have
• A current employee abuses their permissions

Example: Pump.fun ex-developerA former employee used their access to steal around $1.9 million worth of $SOL (12,300 SOL at the time). Read more about it here. 

Example: Cryptopia Insider Theft

A former employee at Cryptopia copied customer private keys while still working there. Later, after leaving the company, he used those keys to steal $172K in crypto. Read more here. 

These cases show that even with secure systems, unchecked human access can expose your entire operation. That’s why it’s important to minimize privileges, review permissions regularly, and have a clear offboarding process in place. 

Infrastructure Attacks: Weak Links in the Stack

Even with secure apps and smart contracts, poor infrastructure hygiene can expose critical assets, especially private keys and credentials.

1. Unsecure Key Management

Data from Chainalysis shows that 43.8% of total crypto hacks were caused by private key exposure. Poor private key protection can leak through logs, crash reports, or misconfigured services. 

Example: Slope Wallet (2022) - Over $6 million was stolen after private key information was inadvertently transmitted to an application monitoring service. Read more here.

This case highlights why manual or app-level key storage is risky. Keys should never be exposed to logs, devices, or centralized services. Using Multi-Party Computation (MPC) can prevent this by ensuring no full private key ever exists in one place.

2. Cloud Credential Leaks

APIs and wallets often run on cloud infrastructure like AWS or GCP. If credentials or secrets stored in these environments are leaked, attackers can gain direct access to backend systems or wallet infrastructure.

Example: Bybit (2023) - Hackers allegedly exploited leaked AWS credentials, leading to a $20 million loss.

Secrets in cloud environments must be tightly scoped, rotated regularly, and stored securely using dedicated secret managers.

3. DNS Hijacking

DNS attacks let hackers redirect users to fake interfaces that steal login credentials or trick them into signing malicious transactions.

Examples: Curve, Balancer, Velodrome, Convex, Stargate - all experienced DNS-related attacks.

These don’t directly compromise private keys but often lead to users unknowingly exposing them through phishing or spoofed wallet prompts.

Software Supply Chain: Compromised Dependencies

Your codebase is rarely 100% your own. Most Web3 projects utilize open-source libraries and packages, especially those from npm. This saves time, but it also opens the door to supply chain attacks. If an attacker compromises an npm package you rely on, they can insert malicious code into your app without needing to touch your own repository.

If that code gains access to sensitive environment variables or storage, it can leak private keys, API tokens, or wallet credentials, especially in cases where secrets are hardcoded or improperly secured.

Here are some real incidents:

• Ledger Connect Kit (2023): A compromised npm package was pushed live. Over $600,000 was stolen in just a few hours. Projects relying on Ledger's kit unknowingly distributed the malicious code to users. Read more here.
• @solana/web3.js (2024): A Solana-related npm token was compromised. Hackers published a malicious version of the package, stealing over $160,000.  Read more here.
• xrpl (2025): Another npm token compromise allowed attackers to tamper with the Ripple package. This risked exposing projects and users relying on the official xrpl package. Read more here.

These incidents prove that even trusted packages are not immune. Many developers automatically update their dependencies, which makes these attacks spread quickly.

Good dependency hygiene matters:

• Lock versions
• Audit third-party libraries, especially ones involved in wallet, signing, or cryptographic logic
• Use scoped access tokens
• Log out of package managers after pushing updates.

Code Vector: Bugs in Smart Contracts or Bridges

Security at the code level often gets the most attention, especially in DeFi and cross-chain infrastructure. But bugs still slip through, even in audited code.

1. Validation BugsValidation issues often lead to logic flaws that attackers can exploit without needing full control.

Example: Cetus Overflow Bug A simple validation oversight in Cetus AMM led to a $200 million loss. The code failed to correctly handle overflow logic, allowing the attacker to drain funds. Details here. 

2. Math Errors and OverflowsMisused math operations can result in unexpected behaviors, especially in on-chain arithmetic.

Example: Wormhole HackA math-related vulnerability contributed to the Wormhole exploit. Analysis by CertiK suggests that the hackers exploited a vulnerability on the Solana side of the Wormhole bridge to create 120,000 so-called "wrapped" Ethereum for themselves. Over $320 million was lost. Details here.

These incidents show how even one line of buggy code can break entire systems. Intensive unit testing with high coverage, regular audits, fuzz testing, and real-time monitoring can help catch problems early.

Device Vector: Physical and SIM-based Attacks

Even with secure code and infrastructure, attackers can go straight for the devices.

1. Tampered Hardware Wallets

Some users unknowingly buy compromised hardware wallets. These often come from unofficial resellers. Attackers preload malicious firmware or tamper with the device to capture seed phrases once activated.

Example: Tampered Ledger on TikTok

A user lost $6.9 million in minutes after buying a compromised Ledger wallet promoted via TikTok. The attacker had full access from the moment the wallet was initialized. Read more here.

2. SIM Swap Attacks

SIM swaps are common in both Web2 and Web3. Attackers trick or bribe telecom employees to assign your phone number to their SIM card. Once they control your number, they can bypass two-factor authentication or reset login credentials to gain access to wallets or exchanges.

Example: $24M SIM SwapIn one case, a user lost $24 million worth of tokens through a SIM swap attack. They later sued AT&T, arguing that the telecom provider failed to protect their identity, but the lawsuit was dismissed. Read more here.

To reduce the risk of SIM swap attacks, avoid using SMS-based two-factor authentication for critical accounts. Instead, use authenticator apps or hardware security keys like YubiKey. Also, limit how much personal info is shared online and with your telecom provider, and ask your carrier to add extra security measures like a PIN or password on your account.

Mistakes Web3 Startups Often Make

Many early-stage Web3 teams don’t intentionally ignore security. But without time, expertise, or proper tools, they often leave gaps, especially around private key handling. Some of the most damaging issues include:

1. Hardcoding Secrets in Repos

Founders or devs sometimes hardcode wallet private keys, access tokens, or API credentials into the codebase for quick testing. If that repo gets pushed to GitHub or shared internally, those secrets are exposed.This can happen even in private repos. GitHub staff and compromised internal accounts can access them.

2. Poor Onboarding & Offboarding

Teams add new members to shared wallets, GitHub, Slack, or Notion workspaces without tracking access levels. When someone leaves, they’re not always fully removed.

This leaves doors open for former employees, contractors, or interns to access sensitive assets like private keys later.

3. No Incident Response Plan

If something goes wrong, most early-stage teams don’t know what to do. They haven’t thought through how to pause contracts, lock access, notify partners, or analyze the root cause. This delays the response and increases the damage.

4. Misconfigured Infrastructure

Poorly set up cloud servers, exposed ports, or unauthenticated dashboards create easy ways in. 

5. Blind Trust in Dependencies

Founders and junior developers often assume that if a library is widely used, it must be safe. But in reality, popular npm packages get compromised too. Teams rarely audit or pin versions.

These mistakes are fixable with clear policies, better tooling, and security baked into team culture.

Web3 Security Best Practices

Security isn’t just about avoiding losses. It builds trust, protects your roadmap, and lends your project the credibility needed to scale. Below are key best security practices Web3 startups can adopt to strengthen their stack without slowing down

1. Make It Hard for Hackers

• Apply zero-trust and least-privilege principles across your systems
• Include security checks early in your development lifecycle
• Limit admin permissions, both on-chain (e.g., upgrade roles, treasury access) and off-chain (e.g., Notion, Slack, GitHub)

2. Manage Dependencies Carefully

• Use short-lived tokens (npm, GitHub) and always log out after changes
• Scan your repos for leaked secrets like wallet private keys, API tokens, and credentials
• Integrate tools like Snyk, Git Guardian, and Socket to detect risky packages

3. Implement Continuous Monitoring

• Monitor smart contracts and system activity
• Use Web3 monitoring tools like Hexagate, Hypernative
• For internal devices, install EDR tools like CrowdStrike or Bitdefender

4. Strengthen Wallet Management

• Never share private keys across team members
• Use multisig or MPC wallets for high-value operations
• For MPC, use at least a 3-of-5 setup to reduce risk and increase redundancy

Taking these steps doesn’t guarantee perfect security, but it makes you a harder target and often, encourages attackers to move elsewhere.

Reduce Single Point of Failure with MPC Wallet

Wallets are often the highest-value target in Web3. If a single private key controls a treasury or protocol, losing that key or having it stolen can lead to irreversible damage.

MPC (Multi-Party Computation) wallets help remove single points of failure by splitting a private key into multiple key shares. These shares live on separate devices or systems and never combine into a full key, even during signing.

This means no single person, device, or leak can compromise the entire wallet.

For example, you can require 3 out of 5 key shares to approve a transaction. Even if one share is compromised, attackers can’t do anything without the rest.

This setup is much safer than storing a full private key on a laptop or phone.

Launch Your MPC Wallets with Fystack

Fystack’s wallet infrastructure is powered by mpcium, our open-source MPC engine built for developers.

You don’t need to know how cryptography works to launch secure wallets.

• Easy setup
• Works in production
• Designed to reduce the headaches of key management

Fystack helps you deploy reliable self-hosted MPC wallets without sacrificing flexibility or security.

Get started today at fystack.io and create your first secure MPC wallet.