Time-to-Hack: How fast vulnerable smart contracts get exploited?

We usually think that vulnerable smart contracts get hacked quickly, but that's not always true. Some stay live and operational for years before being attacked. Why? Because exploitation isn't always about speed—sometimes, it's about strategy.

Let's examine how long these contracts actually remain unhacked before exploitation.

Following closely is the ≤7 days range with, indicating that attackers actively monitor new contracts and exploit vulnerabilities immediately. While the frequency of attacks decreases after the first week, a significant number still occur within the first month.

Let's dig deeper into the annual trend analysis of smart contract exploit times, focusing on the median and mean values from 2020 to 2024. These values represent the time from the deployment of a vulnerable contract to its exploitation, providing key insights into how attacker behavior and exploit dynamics have evolved over time.

Exploit Trends from 2020 to 2024

As we examine the data, both the median and mean exploit times show a clear shift. From 2020 to 2024, both values steadily decreased, revealing a trend where vulnerabilities are increasingly exploited faster over the years. This shift likely reflects the growing sophistication of attackers, aided by improved tools, techniques, and increased market attention to smart contract vulnerabilities. It's a sign that vulnerabilities are being identified and exploited more quickly than ever before.

As we've seen from the annual trend analysis—where exploit timelines have generally shortened from 2020 to 2024—the landscape of smart contract vulnerabilities is evolving at a rapid pace.

But what happens when we break this down further? How do these patterns shift across different blockchain networks like Ethereum, Binance Smart Chain, and others?

The Mean Time to Hack reveals how long, on average, a contract survives before being exploited. A high mean suggests some contracts remain vulnerable for long periods before being targeted, possibly due to strategic waiting by attackers or overlooked vulnerabilities.

Meanwhile, the Median Time to Hack gives a clearer picture of what's typical—half of the attacks occur before this point, half after. If the median is low, it means most hacks happen quickly, even if a few outliers extend the mean.

Exploit Timelines: Ethereum vs. Binance Smart Chain

Ethereum, with its complex and high-value contracts, tends to have a longer time to exploit. While some contracts are hacked almost immediately, others remain vulnerable for extended periods, as attackers often take their time analyzing high-value targets before striking.

On the other side, Binance Smart Chain often sees a lower exploit time, meaning attacks happen sooner on average. The reasons? Several factors contribute to this difference:

Now that we've explored how exploit timelines have changed over the years, let's dive into the details of individual smart contracts. We know the timelines are getting shorter, but what's really happening with these contracts? Do some get hacked right away, or do others survive much longer?

To answer this, we've built a chart using our own database. It shows when each hack happened and how long the contract lasted before getting exploited. Each point represents a hacked protocol, with the x-axis marking the time of the attack and the y-axis showing how long the contract was active before it was targeted.

It's interesting to see the variety—some contracts are compromised almost immediately, while others last for years.

The Role of Stat-analyzer Tools in Changing Exploit Timelines

You've probably noticed the red dashed vertical lines on this chart. These lines mark the release dates of key static analyzer tools designed to identify vulnerabilities in smart contracts.

These tools have definitely had an impact. Though we can't say with certainty whether attackers are using them, the data suggests the automatic detection and exploitation of access control vulnerabilities straight after the deployment is becoming more common.

Why Some Vulnerabilities Stay Hidden for Years

But here's where things get even more interesting: despite the rise in quick exploits, some contracts remain vulnerable for months or even years before getting hacked. This raises an important question—why do some security flaws remain undiscovered for so long?

One possibility is that certain vulnerabilities are too complex or obscure to be easily spotted, even by skilled attackers or automated scanners. Another explanation is that some contracts simply aren't valuable enough to attract immediate attention.

Attackers tend to prioritize high-value targets, leaving lower-profile contracts untouched until circumstances change—such as a sudden surge in user activity or total value locked (TVL).

This mix of immediate and delayed exploits shows that blockchain security isn't just about catching vulnerabilities early—it's also about continuous monitoring and adapting to new threats as they emerge. Even if a contract has been running without issues for years, it doesn't mean it's safe.

After diving into the lifespan of vulnerable smart contracts, we decided to focus on a specific aspect: hacks that involve proxy patterns.

Proxy Upgrade Pattern are essential for smart contracts because they let developers update and change contract logic without starting over. The proxy contract maintains the state and storage while delegating function calls to a separate implementation contract that can be replaced. While this is incredibly useful for flexibility and scalability, it also opens the door to potential vulnerabilities if the updates aren't thoroughly tested and validated before deployment.

