Hexens CEO on Web3 Security: Why Smart Contract Audits Aren’t Enough

For blockchain projects, a smart contract audit can leave major parts of the system unchecked. Websites, domain name services and other familiar online components can expose routes into projects whose security work focuses mainly on on-chain code. Sipan Vardanyan, co-founder and CEO of cybersecurity firm Hexens, argues that teams need experience with both Web2 and Web3 attack methods to find those gaps.

His assessment comes from a field where a single flaw may put substantial funds at risk. Unlike many conventional software attacks, an exploit in blockchain code can enable an attacker to move assets quickly. Vardanyan says some vulnerabilities have led to losses of hundreds of millions of dollars, making security reviews a continuing engineering task rather than a one-time check before launch.

One flaw can put funds at risk

Vardanyan sees two connected challenges: weaknesses in blockchain code and insufficient attention to conventional attack routes. He says some companies treat a smart contract audit as their main security measure, even though attackers can target more than contracts. A vulnerable line of code may be enough to expose a project’s funds, while websites and other connected systems can create additional entry points.

Common contract issues include re-entrancy attacks and failures to validate inputs properly. Projects that hold substantial funds—such as bridges, wallets and exchanges—are also attractive targets. Vardanyan points to private key leaks as another sign that attackers are applying methods associated with Web2 systems to blockchain businesses.

There isn’t one vulnerability pattern that explains every major incident, he says. Each project has its own code and design, so a flaw in one system may have little in common with an exploit elsewhere. That limits the usefulness of relying only on a checklist built from past incidents: teams need to examine how their own components work together and where funds or credentials could be exposed.

Attack methods also change. Vardanyan expects blockchain technology to become more secure over time, but says attackers will keep adapting and may increasingly use conventional routes. For development teams, that means treating security as a recurring part of building and operating a system, with reviews repeated as the technology changes.

Audits need to cover the full system

Vardanyan says some cybersecurity providers lack enough prior Web2 experience, have incomplete knowledge of Web3 security, or apply the same approach to every client. He also identifies rapid growth, inadequate internal methods, and a shortage of suitable tools as factors that can reduce service quality.

Contract audits remain important, but they address only one part of a project. Web3 businesses typically rely on Web2 interfaces, including websites and domain name services. Those components add attack surfaces that attackers can use to reach users or interfere with a project. A review that stops at contract code can therefore miss risks elsewhere in the technical stack.

His advice is to map each project’s possible exposure and tailor the review to its systems. In practice, that means considering how the on-chain components connect to websites and other services, as well as how the project handles sensitive credentials. The aim is to find vulnerabilities before someone else does, while recognizing that no review can establish that a system has no bugs.

Independent reviews can matter especially when a widely used platform sits beneath many applications. Vardanyan says an error in Polygon’s code could affect thousands of decentralized applications built on it, along with their users. Hexens has also reviewed Polygon zkEVM, which uses zero-knowledge proofs. The firm says its work includes security for emerging areas such as ZK proofs and liquid staking.

A review is a snapshot, not a lasting guarantee. It can reveal bugs that auditors find, but it can’t prove that no other flaws exist. As code changes and attackers develop new techniques, projects need further reviews to keep assessing their exposure. Vardanyan recommends working with security specialists at regular intervals during development.

Two teams, multiple perspectives

Hexens says its review process assigns two teams to each engagement. Each team includes at least a lead engineer and a senior engineer, alongside auditors with varying experience. Vardanyan’s stated rationale is to reduce the chance that one team’s assumptions or mistakes shape the entire review. He also says the firm draws on auditors with years of Web2 experience and adapts its work to each client.

That approach reflects the broader argument: finding weaknesses requires thinking across the boundaries between blockchain code and the systems surrounding it. The firm says it keeps its team and client portfolio small to preserve attention as it conducts reviews, and is working on tools intended to help more companies maintain security. These are Hexens’ descriptions of its methods; the interview doesn’t provide comparative performance data for its review model.

Shared learning can reduce repeated mistakes

Vardanyan also sees a role for developers to share what they learn. Teams can describe vulnerabilities they find, explain which coding practices have worked for them, and point peers to useful security resources. Reports published by security firms can help developers recognize recurring mistakes and avoid introducing similar weaknesses in their own systems.

Users, meanwhile, can look for projects whose technology has received thorough review from cybersecurity firms with an established track record. Vardanyan recommends keeping up with reports of incidents, since they can help users assess the security history of platforms they use. Neither step removes risk, but both can make security work and past failures easier to evaluate.

Vardanyan has more than 11 years of cybersecurity experience. He has worked as a banking-sector CISO, teaches cybersecurity, advises startups and has won several security competitions, including first place at PHDays VI with the Antichat team. He was also undefeated in Competitive Intelligence competitions in 2017, 2018 and 2019 under the nickname Noyer.

The practical message for blockchain teams is to assess the entire system, revisit that assessment as the code and infrastructure change, and build security knowledge across the developer community. A contract review is a useful part of that process, but websites, domains, key handling and other connected components can matter just as much to a project’s exposure.