A smart contract can pass an audit and still be exposed by a compromised credential, an unsafe signing process or malicious software in its development chain. Monad co-founder Keone Hon is urging crypto teams to treat operational security as part of security, not an afterthought. He is also promoting the foundation’s AI-assisted contract-testing tool, Ultrafuzz.
- Operational security covers devices, accounts, credentials and software dependencies, not just contract code.
- Monad says Ultrafuzz supports Solidity and Vyper, but warns that its AI agents have unrestricted permissions.
- ChainLight’s reported loss comparison is a historical snapshot. The available details do not specify its cutoff or methodology.
Security extends beyond the code
Hon pointed teams to the Crypto OpSec Bible, written by Omar, along with guidance on administrator accounts and research into using AI to find vulnerabilities. The point is simple: a protocol depends on more than the code deployed on-chain. It also relies on the people, devices and processes used to build and operate it.
Operational security, or OpSec, means protecting those everyday systems. The guide recommends separating personal activity from work devices, using a clean computer or browser for crypto activity, maintaining endpoint protection and checking transaction details before signing.
For critical accounts, it recommends unique passwords and hardware security keys, plus a securely stored backup key. Authentication codes should not be stored alongside passwords. A hardware security key is a physical device that verifies account access. A backup can help prevent lockout if the primary key is lost.
“In this age of AI-empowered attackers, the only way forward for our industry is to continue hardening, ” Hon said.
Hon also highlighted guidance against using externally owned accounts (EOAs) for smart-contract administrator roles and recommended a dedicated laptop for signing administrative functions. An EOA is controlled by a private key rather than smart-contract code. The available details do not spell out all the recommendations for administrator accounts, so teams should consult the guidance itself before deciding that a particular setup is sufficient.
What the loss figures do and do not show
The guide cites ChainLight’s Lumos tracker, which records $3.31 billion in exploited value from “control hijacking, ” compared with $983 million from smart-contract vulnerabilities. The figures cover tracked incidents from January 2023 to a reporting cutoff that the available information does not specify.
The comparison shows why security cannot stop at contract audits. But it is not a definitive ranking of crypto risks. “Control hijacking” includes incidents such as social engineering, private-key leakage, unauthorized access and supply-chain attacks. The other category concerns flaws in contract code. To judge how directly comparable the totals are, readers need the tracker’s category definitions, valuation method and cutoff.
For now, treat the figures as a historical snapshot reported by the tracker, not as a forecast or proof that one type of failure will always cause greater losses.
Ultrafuzz adds AI-assisted testing with a serious caveat
Monad Foundation’s open-source Ultrafuzz tool is designed to examine smart contracts. Monad says it supports Solidity and Vyper, and that more than 20 runs on projects in its ecosystem helped shape the release. The announcement was published on Sept. 10. The available details do not specify the year.
“Smart contract developers, please run Ultrafuzz on your contracts!! It’s open source and available to anyone, ” Hon said.
Monad says Ultrafuzz coordinates specialized AI agents to examine contracts, map user behavior, investigate security properties, run testing strategies and organize findings for review. It can also create and run fuzz tests. Fuzz testing feeds software varied or unexpected inputs to find failures that ordinary tests might miss.
Antonio Viggiano has described developing the tool while helping a team prepare for an external security review. The team had no fuzz tests, which prompted work on an AI-assisted process to create them. That could broaden testing, but it does not show how often Ultrafuzz finds real vulnerabilities or whether it outperforms conventional testing. No detection-rate, false-positive or comparative-performance figures are provided here. Treat it as a testing aid, not a substitute for careful review or a guarantee of security.
Monad warns that Ultrafuzz’s agents have unrestricted permissions and recommends running the tool only in disposable, isolated virtual machines. The available description does not say exactly what those permissions cover, so there is no basis to assume the agents can access a developer’s keys. The safe approach is clear: keep the test environment separate from workstations and accounts with valuable credentials, then destroy it after use.
A compromised dependency can put keys at risk
A reported incident involving an Injective developer package illustrates the supply-chain risk behind Hon’s wider security message. A software dependency is code a project relies on. If a trusted package is compromised, malicious behavior can slip into an application through an ordinary-looking update.
A report summarizing findings attributed to security firm Socket said the package @injectivelabs/sdk-ts, version 1.20.21, contained code that intercepted wallet-generation functions and sent private keys and recovery phrases through fake telemetry. The report said the malicious release had been downloaded about 310 times and that 17 packages depended on the affected version. Those 17 were dependent packages, not necessarily 17 separate compromises.
The report attributed a statement to Injective CEO Eric Chen saying that affected releases had been deprecated and the issue fixed. It also said Socket recommended checking direct and indirect dependencies, moving to clean release 1.20.23, clearing package caches and rebuilding. The available reporting does not establish whether cryptocurrency was stolen. Chen’s reported statement that funds on the Injective network were not at risk does not establish whether individual credentials were exposed.
The incident is described as occurring in July, but the available details do not establish the year. Anyone who used the affected package should check the incident and remediation guidance against Socket’s advisory and Injective’s own records. If wallet material was generated through compromised code, treat it as potentially exposed and follow the project’s verified guidance for securing any affected wallets.
A compromised developer package is not the same as a hack of the Injective blockchain. But that distinction is no reason to dismiss a possible exposure of wallet credentials.
Key questions and answers
-
Why does crypto security go beyond smart contracts?
Projects also depend on secure devices, accounts, credentials, administrator access and software dependencies. Failures in those areas can expose systems or wallet information even when contract code is not the entry point.
-
What does Ultrafuzz do?
Monad describes it as an open-source, AI-assisted tool that examines contracts, investigates security properties, runs testing strategies and organizes findings. Monad says it supports Solidity and Vyper.
-
Does Ultrafuzz replace a security audit?
No performance data provided here shows that it replaces an audit or catches every flaw. It is a testing aid, not a guarantee of safety.
-
How should developers run Ultrafuzz?
Monad recommends a disposable, isolated virtual machine because the agents have unrestricted permissions. Keep valuable credentials and work systems out of that environment.
-
What should users do if they used the compromised Injective package?
Check Socket’s advisory and Injective’s verified remediation guidance, including whether the affected version was in their dependency tree. If wallet material was generated through compromised code, treat it as potentially exposed and follow the recommended steps to secure it.
-
Do the Lumos figures prove control hijacking is always the bigger risk?
No. They are historical tracker totals with an unspecified cutoff and methodology, and the categories may not be directly comparable. They are a reason to pay attention to OpSec, not a universal ranking of risks.
Hon’s central point stands: testing contract code matters, but it cannot secure a careless signing process or a compromised software dependency. AI may help teams test more thoroughly. Running it without isolation creates another risk to manage.
