Note: when a Solidity reentrancy contract drained The DAO of millions of dollars, it became clear: the model of global mutable state plus arbitrary external calls is a fundamental architectural problem. Move solves it differently: resources are not copied or implicitly destroyed, they are moved. Hence the language name.
If you come from a Solidity background, the first week on Move will be painful. Not because it's hard—but because much of what Solidity allows by default, Move forbids at the type system level. We help you make this transition with minimal losses: we show common pitfalls and provide ready-made resource model templates. Over the past years, we have developed more than 30 contracts in Move and use formal verification for critical modules every time.
Move Security Features: Resource Model and Compiler
Linear Type System and Resource Model
In Solidity, a token is an entry in a mapping: mapping(address => uint256) balances. Nothing prevents writing a function that creates tokens out of thin air or "forgets" to deduct a balance. A Move resource exists in exactly one place at a time—this is guaranteed by the bytecode verifier, not an auditor. According to the Move Language documentation, Move Language Book, attributes copy, drop, store, key are abilities. If a type lacks drop, the compiler will not let the function complete without consuming the value. A forgotten resource = compilation error, not lost funds.
// Aptos Move: resource cannot be copied or lost
struct Coin<phantom CoinType> has store {
value: u64,
}
Attack Vectors Closed in Move vs. EVM
| Attack Vector (EVM) | Status in Move |
|---|---|
| Reentrancy | Impossible: no arbitrary external calls to unknown contracts |
| Integer overflow | Impossible: arithmetic aborts on overflow by default |
| Improper proxy initialization | Significantly harder: storage model differs |
| Access control via msg.sender | Replaced with signer—cannot be forged |
| Selfdestruct | No analogue |
This does not mean Move contracts have no vulnerabilities. Logical errors remain. But the class of attacks that consumes 60-70% of EVM audits simply does not exist in Move.
Choosing Between Aptos and Sui
Both chains use Move, but storage architectures are radically different. We have prepared a comparison to help you make a decision.
Aptos: Global Storage and Account-Centric Model
In Aptos, resources are stored in accounts: move_to(account, resource). To access another account's resource, you need an acquires-annotated call: borrow_global<T>(addr). This resembles the EVM pattern mapping(address => struct), but type-safe.
// Aptos: read a specific account's resource
public fun get_balance(owner: address): u64 acquires CoinStore {
borrow_global<CoinStore>(owner).coin.value
}
Parallelism in Aptos is implemented via Block-STM—optimistic execution with rollback on conflicts. This works well if transactions touch different accounts, and poorly if everyone writes to one resource (e.g., a global counter).
Sui: Object Model and True Parallelism
In Sui, everything is an object with a unique ObjectID. A transaction explicitly declares which objects it uses (owned, shared, immutable). The scheduler sees the dependency graph in advance—transactions with non-overlapping objects execute in parallel without optimistic rollbacks.
// Sui: object exists independently of an account
public struct NFT has key, store {
id: UID,
name: String,
// ...
}
public fun transfer_nft(nft: NFT, recipient: address, ctx: &mut TxContext) {
transfer::public_transfer(nft, recipient);
}
For high-TPS DeFi protocols, this is crucial. Shared objects act as shared mutexes, serializing transactions. A well-designed Sui contract maximizes the use of owned objects.
Comparison of Aptos and Sui
| Parameter | Aptos | Sui |
|---|---|---|
| Storage model | Resources in accounts, global access | Objects with ID, explicit ownership |
| Parallelism | Block-STM (optimistic) | Object model (precomputed graph) |
| Typical complexity | Medium (account-centric) | High (object dependencies) |
| Tools | Aptos CLI, Move Framework | Sui CLI, Move Analyzer |
Why Is Move Safer Than Solidity?
Move forbids entire classes of vulnerabilities at the language level: reentrancy, integer overflow, implicit copies. This reduces audit load and bounty costs. Savings of up to 30% on security budget are achieved by eliminating the need for manual analysis of these vectors.
What Is Included in Move Contract Development?
Toolchain and Infrastructure
For Aptos, we use Aptos CLI and Aptos Framework (Move standard library). For Sui, we use Sui CLI and Move Analyzer (LSP plugin for VS Code). Tests are written using Move Test Framework (#[test], #[test_only]) with coverage via aptos move test --coverage or sui move test. For fork testing on Aptos, we use Aptos Local Testnet via Docker. For Sui, the localnet mode of Sui CLI. Integration tests with real protocols (Thala, Cetus, Turbos) require deployment to testnet.
Typical Pitfalls in Your First Move Contract
- **Generic type phantom**: a type parameter not used in fields must be marked `phantom`, otherwise the compiler requires its presence. - **Ability constraints**: generic functions must specify required abilities (store, copy, drop)—otherwise compilation fails. - **Event emission in Sui**: events are not stored on-chain, meaning you cannot subscribe to another contract's events. The architecture must be different.Project Stages
- Analysis—design the resource model, describe signer logic.
- Development—write source code, unit tests, fuzz tests.
- Audit—formal verification via Move Prover, manual code review.
- Deployment—multi-sig deployment, upgrade capability management, documentation.
- Support—1 month warranty support after deployment.
Our experience: over 50 successful projects on EVM and Move. Get a consultation—we will evaluate your project and propose an optimal Move architecture. Discuss your project with our Web3 engineer.
Time and Budget Estimates
A simple token contract on Aptos (fungible asset standard) takes 3-5 days with tests. A lending protocol with price oracles and liquidations takes 4-8 weeks. A cross-chain bridge with finality checks takes from 2 months. The exact cost is determined after a briefing.
Move is a young ecosystem with serious technical advantages. Developer infrastructure lags behind EVM, and documentation sometimes becomes outdated faster than it is updated. But if you need a protocol where the class of reentrancy attacks is eliminated at the language level—this is it.
Contact us to discuss your project—we will evaluate the architecture and propose the optimal solution.