Audits are helpful but only offer a snapshot and smart contract risks don’t stop after audit. They can miss issues that appear later, gaps in your logic, or risks that emerge as your protocol grows.
This guide is organized by what you’re building. Find your product type, understand the vulnerabilities most likely to affect you, and use it before you go into audit, not after you come out.
What are smart contract vulnerabilities in your development lifecycle?
Smart contract vulnerabilities are weaknesses in the code, logic, configuration, or external dependencies of a blockchain-based application that can be exploited to steal funds, manipulate outcomes, block transactions, or take control of contract functions.
| Vulnerability source | Meaning | Example |
|---|---|---|
| Code-level bugs | A flaw in how the contract is written, usually in Solidity/EVM implementation. | Reentrancy, unchecked calls, integer issues |
| Logic-level flaws | The code runs as written, but the underlying business rule is wrong | Incorrect reward calculation, bad liquidation logic |
| Integration risks | A weakness introduced through external dependencies your contract relies on (oracle, bridge, token standard, external contract, etc) | Oracle manipulation, malicious token callback |
| Operational risks | A gap in how the contract is managed, upgraded, or controlled after deployment. | Admin key compromise, uninitialized proxy |
However, the vulnerabilities above don’t hit every product the same way. Here’s how they map to what you’re building.
Smart contract vulnerabilities by product type
Before getting into the details, here’s a quick overview of the main risks you’re likely to face for your product type, and what could happen if these risks are overlooked.
| Product type | Top vulnerabilities | If overlooked |
|---|---|---|
| DeFi Protocol / Lending / Yield | Reentrancy, oracle manipulation, logic flaws | Fund loss, protocol insolvency |
| NFT Marketplace | Access control, front-running, royalty bypass | Failed launch, reputation damage |
| RWA Tokenization | Access control, oracle manipulation, issuance logic | Regulatory exposure, operational halt |
| GameFi / On-Chain Game | Logic flaws, reentrancy, front-running | Economy collapse, full rebuild |
| Crypto Wallet / Infrastructure | Signature validation, upgrade key risk | Direct fund loss, trust collapse |
Detailed breakdown by product type
Now let’s get into the details. You can jump to the section that matches what you’re building.
Smart contract vulnerabilities in DeFi protocols and lending apps
Here is the most common scenario in DeFi exploits: the lending pool passes audit, but months later, someone drains it in one transaction. The vulnerability wasn’t in the original code but appeared later during a rushed, unchecked integration.
That pattern – small, incremental decisions that never get revisited – is how most DeFi vulnerabilities enter a codebase. Below are the three that kill DeFi products most often, and exactly where in your build process they tend to show up.
Reentrancy vulnerabilities in DeFi integrations
In April 2022, Rari Capital’s Fuse pools lost $80M to a reentrancy exploit, not through a flaw in the original lending logic, but through an external token integration added later that nobody reviewed against existing withdrawal functions. The vulnerable path only became visible when you looked across multiple contracts at once.
Most DeFi teams are aware of reentrancy, but it often doesn’t appear in your original code. It usually shows up later when you add third-party integrations, like yield aggregators, liquidity sources, or tokens with special callbacks, and no one fully reviews how these connect to your existing functions.
By the time you submit for audit, reentrancy risks may span several integrations, making it hard for auditors to spot the exploit path across multiple contracts.
Watch out for: Any function that sends funds to an external address before updating your contract’s internal records. If the recipient can call back into your contract, you’re at risk.
Oracle manipulation: A common smart contract vulnerability in DeFi
DeFi protocols need price data. Most teams plug in an oracle early, treat it as infrastructure, and move on. But the real risk isn’t which oracle you use, it’s how you use it.
In October 2022, Mango Markets lost $117M when an attacker temporarily pumped up the MNGO price and then borrowed against that inflated value until the pools were drained. The oracle reported a real price, and the contract followed its instructions. The design just never accounted for what happens when the price is wrong for one block.
Watch out for: Single-source spot price oracles with no time-weighted average, no deviation check, and no fallback. Ask this question: “what happens to your protocol if the price is wrong for one block.”
Logic flaws in DeFi smart contracts
In January 2024, Gamma Finance lost $6.3M when an attacker exploited overly generous price change thresholds in their liquidity pools to claim more LP tokens than intended. The code worked exactly as written. The problem was a business rule that hadn’t been stress-tested against an adversarial user with enough capital to push it to its limits.
These issues aren’t coding mistakes, the code does what it’s supposed to. The problem is the business rule was wrong, or an edge case wasn’t considered, or the math was only stress-tested at small scale.
Where this happens: logic for rewards or liquidations, often written early based on guesses about user behavior. These assumptions might not hold once your protocol is live and attracting serious capital.
Watch out for: Any formula involving user balances, collateral, or rewards. Always ask, “What if someone adds 100x more capital than we tested? What if lots of users try the same action at once?”
Smart contract vulnerabilities in NFT marketplaces
Your mint sells out fast. Then the community finds out bots grabbed 40% of the supply. Then a creator realizes someone bypassed their royalties through a wrapper contract. Neither of these was in your audit report, because neither was in scope when you submitted.
Unlike DeFi hacks, NFT smart contract vulnerabilities don’t usually drain funds. Instead, they hurt trust, and in NFTs, trust is everything.
Access control vulnerabilities in NFT smart contracts
In February 2024, PlayDapp, an NFT marketplace and blockchain gaming platform, lost $290 million after an attacker exploited an access control vulnerability to add themselves as an authorized minter, then created tokens out of thin air. The minting function was fine. The problem is the permission controlling who could call it was.
Many NFT teams set up permissions early, but as features and admin roles are added, the access control gets messy. Each change seems fine alone, but no one checks the big picture. By launch, some functions can be called by addresses that shouldn’t have access.
Watch out for: List every address that has privileged access in your contracts and what each one can do. If you can’t do this quickly, your access control model needs a review before audit.
Royalty bypass: A smart contract logic vulnerability in NFT marketplaces
Royalty bypass happens when traders or marketplaces find ways to avoid paying creator royalties, even if the code follows the standard.
In 2022–2023, platforms like Blur and X2Y2 made royalties optional to attract trading volume, so creators saw their NFTs traded for millions but received nothing. The contracts weren’t hacked, and the code worked as written. The real issue was that royalty enforcement relies on marketplaces choosing to honor it, and many didn’t.
Watch out for: If creator royalties are a core promise of your marketplace, check every way your NFTs can be traded s. If any path bypasses your royalty function, that’s a gap between your product’s intent and its on-chain reality.
Front-running vulnerabilities in NFT minting
In 2021 and 2022, nearly every high-demand NFT mint saw bots capture a disproportionate share of supply. Front-running, where bots watch the public list of pending transactions (the mempool), copy real users’ mint transactions, and pay more gas to get ahead, impacted about 20% of DeFi protocols in 2025 and remains an active threat vector on NFT marketplaces.
The mint function worked correctly in every case. The problem was that public mempools are visible to anyone, and the mint flow was designed without accounting for that.
Watch out for: If your mint has any element of fairness or equal access in its public positioning, you need to address mempool exposure at the product design stage. Commit-reveal schemes, allowlists, or private mempools are options, but each has tradeoffs that affect your mint UX.
Smart contract vulnerabilities in RWA tokenization platforms
RWA (Real-World Asset) tokenization brings both smart contract and regulatory risks. A flaw here can cause more than just money loss, it can lead to stopped operations, compliance violations, or legal trouble that code fixes can’t solve.
The challenge is that most rules for RWA tokens, like who can own them and how they’re traded, are about compliance first, smart contract second. If your contract doesn’t enforce these rules on-chain, there’s a gap between what’s legally required and what your code actually does. That gap is the vulnerability.
Access control: When compliance lives off-chain
In March 2025, Zoth lost $8.4M when an attacker stole the admin key and upgraded the contract to drain funds. The admin key had no multi-sig or timelock, so one compromised key was enough.
For RWA project, this wasn’t just a security failure but could also be a compliance issue if unauthorized transfers happen.
What to watch: Pick any compliance rule (like “only accredited investors can hold this token”) and see exactly how your contract enforces it. If any part relies on off-chain checks, consider what happens if someone skips that step.
Oracle risks in asset valuation
RWA tokens represent real-world assets, so their value changes over time. Most teams just connect a price feed to their contracts without adding checks to make sure the price is reasonable.
In April 2025, Loopscale lost $5.8M when an attacker tricked their pricing oracle into inflating a token’s value, then took out much bigger loans than the collateral was worth. The problem was that the contract accepted any price without question.
Watch out for: Check how much your asset’s value can change in one update, who can change it, and whether there’s a delay or approval before new prices take effect. If the price could change by 50% in a single step without warning, your contract needs more safeguards.
Issuance logic flaws at scale
RWA tokens rely on strict issuance rules set by legal and implemented by developers. While tests cover normal cases, edge cases often slip through.
For example, in August 2022, Acala – Polkadot’s DeFi hub, was exploited through a misconfiguration that hadn’t been stress-tested against adversarial conditions on launch day, letting an attacker mint 1.2 billion aUSD without enough collateral.
Despite audits, the flaw emerged only under real-world, adversarial conditions. Acala had to freeze the network and burn the tokens.
Watch out for: Pick your three most complex issuance rules and ask your dev team what happens at the boundary of each one. If the answer is “we haven’t tested that specific scenario,” that’s the gap.
Smart contract vulnerabilities in GameFi and On-chain games
This is a typical scenario in GameFi exploit: your economy runs fine at low scale, your audit comes back clean, and six months later, when your protocol has real liquidity and players with real capital, someone might find a loophole in the game’s economy that you didn’t plan for.
By then, the damage isn’t just financial. Player trust in the economy is gone, and rebuilding it requires changes deep enough that most teams treat it as a full rebuild.
Logic flaws in game economy design
Game economies have lots of numbers, like how many tokens are made or how big rewards are. These seem fine in small tests, but real players can find ways to combine them and take out more value than the game can handle.
For example, in Sunflower Farmers, a bug let players make unlimited iron pickaxes. This caused gas fees on Polygon to skyrocket, and the team had to shut down the game. The contract worked as coded, but it didn’t expect players to exploit it for profit.
Watch out for: Before setting your game’s numbers, check what happens if one person controls 10% of the game’s money and tries to make the most profit possible. If this breaks your economy, it will eventually happen.
Reentrancy risks in reward systems
GameFi reward systems can become complex as you add features like staking, crafting, and marketplaces. Each part may look safe on its own, but problems like reentrancy can appear when they interact.
In 2022, DeFi Kingdoms was exploited this way: attackers used a loophole across several connected contracts to mint extra tokens, which crashed their value. No single contract was obviously broken, but together they created a hidden risk.
Watch out for: Look at every place in your game where a user action sends tokens to an outside address. For each one, check if that address, or any contract it uses can call back into your game contracts before the transaction is finished.
Front-running and unfair play
In on-chain games, every move you make is a public transaction waiting to be confirmed. Anyone can see your move in the mempool and jump ahead by paying more gas. This lets other players copy or counter your move before it happens, giving them an unfair advantage.
For example, in September 2022, a trader used this to make $565,000 on GMX by acting before their oracle updated, all without breaking any code. The problem was the system let anyone with mempool access get ahead.
This is a game design issue. Blockchains are open by default, so unless you plan for this, skilled players can always act before you.
Fixing this after launch is hard because it’s not just about changing the code. You need to design your game from the start to hide moves (using commit-reveal or batching actions) so other players can’t see and react before you.
What to watch for: If seeing someone’s pending move gives an advantage – like in PvP, resource grabs, or auctions – you need to protect against mempool front-running in your game design.
Smart contract vulnerabilities in crypto wallets and infrastructure
Wallet vulnerabilities are more severe than protocol bugs because users lose their own funds, and trust is nearly impossible to restore. DeFi protocols can recover, but a compromised wallet means permanent loss for users.
These issues are less about clever hacks and more about mistakes in how you set up who can approve transactions and under what conditions. Gaps or untested edge cases in this model can be critical.
Signature validation: Edge cases that authorize the wrong transaction
In July 2024, WazirX lost $234.9 million when attackers tricked signers into approving a transaction that looked routine in their interface but actually upgraded the wallet to a malicious contract. The multi-sig worked as designed, the problem was a mismatch between what signers saw and what really happened on-chain.
Modern wallets have complex features like multi-sig, session keys, and social recovery. Each one works alone, but unexpected problems can happen when they interact in ways no one tested—like a session key with too much power or a recovery process that’s too easy to trigger.
Watch out for: Find the easiest way a transaction could be approved. Then check if someone could use a mix of features to bypass your intended protections.
Upgrade key risk: When the safety mechanism becomes the attack surface
Most wallets use upgradeable proxy contracts so they can fix bugs after launch. But the upgrade key, the one that lets you change the contract, holds huge power. If it’s stolen, an attacker can take over everything: redirect funds, change permissions, or drain wallets before anyone notices.
In April 2026, Wasabi Protocol lost $4.55 million when attackers stole the admin key. With just that one key, they took admin control, upgraded contracts to malicious versions, and drained funds before anyone could react. There was no timelock or multi-sig, so one key meant total control.
What to watch for: Ask yourself what would happen if your upgrade key was stolen tonight. If the answer is “total control, and our team might not notice for hours,” add safety steps like timelocks, multi-sig, and incident response plans before your audit.
Why you should fix smart contract vulnerabilities before audit
Catching these vulnerabilities early saves time and money.
If you find a logic flaw during development, you can fix it quickly. But if you find it during audit, you’ll need to rewrite contracts, retest, and pay for another audit. A flaw is discovered after launch is considered an emergency. Users might lose funds and trust, and reputation damage is hard to fix.
It’s also worth understanding what audit scope actually covers. Auditors review what you submit, against what your code says it does. Vulnerabilities introduced after the audit window, through a new integration, a post-audit feature addition, or a dependency update – fall outside the report entirely. A clean audit report is a snapshot, not a guarantee.
What “Audit-ready” actually means is your business logic and permissions are checked for edge cases, and your dependencies are treated as security boundaries, not just that your code compiles.
Conclusion
The vulnerabilities that cause the most damage rarely announce themselves. They often lurk, unnoticed, in overlooked integrations, outdated permission models, or untested economic assumptions, waiting until someone with enough capital and motivation discovers them.
You can’t eliminate all risk in smart contract development. But you can make sure the risks you’re carrying are ones you chose consciously, not ones you inherited from decisions made in sprint 1 and never revisited.
If you’re building a DeFi protocol, NFT marketplace, RWA platform, GameFi product, or wallet infrastructure and want a development partner who thinks about these questions before they become incidents – talk to our smart contract development team.