We focused specifically on how quickly vulnerabilities introduced by implementation upgrades are exploited. After analyzing several cases of attacks that occurred after implementation upgrades, we created a timeline to track how long it took for vulnerabilities to be exploited.

The chart below represents this timeline. On the x-axis, we have the implementation update date, and on the y-axis, we're tracking how long it took until a hack happened—ranging from hours to months. Each white dot on the chart represents a case where a vulnerability turned into an exploit after the update.

It's important to note that the dataset we analyzed is relatively small, meaning the conclusions we draw come with the limitation of a limited sample size.

However, even with this limitation, the trends we observed were strongly clear. On average, it takes around for a vulnerability to be exploited after an update, highlighting how quickly attackers can target newly exposed weaknesses.

If we look at the density of exploits in more detail, we can see how attacks cluster within specific timeframes after an update. The x-axis of the density chart shows the number of days since the update, while the y-axis represents the frequency of exploits within that period.

Timeline: From Proxy Deployment to Hack

To better understand the timeline of attacks, we mapped out the lifecycle of smart contract protocols—tracking the timeline from deployment and updates to when they get exploited.

The dotted lines connect events for the same protocol, showing each project's timeline from deployment to exploitation. Above each line, you'll see exactly how long it took for attackers to discover and exploit the vulnerability after proxy deployment—ranging from mere minutes to hundreds of days.

The pattern is clear: attacks are much more likely to occur soon after a new implementation is deployed. One notable case, the Li.Fi exploit, follows this exact pattern, with an attack occurring shortly after the implementation update. More details on this hack can be found in our post, which points to the specifics of the hack.

This data not only highlights the risks tied to proxy updates but also underscores the need for continuous monitoring and proactive security measures right after any changes are made. In this fast-paced environment, the sooner vulnerabilities are addressed, the less likely they are to be exploited.

While our research has shown that many vulnerable contracts get exploited within days or weeks of deployment, some attacks happen with astonishing speed. This section highlights the fastest exploits from 2020 to 2025, showcasing just how quickly attackers can identify and exploit vulnerabilities.

The Evolution of Exploit Speed

Looking at the data from 2020 to 2025, we can observe a clear trend: exploit times have been getting dramatically shorter. In 2021, the fastest exploit took over 16 hours, while by 2024, attackers were able to compromise vulnerable contracts in just 10 minutes after deployment.

This acceleration in exploit speed can be attributed to several factors:

• Advancement of blockchain monitoring infrastructure: Sophisticated monitoring systems now scan all new contract deployments in real-time, flagging potential vulnerabilities within seconds. What once required manual code review can now be automated with pattern matching algorithms that identify risky code patterns.
• Evolution of MEV infrastructure: Maximal Extractable Value (MEV) infrastructure has matured significantly, with sophisticated bots constantly monitoring the mempool for profitable opportunities. These systems can automatically detect and exploit vulnerabilities with minimal human intervention.

Security Implications

The trend toward increasingly rapid exploits has profound implications for smart contract security:

1. Pre-deployment security is critical: With exploits happening in minutes, there's virtually no time to fix vulnerabilities after deployment. Thorough testing and auditing before deployment is essential.
2. Monitoring solutions: Implement real-time monitoring systems that can alert teams to suspicious activities immediately after deployment.
3. Time-locked admin functions: Critical functions that could potentially be exploited should include time-locks to provide a window for intervention.

As we move forward, we can expect this trend to continue, with exploit times potentially decreasing even further. This underscores the importance of proactive security measures and the need for developers to assume that any vulnerability will be discovered and exploited almost immediately after deployment.

The most active hour for attacks? UTC , happens during mid-morning in Europe when developers are starting their workday.

A visualization of attack patterns shows clusters aligning with regional working hours, indicating that attacks occur in sync with the daily routines of different regions.

As shown in the chart, attacks cluster into distinct phases:

Based on these trends, it looks like attackers might decide to attack when developers are online and working, possibly to avoid detection in the noise of regular contract activity. But attacks that happen at night may suggest that they were planned ahead of time, where exploits are executed at times when security monitoring may be weaker.

Understanding these timing trends can help teams improve monitoring and response strategies. If most attacks happen during work hours, security teams should focus on real-time anomaly detection and immediate response. If certain networks experience more overnight attacks, automated defense mechanisms should be strengthened during those windows.

In conclusion, the data highlights a dual reality: while of attacks happen within 30 days of a vulnerable contract being deployed, a significant number of more complex vulnerabilities go unnoticed for years. Modern attackers are moving quickly, leveraging automated tools to exploit vulnerabilities within minutes of deployment. Attack methods are becoming more advanced, so should security measures.

Stay safe onchain!