TL;DR

In 2024, Web3 lost between $1.5–2.5B+ across hundreds of incidents; audits alone clearly aren’t enough.
Around 70% of major 2024 exploits hit audited contracts, showing security has to live in development and runtime, not only in PDF reports.
A realistic security program combines pre-deploy checks (tests, invariants, fuzzing) with runtime monitoring, alerts, and circuit breakers.
A lean, 30-day “minimum viable” security program is achievable if you prioritize a small set of high-leverage practices.

1. Audits vs assurance: what audits can and can’t do

The Web3 industry has quietly collected enough data to prove that “we had an audit” is not a security strategy.

Different security firms report slightly different totals, but they all point in the same direction. CertiK’s 2024 Hack3d report measured about $2.36B lost across 760 on-chain incidents, an increase of roughly 31% in value stolen compared to 2023. Beosin’s 2024 global report counted $2.51B in total Web3 losses, including hacks, phishing and rug pulls, with 131 major attacks causing ~$1.79B of that damage. Chainlight’s 2024 postmortem looked at 204 incidents, with average losses of around $9.57M per project, and an incident roughly every 1.78 days.

These are not isolated outliers; they are the baseline.

Even more uncomfortable is what some of the meta-analyses say. Olympix’s review of 2024 incidents concluded that roughly 70% of major exploits hit contracts that had been audited. In other words, the majority of high-impact failures occurred after a formal review by professionals. The same analysis found that when teams integrated security practices into development, things like invariants, fuzzing, mutation tests, vulnerabilities declined by about 84%, and total costs fell by roughly 35% compared with an “audit-only” mindset.

Audits clearly matter. They routinely catch real vulnerabilities that would otherwise become eight-figure losses. But an audit is a point-in-time exercise. It assumes a specific codebase, a snapshot of dependencies, and a bounded threat model. It does not know how you will upgrade, what new integrations you will ship, or how you will respond when something in your environment behaves adversarially.

A grown-up security program treats audits as one control in a larger system: a quality gate before mainnet, a way to pressure-test assumptions, and a forcing function to improve your own testing, invariants, and monitoring not as a replacement for them.

2. Pre-deploy controls: invariants, fuzzing, and pragmatic checks

If your only pre-deploy control is “we sent the code to auditors,” you are effectively asking external reviewers to compensate for missing engineering discipline.

A more realistic approach starts with invariants. Unit tests answer whether specific scenarios behave as expected. Invariants express what must always be true, no matter how users or other contracts interact with the system. For something as basic as a token contract, one key invariant is that total supply should always equal the sum of balances across tracked accounts.

A simple Foundry-style invariant test might look like this:

contract TokenInvariantTest is Test {
    Token token;
    address[] trackedHolders;
function setUp() public {
        token = new Token();
        // trackedHolders populated as your tests add users
    }
    // Total supply must equal sum of balances
    function invariant_totalSupplyMatchesBalances() public {
        uint256 supply = token.totalSupply();
        uint256 sum;
        for (uint256 i = 0; i < trackedHolders.length; i++) {
            sum += token.balanceOf(trackedHolders[i]);
        }
        assertEq(supply, sum, "invariant: totalSupply != sum(balances)");
    }
}

This is not sophisticated, and that is the point. Boring invariants catch exciting bugs.

Fuzzing is the second piece. Instead of hand-picking inputs, you let a tool generate wide ranges of parameters and call sequences for critical functions, especially those related to minting, burning, withdrawals, upgrades and price calculations. In a withdrawal function, for example, you can enforce that no withdrawal ever exceeds the user’s balance, regardless of how the parameters are chosen:

function testFuzz_withdraw_neverExceedsBalance(
    uint256 depositAmount,
    uint256 withdrawAmount
) public {
    vm.assume(depositAmount > 0 && depositAmount < 1e30);
    vm.assume(withdrawAmount > depositAmount);
    token.deposit{value: depositAmount}(address(this));
    uint256 before = token.balanceOf(address(this));
    vm.expectRevert();
    token.withdraw(withdrawAmount);
    uint256 afterBalance = token.balanceOf(address(this));
    assertEq(afterBalance, before, "balance changed unexpectedly");
}

When you look at incident data, this type of discipline matters. Chainlight’s 2024 analysis attributes a large share of losses to recurring patterns: access control mistakes, unsafe external interactions, flawed math in pricing or accounting, and upgrade paths that were never stress-tested. None of those require new categories of attacks. They require better pre-deploy checks.

Full formal verification is unreachable for many teams, but some formal thinking is not. You can embed basic safety properties directly into code with require and assert statements in critical paths. For example, in a bonding-curve-like pricing function, it makes sense to enforce domain constraints and guard against silent overflow:

function getPrice(uint256 amount) public view returns (uint256) {
    require(amount > 0 && amount <= MAX_AMOUNT, "invalid amount");
    uint256 price = basePrice + k * amount;
      // Sanity guard against overflow
    assert(price >= basePrice);
    return price;
}

These simple checks will not replace formal methods, but they dramatically reduce the chance that basic arithmetic failures, like the overflow behind some large 2025 bonding-curve exploit reach the mainnet.

3. Post-deploy controls: monitoring, alerts, circuit breakers and drills

Most of the money is lost when contracts are live, not when code is written.

