AI-assisted attacks on unverified smart contracts are accelerating

At a glance

What this is: Chainalysis reports that attackers stole $36.7 million from unverified smart contracts in six months, highlighting a growing exploit pattern driven by decompilation and AI-assisted analysis.

Why it matters: For IAM and security teams, this shows how control gaps around code verification, runtime monitoring, and lifecycle governance can create exploitable blind spots even when a protocol believes it has security coverage.

By the numbers:

• Attackers stole $36.7 million across four hacks of unverified smart contracts over the past six months, according to Chainalysis.
• The more than $1 billion that DeFiLlama records being stolen from 88 protocols provides the broader loss context for this attack pattern, according to DeFiLlama.
• Truebit accounted for $26.2 million of the losses described in the article, making it the largest named exploit in the dataset, according to Chainalysis.

👉 Read Chainalysis' analysis of AI-assisted attacks on unverified smart contracts

Context

Unverified smart contracts create a governance gap because the usual community review cycle, audit transparency, and bug bounty coverage depend on readable source code. When that code is hidden, defenders lose the passive assurance layer that verified contracts receive, and attackers can still recover enough structure from bytecode to search for weaknesses.

The primary security issue here is not just openness versus secrecy. It is whether a protocol can prove what it deployed, monitor what it runs, and contain harm when exploitation begins. That intersects with identity governance only indirectly through access control and privileged contract behaviour, but the central problem is runtime security and code trust rather than IAM.

As AI-assisted decompilation improves, unverified deployments become easier to triage at scale. That makes source verification and real-time monitoring a baseline control, not a disclosure preference.

Key questions

Q: What breaks when smart contracts are deployed without verified source code?

A: When source code is not verified, defenders lose the broad review surface that catches logic errors before attackers do. The contract can still be analysed through bytecode, but the hidden implementation reduces transparency, limits bug bounty coverage, and shifts security from prevention to detection after deployment.

Q: Why do unverified contracts attract attackers even though the code is harder to read?

A: They attract attackers because decompilation has become good enough to expose structure, and AI tools can then search the recovered code for exploitable patterns at scale. The trade-off now favours attackers when defenders rely on obscurity instead of runtime controls and independent verification.

Q: How can teams know if an unverified contract is operating outside its intended boundary?

A: Teams should monitor for unexpected function calls, unusual token movement, and changes in transaction patterns that do not match normal protocol behaviour. If the code cannot be read publicly, behavioural telemetry becomes the practical indicator that the contract is being abused or is drifting outside its designed use.

Q: Who is accountable when a hidden contract is exploited and user funds are lost?

A: Accountability sits with the protocol operator, because deploying opaque production code does not remove the duty to verify what was shipped and to monitor it continuously. Security, engineering, and governance leaders should treat source verification and runtime monitoring as owned controls, not optional safeguards.

Technical breakdown

Why unverified smart contracts create a hidden attack surface

A smart contract is unverified when the source code on a block explorer does not match a public, readable implementation. Attackers can still inspect the compiled bytecode and recover enough structure through decompilation to identify functions, storage layout, and likely logic paths. The output is imperfect, but it is increasingly usable, especially when combined with automated analysis. Defenders lose the broad review ecosystem that verified code attracts, including audit participants, researchers, and bug bounty hunters. That changes the economics of discovery in favour of attackers, because the target remains live even when its logic is not publicly inspectable.

Practical implication: treat source verification as a deployment control, not a disclosure preference, for any contract that holds user funds.

How AI-assisted decompilation changes exploit discovery

Modern decompilers can turn EVM bytecode into readable pseudo-Solidity, and large language models can then scan that output for common flaws such as reentrancy, access control mistakes, and arithmetic errors. The key shift is scale. What once required manual reverse engineering of one contract can now be chained into workflows that inspect thousands of contracts, rank them by exploitability, and prioritise those with larger potential yield. That does not make exploitation automatic, but it compresses attacker time-to-insight enough to make obscurity-based defenses unreliable. The more contracts remain unverified, the more candidates automated pipelines can evaluate.

Practical implication: assume attackers can decompile first and ask later, then design detection and containment around that assumption.

Why runtime monitoring matters when source review is unavailable

If a contract is unverified, defenders cannot rely on pre-exploit code review to surface every issue. That shifts security emphasis to on-chain telemetry, behavioural anomaly detection, and automated response controls such as pause mechanisms or transaction blocking. In practice, runtime monitoring becomes the last line of defense because it watches what the contract actually does rather than what the team hoped it would do. This is especially important for proxy patterns, where a verified shell can hide an unverified implementation. The operational lesson is simple: if code transparency is missing, runtime visibility has to increase.

Practical implication: instrument suspicious function calls and abnormal value movement before an exploit can complete.

Threat narrative

Attacker objective: The attacker aims to extract protocol funds from contracts that were assumed to be safer because they were harder to inspect.

1. Entry begins when attackers identify unverified contract bytecode that can be decompiled and analysed without public source code.
2. Escalation follows when automated tooling and LLMs surface a viable logic flaw such as integer overflow, access control failure, or validation bypass.
3. Impact occurs when the attacker executes the faulty path, drains funds, and launders proceeds through privacy tooling or other concealment channels.

