Although the Web3 ecosystem is still young, the pace of development has increased significantly over the last few years. Despite this rapid development, Web3 news continues to be dominated by reports of protocols losing millions of dollars’ worth of value to the same classes of vulnerabilities that plagued the space in its infancy. In fact, 2022 was a record year for hackers in the Web3 space who stole over 4.3 billion USD worth of cryptocurrencies.

Why is it that Web3 protocols have so many critical vulnerabilities? At Arbitrary Execution, finding security vulnerabilities in smart contracts is one of our areas of expertise. Over our history of conducting security audits for companies operating in the Web3 space, we’ve noticed a recurring trend with development teams that contributes to the current state of security: security practices are rarely incorporated throughout the Web3 development life cycle. But why is this? Do Web3 development teams simply not care about security? Do they want the protocols they develop to be hacked? The answer to both questions is obviously “no.” Every development team we have worked with has an interest in securing their protocol. So, what’s going on, and why aren’t these teams incorporating security practices into their development life cycles?

In order to answer these questions, we’ll describe four factors preventing Web3 development teams from integrating security practices into their development processes.

Speed over security

Web3 is a growing space with lots of opportunities for new markets. This incentivizes companies to release their protocols as quickly as possible to gain the coveted first-mover advantage. As such, Web3 developers frequently feel intense pressure to get protocol functionality out the door as fast as possible. This urgency leaves little time for focus on tasks unrelated to direct protocol development. Security-related tasks are at odds with development.

The position for focusing on security efforts is worsened by the fact that the Web3 development space lacks a cohesive framework for unifying existing security practices. The lack of such a framework means that developers must figure out how to incorporate security practices into their own development life cycles by themselves. Creating such a framework independently is a big lift and would come at the cost of significant development time. Faced with the pressure of quick market releases, it’s easy to see why security can be an afterthought during development.

Small teams

Web3 companies tend to be small, and their development teams are even smaller. It’s not uncommon to come across development teams of three or fewer people. Smaller companies frequently have small budgets, which means they can’t afford to staff a dedicated product security (prod-sec) team.

In traditional development shops, it’s usually the job of the prod-sec team to both educate developers on security topics and enforce the use of security practices. Without a prod-sec team, this education and enforcement are left to development teams, who tend to be overworked with their existing day-to-day development tasks. It’s not feasible to expect a small company to staff a full-time prod-sec team.

So, when developers are responsible for establishing the security processes that they themselves will follow, what do they do? A lot of times, the answer is less than they should. It’s not reasonable to expect a small development team to build strong internal security practices while its members also play other roles (and sometimes even non-development roles, which is the case in many start-ups). So once again, security practices become backlog fodder.

Lack of trusted materials

What happens when development teams are afforded the time to work on security-related tasks? This brings us to our next observation: Trusted materials covering some parts of the secure development life cycle are notably lacking. A quick Google search will yield some information on security practices that are relevant to Web3 development. However, if you don’t have a security background, how do you know which practices can increase your protocol’s security posture and which are time wasters?

Many developers don’t need to be convinced of the quality of material from well-known sources, but what happens when you’re faced with a Medium post from an unknown author? Most developers don’t have the security experience to separate the wheat from the chaff, especially when the content is not written by one of the few trusted Web3 security sources.

No prescription for success

Let’s say you are a developer, and you find some security resources from a trusted source. This leads us to our fourth and final observation: The material on secure practices that does exist is almost always descriptive, rather than prescriptive. How many times have you come across a tool or framework whose description makes it sound useful for a project you’re working on, but when you read its documentation, you never find any information on how you should use it? And even when you do find that information, how often does that information lack examples using realistic, production code? In our experience, far too often.

You’re far more likely to find demonstrations of security practices and tooling applied to contrived code samples that would never appear in production-quality software. While that descriptive material could improve security posture, it takes a lot of time and effort to understand the material well enough to apply it to an actual code base. Most Web3 developers don't have this time, as their schedules are already filled with development tasks. The result is that efforts to translate descriptive security content into prescriptive, actionable guidelines are pushed into backlogs, where they never see the light of day again.

Closing thoughts

After performing our varied security audits and consulting projects, we believe the biggest reason why the Web3 space is so prone to damaging hacks is the failure to integrate security practices into development life cycles. We’ve observed a set of recurring themes that contribute to this current state:

  • Companies favor faster paths to market
  • Companies tend to have small development teams
  • A lack of trusted material on security practices relating to certain parts of the development life cycle
  • Existing security content being descriptive rather than prescriptive


So, what’s a Web3 developer to do in the face of all these challenges? For now, our recommendation is to stay tuned to our LinkedIn and Twitter feeds. We’ll be making a big announcement during this year’s ETH Denver conference that we hope will provide a solution to many, if not all, of these problems.