This content originally appeared on HackerNoon and was authored by Olayimika Oyebanji
Blockchain security is still the cornerstone of Web3 as smart contracts manage increasingly large amounts of money. Routine audits and ongoing security practices have become essential components of responsible development, yet exploits continue to occur even in audited projects.
Olayimika Oyebanji recently sat down with Andrew Isaacs, Co-founder and COO of Neyro, to discuss the current state of blockchain cybersecurity, smart contract auditing processes, and the practical realities projects face. Let’s dive in.
Can you briefly tell the readers about yourself and your route to web3?
I have 18+ years in all kinds of investment banking, both the boring kind with graphs and data, and the exciting ones with deals and negotiations. My route to Web3 started in 2017 with the dawn of DeFi, first out of curiosity, then in pursuit of making it better. I co-founded Neyro because DeFi and Web3 lack institutional-grade execution systems, leaving execution to manual user input.
What have been the most significant changes in smart contract security threats and attack vectors between 2024 and 2026?
In 1984, William Gibson wrote Neuromancer, and in 1992 Neal Stephenson wrote Snow Crash; those two books told an interesting story in the background about how hackers and counterhackers use automated tools to seek out and exploit vulnerabilities. It’s 2026, and we have both people and LLMs scan for exploits.
As per recent Chainalysis report, unverified smart contracts became the main attack vector, and since 2023 there’s a growth in smart-contract attacks, price manipulation hacks, and private key compromises.
Automated penetration became a thing. AI based penetration attempts on all kinds of code began somewhere in 2023; this trend strengthened in 2024, continued to mature into a fully grown attack vector by 2025, and became a staple tool in 2026.
People don’t need to be technical to hack anymore. One particular case stuck with me: kids used ChatGPT to hack into Rakuten systems. On top of that, since 2024, hackers are actively using LLMs and LLM-based agents to search for vulnerabilities and ruthlessly exploit them.
Social engineering of open-source GitHub repositories by North Korean hackers became a thing, and with it, increased the risk of hackers trying to play as a part of the project’s team. Old-school self-replicating worms resurfaced, and with them, npm attacks aimed at data theft. Overall, code and people behind it are still the main targets, but attackers find new ways to compromise both.
Recent smart contract exploits prove that even audited projects are still vulnerable. Why is a one-time audit often insufficient, and what does a robust, ongoing smart contract security program do?
One-time audits are good, but the project's code will change after the initial investigation. Once auditors close the tickets and compose a lengthy review, the project's team will move on and write new code, add more features, and tweak existing code to accommodate changes.
A one-time security audit is good when you don’t need to change code often, yet it proves the project is secure at that exact moment. New exploits can be found and used, so an ongoing smart-contract security program helps to detect bugs and exploits as they come.
For AI-integrated smart contract systems like trading agents, what unique security challenges arise compared to traditional DeFi protocols, particularly around oracle dependencies, agent autonomy, or non-custodial execution?
Data purity and reliability. Bluntly put, attackers can try to poison data AI agents are using in order to manipulate them. It can be mitigated by multiple validation steps, by working with reliable data providers, by using multiple sources, and cross-validating the inputs.
Non-custodial errors are irreversible, and users need to be aware of the access rights given to the agent. The industry standard is reviewing your access rights every week when you do active trading and once a month if you are mildly active in the blockchain space.
Prompt injection is still a thing; it can be mitigated with robust guardrails and oversight over agentic logic, but it still exists. A basic way to mitigate this is by limiting the amount of inputs an AI agent receives to trusted-only, and filtering token metadata because it can be used to deliver prompt payload.
Containing agents in a secure environment, stripping their file manipulation abilities, keeping them as far as possible from the database and source code, as well as preventing agents from exploring the web on their own are nice starting steps.
What is the main motivation for engaging multiple top-tier auditors like CertiK and Hacken, and how do their approaches differ in practice?
The more eyes that look at the code, the more chances it’s secure. Every software auditing company has its own approach and philosophy, and they prioritize different key aspects. Everyone can do a basic code audit with a Claude or any other LLM, but skilled professionals can tell where else besides the code the problem may be, and how to prevent future issues.
Recently we successfully completed the Hacken audit of our smart-contract, and passed 69 reviews with 0 vulnerabilities found at Hacken DualDefence bug bounty program. Currently we're doing an ongoing CertiK audit as well, so I can share our experience with both parties in question.
CertiK is the AI pentesting factory. They can deploy your smart-contract in a testing environment and see if it mathematically behaves the same way across every possible scenario.
While they do manual testing, automated pentesting helps to detect and prevent leaks which can be exploited by automated hacking tools. They run multiple tests, thousands of them in a tedious audit to see if anything clicks, and this is exactly how AI-hacking tools seem to behave nowadays. Nothing beats them at brute-forcing every automated attack scenario.
Hacken are the white hats with long ponytails who don’t overexplain and pentest every living byte out of your project. They offer a two-layer audit approach: one is a regular safety check, and the other is an active bug bounty program inside their ecosystem called HackenProof.
They look for holes and exploit scenarios automated tools miss, but a skilled attacker can and will find given time. While AI tools look for immediate exploits, human attackers often look at complex and chained actions which lead to exposing a vulnerability sandwiched between different code parts and modules interacting with each other. Sometimes you can have a completely secure smart-contract, but the way your software interacts with it is flawed.
What are the most common categories of vulnerabilities you’ve seen persist even after professional audits — such as logic errors, access control issues, or economic design flaws?
Human oversight is the one issue that persists even after professional audits. Social engineering, namely phishing, remains one of the main attack vectors both in professional and enthusiast environments — that’s how attackers obtain private keys most of the time.
Audits can’t fix flawed tokenomics. This example is overused, but Terra Luna was audited and assured to be secure. The real vulnerability lied elsewhere, both in tokenomics and in human oversight.
How important are formal verification, automated tools, and manual review in a comprehensive audit process today? Where do you see strengths and limitations in each?
As in the CertiK and Hacken example, both approaches have their place, because both approaches are used by the attackers in real-life scenarios.
Automated tools bruteforce common attack vectors in the code. Using LLMs to search for exploits just makes sense for the attackers, so using the same approach to pentest your code before deploying it helps to mitigate such attacks.
A comprehensive human audit pentests your actual security, not only code. Your code can be flawless, pass every test, compile every time, no errors, no exposed API keys in the metadata, no memory leaks, all variables vulnerable to buffer overflow are contained and limited, everything’s smooth.
But then you can have a library dependency tied to an open-source repository which is getting penetrated by North Korean hackers. That’s what human audit helps to uncover — weakest links in the chain.
From an operational perspective, what are the biggest practical challenges teams face when implementing audit recommendations — especially regarding timelines, costs, and trade-offs with product development?
You have to stop whatever you’re doing and patch the software up. A common approach is to start with critical vulnerabilities, then you can look at secondary ones, and only after both are solved you resume active product development.
You can’t wait when vulnerabilities are found. North Korean hackers use automated LLM agents to seek and penetrate 24/7, non-stop, without sleep and on state-issued caffeinated drinks. If you waffle they’ll exploit it and take your whole project down.
Any new feature has to be pentested internally before launch. If a new addition to the project functionality even has a potential to break anything, you have to delay it and polish until it’s safe.
It is costly, but it is the way. With hacks you either pay in money or in reputation, and money is always cheaper in that regard.
Many projects now combine audits with bug bounty programs and continuous monitoring. How effective is this layered approach in identifying issues that static audits might miss?
Bug bounty have, de facto, become the industry standard. This layered approach, when you use one-time audits with continuous reviews, helps to mitigate most of the attacks. It also helps to have expert cybersecurity teams on speed dial of sorts to consult whether your new update can actually break the project’s security.
With bug bounties you essentially pay hackers for not using your vulnerabilities. Pentesters will find a way to use the exploit one way or another. One way to avoid this is to run a bounty program on critical vulnerabilities and pay them for doing their job properly.
What advice would you give to blockchain projects regarding security hygiene, audit frequency, and post-deployment monitoring in the current environment?
Always check your dependencies, and don’t rush updates for libraries. Try to stay one version behind the main branch and only update what’s needed or when a new update introduces patches for bugs; this way you have at least a small buffer before you deploy anything malicious. The initial XZ Utils supply chain attack aimed at the next major update of the Linux kernel, and people who downloaded it right away got exposed first.
Go from one-time audits to continuous programs when possible. This is self-explanatory, whether you are an enthusiast who coded his first MVP or a small team who secured a bag from an angel investor — invest as much as you can in a one-time audit, and gradually climb towards continuous programs.
Have a separate testing environment before deployment. It is costly, and time consuming, but it helps to see if anything you add or tweak breaks in production. This is a basic GIT approach to version control, but keeping it in mind always helps.
This content originally appeared on HackerNoon and was authored by Olayimika Oyebanji
Olayimika Oyebanji | Sciencx (2026-06-22T03:47:10+00:00) Neyro COO Andrew Isaacs on Multi-Auditor Strategies and Blockchain Cybersecurity Challenges . Retrieved from https://www.scien.cx/2026/06/22/neyro-coo-andrew-isaacs-on-multi-auditor-strategies-and-blockchain-cybersecurity-challenges/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.