NHI Mgmt Group analysis

Unverified contract governance is a trust problem, not a visibility preference. When deployed logic cannot be independently inspected, the protocol is asking users to trust hidden execution paths while also expecting defenders to catch problems after the fact. That model weakens the review ecosystem that verified contracts depend on. The practical conclusion is that unverifiable production code should be treated as a governance exception, not an acceptable normal state.

AI-assisted bytecode analysis creates a new form of security debt: decompilation gap. The article shows that attackers no longer need perfect source code to find exploitable patterns. Once decompiled output can be fed into LLM workflows, the limiting factor becomes defender detection speed rather than attacker understanding. Teams should recognise that hiding source code no longer buys meaningful protection when analysis pipelines are scaling faster than manual oversight.

Hidden implementations behind verified shells are now a distinct failure mode. The article notes that several exploits targeted unverified implementations hidden behind proxy structures, which means assurance attached to the visible contract can be misleading. That pattern matters because security review often stops at the published interface instead of the live implementation. Practitioners should treat proxy transparency as part of deployment governance, not a secondary technical detail.

Runtime controls must replace missing pre-deploy assurance when code is closed. The most defensible posture for unverified contracts is not hope, it is containment through real-time monitoring, automated pausing, and strict scope reduction for funds at rest. This is a control-plane issue more than a development issue. Practitioners should align operational response to the assumption that review gaps will be exploited.

What this signals

Decompilation gap: security programmes should assume that hidden logic can still be reconstructed well enough for exploitation, which means detection and containment must be designed for opaque production artefacts. The operational question is no longer whether source code is public, but whether the runtime is observable enough to stop abuse before funds leave the contract.

AI-assisted analysis pushes blockchain exploitation closer to the same pipeline-driven pattern already visible in other security domains, where automation reduces attacker cost faster than defender response time. Teams should strengthen transaction monitoring, proxy transparency reviews, and release governance before closed-source deployments become routine attack magnets.

For organisations with any cryptographic or workload identity dependency, the lesson transfers cleanly: if the control plane cannot prove what is deployed, the attack surface expands faster than traditional review processes can close it. That is a governance problem as much as a technical one.

For practitioners

• Require source verification for every fund-holding deployment Block production release unless the deployed bytecode can be matched to readable source code on the relevant block explorer, including implementation contracts behind proxies.
• Expand audit scope to the live implementation Review the exact contract that runs in production, not just the intended design, and re-check any implementation added after the last audit cycle.
• Put unverified contracts into bug bounty scope Include any contract that can move or custody user funds, even if it is legacy code or a recently added feature outside the original bounty boundary.
• Instrument on-chain anomaly detection and auto-pause controls Watch for suspicious function calls, abnormal value transfers, and rapid drain patterns, then trigger automated response before funds leave the contract.
• Map proxy transparency as a governance control Track which visible contracts depend on hidden implementations so security and compliance teams know where assurance ends and runtime monitoring must begin.

Key takeaways

• Unverified smart contracts are increasingly being treated as searchable attack surface, not as security through obscurity.
• The article ties $36.7 million in losses to a pattern in which bytecode decompilation and AI-assisted analysis reduce the defender’s advantage.
• Protocols that cannot verify source code must compensate with live monitoring, tighter deployment governance, and stricter fund-custody controls.

Key terms

• Unverified Smart Contract: A smart contract whose source code has not been publicly verified against the deployed bytecode on a block explorer. Without that verification, independent reviewers cannot inspect the exact logic running in production, which weakens pre-deployment scrutiny and shifts reliance toward runtime monitoring and post-incident analysis.
• Bytecode Decompilation: The process of converting compiled blockchain bytecode back into a readable approximation of source logic. Decompilation is imperfect, but it can reveal function structure, storage behaviour, and suspicious patterns closely enough for attackers or defenders to analyse risk at scale.
• Proxy Shell: A visible contract that forwards execution to a separate implementation contract. Proxy patterns can support upgradeability, but they also create assurance gaps if the shell is verified while the implementation remains hidden or changes outside normal review controls.
• Runtime Monitoring: Continuous observation of live contract behaviour to detect suspicious calls, abnormal value movement, and other signs of abuse. It becomes especially important when source code is unavailable, because behavioural telemetry may be the only practical way to spot exploitation in time.

What's in the full report

Chainalysis' full analysis covers the operational detail this post intentionally leaves for the source:

• A protocol-by-protocol breakdown of the four unverified-contract exploits and the vulnerable functions involved.
• The bytecode-to-decompilation workflow attackers use to identify reentrancy, access control, and arithmetic flaws.
• The monitoring and pause-control approaches Chainalysis says can detect suspicious on-chain behaviour before funds are lost.
• The implications of proxy patterns where a verified shell can hide an unverified implementation.

👉 Chainalysis' full analysis covers the exploit mechanics, affected protocols, and runtime monitoring implications.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of operational control. It gives security practitioners a structured way to govern identity-linked risk across modern programmes.