CertiK’s 2024 report counted 760 on-chain security incidents, with average losses of roughly $3.1M per hack and a median around $150k. Chainlight’s narrower dataset still came to 204 incidents and at least $1.88B in damage. Immunefi’s 2024 summary put total losses across the crypto ecosystem at about $1.5B, with 98% of that attributed to hacks rather than fraud. No matter which lens you choose, the message is the same: runtime is where things break.

A serious security program treats mainnet as an operational environment, not a scoreboard.

At a minimum, you want to see what your contracts are doing in production. That includes basic metrics such as daily active users, volume and function call distribution, but also risk-focused views: unusual mint and burn patterns, large single transfers, sudden spikes in a rarely used function, or interactions from addresses with known risky histories.

Even a simple off-chain watcher wired into a messaging channel is a step change from silence:

// Simplified ethers.js pseudo-code
const contract = new ethers.Contract(addr, abi, provider);
contract.on("Transfer", async (from, to, value) => {
  const usdValue = await toUSD(value);
  if (usdValue.gt(1_000_000n)) {
    await sendAlert({
      severity: "CRITICAL",
      type: "LARGE_TRANSFER",
      from,
      to,
      value: value.toString(),
    });
  }
});

Alerts should reach people who can act, not a quiet dashboard. In many public incidents, there is a long window of minutes, sometimes hours, between the first abnormal transaction and the full realization that an exploit is in progress.

Circuit breakers are the next line of defense. They exist because, in practice, teams sometimes discover issues too late to rely on code correctness alone. A pause flag, a cap on daily withdrawals or minting, or a rate limiter around certain flows can buy time in the face of unexpected behavior.

A minimal pausing pattern might look like this:

contract PausableToken is ERC20, Ownable {
    bool public paused;
    modifier whenNotPaused() {
            require(!paused, "paused");
            _;
        }
        function pause() external onlyOwner {
            paused = true;
        }
        function unpause() external onlyOwner {
            paused = false;
        }
        function _update(
            address from,
            address to,
            uint256 value
        ) internal override whenNotPaused {
            super._update(from, to, value);
        }
}

In a mature system, “owner” should not be a single externally owned account. It might be a timelocked multisig with narrowly scoped powers, or a governance mechanism with clearly designed emergency handling. But even this simple pattern, correctly constrained, is better than having no way to slow a live exploit.

Finally, incident drills matter. They do not have to be elaborate. You can simulate an anomaly, such as suspicious large transfers or unexpected contract interactions and then see how long it takes for someone to notice from monitoring, who is responsible for pausing, who communicates with users, and how long it takes to coordinate a response. The first time your team runs through that playbook should not be during an actual eight-figure hack.

4. A minimum viable security program in 30 days

Not every project can hire a full security team, but almost every serious project can commit to four weeks of disciplined work.

In the first week, you write down your assumptions. That means documenting who can call what, which contracts hold or move value, what external systems you depend on (oracles, bridges, relayers, governance contracts), and what “catastrophic loss” would look like for you. Many teams discover, during this exercise, that they have more privileged paths than they thought.

In the second week, you strengthen pre-deploy discipline. You add a small set of high-value invariants to your test suite, you turn on fuzzing for a handful of critical functions, and you embed sanity checks into the most sensitive math and access-control branches. The goal is not to reach perfection; it is to make it significantly harder for basic, avoidable bugs to escape into an audit, and then into production.

In the third week, you build minimal monitoring and alerting. You deploy a lightweight watcher that tracks key events and thresholds for your core contracts, and you connect it to a channel where on-call engineers will actually see and respond to alerts. You define clear conditions under which a human must investigate: unusually large transfers, abnormal function mixes, or sudden deviations from baseline usage.

In the fourth week, you implement at least one circuit breaker around critical flows, and you run a short incident drill. The drill can be as simple as “Assume this exploit pattern just started. What do we do, and who has the authority to do it?” The output should be a short runbook that names people and decisions, not abstract intentions.

When you overlay this kind of program on the public data-that hundreds of incidents a year still produce multi-billion-dollar losses, despite growing audit coverage (CertiK)—it becomes clear that even a small amount of structure moves you out of the default risk profile. You are no longer a protocol that simply “had an audit.” You are a protocol that owns its assumptions.

References

Chainlight 2024 hack postmortem: 204 incidents, ~$1.88B losses.
CertiK Hack3d & other 2024 Web3 security reports: multi-billion annual losses.
Olympix Web3 security analysis: ~70% of major 2024 exploits on audited contracts; proactive dev security cuts vulns and costs.
Hacken & QuillAudits 2024 data, access control exploits dominating losses.

Working with Exploitless

At Exploitless, we focus on the gap between passing an audit and surviving mainnet.

For some teams, that means helping define a threat model that includes external dependencies, governance paths, and cross-chain integrations, not just individual contracts. For others, it means designing invariants, fuzzing strategies, and test harnesses that developers can run themselves on every change. And for protocols already in production, it often means building a realistic monitoring and response layer, with clear thresholds and controls, so that security is no longer a single event but an ongoing practice.

If you are responsible for systems that hold real value, the question is not whether you can get an audit. The question is whether your security program continues once the report is delivered and the contracts go live.

Audits are a snapshot. Mainnet is a continuous process. The programs that last are built for runtime, not just for the PDF.

Learn more at Exploitless.

From Audit to Runtime: Building a Security Program That Actually Survives Mainnet.