When Aptos launched its mainnet in October 2022 and Sui followed with its own Move-based chain, the Web3 security community faced a question it had not seriously confronted since Ethereum's early days: how do you audit a smart contract language that was not designed to look like Solidity?
The answer, so far, has been mostly to try to force old frameworks onto new code. That approach is failing.
What Move Gets Right
Move was originally developed at Facebook (now Meta) for the Diem blockchain project. Its designers had the benefit of watching Solidity's security failures play out in real time: reentrancy attacks, integer overflows, and the entire category of bugs that stemmed from Solidity's permissive state management. Move addresses these problems at the language level.
Resource-oriented programming is the core innovation. In Move, assets are modeled as resources that cannot be copied, cannot be implicitly discarded, and must be explicitly moved between owners. This eliminates the double-spend-by-bug class entirely. Linear type enforcement means the compiler rejects code that would allow an asset to exist in two places at once. First-order storage means there is no global state that any contract can reach into. These are meaningful improvements.
Move does not eliminate bugs. It eliminates bug classes. The remaining surface is smaller but no less dangerous if you do not understand its shape.
What Move Gets Wrong, Or At Least Different
The problems emerge not from the language itself but from the ecosystem around it. Solidity has been battle-tested across thousands of deployed contracts and billions of dollars in locked value over seven years. The tooling reflects that: Slither, Mythril, Echidna, Foundry's fuzzing, and formal verification frameworks like Certora are all mature and well understood. When a Solidity auditor sits down to review a contract, they have an arsenal.
Move auditors do not. The Move Prover, a formal verification tool built alongside the language, is powerful but difficult to use correctly and requires writing separate specification code. Static analysis tools for Move are early-stage at best. Fuzzing frameworks that understand Move's execution semantics are limited. Most of the automated tooling that security firms rely on simply does not exist yet for Move-based chains.
This creates a dangerous asymmetry. Teams building on Sui and Aptos believe their code is safer because the language is safer, and they invest less in auditing. Auditors who take on Move contracts often apply Solidity-era mental models that miss the distinct vulnerability patterns of resource-oriented programming.
The Vulnerability Patterns Nobody Is Talking About
In our own audit work on Move contracts over the past six months, we have identified several recurring patterns that are specific to the language's design and that existing Solidity-trained auditors consistently miss.
Capability leakage. Move uses a capability system to authorize privileged operations. A capability is a resource that grants its holder the right to perform an action. If a capability resource is stored in a shared object or returned from a public function without proper access controls, any address can acquire it and perform the privileged action. This is not a bug in Move. It is a correct use of the type system. But the implications are easy to overlook if you are not thinking in terms of capability discipline.
Object ownership confusion on Sui. Sui's object-centric model introduces a distinction between owned objects and shared objects that does not exist in the same way on other chains. Owned objects can be transacted on in parallel without consensus, which is a performance win. But if a developer incorrectly assumes an object is shared (and thus sequentially processed) when it is actually owned, race conditions can emerge that are extremely difficult to detect in testing.
Module upgrade risks. Both Aptos and Sui support upgradeable modules, but the upgrade mechanisms interact with the type system in ways that can invalidate invariants that held in the previous version. An upgrade that changes a struct's fields, for example, can orphan existing resources or break assumptions in dependent modules. There is no equivalent to Solidity's proxy pattern confusion here, but there is an equivalent class of upgrade-related bugs that is under-documented and under-tested.
The most dangerous assumption a Move developer can make is that the language will save them from their own logic errors.
Why Current Audit Practices Fall Short
Most Web3 audit firms expanded into Move auditing by taking their Solidity teams, reading the language documentation, and declaring readiness. This is understandable from a business perspective but insufficient from a security perspective.
The issue is not competence. Solidity auditors are skilled at reasoning about smart contract risks. The issue is mental models. Solidity trains you to think in terms of state machines with global storage, message-based execution, and a specific set of known antipatterns. Move demands that you think in terms of resource lifecycles, capability flows, and object ownership semantics. These are fundamentally different frames, and you cannot switch between them by reading a README.
At ReguSec, we have had to build an entirely separate review methodology for Move contracts. It starts with capability flow mapping: tracing every capability resource from creation through transfer to use, identifying any path where a capability could be acquired by an unauthorized party. It includes object ownership analysis for Sui contracts, where we model the parallel execution assumptions and verify them against the actual ownership configuration. And it requires manual specification writing for the Move Prover, which in our experience catches bugs that neither human review nor the Prover alone would find.
What We Recommend
Building on Move and need an audit that goes beyond the Solidity playbook? Get in touch with our team.